JP4235915B2 - 伝送システムの伝送パラメータ測定方法 - Google Patents

Description

本発明は、一般にプロトコル・アナライザに関し、特に、伝送システムの複数のノード間のインタフェースにて伝送システムの伝送パラメータを測定する方法に関する。

世界中の多くの先進国で用いられているＧＳＭ（Global System for Mobile）通信デジタル・セル方式無線電話標準システムによると、加入者（subscriber）は、その加入者に割り当てられたセル方式ネットワークの無線周波数のみを占有する。会話の休止期間の有無にかかわらず、また、関係したプロバイダが提供し加入者が購入したサービスにかかわらず、加入者がネットワークとの接続を維持している間、その周波数が加入者に占有される。無線周波数は、任意の回数だけコピーできる資源ではなく不足しているので、この状態を改善することには価値がある。モバイル通信の第２世代（２Ｇ）システムの後に、第２．５世代（２．５Ｇ）システムとしてＧＰＲＳ（General Packet Radio Service）標準システムが提案された。第３世代（３Ｇ）の代表としては、ＵＭＴＳ（Universal Mobile Telecommunication Standard）ネットワークがある。このネットワークにより、ＧＳＭネットワークに比較して、非常に多くの加入者がサービスを受けることができ、会話が頻繁でなくそのネットワーク能力を充分に使用しない場合、利用可能なチャネルが一層効率的に分配される。また、その能力は、購入されたサービスに応じて変化する。ＵＭＴＳネットワークにより、多様な情報をチャネルで伝送できる。例えば、これら情報は、伝送システムの複数のノードの間で行き交う情報であり、複数の加入者に向けられた情報であり、特定の１個の加入者のみに向けられた情報である。これら情報は、実用情報と、管理情報とに分類される。この種のセル方式のネットワークにおける特殊インタフェースのみがアクセス可能なモニタ測定機器、プロトコル・テスタなどにとって、伝送データのデコード及び処理を可能とするために、個別チャネルがどのように占有されているかを、既に確立した接続から見つけ出さなければならないという問題がある。

ＵＭＴＳネットワークに関連して後述する用語の詳細情報は、ドメインwww.3GPP.orgから入手可能なドキュメントに記載されている。なお、ドキュメント3GPP TS 25.301は、ＵＭＴＳネットワークにおけるチャネル利用の概略を記載している。ドキュメント3GPP TS 25.427及び3GPP TS 25.435は、フレーム・プロトコル（FP: Frame Protocol）を記載し、ドキュメント3GPP TS 25.321は、媒体アクセス制御（MAC: Medium Access Control）プロトコルを記載し、ドキュメント3GPP TS25.322は、無線リンク制御（RLC: Radio Link Control）プロトコルを記載し、ドキュメント3GPP TS25.331は、無線リソース制御（RRC: Radio Resource Control）プロトコルを記載し、ドキュメント3GPP TS25.433は、ノードＢアプリケーション・パート（NBAP: Node B Application Part）プロトコルを記載している。さらに、アクセス・リンク制御アプリケーション・パート（ALCAP: Access Link Control Application Part）プロトコルの情報は、ＩＴＵ（国際電気通信連合）勧告ITS Q.2630.2から入手できる。サービス依存コネクション型プロトコル（SSCOP: Service Specific Connection Oriented Protocol）に関しては、ＩＴＳ勧告ITU Q.2110.2を参照されたい。

本発明が解決しようとする課題を理解しやすくするために、ＵＭＴＳネットワークの一部を示す図１を参照する。このＵＭＴＳネットワークは、モバイル・スイッチング・センタ（ＭＳＣ：Mobile Switching Center）１０と、３個の無線ネットワーク制御器（RNC: Radio Network Controller）１４Ａ、１４Ｂ、１４Ｃと、３個のノードＢ（Node B）１６Ａ、１６Ｂ，１６Ｃと、３個のユーザ機器（UE: User Equipment）１８Ａ、１８Ｂ、１８Ｃとを有する。ＭＳＣ１０とＲＮＣ１４の各々との間には１個のｌｕインタフェースが夫々設けられており、ＲＮＣ１４ＢとノードＢ１６Ａ、１６Ｂ、１６Ｃの各々との間には１個のｌｕｂインタフェースが夫々設けられており、ＲＮＣ１４Ａ、１４Ｂ、１４Ｃの間には１個のｌｕｒインタフェースが夫々設けられており、ユーザ機器ＵＥ１８Ａ〜１８ＣとノードＢ１６Ｂとの間には１個のＵｕインタフェースが夫々設けられている。

ノードＢ１６の機能の概略は、次の通りである。ノードＢ１６は、ＧＳＭネットワークにおけるベース・トランシーバ・システム（BTS: Base Transceiver System）の如き論理ノードを形成し：ユーザ機器との間で１個又は複数個の無線セルによる送信及び受信に応答し；ｌｕｂインタフェース、即ち、ＮＢＡＰ及びＡＬＣＡＰを終了させ；無線周波数（ＲＦ）電力制御にも用い；予め設定可能な数の無線セルを制御する。よって、ノードＢ１６は、複数の送信機及び受信機のアンテナが接続された基地局であり、これらアンテナの組合せの各々が無線セルを定義する。

ＲＮＣ１４は、無線リソースの利用及び一貫性（完全性／保全性）を制御する。ＲＮＣ１４は、ＲＡＮＡＰ（Radio Access Network Application Protocol：無線アクセス・ネットワーク・アプリケーション・プロトコル）、ＮＢＡＰ、ＡＬＣＡＰ（Access Link Control Application Part：アクセス・リンク制アプリケーション・パート）、ＲＮＳＡＰ（Radio Network Subsystem Application Part：無線ネットワーク・サブシステム・アプリケーション・パート）及びＲＲＣ／ＲＬＣ／ＭＡＣプロトコルを終了させ、ＵＭＴＳネットワークの中央要素を形成する。よって、ＲＮＣ１４は、複数の無線基地局が接続される無線スイッチング局である。

ｌｕｂインタフェースにて用いるプロトコルの機能は、次のようなものである。すなわち、ｌｕｂトランスポート・リソースの管理と；ノードＢ１６の論理動作及びメインテナンス、特に、ｌｕｂリンクの管理と；無線セル構成の管理と；無線ネットワークの性能測定と；ＣＴＣＨ（Common Transport Channel:共通トランスポート・チャネル）の管理と；無線リソースの管理と；無線ネットワーク構成のアライメントとである。さらに、これは、特定の動作及び維持トランスポートの実現と、システム情報管理の機能も含む。また、以下の機能もｌｕｂインタフェースにて実現される。すなわち、これら機能とは、共通チャネルのトラフィック管理、即ち、関連したノードＢ１６に接続された総ての加入者に適用される複数のチャネルに対する特定のアクセス制御手段と；電力管理と；データ伝送とである。さらに、これは、専用チャネル用、即ち、特定加入者に割り当てられたチャネル用のトラフィック管理と、目立つ無線リンク管理と、無線リンク監視と、チャネル割り当て／非割り当てと、電力管理と、測定リポートと、データ伝送と同様な専用トランスポート・チャネル管理とを引き継ぐ。

図２は、ｌｕｂインタフェースに含まれるプロトコル及び層を示す。最下位のプロトコル層は、物理層２０であり、その上には、データ・リンク層の基本フレーム・プロトコル（FP）２２及びその他のＳＳＣＯＰ２４プロトコルがある。層２４は、ＡＬＣＡＰ２６及びＮＢＡＰ２８に続き、これらは基地局管理を行う。ＮＢＡＰは、特に無線セルの構成にて作用し、無線セル用のチャネルを開放する。ＡＬＣＡＰリンクは、ＮＢＣＡＰが開放したチャネルの利用を定義する。ＡＬＣＡＰ２６は、ＡＴＭ（Asynchronous Transfer Mode:非同期伝送モード）トランスポート層に特定されるが、インターネット・プロトコル（ＩＰ）トランスポート層用のＡＬＣＡＰがない。しかし、以下において、ＡＴＭトランスポート層を仮定して、ＮＢＡＰ及びＡＬＣＡＰの間での識別を説明できる。本発明をＩＰトランスポート層に適用してもよいが、ＮＢＡＰ及びＡＬＣＡＰ間の識別ができなくなる。

ＡＬＣＡＰ２６及びＮＢＡＰ２８は、ＲＮＣ１４及びノードＢ１６の間で通信を行い、情報の宛先が複数のノード間となる。個別フレーム・プロトコル（ＦＰ）２２のチャネル形式は、ＦＡＣＨ（Forward Access Channel：前方アクセス・チャネル）、ＲＡＣＨ（Random Access Channel：ランダム・アクセス・チャネル）及びＰＣＨ（Paging Channel：ページング・チャネル）であり、これらは、ノードＢ１６の総ての加入者に伝えられて、情報の宛先が総ての加入者となる。また、個別フレーム・プロトコル２２のチャネル形式は、ＤＣＨ（Dedicated Channel：専用チャネル）でもあり、このＤＣＨが特定の加入者に特に伝送されて、情報の宛先が１つの加入者のみとなる。フレーム・プロトコル上の複数の論理コマンド・レベルを表せるようにするため、論理チャネルＭＡＣ３０及びＲＬＣ３２は、上述のフレーム・プロトコルを基本にしている。ＲＲＣ３４は、ＭＡＣプロトコル３０、ＲＬＣプロトコル３２を基本にしている。

図３は、ＲＮＣ１４及びノードＢ１６の間に用いるリンクを表す詳細な図である。まず、ＡＬＣＡＰリンク及びＮＢＡＰリンクがＲＮＣ１４及びノードＢ１６の間の通信を行い、次に、無線セル＃（ナンバー）１用ＦＰ−ＰＣＨリンク、即ち、総ての加入者が無線セル１に割り当てられ、ＦＰ−ＲＡＣＨリンクが無線セル＃１用となり、ＦＰ−ＦＡＣＨリンクが無線セル＃１用となり、最後に、ＦＰ−ＤＣＨリンクがユーザ機器＃１（ＵＥ１）用となる。さらに、無線セル＃ｎのＦＰリンクが例として追加されている。図３から判るように、リンクＡＬＣＡＰ及びＮＢＡＰが夫々のノードで終了している一方、リンクＰＣＨ、ＲＡＣＨ及びＦＡＣＨがノードＢ側を通過して複数の加入者に向かい、リンクＤＣＨがノードＢ側を通過して特定の加入者に向かう。ＧＳＭネットワークにおいて、上述の６個のチャネル内で伝送された情報は、単一チャネル内で伝送されるので、ＵＭＴＳネットワークの本件場合のように、複数の個部チャネルの間での識別の問題が全く生じない。

例えば、ｌｕｂインタフェース上のタスクをモニタするプロトコルを実行できるようにするため、個別チャネルの占有を知ることが必要である。さらに評価するために、リンクＮＢＡＰ２８、ＡＬＣＡＰ２６の構成と、共通制御チャネル及び専用制御チャネルの構成とが、ＲＮＣ１４及び各無線セルに接続された各ノードＢ１６に必要である。残念なことに、パラメータ又はプロトコルの変動に伴い、制御チャネルがダイナミックにオープンになる。これらチャネル用のＭＡＣ３０及びＲＬＣ３２の構成パラメータと、フレーム・プロトコル２２の構成パラメータと交換を、リンクＮＢＡＰ２８及びＡＬＣＡＰ２６を介して、各ノードＢ１６の初期化フェーズ期間中のみに行う。しかし、アクティブＵＭＴＳネットワークにおいて、モニタ機器又は試験機器がスイッチ・オンされる毎に、モニタ目的用にチャネル構成を判断するために、ノードＢ１６を再初期化することが可能ではない。

使用したデータ・パケットの長さの点から、物理層を評価するという従来方法を試した。この従来方法は、データ・パケットの長さをユーザが決められるという点に基づいている。データの形式は、ユーザが指定する長さで決まる。ユーザに関連した方法で、各ネットワークの操作者及びプロバイダが対応長を決めてデータベースに蓄積する、即ち、特にソートする。さて、特定操作者のｌｕｂインタフェースをモニタしなければならない場合、対応するデータ・エントリが要求され、対応するパラメータがロードされる。しかし、この方法は、ユーザが用いる対応パラメータが既知ではないか、時間に伴い変化する場合、タスクをモニタする満足な解決法とはならない。

特開２００２−１６４９５７公報 特開２００１−１２７８３２公報

そこで、プロトコルをモニタするタスクを容易に実行できる方法が望まれている。

本発明は、第１組の伝送パラメータの１つに応じて伝送システムの複数のノード間で通信を行うか又は第２組の伝送パラメータの１つに応じて加入者と通信を行うチャネルに対し、これら複数のノード間のマルチ・チャネル・インタフェースにてチャネルの伝送パラメータを測定する方法であって；意味のあるデータ結果が得られるか又は選択された組の伝送パラメータの総てが適用されるまで、第１組及び第２組の伝送パラメータの選択された１つの各伝送パラメータを順番に適用して受信データ・ストリームをデコードし；このデコード・ステップの結果からチャネルが複数のノード間で通信を行うものか又は加入者と通信を行うものかの判断を行う。

よって、本発明は、伝送システム内の複数ノード間で、通信プロトコルの如き伝送パラメータを測定する（求める）方法であって、プロトコル・モニタ用の自動構成処理を用いている。ここでは、既知の識別パラメータに基づいて、又は試行錯誤法により、個別のパラメータ又は通信プロトコルを自動的に判断する。この方法においては、データ・パケットのユーザ指定長がたとえ判らなくても、関連した伝送パラメータ又はプロトコルが求まる。伝送パラメータを測定するステップは、特にネットワーク標準を考慮するので、ユーザ指定の解決策を考慮しなくてよい。

本発明の目的、利点及び新規な特徴は、添付図を参照した以下の詳細な説明から明らかになろう。

従来方法も物理層２０（図２）を評価したが、後述の方法は、データ・パケット長の取り決めの如きユーザ指定の特性から自由な高次のプロトコル層を評価する。例えば本発明による方法を促進する補足的な方法においてのみ、ユーザ指定パラメータを評価し、使用する。しかし、一般的に、その知識を求めない。

本発明の好適実施例においては、次のステップが実行される。すなわち、（１）伝送システム内の複数ノード間の通信をするために、又は少なくとも１個の加入者と通信をするために、伝送パラメータとして認められる通信プロトコルに応じて、インタフェースにて受信したデータ・ストリームをデコードする。（２）現在用いている通信プロトコルによって意味のあるデータが生じると、又は、考慮している総ての通信プロトコルが任意の意味のあるデコードされたデータにならないと、直ちにデコードを停止する。（３）このデコード結果を評価して測定を行う。この測定は、（１）このチャネルが、伝送システムの複数ノード間の通信用に機能するものかであり、この伝送システムの複数ノード間の通信用に通信プロトコルを用いた際にデコードにより意味のあるデコード済みデータが得られたか、又は、デコードにより意味のあるデコード済みデータを得られなかったかを判断する。または、この測定は、（２）このチャネルが少なくとも１個の加入者との通信に機能するかであり、デコードにより意味にあるデコード済みデータが得られ通信プロトコルを少なくとも１個の加入者との通信に用いたか、又は、デコードにより意味にあるデコード済みデータが得られず、伝送システムの複数ノード間の通信用に通信プロトコルを用いたかを判断する。これは、このチャネルがＮＢＡＰ／ＡＬＣＡＰのチャネルか、フレーム・プロトコルのグループのチャネルかに関するＵＭＴＳネットワークのｌｕｂインタフェースに対して行う大雑把な判断である。

上述の判断の最初を行い、ＵＭＴＳネットワークによる場合において、このシステムの複数ノード間のいくつかの形式の通信チャネルを考察すると、次のステップを行う。すなわち、（１）第１形式の通信チャネルであると仮定した場合にデータ・ストリームの少なくとも第１データ量をデコードし、次に（２）デコードの結果を評価して別の判断を行う。デコードの結果が意味のあるデコード済みデータである場合、第１形式の通信チャネルであるとの判断になるようにダイアル位置を１だけ増分する。また、デコードの結果が意味のあるデコード済データでない場合、このチャネルが第１形式の通信チャネルではないという判断になるように別のダイアル位置を１だけ増分する。このアプローチは、ＮＢＡＰリンク用及びＡＬＣＡＰリンク用の両方が意味をなすようにするデータ・パターンがあるという事実を考慮に入れる。この理由により、１フレーム内の異なる位置でのビット・パターンを評価して、多数決判断を行う。通信チャネルが少なくとも第２形式か又は他の形式であるとの仮定により、最後に述べたデコード及び評価の２つのステップを繰り返すのが好ましい。これは、ポイントを集める形式であり、この方法において最終的に行うべき判断が影響される。少なくとも第２データ量及び別のデータ量に対して、これらデコードするステップ及び評価するステップを好ましくは繰り返す。この別のデータ量は、好ましくは、同じフレーム内のデータ量である。しかし、他のフレーム内で評価すべき対応データ量に対する他の標準の場合においても、これは可能である。これは、特に、フレーム内の対応位置に配列されたビット・パターンが評価されることを意味する。

最後に述べた評価ステップが少なくとも１回だけ実行されると、どの形式の通信チャネルか、即ち、最上位のダイアル位置を有する形式がどれかいう判断を行う。または、少なくとも２つの形式の通信チャネルが最上位ダイアル位置を占めると、どの形式の通信かという予め定めた取り決めに基づいて判断する。

上述の如く、ＵＭＴＳ形式の伝送システムにとって、インタフェースは、ｌｕｂ又はｌｕｒインタフェースかもしれず、第１ノードがＲＮＣ１４であり、第２ノードがノードＢ１６又は他のＲＮＣである。これら２個のノード間の通信用通信チャネルは、異なる形式であるＮＢＡＰ又はＡＬＣＡＰの一方である。

ＵＭＴＳネットワークの場合において、このチャネルが少なくとも１個の加入者と通信を行うかの判断を行い、また、このシステムの少なくとも１個の加入者と通信を行うためのいくつかの形式の通信チャネルを考量するならば、関連した最下位プロトコル層から最上位プロトコル層までの一連のシーケンスにおいて、１個のプロトコル層又は複数のプロトコル層のために以下のステップを実行する。ヘッダ・フィールド又は有用なデータ・フィールド内でヘッダ制御データ・フィールドを有するフレームの如き所定データ量に対して、第１ヘッダ長を仮定する。関連したヘッダ制御データ・フィールドを計算し、実際のヘッダ制御データ・フィールドと比較する。計算したヘッダ制御データ・フィールドが実際のヘッダ制御データ・フィールドと一致するならば、決定したヘッダ長に応じて、そのチャネルを通信チャネルの形式の特定グループ又は特定形式に割り当てる。計算したヘッダ制御データ・フィールドが実際のヘッダ制御データ・フィールドに一致しないと、計算したヘッダ制御データ・フィールドが実際のヘッダ制御データ・フィールドと一致するまで、異なる仮定ヘッダ長により、特定ヘッダ長と仮定した前のステップを繰り返す。

少なくとも１個の加入者との通信をこのチャネルが行うと判断した後、好ましくは次のステップを実行する。先ず、この特定チャネルがそのノードへのチャネルか又は加入者へのチャネルかを確認し、次のステップで、確認ステップの結果毎にその特定チャネルをグループ形式に割り当てる。

さらに、又は、その代わりに、このチャネルが少なくとも１個の加入者との通信を行うと判断した後に、以下のステップを実行してもよい。ヘッダ・フィールド及び有用なデータ・フィールド内でのフレームのデータ長のランニング番号（running number）用のフィールドを有するフレームの如き所定データ量に対して、ランニング番号用のフィールドの長さを求め、前の判断ステップの結果毎に特定のチャネルをグループ形式に割り当てる。ターム（term）グループは、１個のみのグループ番号を有しているかもしれない。

各場合に判断した結果を高いレベルのプロトコル層にて試験するが、判断した各結果を確認できない場合には、各結果を確認できるようになるまで、各判断ステップと、任意のその後の判断ステップ及び試験ステップを繰り返す。

少なくとも１個の加入者との通信用の特定通信チャネルは、特にＦＡＣＨ、ＲＡＣＨ、ＰＣＨ又はＤＣＨ形式の特定の伝送チャネル形式であり、特にＢＣＣＨ（放送制御チャネル：Broadcast Control Channel）、ＣＣＣＨ（共通制御チャネル：Common Control Channel）又はＰＣＣＨ（ページング制御チャネル：Paging Control Channel）形式の特定論理チャネル形式である。

上述のこの方法は、モニタ機器又はプロトコル・テスタに実施してもよく、ここでは、ソフトウェア側及びハードウェア側に実現したコンポーネントを１つの場所に配列し、伝送パラメータの伝送は他の場所で実行する。プロトコル・テスタは、装置の構成に対して伝送パラメータを自動的に設定するように設計できるので、ユーザ認定に関する要求は低く維持される。これは、短い説明の後で、ユーザがプロトコル・テスタを操作できるようにする。上述の方法と類似なものとして、プロトコル・テスタがメモリを具えてもよいし、又はメモリに結合されてもよい。ここでは、パラメータの組合せが伝送システムの特定ユーザ用にメモリに蓄積され、また、このメモリからのパラメータがユーザにより現在使用のパラメータとしてロードされる。この接続において、ユーザは、各仮定ステップ用のパラメータ組合せをアクセスできると考えられる。これは、実際の伝送パラメータの判断の時間を非常に短縮する。

上述の如く、本発明について、ＵＭＴＳセル方式ネットワークにおけるｌｕｂインタフェースを基本にして説明した。上述に限定されることなく、この方法は、ＵＭＴＳネットワーク又は他の通信ネットワークの他のインタフェースにても実施できる。第１ステップにおいて、大雑把な分類を行う。すなわち、このチャネルがフレーム・プロトコル２２のチャネルか否かの判断を行う。フレーム・プロトコル２２がない場合、このチャネルは、ＮＢＡＰ２８又はＡＬＣＡＰ２６のいずれかである。よって、特定チャネルが、伝送システムの複数のノード間で通信を行うチャネルか、又は、少なくとも１個の加入者と通信を行うチャネルかを判断する。このためには、ＲＮＣ１４及びノードＢ１６の間の通信のためか、又は少なくとも１個のユーザ機器（ＵＥ）１８との通信のためと考えられる通信プロトコルに応じて、ｌｕｂインタフェースが受けたデータ・ストリームをデコードする。現在使用している通信プロトコルにより意味のあるデータ結果となるか、又は、考慮している総ての通信プロトコルが如何なる意味のあるデコード済みデータ結果にもならないと、直ちにデコードを停止する。デコードが意味のあるデコード済みデータとなり且つ通信プロトコルを伝送システムの複数のノード間での通信に用いた場合、又は、デコードが意味のあるデコード済みデータとならず且つ総ての通信プロトコルが少なくとも１個の加入者との間の通信に用いられた場合、このチャネルは、伝送システムの複数ノード間で通信を行う。デコードが意味のあるデコード済みデータとなり且つ通信プロトコルが少なくとも１個の加入者との通信用に使用された場合、又は、デコードが意味のあるデコード済みデータとならず且つ総ての通信プロトコルが伝送システムの複数ノード間の通信用に使用された場合、このチャネルは、少なくとも１個の加入者との通信を行う。よって、この第１の場合、チャネルは、ＮＢＡＰ形式か又はＡＬＣＡＰ形式であり、第２の場合、チャネルはフレーム・プロトコルを表す。

チャネルがＮＢＡＰ２８又はＡＬＣＡＰ２６の場合、処理手順は以下のように続く。まず、ＡＬＣＡＰ又はＮＢＡＰ規則に応じて分析すべきフレームをデコードしようとする。デコード・エラーが生じると、プロトコルは他のプロトコルかもしれない。しかし、少なくともＮＢＡＰは、複雑なプロトコルであり、パケット・エンコード規則を用いてデコードされるＡＮＳ．１（Abstract Syntax Notation One）データを伝送する。完全なデコードは、効率が悪く、時間がかかる。これは、特にＵＭＴＳモニタ技術にとって考慮する必要があり、この処理速度はきわどいパラメータである。よって、分析すべきフレームのいくつかのオクテット（octet）を評価した後、これがＡＬＣＡ又はＮＢＡアプローチであるかに関する予備判断を行う。予備判断とは、選択された各データ・パケットに対して、ポイントがＡＬＣＡＰ又はＮＢＡＰの何れに与えられるかである。このステップの必要性は、ＡＬＣＡＰ規則によるデコードとＮＢＡＰ規則によるデコードの両方に対する意味のある結果を導くオクテットがあるためである。

ＡＬＣＡＰ及びＮＢＡＰの間の識別を実行する手順は、次のように行われる。第１オクテットがＮＢＡＰメッセージ形式、例えば、開始メッセージ（Initiating Message）、結果（Outcome）、好結果（Successful Outcome）又は失敗結果（Unsuccessful Outcome）の場合、ＮＢＡＰは第１ポイントを受ける。第２オクテットが有効ＮＢＡＰ処理コード、即ち、id-RadioLinkSetupの場合、ＮＡＢＰは他のポイントを受ける。第５オクテットが有効ＡＬＣＡＰメッセージ形式の場合、ＡＬＣＡＰは１ポイントを受ける。第７オクテットが存在する場合、即ち、フレーム長が７以上の場合で、且つオクテットが有効ＡＬＣＡＰパラメータ形式の場合、ＡＬＣＡＰは他のポイントを受ける。たとえメッセージ・パラメータがない場合でも、即ち、フレームが６オクテットのみを含んでいる場合でも、ＡＬＣＡＰはポイントを受ける。最後に、第７オクテットにてビット７又はビット３が「１」に等しい場合にＮＢＡＰが他のポイントを受けるが、これは、有効ＡＬＣＡＰフレームにおいて、これらビットが常に「０」（いわゆるスペア・ビット）を有するためである。

２個の候補を集めるアルゴリズムの終わりにて、多数のポイントがチェックされ、かかる候補が最終結果となる。２個の候補が同じポイント数の場合、ＡＬＣＡＰが最終結果となる。意外なことに、同じ通信チャネルの更なるフレームがこのアルゴリズムに適用されない場合、結果には良好なものがない、即ち、一層正確ではないということを実際のテストが示している。

第１分析において、チャネルがフレーム・プロトコル・チャネルであることが判ると、その手順は次のようになる。フレーム・プロトコル・チャネルの間で、３個のダウンリンク・データ・チャネル形式、即ち、加入者に向かうデータ・チャネルであるＦＡＣＨ、ＰＣＨ及びＤＳＣＨ（Downlink Shared Channel）が存在し、また、３個のアップリンク・データ・チャネル形式、即ち、ノードに向かうデータ・チャネルであるＲＡＣＨ、ＣＰＣＨ（Common Packet Channel）及びＵＳＣＨ（Uplink Shared Channel）が存在し、更に、ＤＣＨは、ダウンリンクか、アップリンクか又は双方向リンクである。これら形式の各々は、最大数のトランスポート・フォーマット、トランスポート・フォーマット・コンパイル及び論理リンク組合せの他に、異なる構成のヘッダ及びペイロードである。

残念なことに、データ・ストリームの内容からチャネル形式を識別できず、データ・フォーマットをデコードするのに必要な構成を判断できない。これは、フレーム形式フィールド及び制御フレーム形式フィールドにより識別できる制御フレームに対して異なる。

以下において、例として、データ・フレーム形式であるＦＡＣＨ、ＰＣＨ、ＲＡＣＨ及びＤＣＨの識別について説明するが、これらは、結合制御レベル用のｌｕｂインタフェースで最も一般的に用いるものである。図４は、加入者との通信の場合におけるチャネルの伝送パラメータがＦＡＣＨ形か、ＲＡＣＨ形か、ＰＣＨ形か、ＤＣＨ形かを判断する手順を示す流れ図である。ここでは、ヘッダの長さを求めることができ、ヘッダＣＲＣ（巡回符号：Cyclic Redundancy Code）を用いる。すなわち、このアルゴリズムは、ある長さを仮定し、関連したＣＲＣを計算し、これを現在のフレームの実際のＣＲＣと比較する。ＣＲＣが異なれば、ヘッダ長を他の値としてこのステップを繰り返す。ヘッダ長が判ると直ちに、いくつかのフレーム形式を識別して、ペイロードの第１バイトを特定する。図４に示すアルゴリズムを用いて、シグナリング（signalling）に用いるチャネル形式ＲＡＣＨ、ＦＡＣＨ及びＰＣＨの間で識別してもよく、データ・ストリームのチャネル形式を決定する。これは、以下の仮定に基づく。
・ＣＰＣＨ、ＤＳＣＨ及びＵＳＣＨ形式が生じない。すなわち、ＦＡＣＨ、ＲＡＣＨ、ＰＣＨ及びＤＣＨ形式のみとなる。
・ＣＲＣエラーが生じない。
・ＤＣＨをそれ以上の処理のために評価する必要がないので、無視する。
・アップリンク及びダウンリンクの方向が既知である。

図４において、判断ステップ３６にて、上述のようにヘッダのＣＲＣをチェックして、ヘッダの長さを計算する。ＣＰＣＨ及び／又はＤＳＣＨフレームが存在すると、ＤＳＣＨフレームに対してこのアルゴリズムの機能を持続する。すなわち、判断ステップ３６にて、ＤＳＣＨフレームのヘッダ・サイズが（３又は）５以上だと、ＤＣＨ形式に類似していると判断されて分離される。また、ＤＣＨ形式の判断とは別に、判断ステップ３６で、ヘッダ長が４の場合、ＦＡＣＨ、ＲＡＣＨ及びＰＣＨのチャネル形式となる。この場合、判断ステップ３８にて、方向によりアップリンクか又はダウンリンクかが判断される。アップリンクの場合、このチャネルは、ＲＡＣＨ形式である。ダウンリンクの場合、このチャネルは、ＦＡＣＨ形式又はＰＣＨ形式である。この場合、判断ステップ４０を用いて、ランニング番号（ＣＦＮ：Connection Frame Number）を評価（モニタ）、特に、このランニング番号のビット長を評価する。このビット長が８ビットならば、このチャネルはＦＡＣＨ形式であり、このビット長が１２ビットならば、このチャネルはＰＣＨ形式である。通信チャネルがＰＣＨ形式であることを更に識別する流れ図の図７に示すように、ＰＣＨチャネルは、ＲＬＣモードが「トランスペアレント」のＰＣＣＨとして記録される。

ＣＰＣＨフレームの場合、図４に示すアルゴリズムでは、ＣＰＣＨフレーム及びＲＡＣＨフレームの間を識別することができない。これは、これら両方のフレームが正確に同じ構造のためである。さらにこの場合、高次の層、例えば、ＭＡＣ３０又はＲＬＣ３２からの論理チャネルに関する知識を、要求されたＣＰＣＨフレームを知るのに用いてもよい。ヘッダ長に関するのと類似方法で、ペイロードを用いてペイロード・フレームの長さを判断してもよい。

トランスポート・フォーマット、トランスポート・フォーマット・コンパイル、又はこれらの組合せ、及び論理チャネルのモードの判断は、より一層困難である。３ＧＰＰ規格は、いくつかの所定構成を述べており、総ての製造業者は、ある設定を適用して、そのシステムを構成する。これらパラメータをデータベースに蓄積してもよい。データのほとんどは、ネットワークに依存する。好ましくは、データベースが製造業者に依存する設定のみならず、ネットワークに依存する設定も蓄積するように、このデータベースを設計する。かかるデータベースを用いて、「試行錯誤」方法によって、正確なデコードに必要な設定を決定してもよい。トランスポート・フォーマットを決定する他の方法は、ＮＢＡＰシステムのシステム情報ブロック（ＳＩＢ：System Information Block）を用いるが、これをＮＢＡＰプロトコルにてモニタしてもよい。両方の方法、即ち、データベースの利用とＳＩＢ情報の利用の両方を一緒に用いて、可能性の数を減らすことができる。

その後、上述の方法によって、どの論理チャネルをトランスポート・チャネル上に再生するかを決定する。この目的のために、以下の前提条件を仮定する。
・フレーム・プロトコル・チャネル形式に適用する上述のアルゴリズムが、トランスポート・チャネル形式であるＦＡＣＨ、ＲＡＣＨ、ＰＣＨの少なくとも１個を見つける。
・共通論理制御チャネル形式ＣＣＣＨ、ＳＨＣＣＨ、ＢＣＣＨ及びＰＣＣＨのみを再生する。
・ＦＤＤ（周波数分割二重通信：Frequency Division Duplex）のみが存在する、即ち、ＳＨＣＣＨでの再生を無視する。

論理チャネル上でのトランスポート・チャネルの再生を説明するには、次の５個のパラメータが必要である。
・論理チャネル形式。
・ＲＬＣモード（トランスパレント：Transparent, 肯定応答：Acknowledge, 非応答：Unacknowledge）。
・１個以上の論理チャネル（ＭＵＸ：多重化：multiplexed）にトランスポート・チャネルが再生された場合に、Ｃ／Ｔ（トランスポート用チャネル：Channel for Transport）フィールドの値。
・ＲＬＣ長指示フィールドの長さ（７又は１５ビット）。
・ＲＬＣユーザ（ＰＤＣＰ：Packet Data Convergence Protocol又はＲＲＣ）。

最初に挙げた３個のパラメータで、論理チャネル形式を記述するＭＡＣパケット・データ・ユニット（ＰＤＵ：Packet Data Unit）（ＴＣＴＦ＝Target Channel Type Field）の初めのビット（長さ；１〜８ビット）とトランスポート・チャネル形式から論理チャネル形式及びＲＬＣモードを決定する。

図５は、トランスポート・チャネルがＦＡＣＨ形式かを判断する流れ図を示す。最初の２ビットが「０ｘｂ００」ならば、論理チャネルがＢＣＣＨ形式であり、ＲＬＣモードが「トランスペアレント」である。最初の８ビットが「０ｘｂ０１００００００」ならば、論理チャネルがＣＣＣＨ形式であり、ＲＬＣモードが「非応答」である。これら２個の可能性の何れもないと、ＴＤＤ（Time Division Duplex）であるか又はＣＣＣ（共通制御チャネル：Common Control Channel）形式ではない。

図６は、トランスポート・チャネルがたぶんＲＡＣＨ形式であるかを判断する流れ図である。最初の２ビットが「０ｘｂ００」ならば、論理チャネルがＣＣＣＨ形式であり、ＲＬＣモードが「トランスペアレント」である。そうでなければ、ＴＤＤ又はＣＰＣＨであるか、又はＣＣＣ形式ではない。

よって、本発明の方法は、どのグループのパラメータが特定チャネルに適用できるかを大雑把に判断した後に、識別要素に基づきこのグループ内のパラメータがどの伝送パラメータかを識別することにより、伝送システムの多チャネル・ノードの間の特定チャネルに対して、通信プロトコルの如き伝送パラメータを判断する。

ＵＭＴＳセル方式のネットワークのノード及びインタフェースを示す図である。 ｌｕｂインタフェースに含まれる層及びプロトコルを示す図である。 ｌｕｂインタフェースにて生じる通信チャネルの異なる形式を示す図である。 本発明により、加入者との通信の場合であるチャネル用伝送パラメータがＦＡＣＨ形式か、ＲＡＣＨ形式か、ＰＣＨ形式か、ＤＣＨ形式かを判断する手順を示す流れ図である。 本発明により、通信チャネルがＦＡＣＨ形式であることを更に識別する手順を示す流れ図である。 本発明により、通信チャネルがＲＡＣＨ形式であることを更に識別する手順を示す流れ図である。 本発明により、通信チャネルがＰＣＨ形式であることを更に識別する手順を示す流れ図である。

符号の説明

１０ モバイル・スイッチング・センタ（ＭＳＣ）
１４ 無線ネットワーク制御器
１６ ノードＢ
１８ ユーザ機器（ＵＥ）
２０ 物理層
２２ 基本フレーム・プロトコル
２４ サービス依存コネクション型プロトコル（SSCOP）
２６ アクセス・リンク制アプリケーション・パート（ＡＬＣＡＰ）
２８ ノードＢアプリケーション・パート（NBAP）
３０ 媒体アクセス制御（MAC）
３２ 無線リンク制御（RLC）
３４ 無線リソース制御（RRC）

Claims (4)

1. 第１組の伝送パラメータの１つに応じて伝送システムの複数のノード間で通信を行うか又は第２組の伝送パラメータの１つに応じて加入者と通信を行うチャネルに対し、上記伝送システムの複数のノード間のマルチ・チャネル・インタフェースにて上記チャネルの伝送パラメータを測定する方法であって、
   意味のあるデータ結果が得られるか又は上記選択された組の伝送パラメータの総てが適用されるまで、上記第１組及び第２組の伝送パラメータの選択された１つの各伝送パラメータを順番に適用して受信データ・ストリームをデコードし、
   該デコード・ステップの結果から上記チャネルが複数のノード間で通信を行うものか又は加入者と通信を行うものかの第１判断をすることを特徴とする伝送システムの伝送パラメータ測定方法。
2. 上記第１判断で求めた上記伝送パラメータの組から上記チャネル用の伝送パラメータを求める第２判断を行うことを特徴とする請求項１の方法。
3. 上記第１組の伝送パラメータは、上記伝送システム内の上記複数のノード間で通信を行うための通信プロトコルのグループから成ることを特徴とする請求項１又は２の方法。
4. 上記第２組の伝送パラメータは、上記加入者と通信を行うための通信プロトコルのグループから成ることを特徴とする請求項３の方法。
   

Images