(57)【要約】  無線リンク制御切替えのための方法および装置が開示される。方法および装置は、第1のデバイスと第2のデバイスとの間の無線接続の無線ベアラまたはパケットフローのための、第1のデバイスにおける通信モードを判断し、これは、パケット損失回復またはパケット並べ替えを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含む。パケットフロー向けに第1の通信モードそれとも第2の通信モードが使われるべきかに関連した第1の指示が、第2のデバイスに送信され、パケットバッファリングが維持されるべきかどうかを示す第2の指示が、第2のデバイスに送信される。第1の通信モードと第2の通信モードとの間の無線接続のパケットフロー向けの通信モードは次いで、少なくとも第1の指示に基づいて切り替えられる。
2018509026.tif 000002
【特許請求の範囲】
【請求項１】
ワイヤレス通信のための方法であって、
第1のデバイスにおいて、前記第1のデバイスと第2のデバイスとの間の無線接続の少なくとも第1のパケットフロー向けの通信モードを判断するステップであって、パケット損失回復および/またはパケット並べ替えのうちの少なくとも1つを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含むステップと、
前記第1の通信モードそれとも前記第2の通信モードが前記無線接続の前記第1のパケットフロー向けに使われるべきかに関連した、前記第2のデバイスへの第1の指示、およびパケットバッファリングが維持されるべきかどうかを指示する、前記第2のデバイスへの第2の指示を送信するステップと、
少なくとも前記第1の指示に基づいて、前記無線接続の前記第1のパケットフロー向けの前記通信モードを、前記第1の通信モードと第2の通信モードとの間で切り替えるステップとを含む方法。
【請求項２】
前記第1の指示を送信したことに応答して、前記第2のデバイスから確認応答を受信するステップをさらに含む、請求項1に記載の方法。
【請求項３】
前記第1のデバイスは、前記確認応答が受信された後、前記無線接続の前記第1のパケットフローの前記通信モードを切り替える、請求項2に記載の方法。
【請求項４】
前記無線接続用の前記通信モードを切り替えるステップは、
前記第1および第2のデバイスのうちの少なくとも1つにおいて、前記無線接続の前記第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットするステップをさらに含み、前記状態要素は、状態変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項５】
前記第1の指示は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、帯域内シグナリングおよび/または制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項1に記載の方法。
【請求項６】
前記第2の指示は、前記第1のデバイスおよび/または前記第2のデバイスのうちの少なくとも1つにパケットをバッファリングするかどうかをシグナリングする、プロトコルデータ単位(PDU)のヘッダ中のバッファビットを含む、請求項1に記載の方法。
【請求項７】
ポールビットを含む前記第1の指示が、前記無線接続の前記第1のパケットフローを介して、1つまたは複数の受信PDUのステータスを送るかどうかを指示するステップをさらに含み、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のパケットフロー向けの前記通信モードの切替えを通信するように構成される、請求項6に記載の方法。
【請求項８】
前記第1の通信モードそれとも前記第2の通信モードで動作するか判断するステップは、
前記無線接続の前記第1のパケットフローのデータレート、前記第1および第2のデバイスのうちの少なくとも1つにおけるバッファサイズ、パケットエラーレート(PER)、ブロックエラーレート(BLER)、前記無線接続の前記第1のパケットフローを介した、前記第1および第2のデバイスの間のパケット待ち時間、ならびに/または前記無線接続の前記第1のパケットフローにおいてサービスされるインターネットプロトコル(IP)フローの数のうちの少なくとも1つを測定するステップと、
前記測定に基づいて、前記第1の通信モードそれとも前記第2の通信モードで動作するか判断するステップをさらに含む、請求項1に記載の方法。
【請求項９】
前記第1の通信モードは無線リンク制御(RLC)確認応答モード(AM)であり、前記第2の通信モードはRLC非確認応答モード(UM)である、請求項1に記載の方法。
【請求項１０】
ワイヤレスデバイスであって、
ワイヤレスネットワークを介して通信するように構成された通信インターフェースと、
前記通信インターフェースに結合された処理回路構成とを備え、前記処理回路構成は、
前記ワイヤレスデバイスと別の第2のワイヤレスデバイスとの間の無線接続の少なくとも第1のパケットフロー向けの通信モードを判断し、これは、パケット損失回復および/またはパケット並べ替えのうちの少なくとも1つを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含み、
前記第1の通信モードそれとも前記第2の通信モードが前記無線接続の前記第1のパケットフロー向けに使われるべきかに関連した、前記第2のワイヤレスデバイスへの第1の指示、およびパケットバッファリングが維持されるべきかどうかを指示する、前記第2のワイヤレスデバイスへの第2の指示を送信し、
少なくとも前記第1の指示に基づいて、前記無線接続の前記第1のパケットフロー向けの前記通信モードを、前記第1の通信モードと第2の通信モードとの間で切り替えるように構成される、ワイヤレスデバイス。
【請求項１１】
前記処理回路構成は、前記第1の指示を送信したことに応答して、前記第2のワイヤレスデバイスから確認応答を受信するようにさらに構成される、請求項10に記載のワイヤレスデバイス。
【請求項１２】
前記処理回路構成は、前記確認応答が受信された後、前記無線接続の前記第1のパケットフローの前記通信モードを切り替える、請求項11に記載のワイヤレスデバイス。
【請求項１３】
前記処理回路構成は、
前記ワイヤレスデバイスおよび第2のワイヤレスデバイスのうちの少なくとも1つにおいて、前記無線接続の前記第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットすることを含む、前記無線接続の前記第1のパケットフロー向けの前記通信モードを切り替え、前記状態要素は、状態変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含むようにさらに構成される、請求項11に記載のワイヤレスデバイス。
【請求項１４】
前記第1の指示は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、帯域内シグナリングおよび制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項10に記載のワイヤレスデバイス。
【請求項１５】
前記第2の指示は、前記ワイヤレスデバイスおよび/または前記第2のワイヤレスデバイスのうちの少なくとも1つにパケットをバッファリングするかどうかをシグナリングする、プロトコルデータ単位(PDU)のヘッダ中のバッファビットを含む、請求項10に記載のワイヤレスデバイス。
【請求項１６】
前記無線接続の前記第1のパケットフローを介して、1つまたは複数の受信PDUのステータスを送るかどうかを指示するポールビットを含む前記第1の指示をさらに備え、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のパケットフロー向けの前記通信モードの切替えを通信するように構成される、請求項15に記載のワイヤレスデバイス。
【請求項１７】
前記処理回路構成は、
前記無線接続の前記第1のパケットフローのデータレート、前記ワイヤレスデバイスおよび前記第2のワイヤレスデバイスのうちの少なくとも1つにおけるバッファサイズ、パケットエラーレート(PER)、ブロックエラーレート(BLER)、前記無線接続の前記第1のパケットフローを介した、前記第1および第2のデバイスの間のパケット待ち時間、ならびに/または前記無線接続の前記第1のパケットフローにおいてサービスされるインターネットプロトコル(IP)フローの数のうちの少なくとも1つを測定し、
前記測定に基づいて、前記第1の通信モードそれとも前記第2の通信モードで動作するか判断するようにさらに構成される、請求項10に記載のワイヤレスデバイス。
【請求項１８】
前記第1の通信モードは無線リンク制御(RLC)確認応答モード(AM)であり、前記第2の通信モードはRLC非確認応答モード(UM)である、請求項10に記載のワイヤレスデバイス。
【請求項１９】
ワイヤレス通信のための方法であって、
第1および第2のワイヤレスデバイスの間の無線接続の第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から、前記第1または第2の通信モードのうちの他方に切り替えるように指示する、前記第2のワイヤレスデバイスからの指示信号を前記第1のワイヤレスデバイスにおいて受信するステップであって、前記第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、前記第2の通信モードはパケット損失回復を提供しない、ステップと、
前記無線接続の前記第1のパケットフロー向けの前記通信モードを前記指示信号に従って切り替えるステップとを含み、
前記指示信号は、前記第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも前記第1のワイヤレスデバイスにおいて維持されるべきかどうかを指示する第2の指示を含む、方法。
【請求項２０】
前記受信した指示信号に応答して、前記第1のワイヤレスデバイスから前記第2のワイヤレスデバイスに確認応答を送るステップをさらに含む、請求項19に記載の方法。
【請求項２１】
前記無線接続の前記第1のパケットフロー向けの前記通信モードを切り替えるステップは、
前記指示信号に応答して、少なくとも前記第1のワイヤレスデバイスにおいて、前記無線接続の前記第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットするステップをさらに含み、前記状態要素は、状態変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含む、請求項19に記載の方法。
【請求項２２】
前記指示信号は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、前記第2のワイヤレスデバイスからの、帯域内シグナリングおよび制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項19に記載の方法。
【請求項２３】
前記第2の指示は、少なくとも前記第1のデバイス中でパケットをバッファリングするかどうかをシグナリングする、前記第2のワイヤレスデバイスからのプロトコルデータ単位(PDU)のヘッダ中のバッファビットを含む、請求項19に記載の方法。
【請求項２４】
前記第1の指示が、前記第1のワイヤレスデバイスから前記第2のワイヤレスデバイスに、1つまたは複数の受信PDUのステータスを、前記無線接続の前記第1のフローを介して送るかどうかを指示するポールビットを含めるステップをさらに含み、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のフロー向けの前記通信モードの切替えを通信するように構成される、請求項23に記載の方法。
【請求項２５】
前記第1の通信モードは無線リンク制御(RLC)確認応答モード(AM)であり、前記第2の通信モードはRLC非確認応答モード(UM)である、請求項23に記載の方法。
【請求項２６】
ワイヤレス通信デバイスであって、
ワイヤレスネットワークを介して通信するように構成された通信インターフェースと、
前記通信インターフェースに通信可能に結合された処理回路構成とを備え、前記処理回路構成は、
前記ワイヤレス通信デバイスと第2のワイヤレス通信デバイスとの間の無線接続の少なくとも第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から、前記第1または第2の通信モードのうちの他方に切り替えるように指示する指示信号を、前記第2のワイヤレス通信デバイスから受信し、前記第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、前記第2の通信モードはパケット損失回復を提供せず、
前記無線接続の前記第1のパケットフロー向けの前記通信モードを前記指示信号に従って切り替えるように構成され、
前記指示信号は、前記第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも前記ワイヤレス通信デバイスにおいて維持されるべきかどうかを指示する第2の指示を含む、ワイヤレス通信デバイス。
【請求項２７】
前記処理回路構成は、
前記受信した指示信号に応答して、前記ワイヤレス通信デバイスから前記第2のワイヤレス通信デバイスに確認応答を送るようにさらに構成される、請求項26に記載のワイヤレス通信デバイス。
【請求項２８】
前記指示信号は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、前記第2のワイヤレス通信デバイスからの、帯域内シグナリングおよび制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項26に記載のワイヤレス通信デバイス。
【請求項２９】
前記無線接続の前記第1のパケットフローを介して受信された1つまたは複数の受信プロトコルデータ単位(PDU)のステータスを、前記ワイヤレス通信デバイスから前記第2のワイヤレス通信デバイスに送るかどうかを指示するポールビットを含む前記第1の指示と、
前記ワイヤレス通信デバイスにおいてパケットをバッファリングするかどうかをシグナリングする、前記第2のワイヤレス通信デバイスからのPDUのヘッダ中にバッファビットを含む前記第2の指示とをさらに含み、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のパケットフロー向けの前記通信モードの切替えを通信するように構成される、請求項26に記載のワイヤレス通信デバイス。
【請求項３０】
前記処理回路構成は、
前記第2のワイヤレス通信デバイスから受信された前記指示信号に応答して、前記無線接続の前記第1のパケットフロー向けの前記通信モードを切り替えた後、前記受信した指示信号に一致する補足指示信号を前記第2のワイヤレス通信デバイスに送るようにさらに構成される、請求項26に記載のワイヤレス通信デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、2015年1月26日に出願した、その内容が参照により本明細書に組み込まれる、「METHOD AND APPARATUS FOR RADIO LINK CONTROL SWITCHING」と題する仮出願第62/107,992号、2015年2月13日に出願した、「METHOD AND APPARATUS FOR RADIO LINK CONTROL SWITCHING」と題する仮出願第62/116,262号、および2016年1月15日に出願した、「METHODS AND APPARATUS FOR RADIO LINK CONTROL SWITCHING」と題する非仮出願第14/997,271号に対する優先権を主張する。
【０００２】
本開示は、概して通信システムに関し、より詳細には、無線リンク制御(RLC)切替えのための方法および装置に関する。
【背景技術】
【０００３】
ワイヤレス通信システムは、電話、ビデオ、データ、メッセージング、およびブロードキャストなどの様々な電気通信サービスを提供するために広く展開されている。典型的なワイヤレス通信システムは、利用可能なシステムリソース(たとえば、帯域幅、送信電力)を共有することによって複数のユーザとの通信をサポートすることが可能な多元接続技術を用いることができる。これらの多元接続技術は、様々なワイヤレスデバイスが自治体、国家、地域、さらには地球規模で通信することを可能にする共通プロトコルを提供するために、様々な電気通信規格において採用されている。新たな電気通信規格には、ロングタームエボリューション(LTE)などの第4世代(4G)技術および第5世代(5G)技術が含まれる。
【０００４】
LTEは、具体的には、第3世代パートナーシッププロジェクト(3GPP)によって推進されたユニバーサルモバイル電気通信システム(UMTS)モバイル標準規格に対する拡張のセットである。LTEは、スペクトル効率を改善すること、コストを下げること、サービスを改善すること、新しいスペクトルを利用すること、ならびにダウンリンク(DL)上のOFDMA、アップリンク(UL)上のSC-FDMA、および多入力多出力(MIMO)アンテナ技術を使用して他のオープン規格とより十分に統合することによってモバイルブロードバンドインターネットアクセスをより良好にサポートするように設計される。
【０００５】
LTE用の無線プロトコルアーキテクチャは、たとえば、ワイヤレスインターフェース(たとえば、LTEのケースでは、進化型ユニバーサル地上無線アクセスネットワーク(E-UTRAN))を介した送信および受信のための、ワイヤレスデバイスにおけるユーザプレーンまたは制御プレーンのいずれかからのデータおよびシグナリングの扱いを可能にする様々なプロトコルレイヤからなる。ユーザプレーン側では、たとえば、ワイヤレスデバイス上のアプリケーションが、TCP、UDP、およびIPなどのプロトコルによって処理されるデータパケットを作成する。制御プレーン側では、無線リソース制御(RRC)プロトコルが、あるワイヤレスデバイスと別のワイヤレスデバイスとの間で交換されるシグナリングメッセージを決定する。両方のケースにおいて、情報は次いで、ワイヤレスインターフェースを介した送信のために物理レイヤ(PHY)に渡される前に、パケットデータコンバージェンスプロトコル(PDCP)、無線リンク制御(RLC)プロトコル、およびメディアアクセス制御(MAC)プロトコルを含む様々なプロトコルによって処理される。受信機側では、同じプロトコルが、受信PHYレイヤ信号を受け、これらを折り返し、アプリケーションレイヤデータまたはシグナリング情報に最終的にコンバートするのに使われる。
【０００６】
RLCプロトコルレイヤに関して、特に、このレイヤは、RRCまたはPDCPプロトコルレイヤのいずれかから、MACレイヤとの通信に使われるRLCプロトコルデータ単位(PDU)への、データ構造(たとえば、サービスデータ単位(SDU))のセグメンテーションを可能にする。RLCレイヤは、概して3つのモードに従って動作するように構成されてよく、それらのモードは、(1)RRCまたはPDCPとMACレイヤとの間で、パケットを、PDUに編成せずに渡すだけの透過(TM)モード、(2)データをPDUにセグメント化し、編成するが、受信機からの、パケットの受信成功の確認応答を求めない非確認応答モード(UM)、および(3)PDUへの編成に加え、受信機からの確認応答を求め、受信機によってパケットが確認応答されなかった場合、再送信(たとえば、自動再送要求(ARQ))を認める確認応答モード(AM)である。
【０００７】
RLC AMのAM動作に関して、より高い信頼性を与えると同時に、この動作は、再送信に必要とされるPDUのより大規模なバッファリングも求め、確認応答およびステータス報告における遅延によるスループット低下も引き起こし得る。遅延したステータス報告は、たとえば、逆方向のための不良無線条件、ステータス報告の不良構成、またはユーザデータの送信よりもステータス報告を優先することができない不良データスケジューラ実装など、いくつかの様々な条件により起こり得る。UM動作には一方、AM動作に関連したバッファリングおよびスループットの問題がない。それにも関わらず、UMを常にデータ転送に使うことは理想的ではなく、というのは、UMは、再送信機能性をもたず、損失および回復不能パケットにより信頼性低下につながり得るからである。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
したがって、条件が許すとき、スループットを増大し、やはり必要とされるときは信頼性を保証しながら大量のデータをバッファリングする必要性を低減することができるようにするために、無線リンク制御において、少なくともAMモードとUMモードとの間で効果的および効率的に切り替えることができる必要がある。
【課題を解決するための手段】
【０００９】
ある態様によると、ワイヤレス通信のための方法が本明細書において開示される。この方法は、第1のデバイスにおいて、第1のデバイスと第2のデバイスとの間の無線接続の少なくとも第1のパケットフロー向けの通信モードを判断するステップを含み、これは、パケット損失回復および/またはパケット並べ替えのうちの少なくとも1つを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含む。さらに、この方法は、第1の通信モードそれとも第2の通信モードが無線接続の第1のパケットフロー向けに使われるべきかに関連した、第2のデバイスへの第1の指示、およびパケットバッファリングが維持されるべきかどうかを指示する、第2のデバイスへの第2の指示を送信するステップを採用する。また、この方法は、少なくとも第1の指示に基づいて、無線接続の第1のパケットフロー向けの通信モードを、第1の通信モードと第2の通信モードとの間で切り替えるステップを含む。
【００１０】
別の態様によると、ワイヤレスデバイスが本明細書で開示され、このデバイスは、ワイヤレスネットワークを介して通信するように構成された通信インターフェースと、通信インターフェースと通信するか、またはそれに結合された処理回路構成とを含む。処理回路構成は、ワイヤレスデバイスと別の第2のワイヤレスデバイスとの間の無線接続の少なくとも第1のパケットフロー向けの通信モードを判断するように構成され、これは、パケット損失回復および/またはパケット並べ替えのうちの少なくとも1つを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含む。また、処理回路構成は、第1の通信モードそれとも第2の通信モードが無線接続の第1のパケットフロー向けに使われるべきかに関連した、第2のワイヤレスデバイスへの第1の指示、およびパケットバッファリングが維持されるべきかどうかを指示する、第2のデバイスへの第2の指示を送信するように構成される。処理回路構成は、少なくとも第1の指示に基づいて、第1の通信モードと第2の通信モードとの間の無線ベアラ接続の第1のパケットフロー向けの通信モードを切り替えるようにも構成される。
【００１１】
さらに別の態様では、第1および第2のワイヤレスデバイスの間の無線接続の第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から、第1または第2の通信モードのうちの他方に切り替えるように指示する、第2のワイヤレスデバイスからの指示信号を第1のワイヤレスデバイスにおいて受信するステップを含む、ワイヤレス通信のための方法が開示され、第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、第2の通信モードはパケット損失回復を提供しない。この方法は、無線接続の第1のパケットフロー向けの通信モードを指示信号に従って切り替えるステップも採用し、指示信号は、第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも第1のワイヤレスデバイスにおいて維持されるべきかどうかを指示する第2の指示を含む。
【００１２】
さらに別の態様によると、ワイヤレスネットワークを介して通信するように構成された通信インターフェースと、通信インターフェースに通信可能に結合された処理回路構成とを含むワイヤレス通信デバイスが開示される。処理回路構成は、第1および第2のワイヤレスデバイスの間の無線接続の少なくとも第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から第1または第2の通信モードのうちの他方に切り替えるように指示する、第2のワイヤレス通信デバイスからの指示信号を、ワイヤレス通信デバイスにおいて受信するように構成され、第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、第2の通信モードはパケット損失回復を提供しない。処理回路構成は、無線接続の第1のパケットフロー向けの通信モードを指示信号に従って切り替えるようにも構成され、指示信号は、第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも第1のワイヤレスデバイスにおいて維持されるべきかどうかを指示する第2の指示を含む。
【図面の簡単な説明】
【００１３】
【図１】ネットワークアーキテクチャの例を示す図である。
【図２】アクセスネットワークの例を示す図である。
【図３】ユーザプレーンおよび制御プレーンの無線プロトコルアーキテクチャの例を示す図である。
【図４】LTEパケット交換ネットワークの例において動作する通信デバイスにおいて実装され得るプロトコルスタックの例を示す図である。
【図５】アクセスネットワークに配備された発展型ノードBおよびユーザ機器の例を示す図である。
【図６】AM中の、RLCエンティティと別のピアRLCエンティティとの間の対話を示すタイミング図である。
【図７】本明細書で開示するいくつかの態様による状態図を示す図である。
【図８】本明細書で開示するいくつかの態様による、RLCエンティティと別のピアRLCエンティティとの間の対話を示すタイミング図である。
【図９】本明細書で開示するいくつかの態様による、第1のデバイスと第2のデバイスとの間のデータ転送および受信フローを示す図である。
【図１０】本明細書で開示するいくつかの態様によるRLCデータPDUの図である。
【図１１】本明細書で開示するいくつかの態様によるRLC制御PDU中のヘッダの図である。
【図１２】本明細書で開示するいくつかの態様による別のRLC PDUを示す図である。
【図１３】本明細書で開示するいくつかの態様による、送信機と受信機との間の対話を示すタイミング図である。
【図１４】本明細書で開示する様々な態様を実装するように構成されたワイヤレスデバイスの例を示すブロック図である。
【図１５】ワイヤレス通信の第1の方法のフロー図である。
【図１６】ワイヤレス通信の第2の方法のフロー図である。
【発明を実施するための形態】
【００１４】
以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書において説明する概念が実践され得る唯一の構成を表すことは意図されていない。詳細な説明は、様々な概念の完全な理解を提供する目的で、具体的な詳細を含む。しかし、これらの概念がこれらの具体的な詳細なしに実践され得ることは当業者に明らかであろう。いくつかの事例では、よく知られている構造および構成要素は、そのような概念を不明瞭にすることを避けるためにブロック図の形で示される。
【００１５】
次に、電気通信システムのいくつかの態様を、様々な装置および方法を参照して提示する。これらの装置および方法について、以下の詳細な説明において説明し、様々なブロック、モジュール、構成要素、回路、ステップ、プロセス、アルゴリズムなど(「要素」と総称される)によって添付の図面に示す。これらの要素は、電子ハードウェア、コンピュータソフトウェア、またはこれらの任意の組合せを使用して実装されてもよい。そのような要素がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課された設計制約に依存する。
【００１６】
例として、要素または要素の任意の部分または要素の任意の組合せを、1つまたは複数のプロセッサを含む「処理システム」で実装することができる。プロセッサの例には、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、特定用途向け集積回路(ASIC)、システムオンチップ(SOC)、状態機械、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明される様々な機能性を実施するように構成された他の適切なハードウェアが含まれる。処理システム内の1つまたは複数のプロセッサが、ソフトウェアを実行し得る。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、または他の名称で呼ばれるかどうかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行ファイル、実行スレッド、プロシージャ、関数などを意味するように広く解釈されるべきである。
【００１７】
したがって、1つまたは複数の例示的な実施形態では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアにおいて実施される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして、記憶されるか、または符号化される場合がある。コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータがアクセスできる任意の利用可能な媒体であってもよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または命令もしくはデータ構造の形の所望のプログラムコードを搬送もしくは記憶するために使用可能であり、コンピュータによってアクセス可能な任意の他の媒体を含んでもよい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、およびフロッピーディスク(disk)を含み、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲に含まれるべきである。
【００１８】
本開示のいくつかの態様は、LTE、第4世代(4G)、および比較的初期のネットワークだけでなく、第5世代(5G)およびそれ以降のネットワークを含む、より新しい世代の無線アクセス技術(RAT)にも適用可能である。本明細書では、4G LTEネットワークアーキテクチャの構成および動作について、一例として、および複数のRATに適用され得るいくつかの態様の説明を簡略化することを目的として説明する。
【００１９】
図1は、例示的なLTEネットワークアーキテクチャ100を示す図である。LTEネットワークアーキテクチャ100は、発展型パケットシステム(EPS)100と呼ばれる場合がある。EPS100は、1つまたは複数のユーザ機器(UE)102、発展型UMTS地上波無線アクセスネットワーク(E-UTRAN)104、発展型パケットコア(EPC)110、ホーム加入者サーバ(HSS)120、および事業者のIPサービス122を含み得る。EPSは、他のアクセスネットワークと相互接続することができるが、簡単のために、それらのエンティティ/インターフェースは図示されない。図示のように、EPSはパケット交換サービスを提供するが、当業者が容易に諒解するように、本開示全体にわたって提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。
【００２０】
E-UTRAN104は、発展型ノードB(eNB)106および他のeNB108を含む。eNB106は、UE102に対してユーザプレーンプロトコル終端および制御プレーンプロトコル終端を提供する。eNB106は、バックホール(たとえばX2インターフェース)を介して他のeNB108に接続されてよい。eNB106は、ノードB、基地局、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット(BSS)、拡張サービスセット(ESS)と呼ばれるか、または他の何らかの適切な用語で呼ばれることもある。eNB106は、UE102のためにEPC110へのアクセスポイントを与える。UE102の例には、携帯電話、スマートフォン、セッション開始プロトコル(SIP)電話、ラップトップ、携帯情報端末(PDA)、衛星無線、全地球測位システム、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ(たとえば、MP3プレーヤ)、カメラ、ゲームコンソール、タブレット、データカード、USBドングル、モバイルワイヤレスルータまたは同様に機能する任意の他のデバイスが含まれる。UE102は、当業者によって、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアントと呼ばれるか、または他の何らかの適切な用語で呼ばれることもある。
【００２１】
eNB106は、S1インターフェースによってEPC110に接続される。EPC110は、モビリティ管理エンティティ(MME)112、他のMME114、サービングゲートウェイ116、およびパケットデータネットワーク(PDN)ゲートウェイ118を含む。MME112は、UE102とEPC110との間のシグナリングを処理する制御ノードである。一般に、MME112は、ベアラおよび接続の管理を行う。すべてのユーザIPパケットは、サービングゲートウェイ116を通して転送され、サービングゲートウェイ116自体は、PDNゲートウェイ118に接続される。PDNゲートウェイ118は、UEのIPアドレス割振り、ならびに他の機能を提供する。PDNゲートウェイ118は、事業者のIPサービス122に接続される。事業者のIPサービス122は、インターネット、イントラネット、IPマルチメディアサブシステム(IMS)、およびPSストリーミングサービス(PSS)を含む場合がある。
【００２２】
図2は、LTEネットワークアーキテクチャにおけるアクセスネットワーク200の例を示す図である。この例では、アクセスネットワーク200は、いくつかのセルラー領域(セル)202、212に分割されている。1つまたは複数の低電力クラスeNB208は、セル202、212の1つまたは複数と重複するセルラー領域210を有し得る。低電力クラスeNB208は、フェムトセル(たとえば、ホームeNB(HeNB))、ピコセル、マイクロセル、またはリモートラジオヘッド(RRH)であってよい。マクロeNB204、214は各々、それぞれのセル202、212に割り当てられ、セル202、212中のすべてのUE206にEPC110へのアクセスポイントを提供するように構成される。アクセスネットワーク200のこの例では中央コントローラはないが、代替の構成では中央コントローラが使用される場合がある。eNB204、214は、無線ベアラ制御、承認制御、モビリティ制御、スケジューリング、セキュリティ、およびサービングゲートウェイ116への接続性を含む、すべての無線関係機能を担当する。
【００２３】
アクセスネットワーク200によって採用される変調方式および多元接続方式は、利用されている特定の電気通信規格に応じて変わる場合がある。LTEの適用例では、周波数分割複信(FDD)と時分割複信(TDD)の両方をサポートするために、OFDMがDL上で使用され、SC-FDMAがUL上で使用される。当業者が以下の詳細な説明から容易に諒解するように、本明細書で提示される様々な概念は、LTEの適用例にとって好適である。しかしながら、これらの概念は、他の変調技法および多元接続技法を利用する他の電気通信規格に容易に拡張され得る。例として、これらの概念は、エボリューションデータオプティマイズド(EV-DO)またはウルトラモバイルブロードバンド(UMB)に拡張され得る。EV-DOおよびUMBは、CDMA2000標準規格ファミリの一部として第3世代パートナーシッププロジェクト2(3GPP2)によって公表されたエアインターフェース標準規格であり、CDMAを利用して移動局にブロードバンドインターネットアクセスを提供し、エアインターフェースは、移動局とアクティブ基地局との間の無線ベースの通信リンクとして定義され得る。
【００２４】
これらの概念はまた、広帯域CDMA(WCDMA（登録商標）)およびTD-SCDMAなどのCDMAの他の変形形態を採用するユニバーサル地上波無線アクセス(UTRA)、TDMAを採用するモバイル通信用グローバルシステム(GSM（登録商標）)、ならびにOFDMAを採用する発展型UTRA(E-UTRA)、IEEE802.11(Wi-Fi)、IEEE802.16(WiMAX)、IEEE802.20、およびFlash-OFDMに拡張され得る。UTRA、E-UTRA、UMTS、LTE、およびGSM（登録商標）については、3GPP団体による文書に記載されている。CDMA2000およびUMBについては、3GPP2団体による文書に記載されている。採用される実際のワイヤレス通信規格および多元接続技術は、具体的な適用例およびシステムに課された全体的な設計制約に依存する。
【００２５】
eNB204、214は、MIMO技術をサポートする複数のアンテナを有してよく、5G向けに、複数のアンテナはマッシブMIMO技術をサポートする。MIMO技術の使用により、eNB204、214は空間領域を活用して、空間多重化、ビームフォーミング、および送信ダイバーシティをサポートすることが可能になる。空間多重化を用いて、同じ周波数上で異なるデータストリームを同時に送信することができる。データストリームは、データレートを向上させるために単一のUE206に送信されてよく、または、全体的なシステム容量を増大させるために複数のUE206に送信されてよい。このことは、各データストリームを空間的にプリコーディングし(すなわち、振幅および位相のスケーリングを適用し)、次いで、空間的にプリコーディングされた各ストリームを複数の送信アンテナを通してDL上で送信することによって実現される。空間的にプリコーディングされたデータストリームは、異なる空間シグネチャとともにUE206に到達し、これにより、UE206の各々は、そのUE206に向けられた1つまたは複数のデータストリームを回復することができる。UL上では、各UE206は、空間的にプリコーディングされたデータストリームを送信し、これにより、eNB204、214が、空間的にプリコーディングされた各データストリームのソースを識別することが可能になる。
【００２６】
空間多重化は一般に、チャネル状態が良好なときに使用される。チャネル状態がそれほど好ましくないとき、送信エネルギーを1つまたは複数の方向に集中させるためにビームフォーミングが使用され得る。このことは、複数のアンテナを通じた送信向けにデータを空間的にプリコーディングすることによって実現され得る。セルのエッジにおいて良好なカバレージを実現するために、単一ストリームビームフォーミング送信が、送信ダイバーシティと組み合わせて使用され得る。
【００２７】
以下の詳細な説明では、アクセスネットワークの様々な態様について、DL上でOFDMをサポートするMIMOシステムを参照しながら説明する。OFDMは、OFDMシンボル内のいくつかのサブキャリアにわたってデータを変調するスペクトル拡散技法である。サブキャリアは、厳密な周波数で離間される。離間は、受信機がサブキャリアからデータを回復することを可能にする「直交性」をもたらす。時間ドメインでは、OFDMシンボル間干渉をなくすために、各OFDMシンボルにガードインターバル(たとえば、サイクリックプレフィックス)を追加することができる。ULは、高いピーク対平均電力比(PAPR)を補償するために、DFT拡散OFDM信号の形でSC-FDMAを使用してもよい。
【００２８】
パケット交換ネットワークを含むネットワークは、複数の階層プロトコルレイヤにおいて構造化されてもよく、下位プロトコルレイヤは上位レイヤにサービスを提供し、各レイヤは異なるタスクを担当する。図3は、LTE実装形態におけるユーザプレーンおよび制御プレーン(すなわち、UプレーンおよびCプレーン)用の無線プロトコルアーキテクチャ300の例を示す図である。UEおよびeNBのための無線プロトコルアーキテクチャは、レイヤ1、レイヤ2、およびレイヤ3として示される3つのレイヤで構成される。レイヤ1(L1レイヤ)は最下位レイヤであり、様々な物理レイヤ信号処理機能を実装する。L1レイヤは、本明細書では物理レイヤまたはPHYレイヤ306と呼ばれる。レイヤ2(L2レイヤ)308は、物理レイヤ306の上にあり、物理レイヤ306を介してUEとeNBとの間のリンクを担当する。
【００２９】
ユーザプレーンでは、L2レイヤ308は、メディアアクセス制御(MAC)サブレイヤ310と、無線リンク制御(RLC)サブレイヤ312と、パケットデータコンバージェンスプロトコル(PDCP)サブレイヤ314とを含み、それらはネットワーク側でeNBにおいて終端される。PDCPサブレイヤ314は、異なる無線ベアラと論理チャネルとの間の多重化を行う。PDCPサブレイヤ314は、上位レイヤのデータパケットが無線送信オーバーヘッドを低減するためのヘッダ圧縮、データパケットを暗号化することによるセキュリティ、およびeNB間のUEのためのハンドオーバサポートも提供する。RLCサブレイヤ312は、上位レイヤのデータパケットのセグメンテーションおよびリアセンブリ、損失データパケットの再送信、ならびに、ハイブリッド自動再送要求(HARQ)、デュアル接続性動作、マルチ接続性動作またはキャリアアグリゲーション動作に起因して順序が乱れた受信を補償するデータパケットの並べ替えを実現する。MACサブレイヤ310は、論理チャネルとトランスポートチャネルとの間で多重化を行う。MACサブレイヤ310は、1つのセル中の様々な無線リソース(たとえば、リソースブロック)をUEの間で割り振ることも担当する。MACサブレイヤ310は、HARQ動作も担当する。
【００３０】
制御プレーンでは、UEおよびeNBに関する無線プロトコルアーキテクチャは、制御プレーン用のヘッダ圧縮機能がないこと、および制御プレーン用にPDCPサブレイヤ314中に完全性保護機能があることを除いて、物理レイヤ306の場合もL2レイヤ308の場合も本質的に同じである。制御プレーンは、レイヤ3(L3レイヤ)の中に無線リソース制御(RRC)サブレイヤ316も含む。RRCサブレイヤ316は、無線リソース(すなわち、無線ベアラ)を取得すること、およびeNBとUEとの間のRRCシグナリングを用いて下位レイヤを構成することを担当する。図示されていないが、UEは、L3レイヤ上にいくつかの上位レイヤを有することがあり、それらは、ネットワーク側のPDNゲートウェイ118において終端されるネットワークレイヤ(たとえば、IPレイヤ)、および接続の他端(たとえば、遠端UE、サーバなど)において終端されるアプリケーションレイヤを含む。
【００３１】
LTEネットワークにおけるRLCによる無線リンクセットアップは、eノードBおよびUEなど、2つの通信デバイスの間の1つまたは複数の無線ベアラ(たとえば、無線リンクもしくは無線接続、または無線接続における1つもしくは複数のパケットフロー)の確立を伴い得る。セッションベアラは、論理ベアラまたは論理チャネルであってもよく、その場合、無線リンクを介して確立されてもよく、セッションベアラを介して1つまたは複数のサービスおよび/または通信が確立されてもよい。ここで、「無線ベアラ」という用語は、LTEおよび他の4G技術におけるRLCに関連して使われているが、5Gおよびそれ以降のシステムにおいて、他の用語(たとえば、無線接続におけるパケットフロー)が使われてもよく、使われる場合もあることに留意されたい。したがって、等価な用語は、無線接続における「パケットフロー」または各IPアドレス、ベアラ、フローのアプリケーションなどに与えられる様々な指示を包含するように理解されるべき何らかの他の用語、すなわち、IPアドレスに基づいてフローを記述し、区別するのに使われる用語であろう。
【００３２】
図4は、LTEパケット交換ネットワークにおいて動作する通信デバイスに実装され得るプロトコルスタックの例を示す図である。この例では、LTEプロトコルスタック400は、物理(PHY)レイヤ404と、メディアアクセス制御(MAC)レイヤ406と、無線リンク制御(RLC)レイヤ408と、パケットデータコンバージェンスプロトコル(PDCP)レイヤ411と、RRCレイヤ412と、非アクセス層(NAS)レイヤ414と、アプリケーション(APP)レイヤ416とを含む。NASレイヤ414の下のレイヤは、しばしばアクセス層(AS)403と呼ばれる。
【００３３】
RLCレイヤ408は、1つまたは複数の論理チャネル410を含んでもよい。RRCレイヤ412は、接続状態とアイドル状態とを含む、ユーザ機器に関する様々な監視モードを実現してもよい。NASレイヤ414は、通信デバイスのモビリティ管理コンテキスト、パケットデータコンテキストおよび/またはそのIPアドレスを維持してもよい。プロトコルスタック400中に(たとえば、図示のレイヤの上、下、および/または中間に)他のレイヤが存在する場合があるが、簡潔および明快のために省略されていることに留意されたい。たとえばRRCレイヤ412および/またはNASレイヤ414において無線/セッションベアラ413が確立されてもよい。最初、通信デバイスへの通信または通信デバイスからの通信は、セキュアでない共通制御チャネル(CCCH)を介して送信され得る(保護されないか、または暗号化されずに)。NASレイヤ414は、セキュリティ鍵を生成するために通信デバイスおよびMMEによって使用されてもよい。これらのセキュリティ鍵が確立された後、シグナリングおよび/もしくは制御メッセージを含む通信が専用制御チャネル(DCCH)を介して送信されてよく、ならびに/またはユーザデータが専用トラフィックチャネル(DTCH)を介して送信されてもよい。NASコンテキストは、サービス要求時、アタッチ要求時、およびトラッキングエリア更新(TAU)要求時に再使用されてもよい。
【００３４】
図5は、アクセスネットワークにおいてUE550と通信しているeNB510のブロック図500である。UE550とeノードB510との間の無線インターフェースは、LTE-Uuと呼ばれ得る。より一般的には、Uuという用語は、4GまたはLTE以外の無線アクセス技術(RAT)を含む、UEとeノードBとの間の無線インターフェースリンクを指し得る。
【００３５】
UEへのダウンリンクまたは順方向リンク通信を実施するeノードB510では、たとえば、制御またはデータ情報を含む、コアネットワークからの上位レイヤパケットが、コントローラ/プロセッサ575に与えられる。コントローラ/プロセッサ575は、L2レイヤの機能性を実装する。さらに、コントローラ/プロセッサ575は、ヘッダ圧縮、暗号化、完全性保護、パケットのセグメンテーションおよび並べ替え、論理チャネルとトランスポートチャネルとの間の多重化、ならびに、様々な優先度メトリックに基づくUE550への無線リソース割振りを行う。コントローラ/プロセッサ575はまた、ARQまたはHARQ動作、損失パケットの再送信、およびUE550へのシグナリングを担当する。
【００３６】
送信(TX)プロセッサ516は、L1レイヤ(すなわち、物理レイヤ)のための様々な信号処理機能を実装する。信号処理機能は、UE550における前方誤り訂正(FEC)を容易にするためのコーディングおよびインターリービング、ならびに変調(たとえば、2位相シフトキーイング(BPSK)、4位相シフトキーイング(QPSK)、M位相シフトキーイング(M-PSK)、多値直交振幅変調(M-QAM))を含む。次いで、コード化および被変調シンボルは、並列ストリームに分離され得る。次いで、各ストリームは、OFDMサブキャリアにマッピングされ、時間領域および/または周波数領域において基準信号(たとえば、パイロット)と多重化され、次いで、逆高速フーリエ変換(IFFT)を使用して一緒に結合されて、時間領域OFDMシンボルストリームを搬送する物理チャネルを生成する。OFDMストリームは、複数の空間ストリームを生成するために空間的にプリコーディングされ得る。チャネル推定器574からのチャネル推定値が、コーディングおよび変調方式を決定し、ならびに空間処理を決定するために使用されてもよい。チャネル推定値は、UE550によって送信された基準信号および/またはチャネル状態フィードバックから導出されてもよい。次いで、各空間ストリームは、TX/RXトランシーバ518の別個の送信機を介して異なるアンテナ520に与えられる。トランシーバ518中の各送信機は、送信のためのそれぞれの空間ストリームを用いてRFキャリアを変調する。
【００３７】
UE550において、トランシーバ554の各受信機RXは、それぞれのアンテナ552を通して信号を受信する。トランシーバ554中の各受信機は、変調された情報をRFキャリア上に回復し、情報を受信(RX)プロセッサ556に与える。RXプロセッサ556は、L1レイヤの様々な信号処理機能を実装する。RXプロセッサ556は、情報に対して空間処理を実施して、UE550に向けられたあらゆる空間ストリームを回復する。複数の空間ストリームがUE550に向けられている場合、それらの空間ストリームはRXプロセッサ556によって単一のOFDMシンボルストリームに合成されてもよい。次いで、RXプロセッサ556は、高速フーリエ変換(FFT)を使用して、OFDMシンボルストリームを時間領域から周波数領域にコンバートする。周波数領域信号は、OFDM信号のサブキャリアごとに別個のOFDMシンボルストリームを含む。各サブキャリア上のシンボル、および基準信号は、eNB510によって送信された最も可能性の高い信号コンスタレーションポイントを判断することによって、回復され復調される。このような軟判定は、チャネル推定器558によって計算されたチャネル推定値に基づいてもよい。次いで、物理チャネル上でeNB510によって元々送信されたデータおよび制御信号を回復するために、軟判定が復号されデインタリーブされる。その後、データ信号および制御信号は、コントローラ/プロセッサ559に与えられる。コントローラ/プロセッサ559はL2レイヤを実装する。コントローラ/プロセッサは、プログラムコードおよびデータを記憶するメモリ560に関連付けられ得る。メモリ560は、コンピュータ可読媒体と呼ばれることがある。コントローラ/プロセッサ559は、コアネットワークからの上位レイヤパケットを回復するために、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、解読、RRCシグナリングのための完全性検査、ヘッダ圧縮解除、制御信号処理を行う。次いで、上位レイヤパケットは、データシンク562に与えられ、データシンク562は、L2レイヤの上のすべてのプロトコルレイヤを表す。様々な制御信号も、L3処理のためにデータシンク562に与えられ得る。コントローラ/プロセッサ559は、ARQまたはHARQ動作をサポートするために、確認応答(ACK)および/または否定確認応答(NACK)のプロトコルを使用する誤り検出も担当する。
【００３８】
アップリンクまたは逆方向リンク通信のために、データソース567は、上位レイヤパケットをコントローラ/プロセッサ559に与えるために使用される。データソース567は、L2レイヤの上のすべてのプロトコルレイヤを表す。eNB510によるDL送信との接続に関して説明した機能性と同様に、コントローラ/プロセッサ559は、ヘッダ圧縮、暗号化、パケットのセグメンテーションおよび並べ替え、ならびに、eNB510による無線リソース割振りに基づく論理チャネルとトランスポートチャネルとの間の多重化を行うことによって、ユーザプレーン用および制御プレーン用のL2レイヤを実装する。また、コントローラ/プロセッサ559は、HARQ動作、損失パケットの再送信、およびeNB510へのシグナリングも担当する。
【００３９】
eNB510によって送信された基準信号またはフィードバックからチャネル推定器558によって導出されたチャネル推定値は、適切なコーディングおよび変調方式を選択し、空間処理を容易にするために、TXプロセッサ568によって使用される場合がある。TXプロセッサ568によって生成された空間ストリームは、トランシーバ554中の別個の送信部分を介して異なるアンテナ552に与えられる。各送信部分は、送信のためのそれぞれの空間ストリームを用いてRFキャリアを変調することができる。
【００４０】
UE550からeNB510へのアップリンクまたは逆方向リンク送信は、それぞれのアンテナ520を通してトランシーバ518の受信機部分によって受信される。トランシーバ518の各受信機部分は、変調された情報をRFキャリア上に回復し、情報を受信(RX)プロセッサ570に与える。RXプロセッサ570は、L1レイヤを実装してもよい。コントローラ/プロセッサ575はL2レイヤを実装し得る。コントローラ/プロセッサ575は、プログラムコードおよびデータを記憶するメモリ576に関連付けることができる。メモリ576は、コンピュータ可読媒体と呼ばれることがある。受信されたアップリンク送信のために、コントローラ/プロセッサ575は、UE550から送信された上位レイヤパケットを回復するために、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、解読、RRCシグナリングのための完全性検査、ヘッダ圧縮解除、制御信号処理を行う。コントローラ/プロセッサ575からの上位レイヤパケットは、コアネットワーク(図示せず)に与えられ得る。コントローラ/プロセッサ575はまた、HARQ動作をサポートするためのACKおよび/またはNACKのプロトコルを使用する誤り検出を担当する。5Gのケースのために、各アンテナは1つまたは複数のアンテナであってもよく、各RFチェーンは1つまたは複数のRFチェーンであってもよい。
【００４１】
様々な場所においてネットワークアクセスが可能になり、ますます数が増しているモバイルフォンおよび/またはコンピューティングデバイスにワイヤレス通信機能が設けられているので、サービングネットワークへのアクセスの改善が引き続き要求されている。いくつかのアクセス技術では、異種ネットワーク環境が従来のラージセル(マクロセル)およびスモールセルをサポートすることができ、スモールセルは、認可および無認可スペクトル中で動作するとともに10メートルと2キロメートルとの間の範囲を有し得る低電力無線アクセスノードを通して設けられ得る。たとえばLTEアドバンストを含む4G 3GPP技術のいくつかの実装形態では、リレーノード(RN)が、セルエッジを含む、セル中の、およびホットスポット中の様々な場所において拡張カバレージおよび容量を提供するように展開され得る低電力基地局を含み得る。再度図2を参照すると、リレーノード208が、ラージセル212内に確立され得るスモールセル210中で拡張カバレージを提供し得る。RN208は、無線インターフェース(Un)を通してeNB214(ドナーeNB(DeNB)214)に接続されてよく、Unは、E-UTRANエアインターフェースUuの修正バージョンであり得る。ドナーセル212の無線リソースは、DeNB214によって直接サービスされるUE206とRN208との間で共有することができる。UuおよびUnは、同じ周波数または異なる周波数を使ってよい。
【００４２】
前述のように、無線リンク制御(RLC)レイヤ向けに、WCDMA（登録商標）またはLTEに従って動作可能なワイヤレスデバイス(たとえば、eノードBまたはUE)は、3つのRLCデータ転送モードまたは動作タイプ、すなわち透過モード(TM)、非確認応答モード(UM)、および確認応答モード(AM)のうちの1つで作動することができる。TMデータ転送のために、データは、他に何も供給されることなく、透過的に転送される。TMは、RLCサービスデータ単位(SDU)のいかなるデータのセグメンテーションまたは連結もサポートしないので、1つのRLCプロトコルデータ単位(PDU)が1つのRLC SDUに対応する。
【００４３】
UMでは、データ転送は、TMに加えていくつかの追加機能性で実現されるが、自動再送要求(ARQ)動作は提供しない。送信機側において、UMは、RLC SDUのデータのセグメンテーションおよび連結をサポートする。受信機側において、UMは、RLC SDUの重複回避、並べ替え、および並べ替えられたUMデータ(UMD)からの再アセンブルをサポートする。UMは、いかなるデータ受信確認応答および再送信も提供しない。
【００４４】
確認応答モード(AM)データ転送のために、UM機能性に加えてARQ機能性を用いてデータ転送が実施される。送信機側において、たとえば、AMは、RLC SDUのデータのセグメンテーションおよび連結をサポートし、AMデータ(AMD)の再送信もサポートするが、AMDは、受信機によって否定確認応答される。受信機側において、AMは、RLC SDUの重複回避、並べ替え、および並べ替えられたAMDからの再アセンブルをサポートし、AMD損失検出およびピアRLCエンティティへの、損失AMDについての再送信要求もサポートする。ARQ動作のために、受信機RLCエンティティは、ピアRLCエンティティ(すなわち、データが送信されているエンティティ)にステータス報告を送り、そうすることによって、送信機RLCエンティティは、どのAMDが再送信される必要があるか、およびどのAMDを送信機(たとえば、トランシーバ518のTX部分)中のTXバッファから消去すればよいかを解明することができる。ステータス報告の周期性は、所定の時間に対応する、カウンタ向けの事前構成された閾を用いて、カウンタによって制御することができる。
【００４５】
eノードBまたはUEなどのワイヤレスデバイスが、確認応答動作モード(AM)と非確認応答動作モード(UM)との間を切り替えるとき、発生し得るいくつかの問題がある。特に、デバイスは、AMで動作するとき、無線リンク制御(RLC)レイヤなどのプロトコルレイヤにおいて、無線ベアラ接続パケット損失回復およびパケット並べ替えを提供する。ワイヤレスデバイスがUMで動作するとき、デバイスは、無線ベアラ接続に対して、プロトコルレイヤにおいてパケット損失回復を提供しない。プロトコルレイヤはマルチレイヤプロトコルスタック中の1つのレイヤであってよく、プロトコルレイヤは、無線リンク制御(RLC)レイヤ、メディアアクセス制御(MAC)レイヤ、および/またはパケットデータコンバージェンスプロトコル(PDCP)レイヤである。第1のデバイスが、無線ベアラ接続により第2のデバイスに結合されてもよく、一方のデバイスの個々の動作モードが、他方のデバイスの動作モードに影響し得る。さらに、プロトコルレイヤにおいてパケット損失を回復し、かつ/または並べ替えるかどうかの判断が、RLC送信エンティティまたはRLC受信エンティティにおいて実施され得る。RLC AMは、(1)フロー制御および(2)自動再送要求(ARQ)機能性を提供するので、通常は高速データ転送のために構成され、この機能性は、信頼できる通信を確立する。ただし、RLC AM動作には、たとえば、再送信のために大型データバッファを必要とし、遅延したステータス報告のせいで、全体を通してARQ動作を低下させるなどの欠点がある。遅延したステータス報告は、たとえば、反対方向の送信フローについての不良無線条件、ステータス報告用の不良構成、または不良データスケジューラ実装により起こる場合があり、これらは、ユーザデータよりもステータス報告を優先させるわけではない。
【００４６】
一方、UM動作またはRLC UM動作は、上述した問題を回避する。実際、現実の実証シナリオでは、新規特徴をテストするためにUMがより頻繁に使われ、というのは、UMが、全体を通して高い速度を可能にし、公開されている全体的システムを、AMと比較すると、理論的最大スループットレベルにより容易に、およびより速く達するようにするからである。ただし、UMはARQ機能性をもたないので、データ転送のために常にUMで動作することが理想的でない場合がある。つまり、UM動作において、不良無線条件により欠落した紛失データパケットが回復されず、このことは、アプリケーションの全体的性能および信頼性に影響を及ぼし得る。AMデータ転送動作では、データ転送が両方向においてうまくいき、送信(TX)RLCおよび受信機(RX)RLCにおけるデータバッファが、所望のスループット向けに十分大きく、ステータス報告周期性が現在の無線条件およびバッファサイズ向けに理想的に構成されている場合にのみ、理論的最大スループットは達成され得る。それ以外の場合、図6に関連して論じるように、スループットは低下される。
【００４７】
図6は、送信機602と受信機604との間の対話を示すとともにAMオンリー動作の特定の制限をさらに示すタイミング図600を示す。送信ウィンドウは、図6では、8つのAMD信号である。送信機602は、一連の8つのAMD PDUまたは信号606を受信機604に送信する。この例では、ポールビットが1にセットされていると仮定され、ポールビット(P)は、受信機またはピアエンティティ(すなわち、この例では受信機604)に対する、ステータスについての要求(「1」のビット値をもつ)を指示するのに使われる。受信機604が、送信機602によって送信された第4のAMD PDUを受信すると、受信機604は、送信機602に第1の確認応答信号610を返送する。送信機602が、時間またはイベント608においてすべての8つのAMD PDUまたは信号を送信すると、バッファが満杯になるので送信が停止される。
【００４８】
さらに、送信機602がすべての8つのAMD PDU信号を送信したことに応答して、受信機604は第2の確認応答信号614を送信する。イベントまたは時間608からイベントまたは時間612まで、送信機602は、バッファ不足により非アクティブである。時間またはイベント612において、バッファは確認応答PDUを削除し、そうすることによって送信が再開し得る。したがって、イベント612において、送信機602はさらに4つのAMD信号を送信する。イベントまたは時間616において、送信機602が受信機604から第2の確認応答信号614を受信すると、バッファは、4つのAMD信号からなる次のグループの送信を続けるために、バッファから確認応答PDUを削除する。イベント608と612との間のギャップによってわかり得るように、8つのAMD信号を送信するためのスループットは低下され、というのは、バッファは、4つのAMD PDUまたは信号が送信され、確認応答された後でのみ、確認応答PDUを削除するからである。したがって、図6の全体的方式は、厳密にAMであるデータ転送動作の制限により、できる限り効率的に動作しているわけではない。
【００４９】
したがって、様々なRLCモードに対してスループットの低下を弱めるために、本開示は、スマートRLCモード切替え方式を提供するための少なくとも2つの異なるやり方で動作する新規RLCモード切替え方法および装置を提供する。第1の手法は、RLCエンティティがデバイスのRLCモードをAMモードとUMモードとの間で切り替える動的切替えを実施するものである。第2の手法は、送信機がビットまたはフラグを使って受信機バッファをフラッシュすることを可能にする新規合成AM/UMモードを定義するものである。新規合成AM/UMモードが第2の手法のために構成されると、RLCパケット中のRLCヘッダが、AMおよびUM動作モードの両方を、送信されたRLCパケットごとに切り替えさせるように拡張される。デバイスはまた、ピアRLCエンティティ中の送信RLCがパケットエラーレート(PER)および/またはパケット待ち時間を測定することができるように、UM動作モードにおいても継続ステータス報告を可能にする。[発明者に対する注記:第1の手法の動力は、RLCエンティティ自体にAM/UM切替えを制御させるとともに、さらにピアRLCに、モードを切り替えるようにも要求/シグナリングすることが可能なスキーマを提供することによって生じられるのか?PDU中のフィールド/ビットを通してモード切替えをどのように測定し、トリガし、変更し、シグナリングするかという具体的な詳細はともかく、大局概念的見地から、切替えをいつトリガするべきかをRLCエンティティに判断させることができると、AM/UMの間の従来技術切替えとは大幅に異なる何らかの利益がもたらされるのか?従来技術は、RLCエンティティが、AM/UMの間でいつ切り替えるべきか判断し、ピアにもそうするよう要求し得るためのいかなる手段も提供しなかったのか?また、動力は、様々なPDUヘッダ方式/ビット値を用いて、PDU単位でモード切替えをシグナリングすることができることにより、拡張することができるのか?]
【００５０】
本開示手法によってもたらされる、いくつかの利点がある。たとえば、送信機におけるデータ再送信のための、および受信機におけるデータ連結のための大規模データバッファはもはや必要ない。そうではなく、データバッファのサイズは、遅いスループット動作のために、再送信または連結向けに低減され得る。さらに、高速動作のために、フロー制御は適用されず(すなわち、UMが使用される)、したがって、システムは、いかなるRLCパラメータ微調整もなしで高スループットを容易に達成することができる。高スループットは、不良無線条件において信頼性を損なわずに達成することもでき、というのは、RLCエンティティは依然として、(たとえば、不良無線条件により)低速動作中にARQ手順を実施するからである。
【００５１】
図7は、本開示による、AMモードとUMモードとの間の切替えを示す状態図700である。これは、非確認応答モード状態702、第1のイベント切替え704、第1のイベント706、確認応答モード状態708、第2のイベント切替え710、および第2のイベント712を含む状態図700を示す。第1のイベント706は、UM状態702からAM状態708に状態を移すための第1のイベント切替え704をトリガし、第2のイベント712は、AM状態708からUM状態702への第2のイベント切替え710をトリガする。
【００５２】
図7に示す動的切替え手順は、性能を測定すること、測定された性能に少なくとも基づいてイベントトリガを判断すること、および次いで、モード切替え手順に従うことを含む様々な手順を使用することにより実行することができる。
【００５３】
性能測定に関して、一態様では、受信RLCエンティティは、受信スループットまたはデータパケット(たとえば、PDU)ドロップレートもしくはパケットエラーレート(PER)を、測定するためのメトリックとして測定することができる。別の態様では、送信RLCエンティティは、送信スループット、データパケット(たとえば、PDU)再送信のレート、否定確認応答PDUのレート(たとえば、パケットエラーレート(PER))、またはRLCエンティティの間の待ち時間や測定されたエンドツーエンドの待ち時間などのパケット待ち時間を測定することができる。RLCエンティティの間の待ち時間は、第1のRLCと第2のピアRLCとの間の時間遅延である。エンドツーエンドの待ち時間は、2つのデバイスのピア端の間の待ち時間である。たとえば、エンドツーエンドの待ち時間は、第1のデバイス(たとえば、モバイルデバイスのウェブブラウザ)の第1のピア端と、第2のデバイス(たとえば、ハイパーテキスト転送プロトコル(http)サーバ)の第2のピア端との間である。一実装形態では、2つの異なるデバイスの2つのピア端のアプリケーションレイヤが存在し得る。別の実装形態では、2つの異なるデバイスのアプリケーションレイヤは異なってもよく、またはアプリケーションレイヤは単に、一方のデバイス、もしくは両方のデバイスに存在しなくてよい。たとえば、第1のデバイスがモバイルデバイスであり、第2のデバイスが、eNB(進化型ノードB、ノードBまたは基地局)などのネットワークアクセスノードである場合、アプリケーションレイヤは、ネットワークアクセスノード中ではなく、モバイルフォンデバイス自体の中にのみ存在する。ネットワークアクセスノードのケースでは、アプリケーションレイヤは、ネットワークアクセスノード自体の中ではなく、インターネットのサーバ中に配置される。ユーザプレーン測定値をとることもでき、ユーザプレーン測定値は、データレート、バッファサイズ、PER、および/またはブロックエラーレート(BLER)を含む。他の測定対象は、送信制御プロトコル(TCP)によって測定される、エンドツーエンドのラウンドトリップ時間(RTT)、および紛失した、あるフロー用のパケットが、上位レイヤにフォワードされる他のフローすべてのためのトラフィックを妨げるケースに対して、無線ベアラ接続にわたって現時点でアクティブなフローの数を含み得る。さらに、送信RLCにおける、PERまたは待ち時間の測定を実施するために、送信RLCは、UM動作中であっても、ピアRLCエンティティから継続的ステータス報告を受信する。
【００５４】
測定された結果(たとえば、スループット、PER、または待ち時間)が、第1のイベント706または第2のイベント712用に設定された論理条件であり得るいくつかの基準を満足する場合、RLCエンティティは、RLCモードを切り替えるよう、ピアRLCエンティティに要求するか、または指示する。RLCエンティティは、「X」と呼ばれる、測定された結果を、いくつかの所定の基準に従って評価する。たとえば、測定された結果Xについてのいくつかの基準は、以下の不等式関係により得る。
不等式1:X-ヒステリシス>閾  (1)
不等式2:X+ヒステリシス<閾  (2)
上式で、閾は、知られている規格または経験的に判断された条件のいずれかに基づく所定の閾であり、ヒステリシスは、AMモードとUMモードとの間のあまりにも頻繁な切替えまたはピンポンを防止するための判断においてヒステリシスを導入するように構成された何らかの値または量である。
【００５５】
測定される特定の値またはオブジェクトは、上の式(1)および(2)における不等式のどちらが、UMからAMへの、またはその反対のRLC切替えをトリガするかに影響を及ぼす。たとえば、測定対象がスループットである場合、不等式1が、AMからUMへのRLC切替えをトリガし(すなわち、図7のイベント1(706)に類似)、不等式2が、UMからAMへの切替えをトリガする(すなわち、図7のイベント2(712)に類似)。一方、たとえば、測定対象がPERである場合、不等式1が、UMからAMへのRLC切替えをトリガし(すなわち、図7のイベント2(712)に類似)、不等式2が、AMからUMへの切替えをトリガする(すなわち、図7のイベント1(706)に類似)。
【００５６】
RLCエンティティが、上の基準の適用によって判断されたようにRLCモード切替えをトリガすると決めると、RLCモード切替え手順が始動される。この手順は、発信RLCエンティティが、他のモード(たとえば、AMからUM、またはUMからAM)によって動作し始めるための要求信号をピアRLCエンティティに送ることを含む。ピアRLCエンティティがこの要求信号を受信すると、ピアRLCエンティティは、確認応答信号またはメッセージ(たとえば、ACKメッセージ)の送信を通して、発信RLCエンティティに対して、要求信号の受信成功に確認応答する。発信RLCエンティティが確認応答メッセージを受信した後、発信RLCエンティティは、新規モードにより動作し始める。
【００５７】
ある態様によると、送信または発信RLCエンティティが、このモード切替え手順においてパケットエラーレート(PER)またはパケット待ち時間を測定すると、ピアRLCエンティティは、UM動作モードにおいても、送信RLCへの継続的ステータス報告を実施し得ることに留意されたい。モード切替え要求を送り、確認応答を折り返し受信するこの手順において、ピアRLCエンティティは、非確認応答メッセージ(たとえば、NACKメッセージ)を送り返すことによって、モード切替えについての要求を拒否し得ることが可能であることにも留意されたい。
【００５８】
別の態様によると、上述した手順において、RLCモード切替えシグナリングの成功を保証しようとするための措置がとられ得る。特に、追加タイマーまたはカウンタを利用すればよい。たとえば、1つのソリューションは、発信RLCエンティティにおける、要求の送付から確認応答の受信までに経過する時間を測定するためのタイマーである(たとえば、これは、「t-ModeSwitch」と呼ばれる場合がある)。したがって、このタイマーは、確認応答の受信が長くかかり過ぎるかどうか判断し、確認応答があまりにも長く遅延されるようである場合、適切なアクションをとるのに使うことができる。たとえば、受容可能な所定の時間制限以内にピアエンティティからRLCモード切替えACK信号が受信されると、タイマーは停止される。一方、タイマーが満了した場合、RLCエンティティは、ピアエンティティにRLCモード切替え要求を再送信すればよい。
【００５９】
別のソリューションは、モード切替え要求の数(たとえば、「number_of_MS」と呼ばれる)をカウントするカウンタをさらに利用することであろう。不成功モード切替え要求の数が、所定の数または最大限度を満たすか、または超える場合、カウンタは、各不成功要求(たとえば、t-ModeSwitchタイマーの満了の後に判断される)の後で増分される(または所定の値からゼロに向かって減分される)。モード切替え要求の数が最大限度に達した場合、メインRLCエンティティは、このエラーを上位レイヤに報告すればよく、そうすることによって、上位レイヤは、例として、無線ベアラ解放または呼再確立など、必要なアクションをとることができる。
【００６０】
図8は、発信RLCエンティティ802とピアRLCエンティティ804との間の対話を示すタイミング図800を示す。メインRLCエンティティ802は、時間またはイベント806において、現在のRLCモードを変更するかどうか判断する。切り替え先の新規RLCモードについての情報を運ぶRLCモード切替え要求808が、発信RLCエンティティ802からピアRLCエンティティ804に送られる。ある態様では、要求808の送付により、時間またはイベント810において、タイマー(たとえば、開示した「t-ModeSwitch」)も開始され得る。
【００６１】
ピアRLCエンティティ804がRLCモード切替え要求808を受信すると(かつ、ピア804が要求808に従うと仮定すると)、ピアRLCエンティティ804は、以前のRLCモード動作を停止し、要求されたRLCモード動作(たとえば、AMからUMへの切替え)を開始する。ピアRLCエンティティ804は次いで、発信RLCエンティティ802にRLCモード切替え確認応答ACK814も送信する。ACK信号814を受信すると、発信RLCエンティティは、この態様がシステムにおいて使用されるべきである場合、時間またはイベント816において示されるように、t-ModeSwitchタイマーを停止し得る。ある態様では、ACK814が受信されない(または、代替として、ピアエンティティ804によってNACK信号が送られた)場合、タイマーt-ModeSwitchはタイムアウトしてよく、モード切替え要求808の再送信が行われてよい。別の態様では、モード切替え要求808がピアRLCエンティティ804に送られる回数をカウントするための、上で論じたカウンタが使用されてもよく、このカウンタ向けの最大限度に達すると、適切なアクションがとられる。t-ModeSwitchタイマーが使われるかどうかにかかわらず、発信RLCエンティティ802がピアエンティティ804からACK信号814を受信すると、エンティティ802は、イベントまたは時間818によって示されるように、その以前のRLCモード動作を停止し、イベント806において判断されたRLCモードにより動作し始める。
【００６２】
さらなる態様によると、および上で言及したように、ピアRLCエンティティ804は、RLCモード切替え確認応答814中に否定確認応答(NACK)情報をもつ確認応答メッセージを送り返すことによって、RLCモード切替え要求808を拒否することができる。代替として、RLCモード切替え要求808を許可または拒否するために肯定確認応答メッセージ(ACK)または否定確認応答メッセージ(NACK)を使うのではなく、モード切替え要求確認応答メッセージが、RLCモード切替え要求を許可するのに使われてよく、モード切替え要求失敗メッセージが、RLCモード切替え要求を拒否するのに使われてよい。さらに、他の態様では、RLCモード切替え要求808および/またはRLCモード切替え確認応答814は、無線リンク制御(RLC)レイヤステータスプロトコルデータ単位(PDU)、無線リソース制御(RRC)メッセージ、無線リンク制御(RLC)レイヤPDU中のビット、パケットデータコンバージェンスプロトコル(PDCP)ステータスPDU、PDCPデータPDU中のビット、メディアアクセス制御(MAC)制御要素、またはMAC PDU中のビット内で送られ得る。
【００６３】
図9は、第1のデバイス902と第2のデバイス904(たとえば、それぞれのRLCエンティティを有する第1および第2のデバイス)との間のデータ転送および受信フローを示す図解900を示す。第1のデバイス902は、第1の確認応答モード(AM)無線リンク制御(RLC)送信ユニット906、および第1のAM RLC受信ユニット908を含む。第2のデバイス904は、第2のAM RLC送信ユニット910および第2のAM RLC受信ユニット912を含む。デバイスデータ転送914は、第1のAM RLC送信ユニット906から第2のAM RLC受信ユニット912へ流れる。ステータス報告転送916は、第2のAM RLC送信ユニット910から第1のAM RLC受信ユニット908へ流れる。第1のデバイス902および/または第2のデバイス904は、モバイルデバイス、もしくはネットワークアクセスノード(eNB)、または図8に示す発信RLCエンティティ802およびピアRLCエンティティ804など、異なるRLCエンティティであってよい。デバイスデータ転送914において、第1のAM RLC送信ユニット906は、第1のデバイスまたは第2のデバイスがどの動作モードを採用するべきか、設定調整、性能データなどについての指示を含み得るデータを第2のAM RLC受信ユニット912に送る。ステータス報告転送916において、第2のAM RLC送信ユニット910は、デバイスデータ転送914において送られた初期データ受信に確認応答するステータス報告、または他の確認応答データなどの情報を、第1のAM RLC受信ユニット908に送信する。
【００６４】
当業者には理解されるように、本開示は、少なくとも2つのタイプのRLCモード切替えを包含することが想定され得る。第1のタイプは、「双方向」モード切替えタイプであり、図8の例でのように、発信エンティティとピアエンティティの両方がRLCモードを切り替える。第2のタイプは、「単方向」モード切替えタイプであってよく、RLCエンティティの間のアップリンクまたはダウンリンクのいずれかが変更される。この場合、RLCエンティティの受信側がモードを切り替えると決めた場合であっても、RLCエンティティの送信側は、以前のRLCモード動作に従って動作を続けることができる(たとえば、アップリンク用にUMのようなモードが動作中の間、ダウンリンク用にはAMモードが動作中であり、またはその反対も同様である)。
【００６５】
図9は、第2のAM RLC送信ユニット910が今では、上で言及したデータトランザクションのデータ受信に確認応答し、そのデータ受信を反映するステータス報告を生成し、以前は第1のAM RLC受信ユニット908だった今の第1のUM RLC受信ユニット908(UMモードで動作している)に送信する第2のUM RLC送信ユニット910(やはりUMモードで動作する)であることを除いて、第1のAM RLC送信ユニット906(AMモードで動作する)が第2のAM RLC受信機ユニット912(やはりAMモードで動作している)にデータを送信する単方向モード切替えをサポートするように示され得る。
【００６６】
その上、図9は、第1のデバイスにおけるRLC送信機906が、AM動作のためのPDUをバッファリングする送信バッファ918を含み得ることも示す。相関的には、データ転送914の受信機側において、受信機RLCは、着信PDUをバッファリングする受信バッファ920を含む。図示されていないが、送信および受信ユニット910および908も、それぞれの送信および受信バッファを含み得る。
【００６７】
さらに、図8に示すRLCモード切替え要求808およびRLCモード切替え確認応答814をシグナリングするための、少なくとも2つのやり方があることに留意されたい。ある態様では、信号808および814によって遂行されるシグナリングは、データPDU中の帯域内シグナリングまたはステータスPDUシグナリングのいずれかを使って遂行され得る。この概念を記述するのを促進するために、図10は、信号808または814の帯域内シグナリングを実装するのに使うことができる例示的なRLCデータPDU構築を示す。帯域内シグナリングを用いると、RLCモード切替えコマンドは、RLCデータプロトコルデータ単位(PDU)によってシグナリングされる。この目的のために、本開示は、RLCデータPDUヘッダ内に新たなフィールドを設ける。特に、このフィールドは、たとえば、新規RLCモード情報をもつ、RLCモード切替え要求808、または反対方向ではRLCモード切替え確認応答814をシグナリングするのに使われるモード切替え要求または確認応答フィールドを定義する。図10においてわかり得るように、RLCデータPDU1000は、各々が8ビット(すなわち、1バイト)からなるN個のオクテットでフォーマットされる。RLC PDUは、8ビットまたはオクテットのN倍の長さをもつビットストリングであり、図10のこのビットストリングの表現は、テーブルの形で示されていることに留意されたい。
【００６８】
第1のオクテット1002(すなわち、Oct 1)は、オクテット中にいくつかのビットフィールドを有するヘッダ情報を含む。オクテット1002中の2つのビットからなる第1のフィールド1004は、モード切替え(MS)要求(または、ピアから発信RLCエンティティへの確認応答のケースでは、確認応答フィールド)の導入されたシグナリングである。別のフィールド1006は、AMまたはUMなど、特定のモードを示すモード信号フィールドである。第1のオクテット1002は、サービスデータ単位(SDU)など、より高レベルのデータ編成に関して、またはその中での、この特定のRLCデータPDUの相対ロケーションを指示するために使われるフレーミング情報(FI)フィールド1008も含み得る。オクテット1002は、特定のRLCデータPDU1000が拡張ビットを有するかどうか、およびユーザデータがRLCヘッダの直後に続くかどうか、またはRLCヘッダ、およびPDUのシーケンス中のどこにPDUが入るかを指示するシーケンス番号(SN)フィールド1012の後に長さインジケータ(図示せず)が存在するかどうかを示す拡張ビットフィールド(E)1010も含む。シーケンス番号(SN)は一般に、2つより多いビットであり得るので、第2のオクテット1014がSNに続く。結局、PDUのデータは、残っているN個のオクテット1016中に含まれる。図10は、各フィールド中に特定の数のビットを有する、PDU1000中の様々なフィールドを示すが、シグナリングが、将来の実装において所望されるように、より多くのまたはより少ないビットを求めるようである場合、フィールド長は、そのようなものに必ずしも限定されないことに留意されたい。
【００６９】
図8に示すRLCモード切替え要求808およびRLCモード切替え確認応答814をシグナリングするための、企図される第2のやり方に関して、シグナリングは、RLCステータスPDUを用いて遂行することもできる。図11は、そのようなシグナリングに使われる例示的なステータスPDU1100を示す。ステータスPDU1100は、PDU1100の第1のオクテット1102中に3つのフィールドを有して示されている。第1のフィールド1104はD/Cビットであり、このビットは、PDUがデータそれとも制御PDUであるかを示す。このPDU向けに、ビットは、PDU1100が制御PDUであることを示す値(通常、「0」)になり、そのステータスPDUは、あるタイプの制御PDUである。次のフィールドは、本例において、RLCモード切替えコマンド(たとえば、要求808またはACK814)をさらにシグナリングするのに使われる制御PDUタイプ(CPT)フィールド1106である。具体的には、少なくとも2つのCPT値が、本例に従って、それぞれのRLCモード切替え要求(たとえば、808)、およびRLCモード切替えACK(たとえば、814)向けに定義される。CPTフィールド1106のビットが、たとえば、発信エンティティからピアエンティティへの要求(たとえば、要求808)を指示するようにセットされると、RLCモードフィールド1108は、RLCモード切替えの後でどのRLCモード(たとえば、AMまたはUM)が使われるかを指示するビットを含むことになる。反対方向(たとえば、ACK814)では、CPTフィールド1106の値は、RLCモード切替えが確認応答されることを指示するようにセットされる(RLCモードフィールドは、必ずしも必要とされないが、ある態様では、さらなる確認応答として、折り返し指示されてもよい)。
【００７０】
RLCエンティティ(たとえば、802および804、または902および904)内でRLCモード切替えを実現するための手順または機構に関して、モード切替えは、新規RLCモードに切り替えるとき、以前のRLCモード用にセットされた状態変数、カウンタ、およびタイマーのうちの1つまたは複数をリセットすることを伴うことが、当業者には理解されよう。
【００７１】
確認応答モード(AM)で動作するエンティティに関して、そのようなRLCエンティティは、影響を受ける少なくともLTEシステムにおいて、いくつかの状態変数、カウンタおよびタイマーを有する。本開示方法および装置は、5G技術およびそれ以降のものに適用可能であり、最も可能性が高い類似変数、カウンタおよびタイマーが、そのようなシステムにおいて定義されることに留意されたい。したがって、5Gにおいて実装される切替え手順は、相関機能状態変数、カウンタ、およびタイマーをリセットすることを伴うことになる。
【００７２】
LTEに関して、一例では、3GPP仕様において定義されている、AM RLCエンティティの送信側における、影響を受ける状態変数は、変数VT(A)、VT(MS)、およびVT(S)を含み、VT(A)は確認応答状態変数を表し、VT(MS)は最大送付状態変数を表し、VT(S)は送付状態変数である。AM RLCエンティティの受信側において影響を受ける変数は、受信状態変数であるVR(R)、最大受容可能受信状態変数であるVR(MR)、t_Reordering状態変数であるVR(X)、最大STATUS送信状態変数であるVR(MS)、および最も高い予想状態変数であるVR(H)という状態変数を含む。さらに、送信AM RLCエンティティにおいて影響を受けるカウンタは、ポール送付状態変数であるPOLL_SN、t-StatusProhibit用に使われるカウンタであるPDU_WITHOUT_POLL、t-StatusProhibitとともに使われるカウンタであるBYTE WITHOUT_POLL、および再送信の数のカウンタであるRETX_COUNTを含み得る。
【００７３】
さらに、送信AM RLCエンティティ中で影響を受けるタイマーは、AM RLCエンティティの送信側によって、ポールビットを再送信するのに使われるタイマーであるt-PollRetransmitを含む。受信側では、影響を受ける、ピアAM RLCエンティティ用のタイマーは、受信側AM RLCエンティティおよび受信UM RLCエンティティによって、下位レイヤにおけるRLC PDUの損失を検出するのに使われるタイマーであるt-Reorderingタイマーと、AM RLCエンティティの受信側によって、ステータスPDUの送信を禁じるために使われるタイマーであるt-StatusProhibitタイマーとを含む。
【００７４】
したがって、モード変更動作が実行されると、AM RLCエンティティの送信側は、状態変数およびカウンタをすべてリセットし、送信側タイマーを停止する。AM RLCエンティティの受信側は、状態変数をすべてリセットし、タイマーを停止する。t-Reorderingタイマーが、モード変更が起きたことにより稼動中である場合、AM RLCエンティティの受信側は、並べ替え動作を停止し、直ちに、並べ替えられたRLC PDUからRLC SDUをアセンブルし、RLC SDUを配信すると同時に、RLC SDUにアセンブルすることができなかった、残っている確認応答モードデータ(AMD)を破棄する。ただし、上記は、UM動作中のステータス報告のために影響され得る。一例として、送信RLCが、このステータスPDUシグナリング手順においてパケットエラーレート(PER)または待ち時間を測定するために、ピアRLCエンティティは、UM動作モードであっても、送信RLCへの継続的ステータス報告を実施するべきである。
【００７５】
非確認応答モード(UM)で動作するエンティティに関して、そのようなRLCエンティティも、少なくとも影響を受けるLTEシステムにおいて、いくつかの状態変数、カウンタおよびタイマーを有する。本開示方法および装置は、5G技術およびそれ以降のものに適用可能であり、最も可能性が高い類似変数、カウンタおよびタイマーが、そのようなシステムにおいて定義されることにも再度留意されたい。したがって、5Gにおいて実装される切替え手順は、相関機能状態変数、カウンタ、およびタイマーをリセットすることを伴うことになる。
【００７６】
UM RLCエンティティは、送信側において、リセットされることになるいくつかの状態変数を維持する。これらの変数は、LTEのための3GPP仕様において定義されるように、次の新規生成UMD PDUに割り当てられるべきシーケンス番号(SN)の値を保持する状態変数であるVT(US)を含む。この変数は通常、最初は0にセットされ、UM RLCエンティティがSN=VT(US)であるUMD PDUを配信すると常に更新される。受信側では、UM RLCエンティティの状態変数は、少なくとも、UM受信状態変数であるVR(UR)、UM t-Reordering状態変数であるVR(UX)、およびUM最高受信状態変数であるVR(UH)という状態変数を維持する。時間に関して、受信側UM RLCエンティティは、AM RLCエンティティおよび受信UM RLCエンティティの受信側によって、下位レイヤにおけるRLC PDUの損失を検出するのに使われるタイマーであるタイマーt-Reorderingを含む。モード変更が起こると、UM RLCエンティティの送信側は、状態変数をすべてリセットし、UM RLCエンティティの受信側は、状態変数をすべてリセットし、タイマーt-Reorderingを停止する。t-Reorderingタイマーが、モード変更が起きたことにより稼動中である場合、UM RLCエンティティの受信側は、並べ替え動作を停止し、直ちに、並べ替えられたRLC PDUからRLC SDUをアセンブルし、RLC SDUを配信すると同時に、RLC SDUにアセンブルすることができなかった、残っている確認応答モードデータ(AMD)を破棄する。RLCエンティティの送信機側およびRLCエンティティの受信側は、図8に関連して前に論じた初期化手順の後、新規RLCモード動作を開始する。
【００７７】
図8〜図11に関する、これまでの開示では、性能をより良く最適化するために、RLCエンティティ用にAMとUMとの間を動的に切り替えるための例示的な方法および装置について論じた。前述したような別の例示的な手法は、RLCエンティティの送信または発信側が、RLCデータPDU中で送信機状態を指示するとともに、ピアRLCエンティティの受信側が、RLC PDUのヘッダ中のポールビット(P)とバッファビット(B)の組合せに従ってRLCデータPDUを扱う、RLCの合成AM/UMモードを使用するものである。
【００７８】
図12は、本開示による、合成AM/UMモードを実現するのに使われる例示的なRLC PDU構造1200を示す。PDU1200は、データ/制御(D/C)ビットフィールド1204、ポールビット(P)フィールド1206、バッファビット(B)フィールド1208、予約済みビットフィールド1210、拡張ビット(E)フィールド1212、およびシーケンス番号(SN)フィールド1214を含むヘッダデータを、第1のオクテット1202中で採用する。前に論じたように、D/Cビット1204は、RLC PDU1200が、RLC制御シグナリング(たとえば、ステータスPDU)それともデータ用であるかどうかを指示する。ポールビット(P)フィールド1206は、RLCポールビット(P)を表し、送信機が、ステータス報告を送るよう、受信機に要求するかどうかをシグナリングする。バッファビット(B)フィールド1208は、RLCバッファビット(B)を表し、PDUのバッファリングに関して、RLCデータPDUがどのように扱われるべきかをシグナリングする。予約済みフィールド1210は、RLCデータPDU1200用の予約済みビットである。拡張ビット(E)フィールド1212は、ユーザデータがRLCヘッダのすぐ後に続くかどうか、またはRLCヘッダの後に長さインジケータ(LI)が存在するかどうかを示す。シーケンス番号フィールド1214は、現在のRLCデータPDUに関連付けられたRLCシーケンス番号(SN)と、PDUのシーケンス中のどこにPDUが入るかを指示する。シーケンス番号(SN)は一般に、2つより多いビットであり得るので、第2のオクテット1216がヘッダ情報内でSNを続ける。結局、PDUのデータは、残っているN個のオクテット1218中に含まれる。図12は、各フィールド中に特定の数のビットを有する、PDU1200中の様々なフィールドを示すが、シグナリングが、将来の実装において所望されるように、より多くのまたはより少ないビットを求めるようである場合、フィールド長は、そのようなものに必ずしも限定されないことに留意されたい。
【００７９】
前に論じたように、発信RLCエンティティは、PDU1200などのRLCデータPDU中で送信機状態を指示し、ピアRLCエンティティの受信側は、RLC PDUのヘッダ中に位置するポールビット(P)1206とバッファビット(B)1208の組合せに従って、RLCデータPDUを扱う。これらのビット値を受信すると、受信機またはピアRLCエンティティは、4つの異なる状態を通信する2つのビット(すなわち、PおよびBビット)があるので、4つのやり方のうちの1つで作用し得る。これらの具体的なアクションを、以下のTable 1(表1)に示す。
【００８０】
【表１】
2018509026.tif 000003
【００８１】
Table 1(表1)の最初の2行は、受信機RLCエンティティにおいて一般に見られる既存のAM挙動を本質的に定義する。特に、Table 1(表1)の第1行は、Pビットが、ステータス要求なしを指示するゼロであり(P=0)、Bビットが、バッファリングを指示する1である(B=1)場合、受信したRLCデータは、受信機においてバッファリングされ、順序通りに、受信エンティティ中の上位レイヤにフォワードされることを示す。さらに、受信側が何らかの紛失RLCデータPDUを検出し、t-Reordering(AM)タイマーが満了したとき、受信RLCエンティティは、RLC PDUステータスを送信機に指示する。Table 1(表1)の第2行に示すケースにおいて、ステータス要求を指示するP=1であり、バッファリングを指示するB=1である。この状況において、受信機は、受信したRLCデータを最初にバッファリングし、データを、順序通りに、上位レイヤにフォワードすることによって応答する。この状況において、P=1なので、受信機はまた、RLC PDUステータスを送信機に指示する。
【００８２】
Table 1(表1)の最後の2行は、受信機におけるUMモード挙動を定義するが、通常UMモードに対して付加情報または修正がある。特に、P=0およびB=0である、Table 1(表1)の第3行は、受信したデータを上位レイヤにフォワードすることを含み、紛失パケットのRLC回復および上位レイヤへの順序配信を可能にするためのバッファリングは実施されない。この場合、パケットを並べ替えることは、上位レイヤに任される。さらに、本開示は、新規挙動を値P=0およびB=0であることによるものとし、受信機は随意に、何らかの紛失RLCデータPDUが検出され、t-Reordering(UM)タイマーが満了したとき、RLC PDUステータスを報告してよい。
【００８３】
Table 1(表1)の第4行は、P=1、B=0の場合、受信されたデータが、受信機エンティティにおける上位レイヤにフォワードされることを示す。さらに、紛失パケットのRLC回復および上位レイヤへの順序配信を可能にするためのバッファリングは実施されない。この場合、パケットを並べ替えることは、上位レイヤに任される。本開示は、RLC受信機エンティティがRLC PDUステータスを送信機エンティティに指示する、これらの値に起因する新規挙動も定義する。したがって、RLC送信機は随意に、RLC受信機をポーリングし、紛失パケットを再送信してよい。
【００８４】
Table 1(表1)における上記プロセスに対する仮定は、UEが依然として、HARQ、デュアル/マルチ接続性および/またはキャリアアグリゲーション(CA)動作による順序ずれ配信を吸収するように短い持続時間で並べ替えを実施することであり得る。さらに、送信RLCが、この合成AM/UMモードで、バッファおよびポールビットを使ってパケットエラーレート(PER)または待ち時間を測定するために、ピアRLCエンティティは、UM動作モードであっても、送信RLCへの継続的ステータス報告を実施するべきである。
【００８５】
図13は、開示する合成AM/UM動作中に起こる、発信RLCエンティティ1302と受信またはピアRLCエンティティ1304との間の対話を示すタイミング図1300を示す。発信RLCエンティティ1302などのRLCエンティティが、イベントまたは時間1306において示されるようにRLCモード変更を判断すると、エンティティ1302は、新規RLC動作モードに従って動作し始めるように構成される。発信RLCエンティティ1302は次いで、PおよびBビットフィールド(1206、1208)をセットすることにより、送信1308によって示されるように他の新規モード(たとえば、AMまたはUMのいずれか)に切り替えるように指示する、PDU1200などのRLCデータPDUを送信する。たとえば、RLCエンティティ1302が、受信RLCエンティティ1304向けに、バッファリングまたは順序配信なし(たとえば、UM)に切り替えると判断すると、送信または発信RLCエンティティ1302は、バッファビットB1208を、送信されるべき(たとえば、1308)RLCデータPDU(たとえば、1200)中で、UM用の所定の値(たとえば、Table 1(表1)において指示されるように「0」)にセットすることによって、変更を指示する。さらに、送信または発信RLCエンティティ1302は、どのPDUも再送信する必要がない(たとえば、Bビット=0)と判断した場合、RLCデータPDUのバッファリングを停止してよいことに留意されたい。
【００８６】
受信またはピアRLCエンティティがRLCデータPDU1308を受信すると、RLCデータは、指示されたモードに従って扱われ、同時に、イベントまたは時間1310において指示されるように、新規RLCモード動作が開始される。ある例では、BビットがUM値にセットされた(たとえばB=0)場合、ピアRLCエンティティ1304は、UM動作用に構成されたt-Reorderingタイマーを使い始め、すなわち、タイマーは、AMタイマーよりも短いタイマー持続時間で構成され、これにより、より小さい受信バッファの使用が可能になる。ピアRLCエンティティ1304は次いで、送信1312によって指示されるように、戻りRLCデータPDUを送る。発信RLCエンティティ1302がデータPDU送信1312を受信した後、エンティティ1302は、イベントまたは時間1314において指示されるように、受信またはピア側において、RLCデータPDUを、指示されたモードのデータPDUとして扱う。ある態様では、送信1312は、一致する補足指示信号を信号1308に構成し、ここでピアRLCエンティティは、発信RLCエンティティに(または他のRLCエンティティにも)戻すモード切替え情報を含んでいる。
【００８７】
別の態様によると、RLCエンティティがUMからAMへの切替えを判断すると、送信機RLCエンティティ1302は、送信されるべきRLCデータPDU中で、BビットをAM用の所定の値(たとえば、「1」)にセットすることによって、変更を指示し、バッファBビットが、ピアRLCエンティティがPDUの再送信を要求し得るようなAM値用にセットされたとき、RLCデータPDUをバッファリングし始める。ピアRLCエンティティの受信側が、モードフィールドがAM値(たとえば「1」)にセットされたRLCデータPDUを受信すると、ピアRLCエンティティは、たとえば、受信したRLCデータPDU中のポーリングビットがセットされたとき、および/またはピアRLCエンティティの受信側が、何らかの紛失RLCデータPDUを検出したとき、ステータス報告を生成し始め、また、AM動作用に構成されたt-Reorderingタイマー(受信側が、再送信されたRLC PDUならびに以前受信したRLC PDUからRLC SDUを再アセンブルすることができるように、UM動作よりも長いタイマー持続時間で構成される)を使い始める。ピアRLCエンティティは、送信RLCがパケットエラーレート(PER)および/または待ち時間を測定することができるように、UM動作モードにおいてもステータス報告を生成する必要があり得ることにも留意されたい。
【００８８】
図14は、本明細書で開示した1つまたは複数の機能を実施するように構成され得るワイヤレスデバイス1400の例示的なハードウェア実装形態を示すブロック図である。デバイス1400は、例として、UEまたはeNBの一構成であり得る様々な回路構成および/または論理を含む。デバイス1400は通信インターフェース回路構成1402を含み、これは送信機回路構成1404および受信機回路構成1406を含み得る。通信インターフェース回路構成1402は、アンテナまたは様々なアンテナアレイ(図示せず)を通して、ネットワーク(たとえば、図1のネットワーク104)との間で様々な信号を送り、受信するようにさらに構成される。通信インターフェース回路構成1402は、送信および受信回路構成1404、1406とともに、LTEプロトコルスタック(たとえば、図3参照)などのプロトコルスタックにおける様々なプロトコルレイヤの少なくとも部分的実装を含むが、それに限定されない様々な機能を実現するためのデジタル信号処理(DSP)回路構成または論理を含み得ることにさらに留意されたい。
【００８９】
さらに、デバイス1400は、アプリケーションレイヤ処理、ならびに他の処理を含み得るとともに、いくつかの事例ではプロトコルスタックのいくつかの部分を実装するためでもある処理回路構成1408を含む。さらに、デバイスは、処理回路構成1408または他の計算装置によって実行可能な様々な命令またはコードを記憶するためのメモリデバイスまたは記憶媒体1410を含む。その上、デバイス1400は、概してバス1412によって表されるバスアーキテクチャまたは同様の通信結合を有して実装され得る。バス1412は、処理回路構成1408、通信インターフェース回路構成1402の具体的な用途および全体的な設計制約に応じて、任意の数の相互接続するバスならびにブリッジを含んでもよい。図示のように、バス1412は、通信インターフェース回路構成1402、処理回路構成1408、メモリデバイス1410、および随意のユーザインターフェース1414を含む様々な回路構成を互いにリンクさせる。
【００９０】
メモリデバイス1410は、大容量記憶デバイスを含んでよく、コンピュータ可読媒体およびプロセッサ可読媒体とも呼ばれ得る。バス1412は、タイミングソース、タイマー、カウンタ、周辺機器、電圧調整器、および電力管理回路(図示せず)などの様々な他の回路をリンクさせてもよい。デバイス1400の性質に応じて、ユーザインターフェース1414(たとえば、キーパッド、ディスプレイ、スピーカー、マイクロフォン、ジョイスティック、タッチパネルなど)も備えられてよく、バス1412に通信可能に結合されてもよい。
【００９１】
本開示の他の様々な態様によると、本明細書で開示するような要素、または要素の任意の部分、または要素の任意の組合せは、処理回路構成1408を使って実装されてもよい。処理回路構成1408は、ハードウェアモジュールとソフトウェアモジュールの何らかの組合せによって制御される1つまたは複数のプロセッサを含んでもよい。使用され得るプロセッサの例には、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、特定の機能を特に実施するように構成された特定用途向け集積回路(ASIC)、システムオンチップ(SOC)、状態機械、シーケンサ、ゲート論理、個別ハードウェア回路、または本開示全体に記載される様々な機能性を実施するように構成された他の適切なハードウェアが含まれる。
【００９２】
処理回路構成1408は、少なくとも部分的に、バス1412を管理すること、およびメモリデバイス1410中に存在し得るコンピュータ可読媒体に記憶されたソフトウェアの実行を含み得る一般的な処理を担当してもよい。この点において、処理回路構成1408は、本明細書で開示する方法、機能および技法のうちのいずれかを実装するのに使われてもよい。その上、処理回路構成1408はソフトウェアを実行することができる。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、または他の名称で呼ばれるかどうかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行ファイル、実行スレッド、プロシージャ、関数、アルゴリズムなどを意味するように広く解釈されるべきである。ソフトウェアは、コンピュータ可読の形でメモリデバイス1410の中、またはある事例では、外部コンピュータ可読媒体(図示せず)の中に存在してもよい。メモリデバイス1410は、例として、磁気ストレージデバイス(たとえば、ハードディスク、フロッピーディスク、磁気ストリップ)、光ディスク(たとえば、コンパクトディスク(CD)またはデジタル多用途ディスク(DVD)またはBluRay(商標))、スマートカード、フラッシュメモリデバイス(たとえば、「フラッシュドライブ」、カード、スティック、またはキードライブ)、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、プログラマブルROM(PROM)、消去可能PROM(EPROM)、電気的消去可能PROM(EEPROM)、レジスタ、リムーバブルディスク、ならびに、コンピュータによってアクセスされ読み取られる場合があるソフトウェアおよび/または命令を記憶するための任意の他の適切な媒体を含む非一時的コンピュータ可読媒体を含み得る。コンピュータ可読媒体および/またはストレージ1410は、例として、搬送波、伝送路、ならびに、コンピュータによってアクセスされ読み取られる場合があるソフトウェアおよび/または命令を送信するための任意の他の適切な媒体を含んでもよい。ある代替では、記憶媒体1410は、処理回路構成1408中に存在するか、または処理回路構成1408を含む複数のエンティティに分散されてよい。
【００９３】
またさらに、処理回路構成1408は多機能であってよく、そうであることにより、様々な機能がロードされ、回路構成1408は、異なる機能または同じ機能の異なるインスタンスを実施するように構成される。処理回路構成1408は、さらに、たとえば、ユーザインターフェース1414または通信インターフェース1402からの入力に応答して開始されるバックグラウンドタスクを管理するように適合され得る。
【００９４】
図示していないが、送信および受信回路構成1404、1406は、PHYレイヤにおける信号の送信および受信のために、RF(無線周波数)回路に結合され得る。さらに、送信および受信回路構成1404、1406は、たとえば、RLC AM動作のために、またはバッファリングビットBが「1」にセットされているとき、送信または受信信号を処理し、バッファリングすることができる。
【００９５】
以下のフローチャートは、本明細書において開示するいくつかの態様に従って適合または構成されるネットワーク要素に対して実施されるかまたは動作可能な方法およびプロセスを示す。これらの方法およびプロセスは、ほんのいくつかの例を挙げれば、3G技術、4G技術、および5G技術を含む任意の適切なネットワーク技術において実装されてもよい。したがって、特許請求の範囲は単一のネットワーク技術に制限されない。この点について、「UE」が参照される場合、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、または他の何らかの適切な用語も参照されることが理解されよう。「eノードB」、「eNB」、「フェムトセル」、「ホームノードB」、または「ホームeNB」の参照は、基地局、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット、拡張サービスセットを指すか、または他の何らかの適切な用語に相当することが理解されよう。MMEの参照は、サービングネットワークにおいてオーセンティケータとして働くエンティティ、および/または、たとえばモバイルスイッチングセンタもしくはサービングGPRSサポートノード(SGSN)などの一次サービス配信ノードを指す場合がある。HSSの参照は、ユーザ関連情報および加入者関連情報を含み、たとえば、ホームロケーションレジスタ(HLR)、認証センタ(AuC)、および/もしくは認証、許可、およびアカウンティング(AAA)サーバを含む、モビリティ管理、呼設定およびセッションセットアップ、ならびに/またはユーザ認証およびアクセス認証におけるサポート機能を実現するデータベースを指す場合もある。
【００９６】
図15は、発信RLCデバイスなど、第1のデバイスにおいて実施され得るワイヤレス通信1500のための例示的な方法の流れ図である。ブロック1502において、第1のデバイスは、無線ベアラ接続用の通信モード、または第1のデバイス(たとえば、発信RLCエンティティ)と第2のデバイス(たとえば、ピアRLCエンティティ)との間の無線接続における少なくとも第1のパケットフローを判断し、これは、パケット損失回復およびパケット並べ替えのうちの少なくとも1つを提供する第1の通信モード(たとえば、AM)で動作するか、それともパケット損失回復を提供しない第2の通信モード(たとえば、UM)で動作するか判断することを含む。ブロック1502におけるこのプロセスは、2つの例として、図8のRLCモード変更イベント806または図13のRLCモード変更判断1306に対応し得る。
【００９７】
方法1500は、ブロック1504に示すように、第1のデバイスから第2のデバイスに第1の指示を送信することをさらに含み、指示は、無線接続における第1のパケットフロー向けに第1の通信モードそれとも第2の通信モードが使われるべきかに関する。一例として、この第1の指示は、2つの例として、図8のシグナリング808または図13のシグナリング1308を含み得る。さらに、第1の指示は、データPDUであるか、それともステータスPDUであるかにかかわらず、図10および図11に示すPDUヘッダ情報により実装され得る。さらに、第1の指示は、図12のPDU中のポールビットPであってもよい。ブロック1504における送信は、パケットバッファリングが維持されるべきかどうかを指示する、第2のデバイスへの第2の指示も含む。一例として、この第2の指示は、図12に示すバッファビットBであってよい。したがって、ポールビットとしての第1の指示と、バッファビットBとしての第2の指示の組合せは、前に論じたように、これらのビットの組合せによって通信された、モードを切り替えるための指示シグナリングを、ピアRLCエンティティに与えるのに使われ得ることがさらに諒解されよう。
【００９８】
またさらに、方法1500は、ブロック1506に示すプロセスを含み、ここで、無線接続における第1のパケットフロー向けの通信モードは、少なくとも第1の指示に基づいて、第1の通信モードと第2の通信モードとの間で切り替えられる。例として、このプロセスは、図8のイベント812もしくは818、または図13のイベント1310もしくは1314に対応してよい。
【００９９】
別の例では、第1のデバイスは、指示を送信したことに応答して、第2のデバイスから確認応答を受信し得る。第1のデバイスは次いで、確認応答が受信された後、無線接続における第1のパケットフローの動作を切り替えるだけである。第1のデバイスはまた、確認応答を受信したことに応答して、無線接続における第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットしてよく、状態要素は、変数、カウンタおよび/またはタイマーのうちの少なくとも1つを含む。第1のデバイスはまた、再送信タイマーの満了に先立って、確認応答が受信されなかった場合、指示を再送信するように再送信タイマーをセットしてよい。
【０１００】
さらに別の例では、指示のうちの少なくとも1つは、第1のデバイスがパケットを、回復するためにバッファリング中であるかどうかをさらに示す。送信機は、単に再送信のためにデータをバッファリングする。並べ替えは、送信機側における送信機機能とは関係ない受信機固有機能である。
【０１０１】
別の例によると、第1の通信モードで、それとも第2の通信モードで動作するかの判断は、第1のデバイスの送信機によって実施される。
【０１０２】
別の例では、第1の通信モードで、それとも第2の通信モードで動作するかの判断は、第1のデバイスの受信機によって実施される。
【０１０３】
別の態様によると、プロトコルレイヤは、マルチレイヤプロトコルスタック中の1つのレイヤであり、プロトコルレイヤは、(a)無線リンク制御(RLC)レイヤ、(b)メディアアクセス制御(MAC)レイヤ、または(c)パケットデータコンバージェンスプロトコル(PDCP)レイヤのうちの少なくとも1つである。
【０１０４】
さらに別の態様では、第1のデバイスは、第1のデバイスのメモリ使用が所定の閾を超えると、第1の通信モードから第2の通信モードに切り替え得る。さらに別の例では、第1のデバイスは、第1のデバイスの送信機または受信機バッファの使用が所定の閾を超えると、第1の通信モードから第2の通信モードに切り替え得る。
【０１０５】
別の例によると、第1のデバイスは、無線接続の第1のパケットフローに対するユーザプレーン測定を実施することもでき、第1の通信モードで、それとも第2の通信モードで動作するかどうかの判断は、ユーザプレーン測定値に基づき、ユーザプレーン測定値は、データレート、バッファサイズ、パケットエラーレート(PER)および/またはブロックエラーレート(BLER)のうちの少なくとも1つを含む。第1のデバイスは、第1の通信モードで、それとも第2の通信モードで動作するか判断するために、ユーザプレーン測定値を閾と比較してもよい。
【０１０６】
別の例では、第1の通信モードで、それとも第2の通信モードで動作するかの判断は、第1のデバイスと第2のデバイスとの間の待ち時間、または第1のデバイスの第1のアプリケーションレイヤの第1のピア端と、第2のデバイスの第2のアプリケーションレイヤの第2のピア端との間の測定されたエンドツーエンドの待ち時間に基づく。
【０１０７】
別の例では、第1の通信モードで、それとも第2の通信モードで動作するかの判断は、無線接続における第1のパケットフローに対して現時点でアクティブであるインターネットプロトコル(IP)フローの数に基づく。
【０１０８】
別の例では、第1の通信モードは確認応答モード(AM)を含み、第2の通信モードは非確認応答モード(UM)を含む。ただし、このUMは依然として、ピアRLCエンティティへのステータスPDUを生成したので、このUMは、RLCにおけるUMとまったく同じではない場合がある。
【０１０９】
さらにもう1つの例では、指示のうちの少なくとも1つは、(a)無線リンク制御(RLC)レイヤステータスプロトコルデータ単位(PDU)、(b)無線リソース制御(RRC)メッセージ、(c)無線リンク制御(RLC)レイヤPDU中のビット、(d)パケットデータコンバージェンスプロトコル(PDCP)ステータスPDU、(e)PDCPデータPDU中のビット、(f)メディアアクセス制御(MAC)制御要素、または(g)MAC PDU中のビット内で送られる。
【０１１０】
図16は、無線ベアラ接続の受信端におけるピアRLCエンティティなどのワイヤレス通信デバイスにおいて実施されるワイヤレス通信1600の方法または無線接続におけるパケットフローのフローチャートである。図示されるように、方法1600は、第1のワイヤレスデバイスにおいて、第1および第2のワイヤレスデバイスの間の無線接続における第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から第1または第2の通信モードのうちの他方に切り替えるよう指示する、第2のワイヤレスデバイスからの指示信号を受信することを含む、ブロック1602におけるプロセスを示し、第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、第2の通信モードはパケット損失回復を提供しない。2つの例によると、ブロック1602におけるプロセスは、図8のシグナリング808およびイベント812または図13のシグナリング1308もしくは1312およびイベント1310もしくは1312を含み得ることに留意されたい。
【０１１１】
方法1600は、指示信号に従って、無線接続における第1のパケットフロー向けの通信モードを切り替える、ブロック1604に示すプロセスをさらに含む。さらに、指示信号は、第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも第1のワイヤレスデバイスにおいて維持されるべきかどうかを指示する第2の指示を含む。
【０１１２】
別の例では、ワイヤレス通信デバイスは、指示を受信したことに応答して、第2のワイヤレス通信デバイスに確認応答を送ることもできる。
【０１１３】
別の例では、ワイヤレス通信デバイスは、第2のワイヤレス通信デバイスが無線接続における第1のパケットフローの動作を切り替えるのを防止するために、指示の受信に応答して、確認応答の送信を保留してもよい。
【０１１４】
別の例では、ワイヤレス通信デバイスは、指示を受信したことに応答して、無線接続における第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットしてよく、状態要素は、変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含む。
【０１１５】
別の例では、指示シグナリングは、第2のワイヤレス通信デバイスが、パケットを、回復するためにバッファリング中であるかどうかをさらに示す。送信機は、単に再送信のためにデータをバッファリングする。並べ替えは、送信機側における送信機機能とは関係ない受信機固有機能である。
【０１１６】
別の例では、第1の通信モードは確認応答モード(AM)を含み、第2の通信モードは非確認応答モード(UM)を含む。ただし、このUMは依然として、ピアRLCエンティティへのステータスPDUを生成したので、このUMは、RLCにおけるUMとまったく同じではない場合がある。
【０１１７】
別の例では、プロトコルレイヤは、マルチレイヤプロトコルスタック中の1つのレイヤであり、プロトコルレイヤは、(a)無線リンク制御(RLC)レイヤ、(b)メディアアクセス制御(MAC)レイヤ、または(c)パケットデータコンバージェンスプロトコル(PDCP)レイヤのうちの少なくとも1つである。
【０１１８】
別の例では、指示シグナリングは、(a)無線リンク制御(RLC)レイヤステータスプロトコルデータ単位(PDU)、(b)無線リソース制御(RRC)メッセージ、(c)無線リンク制御(RLC)レイヤPDU中のビット、(d)パケットデータコンバージェンスプロトコル(PDCP)ステータスPDU、(e)PDCPデータPDU中のビット、(f)メディアアクセス制御(MAC)制御要素、または(g)MAC PDU中のビット内で送られる。別の例では、指示は、制御信号(たとえば、制御もしくはステータスPDU)または帯域内信号(たとえば、データPDU)のいずれかを介して受信される。
【０１１９】
開示されたプロセスにおけるステップの特定の順序または階層は、例示的な手法の例示であることを理解されたい。設計上の選好に基づいて、プロセスにおけるステップの特定の順序または階層が並べ替えられてもよいことを理解されたい。さらに、いくつかのステップは、組み合わされるか、または省略される場合がある。添付の方法クレームは、様々なステップの要素を見本的な順序で提示したものであり、提示された特定の順序または階層に限定されるものではない。
【０１２０】
本説明は、本明細書で説明した様々な態様および例を、いかなる当業者も実践できるようにするために提供される。これらの態様に対する様々な修正および例は、当業者に容易に明らかになり、本明細書で定義した一般原理は、他の態様に適用され得る。したがって、特許請求の範囲は、本明細書に示す態様に限定されるものではなく、文言通りの特許請求の範囲と一致するすべての範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」ではなく、「1つまたは複数の」を意味するものとする。別段に明記されていない限り、「いくつかの」という用語は1つまたは複数を指す。当業者に知られているか、または後で知られることになる、本開示全体にわたって説明する様々な態様の要素の、すべての構造的および機能的等価物は、参照により本明細書に明確に組み込まれ、特許請求の範囲によって包含されるものとする。さらに、本明細書に開示されるものは、そのような開示が特許請求の範囲において明示的に記載されているかどうかにかかわらず、公に供されることは意図されていない。「ための手段」という句を使用して要素が明確に列挙されていない限り、いかなるクレーム要素もミーンズプラスファンクションとして解釈されるべきではない。
【符号の説明】
【０１２１】
100  LTEネットワークアーキテクチャ、発展型パケットシステム(EPS)
102  ユーザ機器(UE)
104  発展型UMTS地上波無線アクセスネットワーク(E-UTRAN)
106  発展型ノードB(eNB)
108  他のeNB
110  発展型パケットコア(EPC)
112  モビリティ管理エンティティ(MME)
114  他のMME
116  サービングゲートウェイ
118  パケットデータネットワーク(PDN)ゲートウェイ
120  ホーム加入者サーバ(HSS)
122  事業者のIPサービス
200  アクセスネットワーク
202  セルラー領域(セル)
204  マクロeNB、eNB
206  UE
208  低電力クラスeNB、リレーノード、RN
210  セルラー領域、スモールセル
212  セルラー領域、セル、ラージセル、ドナーセル
214  マクロeNB、eNB、ドナーeNB(DeNB)
300  無線プロトコルアーキテクチャ
306  物理レイヤ、PHY
308  レイヤ2、L2レイヤ
310  メディアアクセス制御(MAC)サブレイヤ
312  無線リンク制御(RLC)サブレイヤ
314  パケットデータコンバージェンスプロトコル(PDCP)サブレイヤ
316  無線リソース制御(RRC)サブレイヤ
400  LTEプロトコルスタック
403  アクセス層(AS)
404  物理(PHY)レイヤ
406  メディアアクセス制御(MAC)レイヤ
408  無線リンク制御(RLC)レイヤ
410  論理チャネル
411  パケットデータコンバージェンスプロトコル(PDCP)レイヤ
412  RRCレイヤ
413  無線/セッションベアラ
414  非アクセス層(NAS)レイヤ
416  アプリケーション(APP)レイヤ
510  eNB、eノードB
516  送信(TX)プロセッサ
518  TX/RXトランシーバ、トランシーバ
520  アンテナ
550  UE
552  アンテナ
554  トランシーバ
556  受信(RX)プロセッサ
558  チャネル推定器
559  コントローラ/プロセッサ
560  メモリ
562  データシンク
567  データソース
570  受信(RX)プロセッサ
574  チャネル推定器
575  コントローラ/プロセッサ
576  メモリ
602  送信機
604  受信機
702  非確認応答モード状態、UM状態
704  第1のイベント切替え
706  第1のイベント
708  確認応答モード状態、AM状態
710  第2のイベント切替え
712  第2のイベント
802  発信RLCエンティティ、メインRLCエンティティ、RLCエンティティ、エンティティ
804  ピアRLCエンティティ、ピア、ピアエンティティ、RLCエンティティ
902  第1のデバイス、RLCエンティティ
904  第2のデバイス、RLCエンティティ
906  第1の確認応答モード(AM)無線リンク制御(RLC)送信ユニット
908  第1のAM RLC受信ユニット、受信ユニット
910  第2のAM RLC送信ユニット、送信ユニット
912  第2のAM RLC受信ユニット
918  送信バッファ
920  受信バッファ
1000  RLCデータPDU
1100  ステータスPDU、PDU
1302  発信RLCエンティティ、エンティティ、RLCエンティティ、送信または発信RLCエンティティ、送信機RLCエンティティ
1304  受信またはピアRLCエンティティ
1400  ワイヤレスデバイス、デバイス
1402  通信インターフェース回路構成、通信インターフェース
1404  送信機回路構成、送信回路構成
1406  受信機回路構成、受信回路構成
1408  処理回路構成、回路構成
1410  メモリデバイスまたは記憶媒体、コンピュータ可読媒体および/またはストレージ
1412  バス
1414  ユーザインターフェース
【図１】
2018509026.tif 000004
【図２】
2018509026.tif 000005
【図３】
2018509026.tif 000006
【図４】
2018509026.tif 000007
【図５】
2018509026.tif 000008
【図６】
2018509026.tif 000009
【図７】
2018509026.tif 000010
【図８】
2018509026.tif 000011
【図９】
2018509026.tif 000012
【図１０】
2018509026.tif 000013
【図１１】
2018509026.tif 000014
【図１２】
2018509026.tif 000015
【図１３】
2018509026.tif 000016
【図１４】
2018509026.tif 000017
【図１５】
2018509026.tif 000018
【図１６】
2018509026.tif 000019
【手続補正書】
【提出日】平成29年7月27日(2017.7.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ワイヤレス通信のための方法であって、
第1のデバイスにおいて、前記第1のデバイスと第2のデバイスとの間の無線接続の少なくとも第1のパケットフロー向けの通信モードを判断するステップであって、パケット損失回復および/またはパケット並べ替えのうちの少なくとも1つを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含むステップと、
前記第1の通信モードそれとも前記第2の通信モードが前記無線接続の前記第1のパケットフロー向けに使われるべきかに関連した、前記第2のデバイスへの第1の指示、およびパケットバッファリングが前記第2のデバイスにおいて実施されるべきかどうかを指示する、前記第2のデバイスへの第2の指示を送信するステップと、
少なくとも前記第1の指示に基づいて、前記無線接続の前記第1のパケットフロー向けの前記通信モードを、前記第1の通信モードと第2の通信モードとの間で切り替えるステップとを含む方法。
【請求項２】
前記第1の指示を送信したことに応答して、前記第2のデバイスから確認応答を受信するステップをさらに含む、請求項1に記載の方法。
【請求項３】
前記第1のデバイスは、前記確認応答が受信された後、前記無線接続の前記第1のパケットフローの前記通信モードを切り替える、請求項2に記載の方法。
【請求項４】
前記無線接続用の前記通信モードを切り替えるステップは、
前記第1および第2のデバイスのうちの少なくとも1つにおいて、前記無線接続の前記第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットするステップをさらに含み、前記状態要素は、状態変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項５】
前記第1の指示は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、帯域内シグナリングおよび/または制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項1に記載の方法。
【請求項６】
前記第2の指示は、前記第1のデバイスおよび/または前記第2のデバイスのうちの少なくとも1つにパケットをバッファリングするかどうかをシグナリングする、プロトコルデータ単位(PDU)のヘッダ中のバッファビットを含む、請求項1に記載の方法。
【請求項７】
ポールビットを含む前記第1の指示が、前記無線接続の前記第1のパケットフローを介して、1つまたは複数の受信PDUのステータスを送るかどうかを指示するステップをさらに含み、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のパケットフロー向けの前記通信モードの切替えを通信するように構成される、請求項6に記載の方法。
【請求項８】
前記第1の通信モードそれとも前記第2の通信モードで動作するか判断するステップは、
前記無線接続の前記第1のパケットフローのデータレート、前記第1および第2のデバイスのうちの少なくとも1つにおけるバッファサイズ、パケットエラーレート(PER)、ブロックエラーレート(BLER)、前記無線接続の前記第1のパケットフローを介した、前記第1および第2のデバイスの間のパケット待ち時間、ならびに/または前記無線接続の前記第1のパケットフローにおいてサービスされるインターネットプロトコル(IP)フローの数のうちの少なくとも1つを測定するステップと、
前記測定に基づいて、前記第1の通信モードそれとも前記第2の通信モードで動作するか判断するステップをさらに含む、請求項1に記載の方法。
【請求項９】
前記第1の通信モードは無線リンク制御(RLC)確認応答モード(AM)であり、前記第2の通信モードはRLC非確認応答モード(UM)である、請求項1に記載の方法。
【請求項１０】
ワイヤレスデバイスであって、
ワイヤレスネットワークを介して通信するように構成された通信インターフェースと、
前記通信インターフェースに結合された処理回路構成とを備え、前記処理回路構成は、
前記ワイヤレスデバイスと別の第2のワイヤレスデバイスとの間の無線接続の少なくとも第1のパケットフロー向けの通信モードを判断し、これは、パケット損失回復および/またはパケット並べ替えのうちの少なくとも1つを提供する第1の通信モードで動作するか、それともパケット損失回復を提供しない第2の通信モードで動作するか判断することを含み、
前記第1の通信モードそれとも前記第2の通信モードが前記無線接続の前記第1のパケットフロー向けに使われるべきかに関連した、前記第2のワイヤレスデバイスへの第1の指示、およびパケットバッファリングが第2のデバイスにおいて実施されるべきかどうかを指示する、前記第2のワイヤレスデバイスへの第2の指示を送信し、
少なくとも前記第1の指示に基づいて、前記無線接続の前記第1のパケットフロー向けの前記通信モードを、前記第1の通信モードと第2の通信モードとの間で切り替えるように構成される、ワイヤレスデバイス。
【請求項１１】
前記処理回路構成は、前記第1の指示を送信したことに応答して、前記第2のワイヤレスデバイスから確認応答を受信するようにさらに構成される、請求項10に記載のワイヤレスデバイス。
【請求項１２】
前記処理回路構成は、前記確認応答が受信された後、前記無線接続の前記第1のパケットフローの前記通信モードを切り替える、請求項11に記載のワイヤレスデバイス。
【請求項１３】
前記処理回路構成は、
前記ワイヤレスデバイスおよび第2のワイヤレスデバイスのうちの少なくとも1つにおいて、前記無線接続の前記第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットすることを含む、前記無線接続の前記第1のパケットフロー向けの前記通信モードを切り替え、前記状態要素は、状態変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含むようにさらに構成される、請求項11に記載のワイヤレスデバイス。
【請求項１４】
前記第1の指示は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、帯域内シグナリングおよび制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項10に記載のワイヤレスデバイス。
【請求項１５】
前記第2の指示は、前記ワイヤレスデバイスおよび/または前記第2のワイヤレスデバイスのうちの少なくとも1つにパケットをバッファリングするかどうかをシグナリングする、プロトコルデータ単位(PDU)のヘッダ中のバッファビットを含む、請求項10に記載のワイヤレスデバイス。
【請求項１６】
前記無線接続の前記第1のパケットフローを介して、1つまたは複数の受信PDUのステータスを送るかどうかを指示するポールビットを含む前記第1の指示をさらに備え、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のパケットフロー向けの前記通信モードの切替えを通信するように構成される、請求項15に記載のワイヤレスデバイス。
【請求項１７】
前記処理回路構成は、
前記無線接続の前記第1のパケットフローのデータレート、前記ワイヤレスデバイスおよび前記第2のワイヤレスデバイスのうちの少なくとも1つにおけるバッファサイズ、パケットエラーレート(PER)、ブロックエラーレート(BLER)、前記無線接続の前記第1のパケットフローを介した、前記第1および第2のデバイスの間のパケット待ち時間、ならびに/または前記無線接続の前記第1のパケットフローにおいてサービスされるインターネットプロトコル(IP)フローの数のうちの少なくとも1つを測定し、
前記測定に基づいて、前記第1の通信モードそれとも前記第2の通信モードで動作するか判断するようにさらに構成される、請求項10に記載のワイヤレスデバイス。
【請求項１８】
前記第1の通信モードは無線リンク制御(RLC)確認応答モード(AM)であり、前記第2の通信モードはRLC非確認応答モード(UM)である、請求項10に記載のワイヤレスデバイス。
【請求項１９】
ワイヤレス通信のための方法であって、
第1および第2のワイヤレスデバイスの間の無線接続の第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から、前記第1または第2の通信モードのうちの他方に切り替えるように指示する、前記第2のワイヤレスデバイスからの指示信号を前記第1のワイヤレスデバイスにおいて受信するステップであって、前記第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、前記第2の通信モードはパケット損失回復を提供しない、ステップと、
前記無線接続の前記第1のパケットフロー向けの前記通信モードを前記指示信号に従って切り替えるステップとを含み、
前記指示信号は、前記第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも前記第1のワイヤレスデバイスにおいて実施されるべきかどうかを指示する第2の指示を含む、方法。
【請求項２０】
前記受信した指示信号に応答して、前記第1のワイヤレスデバイスから前記第2のワイヤレスデバイスに確認応答を送るステップをさらに含む、請求項19に記載の方法。
【請求項２１】
前記無線接続の前記第1のパケットフロー向けの前記通信モードを切り替えるステップは、
前記指示信号に応答して、少なくとも前記第1のワイヤレスデバイスにおいて、前記無線接続の前記第1のパケットフローに関連付けられた1つまたは複数の状態要素をリセットするステップをさらに含み、前記状態要素は、状態変数、カウンタ、および/またはタイマーのうちの少なくとも1つを含む、請求項19に記載の方法。
【請求項２２】
前記指示信号は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、前記第2のワイヤレスデバイスからの、帯域内シグナリングおよび制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項19に記載の方法。
【請求項２３】
前記第2の指示は、少なくとも前記第1のデバイス中でパケットをバッファリングするかどうかをシグナリングする、前記第2のワイヤレスデバイスからのプロトコルデータ単位(PDU)のヘッダ中のバッファビットを含む、請求項19に記載の方法。
【請求項２４】
前記第1の指示が、前記第1のワイヤレスデバイスから前記第2のワイヤレスデバイスに、1つまたは複数の受信PDUのステータスを、前記無線接続の前記第1のフローを介して送るかどうかを指示するポールビットを含めるステップをさらに含み、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のフロー向けの前記通信モードの切替えを通信するように構成される、請求項23に記載の方法。
【請求項２５】
前記第1の通信モードは無線リンク制御(RLC)確認応答モード(AM)であり、前記第2の通信モードはRLC非確認応答モード(UM)である、請求項23に記載の方法。
【請求項２６】
ワイヤレス通信デバイスであって、
ワイヤレスネットワークを介して通信するように構成された通信インターフェースと、
前記通信インターフェースに通信可能に結合された処理回路構成とを備え、前記処理回路構成は、
前記ワイヤレス通信デバイスと第2のワイヤレス通信デバイスとの間の無線接続の少なくとも第1のパケットフローの通信モードを、第1または第2の通信モードのうちの一方から、前記第1または第2の通信モードのうちの他方に切り替えるように指示する指示信号を、前記第2のワイヤレス通信デバイスから受信し、前記第1の通信モードはパケット損失回復およびパケット並べ替えを提供し、前記第2の通信モードはパケット損失回復を提供せず、
前記無線接続の前記第1のパケットフロー向けの前記通信モードを前記指示信号に従って切り替えるように構成され、
前記指示信号は、前記第1または第2の通信モードのうちのどちらに切り替えるべきかについての第1の指示、およびパケットバッファリングが少なくとも前記ワイヤレス通信デバイスにおいて実施されるべきかどうかを指示する第2の指示を含む、ワイヤレス通信デバイス。
【請求項２７】
前記処理回路構成は、
前記受信した指示信号に応答して、前記ワイヤレス通信デバイスから前記第2のワイヤレス通信デバイスに確認応答を送るようにさらに構成される、請求項26に記載のワイヤレス通信デバイス。
【請求項２８】
前記指示信号は、通信モード変更についての要求および/または切り替えられる先の前記通信モードのうちの少なくとも1つを指示する、前記第2のワイヤレス通信デバイスからの、帯域内シグナリングおよび制御シグナリングのうちの少なくとも1つの中の情報を含む、請求項26に記載のワイヤレス通信デバイス。
【請求項２９】
前記無線接続の前記第1のパケットフローを介して受信された1つまたは複数の受信プロトコルデータ単位(PDU)のステータスを、前記ワイヤレス通信デバイスから前記第2のワイヤレス通信デバイスに送るかどうかを指示するポールビットを含む前記第1の指示と、
前記ワイヤレス通信デバイスにおいてパケットをバッファリングするかどうかをシグナリングする、前記第2のワイヤレス通信デバイスからのPDUのヘッダ中にバッファビットを含む前記第2の指示とをさらに含み、
前記ポールビットと前記バッファビットの組合せは、前記第1の通信モードと第2の通信モードとの間での、前記無線接続の前記第1のパケットフロー向けの前記通信モードの切替えを通信するように構成される、請求項26に記載のワイヤレス通信デバイス。
【請求項３０】
前記処理回路構成は、
前記第2のワイヤレス通信デバイスから受信された前記指示信号に応答して、前記無線接続の前記第1のパケットフロー向けの前記通信モードを切り替えた後、前記受信した指示信号に一致する補足指示信号を前記第2のワイヤレス通信デバイスに送るようにさらに構成される、請求項26に記載のワイヤレス通信デバイス。
【国際調査報告】
2018509026.tif 000020
2018509026.tif 000021