JP5774022B2 - 通信端末及びネットワークノード - Google Patents

Description

本発明は、パケット交換データ通信ネットワークにおける通信技術に関する。本発明は、特に、異なるアクセスネットワーク間でハンドオーバが行われる際のパケットデータ通信技術に関する。

第３世代パートナーシッププロジェクト（Third Generation Partnership Project：３ＧＰＰ）では、ロングタームエボリューション（Long Term Evolution：ＬＴＥ）プログラムとして、拡張パケットシステム（Evolved Packet System：ＥＰＳ）と呼ばれる新たなシステムを開発している。ＥＰＳでは、スペクトル効率の改善、レイテンシの短縮、無線リソースなどの改善が実現される。ＬＴＥは、ＧＳＭ（Global System for Mobile communications）／ＥＤＧＥ（Enhanced Data GSM Environment）ネットワーク技術及びＵＭＴＳ（Universal Mobile Telecommunications System）／ＨＳＰＡ（High-Speed downlink/uplink Packet Access）ネットワーク技術を実現したモバイルネットワーク技術における最新の標準規格である。ＥＰＳによって、ユーザは、より高速のデータレートや、より豊富なアプリケーション及びサービスを低コストで体感することが可能となる。ＥＰＳへの接続を確保するために、ユーザは、ＬＴＥに対応した（ＬＴＥコンプライアント）ユーザ端末(User Equipment：ＵＥ）を使用する必要がある。

ＥＰＳには、パケット交換（packet switched：ＰＳ）ドメインと回線交換（circuit switched：ＣＳ）ドメインの２つのタイプのドメインが存在する。ＰＳドメインは、主にデータ通信に使用され、ユーザがより高速のデータレートを求める際の条件を満たす。一方、ＣＳドメインは、主に音声通信に使用され、ユーザ同士が通話を行うことができるように、多数のモバイルオペレータに広く配置される。

ＰＳドメインシステムへのスムーズな移動を実現するためのＬＴＥの特徴として、ＣＳフォールバック（CS fallback：ＣＳＦＢ）が知られている。ネットワークは、このＣＳＦＢのメカニズムによって、ＣＳサービスの機能を有するＵＥをＣＳサービスへアクセスさせるために、ＰＳドメインのみ存在するアクセスネットワーク（例えば、Ｅ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network））から、ＣＳドメインとしての機能も有するＣＳコンパチブルなアクセスネットワーク（例えば、ＵＴＲＡＮ（UMTS Terrestrial Radio Access Network））へ移動させることが可能となる。ＥＰＳのＣＳＦＢによれば、ＵＥがＰＳドメインにのみ接続されている場合に、ＣＳ用に既に配置されているインフラストラクチャを再利用することによって、ＵＥに対して音声サービスを提供することが可能となる。ＣＳＦＢによって、ＵＥは、ボイスコールを受けたり、あるいは、ボイスコールを行ったりすることが可能となる。

ＣＳＦＢを実行するためのＵＥ及びネットワークの手順は、例えば下記の非特許文献１に記載されている。例えば、ネットワークは、ＰＳドメインにのみ接続されているＵＥあてに着信ＣＳコール（incoming CS call）が届いたことを把握すると、ＵＥの近隣に存在するＣＳドメインへ切り替える（スイッチオーバ）ようＵＥへ通知する。この切り替えによって、ＵＥは、着信ＣＳコールを受けることが可能となる。ＵＥがＣＳコールを受け入れたい場合には、ＵＥは、ネットワークによって指示されたＣＳドメインへ接続することによって、その接続に応じる。一方、ＵＥがＣＳコールを受け入れたくない場合には、ＵＥは、ＣＳコールを拒否することをネットワークへ通知する。

なお、ＵＥがＰＳドメインにおいてＰＳセッションを有している場合には、ターゲットアクセスネットワーク（切り替え先のアクセスネットワーク）もＰＳセッションをサポートし、ＰＳセッションの接続を認めるのであれば、ネットワークは、ＰＳセッションのハンドオーバを始動することが可能である。ＣＳコールの終了時に、ＵＥが元のアクセスネットワーク（切り替え前のアクセスネットワーク）へ戻るよう決定しなければ、ＵＥは、ターゲットアクセスネットワークにそのまま滞在することになる。アクティブなセッションが存在しなければ、ＵＥはアイドルモードに入り、ＵＥ内のロジック（例えば、セルの再選択）に従って、元のアクセスネットワークに戻るべきかどうかを判断する。

また、ＬＴＥは、ローカルＩＰアクセス（Local Internet Protocol Access：ＬＩＰＡ）の導入という特徴も有している。ＬＩＰＡを使用することによって、オペレータのコアネットワークを通過する通信を行うことなく、ＵＥとローカルネットワーク上のデバイスとの間での通信が可能となる。ローカルゲートウェイ（Local Gateway：ＬＧＷ）は、例えば家庭内又は企業ネットワーク（residential or corporate network）などのようなローカルネットワークの中や近傍に配置されており、家庭内又は企業ネットワークへのパケットデータアンカとして機能する。例えば、ユーザは、家庭内又は企業ネットワーク内のデバイスにアクセスしようとする場合（例えば、ユーザのＵＥが家庭内又は企業ネットワークに直接接続されている基地局に接続して、メディアサーバにアクセスしようとする場合）には、基地局と家庭内又は企業ネットワークとの間で直接ルーティングされるトラフィックをＬＩＰＡによる通信とすることが可能である。これにより、この通信がセルラオペレータのコアネットワークリソースを利用しないようにし、より良い品質及び低コストを実現できるようになる。なお、ＬＩＰＡに関する説明は、例えば下記の非特許文献２に記載されている。

また、ＬＴＥは、さらに、選択的なＩＰトラフィックオフローディング（Selective IP Traffic Offloading：ＳＩＰＴＯ）という特徴を有している。ＳＩＰＴＯによれば、セルラオペレータは、ＵＥの位置の近くのパケットデータネットワークゲートウェイ（Packet Data Network Gateway：ＰＤＮ ＧＷ）を提供することによって、ＵＥのトラフィックパスを最適化することが可能となる。例えば、ＵＥがセルラオペレータのネットワーク内を移動している場合、ネットワーク内のポリシーは、ＵＥの地理的位置又は論理的位置に基づいて、より近いＰＤＮ ＧＷをＵＥへ割り当てられることを検出することができる。ＳＩＰＴＯは、ユーザに処理を行わせずにＵＥのトラフィックパスをより近いＰＤＮ ＧＷへオフロードすることによって開始される。また、ＳＩＰＴＯは、家庭内又は企業ネットワークのケースにも適用できることが想定されている。セルラオペレータは、ＳＩＰＴＯによって、オペレータコアネットワークのリソースの利用を減らすことができ、さらに、オペレータのコアネットワークを通過するよりもむしろ、より直接的なインターネットへのパスをＵＥへ提供することができるようになる。なお、ＳＩＰＴＯに関する説明は、例えば非特許文献２に記載されている。

図１は、従来の技術並びに本発明の実施の形態に関連したネットワークシステムの一例を示す図である。なお、図１には、３ＧＰＰで説明されているシステムが例示されている。このシステムでは、ＵＥ１００は、ＰＳサービス及びＣＳサービスの両方を受けられるようにオペレータに登録されているとする。また、ＵＥ１００は、Ｅ−ＵＴＲＡＮ１０１とＵＴＲＡＮ１０２がオーバラップしている範囲内に存在しているとする。また、Ｅ−ＵＴＲＡＮ１０１は純粋なＰＳドメインである一方、ＵＴＲＡＮ１０２は、ＰＳドメイン及びＣＳドメインの両方をサポートしているとする。ＵＥ１００は現在、Ｅ−ＵＴＲＡＮ１０１に接続されており、ユーザの家庭内又は企業ネットワーク１０３内に位置している。ホームＥ−ＵＴＲＡＮノードＢ（ＨｅＮＢ１０４）は、Ｅ−ＵＴＲＡＮ１０１の無線アクセスチャンネルをＵＥ１００へ提供している。また、セルラオペレータから提供されるサービスへのＵＥ１００のアクセス方法を制御するために、モビリティ管理エンティティ（Mobility Management Entity：ＭＭＥ１０５）が、ＵＥ１００に関して必要なアクセスコントロール及び認証手続きを実行する。ＵＥ１００がセルラオペレータによって提供されたサービスに関して認証及び認可されると、ＭＭＥ１０５は、必要なリソースを提供するようＨｅＮＢ１０４へ通知し（リンク１０６経由）、ＵＥ１００との無線接続（すなわち、無線チャンネル）を確立する。

また、ＵＥ１００がセルラオペレータの拡張パケットコア（Evolved Packet Core：ＥＰＣ）１０７経由でデータサービス（例えば、ウェブブラウジング）を受けられるよう認可されている場合には、ＭＭＥ１０５は、ＵＥ１００がデータサービスへアクセスするために適切なパケットデータネットワークゲートウェイ（Packet Data Network Gateway：ＰＤＮ ＧＷ１０８）を選択する。さらに、ＭＭＥ１０５は、ＵＥ１００がデータサービスへアクセスするために適切なサービングゲートウェイ（Serving Gateway：ＳＧＷ１０９）も選択する。ＭＭＥ１０５は、ＵＥ１００に関連して、ＰＤＮ ＧＷ１０８への必要な接続（リンク１１１）をセットアップするようＳＧＷ１０９へ依頼する。さらに、ＭＭＥ１０５は、ＵＥ１００に関連して、ＨｅＮＢ１０４への必要なＥＰＳベアラ（リンク１１２）をセットアップするようＳＧＷ１０９へ依頼する。ＵＥ１００に関連するデータパスがセットアップされると、ＵＥ１００のアプリケーション（例えば、ウェブブラウザ）は、インターネット１１３又はその他のネットワークへＰＤＮ ＧＷ１０８経由でアクセスすることが可能となる。ＰＤＮ ＧＷ１０８は、リンク１１４を用いて、ＵＥ１００から／へのデータパケットをインターネット１１３又はその他のネットワークへ／から転送する。

ここで、ＵＥ１００においてＬＩＰＡが利用可能であり、ＵＥ１００があるファイル（例えば、データファイルやビデオファイルなど）を、ホームネットワーク１１８内に位置するサーバ（以下、メディアサーバ１１５と呼ぶ）からダウンロードしようとしている場合について考える。ＵＥ１００が家庭内又は企業ネットワーク１０３と通信を行えるようにするため、ＵＥ１００には、家庭内又は企業ネットワーク１０３に接続されているローカルゲートウェイ（Local Gateway：ＬＧＷ１１６）が割り当てられる必要がある。ＵＥ１００は、ＭＭＥ１０５に対して、家庭内又は企業ネットワーク１０３への接続を求めるリクエストを送信する。ＵＥ１００は、そのリクエストが家庭内又は企業ネットワーク１０３への接続のためのものであることをＭＭＥ１０５へ通知する。ＭＭＥ１０５は、ＵＥ１００の加入者情報を考慮して、ＵＥ１００にとって適切なＰＤＮ ＧＷを検索する。この検索手続きによって、ＭＭＥ１０５は、家庭内又は企業ネットワーク１０３におけるＬＩＰＡに関して、ＬＧＷ１１６をＵＥ１００へ割り当てることを決定する。ＭＭＥ１０５は、ＬＧＷ１１６に対して、ＵＥ１００のために必要なＥＰＳベアラ（リンク１１７）のセットアップ、及び、ＥＰＳベアラがセットアップされた場合にはＭＭＥ１０５へ通知するよう依頼する。

なお、ＬＧＷ１１６及びＨｅＮＢ１０４は、相互に通信可能である（リンク１１９経由）。例えば、ＬＧＷ１１６がＵＥ１００に関するデータパケットを有している場合には、データパケットは、リンク１１９を経由して伝送される。また、ＵＥ１００が家庭内又は企業ネットワーク１０３を離れる場合には、ＬＧＷ１１６はＳＧＷ１０９と通信を行って（リンク１２０経由）、家庭内又は企業ネットワーク１０３へのリモートアクセスをサポートすることが可能である。家庭内又は企業ネットワーク１０３へのリモートアクセスは、ユーザ加入者プロファイルに基づいて許可される。

ＥＰＳベアラがセットアップされたことがＭＭＥ１０５へ通知されると、ＭＭＥ１０５は、ＵＥ１００のために必要な無線ベアラをセットアップするようＨｅＮＢ１０４へ依頼する。なお、ＭＭＥ１０５がＥＰＳベアラの識別子をＨｅＮＢ１０４へ渡すことで、ＨｅＮＢ１０４は、ＵＥ１００の無線ベアラをＥＰＳベアラとマッピングすることが可能となる。ＵＥ１００のために無線ベアラがセットアップされると、ＵＥ１００は家庭内又は企業ネットワーク１０３におけるデータ通信を開始することが可能となる。例えば、ＵＥ１００は、メディアサーバ１１５からデータファイルをダウンロードすることが可能となる。この場合、データパスは、ＬＧＷ１１６がホームネットワーク１１８との接続を有しているリンク１２１を通過する。また、家庭内又は企業ネットワーク１０３のユーザには、通常のインターネットへの接続が提供されてもよく、これによって、ＵＥ１００はインターネットへのアクセスも許可される。例えば、インターネット１１３からのトラフィックは、リンク１２２を通過してホームネットワーク１１８へ届き、続いて、リンク１２１を通過してＬＧＷ１１６へ届く。ＬＧＷ１１６は、インターネット１１３からのトラフィックをＵＥ１００へ転送する。なお、上記は、家庭内又は企業ネットワーク１０３における一配置構成によって実現される一例であり、家庭内又は企業ネットワーク１０３は異なる配置構成であってもよい。

ＭＭＥ１０５は、ＵＥ１００あての着信ＣＳコールが存在しているというトリガをモバイルスイッチングセンタ（Mobile Switching Center：ＭＳＣ１２８）から受信した場合には、ＣＳコールが待機中であること（待機中ＣＳコール（pending CS call）が存在していること）を通知するために、ＣＳサービス通知をＵＥ１００へ送信する。このトリガは、リンク１２９を通じて伝送される。ＵＥ１００が、着信ＣＳコールを受けることをＭＭＥ１０５へ応答すると、ＭＭＥ１０５は、ＵＥ１００がＣＳコール待機中を有していることをＨｅＮＢ１０４へ通知する。ＨｅＮＢ１０４は、ＵＥ１００に関する待機中ＣＳコールの通知を受けると、ＵＥ１００がＣＳコールを受けるために適切なＣＳドメインを検索する。ここで、ＨｅＮＢ１０４が、例えばＵＥ１００からの測定レポートを使用して、基地局サブシステム（Base Station Subsystem：ＢＳＳ）１２３がＵＥ１００のＣＳコールの取り扱いに適切な候補であることを推定できると仮定する。この場合、ＨｅＮＢ１０４は、ＵＥ１００をＵＴＲＡＮ１０２へハンドオーバさせる準備を行うよう要求するリクエストをＢＳＳ１２３へ転送するよう、ＭＭＥ１０５へ依頼する。ＭＭＥ１０５は、ＢＳＳ１２３がＭＳＣ１２８によって管理されていることを把握し、リンク１２９を経由してＭＳＣ１２８へ接続する。なお、上述のように、ＵＴＲＡＮ１０２はＰＳサービスをサポートできないと仮定している。したがって、ＭＭＥ１０５は、ＭＳＣ１２８との間で通信を行って、ＵＥ１００をＵＴＲＡＮ１０２へハンドオーバさせる。

ＭＭＥ１０５は、必要なコンテキスト（例えば、セキュリティ鍵）をＭＳＣ１２８へ渡し、これによって、ＭＳＣ１２８は、ＵＥ１００の着信ＣＳコールを受信するための準備を行うことが可能となる。ＭＳＣ１２８は、ＵＥ１００がＵＴＲＡＮ１０２にハンドオーバされるべきであることを把握すると、ＣＳコールの無線リソースを準備するよう、ＢＳＳ１２３に対してリンク１３０を通じて通知する。ＢＳＳ１２３は、ＵＥ１００を受け入れる準備ができると、ＵＴＲＡＮ１０２への切り替えをＵＥ１００に対して指示するよう、ＨｅＮＢ１０４へ通知する（ＭＳＣ１２８及びＭＭＥ１０５を通じて）。そして、ＵＥ１００は、ＵＴＲＡＮ１０２へ切り替えを行って、着信ＣＳコールを受信する。

なお、ＵＴＲＡＮ１０２がＰＳトラフィックもサポートしている場合には、ＳＧＳＮ（Serving GPRS Support Node）１２４が、ＵＥ１００のＰＳトラフィックのハンドオーバに関する処理を行うことになる。この場合には、ＭＭＥ１０５は、必要なコンテキスト（例えば、セキュリティ鍵）をＳＧＳＮ１２４へ渡し、これによって、ＳＧＳＮ１２４は、ＵＥ１００のＰＳトラフィックの準備ができるようになる。ＭＭＥ１０５は、さらにＥＰＳベアラ識別子をＳＧＳＮ１２４へ通知する。ＳＧＳＮ１２４は、対応するパケットデータプロトコル（Packet Data Protocol：ＰＤＰ）コンテキストにＥＰＳベアラ識別子をマッピングして、ＥＰＳベアラ識別子をＢＳＳ１２３へ渡す。また、ＳＧＳＮ１２４は、ＵＥ１００のＰＳセッションに関して、ＳＧＷ１０９を介して（リンク１２７）、ＰＤＮ ＧＷ１０８又はＬＧＷ１１６のいずれかへの接続をセットアップする。例えば、ＵＥ１００が家庭内又は企業ネットワーク１０３へのリモートアクセスが許可されている場合には、ＵＥ１００は、ＵＴＲＡＮ１０２において、ＬＧＷ１１６へのデータ接続を継続することが可能である（リンク１２６、１２７、１２０経由）。

また、図２は、従来の技術並びに本発明の実施の形態に関連したネットワークシステムの別の一例を示す図である。なお、図２には、３ＧＰＰで説明されているシステムが例示されている。このシステムでは、ＵＥ２００は、ＰＳサービス及びＣＳサービスの両方を受けられるようにオペレータに登録されている。ＵＥ２００は、Ｅ−ＵＴＲＡＮ２０１とＵＴＲＡＮ２０２がオーバラップしている範囲内に存在しているとする。また、Ｅ−ＵＴＲＡＮ２０１は純粋なＰＳドメインである一方、ＵＴＲＡＮ２０２はＰＳドメイン及びＣＳドメインの両方をサポートしているとする。ＵＥ２００は現在、Ｅ−ＵＴＲＡＮ２０１に接続されている。Ｅ−ＵＴＲＡＮ２０１では、ｅＮＢ２０３がＥ−ＵＴＲＡＮ２０１における無線アクセスチャンネルをＵＥ２００へ提供している。また、セルラオペレータから提供されるサービスへのＵＥ２００のアクセス方法を制御するために、ＭＭＥ２０４が、ＵＥ２００に関して必要な認証手続き及びアクセスコントロール制御手続きを実行する。ＵＥ２００がセルラオペレータによって提供されるサービスに関して認証及び認可されると、ＭＭＥ２０４は、必要なリソースを提供するようｅＮＢ２０３へ通知し（リンク２０５）、ＵＥ２００との無線接続（すなわち、無線チャンネル）を確立する。

また、ＵＥ２００がセルラオペレータのＥＰＣ２０６経由でデータサービス（例えば、メディアサーバ２０８からのビデオストリーミング）を受けられるよう認可されている場合は、ＭＭＥ２０４は、ＵＥ２００がデータサービスへアクセスするために適切なＰＤＮ ＧＷ（ＰＤＮ ＧＷ２０７）を選択する。さらに、ＭＭＥ２０４は、ＵＥ２００がデータサービスへアクセスするために適切なサービングゲートウェイ（ＳＧＷ２０９）も選択する。ＭＭＥ２０４は、ＵＥ２００に関連して、ＰＤＮ ＧＷ２０７への必要な接続（リンク２１１）をセットアップするようＳＧＷ２０９へ依頼する。さらに、ＭＭＥ２０４は、ＵＥ２００に関連して、ｅＮＢ２０３への必要なＥＰＳベアラ（リンク２１２）をセットアップするようＳＧＷ２０９へ依頼する。ＵＥ２００に関連するデータパスがセットアップされると、ＵＥ２００のアプリケーション（例えば、メディアプレーヤ）は、インターネット２１３又はその他のネットワークへＰＤＮ ＧＷ２０７経由でアクセスすることが可能となる。ＰＤＮ ＧＷ２０７は、リンク２１４を用いて、ＵＥ２００から／へのデータパケットをインターネット２１３又はその他のネットワークへ／から転送する。

ＭＭＥ２０４は、ＵＥ２００あての着信ＣＳコールが存在しているというトリガをＭＳＣ２２２から受信した場合には、待機中ＣＳコールであることを通知するために、ＣＳサービス通知をＵＥ２００へ送信する。このトリガは、リンク２２３を通じて伝送される。ＵＥ２００が、着信ＣＳコールを受けることをＭＭＥ２０４へ応答すると、ＭＭＥ２０４は、ＵＥ２００が待機ＣＳコールを有していることをｅＮＢ２０３へ通知する。ｅＮＢ２０３は、ＵＥ２００に関する待機ＣＳコールの通知を受けると、ＵＥ２００がＣＳコールを受けるために適切なＣＳドメインを検索する。ここで、ｅＮＢ２０３が、例えばＵＥ２００からの測定レポートを使用して、ＢＳＳ２１５がＵＥ２００のＣＳコールの取り扱いに適切な候補であることを推定できると仮定する。この場合、ｅＮＢ２０３は、ＵＥ２００をＵＴＲＡＮ２０２へハンドオーバさせる準備を行うよう要求するリクエストをＢＳＳ２１５へ転送するよう、ＭＭＥ２０４へ依頼する。ＭＭＥ２０４は、ＢＳＳ２１５がＭＳＣ２２２によって管理されていることを把握し、リンク２２３を経由してＭＳＣ２２２へ接続する。なお、上述のように、ＵＴＲＡＮ２０２はＰＳサービスをサポートできないと仮定している。したがって、ＭＭＥ２０４は、ＭＳＣ２２２との間で通信を行って、ＵＥ２００をＵＴＲＡＮ２０２へハンドオーバさせる。

ＭＭＥ２０４は、必要なコンテキスト（例えば、セキュリティ鍵）をＭＳＣ２２２へ渡し、これによって、ＭＳＣ２２２は、ＵＥ２００の着信ＣＳコールを受信するための準備を行うことが可能となる。ＭＳＣ２２２は、ＵＥ２００がＵＴＲＡＮ２０２にハンドオーバされるべきであることを把握すると、ＣＳコールの無線リソースを準備するよう、ＢＳＳ２１５に対してリンク２２４を通じて通知する。ＢＳＳ２１５は、ＵＥ２００を受け入れる準備ができると、ＵＴＲＡＮ２０２への切り替えをＵＥ２００に対して指示するよう、ｅＮＢ２０３へ通知する（ＭＳＣ２２２及びＭＭＥ２０４を通じて）。そして、ＵＥ２００は、ＵＴＲＡＮ２０２へ切り替えを行って、着信ＣＳコールを受信する。

なお、ＵＴＲＡＮ２０２がＰＳトラフィックもサポートしている場合には、ＳＧＳＮ２１６が、ＵＥ２００のＰＳトラフィックのハンドオーバに関する処理を行うことになる。この場合には、ＭＭＥ２０４は、必要なコンテキスト（例えば、セキュリティ鍵）をＳＧＳＮ２１６へ渡し、これによって、ＳＧＳＮ２１６は、ＵＥ２００のＰＳトラフィックの準備が可能となる。ＭＭＥ２０４は、さらにＥＰＳベアラ識別子をＳＧＳＮ２１６へ通知する。ＳＧＳＮ２１６は、対応するＰＤＰコンテキストにＥＰＳベアラ識別子をマッピングして、ＥＰＳベアラ識別子をＢＳＳ２１５へ渡す。また、ＳＧＳＮ２１６は、ＵＥ２００のＰＳセッションに関して、ＳＧＷ２０９を介して（リンク２１９）、ＰＤＮ ＧＷ２０７への接続をセットアップする。これにより、ＵＥ２００は、ＵＴＲＡＮ２０２において、ＰＤＮ ＧＷ２０７へのデータ接続を継続することが可能となる（リンク２１８、２１９、２１１経由）。

ここで、ＳＧＳＮ２１６が、ＵＥ２００とＰＤＮ ＧＷ２０７とのデータ接続をＧＧＳＮ（Gateway GPRS Support Node）２２０へオフロードすることによって、このデータ接続に関するＳＩＰＴＯを実行することを決定したとする。この場合、ＵＥ２００のデータトラフィックはＧＧＳＮ２２０によって管理されることになる。なお、ＳＧＳＮ２１６がＳＩＰＴＯをトリガする理由としては、例えば、リンク２１９がＵＥ２００のデータトラフィックをルーティングするために効率的ではなく、大量のネットワークリソースを消費することを、ＳＧＳＮ２１６のポリシーが検出することが挙げられる。また、別の理由として、例えば、リンク２１９が輻輳しており、ＵＥ２００のデータトラフィックをサポートできないことが挙げられる。

例えば、ＵＥ２００のアプリケーション（例えば、ビデオプレーヤ）は、最初、インターネット２１３に配置されているメディアサーバ２０８からＰＤＮ ＧＷ２０７経由（リンク２１２、２１１、２１４）でビデオをストリーミングしていたとする。ＵＥ２００がＥ−ＵＴＲＡＮ２０１からＵＴＲＡＮ２０２へハンドオーバした場合には、ＵＥ２００のビデオストリームは、リンク２１８、２１９、２１１、２１４を伝送されるようになる。ここで、ＳＧＳＮ２１６は、ＵＥ２００のデータトラフィックが最適な経路で転送されていないことを検出し、ＵＥ２００によるＰＤＮ ＧＷ２０７へのデータ接続をＧＧＳＮ２２０へオフロードするよう決定する。ＳＧＳＮ２１６は、ＰＤＮ ＧＷ２０７へのＵＥ２００のデータ接続を切断し、データ接続のリクエストを送信するようＵＥ２００へ依頼する。そして、ＵＥ２００はそのリクエストを送信し、ＳＧＳＮ２１６は、ＵＥ２００のデータゲートウェイとしてＧＧＳＮ２２０を選択する。その結果、ＵＥ２００のビデオプレーヤは、ＧＧＳＮ２２０経由（リンク２１８、２２１、２２２）でメディアサーバ２０８からビデオストリームを受信する。なお、オフロード手順の間に、ＵＥ２００のＩＰアドレスが変わってしまうかもしれず、この場合には、メディアサーバ２０８へのＵＥ２００の進行中セッションは継続しないかもしれない。

また、特許文献１には、ユーザがポリシーのセットを定義して、ＣＳＦＢがどのように取り扱われるかを決定することができる方法が開示されている。特許文献１においては、例えば、ＵＥ内部に設定可能なポリシーとして、現在進行中の重要なＰＳセッションが存在するときには、ＵＥがネットワークからのＣＳＦＢに関するページを無視するというポリシーがユーザによって設定される。また、別の実施例においては、サービスリクエスト手続きの際に、ＵＥは、ＣＳＦＢによって現在のセッションに支障が来たされるべきではないことをＭＭＥへ通知するフラグを挿入することが開示されている。

また、特許文献２には、別のアクセス技術のネットワークへＵＥをハンドオーバさせる指示をＭＭＥが受信すると、ＭＭＥは、ＵＥのＰＳセッションが中断されることをＵＥへ通知し、その結果、ＵＥは、ターゲットアクセス技術に接続したときに、ターゲットアクセスネットワークにおいてデータセッションを再開できるようにすることが開示されている。

また、特許文献３には、音声サービスをサポートできるより良いＲＡＴ（Remote Access Technology：リモートアクセス技術）を再選択するために、ＵＥの音声アプリケーションが、優先権リスト内の周波数／ＲＡＴの優先度の変更を行う方法が開示されている。

米国特許公開公報２００９／０２５８６７１Ａ１ 米国特許公開公報２０１０／０１３５２０６Ａ１ 米国特許公開公報２０１０／０１１３０１０Ａ１

3GPP TS 23.272 (V10.1.0): "Circuit Switched (CS) fallback in Evolved Packet System (EPS)", 2010-09 3GPP TR 23.829 (V1.3.0): "Local IP Access and Selected IP Traffic Offload", 2010-09

ＵＥがＣＳＦＢによって別のアクセスネットワークへハンドオーバされた場合に、ＵＥのＰＳセッションに関してセッション継続性をどのように維持するかについての問題が生じる。例えば図１において、ＵＥ１００が、ＣＳＦＢによってＵＴＲＡＮ１０２へハンドオーバを行う前に、メディアサーバ１１５との間でＬＩＰＡのＰＳセッションを有している場合には、ＣＳコール後にＵＥ１００がＬＩＰＡのＰＳセッションを継続できないことがある。例えば、ＣＳコールを受けるために接続するターゲットアクセスネットワーク（例えば、ＵＴＲＡＮ又はＧＥＲＡＮ（GSM/EDGE Radio Access Network））がＰＳサービスをサポートしていないという理由で、この問題が生じる。この場合には、ＬＩＰＡのＰＳセッションはハンドオーバできない。また、セルラオペレータのポリシーにより、ＬＩＰＡのＰＳセッションを現在のサービスセルからハンドオーバさせることが許可されていないなどの理由によって、この問題が生じる。さらに、別な理由として、ユーザ加入者情報によって、ＵＥがＬＩＰＡサービスを有するセル内に存在しない場合にはＬＩＰＡサービスへのリモートアクセスを許可しないことが定められている場合も考えられる。

さらに、ターゲットセルに、ＬＩＰＡのＰＳセッションをサポートできるだけの十分なリソースが存在しないことも考えられる。この場合には、ＵＥ１００がＥ−ＵＴＲＡＮ１０１からハンドオーバする際に、ＨｅＮＢ１０４が、ＵＥ１００のＬＩＰＡのＰＳセッションの終了をトリガし、ＵＥ１００は、ユーザがＣＳコールを終了した後、メディアサーバ１１５への新たなＬＩＰＡのＰＳセッションを確立する必要がある。新たなＬＩＰＡのＰＳセッションには異なるＩＰアドレスが割り当てられる可能性が高く、これによって、ＵＥ１００は、メディアサーバ１１５との間のダウンロードアプリケーションを再起動しなければならなくなる。

また、ＵＥ１００がＬＩＰＡのＰＳセッションを再開できない理由は、セル選択を行う基準がＵＥ１００にどのように実装されているのかにもよる。例えば、ＵＥ１００は、ＣＳコール後にアイドルモードへ入ると、アクセスストラタム（Access Stratum：ＡＳ）レイヤが何らかの無線測定を行って、ＵＥ１００がどのセルに接続すべきかを判断するかもしれない。現在、ＵＥ１００内のＡＳは、最も強い信号（すなわち、ＵＥ１００が感じる最も高い信号強度）を持つセルにＵＥ１００を滞在させるというロジックに基づいている。したがって、ＵＥ１００は、ＵＴＲＡＮ１０２のセルが最も強い信号を有しており、ＵＴＲＡＮ１０２に滞在すると判断する可能性がある。この判断によれば、ＣＳコール後にメディアサーバ１１５とのＬＩＰＡのＰＳセッションを継続するために、ＵＥ１００はＥ−ＵＴＲＡＮ１０１へ接続を戻さないことになる。

また、図２に図示されているシナリオにおいても同様に、ＵＥがＣＳＦＢによって別のアクセスネットワークへハンドオーバされた場合に、ＵＥのＰＳセッションに関してセッション継続性をどのように維持するかについての問題が生じ得る。図２において、ＳＧＳＮ２１６は、ＧＧＳＮ２２０がＵＥ２００のデータ接続の管理に適した候補であることを検出する。ＳＧＳＮ２１６は、ＵＥ２００のＰＳセッションをＰＤＮ ＧＷ２０７からＧＧＳＮ２２０へオフロードすることによって、ＳＩＰＴＯをトリガすることが可能である。しかしながら、データゲートウェイの変更は、ＵＥ２００に割り当てられるＩＰアドレスが変更され、その結果、ＵＥ２００とメディアサーバ２０８とのセッションが継続できないことを意味する。また、ＵＥ２００がＣＳコール後にＥ−ＵＴＲＡＮ２０１へ戻るよう選択した場合には、ＭＭＥ２０４は、ＵＥ２００のデータ接続をＰＤＮ ＧＷ２０７へ再配置し、その結果、ＩＰアドレスが再び変更されるかもしれない。

また、特許文献１に開示されている技術によれば、ＵＥがネットワークからのＣＳＦＢに関するページを無視したり、ＣＳＦＢによって現在のセッションに支障が来たされるべきではないこと（例えば、ＣＳドメインへのＰＳハンドオーバが起こるべきではないこと）が通知されたりする。すなわち、特許文献１に開示されている技術は、ＵＥが現在接続しているネットワークに滞在して現在のネットワークにおける現在の状態を維持するように動作を行うものであり、本発明における目的（ＣＳコールが存在する場合にＵＥのＰＳセッションを維持する）を、ＣＳＦＢを実行しないという別の解決方法によって実現するものである。

また、特許文献２に開示されている技術によれば、ターゲットアクセスネットワークにおいて、すべてのデータセッションが再開できることが前提となっている。本発明では、例えば、ユーザの加入者情報によってハンドオーバが許可されないこと、あるいは、ハンドオーバ要件によってセルラオペレータがハンドオーバを実施しないことなど、あるＰＳセッションがターゲットアクセスネットワークへハンドオーバできない場合も前提としている。また、特許文献２においてはＵＥのデータセッションが中断できると言及されているが、データセッションがハンドオーバできない場合に、ＵＥが再び元のソースアクセスネットワークに戻ってデータセッションを再開することに関しては一切言及されていない。したがって、特許文献２に開示されている技術は、起こり得るあらゆるシナリオにおいて、ＵＥのＰＳセッションを維持できるようにしているものではなく、本発明に係る課題を解決するものではない。

また、特許文献３に開示されている技術は、ＵＥがＣＳＦＢによるハンドオーバを実行する前に進行中セッションを有しているというトリガに基づいて、ＣＳコールの終了時にＥ−ＵＴＲＡＮへ戻ってＰＳセッションを再開するというように優先度リストを変更することができるかもしれない。しかしながら、特許文献３に開示されている技術によれば、別のタイプのトリガに基づく接続先変更を利用することは可能かもしれないが、ＵＥの音声アプリケーション以外の別の形式については一切言及されていない。

本発明は、少なくとも、上述した問題点又は短所を実質的に改善することを目的とし、通信端末が、異種間ネットワークでハンドオーバを行った後であっても、ハンドオーバ前に接続していたアクセスネットワークにおいて進行中であった通信を再開できるかどうかを判断できるようにすることを目的とする。具体的には、本発明は、ＵＥがＣＳコールを行うため（発呼）あるいは受けるため（着呼）に、別のアクセスネットワークへハンドオーバした後であっても、あるアクセスネットワークにおけるＵＥの進行中のＰＳセッションが継続されるようにすることを目的とする。

上記の目的を達成するため、本発明の通信端末は、第１通信技術をサポートしているが第２通信技術をサポートしていない第１ネットワークと、前記第２通信技術をサポートしている第２ネットワークとによって構成されているネットワークに接続可能な通信端末であって、
前記第１ネットワークに接続して前記第１通信技術による通信を行う第１通信部と、
前記第１通信技術による通信を行っている際に、前記第２通信技術による通信を開始するトリガを取得する第２通信トリガ取得部と、
前記トリガに応じて、前記第１ネットワークから前記第２ネットワークへ接続を切り替えて前記第２通信技術による通信を開始する第２通信部と、
前記トリガに応じて開始された前記第２通信技術による通信を終了する前までに、所定の通信再開条件を前記ネットワークから取得する条件取得部と、
前記第２通信技術による通信の終了後に、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点からの前記第１通信技術による通信を再開できるかどうかを、前記所定の通信再開条件が有効か否かに基づいて判断する再開判断部とを、
有する。
この構成により、あるアクセスネットワークにおいてある通信技術を利用して通信を行っている通信端末が、別の通信技術を利用した通信を行うために別のアクセスネットワークへハンドオーバした後であっても、ハンドオーバ前に接続していたアクセスネットワークにおいて進行中であった通信を再開できるかどうかを判断できるようになる

また、上記の目的を達成するため、本発明のネットワークノードは、第１通信技術をサポートしているが第２通信技術をサポートしていない第１ネットワークと、前記第２通信技術をサポートしている第２ネットワークとによって構成されているネットワークにおいて、前記第１ネットワークに位置しているネットワークノードであって、
前記第１ネットワークに接続して前記第１通信技術による通信を行っている通信端末に対して、所定の通信再開条件を提供する通信再開条件提供部を有し、
前記所定の通信再開条件が、前記第１通信技術による通信を行っている前記通信端末が前記第２通信技術による通信を開始するトリガを取得し、前記トリガに応じて前記第１ネットワークから前記第２ネットワークへ接続を切り替えて前記第２通信技術による通信を開始する場合、前記第２通信技術による通信の終了後に、前記通信端末が、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点からの前記第１通信技術による通信を再開できるかどうかを判断するために用いられる情報である。
この構成により、あるアクセスネットワークにおいて、ある通信技術を利用して通信を行っている通信端末が、別の通信技術を利用した通信を行うために別のアクセスネットワークへハンドオーバした後であっても、ハンドオーバ前に接続していたアクセスネットワークにおいて進行中であった通信を再開できるかどうかを判断できるようになる。

本発明は、従来技術の問題点又は短所を実質的に改善するという効果を有している。本発明は、通信端末が、異種間ネットワークでハンドオーバを行った後であっても、ハンドオーバ前に接続していたアクセスネットワークにおいて進行中であった通信を再開できるかどうかを判断できるようにするという効果を有する。具体的には、本発明は、ＵＥがＣＳコールを行うため（発呼）あるいは受けるため（着呼）に、別のアクセスネットワークへハンドオーバした後であっても、あるアクセスネットワークにおけるＵＥの進行中のＰＳセッションが継続されるようにするという効果を有する。

従来の技術並びに本発明の実施の形態に関連したネットワークシステムの一例を示す図 従来の技術並びに本発明の実施の形態に関連したネットワークシステムの別の一例を示す図 本発明の第１の実施の形態において、ＵＥに関するＬＩＰＡ ＰＳセッションを維持することをＵＥへ通知する方法の一例を説明するためのメッセージシーケンスチャート 本発明の第１の実施の形態において、ＵＥが、ＣＳＦＢによって別の無線アクセスネットワークへハンドオーバされる場合について説明するためのメッセージシーケンスチャート 本発明の第１の実施の形態において、ＣＳＦＢのトリガに対してＵＥが実行する処理の一例を示すフローチャート 本発明の第１の実施の形態において、ＣＳコールの終了後にＵＥによって行われる処理の一例を示すフローチャート 本発明の第１の実施の形態において、ＵＥがＬＩＰＡ接続を再開することをＬＧＷへ通知する方法の一例を示すメッセージシーケンスチャートである。 本発明の第２の実施の形態において、ＵＥに関するＰＳセッションを維持するための条件をＵＥへ通知するための方法の一例を説明するメッセージシーケンスチャート 本発明の第２の実施の形態において、ＵＥがＣＳＦＢに関連して別の無線アクセスネットワークへハンドオーバされたかどうかというイベントについて説明するためのメッセージシーケンスチャート 本発明の第２の実施の形態において、ＵＥが別の無線アクセスネットワークへハンドオーバされた後に、ネットワークがＳＩＰＴＯをトリガする場合の一例を示すメッセージシーケンスチャート。 本発明の第２の実施の形態において、ＣＳＦＢのトリガに対してＵＥが実行する処理の一例を示すフローチャート 本発明の第２の実施の形態において、ＣＳコールの終了後にＵＥによって行われる処理の一例を示すフローチャート 本発明の第２の実施の形態において、ＵＥがＰＤＮコネクションを再開することをＬＧＷへ通知する方法の一例を示すメッセージシーケンスチャート 本発明の第１の実施の形態において、ＵＥに関するＳＩＰＴＯ ＰＳセッションを維持する条件をＵＥへ通知する方法の一例を説明するメッセージシーケンスチャート 本発明の第１の実施の形態において、ＵＥがＣＳＦＢに関連して別のアクセスネットワークへハンドオーバされる場合の一例を示すメッセージシーケンスチャート 本発明を実現するための好適な機能アーキテクチャの一例を示すブロック図

以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下では、図１に図示されているネットワーク構成に関連した構成及び動作を第１の実施の形態として説明し、図２に図示されているネットワーク構成に関連した構成及び動作を第２の実施の形態として説明する。

本発明によれば、ＵＥが第１アクセスネットワークにおいてＰＳセッションを有しているときに、ネットワークによって第２アクセスネットワークへのＵＥのハンドオーバが行われた後も、第１アクセスネットワークにおけるＰＳセッションの継続性を実現できる技術が提供される。ネットワークは、第１アクセスネットワークにおけるＰＳセッションの継続性を実現するための条件をＵＥへ通知する。ネットワークは、ＵＥを第２アクセスネットワークへハンドオーバさせるよう指示を受けると、第１アクセスネットワークにおけるＵＥのＰＳセッションに関して、ＵＥへ通知した条件を適用する。第１アクセスネットワーク上でＵＥに提供される条件は、例えば、ＵＥが第２アクセスネットワークに存在するときに、第２アクセスネットワークにおいて何らかの動作を実行するようＵＥへ依頼するものである。ＵＥは、第２アクセスネットワークでのセッションを終了した後、第１アクセスネットワークから提供された条件がまだ有効かどうかを検証する。そして、この条件が有効であるならば、ＵＥは第１アクセスネットワークへ接続を戻して、ハンドオーバ前に第１アクセスネットワークで有していたＰＳセッションを再開する。

＜第１の実施の形態＞
まず、本発明の第１の実施の形態について説明する。第１の実施の形態では、図１に図示されているネットワーク構成の一例を参照しながら、本発明について説明する。図３は、本発明の第１の実施の形態において、ＵＥに関するＬＩＰＡ ＰＳセッションを維持することをＵＥへ通知する方法の一例を説明するためのメッセージシーケンスチャートである。ここでは、ユーザは、何らかのデータファイルをメディアサーバ１１５からＵＥ１００にダウンロードさせようとしていることを前提とする。ＵＥ１００は、ＰＤＮコネクションリクエストメッセージ（PDN connection request message）をＭＭＥ１０５へ送信する（ステップＳ３００）。ＰＤＮコネクションリクエストメッセージには、アクセスポイントネーム（Access Point Name：ＡＰＮ）、あるいは、ＬＧＷ１１６へのＬＩＰＡ接続（ＬＩＰＡコネクション）を確立しようとしていることをＭＭＥ１０５が把握できるようにするためのインディケータが含まれている。ＭＭＥ１０５は、ＵＥ１００がこのＬＩＰＡ接続を行う許可が与えられていることを確認した後、クリエイトセッションメッセージ（create session message）を送信することによって、ＵＥ１００がＬＩＰＡ接続を行おうとしていることをＬＧＷ１１６へ通知する（ステップＳ３０１）。ＬＧＷ１１６は、ＭＭＥ１０５へクリエイトセッション確認メッセージ（create session acknowledgement message）を送り返すことによって、ＬＩＰＡ接続を行おうとするＵＥ１００のリクエストを受け入れる（ステップＳ３０２）。本発明では、さらにＬＧＷ１１６が、ＵＥ１００への応答に一連の条件（条件のセット）を加える。この第１の実施の形態において、条件のセットには、例えば、ＵＥ１００がＣＳＦＢを実行している場合には、ＬＧＷ１１６はＬＩＰＡ接続をハンドオーバさせない代わりに、所定の時間だけＵＥ１００に関するデータパケットをバッファリングする処理を開始するという条件が含まれるが、これに限定されるものではない。また、条件のセットは、例えば、クリエイトセッション確認メッセージによって運ばれるプロトコル構成オプション（Protocol Configuration Options：ＰＣＯ）の新たな情報要素によって伝送可能であるが、これに限定されるものではない。

ＭＭＥ１０５は、ベアラセットアップメッセージ（bearer setup message）を用いて、ＵＥ１００のＬＩＰＡセッションに必要な無線ベアラを作成するよう、ＨｅＮＢ１０４へ通知する（ステップＳ３０３）。さらに、ＭＭＥ１０５は、ステップＳ３０３のベアラセットアップメッセージにＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）を加える。このとき、ＭＭＥ１０５は、クリエイトセッション確認メッセージのＰＣＯをＰＤＮコネクションアクセプトメッセージへコピーする。ＨｅＮＢ１０４は、ＰＤＮコネクションアクセプトメッセージをＵＥ１００へ転送する（ステップＳ３０４）。ＵＥ１００は、ＬＧＷ１１６から提供された条件のセットをＵＥ１００内部のデータベースに格納する（ステップＳ３０５）。そして、ＵＥ１００及びＨｅＮＢ１０４は、ＬＩＰＡ接続用のＵＥ１００の無線チャンネルの再構成（ＲＲＣ（Radio Resource Control）再構成）を続け（ステップＳ３０６）、無線チャンネルが再構成されると、ＵＥ１００はＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）をＭＭＥ１０５へ送信することで、ＬＩＰＡ接続の確立完了をシグナリングする（ステップＳ３０７）。この時点以降、ＵＥ１００は、ＬＩＰＡ接続を用いてメディアサーバ１１５と通信を行い、データファイルを取り込むことが可能となる。

また、図４は、本発明の第１の実施の形態において、ＵＥが、ＣＳＦＢによって別の無線アクセスネットワークへハンドオーバされる場合について説明するためのメッセージシーケンスチャートである。ここでは、ＵＥ１００が、データファイルを取り込むために、メディアサーバ１１５との間で現在進行中の通信を行っていることを前提とする。ＭＭＥ１０５は、ＵＥ１００への待機中ＣＳコールが存在しているという通知をＭＳＣ１２８から受信すると、ＣＳサービス通知メッセージ（CS service notification message）をＵＥ１００へ送信する（ステップＳ４００）。ＵＥ１００は、ＣＳサービス通知メッセージによって、ＵＥ１００への待機中ＣＳコールがあることを把握する。ユーザがＣＳコールを受ける場合には、ＵＥ１００は、拡張サービスリクエストメッセージ（Extended Service Request message）をＭＭＥ１０５へ送信する（ステップＳ４０１）。ＵＥ１００は、拡張サービスリクエストメッセージによって、ＵＥ１００がＣＳコールを受け入れることを通知する。ＣＳコールを受け入れることは、拡張サービスリクエストメッセージのＣＳＦＢ応答情報要素によって伝送される。

ＭＭＥ１０５は、拡張サービスリクエストメッセージをＵＥ１００から受信すると、ＵＥ１００がＣＳコールの受け入れを望んでいることを把握し、ＣＳケーパビリティドメインへＵＥ１００をハンドオーバさせる処理を開始するようＨｅＮＢ１０４へ通知する。これは、ＭＭＥ１０５がＣＳＦＢインディケータを含むＳ１ＡＰメッセージをＨｅＮＢ１０４へ送信することによって実現される（ステップＳ４０２）。ＨｅＮＢ１０４は、ＵＥ１００がＣＳＦＢを実行していることを把握すると、ＣＳＦＢハンドオーバが待機中であることをＬＧＷ１１６へ通知する（ステップＳ４０３）。この第１の実施の形態では、ＨｅＮＢ１０４及びＬＧＷ１１６が同一デバイスに実装されていることを想定しており、この通知が、デバイス内における実装独自（implementation specific）の内部トリガであってもよい。ＬＧＷ１１６は、ＨｅＮＢ１０４からの通知を受信すると、ＵＥ１００へ通知された条件のセットに基づいて、以降のＵＥ１００のデータパケットをバッファリングする処理を開始する（ステップＳ４０４）。

次に、非特許文献１に記載されているＣＳＦＢのインターＲＡＴハンドオーバ手順がトリガされる（ステップＳ４０５）。このＣＳＦＢのインターＲＡＴハンドオーバ手順では、ＨｅＮＢ１０４、ＭＭＥ１０５、ＳＧＳＮ１２４、ＭＳＣ１２８、ＢＳＳ１２３が関与して、ＣＳケーパブルドメインにおける無線リソースの準備が行われる。ここで、ターゲットＲＡＴ（すなわち、ＵＴＲＡＮ１０２）はＰＳサービスをサポートしていないとする。ＵＥ１００のための無線リソースが準備されると、ＨｅＮＢ１０４は、ＵＥ１００のために選択されたターゲットアクセスＣＳケーパブルドメインをＵＥ１００へ通知するハンドオーバコマンド（Handover command）を送る（ステップＳ４０６）。ＵＥ１００は、ＢＳＳ１２３によって管理されている、選択されたＣＳケーパブルドメインへの切り替えを行い、ＵＥ１００が到着に成功したことを示すハンドオーバ完了をＢＳＳ１２３へ送信する（ステップＳ４０７）。また、ＭＭＥ１０５は、ＵＥ１００に関するＬＩＰＡ接続がＵＴＲＡＮ１０２へハンドオーバできないことを把握しているので、ＵＥ１００に関するＬＩＰＡ接続のコンテキストを削除する（ステップＳ４０８）。

ＵＥ１００は、ＣＳケーパブルドメインへのＣＳＦＢを実行しているとき、内部でタイマを開始し、ＵＥ１００がＣＳケーパブルドメインにどのくらいの期間滞在しているかを把握する。図５は、本発明の第１の実施の形態において、ＣＳＦＢのトリガに対してＵＥが実行する処理の一例を示すフローチャートである。この第１の実施の形態では、ＵＥ１００がＣＳＦＢによるハンドオーバコマンドをＨｅＮＢ１０４から取得すると、その機能が開始される（ステップＳ５００）。機能は、ＬＧＷ１１６によって提供されたＵＥ１００のＬＩＰＡ接続に関する条件のセットをＵＥ１００のデータベースから取り出す処理を行う（ステップＳ５０２）。そして、機能は、取り出された条件のセットを用いて、ＵＥ１００のＬＩＰＡ接続に対して、どのような条件がＬＧＷ１１６によって設定されたのかを判断する（ステップＳ５０４）。

ＬＧＷ１１６がＵＥ１００のＬＩＰＡのＰＳセッションに関するバッファリングを実行しないと判断される場合、さらに、ＬＩＰＡ接続がＵＴＲＡＮ１０２へハンドオーバされないと判断される場合には、ＵＥ１００は、ＵＥ１００のＬＩＰＡ接続のコンテキストを削除する（ステップＳ５０６）。ＬＩＰＡ接続がハンドオーバ可能かどうかをＵＥ１００が判断する方法は、例えば、ＬＩＰＡ接続のＥＰＳベアラ識別子を含むハンドオーバコマンドメッセージに基づいて行われてもよいが、これに限定されるものではない。なお、ハンドオーバコマンドメッセージにＬＩＰＡ接続のＥＰＳベアラ識別子が含まれている場合には、ネットワークがＵＥ１００のＬＩＰＡ接続をＵＴＲＡＮ１０２へハンドオーバさせることを示している。ＬＩＰＡのコンテキストが削除されると、機能は終了となり（ステップＳ５０８）、ＵＥ１００は、ネットワークによって選択されたＣＳケーパブルドメインへのハンドオーバ処理を開始する。

また、ＬＧＷ１１６がＵＥ１００のＬＩＰＡのＰＳセッションに関するバッファリングを実行すると判断される場合には、機能は、ＵＥ１００の状態を、ＬＧＷ１１６から提供された条件のセットをＣＳコールの完了後にＵＥ１００にチェックさせる状態とする（ステップＳ５１０）。この状態では、ＵＥ１００は内部でタイマを開始し、ＵＥ１００においてＣＳコールがどのくらいの期間行われたかを把握する。ＵＥ１００がこの状態になると、機能は終了となり（ステップＳ５０８）、ＵＥ１００はネットワークによって選択されたＣＳケーパブルドメインへのハンドオーバ処理を開始する。

ＵＥ１００は、ＣＳコールの終了時に、ＬＧＷ１１６によって提供された条件のセットがまだ有効かどうかをタイマの値を用いてチェックする。図６は、本発明の第１の実施の形態において、ＣＳコールの終了後にＵＥによって行われる処理の一例を示すフローチャートである。ＵＥ１００がＣＳコールを終了し、ＬＧＷ１１６によって提供された条件のセットをＣＳコールの完了後にチェックする状態となると、その機能が開始される（ステップＳ６００）。そして、機能は、ＬＧＷ１１６によって提供された条件のセットがＣＳコール後もまだ有効かどうかを判断する（ステップＳ６０２）。ＬＧＷ１１６によって提供された条件のセットは最早無効であると判断される場合には、ＵＥ１００は、ＵＥ１００のＬＩＰＡ接続のコンテキストを削除する（ステップＳ６０４）。ＬＩＰＡのコンテキストが削除されると、機能は終了となる（ステップＳ６０６）。この時点で、ＵＥ１００のグラフィカルユーザインタフェース（ＧＵＩ）から、ＬＩＰＡのＰＳセッションが切断されたこと、及び、次のステップに関してユーザからの入力待ちであることをユーザに対して表示してもよい。

また、ＬＧＷ１１６によって提供された条件のセットがまだ有効であると判断される場合には、機能は、ＵＥ１００のアクセスストラタム（ＡＳ）レイヤに対して、ＣＳコールを受ける前にＬＩＰＡのＰＳセッションを有していたネットワーク（すなわち、家庭内又は企業ネットワーク１０３）へ戻る選択を行うよう指示する（ステップＳ６０８）。なお、条件のセットがまだ有効であるかどうかを判断する方法としては、例えば、ＬＧＷ１１６のバッファリング期間がＵＥ１００によって開始されたタイマの値（ＣＳコールがどのくらいの期間だったかを示す値）より小さい（短い）ことを確認すればよいが、これに限定されるものではない。また、家庭内又は企業ネットワーク１０３に戻るよう選択する方法としては、例えば、ＵＥ１００のノンアクセスストラタム（Non-Access Stratum：ＮＡＳ）が、Ｅ−ＵＴＲＡＮ１０１のセル識別子のみを含んでいるマニュアルＣＳＧ選択コマンドをＵＥ１００のＡＳレイヤへ送ればよいが、これに限定されるものではない。家庭内又は企業ネットワーク１０３へ戻る選択を行うようＡＳレイヤへ指示すると、機能は終了となる（ステップＳ６０６）。

ＵＥ１００が家庭内又は企業ネットワーク１０３へ戻る選択を行ってＨｅＮＢ１０４へ接続すると、ＵＥ１００は、ＵＥ１００が家庭内又は企業ネットワーク１０３へ戻って、ＬＩＰＡ接続の再開を望んでいることをＬＧＷ１１６へ通知する必要がある。図７は、本発明の第１の実施の形態において、ＵＥがＬＩＰＡ接続を再開することをＬＧＷへ通知する方法の一例を示すメッセージシーケンスチャートである。

ＵＥ１００は、ＨｅＮＢ１０４へ接続した後、トラッキングエリアアップデート（Tracking Area Update：ＴＡＵ）メッセージをＭＭＥ１０５へ送信して、ＵＥ１００がＵＴＲＡＮ１０２からＥ−ＵＴＲＡＮ１０１へ変更したことをＭＭＥ１０５へ通知する（ステップＳ７００）。ＭＭＥ１０５は、ＵＥ１００へトラッキングエリア応答（Tracking Area Response：ＴＡＲ）メッセージを返信することによって、その変更を受け入れる（ステップＳ７０１）。次に、ＵＥ１００は、ＰＤＮコネクションリクエストメッセージ（PDN connection request message）をＭＭＥ１０５へ送信する（ステップＳ７０２）。ＰＤＮコネクションリクエストメッセージには、ＵＥ１００がＬＧＷ１１６へのＬＩＰＡ接続を確立しようとしていることをＭＭＥ１０５が把握できるアクセスポイントネーム（ＡＰＮ）が含まれている。また、ＰＤＮコネクションリクエストメッセージには、ＬＧＷ１１６がＵＥ１００に関してバッファリングを行っている以前のＬＩＰＡ接続をＵＥ１００が再開しようとしていることを、ＵＥ１００からＬＧＷ１１６へ通知できるインディケータが含まれている。ＵＥ１００からＬＧＷ１１６への通知方法としては、例えば、ＵＥ１００が使用していたＬＩＰＡ接続のＩＰアドレスを含むＰＣＯ内の新たな情報要素を用いることができるが、これに限定されるものではない。

ＭＭＥ１０５は、ＵＥ１００がこのＬＩＰＡ接続を行えるよう許可されていることを確認した後、クリエイトセッションメッセージ（create session message）を送信することによって、ＵＥ１００がＬＩＰＡ接続を行おうとしていることをＬＧＷ１１６へ伝送する（ステップＳ７０３）。このとき、ＵＥ１００が使用していたＬＩＰＡ接続のＩＰアドレスを含むＰＣＯは、ＰＤＮコネクションリクエストメッセージからクリエイトセッションメッセージへコピーされる。ＬＧＷ１１６は、ＵＥ１００が以前のＬＩＰＡ接続の再開を望んでいることを把握し、ＵＥ１００が以前使用していた同一ＩＰアドレスを再度割り当てる。ＬＧＷ１１６は、ＬＩＰＡ接続を確立するために、クリエイトセッション確認メッセージ（create session acknowledgement message）をＭＭＥ１０５へ送り返す（ステップＳ７０４）。ＭＭＥ１０５は、ベアラセットアップメッセージを用いて、ＵＥ１００のＬＩＰＡのセッションを可能とするために必要な無線ベアラを作成するようＨｅＮＢ１０４へ通知する（ステップＳ７０５）。なお、ＭＭＥ１０５は、ステップＳ７０５におけるベアラセットアップメッセージ（bearer setup message）にＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）も加える。

その後、ＨｅＮＢ１０４は、ＰＤＮコネクションアクセプトメッセージをＵＥ１００へ転送する（ステップＳ７０６）。ＵＥ１００は、ＬＧＷ１１６によって割り当てられたＩＰアドレスが、以前のＬＩＰＡ接続で使用されていたＩＰアドレスと同一である（あるいは、似ている）ことを確認する。そして、ＵＥ１００及びＨｅＮＢ１０４は、ＬＩＰＡ接続に関して、ＵＥ１００の無線チャンネルの再構成処理（ＲＲＣ再構成）を行い（ステップＳ７０７）、無線チャンネルが再構成されると、ＵＥ１００はＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）をＭＭＥ１０５へ送信することで、ＬＩＰＡ接続の確立完了をシグナリングする（ステップＳ７０８）。この時点以降、ＵＥ１００は、以前のＬＩＰＡ接続を用いてメディアサーバ１１５と通信を行い、データファイルの取り込みを継続することが可能となる。また、図７には不図示であるが、ＬＧＷ１１６は、バッファリングされているＬＩＰＡのＰＳセッションのパケットをＵＥ１００へ転送する。

以下、この第１の実施の形態の一例について明確に説明する。ここでは、家庭内又は企業ネットワーク１０３において、ＵＥ１００のユーザがメディアサーバ１１５からビデオファイルをダウンロードしようとしていることを前提とする。ＵＥ１００が家庭内又は企業ネットワーク１０３においてＬＩＰＡ接続の確立に必要な処理を実行すると、ＬＧＷ１１６は、ＬＩＰＡ接続に関する条件のセットをＵＥ１００へ通知する。ＵＥ１００は、ビデオファイルをダウンロードしている途中で、ユーザへの待機中ＣＳコールが存在しているという通知をネットワークから受信する。ユーザはこのＣＳコールを受け入れ、ＵＥ１００は、ネットワークによって選択されたＣＳケーパブルドメインへハンドオーバするようネットワークから指示を受ける。

ＬＧＷ１１６は、ＵＥ１００がＣＳコールによってハンドオーバされることを把握すると、ＵＥ１００のＬＩＰＡ接続に関するＰＳセッションのパケットのバッファリングを開始する。ＵＥ１００は、ハンドオーバ処理の間、ＬＧＷ１１６から提供される条件のセットに気付き、ＬＧＷ１１６がＵＥ１００のＬＩＰＡ接続に関するＰＳセッションのパケットをバッファリングしていることを知っているので、ＣＳコール後に、ＵＥ１００の状態を条件のセットをチェックする状態へと遷移させる。さらに、ＵＥ１００は内部でタイマを開始し、ＵＥ１００が家庭内又は企業ネットワーク１０３からどのくらいの期間離れているかを判断する。そして、ＣＳコールの完了後、ＵＥ１００は、ＬＧＷ１１６によって提供された条件のセットがまだ有効であるかどうかを検証する。条件のセットが有効であるならば、ＵＥ１００は、家庭内又は企業ネットワーク１０３へ戻るよう選択し、ＬＧＷ１１６との間におけるＬＩＰＡ接続を再開する。ＵＥ１００は、家庭内又は企業ネットワーク１０３に戻ると、ＬＩＰＡ接続を再開するためにＵＥ１００が戻ったことをＬＧＷ１１６へ通知する。ＬＧＷ１１６は、ＵＥ１００がＬＩＰＡ接続のために以前使用していた同一ＩＰアドレスを再度割り当てて、バッファリングされているＵＥ１００のＰＳセッションのパケットをＵＥ１００へ転送する。

この第１の実施の形態では、ＵＥ１００がＣＳコールに関連して（すなわち、ＣＳコールを行うか、あるいは、受けるために）別のアクセスネットワークへハンドオーバされた後であっても、あるアクセスネットワークにおけるＵＥ１００の現在進行中のＰＳセッションに関する継続を認めることによって、本発明の目的が実現される。これは、ユーザがＣＳコールを完了した後に、ＣＳコールの前に行っていたＰＳセッション（例えば、ホームサーバからのファイルのダウンロード）を再開できることを意味する。ＵＥ１００は、ネットワークによって提供された条件に基づいて、ＰＳセッションを再開できるかどうかを判断する。そして、ＰＳセッションが再開できると判断した場合には、ＵＥ１００は、元のアクセスネットワーク（元のセル）へ接続を戻してＰＳセッションを再開する。

なお、上述の実施の形態（第１の実施の形態）では、図４のステップＳ４０３において、ＨｅＮＢ１０４からＬＧＷ１１６に対して、ＵＥ１００がＣＳＦＢによって別のアクセスネットワークへハンドオーバされたことが通知される。しかしながら、ＨｅＮＢ１０４が、ＬＧＷ１１６に対してこの通知を送信しないようにすることも可能である。その代わり、ＬＧＷ１１６は、ＵＥ１００がＨｅＮＢ１０４からハンドオーバしたという通知をＨｅＮＢ１０４から受けた際に、ＵＥ１００のＬＩＰＡ接続のＰＳセッションのバッファリングを開始する。例えば、ＵＥ１００のＬＩＰＡ接続のＰＳセッションがターゲットアクセスネットワークへハンドオーバできる場合には、ＬＧＷ１１６が受ける通知（バッファリングを開始するトリガとなる通知）として変更ベアラリクエストが利用可能であるが、これに限定されるものではない。また、例えば、ＵＥ１００のＬＩＰＡ接続のＰＳセッションがターゲットアクセスネットワークにハンドオーバできない場合には、ＬＧＷ１１６が受ける通知（バッファリングを開始するトリガとなる通知）として削除セッションリクエストが利用可能であるが、これに限定されるものではない。このように、ＨｅＮＢ１０４がＬＧＷ１１６に対して通知を行わないようにした場合、ＨｅＮＢ１０４とＬＧＷ１１６との間で相互作用が必要ではないという利点がある。これは、ＬＧＷ１１６が、ＣＳＦＢによるハンドオーバと、ＵＥ１００のモビリティによるハンドオーバとを区別する必要がないことを意味する。

また、上述の実施の形態（第１の実施の形態）では、ＨｅＮＢ１０４とＬＧＷ１１６とが単一のデバイスに実装されていることを想定している。したがって、ＵＥ１００がＣＳＦＢによってハンドオーバされる際に、ＨｅＮＢ１０４からＬＧＷ１１６への通知には、同一デバイス内における実装独自（implementation specific）の内部トリガが使用可能である。しかしながら、ＨｅＮＢ１０４とＬＧＷ１１６とが異なるデバイスに実装されていてもよい。この場合には、ＵＥ１００がＣＳＦＢによってハンドオーバされたことを通知するために、ＨｅＮＢ１０４とＬＧＷ１１６との間でメッセージ交換が必要となる。このメッセージ交換は、例えば、ＨｅＮＢ１０４がＳ１ＡＰメッセージをＭＭＥ１０５へ送信して、ＵＥ１００がＣＳＦＢによってハンドオーバされたことを通知することによって実現可能である。この場合、ＭＭＥ１０５は、例えば削除セッションリクエストメッセージを用いて、この通知をＳＧＷ１０９経由でＬＧＷ１１６へ転送する。ＨｅＮＢ１０４の機能とＬＧＷ１１６の機能が異なるデバイスに実装される場合には、これらのデバイスの製造又は設定を容易にするという利点がある。

＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。第２の実施の形態では、図２に図示されているネットワーク構成の一例を参照しながら、本発明について説明する。図８は、本発明の第２の実施の形態において、ＵＥに関するＰＳセッションを維持するための条件をＵＥへ通知するための方法の一例を説明するメッセージシーケンスチャートである。第２の実施の形態では、ユーザが、ＵＥ２００を用いてメディアサーバ２０８からビデオストリーミングを受けようとしていることを前提とする。したがって、ＵＥ２００は、ＰＤＮコネクションリクエストメッセージ（PDN connection request message）をＭＭＥ２０４へ送信する（ステップＳ８００）。ＰＤＮコネクションリクエストメッセージには、ＵＥ２００が特定のＡＰＮへのＰＤＮコネクションを確立しようとしていることをＭＭＥ２０４が把握できるアクセスポイントネーム（ＡＰＮ）が含まれていてもよい。ＭＭＥ２０４は、ＵＥ２００によるＰＤＮコネクションの作成が許可されていることを確認した後、クリエイトセッションメッセージ（create session message）を送信することによって、ＵＥ２００がＰＤＮコネクションを求めていることをＳＧＷ２０９へ通知する（ステップＳ８０１）。ＳＧＷ２０９は、クリエイトセッションメッセージをＰＤＮ ＧＷ２０７へ転送することによって、ＵＥ２００がＰＤＮコネクションを求めていることをＰＤＮ ＧＷ２０７へ伝送する（ステップＳ８０２）。

ＰＤＮ ＧＷ２０７は、ポリシーコントロール及びチャージングルール機能（ＰＣＲＦ：Policy Control and Charging Rules Function）に問い合わせを行った後、ＵＥ２００によるＰＤＮコネクションの作成のリクエストを受け入れ、クリエイトセッション確認メッセージ（create session acknowledgement message）を用いてＳＧＷ２０９へ応答を行う（ステップＳ８０３）。本発明では、さらにＰＤＮ ＧＷ２０７が、ＵＥ２００への応答に条件のセットを加えるこの第２の実施の形態において、条件のセットには、例えば、ＵＥ２００がＣＳＦＢを実行している場合には、ＰＤＮ ＧＷ２０７は所定の時間だけＵＥ２００のデータパケットをバッファリングする処理を開始するという条件が含まれるが、これに限定されるものではない。また、ＰＤＮ ＧＷ２０７はＰＤＮコネクションをハンドオーバしてもよく、条件のセットに、ＰＤＮコネクションがハンドオーバされるかどうかについての条件が含まれてもよい。ＰＤＮ ＧＷ２０７はデータパケットをバッファリングするので、ＵＥ２００は、ＰＤＮコネクションがハンドオーバされた場合にはターゲットアクセスネットワークにおけるこのＰＤＮセッションを削除する必要がある。また、条件のセットは、例えば、クリエイトセッション確認メッセージで運ばれるプロトコル構成オプション（ＰＣＯ）内の新たな情報要素によって伝送可能であるが、これに限定されるものではない。ＳＧＷ２０９は、クリエイトセッション確認メッセージをＭＭＥ２０４へ転送する（ステップＳ８０４）。

ＭＭＥ２０４は、ベアラセットアップメッセージ（bearer setup message）を用いて、ＵＥ２００のＰＤＮコネクションに必要な無線ベアラを作成するよう、ｅＮＢ２０３へ通知する（ステップＳ８０５）。さらに、ＭＭＥ２０４は、ステップＳ８０５のベアラセットアップメッセージにＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）を加えてもよい。このとき、ＭＭＥ２０４は、クリエイトセッション確認メッセージのＰＣＯをＰＤＮコネクションアクセプトメッセージへコピーする。ｅＮＢ２０３は、ＰＤＮコネクションアクセプトメッセージをＵＥ２００へ転送する（ステップＳ８０６）。ＵＥ２００は、ＰＤＮ ＧＷ２０７から提供された条件のセットをＵＥ２００内部のデータベースに格納する（ステップＳ８０７）。そして、ＵＥ２００及びｅＮＢ２０３は、ＰＤＮコネクション用のＵＥ２００の無線チャンネルの再構成を続け（ステップＳ８０８）、無線チャンネルが再構成されると、ＵＥ２００はＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）をＭＭＥ２０４へ送信することで、ＰＤＮコネクションの確立完了をシグナリングする（ステップＳ８０９）。この時点以降、ＵＥ２００は、ＰＤＮコネクションを用いてメディアサーバ２０８と通信を行い、ビデオファイルを取り込むことが可能となる。

図９は、本発明の第２の実施の形態において、ＵＥがＣＳＦＢに関連して別の無線アクセスネットワークへハンドオーバされたかどうかというイベントについて説明するためのメッセージシーケンスチャートである。ここでは、ＵＥ２００が、メディアサーバ２０８と現在進行中の通信を行っており、メディアサーバ２０８からビデオのストリーミングを取得していることを前提とする。ＭＭＥ２０４は、ＵＥ２００への待機中ＣＳコールが存在しているという通知をＭＳＣ２２２から受信すると、ＣＳサービス通知メッセージ（CS service notification message）をＵＥ２００へ送信する（ステップＳ９００）。ＵＥ２００は、ＣＳサービス通知メッセージによって、ＵＥ２００への待機中ＣＳコールがあることを把握できる。ユーザがＣＳコールを受ける場合には、ＵＥ２００は、拡張サービスリクエストメッセージ（Extended service request message）をＭＭＥ２０４へ送信する（ステップＳ９０１）。ＵＥ２００は、拡張サービスリクエストによって、ＵＥ２００がＣＳコールを受け入れることを通知する。これは、例えば、拡張サービスリクエストメッセージのＣＳＦＢレスポンス情報要素によって伝送される。

ＭＭＥ２０４は、拡張サービスリクエストメッセージをＵＥ２００から受信すると、ＵＥ２００がＣＳコールの受け入れを望んでいることを把握し、ＣＳケーパビリティ有するドメインへＵＥ２００をハンドオーバさせる処理を開始するようｅＮＢ２０３へ通知する。これは、ＭＭＥ２０４が、ＣＳＦＢインディケータを含むＳ１ＡＰメッセージをｅＮＢ２０３へ送信することによって実現される（ステップＳ９０２）。ｅＮＢ２０３は、ＵＥ２００がＣＳＦＢを実行しており、かつ、ＵＥ２００がＳＩＰＴＯ ＰＳセッションを有していることを把握すると、ＣＳＦＢハンドオーバが待機中であることをＰＤＮ ＧＷ２０７へ通知する。この通知は、ステップＳ９０３、Ｓ９０４、Ｓ９０５において、ｅＮＢ２０３からＰＤＮ ＧＷ２０７へ、ＭＭＥ２０４経由（例えば、ハンドオーバ必須メッセージ（handover required message）を用いる）及びＳＧＷ２０９経由（例えば、削除セッションリクエストメッセージ（Delete Session Request message）を用いる）で渡される。ＰＤＮ ＧＷ２０７は、ｅＮＢ２０３からの通知を受信すると、ＵＥ２００へ通知された条件のセットに基づいて、以降のＵＥ２００のデータパケットをバッファリングする処理を開始する（ステップＳ９０６）。

次に、非特許文献１に記載されているＣＳＦＢのインターＲＡＴハンドオーバ手順がトリガされる（ステップＳ９０７）。このＣＳＦＢのインターＲＡＴハンドオーバ手順では、ｅＮＢ２０３、ＭＭＥ２０４、ＳＧＷ２０９、ＰＤＮ ＧＷ２０７、ＳＧＳＮ２１６、ＭＳＣ２２２、ＢＳＳ２１５が関与して、ＣＳケーパブルドメインにおける無線リソースの準備が行われる。ここで、ターゲットＲＡＴ（すなわち、ＵＴＲＡＮ２０２）がＰＳサービスをサポートしていないとする。ＵＥ２００のための無線リソースが準備されると、ｅＮＢ２０３は、ＵＥ２００のために選択されたターゲットアクセスＣＳケーパブルドメインをＵＥ２００へ通知するハンドオーバコマンド（handover command）を送る（ステップＳ９０８）。ＵＥ２００は、ＢＳＳ２１５によって管理されている、選択されたＣＳケーパブルドメインへの切り替えを行い、ＵＥ２００が到着に成功したことを示すハンドオーバ完了（handover complete）をＢＳＳ２１５へ送信する（ステップＳ９０９）。

また、ターゲットアクセスネットワークがＰＳサービスをサポートしている場合には、ＵＴＲＡＮ２０２もＰＳサービスをサポートしているので、ＭＭＥ２０４は、ＵＥ２００のＰＳセッションをＳＧＳＮ２１６へハンドオーバさせる。その結果、ＵＥ２００は、ＵＴＲＡＮ２０２においてＰＳセッションを継続することが可能となる。しかしながら、データシグナリングパスは最適化されない状態となる。図２を参照すると、ＵＥ２００がメディアサーバ２０８からのビデオストリーミングを継続する場合には、データパスはリンク２１８、２１９、２１１、２１４となる。この最適化されていないデータパスは、セルラオペレータのＥＰＣリソースの消費量を増大させる可能性がある。このような最適化されていないパスの使用を防ぐ方法は、例えば、ＵＥ２００がＥＰＣ２０６からのＰＳサービスを削除することである。

また、図１０は、本発明の第２の実施の形態において、ＵＥが別の無線アクセスネットワークへハンドオーバされた後に、ネットワークがＰＳセッションの削除をトリガする場合の一例を示すメッセージシーケンスチャートである。ＳＧＳＮ２１６は、ＵＥ２００のＰＳセッションに関する現在のデータ接続が最適化されていないことを検出すると、デタッチリクエストメッセージ（Detach Request message）をＵＥ２００へ送信する（ステップＳ１０００）。ＳＧＳＮ２１６は、デタッチリクエストメッセージにリアタッチ（再アタッチ）のコーズ値を挿入して、デタッチ手順の完了後にＵＥ２００がアタッチ手順を実行するよう通知してもよい。また、ＳＧＳＮ２１６は、削除セッションメッセージ（Delete session message）をＳＧＷ２０９へ送信し、ＵＥ２００のＰＤＮコネクションを削除する（ステップＳ１００１）。ＳＧＷ２０９は、ＵＥ２００のＰＤＮコネクションが切断されることをＰＤＮ ＧＷ２０７へ通知する（ステップＳ１００２）。ＰＤＮ ＧＷ２０７は、ＵＥ２００のＰＤＮコネクションを削除し、削除セッション確認メッセージ（Delete session acknowledgement message）によってＳＧＷ２０９へ応答する（ステップＳ１００３）。なお、図９に従うと、ＰＤＮ ＧＷ２０７は既にＵＥ２００のＰＳセッションのバッファリングを開始している。ＳＧＷ２０９は、ＵＥ２００のＰＤＮコネクションが切断されたことをＳＧＳＮ２１６へ通知する（ステップＳ１００４）。

また、ＵＥ２００は、ＳＧＳＮ２１６からのデタッチリクエストメッセージを処理する際に、デタッチリクエストメッセージ内のリアタッチのコーズ値の存在に気付き、ＰＤＮ ＧＷ２０７におけるベアラコンテキスト情報を削除する。なお、ＵＥ２００は、ステップＳ９０８においてハンドオーバコマンドを取得する際に、ＰＤＮ ＧＷ２０７とのＰＤＮコネクションがＵＴＲＡＮ２０２へハンドオーバされるかどうかを把握する。ハンドオーバコマンドにＰＤＮコネクションの識別子が含まれている場合には、ＰＤＮコネクションがターゲットアクセスネットワークへハンドオーバされることを意味する。一方、ハンドオーバコマンドにＰＤＮコネクションの識別子が含まれていない場合には、ＰＤＮコネクションがターゲットアクセスネットワークへハンドオーバされないことを意味する。

また、ＵＥ２００は、ステップＳ８０６においてＰＤＮ ＧＷ２０７から提供された条件のセットに基づいて、ＰＤＮ ＧＷ２０７へのＰＤＮコネクションを削除する処理を行う。このとき、ＵＥ２００は、削除リクエストメッセージ（Detach request message）をＳＧＳＮ２１６へ送信し、ＰＤＮ ＧＷ２０７への接続を削除する（ステップＳ１００５）。ＳＧＳＮ２１６は、コネクションリリースメッセージ（Connection release message）を用いて、ＵＥ２００に関する無線接続をリリースするようＢＳＳ２１５へ依頼する（ステップＳ１００６）。ＵＥ２００及びＢＳＳ２１５は、接続リリース手順を行って、ＵＥ２００のＰＳトラフィックに関する無線ベアラをリリースする（ステップＳ１００７）。

ＵＥ２００は、ＣＳケーパブルドメインへのＣＳＦＢを実行しているとき、内部でタイマを開始し、ＵＥ２００がＣＳケーパブルドメインにどのくらいの期間滞在しているかを把握する。図１１は、本発明の第２の実施の形態において、ＣＳＦＢのトリガに対してＵＥが実行する処理の一例を示すフローチャートである。この第２の実施の形態では、ＵＥ２００がＣＳＦＢによるハンドオーバコマンドをｅＮＢ２０３から取得すると、その機能が開始される（ステップＳ１１００）。機能は、ＰＤＮ ＧＷ２０７によって提供されたＵＥ２００のＰＤＮコネクションに関する条件のセットをＵＥ２００のデータベースから取り出す処理を行う（ステップＳ１１０２）そして、機能は、取り出された条件のセットを用いて、ＵＥ２００のＰＤＮコネクションに対して、どのような条件がＰＤＮ ＧＷ２０７によって設定されたのかを判断する（ステップＳ１１０４）。

ＰＤＮ ＧＷ２０７がＵＥ２００のＰＳセッションのバッファリングを実行しないと判断される場合には、機能は終了となり（ステップＳ１１０６）、ＵＥ２００は、ネットワークによって選択されたＣＳケーパブルドメインへのハンドオーバ処理を行う。一方、ＰＤＮ ＧＷ２０７がＵＥ２００のＰＳセッションのバッファリングを実行すると判断される場合には、機能は、ＵＥ２００の状態を、ＰＤＮ ＧＷ２０７から提供された条件のセットをＣＳコールの完了後にＵＥ２００にチェックさせる状態とする（ステップＳ１１０８）。この場合には、ＵＥ２００は、内部でタイマを開始し、ＵＥ２００においてＣＳコールがどのくらいの期間行われたかを把握する。なお、機能は、ＰＤＮ ＧＷ２０７がＵＥ２００のＰＳセッションのバッファリングを実行している場合には、選択されたＣＳケーパブルドメインへのハンドオーバが完了した後、ＰＤＮ ＧＷ２０７によるＰＳセッションの維持が不要な場合は、該当するＰＳセッションをネットワークから削除するようＵＥ２００へ指示を行ってもよい。そして、機能は終了となり（ステップＳ１１０６）、ＵＥ２００はネットワークによって選択されたＣＳケーパブルドメインへのハンドオーバ処理を行う。

ＵＥ２００は、ＣＳコールの終了後、ＰＤＮ ＧＷ２０７から提供された条件のセットがまだ有効かどうかをタイマの値を用いてチェックする。図１２は、本発明の第２の実施の形態において、ＣＳコールの終了後にＵＥによって行われる処理の一例を示すフローチャートである。ＵＥ２００がＣＳコールを終了し、ＰＤＮ ＧＷ２０７によって提供された条件のセットをＣＳコールの完了後にチェックする状態となると、その機能は開始される（ステップＳ１２００）。そして、機能は、ＰＤＮ ＧＷ２０７によって提供された条件のセットがＣＳコール後もまだ有効かどうかを判断する（ステップＳ１２０２）。ＰＤＮ ＧＷ２０７によって提供された条件のセットが最早無効であると判断される場合には、機能は終了となる（ステップＳ１２０４）。なお、この時点で、ＵＥ２００のグラフィックユーザインタフェース（ＧＵＩ）か、ＵＥ２００が最早ＰＳサービスを持っておらず、次のステップに関してユーザからの入力待ちであることをユーザに対して表示してもよい。

また、ＰＤＮ ＧＷ２０７によって提供された条件のセットがまだ有効であると判断される場合には、機能は、ＵＥ２００のアクセスストラタム（ＡＳ）レイヤに対して、ＵＥ２００がＰＳサービスを受けていた以前のセルへ戻る選択を行うよう指示する（ステップＳ１２０６）。なお、条件のセットがまだ有効かどうかを判断する方法としては、例えば、ＰＤＮ ＧＷ２０７のバッファリングの期間が、ＵＥ２００によって開始されたＣＳコールがどのくらいの期間だったかを示すタイマより短いことを確認すればよいが、これに限定されるものではない。なお、ＵＥ２００がＰＳサービスを受けていた以前のセルに戻る方法は、ＵＥ２００のアプリケーションレイヤがＵＥ２００のＡＳレイヤへコマンドを発行し、ＵＥ２００が以前存在していたＥ−ＵＴＲＡＮ２０１のセル識別子を最優先とする優先付けを行うことで実現可能となるが、これに限定されるものではない。機能は、ＵＥ２００がＰＳサービスに関して存在していた以前のセルへ戻ることを選択するようＡＳレイヤへ指示すると、終了となる（ステップＳ１２０４）。

ＵＥ２００は、ＵＥ２００がＰＳサービスに関連して存在していた以前のセルへ戻る選択を行ってｅＮＢ２０３へ接続すると、ＰＤＮコネクションの再開を望んでいるためＵＥ２００がｅＮＢ２０３へ戻ったことを通知する。図１３は、本発明の第２の実施の形態において、ＵＥがＰＤＮコネクションを再開することをＬＧＷへ通知する方法の一例を示すメッセージシーケンスチャートである。

ＵＥ２００は、ｅＮＢ２０３へ接続した後、アタッチリクエストメッセージ（Attach request message）をＭＭＥ２０４へ送信する（ステップＳ１３００）。さらに、ＵＥ２００は、ＰＤＮコネクションリクエストメッセージ（PDN connection request message）もＭＭＥ２０４へ送信し、ＵＥ２００がＰＤＮコネクションを望んでいることを通知する。また、ＰＤＮコネクションリクエストメッセージに、ＰＤＮ ＧＷ２０７がＵＥ２００のためにバッファリングしていた以前のＰＤＮコネクションの再開を望んでいることを、ＵＥ２００からＰＤＮ ＧＷ２０７へ通知できるインディケータを挿入してもよい。この第２の実施の形態において、ＵＥ２００からＰＤＮ ＧＷ２０７への通知方法としては、例えば、ＵＥ２００が使用していたＰＤＮコネクションのＩＰアドレスを含むＰＣＯ内の新たな情報要素を用いることができるが、これに限定されるものではない。

ＭＭＥ２０４は、ＵＥ２００がこのＰＤＮコネクションを行えるよう許可されていることを確認した後、クリエイトセッションメッセージ（create session message）を送信することによって、ＵＥ２００がＰＤＮコネクションを行おうとしていることをＳＧＷ２０９へ伝送する（ステップＳ１３０１）。ＵＥ２００が使用していたＰＤＮコネクションのＩＰアドレスを含むＰＣＯは、ＰＤＮコネクションリクエストメッセージからクリエイトセッションメッセージへコピーされる。ＳＧＷ２０９は、クリエイトセッションメッセージをＰＤＮ ＧＷ２０７へ転送する（ステップＳ１３０２）。ＰＤＮ ＧＷ２０７は、ＵＥ２００が以前のＰＤＮコネクションの再開を望んでいることを把握し、ＵＥ２００が以前使用していた同一ＩＰアドレスを再度割り当てる。ＰＤＮ ＧＷ２０７は、ＰＤＮコネクションを確立するためにクリエイトセッション確認メッセージ（create session acknowledgement message）をＳＧＷ２０９へ送り返す（ステップＳ１３０３）。ＳＧＷ２０９は、クリエイトセッション確認メッセージをＭＭＥ２０４へ転送する（ステップＳ１３０４）。

ＭＭＥ２０４は、アタッチアクセプトメッセージ（attach accept message）を送信することによって、ＥＰＣ２０６へのアタッチに成功したことをＵＥ２００へ通知する（ステップＳ１３０５）。さらに、ＭＭＥ２０４は、ベアラセットアップメッセージ（bearer setup message）を用いて、ＵＥ２００のＰＤＮセッションを可能とするために必要な無線ベアラを作成するようｅＮＢ２０３へ通知する（ステップＳ１３０６）。なお、ＭＭＥ２０４は、ステップＳ１３０６のベアラセットアップメッセージにＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）を加えてもよい。すなわち、ステップＳ１３０５のベアラセットアップメッセージと、ステップＳ１３０６のＰＤＮコネクションアクセプトメッセージを１つにまとめてもよい。ｅＮＢ２０３は、ＰＤＮコネクションアクセプトメッセージをＵＥ２００へ転送する（ステップＳ１３０７）。ＵＥ２００は、ＰＤＮ ＧＷ２０７によって割り当てられたＩＰアドレスが以前のＰＤＮコネクションで使用されていたＩＰアドレスと同一であることが分かる。ＵＥ２００及びｅＮＢ２０３は、ＰＤＮコネクション用のＵＥ２００の無線チャンネルの再構成処理を行い（ステップＳ１３０８）、無線チャンネルが再構成されると、ＵＥ２００は、ＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）をＭＭＥ２０４へ送信することで、ＰＤＮコネクションの確立完了をシグナリングする（ステップＳ１３０９）。この時点以降、ＵＥ２００は、ＰＤＮコネクションを用いて、メディアサーバ２０８と通信を行い、ビデオファイルのストリーミングを継続して取得することが可能となる。なお、図１３には不図示だが、ＰＤＮ ＧＷ２０７は、バッファリングされたＰＳセッションのパケットをＵＥ２００へ転送する。

以下、この第２の実施の形態の一例について明確に説明する。ここでは、セルラオペレータが、ＥＰＣのリソースの最適化を行うために、すべてのＵＥ２００のＳＩＰＴＯを常に実行しようとするという単純なポリシーを持っていることを前提とする。また、ＵＥ２００は、現在、ＰＤＮ ＧＷ２０７経由でＥＰＣ２０６に接続されており、メディアサーバ２０８からビデオファイルをストリーミングしているとする。メディアサーバ２０８からビデオファイルをストリーミングしている間、ＵＥ２００は、ユーザへの待機中ＣＳコールが存在しているという通知をネットワークから受信する。ユーザはこのＣＳコールを受け入れ、ＵＥ２００は、ネットワークによって選択されたＣＳケーパブルドメインへハンドオーバするようネットワークから指示を受ける。

ＰＤＮ ＧＷ２０７は、ＵＥ２００がＣＳコールによってハンドオーバされることを把握すると、ＵＥ２００へのＰＳセッションのパケットのバッファリングを開始する。ＵＥ２００は、ハンドオーバ処理の間、ＰＤＮ ＧＷ２０７から提供される条件のセットに気付き、ＰＤＮ ＧＷ２０７がＵＥ２００へのＰＳセッションのパケットをバッファリングしていることを知っているので、ＣＳコール後に、条件のセットをチェックする状態とする。さらに、ＵＥ２００は内部でタイマを開始し、ＵＥ２００が接続されていた以前のセルからどのくらいの期間離れているかを判断する。さらに、ＵＥ２００は、ＰＤＮ ＧＷ２０７からの指示に従って、ＰＳセッションがハンドオーバされる場合にはＰＳセッションを終了するようＳＧＳＮ２１６へ通知する。そして、ＣＳコールの完了時、ＵＥ２００は、ＰＤＮ ＧＷ２０７によって提供された条件のセットがまだ有効であるかどうかを検証する。条件のセットが有効であるならば、ＵＥ２００は、ＰＳサービスに関連してＵＥ２００が存在していた以前のセルへ戻るよう選択し、ＰＤＮ ＧＷ２０７とのＰＤＮコネクションを再開する。ＵＥ２００は、ＰＳサービスに関して存在していた以前のセルに戻ると、ＰＤＮコネクションを再開するためにＵＥ２００が戻ったことをＰＤＮ ＧＷ２０７へ通知する。ＰＤＮ ＧＷ２０７は、ＵＥ２００が以前使用していた同一ＩＰアドレスを再度割り当てて、バッファリングされていたＰＳセッションのパケットをＵＥ２００へ転送する。

この第２の実施の形態では、ＵＥ２００がＣＳコールに関連して（すなわち、ＣＳコールを行うか、あるいは、受けるために）別のアクセスネットワークにハンドオーバされた後であっても、あるアクセスネットワークにおけるＵＥ２００の進行中のＰＳセッションに関する継続を認めることによって、本発明の目的が実現される。これは、ユーザが、ＣＳコールを完了した後に、ＣＳコールの前に行っていたＰＳセッション（例えば、メディアサーバからのファイルのダウンロード）を再開できることを意味する。ＵＥ２００は、ネットワークによって提供された条件に基づいて、ＰＳセッションを再開できるかどうかを判断する。そして、ＰＳセッションが再開できると判断した場合には、ＵＥ２００は、元のアクセスネットワーク（元のセル）へ戻ってＰＳセッションを再開する。また、第２の実施の形態では、ＵＥ２００がＣＳコールを受けるＣＳケーパブルドメインへ、ＰＳセッションのハンドオーバを行うようにすることも可能である。

なお、上述の実施の形態（第２の実施の形態）では、図９のステップＳ９０３〜Ｓ９０５において、ｅＮＢ２０３からＰＤＮ ＧＷ２０７に対して、ＵＥ２００がＣＳＦＢによって別のアクセスネットワークへハンドオーバされたことが通知される。しかしながら、ｅＮＢ２０３が、ＰＤＮ ＧＷ２０７に対してこの通知を送信しないようにすることも可能である。その代わり、ＰＤＮ ＧＷ２０７は、ＵＥ２００がハンドオーバを行ったという通知をｅＮＢ２０３から受けた際に、ＵＥ２００のＰＳセッションのバッファリングを開始する。例えば、ＵＥ２００のＰＳセッションがターゲットアクセスネットワークへハンドオーバできる場合には、ＰＤＮ ＧＷ２０７が受ける通知（バッファリングを開始するトリガとなる通知）として変更ベアラリクエストが利用可能であるが、これに限定されるものではない。また、例えば、ＵＥ２００のＰＳセッションがターゲットアクセスネットワークへハンドオーバできない場合には、ＰＤＮ ＧＷ２０７が受ける通知（バッファリングを開始するトリガとなる通知）として削除セッションリクエストが利用可能であるが、これに限定されるものではない。このように、ｅＮＢ２０３がＰＤＮ ＧＷ２０７に対して通知を行わないようにした場合には、ｅＮＢ２０３とＰＤＮ ＧＷ２０７との間で相互作用が必要ではないという利点がある。これは、ＰＤＮ ＧＷ２０７が、ＣＳＦＢによるハンドオーバとＵＥ２００のモビリティによるハンドオーバとを区別する必要がないことを意味する。

また、上述の実施の形態（第２の実施の形態）では、ｅＮＢ２０３とＰＤＮ ＧＷ２０７とが異なるデバイスに実装されていることを想定している。したがって、ＵＥ２００がＣＳＦＢによってハンドオーバされたことを通知するためには、ｅＮＢ２０３とＰＤＮ ＧＷ２０７との間で標準化されたメッセージ交換が必要となる。このメッセージ交換は、例えば、ｅＮＢ２０３がＳ１ＡＰメッセージ（例えば、ハンドオーバリクエストメッセージ）をＭＭＥ２０４へ送信して、ＵＥ２００がＣＳＦＢによってハンドオーバされたことを通知することによって実現可能である。この場合、ＭＭＥ２０４は、例えば削除セッションリクエストメッセージを用いて、この通知をＳＧＷ２０９及びＰＤＮ ＧＷ２０７へ転送する。しかしながら、ｅＮＢ２０３、ＳＧＷ２０９、ＰＤＮ ＧＷ２０７が単一のデバイスに実装されていてもよい。この場合には、ＵＥ１００がＣＳＦＢによってハンドオーバされたことを、ｅＮＢ２０３からＳＧＷ２０９及びＰＤＮ ＧＷ２０７へ通知するために、同一デバイス内における実装独自（implementation specific）の内部トリガが使用可能である。単一のデバイスにすべての機能を実装させる場合には、機能間のメッセージがデバイス間接続を介して交換される必要がある場合に生じる送信遅延を低減できるという利点がある。

＜ホームフェムトセルにおいてＳＩＰＴＯが実行される第１派生例＞
また、上述の第２の実施の形態では、ＳＩＰＴＯによるＵＥ２００のＰＳセッションのオフロードが、セルラオペレータのコアネットワークエンティティで起こることについても説明したが、第１の実施の形態（図１の構成）において、ＵＥ１００がＬＧＷ１１６を有するフェムトセルへ移動した場合においても、ＳＩＰＴＯによるＵＥ１００のＰＳセッションのオフロードが起こる可能性がある。例えば、ＵＥ１００が家庭内又は企業ネットワーク１０３に移動した場合、ＭＭＥ１０５は、ＵＥ１００のために地理的により近いゲートウェイ（ＬＧＷ１１６）を検出してＳＩＰＴＯをトリガするよう決定する。

図１４は、本発明の第１の実施の形態において、ＵＥに関するＳＩＰＴＯ ＰＳセッションを維持する条件をＵＥへ通知する方法の一例を説明するメッセージシーケンスチャートである。この第１の実施の形態において、ＵＥ１００はＥＰＣ１０７へのＰＤＮコネクションを１つだけ有しており、ＰＤＮコネクションがＰＤＮ ＧＷ１０８によって管理されているとする。この場合、ＭＭＥ１０５は、デタッチリクエストメッセージ（Detach Request message）をＵＥ１００へ送信する（ステップＳ１４００）。ＭＭＥ１０５は、デタッチリクエストメッセージにリアタッチ（再アタッチ）のコーズ値を挿入して、デタッチ手順の完了後にアタッチ手順を実行するようＵＥ１００へ通知する。また、ＭＭＥ１０５は、削除セッションメッセージ（delete session message）をＳＧＷ１０９へ送信し、ＵＥ１００のＰＤＮ ＧＷ１０８へのＰＤＮコネクションを削除する（ステップＳ１４０１）。ＳＧＷ１０９は、ＵＥ１００のＰＤＮコネクションが切断されることをＰＤＮ ＧＷ１０８へ通知する（ステップＳ１４０２）。ＰＤＮ ＧＷ１０８は、ＵＥ１００のコンテキストを削除し、削除セッション確認メッセージ（delete session acknowledgement message）によってＳＧＷ１０９へ応答する（ステップＳ１４０３）。ＳＧＷ１０９は、ＵＥ１００のＰＤＮコネクションが切断されたことをＭＭＥ１０５へ通知する（ステップＳ１４０４）。

また、ＵＥ１００は、ＭＭＥ１０５からのデタッチリクエストメッセージを処理する際に、リアタッチのコーズ値の存在に気付き、ＰＤＮ ＧＷ１０８におけるベアラコンテキスト情報を削除する。また、ＵＥ１００は、デタッチアクセプトメッセージ（detach accept message）をＭＭＥ１０５へ送信する（ステップＳ１４０５）。ＭＭＥ１０５は、Ｓ１ＡＰコネクションリリースメッセージ（S1AP connection release message）を用いて、ＵＥ１００のＲＲＣ接続をリリースするようＨｅＮＢ１０４へ依頼する（ステップＳ１４０６）。ＵＥ１００及びＨｅＮＢ１０４は、ＵＥ１００の無線ベアラをすべて削除するためにＲＲＣ接続リリース手順を行う（ステップＳ１４０７）。そして、ＲＲＣ接続リリース手順の後、デタッチ手順は完了となる。

このデタッチ手順が完了すると、ＵＥ１００は、ＭＭＥ１０５の指示に従って、ＥＰＣ１０７へのアタッチ手順を実行する。ＵＥ１００及びＨｅＮＢ１０４は、ＵＥ１００のＲＲＣ接続を確立するためのやり取りを行う（ステップＳ１４０８）。ＲＲＣ接続がセットアップされると、ＵＥ１００は、アタッチリクエストメッセージ（Attach request message）をＭＭＥ１０５へ送信する（ステップＳ１４０９）。さらに、ＵＥ１００は、ＰＤＮコネクションリクエストメッセージ（PDN connection request message）もＭＭＥ１０５へ送信し、ＵＥ１００がＥＰＣ１０７へのＰＤＮコネクションを望んでいることを通知する。ＭＭＥ１０５は、ＵＥ１００の識別子及び加入者情報を確認し、ＵＥ１００に適切なゲートウェイを選択する処理を行う。ＭＭＥ１０５は、ＬＧＷ１１６が地理的にＵＥ１００に近いことに気付き、ＵＥ１００に対してＬＧＷ１１６を選択する。そして、ＭＭＥ１０５は、クリエイトセッションメッセージ（create session message）をＬＧＷ１１６へ送信する処理を行う（ステップＳ１４１０）。ＬＧＷ１１６は、ＵＥ１００のリクエストを受け入れて、クリエイトセッション確認メッセージ（create session acknowledgement message）をＭＭＥ１０５へ送り返すことによって、ＰＤＮコネクションを作成する（ステップＳ１４１１）。なお、本発明では、ＬＧＷ１１６は、さらに、ＵＥ１００への応答に条件のセットを挿入する。ここでは、条件のセットには、ＵＥ１００がＣＳＦＢを実行している場合には、ＬＧＷ１１６がＰＤＮコネクションのハンドオーバを実行し、さらに、所定の時間だけＵＥ１００のデータパケットのバッファリングを開始するという条件を含まれているが、これに限定されるものではない。また、条件のセットが、クリエイトセッション確認メッセージで運ばれるＰＣＯ内の新たな情報要素によって伝送されてもよいが、これに限定されるものではない。

ＭＭＥ１０５は、アタッチアクセプトメッセージ（Attach accept message）を送信することによって、ＥＰＣ１０７へのアタッチに成功したことをＵＥ１００へ通知する（ステップＳ１４１２）。さらに、ＭＭＥ１０５は、ベアラセットアップメッセージ（bearer setup message）を用いて、ＵＥ１００のＰＳセッションを可能とするために必要な無線ベアラを作成するようＨｅＮＢ１０４へ通知する。なお、ＭＭＥ１０５は、ステップＳ１４１３のベアラセットアップメッセージにＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）を加えてもよい。なお、ＭＭＥ１０５は、クリエイトセッション確認メッセージ内のＰＣＯをＰＤＮコネクションアクセプトメッセージへコピーする。そして、ＨｅＮＢ１０４は、ＰＤＮコネクションアクセプトメッセージをＵＥ１００へ転送する（ステップＳ１４１４）。ＵＥ１００は、ＬＧＷ１１６によって提供された条件のセットをＵＥ１００内のデータベースへ格納する（ステップＳ１４１５）。ＵＥ１００及びＨｅＮＢ１０４は、ＰＤＮコネクション用のＵＥ１００の無線チャンネルの再構成処理を行い（ステップＳ１４１６）、無線チャンネルが再構成されると、ＵＥ１００は、ＰＤＮコネクションアクセプトメッセージ（PDN connection accept message）をＭＭＥ１０５へ送信することで、ＰＤＮコネクションの確立完了をシグナリングする（ステップＳ１４１７）。この時点以降、ＥＰＣ１０７からのＵＥ１００のトラフィックを移動することによって、ＵＥ１００に関するＳＩＰＴＯが有効となる。ＵＥ１００は、ＬＧＷ１１６とのＰＤＮコネクションを使用して、インターネット１１３上のエンティティと通信を行う。

また、図１５は、本発明の第１の実施の形態において、ＵＥがＣＳＦＢに関連して別のアクセスネットワークへハンドオーバされる場合の一例を示すメッセージシーケンスチャートである。ＭＭＥ１０５は、ＵＥ１００への待機中ＣＳコールが存在しているという通知をＭＳＣ１２８から受信すると、ＣＳＦＢ手順をトリガして、ＵＥ１００をＣＳケーパビリティドメインへハンドオーバさせる（ステップＳ１５００）。なお、このステップＳ１５００は、図４のステップＳ４００からＳ４０７と同一であり、ここでは詳細な説明は省略する。また、ＵＴＲＡＮ１０２もＰＳサービスをサポートしているので、ステップＳ４００からステップＳ４０７までの処理の間に、ＭＭＥ１０５は、ＵＥ１００のＰＳセッションをＳＧＳＮ１２４へハンドオーバさせる。したがって、ＵＥ１００は、ＵＴＲＡＮ１０２においてＰＳセッションを継続することが可能となる。

しかしながら、この場合にはデータシグナリングパスは最適化されない。ここで、ＤＳＬプロバイダとＥＰＣとが同一セルラオペレータに属していると仮定すると、ＵＴＲＡＮ１０２へハンドオーバした際のＵＥ１００のデータパスに関連して、ＳＧＷ１０９とＬＧＷ１１６との間に論理的なリンクが存在する。この論理的なリンク１２０は、物理的なリンク：ＳＧＷ１０９→リンク１１１→リンク１１４→リンク１２２→リンク１２１→ＬＧＷ１１６を通る。例えば、ＵＥ１００がＵＴＲＡＮ１０２に存在する際にインターネット１１３へデータパケットを送信している場合には、パケットは、リンク１２６→リンク１２７→リンク１１１→リンク１１４→リンク１２２→リンク１２１→リンク１２１→リンク１２２を通過する。この最適化されていないデータパスは、セルラオペレータのＥＰＣリソース消費量を増大させる可能性がある。

このように最適化されていないパスの使用を防ぐ解決方法は、ＵＥ１００がＥＰＣ１０７からのＰＳセッションを削除することである。ＵＥ１００は、ＵＴＲＡＮ１０２へのハンドオーバに成功すると、ＰＳサービスに関してデタッチリクエストメッセージ（Detach Request message）をＳＧＳＮ１２４へ送信する（ステップＳ１５０１）。ＵＥ１００がＰＳサービスをデタッチする理由は、ＬＧＷ１１６によって提供された条件のセットから、ＵＥ１００のデータパケットがＬＧＷ１１６にバッファリングされていることをＵＥ１００が把握しているからである。この実施の形態では、ＥＰＣ１０７内のエンティティ（すなわち、ＭＭＥ１０５及びＳＧＳＮ１２４）が、本発明に対してレガシのエンティティであることを前提としている。したがって、本発明をサポートするために、ＭＭＥ１０５及びＳＧＳＮ１２４の機能を拡張することは考慮していない。したがって、レガシの特徴をサポートした場合には、ＳＩＰＴＯのＰＤＮコネクションは、ＭＭＥ１０５からＳＧＳＮ１２４へハンドオーバされる。ＰＳサービスに関するデタッチリクエストをＵＥ１００からＳＧＳＮ１２４へ送信させることによって、ＵＥ１００がＣＳコール後にＳＩＰＴＯに関するＰＤＮコネクションを再開しようとする場合に、ＵＥ１００とネットワークとの間における状態の誤同期が避けられる。

ＳＧＳＮ１２４は、ＵＥ１００からのデタッチリクエストメッセージを受信すると、ＵＥ１００のＰＳサービスのコンテキストを削除する（ステップＳ１５０２）。ＵＥ１００がＣＳケーパブルドメインへのＣＳＦＢを実行している場合、ＵＥ１００は内部でタイマを開始し、ＵＥ１００がどのくらいの期間だけＣＳケーパブルドメインに滞在しているかを把握する。なお、ＵＥ１００がＰＳセッションを再開するために、家庭内又は企業ネットワーク１０３へ戻るよう選択すべきかどうかを判断するための後続のステップは、図１１及び図１２に示す手順に従う。したがって、ここでは詳細については省略する。

この場合も、ＵＥ１００がＣＳコールに関連して（すなわち、ＣＳコールを行うか、あるいは、受けるために）別のアクセスネットワークへハンドオーバした後であっても、あるアクセスネットワークにおけるＵＥ１００の進行中ＰＳセッションを継続させることによって、本発明の目的が実現される。これは、ユーザがＣＳコールを完了した後に、ＣＳコールの前に行っていたＰＳセッション（例えば、ホームサーバからのメディアファイルのダウンロード）を再開できることを意味する。ＵＥ１００は、ネットワークによって提供された条件に基づいて、ＰＳセッションを再開できるかどうかを判断する。

＜複数のＰＤＮコネクションが存在する第２派生例＞
また、上述の第１及び第２の実施の形態では、ＵＥがＥＰＣへのＰＤＮコネクションを１つだけ有しており、ＰＤＮコネクションがそのＰＤＮ ＧＷによって管理されていることを前提としている。しかしながら、ＵＥは、異なるＰＤＮ ＧＷに管理されている複数のＰＤＮコネクションを持つことも可能である。

例えば図２のネットワーク構成において、ＵＥ２００は、あるＰＤＮ ＧＷ２０７とＰＤＮコネクションを有してインターネット２１３へアクセスしており、さらに、別のＰＤＮ ＧＷとＰＤＮコネクションを有してユーザの企業ネットワークへアクセスしているとする。異なるＰＤＮ ＧＷへの複数のＰＤＮコネクションが存在する状態において、ＳＧＳＮ２１６は、デタッチ手順を用いる代わりに、ＰＤＮ ＧＷ２０７からＧＧＳＮ２２０へのオフロードをトリガした場合には、デアクティベートベアラメッセージを用いてＵＥ２００を別のＰＤＮ ＧＷへオフロードする。デアクティベートベアラメッセージには、ベアラの再アクティベートをＵＥ２００に指示するためのコーズ値が存在する。アクティベーション手順が実行されると、ＳＧＳＮ２１６は、ＧＧＳＮ２２０を選択してＵＥ２００をオフロードする。

また、例えば図１のネットワーク構成において、ＵＥ１００はあるＰＤＮ ＧＷ１０８とＰＤＮコネクションを有してインターネット１１３へアクセスしており、さらに、別のＰＤＮ ＧＷとＰＤＮコネクションを有してユーザの企業ネットワークへアクセスしているとする。このように、異なるＰＤＮ ＧＷへの複数のＰＤＮコネクションが存在する状態において、ＭＭＥ１０５は、デタッチ手順を用いる代わりに、ＰＤＮ ＧＷ１０８からＬＧＷ１１６へのオフロードをトリガした場合には、デアクティベートベアラメッセージを用いてＵＥ１００を別のＰＤＮ ＧＷへオフロードする。デアクティベートベアラメッセージには、ベアラの再アクティベートをＵＥ１００に指示するためのコーズ値が存在する。アクティベーション手順が実行されると、ＭＭＥ１０５は、ＬＧＷ１１６を選択してＵＥ１００をオフロードする。

＜ＣＳコールを受けた後のＵＥへ条件のセットを提供する第３派生例＞
また、上述の第１及び第２の実施の形態において、ＵＥがＣＳコールを受けた後に、条件のセットがＵＥへ提供されるようにすることも可能である。例えば、上述の第１の実施の形態では、ＵＥ１００のＰＳセッションを維持する条件のセットが、ＵＥ１００がＬＧＷ１１６へのＰＤＮコネクションを確立する際にＬＧＷ１１６から送信されると仮定している。しかしながら、ＵＥ１００がＵＴＲＡＮ１０２へハンドオーバされてＣＳコールを受けた後に、ＬＧＷ１１６が条件のセットをＵＥ１００へ送信することも可能である。例えば、ＬＧＷ１１６は、タイムスタンプ付の条件のセットをＭＭＥ１０５へ渡す。この条件のセットには、例えば、ＬＧＷ１１６がＵＥ１００のパケットをバッファリングする期間が含まれるようにすることが可能であるが、これに限定されるものではない。ここで、ターゲットＲＡＴ（すなわち、ＵＴＲＡＮ１０２）がＰＳサービスをサポートしていないと仮定する。ＭＭＥ１０５は、ＵＥ１００がＵＴＲＡＮ１０２に存在していることを把握すると、条件のセット及びタイムスタンプをＳＧＳＮ１２４へ渡し、ＳＧＳＮ１２４からＵＥ１００へ通知メッセージが送信される。この通知メッセージには、ＬＧＷ１１６から受信した条件のセット及びタイムスタンプをＵＥ１００へ伝送するための新たな情報要素が存在する。ＵＥ１００は、ＣＳコールを完了すると、条件のセットがまだ有効かどうかをチェックする。例えば、条件のセットに、ＬＧＷ１１６がＵＥ１００のＳＩＰＴＯコネクションのパケットをバッファリングする期間が含まれている場合には、ＵＥ１００の現在時刻とＬＧＷ１１６から送信されたタイムスタンプとを比較することによって、ＵＥ１００は、これらの時間差を計算することができる。ＵＥ１００は、この時間差と条件のセットに記載されている期間とを比較する。この時間差が条件のセットに記載されている期間より短い場合には、ＵＥ１００は、家庭内又は企業ネットワーク１０３に戻るよう選択し、ＬＧＷ１１６とのＰＤＮコネクションを再開して、バッファリングされているパケットを取得する。

また、更なる派生例として、ターゲットＲＡＴ（すなわち、ＵＴＲＡＮ１０２）がＰＳサービスをサポートしていない場合には、ＭＭＥ１０５は、条件のセット及びタイムスタンプをＭＳＣ１２８へ渡し、ＭＳＣ１２８からＵＥ１００へ通知メッセージが送信されるようにすることが可能である。この通知メッセージには、ＬＧＷ１１６から受信した条件のセット及びタイムスタンプをＵＥ１００へ伝送するための新たな情報要素が存在する。ＵＥ１００は、ＣＳコールを完了すると、条件のセットがまだ有効かどうかをチェックする。例えば、条件のセットに、ＬＧＷ１１６がＵＥ１００のＳＩＰＴＯコネクションのパケットをバッファリングする期間が含まれている場合には、ＵＥ１００の現在時刻とＬＧＷ１１６から送信されたタイムスタンプとを比較することによって、ＵＥ１００は、これらの時間差を計算することができる。ＵＥ１００は、この時間差と条件のセットに記載されている期間とを比較する。この時間差が条件のセットに記載されている期間より短い場合には、ＵＥ１００は、家庭内又は企業ネットワーク１０３へ戻るよう選択し、ＬＧＷ１１６とのＰＤＮコネクションを再開して、バッファリングされているパケットを取得する。

このように、ＵＥ１００がＣＳコールに関連して（すなわち、ＣＳコールを行うか、あるいは、受けるために）別のアクセスネットワークへハンドオーバされた後であっても、あるアクセスネットワークにおけるＵＥの進行中のＰＳセッションに関する継続を認めることによって、本発明の目的が実現される。これは、ユーザがＣＳコールを完了した後に、ＣＳコールの前に行っていたＰＳセッション（例えば、サーバからのファイルのダウンロード）を再開できることを意味する。ＵＥは、ネットワークによって提供された条件に基づいて、ＰＳセッションを再開できるかどうかを判断する。また、さらに、現在ＣＳＦＢで用いられているシグナリングを拡張するだけで、ＵＥのＰＳセッションの維持をサポートできるという利点も有している。

＜ハンドオーバコマンドを用いて条件のセットが送信される第４派生例＞
上述の第１及び第２の実施の形態では、ＵＥがＰＤＮコネクションを確立する際に、ＵＥのＰＳセッションを維持する条件のセットが、ＰＤＮ ＧＷ又はＬＧＷから送信されると仮定している。しかしながら、ＵＥがＣＳケーパブルドメインへのハンドオーバを行っている最中に、ＰＤＮ ＧＷ又はＬＧＷが条件のセットをＵＥへ送信することも可能である。例えば、ハンドオーバコマンドメッセージが送信される際に、ＵＥへ送信すべき条件のセットがｅＮＢ又はＨｅＮＢへ渡される。なお、条件のセットをｅＮＢ又はＨｅＮＢへ渡す方法として、例えば、実装独自のメッセージを使用することが挙げられる。また、ＰＤＮ ＧＷ又はＬＧＷは、例えばクリエイトセッション確認メッセージを用いて、条件のセットをＳＧＷ経由でＭＭＥへ渡すことも可能である。ＭＭＥはＳ１ＡＰメッセージ（例えば、Ｓ１−ＡＰ ＵＥコンテキスト変更リクエスト）を用いて、条件のセットをｅＮＢ又はＨｅＮＢへ渡す。

例えば、図１のネットワーク構成において、ＬＧＷ１１６は、ＵＥ１００がＬＧＷ１１６との間でＬＩＰＡ ＰＤＮコネクションを確立する際に、ＵＥ１００のＬＩＰＡ ＰＤＮコネクションに関する条件のセットをＨｅＮＢ１０４へ通知する（ＭＭＥ１０５を通じて）。ＨｅＮＢ１０４は、ＵＥ１００がＣＳＦＢによってハンドオーバしなければならないことを把握すると、ＵＥ１００へのハンドオーバコマンドメッセージ（ステップＳ４０６において送信される）に、条件のセットを挿入する。ＵＥ１００は、ハンドオーバコマンドメッセージから条件のセットを抽出し、これを用いて、ＣＳコール後にＵＥ１００がＬＩＰＡ ＰＳセッションを再開できるかどうかを判断する。

また、例えば、図２のネットワーク構成において、ＰＤＮ ＧＷ２０７は、ＵＥ２００がＰＤＮ ＧＷ２０７とのＰＤＮコネクションを確立する際に、ＵＥ２００のＰＤＮコネクションのための条件のセットをｅＮＢ２０３へ通知する（ＳＧＷ２０９及びＭＭＥ２０４を通じて）。ｅＮＢ２０３は、ＵＥ２００がＣＳＦＢによってハンドオーバしなければならいことを把握すると、ＵＥ２００へのハンドオーバコマンドメッセージ（ステップＳ９０８において送信される）に、条件のセットを挿入する。ＵＥ２００は、ハンドオーバコマンドメッセージから条件のセットを抽出し、これを用いて、ＣＳコール後にＵＥ２００がＰＳセッションを再開できるかどうかを判断する。

このように、ＵＥがＣＳコールに関連して（すなわち、ＣＳコールを行うか、あるいは、受けるために）別のアクセスネットワークへハンドオーバされた後であっても、あるアクセスネットワークにおけるＵＥの進行中のＰＳセッションに関する継続を認めることによって、本発明の目的が実現される。これは、ユーザがＣＳコールを完了した後に、ＣＳコールの前に行っていたＰＳセッション（例えば、ホームサーバからのメディアファイルのダウンロード）を再開できることを意味する。ＵＥは、ネットワークによって提供された条件に基づいて、ＰＳセッションを再開できるかどうかを判断する。また、さらに、ＵＥがセットアップしているすべてのＰＤＮコネクションに関連した条件のセットがＵＥへ送信される必要がなくなるという利点がある。

＜ｅＮＢ／ＨｅＮＢによってバッファリングが行われる第５派生例＞
また、上述の第１及び第２の実施の形態では、ＵＥのＰＳトラフィックのバッファリングがＰＤＮ ＧＷ又はＬＧＷによって行われると仮定しており、ＰＤＮ ＧＷ又はＬＧＷがＵＥのＰＳセッションを維持するための条件のセットをＵＥへ送信している。しかしながら、ＵＥのＰＳセッションのバッファリングは、ｅＮＢ又はＨｅＮＢにおいても実行可能である。これは、ＰＤＮ ＧＷ又はＬＧＷが、本発明に対するレガシ（本発明に係る機能をサポートしていないデバイス）である場合に有効であるが、一方、ｅＮＢ又はＨｅＮＢが、ＰＳセッションを再開できるよう拡張される必要がある。これを実現するためには、例えば、ＵＥがＣＳＦＢによって別のアクセスネットワークへハンドオーバされる際に、ｅＮＢ又はＨｅＮＢがＵＥのプロキシとして動作する。ＰＤＮ ＧＷ又はＬＧＷは、ｅＮＢ又はＨｅＮＢへＵＥのＰＳトラフィックを送信し続け、ｅＮＢ又はＨｅＮＢが、所定の期間バッファリングを行う。

例えば、図１のネットワーク構成において、ＨｅＮＢ１０４は、ＵＥ１００がＬＧＷ１１６との間でＬＩＰＡ ＰＤＮコネクションを有していることを把握する。ＨｅＮＢ１０４は、ＣＳＦＢによってＵＥ１００をハンドオーバさせる際に、ＵＥ１００へのハンドオーバコマンドメッセージ（ステップＳ４０６において送信される）に条件のセットを挿入する。なお、ＨｅＮＢ１０４は、ＬＩＰＡ ＰＳコンテキストを削除するためのＳ１ＡＰリリースメッセージをＭＭＥ１０５へ送信しない。ＬＧＷ１１６は、ＬＩＰＡ ＰＳトラフィックをＨｅＮＢ１０４へ送信し続け、ＨｅＮＢ１０４は、条件のセットに示されている所定の期間だけ、ＵＥ１００のＬＩＰＡ ＰＳトラフィックのバッファリングを開始する。ＵＥ１００は、ハンドオーバコマンドメッセージから条件のセットを抽出し、これを用いて、ＣＳコール後にＵＥ１００がＬＩＰＡ ＰＳセッションを再開できるかどうかを判断する。

また同時に、ＨｅＮＢ１０４は、ＵＥ１００へのハンドオーバコマンドメッセージに付加情報を挿入して、ＣＳコールが終わった際にＵＥ１００が接続を容易に再開できるようにすることが可能である。例えば、ＵＥ１００がＣＳコール後にＥ−ＵＴＲＡＮへ接続を戻す際にＨｅＮＢ１０４がＵＥ１００を識別できるようにする特定の識別子、ＵＥ１００及びＨｅＮＢ１０４が暗号化の再確立を行えるようにするセキュリティ鍵材料、完全保護鍵、無線ベアラＩＤマッピングなどの付加情報を挿入することが可能である。ＨｅＮＢ１０４は、ＵＥ１００がＨｅＮＢ１０４から離れてＣＳセッションを実行する際に、受信パケットを無線ベアラへ送信するのではなく、その代わりにバッファリングを行うという点を除いて、ＵＥ１００がまだその通信範囲内に存在するかのように動作する。ＵＥ１００は、ＣＳコールを終了すると、ＨｅＮＢ１０４への直接接続に戻して、ハンドオーバコマンド内のＨｅＮＢ１０４から提供された情報を用いて、必要な無線ベアラの再確立を行う。そして、ＨｅＮＢ１０４は、対応する無線ベアラを通じて、バッファリングされているパケットをＵＥ１００へ転送し、ＬＩＰＡ／ＳＩＰＴＯＰＳセッションが再開される。

また、例えば、図２のネットワーク構成において、ｅＮＢ２０３が、ＵＥ２００がＰＤＮ ＧＷ２０７とのＰＤＮコネクションを有していることを把握する。ｅＮＢ２０３は、ＣＳＦＢによってＵＥ２００をハンドオーバさせる際に、ＵＥ２００へのハンドオーバコマンドメッセージ（ステップＳ０９０８において送信される）に条件のセットを挿入する。なお、ｅＮＢ２０３は、ＵＥ２００のＰＳコンテキストを削除するためのＳ１ＡＰメッセージをＭＭＥ２０４へ送信しない。ＰＤＮ ＧＷ２０７は、ＰＳトラフィックをｅＮＢ２０３へ送信し続け、ｅＮＢ２０３は、条件のセットに示されている所定の期間だけ、ＵＥ２００のＰＳトラフィックのバッファリングを開始する。ＵＥ２００は、ハンドオーバコマンドメッセージから条件のセットを抽出し、これを用いて、ＣＳコール後にＵＥ２００がＰＳセッションを再開できるかどうかを判断する。

このように、ＵＥ１００がＣＳコールに関連して（すなわち、ＣＳコールを行うか、あるいは、受けるために）別のアクセスネットワークへハンドオーバされた後であっても、あるアクセスネットワークにおけるＵＥの進行中のＰＳセッションに関する継続を認めることによって、本発明の目的が実現される。これは、ユーザがＣＳコールを完了した後に、ＣＳコールの前に行っていたＰＳセッション（例えば、ホームサーバからのメディアファイルのダウンロード）を再開できることを意味する。ＵＥは、ネットワークによって提供された条件に基づいて、ＰＳセッションを再開できるかどうかを判断する。また、さらに、ＰＤＮ ＧＷ又はＬＧＷが本発明に対してレガシであってもよいという利点がある。

＜ターゲットＲＡＴがＰＳサービスをサポートしていない第６派生例＞
上述の第１及び第２の実施の形態では、ＵＥがＣＳＦＢによってハンドオーバされる際に、ターゲットＲＡＴがＰＳサービスをサポートしていることを前提としている。しかしながら、例えば、ターゲットＲＡＴがＧＲＥＡＮの場合など、ターゲットＲＡＴがＰＳサービスをサポートしない可能性もある。このように、ターゲットＲＡＴがＰＳサービスをサポートしていない場合であっても、ＵＥのＰＳセッションを維持する本発明の解決方法は適用可能である。

ターゲットＲＡＴがＰＳサービスをサポートしていない場合、ＵＥのＰＳセッションは終端されているので、ＳＧＳＮがインターＲＡＴハンドオーバ手順に関与することはない。なお、ＨｅＮＢ又はｅＮＢは、ターゲットＲＡＴへＵＥを移すためのハンドオーバコマンドメッセージの代わりに、ＲＲＣコネクションリリースメッセージを送信する。ＲＲＣコネクションリリースメッセージには、ＵＥがどのＲＡＴに移されるのかを知らせるための通知である。同様に、ＵＥは、ハンドオーバ完了メッセージを送信せず、その代わりに、ルーティングエリア更新（ＲＡＵ）メッセージ、又は、位置エリア更新（ＬＡＵ）メッセージを送信する。

例えば、図４を参照すると、ここでは、ＳＧＳＮ１２４はステップＳ４０５におけるインターＲＡＴハンドオーバ手順に関与していない。ＨｅＮＢ１０４は、ＵＴＲＡＮ１０２がＰＳサービスをサポートできないことを知っている場合には、ＲＲＣ接続リリースメッセージをＵＥ１００へ送信する。ＲＲＣ接続リリースメッセージには、ＵＴＲＡＮ１０２を選択するようＵＥ１００へ知らせる通知が存在している。ＵＥ１００は、ＲＲＣ接続リリースメッセージの情報を用いて、ＵＴＲＡＮ１０２を選択する。同様に、ＨｅＮＢ１０４及びＵＥ１００は、ハンドオーバがＣＳＦＢによるものであることを把握すると、ＨｅＮＢ１０４及びＵＥ１００の両方共、ＵＥ１００のＬＩＰＡ ＰＳセッションのコンテキストを維持する。これによって、ＵＥ１００は、ＣＳコール後にＥ−ＵＴＲＡＮ１０１へ戻る際に、ＬＩＰＡ ＰＳセッションを再開することが可能となる。

また、例えば、図９を参照すると、ここでは、ＳＧＳＮ２１６は、ステップＳ９０７におけるインターＲＡＴハンドオーバ手順に関与していない。ｅＮＢ２０３は、ＵＴＲＡＮ２０２がＰＳサービスをサポートできないことを知っている場合には、ＲＲＣ接続リリースメッセージをＵＥ２００へ送信する。ＲＲＣ接続リリースメッセージには、ＵＴＲＡＮ２０２を選択するようＵＥ２００へ知らせる通知が存在している。ＵＥ２００は、ＲＲＣ接続リリースメッセージの情報を用いて、ＵＴＲＡＮ２０２を選択する。同様に、ｅＮＢ２０３及びＵＥ２００は、ハンドオーバがＣＳＦＢによるものであることを把握すると、ｅＮＢ２０３及びＵＥ２００の両方共、ＵＥ２００のＰＳセッションのコンテキストを維持する。これによって、ＵＥ２００は、ＣＳコール後にＥ−ＵＴＲＡＮ２０１へ戻る際に、ＰＳセッションを再開することが可能となる。

さらに、別の派生例では、図１において、ＵＥ１００がＬＧＷ１１６とＬＩＰＡ ＰＤＮコネクションを確立する際に、ＬＧＷ１１６は、ＵＥ１００のＬＩＰＡ ＰＤＮコネクションに関する条件のセットをＨｅＮＢ１０４へ通知する。ＨｅＮＢ１０４は、ＵＴＲＡＮ１０２が、ＰＳサービスをサポートしていないこと、さらに、ＵＥ１００がＣＳＦＢによってハンドオーバしなければならないことを把握すると、ＵＥ１００へ送信するＲＲＣ接続リリースメッセージに条件のセットを挿入する。ＵＥ１００は、ＲＲＣ接続リリースメッセージから条件のセットを抽出し、これを用いて、ＵＥ１００がＣＳコール後にＬＩＰＡ ＰＳセッションを再開できるかどうかを判断する。

さらにまた別の派生例では、図２を参照すると、ＵＥ２００がＰＤＮ ＧＷ２０７とＰＤＮコネクションを確立する際に、ＰＤＮ ＧＷ２０７は、ＵＥ２００のＰＤＮコネクションに関する条件のセットをｅＮＢ２０３へ通知する（ＳＧＷ２０９及びＭＭＥ２０４を通じて）。ｅＮＢ２０３は、ＵＴＲＡＮ２０２がＰＳサービスをサポートしていないことを把握し、さらに、ＵＥ２００がＣＳＦＢによってハンドオーバしなければならないことを把握すると、ＵＥ２００へ送信するＲＲＣ接続リリースメッセージに条件のセットを挿入する。ＵＥ２００は、ＲＲＣ接続リリースメッセージから条件のセットを抽出し、これを用いて、ＵＥ２００がＣＳコール後にＰＳセッションを再開できるかどうかを判断する。

＜ＣＳコール前のネットワークに戻った際に、ＳＩＰＴＯをトリガするかどうかを判断する第７派生例＞
また、上述の実施の形態において、ＵＥがＣＳコール前のネットワークに戻った際に、ＳＩＰＴＯをトリガするかどうかを動的に判断することも可能である。上述の説明では、例えば図１において、ＵＥ１００がＣＳコール後に家庭内又は企業ネットワーク１０３へ戻るよう選択されたときに、ＭＭＥ１０５がＳＩＰＴＯをトリガしてＵＥ１００に関するＬＧＷ１１６を選択し直すと仮定している。ＭＭＥ１０５がＬＧＷ１１６を選択する理由は、セルラオペレータが、すべてのＵＥに関するＳＩＰＴＯを常に実行してＥＰＣ１０７のリソースの最適化を行おうとする単純なポリシーを持っているからである。すなわち、これは、ポリシーが静的であることを意味している。しかしながら、ポリシーを動的なものとして、ＭＭＥ１０５が、ＥＰＣ１０７のリソース利用に基づいて、ＳＩＰＴＯがトリガされるべきであるかどうかを判断することも可能である。この場合、例えば、ＣＳコール後にＵＥ１００が家庭内又は企業ネットワーク１０３へ戻るよう選択する際に、ＭＭＥ１０５は、ＳＩＰＴＯを実行しないよう決定し、ＵＥ１００をＰＤＮ ＧＷ１０８へ接続させることが可能である。このとき、ＰＤＮ ＧＷ１０８は、ＵＥ１００の以前のＰＤＮコネクションのコンテキストを持っていないので、ＵＥ１００に対して、新たなＩＰアドレスを用いた新たなＰＤＮコネクションを割り当てる。ＵＥ１００は、ＬＧＷ１１６によって提供される条件のセットがまだ有効であること、さらに、ＵＥ１００が以前のＩＰアドレスを取得していないことを把握した場合には、ＳＩＰＴＯがトリガされていないと推定して、別のＰＤＮ ＧＷへ接続される。

しかしながら、ＬＧＷ１１６は、条件のセットが無効になるまでＵＥ１００のパケットのバッファリングを続けることになる。したがって、ＵＥ１００は、ＬＧＷ１１６に対して、ＵＥ１００は別のＰＤＮ ＧＷに接続されていることを通知し、ＵＥ１００に関するバッファをクリアするよう依頼することが有用である。このようなＬＧＷ１１６への通知は、ＨｅＮＢ１０４を経由して行うことが可能である。また、ＵＥ１００は、ＭＭＥ１０５へのＰＤＮコネクションリクエストの間に、ＬＧＷ１１６へ接続することが望ましいことをＭＭＥ１０５へ通知することも可能である。その結果、ＭＭＥ１０５は、可能であれば、ＵＥ１００のためにＬＧＷ１１６を選択する。

＜条件のセットに係る第８派生例＞
上述の実施の形態では、条件のセットが、ＵＥのＰＳトラフィックのバッファリングが可能な期間、さらには、ＵＥのＰＤＮコネクションがターゲットアクセスへハンドオーバされることの通知を含む場合について説明している。しかしながら、条件のセットにはその他の条件やパラメータが含まれてもよい。例えば、条件のセットに、ＣＳコール後にＵＥのＰＳトラフィックを再開するためにＵＥが調整を必要とする周波数が含まれてもよい。

例えば、ＵＥ１００が受信した条件のセットには、ＬＧＷ１１６がＵＥ１００のＬＩＰＡ ＰＳセッションをバッファリングする期間が含まれており、さらに、セル（Ｅ−ＵＴＲＡＮ１０１）の周波数が含まれている。ＣＳコール後、ＵＥ１００は、条件のセットに示されている期間を用いて、ＵＥ１００がＬＩＰＡ ＰＳセッションを再開できるかどうかを判断する。そして、再開できるのであれば、ＵＥ１００は、ＬＩＰＡセッションを再開するためにＨｅＮＢ１０４によって管理されているセル（Ｅ−ＵＴＲＡＮ１０１）へ戻るよう選択する際の参考として、条件のセットに示されている周波数を利用する。

＜ＵＥがバッファリング時間に関してＨｅＮＢと交渉を行う第９派生例＞
条件のセットで示されている期間は、例えば、ネットワークのケーパビリティ（例えば、データ格納キャパシティ）に基づき、ネットワークが決定することが可能である。しかしながら、この期間に関してＵＥとネットワークとの間で交渉が行われてもよい。この交渉は、ＵＥが行う又は受けるＣＳコールのタイプに適した動的な期間の設定を可能にするという利点を有する。例えば、ＵＥ１００は、ＣＳケーパブルドメインへの切り替えが単にショートメッセージの送信（ＳＭＳ）のためだけであることを把握すると、ＬＧＷ１１６がＵＥ１００のＬＩＰＡ ＰＳトラフィックをバッファリングするために必要な期間が短いことをＬＧＷ１１６へ通知する。この場合、ＵＥ１００は、ＳＭＳの送信が完了するとすぐにＥ−ＵＴＲＡＮ１０１へ戻って、ＬＩＰＡ ＰＳトラフィックを継続する。

＜バッファリングエンティティに係る第１０派生例＞
バッファリングエンティティは、ＵＥがＰＳセッションを再開できるように、ＵＥのＩＰアドレスを維持する。このバッファリングエンティティは、例えば、ＰＤＮ ＧＷ、ＬＧＷ、ｅＮＢ、又は、ＨｅＮＢなどによって実現可能である。また、バッファリングエンティティは、さらに、他のタイプのコンテキスト（例えば、ＵＥの接続状態）を維持してもよい。例えば、ＬＧＷ１１６が家庭内又は企業ネットワーク１０３のネットワークアドレス変換（ＮＡＴ）デバイスも兼ねている場合には、ＬＧＷ１１６は、ＵＥ１００に関するＮＡＴの状態も維持することが可能である。これにより、ＵＥ１００がＬＧＷ１１６とのＰＳセッションを再開しようとする際に、ＮＡＴの状態は再構成される必要がなくなる。また、別の例では、ＬＧＷ１１６は、ＵＥ１００のＨＴＴＰプロキシであってもよい。この場合には、ＬＧＷ１１６によって、ＨＴＴＰプロキシに関するＵＥ１００の構成が維持されてもよい。

＜バッファリングする期間をユーザに表示する第１１派生例＞
上述の第１及び第２の実施の形態では、条件のセットに示されている期間が、ＵＥによってのみ考慮されることを前提としているが、この期間をユーザに通知できるようにしてもよい。例えば、ＵＥのグラフィカルユーザインタフェース（ＧＵＩ）によって、ＰＳセッションがバッファリングされる時間をユーザに対して表示してもよい。これによって、ユーザは、ＰＳセッションに影響を与えずにＣＳコールを行うことができる期間を把握することが可能となる。例えば、ＵＥ１００は、ＨｅＮＢ１０４からハンドオーバコマンドを取得すると、ＬＩＰＡ ＰＳセッションがどのくらいの期間バッファリングされるかをユーザへ知らせるために、条件のセットに示されている期間をユーザに対して表示する。ユーザは、ＣＳコールを行う又は受ける際に、この情報を考慮することが可能となる。また、バッファリング時間が短過ぎるとユーザが感じるのであれば、バッファリングエンティティと交渉を行って、バッファリング期間を拡張するか、又は、アプリケーションを使用してＰＳトラフィックを一時的に中断（すなわち、ストリーミングしているビデオ再生を停止するなど）してもよい。

＜ＵＥがページメッセージを受信する第１２派生例＞
上述の第１及び第２の実施の形態では、ＵＥが進行中のデータ通信を有しており、ネットワークがＣＳサービス通知をＵＥへ送信すると仮定している。ＵＥは、ＣＳサービス通知の受信時、又は、ＵＥがＣＳコールを受け入れる場合などに、条件のセットをチェックする。しかしながら、ＵＥは進行中のデータ通信を持っていなくてもよく、また、ネットワークはＣＳサービス通知ではなく、ページメッセージを送信してもよい。ＵＥは、ページメッセージを受信し、ＣＳコールを受け入れる場合に条件のセットをチェックする。

＜Ｍ２Ｍアプリケーションへ適用される第１３派生例＞
また、本発明は、マシントゥーマシンタイプコミュニケーション（Ｍ２Ｍ）のシナリオに適用可能である。例えば、マシンタイプコミュニケーション（ＭＴＣ）デバイスが、ＰＳケーパブルドメインに存在し、ＭＴＣサーバからパケットデータをダウンロードしている際に、ＣＳドメインへ切り替えてＳＭＳを受信するよう要求するページ（ＳＭＳ到着のページ）を受信したとする。このような場合に、本発明を利用して、ＭＴＣデバイスがＣＳケーパブルドメインへハンドオーバしてＳＭＳを取得する際に、バッファリングエンティティがＭＴＣサーバからＭＴＣデバイスへのデータパケットをバッファリングすることが可能である。ＭＴＣデバイスは、ＳＭＳの取得を完了すると、バッファリングエンティティから提供された条件のセットに基づいて、ＭＴＣサーバとのデータ通信を再開することが可能かどうかを判断する。データ通信の再開が可能であるならば、ＭＴＣデバイスは、ＰＳケーパブルドメインへ戻って、ＭＴＣサーバとのデータ通信を再開する。

＜ＵＥの機能アーキテクチャの一例＞
また、図１６は、本発明を実現するための好適な機能アーキテクチャの一例を示すブロック図である。図１６には、ネットワークインタフェースモジュール１６０１、３ＧＰＰアクセススタック１６０２、ＩＰプロトコルスタック１６０３、アプリケーション１６０４を有する機能アーキテクチャ１６００が図示されている。なお、図１６に図示されている機能アーキテクチャを有する好適な装置は、例えばモバイルフォンやラップトップなどのモバイル電子通信デバイスであってもよいが、これに限定されるものではない。また、図１６に図示されている機能アーキテクチャを有する好適な装置は、上述のＵＥ１００、ＵＥ２００に対応している。

ネットワークインタフェースモジュール１６０１は、当該装置が通信媒体を介して別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを示す機能ブロックである。当該技術分野において周知の用語を使用すると、ネットワークインタフェースモジュール１６０１は、レイヤ１（物理レイヤ）とレイヤ２（データリンクレイヤ）の通信コンポーネント、ファームウェア、ドライバ、及び通信プロトコルを表している。なお、当業者であれば、機能アーキテクチャ１６００が、１つ以上のネットワークインタフェースモジュール１６０１を含んでいてもよいことは明らかである。また、シグナル／データパス１６０５によって、ネットワークインタフェースモジュール１６０１は、３ＧＰＰアクセススタック１６０２に対して、トリガ／パケットを伝送することが可能である。例えば、ネットワークインタフェースモジュール１６０１は、受信したＮＡＳメッセージ（例えば、ＰＤＮアクセプトメッセージ）を、更なる処理のために３ＧＰＰアクセススタック１６０２へ転送する。さらに、シグナル／データパス１６０５によって、３ＧＰＰアクセススタック１６０２は、ネットワークへ送信したいＮＡＳメッセージ（例えば、ＰＤＮコネクションメッセージ）を送信するために、ネットワークインタフェースモジュール１６０１へ渡すことが可能である。

また、３ＧＰＰアクセススタック１６０２は、３ＧＰＰ無線アクセスネットワークを介して当該装置とネットワークとの間の通信を管理する機能ブロックである。３ＧＰＰアクセススタック１６０２は、アクセスストラタム１６０６、及び、非アクセスストラタム（ノンアクセスストラタム）１６０７の２つの機能を有している。

アクセスストラタム１６０６は、この好適な装置のための無線ベアラを管理する。例えば、アクセスストラタム１６０６は、ＲＲＣ接続シグナリングを実行して、当該装置がデータパケットを送受信できるようにするための無線ベアラを構成する。ノンアクセスストラタム１６０７は、当該装置が３ＧＰＰ無線アクセスネットワークへ接続される際に、モビリティやセッションに関する処理を行う。アクセスストラタム１６０６とノンアクセスストラタム１６０７との間のシグナル／データパス１６０８によって、相互にトリガ／パケットの伝送を行うことが可能である。例えば、当該装置が無線セルを選択する必要がある場合、ノンアクセスストラタム１６０７は、選択された無線セル識別子をアクセスストラタム１６０６へ提供する。

また、ＩＰプロトコルスタック１６０３は、当該装置がセルラネットワークを介してグローバルインターネット上の他のノードと通信を行うためのインターネットプロトコルを実装するソフトウェアを有する機能ブロックである。ＩＰプロトコルスタック１６０３は、例えばＩＰｖ４又はＩＰｖ６を有しているが、これに限定されるものではない。シグナル／データパス１６０９によって、ＩＰプロトコルスタック１６０３は、３ＧＰＰアクセススタック１６０２へトリガ／パケットを伝送することが可能である。例えば、３ＧＰＰアクセススタック１６０２は、３ＧＰＰ無線アクセスネットワークにおける通信のためのＩＰアドレスを、ＩＰプロトコルスタック１６０３へ渡すことが可能である。さらに、シグナル／データパス１６１０によって、ＩＰプロトコルスタック１６０３は、ＩＰアドレス情報をセッションコントロール機能１６１１へ渡すことが可能である。

また、アプリケーション１６０４は、通信プロトコルスタックにおけるネットワークレイヤより上位に位置するすべてのプロトコル及びプログラムを示す機能ブロックを表している。これは、例えば伝送制御プロトコル（ＴＣＰ）、ストリーム制御トランスポートプロトコル（ＳＣＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）などのトランスポートプロトコル又はセッションレイヤプロトコル、あるいは、他のノードと通信を行うために必要なプログラム及びソフトウェアを含んでいる。アプリケーション１６０４は、さらに、セッションコントロール機能１６１１とデータベースモジュール１６１２とを有している。データベースモジュール１６１２は、当該装置が必要とする情報を格納する機能を提供する。データベースモジュール１６１２に格納される情報は、例えば、ＰＤＮ ＧＷ、ＬＧＷ、ｅＮＢ又はＨｅＮＢによって提供された条件のセットであるが、これに限定されるものではない。また、シグナル／データパス１６１３によって、ノンアクセスストラタム１６０７は、ＰＣＯによって提供された条件のセットをデータベースモジュール１６１２に渡して格納することが可能である。

また、本発明では、セッションコントロール機能１６１１が導入される。このセッションコントロール機能１６１１は、ＣＳコール後に、当該装置がＰＳセッションを継続するために元のアクセスネットワークへ戻るべきかどうかを判断する。ノンアクセスストラタム１６０７は、当該装置に関する待機中ＣＳコールのトリガを受けると、セッションコントロール機能１６１１へこのトリガ（イベント）を通知する。なお、この通知は、シグナル／データパス１６１４によって可能となる。セッションコントロール機能１６１１は、当該装置のＰＳセッション用に提供された条件のセットをデータベースモジュール１６１２から取り出す。この検索は、シグナル／データパス１６１５によって可能となる。さらに、当該装置が接続されている現在の無線セル識別子もデータベースモジュール１６１２において検索される。当該装置のＰＳセッションに関する条件のセットが存在する場合には、セッションコントロール機能１６１１は、ＣＳコールが終了した場合にセッションコントロール機能１６１１へ通知を行うよう、ノンアクセスストラタム１６０７へ依頼する。ノンアクセスストラタム１６０７は、当該装置がアイドルモードになること（すなわち、ＣＳコールの終了）を把握できる。さらに、セッションコントロール機能１６１１は、当該装置がＣＳコールを受けている時間を監視するためのタイマ機能を有しており、ＣＳコールの時間を計測する。

ＣＳコールの完了後に当該装置がアイドルモードになると、ノンアクセスストラタム１６０７は、このイベント（アイドルモードになったこと）をセッションコントロール機能１６１１へ通知する。セッションコントロール機能１６１１は、当該装置によって行われていたＣＳコールの時間が、条件のセットで規定されている期間（すなわち、ネットワークにおけるパケットのバッファリング時間）より短いかどうかをチェックする処理を行う。ＣＳコールの時間がバッファリング時間より短ければ、セッションコントロール機能１６１１は、ノンアクセスストラタム１６０７に対して、当該装置がＣＳコールの前に接続されていた無線セルを選択するよう通知する。このとき、セッションコントロール機能１６１１は、無線セルの識別子（データベースモジュール１６１２から検索される）やその他の付加情報などをノンアクセスストラタム１６０７へ提供することが可能である。ノンアクセスストラタム１６０７は、選択された無線セル識別子をアクセスストラタム１６０６へ提供し、選択手順が実行される。

本明細書では、本発明に関して実用的かつ好適な実施の形態を説明しているが、本発明の範囲を逸脱しない程度に、デザインやパラメータなどの変更が可能である。例えば、本明細書では、特定の番号、回数、構造、プロトコル名、及びその他のパラメータが、本発明を理解するために詳細に説明されているが、これらはいずれも一例である。

例えば、上述の実施の形態では、ユーザの着信ＣＳコールに関して、ネットワークからトリガを取得することを前提としている。しかしながら、本発明は、ユーザがＣＳコールを行うことを決定した場合にも適用可能である。この場合には、トリガはユーザから発せられることになる。また、上述の実施の形態では、ＵＥが異なるアクセスネットワークへハンドオーバを行うためのトリガが、ＣＳコールに基づいていることを前提としている。しかしながら、本発明は、ネットワークが頻繁なスキャニング及びレポーティングを実行するようＵＥへ依頼できる場合に対しても適用可能である。この場合には、本発明に係るトリガはＣＳコールではなく、ネットワークコマンドである。

さらに、上述の実施の形態では、ＵＥがＥ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバを実行する場合について説明されている。しかしながら、本発明は、ＵＥがＥ−ＵＴＲＡＮからＧＲＥＡＮセルへハンドオーバを実行する場合にも適用可能である。また、上述の実施の形態で説明されているシナリオは、３ＧＰＰアーキテクチャに関連している。しかしながら、本明細書で説明されている本発明の解決方法は、異種アクセスネットワークを配置する技術や、何らかのモビリティ管理メカニズムに対してアクセス技術タイプの使用を制限する技術などに対して適用可能である。

また、上記の本発明の実施の形態の説明で用いた機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、 通信端末が、異種間ネットワークでハンドオーバを行った後であっても、ハンドオーバ前に接続していたアクセスネットワークにおいて進行中であった通信を再開できるかどうかを判断できるようにするという効果を有しており、パケット交換データ通信ネットワークにおける通信技術、特に、異なるアクセスネットワーク間でハンドオーバが行われる際のパケットデータ通信技術に適用可能である。

Claims (18)

1. 第１通信技術をサポートしているが第２通信技術をサポートしていない第１ネットワークと、前記第２通信技術をサポートしている第２ネットワークとによって構成されているネットワークに接続可能な通信端末であって、
   前記第１ネットワークに接続して前記第１通信技術による通信を行う第１通信部と、
   前記第１通信技術による通信を行っている際に、前記第２通信技術による通信を開始するトリガを取得する第２通信トリガ取得部と、
   前記トリガに応じて、前記第１ネットワークから前記第２ネットワークへ接続を切り替えて前記第２通信技術による通信を開始する第２通信部と、
   前記トリガに応じて開始された前記第２通信技術による通信を終了する前までに、所定の通信再開条件を前記ネットワークから取得する条件取得部と、
   前記第２通信技術による通信の終了後に、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点からの前記第１通信技術による通信を再開できるかどうかを、前記所定の通信再開条件が有効か否かに基づいて判断する再開判断部とを、
   有する通信端末。
2. 前記第１通信技術がパケット交換通信であり、前記第２通信技術が回線交換通信であり、前記トリガが前記回線交換通信における着呼又は発呼である請求項１に記載の通信端末。
3. 前記第２通信トリガ取得部は、前記トリガを前記ネットワークから取得するとともに、さらに、前記第１ネットワークから前記第２ネットワークへの接続切り替えの指示を前記ネットワークから取得する請求項１に記載の通信端末。
4. 前記条件取得部は、前記第２通信部が前記第１ネットワークから前記第２ネットワークへ接続を切り替えた後、前記所定の通信再開条件を前記第２ネットワークから取得する請求項１に記載の通信端末。
5. 前記条件取得部は、前記第１ネットワークから前記第２ネットワークへの接続切り替えの指示と共に、前記所定の通信再開条件を前記第１ネットワークを通じて取得する請求項１に記載の通信端末。
6. 前記条件取得部は、前記第１通信技術による通信を行うための接続を確立する際に前記所定の通信再開条件を取得する請求項１に記載の通信端末。
7. 前記所定の通信再開条件に、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点以降に前記第１通信技術による通信において前記通信端末へ送信されるべきであった情報を、前記第１ネットワークにおいてバッファリングすることを示す情報が含まれる請求項１に記載の通信端末。
8. 前記所定の通信再開条件に、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点以降に前記第１通信技術による通信において前記通信端末へ送信されるべきであった情報を、前記第１ネットワークにおいてバッファリングするバッファリング期間が含まれる請求項１に記載の通信端末。
9. 前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点から、前記第２通信技術による通信を終了した時点までの計時を行う計時部を有し、
   前記再開判断部は、前記第１ネットワークへ戻って前記第１通信技術による通信を再開できるかどうか判断する際に、前記計時部による計時結果と前記バッファリング期間とを比較する請求項８に記載の通信端末。
10. 前記所定の通信再開条件に、前記第１通信部が前記第２ネットワークへ接続することで、前記第１ネットワークで行われていた前記第１通信技術による通信を前記第２ネットワークを通じて再開できるかどうかを示す情報が含まれている請求項１に記載の通信端末。
11. 前記再開判断部は、前記第２通信技術による通信の終了後に前記第１ネットワークに接続を戻すことで、前記第１ネットワークを通じて前記第１通信技術による通信を再開できるかどうかを判断し、前記第１ネットワークを通じて前記第１通信技術による通信を再開できる場合には、前記第１通信部は、前記第１ネットワークに接続して前記第１通信技術による通信の再開を前記第１ネットワークに対して要求する請求項１に記載の通信端末。
12. 前記第１通信部は、前記第１ネットワークに接続して前記第１通信技術による通信の再開を前記第１ネットワークに対して要求する際、前記第２ネットワークへの接続切り替え前に前記第１通信技術による通信に使用していたアドレスを前記第１ネットワークへ通知する請求項１１に記載の通信端末。
13. 前記再開判断部は、前記第２通信技術による通信の終了後に前記第２ネットワークを通じて前記第１通信技術による通信を再開できるかどうかを判断する請求項１に記載の通信端末。
14. 第１通信技術をサポートしているが第２通信技術をサポートしていない第１ネットワークと、前記第２通信技術をサポートしている第２ネットワークとによって構成されているネットワークにおいて、前記第１ネットワークに位置しているネットワークノードであって、
    前記第１ネットワークに接続して前記第１通信技術による通信を行っている通信端末に対して、所定の通信再開条件を提供する通信再開条件提供部を有し、
    前記所定の通信再開条件が、前記第１通信技術による通信を行っている前記通信端末が前記第２通信技術による通信を開始するトリガを取得し、前記トリガに応じて前記第１ネットワークから前記第２ネットワークへ接続を切り替えて前記第２通信技術による通信を開始する場合、前記第２通信技術による通信の終了後に、前記通信端末が、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点からの前記第１通信技術による通信を再開できるかどうかを判断するために用いられる情報であるネットワークノード。
15. 前記所定の通信再開条件に、前記通信端末が前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点以降に前記第１通信技術による通信において前記通信端末へ送信されるべきであった情報を、前記第１ネットワークにおいてバッファリングすることを示す情報が含まれる請求項１４に記載のネットワークノード。
16. 前記所定の通信再開条件に、前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点以降に前記第１通信技術による通信において前記通信端末へ送信されるべきであった情報を、前記第１ネットワークにおいてバッファリングするバッファリング期間が含まれる請求項１４に記載のネットワークノード。
17. 前記通信端末が前記第１ネットワークから前記第２ネットワークへ接続を切り替えた場合には、前記通信端末が前記第１ネットワークから前記第２ネットワークへ接続を切り替えた時点以降に前記第１通信技術による通信において前記通信端末へ送信されるべきであった情報を、前記バッファリング期間だけバッファリングするバッファを有する請求項１６に記載のネットワークノード。
18. 前記バッファリング期間内に前記通信端末が前記第１ネットワークへ接続を戻し、前記第１通信技術による通信の再開の要求が前記通信端末から送信されたことを検出した場合には、前記バッファに蓄積されている情報を前記通信端末へ転送する情報転送部を有する請求項１７に記載のネットワークノード。

Images