図面 (/)

技術 HARQ送信失敗時に再送信するためにパケットデータを再断片化する方法および装置

出願人 ブラックベリーリミテッド
発明者 鈴木卓ジェームスアールウォマックゴードンピーターヤング
出願日 2007年10月26日 (13年6ヶ月経過) 出願番号 2007-279642
公開日 2008年5月22日 (12年11ヶ月経過) 公開番号 2008-118640
状態 特許登録済
技術分野 エラーの検出、防止 通信制御 移動無線通信システム
主要キーワード コントリビューション カバー範囲外 パラメータ構成 データ送信プロトコル ワークアイテム ステータス報告 制御平面 SDU
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2008年5月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (9)

課題

送信機から受信機へのハイブリッド自動再送要求HARQ送信失敗時にパケットデータを再送信する方法を提供すること。

解決手段

送信機から受信機へのHARQ送信失敗時にパケットデータを再送信する方法であって、該方法は、HARQ送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態劣化が表示されているかどうか、または閾値未満であるかどうかをチェックするステップと、イエスの場合、無線リンク制御サービスデータユニット「RLC−SDU」または無線リンク制御プロトコルデータユニット「RLC−PDU」のデータをより小さなPDUデータサイズに再断片化するステップと、該再断片化されたRLC−PDUデータを送信するステップと、イエスでない場合、以前のRLC−PDUデータを送信するステップとを包含する、方法。

概要

背景

MTSにおいて、集合的にHSPAとして公知の高速ダウンロードパケットアクセス(HSDPA)および拡張専用アップリンクトランスポートチャネル(E−DCH)は、MAC層内のHARQスキームを使用して、ユーザ装備(UE)とノードBとして公知の基地局との間でのデータ送信の効率および信頼性を強化する。これは、例えば、3GPPのTS25.321第6.9.0版の仕様第11.6節および第11.8節で定義されている。HSDPAにおいて、受信機側(UE)は、パイロットチャネル信号強度の短期測定に基づく5ビットチャネル品質インジケータ(CQI)を用いて、送信機(ノードB)にチャネル品質を表示する。これらの測定は、約2msを要し得る。

報告されたCQIに基づいて、ノードBは、UEへの次の送信のために、トランスポートブロックサイズと、変調および符号化スキーム(MCS)とを選択する。これは、トランスポートブロックエラーの確率が10%を超えるべきではないからである。

データは、高速媒体アクセス制御プロトコルデータユニット(MAC−hsPDU)の中で送信される。UEが、MAC−hs PDUを受信するとき、UEは、巡回冗長チェックCRC)を計算して、正しい受信であることを決定する。受信が成功である場合、UEは、ノードBにACKを送信する。成功でない場合、NACKが送信される。ノードBがNACKを受信する場合、ノードBは、再度MAC−hs PDUをチェイス合成のために、また再送信するか、あるいは再送信の回数が、システムオペレータによって設定された特定の最大回数内である場合、インクリメンタル冗長性に対するシステマチックシンボルおよび/またはパリティシンボルを再送信する。インクリメンタルな冗長またはチェイス合成スキームは、3GPPのTS25.212の第6.9.0版に明記されているように、再送信に使用される。

HARQ再送信を最大回数失敗するとき、本明細書では、これをHARQ再送信失敗と称し、MAC−hsPDUの再送信は、失敗であると考えられる。無線リンク制御(RLC)の動作の肯定応答モードは、3GPPのTS25.322の第6.8.0版第9.7節および第11.3節で定義されているように、受信機側によって受信されていないと表示されているMAC−hs PDUに元々多重化されたRLC−PDUを再送信することによって、HARQ送信エラーを回復する。この機能は、自動再送要求すなわちARQと、一般に称される。これは、受信機が受信したか、受信していないかというPDUのステータスを受信機に対してポーリングする送信機に基づき、受信機は、この情報を処理するために、送信機に送信する。この双方向信号伝達は、送信機と受信機との間で不正確に受信されるデータの送信時間に、追加の待ち時間の幾分かを明らかに追加する。

このRLCレベルの再送信待ち時間を減らすために、RLCは、HARQ再送信失敗を通知され得、RLCサービスデータユニット(RLC−SDU)またはRLC−SDUの一部(RLC−PDU)は、受信側からのステータス報告制御メッセージを待ってではなく、むしろ、この通知を受けて再送信され得る。このタイプの強化の一例は、ワークアイテム「Long−term evolution of UMTSTerrestrial Radio Access(UTRA) and Universal Terrestrial Radio Access Network(UTRAN)」(LTE)に対して、NTT DoCoMoからのRAN2ミーティング番号55コントリビューションR2−062906に示されている。LTEに関する3GPP研究の結果は、3GPPのTR25.912の第7.0.0版の仕様に示されている。しかしながら、第二の試みまたは引き続く試みは、シャドーイングまたは他の要因のために、比較的長く続く悪い無線状態によって、再び失敗し得る。特に、再送信されるPLC−PDUのサイズは、以前の送信と同じである。UMTSにおいて、RLC−PDUのサイズは、RLCのRRC構成によって決定されるようなRLC−SDUの断片化の際に決定される。

概要

送信機から受信機へのハイブリッド自動再送要求「HARQ」送信失敗時にパケットデータを再送信する方法を提供すること。送信機から受信機へのHARQ送信失敗時にパケットデータを再送信する方法であって、該方法は、HARQ送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態劣化が表示されているかどうか、または閾値未満であるかどうかをチェックするステップと、イエスの場合、無線リンク制御サービスデータユニット「RLC−SDU」または無線リンク制御プロトコルデータユニット「RLC−PDU」のデータをより小さなPDUデータサイズに再断片化するステップと、該再断片化されたRLC−PDUデータを送信するステップと、イエスでない場合、以前のRLC−PDUデータを送信するステップとを包含する、方法。

目的

本出願は、計算デバイスまたはシステム、例えば、該デバイスまたはシステムにおいて、本出願の上記方法を実行する送信機によって実行可能なプログラムコードを備えるコンピュータ読み取り可能な媒体をさらに提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

送信機から受信機へのハイブリッド自動再送要求HARQ送信失敗時にパケットデータを再送信する方法であって、該方法は、HARQ送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態劣化が表示されているかどうか、または閾値未満であるかどうかをチェックするステップと、イエスの場合、無線リンク制御サービスデータユニット「RLC−SDU」または無線リンク制御プロトコルデータユニット「RLC−PDU」のデータをより小さなPDUデータサイズに再断片化するステップと、該再断片化されたRLC−PDUデータを送信するステップと、イエスでない場合、以前のRLC−PDUデータを送信するステップとを包含する、方法。

請求項2

前記チェックするステップの前に、ハンドオーバが表示されているかどうかを決定するステップと、イエスの場合、前記再送信処理を終了するステップとをさらに包含する、請求項1に記載の方法。

請求項3

前記ハンドオーバは、無線リソース制御プロトコルまたはレイヤレベル信号伝達によって表示される、請求項2に記載の方法。

請求項4

無線リソース制御プロトコルは、測定報告またはレイヤ2レベル信号伝達が、受信または生成されるときに、ハンドオーバが期待されるかどうかを表示する、請求項3に記載の方法。

請求項5

前記チェックするステップの前に、カバー範囲外の状態が表示されているかどうかを決定するステップと、該カバー範囲外の状態が表示されている場合、前記再送信処理を終了するステップとをさらに包含する、請求項1〜請求項4のいずれか1項に記載の方法。

請求項6

前記カバー範囲外の状態は、受信した最終チャネル品質インジケータ「CQI」時間が、閾値より大きいかどうか、もしくは前記受信機からの肯定応答ACK」または否定応答「NACK」の受信に連続して失敗した回数が、構成可能な閾値を超えるかどうかをチェックすること、または物理層が前記受信機はカバー範囲外であると決定する場合、該カバー範囲外の状態が、決定されることによって決定される、請求項5に記載の方法。

請求項7

前記方法は、送信機の無線リンク制御「RLC」レベルで実行される、請求項1〜請求項5のいずれか1項に記載の方法。

請求項8

断片化は、メディアアクセス制御「MAC」層で実行される、請求項1〜請求項5のいずれか1項に記載の方法。

請求項9

断片サイズは、MAC層によって、RLC層報告される、請求項8に記載の方法。

請求項10

カバー範囲外の状態は、MAC層からRLC層に報告される、請求項8に記載の方法。

請求項11

前記再断片化されたデータは、RLC層からMAC層に渡される、請求項1〜請求項5のいずれか1項に記載の方法。

請求項12

勾配チャネル品質インジケータが、閾値未満であるかどうかを決定することによって、前記HARQは、チャネル状態の劣化をチェックする、請求項1に記載の方法。

請求項13

前記勾配チャネル品質インジケータが、閾値より大きいか、あるいは閾値未満でない場合、前記方法は、最終チャネル品質インジケータに対する符号化速度、または直近受信したCQIの平均、および前記受信機に対する無線リソース利用可能性が、閾値より大きいかどうかをチェックするステップと、イエスの場合、新たな断片サイズを有するHARQ再送信失敗を信号伝達するステップと、ノーの場合、HARQ再送信失敗を信号伝達するステップとをさらに包含する、請求項12に記載の方法。

請求項14

再断片化層を備え、無線チャネル状態に従って、データをより適切なサイズに再断片化するように適合されたモバイルネットワークにおける送信機であって、該再断片化層は、ハイブリッド自動再送要求「HARQ」送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態の劣化が表示されているかどうか、または閾値未満であるかどうかをチェックして、イエスの場合、RLC−SDUまたはRLC−PDUのデータをより小さなPDUデータサイズに再断片化し、該再断片化されたRLC−PDUデータを送信すること、イエスでない場合、以前のRLC−PDUデータを送信することを行うように適合されている、送信機。

請求項15

前記再断片化層は、RLC層またはMAC層を備える、請求項14に記載の送信機。

請求項16

前記際断片化層は、ハンドオーバが表示されているかどうかを決定して、イエスの場合、前記再送信処理を終了するように適合されている、請求項14に記載の送信機。

請求項17

無線リソース制御プロトコルまたはレイヤ2レベル信号伝達が、前記ハンドオーバを表示するように適合されている、請求項16に記載の送信機。

請求項18

無線リソース制御プロトコルは、測定報告またはレイヤ2レベル信号伝達が、受信または生成されるときに、ハンドオーバが期待されるかどうかを表示するように適合されている、請求項17に記載の送信機。

請求項19

カバー範囲外の状態が表示されているかどうかを決定して、イエスの場合、前記再送信を終了する、請求項14〜請求項18のいずれか1項に記載の送信機。

請求項20

カバー範囲外の状態は、受信した最終チャネル品質インジケータ「CQI」時間が、閾値より大きいかどうかをチェックすること、受信機または送信機からの肯定応答「ACK」または否定応答「NACK」の受信に連続して失敗した回数が、所定の閾値を超える場合、あるいは勾配チャネル品質インジケータが、閾値未満である場合を決定することのいずれかによって決定するようにさらに適合されている、請求項19に記載の送信機。

請求項21

前記勾配チャネル品質インジケータが、閾値より大きいか、あるいは閾値未満でない場合、前記送信機は、最終チャネル品質インジケータに対する符号化速度が、閾値より大きいかどうかをチェックして、イエスの場合、新たな断片サイズを有するHARQ再送信失敗を信号伝達することと、ノーの場合、HARQ再送信失敗を信号伝達することとを行うように適合されている、請求項20に記載の送信機。

請求項22

請求項14〜請求項21のいずれか1項に記載の送信機と、該送信機からのパケットデータ送信受信可能な複数のユーザ装備「UE」とを備える、通信ネットワーク

請求項23

請求項1〜請求項13のいずれか1項に記載の方法を実行する計算デバイスまたはシステムにおいて実行可能なプログラムコードを備える、コンピュータ読み取り可能な媒体

技術分野

0001

本開示は、一般的に、メディアアクセス制御(MAC)層データ送信、無線リンク制御(RLC)層、および無線リソース制御(RRC)層で使用されるハイブリッド自動再送要求HARQスキームに関し、特に、不成功に終わったMACプロトコルデータユニットを受信すると、データを再送信することに対するこれらの層の相互作用に関する。

背景技術

0002

MTSにおいて、集合的にHSPAとして公知の高速ダウンロードパケットアクセス(HSDPA)および拡張専用アップリンクトランスポートチャネル(E−DCH)は、MAC層内のHARQスキームを使用して、ユーザ装備(UE)とノードBとして公知の基地局との間でのデータ送信の効率および信頼性を強化する。これは、例えば、3GPPのTS25.321第6.9.0版の仕様第11.6節および第11.8節で定義されている。HSDPAにおいて、受信機側(UE)は、パイロットチャネル信号強度の短期測定に基づく5ビットチャネル品質インジケータ(CQI)を用いて、送信機(ノードB)にチャネル品質を表示する。これらの測定は、約2msを要し得る。

0003

報告されたCQIに基づいて、ノードBは、UEへの次の送信のために、トランスポートブロックサイズと、変調および符号化スキーム(MCS)とを選択する。これは、トランスポートブロックエラーの確率が10%を超えるべきではないからである。

0004

データは、高速媒体アクセス制御プロトコルデータユニット(MAC−hsPDU)の中で送信される。UEが、MAC−hs PDUを受信するとき、UEは、巡回冗長チェックCRC)を計算して、正しい受信であることを決定する。受信が成功である場合、UEは、ノードBにACKを送信する。成功でない場合、NACKが送信される。ノードBがNACKを受信する場合、ノードBは、再度MAC−hs PDUをチェイス合成のために、また再送信するか、あるいは再送信の回数が、システムオペレータによって設定された特定の最大回数内である場合、インクリメンタル冗長性に対するシステマチックシンボルおよび/またはパリティシンボルを再送信する。インクリメンタルな冗長またはチェイス合成スキームは、3GPPのTS25.212の第6.9.0版に明記されているように、再送信に使用される。

0005

HARQ再送信を最大回数失敗するとき、本明細書では、これをHARQ再送信失敗と称し、MAC−hsPDUの再送信は、失敗であると考えられる。無線リンク制御(RLC)の動作の肯定応答モードは、3GPPのTS25.322の第6.8.0版第9.7節および第11.3節で定義されているように、受信機側によって受信されていないと表示されているMAC−hs PDUに元々多重化されたRLC−PDUを再送信することによって、HARQ送信エラーを回復する。この機能は、自動再送要求すなわちARQと、一般に称される。これは、受信機が受信したか、受信していないかというPDUのステータスを受信機に対してポーリングする送信機に基づき、受信機は、この情報を処理するために、送信機に送信する。この双方向信号伝達は、送信機と受信機との間で不正確に受信されるデータの送信時間に、追加の待ち時間の幾分かを明らかに追加する。

0006

このRLCレベルの再送信待ち時間を減らすために、RLCは、HARQ再送信失敗を通知され得、RLCサービスデータユニット(RLC−SDU)またはRLC−SDUの一部(RLC−PDU)は、受信側からのステータス報告制御メッセージを待ってではなく、むしろ、この通知を受けて再送信され得る。このタイプの強化の一例は、ワークアイテム「Long−term evolution of UMTSTerrestrial Radio Access(UTRA) and Universal Terrestrial Radio Access Network(UTRAN)」(LTE)に対して、NTT DoCoMoからのRAN2ミーティング番号55コントリビューションR2−062906に示されている。LTEに関する3GPP研究の結果は、3GPPのTR25.912の第7.0.0版の仕様に示されている。しかしながら、第二の試みまたは引き続く試みは、シャドーイングまたは他の要因のために、比較的長く続く悪い無線状態によって、再び失敗し得る。特に、再送信されるPLC−PDUのサイズは、以前の送信と同じである。UMTSにおいて、RLC−PDUのサイズは、RLCのRRC構成によって決定されるようなRLC−SDUの断片化の際に決定される。

発明が解決しようとする課題

0007

概要
本開示は、とりわけ、シャドーイングのような無線チャネル状態に従って、データをより適切なサイズに再断片化することによって、再送信待ち時間をさらに改善するために、上述の問題に対処し得る。さらに、本開示は、データの再断片化が生じ得るべきときに、対処し得る。

課題を解決するための手段

0008

本出願は、ハイブリッド自動再送要求(HARQ)送信失敗時にパケットデータを再送信する方法を提供し得、該方法は、HARQ送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態劣化が表示されているかどうか、または閾値未満であるどうかをチェックするステップと、イエスの場合、RLC−SDUまたはRLC−PDUのデータをより小さなPDUデータサイズに再断片化するステップと、該再断片化されたRLC−PDUデータを送信するステップと、イエスでない場合、以前のRLC−PDUデータを送信するステップとを包含する。

0009

本出願は、再断片化層を備え、無線チャネル状態に従って、データをより適切なサイズに再断片化するように適合されたモバイルネットワークにおける送信機をさらに提供し得、該再断片化層は、ハイブリッド自動再送要求(HARQ)送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態の劣化が表示されているかどうか、または閾値未満であるかどうかをチェックして、イエスの場合、RLC−SDUまたはRLC−PDUのデータをより小さなPDUデータサイズに再断片化し、該再断片化されたRLC−PDUデータを送信すること、イエスでない場合、以前のRLC−PDUデータを送信することを行うように適合されている。本出願は、計算デバイスまたはシステム、例えば、該デバイスまたはシステムにおいて、本出願の上記方法を実行する送信機によって実行可能なプログラムコードを備えるコンピュータ読み取り可能な媒体をさらに提供する。さらに、本出願は、通信ネットワークを提供し、該通信ネットワークは、該送信機と、該送信機からのパケットデータ送信受信可能な複数のユーザ装備「UE」とを備える。

0010

本発明は、さらに、以下の手段を提供する。

0011

項目1)
送信機から受信機へのハイブリッド自動再送要求「HARQ」送信失敗時にパケットデータを再送信する方法であって、該方法は、
HARQ送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態の劣化が表示されているかどうか、または閾値未満であるかどうかをチェックするステップと、
イエスの場合、
無線リンク制御サービスデータユニット「RLC−SDU」または無線リンク制御プロトコルデータユニット「RLC−PDU」のデータをより小さなPDUデータサイズに再断片化するステップと、
該再断片化されたRLC−PDUデータを送信するステップと、
イエスでない場合、
以前のRLC−PDUデータを送信するステップと
を包含する、方法。

0012

(項目2)
上記チェックするステップの前に、ハンドオーバが表示されているかどうかを決定するステップと、イエスの場合、上記再送信処理を終了するステップとをさらに包含する、項目1に記載の方法。

0013

(項目3)
上記ハンドオーバは、無線リソース制御プロトコルまたはレイヤレベル信号伝達によって表示される、項目2に記載の方法。

0014

(項目4)
無線リソース制御プロトコルは、測定報告またはレイヤ2レベル信号伝達が、受信または生成されるときに、ハンドオーバが期待されるかどうかを表示する、項目3に記載の方法。

0015

(項目5)
上記チェックするステップの前に、カバー範囲外の状態が表示されているかどうかを決定するステップと、該カバー範囲外の状態が表示されている場合、上記再送信処理を終了するステップとをさらに包含する、項目1〜項目4のいずれか1項に記載の方法。

0016

(項目6)
上記カバー範囲外の状態は、
受信した最終チャネル品質インジケータ「CQI」時間が、閾値より大きいかどうか、もしくは
上記受信機からの肯定応答「ACK」または否定応答「NACK」の受信に連続して失敗した回数が、構成可能な閾値を超えるかどうかをチェックすること、または
物理層が上記受信機はカバー範囲外であると決定する場合、該カバー範囲外の状態が、決定されること
によって決定される、項目5に記載の方法。

0017

(項目7)
上記方法は、送信機の無線リンク制御「RLC」レベルで実行される、項目1〜項目5のいずれか1項に記載の方法。

0018

(項目8)
断片化は、メディアアクセス制御「MAC」層で実行される、項目1〜項目5のいずれか1項に記載の方法。

0019

(項目9)
断片サイズは、MAC層によって、RLC層に報告される、項目8に記載の方法。

0020

(項目10)
カバー範囲外の状態は、MAC層からRLC層に報告される、項目8に記載の方法。

0021

(項目11)
上記再断片化されたデータは、RLC層からMAC層に渡される、項目1〜項目5のいずれか1項に記載の方法。

0022

(項目12)
勾配チャネル品質インジケータが、閾値未満であるかどうかを決定することによって、上記HARQは、チャネル状態の劣化をチェックする、項目1に記載の方法。

0023

(項目13)
上記勾配チャネル品質インジケータが、閾値より大きいか、あるいは閾値未満でない場合、上記方法は、最終チャネル品質インジケータに対する符号化速度、または直近受信したCQIの平均、および上記受信機に対する無線リソースの利用可能性が、閾値より大きいかどうかをチェックするステップと、
イエスの場合、新たな断片サイズを有するHARQ再送信失敗を信号伝達するステップと、
ノーの場合、HARQ再送信失敗を信号伝達するステップと
をさらに包含する、項目12に記載の方法。

0024

(項目14)
再断片化層を備え、無線チャネル状態に従って、データをより適切なサイズに再断片化するように適合されたモバイルネットワークにおける送信機であって、該再断片化層は、
ハイブリッド自動再送要求「HARQ」送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態の劣化が表示されているかどうか、または閾値未満であるかどうかをチェックして、
イエスの場合、
RLC−SDUまたはRLC−PDUのデータをより小さなPDUデータサイズに再断片化し、
該再断片化されたRLC−PDUデータを送信すること、
イエスでない場合、
以前のRLC−PDUデータを送信すること
を行うように適合されている、送信機。

0025

(項目15)
上記再断片化層は、RLC層またはMAC層を備える、項目14に記載の送信機。

0026

(項目16)
上記際断片化層は、ハンドオーバが表示されているかどうかを決定して、イエスの場合、上記再送信処理を終了するように適合されている、項目14に記載の送信機。

0027

(項目17)
無線リソース制御プロトコルまたはレイヤ2レベル信号伝達が、上記ハンドオーバを表示するように適合されている、項目16に記載の送信機。

0028

(項目18)
無線リソース制御プロトコルは、測定報告またはレイヤ2レベル信号伝達が、受信または生成されるときに、ハンドオーバが期待されるかどうかを表示するように適合されている、項目17に記載の送信機。

0029

(項目19)
カバー範囲外の状態が表示されているかどうかを決定して、イエスの場合、上記再送信を終了する、項目14〜項目18のいずれか1項に記載の送信機。

0030

(項目20)
カバー範囲外の状態は、
受信した最終チャネル品質インジケータ「CQI」時間が、閾値より大きいかどうかをチェックすること、
受信機または送信機からの肯定応答「ACK」または否定応答「NACK」の受信に連続して失敗した回数が、所定の閾値を超える場合、あるいは
勾配チャネル品質インジケータが、閾値未満である場合を決定すること
のいずれかによって決定するようにさらに適合されている、項目19に記載の送信機。

0031

(項目21)
上記勾配チャネル品質インジケータが、閾値より大きいか、あるいは閾値未満でない場合、上記送信機は、最終チャネル品質インジケータに対する符号化速度が、閾値より大きいかどうかをチェックして、
イエスの場合、新たな断片サイズを有するHARQ再送信失敗を信号伝達することと、
ノーの場合、HARQ再送信失敗を信号伝達することと
を行うように適合されている、項目20に記載の送信機。

0032

(項目22)
項目14〜項目21のいずれか1項に記載の送信機と、該送信機からのパケットデータ送信を受信可能な複数のユーザ装備「UE」とを備える、通信ネットワーク。

0033

(項目23)
項目1〜項目13のいずれか1項に記載の方法を実行する計算デバイスまたはシステムにおいて実行可能なプログラムコードを備える、コンピュータ読み取り可能な媒体。

0034

摘要
ハイブリッド自動再送要求(HARQ)送信失敗時にパケットデータを再送信する方法であって、該方法は、HARQ送信エラー性能特性に対する変化が閾値より大きいかどうか、および/またはチャネル状態の劣化が表示されているかどうか、または閾値未満であるどうかをチェックするステップと、イエスの場合、RLC−SDUまたはRLC−PDUのデータをより小さなPDUデータサイズに再断片化するステップと、該再断片化されたRLC−PDUデータを送信するステップと、イエスでない場合、以前のRLC−PDUデータを送信するステップとを有する、方法。

発明を実施するための最良の形態

0035

本出願は、図面を参照することによって、より良く理解される。

0036

(好ましい実施形態の説明)
ここで、図面に参照がなされる。図1は、ロングタームエボリューション(LTE)ユーザの平面プロトコルスタックを説明するブロック図を示す。

0037

UE110は、進化型ノードB(eNB)120とアクセスゲートウェイ(aGW)130の双方と通信する。

0038

様々な層が、プロトコルスタックに示される。パケットデータ収束プロトコル(PDCP)層140は、UE110とaGW130の双方に図示される。PDCP層140は、インターネットプロトコル(IP)ヘッダ圧縮および解凍、ユーザデータの転送、ならびに無線ベアラに対するシーケンス番号(SN)の維持を実行する。

0039

PDCP層140の下に、無線リンク制御プロトコル層142があり、この無線リンク制御プロトコル層142は、eNB120上の無線リンク制御プロトコル層142と通信する。理解されるように、通信は、図1および図2に示されるプロトコルスタックのようなプロトコルスタックにある物理層を介して発生する。しかしながら、UEのRLC層142からのパケットは、eNB120上のRLC層142によって解釈される。

0040

RLC層142の下に、メディアアクセス制御(MAC)データ送信プロトコル層146がある。当業者によって理解されるように、RLCプロトコルおよびMACプロトコルは、UMTSのデータリンクサブ層およびLTE無線インタフェースを形成し、ノードB(すなわち、LTEのeNB)およびユーザ装備上に常駐する。

0041

レイヤ1(L1)LTE(物理層148)は、RLC層142/MAC層146の下にある。この層は、通信用の物理層である。

0042

図2を参照すると、図2は、LTE制御平面プロトコルアーキテクチャを示す。図1に使用された参照番号と同様の参照番号が、図2で使用される。具体的には、UE110は、eNB120およびaGW130と通信する。さらに、物理層148、MAC層146、RLC層142、およびPDCP層140が、図2の中に存在する。

0043

図2はまた、非アクセス階級(non−access stratum)(NAS)層210を示す。理解されるように、NAS層210は、移動性管理およびセッション管理を含み得る。

0044

無線リソース制御プロトコル層(RRC)220は、UEとE−UTRAN(進化型ユニバーサル無線アクセスネットワーク)との間の無線リソースの割り当て、構成、およびリリースを担うプロトコルスタックのパーツである。LTE用RRCプロトコルの基本的な機能性は、3GPPのTR25.813の仕様に記載されている。

0045

当業者によって理解されるように、UMTSにおいて、自動再送要求(ARQ)の機能性は、無線ネットワークコントローラ(RNC)に駐在するRLC層内で実行される。ロングタームエボリューション(LTE)は、ARQ機能性をRNCからeNBに移動させ、ここで、より緊密な相互作用が、ARQとHARQとの間(MAC層内で、またeNBの中にも位置する)に存在し得る。

0046

HSDPAおよびE−DCHにおいて、RLC−SDUは、一連の等しいサイズにされたRLC−PDU(例えば、42オクテット)に断片化され、エアインタフェースを介して送信するために、MAC層に与えられる。MACは、通常、複数のRLC−PDUを1つのMAC−PDUに多重化する。MAC−PDUが、配信され得ない場合、特定回数の試みの後に、そのMAC−PDUの送信は、放棄される。受信機側で、MAC層は、受信したMAC−PDUを複数のRLC−PDUに逆多重化する。何らかの紛失RLC−PDUが検出される場合、受信側は、ステータスメッセージを用いて通知し、紛失RLC−PDUの再送信を要求する。これは、比較的長々しい処理である。

0047

LTEにおいて、待ち時間を大幅に減らし、データのスループットを増やすために、失敗したMACレベルの再送信を放棄する代わりに、再断片化の後に、再送信することが、現在、研究されている。この問題は、いつ、どのようにして再断片化するかということである。

0048

図3および図4を参照すると、本出願に従う方法の概観が、提示される。

0049

HARQ再送信失敗において、エラーを取り扱う3つの選択肢があり、これらは、
1)何もしないこと。これは、ARQ機能のポーリングおよびステータス報告機能に依存して、エラーを回復することを意味する。このオプションは、ハンドオーバが、無線カバー範囲外にあると期待されるときに、選択されるべきである。
2)即座に再断片化して、再送信すること。失敗したデータユニットは、再送信される前に、現在の無線状態に従って、より適切なサイズに再断片化される。このオプションは、当初のトランスポートブロックが、チャネル状態の劣化および/または無線リソースの利用可能性の減少によって、効率的でないと考えられるときに、再送信する際に選択されるべきである。
3)現在のまま、即座に再送信すること。このオプションは、選択肢1)および2)が適用可能でないときに、選択されるべきである。

0050

図3は、HARQ再送信失敗時に、MAC層内で、どのような選択がなされるかの例示的な流れ図を示す。この決定は、HARQ再送信失敗の通知を用いて、再断片化および再送実行機能(RREF)に渡される。RREFは、図4に示される上部層から知らされた決定およびハンドオーバ表示に従って、再送信および/または再断片化を実行する。

0051

図3における選択を行うためには、特定の閾値が、構成される必要がある。受信機側と送信機側との双方でのこのようなパラメータ構成は、図5に示される。図6は、ハンドオーバ表示が、どのようにしてRREFに提供されるかを説明する。図7は、2つの考えられるプロトコルアーキテクチャを示し、その第一において、RREFは、RLCに含まれ、その第二において、RREFは、MACに含まれる。

0052

図3を参照すると、決定実行処理の詳細が、説明される。ステップ310で、HARQ再送信失敗が発生する(最大再送信回数に到達する)とき、ステップ311で、カバー範囲外の状態が、検査される。例えば、受信機からのACK/NAKの受信に連続して失敗した回数(Nanf)が、構成された閾値(TH−Nanf)を超える場合(ACK/NAKが受信機から受信されるべき時間に、送信機が、期待されるACK/NAK応答を検出し得ない場合)、ステップ312で、カバー範囲外の表示が、RREFに渡される。

0053

あるいは、受信機側からの定期的なCQI報告が構成される場合、送信機は、受信機からの直近のCQI報告とHARQ再送信失敗(TLastCQI)との間の時間が、構成された閾値(TH−LC)、例えば、CQIインターバル*Nより長い場合、受信機が無線カバー範囲外であると考える。ここで、Nは、整数値である。このような場合、カバー範囲外の表示は、ステップ312で、RREFに渡される。

0054

さらに、物理層が、受信機がカバー範囲外であることを表示し得る場合、このような表示は、MAC層を介して、RREFに配信され得る。

0055

ステップ311で決定されるように、受信機が無線カバー範囲内にあると考えられる場合、ステップ320で、直近受信したCQI報告の平均および勾配(それぞれE(CQI)およびGrad(CQI)で指定)が、計算される。計算に使用されるCQIの数(Nc)は、例えば、RRCによって構成され得る。チャネル品質の激しい劣化が検出される場合、すなわち、Grad(CQI)が、構成された閾値(TH−G)未満の場合、当初トランスポートブロックサイズの半分のような新たな断片化サイズが、ステップ322で、RREFに提供され得る。

0056

チャネル品質に対するより正確な評価のために、当初のトランスポートブロックサイズが、依然として十分である場合、符号化速度が計算され得る。導出される速度は、当初のブロックは、E(CQI)によって表示されるチャネル状態を用いて、また受信機に現在割り当てられる無線リソースを用いて、再送信される。計算された符号化速度が、構成された閾値、例えば、1よりも大きい場合、当初のサイズは、もはや適切ではない。ステップ332で、新たな断片値が計算され得、RREFに渡され得る。新たな断片サイズ値は、計算された符号化速度によって選択され、この符号化速度は、適切、たとえば、0.5であると考えられる
当初のトランスポートブロックサイズが、現在のチャネル状態に対して、依然として適切である場合、ステップ340で、HARQ再送信失敗のみが、RREFに渡される。この場合、RREFは、再断片化することなく、当初のデータそのままを再送信する。

0057

図4を参照すると、RREFの詳細が、説明される。RREFは、RLC層またはMAC層のいずれかに存在し得る。ステップ410でのMACからのHARQ再送信失敗の通知時に、ステップ411での処理は、ハンドオーバが表示される場合にチェックする。ハンドオーバが表示される場合、即座の再送信は、試みられない。なぜなら、データが、ハンドオーバの間に、失われ得るからである。それゆえ、ARQ再送信手順に、この場合(すなわち、ポーリングおよびステータス報告)を扱わせることによって、再送信を遅延させる方がよい。

0058

ハンドオーバの場合と同様、カバー範囲外であることが表示される場合、即座の再送信は、ステップ412で試みられる。

0059

ステップ413で、MACが、新たな断片化サイズを表示する場合、当初のデータは、ステップ414で、特定サイズに再断片化され、ステップ415で、再送信される。理解されるように、最後の断片は、特定サイズでないこともあり得、このような場合、必要に応じて、パディングが挿入され得る。

0060

MACが、新たな断片データがないことを表示する場合、ステップ415で、当初のデータが、そのまま再送信される。この処理は、ステップ416で終了する。

0061

ここで、図5への参照がなされる。図5は、図3で行われる決定のために、閾値を構成するための流れ図を示す。ステップ510において、受信機側で、MAC層は、特定インターバルを有するCQIを送信機に報告するように構成される。あるいは、受信機側で、MAC層は、CQIがステップ510で構成されたレベルを下回る場合に、特定インターバルを有するCQIを送信機に報告するように構成される。ステップ520において、送信機側で、閾値TH−LC、TH−Nanf、TH−G、およびTH−CR、ならびに幾つかの直近のCQI報告(Nc)が、構成される。UE側に対して構成されるべき値は、RRCまたはレイヤ2信号伝達によって構成され得る。

0062

図6は、eNBとUEとに対するハンドオーバを開始するためのRRC表示を示す。LTEにおいては、eNBのみがハンドオーバを開始するものと、現在、仮定されている。

0063

ネットワークに対する処理は、ステップ610で開始し、ステップ612に進み、ステップ612において、測定制御メッセージを送信して、ハンドオーバ条件を構成する。このメッセージは、RRCメッセージまたはレイヤ2レベル信号伝達であり得る。

0064

次いで、処理は、ステップ614に進み、ステップ614において、測定報告メッセージを待つ。このメッセージは、RRCメッセージまたはレイヤ2レベル信号伝達であり得る。

0065

ステップ616で、処理は、RLCにハンドオーバを表示し、ステップ618で、終了する。

0066

UE側において、処理は、ステップ630で開始し、632に進み、ステップ632において、測定制御メッセージを受信して、ハンドオーバ条件を構成する。このメッセージは、RRCメッセージまたはレイヤ2レベル信号伝達であり得る。

0067

次いで、処理は、ステップ634に進み、ステップ634において、満足されるべきハンドオーバ測定条件を待つ。一度、ハンドオーバ測定条件が満足されると、ステップ635で、処理は、測定報告メッセージを送信して、ステップ636に進み、ステップ636において、ハンドオーバをRLCおよび/またはMAC[図7および図8参照]に表示して、次いで、処理は、ステップ638で、終了する。この測定報告は、RRCメッセージまたはレイヤ2レベル信号伝達であり得る。

0068

ここで、図7への参照がなされる。図7は、図3および図4に従って、RRC層、RLC層、およびMAC層の間での相互作用を示す。図7は、RLC層が、再断片化が起こるべきかどうかを決定する機能を含む場合を示す。図8は、以下に説明されるように、MAC層が、再断片化は起こるべきかどうかを決定する機能を含む状況を示す。

0069

図7において、RRC710は、ハンドオーバ表示を有するRLC720を提供する。次いで、RLCは、再断片化が起こるべきでないことを決定する図3の方法を適用する。

0070

MAC層730は、HARQ再送信失敗およびチャネル状態ステータス情報をRLCに渡す。この情報は、RLCに再断片化が起こるべきかどうかを決定させることを可能にする。

0071

図8を参照すると、図8は、再断片化するための機能を有するMAC層を示す。この場合、RRC810は、RLC820にハンドオーバ表示を渡す。このハンドオーバ表示は、次いで、RLC820からMAC層830に渡される。MAC層は、HARQ再送信失敗情報を既に有し、ハンドオーバ表示を用いて、図3の処理を実行し得る。

0072

したがって、上記は、とりわけ、シャドーイングのような無線チャネル状態に従って、データをより適切なサイズに再断片化することによって、さらに再送信待ち時間を改善する問題に対処する。この方法は、直近に受信したCQI、勾配、または直近に報告されたCQIの符号化速度に基づくチャネル状態表示を使用する。この処理は、RLC−SDUまたはRLC−PDUをより適切なPDUサイズに再断片化し、これらを再送信のために、MAC層に渡す。

0073

特定の期間内におけるHARQ再送信失敗の回数を構成された閾値に対して比較することによって、送信機は、チャネル状態に対する近似を決定し得る。閾値に比べて、HARQ再送信失敗の回数が多い場合、このことは、チャネル状態の著しい劣化を反映し得る。このことは、当初のチャネル評価に基づくデータ(例えば、受信CQI)を成功裏に送信する能力が、送信機に継続的にないことによって反映される。チャネル品質の著しい劣化が検出されるとき、当初のトランスポートブロックサイズの半分のような新たな断片化サイズが、RREFに通知され得る。

0074

特定の期間内におけるHARQ再送信失敗の決定された回数に対して閾値を比較することと、ハンドオーバ表示は、再送信が再び試みられる場合を決定するために使用され得る。

0075

RRCは、受信機側でMACを構成して、CQIを定期的に報告するか、あるいはCQIが構成された閾値を下回るとき、CQIを定期的に報告する。送信機側に対して、RRCはまた、TH−LC、Nc、TH−G、およびTH−CRをMACに信号伝達する。勾配CQIが、TH−G未満の場合、再断片化が実行される。E(CQI)に対する符号化速度が、TH−CRより大きい場合、再断片化が実行される。再断片化されたPDUのサイズは、符号化速度に依存し得る。

0076

したがって、これは、チャネル状態に従ってPDUを再断片化することと、ハンドオーバ手順が完了するまで再送信を待つこととによって、HARQ再送信失敗時における送信機の効率を改善する。

0077

本明細書に記載された実施形態は、この出願の技術の要素に対応する要素を有する構造、システム、または方法の例である。ここに記載された説明は、この出願の技術の要素に同様に対応する代替の要素を有する実施形態を当業者が、利用し、使用することを可能にし得る。したがって、本出願の技術の意図される範囲は、本明細書に記載されたような本出願の技術とは異ならない他の構造、システム、または方法を含み、本明細書に記載されたような本出願の技術とは実質的な差を有しない構造、システム、または方法もさらに含む。

図面の簡単な説明

0078

図1は、ロングタームエボリューションユーザの平面プロトコルスタックを示すブロック図である。
図2は、ロングタームエボリューション制御の平面プロトコルアーキテクチャを示すブロック図である。
図3は、本開示に従って、MAC層内で再送信および再断片化を決定する方法を示す流れ図である。
図4は、本開示および図3でなされた決定に従って、再送信および再断片化を実行する方法を示す流れ図である。
図5は、受信機側と送信機側との双方でのMAC層の構成を示す流れ図である。
図6は、ノードB側とUE側との双方からハンドオーバの表示の流れ図の流れ図を示すブロック図である。
図7は、RRC層、RLC層、およびMAC層の間での相互作用を示すブロック図であり、本発明のシステムおよび方法に従って、再送信および再断片化は、MACおよびRLCで実行される。
図8は、RRC層、RLC層、およびMAC層の間での代替の相互作用を示すブロック図であり、再送信および再断片化は、MACで実行される。

符号の説明

0079

110ユーザ装備(UE)
120進化型ノードB(eNB)
130アクセスゲートウェイ(aGW)
140パケットデータ収束プロトコル(PDCP)層
142、220無線リンク制御プロトコル(RLC)層
146メディアアクセス制御(MAC)データ送信プロトコル層
148レイヤ1(L1)LTE(物理層)
210 非アクセス階級(NAS)層

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • マクセル株式会社の「 無線端末装置および無線給電装置」が 公開されました。( 2021/03/18)

    【課題・解決手段】無線給電と無線データ通信との干渉を防止または低減することができ、効率性や信頼性、ユーザの利便性等を向上できる技術を提供する。無線給電システムは、無線端末装置4、無線給電装置3、無線基... 詳細

  • 株式会社NTTドコモの「 受信装置、送信装置及び無線通信方法」が 公開されました。( 2021/03/18)

    【課題・解決手段】繰り返し送信を適切に行うこと。受信装置は、所定チャネルの複数の繰り返し送信の中の少なくとも1つの繰り返し送信を受信する受信部と、所定条件に基づいて、前記複数の繰り返し送信における前記... 詳細

  • 株式会社NTTドコモの「 ユーザ装置」が 公開されました。( 2021/03/18)

    【課題・解決手段】ランダムアクセス手順開始のトリガとなる制御情報を基地局から受信する受信部と、ランダムアクセス信号を送信するためのリソースを選択し、当該リソースを使用して当該ランダムアクセス信号を前記... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ