JP2011530926A - ネットワークにおいて通信する方法、そのための二次局及びシステム - Google Patents

Abstract

本発明は、ネットワークにおいて通信する方法に関し、前記方法は、二次局が、レポートを有するデータパケットを一次局に送信するステップと、前記二次局が、前記パケットの送信前に、送信されるパケットのシーケンスにおける送信の順序の指示を前記パケットが含むかどうかをモニタリングするステップと、送信されるパケットのシーケンスにおける送信の順序の指示を追加するステップとを有する。

Description

本発明は、一次局及び少なくとも１つの二次局を有するネットワークにおいて通信する方法、並びにこのような二次局に関する。より具体的には、本発明は、ＧＳＭ（グローバル・システム・フォー・モバイル・コミュニケーションズ）又はＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーションズ・システム）ネットワークのような移動体通信ネットワークにおいて通信する方法に関する。

本発明は、例えば、ＵＭＴＳ及びＵＭＴＳロング・ターム・エボリューション、並びに複数の端末から基地局にコールをルートするハブにも関連する。

ＵＭＴＳシステムのような移動体通信ネットワークにおいて、一次局、例えばノードＢ（又は基地局若しくはｅＮＢ）は、複数のチャネルを用いて、少なくとも１つの二次局、例えばユーザ機器（又は移動局）と通信する。前記一次局にデータを送信するために、二次局は、前記一次局にリソースを要求する必要があり、前記リソースが割り当てられる。この割り当て要求は、考慮されるチャネルに依存して複数の方法で行われることができる。

一例において、リソースを要求するために、送信されるべきデータ、すなわち前記二次局のバッファ内のデータの量を示すことが必要とされる。このために、前記二次局は、前記二次局バッファ内のデータの量を示すバッファステータスレポートを前記一次局に送信する。したがって、前記一次局は、前記ネットワークの性能及び前記送信されるべきデータの量の両方に対応するリソースを割り当てる。これは、リソースの割り当てが調整されることを可能にする。

このレポートを送信するために、前記二次局は、例えば、ＡＲＱプロトコル又はＨＡＲＱプロトコルを使用する。これは、前記二次局が、前記一次局から受信の工程の承認を受信するまでメッセージを再送信することができることを意味する。このような場合、第１のレポートが、最終的に、送信されたずっと後に、場合によっては第２のレポートが前記第１のレポートを更新した後でさえ、正しく受信されることが可能である。このような場合、前記一次局は、前記第１のレポートが現在のステータスを表すと信じて前記第２のレポートを放棄しうる。これは、（前記第２のレポートが、データが前記バッファ内に無いこと示す場合）リソースの無駄、又は（前記第１のレポートが、データが前記バッファ内に無いことを示す場合）遅延を生じる可能性がある。

本発明の目的は、この問題が軽減されることを可能にする方法を提案することである。

本発明の他の目的は、送信シーケンス内のレポートが再順序付けされることを可能にする方法を提案することである。

本発明の他の目的は、前記一次局における混乱のリスクが低減されることを可能にする方法を提案することである。

このために、ネットワークにおいて通信する方法が提案され、前記方法は、二次局が、レポートを有するデータパケットを一次局に送信するステップと、前記二次局が、前記パケットの送信前に、送信されるパケットのシーケンスにおける送信の順序の指示（indication）を前記パケットが含むかどうかをモニタリングするステップと、前記送信されるパケットのシーケンスにおける送信の順序の指示を追加するステップとを有する。

本発明の第２の態様によると、二次局が提案され、前記二次局は、前記二次局のバッファ内のデータの量を表すバッファステータスレポートを有するデータパケットを一次局に送信する送信器を有し、前記二次局は、更に、前記パケットの送信前に、送信されるパケットのシーケンスにおける送信の順序の指示を前記パケットが含むかどうかをモニタリングするコントローラを有し、前記コントローラは、送信されるパケットのシーケンスにおける送信の順序の指示を追加するように構成される。

本発明の第３の態様によると、通信のシステムが提案され、前記システムは、二次局と通信する一次局を有し、前記二次局は、前記二次局のバッファ内のデータの量を表すバッファステータスレポートを有するデータパケットを前記一次局に送信する送信器を有し、前記二次局は、更に、前記パケットの送信前に、送信されるパケットのシーケンスにおける送信の順序の指示を前記パケットが含むかどうかをモニタリングするコントローラを有し、前記コントローラは、送信されるパケットのシーケンスにおける送信の順序の指示を追加するように構成される。

結果として、前記一次局は、前記一次局の混乱のリスクを低減するように前記レポートを再順序付けすることを可能にする。これは、レポートが前記二次局の現在のステータスを表し、これを考慮に入れるべきであるか、又はレポートが、例えば後の指示に取って代わられうる前記二次局の過去の状態を表しており、放棄されるべきであるかを前記一次局が知ることができることを意味する。

本発明のこれら及び他の態様は、以下に記載される実施例を参照して説明され、明らかになる。

本発明は、ここで、添付の図面を参照して、例として、更に詳細に記載される。

本発明において実施されるシステムのブロック図である。 従来技術によるメッセージの交換を示すタイムチャートである。

本発明は、基地局のような一次局１００と、移動局のような少なくとも１つの二次局とを有する図１に描かれる通信のシステム３００に関する。

無線システム３００は、複数の一次局１００及び／又は複数の二次局２００を有しうる。一次局１００は、送信器手段１１０及び受信手段１２０を有する。送信器手段１００の出力部及び受信手段１２０の入力部は、例えばサーキュレータ又は切り替えスイッチであることができる結合手段１４０によりアンテナ１３０に結合される。送信器手段１１０及び受信手段１２０に結合されるのは、例えばプロセッサであることができる制御手段１５０である。二次局２００は、送信器手段２１０及び受信手段２２０を有する。送信器手段２１０の出力部及び受信手段２２０の入力部は、例えばサーキュレータ又は切り替えスイッチであることができる結合手段２４０によりアンテナ２３０に結合される。送信器手段２１０及び受信手段２２０に結合されるのは、例えばプロセッサであることができる制御手段２５０である。一次無線局１００から二次局２００への送信は、ダウンリンクチャネル１６０において行われ、二次無線局２００から一次無線局１００への送信は、アップリンクチャネル２６０において行われる。

時々、二次局２００は、送信されるべきデータを含むバッファのステータスの指示をアップリンクチャネル２６０上で送信する。このバッファステータスレポートは、異なるタイプであることができる。ショートバッファステータスレポート（ＢＳＲ）は、論理チャネルの単一のグループの識別子と、現在、送信を待機している前記二次局のバッファ内にある前記論理チャネルのグループに対応するデータの量の６ビットインジケータとを有する。ロングＢＳＲは、４つの連結されたショートＢＳＲを有し、各ショートＢＳＲは、論理チャネルの異なるグループに対応する。

多くの通信システムは、送信リソースを異なるノードに割り当てるのに関与する集中型スケジューラを使用して動作する。典型例は、ＵＭＴＳ ＬＴＥのアップリンクであり、異なるＵＥからのアップリンク送信が、前記ｅＮＢにより時間及び周波数においてスケジュールされ、前記ｅＮＢが、ＵＥに"スケジュール許可"メッセージを送信し、前記メッセージが、典型的には前記許可メッセージの送信の約３ｍｓ後の前記ＵＥの送信に対する特定の時間−周波数リソースを示す。前記許可メッセージは、典型的には、前記ＵＥの送信に対して使用されるべきデータレート及び／又はパワーを指定する。

前記ｅＮＢが適切な許可を発行するために、前記ｅＮＢは、データの量、タイプ、及び各ＵＥのバッファ内の送信を待機しているデータの緊急性に関する十分な情報を持つことを必要とする。この情報は、サービスがもう少しでドロップされうるＵＥ又は個別のＵＥの満足レベルのいずれかを前記ｅＮＢ内の前記スケジューラに通知するのに使用されることができる。

ＬＴＥにおいて、ある数の異なるタイプのバッファステータスレポート（ＢＳＲ）メッセージが規定され、これらのメッセージは、特定のトリガが生じる場合にＵＥから前記ｅＮＢに送信されることができる。これに関する最新技術は、参照により組み込まれる3GPP TS36.321の現在のバージョン（２００８年６月現在）、5.4.5章により規定される。

ショートＢＳＲは、論理チャネルの単一のグループの識別子と、現在、送信を待機している前記ＵＥのバッファ内にある前記論理チャネルのグループに対応するデータの量の６ビットインジケータとを有する。ロングＢＳＲは、４つの連結したショートＢＳＲを有し、各ショートＢＳＲは、論理チャネルの異なるグループに対応する。

これは、現在、参照により組み込まれる36.321（２００８年６月現在）6.1.3.1章において規定されている。

この段落において詳述したように、異なる特性を持つ２つの主なタイプのバッファステータスレポート（ＢＳＲ）、すなわち、
−ＵＬデータが前記ＵＥ送信バッファに到着し、前記データが前記ＵＥ送信バッファ内に既に存在したデータより高い優先度を持つ論理チャネルに属する場合のみにトリガされるレギュラＢＳＲ、
−定期ＢＳＲタイマが満了する場合にトリガされる定期ＢＳＲ、
が存在する。

前記ＵＥが、このＴＴＩに対する新しい送信に対して割り当てられたＵＬリソースを持たない場合、及びレギュラＢＳＲが、ＢＳＲの最後の送信以降にトリガされる場合、スケジューリング要求（ＳＲ）がトリガされるべきである。

このＢＳＲメカニズムは、レギュラＢＳＲの送信に対して利用可能であるＵＬリソースが存在しない場合に、レギュラＢＳＲのみがＳＲの送信をトリガすることができるように設計されている。定期ＢＳＲがトリガされ、割り当てられたＵＬリソースが存在しない場合、前記ＵＥが利用可能なデータを持ち、意図的に前記ＵＥの使用に対してＵＬリソースを割り当てていないことを前記ネットワークが知っていると仮定されるので、前記ＵＥは、ＳＲを送信することができない。

前記定期ＢＳＲが、前記ＢＳＲの送信に対してＵＬリソースが利用可能ではない場合にＳＲを送信することを可能にされた場合、このシステムは、ＳＲを送信するＵＥでオーバロードになりうる。特に前記ＵＥが利用可能なＰＵＣＣＨリソースを持たない場合、ＳＲは、ＲＡＣＨアクセスの送信を必要とする。

また、ＳＲが、保留であると見なされ、ＵＬ−ＳＣＨリソースが許可されるまで繰り返されることが、３６．３２１に記載されている。

上で規定されたＢＳＲ手順に対する問題は、前記ＵＥ内のバッファの状態に関して前記ネットワークが知っている情報が前記ＵＥバッファの実際の状態と異なることができる可能性が存在することである。これは、ＢＳＲが前記ｅＮＢにおいて狂った順番で受信される場合に生じることができる。

ネットワークが、異なる時間においてＵＥからＢＳＲを受信する場合、例えばＨＡＲＱ再送信により前のＢＳＲが後に受信されることもありうるので、いずれが前記ＵＥにより送信された最新のＢＳＲであるかを前記ｅＮＢが決定する方法は存在しない。これは、ゼロを持つＢＳＲが前記ＵＥにより受信されることができ、この場合、たとえ前記ＵＥがバッファ内に送信されるべきデータを持つとしても、前記ネットワークが前記ＵＥからＵＬリソースを除去するという問題を引き起こすことができる。定期ＢＳＲが構成されても、レギュラＢＳＲ（高い優先順位を持つ新しいデータ）に対するトリガが満たされないので、前記ＵＥは、ＳＲを送信することができない。

これの一例は、図２に示される。このタイムチャートにおいて、バッファステータスレポート１００１の前に送信されるバッファステータスレポート１０００が再送信の数のために後にのみ受信されることが見られる。このレポートは、定期レポートであることができ、データが前記バッファステータスレポート内に無いことを示すことができる。前記一次局が、示された順序で前記レポートを受信する場合、現在のステータスが、データが前記二次局のバッファ内に無いことであると誤信する。このため、許可されるべきであるＵＥからのＵＬリソースを除去する。

ここで、主要な問題は、ＳＲが定期ＢＳＲから生成された場合、利用可能であるものが存在しない場合に前記ＵＥがＵＬリソースを絶えず要求するので、ＳＲが定期ＢＳＲから生成されることができないことである。

上に記載された場合に、前記ＵＥ ＵＬデータバッファは、前記バッファのネットワークビューと非同期である。本発明は、前記ＵＥからのＢＳＲが前記ＢＳＲと一緒に送信される情報を用いて実行されるべき順序を識別する方法を提供する。

前記ＢＳＲがデータを含められている場合、前記ＭＡＣパケット内のデータセグメントのＲＬＳシーケンス番号から生じる前記ＭＡＣパケット内に存在するシーケンス番号が既に存在し、したがって前記情報は、前記ＲＬＣシーケンス番号を有する。このシーケンス番号は、狂った順序で実行されないように、前記含められたＢＳＲのタイミングを識別するのに使用されることができる。

（例えばゼロＢＳＲレポートが送信される場合に生じるように）前記ＢＳＲと一緒に送信されたデータが存在しない場合、１つの可能性は、前記ＢＳＲに付随するシーケンス番号のみを持つＲＬＣパケットを生成することである。このようなパケットを生成する１つの手段は、前記ＲＬＣシーケンス番号を含むＲＬＣヘッダ（の全て又は一部）だけからなるゼロ・ペイロードＲＬＣ ＰＤＵを生成することであることができる。代替的には、前記ネットワークに対して有用でありうるシステムパラメータの測定の付加的なレポートのような、ほかに送信されていないデータを含む付加的小ペイロードＲＬＣ ＰＤＵが生成されることができる。

代替的には、前記情報は、前記ＭＡＣ層自体（すなわち前記ＢＳＲの処理と同じプロトコル層、したがって層間処理を低減する）により生成されたシーケンス番号を有することができ、例えば送信された最新のＲＬＣシーケンス番号から算出される。一部の実施例において、このようなＭＡＣレベルシーケンス番号は、前記ＢＳＲと一緒に送信されるべき他のデータが存在したかどうかにかかわらず、又は代替的には前記ＢＳＲと一緒に送信されるべきデータが存在しない場合にのみ、生成されることができる。

幾つかの他の可能性は、情報が専用ＢＳＲシーケンス番号又はシーケンス番号ではなくタイムスタンプ（絶対又は相対）からなることを含む。前記情報が前記ＲＬＣシーケンス番号を有さない場合に、前記情報とシステムフレーム番号又はサブフレーム番号のＲＬＳシーケンス番号との間の関連性は、規定される又は信号通知されることができる。

第２の実施例において、本発明は、ＵＥが生成することができる他のレポート、例えばＣＱＩ（チャネル品質情報）、ＰＭＩ（プリコーディングマトリクス指示）又はＲＩ（ランク指示）のようなチャネル状態情報に適用されることもできる。一般に、これらは、データと一緒に又は別々に送信されることができる。現在のＬＴＥ規格において、チャネル状態情報は、物理層信号を使用して送信されるが、原理的には、ＭＡＣ制御要素として送信されることができる。適用可能な実施例は、ＵＥとｅＮｏｄｅＢとの間の中継を使用するＬＴＥアドバンストのようなシステムである。前記ＵＥから前記中継に前記物理層上で送信されるチャネル状態情報は、ＢＳＲと一緒に、ＭＡＣ制御要素を使用して前記中継から前記ｅＮｏｄｅＢに送信されることができる。この情報は、前記ｅＮｏｄｅＢによりスケジュールするのに使用される。

本発明は、通信装置がＵＭＴＳ又はＬＴＥのような集中型スケジューリングを使用する移動体通信システムにおいて実施されることができる。

更に、本発明は、複数の端末から基地局に接続をルーティングするハブに対しても同様に実施されることができる。このような装置は、前記ネットワークの視点から二次局のように見える。

本明細書及び請求項において、要素に先行する単語"１つの"（"a"又は"an"）は、複数のこのような要素の存在を除外しない。更に、単語"有する"は、リストされた以外の要素又はステップの存在を除外しない。

請求項内の括弧内の参照符号の包含は、理解を助けることを意図され、限定することを意図されない。

本開示を読むことにより、他の修正例が、当業者に明らかである。このような修正例は、無線通信の分野及び送信器パワー制御の分野において既知であり、ここに既に記載されたフィーチャの代わりに又は加えて使用されることができる他のフィーチャを含むことができる。

Claims (14)

1. ネットワークにおいて通信する方法において、二次局が、レポートを有するデータパケットを一次局に送信するステップと、前記二次局が、前記パケットの送信前に、送信されるパケットのシーケンスにおける送信の順序の第１の指示を前記パケットが含むかどうかをモニタリングするステップと、送信されるパケットのシーケンスにおける送信の順序の第２の指示を追加するステップとを有する方法。
2. 前記送信の順序の前記第２の指示が、前記パケットのシーケンスにおける前記パケットの番号を示すシーケンス番号である、請求項１に記載の方法。
3. 前記送信の順序の前記第２の指示が、前記パケットが最初に送信される時間の指示である、請求項１に記載の方法。
4. 前記送信の順序の前記第２の指示を追加するステップが、前記パケットに含められるべき付加的なデータパケットを生成するステップを有し、前記データパケットが、少なくともシーケンス番号からなる、請求項２に記載の方法。
5. 前記データパケットが、前記シーケンス番号を有するヘッダからなるゼロペイロードデータパケットである、請求項４に記載の方法。
6. 前記送信の順序の指示を追加するステップが、前記レポートの処理と同じプロトコル層において実行される、請求項１ないし５のいずれか一項に記載の方法。
7. 前記同じプロトコル層が、媒体アクセス制御層である、請求項６に記載の方法。
8. 前記送信の順序の前記第２の指示を追加するステップが、たとえ指示が前記モニタリングするステップにおいて検出されたとしても実行される、請求項１ないし７のいずれか一項に記載の方法。
9. 前記送信の順序の前記第２の指示を追加するステップは、第１の指示が前記モニタリングするステップにおいて検出されなかった場合にのみ実行される、請求項１ないし６のいずれか一項に記載の方法。
10. 前記第１の指示が、レポートを有するパケットに対して付加的なパケットを含むパケットのシーケンスにおける前記パケットの番号を示すシーケンス番号である、請求項９に記載の方法。
11. 前記レポートが、前記二次局のバッファ内のデータの量を表すバッファステータスレポートである、請求項１ないし１０のいずれか一項に記載の方法。
12. 前記レポートが、前記チャネルの１以上のパラメータを表すチャネル品質情報である、請求項１ないし８のいずれか一項に記載の方法。
13. 二次局において、前記二次局が、前記二次局のバッファ内のデータの量を表すバッファステータスレポートを有するデータパケットを一次局に送信する送信器を有し、前記二次局が、送信されるパケットのシーケンスにおける送信の順序の第１の指示を前記パケットが含むかどうかをモニタリングするコントローラを有し、前記コントローラが、送信されるパケットのシーケンスにおける送信の順序の第２の指示を追加する、二次局。
14. 二次局と通信する一次局を有する通信のシステムにおいて、前記二次局が、前記二次局のバッファ内のデータの量を表すバッファステータスレポートを有するデータパケットを一次局に送信する送信器を有し、前記二次局が、送信されるパケットのシーケンスにおける送信の順序の第１の指示を前記パケットが含むかどうかをモニタリングするコントローラを有し、前記コントローラが、送信されるパケットのシーケンスにおける送信の順序の第２の指示を追加する、システム。

Images