(57)【要約】  接続先セッションコントローラ、ＩＰマルチメディア・サブシステム及び当該システムにおけるセッション登録方法を開示する。接続先セッションコントローラは、メッセージ受信モジュール、サービストリガー配置モジュール、セッション制御モジュール及メッセージ送信モジュールを含む。ＩＰマルチメディア・サブシステムは、接続先セッションコントローラ、網全体ホーム加入者サービスシステム等の設備を含む。接続先セッションコントローラは網全体ホーム加入者サービスシステムに対して認証情報要求を開始し、加入者から発せられたメッセージを直接に処理してセッションを確立する。上述技術案は信号処理フローを簡易化させ、ネットワーク複雑度を低減させることができる。
2010536279.tif 000002
【特許請求の範囲】
【請求項１】
加入者からの発呼要求メッセージ及び応答メッセージを受信するか、又はネットワーク設備からの発呼要求メッセージ及び応答メッセージを受信するメッセージ受信モジュールと、
トリガー情報を配置するサービストリガー配置モジュールと、
前記サービストリガー配置モジュールから配置されたトリガー情報により、前記発呼要求メッセージ又は応答メッセージがアプリケーションサーバのトリガー条件を満たしたと確定した場合、対応するアプリケーションサーバをトリガーするメッセージの送信指示を生成し、セッションを確立・維持・解放し、セッション確立過程において、発呼要求メッセージを直接に着呼加入者が所在する接続先セッションコントローラ又は対応するブレークアウトゲートウェイ制御機能モジュールに送信する指示を生成するセッション制御モジュールと、
前記セッション制御モジュールの指示によりメッセージを送信するメッセージ送信モジュールと
を含むことを特徴とする接続先セッションコントローラ。
【請求項２】
前記メッセージ受信モジュールは、さらに加入者からの登録メッセージを受信し、
前記接続先セッションコントローラは、前記登録メッセージにより、網全体ホーム加入者サービスシステムと情報交換をし、前記加入者の登録過程を制御する登録制御モジュールを更に含むことを特徴とする、請求項１に記載の接続先セッションコントローラ。
【請求項３】
前記発呼要求メッセージに含まれた加入者標識により、メッセージの次のホップの転送先アドレス情報を見つけるルーティングモジュールを更に含み、
前記セッション制御モジュールはさらに、前記ルーティングモジュールで見つけられたアドレス情報により、前記発呼要求メッセージを転送する指示を生成し、前記メッセージ送信モジュールはさらに、前記発呼要求メッセージを転送する指示により発呼要求メッセージを送信することを特徴とする、請求項１又は２に記載の接続先セッションコントローラ。
【請求項４】
前記発呼要求メッセージを圧縮する信号圧縮モジュールを更に含むことを特徴とする、請求項３に記載の接続先セッションコントローラ。
【請求項５】
前記発呼要求メッセージにより確立されたセッションに対して料金を計算する料金計算モジュールを更に含むことを特徴とする、請求項３に記載の接続先セッションコントローラ。
【請求項６】
請求項１〜５のいずれかに記載の接続先セッションコントローラと、
前記接続先セッションコントローラと接続され、前記接続先セッションコントローラが検索できるように、網全体加入者情報及び対応するインデックスを記憶する網全体ホーム加入者サービスシステムと
を含むことを特徴とするＩＰマルチメディア・サブシステム。
【請求項７】
前記網全体ホーム加入者サービスシステムは
網全体加入者情報のインデックスを蓄積する第一蓄積モジュールと、
前記加入者情報インデックスに対応する網全体加入者情報を蓄積する第二蓄積モジュールと
を含むことを特徴とする請求項６に記載のＩＰマルチメディア・サブシステム。
【請求項８】
ＩＰマルチメディア・サブシステムにおける接続先セッションコントローラは発呼要求メッセージを受信し、
前記接続先セッションコントローラは配置されたトリガー情報により、前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たしたと確定した場合、対応するアプリケーションサーバをトリガーし、
前記接続先セッションコントローラは前記対応するアプリケーションサーバから返送されたメッセージにより、セッションを確立する、
ことを特徴とするＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項９】
前記接続先セッションコントローラは配置されたトリガー情報により前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たすかを確定する前に、更に、前記発呼要求メッセージを送信した加入者端末に対して登録を行うことを特徴とする、請求項８に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１０】
前記発呼要求メッセージを送信した加入者端末に対して登録を行うことは、
前記接続先セッションコントローラは加入者端末から送信された登録要求メッセージを受信後、網全体ホーム加入者サービスシステムに対してマルチメディア認証要求メッセージを送信し、
前記網全体ホーム加入者サービスシステムは前記接続先セッションコントローラに対して、前記登録要求メッセージを送信した加入者の認証条件を返送し、
前記接続先セッションコントローラは、前記加入者端末より加入者の認証情報を取得し、前記認証情報が前記認証条件を満たしたと確定した場合、前記網全体ホーム加入者サービスシステムに対してサーバ割当要求メッセージを送信し、前記網全体ホーム加入者サービスシステムから返送されたサーバ割当応答メッセージ及び前記加入者の関連データを受信後、前記加入者に対して登録成功メッセージを返し、前記認証情報が前記認証条件を満たしていないと確定した場合、前記加入者に対して登録失敗メッセージを送信すること
を含むことを特徴とする、請求項９に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１１】
前記接続先セッションコントローラが前記対応するアプリケーションサーバから返されたメッセージによりセッションを確立することは、
前記接続先セッションコントローラは前記対応するアプリケーションサーバから返送されたメッセージにより、前記加入者端末に対して応答メッセージを返送し、前記加入者端末は前記接続先セッションコントローラにより、前記対応するアプリケーションサーバとセッション接続を確立すること
を含むことを特徴とする、請求項８に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１２】
前記接続先セッションコントローラが前記対応するアプリケーションサーバから返送されたメッセージによりセッションを確立することは、
前記接続先セッションコントローラは前記対応するアプリケーションサーバから返送されたメッセージにより、前記網全体ホーム加入者サービスシステムに対して位置情報要求メッセージを送信し、
前記網全体ホーム加入者サービスシステムは着呼加入者が所在する接続先セッションコントローラの情報を返送し、
前記接続先セッションコントローラは前記着呼加入者が所在する接続先セッションコントローラ情報により、対応する着呼側接続先セッションコントローラに対して前記発呼要求メッセージを送信し、
前記着呼側接続先セッションコントローラは記憶されたトリガー情報により、前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たすか否かを判断し、トリガー条件を満たした場合、対応する着呼側アプリケーションサーバをトリガーし、満たさない場合、前記発呼要求メッセージをルーティングして前記着呼加入者に転送すること
を含むことを特徴とする、請求項８に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１３】
前記接続先セッションコントローラが前記対応するアプリケーションサーバから返送されたメッセージによりセッションを確立することは、
前記接続先セッションコントローラは前記対応するアプリケーションサーバから返送されたメッセージにより、前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たしたと確定した場合、継続して対応するアプリケーションサーバをトリガーすることを含むことを特徴とする、請求項８に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１４】
前記接続先セッションコントローラは配置されたトリガー情報により、前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たしていないと確定した場合、網全体ホーム加入者サービスシステムに対して位置情報要求メッセージを送信し、
前  記網全体ホーム加入者サービスシステムは着呼加入者が所在する接続先セッションコントローラの情報を返送し、
前記接続先セッションコントローラは前記着呼加入者が所在する接続先セッションコントローラの情報により，対応する着呼側接続先セッションコントローラに対して前記発呼要求メッセージを転送し、
前記着呼側接続先セッションコントローラは記憶されたトリガー情報により前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たしたと確定後、前記着呼側接続先セッションコントローラは対応する着呼側アプリケーションサーバをトリガーし、前記着呼側アプリケーションサーバから返送されたメッセージによりセッションを確立する、
ことを含むことを特徴とする、請求項８に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１５】
前記着呼側接続先セッションコントローラが対応する着呼側アプリケーションサーバをトリガーすることは、具体的に、前記着呼接続先セッションコントローラは順番に前記発呼要求メッセージでトリガーできる全てのアプリケーションサーバをトリガーすることを特徴とする、請求項１４に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１６】
前記セッション確立の後、更に、前記接続先セッションコントローラはセッションを解放することを含むことを特徴とする、請求項８〜１５の何れかに一項に記載のＩＰマルチメディア・サブシステムにおけるセッション確立方法。
【請求項１７】
ＩＰマルチメディア・サブシステムにおける接続先セッションコントローラは加入者端末より送信された登録要求メッセージを受信後、網全体ホーム加入者サービスシステムに対してマルチメディア認証要求メッセージを送信し、
前記網全体ホーム加入者サービスシステムは前記接続先セッションコントローラに対して前記登録要求メッセージを送信した加入者の認証条件を返送し、
前記接続先セッションコントローラは前記加入者端末より加入者の認証情報を取得し、前記認証情報が前記認証条件を満たしたと確定した場合、前記網全体ホーム加入者サービスシステムに対してサーバ割当要求メッセージを送信し、前記網全体ホーム加入者サービスシステムから返送されたサーバ割当応答メッセージ及び前記加入者の関連データを受信後、前記加入者に対して登録成功メッセージを返送し、前記認証情報が前記認証条件を満たしていないと確定した場合、前記加入者に対して登録失敗メッセージを送信すること
を含むことを特徴とするＩＰマルチメディア・サブシステムにおける端末登録方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワーク技術に関し、特に接続先セッションコントローラ、ＩＭＳ、及びＩＭＳにおけるセッション確立・端末登録方法に関わっている。
【背景技術】
【０００２】
図１６に示すように、運営及び料金計算応援システム６のサポート下の従来のＩＭＳ網は、接続層９、セッション制御層８とアプリケーション層７の三層に分けられる。接続層９はＧＰＲＳゲートウェイ・サポート・ノード（ＧＧＳＮ）９１、サービスＧＰＲＳサポート・ノード（ＳＧＳＮ）９２とＩＰアクセス網９３を含み、端末は接続層９に接続されてから、ＩＭＳシステムより提供されたサービスを利用できる。ネットワークのセッション制御層８に位置しているＩＭＳシステムは、ＩＭＳサービス制御（ＩＳＣ）インターフェース７５をサポートし、更にＩＳＣインターフェース７５により補充サービス及び自己付加価値サービスを提供するアプリケーションサーバ７１と７３と、第三者サービスを提供するサービス能力サーバ７４及び従来のインテリジェント・ネットワーク・サービス・プラットフォーム７２とをサポートする。そのうち、アプリケーションサーバ７１と７３はセッション開始プロトコル（ＳＩＰ）に基づき、サービス能力サーバ７４はオープンサービス構造（ＯＳＡ）に基づいたものである。ＩＭＳシステム１０の構造は図１７に示すように、代理呼セッション制御機能(Ｐｒｏｘｙ−Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、Ｐ−ＣＳＣＦと略称)モジュール１６１、問い合わせ呼セッション制御機能（Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ、Ｉ−ＣＳＣＦと略称）モジュール１６３、サービス呼セッション制御機能(Ｓｅｒｖｉｃｅ−Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、Ｓ−ＣＳＣＦと略称)モジュール１６２、メディアゲートウェイ制御機能(Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、ＭＧＣＦと略称)モジュール１４、マルチメディア・リソース機能コントローラ(Ｍｕｌｔｉｍｅｄｉａ  Ｒｅｓｏｕｒｃｅ  Ｆｕｎｃｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ、ＭＲＦＣと略称)１３、マルチメディア・リソース機能プロセッサ(Ｍｕｌｔｉｍｅｄｉａ  Ｒｅｓｏｕｒｃｅ  Ｆｕｎｃｔｉｏｎ  Ｐｒｏｃｅｓｓｏｒ、ＭＲＦＰと略称)１１、ＩＭＳメディアゲートウェイ(ＩＭＳ  Ｍｅｄｉａ  Ｇａｔｅｗａｙ、ＩＭＳ−ＭＧＷと略称)１２、ブレークアウトゲートウェイ制御機能(Ｂｒｅａｋｏｕｔ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、ＢＧＣＦと略称)モジュール１５、ホーム加入者サーバ(Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅ  Ｓｅｒｖｅｒ、ＨＳＳと略称)１７等の物理的実体を含む。そのうち、Ｓ−ＣＳＣＦ１６２はＩＭＳシステムの制御核心であり、Ｐ−ＣＳＣＦ１６１はＩＭＳ加入者がネットワークにアクセスする入り口であり、Ｐ−ＣＳＣＦ１６１は加入者からのサービス要求をＳ−ＣＳＣＦ１６２に転送し、ホーム網のサービス・プラットフォームにより処理し、ＭＧＣＦ１４とＩＭＳ−ＭＧＷ１２はＩＭＳシステム１０とＵＭＴＳ網のＣＳドメインとを相互接続するか、又は公衆交換電話網（ＰＳＴＮ）１と相互接続するようにし、ＭＲＦＣ１３とＭＲＦＰ１１はサービスに必要なメディアリソース及び関連する制御機能を提供し、ＢＧＣＦ１５はＩＭＳ網２'と外部ネットワークとの境界点として、ＣＳドメイン、またはＰＳＴＮ１との接続点を選択する。既存移動信号網（Ｌｅｇａｃｙ  Ｍｏｂｉｌｅ  Ｓｉｇｎａｌ���ｎｇ  Ｎｅｔｗｏｒｋｓ）３とＨＳＳ１７の間はインターフェースＧｒ、Ｇｃ、Ｃ及びＤを介して接続され、ＩＭＳ網２'とＭＲＦＰ１１の間及びＭＲＦＰ１１とＩＭＳ−ＭＧＷ１２の間はインターフェースＭｂを介して接続され、ＰＳＴＮ１はインターフェースＰＳＴＮを介してＩＭＳ−ＭＧＷ１２及びＭＧＣＦ１４と接続され、ＩＭＳ−ＭＧＷ１２とＭＧＣＦ１４の間はインターフェースＭｎを介して接続され、ＢＧＣＦ１５の間及びＢＧＣＦ１５とＩＭＳ網２'の間はインターフェースＭｋを介して接続され、ＢＧＣＦ１５とＭＧＣＦ１４の間はインターフェースＭｊを介して接続され、ＭＧＣＦ１４とＳ−ＣＳＣＦ１６２の間はインターフェースＭｇを介して接続され、ＭＲＦＰ１１とＭＲＦＣ１３の間はインターフェースＭｐを介して接続され、ＭＲＦＣ１３とＳ−ＣＳＣＦ１６２の間はインターフェースＭｒを介して接続され、ＢＧＣＦ１５とＳ−ＣＳＣＦ１６２の間はインターフェースＭｉを介して接続され、Ｐ−ＣＳＣＦ１６１とＳ−ＣＳＣＦ１６２の間及びＳ−ＣＳＣＦ１６２とＩ−ＣＳＣＦ１６３の間はインターフェースＭｗを介して接続され、ＩＭＳ網２'とＳ−ＣＳＣＦ１６２の間はインターフェースＭｍを介して接続され、Ｓ−ＣＳＣＦ１６２はそれぞれとインターフェースＣｘ、ＤｘとＩＳＣを介してＨＳＳ１７、ＳＬＦ１８及びＡＳ５と接続され、Ｐ−ＣＳＣＦ１６１と端末４の間はインターフェースＧｍを介して接続され、ＡＳ５はそれぞれとインターフェースＳｈ（Ｓｉ）、Ｄｈを介してＨＳＳ１７、ＳＬＦ１８と接続され、上述インターフェースの詳細について３ＧＰＰ  ＴＳ  ２３.００２標準を参照する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
従来のＩＭＳシステムは次のような問題点が存在する。システム構造が複雑すぎるため、呼シグナリング処理フローの中間過程が多くなり、セッション作成過程の時間も長すぎる。例えば、１回の呼において、発呼加入者から送信された初期発呼要求（Ｉｎｖｉｔｅ）メッセージは、まず、発呼加入者のＰ−ＣＳＣＦに送信されて、Ｐ−ＣＳＣＦによりルーティングされて発呼加入者のＳ−ＣＳＣＦに転送され、サービスをトリガーする。次に、着呼ネットワークにより着呼加入者の所在Ｓ−ＣＳＣＦを確定し、Ｉｎｖｉｔｅメッセージが加入者の所在Ｓ−ＣＳＣＦに到着することで、サービスをトリガーする。その後、Ｉｎｖｉｔｅメッセージが着呼加入者の所在するＰ−ＣＳＣＦに送信され、最後に着呼加入者に届けられる。発着側加入者がローミング状態にあれば、呼信号フローは更に複雑となり、ネットワークにおけるシグナリング交換もより多くなり、セッション確立過程の時間遅延も一層長くなってしまう。
【課題を解決するための手段】
【０００４】
本発明に係る実施形態の第一の目的は、接続先セッションコントローラを提供することにより、信号処理フローを簡易化させることにある。
【０００５】
本発明に係る実施形態の第二の目的は、ＩＰマルチメディア・サブシステムを提供することにより、信号処理フローを簡易化させ、ネットワークの複雑度を低下させることにある。
【０００６】
本発明に係る実施形態の第三の目的は、ＩＰマルチメディア・サブシステムがセッション確立方法を提供することにより、セッション確立フローを簡易化させ、セッション確立時間を短縮させ、セッション確立効率を高めることにある。
【０００７】
本発明に係る実施形態の第四の目的は、ＩＰマルチメディア・サブシステムが端末登録方法を提供することにより、端末登録フローを簡易化させ、登録効率を高めることにある。
【０００８】
本発明は、いくつかの実施形態によりローカルセッションコントローラを提供し、メッセージ受信モジュール、セッション制御モジュール、サービストリガー配置モジュール及びメッセージ送信モジュールを含み、メッセージ受信モジュールは加入者からの発呼要求メッセージ及び応答メッセージを受信し、或いはネットワーク設備からの発呼要求メッセージ及び応答メッセージを受信し、サービストリガー配置モジュールはトリガー情報を配置（記憶）し、セッション制御モジュールは前記サービストリガー配置モジュールから配置（提供）されたトリガー情報により、前記発呼要求メッセージ又は応答メッセージがアプリケーションサーバのトリガー条件を満たしたと確定した場合、対応するアプリケーションサーバのトリガーメッセージを送信する指示を生成してセッションを確立・維持・解放し、ここで、セッション確立過程において、発呼要求メッセージを直接に着呼加入者の所在する接続先セッションコントローラ又は対応するブレークアウトゲートウェイ制御機能モジュールに転送する指示を生成し、前記メッセージ送信モジュールは前記セッション制御モジュールの指示によりメッセージを送信する。
【０００９】
上述技術案において、サービストリガー配置モジュールとセッション制御モジュールにより、加入者より送信された発呼要求メッセージを直接に着呼加入者の所属するローカルセッションコントローラに送信でき、着呼加入者及び発呼加入者が同じ接続先セッションコントローラに所属している場合、発着側加入者間の信号フローは１つだけの接続先セッションコントローラを経由すれば、発着呼側に届けられるため、信号処理フローを簡易化させ、発呼要求メッセージの処理効率を高めるようになる。
【００１０】
他方、本発明は、幾つかの実施形態によりＩＰマルチメディア・サブシステムを提供し、前記接続先セッションコントローラ、網全体ホーム加入者サービスシステムを含み、前記網全体ホーム加入者サービスシステムは前記接続先セッションコントローラと相互接続され、前記接続先セッションコントローラが検索できるように前記接続先セッションコントローラの加入者情報及びインデックスを記憶しておく。
【００１１】
上述技術案において、接続先セッションコントローラにより、ＩＰマルチメディア・サブシステムは加入者から送信された要求メッセージを直接に処理できるようになり、又は対応するアプリケーションサーバにトリガーできるようになるため、シグナリング処理フローを簡易化させ、シグナリング処理効率を高め、同時に、網全体ホーム加入者サービスシステムを採用することにより、ＩＰマルチメディア・サブシステム・ネットワークを大幅に簡易化させる。
【００１２】
また、本発明は、幾つかの実施形態により、以下のＩＰマルチメディア・サブシステムにおけるセッション確立方法を提供する：ＩＰマルチメディア・サブシステムにおける接続先セッションコントローラは発呼要求メッセージを受信し、前記接続先セッションコントローラは配置されたトリガー情報により、前記発呼要求メッセージがアプリケーションサーバのトリガー条件を満たしたと確定した場合、対応するアプリケーションサーバをトリガーし、前記接続先セッションコントローラは前記対応するアプリケーションサーバから返されたメッセージによりセッションを確立する。
【００１３】
上述技術案において、接続先セッションコントローラにより、加入者から送信された発呼要求メッセージを直接にルーティングして着呼加入者の所属する接続先セッションコントローラに転送し、着呼加入者、アプリケーションサーバ及び発呼加入者が同じ接続先セッションコントローラに所属している場合、発着呼加入者間のシグナリングフローは１つだけの接続先セッションコントローラの処理を経由すれば、発着側に届けられ、対応される操作を実行できるため、発呼要求メッセージの複数回の転送を回避し、セッション確立フローを簡易化させ、セッション確立効率を高める。
【００１４】
更に、本発明は、幾つかの実施形態によりＩＰマルチメディア・サブシステムにおける端末登録方法を提供し、本方法は具体的に、
ＩＰマルチメディア・サブシステムにおける接続先セッションコントローラは加入者端末から送信された登録要求メッセージを受信後、網全体ホーム加入者サービスシステムに対してマルチメディア認証要求メッセージを送信し、
前記網全体ホーム加入者サービスシステムは前記接続先セッションコントローラに対して前記登録要求メッセージを送信した加入者の認証条件を返し、
前記接続先セッションコントローラは前記加入者端末より加入者の認証情報を取得し、前記認証情報が前記認証条件を満たすと確定した場合、前記網全体ホーム加入者サービスシステムに対してサーバ割当要求メッセージを送信し、前記網全体ホーム加入者サービスシステムから返されたサーバ割当応答メッセージ及び前記加入者の関連データを受信後、前記加入者に対して登録成功メッセージを返し、前記認証情報が前記認証条件を満たしていないと確定した場合、前記加入者に対して登録失敗メッセージを送信する、
ことを含む。
【発明の効果】
【００１５】
上述技術案において、接続先セッションコントローラが直接に加入者から送信された登録要求メッセージにより、網全体ホーム加入者サービスシステムに対して認証情報を要求することで、登録要求メッセージの複数回の転送を回避し、登録フローを簡易化させ、登録効率を高める。
【００１６】
以下、本発明に係る実施形態を図面に基づいて説明する。
【図面の簡単な説明】
【００１７】
【図１】本発明に係る接続先セッションコントローラの第一の実施形態における構造イメージを示す図である。
【図２】本発明に係る接続先セッションコントローラの第二の実施形態における構造イメージを示す図である。
【図３】本発明に係るＩＰマルチメディア・サブシステムの実施形態における構造イメージを示す図である。
【図４】図３に基づいたＩＰマルチメディア・サブシステムネットワークの構造イメージを示す図である。
【図５】本発明に係るＩＰマルチメディア・サブシステムの端末登録方法の実施形態のフロー図である。
【図６】図５に対応するシグナリングフロー図である。
【図７】本発明に係るＩＰマルチメディア・サブシステムがセッションを確立する方法の第一実施形態のフロー図である。
【図８】図７に対応する信号フロー図である。
【図９】本発明に係るＩＰマルチメディア・サブシステムがセッションを確立する方法の第二実施形態のフロー図である。
【図１０】図９に対応するシグナリングフロー図である。
【図１１】本発明に係るＩＰマルチメディア・サブシステムがセッションを確立する方法の第三実施形態のフロー図である。
【図１２】図１１に対応するシグナリングフロー図である。
【図１３】本発明に係るＩＰマルチメディア・サブシステムがセッションを確立する方法の第四実施形態のフロー図である。
【図１４】本発明に係るＩＰマルチメディア・サブシステムのセッション確立方法におけるセッション解放の実施形態のフロー図である。
【図１５】図１４に対応するシグナリングフロー図である。
【図１６】従来技術におけるＩＭＳ網の構造イメージを示す図である。
【図１７】従来技術におけるＩＰマルチメディア・サブシステムの構造イメージを示す図である。
【発明を実施するための形態】
【００１８】
＜コントローラの第一の実施形態＞
図１は本発明に係る接続先セッションコントローラの第一実施形態の構造イメージを示す図である。接続先セッションコントローラはメッセージ受信モジュール０６１、登録制御モジュール０６２、サービストリガー配置モジュール０６３、セッション制御モジュール０６４とメッセージ送信モジュール０６５を含む。このうち、メッセージ受信モジュール０６１は加入者端末からの登録要求メッセージ、発呼要求メッセージ及び応答メッセージを受信し、又はネットワーク設備（例えば、アプリケーションサーバ）からの発呼要求メッセージ及び応答メッセージを受信する。加入者端末から送信されたメッセージは従来のＰ−ＣＳＣＦ又はＩ−ＣＳＣＦを介して転送される必要がなく、直接に接続先セッションコントローラに送信できるようになっている。
【００１９】
登録制御モジュール０６２は加入者の登録過程を制御し、具体的には、登録過程において、登録制御モジュール０６２はメッセージ受信モジュール０６１より登録要求メッセージを受信後、網全体ホーム加入者サービスシステムに対して加入者端末の認証情報を要求し、網全体ホーム加入者サービスシステムより取得された認証情報により、当該加入者が認証に成功したか否かを判断し、登録状態（登録成功したか否か等）の情報を網全体ホーム加入者サービスシステムに報告し、後続過程において、加入者の登録状態情報を維持する。そのようにすることにより、網全体ホーム加入者サービスシステムは接続先セッションコントローラが加入者端末の登録過程を直接に制御できることを確保させる。
【００２０】
サービストリガー配置モジュール０６３はトリガー情報（例えば、着信番号とそれに対応するアプリケーションサーバのＵＲＩとの対応関係テーブル等）を記憶・配置する。
【００２１】
セッション制御モジュール０６４は発呼要求メッセージ又は応答メッセージをサービストリガー配置モジュール０６３に記憶されたトリガー情報と比較して、トリガー条件を満たすか否かを判断する。例えば、サービストリガー配置モジュール０６３には、発呼要求メッセージに含まれた着信番号が記憶されているか否かを判断する。トリガー条件を満たしたと確定した場合、セッション制御モジュール０６４は着信番号に対応するＵＲＩに接続され、対応するアプリケーションサーバをトリガーする。このため、アプリケーションサーバをトリガーする前に発呼要求メッセージをＰ−ＣＳＣＦからＳ−ＣＳＣＦに、更に発呼要求メッセージをＰ−ＣＳＣＦからＩ−ＣＳＣＦに、又Ｓ−ＣＳＣＦへという複数回の転送を回避し、発呼要求メッセージの処理フローを大幅に簡易化させ、発呼要求の処理効率を高める。セッション制御モジュール０６４は又、メッセージ受信モジュール０６１から受信された発呼要求メッセージにより、セッションテーブルを作成・維持し、セッション終了後にセッションを解放するが、関連する処理フローは従来の技術に類似しているが、ただ本発明においては、接続先セッションコントローラにより処理する。発呼要求メッセージがトリガー条件を満たしていないと確定した場合、又はセッション制御モジュール０６４はアプリケーションサーバをトリガーした後、アプリケーションサーバが通話権限を持たない加入者（例えば、前払いサービスを契約して、残金不足になった加入者）であることを示すメッセージを返した場合、セッション制御モジュールはセッション確立を拒否する。上述セッション制御モジュール０６４は対応するアプリケーションサーバをトリガーするか又はセッション確立を拒否する過程は、まず、セッション制御モジュール０６４により対応するメッセージ（例えば、発呼要求メッセージ・呼応答メッセージ・セッション確立拒否メッセージ）を送信する指示を生成し、メッセージ送信モジュール０６５によりメッセージを送信することを含む。なお、セッション制御モジュール０６４はセッション確立過程において、発呼要求メッセージを直接にルーティングして着呼加入者の所在する接続先セッションコントローラ又は対応するブレークアウトゲートウェイ制御機能モジュールに転送させる指示を生成し、メッセージ送信モジュール０６５によりセッション制御モジュール０６４の指示を実行し、発呼要求メッセージを送信する。メッセージ受信モジュール０６１とメッセージ送信モジュール０６５は１つに統合できる。その場合、前記発呼要求メッセージは、前記登録制御モジュール０６２が認証成功と判断された加入者より発せられても良いし、ネットワーク側の設備より発せられても良い。又はネットワーク側の組織ポリシーに従い、認証されていない加入者により発せられても良いが、その場合、登録なしに１１０等の緊急番号を利用できるように登録制御モジュール０６２を設置しないことにする。セッション完了後、セッション制御モジュール０６４はセッション解放要求メッセージを処理してセッションを解放する。そのうち、網全体ホーム加入者サービスシステムの詳細はＩＰマルチメディア・サブシステムの実施形態における記述を参照されたい。
【００２２】
＜コントローラの第二の実施形態＞
図２は本発明に係る接続先セッションコントローラの第二の実施形態の構造イメージを示す図であり、上述の第一の実施形態を元にして、接続先セッションコントローラは更にルーティングモジュール０６６を含む。ルーティングモジュール０６６は発呼要求メッセージに含まれた加入者標識により、網全体ホーム加入者サービスシステムとそれに対応するドメインネームサービスを提供するサーバ（ＤＮＳサーバと略称）を検索し、関連するルーティングポリシーと重ね合わせて次のホップのメッセージ転送先アドレス情報（例えば、対向側接続先セッションコントローラのアドレス情報、又はＢＧＣＦのアドレス情報）を確定する。セッション制御モジュール０６４はトリガーされたアプリケーションサーバから返送されたメッセージによりセッションを解放し、加入者とアプリケーションサーバとの間のセッションを確立し、又は発呼要求メッセージをルーティングして着呼側に転送する。発呼要求メッセージをルーティングして着呼側に転送する必要がある場合、セッション制御モジュール０６４はルーティングモジュール０６６で見つけたアドレス情報により、直接に前記発呼要求メッセージを着呼側接続先セッションコントローラに転送する。又は、サーバのトリガー条件を満たした場合、継続して、トリガーされたアプリケーションサーバより返送されたメッセージを着呼側接続先セッションコントローラに転送する。これにより、発呼要求メッセージが着呼側呼セッション制御モジュールに送信される前の、発呼側Ｐ−ＣＳＣＦから発呼側Ｓ−ＣＳＣＦへ、更に着呼側Ｓ−ＣＳＣＦへの複数回転送を回避し、ひいては、発呼側Ｐ−ＣＳＣＦから発呼側Ｉ−ＣＳＣＦへ、更に発呼側Ｓ−ＣＳＣＦへ、更に着呼側Ｉ−ＣＳＣＦへ、更に又着呼側Ｓ−ＣＳＣＦへのような複数回転送すらも回避できるため、発呼要求メッセージの処理フローを大幅に簡易化させ、発呼要求メッセージの処理効率を高め、セッション確立時間を短縮させる。
【００２３】
上述実施形態におけるセッション制御モジュール０６４は又、セッションの状態情報を維持することに用いられる。複数の加入者が発呼要求メッセージを発信した場合、セッション制御モジュール０６４は又、加入者の加入者標識により加入者発呼要求メッセージ処理過程で発生した他のメッセージを関連付け、接続先セッションコントローラによる各加入者発呼要求メッセージの正確な処理を確保する。
【００２４】
上述実施形態に基づいた接続先セッションコントローラは又、ＳＩＰメッセージを圧縮するシグナリング圧縮モジュールを含み、信号圧縮モジュールによれば、ネットワークの帯域幅を節約できる。
【００２５】
上述実施形態に基づいた接続先セッションコントローラはまた、発呼要求メッセージにより確立されたセッションに対して料金を計算する料金計算モジュールを含む（例えば、呼の詳細記録（ＣＤＲ）により料金を計算する）。
【００２６】
＜システムの実施形態＞
図３は本発明に係るＩＰマルチメディア・サブシステムの実施形態の構造イメージを示す図であり、ＩＰマルチメディア・サブシステム（ＩＭＳ）００は公衆交換電話網（ＰＳＴＮ１）、ＩＰマルチメディア・サブシステム・ネットワーク又は簡易ＩＰマルチメディア・サブシステム・ネットワーク２、既存移動シグナリング網３、端末４、及びアプリケーションサーバ５と接続され、ＩＭＳ００はＭＲＦＰ０１、ＩＭＳ−ＭＧＷ０２、ＭＲＦＣ０３、ＭＧＣＦ０４、ＢＧＣＦ０５、接続先セッションコントローラ（Ａ−ＣＳＣＦ）０６及び網全体ホーム加入者サービスシステム０７を含む。ＭＲＦＣ０３はＡ−ＣＳＣＦ０６の情報を解析し、対応する操作（例えば、リソースの要求・解放・変更）を実行する。ＭＧＣＦ０４は着信番号と発信側の関連情報によりＡ−ＣＳＣＦ０６を選択し、ＰＳＴＮ１とＩＭＳ００との間の呼制御プロトコルの変換を完成する。ＢＧＣＦ０５はＡ−ＣＳＣＦ０６からの発呼要求により適当なＰＳＴＮ１インターフェースポイント又はＣＳドメインのインターフェースポイントを選択し、発呼要求をルーティングしてＰＳＴＮ１又はＣＳドメインのインターフェースと接続されているネットワークに送信し、又は、他のＩＭＳ網或いは本発明に係るＩＭＳシステムにより構成された簡易ＩＭＳ網２に転送する。Ａ−ＣＳＣＦ０６は端末４からの発呼要求をルーティングして対応するネットワーク要素に転送し、発呼要求がトリガー条件を満たしたと確定した場合、対応するアプリケーションサーバ５をトリガーし、発呼要求をルーティングして当該アプリケーションサーバ５に転送する。また、Ａ−ＣＳＣＦ０６は端末４から送信された登録要求により、網全体ホーム加入者サービスシステム０７から認証情報を取得し、端末４の正当性を認証し、即ち、端末４が認証に成功したか否かを判断する。Ａ−ＣＳＣＦ０６は上述コントローラの実施形態で提供されたＡ−ＣＳＣＦにより実現できる。網全体ホーム加入者サービスシステム０７はデータとインデックスを分離した方式を採用して網全体加入者情報（例えば、加入者の認証情報、接続されたＡ−ＣＳＣＦの情報、サービス情報、及びそれらの情報データに対応するインデックス等）を保存できるため、保存されたデータ容量は任意に拡張でき、網全体加入者情報データの保存要求を満足させる。ＵＴＳＴＡＲＣＯＭ社のＭＭＨＬＲサーバ、Ｏｒａｃｌｅ社の大型分散型データベース等の製品も、網全体ホーム加入者サービスシステム０７の構築に用いられる。Ａ−ＣＳＣＦと網全体ホーム加入者サービスシステムを利用することは、ＩＰマルチメディア・サブシステムを大幅に簡易化させる。
【００２７】
上述システムの実施形態より構成されたＩＭＳ網も大きく簡易化される。図４に示すように、分散型コンピュータ技術を採用して統一化された網全体ホーム加入者サービスシステム０７を構築することにより、ホーム領域とローミング先領域を区別する必要性が無くなり、各領域におけるセッション制御機能は統一されたＡ−ＣＳＣＦ０６実体により実現できる。
【００２８】
＜登録方法の実施形態＞
加入者端末は契約サービスを利用する場合、まず登録により利用権限を取得する必要があり、即ち、Ａ−ＣＳＣＦが加入者から送信された発呼要求メッセージがアプリケーションサーバのトリガー条件を満たすか否かを判断する前に、当該加入者に対して登録を行う必要があり、具体的には図５に示す通りである。図５は本発明に係るＩＰマルチメディア・サブシステムにおける端末登録方法の実施形態のフロー図であり、図６は図５に対応するシグナリングフロー図である。ある端末が加入者アクセス網（ＩＰ  ＣＡＮ）に接続し、動的配置プロトコル（ＤＨＣＰ）とＤＮＳ検索メカニズムにより割り当てられたＡ−ＣＳＣＦを取得した後、当該割り当てられたＡ−ＣＳＣＦに対して、割り当てられたＡ−ＣＳＣＦのＩＤ情報を含む登録要求メッセージ（Ｒｅｇｉｓｔｅｒ）を発信すると、ＩＭＳが行う当該端末登録は以下のステップを含む。
【００２９】
ステップ１０１：Ａ−ＣＳＣＦは「Ｒｅｇｉｓｔｅｒ」メッセージ１０１'を受信後、直接に網全体ホーム加入者サービスシステムに対してマルチメディア認証要求（ＭＡＲ）メッセージ１０２’を送信し、網全体ホーム加入者サービスシステムに対して登録を要求した加入者端末に関連する認証情報を要求することで、Ｒｅｇｉｓｔｅｒメッセージの処理フローを大幅に簡易化させる。
【００３０】
ステップ１０２：網全体ホーム加入者サービスシステムは当該加入者端末の認証情報を含むマルチメディア認証応答（ＭＡＡ）メッセージ１０３'をＡ−ＣＳＣＦに返送する。
【００３１】
ステップ１０３：Ａ−ＣＳＣＦは受信された加入者端末の認証情報により、端末に認証失敗（４０１）メッセージ１０４'を送信し、端末に再認証を指示する。
【００３２】
ステップ１０４：Ａ−ＣＳＣＦは端末より再度ネットワーク側に対して送信された端末自身に記憶された認証情報を含む「Ｒｅｇｉｓｔｅｒ」メッセージ１０５'を受信し、当該加入者端末より送信された認証情報が網全体ホーム加入者サービスシステムより送信された認証情報にマッチするか否かを判断して、当該加入者端末の認証成否を確定する。加入者端末が認証成功した場合、ステップ１０５を実行し、失敗した場合、ステップ１０８を実行する。
【００３３】
ステップ１０５：Ａ−ＣＳＣＦは網全体ホーム加入者サービスシステムに対してサーバ割当要求（ＳＡＲ）メッセージ１０６'を送信し、当該Ａ−ＣＳＣＦ自身のＩＤ情報を網全体ホーム加入者サービスシステムに記憶することを要求する。その後に他のＡ−ＣＳＣＦ又は当該Ａ−ＣＳＣＦが該加入者端末を着呼側とした発呼要求メッセージを受信した場合、ＨＳＳを検索すれば、当該ＩＤ情報により当該加入者にサービスを提供するＡ−ＣＳＣＦを見つけることができ、発呼要求メッセージをルーティングして当該ＩＤ情報に対応するＡ−ＣＳＣＦに転送して呼を継続することができる。
【００３４】
ステップ１０６：網全体ホーム加入者サービスシステムはＡ−ＣＳＣＦに対してサーバ割当応答（ＳＡＡ）メッセージ１０７'を返送し、Ａ−ＣＳＣＦの要求を受け、且つ当該加入者端末に関連するサービスデータを返送する。
【００３５】
ステップ１０７：Ａ−ＣＳＣＦは端末に対して登録成功メッセージ（２００  ＯＫ）１０８’を返し、端末登録は成功する。
【００３６】
ステップ１０８：Ａ−ＣＳＣＦは端末に対して登録失敗（４０３）メッセージを送信する。
【００３７】
本実施形態はアクセス網において直接に加入者端末に対してＡ−ＣＳＣＦを割り当て、加入者端末からの登録要求メッセージを受信することにより、登録要求メッセージをＰ−ＣＳＣＦ、Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦの間で複数回に転送することを回避し、加入者端末が登録要求メッセージを送信後に直接にＡ−ＣＳＣＦを介して網全体ＨＳＳに対してマルチメディア認証要求を送信できるようになるため、登録フローを大幅に簡易化させ、登録効率を高める。
【００３８】
加入者は登録成功した後、契約されたサービスを利用できるようになり、本発明に係る実施形態より提供されたＩＭＳシステムによりセッションを確立できるようになる。
【００３９】
＜セッション確立方法の第一の実施形態＞
図７は本発明に係るＩＰマルチメディア・サブシステムのセッション確立方法の第一実施形態のフロー図であり、図８は図７に対応するシグナリングフローである。ある加入者端末が上述システムの実施形態より提供された任意のＩＭＳに対して会議確立要求を発起することを想定し、その際に会議形態はまだ確立されていないため、初期発呼要求（Ｉｎｖｉｔｅ）メッセージ２０１'においては会議場（Ｃｏｎｆｅｒｅｎｃｅ  ｆａｃｔｏｒｙ）の統一資源識別子（ＵＲＩ）を利用することになる。ＩＭＳのセッション確立過程は次のようなステップを含む。
【００４０】
ステップ２０１：ＩＭＳにおけるＡ−ＣＳＣＦは「Ｉｎｖｉｔｅ」メッセージ２０１'を受信後、当該「Ｉｎｖｉｔｅ」メッセージ２０１'がＡＳのトリガー条件を満たすか否かを判断し、トリガー条件を満たす場合、ステップ２０２を実行し、満たさない場合はステップ２１０を実行する。
【００４１】
ステップ２０２：Ａ−ＣＳＣＦは初期フィルター基準（ｉＦＣ：ｉｎｉｔｉａｌ  ｆｉｌｔｅｒ  ｃｒｉｔｅｒｉａ）により「Ｉｎｖｉｔｅ」メッセージ２０１'をＡＳに送信してＡＳをトリガーする。加入者端末は会議を要求する際に会議場のＵＲＩを利用したため、ＡＳは「Ｉｎｖｉｔｅ」メッセージ２０１'を受信後に会議実施形態のＵＲＩを割り当て始め、又、会議において利用可能なセッション記述プロトコル情報（ＳＤＰ）を仮の応答ｓｅｓｓｉｏｎ  ｐｒｏｇｒｅｓｓ（１８３）メッセージ２０２'によりＡ−ＣＳＣＦに送信し、同時にＭＲＦＰにおいて会議の接続リソースを作成する。
【００４２】
ステップ２０３：Ａ−ＣＳＣＦは「１８３」メッセージ２０２'を加入者端末に転送し、加入者端末は「１８３」メッセージ２０２'を受信後に加入者より確定されたＳＤＰ情報を臨時応答（Ｐｒａｃｋ）メッセージ２０３'によりＡ−ＣＳＣＦに送信し、ローカルリソース要求を始める。
【００４３】
ステップ２０４：Ａ−ＣＳＣＦは「Ｐｒａｃｋ」メッセージ２０３’をＡＳに転送し、ＡＳは加入者端末からの「Ｐｒａｃｋ」メッセージ２０３'を応答し、Ａ−ＣＳＣＦに対して応答（２００  ＯＫ）メッセージ２０４'を送信し、当該情報にはＳＤＰ情報を含んでも良い。
【００４４】
ステップ２０５：Ａ−ＣＳＣＦは「２００  ＯＫ」メッセージ２０４'を加入者端末に転送し、加入者端末はＳＤＰ情報を更新し、更新後のＳＤＰを更新（Ｕｐｄａｔｅ）メッセージ２０５'によりＡ−ＣＳＣＦに送信する。
【００４５】
ステップ２０６：Ａ−ＣＳＣＦは「Ｕｐｄａｔｅ」メッセージ２０５'をＡＳに転送し、ＡＳはＡ−ＣＳＣＦに対して「Ｕｐｄａｔｅ」メッセージ２０５'に応答するための「２００  ＯＫ」メッセージ２０６'を送信し、同時に、ＭＲＦＰは端末との間のメディア接続を開始する。
【００４６】
ステップ２０７：Ａ−ＣＳＣＦは「２００  ＯＫ」メッセージ２０６'を加入者端末に転送する。
【００４７】
ステップ２０８：Ａ−ＣＳＣＦはＡＳより返送された「Ｉｎｖｉｔｅ」メッセージ２０１'の応答メッセージ――「Ｃｏｎｔａｃｔ」ヘッダ部に会議実施形態のＵＲＩが含まれている「２００  ＯＫ」メッセージ２０７'を受信して加入者端末に転送し、加入者端末は会議実施形態のＵＲＩが含まれている「２００  ＯＫ」メッセージ２０７'を受信後に、Ａ−ＣＳＣＦに対して「Ｉｎｖｉｔｅ」を確認するための応答メッセージ（ＡＣＫ）２０８'を送信し、会議の確立成功を確認する。
【００４８】
ステップ２０９：Ａ−ＣＳＣＦは「ＡＣＫ」メッセージ２０８'をＡＳに転送し、今回のセッション確立を完成させる。
【００４９】
ステップ２１０：Ａ−ＣＳＣＦは端末に対して確立拒否又は確立失敗のメッセージを返送する。
【００５０】
本実施形態において、前払いサービスを利用している発呼端末である場合、Ａ−ＣＳＣＦは端末により発起された「Ｉｎｖｉｔｅ」メッセージを受信後、まず、前払いサービスのアプリケーションサーバをトリガーし、前払いサービスアプリケーションサーバから返送されたメッセージにより、当該加入者端末は今回のサービス料金を支払う能力の有無を判断し、支払う能力がある場合、引き続いて「Ｉｎｖｉｔｅ」メッセージが他のアプリケーションサーバのトリガー条件を満たすか否かを判断し、本実施形態のように会議状態作成アプリケーションサーバのトリガー条件も満たしたと判断した場合、引き続いて当該アプリケーションサーバをトリガーする。当該加入者が残金不足になった場合、前払いサービスのアプリケーションサーバはＡ−ＣＳＣＦに対して当該加入者の残金不足メッセージを送信し、Ａ−ＣＳＣＦは当該メッセージにより端末に対してセッション確立拒否のメッセージを送信する。
【００５１】
本実施形態において、Ａ−ＣＳＣＦに加入者端末からの「Ｉｎｖｉｔｅ」メッセージを受信させることにより、ＡＳをトリガーする前に「Ｉｎｖｉｔｅ」メッセージをＰ−ＣＳＣＦ、Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦの間に複数回に転送することを回避し、端末より「Ｉｎｖｉｔｅ」メッセージを送信した後、Ａ−ＣＳＣＦは直接に「Ｉｎｖｉｔｅ」メッセージによりＡＳをトリガーできるようになるため、セッション確立フロー又は呼フローを簡易化させ、セッションの確立時間を短縮させ、セッション確立効率を高める。
【００５２】
＜セッション確立方法の第二の実施形態＞
図９は本発明に係るＩＰマルチメディア・サブシステムがセッションを確立する方法の第二実施形態のフロー図であり、図１０は図９に対応するシグナリングフロー図である。ある端末ＵＥ＿１は上述システムの実施形態より提供された任意のＩＭＳネットワークに対して「Ｉｎｖｉｔｅ」メッセージ３０１'を送信し、他の端末ＵＥ＿２に対して発呼し、ＵＥ＿１は発信者番号通知限制サービスを登録した端末とし、ＵＥ＿２は発信者番号通知サービスを登録した端末とし、ＵＥ＿１に対応するＡ−ＣＳＣＦはＡ−ＣＳＣＦ＿１とし、発信者番号通知制限サービスに対応するアプリケーションサーバはＡＳ＿１とし、ＵＥ＿２に対応するＡ−ＣＳＣＦはＡ−ＣＳＣＦ＿２とし、発信者番号通知サービスに対応するアプリケーションサーバはＡＳ＿２とすると想定した場合、着呼側のＩＭＳネットワークのセッション確立過程は次のステップを含む。
【００５３】
ステップ３０１：Ａ−ＣＳＣＦ＿１は「Ｉｎｖｉｔｅ」メッセージ３０１'を受信後に、「Ｉｎｖｉｔｅ」メッセージ３０１'がＡＳのトリガー条件を満たすか否かを判断し、本実施形態では「Ｉｎｖｉｔｅ」メッセージ３０１'はＡＳ＿１のトリガー条件を満たしたとする。
【００５４】
ステップ３０２：Ａ−ＣＳＣＦ＿１はＡＳ＿１をトリガーし、「Ｉｎｖｉｔｅ」メッセージ３０１'をルーティングしてＡＳ＿１に転送する。ＡＳ＿１は「Ｉｎｖｉｔｅ」メッセージ３０１'を受信後に関連するサービス制御ロジックを実行し、例えば、「Ｉｎｖｉｔｅ」メッセージ３０１'に含まれた「Ｐｒｉｖａｃｙ」ヘッダ部の値を「ｉｄ」に変更し、変更後の「Ｉｎｖｉｔｅ」メッセージ３０２'をＡ−ＣＳＣＦ＿１に送信する。
【００５５】
ステップ３０３：Ａ−ＣＳＣＦ＿１は網全体ホーム加入者サービスシステムに対して位置情報要求（ＬＩＲ）メッセージ３０３'を送信し、ＵＥ＿２の所在するＡ−ＣＳＣＦの位置又はアドレス情報を検索することを要求する。
【００５６】
ステップ３０４：網全体ホーム加入者サービスシステムは、ＵＥ＿２の所在するＡ−ＣＳＣＦ（本実施形態ではＡ−ＣＳＣＦ＿２である）の位置又はアドレス情報を含む位置情報応答メッセージ（ＬＩＡ）３０４'を返送する。
【００５７】
ステップ３０５：Ａ−ＣＳＣＦ＿１はＬＩＡメッセージ３０４'により「Ｉｎｖｉｔｅ」メッセージ３０２'をルーティングしてＡ−ＣＳＣＦ＿２に転送する。
【００５８】
ステップ３０６：Ａ−ＣＳＣＦ＿２は「Ｉｎｖｉｔｅ」メッセージ３０２'がＡＳのトリガー条件を満たすか否かを判断し、本実施形態では「Ｉｎｖｉｔｅ」メッセージ３０２'はＡＳのトリガー条件を満たしたとする。
【００５９】
ステップ３０７：Ａ−ＣＳＣＦ＿２は「Ｉｎｖｉｔｅ」メッセージ３０２'をルーティングしてＡＳ＿２に転送する。ＡＳ＿２はＩｎｖｉｔｅメッセージ３０２'に含まれた「Ｐｒｉｖａｃｙ」の値により、発信者番号は非通知番号であることが分かり、「Ｉｎｖｉｔｅ」メッセージ３０２'に含まれた表示名を「Ａｎｏｎｙｍｏｕｓ」に変更してから、変更された「Ｉｎｖｉｔｅ」メッセージ３０５'をＡ−ＣＳＣＦ＿２に送信する。
【００６０】
ステップ３０８：Ａ−ＣＳＣＦ＿２は変更された「Ｉｎｖｉｔｅ」メッセージ３０５'ルーティングをＵＥ＿２に転送する。
【００６１】
ステップ３０９：Ａ−ＣＳＣＦ＿２はＵＥ＿２とＡＳ＿２の間でサービスニーズ応じて相応の調整・制御操作を行う。例えば、「１８３」メッセージ３０６'、「Ｐｒａｃｋ」メッセージ３０７'及び「２００  ＯＫ」メッセージ３０８'等を転送し、更に「ＡＣＫ」メッセージまで転送してセッション確立を完成させる。
【００６２】
ここで、ＵＥ＿１とＵＥ＿２は同時に１つのＡ−ＣＳＣＦによりサービスを提供される場合、又は同時に１つのＡ−ＣＳＣＦサービス領域に位置している場合、Ａ−ＣＳＣＦ＿１とＡ−ＣＳＣＦ＿２は同一のＡ−ＣＳＣＦになることに注意されたい。
【００６３】
本実施形態において、Ａ−ＣＳＣＦに「Ｉｎｖｉｔｅ」メッセージを受信させることにより、ＡＳをトリガーする前に、「Ｉｎｖｉｔｅ」メッセージを発着側のＰ−ＣＳＣＦ、Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦの間に複数回に転送することを回避し、端末より「Ｉｎｖｉｔｅ」メッセージを送信された後、Ａ−ＣＳＣＦは直接に「Ｉｎｖｉｔｅ」メッセージによりＡＳをトリガーできるようになるため、セッション確立フロー又は呼フローを簡易化させ、セッション確立時間を短縮させ、セッション確立効率を高める。
【００６４】
＜セッション確立方法の第三の実施形態＞
図１１は本発明に係るＩＰマルチメディア・サブシステムがセッションを確立する方法の第三の実施形態のフロー図で、図１２は図１１に対応するシグナリングフロー図である。補充サービスである発信者番号表示の例において、ある端末ＵＥ＿１は上述システム実施形態で提供された任意のＩＭＳに対して「Ｉｎｖｉｔｅ」メッセージ４０１'を送信して他の端末ＵＥ＿２に対して発呼し、ＵＥ＿１に対応するＡ−ＣＳＣＦはＡ−ＣＳＣＦ＿１とし、ＵＥ＿２に対応するＡ−ＣＳＣＦはＡ−ＣＳＣＦ＿２とすることを想定する。この場合に着呼側のＩＭＳネットワークがセッションを確立する過程は次のようなステップを含む。
【００６５】
ステップ４０１：Ａ−ＣＳＣＦ＿１は「Ｉｎｖｉｔｅ」メッセージ４０１'がＡＳのトリガー条件を満たしていないと確定した後、網全体ホーム加入者サービスシステムに対して「ＬＩＲ」メッセージ４０２'を送信し、ＵＥ＿２の所在するＡ−ＣＳＣＦを検索することを要求する。
【００６６】
ステップ４０２：網全体ホーム加入者サービスシステムはＡ−ＣＳＣＦ＿１に対してＵＥ＿２の所在するＡ−ＣＳＣＦ（本実施形態ではＡ−ＣＳＣＦ＿２である）のアドレス情報を含む「ＬＩＡ」メッセージ４０３'を返送する。
【００６７】
ステップ４０３：Ａ−ＣＳＣＦ＿１は網全体ホーム加入者サービスシステムから返送された「ＬＩＡ」メッセージ４０３'により、「Ｉｎｖｉｔｅ」メッセージ４０１'をルーティングしてＡ−ＣＳＣＦ＿２に転送する。
【００６８】
ステップ４０４：Ａ−ＣＳＣＦ＿２は「Ｉｎｖｉｔｅ」メッセージ４０１'がＡＳのトリガー条件を満たすか否かを判断し、本実施形態では「Ｉｎｖｉｔｅ」メッセージ４０１'は発信者番号通知サービスのアプリケーションサーバ（ＡＳ＿２と想定する）のトリガー条件を満たしたとする。
【００６９】
ステップ４０５：Ａ−ＣＳＣＦ＿２はｉＦＣにより「Ｉｎｖｉｔｅ」メッセージ４０１'をルーティングしてＡＳ＿２に転送する。ＡＳ＿２はまず「Ｉｎｖｉｔｅ」メッセージ４０１'に「Ｐｒｉｖａｃｙ」ヘッダ部が含まれているか否かを判断し、含まれていないと、又はその値が「ｉｄ」と「ｕｓｅｒ」ではないと、ＵＥ＿１は発信者番号通知制限（ＣＬＩＲ：Ｃａｌｌｉｎｇ  ｌｉｎｅ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｒｅｓｔｒｉｃｔｉｏｎ）サービスを利用していない端末であることを示し、その際にＡＳ＿２は「Ｉｎｖｉｔｅ」メッセージ４０１'に含まれた「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」ヘッダ部により「Ｉｎｖｉｔｅ」メッセージ４０１'を「Ｉｎｖｉｔｅ」メッセージ４０４'に変更し、ＵＥ＿２に対してＵＥ＿１の加入者番号を通知し、「Ｉｎｖｉｔｅ」メッセージ４０４'をＡ−ＣＳＣＦ＿２に送信する。
【００７０】
ステップ４０６：Ａ−ＣＳＣＦ＿２は「Ｉｎｖｉｔｅ」メッセージ４０４'をルーティングしてＵＥ＿２に転送させ、ＵＥ＿２は「Ｉｎｖｉｔｅ」メッセージ４０４'に含まれた、ＵＥ＿２により変更された後の発呼加入者情報により、ＵＥ＿１の加入者番号を通知する。なお、具体的にどのヘッダ部に含まれた情報を発信者番号にするのかは、異なったネットワークにより確定されることであるため、ここではその説明を省略する。そして、ＡＳ＿２はＡ−ＣＳＣＦ＿２に対して「１８３」メッセージ４０５'を送信する。
【００７１】
ステップ４０７：Ａ−ＣＳＣＦ＿２は「１８３」メッセージ４０５'をＡＳ＿２に転送する。
【００７２】
ステップ４０８：Ａ−ＣＳＣＦ＿２はＵＥ＿２とＡＳ＿２の間でサービスニーズに応じて相応の調整・制御操作を行い、例えば、「Ｐｒａｃｋ」メッセージ、「２００  ＯＫ」メッセージ等を転送し、更に「ＡＣＫ」メッセージまで転送してセッション確立を完成させる。これらの後続のメッセージ処理は従来のＩＭＳ網における基本呼のフロー交換ロジックに類似しているが、ただし、本実施形態における全てのセッション処理は発着側のＡ−ＣＳＣＦにより完成される。
【００７３】
本実施形態において、ＵＥ＿２が前払いサービスを利用し、且つ残金不足になった端末である場合、ＡＳ＿２はＵＥ＿２の残金不足を判断した後、当該情報をＡ−ＣＳＣＦ＿２に通知し、Ａ−ＣＳＣＦ＿２はその際のセッション確立要求を拒否してＵＥ＿２に通知する。
【００７４】
ＵＥ＿２は無応答転送サービス登録をした場合、Ａ−ＣＳＣＦ＿２が「Ｉｎｖｉｔｅ」メッセージ４０１'をルーティングしてＡＳ＿２に転送するステップ４０５を実行後、図１２、１３に示すように次の操作を実行する。
【００７５】
ステップ５０１：Ａ−ＣＳＣＦ＿２は継続して「Ｉｎｖｉｔｅ」メッセージ４０４'が他のアプリケーションサーバのトリガー条件を満たすか否かを判断し、本実施形態の例では「Ｉｎｖｉｔｅ」メッセージに含まれた着信番号は無応答転送無しのアプリケーションサーバ（例えば、ＡＳ＿３）のトリガー条件を満たしたため、Ａ−ＣＳＣＦ＿２は「Ｉｎｖｉｔｅ」メッセージ４０４'を利用してＡＳ＿３をトリガーし、ＡＳ＿３はタイマーを開始すると同時に「Ｉｎｖｉｔｅ」メッセージ４０４'を返送する。
【００７６】
ステップ５０２：Ａ−ＣＳＣＦ＿２はＡＳ＿３より返送された「Ｉｎｖｉｔｅ」メッセージ４０４'をＵＥ＿２に送信し、ＵＥ＿２はリングメッセージ（「１８０」メッセージ）５０１'をＡＳ＿３に返送し、ＡＳ＿３は「１８０」メッセージ５０１'をＡ−ＣＳＣＦ＿２に送信する。
【００７７】
ステップ５０３：Ａ−ＣＳＣＦ＿２はＡ−ＣＳＣＦ＿１により「１８０」メッセージ５０１'をＵＥ＿１に転送し、ＵＥ＿１はリングを鳴らす。ＡＳ＿３はタイマーによりＵＥ＿２が予定時間内で応答したか否かを判断し、予定時間を経過した場合、ＡＳ＿３はＡ−ＣＳＣＦ＿２に対して応答前転送メッセージ（「１８１」メッセージ）５０２'を送信する。
【００７８】
ステップ５０４：Ａ−ＣＳＣＦ＿２はＡ−ＣＳＣＦ＿１により「１８１」メッセージ５０２'をＵＥ＿１に転送し、着呼端末が呼を第三者端末（例えばＵＥ＿３）に転送していることを発呼端末に通知する。
【００７９】
ステップ５０５：Ａ−ＣＳＣＦ＿２はＡＳ＿３より開始された「Ｉｎｖｉｔｅ」メッセージ５０３'を受信し、呼をＵＥ＿３に転送し、具体な処理フローは従来の発呼開始フローに類似する。
【００８０】
上述のような実施形態によりセッションを確立後、セッションが完了した場合、Ａ−ＣＳＣＦはまたセッションを解放できる。着呼端末から解放要求メッセージを開始することを例としたセッション解放過程は、図１４と１５に示すように、次のステップを含む。
【００８１】
ステップ６０１：着呼端末ＵＥ＿２は「ｂｙｅ」要求メッセージ６０１'を送信し、Ａ−ＣＳＣＦ＿２は「ｂｙｅ」要求メッセージ６０１'を受信後に、アプリケーションサーバのトリガー条件を満たすか否かを判断し、ＡＳ＿２のトリガー条件を満たすと、「ｂｙｅ」要求メッセージ６０１'をＡＳ＿２に送信し、ＡＳ＿２は受信された「ｂｙｅ」要求メッセージ６０１'を分析して関連する操作を実行し、処理された「ｂｙｅ」要求メッセージ６０１'をＡ−ＣＳＣＦ＿２に返し、満たさない場合、ステップ６０２を実行する。
【００８２】
ステップ６０２：Ａ−ＣＳＣＦ＿２は「ｂｙｅ」要求メッセージ６０１'をルーティング発呼側Ａ−ＣＳＣＦ＿１に転送する。
【００８３】
ステップ６０３：Ａ−ＣＳＣＦ＿１は「ｂｙｅ」要求メッセージ６０１'がトリガー条件を満たすか否かを判断し、判断結果によりトリガーする。
【００８４】
ステップ６０４：Ａ−ＣＳＣＦ＿１は「ｂｙｅ」要求メッセージ６０１'を発呼側末ＵＥ＿１に送信し、ＵＥ＿１は「２００  ＯＫ」メッセージ６０２'を返す。
【００８５】
ステップ６０５：上述の類似処理を経過した「２００  ＯＫ」メッセージ６０２'はＵＥ＿２に返され、セッション解放は完成する。
【００８６】
セッション解放要求メッセージは又、発呼端末、発呼側Ａ−ＣＳＣＦ、アプリケーションサーバ又は着呼側Ａ−ＣＳＣＦにより開始でき、処理フローは従来のセッション解放フローに類似するが、ただし、本実施形態における全てのセッション解放処理は接続先セッションコントローラにより完成される。
【００８７】
本実施形態では、Ａ−ＣＳＣＦに「Ｉｎｖｉｔｅ」メッセージを受信させることにより、「Ｉｎｖｉｔｅ」メッセージを着呼側ＣＳＣＦに転送する前に、発着呼側Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦの間で複数回転送することを回避する。また、ＡＳをトリガーする前に、「Ｉｎｖｉｔｅ」メッセージを着呼側Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ及びＩ−ＣＳＣＦの間で複数回転送することも回避し、端末より送信された「Ｉｎｖｉｔｅ」メッセージが発呼側Ａ−ＣＳＣＦにより直接にルーティングされて着呼側Ａ−ＣＳＣＦに転送するようにできる。また、着呼側Ａ−ＣＳＣＦは「Ｉｎｖｉｔｅ」メッセージによりＡＳをトリガーするため、セッション確立フロー又は呼フローを大幅に簡易化させ、セッション確立時間を短縮させ、セッション確立効率を高める。
【００８８】
最後に注意するべきことは、前記実施例は本発明の技術的な解決手段の説明のみであり、技術上の制限とはならない。本明細書では上述した実施例を参照し本発明を詳しく解説したが、当業者により、上述した技術的な解決手段を改造し、またはその中の一部の技術要素を置換することもできる。そのような改造と置換は本発明の各実施例の技術の範囲から逸脱するとは見なされない。
【図１】
2010536279.tif 000003
【図２】
2010536279.tif 000004
【図３】
2010536279.tif 000005
【図４】
2010536279.tif 000006
【図５】
2010536279.tif 000007
【図６】
2010536279.tif 000008
【図７】
2010536279.tif 000009
【図８】
2010536279.tif 000010
【図９】
2010536279.tif 000011
【図１０】
2010536279.tif 000012
【図１１】
2010536279.tif 000013
【図１２】
2010536279.tif 000014
【図１３】
2010536279.tif 000015
【図１４】
2010536279.tif 000016
【図１５】
2010536279.tif 000017
【図１６】
2010536279.tif 000018
【図１７】
2010536279.tif 000019
【国際調査報告】
2010536279.tif 000020
2010536279.tif 000021
2010536279.tif 000022
2010536279.tif 000023
2010536279.tif 000024
2010536279.tif 000025