(57)【特許請求の範囲】
【請求項１】
無線通信システムにおける端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ)が無線リンク障害(ｒａｄｉｏ ｌｉｎｋ ｆａｉｌｕｒｅ)を報告する方法において、
無線リンク障害を検知し、
前記無線リンク障害に関する無線リンク障害報告(ｒｅｐｏｒｔ)を構成し、
前記無線リンク障害報告を基地局(ｅＮｏｄｅＢ；ｅＮＢ)に送信することを含み、
前記無線リンク障害に前記端末の機器内共存干渉による影響がある場合、前記無線リンク障害報告は、前記機器内共存干渉を発生させた通信システムがいずれの通信システムであるかを示す情報、及び前記機器内共存干渉を発生させた通信システムの信号の受信電力又は干渉電力を測定した値を含むように構成されることを特徴とする無線リンク障害報告方法。
【請求項２】
前記機器内共存干渉を発生させた通信システムの信号の受信電力は、前記端末の無線通信システムで運用する信号測定方式を介して前記端末の無線通信システムの帯域内で受信された前記機器内共存干渉を発生させた通信システムの信号の受信電力を測定した値であることを特徴とする請求項１に記載の無線リンク障害報告方法。
【請求項３】
前記機器内共存干渉を発生させた通信システムの信号の受信電力を測定した値は、ＲＳＲＰ(Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ)で表現されることを特徴とする請求項２に記載の無線リンク障害報告方法。
【請求項４】
前記機器内共存干渉を発生させた通信システムの信号の受信電力は、前記端末の無線通信システムで運用する信号測定方式を介して前記端末の無線通信システムの帯域内で受信された全ての受信信号の受信電力強度に対する前記端末の無線通信システムの帯域内で受信された前記機器内共存干渉を発生させた通信システムの信号の受信電力強度を測定した値であることを特徴とする請求項１に記載の無線リンク障害報告方法。
【請求項５】
前記機器内共存干渉を発生させた通信システムの信号の受信電力を測定した値は、ＲＳＲＱ(Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ)で表現されることを特徴とする請求項４に記載の無線リンク障害報告方法。
【請求項６】
前記機器内共存干渉を発生させた通信システムは、ＷＬＡＮ(Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ)システム、ブルートゥースシステム、及びＧＰＳ(Ｇｌｏｂａｌ ＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ)システムのうち少なくとも一つを含むことを特徴とする請求項１ないし５のうちのいずれか一項に記載の無線リンク障害報告方法。
【請求項７】
前記無線リンク障害報告は、前記無線リンク障害において前記端末の機器内共存干渉による影響があったかどうかを指示する識別子をさらに含むことを特徴とする請求項１に記載の無線リンク障害報告方法。
【請求項８】
前記機器内共存干渉を発生させた通信システムの信号の受信電力又は干渉電力を測定した値は、運転テスト最小化(Ｍｉｎｉｍｉｚａｔｉｏｎ Ｄｒｉｖｉｎｇ Ｔｅｓｔ；ＭＤＴ)を実行するように構成された測定方式に基づいて測定された値であることを特徴とする請求項１に記載の無線リンク障害報告方法。
【請求項９】
前記無線リンク障害報告は、前記無線リンク障害以後実行されるＲＲＣ(Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ)接続再設定手順でＲＲＣ接続再設定要求メッセージに含まれて送信されることを特徴とする請求項１に記載の無線リンク障害報告方法。
【請求項１０】
前記無線リンク障害報告は、Ｅ−ＵＴＲＡＮ(Ｅｖｏｌｖｅｄ−Ｕｎｉｖｅｒｓａｌ ＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓ Ｎｅｔｗｏｒｋ)から受信した端末情報提供要求に対する応答として送信されることを特徴とする請求項１に記載の無線リンク障害報告方法。
【請求項１１】
前記端末情報提供要求を含むメッセージは、無線リンク障害情報を要求(ｒｅｑｕｅｓｔ)するフィールドを含み、前記無線リンク障害情報を要求するフィールドは、ログされた測定情報の報告を指示するフィールド又は無線リンク障害情報を報告すべきかどうかを指示するフィールドであることを特徴とする請求項１０に記載の無線リンク障害報告方法。
【請求項１２】
無線通信システムにおける無線リンク障害(ｒａｄｉｏ ｌｉｎｋ ｆａｉｌｕｒｅ)を報告する端末であって、
無線リンク障害を検知し、前記無線リンク障害に前記端末の機器内共存干渉による影響がある場合、前記機器内共存干渉を発生させた通信システムがいずれの通信システムであるかを示す情報、及び前記機器内共存干渉を発生させた通信システムの信号の受信電力又は干渉電力を測定する測定部を含むプロセッサと、
前記無線リンク障害報告を基地局に送信するＲＦ部とを含むことを特徴する端末。
【請求項１３】
端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ)が無線リンク障害(ｒａｄｉｏｌｉｎｋ ｆａｉｌｕｒｅ)を検知した後に前記端末によって前記無線リンク障害に関する無線リンク障害の報告を通知された無線通信システムにおける基地局が前記無線リンク障害の報告を処理する方法において、
前記無線リンク障害に前記端末の機器内共存干渉による影響がある場合、前記機器内共存干渉を発生させた通信システムがいずれの通信システムであるかを示す情報、及び前記機器内共存干渉を発生させた通信システムの信号の受信電力又は干渉電力を測定した値を含む無線リンク障害報告を端末から受信し、
前記無線リンク障害報告に基づいて前記無線リンク障害が発生したセルに前記無線リンク障害に対する情報を送信し、
前記無線リンク障害報告が無線リンク障害に対する端末の機器内共存干渉情報を含む場合または前記無線リンク障害が発生したセルが前記機器内共存干渉に対する情報を必要とする場合にのみ前記端末の機器内共存干渉情報を送信することを特徴とする無線リンク障害報告処理方法。
【請求項１４】
前記無線リンク障害報告は、前記無線リンク障害が発生した端末から受信したＲＲＣ接続再設定要求メッセージに含まれて送信されることを特徴とする請求項１３に記載の無線リンク障害報告処理方法。
【請求項１５】
前記無線リンク障害報告は、Ｅ−ＵＴＲＡＮの端末情報提供要求に対する応答として送信されたことを特徴とする請求項１３に記載の無線リンク障害報告処理方法。
【請求項１６】
前記無線リンク障害に対する情報は、Ｘ２インターフェースを介して送信されることを特徴とする請求項１３に記載の無線リンク障害報告処理方法。
【請求項１７】
端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ)が無線リンク障害(ｒａｄｉｏｌｉｎｋ ｆａｉｌｕｒｅ)を検知した後に前記端末によって前記無線リンク障害に関する無線リンク障害の報告を通知された場合に、前記無線リンク障害の報告を処理する基地局であって、
前記基地局は、
前記無線リンク障害に前記端末の機器内共存干渉による影響がある場合、前記機器内共存干渉を発生させた通信システムがいずれの通信システムであるかを示す情報、及び前記機器内共存干渉を発生させた通信システムの信号の受信電力又は干渉電力を測定した値を含む無線リンク障害報告を端末から受信し、前記無線リンク障害報告に基づいて前記無線リンク障害が発生したセルに前記無線リンク障害に対する情報を送信するＲＦ部を含み、
前記ＲＦ部は、前記無線リンク障害報告が無線リンク障害に対する端末の機器内共存干渉情報を含む場合または前記無線リンク障害が発生したセルが前記機器内共存干渉に対する情報を必要とする場合にのみ前記端末の機器内共存干渉情報を送信することを特徴とする基地局。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信に関し、具体的には、無線リンク障害(Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ；ＲＬＦ、以下、‘ＲＬＦ’という)を報告する装置及び方法に関する。
【背景技術】
【０００２】
無線通信システムは、一般的にデータ送信のために一つの帯域幅を利用する。例えば、２世代無線通信システムは、２００ＫＨｚ〜１.２５ＭＨｚの帯域幅を使用し、３世帯無線通信システムは、５ＭＨｚ〜１０ＭＨｚの帯域幅を使用する。増加する送信容量をサポートするために、最近の３ＧＰＰ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)ＬＴＥ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)又はＩＥＥＥ８０２.１６ｍは、２０ＭＨｚ又はそれ以上まで引き続きその帯域幅を拡張している。
【０００３】
一方、従来において，一つの端末が一つのネットワークシステムと通信を実行するため、ユーザは各ネットワークシステムをサポートする互いに異なる機器を携帯した。しかし、最近、ユビキタス(ｕｂｉｑｕｉｔｏｕｓ)接続ネットワークによって、ユーザは互いに異なる地域で同じネットワークに接続できるだけでなく、同じ場所で互いに異なるネットワークに接続することもできる。これをサポートするために、端末（UE）の機能が高度化されて複雑になって、一つの端末でも複数のネットワークシステムに接続して通信可能になった。したがって、ユーザの便宜が増大し、帯域幅も効果的に活用されるという効果を得るようになった。
【０００４】
しかし、互いに異なる通信システムの送受信装置による干渉発生によって、無線通信システムの性能低下が発生する問題点が存在する。したがって、このような無線通信システムの性能低下の解決が要求される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の技術的課題は、無線通信システムにおいて、無線リンク障害が発生する原因に対する情報を報告することができる装置及び方法を提供することである。
【０００６】
本発明の技術的課題は、無線通信システムにおいて、無線リンク障害情報を取得してネットワーク品質を改善する装置及び方法を提供することである。
【０００７】
本発明の技術的課題は、無線通信システムにおいて、無線リンク障害原因による無線リンク障害の報告を行う装置及び方法を提供することである。
【０００８】
本発明の技術的課題は、無線通信システムにおいて、端末内の互いに異なる通信装置による干渉のため発生する無線リンク障害情報を報告する装置及び方法を提供することである。
【０００９】
本発明の技術的課題は、無線通信システムにおいて、端末内の互いに異なる通信システムの送受信装置による信号の受信電力及び/又は干渉電力を測定した値を無線リンク障害情報に含んで報告する装置及び方法を提供することである。
【課題を解決するための手段】
【００１０】
本発明の一実施形態は、端末（ＵＥ）の無線リンク障害（ＲＬＦ）報告の方法であって、無線リンク障害に対する無線リンク障害の報告、及び無線リンク障害の報告の送信を含み、無線リンク障害の報告は、前記無線リンク障害に対して機器内共存干渉（Ｉｎ−ｄｅｖｉｃｅ  ＣＯｅｘｉｓｔｅｎｃｅ  ｉｎｔｅｒｆｅｒｅｎｃｅ）（ＩＣＯ）による影響があったかどうかに対する情報を含む。
【００１１】
このとき、無線リンク障害報告は、機器内共存干渉を発生させた通信システムを示す情報を含む。
【００１２】
また、無線リンク障害報告は、無線リンク障害が発生した端末内の第１の通信システムに対する端末内の第２の通信システム信号の受信電力及び/又は干渉電力を測定した値を示す情報を含む。
【００１３】
ここで、第１の通信システムに対する第２の通信システム信号の受信電力は、第１の通信システムが利用する帯域内で第１の通信システムの測定方式により測定された第２の通信システム信号の受信電力を示し、第１の通信システムに対する第２の通信システム信号の干渉電力は、第１の通信システムが利用する帯域内で受信された全ての信号の受信電力に対する第２の通信システム信号の受信電力を第１の通信システムの測定方式により測定した値を示す。
【００１４】
一方、無線リンク障害報告は、該当無線リンク障害以後実行される，Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  （ＲＲＣ）  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｒｅｑｕｅｓｔ（再設定要求）の手順でＲＲＣ再設定要求メッセージに含まれて送信され、又はＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）からの端末情報提供要求に対する応答として送信される。
【００１５】
本発明の他の実施形態は、基地局の無線リンク障害報告処理方法であって、無線リンク障害報告を受信するステップ及び無線リンク障害が発生したセルに無線リンク障害に対する情報を送信するステップを含み、無線リンク障害が発生したセルは、無線リンク障害報告に基づいて判断される。
【００１６】
無線リンク障害報告が無線リンク障害に対する端末の機器内共存干渉情報を含む場合、無線リンク障害が発生したセルが機器内共存干渉に対する情報を必要とする場合にのみ端末の機器内共存干渉情報を送信する。
【００１７】
無線リンク障害報告は、前記無線リンク障害が発生した端末からのＲＲＣ再設定要求メッセージに含まれて送信され、又はＥ−ＵＴＲＡＮの端末情報提供要求に対する応答として送信される。一方、無線リンク障害に対する情報は、Ｘ２インターフェースを介して送信される。
【発明の効果】
【００１８】
本発明によると、ＲＬＦが発生する原因に従ってＲＬＦ情報を正確に報告することができ、これをネットワークで共有することによって、ネットワーク品質を効果的に改善することができる。
【００１９】
本発明によると、端末内の互いに異なる通信システムの送受信装置による干渉を介して発生したＲＬＦに関しても報告することができ、この場合、互いに異なるシステムの送受信装置により干渉が発生したという情報の外に、各システムの送受信装置による信号の受信電力及び/又は干渉電力を測定した値をＲＬＦ情報に含めて、より正確なＲＬＦ報告が行われるようにすることができる。
【図面の簡単な説明】
【００２０】
【図１】本発明の実施例が適用される無線通信システムを示す。
【図２】本発明が適用される機器内共存干渉を説明する説明図である。
【図３】本発明が適用されるＩＳＭ(Ｉｎｄｕｓｔｒｉａｌ、Ｓｃｉｅｎｔｉｆｉｃ ａｎｄ Ｍｅｄｉｃａｌ)送信機からＬＴＥ受信機(ｒｅｃｅｉｖｅｒ)への機器内共存干渉を示す例である。
【図４】本発明が適用されるＲＬＦを概略的に説明する図面である。
【図５】本発明が適用されるＵＥとｅＮＢとの間に実行されるコンテンションベースのランダムアクセス手順を概略的に説明するフローチャートである。
【図６】本発明が適用されるＲＲＣ接続再設定手順を概略的に説明するフローチャートである。
【図７】本発明が適用されるＲＬＦ指示(ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ)を概略的に説明する図面である。
【図８】本発明が適用されるハンドオーバ報告に対して概略的に説明する図面である。
【図９】本発明が適用されるＵＥ情報提供手順を概略的に説明するフローチャートである。
【図１０】本発明が適用されるＭＤＴの基本概念を概略的に説明する図面である。
【図１１】本発明が適用されるシステムで実行されるＲＬＦ報告手順を概略的に説明するフローチャートである。
【図１２】本発明が適用されるシステムでＲＬＦを受けたＵＥが実行するＲＬＦ情報の報告手順を概略的に説明するフローチャートである。
【図１３】本発明が適用されるシステムでＲＬＦ情報を受信するｅＮＢが実行する動作を概略的に説明するフローチャートである。
【図１４】本発明が適用されるシステムでＲＬＦが発生したｅＮＢがＲＬＦ情報に基づいて実行する動作を概略的に説明するフローチャートである。
【図１５】本発明が適用されるシステムでＵＥの構成を概略的に説明するブロック図である。
【図１６】本発明が適用されるシステムでｅＮＢの構成を概略的に説明するブロック図である。
【発明を実施するための形態】
【００２１】
以下、本明細書では一部実施例を例示的な図面を介して詳細に説明する。各図面の構成要素に参照符号を付加するにあたって、同じ構成要素に対しては、たとえ、他の図面上に表示されても、可能の限り同じ符号を有していることを留意しなければならない。また、本明細書の実施例を説明するにあたって、関連した公知構成又は機能に対する具体的な説明が本明細書の要旨を不明にすると判断される場合にはその詳細な説明は省略する。
【００２２】
本明細書は、無線通信ネットワークを対象にして説明し、無線通信ネットワークで行われる作業は、該当無線通信ネットワークを管轄するシステム(例えば、基地局)でネットワークを制御してデータを送信する過程で行われたり、該当無線ネットワークに結合した端末で作業が行われたりされる。
【００２３】
図１は、本発明の実施例が適用される無線通信システムを示す。
【００２４】
図１を参照すると、無線通信システムは、音声、パケットデータなどのような多様な通信サービスを提供するために広く配置され、端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ)１０、基地局(ｅｖｏｌｖｅｄ ＮｏｄｅＢ；ｅＮＢ)２０、無線ＬＡＮ(Ｗｉｒｅｌｅｓｓ ＬＡＮ)アクセスポイント(Ａｃｃｅｓｓ Ｐｏｉｎｔ；ＡＰ)３０、ＧＰＳ(Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ)衛星(ｓａｔｅｌｌｉｔｅ)４０を含む。ここで、無線ＬＡＮは、無線標準であるＩＥＥＥ８０２.１１技術をサポートする装置であり、ＩＥＥＥ８０２.１１は、ワイファイ(ＷｉＦｉ)システムと混用されてもよい。
【００２５】
端末１０は、セルラーネットワーク、無線ＬＡＮ、放送ネットワーク、衛星システムなどのような複数のネットワークのカバレッジ(ｃｏｖｅｒａｇｅ)内に位置される。端末１０が、時間と場所に拘らず、基地局２０、無線ＬＡＮアクセスポイント３０、ＧＰＳ４０等、多様なネットワークと多様なサービスに接続するために、端末１０は、複数の無線送受信機(ｔｒａｎｓｃｅｉｖｅｒ)を具備している。例えば、スマートフォン(ｓｍａｒｔｐｈｏｎｅ)は、ＬＴＥ、ＷｉＦｉ、ブルートゥース(ｂｌｕｅｔｏｏｔｈ；ＢＴ、以下、‘ＢＴ’という)（登録商標）送受信機とＧＰＳ受信機を具備する。このように良い性能を維持しながら一つの同じ端末１０内にさらに多くの送受信機を集積させるために、端末１０のデザインはさらに複雑になっている。これにより、機器内共存干渉が発生する可能性がさらに大きくなる。
【００２６】
以下、ダウンリンク(ｄｏｗｎｌｉｎｋ)は、基地局２０から端末１０への通信を意味し、アップリンク(ｕｐｌｉｎｋ)は、端末１０から基地局２０への通信を意味する。ダウンリンクで、送信機は基地局２０の一部であり、受信機は端末１０の一部である。また、アップリンクで、送信機は端末１０の一部であり、受信機は基地局２０の一部である。
【００２７】
端末１０は、固定されてもよいし、移動性を有してもよく、ＭＳ(Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ)、ＵＴ(Ｕｓｅｒ Ｔｅｒｍｉｎａｌ)、ＳＳ(Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ)、ＭＴ(Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ)、無線機器(Ｗｉｒｅｌｅｓｓ Ｄｅｖｉｃｅ)等、他の用語で呼ばれることもある。基地局２０は、端末１０と通信する固定局(ｆｉｘｅｄ ｓｔａｔｉｏｎ)を意味し、ＢＳ(Ｂａｓｅ Ｓｔａｔｉｏｎ)、ＢＴＳ(Ｂａｓｅ ＴｒａｎｓｃｅｉｖｅｒＳｙｓｔｅｍ)、アクセスポイント(Ａｃｃｅｓｓ Ｐｏｉｎｔ)、フェムト基地局(Ｆｅｍｔｏ ＢＳ)、ピコ基地局(Ｐｉｃｏ ＢＳ)、リレー(ｒｅｌａｙ)等、他の用語で呼ばれることもある。
【００２８】
無線通信システムに適用される多重接続技法には制限がない。ＣＤＭＡ(Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ)、ＴＤＭＡ(Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ)、ＦＤＭＡ(Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ ＭｕｌｔｉｐｌｅＡｃｃｅｓｓ)、ＯＦＤＭＡ(Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ)、ＳＣ−ＦＤＭＡ(Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ−ＦＤＭＡ)、ＯＦＤＭ−ＦＤＭＡ、ＯＦＤＭ−ＴＤＭＡ、ＯＦＤＭ−ＣＤＭＡのような多様な多重接続技法を使用することができる。アップリンク送信及びダウンリンク送信は、互いに異なる時間を使用して送信されるＴＤＤ(Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ)方式が使われてもよく、又は互いに異なる周波数を使用して送信されるＦＤＤ(Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ)方式が使われてもよい。
【００２９】
一方、一つの端末が複数のネットワークシステム帯域上で同時に通信を実行する場合、機器内共存干渉(Ｉｎ−ｄｅｖｉｃｅ ＣＯｅｘｉｓｔｅｎｃｅＩｎｔｅｒｆｅｒｅｎｃｅ；ＩＣＯ)が発生する場合がある。機器内共存干渉は、一周波数帯域で端末が実行する送信が、他の周波数帯域で同じ端末が実行する受信に干渉を起こすことを意味する。例えば、一つの端末がＢＴシステムとＬＴＥ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)システムを同時にサポートする場合、ＢＴシステム帯域とＬＴＥシステム帯域との間に機器内共存干渉が発生する場合がある。
【００３０】
機器内共存干渉は、一つの端末がＬＴＥシステムとＢＴシステムを同時にサポートする場合外に、ＷＬＡＮ(Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ)システム、ＧＰＳ(Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ)などをＬＴＥシステムと同時にサポートする場合にも発生する場合がある。即ち、複数のシステムが共に動作する場合、使用する帯域間に機器内共存干渉が発生する場合がある。機器内共存干渉は、主に異種ネットワークシステムの周波数帯域境界の離隔間隔が十分に広くない場合に発生することがある。
【００３１】
機器内共存干渉を回避するための技術として周波数分割多重化(Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ；ＦＤＭ)方式と時分割多重化(ＴｉｍｅＤｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ；ＴＤＭ)方式が使われることができる。ＦＤＭ方式は、第１のネットワークシステムの第１の周波数帯域と第２のネットワークシステムの第２の周波数帯域との間に干渉が発生する場合、いずれか一つのネットワークシステムの周波数帯域を移動させて機器内共存干渉を調整する方式である。即ち、機器内共存干渉が発生する周波数帯域を回避することによって機器内共存干渉を調整する。一方、ＴＤＭ方式は、第１のネットワークシステムの送信時間と第２のネットワークシステムの受信時間を互いに離隔させて機器内共存干渉を調整する方式である。
【００３２】
図２は、本発明が適用される機器内共存干渉を説明する説明図である。
【００３３】
図２を参照すると、端末２０は、ＬＴＥ ＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）２１、ＧＰＳ ＲＦ２２、ＢＴ/ＷｉＦｉ ＲＦ２３を含む。各ＲＦには、送受信アンテナ２４、２５、２６が接続される。即ち、一つの機器プラットホーム(ｄｅｖｉｃｅ ｐｌａｔｆｏｒｍ)内に多様な種類のＲＦが近接して装着されている。ここで、一つのＲＦの送信電力が他のＲＦ受信機への受信電力水準(ｌｅｖｅｌ)より非常に大きい場合がある。このとき、ＲＦ間の周波数間隔が十分でなく、高度のフィルタリング技術が裏付けられていない場合、同じ機器内で一つのＲＦの送信信号が他のＲＦの受信機に顕著な干渉を引き起こすことがある。例えば、図２において、(１)は、ＬＴＥ ＲＦ２１の送信信号がＧＰＳ ＲＦ２２とＢＴ/ＷｉＦｉ ＲＦ２３に対して機器内共存干渉を起こす例であり、(２)は、ＢＴ/ＷｉＦｉ ＲＦ２３の送信信号がＬＴＥＲＦ２１に対して機器内共存干渉を起こす例である。機器内共存干渉が引き起こす信号間効果を図３で詳細に説明する。
【００３４】
図３は、本発明が適用されるＩＳＭ(Ｉｎｄｕｓｔｒｉａｌ、Ｓｃｉｅｎｔｉｆｉｃａｎｄ Ｍｅｄｉｃａｌ)送信機からＬＴＥ受信機(ｒｅｃｅｉｖｅｒ)への機器内共存干渉を示す例である。ＩＳＭバンドは、産業科学医療分野で使用許可無く自由に使用することができる帯域を示す。
【００３５】
図３を参照すると、ＬＴＥ受信機で受信される信号の帯域がＩＳＭ送信機の送信信号の帯域と重なる部分があることを知ることができる。この場合、機器内共存干渉が発生する場合がある。このように、機器内共存干渉が発生し、又は発生する潜在的(ｐｏｔｅｎｔｉａｌ)可能性が高い、又は発生が予想された周波数帯域を機器内共存干渉脆弱帯域又は略して干渉脆弱帯域(ｉｎｔｅｒｆｅｒｅｎｃｅ ｄｅｌｉｃａｔｅ ｂａｎｄ)という。干渉脆弱帯域で干渉が発生することによって、端末が使用することができない帯域になることができるため、これを使用不能帯域(ｎｏｔ−ｕｓａｂｌｅ ｂａｎｄ)と判断してもよい。干渉脆弱帯域で必ず機器内共存干渉が発生するものではなく、干渉が発生する潜在的可能性がある場合も干渉脆弱帯域と取り扱うことができる。
【００３６】
機器内共存干渉を含め、機器が受ける各種干渉は、ＲＬＦ(Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ；ＲＬＦ)を招く。
【００３７】
図４は、本発明が適用されるＲＬＦの概念を概略的に説明する図面である。図４を参照すると、ＲＬＦは、二つのステップ(ｐｈａｓｅ)に区分されることができる。
【００３８】
正常動作を実行したＵＥが無線チャネルの問題を検出(Ｒａｄｉｏ Ｐｒｏｂｌｅｍ Ｄｅｔｅｃｔｉｏｎ)したときに、ＲＬＦの第１のステップが開始される。ＵＥは、無線チャネルの問題を確認するためにＣＲＳ(Ｃｅｌｌ−ｓｐｅｃｉｆｉｃ ＲｅｆｅｒｅｎｃｅＳｉｇｎａｌ)の受信信号強度(Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ；ＲＳＲＰ)を基準に設定し、これを利用して無線チャネルの問題可否を確認することができる。
【００３９】
図４に示すように、所定時間、例えば、Ｔ１が経過する時まで検出された無線チャネルの問題が復旧されない場合にはＲＬＦとされる。このとき、所定の時間Ｔ１の経過可否は、ＵＥ内の所定のタイマにより確認することもできるため、ＵＥは、ＲＬＦを判断するためのタイマによりＴ１を計測してもよく、他の計測のための経過時間をＴ１として活用してもよい。
【００４０】
ＲＬＦが確認された場合には第２のステップが開始される。このとき、第２のステップに導くＲＬＦは、ハンドオーバの失敗を含む。図４を参照すると、ＲＬＦ後の所定の時間、例えば、Ｔ２が経過するまでに、無線リンクが復旧されない場合(確認された無線チャネルの問題が復旧されない場合)、ＵＥは、ＲＲＣ_ＩＤＬＥ状態に入る。Ｔ２時間の経過の可否は、ＵＥ内の所定のタイマを利用してもよい。
【００４１】
表１は、ＲＬＦの各ステップで発生可能なＵＥの動作によって運用されるリンク接続方法を説明する。
【００４２】
【表１】
0005747120.tif 000002
【００４３】
ここで、‘準備されたｅＮＢ’は、ＵＥが予想より速くハンドオーバを実行しても、これに対応してハンドオーバ手順を実行することができるｅＮＢを示す。
【００４４】
表１は、四つのケースに規定された状況が、(１)ＲＬＦの第１のステップで発生する場合、(２)ＲＬＦの第２のステップで発生する場合、及び(３)各ケースが発生しないままでＴ２が満了する場合に対する無線リンクの運用を説明している。
【００４５】
(１)ＲＬＦの第１のステップでＵＥが同じセルに復帰する場合及び無線チャネルの問題がこれ以上ない場合には、表１に示すように、当該無線リンクが正常に引き続き動作するようになる。
【００４６】
前述したように、ＲＬＦの第１のステップは、無線チャネルの問題を確認した場合に開始され、このとき、無線チャネルの問題が発生したかに対しては無線リンクモニタリング(Ｒａｄｉｏ Ｌｉｎｋ Ｍｏｎｉｔｏｒｉｎｇ；ＲＬＭ)を介して確認することができる。
【００４７】
無線リンクモニタリングは、ＣＲＳ（Ｃｅｌｌ−ｓｐｅｃｉｆｉｃ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）に基づいてｅＮＢとの間で設定されたサービングセルのダウンリンク品質をＵＥが検知することである。ＵＥは、測定されたＣＲＳの受信エネルギに対する制御チャネルの受信エネルギ比により定義される所定のパラメータを利用してダウンリンクの品質を予測することができる。
【００４８】
無線リンクモニタリングは、下記のような条件下に設定されてもよい。
【００４９】
まず、無線リンクモニタリングを介してダウンリンクの品質を予測するための基準値を設定してもよい。例えば、ＣＲＳの平均リソース要素受信エネルギに対するＰＤＣＣＨ(Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ)/ＰＣＦＩＣＨ(Ｐｈｙｓｉｃａｌ Ｃｏｎｔｒｏｌ Ｆｏｒｍａｔ ＩｎｄｉｃａｔｏｒＣｈａｎｎｅｌ)が送信されるリソース要素(Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ、即ち、１つのＯＦＤＭシンボル内の１つの副搬送波)の受信エネルギの比をｄＢ単位に表現した値を基準にしてもよい。
【００５０】
無線リンクモニタリングに利用される所定のパラメータのうち、同期不一致(Ｏｕｔ−ｏｆ−Ｓｙｎｃ)を宣言する基準となるパラメータであるＱｏｕｔ値は、ＰＤＣＣＨ/ＰＣＦＩＣＨを送信するために設定されたパラメータと共にＰＣＦＩＣＨのエラーを考慮した仮想のＰＤＣＣＨ(ＤＣＩ ｆｏｒｍａｔ １Ａベース)送信のＢＥＲ(Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ)が１０％以上と判断される値を基準に設定されることができる。このとき、ＰＤＣＣＨ/ＰＣＦＩＣＨを送信するために設定されたパラメータにはＰＤＣＣＨのＤＣＩフォーマット、サブフレーム内の制御情報が送信されるＯＦＤＭシンボルの個数、ＰＤＣＣＨの自己複製比率を示す集約水準(ａｇｇｒｅｇａｔｉｏｎ ｌｅｖｅｌ)などが含まれ、このパラメータは、ダウンリンク帯域幅に影響を受ける。
【００５１】
Ｑｏｕｔ値は、ＣＲＳが送信されるアンテナポートの個数により異なる値を有してもよい。例えば、ＰＣＦＩＣＨのエラーを考慮した仮想のＰＤＣＣＨ送信のＢＥＲが１０％以上になる状況を考慮するとき、単一アンテナポートに限ってＣＲＳが送信される場合、Ｑｏｕｔ値に設定する前記ＰＤＣＣＨとＣＲとの間のエネルギの比率は４ｄＢを基準にする。また、２個以上のアンテナポートに対してＣＲＳが送信される場合にＱｏｕｔの値は１ｄＢを基準にする。
【００５２】
無線リンクモニタリングに利用される所定のパラメータのうち、同期回復又は同期がとれていること(ｉｎ−ｓｙｎｃ)を宣言する基準になるパラメータであるＱｉｎ値は、前記Ｑｏｕｔ値の場合に比べて十分に大きい信頼性を有する値を基準に設定される。即ち、ＰＤＣＣＨ/ＰＣＦＩＣＨを送信するために設定されたパラメータと共にＰＣＦＩＣＨのエラーを考慮した仮想のＰＤＣＣＨ(ＤＣＩ ｆｏｒｍａｔ １Ｃベース)送信のＢＥＲが２％以上と判断される値を基準に設定されてもよい。
【００５３】
Ｑｉｎ値は、ＣＲＳが送信されるアンテナポートの個数により異なる値を有してもよい。例えば、ＰＣＦＩＣＨのエラーを考慮した仮想のＰＤＣＣＨ送信のＢＥＲが２％以上となる状況を考慮する時、単一アンテナポートにＣＲＳが送信される場合、Ｑｉｎ値に設定する前記ＰＤＣＣＨとＣＲＳとの間のエネルギの比率は０ｄＢを基準にする。また、２個以上のアンテナポートにＣＲＳが送信される場合、Ｑｉｎ値は、−３ｄＢを基準にする。
【００５４】
説明した例で、Ｑｏｕｔ値に比べてＱｉｎ値の基準になるエネルギ比率の値が低い理由は、前述したＰＤＣＣＨ/ＰＣＦＩＣＨを送信するために設定されたパラメータと仮想のＰＤＣＣＨ送信のＢＥＲを基準にするためである。また、Ｑｏｕｔ及びＱｉｎ値は、該当セルに対する端末のＤＲＸ(Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ)動作可否により影響を受ける。
【００５５】
(２)ＲＬＦの第２のステップで、ＵＥが同じセルに復帰する場合、ＵＥが同じｅＮＢの他のセルを選択する場合又はＵＥが準備されたｅＮＢのセルを選択する場合、ＵＥは復帰したｅＮＢ又は選択したｅＮＢとの直接シグナリングを介してＲＲＣ接続再設定手順を実行する。ＲＬＦの第２のステップで、ＵＥが準備されない他のｅＮＢの選択する場合、準備されないｅＮＢは、ＵＥのハンドオーバに対応することができないため、ＵＥは、ＲＲＣ_ＩＤＬＥモードに変更される。
【００５６】
ＲＲＣ_ＩＤＬＥモードは、端末のＲＲＣがＥ−ＵＴＲＡＮのＲＲＣと論理的な接続を有しているかによるＲＲＣモードのうち一つである。ＲＲＣモードは、ＲＲＣ_ＩＤＬＥモードとＲＲＣ_ＣＯＮＮＥＣＴＥＤモードに分けられることができる。
【００５７】
ＲＲＣ_ＣＯＮＮＥＣＴＥＤモードでは、端末とＥ−ＵＴＲＡＮとの間のＲＲＣ接続によってＥ−ＵＴＲＡＮが端末の存在をセル単位に把握することができる。したがって、端末をセル単位に制御することが可能である。
【００５８】
ＲＲＣ_ＩＤＬＥモードでは端末とＥ−ＵＴＲＡＮとの間にＲＲＣ接続がないため、Ｅ−ＵＴＲＡＮが端末の存在を把握することができない。したがって、コアネットワークがセルより大きい範囲のトラッキング領域(Ｔｒａｃｋｉｎｇ Ａｒｅａ；ＴＡ、以下、‘ＴＡ’という)単位にＲＲＣ−ＩＤＬＥモードの端末を管理する。端末は、ＲＲＣ_ＩＤＬＥモードでＴＡ単位に存在のみ把握され、ＲＲＣ_ＣＯＮＮＥＣＴＥＤモードに転換された後にネットワークを介した通常的な通信を実行することができる。このとき、通常的な通信は、音声通話だけでなく、映像通話、データ通信など、ユーザがネットワークを介して利用することができる通信サービスを含む。ＲＲＣ_ＩＤＬＥモードの端末に対し、基地局は、ページング(ｐａｇｉｎｇ)を介してシステム情報の変更などをブロードキャスティンググ(ｂｒｏａｄｃａｓｔｉｎｇ)することができる。
【００５９】
表１を参照すると、ＲＲＣ接続を再設定してＲＲＣ_ＩＤＬＥモードに変更されることを可能の限り避けるために、ＲＬＦの第２のステップで、ＵＥは、ｅＮＢと直接的なシグナリングを介してＲＲＣ接続再設定手順を実行することができる。具体的に、ＲＲＣ_ＩＤＬＥモードに変更されることを可能の限り避けるために、ＵＥは、ＲＲＣ_ＣＯＮＮＥＣＴＥＤモードを維持してランダムアクセス手順を介してセルを評価し、その結果に応じてＲＲＣ接続再設定手順を実行することができる。ＲＲＣ接続再設定手順に対しては後述する。
【００６０】
ランダムアクセス(Ｒａｎｄｏｍ Ａｃｃｅｓｓ)は、ネットワークに接続する場合又はアップリンク同期(ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ)を確保することができない、又は失った場合などに実行される。ＲＬＦが発生した場合にはＲＲＣ_ＩＤＬＥ状態でＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態に転換(初期アクセス又はＴＡアップデート)する場合、アップリンク同期が合わない状態で新たなデータや制御情報を送信しなければならない、又は新たなデータを受信し、これに対するＡＣＫ/ＮＡＣＫ情報を送信しなければならない場合などと同様にコンテンションベースのランダムアクセスが実行される。
【００６１】
図５は、本発明が適用されるＵＥとｅＮＢとの間に実行されるコンテンションベースのランダムアクセス手順を概略的に説明するフローチャートである。
【００６２】
図５を参照すると、ＵＥは、ランダムアクセスのためのプリアンブル(ｐｒｅａｍｂｌｅ)をｅＮＢに送信する(Ｓ５１０)。６４個のランダムアクセスプリアンブルで非コンテンションランダムアクセスに使われるプリアンブルを除いた残りのプリアンブルのうち、ＵＥは、無作為に選択した一つのプリアンブルをｅＮＢに送信することができる。プリアンブルは、ＰＲＡＣＨ(Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ)上にｅＮＢに送信されることができる。このとき、ＰＲＡＣＨに対応する送信チャネルをＲＡＣＨ(Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ)という。
【００６３】
ｅＮＢは、ランダムアクセス応答をＵＥに伝達する(Ｓ５２０)。ランダムアクセス応答(Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｒｅｓｐｏｎｓｅ；ＲＡＲ)は、ＰＤＳＣＨ上に送信され、端末が臨時的に使用することができるＴ
Ｃ−ＲＮＴＩ(Ｔｅｍｐｏｒａｒｙ Ｃｅｌｌ−Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ)、アップリンクグラント、アップリンク同期のための時間整列指示(Ｔｉｍｅ Ａｌｉｇｎｍｅｎｔ Ｉｎｓｔｒｕｃｔｉｏｎ)、選択したプリアンブルのＩＤなどを含む。コンテンションベースのランダムアクセスで、同じプリアンブルを、同じ時間−周波数リソースで送信したＵＥは、同じランダムアクセス応答を受信することもできる。
【００６４】
ランダムアクセス応答を受信したＵＥは、ＰＵＳＣＨ上にＬ２/Ｌ３メッセージをｅＮＢに送信する(Ｓ５３０)。ＭＡＣ(Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ)階層、ＰＬＣ(Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ)階層、ＰＤＣＰ(Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ)階層/ＲＲＣ(Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ)階層メッセージであるＬ２/Ｌ３メッセージは、ＴＣ−ＲＮＴＩとＵＥ固有のＩＤを含む。
【００６５】
ｅＮＢは、コンテンション解消メッセージをＵＥに伝達する(Ｓ５４０)。ｅＮＢが選択したＵＥの固有ＩＤとＴＣ−ＲＮＴＩを含むコンテンション解消メッセージを送信することによって、たとえ、複数のＵＥが同じランダムアクセス応答を受信したとしても、一つの端末が選択されてコンテンションが解消される。
【００６６】
また、表１に対して説明する。ＲＬＦの第２のステップでＵＥが元来のセルに復帰し、又は他のセルを選択して前述したランダムアクセス手順を実行すると、元来のセル又は選択されたセルのｅＮＢは、コンテンションベースのランダムアクセス手順で使用された情報を利用してリンク接続手順を実行する。
【００６７】
具体的に、ＲＬＦが発生したセルでＵＥが使用しているＣ−ＲＮＴＩ情報をＵＥの識別子情報として活用し、セルのＰＣＩ(Ｐｈｙｓｉｃａｌ Ｃｅｌｌ Ｉｄｅｎｔｉｔｙ)を介してセル間の同一性を確認して表１のいずれのケースに該当するかを区別し、ＭＡＣキー(ＭＡＣ ｋｅｙ)情報(例えば、Ｓｈｏｒｔ ＭＡＣ−Ｉ)を介してＵＥに権限（ａｕｔｈｏｒｉｔｙ）を付与してもよい。
【００６８】
ｅＮＢは、該当ＵＥの識別子情報に対応するコンテクスト(ｃｏｎｔｅｘｔ)を保有していることを確認し、無線リンク接続を再開始する。
【００６９】
もし、ｅＮＢが該当ＵＥのコンテクストを探せない場合、ＵＥは、ＲＲＣ接続を解除して新たなＲＲＣ接続を確立しなければならない。まず、ＵＥは、ＲＲＣモードをＲＲＣ_ＩＤＬＥモードに変更してＲＲＣ接続設定(ＲＲＣ ｃｏｎｎｅｃｔｉｏｎｅ ｓｔａｂｌｉｓｈｍｅｎｔ)手順を実行する。
【００７０】
(３)Ｔ２の満了前まで、即ち、ＲＬＦの第２のステップが満了される時まで表１の各ケースが発生しない場合には、ＵＥのＲＲＣモードは、ＲＲＣ_ＩＤＬＥモードに変更される。
【００７１】
以下、前述したＲＲＣ接続再設定(ＲＲＣ Ｒｅ−Ｅｓｔａｂｌｉｓｈｍｅｎｔ)に対して説明する。
【００７２】
ＲＲＣ接続再設定手順は、ＲＲＣ接続を再設定するための手順として、ＳＲＢ(Ｓｉｇｎａｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ)のうち、ＳＲＢ１のオペレーションを再開始するための手順である。
【００７３】
ここで、ＳＲＢは、ＲＲＣとＮＡＳ(Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ)メッセージの送信のためにのみ使われる無線ベアラ(Ｒａｄｉｏ Ｂｅａｒｅｒ；ＲＢ、以下、‘ＲＢ’という)である。ＳＲＢの種類には、ＳＲＢ０、ＳＲＢ１、ＳＲＢ２の三つがある。
【００７４】
まず、ＳＲＢ０は、ＣＣＣＨ(Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ)論理チャネルを使用するＲＲＣメッセージを対象にして使われる。ダウンリンクＣＣＣＨは、ＲＲＣ接続設定、接続再設定、接続設定拒否、接続再設定拒否などと関連した情報送信のために使われる。アップリンクＣＣＣＨは、ＲＲＣ接続要求、ＲＲＣ接続再設定要求などと関連した情報送信のために使われる。
【００７５】
ＳＲＢ１は、ＤＣＣＨ(Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ)論理チャネルを使用する全てのＲＲＣメッセージを対象にして使われ、このＲＲＣメッセージには付けたＮＡＳメッセージが一部含まれることもできる。付けるダウンリンクＮＡＳメッセージは、ベアラ設定/変更/解除手順のように付加的な手順に対してのみ使われる。添付されるアップリンクＮＡＳメッセージ（ａｎ  ａｔｔａｃｈｅｄ  ｄｏｗｎ  ｌｉｎｋ  ＮＡＳ）は、ＲＲＣ接続設定中に初期ＮＡＳメッセージを伝達するためにのみ使われる。また、ＳＲＢ１は、ＳＲＢ２設定以前のＮＡＳメッセージを対象でも使われる。
【００７６】
前述したＤＣＣＨのうち、ダウンリンクＤＣＣＨは、ＲＲＣ接続再構成、接続解除と関連した情報の送信に使われて、セキュリティモード命令(Ｓｅｃｕｒｉｔｙ Ｍｏｄｅ Ｃｏｍｍａｎｄ)、カウンタチェック(ｃｏｕｎｔｅｒ ｃｈｅｃｋ)、異種ネットワーク間ハンドオーバと関連した情報の送信にも使われる。また、ダウンリンクＤＣＣＨは、ダウンリンク関連情報送信、ＵＥ情報要求、ＵＥ性能調査(ＵＥ ｃａｐａｂｉｌｉｔｙ ｅｎｑｕｉｒｙ)関連情報送信にも使われる。
【００７７】
前述したＤＣＣＨのうち、アップリンクＤＣＣＨは、ＲＲＣ接続再構成完了、接続再設定完了、接続設定完了と関連した情報の送信に使われ、セキュリティモード設定完了又はセキュリティモード設定障害、カウンタチェック応答、及び近接性指示(ｐｒｏｘｉｍｉｔｙ ｉｎｄｉｃａｔｉｏｎ)関連情報を送信するためにも使われる。また、アップリンクＤＣＣＨは、アップリンク関連情報送信、測定報告(ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔ)、ＵＥ情報応答、ＵＥ性能情報(ＵＥ ｃａｐａｂｉｌｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ)と関連した情報送信のためにも使われる。
【００７８】
ＳＲＢ(Ｓｉｇｎａｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ)のうち、ＳＲＢ２は、ＤＣＣＨ論理チャネルを使用するＮＡＳメッセージを対象に使われる。ＳＲＢ２は、ＳＲＢ１より優先度が低く、セキュリティ活性化後Ｅ−ＵＴＲＡＮにより常に構成される。例えば、ＲＲＣ接続設定が完了してセキュリティ設定が完了した場合、ＲＲＣ接続再構成手順を介してＳＲＢ２が構成されてもよい。
【００７９】
ＲＲＣ接続再設定手順は、ＲＬＦが検知された場合、ハンドオーバが失敗した場合、下位レイヤから完全性(ｉｎｔｅｇｒｉｔｙ)確認失敗識別子（ｉｎｄｉｃａｔｏｒ）が伝達された場合、ＲＲＣ接続再構成(ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ)が失敗した場合などが発生した状況で開始されてもよい。
【００８０】
前述した状況が発生すると、ＵＥは、ＲＲＣ接続再設定を開始することができる区間（ｔｉｍｅ  ｉｎｔｅｒｖａｌ）中、ＲＲＣ接続再設定の試みに適したセルを探し始める。ＲＲＣ接続再設定の試みに適したセルは、同じネットワークに存在するセルであってもよく、ＵＥがサポート可能な異種ネットワーク内のセルであってもよい。このとき、前記ＲＲＣ接続再設定を開始することができる区間は、ＵＥ内に定義されたタイマを介して規定してもよい。ＬＴＥの場合、ＲＲＣ接続再設定を開始することができる区間を規定するタイマとしてＴ３１１が利用されてもよい。ＲＲＣ接続再設定を開始することができる期間中、ＲＲＣ接続再設定手順を開始するに適したセルを探せることができない場合、ＵＥは、ＲＲＣモードをＲＲＣ_ＩＤＬＥに変更する。
【００８１】
もし、ＵＥがＲＲＣ接続再設定手順を開始するに適したセルを探した場合、ＲＲＣ接続再設定手順を開始する。ＲＲＣ接続再設定手順を開始するためには、下記の三つの条件が全部満たさなければならない。ＵＥが下記の三つの条件を満たしていない場合、ＵＥは、ＲＲＣモードをＲＲＣ_ＩＤＬＥに変更する。
【００８２】
(１)ＵＥがＲＲＣ_ＣＯＮＮＥＣＴＥＤモードにある。
【００８３】
(２)ＡＳセキュリティ(Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ ｓｅｃｕｒｉｔｙ)が活性化されている。
【００８４】
(３)ＵＥコンテクスト(ｃｏｎｔｅｘｔ)が有効である。
【００８５】
ＵＥがこの三つの条件が全部満たした状況の場合、ＵＥは、ＲＲＣ接続再設定手順を開始することができる。
【００８６】
図６は、本発明が適用されるＲＲＣ接続再設定手順を概略的に説明するフローチャートである。
【００８７】
ＵＥが前述した三つの条件を満たす場合、ＵＥは、ＲＲＣ接続再設定要求メッセージ(ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔ)をｅＮＢに送信する(Ｓ６１０)。
【００８８】
ＲＲＣ接続再設定要求メッセージは、ＲＲＣ接続の再設定を要求する原因値を含むことができる。例えば、ＲＬＦにより無線接続が障害した場合にはＲＲＣ接続再設定要求メッセージに原因値としてＲＬＦ情報が含まれることができる。ＲＲＣ接続再設定要求メッセージは、その他にも該当ＵＥの以前セルＩＤを確認することができるＰＣＩ(Ｐｈｙｓｉｃａｌ Ｃｅｌｌ Ｉｄｅｎｔｉｔｙ)などを含むことができる。ＲＬＦにより無線接続が障害した場合、該当ＵＥの以前セルは、ＲＬＦが発生したセルである。
【００８９】
したがって、ＲＬＦが発生した場合、ｅＮＢ(又は、Ｅ−ＵＴＲＡＮ)は、ＵＥからのＲＲＣ接続再設定要求メッセージを介してＲＬＦ情報を取得することができる。
【００９０】
ｅＮＢ(又は、Ｅ−ＵＴＲＡＮ)は、ＲＲＣ接続再設定要求メッセージの内容を確認した後、ＲＲＣ接続再設定が可能であると判断されると、ＲＲＣ接続再設定のためにＲＲＣ接続再設定メッセージ(ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ)をＵＥに送信する(Ｓ６２０)。ＲＲＣ接続再設定メッセージは、ＳＲＢ１を再構成し、このＳＲＢにのみ該当するデータ送信を再開始する手順、セキュリティアルゴリズムの変更なくＡＳセキュリティを再活性化する手順などを実行するために必要な情報を含む。
【００９１】
ＲＲＣ接続再設定メッセージを受信したＵＥは、前述したＲＲＣ再設定メッセージ内の情報を利用してＳＲＢ１を再構成し、このＳＲＢ(ＳＲＢ１)にのみ該当するデータ送信を再開始する手順、セキュリティアルゴリズムの変更なくＡＳセキュリティを再活性化する手順などを実行する。
【００９２】
前述した手順の進行が完了した後、ＵＥは、ｅＮＢ(又は、Ｅ−ＵＴＲＡＮ)にＲＲＣ接続再設定完了メッセージ(ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃｏｍｐｌｅｔｅ)を送信する(Ｓ６３０)。
【００９３】
前述したように、ＵＥは、ＲＲＣ接続再設定手順を介してＲＬＦ情報をＥ−ＵＴＲＡＮ(又は、ｅＮＢ)側に伝達することができ、Ｅ−ＵＴＲＡＮ(又は、ｅＮＢ)側は、ＲＬＦが発生したＵＥから関連した情報を取得することができる。
【００９４】
一方、このようにＥ−ＵＴＲＡＮ側に報告されたＲＬＦ情報は、ＲＬＦ指示手順又はハンドオーバ報告などを介して関連したｅＮＢに伝達されてもよい。
【００９５】
まず、ＵＥから報告されたＲＬＦ報告がネットワーク内のｅＮＢ間に伝達されることに対して説明する。
【００９６】
図７は、本発明が適用されるＲＬＦ指示(ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ)を概略的に説明する図面である。ＲＬＦ指示を実行する目的は、前述したＲＲＣ接続再設定要求と関連した情報をＥ−ＵＴＲＡＮ内でＸ２インターフェースを介してＲＬＦが発生したｅＮＢを含むｅＮＢに伝達することによって、ネットワーク内でＵＥの移動性を改善するためである。
【００９７】
図７を参照すると、ＵＥ７１０は、ｅＮＢ７２０と図６で説明したＲＲＣ接続再設定手順Ｓ７１０〜Ｓ７３０を実行する。
【００９８】
ＲＲＣ接続再設定が完了した後、ｅＮＢ７２０は、ＵＥ７１０から受信したＰＣＩ情報を利用してＵＥ７１０の‘以前サービングセル又はｅＮＢ’(以下、説明の便宜のために、‘以前ｅＮＢ’という)を確認することができる(Ｓ７４０)。
【００９９】
ｅＮＢ７２０は、ＵＥ７１０から受信したＰＣＩに適するｅＮＢ７３０にＲＬＦ指示メッセージ(ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ)を送信する(Ｓ７５０)。このとき、ＲＬＦ指示メッセージは、ｅＮＢ間のＸ２インターフェースを介して伝達され、Ｃ−ＲＮＴＩのようなＵＥ７１０に対する識別子を含んでもよい。
【０１００】
ＵＥ７１０の以前ｅＮＢ７３０は、ｅＮＢ７２０から受信したＵＥ識別子と自分が保有しているＵＥのコンテクストが一致すると、ＲＲＣ接続再設定以前に発生したＵＥ７１０とｅＮＢ７３０との間のＲＬＦに対する原因を分析する。
【０１０１】
ＵＥ７１０は、分析を介してＲＬＦの原因を解消することによって、ネットワーク品質とＵＥの移動性を改善することができる。
【０１０２】
図７ではＵＥ７１０とｅＮＢ７２０との間のＲＲＣ接続再設定が完了した後にｅＮＢ７２０がｅＮＢ７３０にＲＬＦ指示を送信すると説明したが、これはＲＬＦ指示の一例として説明したものに過ぎず、前述と違って、ｅＮＢ７２０がＵＥ７１０からＲＲＣ接続再設定要求メッセージを受信してＰＣＩ情報を取得した後にはＲＲＣ接続再設定完了以前であるとしもｅＮＢ７３０にＲＬＦ指示を送信してもよい。
【０１０３】
図８は、本発明が適用されるハンドオーバ報告に対して概略的に説明する図面である。
【０１０４】
ｅＮＢ間のハンドオーバ報告は、成功的なハンドオーバ以後にすぐに発生するＲＬＦ情報をＥ−ＵＴＲＡＮ内のＸ２インターフェースを介して伝達することによって、ＵＥのネットワーク内の移動性を改善するために実行される。例えば、ハンドオーバ手順があまりにも速く完了してターゲット基地局が予め対応できない場合には、発生したＲＬＦ情報をハンドオーバ報告手順を介してｅＮＢ間に共有してもよい。参考として、遅延したハンドオーバによって発生したＲＬＦの場合にはＲＬＦ情報が前述したＲＬＦ指示手順を介してｅＮＢ間に共有されてもよい。
【０１０５】
図８を参照すると、ＵＥ８１０とｅＮＢ８２０との間にハンドオーバ手順が実行される(Ｓ８１０)。前述したように、ハンドオーバが成功的に実行された後にＲＬＦがすぐに発生してもよい。
【０１０６】
この場合、ＲＬＦを復旧し、無線リンクを再設定したｅＮＢ(元来のターゲットｅＮＢ)８２０は、関連したｅＮＢ８３０にＲＬＦ情報が含まれているハンドオーバ報告を送信する(Ｓ８２０)。このとき、関連したｅＮＢは、元来のソースｅＮＢ、ＵＥ８１０から受信したＰＣＩにより確認されるソースセル及び/又はターゲットセル、ＲＲＣ接続再設定が発生したセルなどを含む。
【０１０７】
ハンドオーバ報告に含まれているＲＬＦ情報は、ハンドオーバ時にＲＬＦを発生させた移動の失敗(ｍｏｂｉｌｉｔｙ ｆａｉｌｕｒｅ)の可能な根本原因、例えば、あまりにも速いハンドオーバ(Ｔｏｏ Ｅａｒｌｙ Ｈａｎｄｏｖｅｒ)、誤ったセルへのハンドオーバ(Ｈａｎｄｏｖｅｒ ｔｏ Ｗｒｏｎｇ Ｃｅｌｌ)を指示する情報を含んでもよい。
【０１０８】
以下、ＵＥが保有しているＲＬＦ情報がＲＲＣ接続再設定以後にＥ−ＵＴＲＡＮに伝達されることについて説明する。このＵＥ情報提供手順(ＵＥ ＩｎｆｏｒｍａｔｉｏｎＰｒｏｃｅｄｕｒｅ)により伝達されたＲＬＦ情報は、ＲＬＦ指示又はハンドオーバ報告などを介してＲＬＦが発生したｅＮＢを含めてＥ−ＵＴＲＡＮ内のｅＮＢ間に共有される。
【０１０９】
図９は、本発明が適用されるＵＥ情報提供(ＵＥ Ｉｎｆｏｒｍａｔｉｏｎ)手順を概略的に説明するフローチャートである。
【０１１０】
Ｅ−ＵＴＲＡＮは、ＵＥ情報提供要求メッセージ(ＵＥ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ)をＵＥに送信する(Ｓ９１０)。ＵＥ情報提供要求メッセージは、Ｅ−ＵＴＲＡＮがＵＥから情報を検索(ｒｅｔｒｉｅｖｅ)するために一般的に利用するメッセージである。ＵＥ情報提供要求メッセージは、ＳＲＢ１を利用し、ＲＬＣ(Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ)−ＳＡＰ(Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ)に対してはＡＭ(Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ)を有して論理チャネルＤＣＣＨ(Ｄｅｄｉｃａｔｅｄ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ)上にＲＲＣシグナリングを介して送信される。
【０１１１】
表２は、ＵＥ情報提供要求メッセージの一例を示す。
【０１１２】
【表２】
0005747120.tif 000003
【０１１３】
表２のＵＥ情報提供要求メッセージで、ｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑは、ログされた(ｌｏｇｇｅｄ)測定情報の報告可否を指示するフィールドである。ＵＥは、無線通信環境の状態を測定するたびにログを引き続き蓄積して新たなログ形態で格納することができ、ＵＥは、現在自分がＭＤＴ実行を介して蓄積されたログ(Ｌｏｇ)を有している状態であることをｅＮＢに報告してもよい。例えば、ログされた測定情報は、ＵＥが運転テスト最小化(Ｍｉｎｉｍｉｚａｔｉｏｎ ＤｒｉｖｉｎｇＴｅｓｔ；ＭＤＴ、以下、‘ＭＤＴ’という)を実行するために別途に構成された測定方式に基づいて測定された情報で作成されることができる。ＭＤＴは、車両などを用いて直接セル内の全ての地域を移動しながら通話品質を測定せずに、セル内の通話品質など、ネットワーク環境に対して測定する方法である。また、ｒｌｆ−ＲｅｐｏｒｔＲｅｑは、ＲＬＦ関連情報の報告可否を指示するフィールドである。
【０１１４】
図１０は、本発明が適用されるＭＤＴの基本概念を概略的に説明する図面である。
【０１１５】
図１０を参照すると、セル内の通話品質は、建物１０３０の配置や地形によって変化する。通話影地域１０６０があり、通話可能地域中にも通話品質が良い地域１０４０と通話品質が良くない地域１０５０がある。セル内の通信状況、例えば、通話品質を測定する時、セル内に散在した複数のＵＥ１０００を利用することによって、測定車両１０１０は、最小限の経路１０２０のみ移動すればよい。
【０１１６】
移動する車両１０１０で実行する測定の外、無線環境に対する測定は、セル内の多様な所にある複数のＵＥで実行される。各々のＵＥは、ＭＤＴ設定によって現在位置での無線環境を測定してもよい。ＵＥは、測定結果をログで作成して格納してもよい。
【０１１７】
また、ＵＥ情報提供要求メッセージのフィールドに対する説明において、ｒａｃｈ−ＲｅｐｏｒｔＲｅｑは、ＵＥがランダムアクセス手順に対する情報を報告すべきかどうかを指示するフィールドである。
【０１１８】
ａｂｓｏｌｕｔｅＴｉｍｅＳｔａｍｐは、測定ロギング(ｌｏｇｇｉｎｇ)が設定された絶対的時間（ａｂｓｏｌｕｔｅｔｉｍｅ）を指示するものであり、Ｅ−ＵＴＲＡＮからａｂｓｏｌｕｔｅＴｉｍｅＩｎｆｏメッセージに含まれて提供される。
【０１１９】
ｃｏｎｔｅｎｔｉｏｎＤｅｔｅｃｔｅｄは、送信されたプリアンブルのうち少なくとも一つに対するコンテンション(ｃｏｎｔｅｎｔｉｏｎ)が検知(ｄｅｔｅｃｔ)されたということを指示するフィールドである。
【０１２０】
ｆａｉｌｅｄＰＣｅｌｌＩｄは、ＲＬＦが検知されたプライマリセル(ＰＣｅｌｌ)や失敗したハンドオーバに対するターゲットＰＣｅｌｌを指示するフィールドである。
【０１２１】
ｍｅａｓＲｅｓｕｌｔＬａｓｔＳｅｒｖＣｅｌｌは、ＲＬＦが発生した主セルで実行された最後の測定結果を参照するフィールドである。
【０１２２】
ｎｕｍｂｅｒＯｆＰｒｅａｍｂｌｅｓＳｅｎｔは、送信されたＲＡＣＨプリアンブルの個数を指示するフィールドである。
【０１２３】
ｐｒｅｖｉｏｕｓＰＣｅｌｌＩｄは、最後のハンドオーバのソースプライマリセル(Ｓｏｕｒｃｅ ＰＣｅｌｌ)を指示するフィールドであり、ソースプライマリセルは、ｍｏｂｉｌｉｔｙｃｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎを含む最後のＲＲＣ−ＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信したときのソースプライマリセルである。
【０１２４】
ｒｅｌａｔｉｖｅＴｉｍｅＳｔａｍｐは、ロギング測定結果を得た時間を指示するものであり、ａｂｓｏｌｕｔｅＴｉｍｅＳｔａｍｐに対する相対的である値として測定され、秒単位の値を有する。
【０１２５】
ｔｒａｃｅＲｅｆｅｒｅｎｃｅは、ＬｏｇｇｅｄＭｅａｓｕｒｅｍｅｎｔＣｏｎｆｉｇｕｒａｔｉｏｎを介して受信したｔｒａｃｅＲｅｆｅｒｅｎｃｅパラメータを指示する。
【０１２６】
ｔｒａｃｅＲｅｃｏｒｄｉｎｇＳｅｓｓｉｏｎは、ＬｏｇｇｅｄＭｅａｓｕｒｅｍｅｎｔＣｏｎｆｉｇｕｒａｔｉｏｎを介して受信したｔｒａｃｅＲｅｃｏｄｉｎｇＳｅｓｓｉｏｎパラメータを指示する。
【０１２７】
一方、無線通信技術が発達するにつれて既存に構築されたシステムと新たに構築されたシステムとの間の互換性が問題になる。即ち、新たに構築されたシステムは、既存の方式を全部サポートしながらシステムを運用することができるが、既存の構築されたシステムは、新たな方式をサポートできない場合がある。したがって、システム上で送受信されるメッセージにも既存システムでサポートされる内容であるかどうかを表示する必要がある。
【０１２８】
表２の場合にはフィールド名と共にｒ９とｒ１０を表示し、該当技術がサポートされる技術のバージョン又はリリースを示している。例えば、表２の例によると、ｒ９で表示されたフィールドは、既存のシステムと新たなシステムで全部認識されることができるが、ｒ１０で表示されたフィールドは、新たなシステムでのみ認識され、既存のシステムでは認識されることができない。
【０１２９】
本明細書では表２で例示した技術バージョン又は技術リリースの表示方法を維持しながら本発明に対して説明する。ここでは技術バージョンを示す一例を共に表示して実施例の具体性を加えているが、技術バージョンの表示によって本発明の技術的思想が変わったり制限されるものではないことに留意する。
【０１３０】
ＵＥ情報提供要求メッセージを受信したＵＥは、ＵＥ情報提供応答メッセージ(ＵＥ ＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅ)を構成してＥ−ＵＴＲＡＮに送信する(Ｓ９２０)。
【０１３１】
ＵＥ情報提供応答メッセージは、Ｅ−ＵＴＲＡＮにより要求された情報を送信するためにＵＥが利用するメッセージであり、ＳＲＢ１を利用するが、ログされた情報を送信する場合にはＳＲＢ２を利用する。ＵＥ情報提供応答メッセージは、ＲＬＣ−ＳＡＰに対するモードとしてＡＭを有して論理チャネルＤＣＣＨ上にＲＲＣシグナリングを介して送信される。
【０１３２】
表３は、ＵＥ情報提供応答メッセージの一例を示す。
【０１３３】
【表３】
0005747120.tif 000004
0005747120.tif 000005
【０１３４】
ＵＥ情報提供応答メッセージは、ＵＥ情報提供要求メッセージの各フィールドに対応して構成されることができる。以下、ＵＥがＵＥ情報提供応答メッセージを構成する方法に対して説明する。
【０１３５】
(１)ｒａｃｈ−Ｒｅｐｏｒｔ
【０１３６】
ＵＥ情報提供要求メッセージ上のｒａｃｈ−ＲｅｐｏｒｔＲｅｑが‘ｔｒｕｅ’に設定されている場合、これに対応するＵＥ情報提供応答メッセージ上のｒａｃｈ−Ｒｅｐｏｒｔは、下記の通り設定される。
【０１３７】
ｎｕｍｂｅｒＯｆＰｒｅａｍｂｌｅｓＳｅｎｔを設定する。ｎｕｍｂｅｒＯｆＰｒｅａｍｂｌｅｓＳｅｎｔは、成功的に完了した最後のランダムアクセス手順に対してＭＡＣにより送信されたプリアンブルの個数を指示する。
【０１３８】
ＣｏｎｔｅｎｔｉｏｎＤｅｔｅｃｔｅｄを設定する。成功的に完了した最後のランダムアクセス手順で少なくとも一つのプリアンブルに対してもコンテンション解決に成功することができない場合にはｃｏｎｔｅｎｔｉｏｎＤｅｔｅｃｔｅｄを‘ｔｒｕｅ’に設定する。その他の場合にはｃｏｎｔｅｎｔｉｏｎＤｅｔｅｃｔｅｄを‘ｆａｌｓｅ’に設定する。
【０１３９】
(２)ｒｌｆ−Ｒｅｐｏｒｔ
【０１４０】
ＵＥ情報提供要求メッセージ上のｒｌｆ−ＲｅｐｏｒｔＲｅｑが‘ｔｒｕｅ’に設定されており、ＵＥがＲＬＦ情報又はハンドオーバ失敗情報をＶａｒＲＬＦ−Ｒｅｐｏｒｔに保有しており、ＶａｒＲＬＦ−Ｒｅｐｏｒｔに格納されているｐｌｍｎ−Ｉｄｅｎｔｉｔｙ値がＲ−ＰＬＭＮ(Ｒｅｇｉｓｔｅｒｅｄ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ)と同じ場合、ＵＥ情報提供応答メッセージにｒｌｆ−Ｒｅｐｏｒｔを含む。このとき、ｒｌｆ−Ｒｅｐｏｒｔの値は、ＵＥが保有したＶａｒＲＬＦ−Ｒｅｐｏｒｔのｒｌｆ−Ｒｅｐｏｒｔ値と同じに設定される。
【０１４１】
表４は、ＵＥが保有したＶａｒＲＬＦ−Ｒｅｐｏｒｔの一例を示す。
【０１４２】
【表４】
0005747120.tif 000006
【０１４３】
ＵＥは、ＲＬＦに対する情報を取得してＲＬＦ−Ｒｅｐｏｒｔのサブフィールドに該当情報を格納してもよい。
【０１４４】
ｒｌｆ−Ｒｅｐｏｒｔが含まれているＵＥ情報提供応答メッセージが成功的に送信された場合、ＵＥは、保有しているＶａｒＲＬＦ−Ｒｅｐｏｒｔ内のｒｌｆ−Ｒｅｐｏｒｔ値を削除(ｄｉｓｃａｒｄ)する。このとき、ｒｌｆ−Ｒｅｐｏｒｔが含まれているＵＥ情報提供応答メッセージが成功的に送信されかどうかは、下位レイヤ(Ｌ１又はＬ２)により確認してもよい。
【０１４５】
(３)ｌｏｇＭｅａｓＲｅｐｏｒｔ
【０１４６】
ＵＥ情報提供要求メッセージにｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑが含まれており、ＵＥが保有しているＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔに格納されたｐｌｍｎ−ｉｄｅｎｔｉｔｙ値がＲ−ＰＬＭＮと同じであり、ＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔが一つ又は複数のログされた(ｌｏｇｇｅｄ)測定エントリ(ｅｎｔｒｙ)を含む場合、ＵＥ情報提供応答メッセージ内のｌｏｇＭｅａｓＲｅｐｏｒｔに対するコンテンツを下記のように設定する。
【０１４７】
表５は、ＵＥが格納しているＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔの一例を示す。
【０１４８】
【表５】
0005747120.tif 000007
【０１４９】
ＵＥは、ＭＤＴを介して取得したログをＬｏｄＭｅａｓＩｎｆｏのサブフィールドに格納してもよい。
【０１５０】
ｌｏｇＭｅａｓＲｅｐｏｒｔにａｂｓｏｌｕｔｅＴｉｍｅＳｔａｍｐを含ませる。ａｂｓｏｌｕｔｅＴｉｍｅＳｔａｍｐの値は、ＵＥが保有するＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔのａｂｓｏｌｕｔｅＴｉｍｅＩｎｆｏ値と同じに設定する。
【０１５１】
ｌｏｇＭｅａｓＲｅｐｏｒｔにｔｒａｃｅＲｅｆｅｒｅｎｃｅを含ませる。ｔｒａｃｅＲｅｆｅｒｅｎｃｅの値は、ＵＥが保有するＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔのｔｒａｃｅＲｅｆｅｒｅｎｃｅ値と同じに設定する。
【０１５２】
ｌｏｇＭｅａｓＲｅｐｏｒｔにｔｒａｃｅＲｅｃｏｒｄｉｎｇＳｅｓｓｉｏｎを含ませる。ｔｒａｃｅＲｅｃｏｒｄｉｎｇＳｅｓｓｉｏｎの値は、ＵＥが保有するＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔのｔｒａｃｅＲｅｃｏｒｄｉｎｇＳｅｓｓｉｏｎ値と同じに設定する。
【０１５３】
ｌｏｇＭｅａｓＲｅｐｏｒｔにｌｏｇＭｅａｓＩｎｆｏＬｉｓｔを含ませる。ＵＥが保有するＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔのログされた(ｌｏｇｇｅｄ)エントリのうち１番目のエントリから一つ又は複数のエントリを含むようにｌｏｇＭｅａｓＩｎｆｏＬｉｓｔを設定する。
【０１５４】
このとき、ＵＥが保有するＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔが空いていない場合、即ち、ＭＤＴなどの測定により作成されたログを利用することができる状態の場合、ｌｏｇＭｅａｓＲｅｐｏｒｔにｌｏｇＭｅａｓＡｖａｉｌａｂｌｅを追加し、その値を‘ｔｒｕｅ’に設定する。
【０１５５】
ｌｏｇＭｅａｓＲｅｐｏｒｔを含むＵＥ情報提供応答メッセージが成功的に送信される場合、ＵＥが保有したＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔ内のｌｏｇＭｅａｓＩｎｆｏＬｉｓｔ値に含まれているログされた(ｌｏｇｇｅｄ)測定エントリを除去(ｄｉｓｃａｒｄ)する。ＵＥ情報提供応答メッセージが成功的に送信されたかどうかは、下位レイヤ(Ｌ１又はＬ２)を介して確認することができる。
【０１５６】
一方、ログ情報は、ＳＲＢ２を介して伝達される。したがって、ＵＥ情報提供応答メッセージもログ情報を含んでいるかどうかにより、ＳＲＢ１を介して伝達されるか又はＳＲＢ２を介して伝達されるかが定められることができる。例えば、ＵＥ情報提供応答メッセージがｌｏｇＭｅａｓＲｅｐｏｒｔを含む場合、ＵＥ情報提供応答メッセージは、ＳＲＢ２を介して下位レイヤに送られる。ＵＥ情報提供応答メッセージがｌｏｇＭｅａｓＲｅｐｏｒｔを含まない場合、ＵＥ情報提供応答メッセージは、ＳＲＢ１を介して下位レイヤに送られる。
【０１５７】
以下、前述した機器内共存干渉(Ｉｎ−Ｄｅｖｉｃｅ Ｃｏｅｘｉｓｔｅｎｃｅ ｉｎｔｅｒｆｅｒｅｎｃｅ：ＩＤＣ)とＲＬＦ報告(ＲＬＦＲｅｐｏｒｔ)に関して説明する。
【０１５８】
ＲＬＦは、ネットワーク状態によって生成さてもよいが、機器内の他のモデム(例えば、ＷＬＡＮ、Ｂｌｕｅｔｏｏｔｈ、ＧＰＳ等に対するモデム)による干渉電力によって、即ち、機器内共存干渉によっても生成されてもよい。
【０１５９】
機器内共存干渉によるＲＬＦ(以下、説明の便宜のために‘ＩＣＯ−ＲＬＦ’という)に対する情報もＵＥ情報提供応答メッセージに含んで送信してもよい。
【０１６０】
ＵＥ情報提供応答メッセージに含まれるＩＣＯ−ＲＬＦ情報は、(１)機器内共存干渉によりＲＬＦの発生と共に、機器内の他の送受信装置(モデム)の受信電力と干渉電力値を含むように構成してもよく、(２)機器内共存干渉によりＲＬＦの発生と共に機器内の他の送受信装置による干渉発生可否のみを含むように構成してもよい。
【０１６１】
ここで、他の送受信装置は、ＬＴＥシステムに対する送受信装置と共にＵＥ内に備えられた送受信装置であり、ＬＴＥシステム外の無線通信システムに対する送受信装置を意味する。
【０１６２】
以下、ＵＥがＩＣＯ−ＲＬＦ情報を送信することに対して、ＵＥ情報提供要求メッセージ上にｒｌｆ−ＲｅｐｏｒｔＲｅｑを受信してＩＣＯ−ＲＬＦ情報を送信する場合と、ＭＤＴに対するｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑを受信してＩＣＯ−ＲＬＦ情報を送信する場合と、に分けて説明する。
【０１６３】
(１)ＵＥがｒｌｆ−ＲｅｐｏｒｔＲｅｑを受信した場合
【０１６４】
表６は、本発明が適用されるシステムにおいて、ＵＥがｒｌｆ−ＲｅｐｏｒｔＲｅｑを受信し、これに対する応答としてｅＮＢ又はＥ−ＵＴＲＡＮに送信する無線通信障害に関する情報を示す一実施例である。表６は、ＩＣＯ−ＲＬＦ情報がＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを報告するために使用される例を示す。
【０１６５】
【表６】
0005747120.tif 000008
【０１６６】
表６ではｍｅａｓＲｅｓｕｌｔＩＤＣを介してＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを指示する。例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣの値がＴｒｕｅの場合、ＵＥ内の他の送受信装置による干渉の影響があることを示し、ｍｅａｓＲｅｓｕｌｔＩＤＣの値がＦａｌｓｅの場合、ＵＥ内の他の送受信装置による干渉の影響がないことを示するようにすることができる。
【０１６７】
表６において、ｍｅａｓＲｅｓｕｌｔＩＤＣは、任意(ｏｐｔｉｏｎａｌ)に追加されてもよく、したがって、ＵＥ内の他の送受信装置による干渉の影響がある場合にのみ設定されるようにしてもよい。
【０１６８】
表６の場合と違って、ＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを送受信装置別に報告してもよい。
【０１６９】
表７は、本発明が適用されるシステムにおいて、ＵＥがｒｌｆ−ＲｅｐｏｒｔＲｅｑを受信し、これに対する応答としてｅＮＢ又はＥ−ＵＴＲＡＮに送信する無線通信障害に対する情報を示す他の実施例である。表７は、ＩＣＯ−ＲＬＦ情報がＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを送受信装置別に報告するために使用される例を示す。
【０１７０】
【表７】
0005747120.tif 000009
【０１７１】
表７のＲＬＦ報告では、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドを介してＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを指示することができる。例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドを介してＵＥ内の他の送受信装置による干渉電力があるかどうかを送受信装置別に指示することができる。
【０１７２】
具体的に、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドの各サブフィールドの値がＴｒｕｅであるかＦａｌｓｅであるかを介してＵＥ内の他の送受信装置別に干渉電力の影響があったかどうかを示してもよい。例えば、ｍｅａｓＲｅｓｕｌｔＷＬＡＮフィールドの値がｔｒｕｅの場合、ＷＬＡＮシステムの送受信装置による干渉電力の影響があるということを示し、ｍｅａｓＲｅｓｕｌｔＷＬＡＮフィールドの値がｆａｌｓｅの場合、ＷＬＡＮシステムの送受信装置による干渉電力の影響がないということを示すものとしてもよい。
【０１７３】
同様に、ｍｅａｓＲｅｓｕｌｔＢＴフィールドの値がｔｒｕｅの場合、ＢＴ（Ｂｌｕｅｔｏｏｔｈ）システムの送受信装置による干渉電力の影響があるということを示し、ｍｅａｓＲｅｓｕｌｔＢＴフィールドの値がｆａｌｓｅの場合、ＢＴシステムの送受信装置による干渉電力の影響がないということを示すものとしてもよい。
【０１７４】
また、ｍｅａｓＲｅｓｕｌｔＧＰＳフィールドの値がｔｒｕｅの場合、ＧＰＳ送受信装置による干渉電力の影響があるということを示し、ｍｅａｓＲｅｓｕｌｔＧＰＳフィールドの値がｆａｌｓｅの場合、ＧＰＳ送受信装置による干渉電力の影響がないということを示すものとしてもよい。
【０１７５】
このとき、ＵＥ内の他の送受信装置のうちいずれの送受信装置による干渉であるかを明確に判断することができない場合にはｍｅａｓＲｅｓｕｌｔＯｔｈｅｒフィールドを介して干渉電力の影響があったかどうかを示してもよい。ｍｅａｓＲｅｓｕｌｔＯｔｈｅｒの値がｔｒｕｅの場合、いずれのシステムの送受信装置による干渉電力の影響であるかは区分することができないが、干渉電力の影響があるということを示したり、二つ以上の送受信装置による干渉電力の影響が存在するということを示すものとしてもよい。
【０１７６】
一方、ｍｅａｓＲｅｓｕｌｔＩＤＣのサブフィールドの値がｔｒｕｅであるかｆａｌｓｅであるかを介して該当サブフィールドに対応する通信システムの送受信装置による干渉電力の影響があったかどうかを指示せずに、各通信システムに対するサブフィールド、例えば、ｍｅａｓＲｅｓｕｌｔＷＬＡＮ、ｍｅａｓＲｅｓｕｌｔＢＴ、ｍｅａｓＲｅｓｕｌｔＧＰＳ、ｍｅａｓＲｅｓｕｌｔＯｔｈｅｒを任意に設定してもよい。即ち、該当通信システムの送受信装置による干渉電力の影響がある場合、又はいずれのシステムの送受信装置によるかを区分することができない干渉電力や二つ以上の送受信装置による干渉電力の影響が存在する場合にのみ、対応するサブフィールドを設定するようにしてもよい。測定された受信電力及び/又は干渉電力がいずれの送受信装置に対することかをＵＥが区別することができる場合にはＭｅａｓＲｅｓｕｌｔＯｔｈｅｒフィールドを設定せずに、該当送受信装置に対するフィールドで測定した受信電力及び/又は干渉電力に対して指示することができることはもちろんである。
【０１７７】
また、表７において、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドは、任意に設定してもよい。この場合、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドは、ＵＥ内の他の送受信装置による干渉電力の影響がある場合にのみ設定するようにすることができる。
【０１７８】
表７の場合と違って、ＵＥ内の他の送受信装置の受信電力及び/又は干渉電力値を全部報告するようにしてもよい。
【０１７９】
表８は、本発明が適用されるシステムにおいて、ＵＥがｒｌｆ−ＲｅｐｏｒｔＲｅｑを受信し、これに対する応答としてｅＮＢ又はＥ−ＵＴＲＡＮに送信する無線通信障害に関する情報を示す他の実施例である。表８は、ＩＣＯ−ＲＬＦ情報がＵＥ内の他の送受信装置の受信電力及び/又は干渉電力値を含む例を示す。
【０１８０】
【表８】
0005747120.tif 000010
【０１８１】
表８のＲＬＦ報告でも、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドを介してＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを示すことができる。例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドを介してＵＥ内の他の送受信装置による干渉電力があるかどうかを送受信装置別に示することができる。
【０１８２】
表８の場合には表７の場合と違って、各サブフィールドが対応する通信システムに対する測定結果を介して該当する通信システムの送受信装置による干渉電力の影響があったかどうかを示すようにすることができる。
【０１８３】
具体的に、表８のＲＬＦ報告では、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドの各サブフィールドを介してＵＥ内の他の送受信装置別測定値を示すようにしてもよい。
【０１８４】
例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドであるｍｅａｓＲｅｓｕｌｔＷＬＡＮが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＷＬＡＮを示し、ＭｅａｓＲｅｓｕｌｔＷＬＡＮのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＷＬＡＮ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＷＬＡＮ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＷＬＡＮ、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＷＬＡＮ等を介して測定結果を示されてもよい。
【０１８５】
同様に、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドであるｍｅａｓＲｅｓｕｌｔＢＴが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＢＴを示し、ＭｅａｓＲｅｓｕｌｔＢＴのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＢＴ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＢＴ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＢＴ、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＢＴ、ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎ_ｌｅｎｇｔｈ、ＢＴ_Ｈｏｐｐｉｎｇ_Ｐａｔｔｅｒｎ等を介して測定結果を示すようにすることができ、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドであるｍｅａｓＲｅｓｕｌｔＧＰＳが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＧＰＳを示し、ＭｅａｓＲｅｓｕｌｔＧＰＳのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＧＰＳ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＧＰＳ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＧＰＳ、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＧＰＳ等を介して測定結果を示ようにすることができる。
【０１８６】
このとき、いずれのシステムの送受信装置によることかを区分することができない干渉電力や二つ以上の送受信装置による干渉電力に対しては、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドとしてｍｅａｓＲｅｓｕｌｔＯｔｈｅｒが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＯｔｈｅｒを指示し、ＭｅａｓＲｅｓｕｌｔＯｔｈｅｒのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＯｔｈｅｒ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＯｔｈｅｒ_Ｒｅｓｕｌｔ等を介して測定結果を示すようにすることができる。
【０１８７】
以下、表８において、ＵＥ内のＷＬＡＮ送受信装置に対して測定値を各フィールドに対して説明する。
【０１８８】
ＵＥ内のＷＬＡＮシステムに対するフィールド
【０１８９】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＷＬＡＮ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式（ｓｉｇｎａｌ  ｍｅａｓｕｒｅｍｅｎｔ  ｍｅｔｈｏｄ）を介して、現時点において無線通信システムの帯域内で受信されたＷＬＡＮ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＷＬＡＮ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＰ(Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ)範囲(ｒａｎｇｅ)で表現されるように特定されてもよい。
【０１９０】
例えば、前記ＲＳＲＰ−ｒａｎｇｅは、整数値０〜９７のうち一つに設定されてもよく、各ＲＳＲＰ−ｒａｎｇｅ値は、表９により定義された値に対応される。
【０１９１】
【表９】
0005747120.tif 000011
【０１９２】
ＲｅｃｅｉｖｅｄＱｕａｌＷＬＡＮ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現時点において無線通信システムの帯域内で受信された全ての受信信号の受信電力強度に対する現在無線通信システムの帯域内で受信されたＷＬＡＮ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＱｕａｌＷＬＡＮ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＱ(Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ)範囲(ｒａｎｇｅ)で表現されるように特定されてもよい。
【０１９３】
例えば、前記ＲＳＲＱ−ｒａｎｇｅは、整数値０〜３４のうち一つに設定されてもよく、各ＲＳＲＱ−ｒａｎｇｅ値は、表１０により定義された値に対応する。
【０１９４】
【表１０】
0005747120.tif 000012
【０１９５】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＷＬＡＮは、現在ＷＬＡＮシステムで運用する信号測定方式を介して、現時点において無線通信システム(ＬＴＥ)の帯域内で受信されたＷＬＡＮ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＷＬＡＮ値を表現する方式は特定されてもよく、例えば、ＷＬＡＮシステムにおいて受信電力の測定に使われる値の範囲(ＷＬＡＮ_ＲＰ−ｒａｎｇｅ)で表現されるように特定されてもよい。
【０１９６】
ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＷＬＡＮは、現在ＷＬＡＮシステムで運用する信号測定方式を介して、現時点において無線通信システム(ＬＴＥ)の帯域内で受信された全ての受信信号の受信電力強度に対する現在無線通信システムの帯域内で受信されたＷＬＡＮ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＷＬＡＮ値を表現する方式は特定されることができ、例えば、ＷＬＡＮシステムにおいて受信品質の測定に使われる値の範囲(ＷＬＡＮ_ＲＱ−ｒａｎｇｅ)で表現されるように特定されてもよい。
【０１９７】
ＵＥ内のＢＴシステムに対するフィールド
【０１９８】
ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎ_ｌｅｎｇｔｈは、現在ＵＥの内部で動作するＢＴ装置が使用する周波数ホッピング(ｆｒｅｑｕｅｎｃｙ ｈｏｐｐｉｎｇ)パターンの長さを示す。ホッピングパターンの長さは、ＢＴ規格により決定されてもよく、例えば、指定された範囲の整数値を有するようにすることができる。反面、ＢＴ規格で使用する周波数ホッピングパターンをインデックス形式で示すことができる場合、前記ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎ_ｌｅｎｇｔｈフィールドは、インデックス値を示すためのフィールドと認識されて使われてもよい。この場合、ＵＥは、ＢＴ規格で使用されるインデックスと対応する周波数ホッピングパターン情報を予め知っている。
【０１９９】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＢＴ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現時点において無線通信システムの帯域内で受信されたＢＴ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＢＴ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＰ−ｒａｎｇｅで表現されるように特定されてもよい。
【０２００】
ＲｅｃｅｉｖｅｄＱｕａｌＢＴ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現時点において無線通信システムの帯域内で受信された全ての受信信号の受信電力強度に対する現時点において無線通信システムの帯域内で受信されたＢＴ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＱｕａｌＢＴ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＱ−ｒａｎｇｅで表現されるように特定されてもよい。
【０２０１】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＢＴは、現在ＢＴシステムで運用する信号測定方式を介して、現時点において無線通信システム(ＬＴＥ)の帯域内で受信されたＢＴ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＢＴ値を表現する方式は特定されてもよく、例えば、ＢＴシステムにおいて、受信電力の測定に使われる値の範囲(ＢＴ_ＲＰ−ｒａｎｇｅ)で表現されるように特定されてもよい。
【０２０２】
ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＢＴは、現在ＢＴシステムで運用する信号測定方式を介して、現時点において無線通信システム(ＬＴＥ)の帯域内で受信された全ての受信信号の受信電力強度に対する現時点において無線通信システムの帯域内で受信されたＢＴ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＢＴ値を表現する方式は特定されてもよく、例えば、ＢＴシステムにおいて、受信品質の測定に使われる値の範囲(ＢＴ_ＲＱ−ｒａｎｇｅ)で表現されるように特定されてもよい。
【０２０３】
ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎは、現在ＵＥの内部で動作するＢＴ装置が使用する周波数ホッピング(ｈｏｐｐｉｎｇ)パターン情報を示す。このとき、ホッピングパターンの長さは、ＢＴ規格によって決定されてもよく、ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎが示すＢＴ装置の周波数ホッピングパターンは、ビットマップで表現されてもよい。例えば、ビット情報が‘１’である場合、予め定められた周波数帯域ほど＋（プラス）方向にホッピングすることを意味し、ビット情報が‘０’である場合、−（マイナス）方向にホッピングすることを意味することができる。または、２個のビット又はそれ以上のビットを１つのホッピングパターンを示すための一つのホッピング情報と判断してもよい。
【０２０４】
例えば、２個のビットを一つのホッピング情報と判断する場合、ホッピングを４ステップで表現することが可能であり(例えば、[００,０１,１０,１１]＝{−２,−１,１,２})４個のビットを一つのホッピング情報と判断する場合にはホッピングを１６ステップで表現することが可能である。前記ビットに対するホッピング情報は、現在ＩＣＯが発生する可能性のあるＵＥが存在し、認可帯域を使用する無線通信システム(ＬＴＥ)でＢＴ規格を参考にして独自に設定されてもよい。反面、ＢＴ規格で使用する周波数ホッピングパターンをインデックス形式で示す場合、前記ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎフィールドは使われない。
【０２０５】
ＵＥ内のＧＰＳシステムに対するフィールド
【０２０６】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＧＰＳ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現在無線通信システムの帯域内で受信されたＧＰＳ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＧＰＳ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＰ−ｒａｎｇｅで表現されるように特定されてもよい。
【０２０７】
ＲｅｃｅｉｖｅｄＱｕａｌＧＰＳ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現時点において無線通信システムの帯域内で受信された全ての受信信号の受信電力強度に対する現時点において無線通信システムの帯域内で受信されたＧＰＳ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＱｕａｌＧＰＳ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＱ−ｒａｎｇｅで表現されるように特定されてもよい。
【０２０８】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＧＰＳは、現在ＧＰＳシステムで運用する信号測定方式を介して、現時点において無線通信システム(ＬＴＥ)の帯域内で受信されたＧＰＳ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＧＰＳ値を表現する方式は特定されてもよく、例えば、ＷＬＡＮシステムにおいて、受信電力の測定に使われる値の範囲(ＧＰＳ_ＲＰ−ｒａｎｇｅ)で表現されるように特定されてもよい。
【０２０９】
ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＧＰＳは、現在ＧＰＳシステムで運用する信号測定方式を介して、現時点において無線通信システム(ＬＴＥ)の帯域内で受信された全ての受信信号の受信電力強度に対する現時点において無線通信システムの帯域内で受信されたＧＰＳ信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＧＰＳ値を表現する方式は特定されてもよくき、例えば、ＧＰＳシステムにおいて受信品質の測定に使われる値の範囲(ＧＰＳ_ＲＱ−ｒａｎｇｅ)で表現されるように特定されてもよい。
【０２１０】
その他のフィールド
【０２１１】
ＲｅｃｅｉｖｅｄＰｏｗｅｒＯｔｈｅｒ_Ｒｅｓｕｌｔは、いずれのシステムの送受信装置によるかを区分することができない干渉電力や二つ以上の送受信装置による干渉電力に対する測定値の示すのに使用されてもよい。ＲｅｃｅｉｖｅｄＰｏｗｅｒＯｔｈｅｒ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現時点において無線通信システムの帯域内で受信された信号のうちＬＴＥ信号を除いた信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＰｏｗｅｒＯｔｈｅｒ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＰ−ｒａｎｇｅで表現されるように特定されてもよい。
【０２１２】
ＲｅｃｅｉｖｅｄＱｕａｌＯｔｈｅｒ_Ｒｅｓｕｌｔは、いずれのシステムの送受信装置によることかを区分することができない干渉電力や二つ以上の送受信装置による干渉電力に対する測定値を示すのに使用されてもよい。ＲｅｃｅｉｖｅｄＱｕａｌＯｔｈｅｒ_Ｒｅｓｕｌｔは、現在無線通信システム(ＬＴＥ)で運用する信号測定方式を介して、現時点において無線通信システムの帯域内で受信された全ての受信信号の受信電力強度に対する現時点において無線通信システムの帯域内で受信された信号のうちＬＴＥ信号を除いた信号の受信電力強度を測定した値を示す。このとき、ＲｅｃｅｉｖｅｄＯｔｈｅｒＧＰＳ_Ｒｅｓｕｌｔ値を表現する方式は特定されてもよく、例えば、ＲＳＲＱ−ｒａｎｇｅで表現されるように特定されてもよい。
【０２１３】
一方、表８ではＵＥ内の他の送受信装置による干渉電力の影響を測定値を介して示すことを説明したが、これと違って、測定値が存在する場合にのみ、示されるべき測定値がオプションとして設定されるようにしてもよい。
【０２１４】
例えば、測定値を示すＲｅｃｅｉｖｅｄＰｏｗｅｒＷＬＡＮ_Ｒｅｓｕｌｔなどのフィールドをオプションとして設定することができる。即ち、該当測定を実行しない場合、測定値が０の場合又は測定値が意味のある閾値に達することができない場合などには対応するフィールドを設定しないようにしてもよい。
【０２１５】
また、ＵＥ内の特定通信システムの送受信装置に対するフィールド、例えば、ｍｅａｓＲｅｓｕｌｔＷＬＡＮ、ｍｅａｓＲｅｓｕｌｔＢＴ、ｍｅａｓＲｅｓｕｌｔＧＰＳ、ｍｅａｓＲｅｓｕｌｔＯｔｈｅｒ等もオプションとして設定されるようにしてよい。即ち、該当システムに対して測定を実行しない場合、測定値が０の場合又は測定値が意味のある閾値に達することができない場合などには対応するフィールドを設定しないようにしてもよい。
【０２１６】
また、ＵＥ内の他の通信システムの送受信装置に対するフィールド、例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣもオプションとして設定されるようにしてもよい。即ち、ＵＥ内の他の通信システムの送受信装置による干渉電力の影響がない場合やその影響が意味のある閾値に達することができない場合などにはｍｅａｓＲｅｓｕｌｔＩＤＣが設定されないようにしてもよい。
【０２１７】
(２)ＵＥがｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑを受信した場合
【０２１８】
表１１は、本発明が適用されるシステムにおいて、ＵＥがｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑを受信し、これに対する応答としてｅＮＢ又はＥ−ＵＴＲＡＮに送信する無線通信障害に関する情報を示す一実施例である。このとき、無線通信障害に関する情報は、ＵＥがＭＤＴを介してログした情報である。表１１は、ＩＣＯ−ＲＬＦ情報がＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを報告する例を示す。
【０２１９】
【表１１】
0005747120.tif 000013
【０２２０】
表１１ではｍｅａｓＲｅｓｕｌｔＩＤＣを介してＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを示す。例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣの値がＴｒｕｅの場合、ＵＥ内の他の送受信装置による干渉の影響があることを指示し、ｍｅａｓＲｅｓｕｌｔＩＤＣの値がＦａｌｓｅの場合、ＵＥ内の他の送受信装置による干渉の影響がないことを示すようにしてもよい。このとき、ｍｅａｓＲｅｓｕｌｔＩＤＣは、オプションとして(ｏｐｔｉｏｎａｌｙ)に追加されてもよく、したがって、ＵＥ内の他の送受信装置による干渉の影響がある場合にのみ設定されるようにすることもできる。
【０２２１】
表１１の場合と違って、ＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを送受信装置別に報告してもよい。
【０２２２】
表１２は、本発明が適用されるシステムにおいて、ＵＥがｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑを受信し、これに対する応答としてｅＮＢ又はＥ−ＵＴＲＡＮに送信する無線通信障害に関する情報を示す他の実施例である。この場合、無線通信障害に関する情報は、ＵＥがＭＤＴを介してログした情報である。表１０は、ＩＣＯ−ＲＬＦ情報がＵＥ内の他の送受信装置による別に干渉電力の影響があったかどうかを送受信装置別に報告する例を示す。
【０２２３】
【表１２】
0005747120.tif 000014
【０２２４】
表１２のＲＬＦ報告では、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドを介してＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを示す。例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドを介してＵＥ内の他の送受信装置による干渉電力があるかどうかを送受信装置別に示すことができる。具体的に、表７と同様に、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドの各サブフィールドの値がＴｒｕｅであるかＦａｌｓｅであるかを介してＵＥ内の他の送受信装置別に干渉電力の影響があったかどうかを示すことができる。
【０２２５】
一方、ＩＣＯ−ＲＬＦ情報としてＵＥ内の他の送受信装置による干渉電力の影響があったかどうかのみを報告する表１０の場合と違って、全ての受信電力又は干渉電力値、及びＵＥ内の他の全ての送受信装置の受信電力及び/又は干渉電力値を報告することが可能となる。
【０２２６】
表１３は、本発明が適用されるシステムにおいて、ＵＥがｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑを受信し、これに対する応答としてｅＮＢ又はＥ−ＵＴＲＡＮに送信する無線通信障害に対する情報を示す他の実施例である。表１３は、ＩＣＯ−ＲＬＦ情報がＵＥ内の他の送受信装置の受信電力及び/又は干渉電力値を含む例を示す。
【０２２７】
【表１３】
0005747120.tif 000015
【０２２８】
表１３のＲＬＦ報告でも、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドを介してＵＥ内の他の送受信装置による干渉電力の影響があったかどうかを示すことができる。例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドを介してＵＥ内の他の送受信装置による干渉電力があったかどうかを送受信装置別に示すことができる。表１３の場合には表１２の場合と違って、各サブフィールドが対応する通信システムに対する測定結果を介して該当する通信システムの送受信装置による干渉電力の影響があったかどうかを示すことができる。
【０２２９】
具体的に、表１３のＲＬＦ報告では、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドの各サブフィールドを介してＵＥ内の他の送受信装置別測定値を示すようにすることができる。
【０２３０】
例えば、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドであるｍｅａｓＲｅｓｕｌｔＷＬＡＮが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＷＬＡＮを指示し、ＭｅａｓＲｅｓｕｌｔＷＬＡＮのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＷＬＡＮ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＷＬＡＮ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＷＬＡＮ、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＷＬＡＮ等を介して測定結果を示すようにすることができる。
【０２３１】
同様に、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドであるｍｅａｓＲｅｓｕｌｔＢＴが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＢＴを指示し、ＭｅａｓＲｅｓｕｌｔＢＴのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＢＴ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＢＴ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＢＴ、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＢＴ、ＢＴ_Ｈｏｐｐｉｎｇ_ｐａｔｔｅｒｎ_ｌｅｎｇｔｈ、ＢＴ_Ｈｏｐｐｉｎｇ_Ｐａｔｔｅｒｎ等を介して測定結果を示すようにすることができ、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドであるｍｅａｓＲｅｓｕｌｔＧＰＳが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＧＰＳを指示し、ＭｅａｓＲｅｓｕｌｔＧＰＳのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＧＰＳ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＧＰＳ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＰｏｗｅｒＦｒｏｍ_ＧＰＳ、ＲｅｃｅｉｖｅｄＱｕａｌＦｒｏｍ_ＧＰＳ等を介して測定結果を指示すようにすることができる。
【０２３２】
このとき、いずれのシステムの送受信装置によることかを区分することができない干渉電力や二つ以上の送受信装置による干渉電力に対しては、ｍｅａｓＲｅｓｕｌｔＩＤＣフィールドのサブフィールドとしてｍｅａｓＲｅｓｕｌｔＯｔｈｅｒが下位サブフィールドであるＭｅａｓＲｅｓｕｌｔＯｔｈｅｒを示し、ＭｅａｓＲｅｓｕｌｔＯｔｈｅｒのサブフィールドであるＲｅｃｅｉｖｅｄＰｏｗｅｒＯｔｈｅｒ_Ｒｅｓｕｌｔ、ＲｅｃｅｉｖｅｄＱｕａｌＯｔｈｅｒ_Ｒｅｓｕｌｔ等を介して測定結果を示すようにしてもよい。
【０２３３】
表１３において、ＵＥ内のＷＬＡＮ送受信装置に対して測定された受信電力及び/又は干渉電力を示すフィールドは、表８の各フィールドと同様に定義されてもよい。
【０２３４】
一方、表６〜表８及び表１１〜表１３の実施例において、ＲＬＦ報告は、ＵＥ内の他の送受信装置について一部の送受信装置による干渉電力の影響があったかどうかのみを指示し、受信電力と干渉電力の値は送受信装置毎に他の送受信装置に対するものとして示すものとして構成されてもよい。また、ＵＥ内の送受信装置の受信電力と干渉電力のうち、いずれか一つのみを示すようにしてもよく、一部の送受信装置に対しては受信電力のみを示し、他の一部の送受信装置に対しては干渉電力のみを示し、残りの送受信装置に対しては受信電力と干渉電力の全てを示すようにＲＬＦ報告を構成してもよい。
【０２３５】
また、表６〜表８及び表１１〜表１３の実施例では、ｒｌｆ−ＲｅｐｏｒｔＲｅｑ又はｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑを受けた場合にＩＣＯ−ＲＬＦ情報を送信すると説明したが、これに限定されるものではなく、ＵＥ情報提供要求メッセージ上にＩＣＯ−ＲＬＦ情報を具体的に要求するフィールドが存在し、該当フィールドを介してＩＣＯ−ＲＬＦ情報が要求された場合にのみＩＣＯ−ＲＬＦ情報をＵＥがＵＥ情報提供応答メッセージに含んで送信するようにしてよい。
【０２３６】
図１１は、本発明が適用されるシステムで実行されるＲＬＦ報告手順を概略的に説明するフローチャートである。
【０２３７】
図１１を参照すると、ＵＥとｅＮＢＲＥＬとの間にＲＬＦ(ＲＬＦ)が発生する(Ｓ１１１０)。このとき、ＲＬＦは、隣接した(異種)セルからの干渉によるものであり、又はＵＥ内の他の送受信装置による干渉の影響のため発生したものである。さらには、ＲＬＦは、ネットワーク自体の問題に基づいたことである。
【０２３８】
ＵＥは、セル探索（セルサーチ）を介してＲＲＣ接続の再設定に適したセルを探す。
【０２３９】
ＲＲＣ接続の再設定に適したセルとしてｅＮＢＣＯＮを選択した場合、ＵＥは、ｅＮＢＣＯＮにＲＲＣ接続再設定メッセージを送信する(Ｓ１１２０)。成功的なハンドオーバ以後に一時的なＲＬＦがあった場合にはｅＮＢＣＯＮがＵＥとの間でＲＬＦを発生させたｅＮＢである。ＵＥからｅＮＢＣＯＮに送信されるＲＲＣ接続再設定メッセージは、ＵＥＩＤ、ＰＣＩなどの情報と共に原因値としてＲＬＦ情報を含んでもよい。
【０２４０】
ｅＮＢＣＯＮは、ＲＲＣ接続再設定要求メッセージを受信し、ＲＲＣ接続再設定メッセージを送信する(Ｓ１１３０)。
【０２４１】
ＵＥは、ＲＲＣ接続再設定メッセージを受信し、ＲＲＣ接続再設定メッセージに含まれている情報に基づいてＲＲＣ接続を再設定し、ＲＲＣ接続再設定完了メッセージをｅＮＢＣＯＮに送信する(Ｓ１１４０)。
【０２４２】
ｅＮＢＣＯＮは、前述したＲＲＣ接続再設定手順を介して、ＲＲＣ接続再設定要求メッセージに原因値として含まれているＲＬＦ情報を取得することができる。
【０２４３】
また、ｅＮＢＣＯＮを介して、Ｅ−ＵＴＲＡＮは、必要な情報を取得するためにＵＥにＵＥ情報提供要求メッセージを送信することができる(Ｓ１１５０)。ＵＥ情報提供要求メッセージは、ｒｌｆ−ＲｅｐｏｒｔＲｅｑ、ｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑなどのようにＲＬＦ情報を要求するフィールドを含んでもよい。
【０２４４】
ＵＥは、ＵＥ情報提供要求メッセージに含まれているｒｌｆ−ＲｅｐｏｒｔＲｅｑ、ｌｏｇＭｅａｓＲｅｐｏｒｔＲｅｑなどを確認し、対応するＲＬＦ情報をＵＥ情報提供応答メッセージに含ませてｅＮＢＣＯＮ(Ｅ−ＵＴＲＡＮ)に伝達されてもよい(Ｓ１１６０)。
【０２４５】
ＲＲＣ接続再設定手順又はＵＥ情報提供手順を介して、ＲＬＦ情報を取得したｅＮＢＣＯＮ(Ｅ−ＵＴＲＡＮ)は、取得したＲＬＦ情報を関連したｅＮＢ(ｅＮＢＲＥＬ)に伝達する(Ｓ１１７０)。このとき、ＲＬＦ情報は、Ｘ２インターフェースを介して伝達されてもよい。
【０２４６】
ｅＮＢＲＥＬは、ＰＣＩに基づいて確認することができるＵＥの以前セル又は以前ｅＮＢであってもよく、この場合、ＲＬＦ情報は、ＲＬＦ識別子(ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ)を介してｅＮＢＲＥＬに伝達されてもよい。
【０２４７】
また、ＲＬＦ情報は、ハンドオーバ報告(ｈａｎｄｏｖｅｒ ｒｅｐｏｒｔ)を介してｅＮＢＲＥＬに伝達されてもよく、この場合、ｅＮＢＲＥＬは、ＰＣＩに基づいて把握されるＵＥの元ソースｅＮＢ、ソースセル、ターゲットセルなどであってもよい。
【０２４８】
一方、ｅＮＢＣＯＮは、ＲＬＦがネットワークの問題に基づいたことではない機器内共存干渉によるものである場合には、該当ＲＬＦ情報がｅＮＢＲＥＬに必要な情報と判断された時期又は場合にのみＲＬＦ情報をｅＮＢＲＥＬに送信することもできる。
【０２４９】
図１２は、本発明が適用されるシステムでＲＬＦを受けたＵＥが実行するＲＬＦ情報の報告手順を概略的に説明するフローチャートである。
【０２５０】
図１２を参照すると、まず、ＵＥは、ＲＬＦが発生したことを検知(ｄｅｔｅｃｔ)する(Ｓ１２１０)。
【０２５１】
このとき、ＵＥは、ＲＬＦ情報を取得してこれを記録することができる(Ｓ１２２０)。ＵＥは、取得したＲＬＦ情報をＶａｒＲＬＦ−Ｒｅｐｏｒｔの各フィールドに格納することができる。ＵＥが取得したＲＬＦ情報がＭＤＴを実行する過程で測定されたものである場合、ＵＥは、ＭＤＴにより作成されたログをＶａｒＬｏｇＭｅａｓＲｅｐｏｒｔの各フィールドに格納することができる。
【０２５２】
ＵＥは、ｅＮＢを介してＲＬＦ情報送信要求を受信する(Ｓ１２３０)。このとき、ｅＮＢは、ＲＬＦ後にＲＲＣ接続が再設定されたｅＮＢである。また、ＲＬＦ情報送信要求は、Ｅ−ＵＴＲＡＮからのＵＥ情報提供要求メッセージに含まれて送信されてもよい。
【０２５３】
ＵＥは、送信すべきＲＬＦ報告を構成する(Ｓ１２４０)。このとき、ＵＥは、ネットワークによるＲＬＦの原因だけでなく、機器内共存干渉によるＲＬＦの原因も含んでＲＬＦ報告を構成してもよい。
【０２５４】
機器内共存干渉に対する情報を含む場合、ＵＥは、機器内共存干渉に対する情報が機器内の共存干渉による影響があったという情報のみを含むようにしてもよく、ＵＥ内のいずれのシステムの送受信装置から干渉があったかを示す情報を含んでもよく、ＵＥ内の各システム別に干渉に対する測定結果を含むようにしてもよい。
【０２５５】
ＲＬＦ報告が含む情報に対してはＵＥに予め設定されていてもよく、上位レイヤからのシグナリングを介して伝達されてもよい。また、ｅＮＢ又はＥ−ＵＴＲＡＮからＵＥ情報提供要求メッセージなどを介して必要な情報を指定してもよい。
【０２５６】
ＵＥは、構成されたＲＬＦ情報をｅＮＢ(Ｅ−ＵＴＲＡＮ)に送信する(Ｓ１２５０)。このとき、ＲＬＦ情報は、ｅＮＢを介してＥ−ＵＴＲＡＮ側に伝達される。ＵＥがＲＬＦに対する情報送信要求をＵＥ情報提供要求メッセージを介して受信した場合には、ＲＬＦ情報をＵＥ情報提供応答メッセージに含んで送信してもよい。
【０２５７】
また、ＵＥがＲＬＦ情報を送信するｅＮＢは、ＲＲＣ接続を再設定しようとするｅＮＢである。この場合、ＵＥは、ｅＮＢからの要求、即ち、Ｓ１２３０ステップを経ずに、ＲＬＦ情報をＲＲＣ接続再設定要求メッセージに原因値として含ませて送信してもよい。
【０２５８】
一方、ここではＵＥがＵＥ情報提供要求メッセージを受信し、ＲＬＦ報告を構成すると説明したが、本発明はこれに限定されるものではなく、ＲＬＦ報告は、ＵＥ情報提供要求メッセージが受信されなくても、ＲＬＦを検知したＵＥにより作成されてもよい。この場合、ＵＥは、ＵＥ情報提供要求メッセージに対する応答として又はＲＲＣ接続再設定要求メッセージに含ませて、作成されたＲＬＦ報告を送信するようにしてもよい。
【０２５９】
図１３は、本発明が適用されるシステムでＲＬＦ情報を受信するｅＮＢが実行する動作を概略的に説明するフローチャートである。
【０２６０】
図１３を参照すると、ｅＮＢは、無線通信障害が発生したＵＥに無線通信障害に対する情報要求メッセージを送信することができる(Ｓ１３１０)。無線通信障害が発生したＵＥとＲＲＣ接続を再設定したｅＮＢは、ＵＥ情報提供要求メッセージなどを介して無線通信障害に対する情報を要求することができる。
【０２６１】
ｅＮＢは、ＵＥからＲＬＦ報告を受信する(Ｓ１３２０)。ＵＥから送信されたＲＬＦ報告は、ＵＥ情報提供要求メッセージに対する応答として、ＵＥ情報提供応答メッセージに含まれて送信されてもよい。
【０２６２】
一方、ＵＥは、ＵＥ情報提供要求メッセージの受信なくてもＲＬＦ情報を報告することができる。即ち、ｅＮＢは、Ｓ１３１０ステップを経ずにＵＥからＲＬＦ情報を受信することができ、この場合、ＲＬＦ情報は、ＵＥからのＲＲＣ接続再設定要求メッセージにＲＲＣ接続再設定要求に対する原因値として含まれて送信されてもよい。
【０２６３】
ｅＮＢは、ＵＥから受信したＲＬＦ情報を分析する(Ｓ１３３０)。ｅＮＢは、ＲＬＦが発生したサービングセルのＩＤを確認することができ、ＲＬＦの原因を確認することができる。
【０２６４】
ｅＮＢは、ＲＬＦ情報を関連ｅＮＢに送信する(Ｓ１３４０)。関連ｅＮＢは、ＰＣＩ等を介して確認することができるＵＥの以前セル又は以前ｅＮＢであり、この場合、ＲＬＦ情報は、ＲＬＦ指示(ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ)を介して伝達される。また、ＲＬＦ情報は、ハンドオーバ報告(ｈａｎｄｏｖｅｒ ｒｅｐｏｒｔ)を介して伝達されてもよく、この場合、関連ｅＮＢは、ＰＣＩ等を介して把握されるＵＥの元ソースｅＮＢ、ソースセル、ターゲットセルなどになってもよい。
【０２６５】
一方、ｅＮＢは、ＲＬＦがネットワークの問題に基づいたものではなく機器内共存干渉によることである場合には、該当ＲＬＦ情報が関連ｅＮＢに必要な情報と判断された時期又は場合にのみＲＬＦ情報を関連ｅＮＢに送信してもよい。
【０２６６】
図１４は、本発明が適用されるシステムでＲＬＦが発生したｅＮＢがＲＬＦ情報に基づいて実行する動作を概略的に説明するフローチャートである。
【０２６７】
図１４を参照すると、ＲＬＦが発生したｅＮＢは、ＲＬＦ情報を受信する(Ｓ１４１０)。ＲＬＦ情報は、ＲＬＦが発生したＵＥと新たにＲＲＣ接続を再設定したｅＮＢからＲＬＦ指示又はハンドオーバ報告などを介して受信することができる。
【０２６８】
ＲＬＦが発生したｅＮＢは、ＲＬＦ情報を分析してＲＬＦの原因を分析することができる(Ｓ１４２０)。
【０２６９】
ＲＬＦが発生したｅＮＢは、分析したＲＬＦの原因に基づいてＲＬＦの原因を改善する(Ｓ１４３０)。ＲＬＦは、多様な原因に基づいて生成されてもよい。ＲＬＦの原因がセル間干渉などのようなネットワークに起因した原因である場合、ｅＮＢは、該当原因を反映してシステムが運用されるようにすることができる。また、ＲＬＦの原因がＵＥの内部の原因、例えば、機器内共存干渉などである場合にはハンドオーバなどを介して該当ＵＥと再びＲＲＣ接続を設定する場合、該当ＵＥに関する情報としてＲＬＦの原因を活用することができる。
【０２７０】
図１５は、本発明が適用されるシステムでＵＥの構成を概略的に説明するブロック図である。
【０２７１】
図１５を参照すると、ＵＥ１５００は、ＲＦ部１５１０、ＲＦ報告部１５１５、メモリ１５２０、及びプロセッサ１５３０を含む。このとき、ＲＦ報告部１５１５は、ＲＦ部１５１０の内部に含まれてもよく、外部に別途に存在してもよい。
【０２７２】
ＵＥ１５００は、ＲＦ部１５１０を介して必要な情報を送受信する。実際に、ＵＥ１５００は、多様な通信システムをサポートすることができ、ＲＦ部１５１０は、ＵＥ１５００が多様な通信システムを利用することができるように各々のシステムに対するＲＦ部を含むことができる。例えば、ＲＦ部１５１０は、ＬＴＥシステムに対するＲＦ部１５４０、ＷＬＡＮシステムに対するＲＦ部１５５０、ＢＴシステムに対するＲＦ部１５６０、ＧＰＳに対するＲＦ部１５７０などを含むことができる。
【０２７３】
各々のシステムに対するＲＦ部１５４０〜１５６０は、各システムで規定された帯域を利用するが、機器内共存干渉に対して前述したように同じＵＥ内で相互間に干渉を起こす場合がある。
【０２７４】
メモリ１５２０は、ＵＥ１５００が通信を実行するときに必要な情報を格納する。例えば、メモリ１５２０は、測定を介したネットワーク状態又はチャネル状態に対する情報を格納し、ＭＤＴを介して作成したログを格納する。また、メモリ１５２０は、ＲＬＦが発生した場合、これに対する情報を格納することができる。ＲＬＦに対する情報がＭＤＴを介して測定された場合にはＲＬＦに対する情報をログで作成して格納してもよい。
【０２７５】
プロセッサ１５３０は、測定部１５８０と制御部１５９０を含む。プロセッサ１５３０は、ＲＦ部１５１０及びメモリ１５２０と接続され、制御部１５９０を介してこれらを制御する。
【０２７６】
測定部１５８０は、ネットワーク状態又はチャネル状態などを判断するための測定を実行する。ＵＥ１５００がサポートする各通信システムは、各通信システム別測定方式を規定している。測定部１５８０は、各通信システム別測定方式によって、各ＲＦ部１５４０〜１５６０を介して受信される信号等の強度を測定することができる。また、測定部１５８０は、機器内共存干渉による影響を判断するために、該当システムの帯域内で受信される異種システムの信号を測定することもできる。例えば、該当システムの帯域内で受信される信号で該当帯域の定められた受信信号を除去することにより、異種システムの影響を測定することもできる。
【０２７７】
測定部１５８０は、ＲＬＦが発生した場合、ＵＥ又はシステムの状況を測定することができ、測定部１５８０の測定結果は、メモリ１５２０に格納される。
【０２７８】
制御部１５９０は、測定部１５８０の測定結果又は無線通信状況を判断してＲＬＦが発生したかどうかを判断することができる。制御部１５９０は、ＲＬＦ報告を作成してもよい。このとき、制御部１５９０は、測定部１５８０の測定結果に基づいてＲＬＦ報告を作成することができる。
【０２７９】
ＲＦ報告部１５１５は、ＵＥ情報提供要求メッセージに対する応答(例えば、Ｅ−ＵＴＲＡＮから受信したＵＥ情報提供要求)に、又はＲＲＣ接続再設定要求メッセージに含ませてＲＬＦ報告を送信してもよい。ＲＬＦ報告は、ｅＮＢから受信したＲＬＦ情報要求に対応して構成されてもよく、予め定められた方式によって構成されてもよい。
【０２８０】
例えば、制御部１５９０は、機器内共存干渉に対し、機器内共存干渉の有無に関する情報のみを含ませるか、システム別干渉の有無に関する情報を含ませるか、システム別測定値を含ませるかをｅＮＢからの要求に対応して又は予め定められた設定によって決定し、これにより、ＲＬＦ報告を作成することができる。このとき、測定値は、ＲＳＲＰ又はＲＳＲＱで表現されてもよい。
【０２８１】
図１６は、本発明が適用されるシステムでｅＮＢの構成を概略的に説明するブロック図である。
【０２８２】
図１６を参照すると、ｅＮＢ１６００は、ＲＦ部１６１０、メモリ１６２０、プロセッサ１６３０を含む。
【０２８３】
ｅＮＢ１６００は、ＲＦ部１６１０を介して必要な情報を送受信する。
【０２８４】
ＲＦ部１６１０は、ＵＥ１５００から前記無線リンク障害に前記端末の機器内共存干渉による影響がある場合、前記機器内共存干渉を発生させた通信システムがいずれの通信システムであるかを示す情報、及び前記機器内共存干渉を発生させた通信システムの信号の受信電力又は干渉電力を測定した値を含む無線リンク障害報告を受信する。
【０２８５】
ＲＦ部１６１０は、前記無線リンク障害報告に基づいて前記無線リンク障害が発生したセルに前記無線リンク障害に関する情報を送信する。
【０２８６】
ＲＦ部１６１０は、前記無線リンク障害報告が無線リンク障害に対する端末の機器内共存干渉情報を含む場合、前記無線リンク障害が発生したセルが前記機器内共存干渉に関する情報を必要とする場合にのみ前記端末の機器内共存干渉情報を送信する。
【０２８７】
メモリ１６２０は、システム運用に必要な情報を格納する。例えば、メモリ１６２０は、ＲＲＣ接続再設定のための情報を格納することができる。ＲＲＣ接続再設定のための情報は、ＲＲＣ接続を再設定しようとするＵＥの以前セルのＩＤ、ＰＣＩ、ＲＲＣ接続再設定に対する原因値としてＲＬＦ情報を含んでもよい。また、メモリ１６２０は、ＵＥ情報提供要求メッセージに対する応答として受信したＵＥ情報提供応答メッセージ内のＲＬＦ情報を格納してもよい。
【０２８８】
プロセッサ１６３０は、ＵＥとｅＮＢとの間でＲＲＣ接続再設定手順を実行してもよい。プロセッサ１６３０は、ＵＥから受信した該当ＵＥのＲＬＦ情報を分析し、これを関連ｅＮＢに送信してもよい。また、プロセッサ１６３０は、ＵＥとｅＮＢとの間でＲＬＦが発生したＵＥのＲＬＦ情報を受信した場合には、該当情報を分析し、ＲＬＦの原因を改善することができる。プロセッサ１６３０は、Ｅ−ＵＴＲＡＮからＵＥ情報提供要求がある場合、ＵＥに情報提供要求メッセージを送信してもよい。
【０２８９】
本発明によると、ＲＬＦが発生する原因によってＲＬＦ情報を正確に報告することができ、これをネットワークで共有することによって、ネットワーク品質を効果的に改善することができる。
【０２９０】
本発明によると、ＵＥ内の互いに異なる通信システムの送受信装置による干渉を介して発生したＲＬＦに対しても報告することができ、このとき、互いに異なるシステムの送受信装置により干渉が発生したという情報外に、各システムの送受信装置による信号の受信電力及び/又は干渉電力を測定した値をＲＬＦ情報に含んでさらに正確なＲＬＦ報告が行われるようにすることができる。
【０２９１】
以上の説明は、本発明の技術思想を例示的に説明したものに過ぎず、本発明が属する技術分野において通常の知識を有する者であれば、本発明の本質的な特性から外れない範囲で多様な修正及び変形が可能である。したがって、本発明に開示された実施例は、本発明の技術思想を限定するためのものではなく、説明するためのものであり、このような実施例によって本発明の技術思想の範囲が限定されるものではない。本発明の保護範囲は、請求の範囲によって解釈されなければならず、それと同等な範囲内にある全ての技術思想は、本発明の権利範囲に含まれると解釈されなければならない。
【図１】
0005747120.tif 000016
【図２】
0005747120.tif 000017
【図３】
0005747120.tif 000018
【図４】
0005747120.tif 000019
【図５】
0005747120.tif 000020
【図６】
0005747120.tif 000021
【図７】
0005747120.tif 000022
【図８】
0005747120.tif 000023
【図９】
0005747120.tif 000024
【図１０】
0005747120.tif 000025
【図１１】
0005747120.tif 000026
【図１２】
0005747120.tif 000027
【図１３】
0005747120.tif 000028
【図１４】
0005747120.tif 000029
【図１５】
0005747120.tif 000030
【図１６】
0005747120.tif 000031