JP5445237B2 - プロトコル代行処理装置及び方法 - Google Patents

プロトコル代行処理装置及び方法 Download PDF

Info

Publication number
JP5445237B2
JP5445237B2 JP2010052586A JP2010052586A JP5445237B2 JP 5445237 B2 JP5445237 B2 JP 5445237B2 JP 2010052586 A JP2010052586 A JP 2010052586A JP 2010052586 A JP2010052586 A JP 2010052586A JP 5445237 B2 JP5445237 B2 JP 5445237B2
Authority
JP
Japan
Prior art keywords
diameter
protocol
message
identification information
diameter message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010052586A
Other languages
English (en)
Other versions
JP2011188326A (ja
Inventor
武士 鶴見
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2010052586A priority Critical patent/JP5445237B2/ja
Publication of JP2011188326A publication Critical patent/JP2011188326A/ja
Application granted granted Critical
Publication of JP5445237B2 publication Critical patent/JP5445237B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Communication Control (AREA)

Description

本発明は、プロトコル代行処理装置及び方法に関する。本発明は、IMS(IP Multimedia Subsystem)を構成する呼制御等を行う通信システムであって、Diameterプロトコルを用いる通信システムにおけるプロトコル処理等に適用することができる。
Diameterプロトコルは、RADIUSプロトコルの後継となる認証・認可・課金(AAA:Authentication, Authorization, Accounting)プロトコルであり、RADIUSで使われているUDP(User Datagram Protocol)ではなく、信頼性のあるトランスポートプロトコルであるトランスミッション制御プロトコル(TCP:Transmission Control Protocol)又はストリーム制御トランスミッションプロトコル(SCTP:Stream Control Transmission Protocol)が用いられる。
図12にIMS(IP Multimedia Subsystem)の構成例を示す。図12において、呼セッション制御装置(CSCF:Call Session Control Function)11は、加入者位置情報サーバ(SLF:Subscription Locator Function)12から、着信先加入者等の加入者情報を保持するホーム加入者情報サーバ(HSS:Home Subscriber Server)13の情報を取得する。
呼セッション制御装置(CSCF)11は、ホーム加入者情報サーバ(HSS)13から着信先加入者等の加入者情報を取得し、該加入者情報により呼セッション制御を行う。また、呼セッション制御装置(CSCF)11は、アプリケーションサーバ(AS:Application Server)14と連携して各種サービスの提供を行う。
呼セッション制御装置(CSCF)11と加入者位置情報サーバ(SLF)12との間、及び呼セッション制御装置(CSCF)11とホーム加入者情報サーバ(HSS)13との間では、Diameter/SCTPのプロトコル等が用いられる。また、呼セッション制御装置(CSCF)11とアプリケーションサーバ(AS)14との間、及び呼セッション制御装置(CSCF)11と他のIP網のノード15との間では、SIP(Session Initiation Protocol)のプロトコル等が用いられる。
Diameter/SCTP(SCTPプロトコル上のDiameterプロトコル)を扱うためには、ストリーム制御トランスミッションプロトコル(SCTP)の規格上、対向装置とのインタフェースにおいて少なくとも第1(Primary)及び第2(Secondary)の物理的に異なるネットワークインタフェースカード(NIC)を備えることとなる。
そのため、従来の呼セッション制御装置(CSCF)では、対向する加入者位置情報サーバ(SLF)やホーム加入者情報サーバ(HSS)等の対向装置毎に、第1(Primary)及び第2(Secondary)の物理的に異なるネットワークインタフェースカード(NIC)を設けていた。
さらに、個々のネットワークインタフェースカード(NIC)をbond等により物理的に冗長構成化した場合、1つの対向装置との接続に設けられるネットワークインタフェースカード(NIC)の数が4つとなる。そのため、複数の異なるセグメントに属する対向装置間でDiameter/SCTPのプロトコルを適用した場合、ネットワークインタフェースカード(NIC)の数が多くなり、物理的に実装可能な数の制限を超えてしまい、Diameter/SCTPのプロトコルの適用が困難となるという問題があった。
Diameterプロトコルの規格上、トランスポートプロトコルとしてトランスミッション制御プロトコル(TCP)のみサポートする構成も許容される。しかし、このような構成の装置にDiameter/SCTPのプロトコルを適用する場合、改造が大掛かりなものとなり、実装変更の負担が大きく、容易に適用することができないという問題があった。
さらに、オペレーティングシステム(OS)がLinuxの場合、ストリーム制御トランスミッションプロトコル(SCTP)の制限上、オペレーティングシステム(OS)も32ビットとなり、アプリケーションソフトウェアで使用可能なメモリ空間は最大3GBとなっていた。
これは、アプリケーションソフトウェアが32ビットのとき、SCTPでは、OSも32ビットで動作させることとなり、LinuxではOSをEMT64T(Extended Memory 64 Technology)の32ビット互換モードにより64ビットで動作させることができないためである。なお、TCPではOSが64ビットでも動作可能である。
ストリーム制御トランスミッションプロトコル(SCTP)とトランスミッション制御プロトコル(TCP)とに関しては、例えば特許文献1に記載されている。該特許文献1には、SCTPのマルチホーミングにより接続された移動局と、TCPにより接続されたステーションとの間で、シームレスなハンドオフを達成する技術等について記載されている。また、セッション中継の技術として、到着したパケットが属するセッションをセッション識別部で決定し、送信端末のセッションと受信端末のセッションの中継を、セッション中継部により行う技術は特許文献2等に記載されている。
特表2005−535230号公報 国際公開第2005/020523号
本発明は、Diameter/SCTPのプロトコルをサポートせず、Diameter/TCPのプロトコルをサポートする呼セッション制御装置(CSCF)等のノード装置に対して、Diameter/SCTPのプロトコルでDiameter電文を送受するノード装置とのDiameter電文の通信を可能にすることを目的とする。
上記課題を解決するプロトコル代行処理装置は、対向する第1及び第2のノード装置の間で送受されるDiameter電文を中継するプロトコル代行処理装置であって、前記Diameter電文のセッッション識別情報と送信元の第1のノード装置識別情報とを対応付けてトランザクション管理テーブルに保持し、第2のノード装置から送信され、前記Diameter電文と同一セッションのDiameter電文に対して、前記トランザクション管理テーブルを参照し、前記セッッション識別情報に対応付けた前記第1のノード装置宛てに、該Diameter電文の転送を行うトランザクション制御手段と、前記Diameter電文の転送で使用されるトランスミッション制御プロトコル(TCP)とストリーム制御トランスミッションプロトコル(SCTP)との変換を行うトランスポートプロトコル変換手段と、を備えたものである。
開示のプロトコル代行処理装置を介することにより、Diameter/TCPのプロトコルをサポートしているが、Diameter/SCTPのプロトコルをサポートしていない呼セッション制御装置(CSCF)等のノード装置は、Diameter/SCTPのプロトコルでDiameter電文を送受するノード装置とのDiameter電文の通信が可能となり、前述した従来技術の種々の問題を解決することが可能となる。
プロトコル代行処理装置を適用したシステム例を示す図である。 Diameter/SCTPコネクション確立のシーケンスを示す図である。 Diameter/TCPコネクション確立のシーケンスを示す図である。 独自ヘッダの一例を示す図である。 独自ヘッダとDiameter電文の送信元・宛先情報の例を示す図である。 Diameterプロトコルのコマンドの一例を示す図である。 Diameterリクエスト/レスポンスのトランザクション制御のシーケンス例(HSS正常)を示す図である。 Diameterリクエスト/レスポンスのトランザクション制御のシーケンス例(HSS無応答)を示す図である。 PPR電文のトランザクション制御のシーケンス例を示す図である。 PPR電文のトランザクション制御のシーケンス例を示す図である。 PPA電文の応答処理のシーケンス例を示す図である。 IMS(IP Multimedia Subsystem)の構成例を示す図である。
図1に開示のプロトコル代行処理装置を適用したシステム例を示す。このシステム例において、IMS(IP Multimedia Subsystem)における呼セッション制御装置(CSCF)11と加入者位置情報サーバ(SLF)12とホーム加入者情報サーバ(HSS)13との間にプロトコル代行処理装置(Diameter-Proxy)20を配備している。
ここで、呼セッション制御装置(CSCF)11は、Diameter/TCPのプロトコルのみをサポートするノード装置とする。プロトコル代行処理装置(Diameter-Proxy)20は、呼セッション制御装置(CSCF)11のDiamter信号に対して、Diameter/SCTPのプロトコルに変換する、トランスポートプロトコル変換及びトランザクション制御を行う。
プロトコル代行処理装置(Diameter-Proxy)20は以下の手段を備える。なお、以下では、呼セッション制御装置(CSCF)のノード装置をCSCF、加入者位置情報サーバ(SLF)のノード装置をSLF、ホーム加入者情報サーバ(HSS)のノード装置をHSSと略記する場合がある。
(1)Diameter/SCTPコネクション制御
保守機能により管理されるSLF/HSSの局データに基づき、対向するSLF/HSSに対して、ストリーム制御トランスミッションプロトコル(SCTP)のコネクションを、それぞれ2本ずつのマルチホーミングにより確立する。なお、SCTPのコネクションは、プロトコル代行処理装置(Diameter-Proxy)側がSCTPクライアントとなり、SLF/HSSがSCTPサーバとなる。該コネクション確立の契機は、プロトコル代行処理装置(Diameter-Proxy)の各再開処理検出時である。また、SCTPのコネクションの接続時には、該接続完了までのタイマ監視を行い、該タイマ監視時間までに接続が完了しない場合はリトライ処理を行う。
(2)Diameter/TCPコネクション制御
プロトコル代行処理装置(Diameter-Proxy)に、呼セッション制御装置(CSCF)と接続されるDiameter/TCPコネクション用のTCPソケットを用意する。プロトコル代行処理装置(Diameter-Proxy)は、TCPコネクションのサーバとして動作し、プロトコル代行処理装置(Diameter-Proxy)からコネクション確立は行わない。
但し、同一の呼セッション制御装置(CSCF)から複数のTCPコネクションが接続された場合、最後に接続されたTCPコネクションを有効な接続として扱い、それまでに確立していた同一の呼セッション制御装置(CSCF)とのTCPコネクションを切断する。
(3)Diameterトランスポートプロトコル変換
対向する呼セッション制御装置(CSCF)とSLF及びHSSとの間のDiameter電文の送受において、トランスポートプロトコル変換を行う。呼セッション制御装置(CSCF)側は、Diameter/TCP、SLF及びHSS側は、Diameter/SCTPとする。
(4)トランザクション制御
呼セッション制御装置(CSCF)から受信したDiameterリクエスト(UAR/SAR/LIR)の電文に対して、Diameterのトランザクション情報(セッション識別情報)と送信元呼セッション制御装置(CSCF)の識別情報とを、内部のトランザクション管理テーブルに保持する。そして、DiameterのトランスポートプロトコルをTCPからSCTPに変換した後に、SLF又はHSSにそれらの電文を転送する。
また、SLF又はHSSから受信したDiameterレスポンス(UAA/SAA/LIA)の電文に付加されているDiameterのトランザクション情報(セッション識別情報)を検索キーとして前述のトランザクション管理テーブルを検索する。そして、該トランザクション情報(セッション識別情報)に対応付けられた呼セッション制御装置(CSCF)を求め、該電文の返却先の呼セッション制御装置(CSCF)としてルーティングを行う。
なお、プロトコル代行処理装置(Diameter-Proxy)におけるDiameter電文の分析・再構築処理に掛かる負荷を減らすため、呼セッション制御装置(CSCF)とプロトコル代行処理装置(Diameter-Proxy)との間では、通常のDiameter電文に新たに独自ヘッダを付与して送受する。
該独自ヘッダの情報を基に分析・ルーティング処理を行うことにより、それらの処理を高速に行うことができる。該独自ヘッダには、バージョン情報、メッセージ長、コマンド種別、セッション識別情報(Session−ID)、送信元ホストのIPアドレス、宛先ホストのIPアドレス、応答コードの情報を含むものとすることができる。
(5)PPR制御
HSSから送信されるプッシュ型のDiameter信号であるPPR(Push-Profile-Request)電文を受信した際、対向する呼セッション制御装置(CSCF)全てに対して、該PPR電文を分配(Fork)して送信する。その後、該PPR電文の送信先の各呼セッション制御装置(CSCF)からその応答であるPPA(Push-Profile-Answer)電文を受信すると、該当するプロファイルが含まれるPPA電文を選別し、該PPAの電文をHSSに送信する。このとき、HSSとプロトコル代行処理装置(Diameter-Proxy)と間のSCTPと、呼セッション制御装置(CSCF)とプロトコル代行処理装置(Diameter-Proxy)間のTCPとの、トランスポートプロトコルの変換を行う。
全ての呼セッション制御装置(CSCF)から該当プロファイルが含まれないPPA電文が受信された場合、HSSに対して「該当プロファイル無し」を示すPPA電文を返送する。また、一部若しくは全ての呼セッション制御装置(CSCF)から、該当プロファイルを含むPPAの電文が受信されることなく、受信待ちタイマが満了した場合は、HSSに対してPPA電文を返送せず無応答として振る舞う。
(6)ホップバイホップ識別情報/エンドツーエンド識別情報の付け替え
SLF/HSSに対して送信するDiameterリクエストについて、プロトコル代行処理装置(Diameter-Proxy)では、Diameter電文のホップバイホップ識別情報(Hop-by-Hop Identifier)ヘッダ又はエンドツーエンド識別情報(End-to-End Identifier)ヘッダの付け替え処理を行う。
(Diameter/SCTPコネクション確立)
Diameter/SCTPコネクション確立のシーケンスを図2に示す。SCTPのコネクションは、クライアント側のプロトコル代行処理装置(Diameter-Proxy)からサーバ側のSLF/HSSに対して開始される。Diameter/SCTPコネクションは、図2に示すように、プロトコル代行処理装置(Diameter-Proxy)とSLF/HSSとの間で、まず、SCTPコネクションが確立され、その後、Diameterのセッションが確立される。
(Diameter/TCPコネクション確立)
Diameter/TCPコネクション確立のシーケンスを図3に示す。TCPのコネクションでは、呼セッション制御装置(CSCF)がTCPクライアント、プロトコル代行処理装置(Diameter-Proxy)がTCPサーバとなる。Diameter/TCPコネクションは、図3に示すように、呼セッション制御装置(CSCF)とプロトコル代行処理装置(Diameter-Proxy)との間で、まず、TCPコネクションが確立され、その後、Diameterのセッションが確立される。
(トランスポートプロトコル変換)
対向する呼セッション制御装置(CSCF)とSLF/HSSとの間において送受されるDiameter信号のトランスポート変換を行う。呼セッション制御装置(CSCF)側は、Diameter/TCP、SLF/HSS側は、Diameter/SCTPのプロトコルである。
なお、呼セッション制御装置(CSCF)側からのDiameterリクエスト(UAR/SAR/LIR)の電文対して、該電文の分析・再構築の処理をスキップし、通常のDiameter電文とは別に付与された独自ヘッダの情報を用いて分析・ルーティング処理を行う。こうすることにより、処理の高速化を図ることができる。この独自ヘッダは、呼セッション制御装置(CSCF)側のDiameterライブラリにより付与する構成とすることができる。
図4に独自ヘッダの一例を示す。図4(a)は、Diameterメッセージに独自ヘッダを付加してカプセリングしたフレーム構成例を示し、図4(b)は、独自ヘッダの構成例を示し、図4(c)は、独自ヘッダの各構成要素の詳細内容を示している。
独自ヘッダの構成は図4(b)に示すように、Local−ID、Message−Length、Command−flags、Command−Code、Session−ID−length、Session−ID、Origin−Host、Destination−Host、Return−Codeを含む構成とすることができる。
独自ヘッダの各構成要素は図4(c)に示すように、ヘッダの先頭のLocal−IDは、Diameterプロトコルではバージョンを表すが、ここでは、独自ヘッダであることを識別するために例えば255を設定することとする。Message−Lengthには、メッセージ全体の長さを設定する。Diameterメッセージの長さに独自ヘッダの長さを加算した値を設定する。
Command−flagsには、コマンドの種別を表すビット列を設定する。即ち、DiameterメッセージのCommand−flagsと同じ値を設定する。Command−Codeには、IANA(Internet Assigned Number Authority)により定義された処理を表すコードを設定する。即ち、DiameterメッセージのCommand−Codeと同じ値を設定する。
Session−ID−Lengthには、セッション識別情報の長さを設定する。無効の場合は0を設定する。Session−IDにセッション識別情報を設定する。即ち、DiameterメッセージのSession−IDの値と同じ値を設定する。Origin−Hostには、送信元ホストのIPアドレスを設定する。Destination−Hostには、宛先ホストのIPアドレスを設定する。
Return−Codeには、コマンド応答の場合、Result−Code又はExperimental−Result−Codeの値をフラグFと共に設定する。ここでフラグFを0としたときは、Result−Codeの値を設定し、フラグFを1としたときは、Experimental−Result−Codeの値を設定する。無効の場合は、フラグF及びReturn−Code共に0を設定する。図5に独自ヘッダとDiameter電文の送信元・宛先情報の例を示す。また、図6にDiameterプロトコルのコマンドの一例を示す。
(トランザクション制御)
呼セッション制御装置(CSCF)からのDiameterリクエスト(UAR/SAR/LIR)に対して、トランザクション情報(セッション識別情報)と送信元呼セッション制御装置(CSCF)の論理番号とをトランザクション管理テーブルに保持する。Diameterリクエストの送信先のSLF/HSSは、独自ヘッダのDestination−Hostから求める。
HSSからDiameterレスポンス(UAA/SAA/LIA)を受信したときは、Diameterレスポンスのセッション識別情報を検索キーにしてトランザクション管理テーブルを検索し、返送先の呼セッション制御装置(CSCF)の論理番号を求める。そして、TCPコネクションが有効となっている系(ACT系)の呼セッション制御装置(CSCF)に該Diameterレスポンスを送信する。
セッション識別情報と送信元の呼セッション制御装置(CSCF)情報は、呼セッション制御装置(CSCF)からのDiameterリクエストの独自ヘッダから抽出する。呼セッション制御装置(CSCF)の論理番号は、該装置のIPアドレスから局データを検索して求める。なお、独自ヘッダの内容が異常の場合、呼セッション制御装置(CSCF)から受信したDiameterリクエストは破棄する。
プロトコル代行処理装置(Diameter-Proxy)からSLF/HSSにDiameterリクエストを送信する場合、リクエスト送信時に応答待ちタイマを設定し、応答監視を行う。応答待ちタイマが満了した場合は、HSSへの再送及び呼セッション制御装置(CSCF)へのレスポンス返却を行わず、無応答として振る舞う。
また、トランザクション管理テーブル上の該当トランザクション情報(セッション識別情報)とその呼セッション制御装置(CSCF)情報とを、呼セッション制御装置(CSCF)へのDiameterレスポンス送信又は応答待ちタイマ満了を契機に削除する。
図7にDiameterリクエスト/レスポンスのトランザクション制御のシーケンス例(HSS正常)を示す。呼セッション制御装置(CSCF)は、独自ヘッダを付与したDiameterリクエスト電文xxR(Cx/Dx)を、プロトコル代行処理装置(Diameter-Proxy)に、TCPのトランスポートプロトコルを用いて送信する(7−1)。なお、CxはHSSとのインタフェースの電文、DxはSLFとのインタフェースの電文である。
プロトコル代行処理装置(Diameter-Proxy)は、該独自ヘッダのセッション識別情報(Session−ID)と送信元CSCFの情報(IPアドレスから論理番号に変換した情報)とをトランザクション管理テーブルに保持する(7−2)。そして、プロトコル代行処理装置(Diameter-Proxy)は、該Diameterリクエスト電文xxRをSCTPのトランスポートプロトコルに変換してSLF又はHSSに送信する(7−3)。このとき、プロトコル代行処理装置(Diameter-Proxy)は、HSSへのDiameterリクエスト電文の送信時に応答待ちタイマを設定し、応答監視を行う。
SLF又はHSSは、Diameterリクエスト電文xxRを受信すると、その応答であるDiameterレスポンス電文xxAを、プロトコル代行処理装置(Diameter-Proxy)にSCTPのトランスポートプロトコルにより送信する(7−4)。プロトコル代行処理装置(Diameter-Proxy)は、該Diameter電文xxAを解析し、セッション識別情報(Session−ID)を検索キーにしてトランザクション管理テーブルを検索し、送信先の呼セッション制御装置(CSCF)を求める(7−5)。
そして、プロトコル代行処理装置(Diameter-Proxy)は、Diameterレスポンス電文xxAをTCPのトランスポートプロトコルに変換して、呼セッション制御装置(CSCF)に送信する(7−6)。プロトコル代行処理装置(Diameter-Proxy)は、呼セッション制御装置(CSCF)への応答返送を契機に、トランザクション管理テーブル上から当該トランザクションに関するトランザクション情報を削除する(7−7)。これは、トランザクション管理テーブルにトランザクション情報が累積され、トランザクション管理テーブルが多数の無効なトランザクション情報によってオーバーフローするのを防ぐためである。
図8にDiameterリクエスト/レスポンスのトランザクション制御のシーケンス例(HSS無応答)を示す。呼セッション制御装置(CSCF)は、独自ヘッダを付与したDiameterリクエスト電文xxR(Cx/Dx)を、プロトコル代行処理装置(Diameter-Proxy)に、TCPのトランスポートプロトコルを用いて送信する(8−1)。
プロトコル代行処理装置(Diameter-Proxy)は、該独自ヘッダのセッション識別情報(Session−ID)と送信元CSCFの情報(IPアドレスから論理番号に変換した情報)とをトランザクション管理テーブルに保持する(8−2)。そして、プロトコル代行処理装置(Diameter-Proxy)は、該Diameterリクエスト電文xxRを、SCTPのトランスポートプロトコルに変換してSLF又はHSSに送信する(8−3)。このとき、プロトコル代行処理装置(Diameter-Proxy)は、HSSへのDiameterリクエスト電文の送信時に応答待ちタイマを設定し、応答監視を行う。
その後、プロトコル代行処理装置(Diameter-Proxy)は、SLF又はHSSからの応答を待つが、応答待ちタイマが満了したことを以って、SLF又はHSSからの無応答を検出する(8−4)。プロトコル代行処理装置(Diameter-Proxy)は、SLF又はHSSからの無応答検出を契機に、トランザクション管理テーブルから、当該トランザクションに関するトランザクション情報を削除する(8−5)。これは、トランザクション管理テーブルにトランザクション情報が累積され、トランザクション管理テーブルが多数の無効なトランザクション情報によってオーバーフローするのを防ぐためである。
次に、SLF/HSS側から呼セッション制御装置(CSCF)側にリクエスト電文が発せられるプッシュ型Diameter信号のPPR(Push-Profile-Request)電文のトランザクション制御について説明する。
(Fork処理(正常シーケンス))
プロトコル代行処理装置(Diameter-Proxy)は、対向するHSSから、SCTPのトランスポートプロトコルによるPPR(Push-Profile-Request)電文を受信する。この場合、該PPR電文の送信先の呼セッション制御装置(CSCF)が不定であるため、局データとして登録されている全ての呼セッション制御装置(CSCF)に該PPR電文をTCPのトランスポートプロトコルに変換して分配送信(Fork)する。
該PPR電文を各呼セッション制御装置(CSCF)に分配送信(Fork)する際、その応答であるPPA電文の受信待ちタイマを設定し、PPA電文の受信監視を行う。それと共に、該PPR電文のセッション識別情報と送信元のHSSの論理番号とを内部のトランザクション管理テーブル(PPRトランザクション管理テーブル)に登録する。
PPA電文の受信待ちタイマが満了する前に、Diameter独自ヘッダのExperimental−Resultに“DIAMETER_ERROR_USER_UNKNOWN”が設定されていない同一セッション識別情報のPPA電文(即ち、ユーザ登録有りの電文)を受信した場合、そのPPA電文を送信元のHSSに、SCTPのトランスポートプロトコルに変換して送信する。
PPRトランザクション管理テーブル上の該当トランザクションに関するデータは、PPA受信待ちタイマが満了したのを契機に削除する。また、HSSにPPA電文を送信する前に、他の呼セッション制御装置(CSCF)から受信した同一セッション識別情報のPPA電文で、Experimental−Resultに“DIAMETER_ERROR_USER_UNKNOWN(即ち、ユーザ登録無しの電文)を受信した場合は、該PPA電文を破棄する。HSSにPPA電文を送信した後、他の呼セッション制御装置(CSCF)から同一セッション識別情報のPPA電文を受信した場合も、そのPPA電文を破棄する。
図9及び図10にPPR電文のトランザクション制御のシーケンス例を示す。HSSは、DiameterリクエストのPPR電文をプロトコル代行処理装置(Diameter-Proxy)に、SCTPのトランスポートプロトコルにより送信する(9−1)。プロトコル代行処理装置(Diameter-Proxy)は、各呼セッション制御装置(CSCF)#1,#2,#nに、該PPR電文を分配送信(Fork)する。また、セッション識別情報(Session−ID)と送信元のHSSの論理番号を、PPRトランザクション管理テーブルに保持する(9−2)。
プロトコル代行処理装置(Diameter-Proxy)は、PPA電文の応答待ちタイマを設定する。ここで、呼セッション制御装置(CSCF)#1から、Diameter独自ヘッダのExperimental−Resultに“DIAMETER_ERROR_USER_UNKNOWN”が設定されたPPA電文(即ち、ユーザ登録(REG)無しの電文)が受信されたとする(9−3)。
プロトコル代行処理装置(Diameter-Proxy)は、受信したPPA電文が、分配送信(Fork)したPPR電文のセッション識別情報(Session−ID)と同一のPPA電文であるかを判断した後、USER_UNKNOWN(ユーザ登録(REG)無しのPPA電文であると認識し、該PPA電文を破棄する(9−4)。分配送信(Fork)したPPR電文のセッション識別情報(Session−ID)と一致するPPA電文が無い場合もPPA電文を破棄する。
その後、図10に示すように、呼セッション制御装置(CSCF)#2から、Diameter独自ヘッダのResult−Codeに“DIAMETER_SUCCESS”が設定されたPPA電文が受信されたとする(10−1)。該PPA電文は、Experimental−Resultに“DIAMETER_ERROR_USER_UNKNOWN”が設定されていない、即ち、ユーザ登録(REG)有りを示す電文である。
プロトコル代行処理装置(Diameter-Proxy)は、受信したPPA電文が、分配送信(Fork)したPPR電文のセッション識別情報(Session−ID)と同一のPPA電文あるかを判断した後、“USER_UNKNOWN”が設定されていない(即ち、ユーザ登録(REG)有りの)PPA電文であると認識し、該PPA電文をHSSに転送する(10−2)。
その後、呼セッション制御装置(CSCF)#nから、Diameter独自ヘッダのExperimental−Resultに“DIAMETER_ERROR_USER_UNKNOWN”が設定されたPPA電文(即ち、ユーザ登録(REG)無しの電文)が受信されたとする(10−3)。
プロトコル代行処理装置(Diameter-Proxy)は、受信したPPA電文が、分配送信(Fork)したPPR電文のセッション識別情報(Session−ID)と同一のPPA電文であるかを判断した後、送信済みのセッション識別情報(Session−ID)のPPA電文であるので、該PPA電文を破棄する(10−4)。プロトコル代行処理装置(Diameter-Proxy)は、PPA電文の受信待ちタイマの満了を契機に、PPAトランザクション管理テーブル上の当該トランザクション情報を削除する(10−5)。
(Fork処理(準正常シーケンス))
PPA電文の受信待ちタイマが満了する迄に、何れの呼セッション制御装置(CSCF)からもユーザ登録(REG)有りを示すPPA電文が返送されない場合、プロトコル代行処理装置(Diameter-Proxy)は、以下の処理を行う。
(a)PPA電文の受信待ちタイマ満了前に、全ての呼セッション制御装置(CSCF)からPPA電文を受信した場合
(a1)受信した全てのPPA電文が、ユーザ登録(REG)無し(Experimental−Result−Code:DIAMETER_ERROR_USER_UNKNOWN)と設定されている場合は、ユーザ登録(REG)無しの旨を示すPPA電文をHSSに送信する。
(a2)受信したPPA電文のうちの一部に、ユーザ登録(REG)無し以外の情報が設定されたPPA電文(Diameter構文エラー等のPPA電文)が存在する場合は、その中の最初にプロトコル代行処理装置(Diameter-Proxy)で受信されたPPA電文をHSSに送信する。
上記(a2)の場合は、ユーザ登録(REG)有りの情報を設定したPPA電文を返却する呼セッション制御装置(CSCF)が、ユーザ登録(REG)無し以外のエラー情報を含むPPA電文を返却したものと判定する。ユーザ登録(REG)無し以外のエラー情報を含む複数のPPA電文が返却された場合、何れのエラー情報のPPA電文を優先させて転送するかは、プロトコル代行処理装置(Diameter-Proxy)では決定することができない。そのため、プロトコル代行処理装置(Diameter-Proxy)は、最初に受信したユーザ登録(REG)無し以外のエラー情報を含むPPA電文を、HSSに送信する。
(b)受信待ちタイマ満了までに全ての呼セッション制御装置(CSCF)からPPA電文を受信していない場合
受信待ちタイマ満了時に、全ての呼セッション制御装置(CSCF)からPPA電文が受信されていない、又は一部の呼セッション制御装置(CSCF)からPPA電文が受信されたが、ユーザ登録(REG)有りのPPA電文が受信されていない場合、受信された一部のPPA電文の内容に関わらず、HSSに対しては無応答とする。何故なら、ユーザ登録(REG)有りのPPA電文を返却するはずの呼セッション制御装置(CSCF)が、無応答である可能性があるためである。
図11に、プロトコル代行処理装置(Diameter-Proxy)におけるPPA電文の応答処理のシーケンス例を示す。プロトコル代行処理装置(Diameter-Proxy)は、PPA電文を受信すると(11−1)、PPA電文の受信待ちタイマが満了しているか否かを判定する(11−2)。該受信待ちタイマが満了していない場合、受信したPPA電文がユーザ登録(REG)有りのPPA電文であるか否かを判定する(11−3)。
ユーザ登録(REG)有りのPPA電文である場合、該ユーザ登録(REG)有りのPPA電文を、HSSに転送する(11−5)。このフローは、前述の正常シーケンスの場合のFork処理である。PPA電文がユーザ登録(REG)有りのPPA電文でない場合、該PPA電文が同一のセッション識別情報の最後のPPA電文であるか否かを判定する(11−6)。
最後のPPA電文である場合、全ての呼セッション制御装置(CSCF)からPPA電文が受信されたこととなり、ユーザ登録(REG)無し以外のエラー情報を含む同一セッション識別情報のPPA電文を受信していたか否かを判定する(11−7)。ユーザ登録(REG)無し以外のエラー情報を含む同一セッション識別情報のPPA電文を受信していた場合、最初に受信した、ユーザ登録(REG)無し以外のエラー情報を含むPPA電文を、HSSに転送する(11−8)。この処理フローは、前述の準正常シーケンスのFork処理の(a2)の処理に相当する。
ユーザ登録(REG)無しの情報を含むPPA電文を受信している場合、該ユーザ登録(REG)無しの情報を含むPPA電文を、HSSに転送する(11−9)。この処理フローは、前述の準正常シーケンスのFork処理の(a1)の処理に相当する。
以上の処理を、PPA電文の受信待ちタイマが満了するまで実行し、受信待ちタイマ満了したとき、受信された一部のPPA電文の内容に関わらず、HSSに対しては無応答とする(11−10)。この処理フローは、前述の準正常シーケンスのFork処理の(b)の処理に相当する。
(ホップバイホップ識別情報/エンドツーエンド識別情報の付け替え)
SLF/HSSへ送信するDiameterリクエストについて、Diameter電文のホップバイホップ識別情報(Hop-by-Hop Identifier)ヘッダ又はエンドツーエンド識別情報(End-to-End Identifier)ヘッダを、プロトコル代行処理装置(Diameter-Proxy)で以下のように付け替える。
(ホップバイホップ識別情報)
プロトコル代行処理装置(Diameter-Proxy)は、SLF/HSSに送信する全てのDiameterリクエストに関して、SLF/HSS毎に再開時に算出した32ビットの乱数を初期値とし、Diameterリクエストを送信する毎に1ずつインクリメントした値をホップバイホップ識別情報(Hop-by-Hop Identifier)に設定する。
SLF/HSSを増設した場合、該SLF/HSSの増設を契機に初期値を乱数で設定するものとする。なお、このホップバイホップ識別情報(Hop-by-Hop Identifier)の値は、SLF/HSS毎に管理する。
また、呼セッション制御装置(CSCF)から受信し、SLF/HSSに送信するDiameterリクエスト(UAR/SAR/LIA)については、上記ホップバイホップ識別情報(Hop-by-Hop Identifier)を付け替える前に、呼セッション制御装置(CSCF)が設定したホップバイホップ識別情報(Hop-by-Hop Identifier)の値をメモリに記憶しておく。そして、該リクエストに対応するレスポンスを返却する際に、メモリに記憶しておいたホップバイホップ識別情報(Hop-by-Hop Identifier)の値をレスポンス上に設定する。ホップバイホップ識別情報(Hop-by-Hop Identifier)の値が0xFFFFFFFFの値に達した場合、次のインクリメントでは0x0の値を設定する。
(エンドツーエンド識別情報)
SLF/HSSに送信する全てのDiameterリクエストに関して、現在時刻の例えば下位12ビットを、エンドツーエンド識別情報(End-to-End Identifier)ヘッダの例えば上位12ビットにセットし、ランダムな値(乱数により生成)を例えば下位20ビットにセットする。
また、呼セッション制御装置(CSCF)から受信し、SLF/HSSに送信するDiameterリクエスト(UAR/SAR/LIA)については、上記のエンドツーエンド識別情報(End-to-End Identifier)を付け替える前に、呼セッション制御装置(CSCF)が設定したエンドツーエンド識別情報(End-to-End Identifier)の値をメモリに記憶しておく。そして、該のリクエストに対応するレスポンスを返却する際に、メモリに記憶しておいたエンドツーエンド識別情報(End-to-End Identifier)の値をレスポンス上に設定する。
このようにホップバイホップ識別情報(Hop-by-Hop Identifier)又はエンドツーエンド識別情報(End-to-End Identifier)の付け替えを行うことにより、同一のセッション識別情報(Session-ID)が付与されてセッション識別情報の衝突が発生した場合でも、これらの情報を用いてセッションを厳密に区別することが可能となる。
以上、Diameter/SCTPのプロトコルをサポートせず、Diameter/TCPのプロトコルをサポートするノード装置として、呼セッション制御装置(CSCF)を例に挙げて説明したが、本発明はこれに限定されず、アプリケーションサーバ(AS)等に対しても同様に適用することが可能である。
11 呼セッション制御装置(CSCF)
12 加入者位置情報サーバ(SLF)
13 ホーム加入者情報サーバ(HSS)
14 アプリケーションサーバ(AS)
15 他のIP網のノード

Claims (6)

  1. 対向する第1及び第2のノード装置の間で送受されるDiameter電文を中継するプロトコル代行処理装置であって、
    前記Diameter電文のセッッション識別情報と送信元の第1のノード装置識別情報とを対応付けてトランザクション管理テーブルに保持し、第2のノード装置から送信され、前記Diameter電文と同一セッションのDiameter電文に対して、前記トランザクション管理テーブルを参照し、前記セッッション識別情報に対応付けた前記第1のノード装置宛てに、該Diameter電文の転送を行うトランザクション制御手段と、
    前記Diameter電文の転送で使用されるトランスミッション制御プロトコル(TCP)とストリーム制御トランスミッションプロトコル(SCTP)との変換を行うトランスポートプロトコル変換手段と、
    を備えたことを特徴とするプロトコル代行処理装置。
  2. 呼セッション制御装置(CSCF)と該呼セッション制御装置(CSCF)と対向する対向ノード装置との間で送受されるDiameter電文を中継するプロトコル代行処理装置であって、
    前記Diameter電文のセッッション識別情報と送信元の前記呼セッション制御装置(CSCF)識別情報とを対応付けてトランザクション管理テーブルに保持し、前記対向ノード装置から送信され、前記Diameter電文と同一セッションのDiameter電文に対して、前記トランザクション管理テーブルを参照し、前記セッッション識別情報に対応付けた前記呼セッション制御装置(CSCF)宛てに、該Diameter電文の転送を行うトランザクション制御手段と、
    前記Diameter電文の転送で使用されるトランスミッション制御プロトコル(TCP)とストリーム制御トランスミッションプロトコル(SCTP)との変換を行うトランスポートプロトコル変換手段と、
    を備えたことを特徴とするプロトコル代行処理装置。
  3. 前記Diameter電文のホップバイホップ識別情報又はエンドツーエンド識別情報を、前記第2のノード装置毎にかつセッション毎に順次異なる値に付け替えて転送し、前記セッッション識別情報と共に、該ホップバイホップ識別情報又はエンドツーエンド識別情報を用いて、当該Diameter電文のセッションを識別する手段を備えたことを特徴とする請求項1又は2に記載のプロトコル代行処理装置。
  4. セッション識別情報、送信元ホストのIPアドレス、宛先ホストのIPアドレス及び応答コードの情報を含む独自ヘッダが付与されたDiameter電文を受信し、該独自ヘッダを参照して、該Diameter電文の解析を行う手段を備えたことを特徴とする請求項1乃至3の何れかに記載のプロトコル代行処理装置。
  5. DiameterのPPR電文をホーム加入者情報サーバから受信した際、前記ストリーム制御トランスミッションプロトコル(SCTP)をサポートしていない呼セッション制御装置(CSCF)の全てに対して、該PPR電文を分配して送信し、該当プロファイル情報が含まれたPPA電文を該PPR電文の送信元のホーム加入者情報サーバに返却する手段を備えたことを特徴とした請求項2に記載のプロトコル代行処理装置。
  6. 対向する第1及び第2のノード装置の間で送受されるDiameter電文を中継するプロトコル代行処理方法であって、
    前記Diameter電文のセッッション識別情報と送信元の第1のノード装置識別情報とを対応付けてトランザクション管理テーブルに保持し、第2のノード装置から送信され、前記Diameter電文と同一セッションのDiameter電文に対して、前記トランザクション管理テーブルを参照し、前記セッッション識別情報に対応付けた前記第1のノード装置宛てに、該Diameter電文の転送を行うステップと、
    前記Diameter電文の転送で使用されるトランスミッション制御プロトコル(TCP)とストリーム制御トランスミッションプロトコル(SCTP)との変換を行うステップと、
    を含むことを特徴とするプロトコル代行処理方法。
JP2010052586A 2010-03-10 2010-03-10 プロトコル代行処理装置及び方法 Active JP5445237B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010052586A JP5445237B2 (ja) 2010-03-10 2010-03-10 プロトコル代行処理装置及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010052586A JP5445237B2 (ja) 2010-03-10 2010-03-10 プロトコル代行処理装置及び方法

Publications (2)

Publication Number Publication Date
JP2011188326A JP2011188326A (ja) 2011-09-22
JP5445237B2 true JP5445237B2 (ja) 2014-03-19

Family

ID=44794052

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010052586A Active JP5445237B2 (ja) 2010-03-10 2010-03-10 プロトコル代行処理装置及び方法

Country Status (1)

Country Link
JP (1) JP5445237B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013188411A2 (en) * 2012-06-11 2013-12-19 Tekelec, Inc. Methods, systems, and computer readable media for routing diameter messages at a diameter signaling router

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6768726B2 (en) * 2002-08-06 2004-07-27 Motorola, Inc. Method and apparatus for effecting a seamless handoff between IP connections
EP2223500B1 (en) * 2007-12-19 2012-12-12 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for use in a communications network
US9021014B2 (en) * 2009-03-25 2015-04-28 Tekelec, Inc. Methods, systems, and computer readable media for providing home subscriber server (HSS) proxy

Also Published As

Publication number Publication date
JP2011188326A (ja) 2011-09-22

Similar Documents

Publication Publication Date Title
US8036182B2 (en) Communication system and communication control equipment
US7286520B2 (en) Mobile terminal equipment and packet communication method between terminals
JP5364671B2 (ja) ネットワーク認証における端末接続状態管理
US7733859B2 (en) Apparatus and method for packet forwarding in layer 2 network
US20070053334A1 (en) Packet forwarding apparatus for connecting mobile terminal to ISP network
US20070104146A1 (en) Apparatus and methods for home agent resiliency for mobile IPv4
CN109644186A (zh) 用于在两个终端之间经由多路径进行udp通信的方法
CN104717259B (zh) 分布式中转服务器网络辅助的多路径数据传输***与方法
CN102118398B (zh) 访问控制方法、装置及***
JP4966376B2 (ja) Sipシグナリング・プロキシ内でのループの検出
EP3203692B1 (en) Method, apparatus and system for acquiring response message, and method, apparatus and system for routing response message
CN103152495B (zh) 一种媒体转移的方法、装置及***
JP5445237B2 (ja) プロトコル代行処理装置及び方法
CN103024100B (zh) 一种建立偶联的方法和域名***服务器
JP4591263B2 (ja) 通信制御装置、及び、通信システム
JP4591338B2 (ja) 通信システム
WO2012089032A1 (zh) 一种采用多种接入方式中的数据传输方法和接入设备
CN102487495B (zh) Hss异常时实现呼叫的方法及cscf
WO2013056999A1 (en) Method and system for enabling nat traversal for multi-homing protocols
JP4823053B2 (ja) 異種通信インタフェース間の切替方法、移動端末および管理装置
JP5840575B2 (ja) マルチホーム通信方法およびシステム
WO2000064120A1 (en) Mobile ip supporting quality of service for foreign network with foreign agent and plurality of mobile nodes
CN102056287B (zh) 一种基于网络的身份标识与位置分离的实现方法及***
JP7158826B2 (ja) 通信制御装置、通信制御システム及び通信制御方法
JP4889617B2 (ja) ゲートウエイ装置および通信制御方法

Legal Events

Date Code Title Description
RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20110915

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131030

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131209

R150 Certificate of patent or registration of utility model

Ref document number: 5445237

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150