特許 6960443 無線通信システムにおけるランダムアクセス手順のＭＳＧ３送信を改善するための方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6960443

(24)【登録日】2021年10月13日

(45)【発行日】2021年11月5日

(54)【発明の名称】無線通信システムにおけるランダムアクセス手順のＭＳＧ３送信を改善するための方法及び装置

(51)【国際特許分類】

   H04W 72/12 20090101AFI20211025BHJP

   H04W 72/04 20090101ALI20211025BHJP

   H04W 74/08 20090101ALI20211025BHJP

【ＦＩ】

   H04W72/12 150

   H04W72/04 131

   H04W74/08

【請求項の数】10

【全頁数】31

(21)【出願番号】特願2019-201501(P2019-201501)

(22)【出願日】2019年11月6日

(62)【分割の表示】特願2017-146452(P2017-146452)の分割

【原出願日】2017年7月28日

(65)【公開番号】特開2020-22205(P2020-22205A)

(43)【公開日】2020年2月6日

【審査請求日】2019年11月6日

(31)【優先権主張番号】62/367,875

(32)【優先日】2016年7月28日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】517114621

【氏名又は名称】華碩電腦股▲ふん▼有限公司

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】陳 威宇

(72)【発明者】

【氏名】曾 立至

【審査官】 久松 和之

(56)【参考文献】

【文献】 特表２０１４−５１１０８０（ＪＰ，Ａ）

【文献】 特開２０１６−０７２８４３（ＪＰ，Ａ）

【文献】 特表２０１７−５３３６２０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

ランダムアクセス手順を実行するためのＵＥ（ユーザ装置）の方法であって、
前記ＵＥがネットワークにプリアンブルを送信することと、
前記ＵＥが前記プリアンブルに応答した前記ネットワークからＭｓｇ２を受信することであって、Ｍｓｇ２はＭｓｇ３のＴＴＩ（送信時間間隔）情報を含み、Ｍｓｇ３の前記ＴＴＩ情報は、Ｍｓｇ３のＴＴＩ持続時間を示すための第１の時間ユニット数と、Ｍｓｇ２受信とＭｓｇ３送信との間のギャップ期間を示すための第２の時間ユニット数とをそれぞれ含む、受信することと、
前記ＵＥが前記ＴＴＩ情報に従って前記ネットワークへの単一トランスポートブロック（ＴＢ）のＭｓｇ３送信を実行することと、を含む、方法。

【請求項2】

前記ＵＥが、前記Ｍｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、ランダムアクセス目的に基づいて、Ｍｓｇ３の前記ＴＴＩ情報を選択することを更に含む、請求項１に記載の方法。

【請求項3】

前記ＵＥが、前記Ｍｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、前記プリアンブル送信のＰＲＡＣＨ（物理ランダムアクセスチャネル）リソースセット又は前記プリアンブル送信のプリアンブルセットに基づいて、Ｍｓｇ３の前記ＴＴＩ情報を選択することを更に含む、請求項１に記載の方法。

【請求項4】

前記ＵＥが、前記Ｍｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、送信に利用可能なデータを有する論理チャネルの最高優先度に基づいて、Ｍｓｇ３の前記ＴＴＩ情報を選択することを更に含む、請求項１に記載の方法。

【請求項5】

Ｍｓｇ３の前記ＴＴＩ情報が、前記プリアンブルに応答するためのＲＡＲ（ランダムアクセス応答）に含まれる、請求項１に記載の方法。

【請求項6】

Ｍｓｇ３の前記ＴＴＩ情報が、前記Ｍｓｇ２内の複数のＲＡＲのための共通フィールドに含まれる、請求項１に記載の方法。

【請求項7】

ユーザ装置（ＵＥ）であって、
制御回路と、
前記制御回路に設けられたプロセッサと、
前記制御回路に設けられるとともに、前記プロセッサに動作可能に結合されたメモリとを備え、
前記プロセッサが、前記メモリに記憶されたプログラムコードを実行して、
ネットワークにプリアンブルを送信することと、
前記プリアンブルに応答した前記ネットワークからＭｓｇ２を受信することであって、Ｍｓｇ２はＭｓｇ３のＴＴＩ（送信時間間隔）情報を含み、Ｍｓｇ３の前記ＴＴＩ情報は、Ｍｓｇ３のＴＴＩ持続時間を示すための第１の時間ユニット数と、Ｍｓｇ２受信とＭｓｇ３送信との間のギャップ期間を示すための第２の時間ユニット数とをそれぞれ含む、受信することと、
Ｍｓｇ３の前記ＴＴＩ情報に従って前記ネットワークへの単一トランスポートブロック（ＴＢ）のＭｓｇ３送信を実行することと、を行うように構成される、ＵＥ。

【請求項8】

前記プロセッサが、前記メモリに記憶された前記プログラムコードを実行して、
当該ＵＥが、前記Ｍｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、ランダムアクセス目的に基づいて、Ｍｓｇ３の前記ＴＴＩ情報を選択するように更に構成される、請求項７に記載のＵＥ。

【請求項9】

前記プロセッサが、前記メモリに記憶された前記プログラムコードを実行して、
当該ＵＥが、前記Ｍｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、前記プリアンブル送信のＰＲＡＣＨ（物理ランダムアクセスチャネル）リソースセット又は前記プリアンブル送信のプリアンブルセットに基づいて、Ｍｓｇ３の前記ＴＴＩ情報を選択するように更に構成される、請求項７に記載のＵＥ。

【請求項10】

前記プロセッサが、前記メモリに記憶された前記プログラムコードを実行して、
当該ＵＥが、前記Ｍｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、利用可能なデータを有する論理チャネルの最高優先度に基づいて、Ｍｓｇ３の前記ＴＴＩ情報を選択するように更に構成される、請求項７に記載のＵＥ。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願との相互参照
本出願は、２０１６年７月２８日に出願された米国仮特許出願第６２／３６７，８７５号の利益を主張するものであり、その全開示内容は参照によりその全体が本明細書に組み込まれる。

【0002】

技術分野
本開示は、一般に、無線通信ネットワークに関し、より詳細には、無線通信システムにおけるランダムアクセス手順のＭｓｇ３送信を改善するための方法及び装置に関する。

【背景技術】

【0003】

大量のデータを移動体通信装置との間で通信するための要求が急速に高まるにつれて、従来のモバイル音声通信ネットワークは、インターネットプロトコル（ＩＰ）データパケットによって通信するネットワークに進化している。そのようなＩＰデータパケット通信は、ボイスオーバＩＰサービス、マルチメディアサービス、マルチキャストサービス、及びオンデマンド通信サービスを、移動体通信装置のユーザに提供することができる。

【0004】

例示的なネットワーク構造は、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）である。Ｅ−ＵＴＲＡＮシステムは、上述したボイスオーバＩＰサービス、及びマルチメディアサービスを実現するために、高いデータスループットを提供することができる。次世代（例えば、５Ｇ）のための新しい無線技術は、現在、３ＧＰＰ標準化団体によって議論されている。したがって、現在の３ＧＰＰ標準への変更が現在提出されており、３ＧＰＰ標準を発展させて確定すると考えられている。

【発明の概要】

【0005】

ランダムアクセス手順を実行するための、ＵＥの観点からの方法及び装置が開示される。一実施例において、方法は、ＵＥがネットワークからメッセージを受信することを含む。メッセージは、Ｍｓｇ３のＴＴＩ（送信時間間隔）情報を含む。さらに、この方法は、ＵＥがネットワークにプリアンブルを送信することを含む。この方法は、同様に、ＵＥがプリアンブルに応答するためのネットワークからのＭｓｇ２を受信することを含む。方法は、ＵＥがＭｓｇ３のＴＴＩ情報に従ってネットワークへのＭｓｇ３送信を実行することを更に含む。

【図面の簡単な説明】

【0006】

【図1】１つの例示的な実施例による無線通信システムの図を示す。

【図2】１つの例示的な実施例による、送信機システム（アクセスネットワークとしても知られている）及び受信機システム（ユーザ機器又はＵＥとしても知られている）のブロック図である。

【図3】１つの例示的な実施例による通信システムの機能ブロック図である。

【図4】１つの例示的な実施例による、図３のプログラムコードの機能ブロック図である。

【図5】３ＧＰＰ ＴＳ ３６．３００ ｖ１３．２．０の図１０．１．５．１−１の複製物である。

【図6】３ＧＰＰ ＴＳ ３６．３００ ｖ１３．２．０の図１０．１．５．２−１の複製物である。

【図7】１つの例示的な実施例による図である。

【図8】１つの例示的な実施例による図である。

【図9】１つの例示的な実施例による図である。

【図10】１つの例示的な実施例による図である。

【図11】１つの例示的な実施例による図である。

【図12】１つの例示的な実施例によるフローチャートである。

【図13】１つの例示的な実施例によるフローチャートである。

【図14】１つの例示的な実施例によるフローチャートである。

【図15】１つの例示的な実施例によるフローチャートである。

【図16】１つの例示的な実施例によるフローチャートである。

【図17】１つの例示的な実施例によるフローチャートである。

【図18】１つの例示的な実施例によるフローチャートである。

【図19】１つの例示的な実施例によるフローチャートである。

【発明を実施するための形態】

【0007】

下記で説明される例示的な無線通信システム及び装置は、ブロードキャストサービスをサポートする無線通信システムを使用する。無線通信システムは、音声、データなどの様々なタイプの通信を提供するために広く展開されている。これらのシステムは、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、直交周波数分割多元接続（ＯＦＤＭＡ）、３ＧＰＰ ＬＴＥ（Long Term Evolution：ロングタームエボリューション）無線アクセス、３ＧＰＰ ＬＴＥ−Ａ又はＬＴＥ−Ａｄｖａｎｃｅｄ（Long Term Evolution Advanced：ロングタームエボリューションアドバンスト）、３ＧＰＰ２ ＵＭＢ（Ultra Mobile Broadband：ウルトラモバイルブロードバンド）、ワイマックス（WiMax）、又はいくつかの他の変調技術に基づくことができる。

【0008】

特に、下記で説明される例示的な無線通信システム装置は、本明細書で３ＧＰＰと呼ばれる「第３世代パートナーシッププロジェクト」と名付けられたコンソーシアムによって提供される標準のような、「ＴＲ ３８．９１３ ｖ０．３．０、“Study on Scenarios and Requirements for Next Generation Access Technologies”」、「ＴＳ ３６．３００ ｖ１３．２．０、“Overall Description; Stage 2”」、「ＴＳ ３６．９１３ ｖ１３．０．０、“Requirements for further advancements for Evolved Universal Terrestrial Radio Access (E-UTRA)”」、「ＴＳ ３６．３３１ ｖ１３．２．０、“Radio Resource Control (RRC); Protocol specification”」、「ＴＳ ３６．３２１ ｖ１３．１．０、“Medium Access Control (MAC) protocol specification”」、「Ｒ２−１６３４４５、“Scheduling Framework and Requirements”、Nokia and Alcatel-Lucent Shanghai Bell」、を含む１つ又は複数の標準をサポートするように設計されてもよい。上記の標準及び文献は、参照によりその全体が本明細書に明確に組み込まれている。

【0009】

図１は、本発明の一実施例による多元接続無線通信システムを示す。アクセスネットワーク１００（ＡＮ）は、１０４及び１０６を含む１つのアンテナグループと、１０８及び１１０を含む別のアンテナグループと、１１２及び１１４を含む追加のアンテナグループとを含んでいる複数のアンテナグループを含む。図１では、各アンテナグループに２つのアンテナしか示されていないが、しかしながら、より多いアンテナ又はより少ないアンテナが、各アンテナグループにおいて利用されてもよい。アクセス端末１１６（ＡＴ）は、アンテナ１１２及び１１４と通信し、アンテナ１１２及び１１４は、順方向リンク１２０を介してアクセス端末１１６に情報を送り、逆方向リンク１１８を介してアクセス端末１１６から情報を受け取る。アクセス端末（ＡＴ）１２２は、アンテナ１０６及び１０８と通信し、アンテナ１０６及び１０８は、順方向リンク１２６を介してアクセス端末（ＡＴ）１２２に情報を送り、逆方向リンク１２４を介してアクセス端末（ＡＴ）１２２から情報を受け取る。ＦＤＤシステムでは、通信リンク１１８、１２０、１２４及び１２６は、通信のために異なる周波数を使用することができる。例えば、順方向リンク１２０は、逆方向リンク１１８によって使用される周波数とは異なる周波数を使用することができる。

【0010】

アンテナの各グループ及び／又はそれらが通信するように設計されているエリアは、しばしば、アクセスネットワークのセクタと呼ばれる。この実施例では、各アンテナグループは、アクセスネットワーク１００によってカバーされているエリアのセクタ内のアクセス端末に通信するように設計されている。

【0011】

順方向リンク１２０及び１２６を介した通信において、アクセスネットワーク１００の送信アンテナは、異なるアクセス端末１１６及び１２２に対する順方向リンクの信号対雑音比を改善するために、ビームフォーミングを利用することができる。さらに、カバレッジの至る所にランダムに散在するアクセス端末に送信するためにビームフォーミングを使用するアクセスネットワークは、単一のアンテナを通してその全てのアクセス端末に送信するアクセスネットワークよりも、隣接セルのアクセス端末への干渉を少なくする。

【0012】

アクセスネットワーク（ＡＮ）は、端末と通信するために使用される固定局又は基地局であり得るとともに、さらに、アクセスポイント、ＮｏｄｅＢ（ノードＢ）、基地局、拡張基地局、進化型ＮｏｄｅＢ（ｅＮＢ）と呼ばれ得るか、又はいくらかの他の用語で呼ばれ得る。アクセス端末（ＡＴ）は、同様に、ユーザ装置（ＵＥ）、無線通信装置、端末、アクセス端末と呼ばれ得るか、又はいくらかの他の用語で呼ばれ得る。

【0013】

図２は、ＭＩＭＯシステム２００における、送信機システム２１０（アクセスネットワークとしても知られている）、及び受信機システム２５０（アクセス端末（ＡＴ）又はユーザ装置（ＵＥ）としても知られている）の実施例の簡略化されたブロック図である。送信機システム２１０では、多数のデータストリームに関するトラフィックデータがデータソース２１２から送信（ＴＸ）データプロセッサ２１４に提供される。

【0014】

一実施例において、各データストリームは、それぞれの送信アンテナを介して送信される。ＴＸデータプロセッサ２１４は、各データストリームに関するトラフィックデータを、符号化データを提供するためにそのデータストリームに対して選択された特定の符号化方式に基づいて、フォーマットし、符号化し、そしてインタリーブする。

【0015】

各データストリームに関する符号化データは、ＯＦＤＭ技術を用いてパイロットデータと多重化され得る。パイロットデータは、通常、既知の方法で処理されるとともに、チャネル応答を推定するために受信機システムで使用され得る既知のデータパターンである。多重化されたパイロット及び各データストリームに関する符号化データは、その後、変調シンボルを提供するためにそのデータストリームに対して選択された特定の変調方式（例えば、ＢＰＳＫ、ＱＰＳＫ、Ｍ−ＰＳＫ、又はＭ−ＱＡＭ）に基づいて変調される（すなわち、シンボルマッピングされる）。各データストリームに関するデータ速度、符号化、及び変調は、プロセッサ２３０によって実行される命令によって決定されてもよい。

【0016】

次いで、全てのデータストリームに関する変調シンボルは、ＴＸ ＭＩＭＯプロセッサ２２０に提供され、ＴＸ ＭＩＭＯプロセッサ２２０は、（例えば、ＯＦＤＭのための）変調シンボルを更に処理することができる。ＴＸ ＭＩＭＯプロセッサ２２０は、その場合に、Ｎ_Ｔ個の変調シンボルストリームをＮ_Ｔ個の送信機（ＴＭＴＲ）２２２ａ乃至２２２ｔに提供する。特定の実施例では、ＴＸ ＭＩＭＯプロセッサ２２０は、ビームフォーミング重みを、データストリームのシンボルに、そしてシンボルが送信されているアンテナに適用する。

【0017】

各送信機２２２は、それぞれのシンボルストリームを受信するとともに処理して、１つ又は複数のアナログ信号を提供し、アナログ信号を更に調整（例えば、増幅、フィルタリング、及びアップコンバート）して、ＭＩＭＯチャネルを介した送信に適した変調信号を提供する。次いで、送信機２２２ａ乃至２２２ｔからのＮ_Ｔ個の変調信号は、それぞれ、Ｎ_Ｔ個のアンテナ２２４ａ乃至２２４ｔから送信される。

【0018】

受信機システム２５０では、送信された変調信号は、Ｎ_Ｒ個のアンテナ２５２ａ乃至２５２ｒによって受信され、各アンテナ２５２からの受信信号は、それぞれの受信機（ＲＣＶＲ）２５４ａ乃至２５４ｒに提供される。各受信機２５４は、それぞれの受信信号を調整（例えば、フィルタリング、増幅、及びダウンコンバート）し、調整された信号をデジタル化してサンプルを提供し、サンプルを更に処理して対応する「受信」シンボルストリームを提供する。

【0019】

次に、ＲＸデータプロセッサ２６０は、特定の受信機処理技術に基づいて、Ｎ_Ｒ個の受信機２５４からのＮ_Ｒ個の受信シンボルストリームを受信するとともに処理して、Ｎ_Ｔ個の「検出」シンボルストリームを提供する。次いで、ＲＸデータプロセッサ２６０は、各検出シンボルストリームを復調し、デインタリーブし、そして復号して、データストリームに関するトラフィックデータを復元する。ＲＸデータプロセッサ２６０による処理は、送信機システム２１０におけるＴＸ ＭＩＭＯプロセッサ２２０及びＴＸデータプロセッサ２１４によって実行される処理と相補的である。

【0020】

プロセッサ２７０は、どのプリコーディング行列を使用するかを定期的に決定する（下記で論じられる）。プロセッサ２７０は、行列インデックス部分とランク値部分とを含む逆方向リンクメッセージを定式化する。

【0021】

逆方向リンクメッセージは、通信リンク及び／又は受信データストリームに関する様々なタイプの情報を含むことができる。逆方向リンクメッセージは、その場合に、データソース２３６からの多数のデータストリームに関するトラフィックデータを同様に受信するＴＸデータプロセッサ２３８によって処理され、変調器２８０によって変調され、送信機２５４ａ乃至２５４ｒによって調整され、そして送信機システム２１０に対して返信される。

【0022】

送信機システム２１０では、受信機システム２５０からの変調信号は、アンテナ２２４によって受信され、受信機２２２によって調整され、復調器２４０によって復調され、そして受信機システム２５０によって送信された逆方向リンクメッセージを抽出するために、ＲＸデータプロセッサ２４２によって処理される。次いで、プロセッサ２３０は、ビームフォーミング重みを判定するためにどのプリコーディング行列を使用するかを決定し、抽出されたメッセージを処理する。

【0023】

図３を参照すると、この図は、本発明の一実施例による通信装置の代替の簡略化された機能ブロック図を示す。図３において示されるように、無線通信システムにおける通信装置３００は、図１におけるＵＥ（若しくはＡＴ）１１６及び１２２、又は図１における基地局（若しくはＡＮ）１００を実現するために利用されることができるとともに、無線通信システムは、ＬＴＥシステムであることが好ましい。通信装置３００は、入力装置３０２、出力装置３０４、制御回路３０６、中央処理装置（ＣＰＵ）３０８、メモリ３１０、プログラムコード３１２、及びトランシーバ３１４を含むことができる。制御回路３０６は、ＣＰＵ３０８を介してメモリ３１０内のプログラムコード３１２を実行し、それにより、通信装置３００の動作を制御する。通信装置３００は、キーボード又はキーパッドなどの入力装置３０２を介してユーザによって入力された信号を受信し、モニタ又はスピーカなどの出力装置３０４を介して画像及び音声を出力することができる。トランシーバ３１４は、無線信号を受信するとともに送信するために使用され、受信信号を制御回路３０６に供給し、制御回路３０６によって生成された信号を無線で出力する。無線通信システムにおける通信装置３００は、同様に、図１におけるＡＮ１００を実現するために利用されることができる。

【0024】

図４は、本発明の一実施例による、図３において示されるプログラムコード３１２の簡略化されたブロック図である。この実施例では、プログラムコード３１２は、アプリケーションレイヤ４００、レイヤ３部分４０２、及びレイヤ２部分４０４を含むとともに、レイヤ１部分４０６に結合される。レイヤ３部分４０２は、一般に、無線リソース制御を実行する。レイヤ２部分４０４は、一般に、リンク制御を実行する。レイヤ１部分４０６は、一般に、物理的接続を実行する。

【0025】

本出願の一般的な目的の１つは、時間及び周波数リソースに関する様々なタイプの要件（３ＧＰＰ ＴＲ ３８．９１３で議論されている）、例えば、ＭＴＣ（マシンタイプ通信）のための超低遅延（約０．５ｍｓ）から予想されるより長いＴＴＩ（送信時間間隔）まで、ｅＭＢＢ（enhanced Mobile Broadband：拡張モバイルブロードバンド）のための高いピークレートからＭＴＣのための非常に低いデータレートまで、に対応するために、５Ｇのための新しいＲＡＴ（New RAT：ＮＲ）で使用されるフレーム構造を研究することである。重要な焦点は、低遅延であるという側面であるが、異なるＴＴＩを混合／適応させる他の側面が、同様に、研究において考慮されることができる。多様なサービスと要件に加えて、ＮＲの全ての機能が最初の段階／リリースに含まれるわけではないため、順方向の互換性は、最初のＮＲフレーム構造の設計における重要な考慮事項である。

【0026】

３ＧＰＰ ＴＳ ３６．３００には、下記のランダムアクセス（random access：ＲＡ）手順に関する記述が含まれている。
１０．１．５ ランダムアクセス手順
ランダムアクセス手順は、
−ＦＤＤ及びＴＤＤに対する共通の手順、
−ＣＡが設定される場合のセルサイズとサービングセルの数に関係ない１つの手順、
によって特徴付けられる。
ランダムアクセス手順は、ＰＣｅｌｌに関連する下記のイベントに対して実行される。
−ＲＲＣ＿ＩＤＬＥからの初期アクセス、
−ＲＲＣ接続再確立手順、
−ハンドオーバ、
−ランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＤＬデータ到着：
−例えば、ＵＬ同期状態が“同期していない”場合、
−ランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＬデータ到着：
−例えば、ＵＬ同期状態が“非同期”であるか、又は利用可能なＳＲ用のＰＵＣＣＨリソースが存在しない場合、
−ランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中の測位目的のため；
−例えば、ＵＥの測位のためにタイミングアドバンス（timing advance）が必要な場合。
ランダムアクセス手順は、同様に、対応するｓＴＡＧのための時間アライメントを確立するためにＳＣｅｌｌ上で実行される。
ＤＣにおいて、ランダムアクセス手順は、同様に、指示されるならばＳＣＧ追加／変更時に、又はランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＤＬ／ＵＬデータ到着時に、少なくともＰＳＣｅｌｌ上で実行される。ＵＥによって開始されるランダムアクセス手順は、ＳＣＧのためのＰＳＣｅｌｌ上でのみ実行される。
さらに、ランダムアクセス手順には２つの異なる形式がある。
−競合ベース（最初の５つのイベントに適用）。
−非競合ベース（ハンドオーバ、ＤＬデータ到着、測位、ｓＴＡＧのタイミングアドバンスアラインメントの取得のみに適用可能）。
通常のＤＬ／ＵＬ送信は、ランダムアクセス手順の後に行うことができる。ＲＮは、競合ベース及び非競合ベースの両方のランダムアクセスをサポートする。ＲＮがランダムアクセス手順を実行する場合、それは現在のＲＮサブフレーム設定（RN subframe configuration）を中断し、つまり、ＲＮサブフレーム設定は一時的に無視される。ＲＮサブフレーム設定は、成功したランダムアクセス手順完了時に再開される。
１０．１．５．１ 競合に基づくランダムアクセス手順
競合ベースのランダムアクセス手順は、下記の図１０．１．５．１−１に概略が示される。
［３ＧＰＰ ＴＳ ３６．３００ ｖ１３．２．０の図１０．１．５．１−１は、図５として再現される。］
競合ベースのランダムアクセス手順の４つのステップは下記の通りである。
１）アップリンクにおけるＲＡＣＨ上のランダムアクセスプリアンブル：
−定義される２つの可能なグループが存在し、１つは任意である。両方のグループが設定される場合は、メッセージ３のサイズとパスロスとを使用して、どのグループからプリアンブルが選択されるかを判別する。プリアンブルが属するグループは、メッセージ３のサイズ及びＵＥにおける無線状態の表示を提供する。プリアンブルグループ情報は、必要なしきい値と共に、システム情報上でブロードキャストされる。
２）ＤＬ−ＳＣＨ上のＭＡＣによって生成されるランダムアクセスレスポンス：
−メッセージ１との半同期（サイズが１つ又は複数のＴＴＩである柔軟なウィンドウ内で）、
−ＨＡＲＱなし、
−ＰＤＣＣＨ上でＲＡ−ＲＮＴＩにアドレス指定される、
−少なくともＲＡプリアンブル識別子、ｐＴＡＧのためのタイミングアライメント情報、初期ＵＬグラント、一時的なＣ−ＲＮＴＩの割り当て（競合解決時に永続化されてもされなくてもよい）を伝える、
−１つのＤＬ−ＳＣＨメッセージ内のＵＥの変数を対象とする。
３）ＵＬ−ＳＣＨ上で最初にスケジュールされるＵＬ送信：
−ＨＡＲＱを使用する、
−トランスポートブロックのサイズは、ステップ２で伝えられたＵＬグラントによって決まる。
−最初のアクセスの場合：
−ＲＲＣレイヤによって生成され、ＣＣＣＨを介して送信されるＲＲＣ接続要求を伝える、
−少なくともＮＡＳのＵＥ識別子を伝えるが、ＮＡＳメッセージは伝えない、
−ＲＬＣ ＴＭ：セグメント化なし。
−ＲＲＣ接続再確立手順の場合：
−ＲＲＣレイヤによって生成され、ＣＣＣＨを介して送信されるＲＲＣ接続再確立要求を伝える、
−ＲＬＣ ＴＭ：セグメント化なし、
−ＮＡＳメッセージを含まない。
−ハンドオーバ後、ターゲットセル内で：
−ＲＲＣレイヤによって生成され、ＤＣＣＨを介して送信される、暗号化されるとともに整合性の保護されたＲＲＣハンドオーバ確認を伝える、
−ＵＥのＣ−ＲＮＴＩ（ハンドオーバ命令によって割り当てられた）を伝える、
−可能であれば、アップリンクバッファステータスレポートを含む。
−その他のイベントの場合：
−少なくともＵＥのＣ−ＲＮＴＩを伝える。
４）ＤＬにおける競合解決：
−早期の競合解決が使用されるべきであり、すなわち、競合を解決する前にｅＮＢがＮＡＳ応答を待たない、
−メッセージ３と同期されない、
−ＨＡＲＱがサポートされる、
−初期アクセス及び無線リンク障害後のＰＤＣＣＨ上の一時Ｃ−ＲＮＴＩ、
−ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおけるＵＥのためのＰＤＣＣＨ上のＣ−ＲＮＴＩ、
にアドレス指定される。
−ＨＡＲＱフィードバックは、メッセージ３で提供されるような自身のＵＥ識別子を検出したＵＥによってのみ送信され、競合解決メッセージにおいてそのまま伝えられる、
−初期アクセス及びＲＲＣ接続再確立手順の場合、セグメンテーションは使用されない（ＲＬＣ−ＴＭ）。
一時的なＣ−ＲＮＴＩは、ＲＡの成功を検出するとともにＣ−ＲＮＴＩをまだ有していないＵＥのＣ−ＲＮＴＩに奨励され（promoted）、それは他のものによって撤回される（dropped）。ＲＡ成功を検出するとともに既にＣ−ＲＮＴＩを有するＵＥは、そのＣ−ＲＮＴＩを使用して再開する。ＣＡが設定される場合、競合ベースのランダムアクセス手順の最初の３つのステップはＰＣｅｌｌ上で行われ、一方競合解決（ステップ４）はＰＣｅｌｌによって相互スケジュールされる（cross-scheduled）ことができる。ＤＣが設定される場合、競合ベースのランダムアクセス手順の最初の３つのステップは、ＭＣＧにおけるＰＣｅｌｌとＳＣＧにおけるＰＳＣｅｌｌ上で行われる。ＣＡがＳＣＧ内に設定される場合、競合ベースのランダムアクセス手順の最初の３つのステップはＰＳＣｅｌｌ上で行われ、一方競合解決（ステップ４）はＰＳＣｅｌｌによって相互スケジュールされることができる。
１０．１．５．２ 非競合ベースのランダムアクセス手順
非競合ベースのランダムアクセス手順は、下記の図１０．１．５．２−１に概略が示される。
［３ＧＰＰ ＴＳ ３６．３００ ｖ１３．２．０の図１０．１．５．２−１は、図６として再現される。］
非競合ベースのランダムアクセス手順の３つのステップは下記の通りである。
０）ＤＬにおける専用シグナリングによるランダムアクセスプリアンブル割り当て：
−ｅＮＢは、非競合ランダムアクセスプリアンブル（ブロードキャストシグナリングで送信されたセット内に存在しないランダムアクセスプリアンブル）をＵＥに割り当てる。
−ターゲットｅＮＢによって生成され、ハンドオーバのためにソースｅＮＢを介して送信されるＨＯ命令、
−ＤＬデータの到着又は測位の場合のＰＤＣＣＨ、
−ｓＴＡＧに関する初期ＵＬ時間アライメントのためのＰＤＣＣＨ
を介してシグナリングされる。
１）アップリンクにおけるＲＡＣＨ上のランダムアクセスプリアンブル：
−ＵＥは、割り当てられた非競合ランダムアクセスプリアンブルを送信する。
２）ＤＬ−ＳＣＨ上のランダムアクセスレスポンス：
−メッセージ１との半同期（semi-synchronous）（サイズが１つ又は複数のＴＴＩである柔軟なウィンドウ内で）、
−ＨＡＲＱなし、
−ＰＤＣＣＨ上でＲＡ−ＲＮＴＩにアドレス指定される、
−少なくとも：
−ハンドオーバに関するタイミングアライメント情報及び初期ＵＬグラント、
−ＤＬデータ到着に関するタイミングアライメント情報、
−ＲＡプリアンブル識別子を伝える、
−１つのＤＬ−ＳＣＨメッセージ内の１つ又は複数のＵＥのために意図される。
ＣＡが設定されている間にＰＣｅｌｌ上で非競合ベースのランダムアクセスを実行する場合、非競合ベースのランダムアクセス手順のステップ０、ステップ１及び２のＰＤＣＣＨを介したランダムアクセスプリアンブル割り当ては、ＰＣｅｌｌ上で行われる。ｓＴＡＧのためのタイミングアドバンスを確立するために、ｅＮＢは、ｓＴＡＧの活性化されたＳＣｅｌｌのスケジューリングセル上で送信されるＰＤＣＣＨ命令（ステップ０）を用いて、非競合ベースのランダムアクセス手順を開始することができる。プリアンブル送信（ステップ１）は、指示されたＳＣｅｌｌ上で起きるとともに、ランダムアクセス応答（ステップ２）は、ＰＳＣｅｌｌ上で行われる。
ＤＣが設定されている間にＰＣｅｌｌ又はＰＳＣｅｌｌ上で非競合ベースのランダムアクセスを実行する場合、非競合ベースのランダムアクセス手順のステップ０、ステップ１及び２のＰＤＣＣＨを介したランダムアクセスプリアンブル割り当ては、対応するセル上で行われる。ｓＴＡＧのためのタイミングアドバンスを確立するために、ｅＮＢは、ＰＳＣｅｌｌを含まないｓＴＡＧの活性化されたＳＣｅｌｌのスケジューリングセル上で送信されるＰＤＣＣＨ命令（ステップ０）を用いて、非競合ベースのランダムアクセス手順を開始することができる。プリアンブル送信（ステップ１）は、指示されたＳＣｅｌｌ上で起きるとともに、ランダムアクセス応答（ステップ２）は、ＭＣＧ用のＰＣｅｌｌ及びＳＣＧ用のＰＳＣｅｌｌ上で行われる。

【0027】

各ランダムアクセスステップ及び関連する制御要素の詳細は、３ＧＰＰ ＴＳ ３６．３２１のセクション５．１、５．４、６、及び７に説明されている。さらに、ランダムアクセス及び取得手順のためのいくつかの構成は、３ＧＰＰ ３６．３３１で議論されている。

【0028】

３ＧＰＰ ＴＲ ３８．９１３に列挙された１つのＮＲ要件は、下記のＮＲ要件を列挙する。“制御プレーンの遅延は、バッテリの効率的状態（例えば、ＩＤＬＥ）から連続データ転送の開始（例えば、ＡＣＴＩＶＥ）に移行する時間を指す。制御プレーンの遅延の目標は１０ｍｓであるべきである。”ＬＴＥにおける同様の要件に関して、制御プレーンの遅延要件は（３ＧＰＰ ＴＳ ３６．９１３で議論されているように）５０ｍｓに設定される。ＬＴＥの遅延要件とＮＲの遅延要件との間には大きな隔たりがある。したがって、可能な限り送信及び処理の遅延を削減する方が良いであろう。下記で説明するように、本出願は、最初にランダムアクセスの遅延に焦点を合わせる。

【0029】

ＬＴＥには、２種類のランダムアクセス手順、すなわち競合及び非競合がある。競合ランダムアクセス手順は、Ｍｓｇ１、Ｍｓｇ２、Ｍｓｇ３、及びＭｓｇ４を含む４つのステップからなる。図５は、競合ランダムアクセスに関する例示的な実施例である。Ｍｓｇ１及びＭｓｇ３は、ＵＥからネットワークに送信される。また、Ｍｓｇ１送信及びＭｓｇ３送信を実行するためのリソースは競合リソースである。ネットワークがＭｓｇ３を正常に受信できる場合、ネットワークはＭｓｇ３の内容に基づいてＵＥを識別し、Ｍｓｇ４をＵＥに送信して競合を終了することができるであろう。

【0030】

一方、動的ＴＴＩの調整概念は、３ＧＰＰ Ｒ２−１６３４４５で議論されており、ＴＣＰ（伝送制御プロトコル）送信の場合を最適化するために、スケジューリンググラントごとにＴＴＩサイズを設定することを提案している。特に、ショートＴＴＩはＴＣＰスロースタートプロセス（slow start process）を加速するために使用され、ロングＴＴＩは安定した伝送レート状態で使用され、制御シグナリングオーバーヘッドを削減することができる。

【0031】

そのような動的ＴＴＩの概念を考慮して、本出願は、ランダムアクセス手順を加速するために同様に使用できるかどうか、またランダムアクセスにおける動的ＴＴＩ変更をどのように達成することができるか、について更に議論する。下記の議論は、主にランダムアクセス手順におけるＭｓｇ３送信ステップに焦点を当てている。さらに、下記の議論は、ＵＥのＲＦ／ベースバンド能力差別化（例えば、ＬＴＥにおける通常の携帯電話とＬＴＥにおけるＮＢ−ＩｏＴ装置との間の差別化）を含まない。

【0032】

ＬＴＥでは、ＬＴＥシステムにおいて３つの異なるランダムアクセス構成（random access configurations）が存在する可能性がある。第１の構成は、一般に、全システム帯域幅を監視するのに十分なＲＦ／ベースバンド能力を有する通常のＵＥ（例えば、携帯電話、ハイエンドＭＴＣ装置）用である。第２の構成は、一般に、ローエンドＭＴＣ装置、及び十分なＲＦ／ベースバンド能力を有するが電力制限状態で動作する通常のＵＥ用である。第３の構成は、一般に、ＲＦ／ベースバンド能力をプールし、狭帯域（例えば、１．４ＭＨｚ）上でのみ送受信を行うことができるＮＢ−ＩｏＴ（狭帯域−モノのインターネット）ＵＥ用である。最後の構成は、一般に、新しいＲＡＴ（Radio Access Technology：無線アクセス技術）として定義される。通常、ローエンドＭＴＣ装置は、第２の構成でのみ動作し、ＮＢ−ＩｏＴ装置は、第３の構成でのみ動作することになる。十分なＲＦ／ベースバンド能力を有する通常のＵＥの場合、ＵＥは、電力制限状態に入ったとき（例えば、セルエッジ又は遠く離れている）にのみＲＡ構成を変更することになる。

【0033】

ショートＴＴＩがＭｓｇ３送信に適用される場合、平均ランダムアクセス遅延は、Ｍｓｇ４を監視することの早期の開始に起因して削減されることができるであろう。このような利点に関する可能性のあるケースが図７に示される。図７において示されるように、処理遅延は固定された期間であるが、ＵＥは、早期のＭｓｇ３送信のために、Ｍｓｇ４を早期に受信し始めることができるであろう。さらに、Ｍｓｇ４を監視するための２つの可能性が図７に示される。ＴＴＩ長情報がスケジューリング制御信号で搬送されない場合、ＵＥは、いずれかのＴＴＩフォーマットを期待することができる。そうでなければ、ＵＥは、ＴＴＩ長の複数の可能性を期待することができる。

【0034】

別の可能な利点は、リソース効率を改善することである。動的ＴＴＩの概念がＭｓｇ３に適用される場合、ネットワークはリソース割り当てをより柔軟に調整することができる。ＬＴＥでは、Ｍｓｇ３のＴＴＩ長は固定である。同じ変調方式状態では、ＬＴＥシステムはＰＲＢレベルで無線リソースをスケジュールするだけでよく、一方ＮＲはシンボルレベルでスケジュールすることができ得る。

【0035】

動的ＴＴＩの概念を達成するために、ＵＥは、エアインタフェース上でＭｓｇ３を送信するためのＴＴＩ情報（例えば、ＴＴＩ長、計算方式（numerology））を得る必要がある。この態様では、そのような情報を得るために、ＵＥに関する可能性のある候補が提案される。１つ又は複数の解決策が、ＮＲシステムに適用されることができる。

【0036】

解決策１−ＲＡＲ（ランダムアクセス応答）。
ＬＴＥでは、Ｍｓｇ３送信はＲＡＲにおけるＵＬグラントフィールドによってスケジュールされる。ＲＡＲは、（複数の）ＵＥからＭｓｇ１送信機会において送信されたプリアンブルに対する応答である。ＬＴＥにおけるＲＡＲのフォーマットが図８に示される。

【0037】

Ｍｓｇ３送信は、ＲＡＲにおけるＵＬ（アップリンク）グラントフィールドに従ってスケジュールされる。この解決策では、Ｍｓｇ３をスケジュールするために、追加のＴＴＩ情報がＲＡＲに追加される。一実施例において、新しいＴＴＩ情報は、特定のプリアンブルのための、若しくはＵＬグラントフィールドに追加された、ＲＡＲにおける新しいフィールドか、又はＭｓｇ２における新しいフィールドとすることができる。可能な例示的な実施例が図９に示される。

【0038】

解決策２−Ｍｓｇ２における共通フィールド。
解決策２では、ＴＴＩ情報も、解決策１と同様に、Ｍｓｇ２において搬送される。Ｍｓｇ２は、複数のＲＡＲを含むことができる。そして、ＲＡＲのサブヘッダは、ＲＡＲがどのプリアンブルのためのものであるかを示す。しかしながら、ＴＴＩ長は選択肢が限られているので、それらは冗長な情報を繰り返し含む必要はない。したがって、Ｍｓｇ２における（複数の）共通フィールドを使用して、ＴＴＩ情報を搬送することが提案される。可能な例が図１０に示される。ＴＴＩ情報１は、プリアンブルセット１（例えば、ＲＡＰＩＤ０〜２０）に提供されることができ、ＴＴＩ情報２は、プリアンブルセット２（例えば、ＲＡＰＩＤ２１〜４０）に提供されることができるであろう。

【0039】

共通フィールドで搬送されるＴＴＩ情報は、異なるＭｓｇ１送信（例えば、異なるプリアンブル）を実行したＵＥに適用されることになる。異なるＭｓｇ１送信は、コードドメイン及び／又は時間ドメイン及び／又は周波数ドメインにおける受信側によって区別可能である。好ましくは、（複数の）共通フィールドは、制御要素として搬送され得る。その代わりに、（複数の）共通フィールドは、ＭＡＣ（サブ）ヘッダの一部として、データ（例えば、ＲＲＣ設定（RRC configuration））として、又はＭｓｇ２をスケジュールするための制御信号（例えば、ＰＤＣＣＨ信号）において、搬送されることができる。

【0040】

複数の共通フィールドがＭｓｇ２に含まれる場合、ＵＥは、Ｍｓｇ３送信に適用するために、それらのうちの１つを選択することができるであろう。一実施例において、ＵＥは、Ｍｓｇ１送信（例えば、Ｍｓｇ１によって使用されるＲＡ構成におけるプリアンブルグループセット、Ｍｓｇ１によって使用されるＲＡ構成におけるＰＲＡＣＨリソースセット、Ｍｓｇ１の長さ又はフォーマット、Ｍｓｇ１によって使用されるＲＡ構成など）に基づいて、共通フィールドを選択することができるであろう。ＵＥは、同様に、サービスタイプ（例えば、ＵＲＬＬＣ、ｅＭＢＢ、遅延センシティブ（delay sensitive）．．．）に基づいて、共通フィールドを選択することができるであろう。例えば、ＵＥが特定のサービスタイプデータ（例えば、ＵＲＬＬＣサービスタイプ）を送信するためにＲＡをトリガする場合、その場合に、ＵＥは、特定のサービスタイプのために、共通フィールドを選択することができるであろう。さらに、ＵＥは、利用可能なデータを有する論理チャネル／ＲＢの構成におけるサービスタイプ表示（論理チャネルの優先度と同類である）に基づいて、データがどのサービスタイプに属するかを理解することができる。サービスタイプ表示は、多重化手順において使用され得る。例えば、ＵＥは、異なるサービスタイプ表示を有するデータを送信のためのＴＢに多重化することはできない。その代わりに、ＵＥは、データのヘッダフィールド（例えば、ＲＬＣヘッダフィールド、ＰＤＣＰフィールド）に基づいて、又はユーザプレーンプロトコルタイプ／カテゴリ（例えば、カテゴリ１はＵＲＬＬＣに位置する）を供給することに基づいて、データがどのサービスタイプに属するかを理解することができる。一例として、ＵＥがＵＲＬＬＣサービスタイプを登録／承認したときにＵＥがＲＡをトリガする場合、ＵＥは、ＵＲＬＬＣサービスタイプのために、共通フィールドを選択することができるであろう。別の例として、ＵＥがＲＡをトリガ及び／又は実行する場合に、ＵＥにおける上位レイヤ（例えば、ＮＡＳレイヤ、アプリケーションレイヤ、ＲＲＣレイヤ）が、ＵＥにおける下位レイヤ（例えば、ＭＡＣ、ＰＨＹ）にサービス表示を送信する場合、ＵＥは、サービス表示によって示されるサービスタイプに基づいて、共通フィールドを選択することができるであろう。

【0041】

一実施例において、ＵＥは、ランダムアクセス目的（random access purpose）（例えば、システム情報、ページング、測位、位置更新、制御プレーン確立、ビーム回復などを要求する）に基づいて、共通フィールドを選択する。また、ランダムアクセス目的は、ＵＥにおける上位レイヤ（例えば、ＮＡＳ、ＲＲＣ、アプリケーションレイヤ）によって示されてもよい。

【0042】

一実施例において、ＵＥは、潜在的なＭｓｇ３サイズに基づいて、共通フィールドを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥにおける保留中の利用可能なデータがしきい値より大きい場合、ＵＥは、しきい値より大きい潜在的なメッセージサイズために、共通フィールドを選択する。

【0043】

一実施例において、ＵＥは、そのＤＬ測定に基づいて、接続確立理由（例えば、緊急通報、ｍｏデータ（mo-data）、ｍｔデータ（mt-data））に基づいて、その現在のパワーランピング（power ramping：電力増加）結果（例えば、しきい値時間又はしきい値電力を超えるランピング、ランピングステップとＴＴＩ情報との間のマッピングテーブルに基づいて変更すること）に基づいて、ネットワーク又はＵＥサブスクリプションから提供されるＵＥの優先度（例えば、アクセスクラスなど）に基づいて、又はＭｓｇ３の内容（例えば、どのタイプの制御要素が含まれることができるか、どのＬＣＧ又はどのＲＢ／ＬＣについてのＢＳＲ報告であるか、どのユーザプレーンプロトコルスタックからのデータであるか、どの無線ベアラからのデータであるか、どの論理チャネルからのデータであるか、・・・）に基づいて、共通フィールドを選択する。例えば、Ｍｓｇ３が特定の（一組の）ＬＣ又はＲＢ（例えば、ＵＲＬＬＣタイプＲＢ、ＣＣＣＨ、・・・）からのデータを含むことができる場合、ＵＥは、ＵＥの構成（例えばＬＣ／ＲＢとランダムアクセス構成との間の関連付け、ＬＣ／ＲＢとサービス構成との間の関連付け、ＬＣ／ＲＢとトランスポートチャネル構成との間の関連付けなど）に基づいて、ＬＣ又はＲＢに関連する共通フィールドを選択することができるであろう。別の例として、Ｍｓｇ３が特別な制御要素／特別なメッセージを含むことができる場合、ＵＥは、特別な制御要素／メッセージに関連する共通フィールドを選択することができるであろう。好ましくは、Ｍｓｇ３が特別な制御要素及び／又は特別なメッセージ（例えば、ＲＲＣメッセージ）を含まない場合、ＵＥは別の共通フィールドを選択することになる。

【0044】

一実施例において、ＵＥは、利用可能なデータを有する無線ベアラの最高優先度に基づいて、共通フィールドを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥは、優先度２及び優先度８を有する無線ベアラに属する利用可能なデータを有する。ＵＥは、優先度２がしきい値を超えているか否かに基づいて、共通フィールドを選択することができるであろう。

【0045】

一実施例において、ＵＥは、利用可能なデータを有する論理チャネルの最高優先度に基づいて、又はどのユーザプレーンプロトコルスタック（例えば、ＵＲＬＬＣ又はｅＭＢＢタイプのユーザプレーンプロトコル、プロトコルスタックカテゴリ／インデックス１又は２・・・）がランダムアクセスを実行しているかに基づいて、共通フィールドを選択する。

【0046】

解決策３−ブロードキャスト情報。
解決策３において、ＵＥは、ネットワーク（例えば、ｇＮＢ、基地局、ＴＲＰなど）からブロードキャストメッセージ（例えば、（複数の）システム情報、ＭＩＢなど）を介して、Ｍｓｇ３送信のためのＴＴＩ長を得ることができるであろう。Ｍｓｇ３送信のための複数のＴＴＩ情報がブロードキャストメッセージに含まれる場合、ＵＥは、Ｍｓｇ３送信に適用するためにそれらのうちの１つを選択することができるであろう。

【0047】

一実施例において、ＵＥは、Ｍｓｇ１送信（例えば、Ｍｓｇ１によって使用されるＲＡ構成におけるプリアンブルグループセット、Ｍｓｇ１によって使用されるＲＡ構成におけるＰＲＡＣＨリソースセット、Ｍｓｇ１の長さ又はフォーマット、Ｍｓｇ１によって使用されるＲＡ構成など）に基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択する。例えば、ＵＥが特定のサービスタイプデータ（例えば、ＵＲＬＬＣサービスタイプ）を送信するためにＲＡをトリガする場合、その場合に、ＵＥは、特定のサービスタイプのために、ブロードキャストメッセージ内のＴＴＩ情報を選択することができるであろう。さらに、ＵＥは、利用可能なデータを有する論理チャネル／ＲＢの構成におけるサービスタイプ表示（論理チャネルの優先度と同類である）に基づいて、データがどのサービスタイプに属するかを理解することができる。

【0048】

サービスタイプ表示は、多重化手順において使用され得る。例えば、ＵＥは、異なるサービスタイプ表示を有するデータを送信のためのＴＢに多重化することはできない。その代わりに、ＵＥは、データのヘッダフィールド（例えば、ＲＬＣヘッダフィールド、ＰＤＣＰフィールド）に基づいて、データがどのサービスタイプに属するかを理解することができる。ＵＥは、同様に、ユーザプレーンプロトコルタイプ／カテゴリ（例えば、カテゴリ１はＵＲＬＬＣに位置する）を供給することに基づいて、データがどのサービスタイプに属するかを理解することができる。別の例として、ＵＥがＵＲＬＬＣサービスタイプを登録／承認したときにＵＥがＲＡをトリガする場合、ＵＥは、ＵＲＬＬＣサービスタイプのために、ブロードキャストメッセージ内のＴＴＩ情報を選択することができるであろう。さらなる例として、ＵＥがＲＡをトリガ及び／又は実行する場合に、ＵＥにおける上位レイヤ（例えば、ＮＡＳレイヤ、アプリケーションレイヤ、ＲＲＣレイヤ）が、ＵＥにおける下位レイヤ（例えば、ＭＡＣ、ＰＨＹ）にサービス表示を送信する場合、ＵＥは、サービス表示によって示されるサービスタイプに基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択することができるであろう。

【0049】

一実施例において、ＵＥは、ランダムアクセス目的（例えば、ブロードキャストメッセージ、ページング、測位、位置更新、制御プレーン確立、ビーム回復などを要求する）に基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択する。また、ランダムアクセス目的は、ＵＥにおける上位レイヤ（例えば、ＮＡＳ、ＲＲＣ、アプリケーションレイヤ）によって示されてもよい。

【0050】

一実施例において、ＵＥは、潜在的なＭｓｇ３サイズに基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥにおける保留中の利用可能なデータがしきい値より大きい場合、ＵＥは、しきい値より大きい潜在的なメッセージサイズために、ブロードキャストメッセージ内のＴＴＩ情報を選択する。

【0051】

一実施例において、ＵＥは、そのＤＬ測定に基づいて、接続確立理由（例えば、緊急通報、ｍｏデータ（mo-data）、ｍｔデータ（mt-data））に基づいて、その現在のパワーランピング（power ramping：電力増加）結果（例えば、しきい値時間又はしきい値電力を超えるランピング、ランピングステップとＴＴＩ情報との間のマッピングテーブルに基づいて変更すること）に基づいて、ネットワーク又はＵＥサブスクリプションから提供されるＵＥの優先度（例えば、アクセスクラスなど）に基づいて、又はＭｓｇ３の内容（例えば、どのタイプの制御要素が含まれることができるか、どのＬＣＧ又はどのＲＢ／ＬＣについてのＢＳＲ報告であるか、どのユーザプレーンプロトコルスタックからのデータであるか、どの無線ベアラからのデータであるか、どの論理チャネルからのデータであるか、・・・）に基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択する。例えば、Ｍｓｇ３が特定の若しくは一組のＬＣ又はＲＢ（例えば、ＵＲＬＬＣタイプＲＢ、ＣＣＣＨ、・・・）からのデータを含むことができる場合、ＵＥは、ＵＥの構成に基づいて、ＬＣ又はＲＢに関連するブロードキャストメッセージ内のＴＴＩ情報を選択することができるであろう。別の例として、Ｍｓｇ３が特別な制御要素／特別なメッセージを含むことができる場合、ＵＥは、特別な制御要素／メッセージに関連するブロードキャストメッセージ内のＴＴＩ情報を選択することができるであろう。好ましくは、Ｍｓｇ３が特別な制御要素及び／又は特別なメッセージ（例えば、ＲＲＣメッセージ）を含まない場合、ＵＥは別のＴＴＩ情報を選択することになる。

【0052】

一実施例において、ＵＥは、利用可能なデータを有する無線ベアラの最高優先度に基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥは、優先度２及び優先度８を有する無線ベアラに属する利用可能なデータを有する。ＵＥは、優先度２がしきい値を超えているか否かに基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択することができる。

【0053】

一実施例において、ＵＥは、利用可能なデータを有する論理チャネルの最高優先度に基づいて、又はどのユーザプレーンプロトコルスタック（例えば、ＵＲＬＬＣ又はｅＭＢＢタイプのユーザプレーンプロトコル、プロトコルスタックカテゴリ／インデックス１又は２・・・）がランダムアクセスを実行しているかに基づいて、ブロードキャストメッセージ内のＴＴＩ情報を選択する。

【0054】

解決策４−専用メッセージ。
解決策４において、ＵＥは、ネットワークから専用メッセージ（例えば、ＲＲＣ再設定メッセージ（RRC reconfiguration message）、ページングメッセージ、ＲＡを開始するためのＰＤＣＣＨ、・・・）を介して、Ｍｓｇ３送信のためのＴＴＩ長を得ることができるであろう。Ｍｓｇ３送信のための複数のＴＴＩ情報が専用メッセージに（暗黙的又は明示的に）含まれている場合、ＵＥは、Ｍｓｇ３送信に適用するためにそれらのうちの１つを選択することができるであろう。

【0055】

一実施例において、ＵＥは、Ｍｓｇ１送信（例えば、Ｍｓｇ１によって使用されるＲＡ構成におけるプリアンブルグループセット、Ｍｓｇ１によって使用されるＲＡ構成におけるＰＲＡＣＨリソースセット、Ｍｓｇ１の長さ又はフォーマット、Ｍｓｇ１によって使用されるＲＡ構成など）に基づいて、専用メッセージ内のＴＴＩ情報を選択する。例えば、ＵＥが特定のサービスタイプデータ（例えば、ＵＲＬＬＣサービスタイプ）を送信するためにＲＡをトリガする場合、その場合に、ＵＥは、特定のサービスタイプのために、専用メッセージ内のＴＴＩ情報を選択することができる。さらに、ＵＥは、利用可能なデータを有する論理チャネル／ＲＢの構成におけるサービスタイプ表示（論理チャネルの優先度と同類である）に基づいて、データがどのサービスタイプに属するかを理解することができる。サービスタイプ表示は、多重化手順において使用され得る。例えば、ＵＥは、異なるサービスタイプ表示を有するデータを送信のためのＴＢに多重化することはできない。その代わりに、ＵＥは、データのヘッダフィールド（例えば、ＲＬＣヘッダフィールド、ＰＤＣＰフィールド）に基づいて、又はユーザプレーンプロトコルタイプ／カテゴリ（例えば、カテゴリ１はＵＲＬＬＣに位置する）を供給することに基づいて、データがどのサービスタイプに属するかを理解することができる。

【0056】

別の例として、ＵＥがＵＲＬＬＣサービスタイプを登録／承認したときにＵＥがＲＡをトリガする場合、ＵＥは、ＵＲＬＬＣサービスタイプのために、専用メッセージ内のＴＴＩ情報を選択することができるであろう。さらなる例として、ＵＥがＲＡをトリガ及び／又は実行する場合に、ＵＥにおける上位レイヤ（例えば、ＮＡＳレイヤ、アプリケーションレイヤ、ＲＲＣレイヤ）が、ＵＥにおける下位レイヤ（例えば、ＭＡＣ、ＰＨＹ）にサービス表示を送信する場合、ＵＥは、サービス表示によって示されるサービスタイプに基づいて、専用メッセージ内のＴＴＩ情報を選択することができるであろう。

【0057】

一実施例において、ＵＥは、ランダムアクセス目的（例えば、システム情報、ページング、測位、位置更新、制御プレーン確立、ビーム回復などを要求する）に基づいて、専用メッセージ内のＴＴＩ情報を選択する。また、ランダムアクセス目的は、ＵＥにおける上位レイヤ（例えば、ＮＡＳ、ＲＲＣ、アプリケーションレイヤ）によって示されてもよい。

【0058】

一実施例において、ＵＥは、潜在的なＭｓｇ３サイズに基づいて、専用メッセージ内のＴＴＩ情報を選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥにおける保留中の利用可能なデータがしきい値より大きい場合、ＵＥは、しきい値より大きい潜在的なメッセージサイズために、専用メッセージ内のＴＴＩ情報を選択する。

【0059】

一実施例において、ＵＥは、そのＤＬ測定に基づいて、接続確立理由（例えば、緊急通報、ｍｏデータ（mo-data）、ｍｔデータ（mt-data））に基づいて、その現在のパワーランピング（power ramping：電力増加）結果（例えば、しきい値時間又はしきい値電力を超えるランピング、ランピングステップとＴＴＩ情報との間のマッピングテーブルに基づいて変更すること）に基づいて、ネットワーク又はＵＥサブスクリプションから提供されるＵＥの優先度（例えば、アクセスクラスなど）に基づいて、又はＭｓｇ３の内容（例えば、どのタイプの制御要素が含まれることができるか、どのＬＣＧ又はどのＲＢ／ＬＣについてのＢＳＲ報告であるか、どのユーザプレーンプロトコルスタックからのデータであるか、どの無線ベアラからのデータであるか、どの論理チャネルからのデータであるか、・・・）に基づいて、専用メッセージ内のＴＴＩ情報を選択する。例えば、Ｍｓｇ３が特定の（一組の）ＬＣ又はＲＢ（例えば、ＵＲＬＬＣタイプＲＢ、ＣＣＣＨ、・・・）からのデータを含むことができる場合、ＵＥは、ＵＥの構成に基づいて、ＬＣ又はＲＢに関連する専用メッセージ内のＴＴＩ情報を選択することができるであろう。別の例として、Ｍｓｇ３が特別な制御要素／特別なメッセージを含むことができる場合、ＵＥは、特別な制御要素／メッセージに関連する専用メッセージ内のＴＴＩ情報を選択することができるであろう。好ましくは、Ｍｓｇ３が特別な制御要素及び／又は特別なメッセージ（例えば、ＲＲＣメッセージ）を含まない場合、ＵＥは別のＴＴＩ情報を選択することになる。

【0060】

一実施例において、利用可能なデータを有する無線ベアラの最高優先度に基づいて、専用メッセージ内のＴＴＩ情報を選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥは、優先度２及び優先度８を有する無線ベアラに属する利用可能なデータを有する。ＵＥは、優先度２がしきい値を超えているか否かに基づいて、専用メッセージ内のＴＴＩ情報を選択することができるであろう。

【0061】

一実施例において、利用可能なデータを有する論理チャネルの最高優先度に基づいて、又はどのユーザプレーンプロトコルスタック（例えば、ＵＲＬＬＣ又はｅＭＢＢタイプのユーザプレーンプロトコル、プロトコルスタックカテゴリ／インデックス１又は２・・・）がランダムアクセスを実行しているかに基づいて、専用メッセージ内のＴＴＩ情報を選択する。

【0062】

解決策５−Ｍｓｇ２送信から暗黙的に派生する。
この解決策では、ＵＥは、Ｍｓｇ２の暗黙の情報に基づいて、Ｍｓｇ３送信のためのＴＴＩ長を得ることができるであろう。一実施例において、ＵＥは、Ｍｓｇ２によって使用されるＴＴＩ長に基づいて、ＴＴＩ長を得る。Ｍｓｇ３送信のＴＴＩ期間は、Ｍｓｇ２のＴＴＩ期間のＮ倍であり得る。Ｎ値は、整数又は１０進数（decimal）である。Ｎ値は、上記の１つ又は複数の解決策に基づいて、ＵＥによって取得されてもよい。例えば、ＵＥは、ネットワークからブロードキャストメッセージを介してＮの値を取得することができる。また、ＵＥは、専用メッセージで別のＮの値を受信した場合、ブロードキャストメッセージで提供されたＮの値を上書きすることができるであろう。

【0063】

別の実施例において、ＵＥは、Ｍｓｇ２によって使用される周波数キャリアに基づいて、ＴＴＩ長を得る。各周波数キャリアは、対応する異なるＴＴＩ長を有することができる。対応するＴＴＩ情報は、システム情報及び／若しくは専用ＲＲＣメッセージを介して、事前定義されるか、並びに／又は提供されてもよい。

【0064】

Ｍｓｇ３開始タイミングオフセット−ＬＴＥでは、Ｍｓｇ２受信とＭｓｇ３送信との間に固定のギャップ（gap：隔たり）期間がある。固定のギャップ期間は、ＵＥのＭｓｇ２／３処理時間（例えば、デコード、トランスポートブロックを（逆）多重化すること）をカバーするように設計される。しかしながら、ＮＲでは、いくつかの可能な方法がそのような固定ギャップ期間を短縮するための利益をもたらすことができる。例えば、図１１に示すように、ショートＴＴＩがＭｓｇ２／Ｍｓｇ３の両方の送信に適用される場合、Ｍｓｇ２とＭｓｇ３との間の固定ギャップの最小値は、ショートＴＴＩに設定されることができる。そうでなければ、最小ギャップは、ショートＴＴＩなしの場合のように、通常のサブフレーム長にしか設定できないであろう。

【0065】

処理時間を削減する他の多くの方法（例えば、ＴＢサイズの提供）が、同様に存在する。これらの方法は、いくつかの利点、並びにいくつかの制限及び／又は複雑さをもたらすことになる。結論として、ネットワークがギャップ期間の長さを決定することができることが、有益であると考える。この概念を達成するために、ＵＥは、ネットワークから提供される情報によってギャップ情報（又は、Ｍｓｇ３開始タイミングオフセットと呼ばれる）を知る必要があるであろう。可能な解決策が下記に示される。

【0066】

解決策１−ＲＡＲ（ランダムアクセス応答）。
ＬＴＥでは、Ｍｓｇ３送信はＲＡＲにおけるＵＬグラントフィールドによってスケジュールされる。ＲＡＲは、（複数の）ＵＥからＭｓｇ１送信機会において送信されたプリアンブルに対する応答である。ＬＴＥにおけるＲＡＲのフォーマットが図８に示される。

【0067】

Ｍｓｇ３送信は、ＲＡＲにおけるＵＬ（アップリンク）グラントフィールドに従ってスケジュールされる。この解決策では、Ｍｓｇ３開始タイミングオフセットを調整するためにＲＡＲに追加情報が追加される。一実施例において、追加情報は、特定のプリアンブルのための、若しくはＵＬグラントフィールドに追加された、ＲＡＲにおける新しいフィールドか、又はＭｓｇ２における新しいフィールドとすることができる。

【0068】

解決策２−Ｍｓｇ２における共通フィールド。
解決策２では、Ｍｓｇ３の開始タイミングオフセットも、解決策１と同様に、Ｍｓｇ２において搬送される。Ｍｓｇ２は、複数のＲＡＲを含むことができる。そして、ＲＡＲのＭＡＣサブヘッダは、ＲＡＲがどのプリアンブルのためのものであるかを示すことになる。しかしながら、ＴＴＩ長は選択肢が限られているので、それらは冗長な情報を繰り返し含む必要はない。したがって、Ｍｓｇ２における（複数の）共通フィールドを使用して、Ｍｓｇ３開始タイミングオフセットを搬送することが提案される。

【0069】

共通フィールドで搬送されるＭｓｇ３開始タイミングオフセットは、異なるＭｓｇ１送信（例えば、異なるプリアンブル）を実行したＵＥに適用されることになる。異なるＭｓｇ１送信は、コードドメイン及び／又は時間ドメイン及び／又は周波数ドメインにおける受信側によって区別可能である。好ましくは、（複数の）共通フィールドは、制御要素として搬送され得る。その代わりに、（複数の）共通フィールドは、ＭＡＣ（サブ）ヘッダの一部として、データ（例えば、ＲＲＣ設定）として、又はＭｓｇ２をスケジュールするための制御信号（例えば、ＰＤＣＣＨ信号）において、搬送されることができる。

【0070】

複数の共通フィールドがＭｓｇ２に含まれる場合、ＵＥは、Ｍｓｇ３送信に適用するために、それらのうちの１つを選択することができるであろう。一実施例において、ＵＥは、Ｍｓｇ１送信（例えば、Ｍｓｇ１によって使用されるＲＡ構成におけるプリアンブルグループセット、Ｍｓｇ１によって使用されるＲＡ構成におけるＰＲＡＣＨリソースセット、Ｍｓｇ１の長さ又はフォーマット、Ｍｓｇ１によって使用されるＲＡ構成など）に基づいて、共通フィールドを選択することができるであろう。ＵＥは、同様に、サービスタイプ（例えば、ＵＲＬＬＣ、ｅＭＢＢ、遅延センシティブ（delay sensitive）．．．）に基づいて、共通フィールドを選択することができるであろう。例えば、ＵＥが特定のサービスタイプデータ（例えば、ＵＲＬＬＣサービスタイプ）を送信するためにＲＡをトリガする場合、その場合に、ＵＥは、特定のサービスタイプのために、共通フィールドを選択することができるであろう。さらに、ＵＥは、利用可能なデータを有する論理チャネル／ＲＢの構成におけるサービスタイプ表示（論理チャネルの優先度と同類である）に基づいて、データがどのサービスタイプに属するかを理解することができる。サービスタイプ表示は、多重化手順において使用され得る。例えば、ＵＥは、異なるサービスタイプ表示を有するデータを送信のためのＴＢに多重化することはできない。

【0071】

その代わりに、ＵＥは、データのヘッダフィールド（例えば、ＲＬＣヘッダフィールド、ＰＤＣＰフィールド）に基づいて、又はユーザプレーンプロトコルタイプ／カテゴリ（例えば、カテゴリ１はＵＲＬＬＣに位置する）を供給することに基づいて、データがどのサービスタイプに属するかを理解することができる。一例として、ＵＥがＵＲＬＬＣサービスタイプを登録／承認したときにＵＥがＲＡをトリガする場合、ＵＥは、ＵＲＬＬＣサービスタイプのために、共通フィールドを選択することができるであろう。別の例として、ＵＥがＲＡをトリガ及び／又は実行する場合に、ＵＥにおける上位レイヤ（例えば、ＮＡＳレイヤ、アプリケーションレイヤ、ＲＲＣレイヤ）が、ＵＥにおける下位レイヤ（例えば、ＭＡＣ、ＰＨＹ）にサービス表示を送信する場合、ＵＥは、サービス表示によって示されるサービスタイプに基づいて、共通フィールドを選択することができるであろう。

【0072】

一実施例において、ＵＥは、ランダムアクセス目的（例えば、システム情報、ページング、測位、位置更新、制御プレーン確立、ビーム回復などを要求する）に基づいて、共通フィールドを選択する。また、ランダムアクセス目的は、ＵＥにおける上位レイヤ（例えば、ＮＡＳ、ＲＲＣ、アプリケーションレイヤ）によって示されてもよい。

【0073】

一実施例において、ＵＥは、潜在的なＭｓｇ３サイズに基づいて、共通フィールドを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥにおける保留中の利用可能なデータがしきい値より大きい場合、ＵＥは、しきい値より大きい潜在的なメッセージサイズために、共通フィールドを選択する。

【0074】

一実施例において、ＵＥは、そのＤＬ測定に基づいて、接続確立理由（例えば、緊急通報、ｍｏデータ（mo-data）、ｍｔデータ（mt-data））に基づいて、その現在のパワーランピング（power ramping：電力増加）結果（例えば、しきい値時間又はしきい値電力を超えるランピング、ランピングステップとＭｓｇ３開始タイミングオフセットとの間のマッピングテーブルに基づいて変更すること）に基づいて、ネットワーク又はＵＥサブスクリプションから提供されるＵＥの優先度（例えば、アクセスクラスなど）に基づいて、又はＭｓｇ３の内容（例えば、どのタイプの制御要素が含まれることができるか、どのＬＣＧ又はどのＲＢ／ＬＣについてのＢＳＲ報告であるか、どのユーザプレーンプロトコルスタックからのデータであるか、どの無線ベアラからのデータであるか、どの論理チャネルからのデータであるか、・・・）に基づいて、共通フィールドを選択する。例えば、Ｍｓｇ３が特定の（一組の）ＬＣ又はＲＢ（例えば、ＵＲＬＬＣタイプＲＢ、ＣＣＣＨ、・・・）からのデータを含むことができる場合、ＵＥは、ＵＥの構成（例えばＬＣ／ＲＢとランダムアクセス構成との間の関連付け、ＬＣ／ＲＢとサービス構成との間の関連付け、ＬＣ／ＲＢとトランスポートチャネル構成との間の関連付けなど）に基づいて、ＬＣ又はＲＢに関連する共通フィールドを選択することができるであろう。別の例として、Ｍｓｇ３が特別な制御要素／特別なメッセージを含むことができる場合、ＵＥは、特別な制御要素／メッセージに関連する共通フィールドを選択することができるであろう。好ましくは、Ｍｓｇ３が特別な制御要素及び／又は特別なメッセージ（例えば、ＲＲＣメッセージ）を含まない場合、ＵＥは別の共通フィールドを選択することになる。

【0075】

一実施例において、ＵＥは、利用可能なデータを有する無線ベアラの最高優先度に基づいて、共通フィールドを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥは、優先度２及び優先度８を有する無線ベアラに属する利用可能なデータを有する。ＵＥは、優先度２がしきい値を超えているか否かに基づいて、共通フィールドを選択することができるであろう。

【0076】

一実施例において、ＵＥは、利用可能なデータを有する論理チャネルの最高優先度に基づいて、又はどのユーザプレーンプロトコルスタック（例えば、ＵＲＬＬＣ又はｅＭＢＢタイプのユーザプレーンプロトコル、プロトコルスタックカテゴリ／インデックス１又は２・・・）がランダムアクセスを実行しているかに基づいて、共通フィールドを選択する。

【0077】

解決策３−ブロードキャスト情報。
解決策３において、ＵＥは、ネットワーク（例えば、ｇＮＢ、基地局、ＴＲＰなど）からブロードキャストメッセージ（例えば、（複数の）システム情報、ＭＩＢなど）を介して、Ｍｓｇ３送信のためのＭｓｇ３開始タイミングオフセットを得ることができるであろう。Ｍｓｇ３送信のための複数のＭｓｇ３開始タイミングオフセットがブロードキャストメッセージに含まれる場合、ＵＥは、Ｍｓｇ３送信に適用するためにそれらのうちの１つを選択することができるであろう。

【0078】

一実施例において、ＵＥは、Ｍｓｇ１送信（例えば、Ｍｓｇ１によって使用されるＲＡ構成におけるプリアンブルグループセット、Ｍｓｇ１によって使用されるＲＡ構成におけるＰＲＡＣＨリソースセット、Ｍｓｇ１の長さ又はフォーマット、Ｍｓｇ１によって使用されるＲＡ構成など）に基づいて、又はサービスタイプ（例えば、ＵＲＬＬＣ、ｅＭＢＢ、遅延センシティブ（delay sensitive）．．．）に基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、ＵＥが特定のサービスタイプデータ（例えば、ＵＲＬＬＣサービスタイプ）を送信するためにＲＡをトリガする場合、その場合に、ＵＥは、特定のサービスタイプのために、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。さらに、ＵＥは、利用可能なデータを有する論理チャネル／ＲＢの構成におけるサービスタイプ表示（論理チャネルの優先度と同類である）に基づいて、データがどのサービスタイプに属するかを理解することができる。

【0079】

サービスタイプ表示は、多重化手順において使用され得る。例えば、ＵＥは、異なるサービスタイプ表示を有するデータを送信のためのＴＢに多重化することはできない。その代わりに、ＵＥは、データのヘッダフィールド（例えば、ＲＬＣヘッダフィールド、ＰＤＣＰフィールド）に基づいて、データがどのサービスタイプに属するかを理解することができる。ＵＥは、同様に、ユーザプレーンプロトコルタイプ／カテゴリ（例えば、カテゴリ１はＵＲＬＬＣに位置する）を供給することに基づいて、データがどのサービスタイプに属するかを理解することができる。別の例として、ＵＥがＵＲＬＬＣサービスタイプを登録／承認したときにＵＥがＲＡをトリガする場合、ＵＥは、ＵＲＬＬＣサービスタイプのために、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。さらなる例として、ＵＥがＲＡをトリガ及び／又は実行する場合に、ＵＥにおける上位レイヤ（例えば、ＮＡＳレイヤ、アプリケーションレイヤ、ＲＲＣレイヤ）が、ＵＥにおける下位レイヤ（例えば、ＭＡＣ、ＰＨＹ）にサービス表示を送信する場合、ＵＥは、サービス表示によって示されるサービスタイプに基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。

【0080】

一実施例において、ＵＥは、ランダムアクセス目的（例えば、ブロードキャストメッセージ、ページング、測位、位置更新、制御プレーンの確立、ビーム回復などを要求する）に基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。また、ランダムアクセス目的は、ＵＥにおける上位レイヤ（例えば、ＮＡＳ、ＲＲＣ、アプリケーションレイヤ）によって示されてもよい。

【0081】

一実施例において、ＵＥは、潜在的なＭｓｇ３サイズに基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥにおける保留中の利用可能なデータがしきい値より大きい場合、ＵＥは、しきい値より大きい潜在的なメッセージサイズために、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。

【0082】

一実施例において、そのＤＬ測定に基づいて、接続確立理由（例えば、緊急通報、ｍｏデータ（mo-data）、ｍｔデータ（mt-data））に基づいて、その現在のパワーランピング（power ramping：電力増加）結果（例えば、しきい値時間又はしきい値電力を超えるランピング、ランピングステップとＭｓｇ３開始タイミングオフセットとの間のマッピングテーブルに基づいて変更すること）に基づいて、ネットワーク又はＵＥサブスクリプションから提供されるＵＥの優先度（例えば、アクセスクラスなど）に基づいて、又はＭｓｇ３の内容（例えば、どのタイプの制御要素が含まれることができるか、どのＬＣＧ又はどのＲＢ／ＬＣについてのＢＳＲ報告であるか、どのユーザプレーンプロトコルスタックからのデータであるか、どの無線ベアラからのデータであるか、どの論理チャネルからのデータであるか、・・・）に基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、Ｍｓｇ３が特定の若しくは一組のＬＣ又はＲＢ（例えば、ＵＲＬＬＣタイプＲＢ、ＣＣＣＨ、・・・）からのデータを含むことができる場合、ＵＥは、ＵＥの構成に基づいて、ＬＣ又はＲＢに関連するブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。別の例として、Ｍｓｇ３が特別な制御要素／特別なメッセージを含むことができる場合、ＵＥは、特別な制御要素／メッセージに関連するブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。好ましくは、Ｍｓｇ３が特別な制御要素及び／又は特別なメッセージ（例えばＲＲＣメッセージ）を含まない場合、ＵＥは別のＭｓｇ３開始タイミングオフセットを選択することになる。

【0083】

一実施例において、ＵＥは、利用可能なデータを有する無線ベアラの最高優先度に基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥは、優先度２及び優先度８を有する無線ベアラに属する利用可能なデータを有する。ＵＥは、優先度２がしきい値を超えているか否かに基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。

【0084】

一実施例において、ＵＥは、利用可能なデータを有する論理チャネルの最高優先度に基づいて、又はどのユーザプレーンプロトコルスタック（例えば、ＵＲＬＬＣ又はｅＭＢＢタイプのユーザプレーンプロトコル、プロトコルスタックカテゴリ／インデックス１又は２・・・）がランダムアクセスを実行しているかに基づいて、ブロードキャストメッセージ内のＭｓｇ３開始タイミングオフセットを選択する。

【0085】

解決策４−専用メッセージ。
解決策４において、ＵＥは、ネットワークから専用メッセージ（例えば、ＲＲＣ再設定メッセージ、ページングメッセージ、ＲＡを開始するためのＰＤＣＣＨ、・・・）を介して、Ｍｓｇ３送信のためのＭｓｇ３開始タイミングオフセットを得ることができるであろう。Ｍｓｇ３送信のための複数のＭｓｇ３開始タイミングオフセットが専用メッセージに（暗黙的又は明示的に）含まれている場合、ＵＥは、Ｍｓｇ３送信に適用するためにそれらのうちの１つを選択することができるであろう。

【0086】

一実施例において、ＵＥは、Ｍｓｇ１送信（例えば、Ｍｓｇ１によって使用されるＲＡ構成におけるプリアンブルグループセット、Ｍｓｇ１によって使用されるＲＡ構成におけるＰＲＡＣＨリソースセット、Ｍｓｇ１の長さ又はフォーマット、Ｍｓｇ１によって使用されるＲＡ構成など）に基づいて、又はサービスタイプ（例えば、ＵＲＬＬＣ、ｅＭＢＢ、遅延センシティブ（delay sensitive）．．．）に基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、ＵＥが特定のサービスタイプデータ（例えば、ＵＲＬＬＣサービスタイプ）を送信するためにＲＡをトリガする場合、その場合に、ＵＥは、特定のサービスタイプのために、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。さらに、ＵＥは、利用可能なデータを有する論理チャネル／ＲＢの構成におけるサービスタイプ表示（論理チャネルの優先度と同類である）に基づいて、データがどのサービスタイプに属するかを理解することができる。サービスタイプ表示は、多重化手順において使用され得る。例えば、ＵＥは、異なるサービスタイプ表示を有するデータを送信のためのＴＢに多重化することはできない。その代わりに、ＵＥは、データのヘッダフィールド（例えば、ＲＬＣヘッダフィールド、ＰＤＣＰフィールド）に基づいて、又はユーザプレーンプロトコルタイプ／カテゴリ（例えば、カテゴリ１はＵＲＬＬＣに位置する）を供給することに基づいて、データがどのサービスタイプに属するかを理解することができる。

【0087】

別の例として、ＵＥがＵＲＬＬＣサービスタイプを登録／承認したときにＵＥがＲＡをトリガする場合、ＵＥは、ＵＲＬＬＣサービスタイプのために、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。さらなる例として、ＵＥがＲＡをトリガ及び／又は実行する場合に、ＵＥにおける上位レイヤ（例えば、ＮＡＳレイヤ、アプリケーションレイヤ、ＲＲＣレイヤ）が、ＵＥにおける下位レイヤ（例えば、ＭＡＣ、ＰＨＹ）にサービス表示を送信する場合、ＵＥは、サービス表示によって示されるサービスタイプに基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。

【0088】

一実施例において、ＵＥは、ランダムアクセス目的（例えば、システム情報、ページング、測位、位置更新、制御プレーン確立、ビーム回復などを要求する）に基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。また、ランダムアクセス目的は、ＵＥにおける上位レイヤ（例えば、ＮＡＳ、ＲＲＣ、アプリケーションレイヤ）によって示されてもよい。

【0089】

一実施例において、ＵＥは、潜在的なＭｓｇ３サイズに基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥにおける保留中の利用可能なデータがしきい値より大きい場合、ＵＥは、しきい値より大きい潜在的なメッセージサイズために、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。

【0090】

一実施例において、ＵＥは、そのＤＬ測定に基づいて、接続確立理由（例えば、緊急通報、ｍｏデータ（mo-data）、ｍｔデータ（mt-data））に基づいて、その現在のパワーランピング（power ramping：電力増加）結果（例えば、しきい値時間又はしきい値電力を超えるランピング、ランピングステップとＭｓｇ３開始タイミングオフセットとの間のマッピングテーブルに基づいて変更すること）に基づいて、ネットワーク又はＵＥサブスクリプションから提供されるＵＥの優先度（例えば、アクセスクラスなど）に基づいて、又はＭｓｇ３の内容（例えば、どのタイプの制御要素が含まれることができるか、どのＬＣＧ又はどのＲＢ／ＬＣについてのＢＳＲ報告であるか、どのユーザプレーンプロトコルスタックからのデータであるか、どの無線ベアラからのデータであるか、どの論理チャネルからのデータであるか、・・・）に基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、Ｍｓｇ３が特定の（一組の）ＬＣ又はＲＢ（例えば、ＵＲＬＬＣタイプＲＢ、ＣＣＣＨ、・・・）からのデータを含むことができる場合、ＵＥは、ＵＥの構成に基づいて、ＬＣ又はＲＢに関連する専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。別の例として、Ｍｓｇ３が特別な制御要素／特別なメッセージを含むことができる場合、ＵＥは、特別な制御要素／メッセージに関連する専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。好ましくは、Ｍｓｇ３が特別な制御要素及び／又は特別なメッセージ（例えばＲＲＣメッセージ）を含まない場合、ＵＥは別のＭｓｇ３開始タイミングオフセットを選択することになる。

【0091】

一実施例において、利用可能なデータを有する無線ベアラの最高優先度に基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。例えば、ＵＥがＲＡを実行しているときに、ＵＥは、優先度２及び優先度８を有する無線ベアラに属する利用可能なデータを有する。ＵＥは、優先度２がしきい値を超えているか否かに基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択することができるであろう。

【0092】

一実施例において、ＵＥは、利用可能なデータを有する論理チャネルの最高優先度に基づいて、又はどのユーザプレーンプロトコルスタック（例えば、ＵＲＬＬＣ又はｅＭＢＢタイプのユーザプレーンプロトコル、プロトコルスタックカテゴリ／インデックス１又は２・・・）がランダムアクセスを実行しているかに基づいて、専用メッセージ内のＭｓｇ３開始タイミングオフセットを選択する。

【0093】

解決策５−Ｍｓｇ２送信から暗黙的に派生する。
この解決策では、ＵＥは、Ｍｓｇ２の暗黙の情報に基づいて、Ｍｓｇ３送信のためのＭｓｇ３開始タイミングオフセットを得ることができるであろう。一実施例において、ＵＥは、Ｍｓｇ２によって使用される開始タイミングオフセットに基づいて、Ｍｓｇ３開始タイミングオフセットを得る。Ｍｓｇ３送信のＭｓｇ３開始タイミングオフセットは、Ｍｓｇ２の開始タイミングオフセットのＮ倍であり得る。Ｎ値は、整数又は１０進数（decimal）である。Ｎ値は、上記の１つ又は複数の解決策に基づいて、ＵＥによって取得されてもよい。例えば、ＵＥは、ネットワークからブロードキャストメッセージを介してＮの値を取得することができる。また、ＵＥは、専用メッセージで別のＮの値を受信した場合、ブロードキャストメッセージで提供されたＮの値を上書きすることができるであろう。

【0094】

別の実施例において、ＵＥは、Ｍｓｇ２によって使用される周波数キャリアに基づいて、Ｍｓｇ３開始タイミングオフセットを得る。各周波数キャリアは、対応する異なるＭｓｇ３開始タイミングオフセットを有することができる。対応するＭｓｇ３開始タイミングオフセットは、システム情報及び／若しくは専用ＲＲＣメッセージを介して、事前定義されるか、並びに／又は提供されてもよい。

【0095】

Ｍｓｇ３開始タイミングオフセットは、上述の解決策１〜５又はこれらの解決策の組み合わせによって導出されることができ、一方Ｍｓｇ３開始タイミングオフセット及びＭｓｇ３のＴＴＩ情報は、同じ又は異なる解決策を適用することができる。Ｍｓｇ３開始タイミングオフセットは、定期的な動作の、ＴＴＩ持続時間、計算方式（numerology）、シンボル、スロット、マイクロ秒、ミリ秒、又はＮ回の周期性で示されることができる。Ｎは、整数又は１０進数（decimal number）とすることができる。

【0096】

図１２は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１２００である。ステップ１２０５において、ＵＥが、ネットワークから専用メッセージを受信して、Ｍｓｇ３送信のＴＴＩ持続時間及び／又はＭｓｇ３送信のための開始タイミングオフセットを設定する。ステップ１２１０において、ＵＥが、ネットワークにＭｓｇ１を送信する。ステップ１２１５において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信する。ステップ１２２０において、ＵＥが、ＴＴＩ持続時間及び／又は開始タイミングオフセットに従って、ネットワークにＭｓｇ３を送信する。

【0097】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークから専用メッセージを受信して、Ｍｓｇ３送信のＴＴＩ持続時間及び／又はＭｓｇ３送信のための開始タイミングオフセットを設定し、（ｉｉ）ネットワークにＭｓｇ１を送信し、（ｉｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、そしてＴＴＩ持続時間及び／又は開始タイミングオフセットに従って、ネットワークにＭｓｇ３を送信することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0098】

図１３は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１３００である。ステップ１３０５において、ＵＥが、ネットワークからブロードキャストメッセージを受信して、Ｍｓｇ３のＴＴＩ持続時間を設定する。ステップ１３１０において、ＵＥが、ネットワークにＭｓｇ１を送信する。ステップ１３１５において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信する。ステップ１３２０において、ＵＥが、Ｍｓｇ３のＴＴＩ持続時間に従ってネットワークにＭｓｇ３を送信する。

【0099】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークからブロードキャストメッセージを受信して、Ｍｓｇ３のＴＴＩ持続時間を設定し、（ｉｉ）ネットワークにＭｓｇ１を送信し、（ｉｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、そして（ｉｖ）Ｍｓｇ３のＴＴＩ持続時間に従ってネットワークにＭｓｇ３を送信することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0100】

図１４は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１４００である。ステップ１４０５において、ＵＥが、ネットワークにプリアンブルを送信する。ステップ１４１０において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、ここで、Ｍｓｇ２はＭｓｇ３送信のＴＴＩ情報及び／又はＭｓｇ３送信の開始タイミングオフセットを含む。一実施例において、Ｍｓｇ３送信のＴＴＩ情報は、Ｍｓｇ２内の複数のＲＡＲのための共通フィールドにおいて示される。別の実施例において、Ｍｓｇ３のＴＴＩ情報が、Ｍｓｇ１送信に応答したＲＡＲにおいて示される。一実施例において、Ｍｓｇ３の開始タイミングオフセットは、Ｍｓｇ２内の複数のＲＡＲのための共通のフィールドにおいて示される。別の実施例において、Ｍｓｇ３の開始タイミングオフセットが、Ｍｓｇ１送信に応答したＲＡＲにおいて示される。ステップ１４１５において、ＵＥが、Ｍｓｇ３のＴＴＩ情報及び／又はＭｓｇ３の開始タイミングオフセットに従ってネットワークにＭｓｇ３を送信する。

【0101】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークにプリアンブルを送信し、（ｉｉ）プリアンブルに応答したネットワークからＭｓｇ２を受信し、ここで、Ｍｓｇ２はＭｓｇ３送信のＴＴＩ持続時間及び／又はＭｓｇ３送信の開始タイミングオフセットを含み、（ｉｉｉ）Ｍｓｇ３のＴＴＩ情報及び／又はＭｓｇ３の開始タイミングオフセットに従ってネットワークへのＭｓｇ３送信を実行することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0102】

図１５は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１５００である。ステップ１５０５において、ＵＥが、ネットワークにＭｓｇ１を送信する。ステップ１５１０において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信する。ステップ１５１５において、ＵＥが、Ｍｓｇ３のＴＴＩ持続時間に従ってネットワークにＭｓｇ３を送信し、ここで、Ｍｓｇ３のＴＴＩ持続時間はＭｓｇ２のＴＴＩ持続時間に基づいて決定される。

【0103】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークにＭｓｇ１を送信し、（ｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、そして（ｉｉｉ）Ｍｓｇ３のＴＴＩ持続時間に従ってネットワークにＭｓｇ３を送信し、ここで、Ｍｓｇ３のＴＴＩ持続時間はＭｓｇ２のＴＴＩ持続時間に基づいて決定されることを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0104】

図１６は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１６００である。ステップ１６０５において、ＵＥが、ネットワークから専用メッセージを受信して、Ｍｓｇ３送信のための開始タイミングオフセットを設定する。ステップ１６１０において、ＵＥが、ネットワークにＭｓｇ１を送信する。ステップ１６１５において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信する。ステップ１６２０において、ＵＥがＭｓｇ２を受信したときから開始タイミングオフセットが経過した後で、ＵＥが、ネットワークにＭｓｇ３を送信する。

【0105】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークから専用メッセージを受信して、Ｍｓｇ３送信のための開始タイミングオフセットを設定し、（ｉｉ）ネットワークにＭｓｇ１を送信し、（ｉｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、そして（ｉｖ）ＵＥがＭｓｇ２を受信したときから開始タイミングオフセットが経過した後で、ネットワークにＭｓｇ３を送信することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0106】

図１７は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１７００である。ステップ１７０５において、ＵＥが、ネットワークからブロードキャストメッセージを受信して、Ｍｓｇ３送信のための開始タイミングオフセットを設定する。ステップ１７１０において、ＵＥが、ネットワークにＭｓｇ１を送信する。ステップ１７１５において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信する。ステップ１７２０において、ＵＥがＭｓｇ２を受信したときから開始タイミングオフセットが経過した後で、ＵＥが、ネットワークにＭｓｇ３を送信する。

【0107】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークからブロードキャストメッセージを受信して、Ｍｓｇ３送信のための開始タイミングオフセットを設定し、（ｉｉ）ネットワークにＭｓｇ１を送信し、（ｉｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、そして（ｉｖ）ＵＥがＭｓｇ２を受信したときから開始タイミングオフセットが経過した後で、ネットワークにＭｓｇ３を送信することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0108】

図１８は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１８００である。ステップ１８０５において、ＵＥが、ネットワークにＭｓｇ１を送信する。ステップ１８１０において、ＵＥが、Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、ここで、Ｍｓｇ２はＭｓｇ３送信のための開始タイミングオフセットを含む。ステップ１８１５において、ＵＥがＭｓｇ２を受信したときから開始タイミングオフセットが経過した後で、ＵＥが、ネットワークにＭｓｇ３を送信する。

【0109】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークにＭｓｇ１を送信し、（ｉｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、（ｉｉ）Ｍｓｇ１に応答したネットワークからＭｓｇ２を受信し、ここで、Ｍｓｇ２はＭｓｇ３送信のための開始タイミングオフセットを含み、（ｉｉｉ）ＵＥがＭｓｇ２を受信したときから開始タイミングオフセットが経過した後で、ネットワークにＭｓｇ３を送信することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0110】

図１９は、１つの例示的な実施例による、ＵＥの観点からのフローチャート１９００である。ステップ１９０５において、ＵＥが、ネットワークからＭｓｇ３のＴＴＩ情報を含むメッセージを受信する。ステップ１９１０において、ＵＥが、ネットワークにプリアンブルを送信する。ステップ１９１５において、ＵＥが、プリアンブルに応答したネットワークからＭｓｇ２を受信する。一実施例において、Ｍｓｇ３のＴＴＩ情報は、Ｍｓｇ２内の複数のＲＡＲのための共通フィールドにおいて示される。別の実施例において、Ｍｓｇ３のＴＴＩ情報が、Ｍｓｇ１送信に応答したＲＡＲにおいて示される。ステップ１９１５において、ＵＥが、Ｍｓｇ３のＴＴＩ情報に従ってネットワークへのＭｓｇ３送信を実行する。

【0111】

図３及び図４に戻ると、ＵＥの１つの例示的な実施例において、装置３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ＵＥが、（ｉ）ネットワークからＭｓｇ３のＴＴＩ情報を含むメッセージを受信し、（ｉｉ）ネットワークにプリアンブルを送信し、（ｉｉｉ）プリアンブルに応答したネットワークからＭｓｇ２を受信し、そして（ｉｖ）Ｍｓｇ３のＴＴＩ情報に従ってネットワークへのＭｓｇ３送信を実行することを可能にする。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、本明細書に記載された上記の動作及びステップ、又は他のものの全てを実行することができる。

【0112】

図１２〜図１９に例示されるとともに上述された実施例に関して、一実施例において、ＵＥは、専用メッセージ、ブロードキャストメッセージ、又はＭｓｇ２内にＭｓｇ３の複数のＴＴＩ情報が存在する場合、Ｍｓｇ３のＴＴＩ情報を選択する。さらに、Ｍｓｇ３のＴＴＩ情報は、Ｍｓｇ１に応答したＲＡＲに含まれるか、又はＭｓｇ２内の複数のＲＡＲのための共通のフィールドに含まれることができるであろう。

【0113】

一実施例において、ＵＥは、専用メッセージ、ブロードキャストメッセージ、又はＭｓｇ２内にＭｓｇ３送信のための複数の開始タイミングオフセットが存在する場合、Ｍｓｇ３のＴＴＩ情報を選択する。さらに、Ｍｓｇ３の開始タイミングオフセットは、Ｍｓｇ１に応答したＲＡＲに含まれるか、又はＭｓｇ２内の複数のＲＡＲのための共通のフィールドに含まれることができるであろう。

【0114】

本開示の様々な態様が上記で説明された。本明細書における教示が多種多様な形態で具体化することができ、そして本明細書で開示されている特定の構造、機能、又はその両方が単に代表的なものに過ぎない、ということは明らかであるはずである。本明細書の教示に基づいて、当業者は、本明細書で開示された態様が任意の他の態様から独立して実施されることができ、そしてこれらの態様の２つ以上が様々な方法で組み合わせられることができる、ということを理解すべきである。例えば、本明細書で説明された任意の数の態様を使用して、装置が実施され得るか、又は方法が実行され得る。さらに、本明細書で説明された態様のうちの１つ若しくは複数に加えて、又はそれ以外の、他の構造、機能、若しくは構造及び機能を使用して、そのような装置が実施され得るか、又はそのような方法が実行され得る。上記の概念のいくつかの例として、いくつかの態様では、パルス繰り返し周波数に基づいてコンカレントチャネル（concurrent channel）が確立されることができる。いくつかの態様では、パルス位置又はオフセットに基づいてコンカレントチャネルが確立されることができる。いくつかの態様では、時間ホッピングシーケンスに基づいてコンカレントチャネルが確立されることができる。いくつかの態様では、コンカレントチャネルは、パルス繰り返し周波数、パルス位置又はオフセット、及び時間ホッピングシーケンスに基づいて確立されてもよい。

【0115】

当業者は、情報及び信号が、様々な異なる技術及び技法のいずれかを使用して表されることができる、ということを理解するであろう。例えば、上記の説明を通して参照され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁気フィールド若しくは磁性粒子、光学フィールド若しくは光学粒子、又はそれらの任意の組み合わせによって表されることができる。

【0116】

当業者は、本明細書で開示される態様に関連して説明された様々な例示的な論理ブロック、モジュール、プロセッサ、手段、回路、及びアルゴリズムステップが、電子的ハードウェア（例えば、ソースコーディング若しくはいくつかの他の技術を使用して設計され得る、デジタル実装、アナログ実装、又は２つの組み合わせ）、命令を組み込んだ様々な形式のプログラム若しくは設計コード（それは、本明細書では便宜上、「ソフトウェア」又は「ソフトウェアモジュール」と呼ばれ得る）、又はその両方の組み合わせとして実施され得る、ということを更に認識するであろう。ハードウェア及びソフトウェアのこの互換性を明確に説明するために、様々な例示的なコンポーネント、ブロック、モジュール、回路、及びステップが、それらの機能性に関して上記で一般的に説明された。そのような機能性がハードウェア又はソフトウェアとして実装されるかどうかは、特定のアプリケーション、及びシステム全体に課される設計の制約に依存する。当業者は、特定のアプリケーションごとに様々な方法で説明された機能を実装することができるが、しかし、そのような実装の決定は、本開示の範囲から逸脱するものと解釈されるべきではない。

【0117】

さらに、本明細書に開示された態様に関連して説明された様々な例示的な論理ブロック、モジュール、及び回路は、集積回路（「ＩＣ」）、アクセス端末、又はアクセスポイント内で実施され得るか、又はそれらによって実行され得る。ＩＣは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブルロジックデバイス、ディスクリートゲート若しくはトランジスタロジック、ディスクリートハードウェアコンポーネント、電気部品、光学部品、機械部品、又は本明細書で説明された機能を実行するように設計されたそれらの任意の組み合わせを含み得るとともに、ＩＣの内部、ＩＣの外部、又はその両方に存在するコード若しくは命令を実行することができる。汎用プロセッサは、マイクロプロセッサであってもよいが、代替として、プロセッサは、任意の従来のプロセッサ、制御装置、マイクロ制御装置、又は状態機械であってもよい。プロセッサは、同様に、コンピューティング装置の組み合わせ、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと連動する１つ若しくは複数のマイクロプロセッサ、又は任意の他のそのような構成として実施されてもよい。

【0118】

任意の開示されたプロセスにおけるステップの任意の特定の順序又は階層は、サンプルアプローチの一例である、ということが理解される。設計の好みに基づいて、プロセスにおけるステップの特定の順序又は階層は、本開示の範囲内にとどまりながら再構成されることができる、ということが理解される。添付の方法の請求項は、サンプル順序における様々なステップの要素を提示するとともに、提示された特定の順序又は階層に限定されることを意味しない。

【0119】

本明細書で開示された態様に関連して説明された方法又はアルゴリズムのステップは、ハードウェアにおいて、プロセッサによって実行されるソフトウェアモジュールにおいて、又はその２つの組み合わせにおいて、直接具体化されてもよい。ソフトウェアモジュール（例えば、実行可能命令及び関連データを含む）並びに他のデータは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭなどのデータメモリ、又は当技術分野で知られている任意の他の形態のコンピュータ読み取り可能な記憶媒体に存在してもよい。サンプル記憶媒体は、例えばコンピュータ／プロセッサ（それは、本明細書では便宜上、「プロセッサ」と呼ばれ得る）のような機械に結合されることができ、そのようなプロセッサは、情報（例えばコード）を記憶媒体から読み取り、そして情報を記憶媒体に書き込むことができる。サンプル記憶媒体は、プロセッサに一体化されていてもよい。プロセッサ及び記憶媒体は、ＡＳＩＣ内に存在してもよい。ＡＳＩＣは、ユーザ装置内に存在してもよい。代わりに、プロセッサ及び記憶媒体は、ユーザ装置内のディスクリート部品として存在してもよい。さらに、いくつかの態様では、任意の適切なコンピュータプログラム製品は、本開示の１つ又は複数の態様に関連するコードを含むコンピュータ読み取り可能媒体を含むことができる。いくつかの態様では、コンピュータプログラム製品は、包装材料を含むことができる。

【0120】

本発明を様々な態様に関連して説明してきたが、本発明は更なる変更が可能であることが理解されるであろう。この出願は、一般に、本発明の原理に従うとともに、本発明が関係する技術分野における既知の習慣的な慣習に含まれるような本開示からのそのような逸脱を含む、本発明のあらゆる変形、使用、又は適合をカバーすることを目的としている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】