| 【発明の名称】 |
サービス側高速ダウンリンクの共用チャネルセル変更の後に、ノードBにバッファされたデータを効率的に回復するシステム |
| 【発明者】 |
【氏名】チャオ イ−ジュ
【氏名】スティーブン イー.テリー
|
| 【要約】 |
【課題】サービス側HS−DSCHセル変更手順の間に、待ち時間を低減し、潜在的にはパケットデータユニット伝送の喪失を防止する。
【構成】ソースノードBによってバッファされたデータをより効率的に回復するために、RRC手順によって示されたセル変更の通知に引き続いて、可能な限り早急にPDUの状況レポートを生成するUE向けに、新しい基準が導入される。PDU状況は、HS−DSCH移送チャネルに関連付けられた各無線リンクコントローラについて示される可能性がある。さらに、インターノードBサービス側HS−DSCHセル変更に応じて、SRNCは、ターゲットセル内で新しいデータの伝送を開始する前に、PDU状況レポートを待つことができる。 |
【特許請求の範囲】
【請求項1】 高速ダウンリンク共用チャネル(HS−DSCH)のセル変更を容易にするユーザ機器(UE)であって、 前記HS−DSCHセル変更に関連付けられた無線リソース制御(RRC)要求メッセージを送信する無線信号を受信するよう構成された回路と、 高速MAC(MAC−hs)回路と、 前記MAC−hs回路に関連付けられた再順序付けバッファと、 前記無線信号を受信するよう構成された回路が前記無線信号を受信した後に、前記再順序付けバッファをフラッシュするよう構成された回路と、 前記MAC−hs回路により提供される再順序付けバッファがフラッシュされたことを示す情報に応答して、失われたHS−DSCHのパケットデータユニット(PDU)を示す状況レポートであって、各々が前記HS−DSCHにマッピングされた肯定確認モード(AM)無線リンク制御(RLC)インスタンスのそれぞれに対応する状況レポートを生成するよう構成された回路と を備えたことを特徴とするユーザ機器。 【請求項2】 前記状況レポートを生成するよう構成された回路を含むRLC回路をさらに備えたことを特徴とする請求項1に記載のユーザ機器。 【請求項3】 高速MAC(MAC−hs)手段と、該MAC−hs手段に関連付けられた再順序付けバッファとを備えたユーザ機器(UE)によって、高速ダウンリンク共用チャネル(HS−DSCH)のセル変更を容易にする方法であって、 前記UEによって、前記HS−DSCHセル変更に関連付けられた無線リソース制御(RRC)要求メッセージを送信する無線信号を受信するステップと、 前記無線信号を受信した後に、前記再順序付けバッファをフラッシュするステップと、 前記MAC−hs手段により、前記再順序付けバッファがフラッシュされたことを示す情報を提供するステップと、 前記情報に応答して、前記UEによって失われたHS−DSCHのパケットデータユニット(PDU)を示す状況レポートであって、各々が前記HS−DSCHにマッピングされた肯定確認モード(AM)無線リンク制御(RLC)インスタンスのそれぞれに対応する状況レポートを生成するステップと を備えたことを特徴とする方法。 【請求項4】 前記UEはRLC回路をさらに備え、 前記RLC回路によって、前記状況レポートを生成するステップをさらに備えたことを特徴とする請求項3に記載の方法。 【請求項5】 高速ダウンリンク共用チャネル(HS−DSCH)のセル変更を容易にするユーザ機器(UE)であって、 前記HS−DSCHセル変更に関連付けられた無線リソース制御(RRC)要求メッセージを送信する無線信号を受信するよう構成された回路と、 高速MAC(MAC−hs)回路と、 前記MAC−hs回路に関連付けられた再順序付けバッファと、 前記RRC要求メッセージに関連付けられた第1の情報に応答して、前記再順序付けバッファをフラッシュするよう構成された回路と、 前記MAC−hs回路により提供される受信したHS−DSCHのパケットデータユニット(PDU)を示す第2の情報に応答して、失われたHS−DSCHのPDUを示す状況レポートであって、前記HS−DSCHにマッピングされた肯定確認モード(AM)無線リンク制御(RLC)インスタンスのそれぞれに対応する状況レポートを生成するよう構成された回路と を備えたことを特徴とするユーザ機器。 【請求項6】 前記状況レポートを生成するよう構成された回路は、さらに失われたHS−DSCHのPDUを示す追加の状況レポートであって、前記HS−DSCHにマッピングされた他のAM RLCインスタンスに関連付けられた追加の状況レポートを提供するようさらに構成されたことを特徴とする請求項5に記載のユーザ機器。 【請求項7】 前記状況レポートを生成するよう構成された回路を含むRLC回路をさらに備えたことを特徴とする請求項6に記載のユーザ機器。 【請求項8】 高速MAC(MAC−hs)回路と、該MAC−hs回路に関連付けられた再順序付けバッファとを備えたユーザ機器(UE)によって、高速ダウンリンク共用チャネル(HS−DSCH)のセル変更を容易にする方法であって、 前記UEによって、前記HS−DSCHセル変更に関連付けられた無線リソース制御(RRC)要求メッセージを送信する無線信号を受信するステップと、 前記RRC要求メッセージに関連付けられた第1の情報に応答して、前記再順序付けバッファをフラッシュするステップと、 前記MAC−hs回路が提供する、受信したHS−DSCHのパケットデータユニット(PDU)を示す第2の情報に応答して、失われたHS−DSCHのPDUを示す状況レポートであって、前記HS−DSCHにマッピングされた肯定確認モード(AM)無線リンク制御(RLC)インスタンスのそれぞれに対応する状況レポートを生成するステップと を備えたことを特徴とする方法。 【請求項9】 さらに失われたHS−DSCHのPDUを示す追加の状況レポートであって、前記HS−DSCHにマッピングされた他のAM RLCインスタンスに関連付けられた追加の状況レポートを提供するステップをさらに備えたことを特徴とする請求項8に記載の方法。 【請求項10】 前記UEは、独立して前記状況レポートを生成することを特徴とする請求項8に記載の方法。 【請求項11】 前記UEはRLC回路をさらに備え、 前記RLC回路によって、前記状況レポートを生成するステップをさらに備えたことを特徴とする請求項9に記載の方法。
|
【発明の詳細な説明】【技術分野】 【0001】 本発明は、ワイヤレス通信の分野に関する。より詳細には、本発明は、中間点からデータを配信するワイヤレスシステムにおいて、バッファされたデータをハンドオーバの後に効率的に回復することに関する。1つまたは複数のノードBに結合された遠隔ネットワークコントローラ(RNC)を有し、ノードBは、複数のユーザ機器(UE)にワイヤレスで結合される第3世代(3G)システムであって、適応変調および符号化(AMC)技法と、ハイブリッド自動再送要求(H−ARQ)技法とを使用する第3世代システムは、この種のシステムの一例にすぎない。 【背景技術】 【0002】 3G地上無線接続網(Universal Terrestrial Radio Access Network:UTRAN)は、いくつかのRNCを備え、各RNCはいくつかのノードBに結合することができる。ノードBは、各々が1つまたは複数のセルについてトラフィックを管理する1つまたは複数の基地局を備えるエンティティである。 【0003】 一般に、3GのFDDシステムとTDDシステムは、RNCを使用し、UEに対するデータ伝送をバッファしてスケジューリングを行う。しかし、3Gセルラシステムの高速チャネルの場合、データは、ノードBにより伝送するためバッファおよびスケジューリングが行われる。たとえば、これらの高速チャネルの1つは、高速ダウンリンクの共用チャネル(HS−DSCH)である。データはノードBによって配信されるため、ノードB内で伝送用にデータをバッファすることが必要である。このアーキテクチャを採用する結果、RNCは、パケットデータユニット(PDU)の、ノードBによって制御された最新の伝送状況を有していない。したがって、セル間でハンドオーバする際、データ伝送のスケジューリングをセル変更にあわせることが必要となる。そうでないと、セル変更の後に伝送されたデータの喪失または重複を回避するため、データ伝送を再同期することが必要になってします。3Gネットワークでは、セル間のハンドオーバは、RNCによって制御される。そのUEが存在するセルを制御するRNCが変わる可能性があるため、ハンドオーバの結果としてデータの損失、または重複のおそれがある。この問題は、各RNCに関連付けられたノードBのアーキテクチャによっては悪化することがある。UEのセルハンドオーバの結果RNCが変更されるより、移動UEがノードBの変更を必要とする可能性の方がはるかに高い。 【0004】 HS−DSCHは、データの高速伝送を可能にするためにAMCを、またデータの送達に成功する可能性を高めるためにH−ARQを使用する。サービス側HS−DSCHセルは、サービス側HS−DSCH無線リンクの送受信を実行しているUTRANアクセスポイントに関連付けられたセルをUEが変更しなければならないとき変更される。サービス側HS−DSCHセルの変更は、物理チャネル条件の改善、および/または物理的容量の改善が、代替のセル内で実現されたとき呼び出される。UTRAN内のRNC部で終端する3Gネットワーク内の他のチャネルと異なり、HS−DSCHはノードB部で終端する。 【0005】 HS−DSCHセル変更には、2つのタイプがある。イントラノードB(Intra−Node B)サービス側HS−DSCHセル変更は、UEが、同じノードBに関連付けられた2つのセル間で変わるときである。インターノードB(Inter−Node B)サービス側HS−DSCHセル変更は、UEが、異なるノードBに関連付けられた2つのセル間で変わるときである。インターノードBセル変更では、サービス側HS−DSCHセル変更の前のノードBがソースノードBと呼ばれ、サービス側HS−DSCHセル変更の後のノードBがターゲットノードBと呼ばれる。 【0006】 RNCにもUEにもピア無線リンク制御(RLC)エンティティがあり、データの伝送用に自動再送要求(ARQ)機能を提供する。送信側RLCエンティティは、PDUヘッダ内でシーケンス番号(SN)を示し、シーケンス番号は、伝送時にPDUを逸しないように受信側RLCエンティティによって使用される。PDUが乱れた順序で送達されたことによって伝送中に逸したPDUがあると認識された場合、受信側RLCエンティティは、状況レポートPDUを送信し、送信側RLCエンティティに逸したPDUを通知する。状況レポートPDUは、データ伝送の状況を述べるために使用される。状況レポートPDUは、逸した、または受信されたPDUのSNを識別する。PDUを逸した場合、送信側RLCエンティティは、逸したPDUの複製を再伝送することになる。 【0007】 送信側RLCエンティティが、受信側RLCエンティティに状況レポートPDUを求めてポーリングし、あるいは受信側RLCエンティティが状況レポートを定期的に生成することも可能である。ポーリング機能は、送信側RLCエンティティがPDU伝送の状況を要求するための機構を提供する。 【0008】 ノードBのH−ARQ機能もまた、失敗した伝送の再伝送を可能にする。H−ARQは、いくつかの失敗した伝送を取り除き、およびデータの送達に成功する確率を高めるように機能するが、最終的に送達の成功を確保するのは、RLCプロトコル層である。 【0009】 伝播条件の動的な変化により、HS−DSCHセル変更は、サービス品質を維持するため迅速に実行しなければならない。サービス側HS−DSCHセル変更中、ソースノードB内に現在格納されているPDUのすべてが成功裏に伝送される前に、UEがソースセル内で送受信を停止する可能性がある。ソースノードBがデータのスケジューリングおよびバッファを行うため、およびデータ転送速度が非常に速いため(たとえば、10Mb/秒以上)、UEが(特にインターノードBハンドオーバのために)サービス側HS−DSCHセル変更を実行するとき、ソースノードB内にバッファされているかなりの量のデータが失われる可能性がある。このようにデータが喪失する理由の1つは、ソースノードB部でバッファされたデータをターゲットノードBに転送するための機構が、UTRANアーキテクチャ内に存在しないことである。HS−DSCHセル変更を行う際、RNCは、ノードBデータ伝送スケジューリングについて、およびその伝送がUEによって肯定確認されるのに成功したかどうか通知されないため、RNCは、あったとしてもどれだけのデータが失われたかについて情報を有していない。したがって、データを喪失することなしに伝送を維持するため、サービス側HS−DSCHセル変更の際、データがソースノードB内にバッファされていると、RNC RLCは、このデータを回復しなければならない。 【0010】 現在、従来技術のシステムがソースノードB部でバッファされたデータの回復を処理する2つの望ましい方法がある。HS−DSCHセル変更の後に、1)RNCは、UEに状況PDUを明示的に要求することができ、あるいは2)RNCは、ソースセル内で停止したところで単に伝送を開始することができ、UEが認識している順序の乱れた送達によって状況PDUが生成されることになる。 【0011】 RNCがUEをポーリングすることによって、状況PDUを明示的に要求する第1の場合には、RNCはまず、新しいセル内で物理チャネルが確立されるまで待たなければならない。次いで、状況PDU要求が送信され、UEによって受信され、処理される。UEは、状況PDUを生成し、それをRNCに返し、RNCは、状況PDUを処理し、どのPDUが再伝送を必要としているかを判定する。 【0012】 RNCが、ソースセル内で停止したところから単にPDUを伝送するのを開始する第2の場合、UEは、データが乱れた順序で送達されたことを認識し、RNCに返す状況PDUを生成する。RNCは、状況PDUを処理し、どのPDUが再伝送を必要としているか学習する。 【発明の開示】 【発明が解決しようとする課題】 【0013】 これら2つの場合のどちらにおいても、ソースノードB内にバッファされているデータを回復することが必要とされる場合は状況PDUが処理されるが、UEによって再伝送データが適切に受信されるのは、かなり遅れることになる。これは、UEによって状況PDUが生成されるのが、また、RNC内で状況PDUが受信されるのが遅れるためである。 【0014】 伝送がRLC肯定確認モードで実行されている場合、データの逐次送達が行われるまで、データは、より高い層に渡されない。したがって、UEは、逸したPDUを再伝送することができるまで、順序の乱れたデータをバッファすることを求められることになる。これは、伝送の遅延を引き起こすだけでなく、ソースノードB内に格納されたデータの送達に成功するまでデータをバッファするのに十分なメモリをUEが有していることが必要である。そうでない場合、有効なデータ伝送速度が低下し、それによりサービス品質に影響を及ぼすこととなる。メモリは非常にコストがかかるため、これは望ましくない設計制約である。 【0015】 したがって、ターゲットノードBに転送する前に、ソースノードB内にバッファされているデータを回復する従来技術の方法は、非常に望ましくない結果をもたらす。ユーザのサービス品質要件を適切に維持するために、より少ない遅延で、より効率的にソースノードB内にバッファされているデータを回復することができるシステムおよび方法を有することが望ましい。 【課題を解決するための手段】 【0016】 本発明は、サービス側HS−DSCHセル変更手順の間に待ち時間を低減し、潜在的にはPDU伝送の喪失を防止するため、一連の動作を実施する方法およびシステムである。RLC PDUの状況レポートをUEで生成するため、新しい基準が導入される。ソースノードBによってバッファされたデータをより効率的に回復するために、UEは、RRCハンドオーバ手順によって示されたHS−DSCHセル変更の通知に引き続いて、可能な限り早急にPDUの状況レポートを独自に生成する。HS−DSCH移送チャネルに関連付けられた各肯定確認モード(AM)RLCインスタンスについてPDU状況を示すこともできる。 【発明を実施するための最良の形態】 【0017】 本発明の好ましい実施形態について図面を参照して説明するが、全体を通して同じ数字は同じ要素を表すものとする。 【0018】 RNCがPDUの状況を取得して、ソースノードB内にバッファされているデータを回復するための待ち時間を低減するため、サービス側HS−DSCHセル変更の後に、UEは、RRC手順によって示されたHS−DSCHセル変更の通知に引き続いて、PDUの状況をRNCに自動的に送信する。HS−DSCH移送チャネルに関連付けられた各AM RLCインスタンスにPDU状況の生成を適用することができる。 【0019】 図1のフローチャートを参照すると、本発明のノードBによってバッファされたデータを効率的に回復する方法10が示されている。RNCは、サービス側HS−DSCHセル変更の必要性を認識する(ステップ12)。次いで、サービス側HS−DSCHセル変更についてノードBに通知する(ステップ14)。RRC要求メッセージを介して示されるサービス側HS−DSCHセル変更についてUEに通知する(ステップ16)。ステップ14の前にステップ16を呼び出すことも可能である。 【0020】 ステップ18でRRC要求メッセージがUEによって受信された後に、ソースノードB内にバッファされているデータを回復する際の遅延を低減するため、UEは、RRC手順によって示されたHS−DSCHセル変更の通知に引き続いて、可能な限り早急にRLC PDU状況を示す状況レポートを独自に生成する(ステップ20)。UEは、状況PDUを生成するためのいずれの従来技術のトリガ(たとえば、状況PDUを生成するためのRNCによる要求、または、順序の乱れたデータの送達のUEによる検出)も待たない。 【0021】 UEにおいては、サービス側HS−DSCHセル変更の後にPDU状況レポートの生成のトリガを引くためにUEが実装することができる多数の様々な代替方法がある。しかし、本明細書では、そのうちいくつかの例を提示する。第1の選択肢として、MAC−hsが、その再順序付けバッファがフラッシュされた後にRLCに通知するのが望ましい。第2の選択肢は、RRCが、サービス側HS−DSCHセル変更を示すレベル3(L3)RRC手順についてRLCに通知することである。第3に、物理層が、ターゲットセル内でのHS−DSCH制御チャネルの受信についてRLCに通知することができ、あるいは物理層が、HS−DSCH制御のターゲットセルへの切換えの際にRLCに通知することができる。UEからRNCに送信すべきRLC PDU状況メッセージのトリガを引くための他の方法があり得ることを、当業者なら確実に理解できるであろう。こ手続きの結果として、PDU状況は、あまり遅延せずに生成され、またRNCに送信され(ステップ22)、これにより、ソースノードBによってバッファされたデータがより効率的に回復される。 【0022】 ステップ22においては、UEがRNCにPDUの状況レポートを送信するためのいくつかの代替の形態がある。状況PDUを送信するこれらの方法は、どのように状況PDUをUEからRNCに示すことができるかという例であり、新しい基準に応じて状況PDUを生成することに関する本発明の最重要事項ではない。UEは、HS−DSCH移送チャネルにマッピングされた各AM RLCインスタンスについてRLC状況レポートを生成するのが望ましい。 【0023】 第2の代替の形態において、UEは、状況レポートが得られたら直ちに、UEからRNCへの第1の既存のアップリンクメッセージを介してPDU状況レポートを送信する。イントラノードBサービス側セル変更の場合(また、HS−DSCH移送チャネルおよび無線ベアラパラメータが変更されていないと仮定して)、メッセージは、DCCH上で「PHYSICAL CHANNEL RECONFIGURATION COMPLETE(物理チャネル再構成完了)」である。HS−DSCH移送チャネルおよび無線ベアラパラメータが変更された場合、および/またはインターノードBサービス側セル変更の場合、メッセージは、DCCH上で「TRANPSORT CHANNEL RECONFIGURATION COMPLETE(移送チャネル再構成完了)」である。PDU状況は、任意のRRCシグナリングメッセージ内で識別することができる。次いで、RNC RRCエンティティは、ターゲットノードBに対して伝送を再開するために、RLCにPDUの状況を通知する。 【0024】 第3の代替形態において、UEは、UEからRNCへのDCCH上の新しいL3シグナリングメッセージ上で状況レポートを送信する。この新しいメッセージは、UEの無線リソース制御(RRC)層からRNCのRRC層に送信される。次いで、RNCは、ターゲットノードBに対して伝送を再開するために、RLC層にPDUの状況を通知する。この場合、図1に示されているPDU状況メッセージは、「RRC完了(RRC Complete)」と「RLC状況(RLC Status)」という2つの別個のメッセージを含むことができる。 【0025】 PDUの状況レポートの特定のフォーマットは変わる可能性があることに留意されたい。たとえば、PDUの状況レポートのフォーマットには、1)最後の成功裏に逐次送達されたPDUのシーケンス番号(SN)、2)成功裏に受信されたPDUの最大SN、3)成功裏に受信されたPDUの最大SNまで、受信するのに成功しなかったPDU(すなわち、逸したPDU)のSN、または4)受信するのに成功したPDUのSNのリストが含まれる。 【0026】 RNCがPDU状況を送信するメッセージを受信した後に、PDU状況メッセージは、逸したPDUを決定するため、RNC RLCによって処理される(ステップ24)。セル変更の結果、失われたデータは、今現在、RNCによって認識され、UEに再伝送することができる(ステップ26)。メッセージは、多数の代替の形態のものとすることができ、必ずしもPDU状況レポートを送信する形態だけに限定されないことに留意されたい。 【0027】 また、本発明のこの実施形態において、RNCは、ステップ16と24の間で、ターゲットセル内でUEに伝送するために引き続きデータを転送することができることに留意されたい。ソースノードBによってバッファされたデータすべてが成功裏に送信された場合、データは順序が乱れることになるため、UEは、より高い層に対する逐次送達を維持するために、データをバッファせざるを得なくなる。これは、UEが、順序の乱れたPDUを格納するために十分なメモリを有することを必要とする。連続データの喪失の後に、失われた連続データが成功裏に伝送されるまで、伝送がUEメモリ容量に制限される。 【0028】 図2のフローチャートを参照すると、本発明の一代替実施形態のノードBによってバッファされたデータを効率的に回復する方法40が示されている。この方法40は、図1に示されている方法10と同様であり、図1の場合と同じ符号が付けられている図2の諸ステップは、同一である。しかし、本発明の 本実施形態によれば、方法40は、ステップ24でPUD状況メッセージが処理されるまで、UEに対するダウンリンクHS−DSCH伝送すべてを中止する新しいステップ17を含む。本実施形態は、ソースノードBによってバッファされたデータを再伝送するための遅延を最小限に抑え、UE部でバッファしなければならないデータ量を制限する。 【0029】 遅延を最小限に抑えることに関連して、ノードBはRLC伝送シーケンス番号を知らず、ノードB内の伝送スケジューリングは、FIFOベースである。したがって、PDU状況が処理される前に、データがターゲットセル内でRNCによって転送される場合、データが先に送信されることになる。ノードBにおけるこのデータキューイングは、ソースノードBによってバッファされたデータの再伝送をさらに遅らせる可能性がある。 【0030】 本発明は、インターノードBセル変更とイントラノードBセル変更のHS−DSCHセル変更に共に適用することができる。イントラノードBセル変更の場合には、内部設計問題により、ノードBが、バッファされているHS−DSCHデータをターゲットセルに再指定することができない場合があり得るため、RNCは、どちらの場合についても、PDU状況の生成の必要性を示すことができる。また、UEは、インターノードBセル変更とイントラノードBセル変更を区別することができない可能性もあり、これもまた、インターとイントラのどちらの場合についても、PDU状況を生成することになるであろう。そのような形で送信される状況PDUは、インターノードBセル変更、またはバッファされているデータをターゲットセルに切り換えることができないイントラノードBの場合において有用となる。 【0031】 以上、本発明について詳しく述べたが、本発明はそれに限定されないこと、また、特許請求の範囲によって規定される本発明の精神および範囲から逸脱することなしに、様々な変更を加えることができることを理解されたい。 【図面の簡単な説明】 【0032】 【図1】HS−DSCHセル変更の後に、ノードBによってバッファされたデータを効率的に回復するための、本発明による効率的な手順のフローチャートである。 【図2】ターゲットセル内で新しいデータの伝送を開始する前に、RNCが状況PDUを待つ代替方法のフローチャートである。
|
| 【出願人】 |
【識別番号】596008622 【氏名又は名称】インターデイジタル テクノロジー コーポレーション
|
| 【出願日】 |
平成19年10月18日(2007.10.18) |
| 【代理人】 |
【識別番号】100077481 【弁理士】 【氏名又は名称】谷 義一
【識別番号】100088915 【弁理士】 【氏名又は名称】阿部 和夫
|
| 【公開番号】 |
特開2008−48456(P2008−48456A) |
| 【公開日】 |
平成20年2月28日(2008.2.28) |
| 【出願番号】 |
特願2007−271637(P2007−271637) |
|