(57)【要約】  ＩＭＳ（ＩＰマルチメディアサブシステム）アーキテクチャにおけるモバイル端末に対するネットワークベースのモビリティをサポートする方法を提供する。モバイル端末はフェムトセルまたはマクロセル、すなわちソースセルに接続され、モバイル端末の実際のセッションのハンドオーバが別のフェムトセルまたはマクロセル、すなわちターゲットセルへと実行される。フェムトセルおよびマクロセルがｅＭＳＣサーバ（ＩＭＳ集中化サービスのために拡張された移動通信交換局サーバ）機能を備えるかまたはｅＭＳＣサーバ機能に接続される。ソースセルのｅＭＳＣサーバ機能はソースユーザエージェントをホストし、ターゲットセルのｅＭＳＣサーバ機能はターゲットユーザエージェントをホストする。本方法は、ソースユーザエージェントが実際のハンドオーバを実行する前に直接または間接に前記ターゲットユーザエージェントとコンタクトし、ソースユーザエージェントが、ハンドオーバ関連情報を交換することによって、対応するアクセスネットワークとともにターゲットユーザエージェントを準備することを特徴とする。
2011530916.tif 000002
【特許請求の範囲】
【請求項１】
ＩＭＳ（ＩＰマルチメディアサブシステム）アーキテクチャにおけるモバイル端末に対するネットワークベースのモビリティをサポートする方法において、
前記モバイル端末はフェムトセルまたはマクロセル、すなわちソースセルに接続され、前記モバイル端末の実際のセッションのハンドオーバが別のフェムトセルまたはマクロセル、すなわちターゲットセルへと実行され、
前記フェムトセルおよび前記マクロセルがｅＭＳＣサーバ（ＩＭＳ集中化サービスのために拡張された移動通信交換局サーバ）機能を備えるかまたはｅＭＳＣサーバ機能に接続され、
前記ソースセルのｅＭＳＣサーバ機能はソースユーザエージェントをホストし、前記ターゲットセルのｅＭＳＣサーバ機能はターゲットユーザエージェントをホストし、
前記ソースユーザエージェントが実際のハンドオーバを実行する前に直接または間接に前記ターゲットユーザエージェントとコンタクトし、前記ソースユーザエージェントが、ハンドオーバ関連情報を交換することによって、対応するアクセスネットワークとともに前記ターゲットユーザエージェントを準備することを特徴とする、ＩＭＳアーキテクチャにおけるモバイル端末に対するネットワークベースのモビリティをサポートする方法。
【請求項２】
前記ハンドオーバが、前記ソースセルのｅＭＳＣサーバ機能によって要求され、前記ハンドオーバ要求が、前記ソースユーザエージェントの加入者識別子および／またはセッション識別子を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ハンドオーバ要求が、前記ターゲットセルのアクセスネットワークに関する情報を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ターゲットセルの前記アクセスネットワーク関連情報が、前記ターゲットセルのセルＩＤ、信号強度、ＲＡＴ（Radio Access Technology）タイプ、ＳＳＩＤ（Service Set Identifier）、ＲＦ（無線周波数）チャネル、測定レポートおよび／または負荷に関する情報を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記ターゲットセルのｅＭＳＣサーバ機能を判定し発見するハンドオーバ決定が、前記ハンドオーバ要求に含まれる前記アクセスネットワーク関連情報に基づいて行われることを特徴とする請求項３または４に記載の方法。
【請求項６】
前記ハンドオーバ決定が、前記ソースセルのｅＭＳＣサーバ機能から受信された前記アクセスネットワーク関連情報に基づいて、前記ＩＭＳアーキテクチャにホストされたアプリケーションサーバによって実行されることを特徴とする請求項５に記載の方法。
【請求項７】
前記アプリケーションサーバが、前記ソースセルのｅＭＳＣサーバ機能から受信された前記アクセスネットワーク関連情報に基づいて、前記ターゲットセルのｅＭＳＣサーバ機能を発見することを特徴とする請求項６に記載の方法。
【請求項８】
前記アプリケーションサーバが、ローカルに前記ハンドオーバ決定を実行することを特徴とする請求項６または７に記載の方法。
【請求項９】
前記アプリケーションサーバが、発見機能に照会することによって前記ハンドオーバ決定を実行することを特徴とする請求項６または７に記載の方法。
【請求項１０】
前記ハンドオーバの決定が、前記ソースセルのｅＭＳＣサーバ機能によって実行されることを特徴とする請求項１または２に記載の方法。
【請求項１１】
前記ソースセルのｅＭＳＣサーバ機能が、前記ターゲットセルのｅＭＳＣサーバ機能のアドレスの明示的または暗黙的な参照を実行することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ソースセルのｅＭＳＣサーバ機能が、前記ターゲットセルのｅＭＳＣサーバ機能のアドレスを取得するために、アプリケーションサーバまたは専用の発見／参照機能に問い合わせることを特徴とする請求項１０または１１に記載の方法。
【請求項１３】
前記専用の発見／参照機能が、セッション確立プロトコル（ＳＩＰ）、ドメインネームシステム（ＤＮＳ）プロトコル、Ｄｉａｍｅｔｅｒ／Ｒａｄｉｕｓプロトコルおよび／またはＬＤＡＰ（Lightweight Directory Access Protocol）プロトコルに基づくことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ソースセルのｅＭＳＣサーバ機能がＩＭＳに登録する際に、アプリケーションサーバが、可能性のあるマクロハンドオーバを担当するターゲットセルのｅＭＳＣサーバ機能を判定し、該担当するターゲットセルのｅＭＳＣサーバ機能のアドレスを前記ソースセルのｅＭＳＣサーバ機能へ送信することを特徴とする請求項１０ないし１３のいずれか１項に記載の方法。
【請求項１５】
前記ソースセルのｅＭＳＣサーバ機能が、アクセスネットワークによって受信された情報に基づいて、ターゲットセルのｅＭＳＣサーバ機能のＩＭＳルーティング可能なＳＩＰ識別子または名称を自動的に導出することを特徴とする請求項１０ないし１４のいずれか１項に記載の方法。
【請求項１６】
前記ターゲットセルのｅＭＳＣサーバ機能が、前記アプリケーションサーバから、または前記ソースセルのｅＭＳＣサーバ機能からハンドオーバ要求を受信した後、ＩＭＳに加入者を登録している前記モバイル端末の該加入者のユーザプロファイルをダウンロードすることによって、前記ハンドオーバ要求を処理することを特徴とする請求項６ないし１５のいずれか１項に記載の方法。
【請求項１７】
前記アプリケーションサーバが、応答メッセージによって、前記ターゲットユーザエージェントにＩＭＳ登録成功をシグナリングすることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ターゲットユーザエージェントが、メディアパスのセッション転送を実行するためのインバイトメッセージを前記アプリケーションサーバへ送信し、該インバイトメッセージが、引き継ぐべきセッションの識別子を含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記インバイトメッセージが、前記ソースセルのｅＭＳＣサーバ機能および前記ターゲットセルのｅＭＳＣサーバ機能の両方への前記セッションメディアのバイキャスティングが許容されることを示す追加フラグを含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記アプリケーションサーバが、リモートアクセスレグを更新し、前記インバイトメッセージに肯定応答するメッセージを前記ターゲットセルのｅＭＳＣサーバ機能へ送信することを特徴とする請求項１８または１９に記載の方法。
【請求項２１】
前記ソースセルのｅＭＳＣサーバ機能が、ターゲットセルのｅＭＳＣサーバ機能における前記セッションハンドオーバの準備の成功が通知された後、該セッションを解放することを特徴とする請求項１８ないし２０のいずれか１項に記載の方法。
【請求項２２】
ＳＩＰ、Ｄｉａｍｅｔｅｒ／Ｒａｄｉｕｓ、コンテキスト転送（Context Transfer）またはＳＣＴＰ（Stream Control Transmission Protocol）が、ハンドオーバの指示および／または準備のプロトコルとして使用されることを特徴とする請求項１ないし２１のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＭＳ（ＩＰマルチメディアサブシステム）アーキテクチャにおけるモバイル端末に対するネットワークベースのモビリティをサポートする方法に関する。前記モバイル端末はフェムトセルまたはマクロセル、すなわちソースセルに接続され、前記モバイル端末の実際のセッションのハンドオーバが別のフェムトセルまたはマクロセル、すなわちターゲットセルへと実行され、前記フェムトセルおよび前記マクロセルがｅＭＳＣサーバ（ＩＭＳ集中化サービスのために拡張された移動通信交換局サーバ）機能を備えるかまたはｅＭＳＣサーバ機能に接続され、前記ソースセルのｅＭＳＣサーバ機能はソースユーザエージェントをホストし、前記ターゲットセルのｅＭＳＣサーバ機能はターゲットユーザエージェントをホストする。
【背景技術】
【０００２】
モバイルセルラネットワークにおいて、モバイル端末（３ＧＰＰでは一般にユーザ装置（ＵＥ）と称する）は通常、同時に複数のマクロセル基地局（ＢＳ）のカバレジエリア内に位置する。どのＢＳがＵＥにサービスするかの決定はさまざまな要因に依存する。最も重要な要因は、ＵＥと、問題となっているＢＳとの間の無線チャネルの品質である。ＵＥとサービングＢＳとの間の無線チャネルが所定しきい値を下回って悪化すると、より良好な無線チャネル品質を有する別のＢＳにＵＥをハンドオーバする決定を行い、ハンドオーバプロセスを開始しなければならない。
【０００３】
さらに、現在、モバイルネットワーク事業者は、事業者のカスタマの宅内に設置されたいわゆるフェムトセル（ホーム基地局、ホームＢＴＳ、ピコセル、ホームＮＢ、あるいはフェムト無線基地局とも呼ばれる）を配備することに関心を示している（非特許文献１を参照）。このようなホーム基地局は、ＷｉＦｉ基地局と同様に、通常のブロードバンドインターネットコネクションに接続されるが、無線インタフェースは、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＵＭＴＳ（Universal Mobile Telecommunications System）あるいは３ＧＰＰ  ＬＴＥ（Long Term Evolution）のような広域セルラネットワーク標準に基づいている。
【０００４】
一般的な場面において、音声通話中のＵＥが、現在使用中のフェムトセル、例えばＩＭＳ対応のフェムトセルのカバレジエリアの境界に近づくと、事業者のマクロネットワークの通常のＢＳにハンドオーバされなければならない。さもなければ、フェムトセルのカバレジが完全に失われると、通話が切れてしまう。このようなＭＳＣ間ハンドオーバのための標準の手続きは、ハンドオーバ後のシグナリングおよび音声トランスポートに関与する２つのＭＳＣ（移動通信交換局）サーバ機能の間での直接コネクションに依拠する。フェムトセルの場合、ＭＳＣサーバ機能は組み込まれているので、音声トラフィックは、ネットワークからフェムトセルへ、およびそこから他方のＭＳＣサーバ機能へとルーティングされる必要がある。すなわち、トラフィックはＤＳＬ（デジタル加入者回線）コネクション経由で２度トランスポートされる。さらに、ＭＳＣサーバ機能とそのエリア内のすべてのフェムトセルとの間のアソシエーションが必要となる。
【０００５】
３ＧＰＰのリリース８では、新しいタイプのＭＳＣが規定された。これは、ＣＳ（circuit switched, 回線交換）音声呼をＩＭＳ呼に変換することができる。すなわち、ＳＩＰ（セッション確立プロトコル）ユーザエージェントが、ユーザのためにＭＳＣサーバ上で動作する。この新しいタイプのＭＳＣは、ＩＭＳ集中化サービスのために拡張されたＭＳＣサーバ（ｅＭＳＣ）と呼ばれる。ただしこの場合でも、ＭＳＣ間ハンドオーバはＩＭＳレベルでは依然として解決されず、代わりに旧式（レガシー）のＥインタフェースに依拠する。Ｅインタフェースは、２つのＭＳＣ間の通信を提供し、ＭＡＰ／Ｅプロトコルを用いてソースＭＳＣとターゲットＭＳＣとの間でハンドオーバ関連データを交換する。
【０００６】
ＩＭＳフェムトセルは、ｅＭＳＣと同様にＩＭＳ集中化サービスのために拡張されたフェムトセルである。しかし、ＳＩＰ／ＩＭＳフェムトセルのアクティブセッションには、ＳＩＰ／ＩＭＳベースのモビリティが存在しない。特にフェムトセルとマクロセルとの間やｅＭＳＣサーバ機能間において、このモビリティがＭＡＰ（モバイルアプリケーションパート）プロトコルによって処理できない場合、例えば、ＭＡＰインタフェースのないＭＳＣサーバ間や、相異なる管理ドメインのＭＳＣサーバ間では、そのようなモビリティが存在しない。
【０００７】
この問題は、ＩＭＳサービス連続性（IMS Service Continuity）自体は２つのＳＩＰユーザエージェント間のパスの切替ができるだけであるということから生じる。しかし、ターゲットｅＭＳＣサーバ機能はさらに、どのＢＳに呼をルーティングすべきかが通知される必要がある。さらに、ｅＭＳＣサーバ機能のデフォルトの登録は予測できないので、転送元ｅＭＳＣサーバ機能（ソースＳＩＰユーザエージェント）は、転送先ｅＭＳＣサーバ機能（ターゲットＳＩＰユーザエージェント）において呼をルーティングすべき登録されたコンタクトポイント（point of contact）を有しない。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】Airvana whitepaper, “Femtocells: Transforming The Indoor Experience”（フェムトセル：屋内エクスペリエンスの転換）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、本発明の目的は、頭書のようなＩＭＳアーキテクチャにおけるモバイル端末に対するネットワークベースのモビリティをサポートする方法において、実施の容易なメカニズムを使用することにより、ｅＭＳＣサーバ機能および／またはフェムトセル間のシームレスなハンドオーバがＩＭＳレベルで実現されるような改良およびさらなる展開を行うことである。
【課題を解決するための手段】
【００１０】
本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、以下のことを特徴とする。すなわち、前記ソースユーザエージェントが実際のハンドオーバを実行する前に直接または間接に前記ターゲットユーザエージェントとコンタクトし、前記ソースユーザエージェントが、ハンドオーバ関連情報を交換することによって、対応するアクセスネットワークとともに前記ターゲットユーザエージェントを準備する。
【００１１】
本発明によって初めて認識されたこととして、ｅＭＳＣサーバ内および／またはフェムトセル内に位置する２つの（ソースおよびターゲット）ｅＭＳＣサーバ機能間で、プロトコル独立なメッセージ交換を適用することによって、ＭＳＣ間ハンドオーバを提供することができる。また、認識されたこととして、ソースユーザエージェントが実際のハンドオーバを実行する前に直接または間接にターゲットユーザエージェントとコンタクトすると、ｅＭＳＣサーバ機能および／またはフェムトセル間のシームレスなハンドオーバを実現することができる。ソースユーザエージェントは、ハンドオーバ関連情報を交換することによって、対応するアクセスネットワークとともにターゲットユーザエージェントを準備する。こうして、ユーザエージェントをホストするターゲットセルのｅＭＳＣサーバ機能およびターゲットネットワークを準備する追加的なシグナリングにより、シームレスなハンドオーバが可能となる。
【００１２】
本発明による方法は、例えば、ＩＭＳアーキテクチャにおいて好適に適用可能である。ただし言うまでもなく、本発明は、２つのユーザエージェント、特にＳＩＰユーザエージェントの間のいかなるシームレスなセッションハンドオーバにも適用可能である。この場合、ユーザエージェントの少なくとも一方がネットワーク内に位置し、それにより、実際のセッションハンドオーバの前にターゲットエンティティを準備するために、ソースからターゲットユーザエージェントへの追加的シグナリングに依拠する。本発明による方法は、同じアクセスネットワークのＳＩＰ／ＩＭＳベースのエンティティ（たとえば、３ＧＰＰ  ｅＭＳＣ、３ＧＰＰ  Ｈ（ｅ）ＮＢ）の間や、アクセスシステム間（例えば、２Ｇ／３Ｇ／ＬＴＥと、ＷｉＭＡＸまたはＷＬＡＮとの間）のモビリティのために使用可能である。また、本方法は、例えば負荷分散の理由で、あるいは障害迂回メカニズムとして、同じネットワークドメインのエンティティ間におけるＳＩＰ／ＩＭＳベースのハンドオーバのために使用可能である。したがって、以下でＩＭＳまたはＳＩＰに言及しながら本発明を説明する場合、この言及は単なる例示的な言及と解すべきであり、いかなる意味でも本発明を限定する意図が全くないことははっきりと指摘しておかなければならない。
【００１３】
好ましい実施形態において、ハンドオーバは、ソースセルのｅＭＳＣサーバ機能によって要求される。ハンドオーバ要求は、ソースユーザエージェントの加入者識別子および／またはセッション識別子を含んでもよい。こうして、ハンドオーバ要求は、発信ユーザおよび転送すべきセッションを識別する情報を提供する。
【００１４】
これに加えて、あるいは別法として、ハンドオーバ要求は、ターゲットセルのアクセスネットワークに関する情報を含んでもよい。ハンドオーバ要求は、ターゲットエンティティがアクセスネットワークリソース（例えば無線およびアクセスベアラ）を設定することを可能にするために重要なアクセスネットワーク情報を、ターゲットセルのｅＭＳＣサーバ機能に提供する。ターゲットセルのアクセスネットワーク関連情報は、例えば、以下のものに限定されないが、ターゲットセルのセルＩＤ、信号強度、ＲＡＴ（Radio Access Technology）タイプ、ＳＳＩＤ（Service Set Identifier）、ＲＦ（無線周波数）チャネル、測定レポートおよび／または負荷に関する情報を含んでもよい。
【００１５】
ターゲットセルのｅＭＳＣサーバ機能を判定し発見するハンドオーバ決定に関して、決定は、ハンドオーバ要求に含まれるアクセスネットワーク関連情報に基づいて行うようにしてもよい。上記のようなアクセスネットワーク情報が、加入者識別子および／またはセッション識別子とともに、ターゲットセルのｅＭＳＣサーバ機能を選択するプロセスへの入力として使用されてもよい。
【００１６】
好ましい実施形態において、ハンドオーバ決定は、ソースセルのｅＭＳＣサーバ機能から受信されたアクセスネットワーク関連情報に基づいて、ＩＭＳアーキテクチャにホストされたアプリケーションサーバまたは類似のアプリケーションサーバ機能によって実行されてもよい。アプリケーションサーバは、セッションをアンカリングし、そのセッションのアクセスネットワーク間でセッション転送を実行することを担当するように設定されてもよい。
【００１７】
有利な態様として、アプリケーションサーバは、ソースセルのｅＭＳＣサーバ機能から受信されたアクセスネットワーク関連情報に基づいて、ターゲットセルのｅＭＳＣサーバ機能を発見する。
【００１８】
アプリケーションサーバは、ローカルに、または、発見機能、例えばホーム加入者サーバ（Home Subscriber Server, ＨＳＳ）に照会することによって、ハンドオーバ決定を実行してもよい。
【００１９】
別の実施形態において、ハンドオーバの決定は、ソースセルのｅＭＳＣサーバ機能によって実行されてもよい。すなわち、ソースセルのｅＭＳＣサーバ機能が、アプリケーションサーバまたは類似のアプリケーションサーバ機能を経由せずに、ターゲットｅＭＳＣサーバ機能と「直接に」通信する。これにより、ターゲットセルのｅＭＳＣサーバ機能の選択は、ソースセルのｅＭＳＣサーバ機能によって行われてもよい。
【００２０】
ターゲットｅＭＳＣサーバ機能のルーティング可能な識別を取得することに関して、ソースセルのｅＭＳＣサーバ機能は、ハンドオーバ要求の前にターゲットセルのｅＭＳＣサーバ機能のアドレスの明示的または暗黙的な参照を実行してもよい。
【００２１】
有利な態様として、ソースセルのｅＭＳＣサーバ機能は、ターゲットセルのｅＭＳＣサーバ機能のアドレスを取得するために、アプリケーションサーバまたは専用の発見／参照機能に問い合わせてもよい。この目的のため、専用の発見／参照機能は、セッション確立プロトコル（ＳＩＰ）、ドメインネームシステム（ＤＮＳ）プロトコル、Ｄｉａｍｅｔｅｒ／Ｒａｄｉｕｓプロトコルおよび／またはＬＤＡＰ（Lightweight Directory Access Protocol）プロトコルに基づいてもよい。専用機能への参照要求は、必要な情報、特に加入者識別子およびセッション識別子とともに、ターゲットのセルＩＤ、ＳＳＩＤ、ＲＦチャネル等のようなアクセスネットワーク関連情報を含んでもよい。
【００２２】
別の可能性として、ソースセルのｅＭＳＣサーバ機能がＩＭＳに登録する際に、アプリケーションサーバが、可能性のあるマクロハンドオーバを担当するターゲットセルのｅＭＳＣサーバ機能を判定し、担当するターゲットセルのｅＭＳＣサーバ機能のアドレスをソースセルのｅＭＳＣサーバ機能へ送信する。
【００２３】
これに加えて、あるいは別法として、ソースセルのｅＭＳＣサーバ機能は、アクセスネットワークによって受信された情報に基づいて、ターゲットセルのｅＭＳＣサーバ機能のＩＭＳルーティング可能なＳＩＰ識別子または名称を自動的に導出してもよい。
【００２４】
好ましい実施形態によれば、ターゲットセルのｅＭＳＣサーバ機能は、アプリケーションサーバから、またはソースセルのｅＭＳＣサーバ機能からハンドオーバ要求を受信した後、ＩＭＳに加入者を登録しているモバイル端末の加入者のユーザプロファイルをダウンロードすることによって、ハンドオーバ要求を処理する。
【００２５】
アプリケーションサーバにアンカリングされたＩＭＳ登録の成功をターゲットユーザエージェントに通知することに関して、アプリケーションサーバは、応答メッセージによって、ターゲットユーザエージェントにＩＭＳ登録成功をシグナリングしてもよい。
【００２６】
有利な態様として、ターゲットユーザエージェントは、メディアパスのセッション転送を実行するためのインバイト（invite）メッセージをアプリケーションサーバへ送信する。インバイトメッセージは、引き継ぐべきセッションの識別子を含む。
【００２７】
データ送信中の損失を効率的に回避するため、インバイトメッセージは、ソースセルのｅＭＳＣサーバ機能およびターゲットセルのｅＭＳＣサーバ機能の両方へのセッションメディアのバイキャスティングが許容されることを示す追加フラグを含んでもよい。さらに、インバイトメッセージまたはリインバイト（re-invite）メッセージは、バイキャスティングのための最大タイマオプションをサポートしてもよい。バイキャスティングは、例えばＳＩＰシグナリングにおける明示的な指示によって、ソースまたはターゲットアクセスから中止されることが可能である。
【００２８】
ハンドオーバの効率的な処理に関して、アプリケーションサーバは、リモートアクセスレグ（remote access leg）を更新し、インバイトメッセージに肯定応答するメッセージをターゲットセルのｅＭＳＣサーバ機能へ送信してもよい。
【００２９】
最後に、ソースセルのｅＭＳＣサーバ機能は、ターゲットセルのｅＭＳＣサーバ機能におけるセッションハンドオーバの準備の成功が通知された後、セッションを解放してもよい。
【００３０】
有利な態様として、ＳＩＰ、Ｄｉａｍｅｔｅｒ／Ｒａｄｉｕｓ、コンテキスト転送（Context Transfer）またはＳＣＴＰ（Stream Control Transmission Protocol）が、ハンドオーバの指示および／または準備のプロトコルとして、特にハンドオーバの要求および肯定応答について、使用されてもよい。
【００３１】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、請求項１に従属する諸請求項を参照しつつ、図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００３２】
【図１】フェムトセルとｅＭＳＣサーバとの間でハンドオーバを実行する適用場面の一例を示す代表的なネットワークアーキテクチャの模式図である。
【図２】２つのｅＭＳＣサーバ間でハンドオーバを実行するもう１つの適用場面の一例を示す代表的なネットワークアーキテクチャの模式図である。
【図３】本発明によるネットワークベースのモビリティをサポートする方法の一実施形態を示す模式図である。
【図４】ＨＯ＿ＲＥＱＵＥＳＴメッセージを用いた、図３による実施形態の例示的な呼フローを示す図である。
【図５】ＨＯ＿ＲＥＱＵＥＳＴメッセージを従来のＳＩＰ  ＲＥＦＥＲメッセージにマッピングする、図３による実施形態の例示的な呼フローを示す図である。
【図６】本発明によるネットワークベースのモビリティをサポートする方法の別の実施形態を示す模式図である。
【図７】アプリケーションレベルの登録を用いることによりターゲットｅＭＳＣサーバを発見する、図６による実施形態の例示的な呼フローを示す図である。
【図８】ＮＯＴＩＦＹメッセージを用いた、図６による実施形態の例示的な呼フローを示す図である。
【発明を実施するための形態】
【００３３】
図１は、フェムトセルとｅＭＳＣサーバとの間でハンドオーバを実行する適用場面の一例を示す代表的なネットワークアーキテクチャの模式図を示している。図１に示すように、ＵＥがフェムトアクセスポイント経由でＩＭＳネットワークに接続され、ＩＭＳネットワークはＳＣＣ  ＡＳ、ＨＳＳおよびＣＳＣＦを有する。フェムトアクセスポイントは組み込みのＭＳＣを有し、ユーザのためにソースＳＩＰユーザエージェント（SIP user agent, ＳＩＰ  ＵＡ）をホストする。ハンドオーバを実行する場合、図１に示すように、ターゲットｅＭＳＣサーバがターゲットＳＩＰ  ＵＡをホストする。ハンドオーバ後、ＵＥはＢＴＳ（Base Transceiver System, ベーストランシーバシステム）またはノードＢおよびＢＳＣ（Base Station Controller, 基地局コントローラ）またはＲＮＣ（Radio Network Controller, 無線ネットワークコントローラ）経由でターゲットｅＭＳＣサーバに接続され、ターゲットｅＭＳＣサーバはＩＭＳアーキテクチャにリンクされる。フェムトアクセスポイントおよびｅＭＳＣサーバは、レガシーＣＳ  ＵＭＴＳ電話システムとパケット交換ＩＰ  ＩＭＳネットワークとの間のギャップを橋渡しするネットワーク要素である。
【００３４】
図２は、ＵＥのハンドオーバを実行するもう１つの適用場面の一例を示す代表的なネットワークアーキテクチャの模式図を示している。この適用場面は、２つのｅＭＳＣサーバ間でハンドオーバを実行する点で、図１に例示した適用場面とは区別される。したがって、図１とは異なり、図２は、ＩＭＳネットワークに接続されたソースおよびターゲットｅＭＳＣサーバを示している。
【００３５】
図３は、本発明によるネットワークベースのモビリティをサポートする方法の一実施形態を示す模式図を示している。特に、ＩＭＳフェムトセルまたはＩＣＳ拡張ＭＳＣサーバ（ｅＭＳＣサーバ）がＭＳＣ間ハンドオーバに関与する場合、ハンドオーバ開始エンティティ、すなわちＩＭＳフェムトセルまたは発信側のＩＣＳ拡張ＭＳＣサーバは、対応する上位レベルの一般的なハンドオーバ要求メッセージＨＯ＿ＲＥＱＵＥＳＴ内にターゲットセル情報を含める。ＨＯ＿ＲＥＱＵＥＳＴは、例えば、ＳＩＰメッセージ（例えばｒｅ−ＩＮＶＩＴＥ、ＲＥＦＥＲ、またはＮＯＴＩＦＹメッセージ）にマッピングされることが可能である。
【００３６】
図３に例示したソリューションにおいて、ＳＣＣ  ＡＳ（Service Continuity and Consistency Application Server, サービス連続性・一貫性アプリケーションサーバ）がハンドオーバ決定を実行し、（ソースおよびターゲット両方のアクセスからの）詳細なアクセス情報、例えば、ＵＥからの測定レポートに基づいて、ターゲットＭＳＣサーバ（またはフェムトアクセスポイント）を選択する。
【００３７】
新たに提案されるメッセージに対してＳＩＰベースのシグナリングが使用される場合、すべてのＩＣＳ拡張ＭＳＣサーバに自分で登録をしなければならない。別の可能性（ＳＩＰを使用しない場合）として、ＳＣＣ  ＡＳ（または類似の機能）が、ＤＮＳあるいはその他のディレクトリサービス（例えばＬＤＡＰ）を用いて、ターゲットＭＳＣサーバのＩＰアドレスを知る場合がある。これは、ＨＯ＿ＲＥＱＵＥＳＴメッセージ（これはソースからターゲットＭＳＣサーバへ必要なコンテキスト情報を伝達することができる）を送信し、ＡＣＫを受信するために必要とされる。同じ原理が、ＳＩＰ−ＵＡをホストしている任意の２つのエンティティ間においても、実際のハンドオーバを実行する前にエンティティ間で情報を交換するために、適用可能である。
【００３８】
なお、ＳＣＣ  ＡＳという用語は、上記の責任／機能を引き受けることが可能なアプリケーションサーバの一例として使用されている。この機能は、ネットワーク内に具体的に実現された別の（新しい）アプリケーションサーバまたは別の（新しい）機能エンティティによって提供されることも可能である。
【００３９】
以下、図３に示した例示的実施形態の各ステップについて、より詳細に説明する。第１ステップ（１）で、ソースフェムトアクセスポイント／ｅＭＳＣサーバが、ＳＣＣ  ＡＳまたは類似のアプリケーションサーバへＨＯ＿ＲＥＱＵＥＳＴを送信する。このハンドオーバ要求内には、転送されるべきセッションおよび発信ユーザに関する情報とともに、ターゲットアクセスおよび／またはターゲットネットワークに関する情報（例えば、ターゲットセルＩＤ、ターゲットＲＡＴタイプ、ＳＳＩＤ、ＲＦチャネル等）が提供される。
【００４０】
ＳＣＣ  ＡＳは、ステップ（１）で取得した情報に基づいて、どのＭＳＣサーバ（またはフェムトアクセスポイント）がセッションのターゲットとなるかを決定する。ＳＣＣ  ＡＳは、選択されたＭＳＣサーバへＨＯ＿ＲＥＱＵＥＳＴメッセージを送信する（２）。また、ＳＣＣ  ＡＳは、ハンドオーバ決定も実行する。ここで、（ソースおよびターゲット両方のアクセスからの）詳細なアクセス情報を考慮することができる（例えばＵＥからの測定レポート）。
【００４１】
ステップ（３）で、ＭＳＣサーバは、ハンドオーバ要求を処理し、例えばホームロケーションレジスタ（ＨＬＲ）から、加入者のユーザプロファイルをダウンロードし、ユーザのために、その加入者をＩＭＳ（または、セッション制御をアンカリングしているＳＩＰ／ＳＩＰ型サーバ）に登録する。また、ターゲットＭＳＣサーバは、ＳＩＰ  ＵＡのＩＭＳ登録に使用されるＩＭＳＩ（国際移動体加入者識別番号）からパブリックユーザＩＤを導出することが必要な場合もある。必要であれば、ＭＳＣサーバは、ターゲットセルに対して、無線アクセスネットワーク（ＲＡＮ）における必要なリソースの要求も行い、あるいは単にアクセスネットワークを準備する。
【００４２】
ＩＭＳ／ＳＩＰ登録が成功し、ＳＣＣ  ＡＳ（または類似のＡＳ機能）にアンカリングされた後、ＳＣＣ  ＡＳは、ＭＳＣサーバ上のＳＩＰ  ＵＡへ２００  ＯＫを送信する（４）。
【００４３】
その後、ユーザエージェントは、セッションを引き継ぐ準備ができ、ステップ（５）で、引き継ぐべきセッションのセッションＩＤを参照するＩＮＶＩＴＥを送信する。このステップ（５）において、フェムトアクセスポイントおよびｅＭＳＣサーバへのメディアのバイキャスティングを開始すべきことを示す追加フラグを挿入することも可能である。
【００４４】
次のステップで、ＳＣＣ  ＡＳは、リモートレグを更新し、ＩＮＶＩＴＥに肯定応答する（６）。その後、ターゲットＭＳＣサーバ（またはフェムトアクセスポイント）は、ＳＣＣ  ＡＳへハンドオーバ肯定応答を送信する（７）。ＳＣＣ  ＡＳは、ソースフェムトアクセスポイント／ｅＭＳＣサーバへＨＯ＿ＡＣＫメッセージを転送する（８）。
【００４５】
こうして、ソースフェムトアクセスポイント／ｅＭＳＣサーバは、ターゲットｅＭＳＣ／フェムトアクセスポイントでハンドオーバが準備されたことを知り、セッションを解放し、ＳＣＣ  ＡＳへＢＹＥを送信する（９）。このＢＹＥメッセージは、ステップ（５）で開始された可能性のあるバイキャスティングを停止する。この時点で、ソースフェムトアクセスポイント／ｅＭＳＣサーバは、これからハンドオーバが行われるべきであることを示すハンドオーバコマンドメッセージをＵＥへ送信するか、またはその送信をトリガすることも行う。最後に、ＳＣＣ  ＡＳは、２００  ＯＫによってＢＹＥに肯定応答する。
【００４６】
別法として、ステップ５でターゲットｅＭＳＣサーバ（またはフェムトアクセスポイント）へデータパスを切り替える代わりに、パス切替はステップ９で（すなわち、ソースフェムトアクセスポイント／ｅＭＳＣサーバの登録解除時に）トリガすることも可能である。
【００４７】
また、ネットワーク内のすべてのＩＣＳ拡張ＭＳＣサーバは、それぞれのコンタクトアドレスをＩＭＳに登録しており、このコンタクトアドレスはＳＣＣ  ＡＳにも提供される。すなわち、ＳＩＰ制御シグナリングはＳＣＣ  ＡＳにアンカリングされる。ＳＣＣ  ＡＳは、担当のターゲットＩＣＳ拡張ＭＳＣサーバのアドレスを提供する。これは、例えばすべての登録されているＭＳＣサーバのデータベース参照によって行うことが可能である。ＩＭＳフェムトセルは、ＵＥの測定レポートによってターゲットセルＩＤがフェムトセルに通知されると、ターゲットセルＩＤを知り、その後、ハンドオーバ決定を行う。
【００４８】
図４は、ＨＯ＿ＲＥＱＵＥＳＴメッセージを用いた、図３による実施形態の呼フローを示す図である。フェムトセルは、ターゲットセルＩＤおよびセッション転送ＩＤ（Session Transfer ID）を有するハンドオーバ要求を、ＣＳＣＦ（Call Session Control Function, 呼セッション制御機能）経由でＳＣＣ  ＡＳへ発信する。ＳＣＣ  ＡＳ  は、担当のＩＣＳ拡張ＭＳＣサーバの対応するコンタクトアドレスを選択するためのデータベースを維持管理する。ＳＣＣ  ＡＳは、適当なＩＣＳ拡張ＭＳＣサーバを選択し、ハンドオーバ要求を転送する。ＩＣＳ拡張ＭＳＣサーバは、ハンドオーバ要求メッセージを受信すると、ターゲットセルへのリソースの設定を開始し、導出された特別なパブリックユーザＩＤにより、ＵＥのためのＩＭＳ登録を開始する。また、ＭＳＣサーバは、セッション転送を開始し、ＳＣＣ  ＡＳへＩＮＶＩＴＥメッセージを送信する。このＩＮＶＩＴＥメッセージは、転送されるべきセッションを識別するセッション転送識別子（Session Transfer Identifier, ＳＴＩ）を宛先とする。また、ＩＮＶＩＴＥメッセージは、完全なメディア転送によるアクセス転送（Access Transfer）を実行するように、ＳＣＣ  ＡＳに指示する。ＳＣＣ  ＡＳは、ＳＴＩに基づいてセッションを識別し、リモートアクセスレグ上でセッションを更新する。ＳＣＣ  ＡＳは、標準のＩＭＳ手続きに基づいて、新しいアクセスレグ上のＩＣＳ拡張ＭＳＣサーバとのセッション設定を完了し、旧セッションを解放する。
【００４９】
図５は、ＨＯ＿ＲＥＱＵＥＳＴメッセージを従来のＳＩＰ  ＲＥＦＥＲメッセージにマッピングする、図３による実施形態の呼フローを示す図である。フェムトアクセスポイントは、ターゲットセルＩＤへＲＥＦＥＲを送信する。ＳＣＣ  ＡＳでの処理後、ＳＣＣ  ＡＳは、登録されたｅＭＳＣサーバインスタンスへ、すべての情報を有するＮＯＴＩＦＹを送信する。これが、導出された特別のパブリックユーザＩＤにより、ユーザのためのＩＭＳ登録をトリガする。ｅＭＳＣサーバインスタンスは、ＮＯＴＩＦＹに肯定応答し、登録されたユーザエージェントをトリガして、ＳＴＩ情報を有するＩＮＶＩＴＥをＳＣＣ  ＡＳへ送信させる。ＳＣＣ  ＡＳは、リモートアクセスレグを更新した後、ソースレグを解放する。
【００５０】
図６は、本発明によるネットワークベースのモビリティをサポートする方法の別の実施形態を示す模式図を示している。この第２のソリューションでは、ソースフェムトアクセスポイント／ｅＭＳＣサーバが、ＳＣＣ  ＡＳ（または類似のアプリケーションサーバ機能）を経由せずに、ターゲットｅＭＳＣサーバ（またはフェムトアクセスポイント）と「直接に」通信する。これを可能にするため、ソースノードは、ターゲットノードのルーティング可能な識別を何らかの方法で取得する必要がある。結果として、ソースフェムトアクセスポイント／ｅＭＳＣサーバは、ＨＯ＿ＲＥＱＵＥＳＴメッセージの前に、ターゲットＭＳＣ（またはフェムトアクセスポイント）アドレスの明示的または暗黙的な参照を実行する。ソースフェムトアクセスポイント／ｅＭＳＣサーバは、例えば、ＳＣＣ  ＡＳ（または類似のＡＳ機能）または専用の発見／参照機能に問合せを行い、ターゲットＭＳＣサーバ（またはフェムトアクセスポイント）を取得してもよい。
【００５１】
別の可能性として、ソースフェムトアクセスポイントがＩＭＳに登録する際に、ＳＣＣ  ＡＳが、可能性のあるマクロハンドオーバを担当するｅＭＳＣサーバを判定する。そして、このｅＭＳＣサーバアドレスが、例えば２００  ＯＫメッセージ内で、フェムトアクセスポイントへ返送される。
【００５２】
別の可能性として、ソースフェムトアクセスポイント／ｅＭＳＣサーバが、アクセスネットワークによって取得された情報（例えば、測定レポート、ターゲットセルＩＤ、ＳＳＩＤ等）に基づいて、ＩＭＳルーティング可能なＳＩＰ識別子／名称を導出する。これにより、ソースノードは、ターゲットノードを直接にアドレスすることができる。この場合、ＩＭＳは、ＨＯ＿ＲＥＱＵＥＳＴメッセージのルーティングを引き受ける（すなわち、あらゆるフェムトアクセスポイント／ｅＭＳＣサーバは、制御目的でＩＭＳに登録される）。
【００５３】
最後に、ＳＩＰに依拠しないソリューションもあり得る。例えば、ソースフェムトアクセスポイント／ｅＭＳＣサーバは、Ｄｉａｍｅｔｅｒ／Ｒａｄｉｕｓ、ＤＮＳまたはその他のディレクトリサービス（例えばＬＤＡＰ）を用いて、ターゲットＭＳＣサーバ（またはフェムトアクセスポイント）のアドレスを取得することも可能である。ＳＩＰと同様に、Ｄｉａｍｅｔｅｒの場合、ソースフェムトアクセスポイント／ｅＭＳＣサーバは、Ｄｉａｍｅｔｅｒ宛先識別子に関連情報をマスカレードしてから、Ｄｉａｍｅｔｅｒルーティング機能に最終選択をさせることもできる。
【００５４】
この第２のソリューションにおいて、ハンドオーバ決定は、（ソースおよびターゲット両方のアクセスからの）詳細なアクセス情報、例えば、ＵＥからの測定レポートに基づいて、ソースフェムトアクセスポイント／ｅＭＳＣサーバによって行われる。
【００５５】
このため、図６は次のように拡張されなければならない。最初のステップの前に、（ａ）ＨＯ＿ＴＡＲＧＥＴ＿ＬＯＯＫＵＰおよび（ｂ）ＨＯ＿ＴＡＲＧＥＴ＿ＲＥＳＰＯＮＳＥという２つのオプションのステップを挿入する。これらのステップは、明示的参照メカニズムの場合にのみ実行されるので、オプションである。暗黙的参照（例えば、ソースエンティティにおける設定に基づくものや、ＳＩＰ／ＩＭＳまたはＤＩＡＭＥＴＥＲルーティングに基づくもの）の場合、これらのステップは不要となる。
【００５６】
以下、図６に示した例示的実施形態の各ステップについて、より詳細に説明する。第１ステップ（１）で、フェムトアクセスポイントが、ＭＳＣサーバへ直接にＨＯ＿ＲＥＱＵＥＳＴを送信する。この要求内には、転送されるべきセッションおよび発信ユーザに関する情報とともに、ターゲットセルＩＤが提供される。
【００５７】
ＭＳＣサーバは、ハンドオーバ要求を処理し、ＨＬＲからＶＬＲに加入者のユーザプロファイルをダウンロードし、ＳＩＰ  ＵＡのＩＭＳ登録に使用されるＩＭＳＩからパブリックユーザＩＤを導出する。そして、ＳＩＰ  ＵＡは、ユーザのためにＩＭＳ登録メッセージを送信する（２）。また、ＭＳＣサーバは、ターゲットセルＩＤのために、ＲＡＮにおけるリソースの要求も行う。
【００５８】
ＩＭＳ登録が成功し、ＳＣＣ  ＡＳにアンカリングされた後、ＳＣＣ  ＡＳは、ＭＳＣサーバ上のＳＩＰ  ＵＡへ２００  ＯＫを送信する（３）。そしてステップ（４）で、ＭＳＣサーバは、ＳＩＰ  ＵＡアドレス情報を有するハンドオーバ肯定応答をフェムトアクセスポイントへ送信する。
【００５９】
その後、フェムトアクセスポイントは、ＭＳＣサーバ上のＳＩＰ  ＵＡへＲＥＦＥＲを送信して、アクティブセッションを引き継ぐ（５）。ＭＳＣサーバはＲＥＦＥＲを処理し、参照を有するＩＮＶＩＴＥをＳＣＣ  ＡＳへ送信する（６）。このステップにおいて、フェムトアクセスポイントおよびｅＭＳＣサーバへのメディアのバイキャスティングを開始すべきことを示す追加フラグを挿入することも可能である。
【００６０】
ステップ（７）で、ＳＣＣ  ＡＳは、リモートレグを更新し、２００  ＯＫによってＩＮＶＩＴＥに肯定応答する。ＭＳＣサーバは、２００  ＯＫによってフェムトアクセスポイントへのＲＥＦＥＲに肯定応答する（８）。こうして、フェムトアクセスポイントは、ＭＳＣサーバでハンドオーバが準備されたことを知り、セッションを解放し、ＳＣＣ  ＡＳへＢＹＥを送信する（９）。このＢＹＥメッセージは、ステップ（６）で開始された可能性のあるバイキャスティングを停止する。最後にステップ（６）で、ＳＣＣ  ＡＳは、２００  ＯＫによってＢＹＥに肯定応答する。
【００６１】
別法として、ステップ（６）でターゲットｅＭＳＣサーバ（またはフェムトアクセスポイント）へデータパスを切り替える代わりに、パス切替はステップ（９）で、すなわち、ソースフェムトアクセスポイント／ｅＭＳＣサーバの登録解除時に、トリガすることも可能である。
【００６２】
図７は、アプリケーションレベルの登録を用いることによりターゲットｅＭＳＣサーバを発見する、図６による実施形態の例示的な呼フローを示す図である。ＵＥがＩＰ接続を取得した後、ＵＥは、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function, プロキシ呼セッション制御機能）へ登録メッセージを送信することによってＩＭ登録を実行する。Ｐ−ＣＳＣＦは、Ｉ−ＣＳＣＦ（Interrogating CSCF）へ登録メッセージを送信し、Ｉ−ＣＳＣＦはＣｘ−Ｑｕｅｒｙ／Ｃｘ−Ｓｅｌｅｃｔ−ＰｕｌｌメッセージをＨＳＳへ送信する。ＨＳＳは、ユーザがすでに登録されているかどうかをチェックする。ＨＳＳは、ユーザサブスクリプションおよび事業者の制限／制約があれば、それに従って、ユーザが当該Ｐ−ＣＳＣＦネットワークに登録可能かどうかを示す。Ｓ−ＣＳＣＦ名を含むＣｘ−Ｑｕｅｒｙ  Ｒｅｓｐ／Ｃｘ−Ｓｅｌｅｃｔ−Ｐｕｌｌ  ＲｅｓｐがＨＳＳからＩ−ＣＳＣＦへ送信される。こうして、Ｉ−ＣＳＣＦは、選択されたＳ−ＣＳＣＦへ登録メッセージを送信することができる。Ｓ−ＣＳＣＦはＣｘ−Ｐｕｔ／Ｃｘ−ＰｕｌｌをＨＳＳへ送信する。ＨＳＳは、当該ユーザに対するＳ−ＣＳＣＦ名を保存し、Ｃｘ−Ｐｕｔ  Ｒｅｓｐ／Ｃｘ−Ｐｕｌｌ  Ｒｅｓｐを用いることにより、ユーザ情報をＳ−ＣＳＣＦに返す。その後、Ｓ−ＣＳＣＦは、フェムトセルユーザをローミングアウトするためのコンタクトとして前に登録されたｅＭＳＣサーバを判定するための登録メッセージをＳＣＣ  ＡＳへ送信する。ＳＣＣ  ＡＳは、ターゲットｅＭＳＣサーバのｅＭＳＣ  ＳＩＰ  ＵＲＩを含む２００  ＯＫメッセージを、ＣＳＣＦ経由でフェムトアクセスポイントへ送信する。こうして、ターゲットｅＭＳＣサーバを発見した後は、フェムトセルは、マクロセルハンドオーバが必要とみなされる場合のアドレスを保存するだけでよい。
【００６３】
図８は、図６による実施形態の例示的な呼フローを示す図である。測定レポートが評価され、フェムトセルがｅＭＳＣサーバへのハンドオーバを実行することに決定した場合、フェムトセルは、保存されているｅＭＳＣサーバアドレスへＣＳＣＦ経由でＮＯＴＩＦＹメッセージを送信する。このＮＯＴＩＦＹメッセージは、さらに、ターゲットセルＩＤおよび転送されるべきセッションのセッション転送識別子（ＳＴＩ）を含む。ｅＭＳＣサーバは、ＮＯＴＩＦＹメッセージに基づいてハンドオーバ要求を識別し、ｅＭＳＣサーバ上のＳＩＰ  ＵＡが、導出された特別なパブリックユーザＩＤにより、ＵＥのためにＩＭＳに登録する。登録成功後、ＭＳＣサーバは２００  ＯＫおよび登録されたＳＩＰ  ＵＡアドレスによりＮＯＴＩＦＹに肯定応答する。こうして、ＦＡＰは、ＳＩＰ  ＵＡが登録されたことを知り、ＵＲＩ（Uniform Resource Identifier）にターゲットＵＥ２を入れたＲＥＦＥＲをｅＭＳＣサーバ上のＳＩＰ  ＵＡへ直接に送信する。さらに、ＳＴＩ情報が提供される。すると、ｅＭＳＣサーバ上のＳＩＰ  ＵＡはＲｅ−ＩＮＶＩＴＥをＵＥ２へ送信する。ＵＥ２が２００  ＯＫを返送した後、ＭＳＣサーバ上のＳＩＰ  ＵＡは、直接にリモートアクセスレグを更新するか、または、タイマが満了する（そのとき、ソースレグが解放されたと仮定される）まで待機することができる。フェムトセルは、ＲＥＦＥＲメッセージに関連する２００  ＯＫ応答を受信したら、ソースアクセスレグを解放する。
【００６４】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【図１】
2011530916.tif 000003
【図２】
2011530916.tif 000004
【図３】
2011530916.tif 000005
【図４】
2011530916.tif 000006
【図５】
2011530916.tif 000007
【図６】
2011530916.tif 000008
【図７】
2011530916.tif 000009
【図８】
2011530916.tif 000010
【国際調査報告】
2011530916.tif 000011
2011530916.tif 000012
2011530916.tif 000013
2011530916.tif 000014
2011530916.tif 000015