(57)【要約】  無線通信システムにおける物理層属性伝送効率を向上させる方法を提供し、（ａ）支持される必要のある、１セット或いは複数のセットの物理層チャンネル基本属性を定義し、セット毎は１つの属性域の値即ちＰｒｏｆｉｌｅの値で示され、（ｂ）送信デバイスは、Ｐｒｏｆｉｌｅの値で本デバイスの支持する物理層チャンネル基本属性を示す物理層のチャンネル説明情報を送信し、（ｃ）受信デバイスは、チャンネル説明情報を受信した後、情報に含まれたＰｒｏｆｉｌｅの値に基づき、当該値に対応する１セットの物理層チャンネル基本属性を支持するかどうかを判断するステップを含む。
2010524411.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおける物理層属性伝送効率を向上させる方法であって、
（ａ）１セット或いは複数のセットの物理層チャンネル基本属性を定義し、セット毎は１つの属性域の値即ちＰｒｏｆｉｌｅの値で示され、
（ｂ）送信デバイスは物理層のチャンネル説明メッセージを送信し、そのなか、Ｐｒｏｆｉｌｅの値で本デバイスの支持する物理層チャンネル基本属性を示し、
（ｃ）受信デバイスは、前記チャンネル説明メッセージを受信した後、これにおけるＰｒｏｆｉｌｅの値に基づき、送信デバイスの支持する１セットの物理層チャンネル基本属性を認知するステップを含む。
【請求項２】
前記送信デバイスは基地局或いは無線中継局であり、前記受信デバイスは移動端末或いは無線中継局であることを特徴とする請求項１に記載の方法。
【請求項３】
ステップ（ａ）において、物理層チャンネルのオプショナル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのオプショナル域の値即ちＯｐｔｉｏｎの値で示され、
ステップ（ｂ）において、前記チャンネル説明メッセージにおいて、前記送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーターを、Ｏｐｔｉｏｎの値で示し、
ステップ（ｃ）において、受信デバイスは、Ｏｐｔｉｏｎの値に基づき、送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーター情報を認知することを特徴とする請求項１に記載の方法。
【請求項４】
ステップ（ａ）において、物理層チャンネル属性パラメーターのデフォルト値をさらに定義し、
ステップ（ｂ）において、物理層チャンネル属性パラメーターの実際値とデフォルト値とは一致である場合、前記送信デバイスは、前記チャンネル説明情報において、チャンネル属性パラメーターの値を示すことはせず、
ステップ（ｃ）において、受信デバイスは、前記メッセージにはチャンネル属性パラメーターの値が見つからない場合、チャンネル属性パラメーターの値がデフォルト値であると認定することを特徴とする請求項１或いは３に記載の方法。
【請求項５】
ステップ（ｂ）において、前記物理層のチャンネル説明メッセージには、前記送信デバイスが支持する、実際値とデフォルト値が異なる属性パラメーター毎及びその実際値は、それぞれに、当該属性のタイプと値で示され、これらの属性タイプと値が示される域の前に、これらの属性タイプと値が示される域の長さを指示するための長さ域を追加することを特徴とする請求項４に記載の方法。
【請求項６】
ステップ（ａ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのパラメータークラス域の値即ちＰａｒａｍｅｔｅｒＣｌａｓｓの値で示され、
ステップ（ｂ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターが存在する場合、前記送信デバイスは、前記チャンネル説明メッセージにおいて、これらの物理層チャンネル属性パラメーターをＰａｒａｍｅｔｅｒＣｌａｓｓの値で示し、当該ＰａｒａｍｅｔｅｒＣｌａｓｓの後に、これらの物理層チャンネル属性パラメーターの実際値を、所定の順に従い、値域即ちＶａｌｕｅに書き込み、
ステップ（ｃ）において、受信デバイスは、前記ＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅの値に基づき、前記送信デバイスが支持する、実際値とデフォルト値が異なる物理層チャンネル属性パラメーター及びその実際値を獲得することを特徴とする請求項４に記載の方法。
【請求項７】
ステップ（ａ）において、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに組合、即ち、２つのセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅ域を利用して、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに示すことを特徴とする請求項６に記載の方法。
【請求項８】
ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターにおいて一部の実際値がデフォルト値と一致していない場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、
実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、
パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする請求項６に記載の方法。
【請求項９】
ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターの実際値のいずれもデフォルト値と一致する場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記ステップ（ｃ）において、受信デバイスは、
（ｃ１）受信デバイスは、属性域の値を検知し、それに対応する１セットの物理チャンネル基本属性を支持するかどうかを判断し、支持する場合にステップ（ｃ２）を行い、支持しない場合にステップ（ｃ６）を行い、
（ｃ２）オプショナル項域の値を検知し、当該値に対応する１セットのオプショナル属性パラメーター組合を支持する場合に記録し、そうでなければ無視し、
（ｃ３）長さ域の値に基づき、後にパラメータークラス域と値域がさらに存在するかどうかを判断し、存在する場合に次のステップを行い、存在しない場合にステップ（ｃ５）を行い、
（ｃ４）パラメータークラス域を検知して、事前の定義に従い、相応な値域の値を取得し、パラメータークラス域の定義を認識することができない場合に直接に廃棄し、
（ｃ５）受信デバイスは、次のアクセスを続けて、終了し、
（ｃ６）受信デバイスは、現在のネットワークから退出し、新たなネットワークを再捜索するステップに従い、物理層チャンネル属性情報を分析することを特徴とする請求項８或いは９に記載の方法。
【請求項１１】
前記送信デバイスは、複数のセットの物理層チャンネル基本属性を支持する場合、前記チャンネル説明メッセージには、複数のセットの物理層チャンネル属性情報の構成を含み、
受信デバイスは、物理層チャンネル属性情報を分析する時に、ステップ（ｃ６）において、まず、メッセージ長さ情報に基づき、後に他の１セットの物理層チャンネル属性情報が存在するかどうかを判断し、存在する場合に、同じ方式でこれに対し処理を行い、存在しない場合、現在のネットワークから退出することを特徴とする請求項１０に記載の方法。
【請求項１２】
ステップ（ａ）において、前記物理層チャンネルの基本属性と物理層チャンネルのオプショナル属性は、同一のプロトコルバージョンで規定されたものであり、プロトコルバージョン或いは選択必須な項の内容が異なる場合、異なる1セットの物理層チャンネル基本属性として、異なるＰｒｏｆｉｌｅの値に対応した上で、これにおけるオプショナル属性パラメーター組合に基づき、異なるＯｐｔｉｏｎの値を定義することを特徴とする請求項３に記載の方法。
【請求項１３】
ステップ（ａ）において、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び２段階目ｗａｖｅ２の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０１に設置し、
及び/或いは、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び３段階目ｗａｖｅ３の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０２に設置することを特徴とする請求項１２に記載の方法。
【請求項１４】
ステップ（ｂ）における物理層のチャンネル説明メッセージとは、アップリンクチャンネル説明メッセージ及び/或いはダウンリンクチャンネル説明メッセージであることを特徴とする請求項１に記載の方法。
【請求項１５】
ステップ（ｂ）において、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、
或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含むことを特徴とする請求項６に記載の方法。
【請求項１６】
前記送信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、前記受信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、或いは各域の値に対応する属性を支持するかどうかの情報を記憶していることを特徴とする請求項１、３、６のいずれか１つに記載の方法。
【請求項１７】
チャンネル説明メッセージにおける物理層チャンネル属性情報の構成であって、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、
実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、
パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する、長さ域Ｌｅｎｇｔｈと、の域を含むことを特徴とする。
【請求項１８】
チャンネル説明メッセージにおける物理層チャンネル属性情報の構成であって、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする。
【請求項１９】
チャンネル説明メッセージにおける物理層チャンネル属性情報の構成であって、
１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、
或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含むことを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムのエアーリンクの伝送効率を向上させる方法に関し、特に、物理層のエアーインターフェースブロードキャスト情報の伝送効率の向上方法に関する。
【背景技術】
【０００２】
現在、多種の無線通信システム、例えばＣＤＭＡ２０００、ＷＣＤＭＡ、ＷｉＭＡＸ、Ｗｉ−Ｆｉ等が存在する。これらの無線通信システムにとって、エアーインターフェースの伝送効率をいかに向上させるという共通の問題がある。従って、物理層（ＭＡＣ）、層２（例えば、ＬＴＥのＭＡＣ、ＵＭＢのＭＡＣ、ＷｉＭＡＸシステムのＭＡＣ、Ｗｉ−ＦｉのＭＡＣ層）のいずれにおいても、制限されたスペクトル帯域幅と制限された無線リソースに、より高い伝送効率をいかに取得することが検討されている。
【０００３】
本願では、主に検討されたのは、層２のメッセージフォーマットに対する設計である。
ＩＥＥＥ８０２．１６ｅ−２００５を例として、現在、このプロトコルにおいて、ＯＦＤＭＡを支持するＤＣＤ（ダウンリンクチャンネル説明）メッセージ構成は以下のようである。
【０００４】
【表１】
2010524411.tif 000003
【０００５】
ここで、ＴＬＶ  Ｅｎｃｏｄｅｄ  ｉｎｆｏｒｍａｔｉｏｎ  ｆｏｒ  ｔｈｅ  ｏｖｅｒａｌｌ  ｃｈａｎｎｅｌという領域の内容の定義は以下のようである。
【０００６】
【表２】
2010524411.tif 000004
【０００７】
【表３】
2010524411.tif 000005
【０００８】
【表４】
2010524411.tif 000006
【０００９】
【表５】
2010524411.tif 000007
【００１０】
【表６】
2010524411.tif 000008
【００１１】
このことから、以上の情報ユニット毎は、Ｔｙｐｅ（タイプ）→Ｌｅｎｇｔｈ（長さ）→Ｖａｌｕｅ（値）の形式で構造されたものである。即ち、１つの情報ユニットを運ぶために、まず、１つのバイトで情報ユニットタイプ（Ｔｙｐｅ）を説明しなければならない、そして１つのユニットの長さの説明（Ｌｅｎｇｔｈ）であり、次は本格の情報ユニット内容（Ｖａｌｕｅ）である。
【００１２】
当該メッセージは、周期的に、所轄セル内の全ての端末や無線中継局に対しブロードキャストされ、端末と無線中継局は、これにおける情報を受信して認識し、物理層属性記録を更新する。演算によれば、当該メッセージの長さは少なくとも７２バイトであることが知られる。これには、ある情報フィールドを複数含むことが可能であるため、実際利用の場合に、７２バイトよりも多いことになる。１６ｅの定義によると、当該メッセージはブロードキャスト送信であり、少なくとも１０秒毎に１回送信され、この７２バイトは、少なくとも１２個のタイムスロットを占用する必要がある。スロット毎は２つの符号、１つのサブチャンネル（２４個のデータサブキャリア波）を占用する必要があり、アップリンクとダウンリンクの比が１：１であることから計算すると、この７２個のバイトは、全部１０Ｍのバンド幅のうちの０．４１８５６Ｍバンド幅において伝送される必要があり、即ち、このメッセージは、送信される時間（５ｍｓ以内）に、少なくとも４．１９％の無線リソースを占用することになる。
【００１３】
これは、このうちの１つのＭＡＣブロードキャストメッセージに過ぎない。１６ｅのプロトコルによれば、ＵＣＤ、ＤＬＭＡＰ、ＵＬＭＡＰなどのメッセージもブロードキャスト送信である。このようなブロードキャストメッセージは、大量なエアーインターフェース無線リソースを消耗することが考えられる。
他の無線システムにおいても、このような伝送チャンネル物理層属性のブロードキャストメッセージが存在し、そして、このようなメッセージは、一般的に、周期的な送信が必要である。従って、このようなメッセージの占用するバイトを低減させることができれば、無線リソースの占用を大幅に低減させることができる。
【００１４】
また、無線リソースに対する大量な占用のため、基地局能力に対する拡張は基本的に不可能になってしまう。これは、能力の拡張は、能力情報を伝送するためのバイトがもっと必要であるからである。このようなメッセージの占用するバイトを低減されることができれば、同じリソース占用状況においても、より多い能力選択を提供し、ユーザに対しもっと個性のあるサービスを提供することができる。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本発明が解決しようとする技術課題は、無線通信システムにおける物理層属性伝送効率を向上させる方法を提供し、物理層のチャンネル属性メッセージの占用するリソースを低減させる。
【課題を解決するための手段】
【００１６】
前記の技術課題を解決するために、本発明は、無線通信システムにおける物理層属性伝送効率を向上させる方法を提供し、（ａ）１セット或いは複数のセットの物理層チャンネル基本属性を定義し、セット毎は１つの属性域（domain of attributes）の値即ちＰｒｏｆｉｌｅの値でそれぞれ示され、（ｂ）送信デバイスは、物理層のチャンネル説明メッセージを送信し、そのなか、Ｐｒｏｆｉｌｅの値で本デバイスの支持する物理層チャンネル基本属性を示し、（ｃ）受信デバイスは、前記チャンネル説明メッセージを受信した後、これにおけるＰｒｏｆｉｌｅの値に基づき、送信デバイスの支持する１セットの物理層チャンネル基本属性を取得するステップを含む。
【００１７】
さらに、前記方法では、前記送信デバイスは基地局或いは無線中継局であり、前記受信デバイスは移動端末或いは無線中継局であることを特徴としてさらに有してもよい。
さらに、前記方法では、ステップ（ａ）において、物理層チャンネルのオプショナル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのオプショナル域の値即ちＯｐｔｉｏｎの値で示され、ステップ（ｂ）において、前記チャンネル説明メッセージにおいて、前記送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーターを、Ｏｐｔｉｏｎの値で示し、ステップ（ｃ）において、受信デバイスは、Ｏｐｔｉｏｎの値に基づき、送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーター情報を取得することを特徴としてさらに有してもよい。
【００１８】
さらに、前記方法では、ステップ（ａ）において、物理層チャンネル属性パラメーターのデフォルト値をさらに定義し、ステップ（ｂ）において、物理層チャンネル属性パラメーターの実際値とデフォルト値とは一致である場合、前記送信デバイスは、前記チャンネル説明情報において、チャンネル属性パラメーターの値を示すことはせず、ステップ（ｃ）において、受信デバイスは、前記メッセージにはチャンネル属性パラメーターの値が見つからない場合、チャンネル属性パラメーターの値がデフォルト値であると認定することを特徴としてさらに有してもよい。
【００１９】
さらに、前記方法では、ステップ（ｂ）において、前記物理層のチャンネル説明メッセージには、前記送信デバイスが支持する、実際値とデフォルト値が異なる属性パラメーター毎及びその実際値は、みんな当該属性のタイプと値で示され、これらの属性タイプと値を示する域の前に、これらの属性タイプと値が示される域の長さを指示するための長さ域を追加することを特徴としてさらに有してもよい。
【００２０】
さらに、前記方法では、ステップ（ａ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのパラメータークラス域の値即ちＰａｒａｍｅｔｅｒＣｌａｓｓの値で示され、ステップ（ｂ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターが存在する場合、前記送信デバイスは、前記チャンネル説明メッセージにおいて、これらの物理層チャンネル属性パラメーターをＰａｒａｍｅｔｅｒＣｌａｓｓの値で示し、当該ＰａｒａｍｅｔｅｒＣｌａｓｓの後に、これらの物理層チャンネル属性パラメーターの実際値を、所定の順に従い、値域即ちＶａｌｕｅに書き込み、ステップ（ｃ）において、受信デバイスは、前記ＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅの値に基づき、前記送信デバイスが支持する、実際値とデフォルト値が異なる物理層チャンネル属性パラメーター及びその実際値を獲得することを特徴としてさらに有してもよい。
【００２１】
さらに、前記方法では、ステップ（ａ）において、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに組合、即ち、２つのセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅ域を利用して、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに示すことを特徴としてさらに有してもよい。
【００２２】
さらに、前記方法では、ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターにおいて一部の実際値がデフォルト値と一致していない場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する、長さ域Ｌｅｎｇｔｈとの域を含むことを特徴としてさらに有してもよい。
【００２３】
さらに、前記方法では、ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターの実際値のいずれもデフォルト値と一致する場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する、長さ域Ｌｅｎｇｔｈとの域を含むことを特徴としてさらに有してもよい。
【００２４】
さらに、前記方法では、前記ステップ（ｃ）において、受信デバイスは、（ｃ１）受信デバイスは、属性域の値を検知し、それに対応する１セットの物理チャンネル基本属性を支持するかどうかを判断し、支持する場合にステップ（ｃ２）を行い、支持しない場合にステップ（ｃ６）を行い、（ｃ２）オプショナル項の値を検知し、当該値に対応する１セットのオプショナル属性パラメーター組合組合を支持する場合に記録し、そうでなければ無視し、（ｃ３）長さ域の値に基づき、後にパラメータークラス域と値域がさらに存在するかどうかを判断し、存在する場合に次のステップを行い、存在しない場合にステップ（ｃ５）を行い、（ｃ４）パラメータークラス域を検知して、事前の定義に従い、相応な値域の値を取得し、パラメータークラス域の定義を識別することができない場合に直接に廃棄し、（ｃ５）受信デバイスは、次のアクセスを続け、終了し、（ｃ６）受信デバイスは、現在のネットワークから退出し、新たなネットワークを再捜索するステップに従い、物理層チャンネル属性情報を分析することを特徴としてさらに有してもよい。
【００２５】
さらに、前記方法では、前記送信デバイスは、複数のセットの物理層チャンネル基本属性を支持する場合、前記チャンネル説明メッセージには、複数のセットの物理層チャンネル属性情報の構成を含み、受信デバイスは、物理層チャンネル属性情報を分析する時に、ステップ（ｃ６）において、まず、メッセージ長さ情報に基づき、後に他の１セットの物理層チャンネル属性情報が存在するかどうかを判断し、存在する場合に、同じ方式でこれに対し処理を行い、存在しない場合、現在のネットワークから退出することを特徴としてさらに有してもよい。
【００２６】
さらに、前記方法では、ステップ（ａ）において、前記物理層チャンネルの基本属性と物理層チャンネルのオプショナル属性は、同一のプロトコルバージョンで規定されたものであり、プロトコルバージョン或いは選択必須（mandatory）な項の内容が異なる場合、異なる1セットの物理層チャンネル基本属性として、異なるＰｒｏｆｉｌｅの値に対応した上で、これにおけるオプショナル属性パラメーター組合に基づき、異なるＯｐｔｉｏｎの値を定義することを特徴としてさらに有してもよい。
【００２７】
さらに、前記方法では、ステップ（ａ）において、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び２段階目ｗａｖｅ２の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０１に設置し、及び/或いは、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び３段階目ｗａｖｅ３の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０２に設置することを特徴としてさらに有してもよい。
【００２８】
さらに、前記方法では、ステップ（ｂ）における物理層のチャンネル説明メッセージとは、アップリンクチャンネル説明メッセージ及び/或いはダウンリンクチャンネル説明メッセージであることを特徴としてさらに有してもよい。
【００２９】
さらに、前記方法では、ステップ（ｂ）において、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラスＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含むことを特徴としてさらに有してもよい。
【００３０】
さらに、前記方法では、前記送信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、前記受信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、或いは各域の値に対応する属性を支持するかどうかの情報を記憶していることを特徴としてさらに有してもよい。
【００３１】
本発明は、チャンネル説明メッセージにおける物理層チャンネル属性情報の構成をさらに提供し、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする。
【００３２】
或いは、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含む。
【００３３】
具体的に、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含む。
【００３４】
前述のように、本発明は、斬新なＭＡＣ層メッセージの構造方法、及び基地局と端末がこのようなメッセージ構成を構造及び分析するフローと方法を提供し、ＭＡＣ層メッセージの伝送をより適切に且つ効率に行い、無線リソース利用率を大幅で低減させる。従来の技術に比較すると、同じ情報内容を伝送する場合、本発明の提供したＭＡＣ方法による無線リソースの占用は、現在の標準に定義された方法の８％〜５７％の程度である。本発明に係る方法によれば、このようなメッセージをエアーで伝送する必要がある場合、エアーリソースの占用を大幅で低減させ、基地局の柔軟性を向上させ、端末と基地局の処理を簡潔にさせ、システム全体の機能を向上させる。
【図面の簡単な説明】
【００３５】
【図１】図１は本発明の実施例の方法のフローチャートである。
【発明を実施するための形態】
【００３６】
従来の技術の内容から、既存の物理層のチャンネル説明メッセージは、物理情報の毎種の属性に対し、タイプと長さと値とを含む情報ユニットの形式でそれぞれに説明することがわかる。このような方式は、各種の属性及びその値を任意に組み合うことができるため、いい柔軟性を有している。しかしながら、実際の基地局の支持する物理層チャンネル属性及びその値は、任意に組合されるものではない。
【００３７】
例えば、ＷｉＭＡＸ  Ｆｏｒｕｍは、オペレーターの要求に応じて、システム属性（Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅ）バージョン１．０．０、対応なプロトコル一致性テスト説明（ＰＩＣＳ）バージョン１．０．０、及び２段階目（ｗａｖｅ２）の要求する選択必須な内容が定義され、ここで、ＤＣＤメッセージに対する要求は、以下のテーブルのように選択的に示される。
【００３８】
【表７】
2010524411.tif 000009
【００３９】
【表８】
2010524411.tif 000010
【００４０】
【表９】
2010524411.tif 000011
【００４１】
【表１０】
2010524411.tif 000012
【００４２】
これは、1セットのＰｒｏｆｉｌｅの例であり、ここで、Ｓｔａｔｕｓ域における‘ｍ’は、支持しなければならないを示す。後は、必要に応じて、Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０に基づくｗａｖｅ３の要求を定義する可能性がある。
【００４３】
物理チャンネルが必ず支持しなければならないのような属性について、物理チャンネル基本属性という。このような約定された1セットのＰｒｏｆｉｌｅに対し、１つの唯一の標記（例えば番号）を約定することができ、基地局は、メッセージの特定域において、このＰｒｏｆｉｌｅの標記を送信し、端末は、基地局の支持する物理チャンネル基本属性をわかることができ、従来の技術では基本属性情報毎を１つずつ伝送することに比較すると、大量のリソースを節約することが明らかである。
【００４４】
物理チャンネルは、基本属性に加え、増強の属性を有してもよく、物理チャンネルオプショナル属性と呼ばれ、これらのオプショナル属性についても、端末に通知する必要がある。これらのオプショナル属性の数は相対的に少ないため、オプショナル属性選択した後に出現可能な各種の結果、即ち基地局の支持するオプショナル属性パラメーター（属性パラメーターは、相応な属性に利用されるパラメーターである）の各種の組合に対し、それぞれに１つの標記（例えば番号）を約定して、メッセージの特定域に書き込んで送信してもよく、端末は、当該標記に基づき、基地局の支持する物理チャンネルオプショナル属性をわかるすることができる。もちろん、オプショナル属性が少ない場合、これらのオプショナル属性パラメーターのタイプを、メッセージに１つずつ標記してもよいことは言うまでもない。
【００４５】
さらに、基地局の支持する物理チャンネル属性以外、各物理チャンネル属性パラメーターの値を示すことが必要な場合があり、物理チャンネルの属性（基本とオプショナルを含む）パラメーター毎に対し、デフォルト値を約定することができる。物理チャンネル属性パラメーターの実際値はデフォルト値ではない場合、メッセージの特定域に明らかに示す。そうでなければ、これらのパラメーターの実際値はデフォルト値と一致していると認定する。
【００４６】
以下、図面と具体的な実施形態を合わせて、本発明に係る内容について詳しく説明する。
【００４７】
（第１の実施例）
以上の分析に基づき、本発明の実施例のＭＡＣメッセージにおける物理層チャンネル属性情報の構造は以下のようである。
【００４８】
【表１１】
2010524411.tif 000013
【００４９】
ここで、Ｐｒｏｆｉｌｅ（属性域）、Ｌｅｎｇｔｈ（長さ域）、Ｏｐｔｉｏｎ（オプショナル項域）、ＰａｒａｍｅｔｅｒＣｌａｓｓ（パラメータークラス域）は、デフォルトが１バイトである。０ｘＦＦ（或いは他のある特定値）に設置した場合、次のバイトは本属性メッセージ域の拡張値であることを示し、そうでなければ、本域は1バイトのみである。
【００５０】
ここで、Ｐｒｏｆｉｌｅの値、即ちＰｒｏｆｉｌｅにおける値は、1セットの必ず支持しなければならない物理チャンネル基本属性に対応し、前文におけるシステム属性（Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅ）バージョン号に基づき定義してもよく、他の国際或いは国内の標準に基づいてもよい。拡張性を支持するために、Ｐｒｏｆｉｌｅの１バイト目は０ｘＦＦである場合、次のバイトはＰｒｏｆｉｌｅの拡張値であることを示し、そうでなければ、Ｐｒｏｆｉｌｅは1バイトのみであり、次のバイトはＬｅｎｇｔｈ域である。Ｐｒｏｆｉｌｅの値の意味は、予め定義される必要がある。
【００５１】
Ｌｅｎｇｔｈの値は、このＰｒｏｆｉｌｅの後ろに含まれる全ての内容の長さを示す。バイトを単位とする。拡張性を支持するために、Ｌｅｎｇｔｈの１バイト目は０ｘＦＦである場合、次のバイトはＬｅｎｇｔｈの拡張値であることを示し、そうでなければ、Ｌｅｎｇｔｈは1バイトのみであり、次のバイトはＯｐｔｉｏｎ域である。
【００５２】
Ｏｐｔｉｏｎの値は、増加された物理チャンネルオプショナル属性の1種の組合に対応する。Ｏｐｔｉｏｎ域の導入は、基地局の能力を柔軟的に拡張すると共に、基地局の機能を向上させることができる。新たな属性を増加していない場合、この域は、０ｘ００で直接に示すことができる。拡張性を支持するために、Ｏｐｔｉｏｎの１バイト目は０ｘＦＦである場合、次のバイトはＯｐｔｉｏｎの拡張値であることを示し、そうでなければ、Ｏｐｔｉｏｎ域は1バイトのみの長さであり、次のバイトはＰａｒａｍｅｔｅｒＣｌａｓｓ域である。Ｏｐｔｉｏｎの値の意味は、予め定義される必要がある。
【００５３】
ＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅとの２つの域は同時に出現するものであり、前記ＰｒｏｆｉｌｅとＯｐｔｉｏｎで示された属性集合には有効である。この２つの域は、当該属性集合においてどの属性パラメーターの値とデフォルト値が一致していないこと、及びその実際値の数を示す。これは、この２つの域はオプショナルであることを示し、全ての属性パラメーターの値とデフォルト値が一致している場合、この２つの域が必要ではない。ここで、ＰａｒａｍｅｔｅｒＣｌａｓｓとしては、標準における属性パラメータークラス値を直接に利用することができ、直後にこのタイプの属性パラメーターの実際値を付ける。複数の属性パラメーターの実際値とデフォルト値が一致していない場合、複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで示すことができる。他の１つの方式では、ＰａｒａｍｅｔｅｒＣｌａｓｓの値で、実際値とデフォルト値が一致していない複数の属性パラメーターの１種の組合を示し、Ｖａｌｕｅは、これらの実際値を示すために用いられる。もちろん、複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅを利用し、１セットは、選択必須属性における、実際値とデフォルト値が一致していない属性パラメーター及びその実際値を示すために用いられ、他の１セットは、オプショナル属性における、実際値とデフォルト値が一致していない属性パラメーター及びその実際値を示すために用いられ、或いは他のグループ化方法を利用してもよい。組合タイプを予め定義して、実際値を提供することにより、基地局属性を柔軟的に設置することができる。
本実施例では、この５つの域の間の関係は以下のようである。
【００５４】
【数１】
2010524411.tif 000014
【００５５】
つまり、セット毎のＰｒｏｆｉｌｅに加え、１セットのオプショナル属性組合をさらに含み、Ｏｐｔｉｏｎの値で示す（オプショナル属性が無い場合に０で示すことができる）ことが可能である。さらに、ＰｒｏｆｉｌｅとＯｐｔｉｏｎ域の範囲内に、１セット或いは複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで、実際値とデフォルト値が一致していない１セットの属性パラメーター及びその実際値を提供する。選択必須に係るパラメーターは前に位置し、オプショナルに係るパラメーターは後ろに位置する。指定されたＰｒｏｆｉｌｅとＯｐｔｉｏｎ域には、ＰａｒａｍｅｔｅｒＣｌａｓｓ毎は１種の属性パラメーター（Ｐａｒａｍｅｔｅｒ）組合のタイプに対応し、対応なＶａｌｕｅ域には、各パラメーターのバイト長さ及び各パラメーターの配列順位は固定である。
【００５６】
送信デバイス（例えば基地局、無線中継局）は、前記物理層のチャンネル属性情報構成における各域の値と相応属性の対応関係を記憶しており、受信デバイス（例えば端末、無線中継局）は、前記物理層のチャンネル属性情報構成における各域の値と相応属性の対応関係を記憶しており、或いは各域の値に対応する属性を支持するかどうかの情報を記憶している。
【００５７】
以下、送信デバイスと受信デバイスとが各状況において、いかにこの構成を利用して物理層チャンネル説明情報の構造と送信と分析とを行うかについて、具体的に説明する。
ＭＡＣ  ＤＣＤメッセージを例とし、他のメッセージも類似である。図１に示すように、当該方法は以下のステップを含む。
【００５８】
ステップ１０：ＷｉＭＡＸ基地局は、本基地局の物理層チャンネル属性情報を獲得し、前記規則に従い、当該情報を示すための各域の値を確定する。
【００５９】
１）Ｐｒｏｆｉｌｅ域の値
前文では、ＷｉＭＡＸ  Ｆｏｒｕｍはシステム属性（Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅ）バージョン１．０．０、対応なプロトコル一致性テスト説明（ＰＩＣＳ）バージョン１．０．０、及び２段階目（ｗａｖｅ２）の要求する選択必須な内容が定義されることは既に記載されている。このセットのＰｒｏｆｉｌｅの値を、Ｐｒｏｆｉｌｅ＝０ｘ０１と定義する。後は必要に応じて、Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０に基づくｗａｖｅ３の要求を定義する可能性があり、ここで、Ｐｒｏｆｉｌｅ＝０ｘ０２と定義することができる。次も類似である。
【００６０】
Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅのバージョンには変更が起こる場合、新たなＳｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン及び対応な異なる選択必須項、例えばＳｙｓｔｅｍＰｒｏｆｉｌｅバージョン１．０．１のｗａｖｅ１を、さらに、新たなＰｒｏｆｉｌｅ値：０ｘ０４と定義することができる。次も類似である。
【００６１】
前述のように、ＷｉＭＡＸの特性に対し、Ｐｒｏｆｉｌｅの定義原則は、ＳｙｓｔｅｍＰｒｏｆｉｌｅバージョンに関連し、選択必須項内容の変更に関連するものである。この２つのうちの１つには変化が起こる場合、新たなＰｒｏｆｉｌｅ値を定義する必要がある。即ち、対応な１セットの物理チャンネル基本属性が異なる場合、異なるＰｒｏｆｉｌｅ値を利用すべきである。
【００６２】
２）Ｏｐｔｉｏｎ域の値
Ｐｒｏｆｉｌｅ＝０ｘ０１を例として、ＳｙｓｔｅｍＰｒｏｆｉｌｅバージョンｖ１．０．０において、ＦＢＳＳ及びＨＡＲＱに対する支持はオプショナルである。基地局は、ネットワーク側から獲得された能力情報から、自身がＦＢＳＳという能力を備えることを認知すると、ＩＥＥＥ８０２．１６ｅの定義に従い、ＤＣＤメッセージに、Ｈ＿Ａｄｄ  ＴｈｒｅｓｈｏｌｄとＨ＿Ｄｅｌｅｔｅ  ＴｈｒｅｓｈｏｌｄとＡＳＲとの３つの情報フィールドを増加する必要がある。
【００６３】
Ｏｐｔｉｏｎ域により、このセットのオプショナル属性パラメーター組合に対応するＯｐｔｉｏｎ値はＯｐｔｉｏｎ＝０ｘ０１であることを確定することができ、本基地局はＦＢＳＳのみを支持することを示す。同様に、ＨＡＲＱのみを支持する場合、このセットのオプショナル属性パラメーター組合に対応するＯｐｔｉｏｎ値をＯｐｔｉｏｎ＝０ｘ０２と定義することができ、本基地局はＨＡＲＱを支持することを示す。２つのオプショナル属性とも支持する場合、０ｘ０３と定義する。基地局の獲得した能力情報においてオプショナル項の内容が存在しない即ちＦＢＳＳとＨＡＲＱを支持しない場合、基地局はＯｐｔｉｏｎ域を０ｘ００に設置することができ、いずれのオプショナル項も支持しないことを示す。新たなバージョンのＳｙｓｔｅｍＰｒｏｆｉｌｅに基づき、新たなオプショナル項はＤＣＤメッセージの支持が必要である場合、以上の原則に従い、新たなオプショナル属性パラメーター組合に対応するＯｐｔｉｏｎの値を定義することができる。
【００６４】
他の１つの実施様態では、オプショナル項の内容がない場合、この域を取り消し、前のＬｅｎｇｔｈフィールドを０ｘ００に設置してもよい。
【００６５】
３）ＰａｒａｍｅｔｅｒＣｌａｓｓと対応なＶａｌｕｅ域の値
つづいては、基地局が、前記ＰｒｏｆｉｌｅとＯｐｔｉｏｎ域の範囲内に、ＰａｒａｍｅｔｅｒＣｌａｓｓと対応なＶａｌｕｅの値をいかに構造することに関する。
以下、４つの例を挙げる。
【００６６】
第１の例は、Ｐｒｏｆｉｌｅ＝０ｘ０１、Ｏｐｔｉｏｎ＝０ｘ００を例とし、ＤＣＤメッセージにおけるＢＳＩＤ情報ユニットはＰｒｏｆｉｌｅ域に属し、そのデフォルト値は０ｘ０００００００００００１であり、本基地局の配置によると、実際値は０ｘ００３２００００００００であり、また、ＰａｇｉｎｇＧｒｏｕｐＩＤのデフォルト値は０ｘ０００１であり、配置によると、本基地局の対応するＰａｇｉｎｇＧｒｏｕｐＩＤ＝０ｘ０１０２である場合、１セットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで、これらの実際の値の提供に協力することが必要である。例えば、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ０Ｄにより、次のバイトから実際のＢＳＩＤ値とＰａｇｉｎｇＧｒｏｕｐＩＤ値を順に提供し、直後のＶａｌｕｅが全部８バイトを有することを示す。前の６バイトは実際のＢＳＩＤ値を示し、例えば０ｘ００３２００００００００であり、次の２バイトはＰａｇｉｎｇＧｒｏｕｐＩＤ値、０ｘ０１０２である。他の情報ユニットは全てデフォルト値を利用する。以下のテーブルに示すように、
【００６７】
【表１２】
2010524411.tif 000015
【００６８】
第２の例は、Ｐｒｏｆｉｌｅ＝０ｘ０１、Ｏｐｔｉｏｎ＝０ｘ０１を例とし、基地局は、配置から、選択必須項におけるＢＳＩＤ、ＰａｇｉｎｇＧｒｏｕｐＩＤとオプショナル項におけるＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲの３つの情報フィールドが全てデフォルト値とは一致していないことを認知する場合、１セットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで、これらの実際の値の提供に協力することも必要である。例えば、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ１２により、次のバイトから実際のＢＳＩＤとＰａｇｉｎｇＧｒｏｕｐＩＤとＨ＿Ａｄｄ  ＴｈｒｅｓｈｏｌｄとＨ＿Ｄｅｌｅｔｅ  ＴｈｒｅｓｈｏｌｄとＡＳＲとの値を順に提供し、直後のＶａｌｕｅが全部１１バイトを有することを示す。前の６バイトは実際のＢＳＩＤ値を示し、例えば０ｘ００１２００１２０００１である。７、８バイト目はＰａｇｉｎｇＧｒｏｕｐＩＤを示し、例えば０ｘ００５５であり、９、１０、１１バイト目は、Ｈ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲの３つの情報ユニットをそれぞれに示し、例えば０ｘ１０、０ｘ０９、０ｘ２３である。以下のテーブルに示すように、
【００６９】
【表１３】
2010524411.tif 000016
【００７０】
第３の例は、第２の例と同じ状況において、２セットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで示してもよい。例えば、依然Ｐｒｏｆｉｌｅ＝０ｘ０１、Ｏｐｔｉｏｎ＝０ｘ０１を例として、基地局は、配置から、選択必須項におけるＢＳＩＤ、ＰａｇｉｎｇＧｒｏｕｐＩＤとオプショナル項におけるＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲの３つの情報フィールドが全てデフォルト値とは一致していないことを認知する場合、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ０Ｄ及び対応なＶａｌｕｅで実際のＢＳＩＤ、ＰａｇｉｎｇＧｒｏｕｐＩＤの値を定義するとともに、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ０Ｅ及び対応なＶａｌｕｅで実際のＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲを定義し、例えば０ｘ１０、０ｘ０９、０ｘ２３である。即ち、２セットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅで、実際に利用された情報ユニット値を説明する。以下のテーブルに示すようである。
【００７１】
【表１４】
2010524411.tif 000017
【００７２】
この場合、前の定義方式より占用したバイトが多いが、追加定義の情報ユニット組合に対し、よりよい柔軟性を備えている。
【００７３】
ＰａｒａｍｅｔｅｒＣｌａｓｓの組合定義も予め定義済みであり、送信デバイスと受信デバイスとも認識することができる必要があることは説明すべきである。ここで、異なる組合方式で同じ意味を示すことは、本発明に定義された方法によれば、組合と拡張を柔軟的に行えることを説明するためである。
【００７４】
第４の例は、基地局は、配置から、自身の現在の物理層属性パラメーターが全てデフォルト値を利用することを認知する場合、Ｐａｒａｍｅｔｅｒ＋Ｖａｌｕｅで更新を行う必要はない。
【００７５】
４）Ｌｅｎｇｔｈ域の値
最後、基地局は、長さ（Ｌｅｎｇｔｈ）域の実際値を算出し、当該長さは、ＯｐｔｉｏｎとＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの占用したバイト数と一致する。
【００７６】
ステップ２０：基地局は、取得した各域の値に基づき、ＭＡＣ  ＤＣＤメッセージにおける物理層チャンネル属性情報部分を構造し、メッセージ全体の構造をさらに完成してから受信デバイスに送信する。
【００７７】
メッセージにおける物理層チャンネル属性情報部分の構成は、Ｐｒｏｆｉｌｅ＋Ｌｅｎｇｔｈ＋Ｏｐｔｉｏｎ＋ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの方式で構造され、他の部分は、プロトコルの規定した方式で構造される。この例には、メッセージタイプ域（ＭｅｓｓａｇｅＴｙｐｅ）と保留フィールド域（Ｒｅｓｅａｒｖｅ）と改正カウント域（ＣｈａｎｇｅＣｏｕｎｔ）とを追加する必要があり、前記例に対応するメッセージ構造全体は以下のようである。
【００７８】
第１の例は、ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２を支持し、オプショナル項なし、ＢＳＩＤとＰａｇｉｎｇＧｒｏｕｐＩＤには更新が必要である場合、エアー伝送の完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００７９】
【表１５】
2010524411.tif 000018
【００８０】
第２の例は、ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２を支持するとともに、ＦＢＳＳオプショナル項を支持し、ＢＳＩＤとＰａｇｉｎｇＧｒｏｕｐＩＤ及びＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲという情報ユニットの値には更新が必要である。この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００８１】
【表１６】
2010524411.tif 000019
【００８２】
第３の例は、２セットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅで、第２の例と同じ意味を実現し、この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００８３】
【表１７】
2010524411.tif 000020
【００８４】
第４の例は、ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２を支持するとともに、ＨＡＲＱオプショナル項を支持し、全てはデフォルト値を利用し、この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００８５】
【表１８】
2010524411.tif 000021
【００８６】
本実施例に定義されたメッセージ構造方法によれば、極端の状況において、占用したバイト数は最小で６バイトであり、最大で占用したバイト数、即ち全ての情報ユニットがデフォルト値とは一致していない場合、占用したバイト数は４１バイトであることがわかる。一方、同じ情報内容では、現在の標準に定義されたＭＡＣメッセージ構造方法によると、７２バイトを占用することが必要である。同じ情報内容を伝送する状況では、本発明の提供したＭＡＣ方法が占用した無線リソースは、現在の標準に定義された方法の８％〜５７％の程度である。
【００８７】
前記基地局の受信した本基地局属性情報は、ネットワーク側から獲得してもよく、ネット管理システムにより配置してもよい。送信の時に、プロトコルに規定された所定時点に従い送信を行う。
【００８８】
ステップ３０：受信デバイスは、受信した後に、予め定義されたメッセージにおける各域の値の意味に基づき、分析と処理を行う。
【００８９】
当該受信デバイスは、移動端末或いは無線中継局であってもよい。本実施例では、基地局が１つのＰｒｏｆｉｌｅのみを支持可能と仮定し、受信デバイスの具体的な処理フローは以下のステップを含む。
【００９０】
ステップ３０１：受信デバイスは、当該ＭＡＣ  ＤＣＤメッセージを受信した後、ＣｈａｎｇｅＣｏｕｎｔ域をまず検知し、前回の記録と異なる場合、当該ＤＣＤ/ＵＣＤメッセージの処理を起動し、次のステップを行う。そうでなければ、処理せず、終了する。
ステップ３０２：まず、Ｐｒｏｆｉｌｅ域の値を検知し、それに対応する１セットの物理チャンネル基本属性集合を支持するかどうかを判断し、支持する場合にステップ３０３を行い、支持しない場合にステップ３０６を行う。
【００９１】
ステップ３０３：Ｏｐｔｉｏｎ域を検知し、Ｏｐｔｉｏｎ域の値を獲得する。当該値に対応する１セットのオプショナル属性パラメーター組合を支持する場合に記録し、そうでなければ無視する。
【００９２】
ステップ３０４：Ｌｅｎｇｔｈ域の値に基づき、後ろにはＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅ域が存在するかどうかを判断し、存在する場合に次のステップを行い、存在しない場合にステップ３０６を行う。
【００９３】
ステップ３０５：受信デバイスは、ＰａｒａｍｅｔｅｒＣｌａｓｓ域の検知を続けて、事前の定義に従い、相応なＶａｌｕｅ域の値を獲得する。ＰａｒａｍｅｔｅｒＣｌａｓｓ域の定義を識別することができない場合、直接に廃棄する。
【００９４】
ここで、複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの存在する可能性がある。このような構造方式によれば、１セットの処理を終了した後、受信デバイスは、ステップ３０４に戻り、Ｌｅｎｇｔｈ域の値に基づき、処理の必要のある次のセットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅが存在するかどうかを判断することができる。
ステップ３０６：受信デバイスは、有効のＰｒｏｆｉｌｅ属性情報を既に獲得したかどうかを検知し、ある場合に次のアクセスを続け、ない場合に、現在のネットワークから退出し、新たなネットワークを再捜索する。
【００９５】
受信デバイスは、ＰｒｏｆｉｌｅとＯｐｔｉｏｎ域の値を獲得した後、１セットの対応なデフォルト属性値を既に有しており、獲得されたＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅ域の値は、この基礎上での更新に過ぎない。これは、ＰａｒａｍｅｔｅｒＣｌａｓｓ域が存在していない場合に、デフォルト値を利用することを示すことである。
基地局の物理層属性には変更がある場合、ネットワーク側は、基地局に通知して、変更された情報ユニット内容を基地局に送信すべきである。基地局は、受信した後に、自身の物理層属性を更新し、新たな内容に基づき、完全の物理層属性メッセージを構造し、構造方法は前述のようである。構造を完成した後に、所定のタイムスロットで、このメッセージを受信デバイスに送信する。受信デバイスは、前記方法に従い、受信と分析と処理とを行って、物理層属性記録を更新する。
【００９６】
第２の実施例
本実施例では、１つの基地局は、複数のセットの物理チャンネルの属性を支持することができ、即ち多種のＰｒｏｆｉｌｅを支持することができ、複数のセットのＰｒｏｆｉｌｅ＋Ｌｅｎｇｔｈ＋Ｏｐｔｉｏｎ＋ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅ域で示すことができる。一方、受信デバイスは、あるセットの物理チャンネルの属性を支持しない場合、無視することを選び、次の種類のＰｒｏｆｉｌｅに関する域に対する分析と処理を続けることができる。
【００９７】
基地局は、配置情報に基づき、複数セットのＰｒｏｆｉｌｅを同時に支持する場合、チャンネル説明メッセージにおける物理層チャンネル属性情報毎のそれぞれは、第１の実施例に記載された方法で構造することができる。
【００９８】
前記第１の実施例における例についてさらに説明し、多種例えば２種のＰｒｏｆｉｌｅを支持する場合、例えば１セット目Ｐｒｏｆｉｌｅ＝０ｘ０１は、構造方法が実施例１の記載と同じである。次いで、同じ方法で、Ｐｒｏｆｉｌｅ＝０ｘ０４の部分（オプショナルパラメーターなし、且つパラメーターのそれぞれはデフォルト値である）を構造して、相応な長さフィールドを書き込む。この後、これらを１つのＤＣＤメッセージとして、エアーインターフェースにより、受信デバイスに伝送する。この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法に従い、以下のようであってもよい。
【００９９】
【表１９】
2010524411.tif 000022
【０１００】
現在の標準において、ＭＡＣメッセージの構造は無線リソースを大量に占用するため、２種のＰｒｏｆｉｌｅを同時に支持することは基本的に不可能である。本発明に提供されたこのようなＭＡＣメッセージ構造方法は、基地局の能力をさらに拡張すること及び基地局の機能をさらに向上させることを可能とする。
【０１０１】
基地局が複数のＰｒｏｆｉｌｅを指示する可能のため、受信デバイスの処理は少し異なり、以下のステップ３０１’〜３０７’を含む。
【０１０２】
ここで、ステップ３０１’〜３０５’は、第１の実施例におけるステップ３０１〜３０５と同じであり、ステップ３０６のジャンプ（proceeding to）のみは、ステップ３０６’にジャンプして、まず、メッセージには他のＰｒｏｆｉｌｅが存在するかどうかを判断する。ステップ３０６’とステップ３０７’は以下のようである。
ステップ３０６’：受信デバイスは、後ろには他のＰｒｏｆｉｌｅが存在するかどうかを判断し、Ｐｒｏｆｉｌｅがさらに存在する場合、ステップ３０１に戻り、新たなＰｒｏｆｉｌｅ属性の獲得を起動し、後ろにはＰｒｏｆｉｌｅ域が存在しない場合、次のステップを行う。
【０１０３】
ＩＥＥＥ８０２．１６の定義によると、ＤＣＤは、ＤＬＭＡＰ（ダウンリンク割当マッピングテーブル）に伝送されるものである。従って、ＤＬＭＡＰによるＤＣＤメッセージ総長さの定義により、Ｌｅｎｇｔｈ域の値を合わせ、受信デバイスは、後ろには他のＰｒｏｆｉｌｅが存在するかどうかを判断することができる。同様に、ＵＣＤは、ＵＬＭＡＰに伝送されるものであり、ＵＬＭＡＰ（アップリンク割当マッピングテーブル）によるＵＣＤメッセージ総長さの定義により、後ろには他のＰｒｏｆｉｌｅが存在するかどうかを判断することができる。
【０１０４】
ステップ３０７’： 受信デバイスは、有効のＰｒｏｆｉｌｅ属性情報を既に獲得したかどうかを検知し、ある場合に次のアクセスを続け、ない場合に、現在のネットワークから退出し、新たなネットワークを再捜索する。
【０１０５】
第３の実施例
本実施例は、ＭＡＣ  ＵＣＤ（アップリンクチャンネル説明）メッセージの構造と伝送と分析について説明する。ここで、物理層チャンネル属性情報の構造原則は、第１の実施例と同じである。
【０１０６】
ステップ１：ＷｉＭＡＸ基地局は、本基地局のアップリンクチャンネル属性情報を獲得し、物理層チャンネル属性情報の構造規則に従い、当該情報を示すための各域の値を確定する。
【０１０７】
ＵＣＤメッセージ構成は、ＩＥＥＥ８０２．１６ｅに従い、以下のように定義される。
【０１０８】
【表２０】
2010524411.tif 000023
【０１０９】
ここで、ＴＬＶ  Ｅｎｃｏｄｅｄ  ｉｎｆｏｒｍａｔｉｏｎ  ｆｏｒ  ｔｈｅ  ｏｖｅｒａｌｌ  ｃｈａｎｎｅｌの定義は以下のようである。
【０１１０】
【表２１】
2010524411.tif 000024
【０１１１】
【表２２】
2010524411.tif 000025
【０１１２】
【表２３】
2010524411.tif 000026
【０１１３】
【表２４】
2010524411.tif 000027
【０１１４】
同様に、ＷｉＭＡＸ  ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２の要求に応じて、ＵＣＤメッセージに対する要求の概要は、以下のテーブルを参照することができる。これは、Ｐｒｏｆｉｌｅ＝０ｘ０１で定義されることが可能な１セットのＰｒｏｆｉｌｅであり、Ｓｔａｔｕｓ域における‘ｍ’は、必ず支持しなければならないを示す。
【０１１５】
【表２５】
2010524411.tif 000028
【０１１６】
【表２６】
2010524411.tif 000029
【０１１７】
【表２７】
2010524411.tif 000030
【０１１８】
【表２８】
2010524411.tif 000031
【０１１９】
基地局の取得したアップリンクチャンネル属性情報にはオプショナル項の支持が存在しない場合、Ｏｐｔｉｏｎ域を０ｘ００に設置する。オプショナル項の支持、例えばＢｅａｍＦｏｒｍｉｎｇが存在する場合、ＩＥＥＥ８０２．１６ｅの定義に従い、ＵＣＤメッセージ定義におけるＮｏｒｍａｌｉｚｅｄ  Ｃ／Ｎ  ｆｏｒ  Ｃｈａｎｎｅｌ  Ｓｏｕｎｄｉｎｇ情報ユニットを支持する必要がある。予め、このオプショナル項のＯｐｔｉｏｎ値をＯｐｔｉｏｎ＝０ｘ０１に設置することができる。基地局のアップリンク物理チャンネルの支持できるより多いＯｐｔｉｏｎエントリが存在する場合、予め定義されたより多いＯｐｔｉｏｎ値により目的を達成することができる。
【０１２０】
Ｐｒｏｆｉｌｅ（０ｘ０１）とＯｐｔｉｏｎ（０ｘ０１）に基づき、基地局はさらに、獲得されたアップリンクチャンネル属性情報に従い、デフォルト値を更新する必要があるかどうかを判断する。必要な場合、予め定義されたＰａｒａｍｅｔｅｒＣｌａｓｓの置値（set value）に従い、例えば、基地局は情報ユニットＩｎｉｔｉａｌ  ｒａｎｇｉｎｇ  ｃｏｄｅｓの値とデフォルト値が異なることを検知し、対応なＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ９６の場合、ＰａｒａｍｅｔｅｒＣｌａｓｓ域を０ｘ９６に設置し、次の１つのバイトは実際に利用されたＩｎｉｔｉａｌ  ｒａｎｇｉｎｇ  ｃｏｄｅｓの値、例えば０ｘ２３である。
【０１２１】
ステップ２：基地局は、獲得された各域の値に基づき、ＭＡＣ  ＵＣＤメッセージにおける物理層チャンネル属性情報部分を構造し、メッセージ全体の構造をさらに完成してから、受信デバイスに送信する。
【０１２２】
本実施例では、エアーで伝送されることになるＵＣＤメッセージコードフォーマットは以下のようである。
【０１２３】
【表２９】
2010524411.tif 000032
【０１２４】
前記実施例に説明された構造方式に類似し、より多いＰｒｏｆｉｌｅが存在する場合、Ｐｒｏｆｉｌｅ＋Ｌｅｎｇｔｈ＋Ｏｐｔｉｏｎ＋ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの方式で新たなＰｒｏｆｉｌｅとＯｐｔｉｏｎに対する定義の増加を続けることができる。ここで、ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅは、存在しなくてもよく（全てはデフォルト値を利用することを示す）、１セットであってもよく、更新された情報ユニット内容を運ぶための複数のセットであってもよい。
【０１２５】
ステップ３：受信デバイスは、受信した後に、予め定義されたＭＡＣ  ＵＣＤメッセージにおける各域の値の意味に基づき、分析と処理を行う。
【０１２６】
ここで、ＵＣＤメッセージに対する分析と処理は、第１と第２実施例におけるＤＣＤメッセージに対する分析と処理のフローと同じであり、域における値の示す意味が異なるだけであり、説明を省略する。
【０１２７】
前記機能を実現するために、既存のＩＥＥＥ８０２．１６の基地局においてエンコードモジュールを増加し、受信デバイスにおいてデコードモジュールを増加し、このようなメッセージの構造と分析を実現する。
【０１２８】
中継局が存在する場合、中継局の受信の時に同じ方法で分析を行うことに拡張することができる。中継局の送信した同じ種類のメッセージについても、同じ方法で構造し、受信デバイスに送信することができる。即ち、前記各実施例における送信デバイスとしての基地局に、中継局で代わって同じ機能を実現することができる。
【０１２９】
本発明に係る前記実施例に説明された方法によれば、エアーでこのようなメッセージを伝送する必要がある場合、エアーリソースの占用を大幅に低減させ、基地局の柔軟性を向上させ、端末と基地局の処理を簡潔にさせ、システム全体の機能を向上させる。
【０１３０】
以上説明したのは本発明の模式実施例のみであり、これは幾つかの変形があることが明らかである。このような変形は、本発明の模式実施例の主旨と範囲を逸脱しないと認定され、当業者にとっての全ての明らかな変形は、本発明における請求の範囲に属すべきである。
【０１３１】
例えば、他の１つの実施例では、前記物理層のチャンネル説明メッセージには、前記送信デバイスの支持する、実際値とデフォルト値が異なる属性パラメーター毎及びその実際値は、当該属性のタイプと値で示され、これらの属性タイプと値を示す域の前に、これらの属性タイプと値を示す域の長さを指示するための１つの長さ域を追加することができる。オプショナル属性に対しても、オプショナル属性毎のタイプをメッセージに書き込んて、前に長さ域をさらに追加することができる。
【０１３２】
また、Ｌｅｎｇｔｈ域の位置は、Ｏｐｔｉｏｎ域の後ろに位置してもよく、ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅ域の長さの指示に用いられる。或いは、終了子の方式で各域の終了位置を標記する方式もある。
【０１３３】
また、前記実施例におけるＰｒｏｆｉｌｅとＯｐｔｉｏｎは、それぞれに基本属性とオプショナル属性に対応したが、他の実施例では、この２つを混在させて番号を付けてもよく、即ち、基本属性とオプショナル属性の可能な組合毎を、１つの値で示す。即ち、Ｐｒｏｆｉｌｅ域とＯｐｔｉｏｎ域を１つの域に併合し、送信デバイスと受信デバイスは相応なエンコードとデコードを完成することができればよい。
【産業上の利用可能性】
【０１３４】
前述のように、本発明は、斬新なＭＡＣ層メッセージの構造方法、及び基地局と端末がこのようなメッセージ構成を構造及び分析するフローと方法を提供し、ＭＡＣ層メッセージの伝送をより適切に且つ効率に行い、無線リソース利用率を大幅で低減させる。従来の技術に比較すると、同じ情報内容を伝送する場合、本発明の提供したＭＡＣ方法による無線リソースの占用は、現在の標準に定義された方法の８％〜５７％の程度である。本発明に係る方法によれば、このようなメッセージをエアーで伝送する必要がある場合、エアーリソースの占用を大幅で低減させ、基地局の柔軟性を向上させ、端末と基地局の処理を簡潔にさせ、システム全体の機能を向上させる。
【図１】
2010524411.tif 000033
【手続補正書】
【提出日】平成21年10月15日(2009.10.15)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムのエアーリンクの伝送効率を向上させる方法に関し、特に、物理層のエアーインターフェースブロードキャスト情報の伝送効率の向上方法に関する。
【背景技術】
【０００２】
現在、多種の無線通信システム、例えばＣＤＭＡ２０００、ＷＣＤＭＡ、ＷｉＭＡＸ、Ｗｉ−Ｆｉ等が存在する。これらの無線通信システムにとって、エアーインターフェースの伝送効率をいかに向上させるという共通の問題がある。従って、物理層（ＭＡＣ）、層２（例えば、ＬＴＥのＭＡＣ、ＵＭＢのＭＡＣ、ＷｉＭＡＸシステムのＭＡＣ、Ｗｉ−ＦｉのＭＡＣ層）のいずれにおいても、制限されたスペクトル帯域幅と制限された無線リソースに、より高い伝送効率をいかに取得することが検討されている。
【０００３】
本願では、主に検討されたのは、層２のメッセージフォーマットに対する設計である。
ＩＥＥＥ８０２．１６ｅ−２００５を例として、現在、このプロトコルにおいて、ＯＦＤＭＡを支持するＤＣＤ（ダウンリンクチャンネル説明）メッセージ構成は以下のようである。
【０００４】
【表１】
2010524411.tif 000034
【０００５】
ここで、ＴＬＶ  Ｅｎｃｏｄｅｄ  ｉｎｆｏｒｍａｔｉｏｎ  ｆｏｒ  ｔｈｅ  ｏｖｅｒａｌｌ  ｃｈａｎｎｅｌという領域の内容の定義は以下のようである。
【０００６】
【表２】
2010524411.tif 000035
【０００７】
【表３】
2010524411.tif 000036
【０００８】
【表４】
2010524411.tif 000037
【０００９】
【表５】
2010524411.tif 000038
【００１０】
【表６】
2010524411.tif 000039
【００１１】
このことから、以上の情報ユニット毎は、Ｔｙｐｅ（タイプ）→Ｌｅｎｇｔｈ（長さ）→Ｖａｌｕｅ（値）の形式で構造されたものである。即ち、１つの情報ユニットを運ぶために、まず、１つのバイトで情報ユニットタイプ（Ｔｙｐｅ）を説明しなければならない、そして１つのユニットの長さの説明（Ｌｅｎｇｔｈ）であり、次は本格の情報ユニット内容（Ｖａｌｕｅ）である。
【００１２】
当該メッセージは、周期的に、所轄セル内の全ての端末や無線中継局に対しブロードキャストされ、端末と無線中継局は、これにおける情報を受信して認識し、物理層属性記録を更新する。演算によれば、当該メッセージの長さは少なくとも７２バイトであることが知られる。これには、ある情報フィールドを複数含むことが可能であるため、実際利用の場合に、７２バイトよりも多いことになる。１６ｅの定義によると、当該メッセージはブロードキャスト送信であり、少なくとも１０秒毎に１回送信され、この７２バイトは、少なくとも１２個のタイムスロットを占用する必要がある。スロット毎は２つの符号、１つのサブチャンネル（２４個のデータサブキャリア波）を占用する必要があり、アップリンクとダウンリンクの比が１：１であることから計算すると、この７２個のバイトは、全部１０Ｍのバンド幅のうちの０．４１８５６Ｍバンド幅において伝送される必要があり、即ち、このメッセージは、送信される時間（５ｍｓ以内）に、少なくとも４．１９％の無線リソースを占用することになる。
【００１３】
これは、このうちの１つのＭＡＣブロードキャストメッセージに過ぎない。１６ｅのプロトコルによれば、ＵＣＤ、ＤＬＭＡＰ、ＵＬＭＡＰなどのメッセージもブロードキャスト送信である。このようなブロードキャストメッセージは、大量なエアーインターフェース無線リソースを消耗することが考えられる。
他の無線システムにおいても、このような伝送チャンネル物理層属性のブロードキャストメッセージが存在し、そして、このようなメッセージは、一般的に、周期的な送信が必要である。従って、このようなメッセージの占用するバイトを低減させることができれば、無線リソースの占用を大幅に低減させることができる。
【００１４】
また、無線リソースに対する大量な占用のため、基地局能力に対する拡張は基本的に不可能になってしまう。これは、能力の拡張は、能力情報を伝送するためのバイトがもっと必要であるからである。このようなメッセージの占用するバイトを低減されることができれば、同じリソース占用状況においても、より多い能力選択を提供し、ユーザに対しもっと個性のあるサービスを提供することができる。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本発明が解決しようとする技術課題は、無線通信システムにおける物理層属性伝送効率を向上させる方法を提供し、物理層のチャンネル属性メッセージの占用するリソースを低減させる。
【課題を解決するための手段】
【００１６】
前記の技術課題を解決するために、本発明は、無線通信システムにおける物理層属性伝送効率を向上させる方法を提供し、（ａ）１セット或いは複数のセットの物理層チャンネル基本属性を定義し、セット毎は１つの属性域（domain of attributes）の値即ちＰｒｏｆｉｌｅの値でそれぞれ示され、（ｂ）送信デバイスは、物理層のチャンネル説明メッセージを送信し、そのなか、Ｐｒｏｆｉｌｅの値で本デバイスの支持する物理層チャンネル基本属性を示し、（ｃ）受信デバイスは、前記チャンネル説明メッセージを受信した後、これにおけるＰｒｏｆｉｌｅの値に基づき、送信デバイスの支持する１セットの物理層チャンネル基本属性を取得するステップを含む。
【００１７】
さらに、前記方法では、前記送信デバイスは基地局或いは無線中継局であり、前記受信デバイスは移動端末或いは無線中継局であることを特徴としてさらに有してもよい。
さらに、前記方法では、ステップ（ａ）において、物理層チャンネルのオプショナル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのオプショナル域の値即ちＯｐｔｉｏｎの値で示され、ステップ（ｂ）において、前記チャンネル説明メッセージにおいて、前記送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーターを、Ｏｐｔｉｏｎの値で示し、ステップ（ｃ）において、受信デバイスは、Ｏｐｔｉｏｎの値に基づき、送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーター情報を取得することを特徴としてさらに有してもよい。
【００１８】
さらに、前記方法では、ステップ（ａ）において、物理層チャンネル属性パラメーターのデフォルト値をさらに定義し、ステップ（ｂ）において、物理層チャンネル属性パラメーターの実際値とデフォルト値とは一致である場合、前記送信デバイスは、前記チャンネル説明メッセージにおいて、チャンネル属性パラメーターの値を示すことはせず、ステップ（ｃ）において、受信デバイスは、前記メッセージにはチャンネル属性パラメーターの値が見つからない場合、チャンネル属性パラメーターの値がデフォルト値であると認定することを特徴としてさらに有してもよい。
【００１９】
さらに、前記方法では、ステップ（ｂ）において、前記物理層のチャンネル説明メッセージには、前記送信デバイスが支持する、実際値とデフォルト値が異なる属性パラメーター毎及びその実際値は、みんな当該属性のタイプと値で示され、これらの属性タイプと値を示する域の前に、これらの属性タイプと値が示される域の長さを指示するための長さ域を追加することを特徴としてさらに有してもよい。
【００２０】
さらに、前記方法では、ステップ（ａ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのパラメータークラス域の値即ちＰａｒａｍｅｔｅｒＣｌａｓｓの値で示され、ステップ（ｂ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターが存在する場合、前記送信デバイスは、前記チャンネル説明メッセージにおいて、これらの物理層チャンネル属性パラメーターをＰａｒａｍｅｔｅｒＣｌａｓｓの値で示し、当該ＰａｒａｍｅｔｅｒＣｌａｓｓの後に、これらの物理層チャンネル属性パラメーターの実際値を、所定の順に従い、値域即ちＶａｌｕｅに書き込み、ステップ（ｃ）において、受信デバイスは、前記ＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅの値に基づき、前記送信デバイスが支持する、実際値とデフォルト値が異なる物理層チャンネル属性パラメーター及びその実際値を獲得することを特徴としてさらに有してもよい。
【００２１】
さらに、前記方法では、ステップ（ａ）において、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに組合、即ち、２つのセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅ域を利用して、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに示すことを特徴としてさらに有してもよい。
【００２２】
さらに、前記方法では、ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターにおいて一部の実際値がデフォルト値と一致していない場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する、長さ域Ｌｅｎｇｔｈとの域を含むことを特徴としてさらに有してもよい。
【００２３】
さらに、前記方法では、ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターの実際値のいずれもデフォルト値と一致する場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する、長さ域Ｌｅｎｇｔｈとの域を含むことを特徴としてさらに有してもよい。
【００２４】
さらに、前記方法では、前記ステップ（ｃ）において、受信デバイスは、（ｃ１）受信デバイスは、属性域の値を検知し、それに対応する１セットの物理チャンネル基本属性を支持するかどうかを判断し、支持する場合にステップ（ｃ２）を行い、支持しない場合にステップ（ｃ６）を行い、（ｃ２）オプショナル項の値を検知し、当該値に対応する１セットのオプショナル属性パラメーター組合組合を支持する場合に記録し、そうでなければ無視し、（ｃ３）長さ域の値に基づき、後にパラメータークラス域と値域がさらに存在するかどうかを判断し、存在する場合に次のステップを行い、存在しない場合にステップ（ｃ５）を行い、（ｃ４）パラメータークラス域を検知して、事前の定義に従い、相応な値域の値を取得し、パラメータークラス域の定義を識別することができない場合に直接に廃棄し、（ｃ５）受信デバイスは、次のアクセスを続け、終了し、（ｃ６）受信デバイスは、現在のネットワークから退出し、新たなネットワークを再捜索するステップに従い、物理層チャンネル属性情報を分析することを特徴としてさらに有してもよい。
【００２５】
さらに、前記方法では、前記送信デバイスは、複数のセットの物理層チャンネル基本属性を支持する場合、前記チャンネル説明メッセージには、複数のセットの物理層チャンネル属性情報の構成を含み、受信デバイスは、物理層チャンネル属性情報を分析する時に、ステップ（ｃ６）において、まず、メッセージ長さ情報に基づき、後に他の１セットの物理層チャンネル属性情報が存在するかどうかを判断し、存在する場合に、同じ方式でこれに対し処理を行い、存在しない場合、現在のネットワークから退出することを特徴としてさらに有してもよい。
【００２６】
さらに、前記方法では、ステップ（ａ）において、前記物理層チャンネルの基本属性と物理層チャンネルのオプショナル属性は、同一のプロトコルバージョンで規定されたものであり、プロトコルバージョン或いは選択必須（mandatory）な項の内容が異なる場合、異なる1セットの物理層チャンネル基本属性として、異なるＰｒｏｆｉｌｅの値に対応した上で、これにおけるオプショナル属性パラメーター組合に基づき、異なるＯｐｔｉｏｎの値を定義することを特徴としてさらに有してもよい。
【００２７】
さらに、前記方法では、ステップ（ａ）において、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び２段階目ｗａｖｅ２の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０１に設置し、及び/或いは、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び３段階目ｗａｖｅ３の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０２に設置することを特徴としてさらに有してもよい。
【００２８】
さらに、前記方法では、ステップ（ｂ）における物理層のチャンネル説明メッセージとは、アップリンクチャンネル説明メッセージ及び/或いはダウンリンクチャンネル説明メッセージであることを特徴としてさらに有してもよい。
【００２９】
さらに、前記方法では、ステップ（ｂ）において、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラスＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含むことを特徴としてさらに有してもよい。
【００３０】
さらに、前記方法では、前記送信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、前記受信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、或いは各域の値に対応する属性を支持するかどうかの情報を記憶していることを特徴としてさらに有してもよい。
【００３１】
本発明は、チャンネル説明メッセージにおける物理層チャンネル属性情報の構成をさらに提供し、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする。
【００３２】
或いは、送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含む。
【００３３】
具体的に、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含む。
【００３４】
前述のように、本発明は、斬新なＭＡＣ層メッセージの構造方法、及び基地局と端末がこのようなメッセージ構成を構造及び分析するフローと方法を提供し、ＭＡＣ層メッセージの伝送をより適切に且つ効率に行い、無線リソース利用率を大幅で低減させる。従来の技術に比較すると、同じ情報内容を伝送する場合、本発明の提供したＭＡＣ方法による無線リソースの占用は、現在の標準に定義された方法の８％〜５７％の程度である。本発明に係る方法によれば、このようなメッセージをエアーで伝送する必要がある場合、エアーリソースの占用を大幅で低減させ、基地局の柔軟性を向上させ、端末と基地局の処理を簡潔にさせ、システム全体の機能を向上させる。
【図面の簡単な説明】
【００３５】
【図１】図１は本発明の実施例の方法のフローチャートである。
【発明を実施するための形態】
【００３６】
従来の技術の内容から、既存の物理層のチャンネル説明メッセージは、物理情報の毎種の属性に対し、タイプと長さと値とを含む情報ユニットの形式でそれぞれに説明することがわかる。このような方式は、各種の属性及びその値を任意に組み合うことができるため、いい柔軟性を有している。しかしながら、実際の基地局の支持する物理層チャンネル属性及びその値は、任意に組合されるものではない。
【００３７】
例えば、ＷｉＭＡＸ  Ｆｏｒｕｍは、オペレーターの要求に応じて、システム属性（Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅ）バージョン１．０．０、対応なプロトコル一致性テスト説明（ＰＩＣＳ）バージョン１．０．０、及び２段階目（ｗａｖｅ２）の要求する選択必須な内容が定義され、ここで、ＤＣＤメッセージに対する要求は、以下のテーブルのように選択的に示される。
【００３８】
【表７】
2010524411.tif 000040
【００３９】
【表８】
2010524411.tif 000041
【００４０】
【表９】
2010524411.tif 000042
【００４１】
【表１０】
2010524411.tif 000043
【００４２】
これは、1セットのＰｒｏｆｉｌｅの例であり、ここで、Ｓｔａｔｕｓ域における‘ｍ’は、支持しなければならないを示す。後は、必要に応じて、Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０に基づくｗａｖｅ３の要求を定義する可能性がある。
【００４３】
物理チャンネルが必ず支持しなければならないのような属性について、物理チャンネル基本属性という。このような約定された1セットのＰｒｏｆｉｌｅに対し、１つの唯一の標記（例えば番号）を約定することができ、基地局は、メッセージの特定域において、このＰｒｏｆｉｌｅの標記を送信し、端末は、基地局の支持する物理チャンネル基本属性をわかることができ、従来の技術では基本属性情報毎を１つずつ伝送することに比較すると、大量のリソースを節約することが明らかである。
【００４４】
物理チャンネルは、基本属性に加え、増強の属性を有してもよく、物理チャンネルオプショナル属性と呼ばれ、これらのオプショナル属性についても、端末に通知する必要がある。これらのオプショナル属性の数は相対的に少ないため、オプショナル属性選択した後に出現可能な各種の結果、即ち基地局の支持するオプショナル属性パラメーター（属性パラメーターは、相応な属性に利用されるパラメーターである）の各種の組合に対し、それぞれに１つの標記（例えば番号）を約定して、メッセージの特定域に書き込んで送信してもよく、端末は、当該標記に基づき、基地局の支持する物理チャンネルオプショナル属性をわかるすることができる。もちろん、オプショナル属性が少ない場合、これらのオプショナル属性パラメーターのタイプを、メッセージに１つずつ標記してもよいことは言うまでもない。
【００４５】
さらに、基地局の支持する物理チャンネル属性以外、各物理チャンネル属性パラメーターの値を示すことが必要な場合があり、物理チャンネルの属性（基本とオプショナルを含む）パラメーター毎に対し、デフォルト値を約定することができる。物理チャンネル属性パラメーターの実際値はデフォルト値ではない場合、メッセージの特定域に明らかに示す。そうでなければ、これらのパラメーターの実際値はデフォルト値と一致していると認定する。
【００４６】
以下、図面と具体的な実施形態を合わせて、本発明に係る内容について詳しく説明する。
（第１の実施例）
以上の分析に基づき、本発明の実施例のＭＡＣメッセージにおける物理層チャンネル属性情報の構造は以下のようである。
【００４７】
【表１１】
2010524411.tif 000044
【００４８】
ここで、Ｐｒｏｆｉｌｅ（属性域）、Ｌｅｎｇｔｈ（長さ域）、Ｏｐｔｉｏｎ（オプショナル項域）、ＰａｒａｍｅｔｅｒＣｌａｓｓ（パラメータークラス域）は、デフォルトが１バイトである。０ｘＦＦ（或いは他のある特定値）に設置した場合、次のバイトは本属性メッセージ域の拡張値であることを示し、そうでなければ、本域は1バイトのみである。
【００４９】
ここで、Ｐｒｏｆｉｌｅの値、即ちＰｒｏｆｉｌｅにおける値は、1セットの必ず支持しなければならない物理チャンネル基本属性に対応し、前文におけるシステム属性（Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅ）バージョン号に基づき定義してもよく、他の国際或いは国内の標準に基づいてもよい。拡張性を支持するために、Ｐｒｏｆｉｌｅの１バイト目は０ｘＦＦである場合、次のバイトはＰｒｏｆｉｌｅの拡張値であることを示し、そうでなければ、Ｐｒｏｆｉｌｅは1バイトのみであり、次のバイトはＬｅｎｇｔｈ域である。Ｐｒｏｆｉｌｅの値の意味は、予め定義される必要がある。
【００５０】
Ｌｅｎｇｔｈの値は、このＰｒｏｆｉｌｅの後ろに含まれる全ての内容の長さを示す。バイトを単位とする。拡張性を支持するために、Ｌｅｎｇｔｈの１バイト目は０ｘＦＦである場合、次のバイトはＬｅｎｇｔｈの拡張値であることを示し、そうでなければ、Ｌｅｎｇｔｈは1バイトのみであり、次のバイトはＯｐｔｉｏｎ域である。
【００５１】
Ｏｐｔｉｏｎの値は、増加された物理チャンネルオプショナル属性の1種の組合に対応する。Ｏｐｔｉｏｎ域の導入は、基地局の能力を柔軟的に拡張すると共に、基地局の機能を向上させることができる。新たな属性を増加していない場合、この域は、０ｘ００で直接に示すことができる。拡張性を支持するために、Ｏｐｔｉｏｎの１バイト目は０ｘＦＦである場合、次のバイトはＯｐｔｉｏｎの拡張値であることを示し、そうでなければ、Ｏｐｔｉｏｎ域は1バイトのみの長さであり、次のバイトはＰａｒａｍｅｔｅｒＣｌａｓｓ域である。Ｏｐｔｉｏｎの値の意味は、予め定義される必要がある。
【００５２】
ＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅとの２つの域は同時に出現するものであり、前記ＰｒｏｆｉｌｅとＯｐｔｉｏｎで示された属性集合には有効である。この２つの域は、当該属性集合においてどの属性パラメーターの値とデフォルト値が一致していないこと、及びその実際値の数を示す。これは、この２つの域はオプショナルであることを示し、全ての属性パラメーターの値とデフォルト値が一致している場合、この２つの域が必要ではない。ここで、ＰａｒａｍｅｔｅｒＣｌａｓｓとしては、標準における属性パラメータークラス値を直接に利用することができ、直後にこのタイプの属性パラメーターの実際値を付ける。複数の属性パラメーターの実際値とデフォルト値が一致していない場合、複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで示すことができる。他の１つの方式では、ＰａｒａｍｅｔｅｒＣｌａｓｓの値で、実際値とデフォルト値が一致していない複数の属性パラメーターの１種の組合を示し、Ｖａｌｕｅは、これらの実際値を示すために用いられる。もちろん、複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅを利用し、１セットは、選択必須属性における、実際値とデフォルト値が一致していない属性パラメーター及びその実際値を示すために用いられ、他の１セットは、オプショナル属性における、実際値とデフォルト値が一致していない属性パラメーター及びその実際値を示すために用いられ、或いは他のグループ化方法を利用してもよい。組合タイプを予め定義して、実際値を提供することにより、基地局属性を柔軟的に設置することができる。
本実施例では、この５つの域の間の関係は以下のようである。
【００５３】
【数１】
2010524411.tif 000045
【００５４】
つまり、セット毎のＰｒｏｆｉｌｅに加え、１セットのオプショナル属性組合をさらに含み、Ｏｐｔｉｏｎの値で示す（オプショナル属性が無い場合に０で示すことができる）ことが可能である。さらに、ＰｒｏｆｉｌｅとＯｐｔｉｏｎ域の範囲内に、１セット或いは複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで、実際値とデフォルト値が一致していない１セットの属性パラメーター及びその実際値を提供する。選択必須に係るパラメーターは前に位置し、オプショナルに係るパラメーターは後ろに位置する。指定されたＰｒｏｆｉｌｅとＯｐｔｉｏｎ域には、ＰａｒａｍｅｔｅｒＣｌａｓｓ毎は１種の属性パラメーター（Ｐａｒａｍｅｔｅｒ）組合のタイプに対応し、対応なＶａｌｕｅ域には、各パラメーターのバイト長さ及び各パラメーターの配列順位は固定である。
【００５５】
送信デバイス（例えば基地局、無線中継局）は、前記物理層のチャンネル属性情報構成における各域の値と相応属性の対応関係を記憶しており、受信デバイス（例えば端末、無線中継局）は、前記物理層のチャンネル属性情報構成における各域の値と相応属性の対応関係を記憶しており、或いは各域の値に対応する属性を支持するかどうかの情報を記憶している。
【００５６】
以下、送信デバイスと受信デバイスとが各状況において、いかにこの構成を利用して物理層チャンネル説明情報の構造と送信と分析とを行うかについて、具体的に説明する。
ＭＡＣ  ＤＣＤメッセージを例とし、他のメッセージも類似である。図１に示すように、当該方法は以下のステップを含む。
【００５７】
ステップ１０：ＷｉＭＡＸ基地局は、本基地局の物理層チャンネル属性情報を獲得し、前記規則に従い、当該情報を示すための各域の値を確定する。
【００５８】
１）Ｐｒｏｆｉｌｅ域の値
前文では、ＷｉＭＡＸ  Ｆｏｒｕｍはシステム属性（Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅ）バージョン１．０．０、対応なプロトコル一致性テスト説明（ＰＩＣＳ）バージョン１．０．０、及び２段階目（ｗａｖｅ２）の要求する選択必須な内容が定義されることは既に記載されている。このセットのＰｒｏｆｉｌｅの値を、Ｐｒｏｆｉｌｅ＝０ｘ０１と定義する。後は必要に応じて、Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０に基づくｗａｖｅ３の要求を定義する可能性があり、ここで、Ｐｒｏｆｉｌｅ＝０ｘ０２と定義することができる。次も類似である。
【００５９】
Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅのバージョンには変更が起こる場合、新たなＳｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン及び対応な異なる選択必須項、例えばＳｙｓｔｅｍＰｒｏｆｉｌｅバージョン１．０．１のｗａｖｅ１を、さらに、新たなＰｒｏｆｉｌｅ値：０ｘ０４と定義することができる。次も類似である。
【００６０】
前述のように、ＷｉＭＡＸの特性に対し、Ｐｒｏｆｉｌｅの定義原則は、ＳｙｓｔｅｍＰｒｏｆｉｌｅバージョンに関連し、選択必須項内容の変更に関連するものである。この２つのうちの１つには変化が起こる場合、新たなＰｒｏｆｉｌｅ値を定義する必要がある。即ち、対応な１セットの物理チャンネル基本属性が異なる場合、異なるＰｒｏｆｉｌｅ値を利用すべきである。
【００６１】
２）Ｏｐｔｉｏｎ域の値
Ｐｒｏｆｉｌｅ＝０ｘ０１を例として、ＳｙｓｔｅｍＰｒｏｆｉｌｅバージョンｖ１．０．０において、ＦＢＳＳ及びＨＡＲＱに対する支持はオプショナルである。基地局は、ネットワーク側から獲得された能力情報から、自身がＦＢＳＳという能力を備えることを認知すると、ＩＥＥＥ８０２．１６ｅの定義に従い、ＤＣＤメッセージに、Ｈ＿Ａｄｄ  ＴｈｒｅｓｈｏｌｄとＨ＿Ｄｅｌｅｔｅ  ＴｈｒｅｓｈｏｌｄとＡＳＲとの３つの情報フィールドを増加する必要がある。
【００６２】
Ｏｐｔｉｏｎ域により、このセットのオプショナル属性パラメーター組合に対応するＯｐｔｉｏｎ値はＯｐｔｉｏｎ＝０ｘ０１であることを確定することができ、本基地局はＦＢＳＳのみを支持することを示す。同様に、ＨＡＲＱのみを支持する場合、このセットのオプショナル属性パラメーター組合に対応するＯｐｔｉｏｎ値をＯｐｔｉｏｎ＝０ｘ０２と定義することができ、本基地局はＨＡＲＱを支持することを示す。２つのオプショナル属性とも支持する場合、０ｘ０３と定義する。基地局の獲得した能力情報においてオプショナル項の内容が存在しない即ちＦＢＳＳとＨＡＲＱを支持しない場合、基地局はＯｐｔｉｏｎ域を０ｘ００に設置することができ、いずれのオプショナル項も支持しないことを示す。新たなバージョンのＳｙｓｔｅｍＰｒｏｆｉｌｅに基づき、新たなオプショナル項はＤＣＤメッセージの支持が必要である場合、以上の原則に従い、新たなオプショナル属性パラメーター組合に対応するＯｐｔｉｏｎの値を定義することができる。
【００６３】
他の１つの実施様態では、オプショナル項の内容がない場合、この域を取り消し、前のＬｅｎｇｔｈフィールドを０ｘ００に設置してもよい。
【００６４】
３）ＰａｒａｍｅｔｅｒＣｌａｓｓと対応なＶａｌｕｅ域の値
つづいては、基地局が、前記ＰｒｏｆｉｌｅとＯｐｔｉｏｎ域の範囲内に、ＰａｒａｍｅｔｅｒＣｌａｓｓと対応なＶａｌｕｅの値をいかに構造することに関する。
以下、４つの例を挙げる。
【００６５】
第１の例は、Ｐｒｏｆｉｌｅ＝０ｘ０１、Ｏｐｔｉｏｎ＝０ｘ００を例とし、ＤＣＤメッセージにおけるＢＳＩＤ情報ユニットはＰｒｏｆｉｌｅ域に属し、そのデフォルト値は０ｘ０００００００００００１であり、本基地局の配置によると、実際値は０ｘ００３２００００００００であり、また、ＰａｇｉｎｇＧｒｏｕｐＩＤのデフォルト値は０ｘ０００１であり、配置によると、本基地局の対応するＰａｇｉｎｇＧｒｏｕｐＩＤ＝０ｘ０１０２である場合、１セットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで、これらの実際の値の提供に協力することが必要である。例えば、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ０Ｄにより、次のバイトから実際のＢＳＩＤ値とＰａｇｉｎｇＧｒｏｕｐＩＤ値を順に提供し、直後のＶａｌｕｅが全部８バイトを有することを示す。前の６バイトは実際のＢＳＩＤ値を示し、例えば０ｘ００３２００００００００であり、次の２バイトはＰａｇｉｎｇＧｒｏｕｐＩＤ値、０ｘ０１０２である。他の情報ユニットは全てデフォルト値を利用する。以下のテーブルに示すように、
【００６６】
【表１２】
2010524411.tif 000046
【００６７】
第２の例は、Ｐｒｏｆｉｌｅ＝０ｘ０１、Ｏｐｔｉｏｎ＝０ｘ０１を例とし、基地局は、配置から、選択必須項におけるＢＳＩＤ、ＰａｇｉｎｇＧｒｏｕｐＩＤとオプショナル項におけるＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲの３つの情報フィールドが全てデフォルト値とは一致していないことを認知する場合、１セットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで、これらの実際の値の提供に協力することも必要である。例えば、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ１２により、次のバイトから実際のＢＳＩＤとＰａｇｉｎｇＧｒｏｕｐＩＤとＨ＿Ａｄｄ  ＴｈｒｅｓｈｏｌｄとＨ＿Ｄｅｌｅｔｅ  ＴｈｒｅｓｈｏｌｄとＡＳＲとの値を順に提供し、直後のＶａｌｕｅが全部１１バイトを有することを示す。前の６バイトは実際のＢＳＩＤ値を示し、例えば０ｘ００１２００１２０００１である。７、８バイト目はＰａｇｉｎｇＧｒｏｕｐＩＤを示し、例えば０ｘ００５５であり、９、１０、１１バイト目は、Ｈ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲの３つの情報ユニットをそれぞれに示し、例えば０ｘ１０、０ｘ０９、０ｘ２３である。以下のテーブルに示すように、
【００６８】
【表１３】
2010524411.tif 000047
【００６９】
第３の例は、第２の例と同じ状況において、２セットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅで示してもよい。例えば、依然Ｐｒｏｆｉｌｅ＝０ｘ０１、Ｏｐｔｉｏｎ＝０ｘ０１を例として、基地局は、配置から、選択必須項におけるＢＳＩＤ、ＰａｇｉｎｇＧｒｏｕｐＩＤとオプショナル項におけるＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲの３つの情報フィールドが全てデフォルト値とは一致していないことを認知する場合、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ０Ｄ及び対応なＶａｌｕｅで実際のＢＳＩＤ、ＰａｇｉｎｇＧｒｏｕｐＩＤの値を定義するとともに、ＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ０Ｅ及び対応なＶａｌｕｅで実際のＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲを定義し、例えば０ｘ１０、０ｘ０９、０ｘ２３である。即ち、２セットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅで、実際に利用された情報ユニット値を説明する。以下のテーブルに示すようである。
【００７０】
【表１４】
2010524411.tif 000048
【００７１】
この場合、前の定義方式より占用したバイトが多いが、追加定義の情報ユニット組合に対し、よりよい柔軟性を備えている。
【００７２】
ＰａｒａｍｅｔｅｒＣｌａｓｓの組合定義も予め定義済みであり、送信デバイスと受信デバイスとも認識することができる必要があることは説明すべきである。ここで、異なる組合方式で同じ意味を示すことは、本発明に定義された方法によれば、組合と拡張を柔軟的に行えることを説明するためである。
【００７３】
第４の例は、基地局は、配置から、自身の現在の物理層属性パラメーターが全てデフォルト値を利用することを認知する場合、Ｐａｒａｍｅｔｅｒ＋Ｖａｌｕｅで更新を行う必要はない。
【００７４】
４）Ｌｅｎｇｔｈ域の値
最後、基地局は、長さ（Ｌｅｎｇｔｈ）域の実際値を算出し、当該長さは、ＯｐｔｉｏｎとＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの占用したバイト数と一致する。
【００７５】
ステップ２０：基地局は、取得した各域の値に基づき、ＭＡＣ  ＤＣＤメッセージにおける物理層チャンネル属性情報部分を構造し、メッセージ全体の構造をさらに完成してから受信デバイスに送信する。
【００７６】
メッセージにおける物理層チャンネル属性情報部分の構成は、Ｐｒｏｆｉｌｅ＋Ｌｅｎｇｔｈ＋Ｏｐｔｉｏｎ＋ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの方式で構造され、他の部分は、プロトコルの規定した方式で構造される。この例には、メッセージタイプ域（ＭｅｓｓａｇｅＴｙｐｅ）と保留フィールド域（Ｒｅｓｅａｒｖｅ）と改正カウント域（ＣｈａｎｇｅＣｏｕｎｔ）とを追加する必要があり、前記例に対応するメッセージ構造全体は以下のようである。
【００７７】
第１の例は、ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２を支持し、オプショナル項なし、ＢＳＩＤとＰａｇｉｎｇＧｒｏｕｐＩＤには更新が必要である場合、エアー伝送の完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００７８】
【表１５】
2010524411.tif 000049
【００７９】
第２の例は、ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２を支持するとともに、ＦＢＳＳオプショナル項を支持し、ＢＳＩＤとＰａｇｉｎｇＧｒｏｕｐＩＤ及びＨ＿Ａｄｄ  Ｔｈｒｅｓｈｏｌｄ、Ｈ＿Ｄｅｌｅｔｅ  Ｔｈｒｅｓｈｏｌｄ、ＡＳＲという情報ユニットの値には更新が必要である。この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００８０】
【表１６】
2010524411.tif 000050
【００８１】
第３の例は、２セットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅで、第２の例と同じ意味を実現し、この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００８２】
【表１７】
2010524411.tif 000051
【００８３】
第４の例は、ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２を支持するとともに、ＨＡＲＱオプショナル項を支持し、全てはデフォルト値を利用し、この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法によれば、以下のように、
【００８４】
【表１８】
2010524411.tif 000052
【００８５】
本実施例に定義されたメッセージ構造方法によれば、極端の状況において、占用したバイト数は最小で６バイトであり、最大で占用したバイト数、即ち全ての情報ユニットがデフォルト値とは一致していない場合、占用したバイト数は４１バイトであることがわかる。一方、同じ情報内容では、現在の標準に定義されたＭＡＣメッセージ構造方法によると、７２バイトを占用することが必要である。同じ情報内容を伝送する状況では、本発明の提供したＭＡＣ方法が占用した無線リソースは、現在の標準に定義された方法の８％〜５７％の程度である。
【００８６】
前記基地局の受信した本基地局属性情報は、ネットワーク側から獲得してもよく、ネット管理システムにより配置してもよい。送信の時に、プロトコルに規定された所定時点に従い送信を行う。
【００８７】
ステップ３０：受信デバイスは、受信した後に、予め定義されたメッセージにおける各域の値の意味に基づき、分析と処理を行う。
【００８８】
当該受信デバイスは、移動端末或いは無線中継局であってもよい。本実施例では、基地局が１つのＰｒｏｆｉｌｅのみを支持可能と仮定し、受信デバイスの具体的な処理フローは以下のステップを含む。
【００８９】
ステップ３０１：受信デバイスは、当該ＭＡＣ  ＤＣＤメッセージを受信した後、ＣｈａｎｇｅＣｏｕｎｔ域をまず検知し、前回の記録と異なる場合、当該ＤＣＤ/ＵＣＤメッセージの処理を起動し、次のステップを行う。そうでなければ、処理せず、終了する。
ステップ３０２：まず、Ｐｒｏｆｉｌｅ域の値を検知し、それに対応する１セットの物理チャンネル基本属性集合を支持するかどうかを判断し、支持する場合にステップ３０３を行い、支持しない場合にステップ３０６を行う。
【００９０】
ステップ３０３：Ｏｐｔｉｏｎ域を検知し、Ｏｐｔｉｏｎ域の値を獲得する。当該値に対応する１セットのオプショナル属性パラメーター組合を支持する場合に記録し、そうでなければ無視する。
【００９１】
ステップ３０４：Ｌｅｎｇｔｈ域の値に基づき、後ろにはＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅ域が存在するかどうかを判断し、存在する場合に次のステップを行い、存在しない場合にステップ３０６を行う。
【００９２】
ステップ３０５：受信デバイスは、ＰａｒａｍｅｔｅｒＣｌａｓｓ域の検知を続けて、事前の定義に従い、相応なＶａｌｕｅ域の値を獲得する。ＰａｒａｍｅｔｅｒＣｌａｓｓ域の定義を識別することができない場合、直接に廃棄する。
【００９３】
ここで、複数のセットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの存在する可能性がある。このような構造方式によれば、１セットの処理を終了した後、受信デバイスは、ステップ３０４に戻り、Ｌｅｎｇｔｈ域の値に基づき、処理の必要のある次のセットのＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅが存在するかどうかを判断することができる。
ステップ３０６：受信デバイスは、有効のＰｒｏｆｉｌｅ属性情報を既に獲得したかどうかを検知し、ある場合に次のアクセスを続け、ない場合に、現在のネットワークから退出し、新たなネットワークを再捜索する。
【００９４】
受信デバイスは、ＰｒｏｆｉｌｅとＯｐｔｉｏｎ域の値を獲得した後、１セットの対応なデフォルト属性値を既に有しており、獲得されたＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅ域の値は、この基礎上での更新に過ぎない。これは、ＰａｒａｍｅｔｅｒＣｌａｓｓ域が存在していない場合に、デフォルト値を利用することを示すことである。
基地局の物理層属性には変更がある場合、ネットワーク側は、基地局に通知して、変更された情報ユニット内容を基地局に送信すべきである。基地局は、受信した後に、自身の物理層属性を更新し、新たな内容に基づき、完全の物理層属性メッセージを構造し、構造方法は前述のようである。構造を完成した後に、所定のタイムスロットで、このメッセージを受信デバイスに送信する。受信デバイスは、前記方法に従い、受信と分析と処理とを行って、物理層属性記録を更新する。
【００９５】
第２の実施例
本実施例では、１つの基地局は、複数のセットの物理チャンネルの属性を支持することができ、即ち多種のＰｒｏｆｉｌｅを支持することができ、複数のセットのＰｒｏｆｉｌｅ＋Ｌｅｎｇｔｈ＋Ｏｐｔｉｏｎ＋ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅ域で示すことができる。一方、受信デバイスは、あるセットの物理チャンネルの属性を支持しない場合、無視することを選び、次の種類のＰｒｏｆｉｌｅに関する域に対する分析と処理を続けることができる。
【００９６】
基地局は、配置情報に基づき、複数セットのＰｒｏｆｉｌｅを同時に支持する場合、チャンネル説明メッセージにおける物理層チャンネル属性情報毎のそれぞれは、第１の実施例に記載された方法で構造することができる。
【００９７】
前記第１の実施例における例についてさらに説明し、多種例えば２種のＰｒｏｆｉｌｅを支持する場合、例えば１セット目Ｐｒｏｆｉｌｅ＝０ｘ０１は、構造方法が実施例１の記載と同じである。次いで、同じ方法で、Ｐｒｏｆｉｌｅ＝０ｘ０４の部分（オプショナルパラメーターなし、且つパラメーターのそれぞれはデフォルト値である）を構造して、相応な長さフィールドを書き込む。この後、これらを１つのＤＣＤメッセージとして、エアーインターフェースにより、受信デバイスに伝送する。この場合、完全のＤＣＤメッセージコードは、本発明に定義された方法に従い、以下のようであってもよい。
【００９８】
【表１９】
2010524411.tif 000053
【００９９】
現在の標準において、ＭＡＣメッセージの構造は無線リソースを大量に占用するため、２種のＰｒｏｆｉｌｅを同時に支持することは基本的に不可能である。本発明に提供されたこのようなＭＡＣメッセージ構造方法は、基地局の能力をさらに拡張すること及び基地局の機能をさらに向上させることを可能とする。
【０１００】
基地局が複数のＰｒｏｆｉｌｅを指示する可能のため、受信デバイスの処理は少し異なり、以下のステップ３０１’〜３０７’を含む。
【０１０１】
ここで、ステップ３０１’〜３０５’は、第１の実施例におけるステップ３０１〜３０５と同じであり、ステップ３０６のジャンプ（proceeding to）のみは、ステップ３０６’にジャンプして、まず、メッセージには他のＰｒｏｆｉｌｅが存在するかどうかを判断する。ステップ３０６’とステップ３０７’は以下のようである。
ステップ３０６’：受信デバイスは、後ろには他のＰｒｏｆｉｌｅが存在するかどうかを判断し、Ｐｒｏｆｉｌｅがさらに存在する場合、ステップ３０１に戻り、新たなＰｒｏｆｉｌｅ属性の獲得を起動し、後ろにはＰｒｏｆｉｌｅ域が存在しない場合、次のステップを行う。
【０１０２】
ＩＥＥＥ８０２．１６の定義によると、ＤＣＤは、ＤＬＭＡＰ（ダウンリンク割当マッピングテーブル）に伝送されるものである。従って、ＤＬＭＡＰによるＤＣＤメッセージ総長さの定義により、Ｌｅｎｇｔｈ域の値を合わせ、受信デバイスは、後ろには他のＰｒｏｆｉｌｅが存在するかどうかを判断することができる。同様に、ＵＣＤは、ＵＬＭＡＰに伝送されるものであり、ＵＬＭＡＰ（アップリンク割当マッピングテーブル）によるＵＣＤメッセージ総長さの定義により、後ろには他のＰｒｏｆｉｌｅが存在するかどうかを判断することができる。
【０１０３】
ステップ３０７’： 受信デバイスは、有効のＰｒｏｆｉｌｅ属性情報を既に獲得したかどうかを検知し、ある場合に次のアクセスを続け、ない場合に、現在のネットワークから退出し、新たなネットワークを再捜索する。
【０１０４】
第３の実施例
本実施例は、ＭＡＣ  ＵＣＤ（アップリンクチャンネル説明）メッセージの構造と伝送と分析について説明する。ここで、物理層チャンネル属性情報の構造原則は、第１の実施例と同じである。
【０１０５】
ステップ１：ＷｉＭＡＸ基地局は、本基地局のアップリンクチャンネル属性情報を獲得し、物理層チャンネル属性情報の構造規則に従い、当該情報を示すための各域の値を確定する。
【０１０６】
ＵＣＤメッセージ構成は、ＩＥＥＥ８０２．１６ｅに従い、以下のように定義される。
【０１０７】
【表２０】
2010524411.tif 000054
【０１０８】
ここで、ＴＬＶ  Ｅｎｃｏｄｅｄ  ｉｎｆｏｒｍａｔｉｏｎ  ｆｏｒ  ｔｈｅ  ｏｖｅｒａｌｌ  ｃｈａｎｎｅｌの定義は以下のようである。
【０１０９】
【表２１】
2010524411.tif 000055
【０１１０】
【表２２】
2010524411.tif 000056
【０１１１】
【表２３】
2010524411.tif 000057
【０１１２】
【表２４】
2010524411.tif 000058
【０１１３】
同様に、ＷｉＭＡＸ  ＳｙｓｔｅｍＰｒｏｆｉｌｅ１．０．０  ｗａｖｅ２の要求に応じて、ＵＣＤメッセージに対する要求の概要は、以下のテーブルを参照することができる。これは、Ｐｒｏｆｉｌｅ＝０ｘ０１で定義されることが可能な１セットのＰｒｏｆｉｌｅであり、Ｓｔａｔｕｓ域における‘ｍ’は、必ず支持しなければならないを示す。
【０１１４】
【表２５】
2010524411.tif 000059
【０１１５】
【表２６】
2010524411.tif 000060
【０１１６】
【表２７】
2010524411.tif 000061
【０１１７】
【表２８】
2010524411.tif 000062
【０１１８】
基地局の取得したアップリンクチャンネル属性情報にはオプショナル項の支持が存在しない場合、Ｏｐｔｉｏｎ域を０ｘ００に設置する。オプショナル項の支持、例えばＢｅａｍＦｏｒｍｉｎｇが存在する場合、ＩＥＥＥ８０２．１６ｅの定義に従い、ＵＣＤメッセージ定義におけるＮｏｒｍａｌｉｚｅｄ  Ｃ／Ｎ  ｆｏｒ  Ｃｈａｎｎｅｌ  Ｓｏｕｎｄｉｎｇ情報ユニットを支持する必要がある。予め、このオプショナル項のＯｐｔｉｏｎ値をＯｐｔｉｏｎ＝０ｘ０１に設置することができる。基地局のアップリンク物理チャンネルの支持できるより多いＯｐｔｉｏｎエントリが存在する場合、予め定義されたより多いＯｐｔｉｏｎ値により目的を達成することができる。
【０１１９】
Ｐｒｏｆｉｌｅ（０ｘ０１）とＯｐｔｉｏｎ（０ｘ０１）に基づき、基地局はさらに、獲得されたアップリンクチャンネル属性情報に従い、デフォルト値を更新する必要があるかどうかを判断する。必要な場合、予め定義されたＰａｒａｍｅｔｅｒＣｌａｓｓの置値（set value）に従い、例えば、基地局は情報ユニットＩｎｉｔｉａｌ  ｒａｎｇｉｎｇ  ｃｏｄｅｓの値とデフォルト値が異なることを検知し、対応なＰａｒａｍｅｔｅｒＣｌａｓｓ＝０ｘ９６の場合、ＰａｒａｍｅｔｅｒＣｌａｓｓ域を０ｘ９６に設置し、次の１つのバイトは実際に利用されたＩｎｉｔｉａｌ  ｒａｎｇｉｎｇ  ｃｏｄｅｓの値、例えば０ｘ２３である。
【０１２０】
ステップ２：基地局は、獲得された各域の値に基づき、ＭＡＣ  ＵＣＤメッセージにおける物理層チャンネル属性情報部分を構造し、メッセージ全体の構造をさらに完成してから、受信デバイスに送信する。
【０１２１】
本実施例では、エアーで伝送されることになるＵＣＤメッセージコードフォーマットは以下のようである。
【０１２２】
【表２９】
2010524411.tif 000063
【０１２３】
前記実施例に説明された構造方式に類似し、より多いＰｒｏｆｉｌｅが存在する場合、Ｐｒｏｆｉｌｅ＋Ｌｅｎｇｔｈ＋Ｏｐｔｉｏｎ＋ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅの方式で新たなＰｒｏｆｉｌｅとＯｐｔｉｏｎに対する定義の増加を続けることができる。ここで、ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅは、存在しなくてもよく（全てはデフォルト値を利用することを示す）、１セットであってもよく、更新された情報ユニット内容を運ぶための複数のセットであってもよい。
【０１２４】
ステップ３：受信デバイスは、受信した後に、予め定義されたＭＡＣ  ＵＣＤメッセージにおける各域の値の意味に基づき、分析と処理を行う。
【０１２５】
ここで、ＵＣＤメッセージに対する分析と処理は、第１と第２実施例におけるＤＣＤメッセージに対する分析と処理のフローと同じであり、域における値の示す意味が異なるだけであり、説明を省略する。
【０１２６】
前記機能を実現するために、既存のＩＥＥＥ８０２．１６の基地局においてエンコードモジュールを増加し、受信デバイスにおいてデコードモジュールを増加し、このようなメッセージの構造と分析を実現する。
【０１２７】
中継局が存在する場合、中継局の受信の時に同じ方法で分析を行うことに拡張することができる。中継局の送信した同じ種類のメッセージについても、同じ方法で構造し、受信デバイスに送信することができる。即ち、前記各実施例における送信デバイスとしての基地局に、中継局で代わって同じ機能を実現することができる。
【０１２８】
本発明に係る前記実施例に説明された方法によれば、エアーでこのようなメッセージを伝送する必要がある場合、エアーリソースの占用を大幅に低減させ、基地局の柔軟性を向上させ、端末と基地局の処理を簡潔にさせ、システム全体の機能を向上させる。
【０１２９】
以上説明したのは本発明の模式実施例のみであり、これは幾つかの変形があることが明らかである。このような変形は、本発明の模式実施例の主旨と範囲を逸脱しないと認定され、当業者にとっての全ての明らかな変形は、本発明における請求の範囲に属すべきである。
【０１３０】
例えば、他の１つの実施例では、前記物理層のチャンネル説明メッセージには、前記送信デバイスの支持する、実際値とデフォルト値が異なる属性パラメーター毎及びその実際値は、当該属性のタイプと値で示され、これらの属性タイプと値を示す域の前に、これらの属性タイプと値を示す域の長さを指示するための１つの長さ域を追加することができる。オプショナル属性に対しても、オプショナル属性毎のタイプをメッセージに書き込んて、前に長さ域をさらに追加することができる。
【０１３１】
また、Ｌｅｎｇｔｈ域の位置は、Ｏｐｔｉｏｎ域の後ろに位置してもよく、ＰａｒａｍｅｔｅｒＣｌａｓｓ＋Ｖａｌｕｅ域の長さの指示に用いられる。或いは、終了子の方式で各域の終了位置を標記する方式もある。
【０１３２】
また、前記実施例におけるＰｒｏｆｉｌｅとＯｐｔｉｏｎは、それぞれに基本属性とオプショナル属性に対応したが、他の実施例では、この２つを混在させて番号を付けてもよく、即ち、基本属性とオプショナル属性の可能な組合毎を、１つの値で示す。即ち、Ｐｒｏｆｉｌｅ域とＯｐｔｉｏｎ域を１つの域に併合し、送信デバイスと受信デバイスは相応なエンコードとデコードを完成することができればよい。
【産業上の利用可能性】
【０１３３】
前述のように、本発明は、斬新なＭＡＣ層メッセージの構造方法、及び基地局と端末がこのようなメッセージ構成を構造及び分析するフローと方法を提供し、ＭＡＣ層メッセージの伝送をより適切に且つ効率に行い、無線リソース利用率を大幅で低減させる。従来の技術に比較すると、同じ情報内容を伝送する場合、本発明の提供したＭＡＣ方法による無線リソースの占用は、現在の標準に定義された方法の８％〜５７％の程度である。本発明に係る方法によれば、このようなメッセージをエアーで伝送する必要がある場合、エアーリソースの占用を大幅で低減させ、基地局の柔軟性を向上させ、端末と基地局の処理を簡潔にさせ、システム全体の機能を向上させる。   
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線通信システムにおける物理層属性伝送効率を向上させる方法であって、
（ａ）１セット或いは複数のセットの物理層チャンネル基本属性を定義し、セット毎は１つの属性域の値即ちＰｒｏｆｉｌｅの値で示され、
（ｂ）送信デバイスは物理層のチャンネル説明メッセージを送信し、そのなか、Ｐｒｏｆｉｌｅの値で本デバイスの支持する物理層チャンネル基本属性を示し、
（ｃ）受信デバイスは、前記チャンネル説明メッセージを受信した後、これにおけるＰｒｏｆｉｌｅの値に基づき、送信デバイスの支持する１セットの物理層チャンネル基本属性を認知するステップを含む。
【請求項２】
前記送信デバイスは基地局或いは無線中継局であり、前記受信デバイスは移動端末或いは無線中継局であることを特徴とする請求項１に記載の方法。
【請求項３】
ステップ（ａ）において、物理層チャンネルのオプショナル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのオプショナル域の値即ちＯｐｔｉｏｎの値で示され、
ステップ（ｂ）において、前記チャンネル説明メッセージにおいて、前記送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーターを、Ｏｐｔｉｏｎの値で示し、
ステップ（ｃ）において、受信デバイスは、Ｏｐｔｉｏｎの値に基づき、送信デバイスの支持する物理層チャンネルのオプショナル属性パラメーター情報を認知することを特徴とする請求項１に記載の方法。
【請求項４】
ステップ（ａ）において、物理層チャンネル属性パラメーターのデフォルト値をさらに定義し、
ステップ（ｂ）において、物理層チャンネル属性パラメーターの実際値とデフォルト値とは一致である場合、前記送信デバイスは、前記チャンネル説明メッセージにおいて、チャンネル属性パラメーターの値を示すことはせず、
ステップ（ｃ）において、受信デバイスは、前記メッセージにはチャンネル属性パラメーターの値が見つからない場合、チャンネル属性パラメーターの値がデフォルト値であると認定することを特徴とする請求項１或いは３に記載の方法。
【請求項５】
ステップ（ｂ）において、前記物理層のチャンネル説明メッセージには、前記送信デバイスが支持する、実際値とデフォルト値が異なる属性パラメーター毎及びその実際値は、それぞれに、当該属性のタイプと値で示され、これらの属性タイプと値が示される域の前に、これらの属性タイプと値が示される域の長さを指示するための長さ域を追加することを特徴とする請求項４に記載の方法。
【請求項６】
ステップ（ａ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターの組合をさらに定義し、毎種の組合は、１つのパラメータークラス域の値即ちＰａｒａｍｅｔｅｒＣｌａｓｓの値で示され、
ステップ（ｂ）において、実際値とデフォルト値が異なる物理層チャンネル属性パラメーターが存在する場合、前記送信デバイスは、前記チャンネル説明メッセージにおいて、これらの物理層チャンネル属性パラメーターをＰａｒａｍｅｔｅｒＣｌａｓｓの値で示し、当該ＰａｒａｍｅｔｅｒＣｌａｓｓの後に、これらの物理層チャンネル属性パラメーターの実際値を、所定の順に従い、値域即ちＶａｌｕｅに書き込み、
ステップ（ｃ）において、受信デバイスは、前記ＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅの値に基づき、前記送信デバイスが支持する、実際値とデフォルト値が異なる物理層チャンネル属性パラメーター及びその実際値を獲得することを特徴とする請求項４に記載の方法。
【請求項７】
ステップ（ａ）において、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに組合、即ち、２つのセットのＰａｒａｍｅｔｅｒＣｌａｓｓとＶａｌｕｅ域を利用して、実際値とデフォルト値が異なる基本属性パラメーターとオプショナル属性パラメーターをそれぞれに示すことを特徴とする請求項６に記載の方法。
【請求項８】
ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターにおいて一部の実際値がデフォルト値と一致していない場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、
実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、
パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする請求項６に記載の方法。
【請求項９】
ステップ（ｂ）において、前記送信デバイスの支持する物理層チャンネル属性パラメーターの実際値のいずれもデフォルト値と一致する場合、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記ステップ（ｃ）において、受信デバイスは、
（ｃ１）受信デバイスは、属性域の値を検知し、それに対応する１セットの物理チャンネル基本属性を支持するかどうかを判断し、支持する場合にステップ（ｃ２）を行い、支持しない場合にステップ（ｃ６）を行い、
（ｃ２）オプショナル項域の値を検知し、当該値に対応する１セットのオプショナル属性パラメーター組合を支持する場合に記録し、そうでなければ無視し、
（ｃ３）長さ域の値に基づき、後にパラメータークラス域と値域がさらに存在するかどうかを判断し、存在する場合に次のステップを行い、存在しない場合にステップ（ｃ５）を行い、
（ｃ４）パラメータークラス域を検知して、事前の定義に従い、相応な値域の値を取得し、パラメータークラス域の定義を認識することができない場合に直接に廃棄し、
（ｃ５）受信デバイスは、次のアクセスを続けて、終了し、
（ｃ６）受信デバイスは、現在のネットワークから退出し、新たなネットワークを再捜索するステップに従い、物理層チャンネル属性情報を分析することを特徴とする請求項８或いは９に記載の方法。
【請求項１１】
前記送信デバイスは、複数のセットの物理層チャンネル基本属性を支持する場合、前記チャンネル説明メッセージには、複数のセットの物理層チャンネル属性情報の構成を含み、
受信デバイスは、物理層チャンネル属性情報を分析する時に、ステップ（ｃ６）において、まず、メッセージ長さ情報に基づき、後に他の１セットの物理層チャンネル属性情報が存在するかどうかを判断し、存在する場合に、同じ方式でこれに対し処理を行い、存在しない場合、現在のネットワークから退出することを特徴とする請求項１０に記載の方法。
【請求項１２】
ステップ（ａ）において、前記物理層チャンネルの基本属性と物理層チャンネルのオプショナル属性は、同一のプロトコルバージョンで規定されたものであり、プロトコルバージョン或いは選択必須な項の内容が異なる場合、異なる1セットの物理層チャンネル基本属性として、異なるＰｒｏｆｉｌｅの値に対応した上で、これにおけるオプショナル属性パラメーター組合に基づき、異なるＯｐｔｉｏｎの値を定義することを特徴とする請求項３に記載の方法。
【請求項１３】
ステップ（ａ）において、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び２段階目ｗａｖｅ２の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０１に設置し、
及び/或いは、システム属性Ｓｙｓｔｅｍ  Ｐｒｏｆｉｌｅバージョン１．０．０、対応なプロトコル一致性テスト説明ＰＩＣＳバージョン１．０．０、及び３段階目ｗａｖｅ３の要求する選択必須な内容に基づき、1セットの物理層チャンネル基本属性を限定し、これに対応するＰｒｏｆｉｌｅ値を０ｘ０２に設置することを特徴とする請求項１２に記載の方法。
【請求項１４】
ステップ（ｂ）における物理層のチャンネル説明メッセージとは、アップリンクチャンネル説明メッセージ及び/或いはダウンリンクチャンネル説明メッセージであることを特徴とする請求項１に記載の方法。
【請求項１５】
ステップ（ｂ）において、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、
或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含むことを特徴とする請求項６に記載の方法。
【請求項１６】
前記送信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、前記受信デバイスは、前記物理層のチャンネル属性情報構成における各域の値と相応な属性との対応関係を記憶しており、或いは各域の値に対応する属性を支持するかどうかの情報を記憶していることを特徴とする請求項１、３、６のいずれか１つに記載の方法。
【請求項１７】
チャンネル説明メッセージにおける物理層チャンネル属性情報の構成であって、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
送信デバイスの支持する、実際値とデフォルト値とが一致していないチャンネル属性パラメーターを示すためのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと、
実際値とデフォルト値とが一致していないチャンネル属性パラメーターの実際値を示すための値域Ｖａｌｕｅと、
パラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓの前に位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する、長さ域Ｌｅｎｇｔｈと、の域を含むことを特徴とする。
【請求項１８】
チャンネル説明メッセージにおける物理層チャンネル属性情報の構成であって、
送信デバイスの支持する物理層チャンネル基本属性を示すための属性域Ｐｒｏｆｉｌｅと、
送信デバイスの支持する物理層チャンネルオプショナル属性を示すためのオプショナル項域Ｏｐｔｉｏｎと、
ＰｒｏｆｉｌｅとＯｐｔｉｏｎとの間或いはＯｐｔｉｏｎの後ろに位置し、Ｌｅｎｇｔｈの値が当該域の後の他の物理層チャンネル属性情報域の長さの合わせと一致する長さ域Ｌｅｎｇｔｈとの域を含むことを特徴とする。
【請求項１９】
チャンネル説明メッセージにおける物理層チャンネル属性情報の構成であって、
１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含み、
或いは、前記チャンネル説明メッセージにおける物理層チャンネル属性情報の構成は、１つ或いは２つのバイトの属性域Ｐｒｏｆｉｌｅと、１つ或いは２つのバイトの長さ域Ｌｅｎｇｔｈと、１つ或いは２つのバイトのオプショナル項域Ｏｐｔｉｏｎとをこの順で含み、実際値とデフォルト値が異なる属性パラメーターが存在する場合、1セット或いは複数のセットの可変長さのパラメータークラス域ＰａｒａｍｅｔｅｒＣｌａｓｓと値域Ｖａｌｕｅをさらに含むことを特徴とする。
【国際調査報告】
2010524411.tif 000064
2010524411.tif 000065
2010524411.tif 000066
2010524411.tif 000067
2010524411.tif 000068
2010524411.tif 000069