(57)【特許請求の範囲】
【請求項１】
PUCIライト機能を支持するIMSノードによって、着呼を処理するためのPUCIシステムであって、
新規セッションを処理する際に、PUCIライト情報を表す前記IMSネットワークのデータベースにクエリすることと、
前記PUCIライト情報が、前記セッションが不審であることを示すと即座に、前記セッションをブロックするか、または単に前記セッションにマーク付けして、後続ノードにおいてさらにPUCI処理することと
を含み、
前記PUCIライト情報は、SIPヘッダから関連情報を得る、前のIMSノードによって解釈される前記元セッションセットアップメッセージのSIP BYE/ERRORメッセージでの拒否の理由を、前記PUCIライト機能を有する前記IMSノードに知らせる標準化されたコードとして働き、前記関連情報は、P-PUCI-Infoヘッダとして示される新規SIPヘッダにおいて提供される、
PUCIシステム。
【請求項２】
前記PUCIライト情報は、前記セッションをブロックする理由に応じて、発信元/送信先SIP URIおよび発信元/送信先IPアドレスのうちの少なくとも1つ、ならびに発信元PLMN/Operatorネットワークに関する情報、SPD情報、元セッションの確立/拒否時間、後続セッションの確立/拒否時間、および標準化されたPUCIテスト結果/コードを含む、請求項１に記載のPUCIシステム。
【請求項３】
前記PUCIライト情報は、前記データベースと、PUCIアプリケーションサーバとの間の帯域外シグナリングとして働く、請求項１または請求項２に記載のPUCIシステム。
【請求項４】
前記PUCIライト機能は、グローバルオペレータポリシデータベースか、またはローカルデータベースかのいずれかに、関連情報を格納するために、PUCIアプリケーションサーバからフィードバックを解釈し、したがって、PUCIをネゲートするIMSノードが、前記ブロックされたセッションに関連している未承諾呼を拒否することを可能にする、請求項１から３のいずれか一項に記載のPUCIシステム。
【請求項５】
前記PUCIライト機能は、コアIMS機能またはSIPベースのシステムの一部として働き、したがって、前記PUCIライト機能をネットワークのエッジに提供する、請求項１から４のいずれか一項に記載のPUCIシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、PUCIシステムに関するものである。
【０００２】
本出願は、特願2008-260090に基づいて優先権を主張するものであり、その内容を参照によって本明細書に組み込む。
【背景技術】
【０００３】
インターネットプロトコルマルチメディアサブシステム(IMS: Internet protocol multimedia subsystems)は、ユーザ(または加入者)に様々な通信サービスを提供するために、公衆電話交換回線網(PSTN: public switched telephone networks)や移動体通信網などのネットワークを統合し、次世代ネットワーク(NGN: the next generation network)における中枢的な役割として機能するIMSは、第3世代パートナーシッププロジェクト(3GPP: the third generation partnership project)によって標準化されている。
【０００４】
電子メールサービスでは、望みもしないメールが一方的に送信者から受信者に送られるというSpamメールや未承諾(またはジャンク)メールなどの厄介な社会問題が起きている。未承諾通信は、通信コストの大幅な低下や、不特定の人またはサイトに大量の電子メールを送信することができる(一般のユーザが購入可能なパソコンなどの)ネットワークアクセス端末の進歩など、インターネットの普及から派生する様々な要因により生じる。
【０００５】
(電子メールサービスでは、すでに生じている)上述の問題は、IMSでもその普及により生じるように思われる。3GPP仕様では、IP電話によるSpam(SPIT: Spam over the IP telephony)からユーザを防御するために、IMSに対する未承諾通信の防御(the protection against unsolicited communication for IMS:簡単に「PUCI」と呼ぶ)が開始されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＩＭＳセッションを相互に通信するオペレータ間でセッションを確立する場合、すべてのオペレータに、着呼が未承諾呼であるか否かをテストするためのPUCI機能に関してそれぞれ改善されたネットワークが必ずしも含まれているとは限らない。PUCI機能が、終端ネットワークにおいてのみ利用可能である場合、他の中間ネットワークは、着呼を終端ネットワークにルーティングする必要がある。このことにより、未承諾呼、またはいたずら呼は、発信ネットワークによって検出されるのではなく、直接、拒否されるので、ネットワーク化の高い作業負荷がもたらされる可能性がある。現在のところ、全PUCI機能を実装せずには未承諾呼を検出することは不可能である。発明者らは、ネットワーク化のわずかな変更による基本的なPUCI機能により、いかにしてネットワークに便益をもたらすか、したがって、PUCIシステムの高性能をいかにして実施するかに関するソリューションの提供を追求している。
【課題を解決するための手段】
【０００７】
本発明は、以下の主な特徴および効果によって、上述の問題解決を追求する。
(1)PUCIシステムは、グローバルオペレータポリシ(OP: operator policy)データベースまたはローカルデータベースに基づくフルPUCI機能セットを実装せずに、基本的または「PUCIライト」機能をIMSノードに統合することによって、ピアリングネットワークがPUCI機能を行うことを可能にし、不審なセッション情報は、いまだ維持されている。
(2)(通常のIMSノードに割り当てられる)PUCIライト機能は、新規セッションを処理すると、PUCIライト情報データベースにクエリし、そのデータベースクエリが不審なセッションを示す場合、PUCIライト機能は即座に、そのセッションをブロックするか、または単にその不審なセッションにマーク付けして、後続ノードにおいてさらにPUCI処理する。
(3)PUCIライト機能は、PUCIアプリケーション/テストに関する関連PUCI情報(またはフィードバック)を、セッションの確立に関わる前のIMSノード(発信ネットワークを含む)に返送する機能がサポートされている。
(4)(標準的なIMSノードに割り当てられる)PUCIライト機能は、(逐次、実行される)PUCIアプリケーション/テストから得られたフィードバックを解釈し、関連PUCI情報をグローバルオペレータポリシ(OP)データベースか、またはローカルデータベースかのいずれか(例えば、コアネットワークのエッジノード)に格納する。グローバル/またはローカルデータベースに格納された関連PUCI情報は、PUCIをネゲートするIMSノードが、後の段階で、未承諾呼(またはPUCIアプリケーションサーバによって、前に拒否された呼)を拒否することを可能にする。
(5)PUCIライト機能は、(プロキシ呼セッション制御機能(P-CSCF: proxy call session control function)と、インテロゲーティング呼セッション制御機能(I-CSCF: interrogating call session control function)と、サービング呼セッション制御機能(S-CSCF: serving call session control function)と、相互接続ボーダ制御機能(IBCF: interconnect border control function)、または例えば、SIPプロキシ/サーバ、SBCなどのセッション開始プロトコルベース(SIP-based: session initiation protocol based)のシステムを含む)コアIMS機能の一部を構成し、したがって、それぞれのネットワークのエッジに、PUCIライト機能をもたらす。
(6)それぞれのネットワークのエッジにおけるPUCIライト機能が、データベースのクエリしか依存しないという理由から、全体的性能を向上させることが可能である。
(7)PUCIライト機能は、情報構成(例えば、O&Mによる発信元/ドメインPLMNの信頼度)を考慮に入れる。
(8)PUCIライト機能は、信頼されたネットワークから得られたフィードバックまたは関連PUCI情報のみを考慮する。
【図面の簡単な説明】
【０００８】
【図１】呼を処理する際のステップS1およびS2を説明するために使用する本発明の好ましい実施形態による種々のネットワークを介して、発信するユーザ装置と、送られることになっているユーザ装置との間で呼を送るためのPUCIシステムの構成を示すブロック図である。
【図２】呼を処理する際のステップS3およびS4を説明するために使用するPUCIシステムのブロック図である。
【図３】呼を処理する際のステップS5およびS6を説明するために使用するPUCIシステムのブロック図である。
【図４】呼を処理する際のステップS7を説明するために使用するPUCIシステムのブロック図である。
【発明を実施するための形態】
【０００９】
全PUCI機能は、IMSの一部として直接、実装される限定された機能に抑えられる。本発明は、相互接続されたネットワークの間で、特定の呼に関連しているPUCI情報をいかにして交換するか、したがって、さらなる未承諾通信をいかにして直接、ブロックするかに関する方法を追求する。
【００１０】
本発明は、IMSへのユーザ装置(UE: user equipment)の第1の接触点にグローバルオペレータポリシ(OP)データベースのうちの1つを、ならびにIMSピアリングの場合には、プロキシ呼セッション制御機能(P-CSCF)または相互接続ボーダ制御機能(IBCF)および/もしくはインテロゲーティング呼セッション制御機能(I-CSCF)を実装するように設計されている。PUCIライト機能は、コアIMS機能の一部(すなわち、P-CSCF、I-CSCF、S-CSCFおよびIBCFの不可欠な部分)として実装されるだけでなく、任意の他のSIPベースのシステム(例えば、SIPプロキシ/サーバ、SBC)としても実装され、したがって、ネットワークのエッジにおけるPUCIライト機能を達成する。
【００１１】
上述のノードは、着呼セットアップ要求(SIP INVITE)に関連するデータベースルックアップなど、付加的なタスクを行うように改善される。データベースは、第1ホップIMSノード(例えば、P-CSCF、もしくはIBCF/I-CSCF)か、またはPUCIアプリケーションサーバかのいずれかによって直接、クエリされる。
【００１２】
さらなる最適化は、第1ホップIMSノードに直接、PUCIライト関連情報を格納することであり、したがって、システム動作を最適化する。加えて、OPデータベースに基づく事前確認によって新規指示がなされ、事前確認情報は、対応するノードに配信される。ネットワークの第1の接点において第1の確認を行うことは有益であり、したがって、ネットワークに高いオーバーヘッドを生じさせる前に、迅速に未承諾呼を拒否することを可能にする。これはまた、全体的ネットワーク性能を向上させるオペレータに対しても有益である。最良の性能をもたらすネットワークのエッジノード(例えば、P-CSCF、IBCF/I-CSCF)のデータベースにPUCI情報を格納する必要があるが、S-CSCFおよび任意の他のノードもまた、PUCI情報を格納することが可能である。OPデータベースは、ブラックリスト/ホワイトリストのデータベース、および信頼できる/信頼できないネットワークデータベースをエッジノードに含み、それらデータベースは、現在のところ生じているある種の不整合を表すSIPヘッダでの指示であるPUCI情報を使用することによって更新される。
【００１３】
セッション関連のPUCI情報は、以下のパラメータを含む。
(a)セッションをブロックする理由によって決まる発信元および/または送信先SIP URIであって、タプルの発信元/送信先SIP URIが、個人ブラックリストにおいては必須であり、発信元SIP URIのみが、グローバルブラックリストにおいては必須である。
(b)セッションをブロックする理由によって決まる発信元/送信先IPアドレスであって、タプルの発信元/送信先SIP URIが、個人ブラックリストには必須であり、発信元SIP URIのみが、グローバルブラックリストには必須である。
(c)発信元PLMN/Operatorネットワーク(ただし、PLNMは、「Public Land Mobile Network:公衆陸上移動体ネットワーク」を表す)。
(d)SDP情報(ただし、SDPは、「Service Delivery Platform:サービス配信プラットフォーム」を表す)。
(e)元セッションの確立/拒否時間。
(f)後続セッションの確立/拒否時間。
(g)標準化されたPUCIテスティング結果/コード。
【００１４】
PUCI情報に関して、以下のアイディアを理解する。
(1)前のIMSノードによって解釈される元セッションセットアップ(INVITE)メッセージのSIP BYE/ERRORメッセージでのフラグのみ。これらのノードは、SIPヘッダから関連PUCI情報(例えば、発信元、送信先、IPアドレス、時間など)を取得する。
(2)前のIMSノードによって解釈された元セッションセットアップ(INVITE)メッセージのSIP BYE/ERRORメッセージでのPUCI拒否の理由をそれぞれのPUCIライトノードに知らせる標準化されたコード(ただし、「01」は、個人ブラックリストを示し、「02」は、グローバルブラックリストを示し、「03」は、個人/グローバルブラックリストを示し、「04」は、他のパラメータを示す)。これらのノードは、SIPヘッダから関連PUCI情報を取得し、関連PUCI情報は後に、新規SIPヘッダ(P-PUCI-Infoヘッダと呼ぶ)の形態で提供される。
(3)PUCIアプリケーション/テストと、PUCIライトデータベースとの間のPUCI情報の「帯域外」シグナリングは、オペレータネットワーク全体にわたって、またはそのネットワークの中に供給される。
(4)PUCIライト機能は、関連PUCI情報をOPデータベースか、またはローカルデータベースかのいずれかに(すなわち、コアネットワークのエッジノードに直接)、あるいはグローバル/ローカルデータベースに格納する。これは、PUCIをネゲートするIMSノードが、後の段階で、関連する未承諾呼(または実在のPUCIアプリケーションサーバによって、前に拒否された呼)を拒否することを可能にする。
(5)PUCI情報は、それぞれのオペレータごと、1つのグローバルデータベースに格納される。
(6)PUCI情報は、それぞれのネットワークノードによって維持されるそれぞれのローカルネットワークに格納される。ローカルネットワークは、互いに同期される。
(7)PUCI情報は、未承諾呼が識別されると、更新を受け取るために、一緒に相互接続される種々のオペレータによって維持される複数のデータベースに格納される。
(8)PUCI情報は、種々のオペレータによって共有されるか、またはGSMAのようなオペレータ構成によってホスティングされる1つの集中型データベースに格納される。
【００１５】
本発明は、様々なネットワーク全体にわたる着呼の処理による図1から図4を参照してさらに詳細に説明する。すなわち、本発明は、発信するユーザ装置が、呼をホームIMSネットワーク(すなわち、「Home IMS3」)300内の加入者に向かって配置するために、訪問先IMSネットワーク(すなわち、「Visited IMS1」)100においてローミングしているシナリオを示す。Visited IMS1は、PUCI機能を持っていないが、ホームIMSネットワーク(すなわち、「Home IMS2」)200は、PUCIライト機能により改善され、したがって、他のオペレータに向かう発呼に関連しているPUCI情報を受け取り、それのデータベースにPUCI情報を格納することが可能である。したがって、(それぞれPUCI情報を格納する)種々のピアリングネットワークのデータベースを相互接続することが可能である。あるいは、ピアリングネットワークは、GSMAのようなオペレータ構成によってホスティングされた同一のデータベースを共有する。制限されたPUCI機能を備えているネットワークは、それらがローミングしているとき、またはそれら自体によって終了すべき呼を配置しているとき、不審な加入者に関するPUCI情報を利用することが可能である。Home IMS3は、テスト結果に基づくPUCI情報により、不審な呼にマーク付けするフルPUCI機能を支持し、それは、それらのデータベースを更新するために、後に、他のオペレータによって再利用可能である。
【００１６】
図1から図4は、最小限のPUCI機能により、Home IMS2 200における未承諾呼をいかにして検出すべきかの原理の説明に使用するブロック図であり、両方のオペレータは、互いに同期しないそれら自体のデータベースを使用する。本明細書においては、発信するユーザ端末(UE A)10が、Visited IMS1 100およびHome IMS2 200を介して、呼をHome IMS3 300内の送られることになっているユーザ端末(UE B)20に向かって配置する。PUCI機能をネゲートするVisited IMS1は、P-CSCF1 110およびIBCF/I-CSCF1 120を含み、PUCIライト機能を支持するHome IMS2は、データベース(DB: database)240と連動するIBCF/I-CSCF2 210、S-CSCF2 220、およびIBCF/I-CSCF2 230を含み、フルPUCI機能を支持するHome IMS3 300は、データベース(DB)340と連動するIBCF/I-CSCF3 310、S-CSCF3 320、アプリケーションサーバ(AS3)330、ならびにユーザ装置(UE B) 20に接続されているP-CSCF3 350を含む。
【００１７】
(ステップS1)
図1においては、ユーザ装置10は、SIP INVITEをユーザ装置20に向かって送信する。PUCIテスティングをネゲートするVisited IMS1は直接、着呼をユーザ装置10のホームIMSに送る。Home IMS2 200は、データベース240内にユーザ装置10に関するいずれのエントリをも含んでいないので、着呼を終端ネットワークにルーティングする。
【００１８】
(ステップS2)
着呼は、ユーザ装置20を含むHome IMS3 300のエッジノードに到着する。本明細書においては、IBCF/I-CSCF3 310は、PUCI処理を実行するために直接、PUCIアプリケーションサーバ(AS3)330と相互作用し、着呼は、例えば、未承諾呼として識別される。
【００１９】
(ステップS3)
図2においては、IBCF/I-CSCF3 310は、PUCIテスティングおよび結果を表すP-PUCI-Infoヘッダの使用によって、REJECTメッセージ内に(PUCIテスティングに関する)PUCI情報を構成するために、着呼を拒否する。加えて、Home IMS3のデータベース340は、PUCIテスティングおよび結果により更新される。
【００２０】
(ステップS4)
REJECTメッセージが、IBCF/I-CSCF3 310およびS-CSCF3 320などのHome IMS3のエッジノードに到着すると、PUCI情報は、始点/終点URI(またはorg/term URI)との相関関係においてデータベース340に格納される。ここで、ユーザ装置10は、Home IMS3 300におけるユーザ装置20に向かって未承諾通信を発信する発信元として認識される。
【００２１】
(ステップS5)
図3においては、ユーザ装置10は、ユーザ装置20に向かって着呼セットアップ要求を再送信し、それは、Home IMS2 200にルーティングされる。
【００２２】
(ステップS6)
Home IMS2 200においては、(理想的には、第1の接触点として働く)IBCF/I-CSCF2 210/230か、またはS-CSCF2 220かのいずれかは、前に受信されたPUCI情報に基づいて、未承諾呼として着呼を識別する。
【００２３】
(ステップS7)
図4においては、IBCF/I-CSCF2 210/230か、またはS-CSCF2 220かのいずれかは、ユーザ装置10がユーザ装置20に対する未承諾発呼側としてマーク付けされる場合、着呼を拒否する。理想的には、IBCF/I-CSCF2 210/230は、終端IMS、すなわち、Home IMS3 300を呼び出すことなく、着呼を拒否する第1のエントリ点として働く。
【００２４】
最後に、本発明は、本実施形態に必ずしも限定されるわけでなく、それは、添付の特許請求の範囲が規定する本発明の範囲の中でさらに修正可能である。
【符号の説明】
【００２５】
10  ユーザ装置(UE A)
20  ユーザ装置(UE B)
100  Visited(訪問先)IMS1
110  P-CSCF1
120  IBCF/I-CSCF1
200  Home(ホーム)IMS2
210  IBCF/I-CSCF2
220  S-CSCF2
230  IBCF/I-CSCF2
240  データベース(DB)
300  Home(ホーム)IMS3
310  IBCF/I-CSCF3
320  S-CSCF3
330  アプリケーションサーバ(AS3)
340  データベース(DB)
350  P-CSCF3
【図１】
0005541287.tif 000002
【図２】
0005541287.tif 000003
【図３】
0005541287.tif 000004
【図４】
0005541287.tif 000005