(57)【要約】  無線通信ネットワークにおけるアップリンクスケジューリング要求情報の報告ストラテジが開示されている。なかでも、無線通信ネットワークにおいて、ユーザデバイスがアップリンクスケジューリング要求情報を基地局へ報告する方法が開示されており、その方法は、第一に、無線ベアラパケット内の、ユーザバッファに入っているサービスデータの合計量を計算し、第二に、無線ベアラパケットのトリガされた１つまたは複数のパケット相関情報を前記基地局へ報告する。それとは別に、無線通信ネットワークにおいて、ユーザデバイスが無線ベアラパケットの緊急状態を基地局へ報告する方法が開示され、その方法は、無線ベアラが緊急状態であるか、そうでないかを判断し、緊急状態を示す情報を伝送する。上述の２つの方法を併用すると、基地局は、効率のよい論理的スケジューリングを実現することができる。
2010502056.tif 000002
【特許請求の範囲】
【請求項１】
無線遠隔通信ネットワークにおいてアップリンクスケジューリングに関する要求情報を基地局へ報告するためのユーザ機器内の方法であって、
ａ．前記ユーザ機器のバッファ内の、同じ優先順位を有する１つまたは複数の無線ベアラを含む無線ベアラの各グループ内の全無線ベアラの全サービスデータ量を計算するステップと、
ｂ．無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報のみを前記基地局へ報告するステップと
を含む、方法。
【請求項２】
前記ステップｂが、
前記無線ベアラの各グループがトリガされたかを判断するステップと、
その中の無線ベアラの１つまたは複数のグループがトリガされた時、前記無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報を前記基地局へ送信するステップと
を含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記無線ベアラの各グループがトリガされたかを判断する前記ステップが、
前記ユーザ機器のバッファ内の無線ベアラの１つまたは複数のグループの全サービスデータ量が、対応する事前定義されたしきい値を超えた時、または前記しきい値より少なくなった時、前記無線ベアラの１つまたは複数のグループはトリガされたと判断するステップ
を含むことを特徴とする、請求項１または２に記載の方法。
【請求項４】
前記無線ベアラの各グループがトリガされたかを判断する前記ステップが、
前記無線ベアラの１つまたは複数のグループの事前定義された報告時間に達した時、前記無線ベアラの１つまたは複数のグループはトリガされたと判断するステップ
を含むことを特徴とする、請求項２または請求項３に記載の方法。
【請求項５】
前記事前定義された報告時間が定期的であることを特徴とする、請求項４に記載の方法。
【請求項６】
前記無線ベアラの各グループのグループ関連情報がメディアアクセス制御層上のデータフレームによって前記基地局へ送信されることを特徴とする、請求項１から５のいずれか一項に記載の方法。
【請求項７】
前記無線ベアラの各グループのグループ関連情報が新しい制御プロトコルデータユニットによって前記基地局へ送信されることを特徴とする、請求項１から５のいずれか一項に記載の方法。
【請求項８】
前記グループ関連情報が、前記無線ベアラのトリガされたグループの数、前記無線ベアラのトリガされたグループのそれぞれのグループインジケータ、および前記無線ベアラのトリガされたグループのそれぞれの全サービスデータ量を含むことを特徴とする、請求項１から７のいずれか一項に記載の方法。
【請求項９】
無線遠隔通信ネットワークにおいてアップリンクスケジューリングに関する要求情報を基地局へ報告するためのユーザ機器内の報告用デバイスであって、
前記ユーザ機器のバッファ内の、同じ優先順位を有する１つまたは複数の無線ベアラを含む無線ベアラの各グループ内の全無線ベアラの全サービスデータ量を計算するための計算手段と、
無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報のみを前記基地局へ報告するための被制御送信手段と
を有する、報告用デバイス。
【請求項１０】
前記被制御送信手段が、
前記無線ベアラの各グループがトリガされたかを判断するための判断手段と、
その中の無線ベアラの１つまたは複数のグループがトリガされた時、前記無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報を前記基地局へ送信するための送信手段と
を有することを特徴とする、請求項９に記載の報告用デバイス。
【請求項１１】
前記判断手段が、前記ユーザ機器のバッファ内の無線ベアラの１つまたは複数のグループの全サービスデータ量が、対応する事前定義されたしきい値を超えた時、または前記しきい値より少なくなった時、前記無線ベアラの１つまたは複数のグループはトリガされたと判断するためにさらに使用されることを特徴とする、請求項１０に記載の報告用デバイス。
【請求項１２】
前記判断手段が、前記無線ベアラの１つまたは複数のグループの事前定義された報告時間に達した時、前記無線ベアラの１つまたは複数のグループはトリガされたと判断するためにさらに使用されることを特徴とする、請求項１０に記載の報告用デバイス。
【請求項１３】
前記事前定義された報告時間が定期的であることを特徴とする、請求項１２に記載の報告用デバイス。
【請求項１４】
前記無線ベアラの各グループのグループ関連情報がメディアアクセス制御層上のデータフレームによって前記基地局へ送信されることを特徴とする、請求項９から１３のいずれか一項に記載の報告用デバイス。
【請求項１５】
前記無線ベアラの各グループのグループ関連情報が新しい制御プロトコルデータユニットによって前記基地局へ送信されることを特徴とする、請求項９から１３のいずれか一項に記載の報告用デバイス。
【請求項１６】
前記グループ関連情報が、前記無線ベアラのトリガされたグループの数、前記無線ベアラのトリガされたグループのそれぞれのグループインジケータ、および前記無線ベアラのトリガされたグループのそれぞれの全データ量を含むことを特徴とする、請求項９から１５のいずれか一項に記載の報告用デバイス。
【請求項１７】
無線遠隔通信ネットワークにおける基地局内の、ユーザ機器に無線リソースを割り振るための方法であって、
ｉ．無線ベアラの１つまたは複数のグループのグループ関連情報を前記ユーザ機器から受信するステップと、
ｉｉ．前記グループ関連情報に従って前記ユーザ機器内の無線ベアラの各グループに割り振られる無線リソースを判定するステップと、
を含む、方法。
【請求項１８】
前記グループ関連情報が、無線ベアラのトリガされたグループの数、前記無線ベアラのトリガされたグループのそれぞれのグループインジケータ、および前記無線ベアラのトリガされたグループのそれぞれの全データ量を含むことを特徴とする、請求項１７に記載の方法。
【請求項１９】
無線遠隔通信ネットワークにおける基地局内の、ユーザ機器に無線リソースを割り振るための無線リソース割り振り用デバイスであって、
無線ベアラの１つまたは複数のグループのグループ関連情報を前記ユーザ機器から受信するために使用される受信手段と、
前記グループ関連情報に従って前記ユーザ機器内の無線ベアラの各グループに割り振られる無線リソースを判定するために使用される判定手段と
を有する、無線リソース割り振り用デバイス。
【請求項２０】
前記グループ関連情報が、無線ベアラのトリガされたグループの数、前記無線ベアラのトリガされたグループのそれぞれのグループインジケータ、および前記無線ベアラのトリガされたグループのそれぞれの全データ量を含むことを特徴とする、請求項１９に記載の無線リソース割り振り用デバイス。
【請求項２１】
無線遠隔通信ネットワークにおけるユーザ機器内の、無線ベアラの緊急状態を基地局へ報告するための方法であって、
ａ．各無線ベアラが緊急状態であるかを判断するステップと、
ｂ．１つまたは複数の前記無線ベアラが緊急状態の場合に緊急表示情報を前記基地局へ送信するステップと
を含む、方法。
【請求項２２】
前記ステップａが、
前記ユーザ機器のバッファ内の前記各無線ベアラのサービスデータの滞留時間を計算するステップと、
前記各無線ベアラのサービスデータの滞留時間を、対応する事前定義された値と比較するステップと、
前記バッファ内の前記１つまたは複数の無線ベアラの事前定義されたサービスデータ量の滞留時間が、対応する事前定義された値を超えている場合、前記１つまたは複数の無線ベアラは緊急状態であると判定するステップと
を含むことを特徴とする、請求項２１に記載の方法。
【請求項２３】
前記ステップｂが、
前記緊急表示情報を制御シグナリングで伝送するステップ
をさらに含むことを特徴とする、請求項２１または２２に記載の方法。
【請求項２４】
前記緊急表示情報が、緊急状況および／または緊急レベルを示すための情報を含むことを特徴とする、請求項２１から２３のいずれか一項に記載の方法。
【請求項２５】
無線遠隔通信ネットワークにおけるユーザ機器内の、無線ベアラの緊急情報を基地局へ報告するためのデバイスであって、
各無線ベアラが緊急状態あるかを判断するための判断手段と、
１つまたは複数の前記無線ベアラが緊急状態にある場合、緊急表示情報を前記基地局へ送信するための送信手段と
を有する、デバイス。
【請求項２６】
前記判断手段が、
前記ユーザ機器のバッファ内の前記各無線ベアラのサービスデータの滞留時間を計算するための計算手段と、
前記各無線ベアラのサービスデータの滞留時間を、対応する事前定義された値と比較するための比較手段と、
前記１つまたは複数の無線ベアラの事前定義されたサービスデータ量の滞留時間が、対応する事前定義された値を超えている場合、前記１つまたは複数の無線ベアラは緊急状態であると判定するための判定手段と
をさらに有することを特徴とする、請求項２５に記載のデバイス。
【請求項２７】
前記送信手段が、前記緊急表示情報を制御シグナリングで伝送するためにさらに使用されることを特徴とする、請求項２５または２６に記載のデバイス。
【請求項２８】
前記緊急表示情報が、緊急状況および／または緊急レベルを示すための情報を含むことを特徴とする、請求項２５から２７のいずれか一項に記載のデバイス。
【請求項２９】
無線遠隔通信ネットワークにおける基地局内の、ユーザ機器のアップリンク伝送待ち時間およびデータパケット消失を低減するための無線リソーススケジューリング方法であって、
ｉ．緊急表示情報を前記ユーザ機器から受信するステップと、
ｉｉ．前記緊急表示情報に従って前記ユーザ機器内の緊急状態の無線ベアラに、対応する無線リソースを割り振るステップと
を含む、無線リソーススケジューリング方法。
【請求項３０】
前記緊急表示情報が、緊急状況および／または緊急レベルを示すための情報を含むことを特徴する、請求項２９に記載の無線リソーススケジューリング方法。
【請求項３１】
無線遠隔通信ネットワークにおける基地局内の、ユーザ機器のアップリンク伝送待ち時間およびデータパケット消失を低減するための無線リソーススケジューリング用デバイスであって、
緊急表示情報を前記ユーザ機器から受信するための受信手段と、
前記緊急表示情報に従って前記ユーザ機器内の緊急状態の無線ベアラに、対応する無線リソースを割り振ることを判定するための判定手段と
を有する、無線リソーススケジューリング用デバイス。
【請求項３２】
前記緊急表示情報が、緊急状況および／または緊急レベルを示すための情報を含むことを特徴する、請求項３１に記載の無線リソーススケジューリング用デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線遠隔通信ネットワークに関し、特に、ユーザ機器のアップリンクスケジューリングまたは緊急状態に関する要求情報を報告する方式に関する。
【背景技術】
【０００２】
Ｅ−ＵＴＲＡＮ  （Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ（発展版ユニバーサル地上無線アクセスネットワーク））では、データはアップリンク共用チャネルを介して伝送される。ＢＳ（基地局）は各ＵＥ（ユーザ機器）にリソースを割り振る。アップリンク伝送でより良い多重化パフォーマンスを実現するように各ＵＥにそのＵＥ独自の必要性に応じたリソースを割り振り、サービスを提供するには、ＢＳは、各ＵＥにいくつのリソースを割り振るべきかを知る必要がある。したがって、ＵＥは、ＢＳにそれぞれのＵＥ独自の要件を効率のよい方法で報告する必要がある。アップリンクグループスケジューリングをサポートするスケジューリング情報報告方式は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ（長期発展））標準化が進められるなかで定義される重要な機能である。
【０００３】
以下の問題は、スケジューリング情報の報告の設計の際に検討する必要がある：
１．スケジューリング情報は、スケジューリングの効率を上げるために十分な情報を提供すべきである。
従来の無線データ遠隔通信システムでは、リソース割り振りは、通常、次の２つの方法を適用する。すなわち、バッファ認識（ｂｕｆｆｅｒ−ａｗａｒｅ）アルゴリズムおよびバッファ無視（ｂｕｆｆｅｒ−ｂｌｉｎｄ）アルゴリズムである。バッファ無視アルゴリズムと比較すると、バッファ認識アルゴリズムは、ＵＥによって報告されたバッファサイズ情報を基にしてスケジューリングを行うので、スケジューリングの効率を上げることができるが、バッファ無視アルゴリズムは、過去に割り振られたリソースの使用状態に応じてのみスケジュールする。したがって、バッファ報告、すなわち、バッファサイズ報告は、報告しなければならない重要なスケジューリング情報である。さらに、ＬＴＥでのＱｏＳのすべてのサービスが共用チャネルを介して伝送されるという事実のために、ＢＳは効率のよいスケジューリングを行い、待ち時間およびパケットエラーの要件を満たす必要があり、そのため、待ち時間情報も、ＵＥによってＢＳに報告されなければならない。このため、待ち時間情報のための、よく定義された効率のよい報告方式が必要である。
２．スケジューリング情報は、ＱｏＳ認識スケジューリングをサポートすべきである。
ＱｏＳ認識スケジューリングをサポートするためには、スケジューリング情報の報告に、異なるＱｏＳに応じた差異を設けるべきである。
３．スケジューリング情報のオーバーヘッドは、できるだけ少なくすべきである。
スケジューリング情報のオーバーヘッドは、オーバーヘッドの量がアップリンク容量に直接に影響するので、できるだけ少なくすべきである。
【０００４】
ここまでに、スケジューリング情報のいくつかの報告方式があった。参考文献１（Ｒ２−０６８０２９、「Ｂｕｆｆｅｒ  Ｒｅｐｏｒｔｉｎｇ  ｆｏｒ  Ｅ−ＵＴＲＡＮ」、ＥＴＲＩ、アテネ、ギリシャ、２００６年３月２７−３１日）は、バッファ報告の方法のみを説明している。この文献は、優先順位に基づいたバッファ報告方法をサポートしているが、報告のフォーマットはすべてのサービスストリームのバッファ情報を含んでおり、報告のフォーマットのサイズは固定である。参考文献２（Ｒ２−０６１０２３、「Ｔｉｍｅｒ−ｂａｓｅｄ  Ｒｅｓｏｕｒｃｅ  Ｒｅｑｕｅｓｔ」、ＥＴＲＩ、アテネ、ギリシャ、２００６年３月２７−３１日）は、異なるサービスに関する報告の異なる内容およびメカニズムを説明しているが、説明が大まかであり、報告の詳細なフォーマットを提案していない。
【０００５】
参考文献１は、待ち時間情報の報告のないバッファ報告のみを説明している。参考文献２は、ヘッドオブライン（ＨＯＬ）遅延の概念を提案しているが、それは、絶対待ち時間情報の報告方法である。
【０００６】
ＨＳＵＰＡ  （Ｈｉｇｈ  Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（高速アップリンクパケットアクセス））システムでは、報告情報は、スケジューリング情報およびハッピービットによって伝送される。スケジューリング情報はＭＡＣシグナリングによって伝送され、その情報は、バッファ全体のサイズおよび最高優先順位を有する論理チャネルのバッファ長を含む。このような報告方法は、低い優先順位を有するサービスの優先順位に差異を付けることができず、したがって、優先順位に基づくスケジューリングはサポートできなかった。さらに、報告が頻繁なためにシグナリングのオーバーヘッドが比較的高い。ハッピービットは、現在割り振られているリソースに関する満足を表すためにのみ使用され、待ち時間情報およびパケット消失情報を表示することはできなかった。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】参考文献１、Ｒ２−０６８０２９、「Ｂｕｆｆｅｒ  Ｒｅｐｏｒｔｉｎｇ  ｆｏｒ  Ｅ−ＵＴＲＡＮ」、ＥＴＲＩ、アテネ、ギリシャ、２００６年３月２７−３１日
【非特許文献２】参考文献２、Ｒ２−０６１０２３、「Ｔｉｍｅｒ−ｂａｓｅｄ  Ｒｅｓｏｕｒｃｅ  Ｒｅｑｕｅｓｔ」、ＥＴＲＩ、アテネ、ギリシャ、２００６年３月２７−３１日
【発明の概要】
【発明が解決しようとする課題】
【０００８】
当技術における技術的問題を解決するために、本発明の１つの目的は、無線遠隔通信ネットワークにおけるアップリンクスケジューリングまたは緊急状態（待ち時間情報およびパケット消失を含む）に関する要求情報を報告するための１つの技術的ソリューションを提供することである。
【課題を解決するための手段】
【０００９】
本発明の第１の態様によれば、無線遠隔通信ネットワークにおけるユーザ機器内に、アップリンクスケジューリングに関する要求情報を基地局へ報告するための方法が提供される。第一に、ユーザ機器は、そのユーザ機器のバッファ内の、同じ優先順位を有する１つまたは複数の無線ベアラを含む無線ベアラの各グループ内の全無線ベアラの全サービスデータ量を計算し、次に無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報のみを基地局へ報告する。
【００１０】
本発明の第２の態様によれば、無線遠隔通信ネットワークにおけるユーザ機器内に、アップリンクスケジューリングに関する要求情報を基地局へ報告するための報告用デバイスが備えられる。この報告用デバイスは、計算手段および被制御送信手段を有する。計算手段は、そのユーザ機器のバッファ内の、同じ優先順位を有する１つまたは複数の無線ベアラを含む無線ベアラの各グループ内の全無線ベアラの全サービスデータ量を計算するために使用され、被制御送信手段は、無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報を基地局へ報告するためのみに使用される。
【００１１】
本発明の第３の態様によれば、無線遠隔通信ネットワークにおける基地局内に、ユーザ機器に無線リソースを割り振るための方法が提供される。第一に、基地局は、無線ベアラの１つまたは複数のグループのグループ関連情報をユーザ機器から受信し、次に、基地局は、受信されたグループ関連情報に従ってユーザ機器内の無線ベアラの各グループに割り振られる無線リソースを判定する。
【００１２】
本発明の第４の態様によれば、無線遠隔通信ネットワークにおける基地局内に、ユーザ機器に無線リソースを割り振るための無線リソース割り振り用デバイスが備えられる。このデバイスは、受信手段および判定手段を有する。ここで、受信手段は、無線ベアラの１つまたは複数のグループのグループ関連情報をユーザ機器から受信するために使用され、判定手段は、受信されたグループ関連情報に従ってユーザ機器内の無線ベアラの各グループに割り振られる無線リソースを判定するために使用されるものとする。
【００１３】
本発明の第５の態様によれば、無線遠隔通信ネットワークにおけるユーザ機器内に、無線ベアラの緊急状態を基地局へ報告するための方法が提供される。第一に、ユーザ機器は、各無線ベアラが緊急状態あるかを判断し、１つまたは複数の前記無線ベアラが緊急状態にある場合、そのユーザ機器は緊急表示情報を基地局へ送信する。
【００１４】
本発明の第６の態様によれば、無線遠隔通信ネットワークにおけるユーザ機器内に、無線ベアラの緊急情報を基地局へ報告するためのデバイスが備えられる。このデバイスは、判断手段および送信手段を有する。ここで、判断手段は、各無線ベアラが緊急状態であるかを判断するために使用され、送信手段は、１つまたは複数の前記無線ベアラが緊急状態の場合に緊急表示情報を基地局へ送信するために使用されるものとする。
【００１５】
本発明の第７の態様によれば、無線遠隔通信ネットワークにおける基地局内に、ユーザ機器のアップリンク伝送待ち時間およびデータパケット消失を低減するための無線リソーススケジューリング方法が提供される。第一に、基地局は、緊急表示情報をユーザ機器から受信し、次に、基地局は、受信された緊急表示情報に従ってユーザ機器内の緊急状態の無線ベアラに、対応する無線リソースを割り振る。
【００１６】
本発明の第８の態様によれば、無線遠隔通信ネットワークにおける基地局内に、ユーザ機器のアップリンク伝送待ち時間およびデータパケット消失を低減するための無線リソーススケジューリング用デバイスが備えられる。この無線リソーススケジューリング用デバイスは、受信手段および判定手段を有する。ここで、受信手段は、緊急表示情報をユーザ機器から受信するために使用され、判定手段は、受信された緊急表示情報に従ってユーザ機器内の緊急状態の無線ベアラに、対応する無線リソースを割り振ることを決定するために使用されるものとする。
【００１７】
本発明は、従来技術に比べて以下の利点がある：
１．スケジューリング情報に関して提案された報告方法によって、バッファ状態情報および伝送待ち時間およびデータパケット消失情報などのＱｏＳ情報が報告できる。
２．優先順位に基づくバッファ状態報告は、優先順位に基づく柔軟なトリガメカニズムおよび柔軟なシグナリング（プロトコルデータユニット（ＰＤＵ）伝送を満杯または制御する層２（Ｌ２）を介する）を有し、一方でシグナリングオーバーヘッドは低減される。
３．緊急伝送待ち時間およびデータパケット消失情報（レベル）を報告するために使用される緊急表示情報が導入される。この報告方法は、詳細なＱｏＳ情報報告のオーバーヘッドを大幅に節約できる。緊急表示情報は、層１（Ｌ１）シグナリングを介して伝送できる。
４．スケジューリング情報に関して提案された報告方法によって、優先順位に基づいた効率のよいスケジューリングアルゴリズムが、伝送待ち時間およびデータパケット消失率などのＱｏＳ要件を満たすように設計できる。
【００１８】
これ以降に記載される、限定でない実施形態の詳細な説明を図面を参照しながら読めば、これらおよび他の機能、目的および利点が明らかになろう。
【図面の簡単な説明】
【００１９】
【図１】本発明の１つの実施形態による無線遠隔通信ネットワークのネットワークトポロジーを示した図である。
【図２ａ】無線遠隔通信ネットワークにおいてＵＥがアップリンクスケジューリングに関する要求情報をＢＳへ報告する場合の、本発明の１つの実施形態による要求情報の詳細なフォーマットを示した図である。
【図２ｂ】無線遠隔通信ネットワークにおいてＵＥがアップリンクスケジューリングに関する要求情報をＢＳへ報告する場合の、本発明の別の実施形態による要求情報の詳細なフォーマットを示した図である。
【図３】無線遠隔通信ネットワークにおいてアップリンクスケジューリングに関する要求を報告するための、本発明の１つの実施形態によるＵＥ内の方法のフローチャートである。
【図４】無線遠隔通信ネットワークにおいて無線ベアラの緊急状態を報告するための、本発明の１つの実施形態によるＵＥ内の方法のフローチャートである。
【図５】無線遠隔通信ネットワークにおける、本発明の１つの実施形態によるＵＥのブロック図である。
【図６】無線遠隔通信ネットワークにおいてＵＥからのアップリンクスケジューリングに関する要求に従ってＵＥに無線リソースを割り振るための、本発明の１つの実施形態によるＢＳ内の方法のフローチャートである。
【図７】無線遠隔通信ネットワークにおいてＵＥのアップリンク待ち時間およびデータパケット消失を低減するためにＵＥに無線リソースを割り振るための、本発明の１つの実施形態によるＢＳ内の方法のフローチャートである。
【図８】無線遠隔通信ネットワークにおける、本発明の１つの実施形態によるＢＳのブロック図である。
【発明を実施するための形態】
【００２０】
図１に示されているように、ＬＴＥにおいて、ＢＳ２は、通常、ＵＥ１からのスケジューリング要求に従ってＵＥ１に無線リソースを割り振る。スケジューリング情報の報告は、ＬＴＥにおける重要な問題である。効率的なスケジューリングをサポートするために、ＵＥ１は、最小のシグナリングを利用して、できるだけ多くの情報を提供する必要がある。ＬＴＥはＱｏＳベースのスケジューリングをサポートする。ＢＳ２が異なるＵＥ間で異なるＱｏＳサービスの公平なスケジューリングを実現したい場合、ＢＳ２はＵＥ１が、ＱｏＳベースのバッファ状態の報告をサポートすることを必要とする。しかし、ＵＥ１におけるＱｏＳベースのバッファ報告の細分性（ｇｒａｄｕｌａｒｉｔｙ）はどうであろうか？  現在、次の３つの選択肢がある。すなわち、１）ＵＥ１に基づいたバッファ報告、２）無線ベアラのグループに基づいたバッファ報告、および３）無線ベアラに基づいた報告。ここで、ＵＥ１に基づいたバッファ報告とは、ＵＥ１内のバッファ全体のデータ量を報告することを意味する。この報告方法は、異なるＵＥ間のサービスの優先順位に差異を付けられないことが明らかであるが、この方法のシグナリングオーバーヘッドは比較的小さい。無線ベアラのグループに基づいたバッファ報告とは、無線ベアラの各グループのデータ量を個々に報告することを意味する。無線ベアラのグループとは、同じサービス優先順位を有する無線ベアラの組み合わせを意味し、無線ベアラのグループのデータ量は、そのグループ内の全無線ベアラのデータ量を加算することにより得られる。この報告方法はＱｏＳに差異を付けることができ、シグナリングオーバーヘッドは中程度である。そして、無線ベアラに基づいた報告とは、各無線ベアラのデータ量を個々に報告することを意味する。この報告方法はＱｏＳのより詳細な報告を提供できることは明らかであるが、シグナリングオーバーヘッドが膨大である。したがって、無線ベアラのグループに基づいたバッファ報告が推奨される。
【００２１】
無音（ｓｉｌｅｎｃｅ）圧縮を行わないほとんどのＶｏＩＰエンコーダは事前定義された長さのパケットを固定のサンプリングインターバルで生成するという理由のために、ＢＳ２は、一般的に、いくつのパケットが伝送済みで、いくつのパケットが伝送されるのを待っているかを認識している。しかし、ＭＰＥＧイメージサービスのバーストは大きい、また対話式ゲームサービスおよびＦＴＰサービスのバーストはさらに大きいために、ＵＥ１がバッファ状態の報告を行わない場合、ＢＳ２がバッファのサイズを認識することは困難である。定期的報告方法がサポートされる場合、これらのサービスは異なる周期が必要である。例えば、ＶｏＩＰサービスは、対話式ゲームサービスおよびＦＴＰサービスに比較してバッファ報告は少なくてよい（理論的には、なくてよい）。イベントトリガ式報告方法がサポートされる場合、トリガメカニズムは、これらのサービスが異なるＱｏＳ要件を有するという理由のために、異なる（おそらく、サービス種類ごとに独立してトリガされる）。そのため、次の状況が発生する可能性がある。すなわち、ある１つのサービスのバッファ報告がトリガされても（定期的トリガ型であるか、イベントトリガ型であるかに関係なく）、他のサービスのバッファ状態を報告する必要がない。したがって、以下の結論に達することができる。すなわち、個々の報告が必ずしも無線ベアラの全グループの情報を含むわけではない。バッファ報告は、無線ベアラの報告されるグループの数、無線ベアラの対応するグループのグループインジケータおよびデータ量を含む。報告の推奨されるフォーマットが図２ａに示されている。
【００２２】
バッファ状態報告は、バッファ内にどれだけのデータがあるかのみを報告することができる。つまり、どれだけのデータが伝送される必要があるかを意味する。しかし、この情報のみに基づくと、ＢＳ２は、伝送待ち時間およびデータパケット消失情報を認識することができない。したがって、本発明では、伝送待ち時間およびデータパケット消失情報を示すための緊急表示情報が導入されている。ＢＳ２は、バッファ状態報告および緊急表示情報の組み合わせにより、効率的かつ公平なスケジューリングを実現することができる。
【００２３】
以下で、本発明を図２〜図８と組み合わせて詳しく説明する。
【００２４】
図３は、無線遠隔通信ネットワークにおいてアップリンクスケジューリングに関する要求をＢＳ２へ報告するための、本発明の１つの実施形態によるＵＥ内の方法のフローチャートを示している。
【００２５】
ステップＳ１１１において、ＵＥ１のバッファ内の、同じ優先順位を有する１つまたは複数の無線ベアラを含む無線ベアラの各グループ内の全無線ベアラの全サービスデータ量が計算される。
【００２６】
ステップＳ１１１のあと、無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報のみが報告される。詳細は、ステップＳ１１２およびＳ１１３に示されている。
【００２７】
ステップＳ１１２において、無線ベアラの各グループがトリガされたかが判断される。ここで、トリガは、イベントトリガまたは時間トリガのどちらでもよい。
【００２８】
イベントトリガの詳しい例として、ＵＥ１のバッファ内の無線ベアラのある特定のグループの全サービスデータ量が、対応する事前定義されたしきい値を超えた時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。イベントトリガの別の例として、ＵＥ１のバッファ内の無線ベアラのある特定のグループの全サービスデータ量が、対応する事前定義されたしきい値より少なくなった時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。イベントトリガのさらに別の詳しい例として、ＵＥ１のバッファ内の無線ベアラのある特定のグループのサービスデータ量の変化が、ある一定の期間中に、対応する事前定義されたしきい値を超えた時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。様々な種類のイベントトリガの例があり、それらは、上述の例に限定されない。
【００２９】
時間トリガの詳しい例として、無線ベアラのある特定のグループに関する事前定義された報告時間に達した時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。ここで、事前定義された報告時間は、定期的または非定期的であってよいが、それは、具体的なサービスカテゴリに基づく。
【００３０】
ステップＳ１１３において、その中の無線ベアラの１つまたは複数のグループがトリガされた時、無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報がＢＳ２へ送信される。ここで、グループ関連情報は、無線ベアラのトリガされた１つまたは複数のグループの数、無線ベアラのトリガされたグループのそれぞれのグループインジケータおよび全サービスデータ量を含むものとし、それらの順序は図２ａまたは図２ｂに示されているが、それによって限定されることはない。グループ関連情報は、メディアアクセス制御（ＭＡＣ）層内のデータフレームによってＢＳ２へ送信できる。または、新しい制御プロトコルデータユニットによってＢＳ２へ送信できる。
【００３１】
図４は、無線遠隔通信ネットワークにおいて無線ベアラの緊急状態をＢＳ２へ報告するための、本発明の１つの実施形態によるＵＥ１内の方法のフローチャートを示している。
【００３２】
第一に、各無線ベアラが緊急状態であるかが判定されるが、これはステップＳ１２１、Ｓ１２２、およびＳ１２３に分割できる。
【００３３】
ステップＳ１２１において、ＵＥ１のバッファ内の各無線ベアラのサービスデータの滞留時間が計算される。
【００３４】
ステップＳ１２２において、各無線ベアラのサービスデータの滞留時間が、対応する事前定義された値と比較される。
【００３５】
ステップＳ１２３において、バッファ内の１つまたは複数の無線ベアラのサービスデータの滞留時間が、対応する事前定義された値を超えている場合、その１つまたは複数の無線ベアラは緊急状態であると判断される。
【００３６】
次に、ステップＳ１２４において、その１つまたは複数の無線ベアラが緊急状態の場合、緊急表示情報がＢＳ２へ送信される。緊急表示情報は、緊急状況および／または緊急レベルを示すための情報を含む。緊急表示情報は、制御シグナリングで移送できる。
【００３７】
実際の状況では、待ち時間の影響を受けやすいサービスの場合、緊急表示情報は、一定の数のビット（Ｌ１）が一定の時間（Ｔ１）に渡ってすでに無線リンクコントローラ（ＲＬＣ）のバッファ内で既に待機していることを示すために使用される。エラーの影響を受けやすいサービスの場合、緊急表示情報は、一定の時間（Ｔ２）経過後に、一定の数のビット（Ｌ２）がＲＬＣ破棄メカニズムによって破棄されることを示すために使用される。Ｌ１、Ｌ２、Ｔ１、Ｔ２は、各無線ベアラのＱｏＳに応じて決めることができる。
【００３８】
緊急表示情報が使用される場合、全無線ベアラ用に１ビットのみ必要とされることがある。１ビットが適用される場合、１つの無線ベアラが緊急条件を満たしている限り、その無線ベアラは緊急状態であり、緊急ビットが「緊急」に設定される。全無線ベアラが非緊急状態の場合のみ、緊急ビットは「非緊急」に設定される。そのような報告方法は、伝送待ち時間およびデータパケット消失情報を最小のシグナリングオーバーヘッドで提供することができる。ＢＳ２は無線リソースを緊急状態のＵＥ１に割り振り、ＵＥ１が、その無線リソースが提供される先方の無線ベアラを判定する。
【００３９】
また、無線ベアラの各グループ（同じ優先順位を有する複数の無線ベアラのグループ）または各無線ベアラが１ビットを使用して、無線ベアラの各グループまたは各無線ベアラが緊急状態であるかを示すことができる。この方法のほうが細分性が良く、より細分性の良い伝送待ち時間およびデータパケット消失情報を提供することができ、その情報により、ＢＳ２は、より正確にスケジュールすることができる。しかし、全無線ベアラが１ビットを共用する上述の方法に比較すると、この方法は、シグナリングオーバーヘッドが大きくならざるを得ない。
【００４０】
さらに、上記の２つの方法で、１ビットの代わりに２個、３個、またはそれ以上のビットを使用することもできる。２個以上のビットを使用すれば、複数の緊急状況のレベルを定義することができ、そのため、緊急度に差異を付けられるようになり、その結果、ＢＳ２は、より詳細な伝送待ち時間およびデータパケット消失情報を得ることができ、したがって、これらのＱｏＳ情報をより柔軟に扱うことができる。１ビットに比べると、この方法では、シグナリングオーバーヘッドが大きくなる。
【００４１】
図５は、無線遠隔通信ネットワークにおける、本発明の１つの実施形態によるＵＥのブロック図である。ＵＥ１は、アップリンクスケジューリング要求報告手段１１および緊急状況報告手段１２を有している。
【００４２】
アップリンクスケジューリング要求報告手段１１は、計算手段１１１および被制御送信手段１１２を有している。被制御送信手段１１２は、判断手段１１２１および送信手段１１２２を有している。
【００４３】
計算手段１１１は、第一に、ＵＥ１のバッファ内の、同じ優先順位を有する１つまたは複数の無線ベアラを含む無線ベアラの各グループ内の全無線ベアラの全サービスデータ量を計算する。
【００４４】
被制御送信手段１１２は、次いで無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報のみをＢＳ２へ報告する。
【００４５】
ここで、判断手段１１２１は、無線ベアラの各グループがトリガされるかを判断する。ここで、トリガは、イベントトリガまたは時間トリガのどちらでもよい。
【００４６】
イベントトリガの詳しい例として、ＵＥ１のバッファ内の無線ベアラのある特定のグループの全サービスデータ量が、対応する事前定義されたしきい値を超えた時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。イベントトリガの別の例として、ＵＥ１のバッファ内の無線ベアラのある特定のグループの全サービスデータ量が、対応する事前定義されたしきい値より少なくなった時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。イベントトリガのさらに別の詳しい例として、ＵＥ１のバッファ内の無線ベアラのある特定のグループのサービスデータ量の変化が、ある一定の期間中に、対応する事前定義されたしきい値を超えた時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。様々な種類のイベントトリガの例があり、それらは、上述の例に限定されない。
【００４７】
時間トリガの詳しい例として、無線ベアラのある特定のグループに関する事前定義された報告時間に達した時、無線ベアラのそのグループはトリガされたと判断されることが挙げられる。ここで、事前定義された報告時間は、定期的または非定期的であってよいが、それは、具体的なサービスカテゴリに基づく。
【００４８】
判断手段１１２１がその中の無線ベアラの１つまたは複数のグループがトリガされたと判断すると、送信手段１１２２が無線ベアラのトリガされた１つまたは複数のグループのグループ関連情報をＢＳ２へ送信する。ここで、グループ関連情報は、無線ベアラのトリガされた１つまたは複数のグループの数、無線ベアラのトリガされたグループのそれぞれのグループインジケータおよび全サービスデータ量を含むものとし、それらの順序は図２ａまたは図２ｂに示されているが、それによって限定されることはない。グループ関連情報は、メディアアクセス制御（ＭＡＣ）層内のデータフレームによってＢＳ２へ送信できる。または、新しい制御プロトコルデータユニットによってＢＳ２へ送信できる。
【００４９】
緊急状況報告手段１２は、判断手段１２１および送信手段１２２を有している。判断手段１２１は、計算手段１２１１、比較手段１２１２、および判定手段１２１３を有している。
【００５０】
判断手段１２１は、各無線ベアラが緊急状態であるかを判定する。具体的に言えば、計算手段１２１１は、ＵＥ１のバッファ内の各無線ベアラのサービスデータの滞留時間を計算する。比較手段１２１２は、各無線ベアラのサービスデータの滞留時間を、対応する事前定義された値と比較する。１つまたは複数の無線ベアラの事前定義されたサービスデータ量の滞留時間が、対応する事前定義された値を超えている場合、判定手段１２１３は、その１つまたは複数の無線ベアラは緊急状態であると判定する。
【００５１】
その１つまたは複数の無線ベアラが緊急状態の場合、送信手段１２２が緊急表示情報をＢＳ２へ送信する。緊急表示情報は、緊急状況および／または緊急レベルを示すための情報を含む。緊急表示情報は、制御シグナリングで移送できる。
【００５２】
実際の状況では、待ち時間の影響を受けやすいサービスの場合、緊急表示情報は、一定の数のビット（Ｌ１）が一定の時間（Ｔ１）に渡ってすでに無線リンクコントローラ（ＲＬＣ）のバッファ内で既に待機していることを示すために使用される。エラーの影響を受けやすいサービスの場合、緊急表示情報は、一定の時間（Ｔ２）経過後に、一定の数のビット（Ｌ２）がＲＬＣ破棄メカニズムによって破棄されることを示すために使用される。Ｌ１、Ｌ２、Ｔ１、Ｔ２は、各無線ベアラのＱｏＳに応じて決めることができる。
【００５３】
緊急表示情報が使用される場合、全無線ベアラ用に１ビットのみ必要とされることがある。１ビットが適用される場合、１つの無線ベアラが緊急条件を満たしている限り、その無線ベアラは緊急状態であり、緊急ビットが「緊急」に設定される。全無線ベアラが非緊急状態の場合のみ、緊急ビットは「非緊急」に設定される。そのような報告方法は、伝送待ち時間およびデータパケット消失情報を最小のシグナリングオーバーヘッドで提供することができる。ＢＳ２は無線リソースを緊急状態のＵＥ１に割り振り、ＵＥ１が、その無線リソースが提供される先方の無線ベアラを判定する。
【００５４】
また、無線ベアラの各グループ（同じ優先順位を有する複数の無線ベアラのグループ）または各無線ベアラが１ビットを使用して、無線ベアラの各グループまたは各無線ベアラが緊急状態であるかを示すことができる。この方法の方が細分性が良く、より細分性の良い伝送待ち時間およびデータパケット消失情報を提供することができ、その情報により、ＢＳ２は、より正確にスケジュールすることができる。しかし、全無線ベアラが１ビットを共用する上述の方法に比較すると、この方法は、シグナリングオーバーヘッドが大きくならざるを得ない。
【００５５】
さらに、上記の２つの方法で、１ビットの代わりに２個、３個、またはそれ以上のビットを使用することもできる。２個以上のビットを使用すれば、複数の緊急状況のレベルを定義することができ、そのため、緊急度に差異を付けられるようになり、その結果、ＢＳ２は、より詳細な伝送待ち時間およびデータパケット消失情報を得ることができ、したがって、これらのＱｏＳ情報をより柔軟に扱うことができる。１ビットに比べると、この方法では、シグナリングオーバーヘッドが大きくなる。
【００５６】
図６は、無線遠隔通信ネットワークにおいてＵＥ１からのアップリンクスケジューリングに関する要求に従ってＵＥ１に無線リソースを割り振るための、本発明の１つの実施形態によるＢＳ内の方法のフローチャートを示している。
【００５７】
ステップＳ２１１において、ＵＥ１からの無線ベアラの１つまたは複数のグループのグループ関連情報およびＵＥ１にリソースを割り振るために必要な他の情報が受信される。
【００５８】
ステップＳ２１２において、受信されたグループ関連情報およびＵＥ１にリソースを割り振るために必要な他の情報に従って、ＵＥ１内の無線ベアラの各グループに割り振られる無線リソースが判定される。
【００５９】
ここで、グループ関連情報は、無線ベアラのトリガされた１つまたは複数のグループの数、無線ベアラのトリガされたグループのそれぞれのグループインジケータおよび全サービスデータ量を含むものとし、それらの順序は図２ａまたは図２ｂに示されているが、それによって限定されることはない。ここで、ＵＥ１にリソースを割り振るために必要な他の情報は、チャネル状態などの情報を含む。
【００６０】
図７は、無線遠隔通信ネットワークにおいてＵＥ１のアップリンク待ち時間およびデータパケット消失を低減するためにＵＥ１に無線リソースを割り振るための、本発明の１つの実施形態によるＢＳ内の方法のフローチャートである。
【００６１】
ステップＳ２２１において、緊急表示情報およびＵＥ１にリソースを割り振るために必要な他の情報がＵＥ１から受信され、ステップＳ２２２において、緊急表示情報およびＵＥ１にリソースを割り振るために必要な他の情報に従って、ＵＥ１内の緊急状態の無線ベアラに無線リソースが割り振られる。ここで、緊急表示情報は、緊急状況および／または緊急レベルを示すための情報を含み、ＵＥ１にリソースを割り振るために必要な他の情報は、チャネル状態などの情報を含むものとする。
【００６２】
実際の状況では、待ち時間の影響を受けやすいサービスの場合、緊急表示情報は、一定の数のビット（Ｌ１）が一定の時間（Ｔ１）に渡ってすでにＲＬＣバッファ内で既に待機していることを示すために使用される。エラーの影響を受けやすいサービスの場合、緊急表示情報は、一定の時間（Ｔ２）経過後に、一定の数のビット（Ｌ２）がＲＬＣ破棄メカニズムによって破棄されることを示すために使用される。Ｌ１、Ｌ２、Ｔ１、Ｔ２は、各無線ベアラのＱｏＳに応じて決めることができる。
【００６３】
緊急表示情報が使用される場合、全無線ベアラ用に１ビットのみ必要とされることがある。１ビットが適用される場合、１つの無線ベアラが緊急条件を満たしている限り、その無線ベアラは緊急状態であり、緊急ビットが「緊急」に設定される。全無線ベアラが非緊急状態の場合のみ、緊急ビットは「非緊急」に設定される。そのような報告方法は、伝送待ち時間およびデータパケット消失情報を最小のシグナリングオーバーヘッドで提供することができる。ＢＳ２は無線リソースを緊急状態のＵＥ１に割り振り、ＵＥ１が、その無線リソースが提供される先方の無線ベアラを判定する。
【００６４】
また、無線ベアラの各グループ（同じ優先順位を有する複数の無線ベアラのグループ）または各無線ベアラが１ビットを使用して、無線ベアラの各グループまたは各無線ベアラが緊急状態であるかを示すことができる。この方法のほうが細分性が良く、より細分性の良い伝送待ち時間およびデータパケット消失情報を提供することができ、その情報により、ＢＳ２は、より正確にスケジュールすることができるが、全無線ベアラが１ビットを共用する上述の方法に比較すると、この方法は、シグナリングオーバーヘッドが大きくならざるを得ない。
【００６５】
さらに、上記の２つの方法で、１ビットの代わりに２個、３個、またはそれ以上のビットを使用することもできる。２個以上のビットを使用すれば、複数の緊急状況のレベルを定義することができ、そのため、緊急度に差異を付けられるようになり、その結果、ＢＳ２は、より詳細な伝送待ち時間およびデータパケット消失情報を得ることができ、したがって、これらのＱｏＳ情報をより柔軟に扱うことができる。１ビットに比べると、この方法では、シグナリングオーバーヘッドが大きくなる。
【００６６】
図８は、無線遠隔通信ネットワークにおける、本発明の１つの実施形態によるＢＳ２のブロック図である。ＢＳ２は、第１の無線リソース割り振り手段２１および第２の無線リソース割り振り手段２２を有している。第１の無線リソース割り振り手段２１は、第１の受信手段２１１および第１の判定手段２１２を有している。第一に、第１の受信手段２１１が、ＵＥ１からの無線ベアラの１つまたは複数のグループのグループ関連情報およびＵＥ１にリソースを割り振るために必要な他の情報を受信する。次に、第１の判定手段２１２が、受信されたグループ関連情報およびＵＥ１にリソースを割り振るために必要な他の情報に従って、ＵＥ１内の無線ベアラの各グループに割り振られる無線リソースを判定する。
【００６７】
ここで、グループ関連情報は、無線ベアラのトリガされた１つまたは複数のグループの数、無線ベアラのトリガされたグループのそれぞれのグループインジケータおよび全サービスデータ量を含むものとし、それらの順序は図２ａまたは図２ｂに示されているが、それによって限定されることはない。ここで、ＵＥ１にリソースを割り振るために必要な他の情報は、チャネル状態などの情報を含む。
【００６８】
第２の無線リソース割り振り手段２２は、第２の受信手段２２１および第２の判定手段２２２を有している。第２の受信手段２２１は、緊急表示情報およびＵＥ１にリソースを割り振るために必要な他の情報をＵＥ１から受信する。第２の判定手段２２２は、緊急表示情報およびＵＥ１にリソースを割り振るために必要な他の情報に従って、ＵＥ１内の緊急状態の無線ベアラに割り振られる無線リソースを判定する。ここで、緊急表示情報は、緊急状況および／または緊急レベルを示すための情報を含み、ＵＥ１にリソースを割り振るために必要な他の情報は、チャネル状態などの情報を含むものとする。
【００６９】
実際の状況では、待ち時間の影響を受けやすいサービスの場合、緊急表示情報は、一定の数のビット（Ｌ１）が一定の時間（Ｔ１）に渡ってすでにＲＬＣバッファ内で既に待機していることを示すために使用される。エラーの影響を受けやすいサービスの場合、緊急表示情報は、一定の時間（Ｔ２）経過後に、一定の数のビット（Ｌ２）がＲＬＣ破棄メカニズムによって破棄されることを示すために使用される。Ｌ１、Ｌ２、Ｔ１、Ｔ２は、各無線ベアラのＱｏＳに応じて決めることができる。
【００７０】
緊急表示情報が使用される場合、全無線ベアラ用に１ビットのみ必要とされることがある。１ビットが適用される場合、１つの無線ベアラが緊急条件を満たしている限り、その無線ベアラは緊急状態であり、緊急ビットが「緊急」に設定される。全無線ベアラが非緊急状態の場合のみ、緊急ビットは「非緊急」に設定される。そのような報告方法は、伝送待ち時間およびデータパケット消失情報を最小のシグナリングオーバーヘッドで提供することができる。ＢＳ２は無線リソースを緊急状態のＵＥ１に割り振り、ＵＥ１が、その無線リソースが提供される先方の無線ベアラを判定する。
【００７１】
また、無線ベアラの各グループ（同じ優先順位を有する複数の無線ベアラのグループ）または各無線ベアラが１ビットを使用して、無線ベアラの各グループまたは各無線ベアラが緊急状態であるかを示すことができる。この方法のほうが細分性が良く、より細分性の良い伝送待ち時間およびデータパケット消失情報を提供することができ、その情報により、ＢＳ２は、より正確にスケジュールすることができるが、全無線ベアラが１ビットを共用する上述の方法に比較すると、この方法は、シグナリングオーバーヘッドが大きくならざるを得ない。
【００７２】
さらに、上記の２つの方法で、１ビットの代わりに２個、３個、またはそれ以上のビットを使用することもできる。２個以上のビットを使用すれば、複数の緊急状況のレベルを定義することができ、そのため、緊急度に差異を付けられるようになり、その結果、ＢＳ２は、より詳細な伝送待ち時間およびデータパケット消失情報を得ることができ、したがって、これらのＱｏＳ情報をより柔軟に扱うことができる。１ビットに比べると、この方法では、シグナリングオーバーヘッドが大きくなる。
【００７３】
本発明の実施形態の説明は、上述のとおりである。本発明は上述の具体的な実施形態に限定されないことを理解すべきであり、当業者は、添付の特許請求の範囲内で様々な変更または修正を行うことができる。
【図１】
2010502056.tif 000003
【図２ａ】
2010502056.tif 000004
【図２ｂ】
2010502056.tif 000005
【図３】
2010502056.tif 000006
【図４】
2010502056.tif 000007
【図５】
2010502056.tif 000008
【図６】
2010502056.tif 000009
【図７】
2010502056.tif 000010
【図８】
2010502056.tif 000011
【国際調査報告】
2010502056.tif 000012
2010502056.tif 000013
2010502056.tif 000014
2010502056.tif 000015
2010502056.tif 000016
2010502056.tif 000017
2010502056.tif 000018
2010502056.tif 000019