(57)【特許請求の範囲】
【請求項１】
ネットワークにおけるトレースセッション管理方法において、各トレースセッションには、トレースＩＤと、前記ネットワーク内に配設された複数のトレース収集エンティティＴＣＥ（５）のうち該トレースセッションの関連する測定値を保存する特定のＴＣＥ（５）と、が割り当てられ、該方法が、
各パーティションが前記複数のＴＣＥ（５）のうちの１個以上に関連づけられるようにトレースＩＤの空間をパーティションに分割するステップと、
前記トレースＩＤ内にパーティションＩＤを符号化するステップと、
前記複数のＴＣＥ（５）のうちの特定のＴＣＥ（５）に前記パーティションＩＤをマッピングするステップと
を備えたことを特徴とする、ネットワークにおけるトレースセッション管理方法。
【請求項２】
前記トレースＩＤが、ネットワーク事業者識別とともに、トレースリファレンス情報要素に含まれ、前記トレースＩＤが、前記ネットワーク事業者内で前記トレースセッションを一意的に識別することを特徴とする請求項１に記載の方法。
【請求項３】
前記トレースリファレンス情報要素が、トレースセッション設定メッセージで前記ネットワークからユーザ機器ＵＥ（４）へ送信されることを特徴とする請求項２に記載の方法。
【請求項４】
前記トレースＩＤのパーティションの個数は２のべき乗であり、前記ネットワーク内に配設される前記複数のＴＣＥ（５）の個数よりも大きいか、または少なくとも等しく選択されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記符号化が、前記パーティションＩＤをトランスポートするために前記トレースＩＤのビットの所定部分を使用することによって実行されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
前記トレースＩＤのビットの残りの部分が、トレースサブＩＤをトランスポートするために使用されることを特徴とする請求項５に記載の方法。
【請求項７】
前記トレースＩＤのビットの対応する部分を指定するために使用されるビットマスクが、前記ネットワークからユーザ機器ＵＥ（４）へ送信されることを特徴とする請求項５または６に記載の方法。
【請求項８】
前記トレースリファレンス情報要素が、ユーザ機器測定報告とともにユーザ機器ＵＥ（４）から前記ネットワークへ送信されることを特徴とする請求項２または３に記載の方法。
【請求項９】
前記トレースリファレンス情報要素を受信したネットワークノードが、前記トレースリファレンス情報要素から前記パーティションＩＤを抽出することを特徴とする請求項２または３に記載の方法。
【請求項１０】
前記パーティションＩＤをＴＣＥ  ＩＰアドレスにマッピングするマッピングテーブルが提供されることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
前記パーティションＩＤを、前記ＴＣＥ（５）の中間的・暗黙的な識別情報ＴＣＥ  ＩＤにマッピングするマッピングテーブルが提供されることを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
【請求項１２】
前記パーティションの個数が前記ネットワーク内に配設されるＴＣＥ（５）の個数よりも大きい場合、実際のＴＣＥ  ＩＰアドレスを前記マッピングテーブル内の別のエントリからマッピングすることを示す特殊値が前記ＴＣＥ  ＩＤとして採用されることを特徴とする請求項１１に記載の方法。
【請求項１３】
トレースＩＤが割り当てられたトレースセッションを起動するように構成された少なくとも１つのネットワークエンティティと、
トレーシングを実行する１個以上のＵＥと、
該ＵＥからのトレースセッション測定値を保存する複数のＴＣＥ（５）と
を備えたトレースセッション管理システムにおいて、
各パーティションが前記複数のＴＣＥのうちの１個以上に関連づけられるようにトレースＩＤの空間をパーティションに分割し、
前記トレースＩＤ内にパーティションＩＤを符号化し、
前記複数のＴＣＥ（５）のうちの特定のＴＣＥ（５）に前記パーティションＩＤをマッピングする
ように構成された処理手段をさらに備えたことを特徴とするトレースセッション管理システム。
【請求項１４】
前記処理手段がｅＮＢ（３）、ＲＮＣ、および／またはＭＭＥに関連づけられることを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記トレースリファレンス情報要素を受信したネットワークノードが、前記トレースリファレンス情報要素から、ビットごとのＸＯＲ演算を実行することによって、前記パーティションＩＤを抽出することを特徴とする請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおけるトレースセッション管理方法に関する。各トレースセッションには、トレースＩＤと、前記ネットワーク内に配設された複数のトレース収集エンティティＴＣＥのうち該トレースセッションの関連する測定値を保存する特定のＴＣＥと、が割り当てられる。
【０００２】
また、本発明は、トレースセッション管理システムに関する。該システムは、トレースＩＤが割り当てられたトレースセッションを起動するように構成された少なくとも１つのネットワークエンティティと、トレーシングを実行する１個以上のＵＥと、該ＵＥからのトレースセッション測定値を保存する複数のＴＣＥとを備える。
【背景技術】
【０００３】
ＭＤＴ（Minimization of Drive Tests, ドライブテストの最小化）は、３ＧＰＰにおいてネットワークの無線リソースを最適化するために採用されているメカニズムである。ＭＤＴがネットワークにおいて起動されると、１つまたは複数のユーザ機器（User Equipment, ＵＥ）が、例えば無線信号強度、可視セル、信号欠損、ハンドオーバー関連メトリック等の無線関連測定を実行し、これらの測定値を記録してネットワークに返送するように要求される。ＭＤＴがなければ、これらの測定は技術者によって実行される必要がある。技術者は、専用のデバイスとともに、通常は自動車を運転して該当エリアを移動する（ドライブテスト）。このため、ＭＤＴが要求される。
【０００４】
１つのＵＥから収集される測定値のセットは「トレース」と呼ばれる。それらの測定値を収集するプロセスは「トレーシング」と呼ばれる。一般的に、３ＧＰＰネットワークにおいて、トレーシングは、さまざまなネットワークノードにおいて起動されることが可能である。例えば、ｅＮＢ（ｅＮｏｄｅＢともいう）において起動される。ｅＮＢは、ＬＴＥ（Long Term Evolution）における基地局を表す。また、ＲＮＣ（Radio Network Controller, 無線ネットワークコントローラ）において起動される。ＲＮＣは、３Ｇにおける基地局を表す。また、ＭＭＥ（Mobility Management Entity, モビリティ管理エンティティ）において起動される。ＭＭＥは、ＬＴＥ無線アクセスのためのコアネットワークを構成する。これらのネットワークノードのうちの１つでいったんトレーシングが起動されると、該ネットワークノードはＵＥでのトレーシングを設定する。
【０００５】
ＵＥからの測定値は、トレース収集エンティティ（Trace Collection Entity, ＴＣＥ）と呼ばれる専用のエンティティに保存される。実際には、ＴＣＥは、測定データのためのデータベースとして実現される。ネットワークは、測定値を受信するたびごとに、それらの測定値をＴＣＥに報告する。一般的に、同じネットワーク内に複数のＴＣＥが存在可能であり、特定のトレースセッションのＴＣＥが、そのトレースセッションに対するＭＤＴの起動時刻に選択され、当該トレーシングプロセスの間全体で固定される。
【０００６】
トレースセッション設定は、さまざまな情報要素を含む。その中には、「トレースリファレンス」（Trace Reference）と呼ばれる情報要素と、「ＴＣＥ  ＩＰアドレス」と呼ばれる情報要素がある。いずれの情報要素も、非特許文献１に規定されている。情報要素「ＴＣＥ  ＩＰアドレス」は、対応するトレースセッションに対するＴＣＥとして選択されているＴＣＥのＩＰアドレスを含む。情報要素トレースリファレンスは、ｉ）ＭＮＣ（Mobile Network Code, モバイルネットワークコード）およびＭＣＣ（Mobile Country Code, モバイル国コード）からなるネットワーク事業者識別と、ｉｉ）該ネットワーク事業者内でトレースセッションを一意的に識別するトレースＩＤと、を含む。
【０００７】
接続モードにおいてはＵＥに対するＭＤＴの満足な解決法が存在するが、ＭＤＴの１つの特徴はアイドルモードにあるＵＥからの測定である。アイドルモードにあるＵＥは、測定値を直ちに報告することはできず、それらの測定値をキャッシュし、後の段階でネットワークとの特別なシグナリングによりそれらを報告する必要がある。このシグナリングを通じて、ＵＥは、記録した測定値を所有していることをネットワークにアドバタイズする。その後、ネットワークは、ＲＲＣ（Radio Resource Connection, 無線リソース接続）手続きを初期化して、そのＵＥから、記録された測定値を取得する。
【０００８】
これに関して、すなわちＵＥがアイドルモードにある場合、ネットワークにおける複数のＴＣＥの存在が、ＭＤＴに対するいくつかの課題を提示する。実際、測定値を受信するネットワークノードは、そのＵＥでＭＤＴを起動したネットワークノードと同一とは限らない。このような場合、新しいノード、すなわち、測定値を実際に受信するネットワークノードは、そのＵＥの宛先ＴＣＥに関する知識を有していない。
【０００９】
現在、３ＧＰＰは、この問題に対して非常に単純な解決法を支持している。現在の解決法では、現在の解決法では、ＴＣＥのＩＰアドレスが設定時にＵＥへ送信される。ＵＥは、報告メッセージで、ＴＣＥのＩＰアドレスをネットワークへ返送する。このようにして、ネットワークは、ＵＥの宛先ＴＣＥについて知る。しかし、上記文献に記載されているこの解決法（現在、３ＧＰＰ仕様に存在する）は、主にセキュリティに関して、いくつかの欠点を有する。特に、コアネットワーク内のネットワークノードのＩＰアドレスは、モバイル機器あるいはエンドユーザに開示されるべきでない。もう１つの欠点は、非特許文献２に記載されているような、負荷分散、ＮＡＴ（ネットワークアドレス変換）の使用等のネットワーク動作の問題に関することである。
【００１０】
現在、２つの代替案が３ＧＰＰで検討中である。これらの２つの代替案は、アイドルモードにあるＭＤＴ対応ＵＥからＴＣＥのＩＰアドレスを取得するという問題における最新技術の代表例である。第１の代替案は、バックエンドにおけるＴＣＥ  ＩＰアドレスの動的問合せであるが、これはかなり煩雑である。第２の代替案によれば、ＴＣＥに対してＩＤが使用される。ＩＰアドレス（ＩＰｖ４（またはＩＰｖ６）アドレスが使用される場合、３２ビット（または１２８ビット））の代わりに、ＴＣＥのＩＤがＵＥへ送信される。そして、ＩＤは、バックエンドで、対応するＩＰアドレスにマッピングされる。しかし、この解決法の欠点は、このＩＤが無線インタフェースを通じて送信されることである。これは、貴重な送信チャネルであり、ネットワークシグナリングにおけるボトルネックとみなされる。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】3GPP TS 32.422 "Subscriber and equipment trace; Trace control and configuration management"
【非特許文献２】R2-110274, "On TCE IP Address configuration to the UE", 3GPP contribution to RAN2#72bis
【発明の概要】
【発明が解決しようとする課題】
【００１２】
したがって、本発明の目的は、頭書のようなトレースセッション管理方法およびトレースセッション管理システムにおいて、アドレスをモバイル機器あるいはエンドユーザに公表することなく、かつ、無線リンク上のオーバーヘッドを引き起こすことなく、トレース測定値を受信するネットワーク要素にＴＣＥ  ＩＰアドレスを効率的に提供するような改良およびさらなる展開を行うことである。
【課題を解決するための手段】
【００１３】
本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、各パーティションが前記複数のＴＣＥの１個以上に関連づけられるようにトレースＩＤの空間をパーティションに分割するステップと、前記トレースＩＤ内にパーティションＩＤを符号化するステップと、前記複数のＴＣＥのうちの特定のＴＣＥに前記パーティションＩＤをマッピングするステップとを備えたことを特徴とする。
【００１４】
また、上記の目的は、独立請求項１３の構成を備えたシステムによって達成される。この請求項に記載の通り、本システムは、各パーティションが前記複数のＴＣＥのうちの１個以上に関連づけられるようにトレースＩＤの空間をパーティションに分割し、前記トレースＩＤ内にパーティションＩＤを符号化し、前記複数のＴＣＥのうちの特定のＴＣＥに前記パーティションＩＤをマッピングするように構成された処理手段をさらに備えたことを特徴とする。
【００１５】
本発明によって認識されたこととして、３ＧＰＰネットワーク内のさまざまなネットワーク要素にわたってＴＣＥ  ＩＰアドレスを効率的に提供することは、特定の分割および符号化方式によって達成することができる。提案する方法は、ｅＮＢとＵＥとの間で追加的な情報要素を無線で送信することを回避する。代わりに、既存のシグナリングメッセージ内に符号化されるパーティションＩＤを生成することを提案する。符号化メカニズムは、ＭＤＴの従来の手続きと後方互換性を保証するように規定することができる。さらに、この符号化は、無線で送信される識別子にＴＣＥ  ＩＰアドレスをマッピングする効率的な方法を提供する。トレースＩＤ空間の分割は、ＯＡＭ手続きにより事前に実行することができる。
【００１６】
さらなる利点として、本発明による方法は、モバイル機器あるいはエンドユーザへＴＣＥ  ＩＰアドレスを公開することを回避する。さらに、ＴＣＥの利用の最適化（例えば負荷分散）の余地を提供する。
【００１７】
好ましい実施形態によれば、トレースＩＤが、ネットワーク事業者識別とともに、トレースリファレンス情報要素に含まれてもよい。トレースＩＤは、ネットワーク事業者内でトレースセッションを一意的に識別する。従来の標準との互換性を保証するため、トレースリファレンス情報要素は、非特許文献１に記載のものと同様に、すなわち、ＭＣＣ＋ＭＮＣ＋トレースＩＤの形式で、構成されてもよい。ただし、ＭＣＣはモバイル国コードを表し、ＭＮＣはモバイルネットワークコードを表す。
【００１８】
高い標準互換性を有する好ましい実施形態において、符号化されたパーティションＩＤをトレースＩＤ内に含むトレースリファレンス情報要素は、トレースセッション設定メッセージで前記ネットワークからユーザ機器へ送信されるようにしてもよい。
【００１９】
有利な態様として、トレースＩＤのパーティションの個数は、ネットワーク内に配設される複数のＴＣＥの個数よりも大きいか、または少なくとも等しく選択される。この仕様は、ネットワークにおいて複数のＴＣＥを効率的かつ最適に使用するため、例えば、ＴＣＥ間で負荷分散を実行するための十分な余地を提供する。マッピングテーブルによるパーティションの直接的な処理に関して、パーティションの個数は、さらに、２のべき乗となるように選択されてもよい。これは、例えば７個のＴＣＥがネットワーク内に提供される場合、パーティションの個数は２＾３＝８とすることを意味する。
【００２０】
符号化に関して、ＭＤＴの従来の手続きとの後方互換性が保証されるように、トレースＩＤのシンタックス（syntax）およびセマンティクス（semantics）は、３ＧＰＰにおける従来の手続きと互換であるようにしてもよい。特定実施形態において、符号化は、パーティションＩＤをトランスポートするためにトレースＩＤのビットの所定部分（例えば最初の２ビットまたは最後の４ビット）を使用することによって実行される。この場合、トレースＩＤのビットの残りの部分は、トレースサブＩＤをトランスポートするために使用されてもよい。ビットごとの演算を用いたさらに複雑な符号化方式では、場合によっては、ゼロパディングを使用してもよい。ただし、このような場合、対応する符号化方式で使用されるビットマスクが、ネットワークからトレーシング対象のユーザ機器へ送信されるべきである。
【００２１】
さらなる標準互換性に関して、トレースリファレンス情報要素は、ユーザ機器測定報告とともにユーザ機器からネットワークへ送信されるようにしてもよい。このような報告を受信した後、受信側ネットワークノード（例えばｅＮＢ）は、トレースリファレンス情報要素からパーティションＩＤを抽出することができる。好ましくは、これは、符号化のために使用される方式に従って、ビットごとのＸＯＲ演算を実行することにより行うことが可能である。
【００２２】
パーティションはＴＣＥを直接には識別しないので、マッピング方式が提供されるべきである。最も簡単な場合、パーティションの個数はＴＣＥの個数に等しい。この場合、ＩＰアドレスは、パーティションＩＤをＴＣＥ  ＩＰアドレスに直接マッピングする対応するマッピングテーブルから導出することができる。パーティションの個数がＴＣＥの個数よりも大きい場合、パーティションＩＤを、前記ＴＣＥの中間的・暗黙的な識別情報ＴＣＥ  ＩＤにマッピングするマッピングテーブルが提供されてもよい。また、これらの場合、実際のＴＣＥ  ＩＰアドレスをマッピングテーブル内の別のエントリからマッピングすることを示す特殊値がＴＣＥ  ＩＤとして採用されてもよい。結果として、事業者は、不要な設定を実行する必要がない。さらに、この特徴は、特に負荷分散の問題に関して、高度なフレキシビリティを提供する。
【００２３】
なお、上記のような分割および符号化を実行するように構成された処理手段は、さまざまなネットワークノード上に存在することが可能である。ネットワークノードとしては、ｅＮＢ（evolved NodeB）、ＲＮＣ（無線ネットワークコントローラ）およびＭＭＥ（モビリティ管理エンティティ）があるが、これらに限定されるものではない。
【００２４】
本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および１３に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００２５】
【図１】従来技術におけるトレース管理を例示するフロー図である。
【図２】従来技術によるＴＣＥ  ＩＤの利用を例示するフロー図である。
【図３】本発明の実施形態によるトレースＩＤの空間の分割を例示する模式図である。
【図４】本発明の実施形態によるトレース管理を例示するフロー図である。
【発明を実施するための形態】
【００２６】
図１は、非特許文献１（Ｖ１０．２．０（２０１０年１２月））に記載されている、ＭＤＴの起動および設定ならびにＵＥからの記録の報告の標準的手続きを例示するフロー図である。さまざまなネットワーク要素がトレーシング手続きに関与する。図１に示す具体的状況では、ＥＭ（Element Manager, 要素マネージャ）１、ＭＭＥ（モビリティ管理エンティティ）２、ｅＮＢ３、複数のＵＥ（ＵＥ１, ..., ＵＥｎと称する）４、およびＴＣＥ（トレース収集エンティティ）５がある。
【００２７】
最初のステップ１０１で、ＥＭ１が、ｅＮＢ３へトレースセッション起動要求を送信する。ＵＥ測定を設定するパラメータ（ジョブタイプ、エリア選択条件およびデバイス能力要件等）のほかに、この要求は、トレースセッションの測定値が保存されるべきＴＣＥ５のＩＰアドレスを含む。ｅＮＢ３は、そのＥＭ１からトレースセッション起動要求を受信すると、ステップ１０２で、トレースセッションを開始し、該トレースセッションに関連するパラメータを保存する。ステップ１０３で、ｅＮＢ３は、利用可能なＵＥ４からデバイス能力を取得する。ただし、デバイス能力要件はトレースセッションに対して与えられ、ｅＮＢ３は過去にそのデバイス能力を取得していなかったと仮定する。ステップ１０４で、ｅＮＢ３は、ＭＤＴデータ収集のために適切なＵＥ４を選択する。ここで選択は、例えば、ＥＭ１から受信されたデバイス能力要件およびＵＥ４から受信された実際のＵＥ能力に基づいてもよい。
【００２８】
ステップ１０５で、ｅＮＢ３は、選択されたＵＥ４に対するＭＤＴ機能を起動する。これに関して、ｅＮＢ３は、ＵＥ４へ設定情報を送信する。ＵＥがアイドルモードにある場合、この設定情報は、他の情報も含み得るが、少なくともトレースリファレンス情報要素、および、測定値が報告されるべきＴＣＥ５のＩＰアドレスを含む。ＵＥ４は、ＭＤＴ起動を受信すると、受信された設定パラメータに基づいてＭＤＴ機能を開始する。ステップ１０６に示すように、ＭＤＴ関連測定値は、ＲＲＣシグナリング（無線リソースシグナリング）経由でｅＮＢ３に報告される。ステップ１０７で、ｅＮＢ３は、ＭＭＥ２と交信し、ＭＭＥ２は、ｅＮＢ３へＭＤＴ報告を報告した与えられたＵＥ４に対するＴＣＥ５へ加入者識別（ＩＭＳＩ，ＩＭＥＩ（ＳＶ））を送信する。
【００２９】
ステップ１０８に示すように、ｅＮＢ３がＲＲＣメッセージでＵＥ４からＭＤＴ報告を受信すると、ｅＮＢ３は、それを捕捉してトレースレコードに入れる。最後に、ステップ１０９で、トレースレコードはｅＮＢ３から、ＵＥ４から受信されたＭＤＴ報告に示されているＴＣＥ５へ転送される。
【００３０】
図１を参照して上記で説明したアイドルモードにあるＵＥの記録の報告はいくつかの問題を伴う。これに関して注意すべき重要な点であるが、（ｉ）記録された測定値を受信するｅＮＢは、以前にＵＥに対してＭＤＴを設定したｅＮＢとは異なる可能性があり、（ｉｉ）ネットワークには（例えば負荷分散の目的で）複数のＴＣＥ５が存在し得る。図１では、この問題点が、ｅＮＢ＿１, ..., ｅＮＢ＿ＮおよびＴＣＥ＿１, ..., ＴＣＥ＿Ｎでそれぞれ表される破線のボックスによって示されている。３ＧＰＰで現在想定されている簡単な解決法では、ＵＥは、報告メッセージでネットワークへＴＣＥ５のＩＰアドレスを返送する（図１のステップ１０６）。
【００３１】
この状況に鑑み、本発明は、記録された測定値を受信するネットワークエンティティ（例えば図１の状況のような場合のｅＮＢ）が、ＴＣＥのＩＰアドレスを、効率的に、かつ、セキュリティ要求を満たすように、どのようにして取得することができるかという問題を解決するものである。この場合、ＵＥがアイドルモードから接続モードに移行すると当該ネットワークエンティティ（例えばｅＮＢ）でＴＣＥ  ＩＰアドレスが利用可能でなくなるという仮定の下で、測定値が報告されるべきである。
【００３２】
図２は、この問題に対する従来技術の解決法を例示するフロー図である。この解決法では、ＴＣＥ  ＩＤと称するＴＣＥの暗黙的な識別を導入する。図２において、図１と同じ参照符号は同じ要素を表す。ステップ２０１で、ＯＡＭ（Operation, Administration and Maintenance, 運用・管理・保守機能）６が、ｅＮＢ３へ、対応するＴＣＥ  ＩＰアドレスを含むＭＤＴ設定を送信する。対応するマッピングテーブルを用いることにより（ステップ２０２）、ｅＮＢ３は、受信されたＴＣＥ  ＩＰアドレスをＴＣＥ  ＩＤに変換する。ステップ２０３で、ｅＮＢ３は、ＭＤＴ設定（ＴＣＥ  ＩＰアドレスではなくＴＣＥ  ＩＤを含む）をＵＥ４へ送信する。ＵＥ４からｅＮＢ３へ返送されるＭＤＴ報告（ステップ２０４）もまた、ＴＣＥ  ＩＤのみを含む。ｅＮＢ３で報告を受信した後、ステップ２０５で、ＴＣＥ  ＩＤはバックエンドでＴＣＥ  ＩＰアドレスにマッピングされる。
【００３３】
上記のＭＤＴ手続きは、ＴＣＥ  ＩＤがグローバルに一意的でなければならないことを要求する。その結果、「ＴＣＥ  ＩＤ」に対する一般的要件として、基本的に、ＴＣＥ  ＩＤはネットワーク内で一意的でなければならない。これに対処するため、また、共有ＮＷ（network, ネットワーク）における各ＰＬＭＮ（Public Land Mobile Network, 公衆移動通信ネットワーク）がそれぞれ自己のＴＣＥ  ＩＤを設定する可能性があることも考慮して、上記の解決法は、次の形式の識別を採用する。
ＴＣＥ  ＩＤ＝ＰＬＭＮ  ＩＤ（２４ビット）＋（ＮＷ内）ＴＣＥ  ＩＤ（８ビット以下）
【００３４】
このＭＤＴ手続きは、モバイル機器およびエンドユーザにＴＣＥ  ＩＰアドレスを公表することを回避するが、希少な無線インタフェース上の追加的なシグナリングを導入する点で不利であることがわかる。ＴＣＥ  ＩＤがグローバルに一意的でなければならず、ＰＬＭＮ  ＩＤと組み合わされなければならない、という要求は依然として当てはまる。
【００３５】
これに対して、本発明の実施形態によれば、ＭＤＴに関して、３ＧＰＰネットワーク内のさまざまなネットワーク要素（例えばＲＮＣやｅＮＢ）にわたるＴＣＥ  ＩＰアドレスの効率的な送信が、上記のようなＴＣＥ  ＩＤの概念を用いることによって達成されるので、追加的な情報要素を無線で送信することが回避される。代わりに、本発明の実施形態によれば、対応する３ＧＰＰ標準化において既に存在するシグナリングメッセージ内に符号化可能なパーティションＩＤが送信される。また、ＭＤＴの従来の手続きとの後方互換性を保証する符号化メカニズムが規定される。以下で詳細に説明するように、この符号化は、無線で送信されるパーティションＩＤにＴＣＥ  ＩＰアドレスをマッピングする効率的な方法を提供する。
【００３６】
本発明の特定実施形態において、新たな情報要素を符号化するために使用される従来の情報要素は、上記の非特許文献１に規定されている「トレースリファレンス」である。この情報は、設定時にネットワークからＵＥへ送信され、報告時にＵＥからネットワークへ返送される。標準によれば、トレースリファレンス情報要素はグローバルに一意的であるべきとされるので、トレースリファレンスは次のように構成されるべきである。
ＭＣＣ＋ＭＮＣ＋トレースＩＤ
ただし、ＭＣＣ（モバイル国コード）およびＭＮＣ（モバイルネットワークコード）は、ＥＭ／ＮＭ（Element Manager/Network Manager, 要素マネージャ／ネットワークマネージャ）からのトレース起動要求に由来し、ＥＭ／ＮＭを含む１つのＰＬＭＮを識別する。また、トレースＩＤは、３バイトのオクテットストリングである。なお、ここでいうトレースＩＤは、標準の過去のリリースにおけるトレースリファレンスと同一であり、ＭＣＣ＋ＭＮＣはＲｅｌ８以降のトレースリファレンスの一部である（例えば、Ｒｅｌ６／Ｒｅｌ７のＵＴＲＡＮネットワーク要素によって無視される）ので、トレースリファレンスの一意性は、トレースに関与するＲｅｌ６／Ｒｅｌ７のネットワーク要素では保証されない可能性がある。
【００３７】
ここで説明する実施形態の一般的アプローチは、ＴＣＥ  ＩＤをパーティションＩＤにマッピングし、さまざまなネットワークノードにわたってＴＣＥ  ＩＰアドレスを伝達する情報としてパーティションＩＤを使用することである。換言すれば、ＴＣＥ  ＩＤがトレースＩＤ内に符号化され、トレースＩＤ内に符号化されたＴＣＥ  ＩＤがＵＥへ送信される。ＴＣＥ  ＩＤの重要な要件はグローバルに一意的でなければならないことである。これは、トレースリファレンス情報要素内の既存のフィールド（ＭＣＣ＋ＭＮＣ）の助けを借りて保証することができる。
【００３８】
上記のことを達成するため、以下のステップが実行される。
・各パーティションが１個以上のＴＣＥに関連づけられるように、トレースＩＤの空間がパーティションに分割される。
・トレースＩＤのシンタックスおよびセマンティクスが３ＧＰＰにおける従来の手続きと互換性があるように、パーティションＩＤがトレースＩＤ内に符号化される。
・記録された測定値を受信すると、パーティションＩＤがトレースＩＤから抽出される。
・抽出されたパーティションＩＤがＴＣＥのＩＰアドレスにマッピングされ、最終的に、中間的なＴＣＥ  ＩＤにマッピングされる。
【００３９】
以下、上記のステップについてさらに詳細に説明する。
【００４０】
トレースＩＤの空間の分割
トレースＩＤの空間のパーティションの個数は、ネットワーク内のＴＣＥの個数に依存する。パーティションの個数は、ネットワーク内のＴＣＥの個数に少なくとも等しいか、またはそれよりも大きくなるように選択される。次のステップで、パーティションの個数が、次に大きい２のべき乗（すなわち、任意のｉに対して２＾ｉ）に丸められる。
【００４１】
図３は、２つの異なる例示的状況に対するトレースＩＤ分割のプロセスを例示している。例えば、図３ａの例では、ネットワーク内に３個のＴＣＥが提供されることが仮定される（ＴＣＥ１、ＴＣＥ２、およびＴＣＥ３）。上記の方式によれば、これは、４（＝２＾２）個のパーティションが必要とされることを意味する。各パーティションにＩＤが関連づけられる。例えば、パーティション１にはＩＤ００が関連づけられ、パーティション２にはＩＤ０１が関連づけられ、パーティション３にはＩＤ１０が関連づけられ、パーティション４にはＩＤ１１が関連づけられる。
【００４２】
上記の場合、ＴＣＥの個数が２のべき乗ではないので、一部のＴＣＥが複数のパーティションに関連づけられることがあり得る。図３ａでは、これはＴＣＥ３の場合であり、ＴＣＥ３はパーティション３およびパーティション４に関連づけられている。
【００４３】
図３ｂは、２＾３＝８個のパーティションの場合のトレースＩＤ分割の対応するプロセスを例示している。これは、ＴＣＥの個数が５から８までの場合に適用可能である。
【００４４】
トレースＩＤ内でのパーティションＩＤの符号化
符号化方法は、トレースＩＤ内でパーティションＩＤを送信することに関する。トレースＩＤの空間が分割されているので、トレースＩＤのビットの一部がパーティションＩＤをトランスポートするために使用可能である。
【００４５】
例として、トレースＩＤの前方のビットがパーティションＩＤを伝達するために使用可能である。
トレースＩＤ＝［パーティションＩＤ；トレースサブＩＤ］
ただし、トレースＩＤの残りのビットは、当該トレースを識別するためのトレースサブＩＤを伝達するために使用される。
【００４６】
別法として、トレースＩＤの後方のビットが使用可能である。
トレースＩＤ＝［トレースサブＩＤ；パーティションＩＤ］
【００４７】
さらなる別法として、トレースサブＩＤとパーティションＩＤとの間でビットごとの演算を実行することが可能である。
トレースＩＤ＝（最後／最初をゼロパディングしたトレースサブＩＤ）ＸＯＲ（最後／最初をゼロパディングしたパーティションＩＤ）
【００４８】
このような場合では、対応するビットマスクが、ネットワークからＵＥへ送信されなければならない。
【００４９】
トレースＩＤからのパーティションＩＤの抽出
非特許文献１にすでに規定されているように、ＵＥは、その測定値とともにトレースリファレンスをネットワークへ返送する。記録された測定値を受信すると、ネットワークノード（例えばｅＮＢ）は、例えばビットごとの演算によって、パーティションＩＤを抽出する。
【００５０】
トレースＩＤの前方のビットがパーティションＩＤを伝達するために使用されている場合、ｅＮＢによって実行されるビットごとの演算は次のようになる。
パーティションＩＤ＝トレースＩＤ  ＸＯＲ［１..１；０..０］
【００５１】
トレースＩＤの後方のビットがパーティションＩＤを符号化するために使用されている場合は次の通りである。
パーティションＩＤ＝トレースＩＤ  ＸＯＲ［０..０；１..１］
【００５２】
いずれの場合でも、パーティションＩＤの抽出は、対応するビットマスクを使用することによって、適用された符号化方式に適応させなければならない。
【００５３】
パーティションＩＤからＴＣＥ  ＩＤおよびＩＰアドレスへのマッピング
ここで説明した本発明の実施形態では、パーティションはＴＣＥを直接には識別せず、マッピング方式が提供されるべきである。最も簡単な場合、パーティションの個数はＴＣＥの個数に等しい。この場合、パーティションＩＤは、非特許文献２で規定されているＴＣＥ  ＩＤと等価であり、ＴＣＥ  ＩＰアドレスは、次のようなマッピングテーブルから導出することができる。
【００５４】
【表１】
0005758500.tif 000002
【００５５】
パーティションの個数がＴＣＥの個数よりも大きい場合、事業者は、必要よりも多くの値を設定する必要がない点で有益である。例えば、５個のＴＣＥの場合、８個のパーティションが使用される。このような場合、事業者は、８個ではなく５個の値だけを設定するのが好ましいであろう。換言すれば、パーティションの実際の個数は事業者には隠蔽される。
【００５６】
上記の要求は、マッピングテーブルにおいてパーティションＩＤとＴＣＥ  ＩＤとを分離し、ＴＣＥ  ＩＤに対する「特殊値」を採用することによって満たすことができる。この特殊値は、実際のＩＰアドレスがテーブル内の別のエントリから（例えば、次／後続のエントリから）マッピングされるべきことを示す。特定実施形態を次のテーブルに例示する。
【００５７】
【表２】
0005758500.tif 000003
【００５８】
こうして、８個のパーティションが使用されている場合であっても、５個の値だけ設定すればよい。
【００５９】
特殊値は、マッピングテーブルの個々の実装に依存し、例えばヌル値、０の値（値０がこの目的のために予約されていると仮定する）、−１の値、あるいは変数の最大値とすることが可能である。
【００６０】
マッピングテーブルは、パーティションＩＤおよびＴＣＥ  ＩＰアドレスの列のみで使用することも可能である。
【００６１】
上記のようなＭＤＴ手続きの１つの要件は、３ＧＰＰネットワークにおけるＴＣＥ  ＩＤの一意性である。ＴＣＥの一意性は、トレースリファレンス内の情報全体を見ることによって導出することができる。実際、上記で説明したマッピングの後、ＭＣＣ，ＭＮＣを知れば、ＴＣＥへの一意的な参照が得られる。この一意的な参照は、下記のトレースリファレンス情報要素の下線部分に示されている。
トレースリファレンス＝ＭＣＣ＋ＭＮＣ＋トレースＩＤ
＝ＭＣＣ＋ＭＮＣ＋パーティションＩＤ＋トレースサブＩＤ
【００６２】
上記のメカニズムを用いたＭＤＴ手続きを図４に例示する。なお、図１に関して説明した標準のトレーシング手続きと比較して、すべてのステップは基本的に同一である。したがって、このメカニズムは従来の手続きと互換性がある。符号化、復号、抽出およびマッピングの追加ステップは図４で強調表示されている。ステップ４０１で、ｅＮＢ３は、ＴＣＥ  ＩＰアドレスとＴＣＥ  ＩＤとの間のマッピングを実行する。例えば、このステップは、ＥＭ１からトレースセッション起動メッセージを受信した直後に実行されることが可能である。ｅＮＢ３は、ＵＥ４でトレーシングを設定すると、ＵＥ４へ設定情報を送信する（図１のステップ１０５に対応）。しかし、標準の手続きとは異なり、今度は、設定メッセージはＴＣＥ  ＩＰアドレスを含まない。代わりに、ステップ４０２で、ｅＮＢ３は、上記のように、対応するＴＣＥ  ＩＤをトレースリファレンス情報要素内に符号化する。最後に、ステップ４０３が、ｅＮＢ３によって、ＵＥ測定報告を受信した後に実行され、トレースリファレンス情報要素に含まれるＴＣＥ  ＩＤが復号され、対応するＴＣＥ  ＩＰアドレスにマッピングされる。
【００６３】
トレースＩＤ空間を分割するステップは図４には明示的には示していない。というのは、これはＯＡＭ手続きにより事前に実行可能だからである。
【００６４】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【図１】
0005758500.tif 000004
【図２】
0005758500.tif 000005
【図３】
0005758500.tif 000006
【図４】
0005758500.tif 000007