添付の図面に関して以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書に記載される概念が実施され得る唯一の構成を表すことを意図していない。詳細な説明は、様々な概念の完全な理解を与えるために特定の詳細を含む。しかしながら、これらの概念がこれらの特定の詳細がなくても実施することができることは当業者に明らかであろう。いくつかの例では、そのような概念を曖昧にするのを防ぐために、よく知られた構造および構成要素がブロック図の形態において示されている。
本開示の態様は、ダウンリンク(DL)およびアップリンク(UL)の不連続受信(DRX)および不連続送信(DTX)を対象とする。たとえば、DTXは、音声通話をサポートするために、回線交換環境において使用され得る。DTXは、連続送信に対して省電力化を提供することができる。
現在、回線交換呼は、20msの送信時間間隔(TTI)を利用する。本開示の態様は、効果的に使用されるTTIの低減のために使用され得る。たとえば、ボイスパケットは、20msのTTIウィンドウの開始時に送信に使用可能であるが、そのパケットの実際の送信は、全TTIウィンドウに及ばないまたは全TTIウィンドウを消費しない可能性があり、したがって、パケットは、送信されるとき、TTIウィンドウの一部を消費するだけである。この場合、送信デバイスは、TTIウィンドウの一部の間、その送信を一時停止し得る。たとえば、TTIウィンドウの一部は、全TTIウィンドウの半分に対応し得る。ボイスパケットの送信によって消費されないTTIウィンドウの第2の部分または残りの間、送信機および/または受信機は、一時停止、電源切断、またはターンオフし得、それによって、省電力化を可能にする。いくつかの場合には、1つまたは複数の専用物理制御チャネル(DPCCH)パラメータは、次のTTIの開始の前のTTIの残りの間にあらかじめ決定された数のスロット上で送信される。
図1は、処理システム114を使用する装置100のためのハードウェア実装形態の一例を示す概念図である。本開示の様々な態様によれば、要素、または要素の任意の部分、または要素の任意の組合せは、1つまたは複数のプロセッサ104を備えた処理システム114を用いて実施することができる。たとえば、装置100は、図2、図3、および図5のうちのいずれか1つまたは複数に示すようなユーザ機器(UE)であってもよい。プロセッサ104の例には、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、状態機械、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明される様々な機能を実行するように構成された他の適切なハードウェアが含まれる。
この例では、処理システム114は、バス102によって概略的に表されるバスアーキテクチャを用いて実装されてもよい。バス102は、処理システム114の特定の応用および設計制約全体に応じて任意の数の相互接続バスおよびブリッジを含むことができる。バス102は、(プロセッサ104によって全体的に表される)1つまたは複数のプロセッサ、メモリ105、および(コンピュータ可読媒体106によって全体的に表される)コンピュータ可読媒体を含む、様々な回路を互いにリンクさせる。バス102は、当業界でよく知られているタイミングソース、周辺機器、電圧レギュレータ、および電源管理回路などの様々な他の回路とリンクすることもでき、したがって、さらに何らか説明されることはない。バスインターフェース108は、バス102とトランシーバ110との間のインターフェースを与える。トランシーバ110は、伝送媒体を介して様々な他の装置と通信するための手段を実現する。装置100の性質に応じて、ユーザインターフェース112(たとえば、キーボード、ディスプレイ、スピーカ、マイクロフォン、ジョイスティック)を設けることもできる。
図1に示されるように、1つまたは複数の送信時間間隔(TTI)パラメータまたは値122は、メモリ105に記憶され得る。TTI値122は、TTIまたはTTIウィンドウの全部または部分に対応し得る。たとえば、第1の値122は、10msまたはTTIウィンドウの半分に対応し得、ただし、TTIウィンドウは、20msでもよく、回線交換音声通話のために選択されてもよい。当然、任意の適切な値がTTI値122として記憶され得る。プロセッサ104は、回線交換音声通話の間に不連続送信(DTX)および不連続受信(DRX)の動作を有効にするために、1つまたは複数のTTI値122に基づいて動作可能であり得る。たとえば、第1のTTI値122がTTIウィンドウの半分である場合、第1のTTI値122の使用は、全TTIウィンドウの別の部分におけるボイスフレームの送信または受信を伴い得る。メモリ105は、いくつかの追加のパラメータまたは値124〜138を含むものとして示されている。パラメータ124〜138は、ここでは、以下のそれらの役割および機能のより詳細な説明の前置きとして参照される。
プロセッサ104は、バス102の管理、およびコンピュータ可読媒体106に記憶されたソフトウェア107の実行を含む全体的な処理を担当する。プロセッサ104によって実行されるとき、ソフトウェア107は、処理システム114に任意の特定の装置について以下で説明される様々な機能を実行させる。コンピュータ可読媒体106は、ソフトウェアを実行するときにプロセッサ104によって操作されるデータを記憶するために使用され得る。本開示の態様によれば、ソフトウェア107は、メモリ105に含まれ得る。
処理システムの1つまたは複数のプロセッサ104は、ソフトウェアを実行することができる。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、または他のものと呼ばれるのであれ何であれ、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行ファイル、実行のスレッド、プロシージャ、機能などを意味すると幅広く解釈されるべきである。ソフトウェアは、コンピュータ可読媒体106に常駐することができる。コンピュータ可読媒体106は、非一時的コンピュータ可読媒体であり得る。非一時的コンピュータ可読媒体には、例として、磁気記憶デバイス(たとえば、ハードディスク、フロッピー(登録商標)ディスク、磁気ストリップ)、光ディスク(たとえば、コンパクトディスク(CD)またはデジタル多用途ディスク(DVD))、スマートカード、フラッシュメモリデバイス(たとえば、カード、スティック、またはキードライブ)、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、プログラマブルROM(PROM)、消去可能PROM(EPROM)、電気的消去可能PROM(EEPROM)、レジスタ、リム-バルディスク、ならびに、コンピュータがアクセスし読み取ることができるソフトウェアおよび/または命令を記憶するための任意の他の適切な媒体が含まれる。コンピュータ可読媒体には、例として、搬送波、伝送路、ならびに、コンピュータがアクセスし読み取ることができるソフトウェアおよび/または命令を送信するための任意の他の適切な媒体も含まれ得る。コンピュータ可読媒体106は、処理システム114の中に存在する場合があり、処理システム114の外に存在する場合があり、または処理システム114を含む複数のエンティティに分散される場合がある。コンピュータ可読媒体106は、コンピュータプログラム製品において具現化することができる。例として、コンピュータプログラム製品は、パッケージング材料内のコンピュータ可読媒体を含む場合がある。当業者は、特定の適用例およびシステム全体に課される全体的な設計制約に応じて、本開示全体にわたって提示された、記載された機能を最善の形でどのように実装することができるかを認識されよう。
本開示全体を通じて示される様々な概念は、広範な電気通信システム、ネットワーク構造、および通信規格にわたって実施され得る。ここで図2を参照すると、限定のない例示の例として様々な本開示の態様が、ユニバーサルモバイルテレコミュニケーションシステム(UMTS)システム200に関連して例示されている。UMTSネットワークは、コアネットワーク204、無線アクセスネットワーク(RAN)(たとえば、UMTS地上無線アクセスネットワーク(UTRAN)202)、およびユーザ機器(UE)210という3つの相互作用ドメインを含む。UTRAN202に利用可能ないくつかのオプションの中で、この例では、図示されたUTRAN202は、電話、ビデオ、データ、メッセージング、放送、および/または他のサービスを含む様々なワイヤレスサービスを可能にするためのW-CDMAエアインターフェースを用いることができる。UTRAN202は、無線ネットワークコントローラ(RNC)206などのそれぞれのRNCによって各々制御される、無線ネットワークサブシステム(RNS)207などの複数のRNSを含み得る。ここで、UTRAN202は、図示されたRNC206およびRNS207に加えて、任意の数のRNC206およびRNS207を含む場合がある。RNC206は、とりわけ、RNS207内の無線リソースを割り当て、再構成し、かつ解放することを受け持つ装置である。RNC206は、任意の適切な転送ネットワークを用いて、直接物理接続、仮想ネットワーク等などの様々なタイプのインターフェースを通じてUTRAN202における他のRNC(図示せず)に相互接続することができる。
RNS207によってカバーされる地理的領域は、いくつかのセルに分割することができ、無線送受信機装置が各セルをサービスする。UMTS応用において無線送受信機装置はノードBと一般に呼ばれるが、基地局(BS)、ベーストランシーバ基地局(BTS)、無線基地局、無線送受信機、送受信機機能、基本サービスセット(BSS)、拡張サービスセット(ESS)、アクセスポイント(AP)、またはいくつかの他の適切な専門用語としても当業者によって呼ばれ得る。明快にするために、各RNS207に3つのノードB208が示されているが、RNS207は、任意の数のワイヤレスノードBを含み得る。ノードB208は、任意の数のモバイル装置のためのコアネットワーク204にワイヤレスアクセスポイントを提供する。モバイル装置の例には、携帯電話、スマートフォン、セッション開始プロトコル(SIP)電話、ラップトップ、ノートブック、ネットブック、スマートブック、携帯情報端末(PDA)、衛星ラジオ、全地球測位システム(GPS)デバイス、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ(たとえば、MP3プレーヤ)、カメラ、ゲーム機、または任意の他の類似の機能デバイスがある。モバイル装置は、通常、UMTS用途ではユーザ機器(UE)と呼ばれるが、当業者により、移動局(MS)、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末(AT)、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、端末、ユーザエージェント、モバイルクライアント、クライアント、または何らかの他の適切な用語で呼ばれる場合もある。UMTSシステムでは、UE210は、ネットワークへのユーザの加入情報を含む汎用加入者識別モジュール(USIM)211をさらに含み得る。説明のために、1つのUE210がいくつかのノードB208と通信しているように示されている。順方向リンクとも呼ばれるダウンリンク(DL)は、ノードB208からUE210への通信リンクを指し、逆方向リンクとも呼ばれるアップリンク(UL)は、UE210からノードB208への通信リンクを指す。
コアネットワーク204は、UTRAN202のような1つまたは複数のアクセスネットワークとインターフェースをとることができる。図示のように、コアネットワーク204はUMTSコアネットワークである。しかしながら、当業者が認識するように、本開示を通じて示された様々な概念は、RAN、または他の適切なアクセスネットワークにおいて実施することができ、UEにUMTSネットワーク以外のコアネットワークのタイプへのアクセスを可能にする。
例示したUMTSコアネットワーク204は、回線交換(CS)ドメインと、パケット交換(PS)ドメインとを含む。回線交換要素のうちのいくつかは、モバイルサービス交換センタ(MSC)、ビジターロケーションレジスタ(VLR)、およびゲートウェイMSC(GMSC)である。パケット交換要素は、サービングGPRSサポートノード(SGSN)と、ゲートウェイGPRSサポートノード(GGSN)とを含む。EIR、HLR、VLR、およびAuCのようないくつかのネットワーク要素は、回線交換ドメインとパケット交換ドメインとの両方によって共有され得る。
図示された例では、コアネットワーク204は、MSC212およびGMSC214を用いて回線交換サービスをサポートする。いくつかの適用例では、GMSC214は、メディアゲートウェイ(MGW)とも呼ばれることがある。RNC206などの1つまたは複数のRNCがMSC212に接続され得る。MSC212は、呼設定、呼ルーティング、およびUEモビリティ機能を制御する装置である。MSC212は、UEがMSC212のカバレッジエリア内にある期間の間加入者関連情報を収容する、ビジターロケーションレジスタ(VLR)も含む。GMSC214は、UEが回線交換ネットワーク216にアクセスするために、MSC212を介したゲートウェイを提供する。GMSC214は、特定のユーザが加入したサービスの詳細を反映するデータのような加入者データを格納する、ホームロケーションレジスタ(HLR)215を含む。HLRは、加入者に固有の認証データを格納する、認証センタ(AuC)とも関連付けられている。特定のUEについて、呼が受信されると、GMSC214は、UEの位置を決定するためにHLR215に問い合わせ、その位置をサービスする特定のMSCに呼を転送する。
例示のコアネットワーク204は、サービングGPRSサポートノード(SGSN)218、およびゲートウェイGPRSサポートノード(GGSN)220を有するパケット交換データサービスのサポートもする。汎用パケット無線サービス(GPRS)は、標準的な回線交換データサービスを用いて利用できるものよりも高い速度でパケットデータサービスを提供するように設計されている。GGSN220は、パケットベースネットワーク222へのUTRAN202用の接続を提供する。パケットベースネットワーク222は、インターネット、プライベートデータネットワーク、またはいくつかの他の適切なパケットベースのネットワークであり得る。GGSN220の主要機能は、パケットベースネットワーク接続をUE210に提供することである。データパケットは、MSC212が回線交換ドメイン内で実行する機能と同じ機能をパケットベースドメイン内で主に実行するSGSN218を介して、GGSN220とUE210との間で転送され得る。
UTRAN202は、本開示に従って利用され得るRANの一例である。図3を参照すると、限定ではなく例として、UTRANアーキテクチャにおけるRAN300の簡略化された概略図が示されている。このシステムは、セル302、304、および306を備えた複数のセルラー領域(セル)を含み、その各々は、1つまたは複数のセクタを含み得る。セルは、(たとえば、カバレージエリアによって)地理的に定義することができ、および/または周波数、スクランブリングコードなどに従って定義することができる。すなわち、図示された地理的に定義されたセル302、304、および306は各々、たとえば、異なるスクランブリングコードを利用することによって、複数のセルにさらに分割され得る。たとえば、セル304aは、第1のスクランブリングコードを利用することができ、セル304bは、同じ地理的な領域内にあり、同じノードB344によってサービスされているが、第2のスクランブリングコードを利用することによって区別することができる。
セクタに分割されているセルにおいて、セル内の複数のセクタは、各アンテナがセルの一部におけるUEとの通信の責任を負っている複数のアンテナからなる群によって形成され得る。たとえば、セル302では、アンテナグループ312、314、および316は各々、異なるセクタに対応することができる。セル304では、アンテナグループ318、320、および322は各々、異なるセクタに対応することができる。セル306では、アンテナグループ324、326、および328は各々、異なるセクタに対応することができる。
セル302、304、および306は、各セル302、304、または306の1つまたは複数のセクタと通信中であり得る、いくつかのUEを含み得る。たとえば、UE330および332はノードB342と通信していることがあり、UE334および336はノードB344と通信していることがあり、UE338および340はノードB346と通信していることがある。ここで、各ノードB342、344、および346は、それぞれのセル302、304、および306の中のすべてのUE330、332、334、336、338、および340のために、コアネットワーク204(図2参照)へのアクセスポイントを提供するように構成され得る。
ソースセルとの呼の間、または任意の他の時間に、UE336は、ソースセルの様々なパラメータならびに隣接するセルの様々なパラメータを監視することができる。さらに、これらのパラメータの品質に応じて、UE336は、近隣セルのうちの1つまたは複数との通信を保つことができる。この時間の間、UE336は、アクティブセット、すなわちUE336が同時に接続されるセルのリストを維持することができる(すなわち、ダウンリンク専用物理チャネル(DPCH)または部分ダウンリンク専用物理チャネル(F-DPCH)をUE336に現在割り当てているUTRANセルは、アクティブセットを構成することができる)。
UTRANエアインターフェースは、W-CDMA規格を利用したものなどのスペクトル拡散直接拡散符号分割多元接続(DS-CDMA: spread spectrum Direct-Sequence Code Division Multiple Access)システムであり得る。スペクトル拡散DS-CDMAは、チップと呼ばれる疑似ランダムビットのシーケンスによって乗法を通じてユーザデータを拡散する。UTRAN202のためのW-CDMAエアインターフェースは、そのようなDS-CDMA技術に基づき、周波数分割複信(FDD)をさらに要求する。FDDは、ノードB208とUE210との間のアップリンク(UL)およびダウンリンク(DL)に異なるキャリア周波数を使用する。DS-CDMAを利用するとともに時分割複信(TDD)を使用するUMTSのための別のエアインターフェースは、TD-SCDMAエアインターフェースである。本明細書に説明された様々な例はW-CDMAエアインターフェースについて言及し得るが、根本的な原理は、TD-SCDMAエアインターフェースまたは任意の他の適切なエアインターフェースに等しく適用可能であることを当業者は認識されよう。
ワイヤレス電気通信システムにおいて、通信プロトコル構造は、特定の応用に応じて様々な形態をとり得る。たとえば、3GPPのUMTSシステムでは、シグナリングプロトコルスタックは、非アクセス層(NAS)およびアクセス層(AS)に分割される。NASは、UE210とコアネットワーク204との間のシグナリングのために上位レイヤを与え(図2参照)、回線交換プロトコルおよびパケット交換プロトコルを含むことができる。ASは、UTRAN202とUE210との間のシグナリング用に下位層を提供し、ユーザプレーンおよび制御プレーンを含む場合がある。ここで、ユーザプレーンまたはデータプレーンはユーザトラフィックを搬送し、一方、制御プレーンは制御情報(すなわち、シグナリング)を搬送する。
図4を参照すると、ASが、レイヤ1、レイヤ2、およびレイヤ3の3つの層とともに示されている。レイヤ1は、最も低いレイヤであり、様々な物理レイヤ信号処理機能を実施する。レイヤ1は、本明細書において物理レイヤ406と呼ばれる。レイヤ2 408と呼ばれるデータリンクレイヤが物理レイヤ406の上にあり、物理レイヤ406にわたってUE210とノードB208との間のリンクの責任を負っている。
レイヤ3において、RRCレイヤ416は、UE210とノードB208との間の制御プレーンのシグナリングを処理する。RRCレイヤ416は、上位レイヤのメッセージのルーティング、ブロードキャスト機能およびページング機能の処理、無線ベアラの確立および構成などのための、いくつかの機能エンティティを含む。
例示したエアインターフェースにおいて、L2レイヤ408は、サブレイヤに分けられる。制御プレーンでは、L2レイヤ408は、2つのサブレイヤ、すなわち、媒体アクセス制御(MAC)サブレイヤ410および無線リンク制御(RLC)サブレイヤ412を含む。ユーザプレーンでは、L2レイヤ408は、パケットデータコンバージェンスプロトコル(PDCP)サブレイヤ414をさらに含む。図示されていないが、UEは、ネットワーク側のPDNゲートウェイで終端するネットワークレイヤ(たとえば、IPレイヤ)、および接続の他の端部(たとえば、遠端のUE、サーバなど)で終端するアプリケーションレイヤを含む、L2レイヤ408の上のいくつかの上位レイヤを有する場合がある。
PDCPサブレイヤ414は、異なる無線ベアラと論理チャネルとの間で多重化を行う。PDCPサブレイヤ414はまた、無線送信のオーバーヘッドを低減するための上位レイヤのデータパケットのヘッダ圧縮、データパケットの暗号化によるセキュリティ、および、ノードB間のUEのハンドオーバのサポートを実現する。
RLCサブレイヤ412は、一般に、(確認および再送信プロセスがエラー訂正に使用され得る)確認応答モード(AM)、非確認応答モード(UM)、およびデータ転送のための透過モードをサポートし、上位レイヤのデータパケットのセグメント化および再アセンブルを行い、データパケットを整理し直してMACレイヤにおけるハイブリッド自動再送要求(HARQ)による適切でない受信を補償する。確認応答モードにおいて、RNCなどのRLCピアエンティティ、およびUEは、数ある中でもRLCデータPDU、RLCステータスPDU、およびRLCリセットPDUを含む様々なRLCプロトコルデータユニット(PDU)を交換することができる。本開示において、「パケット」という用語は、RLCピアエンティティ間で交換された任意のRLC PDUを指し得る。
MACサブレイヤ410は、論理チャネルとトランスポートチャネルとの間の多重化を実現する。MACサブレイヤ410は、UE間の1つのセルにおいて様々な無線リソース(たとえば、リソースブロック)を割り当てることの責任も負っている。MACサブレイヤ410は、HARQ動作の責任も負っている。
図5は、例示的なUE550と通信している例示的なノードB510のブロック図であり、ノードB510は図2のノードB208であってよく、UE550は図2のUE210であってよい。ダウンリンク通信では、送信プロセッサ520は、データソース512からデータを受信し、コントローラ/プロセッサ540から制御信号を受信し得る。送信プロセッサ520は、データ信号および制御信号ならびに基準信号(たとえば、パイロット信号)のための様々な信号処理機能を提供する。たとえば、送信プロセッサ520は、誤り検出のための巡回冗長検査(CRC)コード、順方向誤り訂正(FEC)を支援するためのコーディングおよびインターリービング、様々な変調方式(たとえば、二位相偏移変調(BPSK)、四位相偏移変調(QPSK)、M-位相偏移変調(M-PSK)、M-直角位相振幅変調(M-QAM)など)に基づいた信号コンスタレーションへのマッピング、直交可変拡散率(OVSF)による拡散、ならびに、一連のシンボルを生成するためのスクランブリングコードとの乗算を提供し得る。チャネルプロセッサ544からのチャネル推定値は、送信プロセッサ520のためのコーディング方式、変調方式、拡散方式、および/またはスクランブリング方式を決定するために、コントローラ/プロセッサ540によって使用することができる。これらのチャネル推定値は、UE550によって送信される基準信号から導出され得るか、またはUE550からのフィードバックから導出され得る。送信プロセッサ520によって生成されたシンボルは、フレーム構造を作成するために、送信フレームプロセッサ530に供給される。送信フレームプロセッサ530は、コントローラ/プロセッサ540からの情報とシンボルとを多重化することによって、このフレーム構造を作成し、一連のフレームを生じさせる。次いでこれらのフレームは送信機532に与えられ、送信機532は、アンテナ534を通じたワイヤレス媒体によるダウンリンク送信のために、増幅、フィルタリング、およびフレームのキャリア上への変調を含む、様々な信号調整機能を提供する。アンテナ534は、たとえば、ビームステアリング双方向適応アンテナアレイまたは他の同様のビーム技術を含む、1つまたは複数のアンテナを含む場合がある。
UE550において、受信機554は、アンテナ552を通じてダウンリンク送信を受信し、その送信を処理してキャリア上に変調された情報を復元する。受信機554によって復元された情報は、受信フレームプロセッサ560に与えられ、受信フレームプロセッサ560は、各フレームを解析し、フレームからの情報をチャネルプロセッサ594に提供し、データ信号、制御信号、および基準信号を受信プロセッサ570に提供する。受信プロセッサ570は次いで、ノードB510中の送信プロセッサ520によって実行される処理の逆を実行する。より詳細には、受信プロセッサ570は、シンボルを逆スクランブルおよび逆拡散し、次いで変調方式に基づいて、ノードB510によって送信された、最も可能性の高い信号コンスタレーション点を求める。これらの軟判定は、チャネルプロセッサ594によって計算されるチャネル推定値に基づき得る。そして軟判定は、データ信号、制御信号、および基準信号を復元するために、復号されてデインターリーブされる。次いで、フレームの復号に成功したかどうかを判断するために、CRCコードが検査される。次いで、復号に成功したフレームによって搬送されるデータがデータシンク572に与えられ、データシンク572は、UE550および/または様々なユーザインターフェース(たとえばディスプレイ)において実行されているアプリケーションを表す。復号に成功したフレームが搬送する制御信号は、コントローラ/プロセッサ590に与えられる。受信プロセッサ570によるフレームの復号が失敗すると、コントローラ/プロセッサ590はまた、確認応答(ACK)プロトコルおよび/または否定応答(NACK)プロトコルを使用して、そうしたフレームの再送信要求をサポートし得る。
アップリンクでは、データソース578からのデータおよびコントローラ/プロセッサ590からの制御信号が、送信プロセッサ580に供給される。データソース578は、UE550および様々なユーザインターフェース(たとえば、キーボード)において実行されているアプリケーションを表し得る。ノードB510によるダウンリンク送信に関して説明される機能と同様に、送信プロセッサ580は、CRCコード、FECを容易にするためのコーディングおよびインターリービング、信号コンスタレーションへのマッピング、OVSFによる拡散、ならびに、一連のシンボルを生成するためのスクランブリングを含む、様々な信号処理機能を提供する。ノードB510によって送信される基準信号から、または、ノードB510によって送信されるミッドアンブル中に含まれるフィードバックから、チャネルプロセッサ594によって導出されるチャネル推定値が、適切なコーディング方式、変調方式、拡散方式、および/またはスクランブリング方式を選択するために使用され得る。送信プロセッサ580によって生成されたシンボルは、フレーム構造を作成するために、送信フレームプロセッサ582に供給される。送信フレームプロセッサ582は、コントローラ/プロセッサ590からの情報とシンボルとを多重化することによって、このフレーム構造を作成し、一連のフレームを生じさせる。次いでこれらのフレームは送信機556に与えられ、送信機556は、アンテナ552を通じたワイヤレス媒体によるアップリンク送信のために、増幅、フィルタリング、およびフレームのキャリア上への変調を含む、様々な信号調整機能を提供する。
アップリンク送信は、UE550において受信機機能に関して説明されたのと同様の方式で、ノードB510において処理される。受信機535は、アンテナ534を通じてアップリンク送信を受信し、その送信を処理してキャリア上に変調された情報を復元する。受信機535によって復元された情報は、受信フレームプロセッサ536に与えられ、受信フレームプロセッサ536は、各フレームを解析し、フレームからの情報をチャネルプロセッサ544に提供し、データ信号、制御信号、および基準信号を受信プロセッサ538に提供する。受信プロセッサ538は、UE550中の送信プロセッサ580によって実行される処理の逆を実行する。次いで、復号に成功したフレームによって搬送されたデータ信号および制御信号は、それぞれデータシンク539およびコントローラ/プロセッサに供給することができる。フレームの一部が受信プロセッサによる復号に失敗すると、コントローラ/プロセッサ540はまた、肯定応答(ACK)プロトコルおよび/または否定応答(NACK)プロトコルを使用して、それらのフレームに対する再送信要求をサポートすることができる。
コントローラ/プロセッサ540およびコントローラ/プロセッサ590は、それぞれノードB510およびUE550での動作を指示するために使用することができる。たとえば、コントローラ/プロセッサ540および590は、タイミング、周辺インターフェース、電圧調整、電力管理、および他の制御機能を含む、様々な機能を実現することができる。メモリ542および592のコンピュータ可読媒体は、それぞれ、ノードB510およびUE550のためのデータおよびソフトウェアを記憶し得る。ノードB510におけるスケジューラ/プロセッサ546は、リソースをUEに割り振り、UE用のダウンリンク送信および/またはアップリンク送信をスケジュールするために使用され得る。
様々なタイプのシステムおよび装置を今説明したが、次に、そのようなシステムおよび装置とともに使用され得る異なるタイプの機能、アルゴリズム、および構造に注目する。この複雑なスマートフォンデバイスおよびアプリケーションの時代に、UEバッテリー寿命の最適化は、スマートフォンユーザエクスペリエンスを強化し得る。たとえばアップリンクまたはダウンリンク専用物理チャネル(DPCH)など、専用チャネル上で送信される回線交換(CS)ボイスサービスは、UMTSネットワークにおけるエンドユーザにとって重要なアプリケーションのままであり続ける。しかしながら、CSボイスサービスは、2Gセルラー技術(たとえば、GSM(登録商標))と比較して、かなりの量のUEモデムトランシーバ電流を消費する。
UEモデム電流の節約を達成するための1つの技法または方法は、ダウンリンクとアップリンクの両方における不連続送信(DTX)を導入することであり、これは、当業者にはよく知られている。概して、DTX動作は、(たとえば、限定はしないが、送信機556内の増幅器回路を含む)トランシーバの1つまたは複数の電力消費部分の周期的または断続的なシャットダウンを提供する。しかしながら、DTX動作は、潜在的にリンク効率の影響、ならびにアップリンクリンクバジェットの影響をもたらし得る。
本開示の一態様は、必ずしもいずれかのリンク上のリンク効率への影響を損なうことなく、(たとえば、適応マルチレート(AMR)12.2kbpsのCSボイスコーデックを利用した)専用チャネル上の回線交換音声通話の不連続送信(DTX)をサポートするために、UMTSにおいて利用可能な既存の物理レイヤ(たとえば、図4の物理レイヤ406)送信および受信構成の再利用を対象とする。さらなる態様は、UEが制限された電力ヘッドルームであるとき、セル内の領域におけるアップリンクカバレージの影響を低減または回避することを対象とする。
UMTSにおける従来の回線交換音声通話において、AMRと呼ばれるマルチレートボイスコーデックが使用される。この従来のAMRコーデックの動作の詳細は、当業者にはよく知られており、したがって、本開示では省略される。AMRコーデックの一態様は、音声データに対応するビットの再構成および符号化の間、ビットがエラーに対するそれらの感度に従ってソートされ、それに応じて、エラー感度に対応する重要性の3つのクラス、クラスA、クラスB、およびクラスCにソートされることである。クラスAは、エラーに最も敏感であり、したがって、従来のコーデックでは、クラスAのビットは、最も強いチャネルコーディングを受ける。
一般性の喪失なしに、以下の技法を説明するために、AMR 12.2kbps CSボイスコーデックが想定され得る。技法は、たとえばAMR 5.9kbpsまたはエンハンスドボイスサービス(EVS: enhanced voice service)など、他のコーデックにも適用可能である。
図6は、20msのTTIを使用したDPCH上のAMR 12.2kbpsの回線交換音声送信の従来の送信フォーマットを示すタイミング図である。シグナリングメッセージが送信されるときも、それは符号化され、符号化された回線交換ボイスフレームで時分割多重化され、40msのTTIに及ぶ(簡単のために図6には図示せず)ことに留意されたい。
図6に示されるように、1次共通制御物理チャネル(P-CCPCH)無線フレーム602は、10msのTTIを使用して送信され得る。P-CCPCHは、一般に、UE(たとえば、図2、図3、および図5のUE)が、システムにアクセスするために使用する情報を含む、ブロードキャストチャネル(BCH)を含む、ブロードキャスト情報を運ぶ。単一のP-CCPCH無線フレーム602が示されているが、1つよりも多くのそのようなフレームが送信され得る。ダウンリンク(DL)DPCHパケット604およびアップリンク(UL)DPCHパケット606は、20msのTTIを利用し得る。示されるように、第1のまたは最左のDL DPCHパケット604の開始は、時間TDPCHだけP-CCPCH無線フレーム602の開始からオフセットされ得る。同様に、第1のまたは最左のUL DPCHパケット606の開始は、時間Toだけ第1のDL DPCHパケット604の開始からオフセットされ得、これは、1024チップに等しくなり得る。
UEバッテリー消費電力の節約を達成する1つの方法は、図7に示されるように、不連続送信を導入することによって、UE(たとえば、UE550)での送信および受信の短縮を考慮することである。図7に図示した例において、アップリンク(UL)606'とダウンリンク(DL)604'の両方におけるボイスパケットは、依然としてボイスコーデックで20msごとに生成されるが、10msのTTIを使用してオーバージエアで送信される。言い換えれば、20msの全TTIウィンドウの第1の部分(たとえば、最初の10ms)の間、ボイスパケットの送信が行われ得、20msの全TTIウィンドウの第2の部分または残り(たとえば、第2の10ms)の間、ボイスパケットの送信は行われない可能性があり、したがって、ボイスパケットの送信は、この第2の部分または残りの間、一時停止され得る。ここで、ボイスパケットの送信を一時停止することは、ボイスパケットの送信を一時的に切断する(ゲーティングまたはオフにする)ことを含み得る。送信の一時停止は、トランシーバ110(図1を参照)の1つもしくは複数の構成要素または部分、または限定はしないが送信機556(もしくはたとえば電力増幅器など送信機556の下位構成要素)を含むUE550の1つまたは複数の構成要素または部分の電力を低下させることによって、様々な例において達成され得る。一般に、送信は、TTIウィンドウの最初の部分の間に行われ得るが、これは、必ずしもそうである必要はない。概して、送信が行われるTTIウィンドウの部分は、TTIの第1の部分と呼ばれ得るが、一方、送信が一時停止されるTTIウィンドウの部分は、TTIの第2の部分または残りと呼ばれ得る。すなわち、送信がTTIウィンドウの最初の部分の間に行われる例では、TTIの第2の部分または残りは、送信の終了からTTIウィンドウの終わりまで延長し得る。送信がTTIウィンドウの最初の部分以外の任意の部分の間に行われる例では、TTIの第2の部分または残りは、概して、送信が行われるTTIウィンドウの部分を除く、TTIウィンドウのすべてを含む、第1の部分の前、および第1の部分の後のTTIウィンドウの部分を含み得る。このようにして、UE送信機556は、たとえば、時間の50%など、ゲート制御され得、かなりのUEモデムの電流の節約につながる。
本開示のさらなる態様では、追加または代替の技法は、省電力化を得るために使用され得る。たとえば、送信されたデータまたはパケットのスロットフォーマットは、パイロットビットを除外し得る。ここで、パイロットビットをフレームの送信に関連したスロットフォーマットから除外することによって、フレームに対応するデータ情報は、より少ないスロットまたはシンボルに編成され得る。パイロットビットの削除は、データのためのより多くの数のビットを提供する。省電力化は、パイロットビットを送信する必要がないことから得られ得る。この点で、データまたはパケットのスロットフォーマットを決定するために、図1のメモリ105に記憶されたスロットフォーマットパラメータ126は、プロセッサ104によって検査され得る。スロットフォーマットパラメータ126は、パイロットビットが含まれるかどうかの指示または指定を含み得る。
ボイスパケットまたはフレームがTTIの一部のみを利用して送信され、送信がTTIの残りの間一時停止されるDTX構成の間、TTIの全部がパケットの送信のために使用される非DTX構成に対して、瞬間の送信機電力は増加し得る。たとえば、DTX動作の間、送信の所望の呼品質または信頼性を維持するために、瞬間の送信電力は増加し得る。しかしながら、漸進的電力が利用できない場合、本開示の態様は、TTIの全部を利用する動作に「フォールバックする」ことを伴い得る。たとえば、送信機電力が制限されたヘッドルームである場合、動作は、TTIウィンドウの一部を消費するDTX構成からTTIウィンドウの全部または実質的にすべてを消費する非DTX構成までフォールバックし得る。この点で、DTX構成と非DTX構成との間の変更または動的切替えが設けられ得る。しきい値(たとえば、図1のメモリ105に記憶されたしきい値124)に対する利用可能な電力(たとえば、図1のメモリ105に記憶された電力ヘッドルームに対応し得る送信電力パラメータ130によって提供される)は、たとえば、TTIウィンドウの一部または全部を使用して送信するべきかどうか決定するために、プロセッサ104によって検査され得、送信されているパケットまたはデータの識別に基づき得る。図1には別々に示されているが、しきい値124および送信電力パラメータ130は、共通のパラメータに結合され得る。
図1のメモリ105は、使用のための拡散率を選択するためにプロセッサ104によって検査され得る拡散率パラメータ128の1つまたは複数の値を含み得る。たとえば、ダウンリンクチャネルコーディングおよびフレーム処理では、拡散率は、20msのTTIを利用した回線交換音声通話について3GPP規格に指定されたように、128の値に設定され得る。しかしながら、本開示のいくつかの態様では、拡散率は、20msのTTIを利用した回線交換音声通話について、64の低減された値に設定され得る。低減された拡散率を利用することによって、ビットは、他の場合よりも短い持続時間に及ぶことが可能になる。したがって、本開示の一態様では、たとえば、図7に関して上述したように、TTIウィンドウの一部を消費する送信を取得するために、たとえば64の拡散率など、拡散率の低減が使用され得る。
この例では、本開示のさらなる態様では、ビット当たりの送信時間の減少のために経験され得る品質の任意の低減を補償するために、送信電力が増加し得る。メモリ105は、プロセッサ104が使用する送信電力を選択できるようにするための送信電力パラメータ130を含み得る。以下でさらに詳細に説明するように、1つまたは複数の電力制御機構または技法は、送信電力の増加の量を自動的に決定するために使用され得る。
本開示のさらに別の態様では、図7に関して上記で説明した送信のために音声またはデータフレームの一部を使用することに関して、パンクチャリング技法が使用され得る。パンクチャリングは、さもなければ品質(たとえば、冗長性または信頼性)のために含まれたかもしれないビットなど、1つまたは複数のビットの除去を伴う。図1を参照すると、メモリ105は、パンクチャするかどうか、およびどの程度までパンクチャするかを決定するために、プロセッサ104によって検査され得るパンクチャリングパラメータ132を含む。いくつかの例では、さもなければパンクチャリングを使用して経験され得る品質の減少は、送信電力を増加させることによって補償され得る。さらに、いくつかの例では、パンクチャリングは、フレームをTTIの一部のみを利用して送信できるようにするために拡散率を低減することの代替として使用され得る。
メモリ105は、1つまたは複数のレートマッチング属性134も含み得る。UMTSネットワークにおいて、レートマッチングは、一般に、送信されるビットの数が単一のフレームで利用可能なビットの数に一致するように使用される。これは、一般に、フレームのビットをパンクチャすることによって、および/またはフレーム内のビットの反復によって達成される。レートマッチングは、本明細書でレートマッチング属性と呼ばれる適切なパラメータに従って制御され得る。すなわち、レートマッチング属性は、フレームに適用するためのパンクチャリングの量および/またはフレームに適用するためのビットの反復の量に対応し得るレートマッチング値を計算するために、上位レイヤからシグナリングされ得る。したがって、本開示のいくつかの態様では、適切なレートマッチング属性は、パンクチャリングの所望の量に従って選択され得る。レートマッチング属性134は、追加または代替として、1つまたは複数の追加のパケットに対する第1のパケットの重要性を制御または決定するために使用され得る。ここで、レートマッチング属性134に基づいて、第1のパケットが第2のパケットよりも重要であると決定された場合、第1のパケットは、第2のパケットに対して、受けるパンクチャリングが少ない可能性がある。たとえばシステムによって実行されるパンクチャリングの総量など、パンクチャリングの量は、1つまたは複数のチャネル(たとえば、物理チャネルにマッピングする論理またはトランスポートチャネル)の容量に基づき得る。レートマッチング属性134は、1つまたは複数の標準または仕様(たとえば、物理レイヤ仕様)に基づき得、またはそこにおいて定義され得、例示的に、あらかじめ決定された範囲の値内の数値に関して表され得る。1つまたは複数のレイヤは、トランスポートチャネルごとにレートマッチング属性134を割り当てることができる。トランスポートチャネル上のビットの数は、異なるTTIの間で変わり得る。
明示的な信号は、実行するためのパンクチャリングの量を決定するために使用され得る。明示的な信号の使用は、レートマッチング属性(たとえば、レートマッチング属性134)の使用に加える、またはその代替とすることができる。レートマッチング属性の使用は一般に、送信され得る最大のパケットのサイズに合わせて調整される、またはそれに基づくので、明示的な信号の使用はより大きい柔軟性を提供することができる。明示的な信号の使用は、サポートされる最大のパケットよりも小さいパケットのためにパンクチャリングを調整またはカスタマイズするために使用され得る。一例では、明示的な信号は、トランスポートフォーマットコンビネーションセット(TFCS: transport format combination set)構成の一部として提供され得る。すなわち、UMTSネットワークは、TFCS構成を定義するためにシグナリングを提供し、TFCSは、トランスポートチャネルのために使用され得る1組のフォーマットである。
UEでの省電力化を提供するために使用され得る別の技法は、フレーム早期終了(FET: frame early termination)を含む。フレーム早期終了は、フレームの実際の終了の前にフレームの送信または受信を終了することを伴う。たとえば、受信デバイスは、フレームが受信されている時間の間にフレームを復号している可能性がある。時間とともに、フレームが受信され続ける間、フレームは、その全体が正しく復号され得る。これは、特にそれが高度の符号化および前方誤り訂正を含むとき、フレームの冗長性のために起こり得る。フレームが復号されるとき、受信デバイスは、その受信機を遮断することができ得る。さらに、受信デバイスは、たとえば肯定応答メッセージなどのフィードバックを送信デバイスに送信することができ得る。したがって、送信デバイスは、その完全な送信の前にフレームの送信を終了することができ得る。このフレーム早期終了方式は、送信および受信デバイスで消費電力を低減することができ、ならびにフレームの送信によって利用されるオーバージエアリソースを低減することができる。図1を参照すると、メモリ105は、フレーム早期終了属性136を含むものとして示される。フレーム早期終了属性136は、フレーム早期終了が有効であるか無効であるかを示すことができる。本開示のいくつかの態様では、フレーム早期終了は、早期の復号と結合され得る。早期の復号とともに、フレームの受信機(たとえば、図5の受信機535、554)は、それがフレームの終了の前にフレームのデータを取得したことを検出することができる。受信機は、データに存在する冗長性の結果として、フレームの終了の前に、フレームのデータを受信することができる。受信機は、フレームの終了の前に必要とされる任意のデータを取得する場合、省電力化を有効にするために、電源切断またはターンオフすることができる。受信機は、肯定応答をフレームの送信機(たとえば、図5の送信機556、532)に送信することもできる。送信機は、肯定応答を受信すると、リソースを節約するためにフレームを送信するのを止めることができ、省電力化を有効にするために、電源切断することができる。
本開示の態様によれば、早期復号は、上述したようにクラスA、クラスB、およびクラスCとして表され得るビットの複数のクラスに関して一般の完全性チェック(たとえば、巡回冗長検査(CRC))の使用によって容易にされ得る。すなわち、従来のAMRコーデックでは、完全性チェックは、単一のクラス(たとえば、クラスA)のみについて適用または決定され得る。このようにして、(たとえば、クラスAのビットなど)エラーに最も敏感な情報は、よりよく保存され得る。早期復号が利用される本開示の一態様によれば、第1のクラスにおいて実行される早期復号が、復号が成功した(たとえば、CRCが通過した)ことを示す場合、第2および第3のクラス(たとえば、クラスBおよびクラスC)もそれらのエラー率の点で許容できると仮定され得る。しかしながら、第1のクラスが許容できた場合でも、第2および第3のクラスは、実際は、品質の低下を被り得る。したがって、本開示のいくつかの態様は、クラスA、クラスB、およびクラスCのビットのすべてについて、一般の完全性チェックを適用し、それによって、クラスA、クラスB、およびクラスCのビットのエラーのない送信を得る点で、早期復号の信頼性が向上することを対象とする。
ビットのいくつかのクラスについて一般の完全性チェックを提供するために、クラスA、クラスB、およびクラスCのビットのジョイント符号化が提供され得る。ここで、ビットのいくつかのクラスをジョイント符号化することは、ビットのクラスのすべてに対する単一の適切な符号化アルゴリズムの適用を指し得る。上述したように、クラスAのビットは、エラーにより敏感であるので、従来、クラスBおよびCのビットよりもロバストに符号化される。いくつかのクラスをジョイント符号化することによって、クラスAのビットの完全性を確実にするために、あまり重要ではないクラスBおよびCのビットは、ロバストに符号化され、冗長性を増加させることになるので、総スループットに何らかの影響があり得る。しかしながら、一方では、ビットをジョイント符号化することによって、潜在的に1つまたは複数のエラーチェックアルゴリズムまたは値(たとえば、チェックサム値、CRC値など)に基づく、クラスAのビットの復号の成功は、さもなければ、クラスA、B、およびCのビットがジョイント符号化されなかった場合に起こり得るクラスBおよびCのビットのビット誤り率(BER)を増加させることなく、クラスBおよびCビットに関して、フレーム早期終了を有効にし得る。
本開示の態様によれば、図1のメモリ105は、符号化レートパラメータ138を含む。符号化レートパラメータ138は、エンコーダによって使用するための符号化レートを含み得る。上述した図7のTTI構成は、ベースラインレートコードに対するより高いレートコードによる符号化によって得られ得る。
次に図8を参照すると、ワイヤレス通信を実行するために構成されたプロセッサ800が示される。いくつかの例では、プロセッサは、上述し、図1に図示されたプロセッサ104、および/または図5のプロセッサ560、570、582、590、および594のうちの1つまたは複数と同じとすることができる。プロセッサ800は、たとえば、図7に関して上述した方法でDTXを使用してワイヤレス通信に関与するために、図1、図2、図3、および/または図5に示されるようなUEなどの装置を有効にするように機能し得る。プロセッサ800は、たとえば、図13に関して後述するアルゴリズムなど、1つまたは複数のプロセッサまたはアルゴリズムを実行するための手段として働き得る1つまたは複数の回路を含む。プロセッサ800は、たとえば図1のメモリ105に記憶されるものなど、1つまたは複数のパラメータまたは値に基づいて動作可能であり得る。
装置800は、TTI選択およびDTX使用可能性/フォールバック回路802を含む。回路802は、パケットまたはフレーム(たとえば、ボイスフレーム)を送信および受信するために使用され得る、TTIもしくはTTIウィンドウまたはその1つもしくは複数の部分の選択を可能にし得る。TTIもしくはTTIウィンドウ、またはその1つもしくは複数の部分の選択は、DTX送信のために利用されるTTIウィンドウの選択または持続時間が時間とともに変わり得るという点で動的であり得る。回路802は、DTX動作を選択的に有効にし得る。たとえば、UE(たとえばUE550)が利用可能な電力など、1つもしくは複数の要因もしくはパラメータに基づいて、DTXは、有効もしくは無効にされ得、または、UEは、DTX構成と非DTX構成との間で変わり得る。いくつかの例では、回路802は、少なくとも部分的に図1のTTI値122に基づいて動作可能であり得る。
パイロットビット除外回路804は、部分的に、1つまたは複数のフレームの送信に関連したスロットフォーマットを選択し得る。選択されたスロットフォーマットは、上述したように、パイロットビットを除外することができる。回路804は、少なくとも部分的に図1のスロットフォーマットパラメータ126に基づいて動作可能であり得る。
電力ヘッドルーム決定回路806は、たとえばUE550などのデバイスに関して、(たとえば、所要の電力の量が電力制限または電力容量に近づくとき)電力ヘッドルームが制限されているかどうかを決定することができる。いくつかの例では、電力ヘッドルーム決定回路806は、制限にいつ達したかを示すために、信号またはステータスフラグを提供することができる。ステータスフラグは、TTIウィンドウを選択もしくは変更する、またはDTXを有効/無効にするために、回路802によって使用され得る。回路806は、少なくとも部分的に図1のしきい値124および/または送信電力130に基づいて動作可能であり得る。
拡散率低減回路808は、拡散率を選択または低減することができる。拡散率低減回路808の出力は、TTIウィンドウを選択または変更するために、回路802によって使用され得る。回路808は、少なくとも部分的に図1の拡散率パラメータ128に基づいて動作可能であり得る。
送信電力決定回路810は、送信のために使用される電力を選択または調整することができる。たとえば、回路810は、送信のための電力を選択する際の1つまたは複数の環境条件を決定または測定することができる。別の例では、回路810は、UEがDTX構成で動作しているか、非DTX構成で動作しているかに従って送信電力を選択または調整することができる。回路810は、少なくとも部分的に図1のしきい値124および/または送信電力パラメータ130に基づいて動作可能であり得る。
データパンクチャリング回路812は、フレームのビットのパンクチャリングが実行されるかどうか、およびどの程度まで実行されるかを決定することができる。回路812は、少なくとも部分的にパンクチャリングパラメータ132に基づいて動作可能であり得る。
レートマッチング属性調整回路814は、1つまたは複数のレート属性を選択および/または調整することができる。たとえば、レートマッチング属性調整回路814は、1つまたは複数の追加パケットに対して第1のパケットをレーティングする、または優先順位を付けるように構成され得る。レートマッチング属性調整回路814によって提供されるレーティング/優先順位付けが、データパンクチャリング回路812への入力として使用され得る。レートマッチング属性調整回路814は、少なくとも部分的に図1のレートマッチング属性134に基づいて動作可能であり得る。
フレーム早期終了回路816は、1つまたは複数のフレームに関連したデータの送信または受信を遮断することが適切かどうかを決定することができる。たとえば、回路816は、フレームに関連したデータの第1の部分がいつ復号されたかを決定することができ、したがって、フレームに関連したデータの残りは無視され得る。回路816は、少なくとも部分的に図1のフレーム早期終了(FET)属性136に基づいて動作可能であり得る。
エンコーダ回路818は、1つまたは複数のフレーム(たとえば、ボイスフレーム)に関して、データの符号化を提供することができる。いくつかの例では、エンコーダ回路818は、限定はしないが畳み込みコーディングブロック1208を含む図10〜図12における1つまたは複数のブロックと同様でもよい。回路818は、少なくとも部分的に、図1の符号化レートパラメータ138によって提供され得る1つまたは複数の符号化レートに基づいて、そのような符号化を実行することができる。
図9は、ワイヤレス通信を実行するためのコンピュータ可読媒体900のソフトウェアを示す。コンピュータ可読媒体900は、図1のコンピュータ可読媒体106に対応し得る。コンピュータ可読媒体900のソフトウェア(たとえば、図1のソフトウェア107)は、1つまたは複数のアルゴリズム(たとえば、図13に関連したアルゴリズム)を実行するための命令、たとえば実行可能命を含み得る。コンピュータ可読媒体900は、たとえば図1のメモリ105に記憶されるものなど、1つまたは複数のパラメータまたは値に基づいて動作可能であり得る。
コンピュータ可読媒体900は、TTI選択およびDTX使用可能性/フォールバックソフトウェア902を含む。ソフトウェア902は、パケットまたはフレーム(たとえば、ボイスフレーム)を送信および受信するために使用され得る、TTIもしくはTTIウィンドウまたはその1つもしくは複数の部分の選択を可能にし得る。TTIもしくはTTIウィンドウ、またはその1つもしくは複数の部分の選択は、DTX送信のために利用されるTTIウィンドウの選択または持続時間が時間とともに変わり得るという点で動的であり得る。ソフトウェア902は、DTX動作を選択的に有効にし得る。たとえば、UE(たとえばUE550)が利用可能な電力など、1つもしくは複数の要因もしくはパラメータに基づいて、DTXは、有効もしくは無効にされ得、または、UEは、DTX構成と非DTX構成との間で変わり得る。いくつかの例では、ソフトウェア902は、少なくとも部分的に図1のTTI値122に基づいて動作可能であり得る。
パイロットビット除外ソフトウェア904は、部分的に、1つまたは複数のフレームの送信に関連したスロットフォーマットを選択し得る。選択されたスロットフォーマットは、上述したように、パイロットビットを除外することができる。ソフトウェア904は、少なくとも部分的に図1のスロットフォーマットパラメータ126に基づいて動作可能であり得る。
電力ヘッドルーム決定ソフトウェア906は、たとえばUE550などのデバイスに関して、(たとえば、所要の電力の量が電力制限または電力容量に近づくとき)電力ヘッドルームが制限されているかどうかを決定することができる。いくつかの例では、電力ヘッドルーム決定ソフトウェア906は、制限にいつ達したかを示すために、信号またはステータスフラグを提供することができる。ステータスフラグは、TTIウィンドウを選択もしくは変更する、またはDTXを有効/無効にするために、ソフトウェア902によって使用され得る。ソフトウェア906は、少なくとも部分的に図1のしきい値124および/または送信電力130に基づいて動作可能であり得る。
拡散率低減ソフトウェア908は、拡散率を選択または低減することができる。拡散率低減ソフトウェア908の出力は、TTIウィンドウを選択または変更するために、ソフトウェア902によって使用され得る。ソフトウェア908は、少なくとも部分的に図1の拡散率パラメータ128に基づいて動作可能であり得る。
送信電力決定ソフトウェア910は、送信のために使用される電力を選択または調整することができる。たとえば、ソフトウェア910は、送信のための電力を選択する際の1つまたは複数の環境条件を決定または測定することができる。別の例では、回路810は、UEがDTX構成で動作しているか、非DTX構成で動作しているかに従って送信電力を選択または調整することができる。ソフトウェア910は、少なくとも部分的に図1のしきい値124および/または送信電力パラメータ130に基づいて動作可能であり得る。
データパンクチャリングソフトウェア912は、フレームのビットのパンクチャリングが実行されるかどうか、およびどの程度まで実行されるかを決定することができる。ソフトウェア912は、少なくとも部分的にパンクチャリングパラメータ132に基づいて動作可能であり得る。
レートマッチング属性調整ソフトウェア914は、1つまたは複数のレート属性を選択および/または調整することができる。たとえば、レートマッチング属性調整ソフトウェア914は、1つまたは複数の追加パケットに対して第1のパケットをレーティングする、または優先順位を付けるように構成され得る。レートマッチング属性調整ソフトウェア914によって提供されるレーティング/優先順位付けが、データパンクチャリングソフトウェア912への入力として使用され得る。レートマッチング属性調整ソフトウェア914は、少なくとも部分的に図1のレートマッチング属性134に基づいて動作可能であり得る。
フレーム早期終了ソフトウェア916は、1つまたは複数のフレームに関連したデータの送信または受信を遮断することが適切かどうかを決定することができる。たとえば、ソフトウェア916は、フレームに関連したデータの第1の部分がいつ復号されたかを決定することができ、したがって、フレームに関連したデータの残りは無視され得る。ソフトウェア916は、少なくとも部分的に図1のフレーム早期終了(FET)属性136に基づいて動作可能であり得る。
エンコーダソフトウェア918は、1つまたは複数のフレーム(たとえば、ボイスフレーム)に関して、データの符号化を提供することができる。ソフトウェア918は、少なくとも部分的に、図1の符号化レートパラメータ138によって提供され得る1つまたは複数の符号化レートに基づいて、そのような符号化を実行することができる。
以下の開示において、ボイスパケットが、1つまたは複数の例に従って図7のTTIまたはTTIウィンドウの一部を使用してどのように符号化され、送信されるかについて、詳細が提供される。さらに、ボイスフレームのDTX送信にTTIの一部を使用するために、リンク効率およびアップリンクカバレージに対する潜在的な影響を低減または回避することができる技法および方法が記載される。
Rel-99 DCHにおけるベースライン適応マルチレート(AMR)12.2kbpsの回線交換(CS)ボイスサービスのダウンリンクチャネルコーディングおよび送信時間間隔(TTI)処理
背景情報として、AMR 12.2kbpsのCSボイスフレームが、専用制御チャネル(DCCH)にマッピングされるシグナリング無線ベアラ(SRB)とともに、ダウンリンク専用トラフィックチャネル(DTCH)上でどのように送信されるかに関するいくつかの関連した詳細が、以下のセクションにおけるさらなる考察のためのベースラインとして、このセクションで示される。
Table 1(表1)は、CSボイスパケットビット(クラスA/B/C、無音識別子(SID)、およびNULL)、ならびにいくつかのフィールドを使用してDCCH上で送られるSRBビットについてのチャネル符号化パラメータを列挙する。
上記のTable 1(表1)で、情報ビットフィールドは、送信されるデータの数またはペイロードビットを表す。CRCフィールドは、受信機での復号手順の一部として完全性のために使用される巡回冗長検査ビットの数を表す。エンコーダテールビットフィールドは、畳み込みエンコーダをあらかじめ定義された状態にリセットするために、データのブロック(データのブロックは情報ビットに対応し得る)の終わりに追加される固定されたビットのシーケンスに対応するカウントを表す。エンコーダO/Pフィールドは、エンコーダの出力におけるビットの数nを表す。畳み込みコードレートフィールドは、nビットコードワードへの情報および(総カウントmの)CRCビットの変換を表し、ここにおいてm/nはコードレートである。TTIフィールドは、送信時間間隔を表す。SFフィールドは、拡散率を表す。
Table 2(表2)は、異なるUMTSネットワークにおいて構成される異なるレートマッチング属性を列挙する。Table 2(表2)は、専用トラフィックチャネル(DTCH)クラスA、B、およびC、ならびに専用制御チャネル(DCCH)についての1、3、4、および5とラベル付けされた/番号が付けられたケースごとの値を提供する。Table 2(表2)におけるDTCHクラスおよびDCCHの値は、UMTSについて3GPP R99規格において指定されたように構成され得るパラメータを表す。具体的には、テーブルに示されるように、利用可能なチャネルビットを符号化された出力ストリームに配信する、レートマッチングアルゴリズムにおける対応するトランスポートチャネルの相対的優先度を決定するために、各トランスポートチャネル上に構成される1組のパラメータセットがあり得る。
一般性の喪失なしに、Table 2(表2)に示されるケース3が、後述される異なる方式とともに使用される。提案された方式の背後にある概念は、他のケースにおいても等しく適用可能である。
Table 3(表3)および図10は、それぞれ、本開示のいくつかの態様に従って、ステージ1002において参照されるDTCHクラスA、BおよびC、ならびにDCCH(3.4kbpsのSRB)の各々について、上記のTable 2(表2)のケース3についての拡散およびRF変調より前のチャネルコーディングの様々なステージを列挙し、示す。異なるステージは、図10では1002〜1014とラベル付けされ、該当する場合、Table 3(表3)において参照される。本開示の様々な態様において、ブロック1002〜1014の各々は、図1に図示されるプロセッサ104(たとえば、コンピュータ可読媒体106に記憶されるソフトウェア107と協調して)、図5に図示されるプロセッサ540および/または594、ならびに/あるいは図8/図9に図示されるプロセッサ800(たとえば、コンピュータ可読媒体900と協調して)によって実施され得る。
図10に示されるように、一般の流れは、(1)ステージ1002からCRCアタッチメントステージ1004、(2)CRCアタッチメントステージ1004からテールビット挿入ステージ1006、(3)テールビット挿入ステージ1006から畳み込みコーディングステージ1008、(4)畳み込みコーディングステージ1008からレートマッチングステージ1010、(5)レートマッチングステージ1010から第1のインターリーバステージ1012、および(6)第1のインターリーバステージ1012から直交位相シフトキーイング(QPSK)モジュレータステージ1014である。
ステージ1002は、潜在的にパケットまたはフレームの一部として、通信チャネルを介して送信されるべき情報またはデータ(図5のデータソース512および/またはデータソース578から潜在的に供給される)を提供する。CRCアタッチメントステージ1004は、通信チャネルを介して伝達される情報またはデータの受信に成功したかどうかを判断するために、受信機(たとえば、図5の受信機535または554)によって利用され得るCRCビットを加える、または追加する。テールビット挿入ステージ1006は、畳み込みコーディングステージ1008をあらかじめ定義された状態にリセットするために、固定されたビットのシーケンスに対応するカウントを加える、または挿入する。畳み込みコーディングステージ1008は、nビットシンボルへの情報/データ(カウントmの)変換を実行し、ここにおいてm/nはコードレートである。レートマッチングステージ1010は、上記の方法でレートマッチングを実行する。インターリーバステージ1012は、パケットが正常に受信される確率を向上させるために使用され得るいくつかのコードワードまたはパケットにわたってシンボルをインターリーブまたはシャッフルする。モジュレータステージ1014は、インターリーバステージ1012の出力をキャリアと結合することによって、変調を実行することができる。
方式A:拡散率の半分低減、10msの送信時間間隔(TTI)における回線交換(CS)音声、20msのTTIにおけるシグナリング無線ベアラ(SRB)
この方式では、ダウンリンクチャネルコーディングおよびフレーム処理は、20msのTTIを利用した交換音声通話について3GPP規格に規定されているようなベースラインチャネルコーディングおよびフレーム処理と同じであり得る。しかしながら、本開示の一態様では、拡散率は、選択された拡散率を使用したボイスフレームの拡散がTTIの一部のみを満たすような値を取るように低減または選択され得る。たとえば、拡散率がベースラインに対して1/2に低減される場合、すなわち、128から64に低減される場合、ボイスフレームは、20msのTTIの最初の半分で送信され得る。
方式B1:同じ拡散率の維持、10msの送信時間間隔(TTI)における回線交換(CS)音声、40msのTTIにおけるシグナリング無線ベアラ(SRB)
上述した方式Aは、チャネライゼーションコード空間における次元数の損失を被る可能性があるので、この結果を低減または回避し得る代替方式は、上述したベースラインと同じ拡散率(128)を依然として維持しながら、CS音声を運ぶDTCHの10msのTTIへのマッピング、およびSRBを運ぶDCCHの40msのTTIへのマッピングを行うことである。これを達成する1つの技法は、本開示の別の態様に従って、Table 4(表4)およびTable 5(表5)に列挙され、図11に図示される。上述した図10に酷似し、図11は、チャネルコーディングの様々なステージ1102〜1114を含む。ステージ1102〜1114は、該当する場合、Table 4(表4)〜Table 5(表5)において参照される。具体的には、Table 4(表4)〜Table 5(表5)および図11は、レートマッチングブロックによって出力されるビットの数を示す。本開示の様々な態様において、ブロック1102〜1114の各々は、図1に図示されるプロセッサ104(たとえば、コンピュータ可読媒体106に記憶されるソフトウェア107と協調して)、図5に図示されるプロセッサ540および/または594、ならびに/あるいは図8/図9に図示されるプロセッサ800(たとえば、コンピュータ可読媒体900と協調して)によって実施され得る。
Table 4(表4)〜Table 5(表5)および図11に見られるように、クラスA/B/CのビットおよびSRBの各々についての畳み込みコードレートは、上述したベースライン設計のように維持され得るが、本開示の一態様では、パンクチャされたフレームがTTIの一部(たとえば、TTIの1/2)のみを満たすように、レートマッチングブロック(ブロック1110)におけるパンクチャリングの量(たとえば、パンクチャリング回路812またはパンクチャリングソフトウェア912によって実行される)は増加し得る。本開示のいくつかの態様では、パンクチャリングの量は、10msごとに300のQPSKシンボルにレートマッチングするように構成され得る。本開示のいくつかの態様では、パンクチャリングのこの増加は、レートマッチング属性(たとえば、図1のレートマッチング属性134)の適切な選択によって達成され得る。代替的に、レートマッチング属性が必要とされるパンクチャリングの量に対する十分な制御を行わない場合、本開示のさらなる態様では、たとえば、各トランスポートフォーマットコンビネーション(TFC)ごとの各トランスポートチャネルにおけるパンクチャリング/反復の量を示すトランスポートフォーマットコンビネーションセット(TFCS)の一部として、適切なシグナリングが利用され得る。Table 5(表5)の例では、パンクチャリングは、それぞれクラスA、BおよびCならびにDCCHビットを運ぶトランスポートチャネルについて159、155、234、および166のレートマッチング属性を使用して達成され得る。
SRBにおける大量のパンクチャリングは、SRBの信頼性に潜在的に影響を及ぼし得る。しかしながら、本開示のさらなる態様では、これは、後述するように、緩和され得る。たとえば、パンクチャリングは、すべてのトランスポートチャネルに適用されるので、電力制御は、より高いパンクチャリングの下でさえ、十分な信頼性を確実にし続けることができる。すなわち、SRB送信電力は、パンクチャリングの量の増加に従って増加し得る。別の例では、パンクチャされたSRBの信頼性が不十分である場合、SRBが送信されるとき、DPDCHシンボルは、余分の電力ブーストが与えられ得る。ここで、ブーストレベルは、信頼性を確実にするように選択され得る。この例では、DPCCH電力は変わらないので、内部ループ電力制御は影響を受けない可能性がある。電力のブーストは、図1のしきい値124および/または送信電力130に基づき得る。
方式B2:同じ拡散率の維持、10msの送信時間間隔(TTI)における回線交換(CS)音声、40msのTTIにおけるシグナリング無線ベアラ(SRB)
方式B1の代替は、ベースラインとして同じ拡散率が維持され、代わりに、クラスA、クラスB、およびDCCH情報ビットについて、畳み込みエンコーダレートを1/2に変更することである。すなわち、本開示のいくつかの態様では、畳み込みエンコーダ1208は、符号化されたボイスフレームがTTIの一部のみを満たすように、適切な符号化レートを利用して、フレームを符号化するように構成され得る。一例として、符号化レート(たとえば1/2)は、符号化されたボイスフレームがTTIの最初の半分のみを満たすことができるように選択され得る。この方式は、Table 6(表6)、Table 7(表7)、および図12に示される。上述した図10〜図11に酷似し、図12は、チャネルコーディングの様々なステージ1202〜1214を含む。ステージ1202〜1214は、該当する場合、Table 6(表6)〜Table 7(表7)において参照される。具体的には、Table 6(表6)〜Table 7(表7)および図12は、レートマッチングブロックによって出力されるビットの数を示す。本開示の様々な態様において、ブロック1202〜1214の各々は、図1に図示されるプロセッサ104(たとえば、コンピュータ可読媒体106に記憶されるソフトウェア107と協調して)、図5に図示されるプロセッサ540および/または594、ならびに/あるいは図8/図9に図示されるプロセッサ800(たとえば、コンピュータ可読媒体900と協調して)によって実施され得る。
レートマッチングブロック(ブロック1210)が300のQPSKシンボルが10msごとに送信されることを依然として確実にすることに留意されたい。Table 7(表7)に示されるパンクチャリングは、それぞれクラスA、B、C、およびDCCHビットを運ぶトランスポートチャネルについて182、175、179、196のレートマッチング属性を使用して達成され得る。
いくつかの変種および拡張
上述した方式A、B1およびB2は、1つまたは複数のバリエーションに従ってさらに修正され、および/または拡張され得る。たとえば、本開示の一態様では、クラスA/B/Cビットは、連結され、単一のトランスポートブロックで送信され得る。この場合、畳み込みコーディングレートおよびレートマッチングパラメータは、これらの方式の各々において10ms当たり送信されるQPSKシンボルの数にレートマッチングを維持するように、それに応じて変更され得る。
別の例では、DPCCHにおけるパイロットフィールドは、低減され、または完全に除去され得る。パイロットがDPCCHから除去される場合、その全長は、無線フレーム当たり45のシンボルから無線フレーム当たり15のシンボルに低減され得る。
さらに別の例では、フレーム早期終了(FET)は、これらの方式のいずれかにおいて実行され得る。すなわち、低減された拡散率、変更されたコーディングレート、ボイスフレームのパンクチャリング、またはパイロットビットの除外のうちの任意の1つまたは複数に加えて、受信デバイスは、フレームが完全に復号されたことを示すフィードバック(たとえば、ACK)を送信し、フレームの送信を早期終了するように送信デバイスに指示することができる。
さらなる一例では、本開示の態様に従ってアップリンクDTXのために構成されたUEは、上述したように、TTIの残りまたは第2の部分の間、いくつかのアップリンク送信を行うように構成され得、この場合、ボイスフレームの送信は、一時停止される。すなわち、UEからの送信が一時停止されている間、受信機(たとえばノードB)での1つまたは複数のチャネルフィルタがオフにされる、またはさもなければ休止中であることが起こり得る。ここで、UEは、次のTTIの間、その送信を再開するとき、最適に送信を開始する準備ができていない可能性があるので、送信されたボイスフレームの一部は、受信機で適切に受信されない場合がある。したがって、本開示の一態様では、UEは、TTIの残りの間、および次のTTIの開始の前に、1つまたは複数のスロット(たとえば、あらかじめ決定された数のスロット)の間、1つまたは複数のパラメータを送信するように構成され得る。たとえば、さもなければ送信が一時停止される、TTIの第2の部分の間、UEは、1つまたは複数のDPCCHパラメータを送信することができる。このようにして、1つまたは複数の送信されたパラメータを受信することによって、受信機(たとえば、ノードB)でのチャネルフィルタは、リフレッシュされ得る。
アップリンク構成に対する変更
各ユーザのチャネライゼーションコードが長いスクランブリングコードによってスクランブルされるので、チャネライゼーションコードリソースは、ダウンリンク方向と比較してアップリンク方向の制約を表さない。その結果、拡散率は、1/2に低減され得、DTCH上のCSボイスフレームは10msのTTIにマッピングされ得、DCCH上のSRBフレームは40msのTTIにマッピングされ得る。処理利得(3dB)の損失およびダイバーシティのわずかな損失があるが、送信における大きいギャップ(10ms)は、送信時間間隔(10ms)の間に、送信電力および受信信号対雑音比(SNR)の増加を補償し、その結果、ベースラインとして、チップ当たりの類似の平均送信(Tx)電力および受信機(Rx)エネルギー/帯域における電力密度(Ec/No)が得られる。
アップリンクカバレージに影響を与えないことを確実にするための10msのTTIと20msのTTIとの間の再構成
UE(たとえば、UE550)が制限された電力ヘッドルームになる(たとえば、所望の電力の量が電力制限または電力容量に近づくとき)状況で、UEは、それがDTXを利用するように構成されたままである場合、アップリンク信号を送信することができない場合があり、これは、音声通話のアップリンクカバレージに影響を与え得る。したがって、本開示のさらなる態様では、UEは、そのようなイベントが起こると、DTX構成(たとえば、ボイスフレームを送信するために20msのTTIウィンドウの10msを使用すること)と非DTX構成(たとえば、20msの全TTIウィンドウを使用すること)との間で変わるように構成され得る。様々な例で、様々なトリガのうちの1つまたは複数は、この変更をトリガまたは開始するために使用され得る。
一例では、UEが複数のセル(たとえば、図3のセル302、304および306)間のソフトハンドオーバに入ると、ネットワーク(たとえば、UTRAN202、図2のネットワーク204)は、UEをDTX構成から非DTX構成に変更するように構成することができる。同様に、UEは、ソフトハンドオーバから出るとき(たとえば、アクティブセットサイズが>1から1に変わるとき)、DTX構成に再構成され得る。
別の例では、UEの総送信電力(たとえば、図1の送信電力パラメータ130または送信電力ヘッドルームにおいて反映される)がヒステリシスあり/なしでしきい値(たとえば、図1のしきい値124)を越えるとき、UEは、ノードB(たとえば、ノードB208、ノードB510)またはRNC(たとえば、RNC206)のいずれかに対応するイベントをシグナリングすることができる。この時点で、ネットワークは、UEを非DTX構成に再構成することができる。同様に、UEの総送信電力がヒステリシスあり/なしでしきい値を下回るとき、UEは、DTX構成に再構成され得る。
さらに別の例では、従来の測定報告の一部として、UEは、たとえば受信信号強度表示(RSSI)、受信信号コード電力(RSCP)、総出力に対するパイロット電力の比(Ec/Io)、またはパス損失などのRF測定値を示す。本開示の一態様では、これらの測定報告量のうちの1つまたは複数を、DTX構成を使用することと非DTX構成を使用することとの間を決めるために適切なしきい値と比較され得る。これらの測定値は、呼がセットアップされた後、CELL_FACHまたはCELL_DCHにおけるランダムアクセスチャネル(RACH)上の呼セットアップ時に報告され得る。
さらに別の例では、UEは、(図1の送信電力パラメータ130において反映され得る)その送信電力が変わるレートを追跡し得る。本開示の一態様では、送信電力の変化率がしきい値(たとえば、図1のしきい値124)を超えるまたは下回る場合、UEは、シグナリングを介してこのイベントをネットワークに知らせることができる。したがって、ネットワークは、UEの送信電力が変わるレートに従って、UEがDTXモードと非DTXモードとの間で変わるようにシグナリングし得る。
さらに別の例では、UEは、一連の「n」個の連続アップリンク送信電力制御(TCP)UPコマンドがノードBから受信されるかどうかを決定するように構成され得る。本開示のさらなる態様では、UEは、「n」個の連続アップリンク電力制御UPコマンドを含む無線フレームに対応するときに、DTX構成と非DTX構成との間で変わり得る。
さらに別の例では、ネットワークが、たとえばアップリンクDPDCHなど、ボイスフレームを運ぶチャネルにおいて高ブロックエラーレート(BLER)を経験する場合、ネットワークは、DTX構成と非DTX構成との間で変わるようにUEを再構成し得る。
本開示のさらなる態様では、DTX構成と非DTX構成との間の変更を促進するために、UEは、たとえば、10msのTTIの構成と20msのTTI構成の両方で事前設定され得る。したがって、ノードBまたはRNCは、最小のシグナリングでDTX構成と非DTX構成との間の変更をシグナリングし得る。たとえば、上記のトリガのうちの1つまたは複数をノードBにシグナリングするために、アップリンク上の未使用のTFCIビットは、UEによって使用され得る。UEがDTX構成と非DTX構成との間で変わることを自律的に決めると、そのようなシグナリングは、UEがDTX構成を変えたことをノードBが理解しない確率を低下させ得る。たとえば、変更がアップリンク送信電力制御(TPC)コマンドのUEモニタリングに基づく場合、ノードBは、それらのTPCコマンドを発行しているので、それらを使用してDTX構成を決定することができる。しかしながら、TPCコマンドの復号におけるUEのエラーのため、この決定は、エラーの影響下にある。したがって、UEによるDTX構成の変更の明示的なシグナリングは、これらのエラーを低減または回避することができる。
本開示のさらなる態様では、DTX構成の変更による音声品質の妨害を回避するために、DTX構成が変わった場合であっても、アップリンクタイミングおよびT-DPCH(フレームオフセット)は同じままであり得る。これは、DTX構成の変更の間、シームレスな移行を確実にする。さらに、チャネライゼーションコードが(シームレスB1、B2または変種のように)ダウンリンク上で同じままである場合、中断は、主に再構成時のチャネルコーディング、レートマッチング、および/またはインターリービング処理の変化による。
次に図13を参照すると、本開示の態様に従ってワイヤレス通信を実行する際に実行される例示的なプロセス1300を示すフローチャートが示される。様々な例において、プロセス1300は、上述したように、図1、図2、図3、図5、図8および/または図9に図示された装置または構造のうちの1つまたは複数によって実施され得る。他の例では、プロセスは、説明した機能を実行するための任意の好適な手段によって実施され得る。
ブロック1302において、拡散率低減/選択ソフトウェア908と協調して動作し得る拡散率低減/選択回路808(図8を参照)は、送信されたボイスフレームの拡散率を選択し、ボイスフレームのビットを拡散することができる。ここでは、拡散率は、拡散されたボイスフレームがTTIの一部(たとえば、半分)のみを満たすように選択され得る。
ブロック1304において、エンコーダソフトウェア918と協調して動作し得るエンコーダ回路818は、符号化されたボイスフレームがTTIの一部(たとえば、TTIの半分)のみを満たすように、選択された符号化レートを利用してボイスフレームを符号化することができる。いくつかの例では、ブロック1304において、たとえばクラスA、クラスB、およびクラスCのビットなど、ビットの複数のクラスは、上述したように、ジョイント符号化され得る。
ブロック1306において、CRCアタッチメントステージまたは回路1004は、符号化ビットのために完全性チェックを適用することができる。ビットの複数のクラスがジョイント符号化される例では、ブロック1306で、一般の完全性チェックは、ジョイント符号化されたビットのクラスのために適用され得る。
ブロック1308において、レートマッチング調整ソフトウェア914と協調して動作し得るレートマッチング調整回路814、および/またはデータパンクチャリングソフトウェア912と協調して動作し得るデータパンクチャリング回路812は、1つまたは複数の調整されたレートマッチング属性に従って、および/またはあらかじめ決定されたレベルのパンクチャリングを示す明示的な信号に従ってパンクチャリングのレベルを決定することができる。
ブロック1310において、データパンクチャリングソフトウェア912と協調して動作し得るパンクチャリング回路812は、パンクチャされたボイスフレームがTTIの一部(たとえば、TTIの半分)のみを満たすように、ボイスフレームのビットをパンクチャすることができる。
ブロック1312において、トランシーバ110は、TTIの一部(たとえば、TTIの半分)の間、回線交換音声通話に対応するボイスフレームを送信することができる。いくつかの例では、送信は、UE送信機556を利用したアップリンク送信でもよく、他の例では、送信は、ノードB送信機532を利用したダウンリンク送信でもよい。ここで、送信電力決定ソフトウェア910と協調して動作し得る送信電力決定回路810は、上述したように、少なくとも一部分、様々なパラメータに基づき得る、ボイスフレームの送信のための電力を決定することができる。さらに、パイロットビット除外ソフトウェア904と協調して動作し得るパイロットビット除外回路804は、パイロットビットをボイスフレームの送信に関連したスロットフォーマットから除外することができる。このようにして、送信は、パイロットビットなしで進み得る。
オプションのブロック1314において、フレーム早期終了ソフトウェア916と協調して動作し得るフレーム早期終了回路816は、ボイスフレームを受信する受信機を遮断すること、またはボイスフレームの送信機に承認を送信することのうちの少なくとも1つを実行することによって、フレーム早期終了を可能にすることができる。
ブロック1316において、DTX構成が有効かどうかをプロセッサ104が判定し得る。すなわち、上述したように、プロセッサ104は、DTX構成と非DTX構成との間で変わることが可能になり得る。非DTX構成が有効にされる場合、プロセスは、ブロック1318に進み得、送信機556または532は、たとえば、DTX構成を利用することなく、全TTI上でボイスフレームを送信することができる。一方、DTX構成が有効にされる場合、プロセスは、ブロック1320に進み得、送信機556または532は、(たとえば、TTIの後半の間など)TTIの送信された部分の後のTTIの残りの間、ボイスフレームの送信を一時停止することができる。
オプションのブロック1322において、送信機556または532は、次のTTIの開始の前に、TTIの残りの間にあらかじめ決定された数のスロットにおいて1つまたは複数のDPCCHパラメータを送信することができる。このようにして、上述したように、送信機は、受信機のチャネルフィルタのリフレッシュを有効にすることができる。
図13に図示したプロセス1300は、例示的である。本開示の態様によれば、ブロック(またはその部分)の1つまたは複数は、オプションであり得る。ブロック(またはその部分)は、図13に示されるものと異なる順番または順序で実行することができる。
方法もしくはフローチャート1300、またはその1つもしくは複数の部分は、ワイヤレス通信を実行するために使用され得るアルゴリズムに対応し得る。このアルゴリズムは、たとえば図1のプロセッサ104、および/または図5のノードB510、UE550、もしくはプロセッサ560、570、582、590、および594のうちの1つまたは複数など、1つまたは複数のシステム、デバイス、または構成要素に接続され、またはそれによって実行され得る。方法1300の異なる態様は、上述したように、図8の回路の1つもしくは複数、および/または図9のソフトウェアの1つまたは複数の項目に接続され、またはそれによって実行され得る。
当然、上記の例では、プロセッサに含まれる回路は、単に一例として提供されているにすぎず、記載された機能を実行するための他の手段は、限定はしないが、コンピュータ可読媒体106、または、図のうちの任意のものに記載され、たとえば図13に関して本明細書で説明するプロセスおよび/またはアルゴリズムを利用する他の任意の適した装置もしくは手段に記憶される命令を含めて、本開示の様々な態様内に含まれ得る。
本開示の態様によれば、上記で説明した技法、方式、方法、構成要素、ドライブ、およびシステムは、UEおよび/またはノードBの両方の送信機および/または受信機において実施され得る。
本開示の態様によれば、システムは、本明細書で説明する方法のうちの1つまたは複数を実施するように構成される。
本開示の態様によれば、システムは、本明細書で説明する方法のうちの1つまたは複数を実施するための手段を備える。
本開示の態様によれば、システムは、プロセッサおよびメモリを備え、プロセッサは、本明細書で説明する方法のいずれかを実行するように構成される。
本開示の態様によれば、UEは、本明細書で説明する方法のいずれかを実行するように構成される。
本開示の態様によれば、ノードBは、本明細書で説明する方法のいずれかを実行するように構成される。
本開示の態様によれば、コンピュータ可読媒体は、本明細書で説明する方法のいずれかを実行するように構成されたソフトウェアを備える。
電気通信システムのいくつかの態様は、W-CDMAシステムを参照して存在した。当業者が容易に理解できるように、本開示全体を通じて説明される様々な態様が、他の電気通信システム、ネットワーク構造、および通信規格に広がり得る。
例として、様々な態様は、TD-SCDMAおよびTD-CDMAなど、他のUMTSシステムに拡張され得る。様々な態様はまた、(FDD、TDD、または両方のモードの)ロングタームエボリューション(LTE)、(FDD、TDD、または両方のモードの)LTEアドバンスト(LTE-A)、CDMA2000、エボリューションデータオプティマイズド(EV-DO)、ウルトラモバイルブロードバンド(UMB)、IEEE802.11(Wi-Fi)、IEEE802.16(WiMAX)、IEEE802.20、ウルトラワイドバンド(UWB)、Bluetooth(登録商標)、および/または他の適切なシステムを利用するシステムに拡張され得る。用いられる実際の電気通信規格、ネットワーク構造、および/または通信規格は、特定のアプリケーション、およびシステムに課される全体的な設計制約に依存する。
本開示内の「例示的」という単語は、例、事例、または例示の働きをすることを意味するために使用する。「例示的な」として本明細書で説明されるいかなる実施態様または態様も、必ずしも本開示の他の態様よりも好ましいまたは有利なものと解釈されるべきではない。同様に、「諸態様」という用語は、本開示のすべての態様が、議論される特徴、利点、または動作のモードを含むことを必要としない。「結合された」という用語は、2つの物体間の直接的または間接的な結合を指すために本明細書で使用される。たとえば、物体Aが物体Bに物理的に接触し、物体Bが物体Cに接触する場合、物体AとCとは、互いに物理的に直接接触していなくても、それでも互いに結合するものと見なすことができる。たとえば、第1のダイがパッケージ内の第2のダイに物理的に直接接触していなくても、第1のダイは、第2のダイに結合している可能性がある。「回路(circuit)」および「回路(circuitry)」という用語は広義に使用され、接続され、構成されると、電子回路のタイプに関する制限なく、本開示に記載された機能の性能を可能にする電気デバイスおよびコンダクタのハードウェア実装と、プロセッサによって実行されると、本開示に記載された機能の性能を可能にする情報および命令のソフトウェア実装の両方を含むものとする。
図面に示す構成要素、ステップ、特徴および/または機能のうちの1つまたは複数は、単一の構成要素、ステップ、特徴、または機能に再構成および/または結合されてよく、あるいは、いくつかの構成要素、ステップまたは機能で具現化されてもよい。本明細書に開示された新規な特徴から逸脱することなしに、さらなる要素、構成要素、ステップ、および/または機能も追加され得る。図に示される装置、デバイス、および/またはコンポーネントは、本明細書で説明する方法、特徴、またはステップのうちの1つまたは複数を実行するように構成され得る。本明細書に記載の新規なアルゴリズムも、効率的にソフトウェアに実装されてもよく、および/またはハードウェアに埋め込まれてもよい。
開示された方法におけるステップの特定の順序または階層は例示的なプロセスの例示であることを理解されたい。設計の好みに基づいて、方法におけるステップの特定の順序または階層が再配置されてもよいことを理解されよう。付随の方法のクレームは、サンプルの順序で様々なステップの要素を示し、本明細書に特に定めがない限り、示された特定の順序または階層に限定されることは意味していない。
前述の説明は、当業者が本明細書に説明された様々な態様を実施することを可能にするように与えられる。これらの態様の様々な修正形態は、当業者に容易に明らかになり、本明細書に定められた一般的な原理は、他の態様に適用することができる。したがって、特許請求の範囲は、本明細書に示された態様に限定されるものではないが、特許請求の範囲の言い回しと一致した全範囲に一致することになり、単数形の要素の参照は、特に別段の定めがない限り「1つまたは1つだけ」を意味するものではなく、むしろ「1つまたは複数の」である。特に別段の定めがない限り、「いくつか(some)」という用語は、1つまたは複数を指す。項目のリスト「の少なくとも1つ」について言及するフレーズは、単一のメンバーを含むこれらの項目の任意の組合せを指す。一例として、「a、b、またはcの少なくとも1つ」は、a、b、c、aおよびb、aおよびc、bおよびc、ならびにa、bおよびcを含むことが意図される。当業者により知られているまたは後で当業者に知られることになる本開示を、全体を通じて説明された様々な態様の要素の構造的および機能的なすべての均等物は、参照により明示的に本明細書に組み込まれ、特許請求の範囲によって包含されることが意図される。その上、本明細書に開示されたものは、そのような開示が特許請求の範囲に明示的に説明されているかにかかわらず、公衆にささげられることが意図されるものではない。請求項の要素は、「ための手段(means for)」という句を用いて要素が明示的に記載されていない限り、または方法の請求項の場合、要素が「のためのステップ(step for)」という句を用いて記載されていない限り、米国特許法第112条第6パラグラフの規定の下で解釈されるべきではない。