JP2010531082A - 回線交換ドメインからパケット交換ドメイン上の回線交換サービスへのハンドオーバ - Google Patents

Abstract

移動通信ネットワーク内で移動局（３１）の回線交換ベアラを用いて回線交換ドメインからパケット交換ドメインへの回線交換サービスのハンドオーバを開始する方法。移動通信ネットワークは、無線ネットワークとコアネットワークとを備える。無線ネットワークは制御ノード（３２、３２’）を備える。移動局はＩＰアドレスとアクセスポートとを割り当てられている。本方法には、リロケーション／ハンドオーバリクエストメッセージを制御ノードがコアネットワークに通信することが含まれる。リロケーション／ハンドオーバリクエストメッセージには、移動局に割り当てられたＩＰアドレスとアクセスポートとのインジケーションが含まれる。

Description

本発明は、移動通信システムのためのハンドオーバ制御メカニズムに関する。詳細には、本発明は、例えばＩＰ電話の呼のような、回線交換ドメイン（領域）からパケット交換ドメイン上の回線交換サービスへの、実行中の接続をシームレスにハンドオーバすることをトリガするための方法（および装置）に関する。

ＩＰマルチメディア（ＩＰＭＭ）サービスは、同じセッションの中で音声、動画、メッセージング、データ等の動的なコンビネーション（組み合わせ）を提供する。基本的なアプリケーションの数および組み合わせが可能な媒体の数を増やすことによって、エンドユーザに提供されるサービスの数は増加し、個人間の通信の体験は豊かになるであろう。これによって、いわゆる「コンビネーション型ＩＰマルチメディア」サービスを含めて、次世代のカスタマイズされた豊かなマルチメディア通信サービスがもたらされるであろう。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動通信ネットワーク上でＩＰマルチメディアサービスを提供するために第３世代パートナシッププロジェクト（３ＧＰＰ）によって定義された技術である。ＩＭＳは、諸サービスの統合と相互作用を通じて、エンドユーザの個人対個人の通信を豊かにする重要な諸機能を提供する。ＩＭＳによって、ＩＰベースのネットワーク上で新しい豊かな個人対個人（クライアント対クライアント）の通信並びに個人対コンテンツ（クライアント対サーバ）の通信が可能になる。ＩＭＳは、セッション開始プロトコル（ＳＩＰ）を利用してユーザ端末間の（またはユーザ端末とアプリケーションサーバ間の）呼またはセッションを設定し、かつ制御する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）を用いて、セッションのメディアコンポーネントの記述とネゴシエーション（交渉）とが行われる。ＳＩＰがユーザ対ユーザのプロトコルとして作成されたのに対し、ＩＭＳは、オペレータおよびサービスプロバイダが、サービスへのユーザアクセスを制御し、それに応じてユーザに課金できるようにするものである。メディアの送信および制御については、その他のプロトコル、例えばリアルタイム・トランスポート・プロトコルおよびリアルタイム・トランスポート・コントロール・プロトコル（ＲＴＰ／ＲＴＣＰ）、メッセージ・セッション・リレー・プロトコル（ＭＳＲＰ）およびハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）が用いられる。ＩＭＳは、ＩＰベースのアクセスネットワークを必要とし、それは例えば、３ＧＰＰパケット交換（ＰＳ）ネットワークかまたはそれ以外のアクセスネットワーク、例えば固定ブロードバンドまたはＷｉＦｉネットワークでもよいであろう。

リアルタイムサービスを提供するための基本的な要件として、無線アクセスネットワーク（ＲＡＮ）のセル境界線を横切るかたちでローミングする加入者についての、サービスのシームレスなハンドオーバがある。従来の回線交換（ＣＳ）ベースの呼サービスは、この要件に合うように設計されてきた。２Ｇおよび最近実装された３Ｇネットワークの場合、端末側でのサービスの連続性はセッションが１つのセルから別のセルへと移動されるように命令することによって達成されるが、低レイテンシ（遅延）のＰＳリアルタイムハンドオーバは、提供されておらず、すなわち、セルを移動させる場合にレイテンシを短くする準備段階は存在しない。

リアルタイムのＰＳハンドオーバは、３Ｇネットワークについては３ＧＰＰで標準化されているが、その機能はまだ導入されていない。ハイスピード・ダウンリンク・パケット・アクセス（ＨＳＤＰＡ）が導入された場合かまたはその後まもなく、高速ＰＳハンドオーバに必要なメカニズムも導入されるであろうと予想されている。当初の実装段階では、３Ｇネットワーク全体に対するこの機能の展開は、つぎはぎ状に行われることが不可避であろう。２Ｇネットワークに関しては、２Ｇネットワーク内での（および２Ｇネットワークと３Ｇネットワークの間での）パケット交換（ＰＳ）ドメイン内での高速で効率的なＰＳハンドオーバ手順が最近になってようやくＧＳＭ／ＥＤＧＥネットワーク用の３ＧＰＰ ＴＳ４３．１２９で標準化されたばかりであり、その展開はまだ行われていない。２ＧネットワークにおけるＰＳハンドオーバのサポートは、（たとえ実装されたとしても）包括的になりそうにもないが、２Ｇネットワークは３Ｇネットワークの通信可能範囲が限られる場合に３Ｇ加入者のための代替ネットワークとなり続けるであろうから、ＰＳ呼のハンドオーバは、望ましいであろう。また、３ＧＰＰにおいてＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）およびＳＡＥ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）の名前で現在仕様を作成中である次世代無線およびコアネットワークの通信可能範囲も限られるであろうから、これらのネットワークも３Ｇおよび２Ｇネットワークへの代替を必要とするであろうということも予想できる。

将来、ＰＳサービスの主なユーザはＩＰ電話（ＶｏＩＰ）アプリケーションであろうということが予想されている。ＶｏＩＰ呼は、セル間のハンドオーバによって引き起こされる比較的軽微なサービスの障害にすら特に敏感であろう。ＶｏＩＰ呼に携わる端末が別のセル（「ターゲット（目標）セル」）に対するＰＳハンドオーバを実行できる限り、何らかの著しい知覚品質の低下を避けるのに十分な程度まで障害を短く維持することができる。しかし、現行のセルまたは目標セルのいずれか一方がＰＳハンドオーバをサポートしない場合には、ハンドオーバによる移行期間中にパケットが失われるであろうから、著しい障害が発生する可能性が高い。その結果として、すべてのＲＡＮセルがＰＳハンドオーバをサポートするまでは、ＰＳドメインを利用した音声呼および動画呼のようなＩＭＳサービスの提供について、セルの境界線を渡る際に、ユーザがサービス品質の低下を経験する結果となる可能性が高い。

ＧＳＭおよびＷＣＤＭＡ無線アクセスをベースにした移動ＣＳサービスは、世界的な成功を収めており、それによって、１度加入すれば世界中のほとんどすべての国で通信サービスを受けることができる。また現在、インドや中国のような人口の多い国々における移動ＣＳサービスの展開に押し上げられて、ＣＳ加入者の数は急速な増加を続けている。このサクセスストーリーは、従来のＭＳＣアーキテクチャが、移動ＣＳサービス用にパケットトランスポートインフラストラクチャの使用を可能にするソフトスイッチソリューションへと進化することによって、さらに続くであろう。

最近、３ＧＰＰ作業項目「Ｅｖｏｌｖｅｄ ＵＴＲＡ ａｎｄ ＵＴＲＡＮ」（２００６年夏開始）が、３ＧＰＰをベースにしたアクセス技術の競争力を保証するＬｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）構想を定義した。それに先立ってＲＡＮワークグループでは見込まれる機能と技術について幅広い評価が行われたが、ＲＡＮワークグループは、合意されたシステム構想は大半の要件に合致することが可能であると結論付け、そして、実現可能性に関して重大な問題はまったく特定されなかった。

ＬＴＥによれば、ダウンリンクでは直交周波数分割多重（ＯＦＤＭ）無線技術を用い、アップリンクではシングルキャリア−周波数分割多元接続方式（ＳＣ−ＦＤＭＡ）を用いることになり、それによってダウンリンクのデータレートについては少なくとも１００Ｍｂｐｓのピークデータレートが可能となり、そしてアップリンクのデータレートについては５０Ｍｂｐｓが可能になるであろう。ＬＴＥ無線は、多様な周波数帯で運用することができ、従って、世界中の多様な地域で展開するのに非常に柔軟性がある。

また、ＲＡＮの標準化と並行して、３ＧＰＰは、進化型コアネットワーク（ＣＮ）を開発するためにシステム・アーキテクチャ・エヴォリューション（ＳＡＥ）作業項目も推進している。図１は、ＳＡＥおよびＬＴＥのインタフェースを略示する。ＳＡＥコアネットワークは、コアノード群で構成されており、コアノード群は、さらに、制御プレーンノード（移動管理エンティティ（ＭＭＥ）２１）およびユーザプレーンゲートウェイ２２（在圏ゲートウェイおよびＰＤＮゲートウェイ）ノードとに分かれる。本発明の文脈では、アクセスゲートウェイ（ＡＧＷ）およびＳＡＥ ＧＷという用語は、在圏ゲートウェイおよびＰＤＮゲートウェイのノードと機能の両方を表すのに用いられる。現在用いられている用語集では、ＡＧＷには、ユーザプレーンエンティティ（ＵＰＥ）とインターアクセスアンカー（ＩＡＳＡ）機能とが両方含まれる。ＭＭＥ２１は、Ｓ１−ＭＭＥインタフェースを介してｅＮｏｄｅＢ２３、２３’に接続し、ＡＧＷ２２は、Ｓ１−Ｕインタフェースを介してｅＮｏｄｅＢ２３、２３’に接続する。

ＬＴＥおよびＳＡＥに共通するのは、パケット交換（ＰＳ）ドメインだけが指定される。すなわち、すべてのサービスはこのドメインを介してサポートされることになるであろうということである。しかし、ＧＳＭ（ＧＰＲＳ）およびＷＣＤＭＡは、ＰＳアクセスと回線交換（ＣＳ）アクセスを同時に提供する。

従って、電話サービスがＬＴＥ無線アクセスおよびＳＡＥコアネットワーク上で展開されなければならない場合、ＩＭＳベースのサービスエンジン（あるいは同様のもの）が必要である。最近、既存のモバイル・スイッチング・サブシステム（ＭＳＳ）インフラストラクチャに対するアクセス技術としてＬＴＥ／ＳＡＥをどう使うかについて調査が行われた。調査されたソリューションは、「ＣＳ ｏｖｅｒ ＬＴＥ／ＳＡＥ」または簡単に「ＣＳ ｏｖｅｒ ＬＴＥ」（ＣＳｏＬＴＥ）と呼ばれている。

これらのソリューションの基本的なＣＳｏＬＴＥアーキテクチャを図２に示す。パケット移動交換局（ＰＭＳＣ）２４は、従来型の２Ｇおよび３ＧのＲＡＮ並びに新たなＣＳ ｏｖｅｒ ＬＴＥをベースにしたソリューションの両方にサービスを提供してもよい。パケットＭＳＣ２４には、パケット ＣＳ 制御装置（ＰＣＳＣ）２７およびインターワーキングユニット（ＩＷＵ）２８と呼ばれる２つの新たな論理機能が含まれている。それらについては図３に関連付けてさらに説明する。

ここで図３を参照するが、端末３１とＰＭＳＣ２４の間における通信は、標準のＧｉインタフェースをベースにしている。これは、ＳＡＥ用語集ではＳＧｉインタフェースとも呼ばれる。これは、端末３１とＰＭＳＣ２４の中のＰＣＳＣ２７およびＩＷＵ２８の間におけるすべての直接通信はインターネットプロトコル（ＩＰ）をベースにすることと、端末３１はアクセスゲートウェイ（ＡＧＷ）２２を介してＩＰアドレスを用いて可視であり到達可能であることとを意味する。端末３１とＰＭＳＣ２４の間におけるこの通信は、２つの異なるインタフェース、制御プレーン用のＵ８ｃとユーザプレーン用のＵ８ｕとに分割される。Ｕ８ｃは、ＰＣＳＣ２７で終端し、そしてＰＣＳＣ２７は、ＬＴＥ／ＳＡＥベアラを認証するためのポリシーおよび課金ルール機能部（ＰＣＲＦ）３３に対するＲｘインタフェースも有している。Ｕ８ｕは、ＩＷＵ２８で終端する。

ＬＴＥ無線アクセス上でＣＳサービスを提供するための例示するソリューションを、「ＣＳ フォールバック」と呼ぶが、これは、端末がＬＴＥアクセスに留まりながらＭＭＥ２１に向かってＳＡＥ ＭＭ手順を行うことを意味する。ＭＭＥ２１は、ＣＳベースのサービス用に、端末をＭＳＣ−Ｓ２９に登録する。ＣＳサービスのためのページがＭＳＣ−Ｓ２９で受信されると、ページはＭＭＥ２１を介して端末３１へ転送され、次いで、端末３１は、２Ｇもしくは３ＧのＲＡＮ４１へと代替を行う。同様の動作は、移動体発のＣＳサービスにも適用され、そして、これらがトリガされて端末３１がＬＴＥアクセス上に留まっている場合、端末は２Ｇもしくは３ＧのＲＡＮへと代替を行って、そこでＣＳサービスの開始をトリガするであろう。

端末３１とＰＭＳＣ２４の間におけるＣＳｏＬＴＥ制御プレーンのプロトコルアーキテクチャ（すなわちＵ８ｃインタフェース）を図４に示す。それら２つの間には、ｅＮｏｄｅＢ２３とＡＧＷ２２とが置かれている。このアーキテクチャは、ＩＰプロトコル（ＩＰ、ＴＣＰ、ＵＤＰ）と、Ｕ８−回線交換リソース（Ｕ８−ＣＳＲ）という名前の追加のトンネリングプロトコルをベースにしている。このプロトコルは、移動管理（ＭＭ）とＭＭより上位のすべてのプロトコルレイヤとを、端末３１とＰＭＳＣ２４の間でトランスペアレント（透過）的に搬送する。

端末とＰＭＳＣ２４の間におけるＣＳｏＬＴＥ制御プレーンのプロトコル（すなわちＵ８ｕインタフェース）を図５に示す。それら２つの間には、ｅＮｎｏｄｅＢ２３とＡＧＷ２２とが配置されている。このアーキテクチャは、必要な音声およびデータ通信（例えばＡＭＲ符号化音声）を端末３１とＰＭＳＣ２４の間で送信するのに用いられるＩＰプロトコル（ＩＰ、ＵＤＰ、ＲＴＰ）をベースにしている。

従来型のＣＳドメインからＣＳｏＬＴＥをベースにしたソリューションへのハンドオーバのための既知のソリューションは存在しない。

上記の不利点の少なくとも一部を未然に防ぎ、回線交換ドメインからパケット交換ドメイン上の回線交換サービスへの、従来の接続のシームレスなハンドオーバをトリガするための方法および装置を提供することが、本発明の目的である。

本発明の第１の態様によれば、移動通信ネットワーク内の回線交換ドメインからパケット交換ドメインへの、移動局の回線交換ベアラを用いた、回線交換サービスのハンドオーバを開始するための方法が提供される。移動通信ネットワークは、無線ネットワークとコアネットワークとを備える。無線ネットワークは制御ノードを備える。移動局には、ＩＰアドレスとアクセスポートとが割り当てられている。制御ノードは、リロケーション（移転）／ハンドオーバリクエストメッセージをコアネットワークに対して通信する。リロケーション／ハンドオーバリクエストメッセージには、移動局に割り当てられたＩＰアドレスとアクセスポートとのインジケーションが含まれる。

本発明の第２の態様によれば、移動通信ネットワーク内の回線交換ドメインからパケット交換ドメインへの、移動局の回線交換ベアラを用いた、回線交換サービスのハンドオーバの開始を支援するように構成された制御ノードが提供される。移動通信ネットワークは、無線ネットワークとコアネットワークとを備える。無線ネットワークは制御ノードを備える。移動局には、ＩＰアドレスとアクセスポートとが割り当てられている。制御ノードは、リロケーション／ハンドオーバリクエストメッセージをコアネットワークに対して通信するための手段を備える。リロケーション／ハンドオーバリクエストメッセージには、移動局に割り当てられたＩＰアドレスとアクセス（ＵＤＰ）ポートとのインジケーション（指標）が含まれる。

本発明の第３の態様によれば、移動通信ネットワーク内の回線交換ドメインからパケット交換ドメインへの、移動局の回線交換ベアラを用いた、回線交換サービスのハンドオーバの開始を支援するように構成されたパケット交換ノードが提供される。移動通信ネットワークは、無線ネットワークとコアネットワークとを備える。無線ネットワークは制御ノードを備える。移動局には、ＩＰアドレスとアクセスポートとが割り当てられている。パケット交換ノードは、リロケーション／ハンドオーバリクエストメッセージを制御ノードから受信するための手段を備える。リロケーション／ハンドオーバリクエストメッセージには、移動局に割り当てられたＩＰアドレスとアクセスポートとのインジケーションが含まれる。

ＣＳ呼に関与する端末は、ＬＴＥ／ＳＡＥアクセスへと移動してもよい。これは、ＣＳサービスが２Ｇ／３ＧのＲＡＮの中で開始された場合であっても、端末がＬＴＥの通信可能範囲へと移動する場合には、端末は、ＬＴＥ／ＳＡＥブロードバンドアクセスを使用開始できることを意味する。

さらに、既存のＣＳ ＣＮインフラストラクチャ（すなわち、そのＰＭＳＣ以外の他のＭＳＣ）に対する変更はまったく必要ない。

ＳＡＥおよびＬＴＥインタフェースを略示する図である。 ＣＳｏＬＴＥアーキテクチャを略示する図である。 ＣＳｏＬＴＥ参照アーキテクチャを略示する図である。 ＣＳｏＬＴＥ制御プレーンのプロトコルアーキテクチャを略示する図である。 ＣＳｏＬＴＥユーザプレーンのプロトコルアーキテクチャを略示する図である。 オプション１の実行の前のＣＳからＣＳｏＬＴＥへのハンドオーバを略示する図である。 オプション１の実行の後のＣＳからＣＳｏＬＴＥへのハンドオーバを略示する図である。 オプション２の実行の前のＣＳからＣＳｏＬＴＥへのハンドオーバを略示する図である。 オプション２の実行の後のＣＳからＣＳｏＬＴＥへのハンドオーバを略示する図である。 ＵＴＲＡＮ ＣＳからＣＳｏＬＴＥへのハンドオーバ―オプション１のためのシーケンス図である。 ＵＴＲＡＮ ＣＳからＣＳｏＬＴＥへのハンドオーバ―オプション２のためのシーケンス図である。 ＧＥＲＡＮ ＣＳからＣＳｏＬＴＥへのハンドオーバのためのシーケンス図である。

本発明は、従来のＣＳドメイン（すなわち２Ｇおよび／または３ＧのＲＡＮ）からＣＳｏＬＴＥベースのソリューションへのハンドオーバに関する。本発明は、ＣＳ専用状態における端末が２Ｇ／３ＧのＲＡＮからＬＴＥのカバレッジ（通信可能範囲）が存在するエリアに移動する場合であって、かつ、呼がＬＴＥ／ＳＡＥネットワークにハンドオーバされることが好適である場合に適用される。

これは、本発明がＣＳｏＬＴＥ−ＩおよびＣＳｏＬＴＥ−Ｄソリューションに適用されてもよいことを意味するが、それは、これらのソリューションにはユーザプレーンとＣＳシグナリングコネクション（接続）を転送するためのＣＳｏＬＴＥ原理の利用が含まれているからである。

本発明の基本概念は、従来のＣＳドメインからＣＳｏＬＴＥへのハンドオーバが、２Ｇ／３ＧのＲＡＮからトリガされるということである。このハンドオーバは、２つの並行したハンドオーバリクエストで構成され、第１のリクエストは既存のＣＳハンドオーバリクエストと同様であり、第２のリクエストは既存のＰＳハンドオーバリクエストと同様である。また、ＣＳハンドオーバリクエストは、必要な端末と通信するメカニズムおよびＰＭＳＣ ＩＰアドレス情報で拡張される。

本発明が取り組む状況は以下のようである。

端末は当初、
１． ２Ｇ／３ＧのＲＡＮの中であって、ＣＳ ＣＮと２Ｇ／３Ｇ ＲＡＮとの間に位置しており、予約されたＣＳリソースを用いるＣＳ専用状態にあり、
２． ＧＰＲＳ／ＰＳドメインは現行の２Ｇ／３Ｇ ＲＡＮを介して接続しており、そして、
３． 端末がＧＧＳＮ／ＡＧＷにおいてＩＰアドレスを保持するように、デフォルトのパケットデータプロトコル（ＰＤＰ）コンテクストを有する。

図６は、オプション１の下での実行の前の、ＣＳからＣＳｏＬＴＥへのハンドオーバを略示する。

注１：ＣＳドメインは、ＭＳＣ−ＳおよびＭＧＷで構成されてもよいし、あるいは、その代わりに、従来型のＭＳＣ／ＶＬＲノード群で構成されてもよい。これは、本発明とは関係ない。

注２：本書で用いられる「オプション」という言葉は、異なる展開の選択肢とオプションとを記述するのに用いられる。

オプション１：
第１のオプションは、在圏ＭＳＣ３４がＰＭＳＣとして動作する能力を有しないこと、すなわち、ＬＴＥ／ＳＡＥネットワークにアクセスしないことを想定する。ＬＴＥ／ＳＡＥの初期の導入においてはこのようであってもよいが、その後の展開段階においては、すべての既存のＭＳＣがＰＭＳＣ能力も有するであろうということが想定されうる。

従来のＣＳドメイン（すなわち２Ｇ／３Ｇ ＲＡＮ）からのハンドオーバがＣＳｏＬＴＥソリューションに対して行われる場合、下記の動作が行われる必要がある。

１． ＣＮにおいてＭＳＣ３４とＰＭＳＣ２４の間におけるパスを確立する必要がある。現行のＭＳＣ３４は、このハンドオーバでのアンカーポイントとして動作するであろう。この動作のため、目標ＬＴＥセルは、２Ｇ／３Ｇ ＲＡＮにサービス提供する既存のＭＳＣの変更を回避する目的で、ＧＥＲＡＮセルまたはＵＴＲＡＮセルのいずれか一方として識別される必要がある。

２． この端末用に、ＣＳｏＬＴＥに必要なＬＴＥ／ＳＡＥベアラを確立する必要がある。

３． ＰＭＳＣ２４および端末３１は、制御プレーンの通信に用いられるＩＰアドレスとＵＤＰポートとを認識する必要がある。

４． ＰＭＳＣ２４および端末３１は、ユーザプレーンの通信に用いられるＩＰアドレスとＵＤＰポートとを認識する必要がある。

図７は、オプション１の下での実行の後のＣＳからＣＳｏＬＴＥへのハンドオーバについて略示する。

オプション２：
第２のオプションでは、在圏ＭＳＣはＰＭＳＣとして機能することもできる。

この場合、ＬＴＥ／ＳＡＥへのハンドオーバをＭＳＣ間のハンドオーバ事例として処理する代わりに、これをＭＳＣ内でのシステム間におけるハンドオーバとして処理することができる。また、これは現在、ＧＳＭとＷＣＤＭＡ ＲＡＮとの間でも可能である。ハンドオーバの手順はオプション１に非常によく似ており、唯一の違いは、非アンカーＭＳＣが不要であることで、従って、ＭＳＣ間のユーザプレーン接続も不要である。さらに、オプション２について図８および９に示す。

図８は、オプション２の下での実行の前のＣＳからＣＳｏＬＴＥへのハンドオーバを略示する。

図９は、オプション２の下での実行の後のＣＳからＣＳｏＬＴＥへのハンドオーバを略示する。

ＵＴＲＡＮ ＣＳからＣＳｏＬＴＥへのハンドオーバ手順
図１０は、ＰＭＳＣ２４が在圏ＭＳＣではないオプション１の場合に、ＣＳ呼に従事している端末が３Ｇ ＲＡＮからＣＳｏＬＴＥに移動するときに必要とされる関連ステップを示す。

最初の状態：ＭＳは、ＵＴＲＡＮ／ＷＣＤＭＡセルの中でＣＳ呼に携わっている。移動局３１は、隣接セルの測定を行うように構成されており、測定されることになるセルのうち少なくとも１つはＬＴＥセルである。移動局３１は、ＬＴＥセルの通信可能範囲のエリアへ移動し、そのセルを検出する。

ステップ１：移動局３１は、検出されたＬＴＥセルについて移動局が行った測定の報告をする。この詳細はまだ標準化されていないが、ＬＴＥセルはＩＲＡＴセルとして測定され報告されることが想定されてもよい。

ステップ２：このステップでは、ＲＮＣは移動局３１のＩＰアドレスを検索し、そして、ＣＳｏＬＴＥユーザプレーンのために使用されることになるＵＤＰポートも検索する。これは任意のステップであり、すでにＣＳハンドオーバ手順が行われた後にＰＭＳＣがダウンリンクのパケットの端末への送信を開始することを可能にするものである。

別の可能性として、ＰＭＳＣ２４がステップ１０で端末からの第１のアップリンクのユーザのペイロードパケットを待機し、そして移動局３１によって用いられるＩＰアドレスとＵＤＰポートとを確認して、この後でまずダウンリンク方向を可能にすることがあるであろう。

ステップ３：ＲＮＣはＣＳｏＬＴＥソリューションへのハンドオーバを行うことを決定する。この決定は、移動局３１に割り当てられたＣＳベアラ／ＲＡＢの知識と、報告された目標セルがＬＴＥセルであることとに基づく。以下の記述はＣＳハンドオーバとＰＳハンドオーバという２つの異なる部分に分かれており、それらはいずれもＣＳからＣＳｏＬＴＥへのハンドオーバ手順のためにトリガされる。ＣＳハンドオーバをステップ３ａ乃至７ａとして示し、ＰＳハンドオーバをステップ３ｂ乃至７ｂとして部分的に示す。

ステップ３ｂ乃至７ｂ：ＲＮＣがＰＳハンドオーバ手順をトリガする。この手順は通常通りに行われるため、ステップ３ｂと７ｂの間におけるステップは記述しない。ステップ７ｂでは、ＲＮＣは、ステップ８に続くまでＣＳおよびＰＳハンドオーバ手順の完了を待機する。

ステップ３ａ：ＲＮＣは（ＲＡＮＡＰ）Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ（リロケーション要請）メッセージをＭＳＣへ送信することによってＣＳハンドオーバ手順をトリガする。前述したように、目標ＬＴＥセルも、ＵＴＲＡＮセルまたはＧＥＲＡＮセルのいずれか一方に関連している。このセル情報（例えばＧＥＲＡＮセル用のＣＧＩまたはＵＴＲＡＮセル用のＲＮＣ−ＩＤおよびＣＩ）は、ハンドオーバリクエストの中で目標セルとして用いられ、従って、指定されたＬＴＥセルのためのＣＳｏＬＴＥサービスをどのＰＭＳＣが処理するのかを決定する。この目的でＧＥＲＡＮセルおよび／またはＵＴＲＡＮセル情報を用いる理由は、このハンドオーバ事例のためにソースＭＳＣにおける不要な変更を回避するためである。

上記の任意のステップ２が行われた場合、ＲＮＣには、通常はソースＢＳＣ／ＲＮＣと目標ＢＳＣ／ＲＮＣとの間でトランスポートされる透過的な情報要素の中に移動局３１のＩＰアドレスとＵＤＰポートの情報とが含まれる。目標セルがＵＴＲＡＮセルであると識別された場合には、Ｓｏｕｒｃｅ ＲＮＣ Ｔｏ Ｔａｒｇｅｔ ＲＮＣ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ（ソースＲＮＣからターゲットＲＮＣへのトランスペアレントなコンテナ） ＩＥを用いて、目標セルがＧＥＲＡＮセルであると識別された場合には、Ｏｌｄ ＢＳＳ Ｔｏ Ｎｅｗ ＢＳＳ Ｉｎｆｏｒｍａｔｉｏｎ （旧ＢＳＳから新ＢＳＳへの情報） ＩＥを用いて、ソースＲＮＣからの情報がＰＭＳＣ２４へ、ＣＳハンドオーバ準備リクエストの中のソースＭＳＣを通して透過的に送信されてもよい。

ステップ４ａ：ＭＳＣは、Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージの中で受信した目標セル識別子を用いて、このハンドオーバリクエスト用の目標ＭＳＣを識別する。この場合、分析はＰＭＳＣ２４を示し、そして関連するＭＡＰシグナリング（ＭＡＰ−Ｐｒｅｐ−Ｈａｎｄｏｖｅｒ−Ｒｅｑｕｅｓｔ（ＭＡＰ準備ハンドオーバリクエスト））が、ＰＭＳＣに向かってトリガされる。透過的コンテナ（例えばＳｏｕｒｃｅ ＲＮＣ Ｔｏ Ｔａｒｇｅｔ ＲＮＣ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ ＩＥ）が、ＭＡＰシグナリングの中に含まれ、そして、移動局３１のＩＰアドレスおよびＵＰＤポートがステップ２で検索された場合、これは、その情報をＰＭＳＣ２４へ渡すためのメカニズムとして機能する。

ステップ５ａ：ＰＭＳＣ２４は、ＣＳｏＬＴＥ呼のために必要なリソースを予約する。これは、ＩＰアドレスとＵＤＰポートとを備えたＩＰターミネーション（終端）がユーザプレーン用に予約されることを意味する。同様に、ＩＰアドレスとＵＤＰポートとを備えたＩＰ終端が制御プレーン用に予約されてもよい。次いで、ＭＡＰシグナリングを用いてソースＭＳＣ（ＭＡＰ−Ｐｒｅｐ−Ｈａｎｄｏｖｅｒ−Ｒｅｓｐｏｎｓｅ）に対する通信が行われ、そして、ＣＳｏＬＴＥ呼のために受信されたＩＰアドレスとＵＤＰポートとは、Ｔａｒｇｅｔ ＲＮＣ Ｔｏ Ｓｏｕｒｃｅ ＲＮＣ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ（ターゲットＲＮＣからソースＲＮＣへのトランスペアレントコンテナ） ＩＥの中に含まれてもよい。

ステップ６ａ：このステップでは、必要なコネクティビティ（接続性）が、ＭＳＣとＰＭＳＣ２４との間で標準のＣＳ呼の制御シグナリングを用いて確立される。

ステップ７ａ：ＣＳハンドオーバが準備されていることと、ＲＮＣは目標セルへ移動するように端末に命令することができるということとのインジケーションとして、ＭＳＣが（ＲＡＮＡＰ）Ｒｅｌｏｃａｔｉｏｎ Ｃｏｍｍａｎｄ（リロケーションコマンド）をＲＮＣへ返信する。この特定のハンドオーバは、ＬＴＥおよびＣＳｏＬＴＥへのハンドオーバについてであるから、ＲＮＣは、移動局３１に目標ＬＴＥセルへと移動するよう命令できる前に、ステップ７ａおよび７ｂが行われるのを待機する必要がある。

ステップ８ａ：ＲＮＣは、Ｈａｎｄｏｖｅｒ ｆｒｏｍ ＵＴＲＡＮ Ｃｏｍｍａｎｄ（ＵＴＲＡＮからのハンドオーバコマンド）メッセージを作成してこのメッセージを端末へ送信する。このメッセージには、ＣＳｏＬＴＥハンドオーバの事例のための一部の特定の情報が含まれるが、それは、行われたＰＳハンドオーバおよびＣＳハンドオーバの準備の一環として検索された情報の組み合わせだからである。第１に、目標ＬＴＥセルの無線レベル情報が、ＰＳハンドオーバの一部として受信される。第２に、必要なＰＭＳＣアドレス情報も、メッセージ内に含まれている。

ステップ９：移動局３１は、通常のＰＳハンドオーバのために指定されたメカニズムを用いて、目標ＬＴＥセルにアクセスする。留意すべきだが、ＰＳハンドオーバメカニズムは、まだ標準化の最中である。

ステップ１０：移動局３１とＰＭＳＣ２４とは、ＰＳハンドオーバシナリオの一部として確立されたデフォルトのベストエフォートＬＴＥ／ＳＡＥベアラを用いて通信してもよい。移動局３１は、ＩＷＵ／ＭＧＷの中で予約されたＩＰ終端のためのユーザプレーンのＩＰアドレスとＵＤＰポートとを知っており、この終端に対するアップリンクにおけるユーザプレーンのパケットの送信を開始する。これと並行して移動局３１は、ＰＭＳＣ２４に対する制御プレーンの接続を確立し、また、これに必要なＩＰ／ＵＤＰアドレス／ポート情報も、ステップ８で移動局３１に対してシグナリングにより通知される。

ステップ２が実行されたかどうかに応じて、ＰＭＳＣ２４は、ステップ４ａの後ではすでに、ダウンリンクのユーザプレーンのパケットを移動局３１に対して送信し始めてもよい。ステップ２が行われていなかった場合には、ＰＭＳＣ２４は、予約されたＩＰ終端上で移動局３１からの第１のアップリンクのユーザプレーンのパケットを待機して、次いで、これらのアップリンクパケットからのソースＩＰアドレスおよびＵＤＰポートを、ダウンリンクにおけるユーザプレーンのパケットのための着信先ＩＰアドレスおよびＵＤＰポートとして用いるであろう。

ステップ１１：移動局３１は、ＣＳからＣＳｏＬＴＥへのハンドオーバが成功したことをＵ８ｃ−ＨＡＮＤＯＶＥＲ ＣＯＭＰＬＥＴＥ（ハンドオーバ完了）メッセージを送信することによってＰＭＳＣ２４に通知する。

ステップ１２：ステップ１０（移動局３１からのアップリンクにおけるユーザプレーンのトラヒックの受信）またはステップ１１に基づいて、ＰＭＳＣ２４は、今では移動局３１が新たなセルに到着済みであることを認識している。ＰＭＳＣ２４は、ＡＡ−Ｒｅｑｕｅｓｔ（ＡＡＲ）をＲｘ−インタフェースでＰｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ（ＰＣＲＦ）へ送信することによって、ＣＳｏＬＴＥアプリケーションのために必要な専用ＬＴＥ／ＳＡＥベアラの許可と生成とをトリガする。

ステップ１３：ＰＣＲＦは、リクエストされたベアラを受け入れて、Ｒｅ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ（ＲＡＲ）メッセージをＳＡＥ−ＧＷへ送信することによって、ＣＳｏＬＴＥのための専用ＬＴＥ／ＳＡＥベアラを生成する必要性を通知する。

ステップ１４：ＣＳｏＬＴＥのための専用ＬＴＥ／ＳＡＥベアラを起動するために、ＳＡＥ／ＬＴＥと移動局３１との間で標準的なシグナリングが行われる。

ステップ１５：ＳＡＥ−ＧＷがＲｅ−Ａｕｔｈ−Ａｃｃｅｐｔ（ＲＡＡ）メッセージをＰＣＲＦへ送信して、ベアラが確立されていることを示す。

ステップ１６：ＰＣＲＦがＡＡ−Ａｃｃｅｐｔ（ＡＡＡ）メッセージをＰＭＳＣ２４へ送信して、ベアラが確立されていることを示す。

ステップ１７：ＣＳｏＬＴＥ呼は、最適化されたＬＴＥ／ＳＡＥベアラを用いている。

ステップ１８乃至２０：ＰＭＳＣ２４が、ハンドオーバの完了をソースＭＳＣに示し、ソースＭＳＣは、ソースセルの中で以前用いたリソースを解放するようＲＮＣにリクエストする。実行されたステップはハンドオーバの後で行われる通常の手順であるため、それらをすべて図８に示しているわけではない。

図１１は、ＵＴＲＡＮ ＣｓからＣＳｏＬＴＥへのハンドオーバ−オプション２のためのシーケンス図である。これは、在圏ＭＳＣがＰＭＳＣとしても機能するオプション２の場合にＣＳ呼に従事している端末が３Ｇ ＲＡＮからＣＳｏＬＴＥに移動するときに必要とされる関連ステップを示す。その場合に適用される図１０の記述は、ステップ４乃至６および１８乃至１９が省略されることを想定する。

ＧＳＭ ＣＳからＣＳｏＬＴＥへのハンドオーバ手順
図１２は、ＧＥＲＡＮ ＣＳからＣＳｏＬＴＥへのハンドオーバのシーケンス図であり、ＣＳ呼に従事している端末がＧＥＲＡＮからＣＳｏＬＴＥに移動するときに必要とされる関連ステップを示す。

最初の状態：移動局３１は、ＧＥＲＡＮ／ＧＳＭセルの中のＣＳ呼に携わっている。移動局３１は、隣接セルの測定を行うように構成されており、測定されることになるセルのうち少なくとも１つはＬＴＥセルである。移動局３１は、ＬＴＥセルの通信可能範囲のエリアへ移動し、そのセルを検出する。

ステップ１：移動局３１は、検出されたＬＴＥセルについて移動局が行った測定結果を報告する。この詳細はまだ標準化されていないが、ＬＴＥセルはＩＲＡＴセルとして信号を測定され報告されることが想定されてもよい。

ステップ２：このステップでは、ＢＳＣは移動局３１のＩＰアドレスを検索し、そして、ＣＳｏＬＴＥユーザプレーンのために使用されることになるＵＤＰポートも検索する。これは任意のステップであり、すでにＣＳハンドオーバ手順が行われた後にＰＭＳＣ２４がダウンリンクのパケットの端末への送信を開始することを可能にするものである。

別の可能性として、ＰＭＳＣ２４がステップ１０で端末からの第１のアップリンクにおけるユーザのペイロードパケットを待機し、そして移動局３１によって用いられるＩＰアドレスとＵＤＰポートとを確認して、この後でまずダウンリンク方向を可能にすることがあるであろう。

ステップ３：ＢＳＣはＣＳｏＬＴＥソリューションへのハンドオーバを行うことを決定する。この決定は、移動局３１に割り当てられたＣＳベアラの知識と、報告された目標セルがＬＴＥセルであることとに基づく。以下の記述はＣＳハンドオーバとＰＳハンドオーバという２つの異なる部分に分かれており、それらはいずれもＣＳからＣＳｏＬＴＥへのハンドオーバ手順のためにトリガされる。ＣＳハンドオーバをステップ３ａ乃至７ａとして示し、ＰＳハンドオーバをステップ３ｂ乃至７ｂとして部分的に示す。

ステップ３ｂ乃至７ｂ：ＢＳＣ３２’がＰＳハンドオーバ手順をトリガする。この手順は通常通りに行われるため、ステップ３ｂと７ｂの間におけるステップは記述しない。通常のＰＳハンドオーバとの唯一の違いは、移動局３１によってかまたは現行のセルの中でＤＴＭがサポートされなかった場合には、非アクティブなＰＤＰコンテクストも目標ＲＡＴ（すなわちＭＭＥおよびＵＰＥおよびｅＮｏｄｅＢおよびＡＧＷ）に対して転送される必要があることを示す目的で、ステップ３ｂにおいてＢＳＣからＳＧＳＮへ特別なインジケーションを送信する必要があるかもしれないということである。ステップ７ｂでは、ＢＳＣは、ステップ８に続くまでＣＳおよびＰＳハンドオーバ手順の完了を待機する。

ステップ３ａ：ＢＳＣは（ＢＳＳＭＡＰ）Ｈａｎｄｏｖｅｒ ＲｅｑｕｉｒｅｄメッセージをＭＳＣへ送信することによってＣＳハンドオーバ手順をトリガする。前述したように、目標ＬＴＥセルも、ＵＴＲＡＮセルまたはＧＥＲＡＮセルのいずれか一方に関連している。このセル情報（例えばＧＥＲＡＮセル用のＣＧＩまたはＵＴＲＡＮセル用のＲＮＣ−ＩＤおよびＣＩ）は、ハンドオーバリクエストの中で目標セルとして用いられ、従って、指定されたＬＴＥセルのためのＣＳｏＬＴＥサービスをどのＰＭＳＣが処理するのかを決定する。この目的でＧＥＲＡＮセルおよび／またはＵＴＲＡＮセル情報を用いる理由は、このハンドオーバ事例のためにソースＭＳＣにおける不要な変更を回避するためである。

上記の任意のステップ２が行われた場合には、ＢＳＣには、通常はソースＢＳＣ／ＲＮＣと目標ＢＳＣ／ＲＮＣの間でトランスポートされる透過的な情報要素の中に移動局３１のＩＰアドレスとＵＤＰポート情報とが含まれる。目標セルがＵＴＲＡＮセルであると識別された場合には、Ｓｏｕｒｃｅ ＲＮＣ Ｔｏ Ｔａｒｇｅｔ ＲＮＣ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ ＩＥを用いて、目標セルがＧＥＲＡＮセルであると識別された場合には、Ｏｌｄ ＢＳＳ Ｔｏ Ｎｅｗ ＢＳＳ Ｉｎｆｏｒｍａｔｉｏｎ ＩＥを用いて、ソースＢＳＣからの情報がＰＭＳＣ２４へ、ＣＳハンドオーバ準備リクエストの中のソースＭＳＣを通して透過的に送信されてもよい。

ステップ４ａ：ＭＳＣは、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージの中で受信した目標セル識別子を用いて、このハンドオーバリクエスト用の目標ＭＳＣを識別する。この場合、分析はＰＭＳＣ２４を示し、そして関連するＭＡＰシグナリング（ＭＡＰ−Ｐｒｅｐ−Ｈａｎｄｏｖｅｒ−Ｒｅｑｕｅｓｔ）が、ＰＭＳＣ２４に向かってトリガされる。透過的コンテナ（例えばＳｏｕｒｃｅ ＲＮＣ Ｔｏ Ｔａｒｇｅｔ ＲＮＣ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ ＩＥ）が、ＭＡＰシグナリングの中に含まれ、そして、移動局３１のＩＰアドレスおよびＵＰＤポートがステップ２で検索された場合には、これは、その情報をＰＭＳＣ２４へ通すためのメカニズムである。

ステップ５ａ：ＰＭＳＣ２４は、ＣＳｏＬＴＥ呼のために必要なリソースを予約する。これは、ＩＰアドレスとＵＤＰポートとを備えたＩＰ終端がユーザプレーン用に予約されることを意味する。同様に、ＩＰアドレスとＵＤＰポートとを備えたＩＰ終端が制御プレーン用に予約されてもよい。次いで、ＭＡＰシグナリングを用いてＭＳＣ（ＭＡＰ−Ｐｒｅｐ−Ｈａｎｄｏｖｅｒ−Ｒｅｓｐｏｎｓｅ）に対する通信が行われ、そして、ＣＳｏＬＴＥ呼のために受信されたＩＰアドレスとＵＤＰポートとは、Ｔａｒｇｅｔ ＲＮＣ Ｔｏ Ｓｏｕｒｃｅ ＲＮＣ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ ＩＥの中に含まれてもよい。

ステップ６ａ：このステップでは、必要な接続性が、ＭＳＣとＰＭＳＣ２４の間で標準のＣＳ呼の制御シグナリングを用いて確立される。

ステップ７ａ：ＣＳハンドオーバが準備されていることと、ＢＳＣは目標セルへ移動するように端末に命令することができるということとのインジケーションとして、ＭＳＣが（ＢＳＳＭＡＰ）Ｈａｎｄｏｖｅｒ ＲｅｑｕｉｒｅｄメッセージをＢＳＣへ返信する。この特定のハンドオーバは、ＬＴＥおよびＣＳｏＬＴＥへのハンドオーバについてであるから、ＢＳＣは、移動局３１に目標ＬＴＥセルへと移動するよう命令できる前に、ステップ７ａおよび７ｂが行われるのを待機する必要がある。

ステップ８ａ：ＢＳＣは、Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージを作成してこのメッセージを端末へ送信する。このメッセージには、ＣＳｏＬＴＥハンドオーバの事例のための一部の特定の情報が含まれるが、それは、行われたＰＳハンドオーバおよびＣＳハンドオーバの準備の一環として検索された情報の組み合わせだからである。第１に、目標ＬＴＥセルの無線レベル情報が、ＰＳハンドオーバの一部として受信される。第２に、必要なＰＭＳＣアドレス情報も、メッセージ内に含まれている。

ステップ９：移動局３１は、通常のＰＳハンドオーバのために指定されたメカニズムを用いて、目標ＬＴＥセルにアクセスする。留意すべきだが、ＰＳハンドオーバメカニズムは、まだ標準化の最中である。

ステップ１０：移動局３１とＰＭＳＣ２４とは、ＰＳハンドオーバシナリオの一部として確立されたデフォルトのベストエフォートＬＴＥ／ＳＡＥベアラを用いて通信してもよい。移動局３１は、ＩＷＵ／ＭＧＷの中で予約されたＩＰ終端のためのユーザプレーンのＩＰアドレスとＵＤＰポートとを知っており、この終端に対するアップリンクにおけるユーザプレーンのパケットの送信を開始する。並行して移動局３１は、ＰＭＳＣ２４に対する制御プレーンの接続を確立し、また、これに必要なＩＰ／ＵＤＰアドレス／ポート情報も、ステップ８で移動局３１に対して通知される。

ステップ２が実行されたかどうかに応じて、ＰＭＳＣ２４は、ステップ４ａの後ではすでに、ダウンリンクのユーザプレーンのパケットを移動局３１に対して送信し始めてもよい。ステップ２が行われていなかった場合には、ＰＭＳＣ２４は、予約されたＩＰ終端上で移動局３１からの第１のアップリンクのユーザプレーンのパケットを待機して、次いで、これらのアップリンクパケットからのソースＩＰアドレスおよびＵＤＰポートを、ダウンリンクにおけるユーザプレーンのパケットのための着信先ＩＰアドレスおよびＵＤＰポートとして用いるであろう。

ステップ１１：移動局３１は、ＣＳからＣＳｏＬＴＥへのハンドオーバが成功したことをＵ８ｃ−ＨＡＮＤＯＶＥＲ ＣＯＭＰＬＥＴＥメッセージを送信することによってＰＭＳＣ２４に通知する。

ステップ１２：ステップ１０（移動局３１からのアップリンクにおけるユーザプレーンのトラヒックの受信）またはステップ１１に基づいて、ＰＭＳＣ２４は、今では移動局３１が新たなセルに到着済みであることを知っている。ＰＭＳＣ２４は、ＡＡ−Ｒｅｑｕｅｓｔ（ＡＡＲ）をＲｘ−インタフェースでＰｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ（ＰＣＲＦ）へ送信することによって、ＣＳｏＬＴＥアプリケーションのために必要な専用ＬＴＥ／ＳＡＥベアラの許可と生成とをトリガする。

ステップ１３：ＰＣＲＦは、リクエストされたベアラを受け入れて、Ｒｅ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ（ＲＡＲ）メッセージをＳＡＥ−ＧＷへ送信することによって、ＣＳｏＬＴＥのための専用ＬＴＥ／ＳＡＥベアラを生成する必要性を通知する。

ステップ１４：ＣＳｏＬＴＥのための専用ＬＴＥ／ＳＡＥベアラを起動するために、ＳＡＥ／ＬＴＥと移動局３１の間で標準的なシグナリングが行われる。

ステップ１５：ＳＡＥ−ＧＷがＲｅ−Ａｕｔｈ−Ａｃｃｅｐｔ（ＲＡＡ）メッセージをＰＣＲＦへ送信して、ベアラが確立されていることを示す。

ステップ１６：ＰＣＲＦがＡＡ−Ａｃｃｅｐｔ（ＡＡＡ）メッセージをＰＭＳＣ２４へ送信して、ベアラが確立されていることを示す。

ステップ１７：ＣＳｏＬＴＥ呼が、最適化されたＬＴＥ／ＳＡＥベアラを用いている。

ステップ１８乃至２０：ＰＭＳＣ２４が、ハンドオーバの完了をソースＭＳＣに示し、ソースＭＳＣは、ソースセルの中で以前用いたリソースを解放するようＢＳＣにリクエストする。実行されたステップはハンドオーバの後で行われる通常の手順であるため、それらをすべて図８に示しているわけではない。

在圏ＭＳＣがＰＭＳＣとしても機能しているオプション２の場合にＣＳ呼に従事している端末がＧＳＭからＣＳｏＬＴＥへ移動するときには、同様のステップが必要である。また、その場合に適用される図１２の記述は、ステップ４ａ乃至５ａおよび１８乃至１９が省略されることを想定する。

もちろん、その他の多くの代替形態が当業者によって行われるであろう。理解されるであろうが、本発明は、ここに記述された実施形態に限定されるのではなく、本発明に添付された請求項に記載された思想とその範囲の中に存在する、当業者には明白な修正形態を包含する。

Claims (20)

1. 制御ノードを有する無線ネットワークとコアネットワークとを含む移動通信ネットワークにおいて、ＩＰアドレスとアクセスポートとを割り当てられている移動局の回線交換型のベアラを使用して、回線交換ドメインからパケット交換ドメインへ回線交換型のサービスをハンドオーバすることを開始する方法であって、
   前記制御ノードが前記コアネットワークに対してリロケーション／ハンドオーバの要請メッセージを送信するステップを含み、
   前記リロケーション／ハンドオーバの要請メッセージには、前記移動局に割り当てられているＩＰアドレスとアクセスポートとを示すインジケーションが含まれていることを特徴とする方法。
2. 前記制御ノードが前記移動局に対して該移動局のＩＰアドレスとアクセスポートとを示すインジケーションを要求するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記制御ノードは無線ネットワーク制御装置であり、前記リロケーション／ハンドオーバの要請メッセージはリロケーション要請メッセージであることを特徴とする請求項１または２に記載の方法。
4. 前記制御ノードは基地局制御装置であり、前記リロケーション／ハンドオーバの要請メッセージはハンドオーバ要請メッセージであることを特徴とする請求項１または２に記載の方法。
5. 前記無線ネットワークはパケット交換ノードを含み、
   前記方法は、
   前記制御ノードが前記リロケーション／ハンドオーバの要請メッセージを前記パケット交換ノードへ送信するステップをさらに含み、
   前記リロケーション／ハンドオーバの要請メッセージには、前記移動局に割り当てられているＩＰアドレスとアクセスポートとを示すインジケーションが含まれていることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
6. 前記リロケーション／ハンドオーバの要請メッセージは、その時点で使用されている交換ノードを介して前記制御ノードから前記パケット交換ノードへと転送されることを特徴とする請求項５に記載の方法。
7. 前記リロケーション／ハンドオーバの要請メッセージを受信したことに応じて、前記パケット交換ノードがローカルのＩＰアドレスとアクセスポートとの少なくとも一方を予約し、該ローカルのＩＰアドレスとアクセスポートとの少なくとも一方を示す情報を前記制御ノードに送信することを特徴とする請求項１ないし６のいずれか１項に記載の方法。
8. 前記制御ノードが受信した前記ローカルのＩＰアドレスとアクセスポートとを示す情報を前記移動局に対して転送することを特徴とする請求項７に記載の方法。
9. 前記パケット交換ノードによって割り当てられた前記ＩＰアドレスと前記アクセスポートとを受信したことに応じて、該ＩＰアドレスと該アクセスポートとを使用して前記移動局が前記パケット交換ノードと通信することを特徴とする請求項８に記載の方法。
10. 前記パケット交換ノードは、前記移動局によって送信されたアップリンクパケットからハンドオーバが完了したと判定することを特徴とする請求項９に記載の方法。
11. 前記ハンドオーバ完了したことに応じて、前記移動局がハンドオーバ完了メッセージを前記パケット交換ノードに対して送信することを特徴とする請求項９に記載の方法。
12. 前記パケット交換ノードは、要求されたパケット交換型のベアラの起動を開始することを特徴とする請求項１０または１１に記載の方法。
13. 制御ノードを有する無線ネットワークとコアネットワークとを含む移動通信ネットワークにおいて、ＩＰアドレスとアクセスポートとを割り当てられている移動局の回線交換型のベアラを使用して、回線交換ドメインからパケット交換ドメインへ回線交換型のサービスをハンドオーバすることを開始することを補助する該制御ノードであって、
    前記コアネットワークに対してリロケーション／ハンドオーバの要請メッセージを送信する手段を含み、
    前記リロケーション／ハンドオーバの要請メッセージには、前記移動局に割り当てられているＩＰアドレスとアクセスポートとを示すインジケーションが含まれていることを特徴とする制御ノード。
14. 前記移動局に対して該移動局のＩＰアドレスとアクセスポートとを示すインジケーションを要求する手段をさらに含むことを特徴とする請求項１３に記載の制御ノード。
15. 前記制御ノードは無線ネットワーク制御装置であり、前記リロケーション／ハンドオーバの要請メッセージはリロケーション要請メッセージであることを特徴とする請求項１３または１４に記載の制御ノード。
16. 前記制御ノードは基地局制御装置であり、前記リロケーション／ハンドオーバの要請メッセージはハンドオーバ要請メッセージであることを特徴とする請求項１３または１４に記載の制御ノード。
17. 制御ノードを有する無線ネットワークとコアネットワークとを含む移動通信ネットワークにおいて、ＩＰアドレスとアクセスポートとを割り当てられている移動局の回線交換型のベアラを使用して、回線交換ドメインからパケット交換ドメインへ回線交換型のサービスをハンドオーバすることを開始することを補助するパケット交換ノードであって、
    前記制御ノードからリロケーション／ハンドオーバの要請メッセージを受信する手段を含み、
    前記リロケーション／ハンドオーバの要請メッセージには、前記移動局に割り当てられているＩＰアドレスとアクセスポートとを示すインジケーションが含まれていることを特徴とするパケット交換ノード。
18. 前記リロケーション／ハンドオーバの要請メッセージを受信したことに応じて、ローカルのＩＰアドレスとＵＤＰポートとの少なくとも一方を予約する手段と、
    前記ローカルのＩＰアドレスとＵＤＰポートとの少なくとも一方を示す情報を前記制御ノードに送信する手段と
    をさらに含むことを特徴とする請求項１７に記載の方法。
19. 前記移動局によって送信されたアップリンクパケットからハンドオーバが完了したと判定する手段をさらに含むことを特徴とする請求項１７または１８に記載のパケット交換ノード。
20. 要求されたパケット交換型のベアラの起動を開始する手段をさらに含むことを特徴とする請求項１７ないし１９のいずれか１項に記載のパケット交換ノード。

Images