JP5727477B2 - 非定常ＶｏＩＰ通話の間で端末をハンドオーバさせるための方法、ネットワーク要素、装置およびシステム - Google Patents

Description

本発明は通信の分野に関し、より詳細には、ＶｏＩＰ通話の非定常状態の間で端末をハンドオーバさせることに関する。

通話／セッションが定常状態にある、すなわちユーザがＣＳ（回線交換）へのアクセス転移の開始時に、ＰＳ（パケット交換）の（複数の）メディア・フローを使用するＩＭＳセッション内で活動中にある間で単一無線音声通話継続性（ＳＲＶＣＣ）をサポートする方法は３ＧＰＰ ＴＳ ２３．２１６で規定された。

一例として、図１は３ＧＰＰ ＴＳ ２３．２１６において供給されるＳＲＶＣＣネットワーク・アーキテクチャを示している。図１に示されるように、ＵＥはＥ−ＵＴＲＡＮ、Ｓ−ＧＷ／ＰＤＮ ＧＷを介してＩＭＳにアクセスする。ＬＴＥ（長期進化型）としても知られるＥ−ＵＴＲＡＮは無線アクセス・ネットワークを担ういくつかのｅノードＢを含む。ＥＰＳは既に存在するＷＣＤＭＡおよびＴＤ−ＳＣＤＭＡシステムのノードＢ、ＲＮＣおよびＣＮを機能面で合体させることにより、２つのタイプのネットワーク要素すなわちｅノードＢとＥＰＣとして簡素化される。

いわゆるＥＰＳはＥＰＣ（進化型パケット・コア、すなわちコア・ネットワーク）、Ｅ−ＵＴＲＡＮ（ＬＴＥとしても知られる）およびＵＥを含む。ＥＰＣは制御ノードの役割を果たし、かつコア・ネットワークの信号処理を担うためのＭＭＥ（モビリティ管理エンティティ）、コア・ネットワークのデータ処理を担うＳ−ＧＷ（サービング・ゲートウェイ）／ＰＤＮ−ＧＷ（パケットデータ・ネットワーク・ゲートウェイ）を含み、ここで非３ＧＰＰの無線アクセス・ネットワークはＰＤＮ−ＧＷを介してＥＰＣにアクセスすることが可能であり、３ＧＰＰの無線アクセス・ネットワークはＳ−ＧＷを介してＥＰＣにアクセスすることが可能である。

さらに、図１はこの仕様によって提案されるネットワーク要素の間のインタフェースもやはり示している。例えば、Ｅ−ＵＴＲＡＮとＥＰＣはＳ１（ｌｕと同様）インタフェースを介して相互に接続され、Ｅ−ＵＴＲＡＮ同士はＸ２（ｌｕｒと同様）インタフェース（図示せず）を介して相互に接続され、ＵＥとＥ−ＵＴＲＡＮはＬＴＥ−Ｕｕインタフェースを介して相互に接続される。

図１に示されるような環境では、ＵＴＲＡＮ（ＵＭＴＳ地上波無線アクセス・ネットワーク）／ＧＥＲＡＮ（ＧＳＭ／ＥＤＧＥ無線アクセス・ネットワーク）によって提供される回線交換ドメインへとＵＥをハンドオーバさせることに関する決定は、ＵＥがＥ−ＵＴＲＡＮのカバレージの端またはカバレージの外側にあるときに為されてもよい。ＵＴＲＡＮ／ＧＥＲＡＮでは、ＵＥは基地局、ＭＳＣ（移動通信交換局）サーバを介してＩＭＳネットワークにアクセスする。

ＵＴＲＡＮはＵＭＴＳのためのどちらかといえば新しいアクセス・ネットワークであり、現在ではＵＭＴＳの重要なアクセス方式になっており、ノードＢ、ＲＮＣ（無線ネットワーク制御装置）、ＣＮ（コア・ネットワーク）などを含むことが可能であり、ＧＥＲＡＮは３ＧＰＰによって策定され維持されるＧＳＭの主要部分であり、ＵＭＴＳ／ＧＳＭネットワーク内にもやはり含まれ、基地局ＢＳおよび基地局制御装置ならびにこれらのインタフェース（例えばＡｔｅｒインタフェース、Ａｂｉｓインタフェース、Ａインタフェースなど）を含む。概して、移動通信オペレータ・ネットワークは、ＵＭＴＳ／ＧＳＭネットワーク内のＵＴＲＡＮと組み合わされるいくつかのＧＥＲＡＮから成る。

図１内の他のネットワーク要素およびそれらの間の通信方式についてのさらなる詳細に関しては、ＴＳ ２３．２１６を参照することができる。

一例として、図２はＥ−ＵＴＲＡＮからターゲットのＧＥＲＡＮへの当該通話のフローを示している。音声セッションのハンドオーバを完成させるために、音声通話は例えばＩＭＳのＳＣＣ ＡＳ（サービスの集中化・継続性アプリケーション・サーバ）に前もって固定されるべきである。

図２に示されるように、ソースＥ−ＵＴＲＡＮはローカル／ソースＵＥから受信した測定報告に基づいて、進行中のローカルＵＥのＶｏＩＰ通話をＰＳドメインからＣＳドメインへとハンドオーバさせることを決定すると、ハンドオーバ要求をローカルＭＭＥに送信することになる。その後、ソースＭＭＥは（後に生じる音声サービスのハンドオーバのために）ベアラを分割し、ＰＳドメインからＣＳドメインへの該当のハンドオーバ要求を、現在このローカルＵＥをカバーできるＭＳＣサーバまたはメディア・ゲートウェイに送信することになる。該当のＭＳＣ／メディア・ゲートウェイはハンドオーバのための準備を終えて回線を確立した後にセッションのハンドオーバを開始することになる。本明細書において、ローカルＵＥがハンドオーバされるターゲットのＭＳＣがＭＭＥからハンドオーバ要求を受信するＭＳＣと同じであるケースでは破線部分のステップ６〜９（およびステップ２０〜２１もやはり）が省略されてもよいことに留意されたい。

以下のステップ（すなわちステップ１０以降）で、図２はユーザ・レイヤの２通りのハンドオーバ手順を示している。
・（遠隔のＵＥ、すなわちローカルＵＥとＶｏＩＰセッションをセットアップしている相手側での）ＩＭＳレイヤのセッション・ハンドオーバ手順（ステップ１１〜１２）。より具体的には、このセッション・ハンドオーバ手順はＩＭＳのＳＣＣ ＡＳによって遂行され、その後に遠隔のＵＥがターゲットのＣＳアクセス区切りのＳＤＰ（セッション記述プロトコル）によって更新され、ソースＥＰＣのＰＳアクセス区切りが解除される。上記のステップにより、進行中のセッションの音声部分がユーザ・レイヤにおいてＥＰＣからＭＧＷへとハンドオーバさせられることになる。
・ローカルＵＥおよびアクセス・ネットワークで遂行されるＲＡＴ間のハンドオーバである、レイヤ２のターゲットのセルへのハンドオーバ手順（ローカルＵＥおよびアクセス・ネットワークで遂行される、ステップ１５〜２１のＥ−ＵＴＲＡＮからＧＳＭへのハンドオーバ）。

図２のステップのさらなる詳細については、３ＧＰＰ ＴＳ ２３．２１６を参照することが可能である。

しかしながら、セッションの非定常状態の間でＳＲＶＣＣをサポートする方法は３ＧＰＰ ＴＳ ２３．２１６には示されていない。この非定常状態はセッションの初期の状態、例えば起呼側が２００ ＯＫメッセージではなく暫定ＳＩＰ応答メッセージ（１００ Ｔｒｙｉｎｇメッセージを除く）を受信した状態を意味してもよい。

したがって、セッションの非定常状態の間でＰＳドメインからＣＳドメインへのＳＲＶＣＣハンドオーバをサポートすることができるメカニズムが必要とされる。

先行技術の上記の課題を解決するために、本発明の態様によれば、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせるための方法が提案される。本方法は、第１のネットワーク要素が端末から受信した通話セットアップ要求に基づいて通話を固定させ、かつこの端末へと返信される暫定応答および通話の状態を記憶するステップと、ハンドオーバが必要であることを端末が検出し測定報告をアクセス・ネットワークに送信するステップと、この測定報告がハンドオーバ条件に合致する間で信号ベアラを検出すると、アクセス・ネットワークが第２のネットワーク要素にハンドオーバの要求をすることを決定するステップと、ハンドオーバの要求をアクセス・ネットワークから受信した後に、信号ベアラを検出すると第２のネットワーク要素が第１のネットワーク要素にＰＳからＣＳへのハンドオーバ要求を送信することを決定するステップと、前記ハンドオーバ要求を受信した後に、第１のネットワーク要素が、通話が非定常状態にあることを検出すれば、前に記憶された暫定応答をチェックし、この暫定応答を第３のネットワーク要素に送信し、それによってセッション・ハンドオーバ手順を完成させ、遠隔末端を更新するステップとを含む。

本発明の他の態様によると、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができる、サービスの集中化および継続性を管理するネットワーク要素が提案される。このネットワーク要素は、端末へと返信される暫定応答および端末から受信した通話セットアップ要求に基づいて通話が固定させられた後の通話の状態を記憶するための記憶手段と、別のネットワーク要素からハンドオーバ要求を受信すると、通話が非定常状態にあると検出されるケースでは、前に記憶された暫定応答をチェックしこの暫定応答をさらに別のネットワーク要素へと送信するための暫定応答チェック・送信手段とを含む。

本発明のさらに他の態様によると、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができるアクセス装置が提案される。このアクセス装置は、端末から受信した測定報告がハンドオーバ条件に合致する間で信号ベアラを検出すると、別のネットワーク要素にハンドオーバの要求をすることを決定するための決定手段を含む。

本発明のさらに他の態様によると、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができる、端末のモビリティを管理するネットワーク要素が提案される。このネットワーク要素は、アクセス・ネットワークからハンドオーバの要求を受信した後に、信号ベアラを検出するとＰＳからＣＳへのハンドオーバ要求を別のネットワーク要素へと送信することを決定するための決定手段を含む。

本発明のさらに他の態様によると、少なくとも１つの端末と、本発明によるサービスの集中化および継続性を管理するネットワーク要素と、本発明によるアクセス装置と、本発明による、端末のモビリティを管理するネットワーク要素とを少なくとも含む通信システムが提案される。

本発明のこれらおよび他の多くの特徴および利点は、図面を参照した下記の本発明の実施形態の説明から明らかになろう。

３ＧＰＰ ＴＳ ２３．２１６において供給されるＳＲＶＣＣのためのネットワーク・アーキテクチャを一例として示す図である。 先行技術によるＥ−ＵＴＲＡＮからＧＥＲＡＮ／ＵＴＲＡＮへのＳＲＶＣＣハンドオーバの信号のフローを一例として示す図である。 本発明による、非定常通話状態下のＥ−ＵＴＲＡＮからＧＥＲＡＮ／ＵＴＲＡＮへのＳＲＶＣＣハンドオーバの信号のフローを一例として示す図である。 本発明の一実施形態による、非定常通話状態下でＳＲＶＣＣハンドオーバを実行するための方法のフローチャートである。 本発明の一実施形態によるネットワーク要素のブロック図である。 本発明の一実施形態によるアクセス装置のブロック図である。 本発明の一実施形態によるネットワーク要素のブロック図である。

本発明は、ＶｏＩＰ通話がまだ非定常状態下にあるケースでＥ−ＵＴＲＡＮからＧＥＲＡＮ／ＵＴＲＡＮへのＳＲＶＣＣハンドオーバを遂行することを意図され、ここで非定常状態の一例は通話の初期の状態である。

したがって、本発明の基本的概念は、ＩＭＳ信号ベアラ（ＱＣＩ（品質クラス識別子）＝５）の存在を検出するとモビリティ管理エンティティ（ＭＭＥ）およびｅノードＢがＳＲＶＣＣハンドオーバ手順を開始できるようにすることである。すなわち、たとえ音声ベアラが存在しなくても（ＱＣＩ＝１）、ＩＭＳ信号ベアラの存在を検出するとＭＭＥはＳＲＶＣＣのＰＳからＣＳへのハンドオーバの要求を移動通信交換局（ＭＳＣ）サーバに送信することになる。ＭＳＣサーバはＳＲＶＣＣのＰＳからＣＳへのハンドオーバの要求を受信した後にＩＭＳおよびＳＣＣ ＡＳへのセッション・ハンドオーバ手順を開始することになる。その後、アクセス区切りの状態およびＳＣＣ ＡＳからローカル端末に送信された前の応答（この応答は予めＳＣＣ ＡＳによって保存されている）に基づいてＳＣＣ ＡＳがＭＳＣサーバに応答することになる。ＳＣＣ ＡＳはセッションのハンドオーバを完成させ、ＭＳＣサーバへの応答を送信した後に遠隔末端を更新し元のアクセス区切りを解除することになる。

ＭＳＣサーバが以下の２通りの方式によってＩＭＳ／ＳＣＣ ＡＳに接続されてもよいことに留意されたい。
１．ＭＳＣサーバがＣＳＣＦ／ＳＣＣ ＡＳへのＩ２／Ｉ１インタフェースをサポートする場合、ＭＳＣサーバはＩ２／Ｉ１インタフェースを介して直接ＩＭＳ／ＳＣＣ ＡＳに接続されることになる。
２．ＭＳＣサーバがＣＳＣＦ／ＳＣＣ ＡＳへのＩ２／Ｉ１インタフェースをサポートしない場合、ＭＳＣサーバはＭＧＣＦ／ＭＧＷを介してＩＭＳ／ＳＣＣ ＡＳに接続されることになる。

しかしながら、本発明はこれら２つの方式のどちらにも応用可能である。単純化するために、第１の方式が以下で述べられる。しかしながら、本発明は第２の方式にもやはり応用可能であり、第２の方式の通話手順は第１の方式のそれと同様である。

本発明において、ｅＮＢ、ＭＭＥおよびＳＣＣ ＡＳを以下のように若干変更することが必要であることに留意されたい。
・アクセス区切りの状態およびＳＣＣ ＡＳから起呼側に送信された前の応答が保存されることができるようにＳＣＣ ＡＳが向上されるべきである。ＳＣＣ ＡＳがアクセス区切り内の１８０ Ｒｉｎｇｉｎｇ ＳＩＰメッセージを起呼側に送信した場合、ＳＣＣ ＡＳはこの応答を保存すべきである。さらに、セッションのハンドオーバを開始する要求をＭＳＣサーバから受信した後に、ＳＣＣ ＡＳはアクセス区切りの状態および前に保存した応答に基づいて適切な応答をＭＳＣサーバに送信すべきである。
・ＩＭＳ信号ベアラが検出されることが可能になり、かつＳＲＶＣＣ要求がローカル・ポリシーに基づいてＭＳＣサーバに送信されることが可能になるようにＭＭＥが向上されるべきである。
・ＩＭＳ信号ベアラの存在を検出するとＳＲＶＣＣハンドオーバが開始されるが可能になるようにＥ−ＵＴＲＡＮが向上されるべきである。

場合によっては、ＳＣＣ ＡＳによって送信される暫定応答が１８０ ＲｉｎｇｉｎｇのＳＩＰメッセージであれば、ＭＳＣサーバは起呼側の呼び出し音を再生するようにＭＧＷに命令する能力を持つべきである。

図３は非定常状態の間の通話／セッションのＳＲＶＣＣハンドオーバの信号のフローを示している。

本明細書で、ＭＧＷによってＳＣＣ ＡＳに送信されるセッションのハンドオーバ要求がＭＳＣサーバの能力に従ったＩＳＵＰメッセージまたはＳＩＰメッセージであってもよいことに留意されたい。本発明はＩＳＵＰまたはＳＩＰのどちらにも応用可能である。単純化するために、本明細書では例証のためにＳＩＰメッセージが一例として採用される。

ステップ１で、ローカルＵＥがＩＮＶＩＴＥ要求をＩＭＳおよびＳＣＣ ＡＳに送信する。この要求が通常のＩＭＳセッション確立手順に従ってＳ−ＣＳＣＦ（図示せず）へと転送される。この要求はｉＦＣ（イニシャル・フィルタ・クライテリア）サービス・ロジックを使用することによってＳＣＣ ＡＳへと転送される。

ステップ２で、ＳＣＣ ＡＳはハンドオーバを実施するためにこのセッションを固定させる。

ステップ３で、ＳＣＣ ＡＳは暫定応答をＵＥへと送信する。本明細書において、この暫定応答は例えば１８０ Ｒｉｎｇｉｎｇまたは１８３ Ｓｅｓｓｉｏｎ ＰｒｏｇｒｅｓｓのＳＩＰメッセージである。

ステップ４で、Ｅ−ＵＴＲＡＮからＧＥＲＡＮ−ＵＴＲＡＮへのハンドオーバが必要とされ得ることをローカルＵＥが検出し測定報告をＥ−ＵＴＲＡＮへと送信する。

ステップ５で、ＵＥの測定報告に基づき、場合によっては「ＳＲＶＣＣオペレーション可能」の表示に基づいて、ソースＥ−ＵＴＲＡＮは、このＵＥのためにセットアップされ、図２に示された信号のフローとは異なるＱＣＩ＝５のベアラ（ＩＭＳ信号）またはＱＣＩ＝１のベアラ（ＩＭＳ音声）の存在を検出するとＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガすることを決定する。本明細書において、ハンドオーバをトリガすることに関する決定はＩＭＳ信号ベアラの存在に基づいて為されてもよく、それにより、非定常状態の間の通話／セッションのＳＲＶＣＣハンドオーバ手順が実施されることができる。

ステップ６で、ソースＥ−ＵＴＲＡＮはハンドオーバ要求（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄ）メッセージをソースＭＭＥへと送信し、これがＳＲＶＣＣハンドオーバ・オペレーションであることをソースＭＭＥに示す。

ステップ７で、ソースＭＭＥは当該ＱＣＩおよび包括的コンテナのタイプをチェックする。音声ベアラ（ＱＣＩ＝１）が存在し、かつコンテナのタイプがＳＲＶＣＣハンドオーバを示せば、ＭＭＥは図２のステップ４と同じプロセスを遂行する（すなわちＭＭＥは非音声ベアラから音声ベアラを分割し、ＭＳＣサーバ向けのＰＳ−ＣＳハンドオーバ手順を開始する準備をする）。コンテナのタイプはＳＲＶＣＣを示すが音声ベアラが存在しなければ、本発明によれば、ＭＭＥはＩＭＳ信号ベアラ（ＱＣＩ＝５）が存在するかどうかさらにチェックする。ＩＭＳ信号ベアラが存在すれば、ＭＭＥはＭＭＥに記憶されたオペレータのローカル・ポリシーに基づいてＰＳ−ＣＳハンドオーバ手順を開始する準備をしてもよい。本明細書では、オペレータのローカル・ポリシーはＩＭＳ信号ベアラが存在して音声ベアラが存在しないケースでＭＭＥがＰＳ−ＣＳハンドオーバ手順を開始することを許可すると仮定する。したがって、ＭＭＥはＳＲＶＣＣのＰＳ−ＣＳ要求をＭＳＣサーバへと送信することになる。

ステップ８〜１２は図２のステップ５〜９と同様である。さらなる詳細については３ＧＰＰ ＴＳ ２３．２１６を参照することが可能であり、本明細書では不必要に詳しく説明されない。

ステップ１３で、ＭＳＣサーバはＳＴＮ−ＳＲ（Ｓｅｓｓｉｏｎ Ｔｒａｎｓｆｅｒ Ｎｕｍｂｅｒ−Ｓｉｎｇｌｅ Ｒａｄｉｏ）およびＭＧＷのＳＤＰ情報を有するＩＮＶＩＴＥメッセージをＩＭＳに送信することによってセッションのハンドオーバを開始する。ＳＴＮ−ＳＲはＳＲＶＣＣ手順がＰＳ−ＣＳハンドオーバのために採用されることになることを示す。

ステップ１４で、ＳＣＣ ＡＳが固定されたセッションをＳＴＮ−ＳＲに基づいて見つける。次いで、ＳＣＣ ＡＳはアクセス区切りが非定常状態下にあること、すなわち通話が初期の状態にあることを検出する。その後、ＳＣＣ ＡＳは前に保存されたＳＩＰ暫定応答をチェックし、該当の応答をＭＳＣサーバへと送信する。例えば、保存された応答が１８０ Ｒｉｎｇｉｎｇであれば、ＳＣＣ ＡＳは１８０ ＲｉｎｇｉｎｇメッセージをＭＳＣサーバに送信することになる。保存された応答が１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージであれば、ＳＣＣ ＡＳは１８３ Ｓｅｓｓｉｏｎ ＰｒｏｇｒｅｓｓメッセージをＭＳＣサーバに送信することになる。しかしながら、アクセス区切りが定常状態下にあることをＳＣＣ ＡＳが検出すれば元のＳＲＶＣＣ手順に従って動作することになることは理解されるはずである。

ステップ１５は２つの実例の選択肢、すなわち１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージと１８０ Ｒｉｎｇｉｎｇメッセージ例示している。１８０ Ｒｉｎｇｉｎｇメッセージのケースでは、ＭＳＣサーバは起呼側に呼び出し音を再生することになる。しかしながら、本発明がこれら２つのメッセージに限定されず、非定常状態のための他の応答メッセージを使用することもやはりあり得ることを理解されたい。

ステップ１６で、ＳＣＣ ＡＳはセッション・ハンドオーバ手順を完成させ続け、次いで遠隔末端を更新する。しかしながら、本発明で、セッションは非定常状態下にあるのでＵＰＤＡＴＥメッセージが唯一の選択肢であることに留意されたい。

ステップ１７で、元のアクセス区切りが非定常状態下にあるのでＳＣＣ ＡＳはアクセス区切りを解除するためにＢＹＥメッセージではなくＣＡＮＣＥＬメッセージを送信することになる。

図３はローカルＵＥが起呼側であるケースのみ対象にしているが、ローカルＵＥが被呼側であるケースにもやはり本発明が応用可能であり、信号のフローが図３のそれと同様であることに留意されたい。単純化するために、本明細書において、不必要にその詳細な説明はこれ以上行わない。

このようにして、本発明の解決策を適用することによって、通話／セッションの非定常状態の間でさえＳＲＶＣＣハンドオーバ手順が実施されることが可能になり、これは疑いなく元のＳＲＶＣＣ解決策に対する向上である。

本発明の一実施形態による、ＶｏＩＰ通話の非定常状態の間でＥ−ＵＴＲＡＮ（ＰＳドメイン）からＵＴＲＡＮ／ＧＥＲＡＮ（ＣＳドメイン）へと端末をハンドオーバさせるための方法が図４を参照しながら以下で説明される。本実施形態の方法は、例えば図１に示されたネットワーク・アーキテクチャに応用可能である。そのようなネットワーク・アーキテクチャについての説明は本明細書では繰り返されない。

図４に示されるように、最初にステップ４０１で、第１のネットワーク要素が端末から受信した通話セットアップ要求に基づいて通話を固定させ、端末へと返信される暫定応答および通話の状態を記憶する。本明細書において、第１のネットワーク要素は例えば図３のＳＣＣ ＡＳであってもよく、端末は例えば図３のローカルＵＥであってもよく、通話セットアップ要求は例えばＳＩＰプロトコルに準拠するＩＮＶＩＴＥメッセージであってもよく、暫定応答は例えばＳＩＰプロトコルに準拠する１８０ Ｒｉｎｇｉｎｇメッセージまたは１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージであってもよい。さらに、通話の状態が本実施形態における通話の初期の状態、すなわち通話が完全に首尾良くセットアップされていないときの状態を意味することに留意されたい。より具体的には、本実施形態によればかつ図３を参照すると、ローカルＵＥは通話をセットアップするように要求するためにＩＮＶＩＴＥメッセージをＳＣＣ ＡＳに送信する。ＩＮＶＩＴＥメッセージを受信した後に、ＳＣＣ ＡＳは通話を固定させ、１８０ Ｒｉｎｇｉｎｇメッセージまたは１８３ Ｓｅｓｓｉｏｎ ＰｒｏｇｒｅｓｓメッセージをローカルＵＥに送信し、送信した暫定応答メッセージおよびアクセス区切りの状態を保存する。

次にステップ４０２で、ハンドオーバが必要であることを端末が検出して測定報告をアクセス・ネットワークに送信する。本明細書おいて、アクセス・ネットワークは例えば図３のソースＥ−ＵＴＲＡＮであってもよい。より具体的には、本実施形態によればかつ図３を参照すると、Ｅ−ＵＴＲＡＮからＧＥＲＡＮ−ＵＴＲＡＮへのＳＲＶＣＣハンドオーバが必要であり得ることをローカルＵＥが検出し、したがって測定報告をソースＥ−ＵＴＲＡＮへと送信する。

次いでステップ４０３で、この測定報告がハンドオーバ条件に合致する間で信号ベアラを検出すると、アクセス・ネットワークは第２のネットワーク要素にハンドオーバの要求をすることを決定する。本明細書において、第２のネットワーク要素は例えば図３に示されるようなソースＭＭＥであってもよい。さらに、本実施形態では、信号ベアラの検出はＵＥのために確立されるＱＣＩ＝５のベアラを意味する。より具体的には、本実施形態によればかつ図３を参照すると、ソースＥ−ＵＴＲＡＮは、ＵＥの測定報告に基づき、場合によっては「ＳＲＶＣＣオペレーション可能」の表示に基づき、信号ベアラの存在を検出するとＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガするように決定してもよい。

音声ベアラを検出すると、ソースＥ−ＵＴＲＡＮがＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガすることもやはり決定することになり、このハンドオーバは通常のＳＲＶＣＣハンドオーバ手順に準拠することに留意されたい。詳細なプロセスについては３ＧＰＰ ＴＳ ２３．２１６を参照することが可能であり、不必要に詳しく説明されない。

次いでステップ４０４で、アクセス・ネットワークからハンドオーバの要求を受信した後に、信号ベアラを検出すると第２のネットワーク要素はＰＳからＣＳへのハンドオーバ要求を第１のネットワーク要素に送信することを決定する。本明細書において、ハンドオーバ要求は例えばＳＩＰプロトコルに準拠し、かつ単一無線音声通話継続性ハンドオーバを使用することを示す情報および通話パラメータを有するＩＮＶＩＴＥメッセージであってもよく、ここで、単一無線音声通話継続性ハンドオーバを使用することを示す情報は、例えばＰＳ−ＣＳハンドオーバのためのＳＲＶＣＣ手順を使用することを示すＳＴＮ−ＳＲであってもよく、前記通話パラメータは例えばメディア・ゲートウェイからのＳＤＰであってもよい。より具体的には、本実施形態によればかつ図３を参照すると、ソースＭＭＥは、ソースＥ−ＵＴＲＡＮからハンドオーバ要求を受信したとき、保存した包括的コンテナのタイプをチェックすることになる。コンテナのタイプがＳＲＶＣＣハンドオーバを示せば、信号ベアラ（ＱＣＩ＝５）が検出される、すなわちＳＣＣ ＡＳへと送信されたＳＴＮ−ＳＲのＳＤＰおよびＭＧＷを有するＩＮＶＩＴＥメッセージである限り、オペレータのローカル・ポリシーに基づいてＰＳ−ＣＳのＳＲＶＣＣハンドオーバ手順が開始されてもよい。本発明では、オペレータのローカル・ポリシーはＩＭＳ信号ベアラが存在するが音声ベアラが存在しないケースにおいてＭＭＥがＰＳ−ＣＳのＳＲＶＣＣハンドオーバ手順を開始することを許可すると仮定する。

先行技術ではステップ４０４の特定のプロセスが例えば以下のように実行され得ることに留意されたい。ＭＭＥがＳＲＶＣＣのＰＳ−ＣＳ要求をＭＳＣサーバに送信する。ＭＳＣサーバはハンドオーバの準備をして回線を確立し、その後、ＳＴＮ−ＳＲのＳＤＰ情報およびＭＧＷを有するＩＮＶＩＴＥメッセージをＳＣＣ ＡＳに送信する過程を通じてセッションのハンドオーバを開始する。しかしながら、本発明が上記のプロセスに限定されず、ハンドオーバを実施するためのＭＭＥとＳＣＣ ＡＳとの間のいずれの相互作用も当業者によって考案され得ることは理解されるはずである。

最後にステップ４０５で、前記ハンドオーバ要求の受信の後に、第１のネットワーク要素は、通話が非定常状態にあることを検出すれば前に記憶された暫定応答をチェックしこの暫定応答を第３のネットワーク要素へと送信し、それによってセッション・ハンドオーバ手順を完成させ、遠隔末端を更新する。本明細書において、第３のネットワーク要素は例えば図３に示されるようなＭＳＣサーバであってもよい。より具体的には、本実施形態によればかつ図３を参照すると、ＳＣＣ ＡＳは固定されたセッションをＳＴＮ−ＳＲに基づいて見つける。次いで、ＳＣＣ ＡＳはアクセス区切りが非定常状態、すなわち通話の初期の状態下にあることを検出する。その後、ＳＣＣ ＡＳは前に記憶されたＳＩＰ暫定応答をチェックし、該当の応答をＭＳＣサーバへと送信する。例えば、記憶された応答が１８０ Ｒｉｎｇｉｎｇであれば、ＳＣＣ ＡＳは１８０ ＲｉｎｇｉｎｇメッセージをＭＳＣサーバへと送信することになる、記憶された応答が１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージであれば、ＳＣＣ ＡＳは１８３ Ｓｅｓｓｉｏｎ ＰｒｏｇｒｅｓｓメッセージをＭＳＣサーバへと送信することになる。１８０ Ｒｉｎｇｉｎｇメッセージのケースであれば、ＭＳＣサーバは起呼側に呼び出し音を再生することになる。しかしながら、本発明がこれら２つのメッセージに限定されず、非定常状態のための他の応答メッセージを採用することもあり得ることは理解されるはずである。次いで、ＳＣＣ ＡＳはセッション・ハンドオーバ手順を完成させ続け、遠隔末端を更新する。

遠隔末端を更新するためにＵＰＤＡＴＥまたはｒｅ−ＩＮＶＩＴＥメッセージが使用され得ると３ＧＰＰ ＴＳ ２３．２１６に規定されているが、セッションが非定常状態下にあるので本発明ではＵＰＤＡＴＥメッセージが唯一の選択肢であることに留意されたい。

元のアクセス区切りが非定常状態にあるのでＳＣＣ ＡＳはアクセス区切りを解除するためにＢＹＥメッセージではなくＣＡＮＣＥＬメッセージを送信することにもやはり留意されたい。

上記の説明はローカルＵＥが起呼側であるケースのみを対象としているが、ローカルＵＥが被呼側であるケースにもやはり本実施形態が応用可能であり、方法のプロセスは上述のプロセスと同様である。単純化するために、その説明は本明細書に繰り返されない。

本発明の解決策を使用することによって、通話／セッションが非定常状態にあるときにＳＲＶＣＣハンドオーバ手順が実施されることもやはり可能であり、これが元のＳＲＶＣＣ解決策を向上させることが認められ得る。

同じ発明概念に基づき、本発明の他の態様によると、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができる、サービスの集中化および継続性を管理するネットワーク要素が提案される。このサービスの集中化および継続性を管理するネットワーク要素は図５を参照しながら以下で説明する。

図５は本発明の一実施形態による、サービスの集中化および継続性を管理するネットワーク要素５００を示している。ネットワーク５００は記憶手段５０１、および暫定応答チェック・送信手段５０２を含む。記憶手段５０１は端末に返信される暫定応答、および端末から受信した通話セットアップ要求に基づいて通話が固定させられた後の通話の状態を記憶するように構成される。例えば、ＵＥからＩＮＶＩＴＥメッセージを受信すると、ＳＣＣ ＡＳは通話を固定させ、１８０ Ｒｉｎｇｉｎｇまたは１８３ Ｓｅｓｓｉｏｎ ＰｒｏｇｒｅｓｓメッセージをＵＥへと送信する。その後、記憶手段５０１がＵＥへと送信されたメッセージおよびアクセス区切りの状態を記憶する。別のネットワーク要素（ソースＭＭＥ）からハンドオーバ要求を受信すると、通話が非定常状態にあることが検出されるケースでは、暫定応答チェック・送信手段５０２は前に記憶された暫定応答をチェックしこの暫定応答をさらに別のネットワーク要素（ＭＳＣサーバ）へと送信するように構成される。例えば、ＳＣＣ ＡＳがＳＴＮ−ＳＲのＳＤＰおよびＭＧＷを含むＩＮＶＩＴＥメッセージをソースＭＭＥから受信し、アクセス区切りが非定常状態下にあることを検出したとき、暫定応答チェック・送信手段５０２は前に記憶された１８０ Ｒｉｎｇｉｎｇまたは１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ応答メッセージをチェックし、該当の応答メッセージをＭＳＣサーバへと送信する。

実施において、本発明のネットワーク要素５００ならびにこれが含む記憶手段５０１および暫定応答チェック・送信手段５０２はソフトウェア、ハードウェアまたはそれらの組合せで実施されてもよい。例えば、当業者はこれらの構成要素を実施するために使用され得るマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、ＰＬＤおよび／またはＦＰＧＡなどといった多様なデバイスを熟知している。本実施形態のネットワーク要素のこれらそれぞれの構成要素は物理的に別々で実装されるが動作面で相互接続されることもあり得る。

動作において、図５と関連して例示される実施形態の、サービスの集中化および継続性を管理するネットワーク要素５００はＶｏＩＰ通話の非定常状態の間でＶｏＩＰ通話をＰＳからＣＳへとハンドオーバさせるために上述の方法を実施してもよい。このネットワーク要素５００を使用することによって、通話／セッションの非定常状態の間でＳＲＶＣＣハンドオーバ手順が実施されることが可能であり、したがって元のＳＲＶＣＣ解決策を向上させる。

同じ発明概念に基づき、本発明の別の態様によると、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができるアクセス装置が提案される。

図６は本発明の一実施形態によるアクセス装置６００を示しており、アクセス装置６００は決定手段６０１を含む。決定手段６０１は、端末から受信した測定報告がハンドオーバ条件に合致する間で信号ベアラを検出すると別のネットワーク要素（ソースＭＭＥ）にハンドオーバの要求をすることを決定するように構成される。例えば、ソースＥ−ＵＴＲＡＮによってＵＥから受信された測定報告がハンドオーバ条件に合致してかつ信号ベアラすなわちＱＣＩ＝５が検出されれば、決定手段６０１はソースＭＭＥにハンドオーバ要求を送信することを決定する。

実施において、本実施形態のアクセス装置６００ならびにこれが含む決定手段６０１はソフトウェア、ハードウェアまたはそれらの組合せで実施されてもよい。例えば、当業者はこれらの構成要素を実施するために使用され得るマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、ＰＬＤおよび／またはＦＰＧＡなどといった多様なデバイスを熟知している。

動作において、図６と関連して例示される実施形態のアクセス装置６００はＶｏＩＰ通話の非定常状態の間でＶｏＩＰ通話をＰＳからＣＳへとハンドオーバさせるために上述の方法を実施してもよい。このアクセス装置を使用することによって、通話／セッションの非定常状態の間でＳＲＶＣＣハンドオーバ手順が実施されることが可能であり、したがって元のＳＲＶＣＣ解決策を向上させる。

同じ発明概念に基づき、本発明の別の態様によると、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができる、端末のモビリティを管理するネットワーク要素が提案される。

図７は本発明の一実施形態による、端末のモビリティを管理するネットワーク要素７００を示しており、ネットワーク要素７００は決定手段７０１を含む。決定手段７０１はアクセス・ネットワークからハンドオーバの要求を受信した後に信号ベアラを検出するとＰＳからＣＳへのハンドオーバ要求を別のネットワーク要素に送信することを決定するように構成される。例えば、ソースＭＭＥがソースＥ−ＵＴＲＡＮからハンドオーバ要求を受信してかつ信号ベアラすなわちＱＣＩ＝５を検出したとき、決定手段７０１はＰＳからＣＳへのＳＲＶＣＣハンドオーバ手順を要求するための、ＳＴＮ−ＳＲのＳＤＰおよびＭＧＷを含むＩＮＶＩＴＥメッセージをＳＣＣ ＡＳへと送信することを決定する。

実施において、本実施形態のネットワーク要素７００ならびにこれが含む決定手段７０１はソフトウェア、ハードウェアまたはそれらの組合せで実施されてもよい。例えば、当業者はこれらの構成要素を実施するために使用され得るマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、ＰＬＤおよび／またはＦＰＧＡなどといった多様なデバイスを熟知している。

動作において、図７と関連して例示される実施形態のネットワーク要素７００はＶｏＩＰ通話の非定常状態の間でＶｏＩＰ通話をＰＳからＣＳへとハンドオーバさせるために上述の方法を実施してもよい。このネットワーク要素７００を使用することによって、通話／セッションの非定常状態の間でＳＲＶＣＣハンドオーバ手順が実施されることが可能であり、したがって元のＳＲＶＣＣ解決策を向上させる。

同じ発明概念に基づき、本発明のさらに別の態様によると、少なくとも１つの端末と、上記の実施形態で述べられたサービスの集中化および継続性を管理するネットワーク要素５００と、アクセス装置６００と、端末のモビリティを管理するネットワーク要素７００とを含む通信システムがやはり提案される。さらに、この通信システムは他のネットワーク要素、例えばＭＳＣサーバなどを含むこともやはりあり得る。

例えば、本実施形態の通信システムでは、ＶｏＩＰ通話の非定常状態の間でＰＳ−ＣＳのＳＲＶＣＣハンドオーバが実施されることが可能である。詳細な作業プロセスについては、本発明の実施形態によりＶｏＩＰ通話の非定常状態の間でＶｏＩＰ通話をＰＳからＣＳへとハンドオーバさせるための上述の方法を参照することが可能であり、その不必要に詳しい説明はこれ以上本明細書において行わない。

本発明の、ＶｏＩＰ通話の非定常状態の間でＶｏＩＰ通話をＰＳからＣＳへとハンドオーバさせるための方法、サービスの集中化および継続性を管理するネットワーク要素、アクセス装置、端末のモビリティを管理するネットワーク要素、ならびに少なくとも１つの端末と、サービスの集中化および継続性を管理するネットワーク要素と、アクセス装置と、端末のモビリティを管理するネットワーク要素とを含む通信システムの実例の実施形態が上記で詳述されているが、上記の実施形態は網羅的ではなく、当業者は本発明の精神および範囲の中で数多くの変更および修正を為すことが可能である。したがって、本発明はこれらの実施形態に限定されず、その範囲は添付の特許請求の範囲によってのみ定義される。

Claims (14)

1. 通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせるための方法であって、
   該端末から受信した該通話のセットアップ要求に基づいて第１のネットワーク要素が該通話を固定させ、かつ該端末へと返信される暫定応答及び該通話の状態を記憶するステップと、
   ハンドオーバが必要であることを該端末が検出し測定報告をアクセス・ネットワークに送信するステップと、
   該測定報告がハンドオーバ条件に合致するという表示に基づいて、信号ベアラを検出すると、該アクセス・ネットワークが第２のネットワーク要素にハンドオーバの要求をすることを決定するステップと、
   該アクセス・ネットワークからハンドオーバの要求を受信した後に、該信号ベアラを検出すると該第２のネットワーク要素がＰＳからＣＳへのハンドオーバ要求を該第１のネットワーク要素へと送信することを決定するステップと、
   該ハンドオーバ要求の受信後に、該第１のネットワーク要素が、該通話が該非定常状態にあることを検出すれば、前に記憶された暫定応答をチェックし該暫定応答を第３のネットワーク要素へと送信し、それによってセッション・ハンドオーバ手順を完成させ、遠隔末端を更新するステップとを含む方法。
   
2. 請求項１に記載の方法において、
   該ハンドオーバがＳＲＶＣＣハンドオーバであり、かつ／又は
   該通話の該非定常状態が、該通話が完全にセットアップされていないときの状態であり、かつ／又は
   該パケット交換ドメインがＥ−ＵＴＲＡＮネットワークによって提供され、該回線交換ドメインがＧＥＲＡＮ又はＵＴＲＡＮネットワークによって提供され、かつ／又は
   ＳＲＶＣＣハンドオーバを使用することを示す情報がＳＴＮ−ＳＲであり、かつ／又は
   通話のパラメータがＳＤＰであり、かつ／又は
   該信号ベアラの検出が、ＱＣＩの値が５に等しいと検出することを意味する、方法。
   
3. 請求項１又は２に記載の方法において、
   該第１のネットワーク要素がＳＣＣ ＡＳであり、かつ／又は該アクセス・ネットワークがソースＥ−ＵＴＲＡＮであり、かつ／又は該第２のネットワーク要素がソースＭＭＥであり、かつ／又は該第３のネットワーク要素がＭＳＣサーバである、方法。
   
4. 請求項１又は２に記載の方法において、
   該通話のセットアップ要求がＩＮＶＩＴＥメッセージであり、かつ／又は該暫定応答が１８０ Ｒｉｎｇｉｎｇメッセージ又は１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージであり、かつ／又は該ハンドオーバ要求が、ＳＲＶＣＣハンドオーバを使用することを示す情報及び該通話のパラメータを備えたＩＮＶＩＴＥメッセージである、方法。
   
5. 通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができる、サービスの集中化及び継続性を管理するネットワーク要素であって、
   該端末へと返信される暫定応答、及び該通話が該端末から受信された該通話のセットアップ要求に基づいて固定させられた後の該通話の状態を記憶するための記憶手段と、
   別のネットワーク要素からハンドオーバ要求を受信すると、該通話が該非定常状態にあると検出されるケースでは、前に記憶された暫定応答をチェックし該暫定応答をさらに別のネットワーク要素へと送信するための暫定応答チェック・送信手段とを含むネットワーク要素。
   
6. 通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができる、端末のモビリティを管理するネットワーク要素であって、
   アクセス・ネットワークからハンドオーバの要求を受信した後に、信号ベアラを検出するとＰＳからＣＳへのハンドオーバ要求を第１の別のネットワーク要素へと送信することを決定するための決定手段を含み、
   該ＰＳからＣＳへのハンドオーバ要求の受信後に、該第１の別のネットワーク要素が、該通話が該非定常状態にあることを検出すれば、該第１の別のネットワーク要素が、前に記憶された暫定応答をチェックし該暫定応答を第２の別のネットワーク要素へと送信し、それによってセッション・ハンドオーバ手順を完成させ、遠隔末端を更新し、
   該信号ベアラの検出が、ＱＣＩの値が５に等しいと検出することを意味する、ネットワーク要素。
   
7. 請求項５に記載のネットワーク要素において、
   該別のネットワーク要素がソースＭＭＥであり、かつ／又は該さらに別のネットワーク要素がＭＳＣサーバである、ネットワーク要素。
   
8. 請求項５又は６に記載のネットワーク要素において、
   該ハンドオーバがＳＲＶＣＣハンドオーバであり、かつ／又は
   該通話の該非定常状態が、該通話が完全にセットアップされていないときの状態であり、かつ／又は
   該パケット交換ドメインがＥ−ＵＴＲＡＮネットワークによって提供され、該回線交換ドメインがＧＥＲＡＮ又はＵＴＲＡＮネットワークによって提供され、かつ／又は
   ＳＲＶＣＣハンドオーバを使用することを示す情報がＳＴＮ−ＳＲであり、かつ／又は
   通話のパラメータがＳＤＰである、ネットワーク要素。
   
9. 請求項５に記載のネットワーク要素において、
   該通話のセットアップ要求がＩＮＶＩＴＥメッセージであり、かつ／又は該暫定応答が１８０ Ｒｉｎｇｉｎｇメッセージ又は１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージであり、かつ／又は該ハンドオーバ要求が、ＳＲＶＣＣハンドオーバを使用することを示す情報及び該通話のパラメータを備えたＩＮＶＩＴＥメッセージである、ネットワーク要素。
   
10. 請求項６に記載のネットワーク要素において、
    該ネットワーク要素がソースＭＭＥであり、かつ／又は該アクセス・ネットワークがソースＥ−ＵＴＲＡＮであり、かつ／又は該別のネットワーク要素がＳＣＣ ＡＳである、ネットワーク要素。
    
11. 請求項６に記載のネットワーク要素において、
    該ハンドオーバ要求が、ＳＲＶＣＣハンドオーバを使用することを示す情報及び該通話のパラメータを備えたＩＮＶＩＴＥメッセージである、ネットワーク要素。
    
12. アクセス装置と別のネットワーク要素と第１のネットワーク要素と第２のネットワーク要素とを含むネットワーク・アーキテクチャにおいて、通話の非定常状態の間で端末をパケット交換ドメインから回線交換ドメインへとハンドオーバさせることができるアクセス装置であって、
    該端末から受信した測定報告がハンドオーバ条件に合致するという表示に基づいて、信号ベアラを検出すると、該別のネットワーク要素にハンドオーバの要求をすることを決定するための決定手段を含み、
    該別のネットワーク要素が、該アクセス装置からハンドオーバの要求を受信した後に、信号ベアラを検出するとＰＳからＣＳへのハンドオーバ要求を該第１のネットワーク要素へと送信することを決定し、
    該ＰＳからＣＳへのハンドオーバ要求の受信後に、該第１のネットワーク要素が、該通話が該非定常状態にあることを検出すれば、該第１のネットワーク要素が、前に記憶された暫定応答をチェックし該暫定応答を第２のネットワーク要素へと送信し、それによってセッション・ハンドオーバ手順を完成させ、遠隔末端を更新し、
    該信号ベアラの検出が、ＱＣＩの値が５に等しいと検出することを意味する、アクセス装置。
    
13. 請求項１２に記載のアクセス装置において、
    該アクセス装置がソースＥ−ＵＴＲＡＮ内部にあり、かつ／又は
    該別のネットワーク要素がソースＭＭＥであり、かつ／又は
    該ハンドオーバがＳＲＶＣＣハンドオーバであり、かつ／又は
    該通話の該非定常状態が、該通話が完全にセットアップされていないときの状態であり、かつ／又は
    該パケット交換ドメインがＥ−ＵＴＲＡＮネットワークによって提供され、該回線交換ドメインがＧＥＲＡＮ又はＵＴＲＡＮネットワークによって提供され、かつ／又は
    ＳＲＶＣＣハンドオーバを使用することを示す情報がＳＴＮ−ＳＲである、アクセス装置。
    
14. 少なくとも１つの端末と、
    請求項５に記載のネットワーク要素と、
    請求項１３に記載のアクセス装置と、
    請求項６に記載のネットワーク要素とを少なくとも含む通信システム。

Images