JP2015065689A - 移動通信システム、基地局、上位装置、ゲートウェイ装置、通信方法、プログラム - Google Patents

Abstract

【課題】ＨＮＢ間でＲＦＣＩ情報が一致しない場合の解決方法を提供する。
【解決手段】移動通信システムは、端末と、端末が移動前に接続する移動元基地局と、端末が移動後に接続する移動先基地局と、移動元基地局および移動先基地局を配下に持つ上位装置と、を有する。ここで、移動元基地局および移動先基地局は、音声符号化における制御情報が予め設定されており、前記移動元基地局は、自局の制御情報を第１のメッセージに含め、第１のメッセージを上位装置に送信し、上位装置は、移動元基地局の制御情報を第２のメッセージに含め、第２のメッセージを移動先基地局に送信する。
【選択図】図２

Description

本発明は、移動通信システム、基地局、上位装置、ゲートウェイ装置、通信方法、プログラムに関する。

３ＧＰＰ（3rd Generation Partnership Project）の既存の移動通信システムとして、Ｎｏｄｅ−Ｂ（基地局）と、ＲＮＣ（Radio Network Controller）と、ＣＮ（Core Network：コアネットワーク）と、から構成される移動通信システムがある。

このような構成の移動通信システムにおける音声データの符号化方式として、ＡＭＲ（Adaptive Multi-Rate）が挙げられる。ＡＭＲは、回線状況等に応じて、動的に音声データのレートを変更する方式である。

ＡＭＲを用いる移動通信システムでは、音声データの符号化と復号化のレートを同じにするために、ＣＮ内にトランスコーダを設置し、必要に応じて、トランスコーダにより再符号化（トランスコード）を行っている。

ＡＭＲにより符号化された音声データのデータフレームは、データサイズが異なる複数のサブフローから構成される。これら複数のサブフレームの組み合わせは、音声データのレートに応じて異なり、その組み合わせごとにＲＦＣＩ（RAB sub-Flow Combination Indicator）値が識別子として規定されている。すなわち、ＲＦＣＩ値は、音声データのレートごとに定義されることになる。

また、ＡＭＲを用いる移動通信システムでは、各Ｎｏｄｅ−Ｂに、音声符号化における制御情報として、ＲＦＣＩ情報が設定されている。ＲＦＣＩ情報は、ＲＦＣＩ値ごとに、そのＲＦＣＩ値が示すデータフレームの構造を識別する情報、具体的には、そのデータフレームを構成するサブフロー数とサブフロー毎のデータサイズに関する情報を含んでいる。なお、ＲＦＣＩ情報は、ＡＭＲ以外に、Ｗｉｄｅ−Ｂａｎｄ ＡＭＲ（広帯域の音声コーデック）やＣＳストリーミングサービス（Ｆａｘやモデム通信）にも用いられる。

Ｎｏｄｅ−Ｂは、あるレートで符号化した音声データを送信する場合、そのレートに対応するＲＦＣＩ値を付加した音声データを他のＮｏｄｅ−Ｂに送信し、また、他のＮｏｄｅ−Ｂから音声データを受信した場合、その音声データに付加されているＲＦＣＩ値に対応するレートで、その音声データを復号化する。

ここで、ＵＥ（User Equipment：端末）が２つのＮｏｄｅ−Ｂを介して音声通話を行う場合に、２つのＮｏｄｅ−Ｂ間でＲＦＣＩ情報が一致していれば、これら２つのＲＦＣＩ情報において、各ＲＦＣＩ値は同じ構造のデータフレームを示していることになる。そのため、２つのＮｏｄｅ−Ｂ間では、ＣＮ内のトランスコーダを経由しなくても、同じレートで音声データの符号化／復号化を行うことが可能となる。このようにトランスコーダを経由せずに音声通話を行う方式を、トランスコーダフリーオペレーション（ＴｒＦＯ：Transcoder Free Operation）という。この方式は、３ＧＰＰ ＴＳ２３．１５３（非特許文献１）で規定されている。

その一方、２つのＮｏｄｅ−Ｂ間でＲＦＣＩ情報が不一致であれば、これら２つのＲＦＣＩ情報においては、ＲＦＣＩ値が同じであっても、異なる構造のデータフレームを示している場合がある。この場合、トランスコーダを経由しないと、２つのＮｏｄｅ−Ｂ間で同じレートで音声データの符号化／復号化を行うことはできないことから、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま音声通話を行うことはできない。

したがって、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うには、２つのＮｏｄｅ−Ｂ間でＲＦＣＩ情報を一致させることが望ましい。

しかし、移動通信システムでは、ＵＥの移動が頻繁に発生するため、ＵＥが移動前に接続する移動元Ｎｏｄｅ−ＢとＵＥが移動後に接続する移動先Ｎｏｄｅ−ＢとでＲＦＣＩ情報が一致しない場合も多いと考えられる。

そこで、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）では、ＵＥの移動元Ｎｏｄｅ−Ｂが接続されるＲＮＣと移動先Ｎｏｄｅ−Ｂが接続されるＲＮＣとが異なる、いわゆるＳＲＮＳ（Serving Radio Network Subsystem）リロケーションの発生時に、ＲＮＣ間で、ＣＮを介して、Ｉｕ−ＵＰ（Iu interface user plane）プロトコルにて規定されるＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎメッセージにより、ＲＦＣＩ情報の引継ぎを行うことが規定されている。

３ＧＰＰ ＴＳ ２３．１５３ ３ＧＰＰ ＴＳ ２５．４１５ ３ＧＰＰ ＴＳ ２５．４１３ ３ＧＰＰ ＴＳ ２５．４６７ ３ＧＰＰ ＴＳ ２５．４６８ ３ＧＰＰ ＴＳ ２５．４６９

ところで、昨今、３ＧＰＰでは、ＨＮＢ（Home Node-B：小型基地局）と呼ばれる、家庭および小規模オフィス向けの小型基地局と、ＨＮＢ−ＧＷ（Home Node-Gateway）と、ＣＮと、から構成される移動通信システムが検討されている。この移動通信システムの構成を、図１を用いて詳細に説明する。

図１を参照すると、この移動通信システムは、ＵＥ１と、ＨＮＢ−Ｓ２と、ＨＮＢ−Ｔ３と、ＨＮＢ−ＧＷ４と、ＣＮノード５を含むＣＮ６と、ＨＮＢ−ＧＷ７と、ＨＮＢ−Ｘ８と、を有する。

ＵＥ１は、第３世代移動携帯電話（端末）である。

ＨＮＢ−Ｓ２、ＨＮＢ−Ｔ３、およびＨＮＢ−Ｘ８は、家庭および小規模オフィス向けの小型基地局である。

ＨＮＢ−Ｓ２は、ＵＥ１が移動前に接続する移動元ＨＮＢである。

ＨＮＢ−Ｔ３は、ＵＥ１が移動後に接続する移動先ＨＮＢである。

ＨＮＢ−Ｘ８は、ＵＥ１の通信相手のＵＥ（不図示）を配下に持つＨＮＢである。

ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３をＣＮ６に接続するゲートウェイ装置であり、また、ＨＮＢ−ＧＷ７は、ＨＮＢ−Ｘ８をＣＮ６に接続するゲートウェイ装置である。

ＣＮ６は、第３世代移動交換網である。

ＣＮノード５は、ＣＮ６内に設けられたＨＭＳ（Home NodeB Management System）やＭＳＣ（Mobile Switching Center）などのコアネットワーク装置である。

ＵＥ１は、同一のＨＮＢ−ＧＷ４配下のＨＮＢ−Ｓ２からＨＮＢ−Ｔ３へ移動する。このような移動を、ｉｎｔｒａ−ＨＮＢ−ＧＷリロケーションと呼ぶ。

ＵＥ１は、移動前は、ＨＮＢ−Ｓ２、ＨＮＢ−ＧＷ４、ＣＮ６、ＨＮＢ−ＧＷ７、およびＨＮＢ−Ｘ８を介して、ＨＮＢ−Ｘ８配下のＵＥと音声通話を行う。

また、ＵＥ１は、移動後は、ＨＮＢ−Ｔ３、ＨＮＢ−ＧＷ４、ＣＮ６、ＨＮＢ−ＧＷ７、およびＨＮＢ−Ｘ８を介して、ＨＮＢ−Ｘ８配下のＵＥと音声通話を行う。

なお、図１において、ＵＥ１の通信相手の対向のシステムは、ＨＮＢ−Ｘ８／ＨＮＢ−ＧＷ７／ＣＮ６で構成される３ＧＰＰ無線通信システムになっているが、既存のＮｏｄｅ−Ｂ／ＲＮＣ／ＣＮで構成される３ＧＰＰ無線通信システムであってもよい。

ここで、ＨＮＢは、携帯電話事業者ではなく、個人が設置することが想定される。そのため、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３は、同一のＨＮＢ−ＧＷ４の配下にあるものの、ベンダが異なることが想定される。

従って、ＵＥ１によるＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーションの発生時に、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間でＲＦＣＩ情報が一致しないことも十分に考えられる。

もし、ＲＦＣＩ情報が一致しない場合、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができなくなるという課題が生じる。

そこで、３ＧＰＰでは、ＨＮＢ／ＨＮＢ−ＧＷ／ＣＮで構成される移動通信システムにおいても、ＨＮＢ間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーションの方法の標準化に向けた議論がなされているが、ＨＮＢ間でＲＦＣＩ情報が一致しない場合の解決方法は何ら提示されていない。

そこで、本発明の目的は、上述した課題を解決し、ＨＮＢ間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる移動通信システム、基地局、上位装置、ゲートウェイ装置、通信方法、プログラムを提供することにある。

本発明の第１の移動通信システムは、
端末と、前記端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、前記移動元基地局および前記移動先基地局を配下に持つ上位装置と、を有してなる移動通信システムであって、
前記移動元基地局および前記移動先基地局は、音声符号化における制御情報が予め設定されており、
前記移動元基地局は、自局の前記制御情報を第１のメッセージに含め、該第１のメッセージを前記上位装置に送信し、
前記上位装置は、前記移動元基地局の前記制御情報を第２のメッセージに含め、該第２のメッセージを前記移動先基地局に送信する。

本発明の第２の移動通信システムは、
端末と、前記端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、前記移動元基地局および前記移動先基地局をコアネットワークに接続するゲートウェイ装置と、を有してなる移動通信システムであって、
前記移動元基地局および前記移動先基地局は、音声符号化における制御情報として、識別子ごとに、該識別子が示す、音声符号化された音声データのデータフレームの構造を識別する制御情報が予め設定されており、
前記移動元基地局は、自局の前記制御情報を第１のメッセージに含め、該第１のメッセージを前記ゲートウェイ装置に送信し、
前記移動先基地局は、自局の前記制御情報を第２のメッセージに含め、該第２のメッセージを前記ゲートウェイ装置に送信し、
前記ゲートウェイ装置は、
前記第１のメッセージに含まれる、前記移動元基地局の前記制御情報と、前記第２のメッセージに含まれる、前記移動先基地局の前記制御情報と、を格納し、
前記移動元基地局および前記移動先基地局の前記制御情報が一致しない場合、以降に、前記移動先基地局から音声データを受信すると、該音声データに付加されている識別子を、前記移動元基地局の前記制御情報内で同じ構造のデータフレームを示している識別子に変換し、
前記変換された識別子が付加された音声データを前記コアネットワークに送信する。

本発明の第１の基地局は、
端末が移動前に接続する移動元の基地局であって、
音声符号化における制御情報が予め設定されており、自局の前記制御情報をメッセージに含める制御部と、
前記メッセージを上位装置に送信する送受信部と、を有する。

本発明の第２の基地局は、
端末が移動後に接続する移動先の基地局であって、
音声符号化における制御情報が予め設定されている制御部と、
上位装置から、前記端末が移動前に接続していた移動元の基地局の前記制御情報を含む第１のメッセージを受信する送受信部と、を有する。

本発明の上位装置は、
端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、を配下に持つ上位装置であって、
前記移動元基地局および前記移動先基地局は、音声符号化における制御情報が予め設定されており、
前記移動元基地局から、前記移動元基地局の前記制御情報を含む第１のメッセージを受信する送受信部と、
前記移動元基地局の前記制御情報を第２のメッセージに含める制御部と、を有し、
前記送受信部は、前記第２のメッセージを前記移動先基地局に送信する。

本発明のゲートウェイ装置は、
端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、をコアネットワークに接続するゲートウェイ装置であって、
前記移動元基地局および前記移動先基地局は、音声符号化における制御情報として、識別子ごとに、該識別子が示す、音声符号化された音声データのデータフレームの構造を識別する制御情報が予め設定されており、
前記移動元基地局から、前記移動元基地局の前記制御情報を含む第１のメッセージを受信するとともに、前記移動先基地局から、前記移動先基地局の前記制御情報を含む第２のメッセージを受信する送受信部と、
前記第１のメッセージに含まれる、前記移動元基地局の前記制御情報と、前記第２のメッセージに含まれる、前記移動先基地局の前記制御情報と、を格納する記憶部と、
前記移動元基地局および前記移動先基地局の前記制御情報が一致しない場合、以降に、前記移動先基地局から音声データを受信すると、該音声データに付加されている識別子を、前記移動元基地局の前記制御情報内で同じ構造のデータフレームを示している識別子に変換する制御部と、
前記変換された識別子が付加された音声データを前記コアネットワークに送信する第２の送受信部と、を有する。

本発明の第１の通信方法は、
端末と、前記端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、前記移動元基地局および前記移動先基地局を配下に持つ上位装置と、を有してなる移動通信システムによる通信方法であって、
前記移動元基地局が、自局の音声符号化における制御情報を第１のメッセージに含め、該第１のメッセージを前記上位装置に送信するステップと、
前記上位装置が、前記移動元基地局の前記制御情報を第２のメッセージに含め、該第２のメッセージを前記移動先基地局に送信するステップと、を有する。

本発明の第２の通信方法は、
端末と、前記端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、前記移動元基地局および前記移動先基地局をコアネットワークに接続するゲートウェイ装置と、を有してなる移動通信システムによる通信方法であって、
前記移動元基地局が、自局の音声符号化における制御情報として、識別子ごとに、該識別子が示す、音声符号化された音声データのデータフレームの構造を識別する制御情報を第１のメッセージに含め、該第１のメッセージを前記ゲートウェイ装置に送信するステップと、
前記移動先基地局が、自局の前記制御情報を第２のメッセージに含め、該第２のメッセージを前記ゲートウェイ装置に送信するステップと、
前記ゲートウェイ装置が、前記第１のメッセージに含まれる、前記移動元基地局の前記制御情報と、前記第２のメッセージに含まれる、前記移動先基地局の前記制御情報と、を格納するステップと、
前記ゲートウェイ装置が、前記移動元基地局および前記移動先基地局の前記制御情報が一致しない場合、以降に、前記移動先基地局から音声データを受信すると、該音声データに付加されている識別子を、前記移動元基地局の前記制御情報内で同じ構造のデータフレームを示している識別子に変換するステップと、
前記ゲートウェイ装置が、前記変換された識別子が付加された音声データを前記コアネットワークに送信するステップと、を有する。

本発明の第３の通信方法は、
端末が移動前に接続する移動元の基地局による通信方法であって、
自局の音声符号化における制御情報をメッセージに含めるステップと、
前記メッセージを上位装置に送信するステップと、を有する。

本発明の第４の通信方法は、
端末が移動後に接続する移動先の基地局による通信方法であって、
上位装置から、前記端末が移動前に接続していた移動元の基地局の音声符号化における制御情報を含む第１のメッセージを受信するステップと、を有する。

本発明の第５の通信方法は、
端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、を配下に持つ上位装置による通信方法であって、
前記移動元基地局から、前記移動元基地局の音声符号化における制御情報を含む第１のメッセージを受信するステップと、
前記移動元基地局の前記制御情報を第２のメッセージに含めるステップと、
前記第２のメッセージを前記移動先基地局に送信するステップと、を有する。

本発明の第６の通信方法は、
端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、をコアネットワークに接続するゲートウェイ装置による通信方法であって、
前記移動元基地局から、前記移動元基地局の音声符号化における制御情報として、識別子ごとに、該識別子が示す、音声符号化された音声データのデータフレームの構造を識別する制御情報を含む第１のメッセージを受信するとともに、前記移動先基地局から、前記移動先基地局の前記制御情報を含む第２のメッセージを受信するステップと、
前記第１のメッセージに含まれる、前記移動元基地局の前記制御情報と、前記第２のメッセージに含まれる、前記移動先基地局の前記制御情報と、を格納するステップと、
前記移動元基地局および前記移動先基地局の前記制御情報が一致しない場合、以降に、前記移動先基地局から音声データを受信すると、該音声データに付加されている識別子を、前記移動元基地局の前記制御情報内で同じ構造のデータフレームを示している識別子に変換するステップと、
前記変換された識別子が付加された音声データを前記コアネットワークに送信するステップと、を有する。

本発明の第１のプログラムは、
端末が移動前に接続する移動元の基地局に、
自局の音声符号化における制御情報をメッセージに含める手順と、
前記メッセージを上位装置に送信する手順と、を実行させる。

本発明の第２のプログラムは、
端末が移動後に接続する移動先の基地局に、
上位装置から、前記端末が移動前に接続していた移動元の基地局の音声符号化における制御情報を含む第１のメッセージを受信する手順を実行させる。

本発明の第３のプログラムは、
端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、を配下に持つ上位装置に、
前記移動元基地局から、前記移動元基地局の音声符号化における制御情報を含む第１のメッセージを受信する手順と、
前記移動元基地局の前記制御情報を第２のメッセージに含める手順と、
前記第２のメッセージを前記移動先基地局に送信する手順と、を実行させる。

本発明の第４のプログラムは、
端末が移動前に接続する移動元基地局と、前記端末が移動後に接続する移動先基地局と、をコアネットワークに接続するゲートウェイ装置に、
前記移動元基地局から、前記移動元基地局の音声符号化における制御情報として、識別子ごとに、該識別子が示す、音声符号化された音声データのデータフレームの構造を識別する制御情報を含む第１のメッセージを受信するとともに、前記移動先基地局から、前記移動先基地局の前記制御情報を含む第２のメッセージを受信する手順と、
前記第１のメッセージに含まれる、前記移動元基地局の前記制御情報と、前記第２のメッセージに含まれる、前記移動先基地局の前記制御情報と、を格納する手順と、
前記移動元基地局および前記移動先基地局の前記制御情報が一致しない場合、以降に、前記移動先基地局から音声データを受信すると、該音声データに付加されている識別子を、前記移動元基地局の前記制御情報内で同じ構造のデータフレームを示している識別子に変換する手順と、
前記変換された識別子が付加された音声データを前記コアネットワークに送信する手順と、を実行させる。

本発明の第１の移動通信システムによれば、移動元基地局は、自局の制御情報を上位装置に送信し、上位装置は、移動元基地局の制御情報を移動先基地局に送信する。

したがって、移動先基地局は、移動元基地局から制御情報を引き継ぐことができるため、移動元基地局と移動先基地局間のリロケーション発生時に、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

本発明の第２の移動通信システムによれば、ゲートウェイ装置は、移動元基地局および移動先基地局の制御情報が一致しない場合、以降、移動先基地局から受信した音声データに付加されている識別子を、移動元基地局の制御情報内で同じ構造のデータフレームを示している識別子に変換する。

したがって、移動元基地局と移動先基地局間で制御情報を引き継がなくても、移動元基地局と移動先基地局間のリロケーション発生時に、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

ＨＮＢ／ＨＮＢ−ＧＷ／ＣＮで構成される移動通信システムの構成を示す図である。 本発明の第１の実施形態の移動通信システムにおけるＨＮＢと上位装置の内部構成を示すブロック図である。 本発明の第１の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第２の実施形態の移動通信システムにおけるＨＮＢとＨＮＢ−ＧＷの内部構成を示すブロック図である。 本発明の第２の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第２の実施形態により変更されたＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージを示す図である。 本発明の第２の実施形態により変更されたＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを示す図である。 本発明の第２の実施形態により変更されたＩｕ−ＵＰ Ｐｒｏｔｏｃｏｌの状態遷移図である。 本発明の第３の実施形態の移動通信システムにおけるＨＮＢとＨＮＢ−ＧＷの内部構成を示すブロック図である。 本発明の第３の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第３の実施形態により変更されたＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージを示す図である。 本発明の第４の実施形態の移動通信システムにおけるＨＮＢとＨＮＢ−ＧＷの内部構成を示すブロック図である。 本発明の第４の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第５の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第６の実施形態の移動通信システムにおけるＣＮノードの内部構成を示すブロック図である。 本発明の第６の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第７の実施形態の移動通信システムにおけるＨＮＢとＨＮＢ−ＧＷの内部構成を示すブロック図である。 本発明の第７の実施形態の移動通信システムの動作を説明するシーケンス図である。 本発明の第８の実施形態の移動通信システムにおけるＨＮＢとＨＮＢ−ＧＷの内部構成を示すブロック図である。 本発明の第８の実施形態の移動通信システムの動作を説明するシーケンス図である。

以下に、本発明の実施形態について図面を参照して説明する。

なお、以下で説明する実施形態において、移動通信システムの全体構成自体は、図１に示したものと同様である。
（第１の実施形態）
本実施形態は、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３と、ＨＮＢ−ＧＷ４またはＣＮノード５のいずれかである上位装置（以下、上位装置９と称す）と、に特徴がある。

本実施形態では、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＨＮＢ−Ｓ２から上位装置９を介してＨＮＢ−Ｔ３に通知する。

図２を参照すると、本実施形態のＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を第１のメッセージに含める制御部２１Ａと、その第１のメッセージを上位装置９に送信する送受信部２２Ａと、を有する。

また、本実施形態の上位装置９は、ＨＮＢ−Ｓ２から第１のメッセージを受信する送受信部９１Ａと、第１のメッセージに含まれるＲＦＣＩ情報を第２のメッセージに含める制御部９２Ａと、を有し、送受信部９１Ａは、第２のメッセージをＨＮＢ−Ｔ３に送信する。

また、本実施形態のＨＮＢ−Ｔ３は、上位装置９から第２のメッセージを受信する送受信部３１Ａと、ＨＮＢ−Ｔ３のＲＦＣＩ情報を初期化し、第２のメッセージに含まれるＲＦＣＩ情報に設定（再設定）する制御部３２Ａと、を有する。

以下、本実施形態の移動通信システムの動作について、図３に示すシーケンス図に沿って説明する。

ＨＮＢ−Ｓ２は、ステップＳ１０１において、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含む第１のメッセージを上位装置９に送信する。

上位装置９は、ステップＳ１０２において、ＨＮＢ−Ｓ２から受信した第１のメッセージに含まれるＲＦＣＩ情報を含む第２のメッセージを、ＨＮＢ−Ｔ３に送信する。

上述したように本実施形態においては、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｓ２から上位装置９を介してＲＦＣＩ情報を引き継ぐことができるため、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができるという効果が得られる。
（第２の実施形態）
本実施形態は、上位装置９をＨＮＢ−ＧＷ４として、第１の実施形態をより具体化した例である。

本実施形態では、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＲＡＮＡＰメッセージにより、ＨＮＢ−Ｓ２からＨＮＢ−ＧＷ４を介してＨＮＢ−Ｔ３に通知する。

図４を参照すると、本実施形態のＨＮＢ−ＧＷ４は、対ＨＮＢ送受信部４１Ｂと、ＲＡＮＡＰ機能部４２Ｂと、対ＣＮ送受信部４３Ｂと、Ｉｕ−ＵＰフレーム制御部４４Ｂと、Ｉｕ−ＵＰフレーム転送部４５Ｂと、ＲＦＣＩ保持部４６Ｂと、を有する。なお、図４において、対ＨＮＢ送受信部４１Ｂが図２の送受信部９１Ａを構成し、その他の機能ブロックが図２の制御部９２Ａを構成する。

また、本実施形態のＨＮＢ−Ｓ２は、対ＨＮＢ−ＧＷ送受信部２１Ｂと、ＲＡＮＡＰ機能部２２Ｂと、Ｉｕ−ＵＰフレーム制御部２３Ｂと、Ｉｕ−ＵＰフレーム転送部２４Ｂと、を有する。なお、図４において、対ＨＮＢ−ＧＷ送受信部２１Ｂが図２の送受信部２２Ａを構成し、その他の機能ブロックが図２の制御部２１Ａを構成する。

また、本実施形態のＨＮＢ−Ｔ３は、対ＨＮＢ−ＧＷ送受信部３１Ｂと、ＲＡＮＡＰ機能部３２Ｂと、Ｉｕ−ＵＰフレーム制御部３３Ｂと、Ｉｕ−ＵＰフレーム転送部３４Ｂと、を有する。なお、図４において、対ＨＮＢ−ＧＷ送受信部３１Ｂが図２の送受信部３１Ａを構成し、その他の機能ブロックが図２の制御部３２Ａを構成する。

対ＨＮＢ送受信部４１Ｂは、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３と接続するためのインタフェースを有し、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３との間で音声データの送受信を行う。

ＲＡＮＡＰ機能部２２Ｂ，３２Ｂ，４２Ｂは、３ＧＰＰ ＴＳ２５．４１３（非特許文献３）で規定されるＲＡＮＡＰ（Radio Access Network Application Part）プロトコル機能を実現する。例えば、ＲＡＮＡＰ機能部２２Ｂ，３２Ｂ，４２Ｂは、ＲＡＮＡＰメッセージを生成する機能と、ＲＡＮＡＰメッセージを終端する機能と、を有する。

対ＣＮ送受信部４３Ｂは、ＣＮノード５と接続するためのインタフェースを有し、ＣＮノード５の間で音声データの送受信を行う。

Ｉｕ−ＵＰフレーム制御部２３Ｂ，３３Ｂ，４４Ｂは、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）で規定されるＩｕ−ＵＰプロトコル機能を実現する。例えば、Ｉｕ−ＵＰフレーム制御部２３Ｂ，３３Ｂ，４４Ｂは、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎメッセージ（以下、Ｉｕ−ＵＰ Ｉｎｉｔメッセージと略す）を生成する機能と、Ｉｕ−ＵＰ Ｉｎｉｔメッセージを終端する機能と、を有する。それに加えて、Ｉｕ−ＵＰフレーム制御部４４Ｂは、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれるＲＦＣＩ情報をＲＦＣＩ保持部４６Ｂへ通知する機能と、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動が生じた場合に、ＲＦＣＩ保持部４６ＢへＲＦＣＩ情報の比較要求をする機能と、を有する。

Ｉｕ−ＵＰフレーム転送部２４Ｂ，３４Ｂ，４５Ｂは、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）で規定されるＩｕ−ＵＰプロトコル機能を実現する。例えば、Ｉｕ−ＵＰフレーム転送部２４Ｂ，３４Ｂ，４５Ｂは、Ｉｕ−ＵＰフレームデータを転送する機能を有する。

ＲＦＣＩ保持部４６Ｂは、Ｉｕ−ＵＰフレーム制御部４４Ｂから通知されたＲＦＣＩ情報を保持する機能と、Ｉｕ−ＵＰフレーム制御部４４ＢからのＲＦＣＩ情報の比較要求に基づいて比較結果を通知する機能と、を有する。

対ＨＮＢ−ＧＷ送受信部２１Ｂ，３１Ｂは、ＨＮＢ−ＧＷ４と接続するためのインタフェースを有し、ＨＮＢ−ＧＷ４との間で音声データの送受信を行う。

ここで、本実施形態に関連する３ＧＰＰの現状の２つの規定について説明する。
（１）第１の規定
３ＧＰＰ ＴＳ２５．４１５（非特許文献２）では、ＵＥとＣＮ間の無線アクセスベアラ（ＲＡＢ：Radio Access Bearer）に関するＲＡＢパラメータを、ＣＮとＲＮＣ（ＨＮＢ−ＧＷ）間でＲＡＮＡＰメッセージにより通知することが規定されている。具体的には、ＲＡＢパラメータは、サービスの種類に応じたＱｏＳ（Quality of Service）のパラメータ（データ伝送レート、ブロックサイズ、エラー率など）である。

しかし、ＲＡＢパラメータは、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎメッセージによりやり取りされるＲＦＣＩ情報と密接に関係しており、ＲＡＢパラメータの変更（ＲＡＢ Ｍｏｄｉｆｉａｔｉｏｎ）を伴わず、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動によりＲＦＣＩ情報のみを変更した場合、状態の不整合が生じる恐れがある。

そのため、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）では、そのような手続きが発生しないようにするため、ＲＡＢ Ｍｏｄｉｆｉａｔｉｏｎを除いて、同一ＳＲＮＳからのＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動を行ってはならないと規定している（第１の規定）。

もし、既存のＮｏｄｅ−Ｂ／ＲＮＣ／ＣＮで構成される移動通信システムにおける、Ｉｕ−ＵＰ ＩｎｉｔｉａｌｉｚａｔｉｏｎメッセージによりＲＦＣＩ情報の引継ぎを行う機能を、ＨＮＢ／ＨＮＢ−ＧＷ／ＣＮで構成される移動通信システムに適用した場合、図１において、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３の各々からＣＮ６に対してＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎを起動することになる。しかし、この場合、ＣＮ６から見と、同一ＳＲＮＳ（ＨＮＢ−ＧＷ４）によりＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動を行ったことになるため、第１の規定に違反する。
（２）第２の規定
上記第１の規定の問題は、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎメッセージを、ＨＮＢ−ＧＷで終端する（すなわち、ＣＮで終端しない）ことで、解決することができると考えられる。

しかし、３ＧＰＰ ＴＳ２５．４６７（非特許文献４）では、ＨＮＢ−ＧＷでＩｕ−ＵＰメッセージを終端した場合、ＨＮＢ−ＧＷでの信号処理の増加や処理の複雑化が懸念されるため、Ｉｕ−ＵＰプロトコルのメッセージはＨＮＢ−ＧＷにて終端しないと規定されている（第２の規定）。そのため、Ｉｕ−ＵＰ ＩｎｉｔｉａｌｉｚａｔｉｏｎメッセージをＨＮＢ−ＧＷで終端した場合、第２の規定に違反する。

本実施形態では、上記の第１の規定および第２の規定を変更することなく、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時に、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことを可能にするものである。

以下、本実施形態の動作について、図５に示すシーケンス図に沿って説明をする。

まず、ＨＮＢ−Ｓ２は、ステップＳ２０１において、ＨＮＢ−Ｓ２からのＵＥ１の移動を要求するＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＨＮＢ−ＧＷ４へ送信することにより、Ｒｅｌｏｃａｔｉｏｎ手順を開始する。

本実施形態では、３ＧＰＰ ＴＳ２５．４１３（非特許文献３）の９．１．９のＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージにおいて、Ｉｕ−ＵＰ ＩｎｉｔメッセージのＲＦＣＩ情報を追加する。図６に、本実施形態により変更されたＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージを示す。なお、図６は、変更された箇所のみを示している。本実施形態のＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージには、ＲＦＣＩ値である“ＲＦＣＩ”と、そのＲＦＣＩ値が示すデータフレームを構成するサブフロー数である“ＲＣＦＩ Ｓｕｂｆｌｏｗ”と、サブフロー毎のデータサイズである“Ｌｅｎｇｔｈ ｏｆ Ｓｕｂｆｌｏｗ”と、がＲＦＣＩ情報として追加されている。

ＨＮＢ−ＧＷ４は、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＲＡＮＡＰ機能部４２Ｂにて終端し、ＲＦＣＩ情報を取得する。

さらに、ＨＮＢ−ＧＷ４は、ステップＳ２０２において、ＨＮＢ−Ｔ３へのＵＥ１の移動を要求するＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＮＢ−Ｔ３へ送信することにより、ＨＮＢ−Ｔ３のリソースの確保を要求する。

本実施形態では、ステップＳ２０１にて、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージにＲＦＣＩ情報が含まれていた場合、ＲＡＮＡＰ機能部４２Ｂは、ＲＦＣＩ情報を取得し、そのＲＦＣＩ情報をＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含める。

すなわち、本実施形態では、３ＧＰＰ ＴＳ２５．４１３（非特許文献３）の９．１．１０のＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージにおいて、ＲＦＣＩ情報を追加する。図７に、本実施形態により変更されたＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを示す。なお、図７は、変更された箇所のみを示している。本実施形態のＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージには、図６のＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージと同様に、ＲＦＣＩ値である“ＲＦＣＩ”と、そのＲＦＣＩ値が示すデータフレームを構成するサブフロー数である“ＲＣＦＩ Ｓｕｂｆｌｏｗ”と、サブフロー毎のデータサイズである“Ｌｅｎｇｔｈ ｏｆ Ｓｕｂｆｌｏｗ”と、がＲＦＣＩ情報として追加されている。

ＨＮＢ−Ｔ３は、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＲＡＮＡＰ機能部３２Ｂにて終端する。もし、そのＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージにＲＦＣＩ情報が含まれていた場合、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報を初期化し、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含まれるＲＦＣＩ情報に再設定する。

これにより、ＨＮＢ−Ｔ３は、以降、ＵＥ１からの上りの音声データおよびＣＮ６からの下りの音声データを受信した場合、その音声データに付加されているＲＦＣＩ値によって、その音声データのデータフレームの構造、さらにはレートを正しく認識することができる。

さらに、本実施形態では、ＨＮＢ−Ｔ３の状態遷移に関する、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）のＩｕ−ＵＰ Ｐｒｏｔｏｃｏｌの状態遷移図において、“ＮＵＬＬ”状態から直接“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ”状態に遷移する条件を追加する。図８に、本実施形態により変更されたＩｕ−ＵＰ Ｐｒｏｔｏｃｏｌ状態遷移図のイメージを示す。図８は、ＲＦＣＩ情報を含むＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ（図８では、Ｉｎｔｒａ−ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ−Ｒｅｑとしている）を受信した際に、“ＮＵＬＬ”状態から直接“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ”状態に遷移することを意味する。

これにより、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｔ３は、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを受信すると、これをトリガーにして、Ｉｕ−ＵＰフレーム転送部３３Ｂの状態を、“ＮＵＬＬ”状態から、“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ“状態に遷移させ、Ｉｕ−ＵＰフレームデータを転送可能な状態になる。

なお、本実施形態では、“ＮＵＬＬ”状態から“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ”状態へ遷移させる信号名を、Ｉｎｔｒａ−ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ−Ｒｅｑとしたが、信号名はこれに限定されない。

以下のステップＳ２０３〜Ｓ２１１は、ＨＮＢ／ＨＮＢ−ＧＷ／ＣＮで構成される移動通信システムにおいて、現在検討されているＩｎｔｒａ ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ手順の検討案の１つとしてよく知られており、本発明とは直接関係しない。

ステップＳ２０２の実行後、ＨＮＢ−Ｔ３は、ステップＳ２０３において、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫメッセージをＨＮＢ−ＧＷ４へ送信することにより、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに対する応答を行う。

次に、ＨＮＢ−ＧＷ４は、ステップＳ２０４において、Ｒｅｌｏｃａｔｉｏｎ ｃｏｍｍａｎｄメッセージをＨＮＢ−Ｓ２へ送信することにより、Ｒｅｌｏｃａｔｉｏｎの開始を指示する。

次に、ＨＮＢ−Ｓ２は、ステップＳ２０５において、ＲＲＣ：ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１へ送信することにより、無線チャネルの再構成を指示する。

次に、ＨＮＢ−Ｔ３は、ステップＳ２０６において、無線Ｌａｙｅｒ１での同期により、ＵＥ１を検出し、Ｒｅｌｏｃａｔｉｏｎ ＤｅｔｅｃｔメッセージをＨＮＢ−ＧＷ４へ送信することにより、ＵＥ１を検出したことを通知する。

次に、ＵＥ１は、ステップＳ２０７において、ＲＲＣ：Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ＣｏｍｐｌｅｔｅメッセージをＨＮＢ−Ｔ３へ送信することにより、無線リソースの割り当てが完了したことを通知する。

次に、ＨＮＢ−Ｔ３は、ステップＳ２０８において、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＣｏｍｐｌｅｔｅメッセージをＨＮＢ−ＧＷ４へ送信することにより、Ｒｅｌｏｃａｔｉｏｎが完了したことを通知する。

次に、ＨＮＢ−ＧＷ４は、ステップＳ２０９において、ＲＡＮＡＰ：Ｉｕ Ｒｅｌｅａｓｅ ＣｏｍｍａｎｄメッセージをＨＮＢ−Ｓ２へ送信することにより、ＨＮＢ−Ｓ２のリソースの解放を要求する。

次に、ＨＮＢ−Ｓ２は、ステップＳ２１０において、ＲＡＮＡＰ：Ｉｕ Ｒｅｌｅａｓｅ ＣｏｍｐｌｅｔｅメッセージをＨＮＢ−ＧＷ４へ送信することにより、ＨＮＢ−Ｓ２のリソースが解放されたことを通知する。

その後、ＵＥ１は、ステップＳ２１１において、ＨＮＢ−Ｔ３を介してＨＮＢ−ＧＷ４と音声データ（ユーザデータ）の送受信を行う。

上述したように本実施形態では、ＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージによりＨＮＢ−ＧＷ４に通知し、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージによりＨＮＢ−Ｔ３に通知するため、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぐことが可能になる。

また、ＨＮＢ−Ｔ３は、ＨＮＢ−ＧＷ４からのＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの受信をトリガーにして、音声データを転送可能な状態に遷移するため、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、音声データを送信することが可能になる。

したがって、ＨＮＢ−Ｔ３は、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぎ、音声データを送信することが可能になるため、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

また、本実施形態では、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行する必要がないため、３ＧＰＰにおいて、同一ＳＲＮＳ（ＨＮＢ−ＧＷ４）からのＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動を許容しない第１の規定を変更する必要がない。

また、本実施形態では、Ｉｕ−ＵＰ ＩｎｉｔｉａｌｉｚａｔｉｏｎメッセージをＨＮＢ−ＧＷで終端する必要がないため、３ＧＰＰにおいて、Ｉｕ−ＵＰプロトコルのメッセージがＨＮＢ−ＧＷにて終端することを許容しない第２の規定も変更する必要がない。

また、本実施形態では、ＲＦＣＩ情報の通知に、ＲＡＮＡＰメッセージを用いるため、次のようなメリットも得られる。
（１）第１のメリット
ＲＡＮＡＰメッセージは、ＨＮＢおよびＨＮＢ−ＧＷにて終端することが３ＧＰＰ ＴＳ ２５．４６７（非特許文献４）に規定されている。そのため、ＲＡＮＡＰメッセージに本実施形態に関する機能を追加する上で、新規にプロトコルを追加でサポートする必要がないというメリットがある。
（２）第２のメリット
現在、３ＧＰＰでは、Ｉｎｔｒａ ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ手順が検討されているが、本手順の信号にＲＡＮＡＰメッセージを使用することが一般的である。そのため、ＲＡＮＡＰメッセージに本実施形態に関する機能を追加することで、Ｉｎｔｒａ ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ手順に新たな信号を追加する必要がないというメリットがある。
（第３の実施形態）
本実施形態は、上位装置９をＨＮＢ−ＧＷ４として、第１の実施形態をより具体化した例である。

本実施形態では、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＲＡＮＡＰ Ｕｓｅｒ Ａｄａｐｔｉｏｎ（以下、ＲＵＡと略す）のＤｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージにより、ＨＮＢ−Ｓ２からＨＮＢ−ＧＷ４を介してＨＮＢ−Ｔ３に通知する。

なお、ＲＵＡは、３ＧＰＰ ＴＳ ２５．４６８（非特許文献５）で定義される。また、ＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージは、ＲＡＮＡＰメッセージを転送するために使用されるメッセージである。

図９を参照すると、本実施形態のＨＮＢ−ＧＷ４は、図４に示した第２の実施形態のＨＮＢ−ＧＷ４と比較して、ＲＵＡ機能部４７Ｂを追加した点が異なる。なお、ＲＵＡ機能部４７Ｂは、図２の制御部９２Ａを構成する構成要素の１つとなる。

また、本実施形態のＨＮＢ−Ｓ２は、図４に示した第２の実施形態のＨＮＢ−Ｓ２と比較して、ＲＵＡ機能部２５Ｂを追加した点が異なる。なお、ＲＵＡ機能部２５Ｂは、図２の制御部２１Ａを構成する構成要素の１つとなる。

また、本実施形態のＨＮＢ−Ｔ３は、図４に示した第２の実施形態のＨＮＢ−Ｔ３と比較して、ＲＵＡ機能部３５Ｂを追加した点が異なる。なお、ＲＵＡ機能部３５Ｂは、図２の制御部３２Ａを構成する構成要素の１つとなる。

ＲＵＡ機能部２５Ｂ，３５Ｂ，４７Ｂは、３ＧＰＰ ＴＳ ２５．４６８（非特許文献５）で規定されるＲＵＡプロトコル機能を実現する。例えば、ＲＵＡ機能部２５Ｂ，３５Ｂ，４７Ｂは、ＲＵＡメッセージを生成する機能と、ＲＵＡメッセージを終端する機能と、を有する。

以下、本実施形態の動作について、図１０に示すシーケンス図に沿って説明をする。

まず、ＨＮＢ−Ｓ２は、ステップＳ３０１において、ＨＮＢ−Ｓ２からのＵＥ１の移動を要求するＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＨＮＢ−ＧＷ４へ送信することにより、Ｒｅｌｏｃａｔｉｏｎ手順を開始する。

本実施形態では、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージの送信時に、このＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージを転送するためのＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージを併せて送信する。

さらに、本実施形態では、３ＧＰＰ ＴＳ ２５．４６８（非特許文献５）の９．１．４のＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージにおいて、Ｉｕ−ＵＰ ＩｎｉｔメッセージのＲＦＣＩ情報を追加する。図１１に、本実施形態により変更されたＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージを示す。なお、図１１は、変更された箇所のみを示している。本実施形態のＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージには、ＲＦＣＩ値である“ＲＦＣＩ”と、そのＲＦＣＩ値が示すデータフレームを構成するサブフロー数である“ＲＣＦＩ Ｓｕｂｆｌｏｗ”と、サブフロー毎のデータサイズである“Ｌｅｎｇｔｈ ｏｆ Ｓｕｂｆｌｏｗ”と、がＲＦＣＩ情報として追加されている。

ＨＮＢ−ＧＷ４は、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＲＡＮＡＰ機能部４２Ｂにて終端するとともに、ＲＵＡ Ｄｉｒｅｃｔ ＴｒａｎｓｆｅｒメッセージをＲＵＡ機能部４７Ｂにて終端し、ＲＦＣＩ情報を取得する。

さらに、ＨＮＢ−ＧＷ４は、ステップＳ３０２において、ＨＮＢ−Ｔ３へのＵＥ１の移動を要求するＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＮＢ−Ｔ３へ送信することにより、ＨＮＢ−Ｔ３のリソースの確保を要求する。

本実施形態では、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの送信時に、このＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを転送するためのＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージを併せて送信する。

さらに、本実施形態では、ステップＳ３０１にて、ＲＵＡ Ｄｉｒｅｃｔ ＴｒａｎｓｆｅｒメッセージにＲＦＣＩ情報が含まれていた場合、ＲＵＡ機能部４７Ｂは、ＲＦＣＩ情報を取得し、そのＲＦＣＩ情報をＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージに含める。このときのＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージは、図１１に示したものと同様である。

ＨＮＢ−Ｔ３は、ＲＡＮＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＲＡＮＡＰ機能部３２Ｂにて終端するとともに、ＲＵＡ Ｄｉｒｅｃｔ ＴｒａｎｓｆｅｒメッセージをＲＵＡ機能部３５Ｂにて終端する。もし、そのＲＵＡ Ｄｉｒｅｃｔ ＴｒａｎｓｆｅｒメッセージにＲＦＣＩ情報が含まれていた場合、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報を初期化し、ＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージに含まれるＲＦＣＩ情報に再設定する。

これにより、ＨＮＢ−Ｔ３は、以降、ＵＥ１からの上りの音声データおよびＣＮ６からの下りの音声データを受信した場合、その音声データに付加されているＲＦＣＩ値によって、その音声データのデータフレームの構造、さらにはレートを正しく認識することができる。

さらに、本実施形態では、ＨＮＢ−Ｔ３の状態遷移に関する、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）のＩｕ−ＵＰ Ｐｒｏｔｏｃｏｌの状態遷移図（図８参照）において、“ＮＵＬＬ”状態から直接“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ”状態に遷移する条件として、ＲＦＣＩ情報を含むＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージ（図８では、Ｉｎｔｒａ−ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ−Ｒｅｑとしている）を受信するという条件を追加する。

これにより、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｔ３は、ＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージの受信をトリガーにして、Ｉｕ−ＵＰフレーム転送部３３Ｂの状態を、“ＮＵＬＬ”状態から、“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ“状態に遷移させ、Ｉｕ−ＵＰフレームデータを転送可能な状態になる。

以降のステップＳ３０３〜Ｓ３１１の処理は、図５のステップＳ２０３〜Ｓ２１１の処理と同様である。

上述したように本実施形態では、ＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＲＵＡ Ｄｉｒｅｃｔ ＴｒａｎｓｆｅｒメッセージによりＨＮＢ−ＧＷ４に通知し、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＲＵＡ Ｄｉｒｅｃｔ ＴｒａｎｓｆｅｒメッセージによりＨＮＢ−Ｔ３に通知するため、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぐことが可能になる。

また、ＨＮＢ−Ｔ３は、ＨＮＢ−ＧＷ４からのＲＵＡ Ｄｉｒｅｃｔ Ｔｒａｎｓｆｅｒメッセージの受信をトリガーにして、音声データを転送可能な状態に遷移するため、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、音声データを送信することが可能になる。

したがって、ＨＮＢ−Ｔ３は、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぎ、音声データを送信することが可能になるため、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

また、本実施形態では、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行する必要がないため、３ＧＰＰにおいて、同一ＳＲＮＳ（ＨＮＢ−ＧＷ４）からのＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動を許容しない第１の規定を変更する必要がない。

また、本実施形態では、Ｉｕ−ＵＰ ＩｎｉｔｉａｌｉｚａｔｉｏｎメッセージをＨＮＢ−ＧＷで終端する必要がないため、３ＧＰＰにおいて、Ｉｕ−ＵＰプロトコルのメッセージがＨＮＢ−ＧＷにて終端することを許容しない第２の規定も変更する必要がない。
（第４の実施形態）
本実施形態は、上位装置９をＨＮＢ−ＧＷ４として、第１の実施形態をより具体化した例である。

本実施形態では、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、Ｈｏｍｅ Ｎｏｄｅ Ｂ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ（以下、ＨＮＢＡＰと略す）のＲｅｌｏｃａｔｉｏｎメッセージにより、ＨＮＢ−Ｓ２からＨＮＢ−ＧＷ４を介してＨＮＢ−Ｔ３に通知する。

なお、ＨＮＢＡＰは、３ＧＰＰ ＴＳ ２５．４６９（非特許文献６）で定義される。ただし、ＨＮＢＡＰ Ｒｅｌｏｃａｔｉｏｎメッセージは、３ＧＰＰで規定されておらず、現在検討されているＩｎｔｒａ ＨＮＢ−ＧＷリロケーション手順において、検討案の１つとしてよく知られており、本発明とは直接関係しない。

図１２を参照すると、本実施形態のＨＮＢ−ＧＷ４は、図４に示した第２の実施形態のＨＮＢ−ＧＷ４と比較して、ＨＮＢＡＰ機能部４８Ｂを追加した点が異なる。なお、ＨＮＢＡＰ機能部４８Ｂは、図２の制御部９２Ａを構成する構成要素の１つとなる。

また、本実施形態のＨＮＢ−Ｓ２は、図４に示した第２の実施形態のＨＮＢ−Ｓ２と比較して、ＨＮＢＡＰ機能部２６Ｂを追加した点が異なる。なお、ＨＮＢＡＰ機能部２６Ｂは、図２の制御部２１Ａを構成する構成要素の１つとなる。

また、本実施形態のＨＮＢ−Ｔ３は、図４に示した第２の実施形態のＨＮＢ−Ｔ３と比較して、ＨＮＢＡＰ機能部３６Ｂを追加した点が異なる。なお、ＨＮＢＡＰ機能部３６Ｂは、図２の制御部３２Ａを構成する構成要素の１つとなる。

ＨＮＢＡＰ機能部２６Ｂ，３６Ｂ，４８Ｂは、３ＧＰＰ ＴＳ ２５．４６９（非特許文献６）で規定されるＨＮＢＡＰプロトコル機能を実現する。例えば、ＨＮＢＡＰ機能部２６Ｂ，３６Ｂ，４８Ｂは、ＨＮＢＡＰメッセージを生成する機能と、ＨＮＢＡＰメッセージを終端する機能と、を有する。

以下、本実施形態の動作について、図１３に示すシーケンス図に沿って説明をする。

まず、ＨＮＢ−Ｓ２は、ステップＳ４０１において、ＨＮＢ−Ｓ２からのＵＥ１の移動を要求するＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＨＮＢ−ＧＷ４へ送信することにより、Ｒｅｌｏｃａｔｉｏｎ手順を開始する。

本実施形態では、このＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄメッセージにおいて、Ｉｕ−ＵＰ ＩｎｉｔメッセージのＲＦＣＩ情報を追加する。このときのＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄには、例えば、図１１と同様に、ＲＦＣＩ情報を追加することができる。

ＨＮＢ−ＧＷ４は、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＨＮＢＡＰ機能部４８Ｂにて終端し、ＲＦＣＩ情報を取得する。

さらに、ＨＮＢ−ＧＷ４は、ステップＳ４０２において、ＨＮＢ−Ｔ３へのＵＥ１の移動を要求するＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＮＢ−Ｔ３へ送信することにより、ＨＮＢ−Ｔ３のリソースの確保を要求する。

本実施形態では、ステップＳ４０１にて、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージにＲＦＣＩ情報が含まれていた場合、ＨＮＢＡＰ機能部４８Ｂは、ＲＦＣＩ情報を取得し、そのＲＦＣＩ情報をＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含める。このときのＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージには、例えば、図１１と同様に、ＲＦＣＩ情報を追加することができる。

ＨＮＢ−Ｔ３は、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＮＢＡＰ機能部３６Ｂにて終端する。もし、そのＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージにＲＦＣＩ情報が含まれていた場合、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報を初期化し、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含まれるＲＦＣＩ情報に再設定する。

これにより、ＨＮＢ−Ｔ３は、以降、ＵＥ１からの上りの音声データおよびＣＮ６からの下りの音声データを受信した場合、その音声データに付加されているＲＦＣＩ値によって、その音声データのデータフレームの構造、さらにはレートを正しく認識することができる。

さらに、本実施形態では、ＨＮＢ−Ｔ３の状態遷移に関する、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）のＩｕ−ＵＰ Ｐｒｏｔｏｃｏｌの状態遷移図（図８参照）において、“ＮＵＬＬ”状態から直接“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ”状態に遷移する条件として、ＲＦＣＩ情報を含むＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ（図８では、Ｉｎｔｒａ−ＨＮＢ−ＧＷ Ｒｅｌｏｃａｔｉｏｎ−Ｒｅｑとしている）を受信するという条件を追加する。

これにより、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｔ３は、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの受信をトリガーにして、Ｉｕ−ＵＰフレーム転送部３３Ｂの状態を、“ＮＵＬＬ”状態から、“Ｓｕｐｐｏｒｔ Ｍｏｄｅ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ“状態に遷移させ、Ｉｕ−ＵＰフレームデータを転送可能な状態になる。

以降のステップＳ４０３〜Ｓ４１１の処理は、図５のステップＳ２０３〜Ｓ２１１の処理と同様である。

上述したように本実施形態では、ＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージによりＨＮＢ−ＧＷ４に通知し、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、ＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージによりＨＮＢ−Ｔ３に通知するため、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぐことが可能になる。

また、ＨＮＢ−Ｔ３は、ＨＮＢ−ＧＷ４からのＨＮＢＡＰ：Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの受信をトリガーにして、音声データを転送可能な状態に遷移するため、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、音声データを送信することが可能になる。

したがって、ＨＮＢ−Ｔ３は、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行しなくとも、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぎ、音声データを送信することが可能になるため、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

また、本実施形態では、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順を実行する必要がないため、３ＧＰＰにおいて、同一ＳＲＮＳ（ＨＮＢ−ＧＷ４）からのＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動を許容しない第１の規定を変更する必要がない。

また、本実施形態では、Ｉｕ−ＵＰ ＩｎｉｔｉａｌｉｚａｔｉｏｎメッセージをＨＮＢ−ＧＷで終端する必要がないため、３ＧＰＰにおいて、Ｉｕ−ＵＰプロトコルのメッセージがＨＮＢ−ＧＷにて終端することを許容しない第２の規定も変更する必要がない。
（第５の実施形態）
本実施形態は、上位装置９をＨＮＢ−ＧＷ４として、第１の実施形態をより具体化した例である。また、本実施形態の構成は、図４に示した第２の実施形態の構成と同様である。

本実施形態では、ＨＮＢ−ＧＷ４が、ＵＥ１のＨＮＢ−Ｓ２からＨＮＢ−Ｔ３へのＲｅｌｏｃａｔｉｏｎ処理時に、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、Ｉｕ−ＵＰ Ｉｎｉｔメッセージにより、ＨＮＢ−Ｔ３に通知する。なお、Ｉｕ−ＵＰ Ｉｎｉｔメッセージは、ＨＮＢが、Ｒｅｌｏｃａｔｉｏｎの発生時など、ＵＥの通信相手の端末を配下に持つＨＮＢとの通信を確立しようとする時に、ＨＮＢとＨＮＢ−ＧＷとの間で送受信されるメッセージである。

３ＧＰＰ ＴＳ２５．４１５（非特許文献２）のＩｕ−ＵＰ Ｖｅｒ２では、Ｉｕ−ＵＰ ＩｎｉｔメッセージをＣＮからＲＮＣへ送信することが規定されている。しかし、この規定は、３ＧＰＰの既存のＮｏｄｅ−Ｂ／ＲＮＣ／ＣＮで構成される移動通信システムを前提としている。

そのため、ＨＮＢ／ＨＮＢ−ＧＷ／ＣＮで構成される移動通信システムにおいても、Ｉｕ−ＵＰ ＩｎｉｔメッセージをＣＮからＨＮＢ−ＧＷへ送信できるようにする必要があるが、３ＧＰＰ ＴＳ２５．４６７（非特許文献４）では、Ｉｕ−ＵＰプロトコルのメッセージはＨＮＢ−ＧＷにて終端しないと規定されている。

そこで、本実施形態では、３ＧＰＰの規定を変更し、Ｉｕ−ＵＰメッセージをＨＮＢ−ＧＷで終端することを許容する。

以下、本実施形態の動作について、図１４に示すシーケンス図に沿って説明をする。

なお、図１４においては、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を予め取得しているものとする。すなわち、ＨＮＢ−Ｓ２とＨＮＢ−Ｘ８との間で通信を確立する際に、ＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４へ送信しており、これにより、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を取得している。この手順は、図１４のステップＳ５０１以前に実施されており、図１４には記載されていない。

まず、図５のステップＳ２０１，Ｓ２０２の処理と同様のステップＳ５０１，Ｓ５０２の処理が行われる。

次に、ＨＮＢ−Ｔ３は、ステップＳ５０３において、ＨＮＢ−Ｔ３のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４へ送信する。ＨＮＢ−ＧＷ４は、Ｉｕ−ＵＰフレーム制御部４４ＢにてＩｕ−ＵＰ Ｉｎｉｔメッセージを終端し、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれるＨＮＢ−Ｔ３のＲＦＣＩ情報と、予め取得していたＨＮＢ−Ｓ２のＲＦＣＩ情報との比較を行う。

次に、ＨＮＢ−ＧＷ４は、ステップＳ５０４において、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージをＨＮＢ−Ｔ３へ送信することにより、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに対する応答を行う。

ステップＳ５０３において、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３のＲＦＣＩ情報が不一致であれば、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｔ３のＲＦＣＩ情報をＨＮＢ−Ｓ２のＲＦＣＩ情報と一致させるため、ステップＳ５０５において、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−Ｔ３へ送信する。

次に、ＨＮＢ−Ｔ３は、ステップＳ５０６において、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージをＨＮＢ−ＧＷ４へ送信することにより、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに対する応答を行う。また、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報を初期化し、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれるＨＮＢ−Ｓ２のＲＦＣＩ情報に再設定する。

以降のステップＳ５０７〜Ｓ５１５の処理は、図５のステップＳ２０３〜Ｓ２１１の処理と同様である。

上述したように本実施形態では、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、Ｉｕ−ＵＰ ＩｎｉｔメッセージによりＨＮＢ−Ｔ３に通知するため、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぐことが可能になる。

したがって、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

また、本実施形態により変更される、３ＧＰＰ ＴＳ２５．４６７（非特許文献４）の７．２における記述は、次の通りになる。

Ｉｕ−ＵＰは、ＣＮ、ＨＮＢ、およびＨＮＢ−ＧＷでのみ終端する。

また、本実施形態により変更される、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）の６．５．２におけるＩｕ−ＵＰ Ｖｅｒ２の記述は、次の通りになる。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、２つのＩｕアクセスポイント、すなわちＣＮとＵＴＲＡＮの双方にて制御可能である。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、Ｉｕ−ＵＰ手順の制御機能によって示される時、すなわちＳＲＮＳのリロケーションまたはＩｕ上でのＲＡＢ確立が行われる時や、ＣＮまたはＨＮＢ−ＧＷがＴｒＦＯを行っている状況でＲＦＣＩの不一致を解決しようとする場合に、起動される。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、ＲＡＮＡＰによるＲＡＢ Ｍｏｄｉｆｉａｔｉｏｎの要求をすることなく、ＲＡＢのためにＳＲＮＣにより再起動することはできない。

なお、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）のＩｕ−ＵＰ Ｖｅｒ１においては、Ｉｕ−ＵＰ ＩｎｉｔメッセージをＲＮＣからＣＮへ送信することは規定されているものの、Ｉｕ−ＵＰ ＩｎｉｔメッセージをＣＮからＲＮＣへ送信することは、規定されていない。そこで、Ｉｕ−ＵＰ Ｖｅｒ１についても、Ｉｕ−ＵＰ Ｖｅｒ２と同様に規定を改めてもよい。

この場合に、本実施形態により変更される、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）の６．５．２におけるＩｕ−ＵＰ Ｖｅｒ１の記述は、次の通りになる。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、２つのＩｕアクセスポイント、すなわちＣＮとＵＴＲＡＮの双方にて制御可能である。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、Ｉｕ−ＵＰ手順の制御機能によって示される時、すなわちＳＲＮＳのリロケーションまたはＩｕ上でのＲＡＢ確立が行われる時や、ＣＮまたはＨＮＢ−ＧＷがＴｒＦＯを行っている状況でＲＦＣＩの不一致を解決しようとする場合に、起動される。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、ＲＡＮＡＰによるＲＡＢ Ｍｏｄｉｆｉａｔｉｏｎの要求をすることなく、ＲＡＢのためにＳＲＮＣにより再起動することはできない。
（第６の実施形態）
本実施形態は、上位装置９をＣＮノード５として、第１の実施形態をより具体化した例である。

本実施形態では、ＣＮノード５が、ＵＥ１のＨＮＢ−Ｓ２からＨＮＢ−Ｔ３へのＲｅｌｏｃａｔｉｏｎ処理時に、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、Ｉｕ−ＵＰ Ｉｎｉｔメッセージにより、ＨＮＢ−Ｔ３に通知する。

すなわち、本実施形態は、ＣＮノード５が、第３の実施形態でＨＮＢ−ＧＷ４が行っていた動作を行い、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２／ＨＮＢ−Ｔ３とＣＮノード５との間でやりとりされる、ＲＡＮＡＰメッセージおよびＩｕ−ＵＰ Ｉｎｉｔメッセージを終端せずに、転送のみを行う。

しかし、現在の３ＧＰＰ ＴＳ２５．４１５（非特許文献２）では、Ｉｎｔｒａ ＨＮＢ−ＧＷリロケーション発生時のＩｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動は許容しないと規定されている。

そこで、本実施形態では、３ＧＰＰの規定を変更し、Ｉｎｔｒａ ＨＮＢ−ＧＷリロケーションが発生した場合においても、Ｉｕ−ＵＰ Ｉｎｉｔｉａｌｉｚａｔｉｏｎの再起動を許容する。

図１５を参照すると、本実施形態のＣＮノード５は、ＨＮＢ−ＧＷ４向けの対ＨＮＢ−ＧＷ送受信部５１Ｃと、ＲＡＮＡＰ機能部５２Ｃと、ＨＮＢ−ＧＷ７向けの対ＨＮＢ−ＧＷ送受信部５３Ｃと、Ｉｕ−ＵＰフレーム制御部５４Ｃと、Ｉｕ−ＵＰフレーム転送部５５Ｃと、ＲＦＣＩ保持部５６Ｃと、を有する。なお、図１５において、対ＨＮＢ−ＧＷ送受信部５１Ｃが図２の送受信部９１Ａを構成し、その他の機能ブロックが図２の制御部９２Ａを構成する。

なお、本実施形態のＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３の構成は、図４に示した第２の実施形態のＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３の構成と同様である。

対ＨＮＢ−ＧＷ送受信部５１Ｃは、ＨＮＢ−ＧＷ４と接続するためのインタフェースを有し、ＨＮＢ−ＧＷ４との間で音声データの送受信を行う。

対ＨＮＢ−ＧＷ送受信部５３Ｃは、ＨＮＢ−ＧＷ７と接続するためのインタフェースを有し、ＨＮＢ−ＧＷ７との間で音声データの送受信を行う。

なお、その他のＲＡＮＡＰ機能部５２Ｃ、Ｉｕ−ＵＰフレーム制御部５４Ｃ、Ｉｕ−ＵＰフレーム転送部５５Ｃ、およびＲＦＣＩ保持部５６Ｃは、それぞれ、図４に示したＲＡＮＡＰ機能部４２Ｂ、Ｉｕ−ＵＰフレーム制御部４４Ｂ、Ｉｕ−ＵＰフレーム転送部４５Ｂ、およびＲＦＣＩ保持部４６Ｂと同様の動作を行う。

以下、本実施形態の動作について、図１６に示すシーケンス図に沿って説明をする。

なお、図１６においては、ＣＮノード５は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を予め取得しているものとする。すなわち、ＨＮＢ−Ｓ２とＨＮＢ−Ｘ８との間で通信を確立する際に、ＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４を介してＣＮノード５へ送信しており、これにより、ＣＮノード５は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を取得している。この手順は、図１６のステップＳ６０１以前に実施されており、図１６には記載されていない。

まず、図５のステップＳ２０１，Ｓ２０２において、ＨＮＢ−Ｓ２、ＨＮＢ−Ｔ３、およびＨＮＢ−ＧＷ４により行われていた処理と同様の処理が、ステップＳ６０１，Ｓ６０２において、ＨＮＢ−Ｓ２、ＨＮＢ−Ｔ３、およびＣＮノード５により行われる。

次に、ＨＮＢ−Ｔ３は、ステップＳ６０３において、ＨＮＢ−Ｔ３のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４を介してＣＮノード５へ送信する。ＣＮノード５は、Ｉｕ−ＵＰフレーム制御部５４ＣにてＩｕ−ＵＰ Ｉｎｉｔメッセージを終端し、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれるＨＮＢ−Ｔ３のＲＦＣＩ情報と、予め取得していたＨＮＢ−Ｓ２のＲＦＣＩ情報との比較を行う。

次に、ＣＮノード５は、ステップＳ６０４において、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージをＨＮＢ−ＧＷ４を介してＨＮＢ−Ｔ３へ送信することにより、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに対する応答を行う。

ステップＳ６０３において、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３のＲＦＣＩ情報が不一致であれば、ＣＮノード５は、ＨＮＢ−Ｔ３のＲＦＣＩ情報をＨＮＢ−Ｓ２のＲＦＣＩ情報と一致させるため、ステップＳ６０５において、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４を介してＨＮＢ−Ｔ３へ送信する。

次に、ＨＮＢ−Ｔ３は、ステップＳ６０６において、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージをＨＮＢ−ＧＷ４を介してＣＮノード５へ送信することにより、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに対する応答を行う。また、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報を初期化し、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれるＨＮＢ−Ｓ２のＲＦＣＩ情報に再設定する。

以降のステップＳ６０７〜Ｓ６１５において、ＵＥ１、ＨＮＢ−Ｓ２、ＨＮＢ−Ｔ３、およびＣＮノード５により行われる処理は、図５のステップＳ２０３〜Ｓ２１１において、ＵＥ１、ＨＮＢ−Ｓ２、ＨＮＢ−Ｔ３、およびＨＮＢ−ＧＷ４により行われていた処理と同様である。

上述したように本実施形態では、ＣＮノード５は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を、Ｉｕ−ＵＰ ＩｎｉｔメッセージによりＨＮＢ−Ｔ３に通知するため、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｓ２からＲＦＣＩ情報を引き継ぐことが可能になる。

したがって、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時にも、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

なお、本実施形態により変更される、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）の６．５．２におけるＩｕ−ＵＰ Ｖｅｒ１の記述は、次の通りになる。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、ＲＡＮＡＰによるＲＡＢ Ｍｏｄｉｆｉａｔｉｏｎの要求をすることなく、または、Ｉｎｔｒａ ＨＮＢ−ＧＷリロケーションが発生することなく、ＲＡＢのために再起動することはできない。

また、本実施形態により変更される、３ＧＰＰ ＴＳ２５．４１５（非特許文献２）の６．５．２におけるＩｕ−ＵＰ Ｖｅｒ２の記述は、次の通りになる。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ手順は、ＲＡＮＡＰによるＲＡＢ Ｍｏｄｉｆｉａｔｉｏｎの要求をすることなく、または、Ｉｎｔｒａ ＨＮＢ−ＧＷリロケーションが発生することなく、ＲＡＢのために再起動することはできない。
（第７の実施形態）
本実施形態の移動通信システムは、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３と、ＨＮＢ−ＧＷ４と、に特徴がある。

本実施形態では、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３の各々が、ＲＦＣＩ情報をＨＮＢ−ＧＷ４に通知し、ＨＮＢ−ＧＷ４が、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致しない場合、ＨＮＢ−Ｔ３から受信した音声データに付加されているＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内で同じ構造のデータフレームを示しているＲＦＣＩ値に変換する。

図１７を参照すると、本実施形態のＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を第１のメッセージに含める制御部２１Ｄと、その第１のメッセージをＨＮＢ−ＧＷ４に送信する送受信部２２Ｄと、を有する。

また、本実施形態のＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報を第２のメッセージに含める制御部３１Ｄと、その第２のメッセージをＨＮＢ−ＧＷ４に送信する送受信部３２Ｄと、を有する。

また、本実施形態のＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２から第１のメッセージを受信するとともにＨＮＢ−Ｔ３から第２のメッセージを受信する第１の送受信部４１Ｄと、第１のメッセージに含まれるＨＮＢ−Ｓ２のＲＦＣＩ情報と第２のメッセージに含まれるＨＮＢ−Ｔ３のＲＦＣＩ情報を格納する記憶部４２Ｄと、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致しない場合、以降に、ＨＮＢ−Ｔ３から音声データを受信すると、その音声データに付加されたＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内でその音声データと同じ構造のデータフレームを示しているＲＦＣＩ値に変換するＲＦＣＩ変換を行う制御部４３Ｄと、制御部４３ＤにてＲＦＣＩ変換されたＲＦＣＩ値が付加された音声データをＣＮ６に送信する第２の送受信部４４Ｄと、を有する。

以下、本実施形態の移動通信システムの動作について、図１８に示すシーケンス図に沿って説明する。

ＨＮＢ−Ｓ２は、ステップＳ７０１において、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含む第１のメッセージをＨＮＢ−ＧＷ４に送信する。

ＨＮＢ−Ｔ３は、ステップＳ７０２において、ＨＮＢ−Ｔ３のＲＦＣＩ情報を含む第２のメッセージをＨＮＢ−ＧＷ４に送信する。

ＨＮＢ−ＧＷ４は、第１のメッセージに含まれるＨＮＢ−Ｓ２のＲＦＣＩ情報と第２のメッセージに含まれるＨＮＢ−Ｔ３のＲＦＣＩ情報を、記憶部４２Ｄに格納する。また、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報を比較する。

その後、ＵＥ１は、ステップＳ７０３において、ＨＮＢ−Ｔ３を介してＨＮＢ−ＧＷ４と音声データ（ユーザデータ）の送受信を行う。

このとき、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致していなかった場合、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｔ３から音声データを受信すると、その音声データに付加されたＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内でその音声データと同じ構造のデータフレームを示しているＲＦＣＩ値に変換するＲＦＣＩ変換を行う。

そして、ＨＮＢ−ＧＷ４は、ＲＦＣＩ変換されたＲＦＣＩ値が付加された音声データをＣＮ６に送信する。

なお、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致していた場合には、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｔ３から受信した音声データとその音声データに付加されたＲＦＣＩ値を、そのままＣＮ６に送信する。

上述したように本実施形態では、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致しない場合、以降に、ＨＮＢ−Ｔ３から受信した音声データに付加されているＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内で同じ構造のデータフレームを示しているＲＦＣＩ値に変換する。

そのため、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間でＲＦＣＩ情報を引き継がなくても、ＨＮＢ間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時に、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。
（第８の実施形態）
本実施形態は、第７の実施形態をより具体化した例である。

本実施形態では、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３の各々が、Ｉｕ−ＵＰ Ｉｎｉｔメッセージにより、ＲＦＣＩ情報をＨＮＢ−ＧＷ４に通知し、ＨＮＢ−ＧＷ４が、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致しない場合、ＨＮＢ−Ｔ３から受信した音声データに付加されているＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内で同じ構造のデータフレームを示しているＲＦＣＩ値に変換する。

しかし、３ＧＰＰ ＴＳ２５．４６７（非特許文献４）のＵＴＲＡＮ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ３Ｇ Ｈｏｍｅ ＮｏｄｅＢでは、Ｉｕ−ＵＰプロトコルのメッセージはＨＮＢ−ＧＷにて終端しないと規定されている。

そこで、本実施形態では、３ＧＰＰの規定を変更し、Ｉｕ−ＵＰメッセージをＨＮＢ−ＧＷで終端することを許容する。

図１９を参照すると、本実施形態のＨＮＢ−ＧＷ４は、対ＨＮＢ送受信部４１Ｅと、ＲＡＮＡＰ機能部４２Ｅと、対ＣＮ送受信部４３Ｅと、Ｉｕ−ＵＰフレーム制御部４４Ｅと、Ｉｕ−ＵＰフレーム転送部４５Ｅと、ＲＦＣＩ保持部４６Ｅと、ＲＦＣＩ変換部４７Ｅと、を有する。なお、図１９において、対ＨＮＢ送受信部４１Ｅが図１７の第１の送受信部４１Ｄを構成し、対ＣＮ送受信部４３Ｅが図１７の第２の送受信部４４Ｄを構成し、ＲＦＣＩ保持部４６Ｅが図１７の記憶部４２Ｄを構成し、その他の機能ブロックが図１７の制御部４３Ｂを構成する。

また、本実施形態のＨＮＢ−Ｓ２は、対ＨＮＢ−ＧＷ送受信部２１Ｅと、ＲＡＮＡＰ機能部２２Ｅと、Ｉｕ−ＵＰフレーム制御部２３Ｅと、Ｉｕ−ＵＰフレーム転送部２４Ｅと、を有する。なお、図１９において、対ＨＮＢ−ＧＷ送受信部２１Ｅが図１７の送受信部２２Ｄを構成し、その他の機能ブロックが図１７の制御部２１Ｄを構成する。

また、本実施形態のＨＮＢ−Ｔ３は、対ＨＮＢ−ＧＷ送受信部３１Ｅと、ＲＡＮＡＰ機能部３２Ｅと、Ｉｕ−ＵＰフレーム制御部３３Ｅと、Ｉｕ−ＵＰフレーム転送部３４Ｅと、を有する。なお、図１９において、対ＨＮＢ−ＧＷ送受信部３１Ｅが図１７の送受信部３２Ｄを構成し、その他の機能ブロックが図１７の制御部３１Ｄを構成する。

ＲＦＣＩ変換部４７Ｅは、ＨＮＢ−Ｔ３から受信した音声データに付加されているＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内で同じ構造のデータフレームを示しているＲＦＣＩ値に変換するＲＦＣＩ変換を行う機能を有する。

なお、ＨＮＢ−ＧＷ４において、その他の対ＨＮＢ送受信部４１Ｅ、ＲＡＮＡＰ機能部４２Ｅ、対ＣＮ送受信部４３Ｅ、Ｉｕ−ＵＰフレーム制御部４４Ｅ、Ｉｕ−ＵＰフレーム転送部４５Ｅ、およびＲＦＣＩ保持部４６Ｅは、それぞれ、図４に示した対ＨＮＢ送受信部４１Ｂ、ＲＡＮＡＰ機能部４２Ｂ、対ＣＮ送受信部４３Ｂ、Ｉｕ−ＵＰフレーム制御部４４Ｂ、Ｉｕ−ＵＰフレーム転送部４５Ｂ、およびＲＦＣＩ保持部４６Ｂと同様の動作を行う。

また、ＨＮＢ−Ｓ２において、対ＨＮＢ−ＧＷ送受信部２１Ｅ、ＲＡＮＡＰ機能部２２Ｅ、Ｉｕ−ＵＰフレーム制御部２３Ｅ、およびＩｕ−ＵＰフレーム転送部２４Ｅは、それぞれ、図４に示した対ＨＮＢ−ＧＷ送受信部２１Ｂ、ＲＡＮＡＰ機能部２２Ｂ、Ｉｕ−ＵＰフレーム制御部２３Ｂ、およびＩｕ−ＵＰフレーム転送部２４Ｂと同様の動作を行う。

また、ＨＮＢ−Ｔ３において、対ＨＮＢ−ＧＷ送受信部３１Ｅ、ＲＡＮＡＰ機能部３２Ｅ、Ｉｕ−ＵＰフレーム制御部３３Ｅ、およびＩｕ−ＵＰフレーム転送部３４Ｅは、それぞれ、図４に示した対ＨＮＢ−ＧＷ送受信部３１Ｂ、ＲＡＮＡＰ機能部３２Ｂ、Ｉｕ−ＵＰフレーム制御部３３Ｂ、およびＩｕ−ＵＰフレーム転送部３４Ｂと同様の動作を行う。

以下、本実施形態の動作について、図２０に示すシーケンス図に沿って説明をする。

なお、図２０においては、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を予め取得しているものとする。すなわち、ＨＮＢ−Ｓ２とＨＮＢ−Ｘ８との間で通信を確立する際に、ＨＮＢ−Ｓ２は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４へ送信しており、これにより、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２のＲＦＣＩ情報を取得している。この手順は、図２０のステップＳ８０１以前に実施されており、図２０には記載されていない。

まず、図５のステップＳ２０１，Ｓ２０２の処理と同様のステップＳ８０１，Ｓ８０２の処理が行われる。

次に、ＨＮＢ−Ｔ３は、ステップＳ８０３において、ＨＮＢ−Ｔ３のＲＦＣＩ情報を含むＩｕ−ＵＰ ＩｎｉｔメッセージをＨＮＢ−ＧＷ４へ送信する。ＨＮＢ−ＧＷ４は、Ｉｕ−ＵＰフレーム制御部４４ＥにてＩｕ−ＵＰ Ｉｎｉｔメッセージを終端し、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれるＨＮＢ−Ｔ３のＲＦＣＩ情報と、予め取得していたＨＮＢ−Ｓ２のＲＦＣＩ情報との比較を行う。

次に、ＨＮＢ−ＧＷ４は、ステップＳ８０４において、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージをＨＮＢ−Ｔ３へ送信することにより、Ｉｕ−ＵＰ Ｉｎｉｔメッセージに対する応答を行う。

以降、図５のステップＳ２０３〜Ｓ２１１の処理と同様のステップＳ８０５〜Ｓ８１２の処理が行われ、その後、ＵＥ１は、ステップＳ８１３において、ＨＮＢ−Ｔ３を介してＨＮＢ−ＧＷ４と音声データ（ユーザデータ）の送受信を行う。

このとき、ステップＳ８０３において、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致していなかった場合には、ＨＮＢ−Ｔ３およびＨＮＢ−Ｘ８のＲＦＣＩ情報も不一致となる。そうすると、ＨＮＢ−Ｔ３およびＨＮＢ−Ｘ８の２つのＲＦＣＩ情報においては、ＲＦＣＩ値が同じであっても、異なる構造のデータフレームを示している場合があるため、ＵＥ１からＨＮＢ−Ｔ３を介して送信されてきた音声データはＲＦＣＩ変換を行う必要がある。

そのため、ＨＮＢ−ＧＷ４は、ＵＥ１からＨＮＢ−Ｔ３を介して送信されてきた音声データをＩｕ−ＵＰフレーム転送部４５ＥからＲＦＣＩ変換部４７Ｅへ転送し、ＲＦＣＩ変換部４７Ｅにて、その音声データに付加されたＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内でその音声データと同じ構造のデータフレームを示しているＲＦＣＩ値に変換するＲＦＣＩ変換を行う。その後に、ＲＦＣＩ変換されたＲＦＣＩ値が付加された音声データをＩｕ−ＵＰフレーム転送部４５Ｅへ転送し、対ＣＮ送受信部４３Ｅを介してＣＮ６へ送信する。

上述したように本実施形態では、ＨＮＢ−ＧＷ４は、ＨＮＢ−Ｓ２およびＨＮＢ−Ｔ３のＲＦＣＩ情報が一致しない場合、以降に、ＨＮＢ−Ｔ３から受信した音声データに付加されているＲＦＣＩ値を、ＨＮＢ−Ｓ２のＲＦＣＩ情報内で同じ構造のデータフレームを示しているＲＦＣＩ値に変換する。

そのため、ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３間でＲＦＣＩ情報を引き継がなくても、ＨＮＢ間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーション発生時に、トランスコーダフリーオペレーション（ＴｒＦＯ）を維持したまま、音声通話を行うことができる。

なお、本実施形態により変更される、３ＧＰＰ ＴＳ２５．４６７（非特許文献４）の７．２における記述は、次の通りになる。

Ｉｕ−ＵＰは、ＣＮ、ＨＮＢ、およびＨＮＢ−ＧＷでのみ終端する。

以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されものではない。本発明の構成や詳細には、本発明の範囲内で当業者が理解し得る様々な変更をすることができる。

例えば、第１〜第４の実施形態では、ＨＮＢ−Ｓ２からＨＮＢ−Ｔ３へ引き継ぐ制御情報がＲＦＣＩ情報のみであるものとして説明したが、本発明はこれに限定されず、ＩＰＴＩ（Inter PDU Transmission Interval）情報を追加で引き継いでもよい。

ＩＰＴＩ情報は、サブフローのデータ送信間隔（周期）を規定したものであり、ＩＰＴＩ情報により、音声データの引継ぎを行わなくとも、サブフローのトールデータサイズとＡＭＲコーデックのレートとにより一意に音声データを算出することができる。

また、第１〜第６の実施形態では、本発明をＨＮＢ間のｉｎｔｒａ−ＨＮＢ−ＧＷリロケーションに適用できる旨を説明したが、本発明はｉｎｔｅｒ−ＨＮＢ−ＧＷリロケーション（ＨＮＢ−Ｓ２とＨＮＢ−Ｔ３が接続されるＨＮＢ−ＧＷが同一でないリロケーション）に適用してもよい。

また、第５および第６の実施形態では、ＨＮＢ−Ｔ３は、ＨＮＢ−Ｔ３のＲＦＣＩ情報をＩｕ−ＵＰ Ｉｎｉｔメッセージに含めて送信しているが、Ｉｕ−ＵＰ Ｉｎｉｔメッセージを送信しようとする時点で、ＨＮＢ−Ｓ２のＲＦＣＩ情報を受信していれば、ＨＮＢ−Ｔ３によるＩｕ−ＵＰ Ｉｎｉｔメッセージの送信を禁止してもよい。

なお、本発明のＨＮＢ−Ｓ、ＨＮＢ−Ｔ、ＨＮＢ−ＧＷ、およびＣＮノードにて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。

本出願は、２００９年８月１２日に出願された日本出願特願２００９−１８７３２０を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (20)

1. 第１のＨＮＢと、第２のＨＮＢと、コアネットワークに接続するＨＮＢ−ＧＷと、を有する移動通信システムであって、
   前記第１のＨＮＢは、ＵＥが前記第１のＨＮＢから前記第２のＨＮＢへリロケーションを実行する前に前記ＵＥと通信し、
   前記第２のＨＮＢは、前記リロケーションを実行した後に前記ＵＥと通信し、前記ＨＮＢ−ＧＷにＲＦＣＩ情報を含むＩｕ−ＵＰ Ｉｎｉｔメッセージを送信し、
   前記ＨＮＢ−ＧＷは、前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージを受信する、移動通信システム。
2. 前記ＨＮＢ−ＧＷは、前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージを受信した後に、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージを前記第２のＨＮＢに送信する、請求項１に記載の移動通信システム。
3. 前記ＨＮＢ−ＧＷは、前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれる情報を前記コアネットワークに転送しない、請求項１または２に記載の移動通信システム。
4. 前記ＨＮＢ−ＧＷは、保持された前記第１のＨＮＢに関するＲＦＣＩ情報と、前記第２のＨＮＢから受信したＲＦＣＩ情報との一致を確認する、請求項１乃至３のいずれか１項に記載の移動通信システム。
5. 前記ＨＮＢ−ＧＷは、前記第１のＨＮＢに関するＲＦＣＩ情報と前記第２のＨＮＢから受信したＲＦＣＩ情報とが一致しない場合にＲＦＣＩ値を変換する、請求項１乃至４のいずれか１項に記載の移動通信システム。
6. コアネットワークに接続されるＨＮＢ−ＧＷであって、
   第１のＨＮＢが通信したＵＥが前記第１のＨＮＢとの通信後に前記第１のＨＮＢから第２のＨＮＢへリロケーションを実行したとき、該リロケーションの実行後に前記ＵＥと通信した前記第２のＨＮＢから、ＲＦＣＩ情報を含むＩｕ−ＵＰ Ｉｎｉｔメッセージを受信する、ＨＮＢ−ＧＷ。
7. 前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージを受信した後に、Ｉｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージを前記第２のＨＮＢに送信する、請求項６に記載のＨＮＢ−ＧＷ。
8. 前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれる情報を前記コアネットワークに転送しない、請求項６または７に記載のＨＮＢ−ＧＷ。
9. 保持された前記第１のＨＮＢに関するＲＦＣＩ情報と、前記第２のＨＮＢから受信したＲＦＣＩ情報との一致を確認する、請求項６乃至８のいずれか１項に記載のＨＮＢ−ＧＷ。
10. 前記第１のＨＮＢに関するＲＦＣＩ情報と前記第２のＨＮＢから受信したＲＦＣＩ情報とが一致しない場合にＲＦＣＩ値を変換する、請求項６乃至９のいずれか１項に記載のＨＮＢ−ＧＷ。
11. 第１のＨＮＢと、第２のＨＮＢと、コアネットワークに接続するＨＮＢ−ＧＷと、を有する移動通信システムにおける第２のＨＮＢであって、
    第１のＨＮＢが通信したＵＥが前記第１のＨＮＢとの通信後に前記第１のＨＮＢから第２のＨＮＢへリロケーションを実行したとき、該リロケーションの実行後に前記ＵＥと通信し、前記ＨＮＢ−ＧＷにＲＦＣＩ情報を含むＩｕ−ＵＰ Ｉｎｉｔメッセージを送信する、第２のＨＮＢ−ＧＷ。
12. 前記ＨＮＢ−ＧＷが前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージを受信した後に、前記ＨＮＢ−ＧＷからＩｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージを受信する、請求項１１に記載の第２のＨＮＢ。
13. 前記ＨＮＢ−ＧＷが前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれる情報を前記コアネットワークに転送しない、請求項１１または１２に記載の第２のＨＮＢ。
14. 前記ＨＮＢ−ＧＷが、該ＨＮＢ−ＧＷに保持された前記第１のＨＮＢに関するＲＦＣＩ情報と前記第２のＨＮＢから受信したＲＦＣＩ情報との一致を確認する、請求項１１乃至１３のいずれか１項に記載の第２のＨＮＢ。
15. 前記第１のＨＮＢに関するＲＦＣＩ情報と前記第２のＨＮＢから受信したＲＦＣＩ情報とが一致しない場合に前記ＨＮＢ−ＧＷがＲＦＣＩ値を変換する、請求項１１乃至１４のいずれか１項に記載の第２のＨＮＢ。
16. 第１のＨＮＢと、第２のＨＮＢと、コアネットワークに接続するＨＮＢ−ＧＷと、を有する移動通信システムのＵＥであって、
    前記第１のＨＮＢから前記第２のＨＮＢへリロケーションを実行する前に前記第１のＨＮＢと通信し、
    前記リロケーションの実行後、前記第２のＨＮＢと通信し、
    前記ＵＥと通信した前記第２のＨＮＢが前記ＨＮＢ−ＧＷにＲＦＣＩ情報を含むＩｕ−ＵＰ Ｉｎｉｔメッセージを送信する、ＵＥ。
17. 前記ＨＮＢ−ＧＷが前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージを受信した後にＩｕ−ＵＰ Ｉｎｉｔ ＡＣＫメッセージを前記第２のＨＮＢに送信する、請求項１６に記載のＵＥ。
18. 前記ＨＮＢ−ＧＷが前記Ｉｕ−ＵＰ Ｉｎｉｔメッセージに含まれる情報を前記コアネットワークに転送しない、請求項１６または１７に記載のＵＥ。
19. 前記ＨＮＢ−ＧＷが、該ＨＮＢ−ＧＷに保持された前記第１のＨＮＢに関するＲＦＣＩ情報と前記第２のＨＮＢから受信したＲＦＣＩ情報との一致を確認する、請求項１６乃至１８のいずれか１項に記載のＵＥ。
20. 前記第１のＨＮＢに関するＲＦＣＩ情報と前記第２のＨＮＢから受信したＲＦＣＩ情報とが一致しない場合に前記ＨＮＢ−ＧＷがＲＦＣＩ値を変換する、請求項１６乃至１９のいずれか１項に記載のＵＥ。

Images