JP2010532131A - 着信された音声／ビデオ呼のためのｕｅ接近ドメイン選択方法 - Google Patents

Abstract

本発明は、移動通信ネットワークにおける移動局において、音声及び／またはビデオ呼を受信するための接近ドメインを選択する方法を提供するためのものであり、ここで呼は複数の接近ドメインに共通的な中央サービス制御部を通じてルーティングされる。本発明の方法は、上記中央サービス制御部が着信移動局に呼を設定するための招請メッセージを送信するステップと、上記移動局がローカル接続ネットワークの容量を考慮した上記呼を受信するために接近ドメインを決定し、上記中心サービス制御部に上記選択された接近ドメインを転送するステップと、上記選択された接近ドメインに従い上記呼を設定するステップとを含む。

Description

本発明は、回線−交換（Circuit Switched；ＣＳ）ドメインまたはパケット−交換（Packet Switched；ＰＳ）ドメインのうち、いずれか１つを通じて音声／ビデオ呼を提供する移動通信システムに関し、特にデュアルモードＣＳ／ＩＰマルチメディアシステム（IP Multimedia System；ＩＭＳ）に関するものであるが、これに限定されるのではない。

デュアルモードＣＳ／ＩＭＳシステムにおいて、ＶｏＩＰ（Voice over IP）呼のような音声／ビデオ呼はＣＳドメインまたはＩＭＳを通じて提供可能である。以前のＣＳと新たなＩＭＳ核心ネットワーク全てを維持管理し、アップデートする必要を回避するために、多くの会社は音声／ビデオ関連サービスをＩＭＳ核心ネットワークのみで集中化することに注目している。しかしながら、例えば全てのＩＰ−ＣＡＮｓ（IP Connectivity Access Networks）はＶｏＩＰサービスにより要求されるサービス品質をサポートできず、これによってＶｏＩＰ−可能ＩＰ−ＣＡＮｓは利用可能でない集中化したサービスに対する接近を可能にするために、第３世代パートナーシッププロジェクト（３ＧＰＰ）は端末機がＣＳドメインに接続されるようにし、ＩＭＳにより提供される接続サービスを使用するようにする手段を定義している。これは、ＩＭＳ集中化サービス制御または“ＩＣＳ（IMS Centralized Service）”として知られている。

デュアルモードネットワークで動作するデュアルモード端末機の場合に発生する問題点のうちの１つは、音声呼のためのドメイン選択にある。モバイル発信（Mobile Originating）呼の場合に、例えば、セルラー電話機などの呼を発信したユーザ装置（ＵＥ）がＶｏＩＰをサポートする接続ネットワークの容量（capability）を知っている場合に、どのドメインで呼を開始するかを選択することが比較的容易である。さらに、現在提案されたＩＣＳソリューションの限界内で、ＵＥはＩＣＳを利用するためにＣＳベアラ設定と同時にＰＳ基盤シグナリングチャンネルを通じたセッション開始プロトコル（Session Initiation Protocol；ＳＩＰ）を使用するか、またはＵＳＳＤを通じた（または、ＣＡＭＥＬトリガリングに依存した）ＩＭＳ ＣＳ制御プロトコル（IMS CS Control Protocol；ＩＣＣＰ）を使用するか否かを決定できる。

ＩＣＳにおいて、端末機はＩＭＳで遠隔ユーザエージェント（Remote User Agent；ＲＵＡ）で表示されることによって、ＩＰ−ＣＡＮが存在しないとか、使用可能なＩＰ／ＣＡＮが音声／ビデオをサポートできない場合にも、端末機が音声／ビデオサービスのためにＩＰ−ＣＡＮを通じて接続されているようにみられる。

現在定義されたＩＣＳソリューションは２つの可能なシナリオを考慮する。
１．利用可能なＩＰ−ＣＡＮがないとか、即ちＰＳドメインカバレッジがないとか、またはＣＳと同時にＰＳを通じて送信し受信することが不可能である。
２．ＣＳと同時に使用可能なＩＰ−ＣＡＮカバレッジがあるが、ＩＰ−ＣＡＮは音声やビデオ（例えば、ＶｏＩＰ）をサポートしない。
第１のシナリオで、現在のＩＣＳソリューションによれば、端末機からのＣＳ呼は下記のように提案する。
ａ．集中化されたサービス提供のためにＣＡＭＥＬトリガを用いてＩＭＳに再ルーティングされる。
ｂ．関連ＳＩＰセッションパラメータがＵＳＳＤを通じたＩＣＣＰを通じてＩＣＣＦに送信されるネットワークで直接的にＩＭＳ ＣＳ制御機能（IMS CS Control Function；ＩＣＣＦ）に設定される。

第２のシナリオで、現在のＩＣＳソリューションによれば、標準SIP INVITEが呼出し相手方に送信され、サービング呼セッション制御機能（serving-Call Session Control Function；Ｓ−ＣＳＣＦ）での初期フィルタ条件（initial Filter Criteria；ｉＦＣ）処理によってＩＣＣＦを通じてルーティングされる。以後、端末機は標準ＣＳ呼制御を用いてＩＣＣＦへのＣＳベアラを設定する。

両シナリオの場合に、ＩＣＣＦはＣＳベアラとＵＳＳＤを通じて、またはSIP INVITEで受信された情報を相関し、ＩＭＳを通じて呼出し相手方へのセッションを設定する。以後、発信端末機は当該呼に対するＩＭＳでのサービスを制御し構成するために（接続ネットワークの容量に依存して）ＳＩＰシグナリングやＵＳＳＤを使用することができる。

前述したように、端末機はどのようにＭＯ呼を設定するか及びどの接近ドメインを通じてＭＯ呼を設定するかを決定する。しかしながら、モバイル着信（ＭＴ）呼の場合に問題が発生する。現在のソリューションによれば、（例えば、発信端末機の助けにより）ＩＣＣＦのドメイン選択機能は、モバイル着信のためにどの接続ネットワークを介して電話呼をルーティングするかを決定する。これによれば、ＩＣＣＦは着信端末機が現在位置したローカル接続ネットワーク及びＩＰ−ＣＡＮの容量がある程度分かり、これに対してアップデートされることによって、端末機に接続するためにＵＳＳＤまたはＰＳを通じたＳＩＰを使用するか否かを決定するように要求される。ＩＣＣＦがどのようにこれに対して分かるかは明らかでないが、このような決定を容易にするように、端末機がローカル接続ネットワークの容量（capability）に関する情報をＩＣＣＦに送信可能なことと提案された。（例えば、本願でその全体内容が参照文献として含まれた英国特許出願第０６０１００７．８号を参照すれば、）ネットワークがＶｏＩＰ容量表示を端末機に提供してＭＯ接近ドメイン選択を助けるように提案された。ＳＡ２に対する寄稿文（例えば、ＮＳＮ論文Ｓ２−０７２４５９）は、端末機が現在の接近ドメインのＶｏＩＰ容量をＩＣＣＦに送信してネットワークが着信ドメインを選択することを助けるように提案した。

図１は、ＩＣＳでの既存の着信呼ドメイン選択機能の一例を示す。この場合に、ＩＭＳは接続ネットワークのＶｏＩＰと同時的なＣＳ／ＰＳ容量に対して知っており、アップデートされなければならず、これによってどのドメインを通じて呼着信を試みるのか、及びこのような着信呼をどのように端末機にシグナリングするのかを決定する。これは端末機がネットワーク内で移動する時に情報がアップデートされなければならないので、ネットワークと端末機との間の相当な余分のシグナリングオーバーヘッドをもたらすことがある。

図１に示すように、Ｓ１で呼通知の到達の以後に、ＩＣＣＦはＳ３で着信端末機がＩＭＳ登録されたかを確認する。着信端末機がＩＭＳ登録された場合に、ＩＣＣＦはＳ５で着信端末機が現在ＶｏＩＰをサポートする接続ネットワークにあるかをチェックする。仮に、そのような場合に、ＩＣＣＦはＳ７でＶｏＩＰ呼が設定されることを表示するSIP INVITEを、ＰＳドメインを通じて着信端末機に送信する。SIP INVITEを受信すると共に、着信端末機はＳ９でＳＩＰ １８ｘメッセージと後の正常なＩＭＳセッションを用いて応答する。

着信端末機がＩＭＳ登録されたがＶｏＩＰをサポートしない接続ネットワークに位置した場合に、Ｓ１１でＩＣＣＦは着信端末機が同時的なＰＳ及びＣＳ通信をサポートする接続ネットワークに位置しているか否かをチェックする。仮に、そのような場合に、Ｓ１３でＩＣＣＦはＰＳドメインを通じてSIP INVITEを着信端末機に送信するが、SIP INVITEはＰＳ制御チャンネルとメディアに対するＣＳベアラを用いて呼が設定されることを表示する。上記SIP INVITEの受信以後に、Ｓ１５で着信端末機はＳＩＰを用いてＰＳドメインを通じて応答し、メディア転送のためにＩＣＣＦへのＣＳベアラを設定する。以後、Ｓ１７でサービスの制御と構成のためにＳＩＰとメディアに対するＣＳベアラを用いてＰＳドメインを通じてＩＭＳセッションが引き続く。

仮に、着信端末機がＩＭＳ登録されていないか、または着信端末機がＩＭＳ登録されたが同時にＰＳとＣＳとが受信できない場合に、Ｓ１９でＩＣＣＦは端末機がＣＳドメインを通じてＩＭＳを受信するように登録されたか否かをチェックする。仮に、そのような場合に、Ｓ２１でＩＣＣＦは着信呼通知を、ＵＳＳＤを通じて着信端末機に送信する。上記着信呼通知を受信すると共に、Ｓ２３で着信端末機はＵＳＳＤを用いてＣＳドメインを通じて応答し、メディア転送のためにＩＣＣＦへのＣＳベアラを設定する。以後、Ｓ２５で、サービスの制御及び構成のためにＩＣＣＰとのメディアに対するＣＳベアラを用いてＵＳＳＤを通じたＩＭＳセッションが続く。

仮に、端末機がＩＭＳサービスを受信するように登録されていない場合に、Ｓ２７でＩＣＣＦは端末機が正常なＣＳを受信するように登録されたか否かをチェックする。仮に、そのような場合に、Ｓ２９でＩＣＣＦは端末機への標準ＣＳ呼としてセッションを完了する。仮に、そうでない場合に、Ｓ３１でＩＣＣＦは呼が完了できないと決定する。

前述したように、既存のソリューションは、例えば、ＶｏＩＰを通じてリアルタイム対話形音声／ビデオをサポートするようにサービングＩＰ−ＣＡＮの容量に関して知るためにＩＭＳネットワークでＩＣＣＦを要求する。また、これはＩＭＳに同時的なＣＳ及びＰＳベアラをサポートするようにローカル接続ネットワークの容量に関して知っているように要求する。これは、ＵＥとＩＭＳとの間の、またはＩＰ−ＣＡＮとＩＭＳとの間の付加的なシグナリングを要求する。

本発明の一態様によれば、移動通信ネットワークの移動局で音声及び／またはビデオ呼を受信するための接近ドメインを選択する方法において、上記移動通信ネットワークで呼は複数の接近ドメインに共通的な中央サービス制御部を通じてルーティングされ、上記の方法はローカル接続ネットワークの容量を考慮して上記移動局が呼を処理する接近ドメインを決定するステップ及び上記中心サービス制御部で上記選択された接近ドメインを表示するステップを含む。

本発明によれば、ＩＰ−ＣＡＮが利用可能な場合にＩＰ−ＣＡＮの容量に基づいて端末機をしてどのドメインが呼を受信するかを決定するようにすることで、システムのシグナリングと複雑度とを減少させる。このような選択は（例えば、３ＧＰＰ ＴＳ２３．２０６の下部条項５．４．６で論議されたＵｔインターフェースを通じて）通信運営者政策に委任されることができ、着信ドメインの最終的な制御は相変わらずネットワーク運営者による。また、本発明は、関連シグナリングのためにＰＳドメインまたはＵＳＳＤ基本制御チャンネルが要求されるか否かを、端末機が決定できるようにする。これによって、ローカル接続ネットワークの容量を設定するためにネットワークに要求されるシグナリングは減少され、またＵＳＳＤシグナリング量は減少できる。本質的に、本発明はモバイル着信（ＭＴ）ドメイン選択のためのより良好なソリューションになる。

本発明の多様な、好ましい実施形態は添付図面を参照しつつ説明される。
ＩＣＳのための既存の着信呼ドメイン選択過程を示すフローチャートである。 本発明の実施形態に従うＩＣＳのための着信呼ドメイン選択過程を示すフローチャートである。 本発明に従うシステムの機能要素を概略的に示す構成図である。 着信端末機がＩＭＳ登録され、接続ネットワークが同時的なＣＳとＰＳ動作可能な時に遂行される動作のシグナリングを示す図である。 着信端末機がＩＭＳ登録され、接続ネットワークが同時的なＣＳとＰＳ動作可能でない時に遂行される動作のシグナリングを示す図である。 ＣＳ呼と引込ＳＩＰ呼とを相関させる必要性を決定するようにＩＣＣＦにより遂行される動作を示すフローチャートである。 本発明の代案的な実施形態に従ってＩＣＳのために着信呼ドメイン選択過程を示すフローチャートである。

本発明の実施形態において、ＩＣＳ ＵＥはＰＳドメインを通じて正常なセッション開始プロトコル（ＳＩＰ）INVITEを受信するが、以後にＵＳＳＤを用いてＣＳドメインを通じてＩＣＣＦに応答してＩＣＣＦに同時的なＰＳ及びＣＳが可能でないことを知らせる選択権を有する。これは（ＣＳ呼に連結されていない場合に）同時的なＣＳとＰＳ動作可能な接続ネットワークを介して接続されているか否かに関わらず、ＩＭＳ登録されたＵＥが常にSIP INVITEを受信可能であるという事実に起因する。追加的な進歩的段階で、端末機からの初期SIP INVITEに対する応答は、仮にＩＰ−ＣＡＮが、例えば、ＶｏＩＰを通じて対話形音声／ビデオをサポートできない場合にセッションのメディア部分としてＣＳベアラが使われるという表示を含む。この情報はＩＭＳ通信サービス識別子（IMS Communication Service Identifier；ＩＣＳＩ）、またはSIP INVITEに対するＳＩＰ応答がＵＳＳＤによりＩＣＣＦに伝えられたという事実が十分に表示されない場合に、ＩＣＣＦに後続ＣＳベアラ設定がセッションと関連することと期待するように知らせるいくつかの他の手段を用いて送信できる。

本発明は、ユーザメディア及び／またはセッション設定シグナリング転送のためにＩＰ−ＣＡＮを通じて、またはより制限された程度にＣＳドメインを通じて接近可能なＩＭＳコアネットワークを許容する３ＧＰＰ ＴＲ ２３．８９２で説明されたＩＣＳアーキテクチャ上で構築される。特に、本発明は呼（call）受信目的用としてＩＣＳネットワークのドメイン選択機能をＵＥに位置させるようにする。

図２は、ＵＥが運営者政策と接続ネットワークの容量（capabilities）に基づいてセッション終了のための適切なドメインを決定するようにする場合の例示的な論理フローを提示する。この場合に、ＵＥはまた関連制御シグナリングとしてＰＳ基盤の制御チャンネル、またはＵＳＳＤ基盤の制御チャンネルを使用するか否かを決定できる。本発明の一態様によれば、ＩＣＣＦは常にＭＴ呼のための呼フローに含まれる。

図２に示すように、Ｓ４１で呼通知がＩＣＣＦに到達した以後に、Ｓ４３でＩＣＣＦは着信端末機がＩＰ−ＣＡＮを通じてＩＭＳに登録されているか否かを決定する。仮に、そのような場合に、例えば、Ｓ４５でＶｏＩＰを通じてリアルタイム音声／ビデオをサポートするためのローカル接続ネットワークとＩＰ−ＣＡＮの容量に関わらず、ＩＣＣＦはSIP INVITEを着信端末機に送信する。SIP INVITEを受信すると共に、Ｓ４７で着信端末機はローカル接続ネットワークがＶｏＩＰをサポートするか否かを決定する。ＶｏＩＰがサポートされる場合に、Ｓ４９で着信端末機はＳＩＰ １８ｘメッセージを用いて応答し、正常なＩＭＳセッションが引き続く。

上記Ｓ４７で、接続ネットワークがＶｏＩＰをサポートしないことと着信端末機により決定されれば、Ｓ５１で着信端末機は接続ネットワークがＣＳとＰＳドメインで同時的な通信をサポートするか否かをチェックする。仮に、そのような場合に、Ｓ５３で着信端末機はメディアがＣＳベアラにより運搬されることを表示するＰＳドメインのＳＩＰ １８３メッセージ（セッション進行）で応答し、メディア転送のためにＩＣＣＦへのＣＳベアラを設定する。ＣＳベアラによりメディアが運搬されるというＳＩＰ １８３メッセージでの表示は、多数の異なる形態を取ることができる。ＩＣＣＦからのSIP INVITEはＣＳドメインを通じたメディア転送を具体的に表示するメディアラインを含むＳＤＰオファー（SDP offer）を伝達することができ、ＵＥはＣＳ関連メディアラインのみを含むＳＤＰアンサー（SDP answer）を提供する。選択的に、ＩＭＳサービスを受信するようにＣＳを通じてＩＣＳ ＵＥが登録され、メディア転送のためにＣＳベアラが設定されなければならないことを知っている時に、ＳＩＰ ４１５メッセージ（サポートできないメディア）が送信されることができ、これはＩＣＣＦにより解釈可能である。以後、Ｓ５５で、サービス制御及び構成のためにＰＳドメインを通じたＳＩＰと共にメディアのためのＣＳベアラを用いてＩＭＳセッションが続く。

Ｓ５１で、ローカル接続ネットワークが同時的なＣＳとＰＳ通信とがサポートできないと着信端末機が決定した場合に、Ｓ６１で着信端末機はＣＳドメインを通じてセッションが設定されなければならないことを表示する“進行（progress）”メッセージを、ＵＳＳＤを用いて送信することによって応答し、メディア転送のためにＩＣＣＦへのＣＳベアラを設定する。選択的に、ＵＥはＣＳベアラ制御のためにＵＳＳＤが使われなければならないことを表示するＩＣＣＦへの新たなＳＩＰ ４ｘｘメッセージを送信することによって応答する。以後、Ｓ６３で、サービス制御及び構成のためにＵＳＳＤを通じたＩＣＣＰと共にメディアのためのＣＳベアラを用いてＩＭＳセッションが続く。

Ｓ４３で、着信端末機がＩＰ−ＣＡＮを通じてＩＭＳ登録されていないことをＩＣＣＦにより決定されれば、Ｓ５７で着信端末機がＣＳドメインを通じてＩＭＳを受信するように登録されるか否かをＩＣＣＦが決定する。仮に、そのような場合に、Ｓ５９でＩＣＣＦはＵＳＳＤを通じて着信端末機に着信呼通知を送信する。このような着信呼通知の受信以後に、Ｓ６１で着信端末機はＵＳＳＤを用いてＣＳドメインを通じて応答し、メディア転送のためのＩＣＣＦへのＣＳベアラを設定する。以後、Ｓ６３で、サービス制御及び構成のためにＵＳＳＤを通じたＩＣＣＰと共にメディアのためのＣＳベアラを用いてＩＭＳセッションが続く。

Ｓ５７で、着信端末機がＣＳドメインを通じてＩＭＳを受信するように登録されていないとＩＣＣＦにより決定されれば、Ｓ６５でＩＣＣＦは着信端末機が正常なＣＳを受信するように登録されたか否かをチェックする。仮に、そのような場合に、Ｓ６７でＩＣＣＦは着信端末機への標準ＣＳ呼としてセッションを完了する。そうでない場合に、Ｓ６９でＩＣＣＦは呼が完了できないことを決定する。

本発明は、３ＧＰＰ ＴＲ２３．８９２ ｖ１．０．０でアーキテクチャ要件が論議されたＩＰマルチメディアシステム（ＩＭＳ）集中化サービス（ＩＣＳ）に適用可能であり、３ＧＰＰ ＴＲ２３．８９２ ｖ１．０．０はwww.3GPP.orgからダウンロードされることもでき、その全体が参照用として本願に含まれる。

図３は、本発明と関連したＩＣＳシステムのメーン機能要素を概略的に示す。理解する事項として、ＩＣＳ要素が他の多くの機能要素を含むが、これらは図示の便宜のために図３に含まれなかった。

図３に示すように、発信ＵＥ１はローカル無線接続網（Radio Access Network）３を介して呼セッション制御機能（Call Session Control Function；ＣＳＣＦ）５と通信する。当該技術分野の通常の知識を有する者であれば、事実上３つタイプの呼セッション制御機能、即ちプロキシＣＳＣＦ、Ｓ−ＣＳＣＦ（Serving CSCF）及びＩ−ＣＳＣＦ（interrogating CSCF）があることを理解するはずである。しかしながら、説明の便宜のために、これらは図３で一緒にグループ化されている。

ＣＳＣＦ５はＩＭＳ ＣＳ制御機能（ＩＣＣＦ）７と接続される。ＩＣＣＦ７はＣＳ接続ネットワークを介して発信または着信される呼及びＣＳとＰＳ接続ネットワークの間で転送される呼に対し、ＩＭＳサービス提供に必要な機能を提供する。図３に示すように、ＩＣＣＦ７は、２つの機能、即ちＣＡＡＦ（CS Access Adaptation Function）とＲＵＡ（Remote User Agent）とを含む。

ＩＣＣＦ（７）は、ホーム加入者サーバー（Home Subscriber Server；ＨＳＳ）９、メディアゲートウェイ制御機能（Media Gateway Control Function；ＭＧＣＦ）１１、及びメディアゲートウェイ（Media Gateway；ＭＧＷ） １３と接続される。ＨＳＳ９は加入関連情報を含む管轄ユーザデータベースであり、ユーザ位置に関する情報を提供することができる。ＭＧＷ１３は、ＣＳドメインのメディア平面とインターフェースし、ＭＧＣＦ１１は制御プロトコル変換を遂行する。

ＨＳＳ９、ＭＧＣＦ１１、及びＭＧＷ１３の全ては、ＶＭＳＣ（visited mobile switching centre）１５と無線接続網１７を介して着信ＵＥ１９と連結される。

ＣＳドメインを通じてＩＭＳサービスに接続する時、ＩＭＳ ＣＳ制御チャンネル（IMS CS Control Channel；ＩＣＣＣ）はＩＣＳ ＵＥとＩＭＳとの間で制御シグナリングを転送することに使われる。ＩＣＣＣはＣＳドメインネットワークにわたって設定可能であり、この場合にＩ１−ｃｓと称され、ＰＳドメインにわたって設定される場合にはＩ１−ｐｓと称される。

ＣＳドメインで使われるＵＳＳＤ転送メカニズムは、ＰＳベアラだけの帯域幅を提供せず、したがって適したＩＭＳ ＣＳ制御プロトコル（ＩＣＣＰ）が要求される。

図４は、端末機がＩＭＳ登録され、接続ネットワークが同時的なＣＳとＰＳ動作可能な時の呼設定のための例示的なメッセージフローを示す。

このメッセージ流れが完全に新たなものではないが、区別される部分は本発明を例示する第６ステップである。第６ステップで、SIP INVITE要請を受信すると共に、ＵＥは自身がどのドメインで呼を完了するか否かを決定する。さらに、ＵＥによりこのような決定がなされれば、ステップ７でＵＥはこのような表示をまたＩＭＳ回線交換制御機能（ＩＣＣＦ）に伝達する。

１．着信SIP INVITEはＡ−当事者からのＳＤＰを含むオファー（offer）と共にＢ当事者のＳ−ＣＳＣＦで受信される。
２．Ｓ−ＣＳＣＦはこのようなINVITEをＩＣＣＦに転送する。
３．ＩＣＣＦは１８３セッション進行をまたＳ−ＣＳＣＦに送る。
４．Ｓ−ＣＳＣＦはＡ−当事者にこのような１８３セッション進行を送る。
５．（Ｂ２ＢＵＡとして動作する）ＩＣＣＦは、Ｂ−当事者にINVITEを送信することによってＩ１−ｐｓを通じてセッションを設定する。INVITEは後でＩＣＣＦをして発信セッション制御シグナリングと着信ベアラ制御シグナリングとを相関させるように動的ＲＵＡ ＰＳＩを含む。
６．ＵＥ−Ｂは１８３セッション進行に応答し、メディア転送のためにＣＳベアラが要求されるという表示をＩＣＣＦに提供することによって、ＩＣＣＦはＣＳベアラ設定と関連するＵＥからの後続INVITEを期待する。
７．ＵＥ−Ｂはベアラ制御シグナリングセッションを設定するためにＶＭＳＣにSETUPメッセージを送る。このSETUPメッセージは呼出し当事者番号としてＲＵＡ ＰＳＩ ＤＮを含む。これはＵＥとＩＭＳとの間のアナログ音声ベアラを設定する。
８．ＶＭＳＣは、呼進行メッセージに応答し、ベアラ制御シグナリングセッションを設定する。
９．ＶＭＳＣはSETUPメッセージを処理し、ＭＧＣＦにＩＡＭを送る。このSETUPメッセージはＲＵＡ ＰＳＩ ＤＮを含む。［注目事項：ＣＳ開始のための標準ＶＭＳＣ過程］
１０．ＭＧＣＦはＭＧＷの設定を遂行し、ＭＧＷからのＳＤＰを含むオファー（Offer）を持つINVITEを生成する。このINVITEは（Ｉ／Ｓ−ＣＳＣＦを通じて）ＩＣＣＦに送られる。［注目事項：ＰＳＴＮ開始のための標準ＭＧＣＦ過程］
１１．Ｉ／Ｓ ＣＳＣＦはINVITEをＩＣＣＦのＲＵＡに転送する。
１２．ＩＣＣＦはＡ−当事者からのオファー（offer）に対するアンサー（answer）を持つUPDATEをＳ−ＣＳＣＦに送り、これはＭＧＷからのＳＤＰを含む。
１３．Ｓ−ＣＳＣＦはこのUPDATEをＡ−当事者に転送する。
１４．Ｓ−ＣＳＣＦはこのUPDATEに対する２００ ＯＫを受信する。
１５．Ｓ−ＣＳＣＦはこの２００ ＯＫをＩＣＣＦに転送する。
１６．ＩＣＣＦはＭＧＷからオファー（offer）に対するアンサー（answer）を持つ１８３セッション進行をＳ−ＣＳＣＦに送り、これはＡ−当事者からのＳＤＰを含む。
１７．Ｓ−ＣＳＣＦはこの１８３セッション進行をＭＧＣＦに送る。
１８．ＭＧＣＦはＡＣＭを生成し、これをＶＭＳＣに送る。
１９．警報（Alerting）がＶＭＳＣからＵＥＢに送信される。
２０．ＩＣＣＦはステップ１２のINVITEに応答して２００ ＯＫをＳ−ＣＳＣＦに送る。
２１．Ｓ−ＣＳＣＦはこの２００ ＯＫをＭＧＣＦに転送する。
２２．ＭＧＣＦはＡＮＭを生成し、これをＶＭＳＣに送る。
２３．ＶＭＳＣは連結（Connect）をＵＥ Ｂに送る。ベアラ設定が完了する。
２４．ＵＥ Ｂでのユーザ警報、ＵＥ Ｂは１８０RingingをＩＣＣＦに送る。
２５．ＩＣＣＦはＵＥ Ａとの通信のために、この１８０RingingをＳ−ＣＳＣＦに転送する。
２６．Ｓ−ＣＳＣＦは、この１８０RingingをＵＥ Ａに転送する。
２７．ＵＥ Ｂでのユーザ応答、ＵＥ Ｂはステップ６でのINVITEに対する２００ ＯＫをＩＣＣＦに送る。
２８．ＩＣＣＦはＵＥへの通信のために、この２００ ＯＫをＳ−ＣＳＣＦに転送する。
２９．Ｓ−ＣＳＣＦは、この２００ ＯＫをＡ−当事者に転送する。

図５は、端末機がＩＭＳ登録されたが、接続ネットワークが同時的なＣＳとＰＳ動作が可能でない時の例示的なメッセージフロー呼設定を示す。

このメッセージフローは新たなものであり、ＩＣＳ ＵＥがＵＳＳＤを通じてＩＣＣＦに進行メッセージを送ることによって、着信INVITEに応答できることを示す。これは、このセッションに対する追加的なシグナリングがＵＳＳＤを通じてなされることができることをＩＣＣＦに知らせる。

１．着信SIP INVITEがＡ−当事者からのＳＤＰを含むオファー（Offer）と一緒にＢ当事者のＳ−ＣＳＣＦで受信される。
２．Ｓ−ＣＳＣＦは、このINVITEをＩＣＣＦに転送する。
３．ＩＣＣＦは、１８３セッション進行をまたＳ−ＣＳＣＦに送る。
４．Ｓ−ＣＳＣＦは、この１８３セッション進行をＡ−当事者に送る。
５．（Ｂ２ＢＵＡとして動作する）ＩＣＣＦは、INVITEをＢ−当事者に送ることによってＩ１−ＰＳを通じてセッションを設定する。このINVITEは後でＩＣＣＦをして発信セッション制御シグナリングと着信ベアラ制御シグナリングとを相関させるように動的ＲＵＡ ＰＳＩを含む。
６．INVITEはＵＥ Ｂに到達する。ＵＥ Ｂは接続ネットワークで同時的なＣＳ及びＰＳ容量がないことと決定する。ＵＥ Ｂは進行（ＵＳＳＤメッセージ）をＶＭＳＣに送る。ＶＭＳＣはＵＳＳＤ（進行）をＨＳＳに転送する。ＨＳＳはＵＳＳＤ（進行）をＩＣＣＦのＣＡＡＦに転送する。ＩＣＣＦはＵＳＳＤが後続的な制御シグナリングのために使われることを知っている。
７．ＵＥ−Ｂは、ベアラ制御シグナルセッションを設定するためにSETUPメッセージをＶＭＳＣに送る。このSETUPメッセージは、呼出し当事者番号としてＲＵＡ ＰＳＩ ＤＮを含む。これは、ＵＥとＩＭＳとの間のアナログ音声ベアラを設定する。
８．ＶＭＳＣは呼進行メッセージに応答し、ベアラ制御シグナリングセッションを設定し始める。
９．ＶＭＳＣは、このSETUPメッセージを処理し、ＩＡＭをＭＧＣＦに送る。このSETUPメッセージはＲＵＡ ＰＳＩ ＤＮを含む。［注目事項：ＣＳ開始のための標準ＶＭＳＣ過程］
１０．ＭＧＣＦはＭＧＷの設定を遂行し、ＭＧＷからのＳＤＰを含むオファー（offer）と共にINVITEを生成する。このINVITEは（Ｉ／Ｓ−ＣＳＣＦを通じて）ＩＣＣＦに送られる。［注目事項：ＰＳＴＮ開始のための標準ＭＧＣＦ過程］
１１．Ｉ／Ｓ−ＣＳＣＦは、このINVITEをＩＣＣＦのINVITEに転送する。
１２．ＩＣＣＦは、Ａ−当事者からのオファー（offer）に対するアンサー（answer）を持つUPDATEをＳ−ＣＳＣＦに送り、これはＭＧＷからのＳＤＰを含む。
１３．Ｓ−ＣＳＣＦは、このUPDATEをＡ−当事者に転送する。
１４．Ｓ−ＣＳＣＦは、このUPDATEに対する２００ ＯＫを受信する。
１５．Ｓ−ＣＳＣＦは、この２００ ＯＫをＩＣＣＦに転送する。
１６．ＩＣＣＦは、ＭＧＷからオファー（offer）に対するアンサー（answer）を持つ１８３セッション進行をＳ−ＣＳＣＦに送り、これはＡ−当事者からのＳＤＰを含む。
１７．Ｓ−ＣＳＣＦは、この１８３セッション進行をＭＧＣＦに送る。
１８．ＭＧＣＦはＡＣＭを生成し、これをＶＭＳＣに送る。
１９．警報はＶＭＳＣからＵＥ Ｂに送られる。
２０．ＩＣＣＦは、上記ステップ１２でのINVITEに応答して２００ ＯＫをＳ−ＣＳＣＦに送る。
２１．Ｓ−ＣＳＣＦは、この２００ ＯＫをＭＧＣＦに転送する。
２２．ＭＧＣＦはＡＮＭを生成し、これをＶＭＳＣに送る。
２３．ＶＭＳＣは連結（connection）をＵＥ Ｂに送る。ベアラ設定が完了する。
２４．ＵＥ Ｂでのユーザ警報；ＵＥ ＢはＵＳＳＤメッセージでRingingをＶＭＳＣに送る。ＶＭＳＣはＵＳＳＤ（Ringing）をＨＳＳに転送する。ＨＳＳはＵＳＳＤ（Ringing）をＩＣＣＦのＣＡＡＦに転送する。
２５．ＩＣＣＦのＣＡＡＦは必要な調節を遂行し、ＩＣＣＦのＲＵＡでＳＩＰメッセージ生成に必要な情報を中継する。Ｂ２ＢＵＡとして動作するＩＣＣＦのＲＵＡは１８０リングトンを生成し、ＵＥ Ａとの通信のためにこれをＳ−ＣＳＣＦに送る。
２６．Ｓ−ＣＳＣＦは１８０RingingをＵＥ Ａに転送する。
２７．ＵＥ Ｂでのユーザ応答；ＵＥ ＢはＵＳＳＤメッセージでアンサー（answer）をＶＭＳＣに送る。ＶＭＳＣはＵＳＳＤ（answer）をＨＳＳに転送する。ＨＳＳは、ＵＳＳＤ（answer）をＩＣＣＦのＣＡＡＦに転送する。
２８．ＩＣＣＦのＣＡＡＦは必要な適応を遂行し、ＩＣＣＦのＲＵＡでＳＩＰメッセージの生成に必要な情報を中継する。Ｂ２ＢＵＡとして動作するＩＣＣＦのＲＵＡは２００ ＯＫを生成し、ＵＥ Ａと通信するためにこれをＳ−ＣＳＣＦに送る。
２９．Ｓ−ＣＳＣＦは、この２００ ＯＫをＡ−当事者に転送する。

同様に、図５のステップ６は新しく、区別されて本発明を説明している。上記ステップ６で、SIP INVITE要請を受信すると共に、ＵＥはどのドメインを通じて呼を完了するか否かを決定する。上記完了するか否かが決定されれば、上記の決定はＩＣＣＦに知らされるようになる（ステップ７）。

図４及び図５全てに示すように、ＩＣＣＦは（ＵＥ Ａからの）ＣＳ呼とＩＭＳ呼の相関を遂行するが、これはＵＥ−ＡとＵＥ−Ｂとの間の呼が呼完了で正常なＩＭＳ方式によりＩＭＳ ＣＮを通じて完了されないためである。したがって、（図４及び図５の）ステップ７で、１８３セッション進行でのＵＥ応答はＩＣＣＦをしてＣＳドメインとの相関が要求されるかを決定するようにもたらす。図６はＩＣＣＦをしてこのような相関の必要性を決定するようにする過程の図解的な例示を提供する。

本発明の変形及び追加的な実施形態
ＩＰ−ＣＡＮが利用可能でなければ、ＣＳ接続端末機によるＩＭＳへの登録が必ず要求されるのではない。このように、ＵＥがＩＭＳサービスを受信するようにＣＳを通じて登録されていることをＩＣＣＦが知っているという概念は剰余的でありうる。しかしながら、ＳＤＰオファー／アンサーメカニズムの使用は相変わらず有効である。

図７は、他の例示的な論理フローを提示するが、この場合にＵＥは接続ネットワークの容量と運営者政策に基づいてＩＣＣＦと関連してセッション終了のための適切なドメインを決定するようになる。本実施形態では、ＵＥがＩＣＳ可能なことと仮定していることを注目する。運営者政策とＲＵＡ ＰＳＩ ＤＮなどのＩＣＳ情報はＶＣＣでターミナルプロビジョニング（terminal provisioning）に使われることと類似な方式によりＩＣＳ ＵＥと通信する。運営者政策に基づいたドメイン選択はホームネットワークをしてドメイン選択決定を続けて制御するようにする。この場合に、ＵＥはまたＰＳまたはＵＳＳＤ基盤の制御チャンネルが関連制御シグナリングのために使われなければならないかを決定することができる。このようなソリューションは訪問接続ネットワークとホームＩＭＳとの間で情報を伝達する必要性を除去し、またＵＳＳＤを通じて送信されるシグナリング量を減少させることができる。さらに、これはＩＭＳに関わらず、ＭＴドメイン選択のためにより良好なソリューションになり、相当数のＩＰ−ＣＡＮがＶｏＩＰ可能になる時に適切に順方向−互換（forward compatible）される。また、ＥＰＳと伝統的な接続ネットワークとの間のシグナリングの自由移動性（signaling free mobility）の場合のドメイン選択に関する問題の克服への助けになる。

例示的な終了過程は、次の通りである。
１．ＩＣＣＦは常にＭＴ呼のための呼フローの中に含まれる。
２．端末機がＩＭＳ登録されれば、（知られていない、例えば、ＶｏＩＰを通じてリアルタイム音声／ビデオをサポートするためのＩＰ−ＣＡＮの容量に関わらず）ＩＣＣＦがINVITEを着信ＵＥに送る。
ａ．端末機は、自身がＶｏＩＰ可能ＩＰ−ＣＡＮにあることと決定すれば、上記端末機は標準１８ｘ応答でINVITEに応答し、セッションはＩＭＳを通じて設定される。
ｂ．端末機は、自身がＶｏＩＰをサポートしないが、接続ネットワークにより同時的なＣＳとＣＳをサポートできるＩＰ−ＣＡＮにあることと決定すれば、上記端末機は１８３応答で応答するが、ここで１８３応答はメディアがＣＳベアラを通じて運搬されなければならないことを表示する。以後、ＵＥはＩＣＣＦへのＣＳベアラを設定し、ＩＣＣＦがＣＳベアラとＩＭＳセッション（INVITE／１８３進行）を相関させる。セッションはメディア転送のためにＣＳベアラを用いたＩＭＳセッションとして取り扱われる。
ｃ．端末機は自身がＶｏＩＰをサポートせず、接続ネットワークに同時的なＣＳとＰＳがないＩＰ−ＣＡＮにあることと決定すれば、上記端末機はセッションがＩ１−ＣＳ手続きを用いてＣＳドメインを通じて設定されなければならないことを表示する方式によりＩＣＣＦ方向にＵＳＳＤを通して“進行”メッセージを送信することによって応答する。ＩＣＣＦはセッションのためにＩＭＳシグナリング（INVITE）を相関させる。追加的なサービス制御及び構成はＵＳＳＤを通じてなされる。
３．端末機がＩＰ−ＣＡＮを通じてＩＭＳ登録されなかったが、ＣＳ登録された場合に、ＩＣＣＦは端末機への着信呼通知を送信するためにＵＳＳＤを使用する。ＵＥはＩ１−ｃｓ呼設定過程を用いてＩＣＣＦへのＣＳベアラを設定し、ＩＣＣＦはセッションのためにＩＭＳシグナリング（INVITE）と相関される。追加的なサービス制御及び構成はＵＳＳＤを通じてなされる。

３ ＲＡＮ
５ ＣＳＣＦ
１５ ＶＭＳＣ

Claims (12)

1. 移動通信ネットワークの移動局における音声及び／またはビデオ呼を受信するための接近ドメインを選択する方法であって、
   前記呼は複数の接近ドメインに共通的な中央サービス制御部を通じてルーティングされ、
   前記中央サービス制御部が着信移動局に呼を設定するための招請（invite）メッセージを送信するステップと、
   前記移動局がローカル接続ネットワークの容量（capabilities）を考慮して前記呼を処理するための接近ドメインを決定し、前記中心サービス制御部に前記選択された接近ドメインを指示するステップと、
   前記選択された接近ドメインに従い前記呼を設定するステップと、
   を含む接近ドメイン選択方法。
2. 前記中央サービス制御部は、前記着信移動局が招請メッセージを送信する前にＩＭＳ登録されたか否かを決定するＩＭＳ集中化サービス制御部であることを特徴とする請求項１に記載の接近ドメイン選択方法。
3. 前記招請メッセージはＳＩＰ招請メッセージであることを特徴とする請求項１または２に記載の接近ドメイン選択方法。
4. 仮に、前記移動局は自身がＶｏＩＰ（Voice Over IP）可能接続ネットワークにあることを決定すれば、ＩＭＳ接続ドメインが選択されることを特徴とする請求項１乃至３のうち、いずれか１つに記載の接近ドメイン選択方法。
5. 仮に、前記移動局は自身がＶｏＩＰをサポートしないが、同時的な回線交換（ＣＳ）及びパケット交換（ＰＳ）接続をサポートする接続ネットワークにあることを決定すれば、ＣＳベアラが前記ＩＭＳ集中化サービス制御部に直接的に設定されることを特徴とする請求項１乃至４のうち、いずれか１つに記載の接近ドメイン選択方法。
6. 前記移動局は自身がＶｏＩＰをサポートせず、同時的な回線交換（ＣＳ）及びパケット交換（ＰＳ）接続をサポートしない接続ネットワークであると決定すれば、ＣＳベアラが前記ＩＭＳ集中化サービス制御部に直接的に設定され、並列ＰＳチャンネルがサポートできないことを指示するメッセージが送信されることを特徴とする請求項１乃至５のうち、いずれか１つに記載の接近ドメイン選択方法。
7. 前記メッセージはＵＳＳＤを通じて送信されることを特徴とする請求項６に記載の接近ドメイン選択方法。
8. 前記呼を受信するための前記接近ドメインの決定は、前記通信ネットワークの運営者の政策を考慮することを特徴とする請求項１乃至７のうち、いずれか１つに記載の接近ドメイン選択方法。
9. 前記ローカル接続ネットワークは無線接続網であることを特徴とする請求項１乃至８のうち、いずれか１つに記載の接近ドメイン選択方法。
10. 請求項１乃至９のうちのいずれか１つに従う方法を具現するように動作可能な移動通信ネットワーク。
11. 請求項１乃至１０のうちのいずれか１つに従う前記移動通信ネットワーク用移動局であって、
    前記移動局は受信された呼招請メッセージに応答して、前記ローカル接続ネットワークの容量を考慮した前記呼を受信するために接近ドメインを決定すると共に、前記選択された接近ドメインを前記中央サービス制御部に送信するように動作可能であることを特徴とする移動局。
12. 無線接続網を介して通信ネットワークに連結された移動局に呼を設定する方法であって、
    前記移動局は、前記呼の設定に使われるサービスドメインまたはドメインを決定する呼設定方法。

Images