JP2012044374A - セッション処理システム、ｓｉｐ処理装置、ポリシ管理装置、セッション処理方法、及びプログラム - Google Patents

Abstract

【課題】相互接続網において、接続するセッションの種別に応じて適切な接続先方路を選択可能とする。
【解決手段】回線交換網とパケット交換網からなる第１の網と、パケット交換網からなる第２の網とを複数の相互接続点を介して相互接続した相互接続網における前記第２の網に備えられるセッション処理システムのSIP処理装置において、前記第２の網のパケット交換網から、前記第１の網への発信のためのSIP信号を受信したときに、ポリシデータベースからセッション分割ポリシを取得するデータベース処理手段と、前記セッション分割ポリシと前記SIP信号とを比較し、当該SIP信号が、前記セッション分割ポリシの条件に合致する場合に、当該セッション分割ポリシに従って、前記SIP信号を、接続先となる相互接続点毎に分割し、分割した各SIP信号を、対応する相互接続点に向けて送信するSIP制御手段とを備える。
【選択図】図４

Description

本発明は、ネットワーク間の相互接続に関するものであり、特に、SIP(Session Initiation Protocol)を用いてマルチメディア通信のセッション制御を行うネットワークにおいて、相互接続先ネットワークとの間の合意に基づき、接続するセッションの種別に応じて適切な接続先方路を選択可能とするための技術に関するものである。

現在、携帯電話の技術標準を定めるGSMAでは、音声通話中の相手にビデオを共有するなど、リッチコミュニケーションサービスをユーザに提供するための技術仕様として、RCS(Rich Communication Suite)の技術仕様が定められている（非特許文献1参照）。

RCSでは、携帯電話事業者が従来から音声通話の制御に用いる回線交換網に加え、ビデオ共有やテキストチャットの制御を行うために、SIP(Session Initiation Protocol)及びIMS(IP Multimedia Subsystem)を用いたパケット交換網の2網を組み合わせて用いることとされている。それに対して、固定通信事業者のNGN(Next Generation Network)では、音声通話に関しても、IMSを基盤とするパケット交換網で制御・提供している。

現状のRCS仕様では、IMSと回線交換網をともに有する事業者同士の相互接続のみが考慮されており、IMSのみで音声通話も制御・提供する事業者は考慮されていない。ここで、IMSと回線交換網をともに有する事業者Aと、IMSのみで音声通話も提供する事業者Bが相互接続する場合、大きく以下の2つの方法がある。

一つは、事業者AのIMSと事業者BのIMSを相互接続し、事業者間の接続は全てSIPセッションにより実施する方法（これを接続構成１と呼ぶ）である。図１に、接続構成１のイメージ図を示す。この場合、事業者Aが、通信の種別に応じてパケット交換技術と回線交換技術を使い分けることを可能にするための技術が非特許文献2に定められている。

この非特許文献2に開示された技術によれば、事業者Bは、事業者Aから流入するSIPセッションの中に回線交換網で制御すべき音声通話などが含まれる場合、当該セッションを、SIPセッションと回線交換セッションに分割して自網ユーザに中継したり、反対に、自網ユーザからのSIPセッションと回線交換セッションを、一つのIMSセッションに統合して事業者Aに中継することが可能となる。

もう一つは、IMS間の相互接続に加えて、事業者Bが、事業者Aの回線交換網に対して、SIPと回線交換プロトコルの相互変換装置を介して接続する方法（これを接続構成２と呼ぶ）である。これには、図２（ａ）に示すように、事業者Bが回線交換網を一切持たず、IMS網のみを有している場合のほか、図２（ｂ）に示すように、事業者AがIMS網とは別に有している回線交換網を、前述の相互変換装置の代わりとして単に経由させる場合がある。この相互接続構成は、従来より音声通話の相互接続を実施していた事業者間で、新たにIMS間の相互接続を実施するケースでは、一般的な相互接続構成であると言える。なお、図２（ａ）において、変換装置は、事業者Ａ側の回線交換網の端点に備えられていてもよい。

GSMA IR.74 Video Share Interoperability Specification 3GPP TS 24.279 Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services

非特許文献2に開示された技術では、事業者Bから事業者Aへの接続時、セッションの分割・統合は、事業者A側で担うケースのみが考慮されている。すなわち、事業者Bから事業者Aへの接続セッションは、両事業者のIMS間相互接続点を介して事業者AのIMSで処理され、事業者Aの網内でIMSセッションと回線交換セッションに分割される場合しか考慮されていない。

従って、前述の接続構成１が実現している場合は問題なく機能するものの、接続構成２において、音声通話をIMS間の相互接続点を経由させることができず、変換装置を介して回線交換網の相互接続点を経由させざるを得ない場合には、非特許文献2の技術が適用できない。

また、接続構成１において非特許文献2の技術を適用した場合、事業者Bでは、音声と非音声のセッションを一つのSIPセッションに集約された状態で扱うこととなる。すなわち、音声と非音声のSIPセッションが同じ経路に従う。SIPでは、セッション確立時に確定されたSIP経路を、セッション確立後に修正することは許されていないため、たとえば、最初に音声セッションだけを確立した後、非音声セッションを同じSIP経路で追加した場合に、非音声セッションに対してメディア処理等のネットワークサービスを起動しようとしても、SIP経路が既に固定されてしまっているため、新たなアプリケーションサーバにSIP信号を中継することができず、サービスが起動できないという問題がある。

通信中に起動される可能性のあるネットワークサービスに関しては全て、通信開始時にアプリケーションサーバへルーチングしておく、という方法もあるが、アプリケーションサーバの処理リソースおよびネットワークリソースの浪費につながるため望ましくない。

本発明は上記の点に鑑みてなされたものであり、回線交換網とパケット交換網の2網を組み合わせて音声通信サービスと非音声通信サービスを提供する第１の網と、パケット交換網により音声通信サービスと非音声通信サービスの両方を提供する第２の網とを複数の相互接続点を介して相互接続した相互接続網において、第２の網側で、適切にセッションの分割や集約を行い、複数の相互接続点を適切に経由させるための技術を提供することを目的とする。

また、本発明は、適切なタイミングでセッション分割・集約を実行することで、通信確立時に利用が確定しないサービスを通信中に起動可能とすることを目的とする。更に、本発明は、ポリシの更新、適用、合意を、管理端末から遠隔で制御可能とすることで、簡便・迅速なポリシ操作を可能とすることも目的としている。

上記の課題を解決するために、本発明は、回線交換網とパケット交換網の2網を組み合わせて音声通信サービスと非音声通信サービスを提供する第１の網と、パケット交換網により音声通信サービスと非音声通信サービスの両方を提供する第２の網とを複数の相互接続点を介して相互接続した相互接続網において、前記第２の網に備えられるセッション処理システムであって、前記セッション処理システムは、SIP処理装置と、セッション分割ポリシを格納したポリシデータベースとを備え、前記SIP処理装置は、前記第２の網のパケット交換網から、前記第１の網への発信のためのSIP信号を受信したときに、前記ポリシデータベースからセッション分割ポリシを取得するデータベース処理手段と、前記セッション分割ポリシと前記SIP信号とを比較し、当該SIP信号が、前記セッション分割ポリシの条件に合致する場合に、当該セッション分割ポリシに従って、前記SIP信号を、接続先となる相互接続点毎に分割し、分割した各SIP信号を、対応する相互接続点に向けて送信するSIP制御手段とを備えることを特徴とするセッション処理システムとして構成される。

前記第２の網におけるパケット交換網は、前記発信のためのSIP信号を、他のアプリケーションサーバに先立って、最初のアプリケーションサーバとして前記SIP処理装置に転送するように構成してもよい。

また、前記SIP制御手段は、前記第１の網から着信のためのSIP信号を受信したときに、SIPセッション情報格納手段を参照することにより集約対象となる既存セッションの有無を調べ、当該既存セッションがある場合に、前記着信のためのSIP信号から通信内容を抽出し、前記既存セッションに当該通信内容を加えたSIP信号を生成して送信することによりセッション集約を行うようにしてもよい。

また、前記第２の網におけるパケット交換網は、前記着信のためのSIP信号を、所定のアプリケーションサーバへのルーチングが全て完了した後に、最後のアプリケーションサーバとしての前記SIP処理装置に転送するように構成してもよい。

また、本発明は、上記のセッション処理システムに対応するセッション処理方法、及びSIP処理装置として構成することもできる。

また、本発明は、前記セッション処理システムにおけるポリシデータベースに格納されるセッション分割ポリシを管理するためのポリシ管理装置であって、通信ネットワークを介して、管理端末から、ポリシ変更要求を受信したときに、ポリシ変更後に適用されることになるセッション分割ポリシと網条件とを照合し、これらが整合しているか否かを確認する整合性確認手段と、前記整合性確認手段により、前記セッション分割ポリシと前記網条件とが整合していると判定された場合に、前記ポリシデータベースに対するポリシ変更処理を行うデータベース処理手段とを備えることを特徴とするポリシ管理装置として構成してもよい。

ポリシ管理装置は、前記ポリシ変更後のセッション分割ポリシを適用した場合に、前記第１の網又は前記第２の網に与えることになる影響を計算し、計算結果を前記管理端末に送信する手段を更に備えてもよい。

また、本発明は、コンピュータを、前記SIP制御装置、又は、前記ポリシ管理装置の各手段として機能させるためのプログラムとして構成することもできる。

本発明によれば、回線交換網とパケット交換網の2網を組み合わせて音声通信サービスと非音声通信サービスを提供する第１の網と、パケット交換網により音声通信サービスと非音声通信サービスの両方を提供する第２の網とを複数の相互接続点を介して相互接続した相互接続網において、第２の網側で、適切なセッションの分割や集約を行い、複数の相互接続点を適切に経由させるための技術を提供することが可能となる。

また、本発明によれば、適切なタイミングでセッション分割・集約を実行することで、通信確立時に利用が確定しないサービスを通信中に起動可能とすることも可能になる。更に、本発明によれば、ポリシの更新、適用、合意を、管理端末から遠隔で制御可能とすることで、簡便・迅速なポリシ操作が可能になる。

接続構成１を説明するための図である。 接続構成２を説明するための図である。 本発明の実施の形態におけるシステムの全体構成図である。 SIP処理装置２３の機能構成図である。 セッション分割に関わる全体の処理の流れの例を説明するための図である。 SIP処理装置２３が実行するセッション分割に係る処理のフローチャートである。 セッション分割ポリシの具体例を説明するための図である。 セッション集約に関わる全体の処理の流れの例を説明するための図である。 SIP処理装置２３が実行するセッション集約に係る処理のフローチャートである。 セッション集約処理の具体例を示す図である。 ポリシ更新に関するシステムの全体構成図である。 ポリシ管理装置６２の機能構成図である。 ポリシ更新に関するシステムの動作例を説明するための図である。 トラヒック等の確認の処理について説明するための図である。

以下、図面を参照して本発明の実施の形態を説明する。

＜概要＞
本実施の形態では、前述した接続構成２において、事業者Bから事業者Aに接続する場合、発信側である事業者B側で、セッションの内容及び事業者Aとの接続点に関する合意に基づいて適切なセッションの分割を行い、IMS間の相互接続点と、変換装置を介した回線交換網とIMS間の相互接続点との双方を適切に経由させることを可能とする構成が示される。

また、本実施の形態では、事業者Bにおいて、セッション分割をSIP経路上の適切なタイミングで実行し、音声と非音声などの通信毎に異なるSIP経路を経由できるようにすることで、通信開始時には利用していなかったネットワークサービスを通信開始後に起動可能にする構成も示される。

更に、本実施の形態では、セッション分割ポリシを更新するための構成も示されている。これにより、例えば、着信側である事業者Aが、状況に応じて、特定のセッションが通過する相互接続点を変更したい場合に、変更希望及び変更の許可/拒否を事業者間で容易に授受することを可能とし、更にその変更によって生じる相互接続点の通信トラヒックの変化などを自動的に表示して事業者間で共有することで、当該の変更の実施要否・可否を容易に判断することを可能としている。

以下、最初に、セッション分割及び集約についての実施の形態を説明し、その後に、ポリシ更新に関する実施の形態を説明する。

＜セッション分割、セッション集約＞
以下、本実施の形態におけるセッション分割、及びセッション集約に関するシステム構成、及びシステムの動作を説明する。

（システム構成）
本実施の形態におけるシステムの全体構成を図３に示す。図３に示す構成は、図２に示した接続構成２に対応する。図３に示すように、本実施の形態におけるシステムは、事業者ＡのIMS１１と事業者BのIMS２１とが相互接続されるとともに、事業者BのIMS２１と事業者Aの回線交換網１２とが、事業者Bの変換装置２２を介して接続された構成を有する。なお、変換装置２２は、事業者A側に設置されてもよい。また、図２（ｂ）に示したように、変換装置２２が、事業者Bの回線交換網であってもよい。

事業者BのIMS２１には、本発明に係るセッション分割やセッション集約の制御を行うSIP処理装置２３、セッション分割のための種々のセッション分割ポリシを格納したポリシDB２４、及び、サービスを利用するユーザ端末２５が接続されている。事業者AのIMS１１及び回線交換網１２には、サービスを利用するユーザ端末１３が接続されている。本例では、ユーザ端末１３とユーザ端末２５との間で、音声やテキストチャット等の通信が行われる。ポリシDB２４は、単独のサーバ装置であってもよいし、SIP処理装置２３や、後述するポリシ管理装置等の中に備えられたDBであってもよい。

図４に、SIP処理装置２３の機能構成図を示す。図４に示すように、SIP処理装置２３は、ソケット部３１、通信制御部３２、DB処理部３３、SIP制御部３４、SIPセッション情報DB３５を備える。

ソケット部３１及び通信制御部３２は、SIP処理装置が、IMS２１を介して通信を行うための機能部である。SIP制御部３４は、SIPのヘッダ・ボディ処理、トランザクション管理、ダイアログ管理、セッションタイマ管理等を行う機能部であり、IMSにおける通常のSIP処理の他、DB処理部３３を介してセッション分割ポリシを取得し、ポリシに応じたSIPセッション分割処理を実行する。

SIPセッション情報DB３５は、SIP制御部３５のSIP処理に必要なセッション情報（Call-ID，tag，branch値等）を格納するデータベース（DB)である。DB処理部３３は、SIPセッション分割に必要なセッション分割ポリシを取得するために、ポリシDB２４にアクセスする機能部である。

SIP処理装置２３は、ＣＰＵ、メモリ、ハードディスク、通信インターフェース等を備えた一般的なコンピュータに、各機能部の処理に対応するプログラムを実行させることにより実現可能である。当該プログラムは、可搬メモリ等の記録媒体に記録して配布することが可能である。また、当該プログラムをネットワーク上のサーバからダウンロードしてインストールすることも可能である。

（セッション分割）
次に、図３に示すシステムにおいて行われるセッション分割の動作例を説明する。最初に、図５を参照して、セッション分割に関わる全体の処理の流れの例を説明する。

まず、事業者Bのユーザ端末２５が、事業者Aのユーザ端末１３に対して音声及びチャットを行うことを要求するSIP INVITEメッセージを送信する（ステップ１）。SIP INVITEメッセージは、IMS２１においてiFC（initial Filter Criteria）に基づきSIP処理装置２３に送られる（ステップ２）。本実施の形態において、事業者B側での発信に係るセッション分割時には、SIP処理装置２３が他のアプリケーションサーバに先立ち、最初のアプリケーションサーバとしてSIP経路に加わるようにIMSでの設定がなされている。

SIP INVITEメッセージを受信したSIP処理装置２３は、ポリシDB２４にアクセスしてポリシ取得要求を送信し、ポリシDBからセッション分割ポリシを取得する（ステップ３、４）。

SIP処理装置２３は、セッション分割ポリシに基づき、各分割セッションの接続点の判定を行う（ステップ５）。本例では、音声セッションは変換装置２２を経由して回線交換網１２との接続点へルーチングし、テキストチャットセッションはそのままIMS１１との接続点へルーチングするようにポリシが設定されているものとし、以下、このポリシに従った動作がなされる。

ここではまず、SIP処理装置２３は、音声接続のための処理を行う。つまり、SIP処理装置２３は、音声接続のためのSIP INVITEメッセージをIMS２１を介して変換装置２２に向けて送出し（ステップ６、７）、当該SIP INVITEメッセージは変換装置２２に届く。変換装置２２は、IMSのプロトコルから回線交換網のプロトコルへのプロトコル変換処理を行って（ステップ８）、回線交換網１２でのプロトコルで音声接続要求を回線交換網１２に送出し、当該接続要求は、回線交換網１２によりユーザ端末１３に送信される（ステップ９、１０）。その後、ユーザ端末１３とユーザ端末２５との間で音声通信が行われる（ステップ１１）。

続いて、SIP処理装置２３は、チャット接続のための処理を行う。つまり、SIP処理装置２３は、チャット接続のためのSIP INVITEメッセージを事業者AのIMS１１に向けて送出し、当該SIP INVITEメッセージは、事業者BのIMS２１及び事業者AのIMS１１を経由してユーザ端末１３に送信される（ステップ１２、１３、１４）。その後、ユーザ端末１３とユーザ端末２５との間でテキストチャット通信が行われる（ステップ１５）。

なお、図５に示した音声接続のための処理と、チャット接続のための処理は、同時に行われてもよいし、上述した順序と逆の順序で行うようにしてもよい。また、図５に示した処理においては、本実施の形態の説明をわかりやすくするために、主要な信号のみを示し、応答信号等の図示を省略している。また、IMS、回線交換網、変換装置、ユーザ端末の間の手順は、各々の標準的な手順に従うものである。

上記のように、本実施の形態では、SIP処理装置２３が、発信によるセッション分割時において、他のアプリケーションサーバに先立ち、最初のアプリケーションサーバとしてSIP経路に加わることとしている。このようにすることで、SIP処理装置２３が分割した個別のSIPセッションのそれぞれについて、IMSによるSIP経路設定が可能となる。そのため、例えば、図５に示した例のように、最初に音声呼を確立し、次にテキストチャットを追加した場合に、テキストチャットのSIPセッションはSIP処理装置２３で音声とは異なるSIPセッションとしてIMSで処理され、音声セッション確立時にはSIP経路に含まれなかったアプリケーションサーバにもSIP信号をルーチングすることができるようになり、音声呼確立時には利用が確定しなかったテキストチャット用のネットワークサービス（例：テキスト自動翻訳サービスなど）を、テキストチャット利用開始時に起動できるようになる。

次に、図６に示すフローチャートを参照して、SIP処理装置２３が実行するセッション分割に係る処理をより詳細に説明する。

SIP処理装置２３は、待機を経て（ステップ１０１）、SIP信号をIMS２１から受信する（ステップ１０２）。SIP処理装置２３のSIP制御部３４は、SIPセッション情報DB３５を参照して、当該SIP信号が新規ダイアログに係るものかどうか判定する（ステップ１０３）。新規ダイアログでなければ、通常のSIP手順に従って処理を継続する（ステップ１０４）。

ステップ１０３において、新規ダイアログであった場合、SIP処理装置２３のDB処理部３３は、ポリシDB２４にポリシ取得要求を送信する（ステップ１０５）。これにより、ポリシを正常に受信しなかった場合は（ステップ１０６のNo)、デフォルトポリシに従って処理を継続する（ステップ１０７）。

ポリシを正常に受信した場合（ステップ１０６のYes)、SIP処理装置２３のSIP制御部３４は、ポリシと受信信号とを照合して接続点判定を実施する（ステップ１０８）。ここで、受信信号がポリシにマッチしていなければ（ステップ１０９のNo)、通常のSIP手順に従って処理が継続される（ステップ１１０）。

ポリシにマッチしていた場合（ステップ１０９のYes)、SIP制御部３４はマッチしたポリシに従ってSIP信号を分割し（ステップ１１１）、未送信信号がなくなるまで、分割したSIP信号を順次IMS２１に送信する（ステップ１１２、１１３）。

セッションの種別に応じた接続点選択のためのセッション分割ポリシの具体例を図７（ａ）、（ｂ）に示す。なお、ここで示す例は、あくまでも一例であり、ポリシ内容や記述方法はこれに限られるわけではなく、同じ帰結を導くための異なる種々の記述方法、およびこれ以外の異なる帰結を導く種々の記述が存在し得る。

図７（ａ）は、セッション分割前のSIPメッセージ条件の例を示す。図７（ｂ）は、セッション分割条件の例を示す。

例えば、事業者Aと事業者B間で適用するセッション分割ポリシが図７（ａ）、（ｂ）に示すとおりであった場合、図６のステップ１０９における判定において、「受信したSIP信号のSIP-URIのhost部に"operatorA.com"が設定されており、Content-Typeとしてapplication/sdpが設定されおり、SDPにおけるコーデックにAMRまたはG.711が設定された(a=rtpmap行にAMRまたはPCMUが設定された)音声メディア(m=audio行)が設定され、かつ、CPIMまたはプレーンテキストを許容し(a=accept-types行にmessage/cpimまたはtext/plainまたはその両方が設定され)、プロトコルにMSRPが指定されたメッセージメディア(m=message行にTCP/MSRPを含む)が設定されている」ことが確認された場合、メッセージメディアのセッションの接続先をIMS間相互接続点とし、音声メディアの接続点を回線交換網相互接続点とするセッション分割を行うと判定し、図７（ｂ）に示す条件に従って、受信したSIP信号を分割して各分割セッションのSIP信号を形成する。

（セッション集約）
次に、セッション集約について説明する。最初に、図８を参照して、セッション集約に関わる全体の処理の流れの例を説明する。

まず、事業者Aのユーザ端末１３から回線交換網１２に対して音声接続のための接続要求が送信される（ステップ２１）。当該接続要求は、変換装置２２に送信され（ステップ２２）、変換装置２２によりSIP INVITEメッセージに変換されてIMS２１に送信される（ステップ２３）。IMS２１では、iFCにより、当該SIP INVITEメッセージがSIP処理装置２３に送信され（ステップ２４）、当該SIP INVITEメッセージは、SIP処理装置２３からIMS２１を介してユーザ端末２５に送信される（ステップ２５、２６）。その後、ユーザ端末とユーザ端末との間で音声通信が行われる（ステップ２７）。

続いて、事業者Aのユーザ端末１３から、テキストチャットの接続を要求するSIP INVITEメッセージがIMS１１に送信される（ステップ２８）。当該SIP INVITEメッセージは、事業者BのIMS２１に送信される（ステップ２９）。IMS２１では、iFCにより、当該SIP INVITEメッセージがSIP処理装置２３に送信される（ステップ３０）。当該SIP INVITEメッセージを受信したSIP処理装置２３は、音声セッションとチャットセッションを集約するセッション集約処理を行う（ステップ３１）。

本実施の形態では、SIP処理装置２３がSIP INVITEメッセージを受信した場合、集約対象の既存セッションがあるかどうかを確認し、集約対象の既存セッションがある場合に集約処理を実行する。本例のステップ３１において、既存セッションとして音声セッションがあるので、集約処理を実行している。集約対象の既存セッションの有無は、SIPセッション情報DB３５を参照して、発着端末の識別子（SIP-URI，TEL-URIなど）の組み合わせで、既に同じ組み合わせのセッションが確立されているかどうかを検索することで確認できる。

そして、SIP処理装置２３は、集約されたセッション（音声＋チャット）に係るSIP re-INVITEメッセージをIMS２１に送信し（ステップ３２）、SIP re-INVITEメッセージはユーザ端末２５に届けられる（ステップ３３）。その後、SIP re-INVITEメッセージに基づく音声通信とテキストチャット通信が行われる（ステップ３４、３５）。

図５の場合と同様に、図８に示した処理においては、本実施の形態の説明をわかりやすくするために、主要な信号のみを示し、応答信号等の図示を省略している。また、IMS、回線交換網、変換装置、ユーザ端末の間の手順は、各々の標準的な手順に従うものである。

本実施の形態において、事業者Aからの着信によるセッション集約時においては、SIP処理装置２３は、着信要求に関わる他のアプリケーションサーバへのルーチングが全て終わった後に、最後のアプリケーションサーバとしてSIP経路に加わるように設定がされている。

このようにすることで、SIP処理装置２３が集約する前の個別のSIPセッションのそれぞれについて、IMSによるSIP経路設定が可能となる。そのため、例えば、最初に音声呼を着信し、次にテキストチャットの追加を着信した場合に、テキストチャットのSIPセッションはSIP処理装置２３で音声とは異なるSIPセッションとしてIMSで処理され、音声セッション確立時にはSIP経路に含まれなかったアプリケーションサーバにもSIP信号をルーチングすることができるようになり、音声呼確立時には利用が確定しなかったテキストチャット用のネットワークサービス（例：テキスト自動翻訳サービスなど）を、テキストチャット着信時に起動できるようになる。

次に、図９に示すフローチャートを参照して、SIP処理装置２３が実行するセッション集約に係る処理をより詳細に説明する。

SIP処理装置２３は、待機を経て（ステップ２０１）、SIP信号をIMS２１から受信する（ステップ２０２）。SIP処理装置２３のSIP制御部３４は、SIPセッション情報DB３５を参照して、集約対象となる既存セッションの有無を判定する（ステップ２０３）。既存セッションがなければ、通常のSIP手順に従って処理を継続する（ステップ２０４）。

既存セッションがあれば、SIP制御部３４は、ステップ２０２で受信したSIP信号に係るセッションを、既存セッションに集約してre-INVITEメッセージを生成し、送信する（ステップ２０５、２０６）。その後は、通常のSIP手順に従って処理を継続する（ステップ２０７）。

図１０は、本実施の形態におけるセッション集約処理の具体例を示す図である。図１０に示すように、セッション集約においては、SIP制御部３４は、2番目以降に受信したSIPリクエストに設定されているセッション記述（SDP：Session Description Protocol)から、当該のSIPリクエストで確立したいメディア記述（m=行およびそれに関連したa=行）を抽出し、それを最初に確立したSIPセッションを更新するためのre-INVITEリクエストのSDPに追加して送信することとしている。

＜ポリシ更新＞
続いて、本実施の形態におけるポリシ更新に関するシステム構成、及び動作を説明する。

（システム構成）
ポリシ更新に関するシステムの全体構成を図１１に示す。図１１に示すように、このシステムでは、事業者Bの通信ネットワーク６１と事業者Aの通信ネットワーク５１が相互接続されているとともに、事業者Bの通信ネットワーク６１に、ポリシ更新等を行うためのポリシ管理装置６２、ポリシDB２４、トラヒック情報DB６３、及び管理端末６４が接続され、事業者Aの通信ネットワーク５１に管理端末５２が接続されている。

なお、通信ネットワーク５１、６１は上記装置間で通信を行うことを可能にするネットワークであり、特定のものに限定されないが、例えば、通信ネットワーク５１、６１は、それぞれIMS１１、２１であってよい。

本実施の形態におけるポリシ管理装置６２は、セッション分割ポリシの更新、削除、追加等の要求（これらを総称してポリシ変更要求と呼ぶ）を受信した場合に、変更後に事業者A、Bに適用されるセッション分割ポリシ（更新／追加されるポリシ、指定されたポリシ削除後に適用されるポリシ等）と、事業者A、Bの網構成や制約条件等（これらをまとめて網条件と呼ぶ。網条件はポリシ管理装置が記憶手段に保持し、それを取得してもよいし、外部のDBから取得してもよい）とを照合し、これらの間に矛盾がないかどうかを確認する機能を有する装置である。本実施の形態では、この確認処理を「整合性確認」と呼んでいる。

生じる可能性のある主な不整合としては、例えば、変換装置２２が対応していない種類の通信セッションを、変換装置２２を経由して回線交換網１２との接続点へルーチングするようなポリシを設定しようとすることや、あるポリシを削除することで、どこにもルーチング先がないような通信セッションが生じてしまうこと等がある。

トラヒック情報DB６３は、後述するポリシ管理装置６２のトラヒック確認部７８が計算をするために必要な、接続統計情報、課金情報等を格納するDBである。これらの情報は、情報種別毎に複数の異なるDBに分離して格納されていても良い。また、トラヒック情報DB６３は、サーバ装置として構成してもよいし、ポリシ管理装置６２等の装置の中のDBとして構成してもよい。

図１２に、ポリシ管理装置６２の機能構成図を示す。図１２に示すように、ポリシ管理装置６２は、ソケット部７１、通信制御部７２、フロントエンド７３、認証処理部７４、認証情報DB７５、整合確認部７６、DB処理部７７、トラヒック確認部７８を有する。

ソケット部７１及び通信制御部７２は、ポリシ管理装置６２が、通信ネットワーク６１を介して通信を行うための機能部である。

フロントエンド７３は、管理端末５２、６４にGUI（Graphical User Interface）を提供するための機能部である。なお、一部のDB処理（ポリシ取得等）はフロントエンド７３を経由せず、直接通信制御部７２を介して行われることがある。

認証処理部７４は、管理端末５２、６４からのアクセス認証を担う機能部である。認証情報DB７５は、管理端末５２、６４からのアクセス認証に必要な認証情報（ID，パスワード等）を格納するDBである。整合確認部７６は、セッション分割ポリシの更新・削除等の変更が、事業者の網構成や制約条件等に矛盾しないかどうかをチェックする機能部である。

DB処理部７７は、セッション分割ポリシの取得、更新、削除、接続統計情報取得等の要求に応じて、各DBへアクセスする機能部である。トラヒック確認部７８は、セッション分割ポリシの変更によって、トラヒック量や相互接続料金がどのように変わるのかを計算する機能部である。

ポリシ管理装置６２は、ＣＰＵ、メモリ、ハードディスク、通信インターフェース等を備えた一般的なコンピュータに、各機能部の処理に対応するプログラムを実行させることにより実現可能である。当該プログラムは、可搬メモリ等の記録媒体に記録して配布することが可能である。また、当該プログラムをネットワーク上のサーバからダウンロードしてインストールすることも可能である。

（システムの動作）
次に、ポリシ更新に関するシステムの動作例を、図１３のシーケンスチャートを参照して説明する。

事業者Aの管理端末５２が、接続要求をポリシ管理装置６２に送信すると（ステップ５１）、ポリシ管理装置６３の認証処理部７４は、認証処理を行って（ステップ５２）、認証に成功すれば接続成功応答を管理端末５２に送信する（ステップ５３）。

管理端末５２がポリシ更新要求をポリシ管理装置６２に送信すると（ステップ５４）、ポリシ管理装置６２のDB処理部７７は、ポリシDB２４にポリシ取得要求を送信し（ステップ５５）、ポリシDB２４から、更新要求で要求された内容に対応するポリシを取得する（ステップ５６）。そして、ポリシ管理装置６２の整合性確認部７６は、前述したような整合性確認を行う（ステップ５７）。

整合性確認の結果、不整合であった場合、ポリシ管理装置６３は、ポリシ更新失敗通知を事業者Aの管理端末５２に送信するとともに（ステップ６１）、不整合通知を事業者Bの管理端末６４に送信する（ステップ６２）。

整合性確認の結果、整合していた場合、ポリシ管理装置６２は、ポリシ更新保留応答を事業者Aの管理端末５２に送信するとともに（ステップ７１）、ポリシ更新確認要求を事業者Bの管理端末６４に送信する（ステップ７２）。ポリシ更新確認要求には、更新しようとするポリシの内容等が含まれる。

ポリシ更新確認要求に応じて、事業者Bにおいてポリシ更新が許可された場合、管理端末６４から許可応答がポリシ管理装置６２に送信され（ステップ７３）、許可応答を受信したポリシ管理装置６２は、ポリシ更新要求をポリシDB２４に送信し（ステップ７４）、ポリシDBから更新成功応答を受信する（ステップ７５）。上記ポリシ更新要求は、例えば、事業者Aと事業者B間で新たに適用するポリシを識別する情報を含む。

そして、ポリシ管理装置２４は、ポリシ更新完了通知を事業者Aの管理端末５２に送信し（ステップ７６）、ポリシ更新完了通知を事業者Bの管理端末６４に送信する（ステップ７７）。

事業者Bにおいてポリシ更新が許可されなかった場合は、管理端末６４から拒否応答がポリシ管理装置６２に送信され（ステップ７８）、拒否応答を受信したポリシ管理装置２４は、ポリシ更新拒否通知を事業者Aの管理端末５２に送信する（ステップ７９）。

上記ポリシ更新の処理において、ステップ５４、ステップ７３又は７８のそれぞれにおいて（図１３で※で示す）、当該ステップに先立って、各管理端末で、新たなポリシを適用した場合のトラヒックの変化等を確認することが可能である。すなわち、事業者A側は、ポリシ変更要求を送信する前に（図１３のステップ５４の前に）、当該のポリシ変更が及ぼすトラヒック等への影響を確認することができる。また、事業者B側は、事業者A側からポリシ変更要求があった場合、ポリシ変更が及ぼすトラヒック等への影響を確認してから、許可/拒否を判断することができる。図１４を参照して、このトラヒック等の確認の処理について説明する。

事業者A側での確認時（図１３のステップ５４の前）、事業者Aの管理端末５２は、ポリシ送信・影響確認要求をポリシ管理装置６２に送信する。ポリシ送信・影響確認要求を受信したポリシ管理装置６２のDB処理部７７は、トラヒック情報等取得要求をトラヒック情報DB６３に送信し、トラヒック情報等を取得する（ステップ８２、８３）。そして、トラヒック確認部７８が、取得したトラヒック情報等と、更新に係るポリシとを用いて、ポリシ適用結果の計算を行い（ステップ８４）、ポリシ変更による影響を示す計算結果を事業者Aの管理端末５２に返却する（ステップ８５）。

事業者B側での確認時（図１３のステップ７２の後）においては、事業者Bの管理端末６４は、ポリシ影響確認要求をポリシ管理装置６２に送信する（ステップ８６）。ポリシ影響確認要求を受信したポリシ管理装置６２は、対象ポリシ取得要求をポリシDB２４に送信し（ステップ８７）、ポリシDB２４から更新に係るポリシを取得する（ステップ８８）。また、ポリシ管理装置６２のDB処理部７７は、トラヒック情報等取得要求をトラヒック情報DB６３に送信し、トラヒック情報等を取得する（ステップ８９、９０）。そして、トラヒック確認部７８は、取得したトラヒック情報等と、新たに適用しようとしている更新に係るポリシとを用いて、ポリシ適用結果の計算を行い（ステップ９１）、ポリシの更新を行った場合の影響を示す計算結果を事業者Bの管理端末６４に返却する（ステップ９２）。

＜まとめ、実施の形態の効果＞
これまでに説明したように、本実施の形態においては、SIPセッション確立時に、事業者A、B間で合意したセッション分割ポリシに応じてSIP処理装置２３がSIPセッションの分割を実施することで、必ずしも全てのセッションをIMS間相互接続点を通過させられない場合においても、適切な接続点を選択してルーチングさせることを可能としている。

また、セッション分割・集約時のSIP経路とサービス起動の関係性に着目し、適切なタイミングでセッション分割・集約を実行することで、通信確立時に利用が確定しないサービスを通信中に起動可能にし、更に、ポリシの更新、適用、合意を、両事業者の管理端末から遠隔で制御可能とすることで、簡便・迅速なポリシ操作を可能としている。

すなわち、本実施の形態の技術によれば、RCSのようなリッチコミュニケーションサービスを、事業者間の接続構成上の都合により従来は享受することができなかったエンドユーザに対しても、提供することができるようになる。

また、通信開始時に利用が確定しないネットワークサービスを、アプリケーションサーバの処理リソース・ネットワークリソースの浪費を防ぎつつ、通信中のユーザ要求に応じて起動することが可能になり、より低いコストでユーザに新たなネットワークサービスを提供可能となる。

更に、ポリシ管理装置６２を導入したことにより、セッション種別に応じて適切な接続点を経由させるためのポリシの更新・適用・合意をより簡便かつ迅速に実施することができるようになるとともに、ポリシの適用が及ぼすトラヒック等への提供をより簡便・迅速に確認することができるようになり、事前の検討が不十分なポリ詩の変更による予期せぬトラヒック集中の発生などのリスクを低減することができる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１１、２１ IMS
１２ 回線交換網
１３、２５ ユーザ端末
２２ 変換装置
２３ SIP処理装置
２４ ポリシDB
３１ ソケット部
３２ 通信制御部
３３ DB処理部
３４ SIP制御部
３５ SIPセッション情報DB
５１、６１ 通信ネットワーク
５２、６４ 管理端末
６２ ポリシ管理装置
６３ トラヒック情報DB
７１ ソケット部
７２ 通信制御部
７３ フロントエンド
７４ 認証処理部
７５ 認証情報DB
７６ 整合確認部
７７ DB処理部
７８ トラヒック確認部

Claims (10)

1. 回線交換網とパケット交換網の2網を組み合わせて音声通信サービスと非音声通信サービスを提供する第１の網と、パケット交換網により音声通信サービスと非音声通信サービスの両方を提供する第２の網とを複数の相互接続点を介して相互接続した相互接続網において、前記第２の網に備えられるセッション処理システムであって、
   前記セッション処理システムは、SIP処理装置と、セッション分割ポリシを格納したポリシデータベースとを備え、前記SIP処理装置は、
   前記第２の網のパケット交換網から、前記第１の網への発信のためのSIP信号を受信したときに、前記ポリシデータベースからセッション分割ポリシを取得するデータベース処理手段と、
   前記セッション分割ポリシと前記SIP信号とを比較し、当該SIP信号が、前記セッション分割ポリシの条件に合致する場合に、当該セッション分割ポリシに従って、前記SIP信号を、接続先となる相互接続点毎に分割し、分割した各SIP信号を、対応する相互接続点に向けて送信するSIP制御手段と
   を備えることを特徴とするセッション処理システム。
2. 前記第２の網におけるパケット交換網は、前記発信のためのSIP信号を、他のアプリケーションサーバに先立って、最初のアプリケーションサーバとして前記SIP処理装置に転送することを特徴とする請求項１に記載のセッション処理システム。
3. 前記SIP制御手段は、前記第１の網から着信のためのSIP信号を受信したときに、SIPセッション情報格納手段を参照することにより集約対象となる既存セッションの有無を調べ、当該既存セッションがある場合に、前記着信のためのSIP信号から通信内容を抽出し、前記既存セッションに当該通信内容を加えたSIP信号を生成して送信することによりセッション集約を行う
   ことを特徴とする請求項１又は２に記載のセッション処理システム。
4. 前記第２の網におけるパケット交換網は、前記着信のためのSIP信号を、所定のアプリケーションサーバへのルーチングが全て完了した後に、最後のアプリケーションサーバとしての前記SIP処理装置に転送する
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載のセッション処理システム。
5. 回線交換網とパケット交換網の2網を組み合わせて音声通信サービスと非音声通信サービスを提供する第１の網と、パケット交換網により音声通信サービスと非音声通信サービスの両方を提供する第２の網とを複数の相互接続点を介して相互接続した相互接続網において、前記第２の網に備えられるSIP処理装置であって、
   前記第２の網のパケット交換網から、前記第１の網への発信のためのSIP信号を受信したときに、前記第２の網に備えられるポリシデータベースからセッション分割ポリシを取得するデータベース処理手段と、
   前記セッション分割ポリシと前記SIP信号とを比較し、当該SIP信号が、前記セッション分割ポリシの条件に合致する場合に、当該セッション分割ポリシに従って、前記SIP信号を、接続先となる相互接続点毎に分割し、分割した各SIP信号を、対応する相互接続点に向けて送信するSIP制御手段と
   を備えることを特徴とするSIP処理装置。
6. 前記SIP制御手段は、前記第１の網から着信のためのSIP信号を受信したときに、SIPセッション情報格納手段を参照することにより集約対象となる既存セッションの有無を調べ、当該既存セッションがある場合に、前記着信のためのSIP信号から通信内容を抽出し、前記既存セッションに当該通信内容を加えたSIP信号を生成して送信することによりセッション集約を行う
   ことを特徴とする請求項５に記載のSIP処理装置。
7. 請求項１ないし４のうちいずれか１項に記載された前記セッション処理システムにおけるポリシデータベースに格納されるセッション分割ポリシを管理するためのポリシ管理装置であって、
   通信ネットワークを介して、管理端末から、ポリシ変更要求を受信したときに、ポリシ変更後に適用されることになるセッション分割ポリシと網条件とを照合し、これらが整合しているか否かを確認する整合性確認手段と、
   前記整合性確認手段により、前記セッション分割ポリシと前記網条件とが整合していると判定された場合に、前記ポリシデータベースに対するポリシ変更処理を行うデータベース処理手段と
   を備えることを特徴とするポリシ管理装置。
8. 前記ポリシ変更後のセッション分割ポリシを適用した場合に、前記第１の網又は前記第２の網に与えることになる影響を計算し、計算結果を前記管理端末に送信する手段を備えることを特徴とする請求項７に記載のポリシ管理装置。
9. コンピュータを、請求項５又は６に記載のSIP制御装置、又は、請求項７又は８に記載のポリシ管理装置の各手段として機能させるためのプログラム。
10. 回線交換網とパケット交換網の2網を組み合わせて音声通信サービスと非音声通信サービスを提供する第１の網と、パケット交換網により音声通信サービスと非音声通信サービスの両方を提供する第２の網とを複数の相互接続点で相互接続した相互接続網において、前記第２の網に備えられるセッション処理システムにおけるセッション処理方法であって、
    前記セッション処理システムは、SIP処理装置と、セッション分割ポリシを格納したポリシデータベースとを備え、
    前記SIP処理装置が、前記第２の網のパケット交換網から、前記第１の網への発信のためのSIP信号を受信したときに、前記ポリシデータベースからセッション分割ポリシを取得するデータベース処理ステップと、
    前記SIP処理装置が、前記セッション分割ポリシと前記SIP信号とを比較し、当該SIP信号が、前記セッション分割ポリシの条件に合致する場合に、当該セッション分割ポリシに従って、前記SIP信号を、接続先となる相互接続点毎に分割し、分割した各SIP信号を、対応する相互接続点に向けて送信するSIP制御ステップと
    を備えることを特徴とするセッション処理方法。

Images