知財求人 - 知財ポータルサイト「IP Force」
▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
特表2024-512126ユーザ機器、スケジューリングノード、ユーザ機器の方法、およびスケジューリングノードの方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-18
(54)【発明の名称】ユーザ機器、スケジューリングノード、ユーザ機器の方法、およびスケジューリングノードの方法
(51)【国際特許分類】
H04W 74/02 20090101AFI20240311BHJP
H04W 74/0833 20240101ALI20240311BHJP
H04W 76/27 20180101ALI20240311BHJP
H04W 72/1268 20230101ALI20240311BHJP
【ＦＩ】
H04W74/02
H04W74/0833
H04W76/27
H04W72/1268
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023560173
(86)(22)【出願日】2022-03-28
(85)【翻訳文提出日】2023-09-28
(86)【国際出願番号】 EP2022058049
(87)【国際公開番号】W WO2022207527
(87)【国際公開日】2022-10-06
(31)【優先権主張番号】21166342.2
(32)【優先日】2021-03-31
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21199586.5
(32)【優先日】2021-09-28
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】シャー リキン
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】タオ ミン－フン
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067EE02
5K067JJ16
(57)【要約】
ＵＥは、送受信機および回路を備える。回路は、待機するべき送信機会が存在するか否かを判定する。待機するべき送信機会とは、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがないと判定されたとき、回路は、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する。一方、待機するべき送信機会が存在すると判定され、その送信機会が発生すると、回路は、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように送受信機を制御する。
【選択図】図２１
【選択図】図２１
【特許請求の範囲】
【請求項1】
ユーザ機器（ＵＥ）であって、送受信機と、
回路であって、
非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出し、
待機するべき送信機会が存在するか否かを判定し、前記待機するべき送信機会が、
－ 前記第１のデータの少なくとも一部を送信するための送信機会であり、かつ、
－ 前記第１のデータを送信するための前記手順の一部として発生すると予期され、
前記待機するべき送信機会が存在しない、または前記待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始し、
前記待機するべき送信機会が存在すると判定され、前記送信機会が発生したとき、前記送信機会を使用して、前記第２のデータの前記検出を示すトラフィック指示を送信するように、前記送受信機を制御する、
前記回路と、
を備える、ユーザ機器（ＵＥ）。
【請求項2】
前記第１のデータを送信するための前記手順が、ＲＡＣＨ手順において開始される手順であり、前記待機するべき送信機会が、
－ 前記ＲＡＣＨ手順の最初の送信である、
－ 前記ＲＡＣＨ手順の一部として受信されたアップリンクグラントによって示されている、または、
－ 前記ＲＡＣＨ手順の完了後に前記第１のデータを送信するために受信されたアップリンクグラントによって示されている、
請求項１に記載のユーザ機器（ＵＥ）。
【請求項3】
前記第１のデータを送信するための前記手順が、ＲＡＣＨ手順において開始される手順であり、－ 前記回路が、前記第１のデータを送信するように前記送受信機を制御した後、前記待機するべき送信機会が存在しないと判定する、または、
－ 前記待機するべき送信機会が、アップリンクグラントによって示されることが予期され、前記アップリンクグラントが、
〇 前記ＲＡＣＨ手順の一部として、または、
〇 前記ＲＡＣＨ手順の完了後に前記第１のデータの一部を送信するために、
受信されることが予期される、
請求項１に記載のユーザ機器（ＵＥ）。
【請求項4】
前記アップリンクグラントが、前記回路が前記送受信機を制御して、－ 前記ＲＡＣＨ手順の最初の送信を送信した後、
－ さらに送信される前記第１のデータの量を示すバッファ状態報告（ＢＳＲ）を送信した後、および／または、
－ 前記ＢＳＲを送信した後に前記第１のデータの一部を送信した後、このとき前記第１のデータの前記一部の量が、前記ＢＳＲによって示された量よりも小さい、
に受信されることが予期される、
請求項３に記載のユーザ機器（ＵＥ）。
【請求項5】
前記予期されるアップリンクグラントが受信されておらず、かつ、もはや受信される見込みがないとき、前記待機するべき送信機会が、もはや発生する見込みがなく、－ 前記送受信機が、前記第１のデータを送信するための前記手順の終了を示す指示を受信した場合、および／または、
－ 前記第１のデータの少なくとも一部の最初の送信または前の送信から所定の時間が経過した場合、
前記予期されるアップリンクグラントが、もはや受信される見込みがない、
請求項３または請求項４に記載のユーザ機器（ＵＥ）。
【請求項6】
前記トラフィック指示が、－ 前記アップリンクグラントによって示される前記リソースを使用する、前記第１のデータの少なくとも一部、および／または、
－ 前記第１のデータの量を示すバッファ状態報告（ＢＳＲ）、
と一緒に送信される、
請求項１から請求項５のいずれか１項に記載のＵＥ。
【請求項7】
前記ＲＡＣＨ手順が、４ステップＲＡＣＨ手順または２ステップＲＡＣＨ手順である、請求項１から請求項６のいずれか１項に記載のＵＥ。
【請求項8】
前記第１のデータを送信するための前記手順が、前記第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順であり、前記回路が、
前記ＣＧ手順の次のリソースが次のＲＡＣＨリソースよりも早い場合、待機するべき送信機会が存在すると判定し、前記送信機会を使用して前記トラフィック指示を送信するように前記送受信機を制御し、
前記ＣＧ手順の前記次のリソースが前記次のＲＡＣＨリソースよりも遅い場合、待機するべき送信機会が存在しないと判定し、前記接続状態に入るために前記ＲＡＣＨ手順を開始する、
請求項１に記載のユーザ機器（ＵＥ）。
【請求項9】
前記トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、前記ＬＣＩＤの前記事前定義値が、前記第２のデータが検出されたことを示す、
請求項１から請求項８のいずれか１項に記載のＵＥ。
【請求項10】
前記ＬＣＩＤの前記事前定義値が、ＭＡＣ制御要素ＣＥが前記ＭＡＣサブヘッダに付加されていないことを示す、請求項９に記載のＵＥ。
【請求項11】
前記ＬＣＩＤが、ＢＳＲ ＭＡＣ制御要素（ＣＥ）が前記ＭＡＣサブヘッダに付加されていることを示し、前記ＢＳＲ ＭＡＣ ＣＥが、さらに送信される前記第１のデータの量を示す、
請求項９に記載のＵＥ。
【請求項12】
前記トラフィック指示が、ＭＡＣ制御要素（ＣＥ）の一部であり、－ 前記ＭＡＣ ＣＥの１ビットが、前記第２のデータが検出されたか否かを示し、
－ 前記ＭＡＣ ＣＥの２ビットが、前記非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、前記第１のデータの論理チャネルグループ（ＬＣＧ）を示し、
－ 前記ＭＡＣ ＣＥの５ビットが、前記示されたＬＣＧに対応する前記第１のデータの、さらに送信される量を示す、
請求項１から請求項８のいずれか１項に記載のＵＥ。
【請求項13】
前記トラフィック指示が、無線リソース制御（ＲＲＣ）レベルの指示である、請求項１から請求項８のいずれか１項に記載のＵＥ。
【請求項14】
ユーザ機器（ＵＥ）のための方法であって、前記方法が、以下のステップ、すなわち、－ 非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出するステップと、
－ 待機するべき送信機会が存在するか否かを判定するステップであって、前記待機するべき送信機会が、
－ 前記第１のデータの少なくとも一部を送信するための送信機会であり、かつ、
－ 前記第１のデータを送信するための前記手順の一部として発生すると予期される、
ステップと、
前記待機するべき送信機会が存在しない、または前記待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始するステップと、
前記待機するべき送信機会が存在すると判定され、前記送信機会が発生したとき、前記送信機会を使用して、前記第２のデータの前記検出を示すトラフィック指示を送信するステップと、
を含む、方法。
【請求項15】
スケジューリングデバイスであって、送受信機と、
回路であって、
非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するように、前記送受信機を制御し、
前記第１のデータを含む前記送信から、前記ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得し、
前記第２のデータが、接続状態にある前記ＵＥによって送信されるデータであり、
前記トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、
前記ＬＣＩＤの前記事前定義値が、前記第２のデータが検出されたことを示す、
前記回路と、
を備える、スケジューリングデバイス。
【請求項16】
スケジューリングデバイスのための方法であって、前記方法が、以下のステップ、すなわち、非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するステップと、
前記第１のデータを含む前記送信から、前記ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得するステップであって、
前記第２のデータが、接続状態にある前記ＵＥによって送信されるデータであり、
前記トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、
前記ＬＣＩＤの前記事前定義値が、前記第２のデータが検出されたことを示す、
ステップと、
を含む、方法。
【請求項17】
ユーザ機器（ＵＥ）のプロセスを制御する集積回路であって、前記プロセスが、以下のステップ、すなわち、非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出するステップと、
待機するべき送信機会が存在するか否かを判定するステップであって、前記待機するべき送信機会が、
－ 前記第１のデータの少なくとも一部を送信するための送信機会であり、かつ、
－ 前記第１のデータを送信するための前記手順の一部として発生すると予期される、
ステップと、
前記待機するべき送信機会が存在しない、または前記待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始するステップと、
前記待機するべき送信機会が存在すると判定され、前記送信機会が発生したとき、前記送信機会を使用して、前記第２のデータの前記検出を示すトラフィック指示を送信するステップと、
を含む、
集積回路。
【請求項18】
スケジューリングデバイスのプロセスを制御する集積回路であって、前記プロセスが、以下のステップ、すなわち、非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するステップと、
前記第１のデータを含む前記送信から、前記ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得するステップであって、
前記第２のデータが、接続状態にある前記ＵＥによって送信されるデータであり、
前記トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、
前記ＬＣＩＤの前記事前定義値が、前記第２のデータが検出されたことを示す、
ステップと、
を含む、
集積回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信システムにおける信号の送信および受信に関する。特に、本開示は、そのような送信および受信のための方法および装置に関する。
【背景技術】
【0002】
第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標）：The 3rd Generation Partnership Project）は、最大１００ＧＨｚの周波数範囲で動作する「新無線」（ＮＲ：New Radio）無線アクセス技術（ＲＡＴ：radio access technology）を含む、第５世代（５Ｇ）とも呼ばれる次世代携帯電話技術の技術仕様を策定している。ＮＲは、ＬＴＥ（Long Term Evolution）およびＬＴＥ Ａｄｖａｎｃｅｄ（ＬＴＥ－Ａ）に代表される技術の後継技術である。
【0003】
ＬＴＥやＮＲなどのシステムでは、さらなる改良およびオプションによって、通信システムだけでなくシステムに関連する特定のデバイスの効率的な動作を促進することができる。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】3GPP TS 38.300 v15.6.0
【非特許文献2】3GPP TS 38.211 v15.6.0
【非特許文献3】3GPP TS 38.211, v 15.7.0
【非特許文献4】ITU-R M.2083
【非特許文献5】TR 38.913
【非特許文献6】TS 23.501 v16.1.0
【非特許文献7】TS 38.212 v15.6.0
【非特許文献8】3GPP TS 38.321 v15.8.0
【非特許文献9】TS 38.331 v15.8.0
【非特許文献10】3GPP TS 38.321, v16.1.0
【非特許文献11】3GPP TS 38.211 V16.2.0
【非特許文献12】TS 38.331 v16.1.0
【非特許文献13】TS 38.331, v15.12.0
【発明の概要】
【発明が解決しようとする課題】
【0005】
非限定的かつ例示的な一実施形態は、非アクティブ状態においてデータを送信するためのコンフィギュアドグラント（ＣＧ：configured grant）手順の間に、ＲＡ－ＳＤＴデータが到着した場合の効率的な処理を容易にする。
【課題を解決するための手段】
【0006】
一実施形態では、本明細書に開示される技術は、装置（例えばユーザ機器（ＵＥ））を特徴とする。本装置は、送受信機および回路を備える。回路は、非アクティブ状態において、第１の論理チャネルの第１のデータを送信するための手順中に、第２の論理チャネルの第２のデータが非アクティブ状態において送信されることを検出する。第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順である。第２の論理チャネルには、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。さらに、回路は、待機するべき送信機会が存在するか否かを判定し、待機するべき送信機会は、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。
【0007】
さらに、待機するべき送信機会が存在しない、または、待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する。さらに、待機するべき送信機会が存在すると判定され、かつその送信機会が発生したとき、回路は、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように、送受信機を制御する。
【0008】
なお、一般的または特定の実施形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、またはこれらの任意の選択的な組合せとして実施できることに留意されたい。
【0009】
開示されている実施形態のさらなる恩恵および利点は、本明細書および図面から明らかになるであろう。これらの恩恵および／または利点は、本明細書および図面の様々な実施形態および特徴によって個別に得ることができ、このような恩恵および／または利点の１つまたは複数を得るために、これらの特徴すべてを設ける必要はない。
【図面の簡単な説明】
【0010】
以下では、例示的な実施形態について、添付の図および図面を参照しながらより詳細に説明する。
【図1】３ＧＰＰ ＮＲシステムの例示的なアーキテクチャを示している。
【図2】ＮＧ－ＲＡＮと５ＧＣとの間の機能の分離を示した概略図である。
【図3】ＲＲＣ接続確立／再設定手順のシーケンス図である。
【図4】拡張モバイルブロードバンド（ｅＭＢＢ：Enhanced mobile broadband）、大規模マシンタイプ通信（ｍＭＴＣ：Massive Machine Type Communications）、および超高信頼・低遅延通信（ＵＲＬＬＣ：Ultra Reliable and Low Latency Communications）の使用シナリオを示した概略図である。
【図5】非ローミングの場合の例示的な５Ｇシステムのアーキテクチャを示したブロック図である。
【図6】競合ベースのＲＡＣＨ手順および競合なしのＲＡＣＨ手順を示している。
【図7】競合ベースのＲＡＣＨ手順および競合なしのＲＡＣＨ手順を示している。
【図8】可能なＲＲＣ状態の変化を示している。
【図9】ＲＲＣ再開（ＲＲＣ Ｒｅｓｕｍｅ）手順におけるメッセージ交換を示している。
【図10】ＲＲＣ解放（ＲＲＣ Ｒｅｌｅａｓｅ）手順におけるメッセージ交換を示している。
【図11】ＲＲＣ解放（ＲＲＣ Ｒｅｌｅａｓｅ）手順におけるメッセージ交換を示している。
【図12】非アクティブ状態から接続状態へのＵＥの状態変化を含む、アップリンクデータ送信のための先行技術のメッセージ交換を示している。
【図13】それぞれ、ＲＲＣ＿ＩＮＡＣＴＩＶＥ ＵＥがスモールデータをアップリンク送信するのに使用可能な例示的な４ステップＲＡＣＨおよび２ステップＲＡＣＨを示している。
【図14】それぞれ、ＲＲＣ＿ＩＮＡＣＴＩＶＥ ＵＥがスモールデータをアップリンク送信するのに使用可能な例示的な４ステップＲＡＣＨおよび２ステップＲＡＣＨを示している。
【図15】ＲＡＣＨ手順中にスモールデータの１回の送信を含む、例示的なＳＤＴ手順を示している。
【図16】ＲＡＣＨ手順中にスモールデータの複数回の送信を含む、例示的なＳＤＴ手順を示している。
【図17】ＲＡＣＨ手順中および終了後のスモールデータの送信を含む、例示的なＳＤＴ手順を示している。
【図18】ネットワークノードおよびユーザ機器の例示的な機能構造を示したブロック図である。
【図21】ユーザ機器によって実行される例示的なステップを示したフローチャートである。
【図22】ネットワークノードによって実行される例示的なステップを示したフローチャートである。
【図23】ＳＤＴ手順中に非ＳＤＴデータが到着する異なるタイミングを示している。
【図24】ユーザ機器によって実行される例示的なステップを示したフローチャートである。
【図25】非ＳＤＴ ＤＲＢの到着を示すサブヘッダを有しかつＣＥを有さないＭＡＣサブフレームを含む、Ｍｓｇ３メッセージの例示的な構造を示している。
【図26】非ＳＤＴ ＤＲＢの到着を示すサブヘッダと、ＳＤＴ ＤＲＢデータのバッファサイズを示すＣＥとを含むＭＡＣサブフレームを含む、Ｍｓｇ３メッセージの例示的な構造を示している。
【図27】論理チャネルグループのバッファサイズを示すためのＭＡＣ ＣＥの例示的な構造（上段）と、論理チャネルグループのバッファサイズを示し、かつ非ＳＤＴ ＤＲＢデータの到着を示すためのＭＡＣ ＣＥの例示的な構造（下段）を示している。
【図28】ネットワークノードおよびユーザ機器の例示的な機能構造を示したブロック図である。
【図31】ユーザ機器によって実行される例示的なステップを示したフローチャートである。
【図32】ネットワークノードによって実行される例示的なステップを示したフローチャートである。
【図33】ＵＥの例示的な論理チャネル設定を示している。
【図34】ＲＡ－ＳＤＴトラフィックの到着を示した概略図である。
【図35】ＲＡ－ＳＤＴトラフィックの到着の例示的な処理を示した概略図である。
【発明を実施するための形態】
【0011】
＜５Ｇ ＮＲシステムのアーキテクチャおよびプロトコルスタック＞
３ＧＰＰは、最大１００ＧＨｚの周波数で動作する新しい無線アクセス技術（ＮＲ）の開発を含む第５世代セルラー技術（単に５Ｇと呼ばれる）の次のリリースに取り組んでいる。５Ｇ標準の最初のバージョンは、２０１７年の終わりに完了し、これにより、５Ｇ ＮＲ標準に準拠したスマートフォンの試験および商用展開に進むことができる。
３ＧＰＰは、最大１００ＧＨｚの周波数で動作する新しい無線アクセス技術（ＮＲ）の開発を含む第５世代セルラー技術（単に５Ｇと呼ばれる）の次のリリースに取り組んでいる。５Ｇ標準の最初のバージョンは、２０１７年の終わりに完了し、これにより、５Ｇ ＮＲ標準に準拠したスマートフォンの試験および商用展開に進むことができる。
【0012】
特に、全体的なシステムアーキテクチャは、ｇＮＢを備えるＮＧ－ＲＡＮ（次世代－無線アクセスネットワーク：Next Generation - Radio Access Network）を想定しており、ｇＮＢは、ＵＥに向かうＮＧ無線アクセスユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ）プロトコルを終端させる。ｇＮＢは、Ｘｎインターフェイスによって互いに相互接続されている。さらにｇＮＢは、次世代（ＮＧ）インターフェイスによってＮＧＣ（次世代コア：Next Generation Core）に接続され、より具体的には、ＮＧ－ＣインターフェイスによってＡＭＦ（アクセスおよびモビリティ管理機能：Access and Mobility Management Function）（例：ＡＭＦを実行する特定のコアエンティティ）に接続され、ＮＧ－ＵインターフェイスによってＵＰＦ（ユーザプレーン機能：User Plane Function）（例：ＵＰＦを実行する特定のコアエンティティ）に接続される。図１はＮＧ－ＲＡＮのアーキテクチャを示している（例えば非特許文献１の４節を参照）。
【0013】
ＮＲにおけるユーザプレーンプロトコルスタック（例えば非特許文献１の４．４．１節を参照）は、ＰＤＣＰ（パケットデータコンバージェンスプロトコル：Packet Data Convergence Protocol、非特許文献１の６．４節を参照）サブレイヤ、ＲＬＣ（無線リンク制御：Radio Link Control、非特許文献１の６．３節を参照）サブレイヤ、およびＭＡＣ（媒体アクセス制御：Medium Access Control、非特許文献１の６．２節を参照）サブレイヤを含み、これらのサブレイヤは、ネットワーク側ではｇＮＢにおいて終端する。これに加えて、ＰＤＣＰの上に、アクセス層（ＡＳ）の新しいサブレイヤ（ＳＤＡＰ：サービスデータアダプテーションプロトコル：Service Data Adaptation Protocol）が導入される（例えば非特許文献１の６．５節を参照）。ＮＲにおいても制御プレーンプロトコルスタックが定義されている（例えば非特許文献１の４．４．２節を参照）。レイヤ２の機能の概要は、非特許文献１の６節に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、およびＭＡＣサブレイヤの機能は、それぞれ非特許文献１の６．４節、６．３節、および６．２節に記載されている。ＲＲＣ層の機能は、非特許文献１の７節に記載されている。
【0014】
媒体アクセス制御（ＭＡＣ）層は、例えば、論理チャネルの多重化と、スケジューリングおよびスケジューリング関連機能（様々なヌメロロジーの処理を含む）を扱う。
【0015】
物理層（ＰＨＹ）は、例えば、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、適切な物理的時間－周波数リソースへの信号のマッピングの責務を担う。さらに物理層（ＰＨＹ）は、物理チャネルへのトランスポートチャネルのマッピングを処理する。物理層（ＰＨＹ）は、トランスポートチャネルの形でＭＡＣ層にサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルが、対応する物理チャネルにマッピングされる。例えば、物理チャネルは、アップリンク用として、ＰＲＡＣＨ（物理ランダムアクセスチャネル：Physical Random Access Channel）、ＰＵＳＣＨ（物理アップリンク共有チャネル：Physical Uplink Shared Channel）、およびＰＵＣＣＨ（物理アップリンク制御チャネル：Physical Uplink Control Channel）があり、ダウンリンク用として、ＰＤＳＣＨ（物理ダウンリンク共有チャネル：Physical Downlink Shared Channel）、ＰＤＣＣＨ（物理ダウンリンク制御チャネル：Physical Downlink Control Channel）、およびＰＢＣＨ（物理ブロードキャストチャネル：Physical Broadcast Channel）がある。
【0016】
ＮＲのユースケース／配置シナリオには、拡張モバイルブロードバンド（ｅＭＢＢ）、超高信頼・低遅延通信（ＵＲＬＬＣ）、大規模マシンタイプ通信（ｍＭＴＣ）が含まれ、これらのサービスは、データレート、レイテンシ、およびカバレッジに関して多様な要件を有する。例えばｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄによって提供される３倍のオーダーのピークデータレート（ダウンリンクが２０Ｇｂｐｓ、アップリンクが１０Ｇｂｐｓ）およびユーザ体感データレートをサポートすることが期待される。これに対してＵＲＬＬＣの場合、より厳しい要件として、極めて低いレイテンシ（ユーザプレーンのレイテンシはアップリンクおよびダウンリンクそれぞれで０．５ｍｓ）および高い信頼性（１ｍｓ内で１～１０－５）が課せられる。さらにｍＭＴＣでは、高い接続密度（都市環境では１ｋｍ２あたり１，０００，０００個のデバイス）、過酷な環境における広いカバレッジ、デバイスコストを下げるための極めて長寿命のバッテリ（１５年）が好ましくは要求されうる。
【0017】
したがって、あるユースケースに適したＯＦＤＭヌメロロジー（例：サブキャリア間隔、ＯＦＤＭシンボル持続時間、サイクリックプレフィックス（ＣＰ）持続時間、スケジューリング間隔あたりのシンボル数）が、別のユースケースではうまく機能しないことがある。例えば、低レイテンシのサービスでは、ｍＭＴＣサービスよりも短いシンボル持続時間（したがってより大きいサブキャリア間隔）、および／または、スケジューリング間隔（ＴＴＩとも称される）あたりの少ないシンボル、が好ましくは要求されうる。さらには、チャネルの遅延スプレッドが大きい配置シナリオでは、遅延スプレッドが短いシナリオよりも長いサイクリックプレフィックス（ＣＰ）持続時間が好ましくは要求されうる。同程度のサイクリックプレフィックス（ＣＰ）オーバーヘッドを維持するため、遅延スプレッドに応じてサブキャリア間隔を最適化するべきである。ＮＲでは、サブキャリア間隔の２つ以上の値がサポートされうる。したがって現在のところ、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、．．．のサブキャリア間隔が検討されている。シンボル持続時間Ｔｕとサブキャリア間隔Δｆは、式Δｆ＝１／Ｔｕにより、直接関係している。ＬＴＥシステムの場合と同様に、１個のＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから構成される最小リソース単位を表すのに、用語「リソースエレメント」を使用することができる。
【0018】
新無線システム５Ｇ ＮＲでは、各ヌメロロジーおよびキャリアごとに、アップリンクおよびダウンリンクそれぞれにおいて、サブキャリアとＯＦＤＭシンボルのリソースグリッドが定義される。リソースグリッド内の各要素は、リソースエレメントと呼ばれ、周波数領域における周波数インデックスと時間領域におけるシンボル位置とに基づいて識別される（非特許文献２を参照）。例えば、ダウンリンクおよびアップリンクの送信は、持続時間１０ｍｓのフレームに編成され、各フレームは、それぞれ持続時間１ｍｓの１０個のサブフレームから構成される。５Ｇ ＮＲの実装では、サブフレームあたりの連続するＯＦＤＭシンボルの数は、サブキャリア間隔の設定に依存する。例えば、サブキャリア間隔が１５ｋＨｚの場合、１サブフレームは１４個のＯＦＤＭシンボルを有する（通常のサイクリックプレフィックスを想定したＬＴＥ準拠の実装に類似する）。一方、サブキャリア間隔が３０ｋＨｚの場合、サブフレームは２つのスロットを有し、各スロットが１４個のＯＦＤＭシンボルを含む。
【0019】
ＬＴＥのヌメロロジー（サブキャリア間隔およびシンボル長）と比較すると、ＮＲでは、パラメータμによってラベル付けされる複数の異なるタイプのサブキャリア間隔がサポートされる（ＬＴＥでは１５ｋＨｚのサブキャリア間隔のみが存在し、これはＮＲではμ＝０に相当する）。ＮＲのヌメロロジーのタイプは、非特許文献３にまとめられている。
【0020】
＜ＮＧ－ＲＡＮと５ＧＣとの間の５Ｇ ＮＲ機能の分割＞
図２は、ＮＧ－ＲＡＮと５ＧＣとの間での機能の分割を示している。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣの論理ノードは、ＡＭＦ、ＵＰＦ、およびＳＭＦである。
図２は、ＮＧ－ＲＡＮと５ＧＣとの間での機能の分割を示している。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣの論理ノードは、ＡＭＦ、ＵＰＦ、およびＳＭＦである。
【0021】
ｇＮＢおよびｎｇ－ｅＮＢは、特に次の主要機能を処理する。
－ 無線ベアラ制御（Radio Bearer Control）、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、アップリンクおよびダウンリンクの両方向におけるＵＥへの動的なリソース割当て（スケジューリング）など、無線リソース管理（Radio Resource Management）の機能
－ ＩＰヘッダ圧縮、暗号化、およびデータの完全性保護
－ ＵＥによって提供される情報からＡＭＦへのルーティングを決定できないときのＵＥのアタッチ時のＡＭＦの選択
－ ＵＰＦへのユーザプレーンデータのルーティング
－ ＡＭＦへの制御プレーン情報のルーティング
－ 接続の確立および解放
－ ページングメッセージのスケジューリングおよび送信
－ （ＡＭＦまたはＯＡＭから送られる）システムブロードキャスト情報のスケジューリングおよび送信
－ モビリティおよびスケジューリングのための測定および測定報告の設定
－ アップリンクにおけるトランスポートレベルのパケットマーキング
－ セッション管理
－ ネットワークスライシングのサポート
－ ＱｏＳフロー管理およびデータ無線ベアラへのマッピング
－ RRC_INACTIVE状態にあるＵＥのサポート
－ ＮＡＳメッセージの配信機能
－ 無線アクセスネットワークシェアリング
－ 二重接続
－ ＮＲとＥ－ＵＴＲＡ間の緊密なインターワーキング
－ 無線ベアラ制御（Radio Bearer Control）、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、アップリンクおよびダウンリンクの両方向におけるＵＥへの動的なリソース割当て（スケジューリング）など、無線リソース管理（Radio Resource Management）の機能
－ ＩＰヘッダ圧縮、暗号化、およびデータの完全性保護
－ ＵＥによって提供される情報からＡＭＦへのルーティングを決定できないときのＵＥのアタッチ時のＡＭＦの選択
－ ＵＰＦへのユーザプレーンデータのルーティング
－ ＡＭＦへの制御プレーン情報のルーティング
－ 接続の確立および解放
－ ページングメッセージのスケジューリングおよび送信
－ （ＡＭＦまたはＯＡＭから送られる）システムブロードキャスト情報のスケジューリングおよび送信
－ モビリティおよびスケジューリングのための測定および測定報告の設定
－ アップリンクにおけるトランスポートレベルのパケットマーキング
－ セッション管理
－ ネットワークスライシングのサポート
－ ＱｏＳフロー管理およびデータ無線ベアラへのマッピング
－ RRC_INACTIVE状態にあるＵＥのサポート
－ ＮＡＳメッセージの配信機能
－ 無線アクセスネットワークシェアリング
－ 二重接続
－ ＮＲとＥ－ＵＴＲＡ間の緊密なインターワーキング
【0022】
アクセスおよびモビリティ管理機能（ＡＭＦ）は、次の主要機能を処理する。
－ 非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
－ ＮＡＳシグナリングのセキュリティ
－ アクセス層（ＡＳ：Access Stratum）のセキュリティ制御
－ ３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
－ アイドルモードＵＥの到達可能性（ページング再送の制御および実行を含む）
－ レジストレーションエリア（Registration Area）管理
－ システム内モビリティおよびシステム間モビリティのサポート
－ アクセス認証
－ ローミング権のチェックを含むアクセス認証
－ モビリティ管理制御（サプスクリプションおよびポリシー）
－ ネットワークスライシングのサポート
－ セッション管理機能（ＳＭＦ：Session Management Function）の選択
－ 非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
－ ＮＡＳシグナリングのセキュリティ
－ アクセス層（ＡＳ：Access Stratum）のセキュリティ制御
－ ３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
－ アイドルモードＵＥの到達可能性（ページング再送の制御および実行を含む）
－ レジストレーションエリア（Registration Area）管理
－ システム内モビリティおよびシステム間モビリティのサポート
－ アクセス認証
－ ローミング権のチェックを含むアクセス認証
－ モビリティ管理制御（サプスクリプションおよびポリシー）
－ ネットワークスライシングのサポート
－ セッション管理機能（ＳＭＦ：Session Management Function）の選択
【0023】
さらに、ユーザプレーン機能（ＵＰＦ：User Plane Function）は、次の主要機能を処理する。
－ ＲＡＴ内／ＲＡＴ間モビリティのためのアンカーポイント（適用可能時）
－ データネットワークとの相互接続の外部ＰＤＵセッションポイント
－ パケットのルーティングおよび転送
－ パケット検査およびポリシー規則施行のユーザプレーン部分
－ トラフィック使用報告
－ データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類器
－ マルチホームＰＤＵセッションをサポートするためのブランチングポイント
－ ユーザプレーンのＱｏＳ処理（例：パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート強制）
－ アップリンクトラフィックの検証（ＳＤＦからＱｏＳフローへのマッピング）
－ ダウンリンクパケットのバッファリングおよびダウンリンクデータ通知のトリガーリング
－ ＲＡＴ内／ＲＡＴ間モビリティのためのアンカーポイント（適用可能時）
－ データネットワークとの相互接続の外部ＰＤＵセッションポイント
－ パケットのルーティングおよび転送
－ パケット検査およびポリシー規則施行のユーザプレーン部分
－ トラフィック使用報告
－ データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類器
－ マルチホームＰＤＵセッションをサポートするためのブランチングポイント
－ ユーザプレーンのＱｏＳ処理（例：パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート強制）
－ アップリンクトラフィックの検証（ＳＤＦからＱｏＳフローへのマッピング）
－ ダウンリンクパケットのバッファリングおよびダウンリンクデータ通知のトリガーリング
【0024】
最後に、セッション管理機能（ＳＭＦ）は、次の主要機能を処理する。
－ セッション管理
－ ＵＥ ＩＰアドレスの割当ておよび管理
－ ＵＰ機能の選択および制御
－ トラフィックを正しい宛先にルーティングするためのユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
－ ポリシー施行およびＱｏＳの制御部分
－ ダウンリンクデータ通知
－ セッション管理
－ ＵＥ ＩＰアドレスの割当ておよび管理
－ ＵＰ機能の選択および制御
－ トラフィックを正しい宛先にルーティングするためのユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
－ ポリシー施行およびＱｏＳの制御部分
－ ダウンリンクデータ通知
【0025】
＜ＲＲＣ接続の確立および再構成の手順＞
図３は、ＵＥがＮＡＳ部分においてＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに遷移するときの、ＵＥ、ｇＮＢ、およびＡＭＦ（５ＧＣエンティティ）の間のいくつかのインタラクションを示している（非特許文献１を参照）。
図３は、ＵＥがＮＡＳ部分においてＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに遷移するときの、ＵＥ、ｇＮＢ、およびＡＭＦ（５ＧＣエンティティ）の間のいくつかのインタラクションを示している（非特許文献１を参照）。
【0026】
ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位層シグナリング（プロトコル）である。特に、この遷移では、ＡＭＦがＵＥのコンテキストデータ（例：ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線能力、ＵＥセキュリティ能力などを含む）を作成し、それを初期コンテキスト設定要求（ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）によってｇＮＢに送る。次にｇＮＢが、ＵＥとのＡＳセキュリティをアクティブにし、これはｇＮＢがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄメッセージをＵＥに送信し、ＵＥがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅメッセージでｇＮＢに応答することによって実行される。その後ｇＮＢは、再設定を実行してシグナリング無線ベアラ２（ＳＲＢ２）およびデータ無線ベアラ（ＤＲＢ：Data Radio Bearer）を確立し、これは、ｇＮＢがＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥに送信し、これに応答してＵＥからのＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅをｇＮＢが受信することによる。シグナリングのみの接続の場合、ＳＲＢ２およびＤＲＢが確立されないため、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎに関連するこれらのステップはスキップされる。最後にｇＮＢは、確立手順が完了したことを、初期コンテキスト設定応答（ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥ）によってＡＭＦに通知する。
【0027】
したがって本開示では、第５世代コア（５ＧＣ：5th Generation Core）のエンティティ（例えばＡＭＦ、ＳＭＦなど）であって、動作時に、ｇＮｏｄｅＢとの次世代（ＮＧ）接続を確立する制御回路と、動作時に、ｇＮｏｄｅＢとユーザ機器（ＵＥ）との間のシグナリング無線ベアラを確立させるために、ＮＧ接続を介して初期コンテキスト設定メッセージをｇＮｏｄｅＢに送信する送信器と、を備える、第５世代コアのエンティティ、が提供される。具体的には、ｇＮｏｄｅＢは、リソース割当て設定の情報要素を含むＲＲＣ（無線リソース制御：Radio Resource Control）シグナリングを、シグナリング無線ベアラを介してＵＥに送信する。ＵＥは、リソース割当て設定に基づいて、アップリンク送信またはダウンリンク受信を実行する。
【0028】
＜２０２０年以降のＩＭＴの使用シナリオ＞
図４は、５Ｇ ＮＲのユースケースのいくつかを示している。３ＧＰＰ（第３世代パートナーシッププロジェクト）の新無線（３ＧＰＰ ＮＲ）では、ＩＭＴ－２０２０による様々なサービスおよびアプリケーションをサポートするために想定される３つのユースケースが考慮されている。拡張モバイルブロードバンド（ｅＭＢＢ）のフェーズ１の仕様は決定された。現在および今後の作業としては、ｅＭＢＢのサポートをさらに拡張することに加えて、超高信頼・低遅延通信（ＵＲＬＬＣ）および大規模マシンタイプ通信の標準化が含まれる。図４は、２０２０年以降のＩＭＴの想定される使用シナリオのいくつかの例を示している（例えば非特許文献４の図２を参照）。
図４は、５Ｇ ＮＲのユースケースのいくつかを示している。３ＧＰＰ（第３世代パートナーシッププロジェクト）の新無線（３ＧＰＰ ＮＲ）では、ＩＭＴ－２０２０による様々なサービスおよびアプリケーションをサポートするために想定される３つのユースケースが考慮されている。拡張モバイルブロードバンド（ｅＭＢＢ）のフェーズ１の仕様は決定された。現在および今後の作業としては、ｅＭＢＢのサポートをさらに拡張することに加えて、超高信頼・低遅延通信（ＵＲＬＬＣ）および大規模マシンタイプ通信の標準化が含まれる。図４は、２０２０年以降のＩＭＴの想定される使用シナリオのいくつかの例を示している（例えば非特許文献４の図２を参照）。
【0029】
ＵＲＬＬＣのユースケースは、スループット、レイテンシ、可用性などの能力に関する厳しい要件を有し、産業製造や生産工程のワイヤレス制御、リモート医療手術、スマートグリッドにおける配電自動化、輸送の安全性など、将来の垂直アプリケーションを実現する手段の１つとして想定されている。ＵＲＬＬＣの超高信頼性は、非特許文献５によって設定される要件を満たすための技術を特定することによってサポートされる。リリース１５のＮＲ ＵＲＬＬＣでは、主な要件として、ＵＬ（アップリンク）で０．５ｍｓ、ＤＬ（ダウンリンク）で０．５ｍｓの目標ユーザプレーンレイテンシが含まれる。パケットの１回の送信における一般的なＵＲＬＬＣの要件は、１ｍｓのユーザプレーンレイテンシでパケットサイズ３２バイトの場合にＢＬＥＲ（ブロック誤り率）１Ｅ－５である。
【0030】
物理層の観点から、信頼性を向上させる方法はいくつか考えられる。信頼性を向上させるための現在の範囲には、ＵＲＬＬＣ用の個別のＣＱＩテーブルの定義、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返しなどが含まれる。しかしながら、（ＮＲ ＵＲＬＬＣの重要な要件について）ＮＲがさらに安定し、開発が進むにつれて、超高信頼性を実現するための範囲が広がりうる。リリース１５におけるＮＲ ＵＲＬＬＣの具体的なユースケースとしては、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅヘルス、ｅセーフティ、ミッションクリティカルなアプリケーションが挙げられる。
【0031】
さらに、ＮＲ ＵＲＬＬＣが対象とする技術強化は、レイテンシの改良および信頼性の向上を目標としている。レイテンシを改良するための技術強化としては、設定可能なヌメロロジー、柔軟なマッピングを使用する非スロットベースのスケジューリング、グラントフリー（コンフィギュアドグラント（configured grant））のアップリンク、データチャネルのスロットレベルの繰り返し、およびダウンリンクのプリエンプションが挙げられる。プリエンプションとは、リソースがすでに割り当てられている送信が中止され、すでに割り当てられているリソースが、後から要求された、より小さいレイテンシ／より高い優先度要件を有する別の送信に使用されることを意味する。したがって、すでに許可された送信が、より後の送信によってプリエンプトされる。プリエンプションは、サービスタイプに関係なく適用される。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信を、サービスタイプＢ（ｅＭＢＢなど）の送信によってプリエンプトすることができる。信頼性の向上に関連する技術強化としては、１Ｅ－５の目標ＢＬＥＲのための専用ＣＱＩ／ＭＣＳテーブルが挙げられる。
【0032】
ｍＭＴＣ（大規模マシンタイプ通信）のユースケースは、非常に多数の接続されたデバイスが、一般には遅延の影響が小さい比較的少量のデータを送信することを特徴とする。デバイスは、低コストでありかつ極めて長いバッテリ寿命を有することが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することは、ＵＥの観点からの省電力を達成して長いバッテリ寿命を可能にするための１つの可能な解決策である。
【0033】
上に述べたように、ＮＲにおける信頼性の範囲が広がることが予測される。あらゆるケース、特にＵＲＬＬＣおよびｍＭＴＣの場合に必要な１つの重要な要件は、高信頼性または超高信頼性である。無線の観点およびネットワークの観点から、信頼性を向上させるためのいくつかのメカニズムを考えることができる。一般には、信頼性の向上に役立つ可能性のある重要な領域がいくつか存在する。これらの領域としては、コンパクトな制御チャネル情報、データチャネル／制御チャネルの繰り返し、周波数領域、時間領域、および／または空間領域に関連するダイバーシティが挙げられる。これらの領域は、特定の通信シナリオには関係なく、一般的に信頼性に適用可能である。
【0034】
ＮＲ ＵＲＬＬＣの場合、ファクトリーオートメーション、運輸業、配電など、より厳しい要件のさらなるユースケースが特定されている。より厳しい要件とは、ユースケースに応じて、より高い信頼性（最大１０－６レベル）、より高い可用性、最大２５６バイトのパケットサイズ、数μｓオーダーまでの時刻同期（値は周波数範囲に応じて１μｓないし数μｓ）、０．５～１ｍｓオーダーの短いレイテンシ、特に０．５ｍｓの目標ユーザプレーンレイテンシである。
【0035】
さらに、ＮＲ ＵＲＬＬＣの場合、物理層の観点からいくつかの技術的強化が確認されている。特に、ＰＤＣＣＨ（物理ダウンリンク制御チャネル）に関連する強化として、コンパクトなＤＣＩ、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨ監視の増加などが挙げられる。また、ＵＣＩ（アップリンク制御情報：Uplink Control Information）に関連する強化として、ＨＡＲＱ（ハイブリッド自動再送要求）の強化およびＣＳＩフィードバックの強化が挙げられる。また、ミニスロットレベルのホッピングや再送／繰り返しの強化に関連するＰＵＳＣＨの強化も認識されている。用語「ミニスロット」は、スロットよりも少ない数のシンボルを含むＴＴＩ（送信時間間隔：Transmission Time Interval）を意味する（スロットは１４個のシンボルを含む）。
【0036】
＜ＱｏＳ制御＞
５Ｇ ＱｏＳ（サービス品質）モデルは、ＱｏＳフローに基づいており、保証フロービットレートを必要とするＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証フロービットレートを必要としないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方をサポートする。したがってＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおけるＱｏＳ差別化の最も細かい粒度である。ＱｏＳフローは、ＰＤＵセッション内では、ＮＧ－Ｕインターフェイスを通じてカプセル化ヘッダ内で伝えられるＱｏＳフローＩＤ（ＱＦＩ）によって識別される。
５Ｇ ＱｏＳ（サービス品質）モデルは、ＱｏＳフローに基づいており、保証フロービットレートを必要とするＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証フロービットレートを必要としないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方をサポートする。したがってＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおけるＱｏＳ差別化の最も細かい粒度である。ＱｏＳフローは、ＰＤＵセッション内では、ＮＧ－Ｕインターフェイスを通じてカプセル化ヘッダ内で伝えられるＱｏＳフローＩＤ（ＱＦＩ）によって識別される。
【0037】
５ＧＣは、ＵＥごとに１つ以上のＰＤＵセッションを確立する。ＮＧ－ＲＡＮは、ＵＥごとに、ＰＤＵセッションと一緒に少なくとも１つのデータ無線ベアラ（ＤＲＢ）を確立し、次にそのＰＤＵセッションのＱｏＳフローのための追加のＤＲＢを、例えば図３を参照しながら上述したように設定することができる（いつ設定するかはＮＧ－ＲＡＮが決定する）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルのパケットフィルタによって、ＵＬおよびＤＬのパケットがＱｏＳフローに関連付けられ、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルのマッピング規則によって、ＵＬおよびＤＬのＱｏＳフローがＤＲＢに関連付けられる。
【0038】
図５は、５Ｇ ＮＲの非ローミング基準アーキテクチャを示している（非特許文献６の４．２３節を参照）。アプリケーション機能（ＡＦ：Application Function）（例えば図４に例示的に記載されている５Ｇサービスを処理する外部アプリケーションサーバ）は、サービスを提供する目的で、３ＧＰＰコアネットワークと対話する。例えば、トラフィックのルーティングに対するアプリケーションの影響をサポートしたり、ネットワーク公開機能（ＮＥＦ：Network Exposure Function）にアクセスしたり、ポリシー制御（例：ＱｏＳ制御）のためのポリシーフレームワーク（ポリシー制御機能（ＰＣＦ）を参照）と対話する。事業者の配備に基づいて、事業者によって信頼されるものとみなされるアプリケーション機能（ＡＦ）を、関連するネットワーク機能（Network Function）と直接対話できるようにすることができる。ネットワーク機能に直接アクセスすることが事業者によって許可されていないアプリケーション機能（ＡＦ）は、ＮＥＦを介して外部の公開フレームワークを使用して、関連するネットワーク機能と対話する。
【0039】
図５は、５Ｇアーキテクチャのさらなる機能ユニット、すなわち、ネットワークスライス選択機能（ＮＳＳＦ：Network Slice Selection Function）、ネットワークリポジトリ機能（ＮＲＦ：Network Repository Function）、統一データ管理（ＵＤＭ：Unified Data Management）、認証サーバ機能（ＡＵＳＦ：Authentication Server Function）、アクセスおよびモビリティ管理機能（ＡＭＦ：Access and Mobility Management Function）、セッション管理機能（ＳＭＦ：Session Management Function）、およびデータネットワーク（ＤＮ：Data Network）（例：事業者のサービス、インターネットアクセス、またはサードパーティのサービス）を示している。コアネットワーク機能およびアプリケーションサービスのすべてまたは一部を、クラウドコンピューティング環境に配置して実行してもよい。
【0040】
したがって本開示では、アプリケーションサーバ（例えば５ＧアーキテクチャのＡＦ）が提供され、このアプリケーションサーバは、動作時に、ＵＲＬＬＣサービス、ｅＭＢＢサービス、およびｍＭＴＣサービスの少なくとも１つに対するＱｏＳ要件を含む要求を５ＧＣの機能（例えばＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦなど）の少なくとも１つに送信して、ＱｏＳ要件に従ってｇＮｏｄｅＢとＵＥとの間に無線ベアラを含むＰＤＵセッションを確立する送信機と、動作時に、確立されたＰＤＵセッションを使用してサービスを実行する制御回路と、を備える。
【0041】
＜制御信号＞
本開示では、本開示に関連するダウンリンク制御信号（情報）は、物理層のＰＤＣＣＨを介して送信される信号（情報）とすることができる、または、上位層のＭＡＣ制御要素（ＣＥ）またはＲＲＣを介して送信される信号（情報）とすることができる。ダウンリンク制御信号は、事前定義される信号（情報）とすることができる。
本開示では、本開示に関連するダウンリンク制御信号（情報）は、物理層のＰＤＣＣＨを介して送信される信号（情報）とすることができる、または、上位層のＭＡＣ制御要素（ＣＥ）またはＲＲＣを介して送信される信号（情報）とすることができる。ダウンリンク制御信号は、事前定義される信号（情報）とすることができる。
【0042】
本開示に関連するアップリンク制御信号（情報）は、物理層のＰＵＣＣＨを介して送信される信号（情報）とすることができる、または、上位層のＭＡＣ ＣＥもしくはＲＲＣを介して送信される信号（情報）とすることができる。さらに、アップリンク制御信号は、事前定義される信号（情報）とすることができる。アップリンク制御信号は、アップリンク制御情報（ＵＣＩ）、第１段サイドリンク制御情報（ＳＣＩ）（1st stage sildelink control information (SCI)）、または第２段ＳＣＩ（2nd stage SCI）に置き換えることができる。
【0043】
＜端末＞
端末またはユーザ端末またはユーザデバイスまたは移動局または移動ノードは、ＬＴＥおよびＮＲではユーザ機器（ＵＥ：user equipment）と呼ばれる。ユーザ機器（ＵＥ）は、無線電話、スマートフォン、タブレットコンピュータ、またはユーザ機器の機能を備えたＵＳＢ（ユニバーサルシリアルバス）スティックなど、モバイルデバイスまたは通信装置であってもよい。ただし、モバイルデバイスという用語はこれに限定されるものではなく、一般に、中継機もこのようなモバイルデバイスの機能を有することがあり、モバイルデバイスが中継機として機能することもある。例えば、端末は、通信ネットワーク内の物理的なエンティティ（物理ノード）である。さらに、通信デバイスは、ＩｏＴデバイス等のような任意のマシンタイプの通信デバイスであってもよい。１つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、所定の機能セットを実装する、および／または、所定の機能セットを同じノードもしくは別のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、自身を通信設備または通信媒体にアタッチする１つ以上のインターフェイスを有することができ、ノードは、これら通信設備または通信媒体を通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信設備または通信媒体にアタッチする論理インターフェイスを有することができ、機能エンティティは、これら通信設備または通信媒体を通じて別の機能エンティティまたは対応するノードと通信することができる。
端末またはユーザ端末またはユーザデバイスまたは移動局または移動ノードは、ＬＴＥおよびＮＲではユーザ機器（ＵＥ：user equipment）と呼ばれる。ユーザ機器（ＵＥ）は、無線電話、スマートフォン、タブレットコンピュータ、またはユーザ機器の機能を備えたＵＳＢ（ユニバーサルシリアルバス）スティックなど、モバイルデバイスまたは通信装置であってもよい。ただし、モバイルデバイスという用語はこれに限定されるものではなく、一般に、中継機もこのようなモバイルデバイスの機能を有することがあり、モバイルデバイスが中継機として機能することもある。例えば、端末は、通信ネットワーク内の物理的なエンティティ（物理ノード）である。さらに、通信デバイスは、ＩｏＴデバイス等のような任意のマシンタイプの通信デバイスであってもよい。１つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、所定の機能セットを実装する、および／または、所定の機能セットを同じノードもしくは別のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、自身を通信設備または通信媒体にアタッチする１つ以上のインターフェイスを有することができ、ノードは、これら通信設備または通信媒体を通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信設備または通信媒体にアタッチする論理インターフェイスを有することができ、機能エンティティは、これら通信設備または通信媒体を通じて別の機能エンティティまたは対応するノードと通信することができる。
【0044】
＜基地局＞
本開示において、基地局は、例えば、送受信点（ＴＲＰ：Transmission Reception Point）、クラスタヘッド、アクセスポイント、遠隔無線ヘッド（ＲＲＨ：Remote Radio Head）、ｅＮｏｄｅＢ（ｅＮＢ）、ｇＮｏｄｅＢ（ｇＮＢ）、基地局（ＢＳ）、ベース送受信機ステーション（ＢＴＳ：Base Transceiver Station）、ベースユニット、またはゲートウェイとすることができる。さらに、サイドリンク通信では、基地局の代わりに端末を採用することができる。基地局は、上位ノードと端末との間の通信を中継する中継装置であってもよい。基地局は、路側機（roadside unit）であってもよい。基地局は、例えば、端末にサービスを提供するためのネットワークの一部を形成するスケジューリングノードまたはネットワークノードであってもよい。特に、基地局は端末に無線アクセスを提供することができる。端末と基地局との間の通信は一般的に標準化されており、ＰＨＹ、ＭＡＣ、ＲＲＣなどの異なる層によって定義することができる。ＬＴＥおよびＮＲでは、無線インターフェイスプロトコルスタックには、物理層、媒体アクセス層（ＭＡＣ）、および上位層が含まれる。制御プレーンには、上位層プロトコルである無線リソース制御プロトコルが提供される。ＲＲＣを介して、基地局は端末の設定を制御することができ、端末は基地局と通信して、接続およびベアラの確立、変更などの制御タスク、測定、その他の機能を実行することができる。ＬＴＥで使用される専門用語はｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている専門用語はｇＮＢである。ここでの基地局または無線基地局という用語は、通信ネットワーク内の物理的なエンティティを指す。移動局と同様に、基地局はいくつかの機能エンティティを有することができる。機能エンティティとは、所定の機能セットを実装する、および／または、所定の機能セットを同じノードもしくは別のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。物理エンティティは、スケジューリングおよび設定の１つ以上を含む、通信デバイスに関するいくつかの制御タスクを実行する。なお基地局の機能と通信デバイスの機能は、単一のデバイス内に統合されてもよいことに留意されたい。例えば、移動端末が、他の端末のために基地局の機能も実施することができる。ＬＴＥで使用される専門用語はｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている専門用語はｇＮＢである。
本開示において、基地局は、例えば、送受信点（ＴＲＰ：Transmission Reception Point）、クラスタヘッド、アクセスポイント、遠隔無線ヘッド（ＲＲＨ：Remote Radio Head）、ｅＮｏｄｅＢ（ｅＮＢ）、ｇＮｏｄｅＢ（ｇＮＢ）、基地局（ＢＳ）、ベース送受信機ステーション（ＢＴＳ：Base Transceiver Station）、ベースユニット、またはゲートウェイとすることができる。さらに、サイドリンク通信では、基地局の代わりに端末を採用することができる。基地局は、上位ノードと端末との間の通信を中継する中継装置であってもよい。基地局は、路側機（roadside unit）であってもよい。基地局は、例えば、端末にサービスを提供するためのネットワークの一部を形成するスケジューリングノードまたはネットワークノードであってもよい。特に、基地局は端末に無線アクセスを提供することができる。端末と基地局との間の通信は一般的に標準化されており、ＰＨＹ、ＭＡＣ、ＲＲＣなどの異なる層によって定義することができる。ＬＴＥおよびＮＲでは、無線インターフェイスプロトコルスタックには、物理層、媒体アクセス層（ＭＡＣ）、および上位層が含まれる。制御プレーンには、上位層プロトコルである無線リソース制御プロトコルが提供される。ＲＲＣを介して、基地局は端末の設定を制御することができ、端末は基地局と通信して、接続およびベアラの確立、変更などの制御タスク、測定、その他の機能を実行することができる。ＬＴＥで使用される専門用語はｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている専門用語はｇＮＢである。ここでの基地局または無線基地局という用語は、通信ネットワーク内の物理的なエンティティを指す。移動局と同様に、基地局はいくつかの機能エンティティを有することができる。機能エンティティとは、所定の機能セットを実装する、および／または、所定の機能セットを同じノードもしくは別のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。物理エンティティは、スケジューリングおよび設定の１つ以上を含む、通信デバイスに関するいくつかの制御タスクを実行する。なお基地局の機能と通信デバイスの機能は、単一のデバイス内に統合されてもよいことに留意されたい。例えば、移動端末が、他の端末のために基地局の機能も実施することができる。ＬＴＥで使用される専門用語はｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている専門用語はｇＮＢである。
【0045】
＜アップリンク／ダウンリンク／サイドリンク＞
本開示は、アップリンク、ダウンリンク、およびサイドリンクのいずれにも適用することができる。
本開示は、アップリンク、ダウンリンク、およびサイドリンクのいずれにも適用することができる。
【0046】
本開示は、例えば、ＰＵＳＣＨ、ＰＵＣＣＨ、およびＰＲＡＣＨなどのアップリンクチャネル、ＰＤＳＣＨ、ＰＤＣＣＨ、およびＰＢＣＨなどのダウンリンクチャネル、ならびに物理サイドリンク共有チャネル（ＰＳＳＣＨ：Physical Sidelink Shared Channel）、物理サイドリンク制御チャネル（ＰＳＣＣＨ：Physical Sidelink Control Channel）、および物理サイドリンクブロードキャストチャネル（ＰＳＢＣＨ：Physical Sidelink Broadcast Channel）などのサイドリンクチャネルに適用することができる。
【0047】
ＰＤＣＣＨ、ＰＤＳＣＨ、ＰＵＳＣＨ、ＰＵＣＣＨは、それぞれ、ダウンリンク制御チャネル、ダウンリンクデータチャネル、アップリンクデータチャネル、アップリンク制御チャネルの一例である。ＰＳＣＣＨおよびＰＳＳＣＨは、それぞれ、サイドリンク制御チャネルおよびサイドリンクデータチャネルの一例である。ＰＢＣＨおよびＰＳＢＣＨは、それぞれブロードキャストチャネルの一例であり、ＰＲＡＣＨは、ランダムアクセスチャネルの一例である。
【0048】
＜データチャネル／制御チャネル＞
本開示は、データチャネルおよび制御チャネルのいずれにも適用することができる。本開示におけるチャネルは、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＳＳＣＨを含むデータチャネル、および／または、ＰＤＣＣＨ、ＰＵＣＣＨ、ＰＢＣＨ、ＰＳＣＣＨ、およびＰＳＢＣＨを含む制御チャネルに置き換えることができる。
本開示は、データチャネルおよび制御チャネルのいずれにも適用することができる。本開示におけるチャネルは、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＳＳＣＨを含むデータチャネル、および／または、ＰＤＣＣＨ、ＰＵＣＣＨ、ＰＢＣＨ、ＰＳＣＣＨ、およびＰＳＢＣＨを含む制御チャネルに置き換えることができる。
【0049】
＜参照信号＞
本開示において、参照信号は、基地局および移動局の両方に既知である信号であり、各参照信号は、基準信号（ＲＳ）または場合によりパイロット信号と呼ばれることがある。参照信号は、ＤＭＲＳ、チャネル状態情報－参照信号（ＣＳＩ－ＲＳ：Channel State Information - Reference Signal）、追跡参照信号（ＴＲＳ：Tracking Reference Signal）、位相追跡参照信号（ＰＴＲＳ：Phase Tracking Reference Signal）、セル固有参照信号（ＣＲＳ：Cell-specific Reference Signal）、およびサウンディング参照信号（ＳＲＳ：Sounding Reference Signal）のいずれであってもよい。
本開示において、参照信号は、基地局および移動局の両方に既知である信号であり、各参照信号は、基準信号（ＲＳ）または場合によりパイロット信号と呼ばれることがある。参照信号は、ＤＭＲＳ、チャネル状態情報－参照信号（ＣＳＩ－ＲＳ：Channel State Information - Reference Signal）、追跡参照信号（ＴＲＳ：Tracking Reference Signal）、位相追跡参照信号（ＰＴＲＳ：Phase Tracking Reference Signal）、セル固有参照信号（ＣＲＳ：Cell-specific Reference Signal）、およびサウンディング参照信号（ＳＲＳ：Sounding Reference Signal）のいずれであってもよい。
【0050】
＜時間間隔＞
本開示において、時間リソースの単位は、スロットおよびシンボルの一方または組合せに限定されず、フレーム、スーパーフレーム、サブフレーム、スロット、時間スロットサブスロット、ミニスロットなどの時間リソース単位、または、シンボル、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）シンボル、シングルキャリア－周波数分割多重アクセス（ＳＣ－ＦＤＭＡ：Single Carrier-Frequency Division Multiplexing Access）シンボルなどの時間リソース単位、または他の時間リソース単位であってもよい。１スロットに含まれるシンボルの数は、上述した実施形態において例示した数に限定されず、別のシンボル数であってもよい。
本開示において、時間リソースの単位は、スロットおよびシンボルの一方または組合せに限定されず、フレーム、スーパーフレーム、サブフレーム、スロット、時間スロットサブスロット、ミニスロットなどの時間リソース単位、または、シンボル、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）シンボル、シングルキャリア－周波数分割多重アクセス（ＳＣ－ＦＤＭＡ：Single Carrier-Frequency Division Multiplexing Access）シンボルなどの時間リソース単位、または他の時間リソース単位であってもよい。１スロットに含まれるシンボルの数は、上述した実施形態において例示した数に限定されず、別のシンボル数であってもよい。
【0051】
＜周波数帯域＞
本開示は、ライセンスバンドおよびアンライセンスバンドのいずれにも適用することができる。
本開示は、ライセンスバンドおよびアンライセンスバンドのいずれにも適用することができる。
【0052】
＜通信＞
本開示は、基地局と端末との間の通信（Ｕｕリンク通信）、端末と端末の間の通信（サイドリンク通信）、および、車両と何らかのエンティティとの通信（Ｖ２Ｘ：Vehicle to Everything）のいずれにも適用することができる。本開示におけるチャネルは、ＰＳＣＣＨ、ＰＳＳＣＨ、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ：Physical Sidelink Feedback Channel）、ＰＳＢＣＨ、ＰＤＣＣＨ、ＰＵＣＣＨ、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＢＣＨに置き換えることができる。
本開示は、基地局と端末との間の通信（Ｕｕリンク通信）、端末と端末の間の通信（サイドリンク通信）、および、車両と何らかのエンティティとの通信（Ｖ２Ｘ：Vehicle to Everything）のいずれにも適用することができる。本開示におけるチャネルは、ＰＳＣＣＨ、ＰＳＳＣＨ、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ：Physical Sidelink Feedback Channel）、ＰＳＢＣＨ、ＰＤＣＣＨ、ＰＵＣＣＨ、ＰＤＳＣＨ、ＰＵＳＣＨ、およびＰＢＣＨに置き換えることができる。
【0053】
さらに、本開示は、地上ネットワーク、または、衛星もしくは高高度疑似衛星（ＨＡＰＳ：High Altitude Pseudo Satellite）を使用する地上ネットワーク以外のネットワーク（ＮＴＮ：非地上系ネットワーク：Non-Terrestrial Network）のいずれにも適用することができる。さらに、本開示は、大きいセルサイズを有するネットワーク、または超広帯域伝送ネットワークのようにシンボル長やスロット長に比べて遅延が大きい地上ネットワークに適用してもよい。
【0054】
＜アンテナポート＞
アンテナポートとは、１つ以上の物理アンテナから形成される論理アンテナ（アンテナ群）のことを指す。すなわち、アンテナポートは、必ずしも１つの物理アンテナを指すものではなく、複数のアンテナから形成されるアレイアンテナ等を指す場合もある。例えば、アンテナポートを形成する物理アンテナの数は定義されておらず、代わりに、端末が参照信号を送信することのできる最小単位をアンテナポートと定義する。また、アンテナポートは、プリコーディングベクトル重み付けの乗算のための最小単位として定義されることもある。
アンテナポートとは、１つ以上の物理アンテナから形成される論理アンテナ（アンテナ群）のことを指す。すなわち、アンテナポートは、必ずしも１つの物理アンテナを指すものではなく、複数のアンテナから形成されるアレイアンテナ等を指す場合もある。例えば、アンテナポートを形成する物理アンテナの数は定義されておらず、代わりに、端末が参照信号を送信することのできる最小単位をアンテナポートと定義する。また、アンテナポートは、プリコーディングベクトル重み付けの乗算のための最小単位として定義されることもある。
【0055】
＜ダウンリンク制御チャネルの監視、ＰＤＣＣＨ、ＤＣＩ＞
ＵＥによって動作する機能の多くは、例えばＵＥ宛の特定の制御情報またはデータを受信するためにダウンリンク制御チャネル（例えばＰＤＣＣＨ、非特許文献１の５．２．３節を参照）を監視することを含む。
ＵＥによって動作する機能の多くは、例えばＵＥ宛の特定の制御情報またはデータを受信するためにダウンリンク制御チャネル（例えばＰＤＣＣＨ、非特許文献１の５．２．３節を参照）を監視することを含む。
【0056】
以下は、このような機能のリスト（すべてを網羅していない）を示す。
－ ページングメッセージ監視機能、
－ システム情報取得機能、
－ 不連続受信（ＤＲＸ）機能におけるシグナリング監視動作、
－ 不連続受信（ＤＲＸ）機能における非アクティブ性（inactivity）監視動作、
－ ランダムアクセス機能におけるランダムアクセス応答の受信、
－ パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤのリオーダリング機能
－ ページングメッセージ監視機能、
－ システム情報取得機能、
－ 不連続受信（ＤＲＸ）機能におけるシグナリング監視動作、
－ 不連続受信（ＤＲＸ）機能における非アクティブ性（inactivity）監視動作、
－ ランダムアクセス機能におけるランダムアクセス応答の受信、
－ パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤのリオーダリング機能
【0057】
上述したように、ＰＤＣＣＨの監視は、制御情報およびユーザトラフィック（例えばＰＤＣＣＨ上のＤＣＩ、ＰＤＣＣＨによって示されるＰＤＳＣＨ上のユーザデータ）など、ＵＥを対象とする情報を識別して受信するために、ＵＥによって行われる。
【0058】
ダウンリンクにおける制御情報（ダウンリンク制御情報、ＤＣＩと呼ぶことができる）は、５Ｇ ＮＲではＬＴＥのＤＣＩと同じ目的を有し、すなわち、例えばダウンリンクデータチャネル（例：ＰＤＳＣＨ）またはアップリンクデータチャネル（例：ＰＵＳＣＨ）をスケジューリングする特別な制御情報のセットである。５Ｇ ＮＲでは、すでに多くの異なるＤＣＩフォーマットが定義されている（非特許文献７の７．３．１節を参照）。
【0059】
これらのＤＣＩフォーマットは、それぞれの情報が形成されて送信される所定のフォーマットを表している。特に、ＤＣＩフォーマット０＿１および１＿１は、それぞれ、１つのセルにおいてＰＵＳＣＨおよびＰＤＳＣＨをスケジューリングするために使用される。
【0060】
これらの機能それぞれにおけるＰＤＣＣＨ監視は、特定の目的を果たし、したがってその目的のために開始される。ＰＤＣＣＨ監視は、一般に、ＵＥが動作させるタイマーに少なくとも基づいて制御される。タイマーはＰＤＣＣＨ監視を制御する目的を有し、例えば、ＵＥがＰＤＣＣＨを監視する最大時間長を制限する。例えば、ＵＥはＰＤＣＣＨを無期限に監視する必要はなく、電力を節約できるように、ある時間後に監視を停止することができる。
【0061】
上述したように、ＰＤＣＣＨにおけるＤＣＩの目的の１つは、ダウンリンクまたはアップリンク、あるいはサイドリンクにおけるリソースを動的にスケジューリングすることである。特に、ＤＣＩのいくつかのフォーマットは、特定のユーザのためにデータチャネルに割り当てられるリソースの指示（リソース割当て、ＲＡ）を伝えるために提供されている。リソース割当ては、周波数領域および／または時間領域におけるリソースの指定を含むことができる。
【0062】
＜ＵＥの識別＞
ＲＮＴＩは、無線ネットワーク一時識別子（Radio Network Temporary Identifier）の略である。例えば、ＲＮＴＩは、無線セル内のＵＥを区別して識別するために使用することができる。さらに、ＲＮＴＩは、特定の無線チャネル、ページングの場合のＵＥのグループ、ｅＮＢによって電力制御が発行される対象のＵＥのグループ、５Ｇ ｇＮＢによってすべてのＵＥに対して送信されるシステム情報も、識別することができる。５Ｇ ＮＲでは、ＵＥのための多くの異なる識別情報が定義されており、その一部を次の表に示す（非特許文献８の７．１節を参照）。
ＲＮＴＩは、無線ネットワーク一時識別子（Radio Network Temporary Identifier）の略である。例えば、ＲＮＴＩは、無線セル内のＵＥを区別して識別するために使用することができる。さらに、ＲＮＴＩは、特定の無線チャネル、ページングの場合のＵＥのグループ、ｅＮＢによって電力制御が発行される対象のＵＥのグループ、５Ｇ ｇＮＢによってすべてのＵＥに対して送信されるシステム情報も、識別することができる。５Ｇ ＮＲでは、ＵＥのための多くの異なる識別情報が定義されており、その一部を次の表に示す（非特許文献８の７．１節を参照）。
【表1】
【0063】
上に示されているＲＮＴＩ以外に、Ｉｎａｃｔｉｖｅ－ＲＮＴＩ（Ｉ－ＲＮＴＩ）などのさらなるＩＤが存在し得る（非特許文献９の例えば６．３．２節を参照）。Ｉｎａｃｔｉｖｅ－ＲＮＴＩは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあるＵＥに使用され、例えば、そのＵＥのサスペンドされたＵＥコンテキストを識別および特定するプロセスにおいて使用される。一実装形態によれば、ネットワークは、ＵＥが（例えばＲＲＣ＿ＣＯＮＮＥＣＴＥＤから）ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に移行するときに、（例えばＳｕｓｐｅｎｄＣｏｎｆｉｇ内のＲＲＣＲｅｌｅａｓｅメッセージの一部として）Ｉ－ＲＮＴＩを割り当てる。Ｉ－ＲＮＴＩには２つのタイプがあり、すなわち完全なＩ－ＲＮＴＩおよびショートＩ－ＲＮＴＩである。ネットワークは、接続を再開するときにどちらのＩ－ＲＮＴＩを使用するかを、（例えばＳＩＢ１（システム情報ブロック１：System Information Block 1）の一部として）ＵＥに通知することができる。完全なＩ－ＲＮＴＩは、長さ４０ビットのビット列であり、ショートＩ－ＲＮＴＩは、長さ２４ビットのビット列である。
【0064】
＜ランダムアクセス手順＞
ＬＴＥと同様に、５Ｇ ＮＲではＲＡＣＨ（ランダムアクセスチャネル：Random Access Channel）手順（または単にランダムアクセス手順）が提供される。例えば、ＲＡＣＨ手順は、ＵＥが、発見したセルにアクセスするために使用することができる。またＲＡＣＨ手順は、例えば以下のように、ＮＲ内の他のコンテキストでも使用することができる。
・ ハンドオーバーにおいて、新しいセルへの同期を確立するとき
・ デバイスからのアップリンク送信がない期間が長すぎるために同期が失われた場合に、現在のセルへのアップリンク同期を再確立する
・ 専用のスケジューリング要求リソースがデバイスに設定されていない場合、アップリンクのスケジューリングを要求する
ＬＴＥと同様に、５Ｇ ＮＲではＲＡＣＨ（ランダムアクセスチャネル：Random Access Channel）手順（または単にランダムアクセス手順）が提供される。例えば、ＲＡＣＨ手順は、ＵＥが、発見したセルにアクセスするために使用することができる。またＲＡＣＨ手順は、例えば以下のように、ＮＲ内の他のコンテキストでも使用することができる。
・ ハンドオーバーにおいて、新しいセルへの同期を確立するとき
・ デバイスからのアップリンク送信がない期間が長すぎるために同期が失われた場合に、現在のセルへのアップリンク同期を再確立する
・ 専用のスケジューリング要求リソースがデバイスに設定されていない場合、アップリンクのスケジューリングを要求する
【0065】
ランダムアクセス手順（非特許文献１の９．２．６節を参照）を実行するようにＵＥをトリガーし得るイベントは、以下を含む多数がある。ランダムアクセス手順は、多くのイベントによってトリガーされる。
－ ＲＲＣ＿ＩＤＬＥからの最初のアクセス
－ ＲＲＣ接続再確立手順
－ ＵＬ同期状態が「非同期」であるときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＤＬデータまたはＵＬデータが到着する
－ ＳＲ用のＰＵＣＣＨリソースが利用可能ではないときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＵＬデータが到着する
－ ＳＲの失敗
－ 同期再設定（例：ハンドオーバー）時にＲＲＣによって要求される
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥから遷移する
－ セカンダリＴＡＧのタイムアライメントを確立する
－ その他のＳＩの要求（７．３節を参照）
－ ビームの障害回復
－ ＳｐＣｅｌｌでＵＬ ＬＢＴが連続的に失敗する
－ ＲＲＣ＿ＩＤＬＥからの最初のアクセス
－ ＲＲＣ接続再確立手順
－ ＵＬ同期状態が「非同期」であるときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＤＬデータまたはＵＬデータが到着する
－ ＳＲ用のＰＵＣＣＨリソースが利用可能ではないときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＵＬデータが到着する
－ ＳＲの失敗
－ 同期再設定（例：ハンドオーバー）時にＲＲＣによって要求される
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥから遷移する
－ セカンダリＴＡＧのタイムアライメントを確立する
－ その他のＳＩの要求（７．３節を参照）
－ ビームの障害回復
－ ＳｐＣｅｌｌでＵＬ ＬＢＴが連続的に失敗する
【0066】
移動端末のアップリンク送信が時刻同期している場合には、アップリンク送信のために移動端末をスケジューリングすることができる。したがって、ランダムアクセスチャネル（ＲＡＣＨ）手順は、同期していない移動端末（ＵＥ）とアップリンク無線アクセスの直交伝送の間のインターフェイスとしての役割を果たす。ランダムアクセスは、例えば、アップリンクの同期をまだ獲得していない、あるいは失ったユーザ機器のアップリンク時刻同期を達成するために使用される。ユーザ機器がアップリンク同期を獲得すると、基地局はそのユーザ機器のためにアップリンク送信リソースをスケジューリングすることができる。ランダムアクセスに関連する１つのシナリオは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるユーザ機器が、現在のサービングセルから新しいターゲットセルにハンドオーバーし、ターゲットセルにおいてアップリンク時刻同期を達成するためにランダムアクセス手順を実行する場合である。
【0067】
ランダムアクセス手順には少なくとも２つのタイプがあり、競合ベースで（すなわち本質的に衝突のリスクを伴う）アクセスを可能にする手順と、競合なしで（非競合ベースで）アクセスを可能にする手順である。ランダムアクセス手順の例示的な定義は、非特許文献１０の５．１節に記載されている。
【0068】
次に、図６および図７を参照しながら、ＲＡＣＨ手順についてより詳細に説明する。以下では、図６を参照しながら、競合ベースのランダムアクセス手順についてより詳細に説明する。この手順は、４つの「ステップ」から構成され、したがって例えば４ステップＲＡＣＨ手順と称することができる。最初に、ユーザ機器は、物理ランダムアクセスチャネル（ＰＲＡＣＨ）上でランダムアクセスプリアンブルを基地局に送信する（すなわちＲＡＣＨ手順のメッセージ１）。基地局は、ＲＡＣＨプリアンブルを検出した後、プリアンブルが検出された時間周波数およびスロットを特定する（ランダムアクセス）ＲＡ－ＲＮＴＩを使用してＰＤＣＣＨ上でアドレッシングされるＰＤＳＣＨ（物理ダウンリンクリンク共有チャネル：Physical Downlink Shared Channel）上で、ランダムアクセス応答（ＲＡＲ：Random Access Response）メッセージ（ＲＡＣＨ手順のメッセージ２）を送信する。複数のユーザ機器が同じＰＲＡＣＨリソースで同じＲＡＣＨプリアンブルを送信した場合（これは衝突とも呼ばれる）、それらのユーザ機器は同じランダムアクセス応答メッセージを受信する。ＲＡＲメッセージは、検出されたＲＡＣＨプリアンブルと、受信したプリアンブルのタイミングに基づくその後のアップリンク送信の同期のためのタイミングアライメントコマンド（ＴＡコマンド）と、最初のスケジューリングされた送信を送るための最初のアップリンクリソース割当て（グラント）と、Ｔ－ＣＲＮＴＩ（一時セル無線ネットワーク一時識別子：Temporary Cell Radio Network Temporary Identifier）の割当て、を伝えることができる。このＴ－ＣＲＮＴＩは、ＲＡＣＨ手順が終了するまで、ＲＡＣＨプリアンブルが検出された移動体にアドレッシングする目的に基地局によって使用され、なぜならこの時点で基地局は、移動体の「本当の」識別情報を認識していないためである。
【0069】
ユーザ機器は、基地局によって設定され得る所定の時間ウィンドウ（例えばＲＡＲ受信ウィンドウと呼ばれる）内で、ランダムアクセス応答メッセージを受信するためにＰＤＣＣＨを監視する。基地局から受信したＲＡＲメッセージに応答して、ユーザ機器は、最初のスケジューリングされたアップリンク送信を、ランダムアクセス応答内のグラントによって割り当てられた無線リソース上で送信する。このスケジューリングされたアップリンク送信は、ＲＲＣ接続要求、ＲＲＣ再開要求、またはバッファ状態報告などの特定の機能を有する実際のメッセージを伝える。
【0070】
ＲＡＣＨ手順の最初のメッセージにおいてプリアンブルの衝突が発生した場合（すなわち複数のユーザ機器が同じＰＲＡＣＨリソース上で同じプリアンブルを送信した場合）、衝突したユーザ機器はランダムアクセス応答内で同じＴ－ＣＲＮＴＩを受信し、ＲＡＣＨ手順の第３のステップにおいて自身のスケジューリングされた送信を送信するときにも同じアップリンクリソースにおいて衝突する。１基のユーザ機器からのスケジューリングされた送信が基地局によって正常に復号された場合、他のユーザ機器については競合が未解決のままである。このタイプの競合を解決するために、基地局はＣ－ＲＮＴＩまたは一時Ｃ－ＲＮＴＩ宛にアドレッシングされた競合解決メッセージ（第４のメッセージ）を送信する。これで手順は終了する。
【0071】
図７は、競合なしのランダムアクセス手順を示しており、この手順は、競合ベースのランダムアクセス手順と比較して簡略化されている。基地局は、衝突（すなわち複数のユーザ機器が同じプリアンブルを送信する）の危険性がないように、最初のステップで、ランダムアクセスに使用する専用のプリアンブルをユーザ機器に提供する。したがってユーザ機器は、基地局によってシグナリングされたプリアンブルを、その後、ＰＲＡＣＨリソース上でアップリンクにおいて送信する。競合なしのランダムアクセスでは、複数のＵＥが同じプリアンブルを送信するケースが回避されるため、競合なしのランダムアクセス手順は、本質的には、ランダムアクセス応答がＵＥによって正常に受信された後に終了する。
【0072】
３ＧＰＰは、５Ｇ ＮＲ用の２ステップ（競合ベース）ＲＡＣＨ手順も定義しており、この手順では、４ステップのＬＴＥ／ＮＲ ＲＡＣＨ手順におけるメッセージ１およびメッセージ３に対応するメッセージ１（ＭｓｇＡと呼ばれる）が、最初に送信される。この２ステップＲＡＣＨタイプのＭｓｇＡは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）上のプリアンブルと、物理アップリンク共有チャネル（ＰＵＳＣＨ）上のペイロードを含む。ＭｓｇＡを送信した後、ＵＥは、設定された時間ウィンドウ内で、ｇＮＢからの応答を監視する。次に、ｇＮＢは、４ステップＬＴＥ／ＮＲ ＲＡＣＨ手順のメッセージ２およびメッセージ４に対応するメッセージ２（ＭｓｇＢと呼ばれる）で応答する。このＭｓｇＢは、例えば成功ランダムアクセス応答（ＲＡＲ）、フォールバックＲＡＲ、およびオプションとしてバックオフ指示を含むことができる。成功ＲＡＲを受信して競合の解決に成功した場合、ＵＥはランダムアクセス手順を終了する。一方、ＭｓｇＢにおいてフォールバックＲＡＲを受信した場合、ＵＥは（４ステップＲＡＣＨ手順と同様に）メッセージ３の送信を実行し、競合解決を監視する。２ステップＲＡＣＨ手順ではさらにいくつかの例示的な想定がなされ、例えばＵＥは、ＲＡＣＨタイプ（例えば２ステップＲＡＣＨ）を決定した後、失敗するまで同じＲＡＣＨタイプを再試行し続ける。しかしながら、ＵＥがＭｓｇＡの送信を特定の回数だけ再試行した後に４ステップＲＡＣＨ手順に切り替えることを可能としてもよい。
【0073】
さらに、２ステップＲＡＣＨ手順および４ステップＲＡＣＨ手順を実行するために使用される、互いに排他的である無線リソースを、ネットワークが半静的に決定することができる。ＲＡＣＨ手順における最初のメッセージの送信に使用される無線リソースは、少なくともＲＡＣＨ機会およびプリアンブルを含む。例えば２ステップＲＡＣＨ手順では、最初のメッセージＭｓｇＡは、ＰＲＡＣＨリソース（例えばＲＡＣＨ機会およびプリアンブル）のみならず、関連するＰＵＳＣＨリソースも使用する。
【0074】
一般に、ＲＡＣＨプリアンブルについては、例えば非特許文献１１の「表６．３．３．２－２： ＦＲ１およびペアスペクトル／補足アップリンクのランダムアクセス設定（Random access configurations for FR1 and paired spectrum/supplementary uplink）」および６．３．３．２節「物理リソースへのマッピング（Mapping to physical resources）」を参照されたい。
【0075】
＜ＲＲＣ状態（ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ、ＲＲＣ＿Ｉｎａｃｔｉｖｅ、ＲＲＣ Ｉｄｌｅ）＞
ＬＴＥでは、ＲＲＣ状態機械は、ＲＲＣアイドル状態（主として、高い省電力化、ＵＥ自律モビリティ、コアネットワークとのＵＥ接続が確立されていない、ことを特徴とする）と、ＲＲＣ接続状態の２つの状態のみから構成されており、ＲＲＣ接続状態では、ロスレスサービス継続をサポートするためにモビリティがネットワークによって制御されている間、ＵＥはユーザプレーンデータを送信することができる。５Ｇ ＮＲでは、ＬＴＥに関連するＲＲＣ状態機械を、以下で説明するように、非アクティブ状態（例えば非特許文献１２の図４．２．１－１および図４．２．１－２を参照）によって拡張することができる。
ＬＴＥでは、ＲＲＣ状態機械は、ＲＲＣアイドル状態（主として、高い省電力化、ＵＥ自律モビリティ、コアネットワークとのＵＥ接続が確立されていない、ことを特徴とする）と、ＲＲＣ接続状態の２つの状態のみから構成されており、ＲＲＣ接続状態では、ロスレスサービス継続をサポートするためにモビリティがネットワークによって制御されている間、ＵＥはユーザプレーンデータを送信することができる。５Ｇ ＮＲでは、ＬＴＥに関連するＲＲＣ状態機械を、以下で説明するように、非アクティブ状態（例えば非特許文献１２の図４．２．１－１および図４．２．１－２を参照）によって拡張することができる。
【0076】
ＮＲ ５ＧにおけるＲＲＣ（非特許文献１２の４節を参照）では、次の３つの状態、すなわちＲＲＣ Ｉｄｌｅ、ＲＲＣ Ｉｎａｃｔｉｖｅ、およびＲＲＣ Ｃｏｎｎｅｃｔｅｄがサポートされる。ＵＥは、ＲＲＣ接続が確立されているときには、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態またはＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のいずれかである。そうでない場合、すなわちＲＲＣ接続が確立されていない場合、ＵＥはＲＲＣ＿ＩＤＬＥ状態である。図８に示したように、以下の状態遷移が可能である。
・ 例えば「接続確立」手順に従って、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
・ 例えば「接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥ
・ 例えば「サスペンドによる接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＮＡＣＴＩＶＥ
・ 例えば「接続再開」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
・ 例えば「接続解放」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＩＤＬＥ（単方向）
・ 例えば「接続確立」手順に従って、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
・ 例えば「接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥ
・ 例えば「サスペンドによる接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＮＡＣＴＩＶＥ
・ 例えば「接続再開」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
・ 例えば「接続解放」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＩＤＬＥ（単方向）
【0077】
新しいＲＲＣ状態であるＲＲＣ Ｉｎａｃｔｉｖｅは、ｅＭＢＢ（拡張モバイルブロードバンド）、ｍＭＴＣ（大規模マシンタイプ通信）、ＵＲＬＬＣ（超高信頼・低遅延通信）など、シグナリング、省電力、レイテンシなどに関して極めて異なる要件を有する幅広いサービスをサポートするときに恩恵が提供されるように、５Ｇ ３ＧＰＰの新しい無線技術を対象に定義されたものである。したがって新しいＲＲＣ Ｉｎａｃｔｉｖｅ状態は、無線アクセスネットワークおよびコアネットワークにおけるシグナリング、消費電力、リソースコストを最小限に抑えることができる一方で、例えば低遅延でデータ転送を開始できるように設計される。
【0078】
５Ｇ ＮＲの例示的な実装によれば、これらの異なる状態は以下のように特徴付けられる（非特許文献１２の４．２．１節を参照）。
「ＲＲＣ＿ＩＤＬＥ」
－ ＵＥ固有のＤＲＸを上位層によって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージを監視する（６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングにおいてページングチャネルを監視する
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）。
－ ログに記録された測定設定済みＵＥの位置および時刻とともに、利用可能な測定のロギングを実行する
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ
－ ＵＥ固有のＤＲＸを、上位層またはＲＲＣ層によって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、ＵＥ Ｉｎａｃｔｉｖｅ ＡＳコンテキストを格納する
－ ＲＡＮベースの通知領域がＲＲＣ層によって設定される
ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージを監視する（６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングおよび完全なＩ－ＲＮＴＩを使用するＲＡＮページングにおいてページングチャネルを監視する
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ ＲＡＮベースの通知領域の更新を、定期的に、および設定されたＲＡＮベースの通知領域の外側に移動したときに、実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）
－ ログに記録された測定設定済みＵＥの位置および時刻とともに、利用可能な測定のロギングを実行する
－ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ：
－ ＵＥはＡＳコンテキストを格納する
－ ＵＥとの間でのユニキャストデータの転送
－ 下位層において、ＵＥにＵＥ固有のＤＲＸを設定することができる
－ ＣＡをサポートするＵＥの場合、帯域幅を広げるためにＳｐＣｅｌｌとアグリゲートされた１つ以上のＳＣｅｌｌを使用する
－ ＤＣをサポートするＵＥの場合、帯域幅を広げるためにＭＣＧとアグリゲートされた１つのＳＣＧを使用する
－ ＮＲ内およびＥ－ＵＴＲＡとの間での、ネットワークが制御するモビリティ
－ ＵＥは、
－ 設定されている場合、ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージを監視する（６．５節を参照）
－ 共有データチャネルに関連付けられる制御チャネルを監視し、共有データチャネルにデータがスケジューリングされているかどうかを判定する
－ チャネル品質およびフィードバック情報を提供する
－ 隣接セルの測定および測定報告を実行する
－ システム情報を取得する
－ 利用可能な位置の報告とともに、ただちにＭＤＴ測定を行う
「ＲＲＣ＿ＩＤＬＥ」
－ ＵＥ固有のＤＲＸを上位層によって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージを監視する（６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングにおいてページングチャネルを監視する
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）。
－ ログに記録された測定設定済みＵＥの位置および時刻とともに、利用可能な測定のロギングを実行する
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ
－ ＵＥ固有のＤＲＸを、上位層またはＲＲＣ層によって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、ＵＥ Ｉｎａｃｔｉｖｅ ＡＳコンテキストを格納する
－ ＲＡＮベースの通知領域がＲＲＣ層によって設定される
ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージを監視する（６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングおよび完全なＩ－ＲＮＴＩを使用するＲＡＮページングにおいてページングチャネルを監視する
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ ＲＡＮベースの通知領域の更新を、定期的に、および設定されたＲＡＮベースの通知領域の外側に移動したときに、実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）
－ ログに記録された測定設定済みＵＥの位置および時刻とともに、利用可能な測定のロギングを実行する
－ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ：
－ ＵＥはＡＳコンテキストを格納する
－ ＵＥとの間でのユニキャストデータの転送
－ 下位層において、ＵＥにＵＥ固有のＤＲＸを設定することができる
－ ＣＡをサポートするＵＥの場合、帯域幅を広げるためにＳｐＣｅｌｌとアグリゲートされた１つ以上のＳＣｅｌｌを使用する
－ ＤＣをサポートするＵＥの場合、帯域幅を広げるためにＭＣＧとアグリゲートされた１つのＳＣＧを使用する
－ ＮＲ内およびＥ－ＵＴＲＡとの間での、ネットワークが制御するモビリティ
－ ＵＥは、
－ 設定されている場合、ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージを監視する（６．５節を参照）
－ 共有データチャネルに関連付けられる制御チャネルを監視し、共有データチャネルにデータがスケジューリングされているかどうかを判定する
－ チャネル品質およびフィードバック情報を提供する
－ 隣接セルの測定および測定報告を実行する
－ システム情報を取得する
－ 利用可能な位置の報告とともに、ただちにＭＤＴ測定を行う
【0079】
ＲＲＣ Ｉｎａｃｔｉｖｅ状態の特徴によれば、Ｉｎａｃｔｉｖｅ ＵＥの場合、ＲＡＮおよびコアネットワークとの接続（ユーザプレーンおよび制御プレーンの両方）が維持される。より具体的には、ＲＲＣ Ｉｎａｃｔｉｖｅでは、接続は依然として存在するがサスペンドされている、言い換えれば、接続はもはや有効ではない。これに対してＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態では、接続は存在し、例えばデータ送信に使用されるという意味でアクティブである。ＲＲＣ Ｉｄｌｅ状態では、ＵＥはＲＡＮおよびコアネットワークとのＲＲＣ接続を有さず、このことは、例えば、無線基地局がＵＥのコンテキストを有さず、例えばＵＥの識別情報を認識しておらず、ＵＥによって送信されたデータを正しく復号できるようにするためのＵＥに関するセキュリティパラメータを有さない（セキュリティは例えば送信されたデータの完全性を保証する）ことも意味する。ＵＥコンテキストはコアネットワークにおいて利用可能であり得るが、最初に無線基地局によって取得されなければならない。
【0080】
さらに、無線セル内のユーザ機器のためのページングメカニズム（例えば通知メカニズムとも呼ばれる）は、いわゆる無線アクセスネットワーク（ＲＡＮ）ベースの通知領域（略してＲＮＡ）に基づく。無線アクセスネットワークは、ユーザ機器が位置している現在のＲＮＡを認識しているべきであり、ユーザ機器は、様々なＲＮＡの間を移動するＵＥを追跡するようにｇＮＢを支援することができる。ＲＮＡはＵＥ固有とすることができる。
【0081】
以下では、ＵＥがＲＲＣ＿Ｉｎａｃｔｉｖｅ状態からＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に移行するためのＲＲＣ再開手順の一例（非特許文献１２の５．３．１３節を参照）について、図９を参照しながら説明する。この手順の目的は、サスペンドされたＲＲＣ接続を再開することである（シグナリング無線ベアラおよびデータ無線ベアラの再開を含みうる）。
【0082】
この手順では、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージまたはＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージのいずれかを送信することができる。ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信するときには、ＵＥの識別情報（例示的に「ｒｅｓｕｍｅＩｄｅｎｔｉｔｙ」と呼ばれる）としてショートＩ－ＲＮＴＩ（例えば省略型（truncated）Ｉ－ＲＮＴＩ）が使用される。ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージを送信するときには、ＵＥの識別情報（例示的に「ｒｅｓｕｍｅＩｄｅｎｔｉｔｙ」と呼ばれる）として完全なＩ－ＲＮＴＩが使用される。ＵＥは、ＳＩＢ１における指示「ｕｓｅＦｕｌｌＲｅｓｕｍｅＩＤ」を確認し、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージまたはＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージのいずれかを送信するように決定する。「ｕｓｅＦｕｌｌＲｅｓｕｍｅＩＤ」が「ｔｒｕｅ」を示している場合、ＵＥは完全なＩ－ＲＮＴＩを使用してＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１を送信し、そうでない場合、ＵＥはショートＩ－ＲＮＴＩを使用してＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔを送信する。ＵＥがＲＲＣ再開手順において実行するアクションには（非特許文献１２の５．３．１３．４節を参照）、ＳＲＢ２およびすべてのＤＲＢ（これらはＲＲＣ Ｉｎａｃｔｉｖｅ状態に移行したときにサスペンドされた（以下の解放手順を参照））を再開することが含まれる。
【0083】
ＲＲＣＲｅｓｕｍｅ手順は、ＵＥが、設定されたＲＮＡの外に移動するときにＲＮＡの更新を実行するために使用することもできる。この場合にネットワークは、図１０に示したように、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ／ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージに対する応答として、ＲＲＣＲｅｓｕｍｅの代わりにＲＲＣＲｅｌｅａｓｅを送信する。ＵＥは、ＲＲＣＲｅｌｅａｓｅメッセージを受信した後、ＲＲＣ＿ＩＮＡＣＴＩＶＥのままである。
【0084】
以下では、ＵＥをＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態からＲＲＣ Ｉｎａｃｔｉｖｅ状態に遷移させるためのその後のＲＲＣ接続解放手順の一例について（非特許文献１２の５．３．８節を参照）、図１１を参照しながら説明する。この手順の目的は、ＲＲＣ接続を解放すること、またはＲＲＣ接続をサスペンドすることである。例えば、ネットワークは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにあるＵＥをＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＩＮＡＣＴＩＶＥに遷移させるためにＲＲＣ接続解放手順を開始する。ＲＲＣ接続解放手順においてＵＥが実行するアクションには（非特許文献１２の５．３．８．３節を参照）、サスペンドによって解放が行われる場合（例：ＲＲＣＲｅｌｅａｓｅがｓｕｓｐｅｎｄＣｏｎｆｉｇを含む）、ＳＲＢ０を除くすべてのＳＲＢ（シグナリング無線ベアラ：Signaling Radio Bearer）およびＤＲＢ（データ無線ベアラ：Data Radio Bearer）をサスペンドすることが含まれる。したがって、ＲＲＣ Ｉｎａｃｔｉｖｅ状態にあるＵＥは、サスペンドされていないＤＲＢまたはアクティブなＤＲＢを有さない（ＵＥはサスペンドされたＤＲＢのみを有する）。ＳＲＢ０は、ＲＲＣ Ｉｎａｃｔｉｖｅ状態であってもアクティブに維持され、例えばＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔなどのＲＲＣメッセージを伝えるときに、ＲＡＣＨ手順を実行するためにＵＥによって使用することができる。
【0085】
本出願において使用される非アクティブ状態という用語は、ＵＥと基地局との間の定期的かつ大規模なデータ交換が不可能である状態、または一般的ではない状態として広義に理解されるものとする。例えば、ＵＥは、非アクティブ状態にあるとき（例えば「非アクティブＵＥ」と呼ばれる）、アクティブに使用されるデータ接続を有さないが、最初にデータ接続を再開する必要なしに（少量の）データの送信を可能にする１つ以上の非アクティブなデータ接続（例えば、存在するが現在使用されていないデータ接続と呼ぶこともできる）を依然として有する。完全を期すために説明すると、アイドル状態にあるＵＥは、ＵＥが基地局にデータを送信することのできるデータ接続を有さないが、接続状態にあるＵＥは、基地局にデータを伝えるためにただちに使用することのできる１つ以上のアクティブなデータ接続を有する。
【0086】
＜ＲＲＣ非アクティブ状態にあるＵＥによるデータ送信－ＳＤＴ手順＞
より詳細には、５Ｇ ＮＲではＲＲＣ＿ＩＮＡＣＴＩＶＥ状態がサポートされており、低頻度の（定期的および／または非定期的な）データ送信を有するＵＥは、一般に、ネットワークによってＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に維持される。リリース１６までは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態ではデータ送信がサポートされない。したがって、ＵＥは、いかなるＤＬ（ＭｏｂｉｌｅＴｅｒｍｉｎａｔｅｄ）データおよびＵＬ（ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ）データについても、接続を再開（例えばＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行）しなければならない。データパケットがどれだけ小さく低頻度であっても、データ送信のたびに、接続のセットアップ（または再開）、およびその後のＲＲＣ＿ＩＮＡＣＴＩＶＥ状態への解放を行わなければならない。その結果として、不必要な電力消費およびシグナリングオーバーヘッドが発生する。
より詳細には、５Ｇ ＮＲではＲＲＣ＿ＩＮＡＣＴＩＶＥ状態がサポートされており、低頻度の（定期的および／または非定期的な）データ送信を有するＵＥは、一般に、ネットワークによってＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に維持される。リリース１６までは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態ではデータ送信がサポートされない。したがって、ＵＥは、いかなるＤＬ（ＭｏｂｉｌｅＴｅｒｍｉｎａｔｅｄ）データおよびＵＬ（ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ）データについても、接続を再開（例えばＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行）しなければならない。データパケットがどれだけ小さく低頻度であっても、データ送信のたびに、接続のセットアップ（または再開）、およびその後のＲＲＣ＿ＩＮＡＣＴＩＶＥ状態への解放を行わなければならない。その結果として、不必要な電力消費およびシグナリングオーバーヘッドが発生する。
【0087】
小さくかつ低頻度のデータトラフィックの具体例としては、以下のユースケースが挙げられる。
－ スマートフォンのアプリケーション：
〇 インスタントメッセージングサービス（ｗｈａｔｓａｐｐ、ＱＱ、ｗｅｃｈａｔなど）からのトラフィック
〇 ＩＭ／メールクライアントおよび他のアプリからのハートビート／キープアライブトラフィック
〇 様々なアプリケーションからのプッシュ通知
－ スマートフォン以外のアプリケーション：
〇 ウェアラブルデバイスからのトラフィック（定期的な位置情報など）
〇 センサー（温度、圧力の測定値を定期的またはイベントトリガー方式で送信する産業用無線センサーネットワークなど）。
〇 定期的な検針値を送信するスマートメーターおよびスマートメーターネットワーク
－ スマートフォンのアプリケーション：
〇 インスタントメッセージングサービス（ｗｈａｔｓａｐｐ、ＱＱ、ｗｅｃｈａｔなど）からのトラフィック
〇 ＩＭ／メールクライアントおよび他のアプリからのハートビート／キープアライブトラフィック
〇 様々なアプリケーションからのプッシュ通知
－ スマートフォン以外のアプリケーション：
〇 ウェアラブルデバイスからのトラフィック（定期的な位置情報など）
〇 センサー（温度、圧力の測定値を定期的またはイベントトリガー方式で送信する産業用無線センサーネットワークなど）。
〇 定期的な検針値を送信するスマートメーターおよびスマートメーターネットワーク
【0088】
ＲＲＣ Ｉｎａｃｔｉｖｅ状態にあるＵＥが、ＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態に遷移した後に（少量の）データを送信できるようにするための先行技術の例示的な手順（この場合には５Ｇ－ＮＲ準拠の先行技術の解決策）について、図１２を参照しながら以下に簡潔に説明する。図から明らかなように、ＵＥはＲＲＣ＿Ｉｎａｃｔｉｖｅ状態にあると想定し、この状態では例えば、ＵＥ（およびｇＮＢ）はすべてのデータ無線ベアラをサスペンドしており、ｇＮＢにデータを送信することができない。ＵＥがデータを送信できるようにするためには、最初にＵＥがＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態に遷移しなければならず、これは、ＵＥがＲＡＣＨ手順（図１２では例えば４ステップＲＡＣＨ手順を使用する）の一部としてＲＲＣ接続の再開を要求する（ここではＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔを送信する）ことによって、行うことができる。
【0089】
詳細には、ＵＥは現在のｇＮＢにプリアンブルを送信することができ、その後、無線リソースの（少量の）ＵＬグラントを含む対応するランダムアクセス応答を受信し、ＵＥはこの無線リソースを使用して、ＲＡＣＨ手順のｍｓｇ３としてＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信する。最後に、新しいｇＮＢがＵＥにＲＲＣＲｅｓｕｍｅメッセージを提供し、ＵＥはＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態に遷移する（すべてのデータ無線ベアラの再開を含む）。ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態では、ＵＥはＵＬデータを送信することができる。
【0090】
ｇＮＢは、このＵＬスモールデータの送信の後、ＵＥを実際にＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移させるべきであることを決定することができる。ＵＥはＲＲＣ接続の再開を要求することができるが、この点に関する制御はｇＮＢに委ねることができる。１つの例示的な可能性は、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移するべきか否かを決定するために、ＵＥが例えばＭｓｇ３またはＭｓｇＡにおいて送信することのできるバッファ状態報告をｇＮＢが考慮に入れることである。バッファ状態報告は、ＵＥのバッファ内の実際のデータ量を示す。例えば、バッファ状態報告が、ＵＥのバッファ内の大量のデータを示している場合、ｇＮＢはＵＥをＲＲＣ＿ＩＮＡＣＴＩＶＥ状態からＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移させることを決定することができる（例えばｇＮＢがＲＲＣＲｅｓｕｍｅメッセージを送信することによる）。一方、バッファ状態報告が、ＵＥのバッファ内の少量のみのデータを示している場合、ｇＮＢはＵＥをＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に維持することを決定することができる（例えばｇＮＢがＲＲＣＲｅｌｅａｓｅメッセージを送信することによる）。さらに、Ｍｓｇ３／ＭｓｇＡにバッファ状態報告が含まれないことによって、例えばＵＥのバッファにそれ以上のデータが存在しないことをｇＮＢに示すこともでき、ＵＥはＲＲＣ＿ＩＮＡＣＴＩＶＥにとどまることができる。
【0091】
図１２の説明から理解できるように、ＵＥがアップリンクでユーザデータを送信できるように、ＵＥが最初に非アクティブ状態から接続状態に遷移する必要がある上記のプロセスでは、レイテンシが発生するうえに、ユーザデータを送信するたびにＵＥのかなりの電力が消費される。さらに、スモールデータパケットを送信するときにＩＮＡＣＴＩＶＥ状態のＵＥに発生するシグナリングオーバーヘッドは一般的な問題であり、５Ｇ ＮＲでＵＥの数が増えれば、さらに悪化する。
【0092】
したがって３ＧＰＰは、ＵＥの状態をＲＲＣ Ｃｏｎｎｅｃｔｅｄに変更することなく、ＲＲＣ＿Ｉｎａｃｔｉｖｅ ＵＥがアップリンクで（スモール）データを送信できるようにすることを意図している。一般に、ＩＮＡＣＴＩＶＥ状態にあるときに断続的な（スモール）データパケットを有するデバイスは、ＩＮＡＣＴＩＶＥ状態での（スモール）データの送信を可能にすることから恩恵を受ける。
【0093】
図１３および図１４に関して、ならびに、本発明のコンセプト、解決策、および変形形態についてその後に説明するためになされた以下の想定は、例示的にすぎないものとみなされるべきであり、ＲＡＣＨベースのスモールデータアップリンク送信を限定するものではない。
【0094】
さらに、一例としてＲＡＣＨベースのスモールデータアップリンク送信を想定するとき、ＵＥは、２ステップＲＡＣＨまたは４ステップＲＡＣＨのいずれかを使用して、アップリンクでスモールデータを送信することができ（ＭｓｇＡまたはＭｓｇ３を参照）、図１３および図１４は、簡略化された例示的なＲＡＣＨベースのスモールデータアップリンク送信手順を示している。図１３および図１４の両方において、ＵＥはすでにＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあり、送信可能なスモールデータを有するものと例示的に想定する。図１３では、４ステップのＲＡＣＨ手順を想定しており、ＵＥがＭｓｇ３を使用してスモールデータをどのように送信するかを示している。図１４では、２ステップのＲＡＣＨ手順を想定しており、ＵＥがＭｓｇＡを使用してスモールデータをどのように送信するかを示している。
【0095】
一例によれば、制御メッセージおよびスモールデータは、一緒に、例えば同じトランスポートブロック内で一緒に基地局に送信され、この場合、ＵＥは、リソースを使用してトランスポートブロックを構築し、ＭＡＣ層の同じトランスポートブロック内にデータおよびシグナリングを一緒に多重化する。４ステップＲＡＣＨの場合、スモールデータは、例えばＭｓｇ２でｇＮＢから受信されたアップリンクグラントを通じて付与される無線リソースに基づいて、Ｍｓｇ３の中で送信される。２ステップＲＡＣＨの場合、スモールデータは、例えば、選択されたＲＡＣＨプリアンブルに関連して、例えば以前に設定されたいいくつかの無線リソースからＵＥによって選択される無線リソースを使用して、ＭｓｇＡの中で送信される。
【0096】
さらに図１３および図１４は、それぞれ、Ｍｓｇ３およびＭｓｇＡにバッファ状態報告を含めることができることを示しており、ただしＢＳＲを含めることが単に例示的な可能性であることを反映するために、ＢＳＲは括弧内に示してあるのみである。例えば、図１３では、例えばＢＳＲが存在しない、またはＢＳＲがＵＥのバッファ内の少量のみのアップリンクスモールデータを示しているため、ｇＮＢがＵＥをＲＲＣ＿Ｉｎａｃｔｉｖｅ状態に維持することを決定するものと例示的に想定している。これに対応して、Ｍｓｇ４においてＲＲＣＲｅｌｅａｓｅメッセージが送信される。一方、図１４では、例えばＢＳＲが、ＵＥによって送信されなければならないＵＥバッファ内のかなりの量のアップリンクデータを示しているため、ｇＮＢがＵＥをＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に遷移させることを決定するものと例示的に想定している。これに対応して、ＭｓｇＡに対してＲＲＣＲｅｓｕｍｅメッセージが送信される。
【0097】
さらに、図１３では、アップリンクグラントは、Ｍｓｇ２のランダムアクセス応答とは別に示されているが、図１３および以下の類似する実装形態では、アップリンクグラントは、これと同等に、ランダムアクセス応答に属しており、ランダムアクセス応答の一部であると見なすことができる。
【0098】
要約すると、ＲＲＣ＿ＩＮＡＣＴＩＶＥ ＵＥのためのスモールデータアップリンク送信の例示的な実装形態が可能であり、例えばＲＡＣＨ手順、すなわち２ステップＲＡＣＨ手順または４ステップＲＡＣＨ手順（図１３および図１４を参照）に基づくことができる。
【0099】
上記では、（例えばＲＡＣＨのＭｓｇ３／ＭｓｇＡを使用する）１回のスモールデータアップリンク送信について説明した。さらに、３ＧＰＰでは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあるＵＥが、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移することなく、同じ手順を使用して複数回のＵＬ（および場合によってはＤＬ）送信を送る（および受信する）ことが可能であるべきであることが合意された。
【0100】
図１５は、図１３の簡略化された例示的な図解よりも詳細な、シングルＳＤＴ送信手順の例示的な実装形態を示している。図解および以降の説明を容易にするために、例示的に、マルチＳＤＴ送信手順は４ステップＲＡＣＨに基づいているものと想定する。
【0101】
さらに、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にある間に、ＵＥが以前のｇＮＢ（アンカーｇＮＢ）から現在のｇＮＢ（したがって現在のサービングｇＮＢ）に移行したものと例示的に想定する。このため、例えばサービングｇＮＢが（サービングｇＮＢにとっては未知の）ＵＥを認証することができるように、サービングｇＮＢがＲＡＣＨ手順の一部として、アンカーｇＮＢからＵＥコンテキストを取得することが必要であり得る。
【0102】
これに関連して、ＵＥのＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージに対する応答（図１５の例ではＲＲＣＲｅｌｅａｓｅメッセージ）とは別に、競合解決識別情報ＭＡＣ制御要素（ＣＲ ＭＡＣ ＣＥ）（Contention Resolution Identity MAC Control Element）が送信されることも例示的に想定する。このＭｓｇ４および対応するＣＲ ＭＡＣ ＣＥの主な目的は、競合ベースのＲＡＣＨで起こり得る競合を解決することであり、したがってサービングｇＮＢがＵＥコンテキストを取得するのを待機する必要がない。したがって、サービングｇＮＢは、できる限り早く（例えばサービングｇＮＢにおいて競合解決の結果が判定されたときに）ＣＲ ＭＡＣ ＣＥを送信することができ、一方、ＵＥからのＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージに対する応答メッセージの送信は、ＵＥコンテキストを受信して処理した後にサービングｇＮＢによって実行することができる。一方、別のシナリオでは、競合解決識別情報ＭＡＣ制御要素をＲＲＣ応答メッセージ（例えばＲＲＣＲｅｌｅａｓｅまたはＲＲＣＲｅｓｕｍｅ）と一緒に送信することができる。
【0103】
図１５に示したシングルＳＤＴ手順の一連のステップは以下のとおりである。
【0104】
１．送信可能なスモールデータを有するＵＥが、スモールデータの送信を実行するためにＲＡＣＨを開始する。したがってＵＥは、サービングｇＮＢにプリアンブルを送信する。
【0105】
２．次にＵＥは、サービングｇＮＢから、ＵＥの一時的な識別子（例えば一時Ｃ－ＲＮＴＩ）およびアップリンクリソースグラントを、ＲＡＲとして受信する。
【0106】
３．次にＵＥは、前に受信したＵＬグラントに基づいて、ＵＬスモールデータと一緒にＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信する。さらにＵＥは、実質的にその時点において、ＲＲＣ再開要求手順を制御する役割を担うタイマー（Ｔ３１９と呼ばれる）を開始させる。タイマーＴ３１９に関するさらなる詳細について以下に説明する。
【0107】
より詳細には、５Ｇに準拠する例示的な実装形態によれば、Ｔ３１９タイマーは、ＲＲＣ再開要求手順の最大継続時間を調整する。タイマーＴ３１９は、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信したときに開始され、それに対応する応答（ＲＲＣＲｅｌｅａｓｅまたはＲＲＣＲｅｓｕｍｅメッセージなど）を受信したときに停止される。停止される前にＴ３１９が切れた場合、ＵＥは、そのＲＲＣ再開要求手順が失敗したと判定し、ＲＲＣ＿ＩＤＬＥ状態に遷移する。
【0108】
例示的に、Ｔ３１９に適用される値は、ｇＮＢが、別のアンカーｇＮＢからＵＥコンテキストを取得するために必要な時間を考慮に入れて決定する。Ｔ３１９が長いほど、サービングｇＮＢは応答メッセージ（例えばＲＲＣＲｅｌｅａｓｅまたはＲＲＣＲｅｓｕｍｅ）をより遅いタイミングでＵＥに送信することができる。Ｔ３１９の値は、例えばｇＮＢがシステム情報（ＳＩＢ）を使用して自身のセル内でブロードキャストすることができ、したがってＴ３１９タイマーはセルに固有であり、ＵＥに固有ではない。
【0109】
４．サービングｇＮＢは、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージの情報コンテンツに基づいて、アンカーｇＮＢからＵＥのコンテキストの取得を試みる。ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージには、例えばコンテキストを取得するための対応するＵＥ ＩＤ（Ｉｎａｃｔｉｖｅ－ＲＮＴＩ、Ｉ－ＲＮＴＩなど）が含まれている。
【0110】
５．サービングｇＮＢは、ＵＥコンテキスト取得の完了を待たずに、競合解決識別情報ＭＡＣ ＣＥをＵＥに送信し、これによりＲＡＣＨ手順が完了する。ＵＥはこのＣＲ ＭＡＣ ＣＥを受信し、その中の競合解決識別情報と、前にＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージにおいてサービングｇＮＢに送信したＵＥ ＩＤ（例えばＩ－ＲＮＴＩ）とを比較する。２つのＩＤが一致した場合、競合は肯定的に解決される（positively resolved）。
【0111】
６．ＲＡＣＨ競合が肯定的に解決した結果として、ＵＥは、前に受信した一時Ｃ－ＲＮＴＩをＣ－ＲＮＴＩとして使用する。
【0112】
７．次に、サービングｇＮＢがアンカーｇＮＢからＵＥのコンテキストを正常に取得すると想定する。
【0113】
８．次に、サービングｇＮＢは、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージに対してどのように応答するかを決定し、図１５のこの例示的なケースでは、ＵＥをＲＲＣ＿Ｉｎａｃｔｉｖｅに維持するために、ＲＲＣＲｅｌｅａｓｅメッセージをＵＥに送信する。ＵＥ側では、このＲＲＣＲｅｌｅａｓｅメッセージを受信したときに、Ｔ３１９タイマーを停止させる。
【0114】
９．さらに、ＲＲＣＲｅｌｅａｓｅメッセージの結果として、ＵＥはＲＲＣ＿ＩＮＡＣＴＩＶＥにとどまり、したがってＣ－ＲＮＴＩを解放する（破棄すると称することもできる）。これに対して、例えば、上のステップ３における前のＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージに対する応答としてＲＲＣＲｅｓｕｍｅメッセージを受信したときには、ＵＥはＣ－ＲＮＴＩを保持する。
【0115】
マルチＳＤＴ送信をサポートするためには、ステップ３における１回のスモールデータ送信のみを含む上記の一連のステップを拡張する必要があり得る。例えばＵＥは、追加の適切なＵＬ無線リソースを取得し、それに対応して１回以上のＵＬスモールデータ送信を実行することができる。
【0116】
しかしながら、ＵＥがサービングｇＮＢからアップリンクリソースグラントを受信できるようにするためには、アップリンクリソースグラント（フォーマット０＿０、０＿１、または０＿２のＤＣＩなど）がアドレッシングされる先の有効なＣ－ＲＮＴＩ（すなわち一時Ｃ－ＲＮＴＩがＣ－ＲＮＴＩに変換された後）をＵＥが有することが有利である。言い換えれば、Ｃ－ＲＮＴＩが有効であることは、マルチＳＤＴ手順を実施するために重要である。しかしながら、ＵＥがＣ－ＲＮＴＩを保持するか否かは、上記から明らかなように、開始されたＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔに関連してＵＥが受信する応答と、タイマーＴ３１９の動作とによって決まる。
【0117】
より具体的には、ＵＥがＲＲＣＲｅｌｅａｓｅメッセージを受信した場合（上記のステップ８を参照）、または（例えばＲＲＣＲｅｌｅａｓｅメッセージを受信する前に）Ｔ３１９が切れた場合には、ＵＥのＣ－ＲＮＴＩが解放される。例えば、非特許文献１２の現在の規格には、その５．３．８．３節に、ＲＲＣＲｅｌｅａｓｅメッセージを受信したときのＵＥの動作が定義されており、それによると、ＵＥの動作には、（例えばＭＡＣリセットの一部として）Ｃ－ＲＮＴＩを解放することが含まれる。さらに、非特許文献１２の現在の規格には、その５．３．１３．５節に、例えばＴ３１９タイマーが切れたときのＵＥの動作も定義されており、それによると、ＵＥの動作には、ＲＲＣ＿ＩＤＬＥに遷移することが含まれ、この動作には（非特許文献１２の５．３．１１節を参照）、（例えばＲＬＣエンティティ、ＭＡＣ設定など、すべてのリソースの解放の一部として）Ｃ－ＲＮＴＩを解放することが含まれる。
【0118】
要約すると、ＵＥのＣ－ＲＮＴＩは、Ｔ３１９タイマーが動作している間、かつＲＲＣＲｅｌｅａｓｅメッセージが受信されるまで、ＵＥ内で有効に保持される。その結果、Ｃ－ＲＮＴＩは特定の時間長のみにわたり利用可能であり、この時間長は、ＵＥがマルチＳＤＴ手順を実行するには不十分であることがある。
【0119】
１つの可能な解決策は、正当に可能である最も早いタイミング、例えばＵＥがＭｓｇ４の競合解決を受信した後（図１５およびステップ５の説明を参照）、ただしＲＲＣＲｅｌｅａｓｅメッセージを受信する前に、追加の１回以上のスモールデータ送信を実施することであり得る。図１６はこのような解決策を示しており、この図は図１５に類似しており、対応する想定がなされている。
【0120】
このような解決策では、サービングｇＮＢは、Ｃ－ＲＮＴＩにアドレッシングされたアップリンクグラントをＵＥに送信し、ＵＥは、サービングｇＮＢによってＲＲＣＲｅｌｅａｓｅメッセージが送信される前に、割り当てられたアップリンク無線リソースを使用して、対応するスモールデータアップリンク送信を実行する。
【0121】
オプションとして、スモールデータ送信をバッファ状態報告と一緒に送信することができ、したがってサービングｇＮＢは、ＵＥのバッファにさらにどれだけのデータが存在するかを認識し、さらなるスモールデータ送信が必要であるかどうかを決定して、必要な場合、それに応じて次のＵＬグラントを作成することができる。
【0122】
このように、図１６の解決策によれば、スモールデータ送信を効率的かつ迅速に実施することができる。
【0123】
しかしながら、このような解決策には、サービングｇＮＢがまだアンカーｇＮＢからＵＥコンテキストを受信していないため、ＵＥがまだサービングｇＮＢによって認証されていないという欠点があり得る。一般的には、ＵＥが最初に（ＵＥコンテキストに基づいて）サービングｇＮＢによって認証された後に、ＵＬ無線リソースが実際に予約され、そのような新しいＵＥに割り当てられることが好ましい。例えば、ＵＥコンテキストの取得に失敗する、あるいはＵＥが不正または偽物であることが判明することがあり、したがってＵＬ ＳＤＴ用に意図されている割り当てられた無線リソースが無駄になることがある。
【0124】
さらに、図１６の例示的なシナリオでは、ＵＥコンテキストが取得され、ｇＮＢがＵＥにＲＲＣＲｅｌｅａｓｅメッセージを送信する前に、２回の追加のスモールデータ送信（合計で３回のＳＤＴ）が可能であるものと想定している。その後、ＵＥは、Ｔ３１９タイマーを停止させ、Ｃ－ＲＮＴＩを解放する。その後、さらなるＵＬスモールデータの送信はもはや不可能になる。ただし、利用可能な時間の長さは、ＵＥコンテキストの取得に必要な時間によって決まり、取得に必要な時間は大きく変動する可能性があり、実際には極めて短いこともある。
【0125】
説明した解決策の可能なバリエーションとして、ＵＥがＣ－ＲＮＴＩを破棄することを避けるために、ｇＮＢがＲＲＣＲｅｌｅａｓｅメッセージの送信を待機することが考えられる。例えば、ＵＥがＲＲＣＲｅｌｅａｓｅメッセージを受信してＴ３１９タイマーを停止させ、したがってＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ手順の失敗、および起こり得るＲＲＣ＿ＩＤＬＥ状態への遷移を回避できるちょうどのタイミングまで、ｇＮＢが待機することができる。これにより、サービングｇＮＢがＵＥコンテキストを実際に受信するタイミングとは多少独立して、スモールデータ送信に利用可能な時間が最大化される。しかしながら、サービングｇＮＢによる待機時間は、Ｔ３１９タイマーの値によって制限され、なぜならサービングｇＮＢは、Ｔ３１９タイマーが切れる前にＵＥが受信できる時間内にＲＲＣＲｅｌｅａｓｅを送信する必要があるためである。したがって、必要な回数のスモールデータ送信を実行するための十分な時間がない可能性がある。現在の３ＧＰＰ ５Ｇ準拠の実装では、Ｔ３１９タイマーは最大２０００ｍｓに設定することができる（非特許文献１２の６．３．２節、情報要素「ＵＥ－ＴｉｍｅｒｓＡｎｄＣｏｎｓｔａｎｔｓ」の「ＥＮＵＭＥＲＡＴＥＤ｛ｍｓ１００、ｍｓ２００、ｍｓ３００、ｍｓ４００、ｍｓ６００、ｍｓ１０００、ｍｓ１５００、ｍｓ２０００｝」を参照）。この２０００ｍｓという最大値は、非アクティブＵＥのＵＥコンテキストを保持するアンカーｇＮＢとサービングｇＮＢとの間のバックホールリンクに起因して発生し得る遅延を含めて、別のｇＮＢからのＵＥコンテキスト取得に対応できるように定義されたものである。Ｔ３１９タイマーの最大値は、マルチＳＤＴ手順に対応するようには設計されておらず、したがって小さすぎる可能性が高い。
【0126】
（図１６に基づく）上記の解決策のさらなるオプションの変形形態として、Ｔ３１９タイマーの長さを延長する、すなわち長くすることができる。この点において、Ｔ３１９タイマーを定義することのできる最大値を、ずっと高く設定することができる（例えば８０００ｍｓ）。これによる恩恵として、改良されたマルチＳＤＴ手順によって、ＵＥはＣ－ＲＮＴＩをより長く有効な状態に維持することができ、したがってＲＲＣＲｅｌｅａｓｅメッセージを受信する前に複数のスモールデータ送信のためのより多くの時間を確保することができる。
【0127】
しかしながら、Ｔ３１９タイマーをより高い値に設定することにはデメリットもあり、なぜなら複数回のスモールデータ送信を実行しない、あるいはサポートすらしていない他のＵＥが悪影響を受けるためである。Ｔ３１９タイマーの値は、システム情報の一部としてサービングｇＮＢによってそのセル内でブロードキャストされ、マルチスモールデータ送信を実行しないＵＥまたはサポートしないＵＥを含めて、さらには、ＲＮＡ（ＲＡＮベースの通知領域更新）の実行のみを予定しているＵＥ、ＲＲＣ接続の再開を予定しているＵＥも含めて、すべてのＵＥによって採用される。したがって、延長されたＴ３１９タイマー値は、これらのＵＥのＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ手順に悪影響を及ぼし、なぜならＵＥは、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ手順が失敗した場合、そのことを検出するのはより後の、Ｔ３１９タイマーが切れた時点であるためである。
【0128】
マルチＳＤＴ手順は、シングルＳＤＴ送信手順よりもずっと長い時間にわたることがある。特に、マルチＳＤＴ送信手順は、最初のＵＬ ＳＤＴ送信の後に、いくつかの後続のＵＬグラントの送信を伴うことがある（図１３および図１４も参照）。これにより、例えば上述したシングルＳＤＴ送信手順と比較すると、マルチＳＤＴ手順が大幅に長くなる可能性が高い。
【0129】
ＲＡＮ２＃１１１＿ｅ会合では、スモールデータ送信（ＳＤＴ）はデータ無線ベアラ（ＤＲＢ）ごとにネットワークによって設定されることが合意された。より具体的には、ＲＲＣ＿ＩＮＡＣＴＩＶＥにおいてＳＤＴ ＤＲＢトラフィックが到着すると、ＳＤＴ手順がトリガーされ、一方、ＲＲＣ＿ＩＮＡＣＴＩＶＥにおいて非ＳＤＴ ＤＲＢトラフィックが到着すると、レガシーＲＲＣ再開手順（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤに戻るように要求する）がトリガーされる。言い換えれば、非アクティブ状態でのデータの送信が許可されるようにネットワークによって（例えば基地局によって）設定されているＤＲＢにデータが到着すると、ＳＤＴ手順がトリガーされ、一方、ネットワークによって設定されていないＤＲＢにデータが到着すると、ＵＥは接続状態に入るために（レガシー）ＲＲＣ再開手順を開始するようにトリガーされる。ＲＡＮ２＃１１２＿ｅ会合では、ＵＥはＲＲＣ＿ＩＮＡＣＴＩＶＥに入ったときにすべてのＤＲＢをサスペンドし、ＳＤＴ手順の開始時にはＳＤＴ ＤＲＢのみが（ＵＥによって）再開されることがさらに合意された。
【0130】
したがって、ＳＤＴ手順、またはＳＤＴ ＤＲＢデータを送信する手順という用語は、非アクティブ状態（例えばＲＲＣ＿ＩＮＡＣＴＩＶＥ）においてデータを送信する手順を意味し、必ずしもＳＤＴ手順によって送信されるデータの量を意味するものではない。したがって、スモールデータおよびＳＤＴ ＤＲＢデータという用語は、（ＵＥの）非アクティブ状態において送信することのできるデータを意味し、必ずしもこのデータのサイズを意味するものではない。特に、スモールデータまたはＳＤＴ ＤＲＢデータは、非アクティブ状態での送信用に設定されているＤＲＢ（このようなＤＲＢを本明細書ではＳＤＴ ＤＲＢとも呼ぶ）の任意のデータとすることができる。同様に、非ＳＤＴ ＤＲＢデータという用語は、（ＵＥの）非アクティブ状態において送信することのできないデータ、および／または、（ＵＥの）接続状態においてのみ送信することのできるデータ、を意味する。特に、非ＳＤＴ ＤＲＢデータは、非アクティブ状態での送信用に設定されていないＤＲＢ（このようなＤＲＢを本明細書では非ＳＤＴ ＤＲＢとも呼ぶ）の任意のデータとすることができる。
【0131】
ＳＤＴ ＤＲＢデータを送信する手順は、ＲＡＣＨ手順に基づく、および／またはＲＡＣＨ手順において開始される手順とすることができる。特に、このＲＡＣＨ手順は、４ステップＲＡＣＨ手順または２ステップＲＡＣＨ手順とすることができる。より具体的には、本明細書における、ＲＡＣＨ手順に基づくＳＤＴ手順とは、ＲＡＣＨ手順中に開始されるＳＤＴ手順を意味する。これには、例えば図１３～図１５に示したように、ＲＡＣＨ手順中にスモールデータの送信が１回だけ実行されるＳＤＴ手順のみならず、図１６に示したように、ＲＡＣＨ手順中および／またはＲＡＣＨ手順に続いてスモールデータの送信が２回以上実行されるＳＤＴ手順も含まれる。さらに、図１７に示したように、ＳＤＴ手順が開始されたＲＡＣＨ手順と一緒に終了しないＳＤＴ手順も含まれる。
【0132】
より具体的には、図１７は、マルチＳＤＴ手順、すなわち、４ステップＲＡＣＨ手順に基づく、スモールデータの２回以上の送信を含むＳＤＴ手順を示している。図から理解できるように、図１７のＳＤＴ手順は、ＲＡＣＨ手順とともに終了せず、Ｍｓｇ４の受信後も継続する。より具体的には、ＵＥは、Ｍｓｇ４を受信した後にＵＬグラント１７００を受信し、ＵＬグラント１７００を使用してスモールデータの送信を実行する。図１７では、ＲＡＣＨ手順の終了前に１回のみのスモールデータ送信があり、ＲＡＣＨ手順の終了後に１回のみのスモールデータ送信がある。しかしながら、一般的には、ＲＡＣＨ手順の終了前および／または終了後に、スモールデータの複数回の送信を行うことができる。
【0133】
要約すると、ＲＡＣＨ手順に基づくＳＤＴ手順、またはＲＡＣＨ手順中に開始されるＳＤＴ手順は、非アクティブ状態において１回以上のデータ送信が実行される手順とすることができ、ｉ）これら１回以上の送信のうちの少なくとも１回が、ＵＥによって、ＲＡＣＨ手順のメッセージと一緒に実行される、および／または、ｉｉ）ＲＡＣＨ手順のメッセージと一緒にＵＥによって指示が送信され、この指示は、スモールデータ送信のためのリソースグラントの要求を示す。
【0134】
しかしながら、ＳＤＴ手順という用語は、ＲＡＣＨベースのＳＤＴ手順に限定されず、なぜならこの用語は、コンフィギュアドグラント（ＣＧ）を使用する、非アクティブ状態におけるデータ送信も含むためである。より具体的には、ＵＥは、コンフィギュアドＣＧリソースを使用して、対応する指示をスケジューリングデバイスに送信することにより、ＣＧベースのＳＤＴ手順を開始することができる。ＵＥは、ＳＤＴ ＤＲＢデータの送信を、指示の送信と一緒に、または、より後の送信（これもＣＧリソースを使用することができる）と一緒に、開始することができる。例えばＵＥは、ＳＤＴ ＤＲＢデータが到着すると、そのＳＤＴ ＤＲＢデータをＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージと一緒に多重化して、最も近いＣＧリソースにおいてこれらを送信することができる。ＣＧリソースは、周期的に現れるＵＬグラントであり、ＵＥが非アクティブ状態に入る前／入ったときにスケジューリングデバイスによってＵＥに設定される。
【0135】
＜データ接続＞
本明細書で使用される「データ接続」という用語は、例えばＵＥと無線基地局との間で、データ（例えばスモールデータ）の送信が可能である接続と理解することができる。より詳細には、データ接続を有さないＵＥは、例えばシグナリング接続に基づいて無線基地局と接続されていても、データをただちに送信することはできない。この文脈におけるデータとは、例えばシグナリング接続を使用して送信される制御情報とは対照的に、例えばＵＥ上で実行されているアプリケーションからのユーザデータとして広義に理解することができる。
本明細書で使用される「データ接続」という用語は、例えばＵＥと無線基地局との間で、データ（例えばスモールデータ）の送信が可能である接続と理解することができる。より詳細には、データ接続を有さないＵＥは、例えばシグナリング接続に基づいて無線基地局と接続されていても、データをただちに送信することはできない。この文脈におけるデータとは、例えばシグナリング接続を使用して送信される制御情報とは対照的に、例えばＵＥ上で実行されているアプリケーションからのユーザデータとして広義に理解することができる。
【0136】
例示的な一実装形態において、５Ｇ ＮＲ規格によれば、データ接続はデータ無線ベアラ（ＤＲＢ）として理解することができ、シグナリング接続はシグナリング無線ベアラ（ＳＲＢ）として理解することができる。
【0137】
場合によっては、本出願では、データ接続の異なる状態、例えば、存在しない、存在するがサスペンドされている、存在するが使用されていない（サスペンドされていない、または非アクティブと呼ぶこともできる）、存在しており現在データの送信に使用されている（アクティブと呼ぶこともできる）、をさらに区別する。データ接続のこの分類に従うと、サスペンドされているデータ接続は、データ接続が存在するが、（例えばアップリンクにおいて）データを送信するためにただちに使用することはできず、なぜならデータ接続が両方のエンドポイント（例えばＵＥおよび無線基地局）によってサスペンドされており、最初に再開する必要があるためである。一方、サスペンドされていないデータ接続では、（例えばデータ接続を再開するなどのさらなる手順なしに）ただちにデータを送信することができる。例えば、３ＧＰＰ規格に現在定義されている例示的な５Ｇ ＮＲ実装を参照すると、ＲＲＣ非アクティブ状態にあるＵＥは、１つ以上のサスペンドされたデータ接続を有する（ＤＲＢがサスペンドされている）。ＲＲＣ接続状態にあるＵＥは、１つ以上のアクティブなデータ接続と、場合によっては他のサスペンドされていないデータ接続（現在アクティブに使用されていない）を有することができる。ＲＲＣアイドル状態にあるＵＥは、データ接続（サスペンドされたデータ接続およびアクティブなデータ接続）を有さない。一方、以下に説明する改良されたデータ送信手順によれば、３ＧＰＰ規格に現在定義されている５Ｇ ＮＲ実装とは異なり、ＲＲＣ非アクティブ状態にあるＵＥは、１つ以上の利用可能なサスペンドされていないデータ接続を有する（これらのデータ接続は、スモールデータ送信まではデータが交換されないため非アクティブである）。
【0138】
このコンテキストにおいて、本出願では、例えばＵＥがデータ接続を使用してスモールデータを送信することを説明する。本シナリオでは、データ接続はＵＥと基地局との間に確立されている。例示的な一実装形態では、データ接続は、符号化、セキュリティ、暗号化などに関連する特定のパラメータに関連付けられるものとして広義に理解されるものとする。したがって、送信側の観点から見ると、ＵＥは、そのデータ接続に関連付けられるこれらのパラメータを、そのデータ接続を使用して送信される（スモール）データに適用する。この適用は、例えば特定のサービス品質を保証するために行うことができる。これに対応して、受信側の観点から見ると、受信機は、データ接続を介して送信されるデータを正常に復号するために、送信側とは逆の処理（例えば符号化、セキュリティ、暗号化などに関する処理）を適用する必要があり得る。
【0139】
＜専門用語＞
以下では、５Ｇ移動通信システムにおいて想定される新しい無線アクセス技術のためのＵＥ、基地局、および手順について説明する（ただしこれらはＬＴＥ移動通信システムでも使用することができる）。複数の異なる実装形態および変形形態も説明する。以下の開示は、上述した議論および発見事項によって促進され、例えば、その少なくとも一部に基づくことができる。
以下では、５Ｇ移動通信システムにおいて想定される新しい無線アクセス技術のためのＵＥ、基地局、および手順について説明する（ただしこれらはＬＴＥ移動通信システムでも使用することができる）。複数の異なる実装形態および変形形態も説明する。以下の開示は、上述した議論および発見事項によって促進され、例えば、その少なくとも一部に基づくことができる。
【0140】
一般に、本開示の基礎となる原理を明確かつ理解しやすい方法で説明できるように、本明細書では多くの想定がなされていることに留意されたい。しかしながら、これらの想定は、本明細書において説明を目的としてなされた単なる例であり、本開示の範囲を限定するものではないことを理解されたい。
【0141】
さらに、次の３ＧＰＰ ５Ｇ通信システムのための新しい無線アクセス技術のコンテキストで使用される特定の専門用語は、まだ完全に決定されていない、または最終的に変更される可能性があるが、以下で使用されている手順、エンティティ、層などの用語のいくつかは、ＬＴＥ／ＬＴＥ－Ａシステムに、または現在の３ＧＰＰ ５Ｇ標準化において使用されている専門用語に、密接に関連している。したがって、用語は将来的に変更されうるが、実施形態の機能に影響を与えることはない。したがって、実施形態およびその保護範囲は、より新しいまたは最終的に合意された専門用語が存在しないために本明細書で例示的に使用されている特定の用語に制限されるものではなく、本開示の機能および原理の基礎をなす機能およびコンセプトの観点においてより広義に理解されるべきであることが、当業者には認識されるであろう。
【0142】
＜実施形態＞
一般に、ＳＤＴ手順中に非ＳＤＴデータが到着すると、ＲＲＣ＿ＩＮＡＣＴＩＶＥにあるＵＥは、ｉ）他の状況に関係なく、接続状態に入るためにＲＡＣＨ手順をトリガーすることができ、これはシステム全体のパフォーマンスを低下させる非効率的なアプローチであり得る、および／または、ｉｉ）現在の仕様にはまだ存在しない要因または条件に基づいて、非ＳＤＴデータの到着を示すためにＲＡＣＨ手順をトリガーすることができ、この場合、仕様を変更するための多大な労力が必要となり得る。
一般に、ＳＤＴ手順中に非ＳＤＴデータが到着すると、ＲＲＣ＿ＩＮＡＣＴＩＶＥにあるＵＥは、ｉ）他の状況に関係なく、接続状態に入るためにＲＡＣＨ手順をトリガーすることができ、これはシステム全体のパフォーマンスを低下させる非効率的なアプローチであり得る、および／または、ｉｉ）現在の仕様にはまだ存在しない要因または条件に基づいて、非ＳＤＴデータの到着を示すためにＲＡＣＨ手順をトリガーすることができ、この場合、仕様を変更するための多大な労力が必要となり得る。
【0143】
これに鑑みて、本開示は、ＳＤＴ手順中に非ＳＤＴ ＤＲＢデータが到着した場合の効率的な処理を可能にする技術を提供する。特に、開示される手順は、スモールデータの送信のためにすでに発生している送信機会を、非ＳＤＴ ＤＲＢデータの到着を示すトラフィック指示を送信する目的にも使用することを可能にする。すでに発生している送信機会を使用することで、ＵＥが非ＳＤＴデータの到着の指示を送信するために別のＵＬグラントを必要とすること、および／または、接続状態に入るために追加のＲＡＣＨ手順を開始すること、を回避することができ、したがってＵＥの電力を節約し、オーバーヘッドを減らし、他のＵＥとの衝突を回避することができる。
【0144】
本開示は、基地局およびユーザ機器を提供する。図１８に示したように、ユーザ機器１８１０および基地局１８６０は、無線通信システムにおいて無線チャネルを介して互いに通信することができる。例えば、ユーザ機器は、ＮＲユーザ機器とすることができ、基地局は、ｅＮＢ、またはＮＲ ｇＮＢ、特に非地上系ネットワーク（ＮＴＮ）ＮＲシステムにおけるｇＮＢなどのネットワークノードまたはスケジューリングノードとすることができる。本開示はさらに、スケジューリングされる側のデバイスおよびスケジューリングする側のデバイスを含むシステム、ならびに対応する方法およびプログラムを提供する。このような通信システムの一例を図１８に示す。通信システム１８００は、５Ｇの技術仕様に従った無線通信システム、特にＮＲ通信システムとすることができる。しかしながら、本開示は、３ＧＰＰ ＮＲに限定されるものではなく、ＮＴＮなどの他の無線システムまたはセルラーシステムに適用することもできる。図１８は、ユーザ機器１８１０（通信デバイスとも称する）と、ここでは例示的に基地局（ネットワークノード）に配置されると想定されるスケジューリングデバイス１８６０の、簡略化された一般的かつ例示的なブロック図を示している。しかしながら、一般に、スケジューリングデバイスは、２つの端末間のサイドリンク接続の場合には、端末であってもよい。さらに、特にＵＲＬＬＣ、ｅＭＢＢ、およびｍＭＴＣのユースケースに関して、通信デバイス１８１０は、センサーデバイス、ウェアラブルデバイス、または接続された車両、または産業工場における自動機械のコントローラであってもよい。さらに、通信デバイス１８１０は、基地局１８６０とは別の通信デバイスとの間の中継機として機能することもできる（例えば本開示は、通信「端末」またはユーザ「端末」に限定されない）。
【0145】
ＵＥおよびｅＮＢ／ｇＮＢは、それぞれ送受信機１８２０（ＵＥ側）および１８７０（基地局側）を使用して、（無線）物理チャネル１８５０を介して互いに通信する。基地局１８６０および端末１８１０は、共に通信システム１８００を形成する。通信システム１８００は、図１に示したような他のエンティティをさらに含むことができる。
【0146】
図１８（左側）に示したように、例示的な実施形態によれば、ユーザ機器（ＵＥ）１８１０が提供される。ＵＥ １８１０は、送受信機１８２０および回路１８３０を備える。回路１８３０は、動作時、非アクティブ状態においてＳＤＴ ＤＲＢデータを送信する手順中に、非ＳＤＴ ＤＲＢデータが接続状態において送信されることを検出する。回路１８３０は、動作時、待機するべき送信機会が存在するか否かを判定する。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、動作時、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始する。待機するべき送信機会が存在すると判定され、その送信機会が発生すると、回路は、動作時、その送信機会を使用して、非ＳＤＴ ＤＲＢデータの検出を示すトラフィック指示を送信するように送受信機を制御する。
【0147】
図１９は、回路１８３０、すなわち、非ＳＤＴ ＤＲＢデータの到着を処理する回路の例示的な機能構造を示している。図示したように、非ＳＤＴ ＤＲＢデータ到着処理トラフィック指示処理回路１８３０は、非ＳＤＴ ＤＲＢデータ検出回路１９３６および送信機会判定回路１９３７を含むことができる。より具体的には、回路１９３６は、例えば、送信される非ＳＤＴ ＤＲＢデータが存在するか否かを検出または判定することによって、非ＳＤＴ ＤＲＢデータを検出する。また、回路１９３６は、非ＳＤＴ ＤＲＢの到着が予期されるか否かを判定することもできる。送信機会判定回路１９３７は、待機するべき送信機会が存在するか否かを判定することができる。さらに、待機するべき送信機会が存在すると判定された場合、回路１９３７は、待機するべき送信機会（例えばその送信機会のリソース）を求めることもできる。
【0148】
上述したＵＥに対応して、別の例示的な実施形態によれば、ＵＥによって実行される通信方法が提供される。図２１に示したように、この方法は、以下のステップ、すなわち、
－ 非アクティブ状態においてＳＤＴ ＤＲＢデータを送信する手順中に、非ＳＤＴ ＤＲＢデータが接続状態において送信されることを検出するステップＳ２１１０と、
－ 待機するべき送信機会が存在するか否かを判定するステップＳ２１２０と、
－ Ｓ２１２０で、待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない（Ｓ２１４０で「いいえ」）、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始するステップＳ２１３０と、
－ Ｓ２１２０で、待機するべき送信機会が存在すると判定され、その送信機会が発生した場合（Ｓ２１４０で「はい」）、その送信機会を使用して、非ＳＤＴ ＤＲＢデータの検出を示すトラフィック指示を送信するステップＳ２１５０と、
を含む。
－ 非アクティブ状態においてＳＤＴ ＤＲＢデータを送信する手順中に、非ＳＤＴ ＤＲＢデータが接続状態において送信されることを検出するステップＳ２１１０と、
－ 待機するべき送信機会が存在するか否かを判定するステップＳ２１２０と、
－ Ｓ２１２０で、待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない（Ｓ２１４０で「いいえ」）、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始するステップＳ２１３０と、
－ Ｓ２１２０で、待機するべき送信機会が存在すると判定され、その送信機会が発生した場合（Ｓ２１４０で「はい」）、その送信機会を使用して、非ＳＤＴ ＤＲＢデータの検出を示すトラフィック指示を送信するステップＳ２１５０と、
を含む。
【0149】
図１８（右側）にも示したように、別の例示的な実施形態によれば、スケジューリングデバイス１８６０が提供される。スケジューリングデバイス１８６０は、送受信機１８７０および回路１８８０を備える。回路１８８０は、動作時、非アクティブ状態にあるユーザ機器（ＵＥ）から、ＳＤＴ ＤＲＢデータを含む送信を受信するように、送受信機を制御する。回路１８８０は、動作時、ＳＤＴ ＤＲＢデータを含む受信した送信から、トラフィック指示を取得する。トラフィック指示は、ＵＥによって非ＳＤＴ ＤＲＢデータが検出されたことを示す。非ＳＤＴ ＤＲＢデータとは、接続状態にあるＵＥによって送信されるデータであり、トラフィック指示は、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ＬＣＩＤの事前定義値は、非ＳＤＴ ＤＲＢデータが検出されたことを示す。
【0150】
図２０は、トラフィック指示処理回路１８８５の例示的な機能構造を示している。特に、トラフィック指示処理回路１８８５は、トラフィック指示評価回路２０３６およびＲＲＣ状態遷移回路２０３７を含むことができる。回路２０３６は、スモールデータを含む送信からトラフィック指示を取得して解釈する役割を担うことができる。さらに、回路２０３６が、受信された送信からトラフィック指示を取得すると、回路２０３７は、ＵＥを非アクティブ状態から接続状態に移行させるためのＲＲＣメッセージをＵＥに送信する役割を担うことができる。
【0151】
さらに、上述した基地局に対応して、スケジューリングデバイスによって実行される通信方法が提供される。図２２に示したように、この方法は、以下のステップ、すなわち、
－ 非アクティブ状態にあるユーザ機器（ＵＥ）から、ＳＤＴ ＤＲＢデータを含む送信を受信するステップＳ２２１０と、
－ ＳＤＴ ＤＲＢデータを含む送信から、ＵＥによって非ＳＤＴ ＤＲＢデータが検出されたことを示すトラフィック指示を取得するステップＳ２２２０であって、ｉ）非ＳＤＴ ＤＲＢデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、非ＳＤＴ ＤＲＢデータが検出されたことを示す、ステップＳ２２２０と、
を含む。
－ 非アクティブ状態にあるユーザ機器（ＵＥ）から、ＳＤＴ ＤＲＢデータを含む送信を受信するステップＳ２２１０と、
－ ＳＤＴ ＤＲＢデータを含む送信から、ＵＥによって非ＳＤＴ ＤＲＢデータが検出されたことを示すトラフィック指示を取得するステップＳ２２２０であって、ｉ）非ＳＤＴ ＤＲＢデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、非ＳＤＴ ＤＲＢデータが検出されたことを示す、ステップＳ２２２０と、
を含む。
【0152】
通信デバイス１８１０は、送受信機１８２０および（処理）回路１８３０を備えることができ、スケジューリングデバイス１８６０は、送受信機１８７０および（処理）回路１８８０を備えることができる。送受信機１８１０は、受信機および／または送信機を備える、および／または、受信機および／または送信機として機能することができる。本開示では、言い換えれば、「送受信機」という用語は、通信デバイス１８１０または基地局１８６０が、無線チャネル１８５０を介して無線信号を送信および／または受信することを可能にするハードウェア構成要素およびソフトウェア構成要素に対して使用される。したがって、送受信機は、受信機、送信機、または受信機と送信機の組合せに対応する。一般に、基地局および通信デバイスは、無線信号を送信および受信することができるものと想定される。しかしながら、特に、ｅＭＢＢ、ｍＭＴＣ、およびＵＲＬＬＣの一部の用途（スマートホーム、スマートシティ、産業オートメーションなど）に関しては、センサーなどのデバイスが信号を受信するのみであるケースが考えられる。さらに、「回路」という用語は、１つ以上のプロセッサまたは処理ユニットなどによって形成される処理回路を含む。回路１８３０および１８８０（または処理回路）は、１つ以上のプロセッサまたは任意のＬＳＩなどの１つ以上のハードウェアとすることができる。送受信機と処理回路との間には入出力点（またはノード）が存在しており、処理回路は動作時にこの入出力点（またはノード）を通じて送受信機を制御する、すなわち受信機および／または送信機を制御して、受信／送信データを交換することができる。送受信機は、送信機および受信機として、１つ以上のアンテナ、増幅器、ＲＦ変調器／復調器などを含むＲＦ（無線周波数）フロントを含むことができる。処理回路は、処理回路によって提供されるユーザデータおよび制御データを送信する、および／または処理回路によってさらに処理されるユーザデータおよび制御データを受信するように送受信機を制御するなどの制御タスクを実施することができる。処理回路はまた、判定、決定、計算、測定などの他の処理を実行する役割を担うこともできる。送信機は、送信の処理およびそれに関連する他の処理を実行する役割を担うことができる。受信機は、受信の処理およびそれに関連する他の処理（チャネルを監視するなど）を実行する役割を担うことができる。
【0153】
さらに、以下に説明するステップ／動作のいずれも、（ＵＥ側の）回路１８３０および／または（基地局側の）回路１８８０によって実行または制御することができることに留意されたい。
【0154】
さらなる説明において、詳細および実施形態は、明示的な記述または文脈がそうでないことを示さない限り、送受信機デバイス、スケジューリングデバイス（またはスケジューリングノード）、および方法のそれぞれに適用される。
【0155】
＜非ＳＤＴデータの到着＞
ＵＥが非アクティブ状態にある、ある時点において、非ＳＤＴ ＤＲＢデータが送信可能になり、したがってＵＥが、非ＳＤＴ ＤＲＢの送信が実行されることを判定するものと想定する。非ＳＤＴ ＤＲＢデータの到着を検出したときに、ＵＥがＳＤＴ手順中でない場合、ＵＥは接続状態に入るためにＲＡＣＨ手順を開始することができる。したがって、非ＳＤＴ ＤＲＢデータの到着を検出したとき、ＵＥはＳＤＴ手順中であると想定する。
ＵＥが非アクティブ状態にある、ある時点において、非ＳＤＴ ＤＲＢデータが送信可能になり、したがってＵＥが、非ＳＤＴ ＤＲＢの送信が実行されることを判定するものと想定する。非ＳＤＴ ＤＲＢデータの到着を検出したときに、ＵＥがＳＤＴ手順中でない場合、ＵＥは接続状態に入るためにＲＡＣＨ手順を開始することができる。したがって、非ＳＤＴ ＤＲＢデータの到着を検出したとき、ＵＥはＳＤＴ手順中であると想定する。
【0156】
図２３に示したように、ＵＥがＳＤＴ手順中であるという記述は、必ずしも、ＵＥがＳＤＴ手順に関連する送信をすでに実行したことを意味するものではなく、ＵＥが非アクティブ状態において（スモール）データが送信されることを判定したことを意味する。したがって、ＳＤＴ手順は、非アクティブ状態において（スモール）データが送信されると判定することから始まることができる、ＳＤＴ手順を開始するＲＡＣＨ手順を含むことができる、および／または、そのＲＡＣＨ手順の後に継続することができる。
【0157】
本明細書における「到着」とは、上位層からの到着を意味する。したがって言い換えれば、非ＳＤＴデータが送信可能になる。さらに、「検出される」という用語は、データが実際に到着したことの検出のみならず、非ＳＤＴ ＤＲＢデータが送信のために到着すると予期されることの検出／判定も含む。
【0158】
図２３に示したように、非ＳＤＴ ＤＲＢデータは、時間ＴＡまたは時間ＴＢに到着する、および／または検出することができる。より具体的には、非ＳＤＴトラフィックの到着のタイミングＴＡは、スモールデータ（例えばＭｓｇ３／ＭｓｇＡ）の最初の送信より前のタイミングを意味する。これに代えて、またはこれに加えて、タイミングＴＡは、ＵＥが自身のＲＡＣＨ送信すべてを実行する前の期間とすることもできる。したがって、ＴＡの期間内に非ＳＤＴトラフィックが到着した場合、スモールデータの送信のための少なくとも１つのＵＬグラント（または送信機会）が存在し、ＵＥはこのＵＬグラント（または送信機会）を利用して、非ＳＤＴトラフィックの到着を示すことができる。特に、ＲＡＣＨ手順の一部としての送信機会が存在する。例えば、図２３に示したように、ＴＡは、ＵＥがＳＤＴ手順をトリガーしたとき、またはその直後に始まることができ、ＵＥがＭｓｇ３／ＭｓｇＡを送信したとき、またはその直前に終了することができる。一方、タイミングＴＢは、スモールデータ（例えばＭｓｇ３／ＭｓｇＡ）の最初の送信後に非ＳＤＴトラフィックが到着することを意味する。したがって、ＴＢの期間内に非ＳＤＴトラフィックが到着した場合、後続のデータ送信が存在するか否かに応じて、ＵＥが非ＳＤＴトラフィックの到着を示すために利用できるＵＬグラントが存在し得る、または存在し得ない。例えば、図２３に示したように、タイミングＴＢは、ＵＥがＭｓｇ３を送信したときから始まり、ＵＥがＲＲＣＲｅｌｅａｓｅメッセージ／ＭｓｇＢを受信する前に終了することができる。さらに、図２３ではＴＢがＴＡよりも短い期間であることが示されているが、ネットワークの決定によってはＴＢの方が長い期間となり得ることに留意されたい。
【0159】
非ＳＤＴ ＤＲＢデータの到着が検出されたとき、ＵＥは、例えばＣＣＣＨメッセージを使用する新しいＲＲＣ再開手順を開始することができる。したがって、（ＳＤＴ ＤＲＢデータを送信するための）進行中のＲＲＣ再開手順が存在していても、ＵＥは新しいＲＡＣＨ手順を開始し、Ｍｓｇ３においてＲＲＣ再開要求を再び送信することができる。しかしながら、やがて発生するＵＬグラントまたは送信機会が存在するか否かに関係なく新しいＲＡＣＨがトリガーされる場合、リソースの利用が非効率的となり、他のＵＥとのＲＡＣＨ衝突が増加する可能性がある。
【0160】
したがって、以下にさらに詳細に説明するＲＡＣＨベースのＳＤＴ手順の場合の処理をまとめると、ＴＡにおいて非ＳＤＴトラフィックが到着した場合、ＵＥは残りの送信機会を利用してトラフィック指示を送信することができる。さらに、ＴＢにおいて非ＳＤＴトラフィックが到着した場合、ＵＥは、ｉ）ＳＤＴ手順の終了前に受信した（１つ以上の）専用ＵＬリソースにおいて非ＳＤＴトラフィック指示をｇＮＢに送信する、または、ｉｉ）（１つ以上の）専用ＵＬリソースを受信していない、または受信する見込みがない場合、接続状態に入るために新しいＲＡＣＨ手順（ＲＲＣ再開手順）を開始する、ことができる。さらに、ＵＥは、予期されるＵＬグラントをもはや受信する見込みがない、言い換えれば、専用ＵＬグラントをもはや受信する見込みがないと（後から）判定した場合にも、新しいＲＡＣＨ手順を開始することができる。
【0161】
＜送信機会＞
一般に、送信機会という用語は、新しいＲＡＣＨ手順（例えば、ＳＤＴ ＤＲＢデータ送信を開始するためのＲＡＣＨ手順、またはすでに開始しているＲＡＣＨ手順に加えて、それとは異なるＲＡＣＨ手順）を開始することなく、トラフィック指示を送信するための機会を意味する。したがって、送信機会は、ＵＥがデータを送信するために使用することのできる（１つ以上の）リソースに関連付けられる。一般に、これらのリソースは、ＳＤＴ手順の一部として受信される専用ＵＬグラントによって示される、または示されると予期される専用リソース、および／または、ＲＡＣＨ手順の送信に使用されるリソース（例えばＭｓｇ３またはＭｓｇＡ）、ならびにコンフィギュアドグラント（ＣＧ）を介してＵＥに割り当てられるリソース、であり得る。特に、送信機会は、ｉ）ＳＤＴ ＤＲＢデータの少なくとも一部を送信するための送信機会、およびｉｉ）ＳＤＴ ＤＲＢデータを送信するための手順の一部として発生すると予期される送信機会、であり得る。
一般に、送信機会という用語は、新しいＲＡＣＨ手順（例えば、ＳＤＴ ＤＲＢデータ送信を開始するためのＲＡＣＨ手順、またはすでに開始しているＲＡＣＨ手順に加えて、それとは異なるＲＡＣＨ手順）を開始することなく、トラフィック指示を送信するための機会を意味する。したがって、送信機会は、ＵＥがデータを送信するために使用することのできる（１つ以上の）リソースに関連付けられる。一般に、これらのリソースは、ＳＤＴ手順の一部として受信される専用ＵＬグラントによって示される、または示されると予期される専用リソース、および／または、ＲＡＣＨ手順の送信に使用されるリソース（例えばＭｓｇ３またはＭｓｇＡ）、ならびにコンフィギュアドグラント（ＣＧ）を介してＵＥに割り当てられるリソース、であり得る。特に、送信機会は、ｉ）ＳＤＴ ＤＲＢデータの少なくとも一部を送信するための送信機会、およびｉｉ）ＳＤＴ ＤＲＢデータを送信するための手順の一部として発生すると予期される送信機会、であり得る。
【0162】
１．すでに既知の送信機会
一般に、送信機会を待機するか否かを判定するとき、その送信機会のリソースがＵＥに既知である場合がある。
一般に、送信機会を待機するか否かを判定するとき、その送信機会のリソースがＵＥに既知である場合がある。
【0163】
一般に、ＳＤＴ ＤＲＢデータを送信するための手順が、ＲＡＣＨ手順において開始される手順である場合、待機するべき送信機会は、ＲＡＣＨ手順の最初の送信とすることができる。例えば、ＳＤＴ手順が２ステップＲＡＣＨ手順において開始され、ＵＥが自身の最初の送信（例えばＭｓｇＡ）をまだ送信していない場合、ＵＥはこの最初の送信を使用してトラフィック指示を送信することができる。言い換えれば、ＵＥは、ＲＡＣＨリソース（例えばＲＡＣＨ機会のリソース）を使用して、ＳＤＴ ＤＲＢデータ（またはその一部）およびトラフィック指示を送信することができる。したがって、非ＳＤＴ ＤＲＢデータは、ＵＥがＲＡＣＨ手順をトリガーした（例えばＲＡＣＨ手順を開始すると決定した）後、かつ、そのＲＡＣＨ手順の最初の送信を送信する前に、ＵＥによって検出されていることができる。例えば、ＵＥが使用する予定の（例えば次の）ＲＡＣＨリソースを待機している間に、非ＳＤＴデータが到着することがある。この場合、（待機するべき、または待機しない）送信機会は、そのＲＡＣＨリソースによって与えることができる。
【0164】
さらに、一般的に、ＳＤＴ ＤＲＢデータを送信するための手順が、ＲＡＣＨ手順において開始される手順である場合、送信機会は、ＲＡＣＨ手順の一部として受信されるアップリンクグラントによって示されている機会とすることができる。例えば、ＳＤＴ手順が、４ステップＲＡＣＨ手順において開始される（開始された、または開始される予定である）。この場合、ＵＥは、ランダムアクセス応答を受信した後、かつ、そのランダムアクセス応答によって示されたリソースを使用してＳＤＴ ＤＲＢデータ（またはその一部）を送信する前に、非ＳＤＴ ＤＲＢデータを検出していることができる。例えば、ＵＥは、Ｍｓｇ２をすでに受信しているが、Ｍｓｇ３をまだ送信していない場合がある。したがって、一般的に、ＵＥはＲＡＣＨ手順の間にＵＬグラントを受信している可能性があり、このＵＬグラントは、例えば、まだ過ぎ去っていない、ＳＤＴデータの送信のための送信機会（リソース）を示している。その場合、（待機するべき、または待機しない）送信機会は、ＵＬグラントによって示されたその送信機会とすることができる。
【0165】
さらに、一般的に、ＳＤＴ ＤＲＢデータを送信するための手順が、ＲＡＣＨ手順において開始される手順である場合、待機するべき送信機会は、ＲＡＣＨ手順の完了後にＳＤＴ ＤＲＢデータを送信するために受信されたアップリンクグラントによって示されている。例えば、ＳＤＴ手順は、ＲＡＣＨ手順（例えば２ステップまたは４ステップのＲＡＣＨ手順）において開始されている。このＲＡＣＨ手順は完了している（例えばＵＥが、スケジューリングデバイスから競合解決ＭＡＣ ＣＥをすでに受信している）が、このＲＡＣＨ手順において開始されたＳＤＴ手順が依然として進行中である場合がある。言い換えれば、ＵＥは、ＳＤＴ ＤＲＢデータの送信のためのＵＬグラントをスケジューリングデバイスから依然として受信する可能性がある。非ＳＤＴ ＤＲＢデータの到着を検出したとき、ＵＥは、まだ過ぎ去っていない、ＳＤＴデータを送信するための送信機会を示すそのようなＵＬグラントを受信していることがある。その場合、（待機するべき、または待機しない）送信機会は、ＵＬグラントによって示されたその送信機会とすることができる。
【0166】
＜既知の送信機会の監視－Ｓ２１４０＞
待機するべき送信機会が存在すると判定した後、ＵＥは、その送信機会を監視することができる（Ｓ２１４０）。その送信機会の（１つ以上の）リソースがＵＥにすでに既知である場合、このステップは、その送信機会が発生するのを待機する（Ｓ２１４０）ことを含むことができる。より具体的には、その送信機会のリソースは以降のどこかで発生し、したがってＵＥは、トラフィック指示の送信のためにそのリソースを使用できるまで待機しなければならない。しかしながら、監視は、その送信機会が発生する前に基地局によってキャンセルまたはプリエンプトされるかどうかを監視することも含むことができ、その場合、ＵＥは、接続状態に入るために新たなＲＡＣＨ手順を開始することができる。
待機するべき送信機会が存在すると判定した後、ＵＥは、その送信機会を監視することができる（Ｓ２１４０）。その送信機会の（１つ以上の）リソースがＵＥにすでに既知である場合、このステップは、その送信機会が発生するのを待機する（Ｓ２１４０）ことを含むことができる。より具体的には、その送信機会のリソースは以降のどこかで発生し、したがってＵＥは、トラフィック指示の送信のためにそのリソースを使用できるまで待機しなければならない。しかしながら、監視は、その送信機会が発生する前に基地局によってキャンセルまたはプリエンプトされるかどうかを監視することも含むことができ、その場合、ＵＥは、接続状態に入るために新たなＲＡＣＨ手順を開始することができる。
【0167】
２．予期されるアップリンク（ＵＬ）グラントによって示される送信機会
一般に、送信機会を待機するか否かを決定するとき、その送信機会のリソースがＵＥに既知ではないことがある。この場合、ＵＥは、その送信機会のリソースを指定するＵＬグラントをスケジューリングデバイスから受信することを予期することができる。以下でさらに説明するように、ＵＥがスケジューリングデバイスからＵＬグラントを受信することを予期することのできるいくつかのシナリオが存在する。
一般に、送信機会を待機するか否かを決定するとき、その送信機会のリソースがＵＥに既知ではないことがある。この場合、ＵＥは、その送信機会のリソースを指定するＵＬグラントをスケジューリングデバイスから受信することを予期することができる。以下でさらに説明するように、ＵＥがスケジューリングデバイスからＵＬグラントを受信することを予期することのできるいくつかのシナリオが存在する。
【0168】
一般に、待機するべき送信機会は、アップリンクグラントによって示されると予期することができる。さらに、一般的に、ＵＥは、ＳＤＴデータを送信するためのリソースを示すそのＵＬグラントをＳＤＴ手順の一部として受信することを予期することができる。以下にさらに説明するように、（予期される）アップリンクグラントは、ＳＤＴ手順を開始するＲＡＣＨ手順の一部として受信されることが予期される場合もあれば、ＲＡＣＨ手順の一部としてではなく（ただし依然としてＳＤＴ手順の一部として）受信されることが予期される場合もある。言い換えれば、ＵＬグラントは、ＲＡＣＨ手順の完了後に、ＳＤＴ ＤＲＢデータまたはＳＤＴ ＤＲＢデータの一部を送信するために受信されることが予期されるＵＬグラントである場合もある。
【0169】
例えば、回路が送受信機を制御してＲＡＣＨ手順の最初の送信を送信した後にアップリンクグラントが受信されることを予期することができる。特に、ＲＡＣＨ手順は４ステップＲＡＣＨ手順とすることができ、Ｍｓｇ１を送信した後、ＵＥはＭｓｇ２によってＵＬグラントを受信することを予期する。
【0170】
これに代えて、またはこれに加えて、回路が送受信機を制御して、さらに送信されるＳＤＴ ＤＲＢデータの量（例えばゼロではない量）を示すバッファ状態報告（ＢＳＲ）を送信した後に、アップリンクグラントが受信されることを予期することができる。このＢＳＲは、ＲＡＣＨ手順の一部として（例えばＭｓｇＡまたはＭｓｇ３において）送信されていることもあれば、ＲＡＣＨ手順の完了後にＳＤＴ ＤＲＢデータの一部と一緒に送信されていることもある。例えば（図１７に示したように）、ＵＥは、（例えばＳＤＴ ＤＲＢデータのサイズを考慮して）ＭｓｇＡ／Ｍｓｇ３においてＳＤＴ ＤＲＢデータ全体を送信しないことができる。したがって、ＵＥは、ＳＤＴ ＤＲＢデータをセグメント化し、ＳＤＴ ＤＲＢデータの一部のみと、残りのＳＤＴ ＤＲＢデータのゼロでないサイズを示すＢＳＲとを、ＭｓｇＡ／Ｍｓｇ３において送信することができる。次に、ＵＥは、ＳＤＴ ＤＲＢデータの残りの部分を送信するために、（もはやＲＡＣＨ手順の一部ではない）さらなるアップリンクグラントを待機する、および／または、予期することができる。
【0171】
さらに、これに代えて、またはこれに加えて、ＢＳＲを送信した後、回路が送受信機を制御してＳＤＴ ＤＲＢデータの一部を送信した後に、アップリンクグラントが受信されることを予期することができ、この場合にＳＤＴ ＤＲＢデータの一部の量は、ＢＳＲによって示した量よりも小さい。言い換えれば、ＳＤＴ ＤＲＢデータに関するＢＳＲを送信した後、ＵＥは、そのＢＳＲの送信以降、そのＢＳＲによって示したサイズのＳＤＴ ＤＲＢデータを（正常に）送信するまで、ＵＬグラントを予期することができる。
【0172】
＜送信機会の監視－Ｓ２１４０＞
待機するべき送信機会が存在すると判定した後、ＵＥは、その送信機会を監視することができる（Ｓ２１４０）。その送信機会の（１つ以上の）リソースがＵＬグラントによって示されることが予期される場合、このステップは、そのＵＬグラントを待機する（Ｓ２１４０）ことを含むことができる。この待機は、ＵＬグラントについてＰＤＣＣＨを監視することを含むことができる。ＵＬグラントが受信された場合、ＵＥは、すでに上で説明したように、送信機会の待機を継続することができる。
待機するべき送信機会が存在すると判定した後、ＵＥは、その送信機会を監視することができる（Ｓ２１４０）。その送信機会の（１つ以上の）リソースがＵＬグラントによって示されることが予期される場合、このステップは、そのＵＬグラントを待機する（Ｓ２１４０）ことを含むことができる。この待機は、ＵＬグラントについてＰＤＣＣＨを監視することを含むことができる。ＵＬグラントが受信された場合、ＵＥは、すでに上で説明したように、送信機会の待機を継続することができる。
【0173】
しかしながら、一般に、ＵＥは、予期されるアップリンクグラントを受信しないことがある。これに対応して、ＵＥは、送信機会が発生するかどうかを監視している（Ｓ２１４０）ときに、特定の条件下で、予期されるアップリンクグラントを受信する見込みがない、および／または、機会が発生する見込みがない、ものと判定することができる。特に、待機するべき送信機会は、予期されるアップリンクグラントが受信されておらず、受信されることがもはや予期されないときには、発生する見込みがないものとすることができる。これに対応して、ＵＥは、送信機会が発生しないと判定する、および／または、接続状態に入るために（新しい）ＲＡＣＨ手順を開始することができる。特に、ＵＥがＲＲＣＲｅｌｅａｓｅメッセージの受信時にＵＬグラントを受信していない場合、ＵＥはＲＲＣ再開手順を開始することができる。特に、ＵＥはその後、ただちに（例えば、ＳＤＴ手順および／またはそのＳＤＴ手順を開始したＲＡＣＨ手順の終了を待たずに）レガシーＲＲＣ再開手順を開始することができる。
【0174】
例えば、ＳＤＴ ＤＲＢデータを送信するための手順の終了を示す指示を送受信機が受信した場合、予期されるアップリンクグラントを受信する見込みがないものとすることができる。ここで、ＳＤＴ手順の終了を示すこの指示は、Ｍｓｇ４またはＭｓｇＢの受信であり得ることに留意されたい。ただし、上述したように、ＲＡＣＨ手順は、一般にＳＤＴ手順よりも早く終了することがある。より具体的には、図１７にも示したように、ＲＡＣＨ手順は、一般に競合が解決されたときに終了するのに対し、ＳＤＴ手順は、一般にＲＲＣＲｅｌｅａｓｅメッセージが受信されたときに終了する。したがって、ＳＤＴ手順の終了を示す指示は、基地局から受信されるＲＲＣＲｅｌｅａｓｅメッセージであってもよい。
【0175】
一般には、これに代えて、またはこれに加えて、ＳＤＴ ＤＲＢデータの少なくとも一部の最初の送信または前の送信から所定の時間が経過した場合、予期されるアップリンクグラントを受信する見込みがないものとすることができる。所定の時間は、例えば、上で説明したＴ３１９タイマーまたはＴ３１９に類似するタイマーによって与えることができる。しかしながら、ＵＬグラントの受信が依然として予期されるかどうかを判定するためにＵＥによって使用される所定の時間は、ＵＬグラントの受信をＵＥが待機する別の所定の期間であってもよい。
【0176】
＜待機するべき送信機会が存在するか否かの判定（Ｓ２１２０）＞
１．ＲＡＣＨ手順
ＲＡＣＨベースのＳＤＴ手順中に非ＳＤＴトラフィックが到着した場合、ＵＥは、ＲＡＣＨ手順の最初の送信をまだ送信していないならば、待機するべき送信機会が存在すると判定することができる（言い換えれば、非ＳＤＴトラフィックがＴＡにおいて到着する）。その後、ＵＥは送信機会を待機し（Ｓ２１４０）、その送信機会を使用してトラフィック指示を送信することができる。
１．ＲＡＣＨ手順
ＲＡＣＨベースのＳＤＴ手順中に非ＳＤＴトラフィックが到着した場合、ＵＥは、ＲＡＣＨ手順の最初の送信をまだ送信していないならば、待機するべき送信機会が存在すると判定することができる（言い換えれば、非ＳＤＴトラフィックがＴＡにおいて到着する）。その後、ＵＥは送信機会を待機し（Ｓ２１４０）、その送信機会を使用してトラフィック指示を送信することができる。
【0177】
さらに、非ＳＤＴトラフィックがＴＢにおいて到着し、ＵＬグラントがｇＮＢによってまもなく割り当てられる（すなわちＢＳＲを前に送信したが、ｇＮＢがＳＤＴ ＤＲＢのＢＳＲに対するグラントを割り当てていない）とＵＥが予期する場合、ＵＥは待機するべき送信機会が存在すると判定することができる。特に、ＵＥは、待機するべきその送信機会のリソースが、その予期されるＵＬグラントによって指定されるものと判定することができる。次いで、ＵＥは、次のＵＬグラントを待機することができ（Ｓ２１４０）、そのグラントにおいて非ＳＤＴトラフィック指示をｇＮＢに送信する。
【0178】
しかしながら、一般的に、非ＳＤＴトラフィックがＴＢにおいて到着した場合に、ＵＥはＤＣＣＨを送信するためのさらなるＵＬグラントを有さないことがあり、したがってＤＣＣＨを送信するためだけに新しいＲＡＣＨを開始する必要が生じることがある。したがって、ＳＤＴ手順においてＳＤＴ ＤＲＢのみを送信できる場合、ＵＥが指示を送信するには、別のＵＬグラントが必要である。したがって、ＲＡＣＨベースのＳＤＴ手順中に非ＳＤＴトラフィックが到着した場合に、ＵＥがＲＡＣＨ手順の最初の送信をすでに送信しており、かつＵＬグラントを受信する見込みがない場合、ＵＥは待機するべき送信機会が存在しないと判定することができる。特に、ＵＥは、（すべての）ＳＤＴ ＤＲＢデータを送信した後（例えば回路１８３０が送受信機１８２０を制御してＳＤＴ ＤＲＢデータをすでに送信したとき）、待機するべき送信機会が存在しないと判定することができる。言い換えれば、非ＳＤＴトラフィックがＴＢにおいて到着し、ＵＬグラントがｇＮＢによって割り当てられる予定であることをＵＥが予期しない場合（すなわち、ＢＳＲを前に送信していない、またはＢＳＲがｇＮＢによって解決されている場合）、ＵＥは、待機するべき送信機会が存在しないと判定し、（例えば、ＳＤＴ手順および／またはそのＳＤＴ手順を開始したＲＡＣＨ手順の終了を待たずにただちに）レガシーＲＲＣ再開手順を開始することができる。
【0179】
待機するべき送信機会が存在するかどうかの判定Ｓ２１２０を含む、ＲＡＣＨベースのＳＤＴ手順中の非ＳＤＴトラフィックの到着の処理について、この処理を例示的に示している図２４を参照しながらもう一度要約しておく。より具体的には、図２４では、ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥにあったときにＳＤＴトラフィックが到着し、それに応じてＵＥがＳＤＴ手順をトリガーした（Ｓ２４１０）ものと、例示的に想定している。さらに、ＵＥはＳＤＴ手順を開始するために４ステップＲＡＣＨ手順のＲＡＣＨプリアンブルをすでに送信したものと想定する。ここで「トリガーした」という用語は、ＳＤＴ手順を実行することをＵＥが内部的に決定／判定したことを意味するのに対し、「開始する」という用語は、ＳＤＴ手順を実行するというＵＥの決定をスケジューリングデバイスに認識させることのできる、ＳＤＴ手順の最初のメッセージを意味することに留意されたい。したがって、Ｓ２４１０の後、ＵＥは、スモールデータを送信するためにＲＡＣＨベースのＳＤＴ手順に入る。その後、非ＳＤＴトラフィックが到着する、および／またはＵＥによって検出されるものとさらに想定する。
【0180】
さらに理解できるように、非ＳＤＴトラフィックが到着すると、ＵＥはまず、最初のＲＡＣＨメッセージをすでに送信したか否か（Ｓ２４２０で「はい」または「いいえ」）を判定することができる。しかしながら、ＵＥは最初に、進行中のＳＤＴ手順が依然として存在するか否か（Ｓ２４３０で「はい」または「いいえ」）、すなわち、ＳＤＴ手順を終了させるメッセージ（例えばＲＲＣＲｅｌｅａｓｅメッセージ）をすでに受信したか否かを判定してもよく、このことは、Ｓ２４２０およびＳ２４３０の両方で「いいえ」を意味することに留意されたい。言い換えれば、ＵＥは、Ｓ２４２０、Ｓ２４３０、Ｓ２４４０、およびＳ２４５０に関連付けられる個々の判定を実行することができるが、必ずしも実行しなくてもよく、特に、図２４に示した特定の順序でこれらの判定を実行しなくてもよい。
【0181】
図２４に示したように、ＵＥがＲＡＣＨ手順の自身のすべてのメッセージを送信する（例えばＭｓｇ３／ＭｓｇＡを送信する）前に非ＳＤＴトラフィックが到着した場合（Ｓ２４２０で「はい」）、ＵＥは、後続のＲＡＣＨメッセージに、非ＳＤＴ ＤＲＢデータの検出を示すトラフィック指示を含めることができる（Ｓ２４２１）。言い換えれば、非ＳＤＴ ＤＲＢデータが期間ＴＡ内に検出された場合、ＵＥは、待機するべき送信機会（すなわち後続のＲＡＣＨメッセージ）が存在すると判定することができる。図２４にさらに示したように、スケジューリングデバイスは、このトラフィック指示に応答して、非アクティブ状態に戻ることを示すメッセージ（例えばＲＲＣＲｅｌｅａｓｅメッセージ）ではなく、接続状態への遷移を示すメッセージ（例えばＲＲＣＲｅｓｕｍｅメッセージ）によってＲＡＣＨ手順を終了させることができる。したがって、ＵＥは、接続状態への遷移を示すメッセージを受信し（Ｓ２４２２）、接続状態（例えばＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態）に入ることができる（Ｓ２４２３）。その後、ＵＥは非ＳＤＴ ＤＲＢデータを送信することができる。
【0182】
さらに理解できるように、ｉ）（Ｓ２４２０で「いいえ」）ＵＥがＲＡＣＨ手順の自身のすべてのメッセージ（例えばＭｓｇ３／ＭｓｇＡ）を送信した後、かつｉｉ）（Ｓ２４３０で「いいえ」）ＵＥが、ＳＤＴ手順を終了するメッセージを受信した（Ｓ２４３１）後に、非ＳＤＴトラフィックが到着した場合、ＵＥはＲＲＣ＿ＩＮＡＣＴＩＶＥにある／にとどまる（Ｓ２４３２）。言い換えれば、ＵＥは、非ＳＤＴ ＤＲＢデータが検出されたときに、ＳＤＴ手順を終了するメッセージをすでに受信している場合、および／または、進行中のＳＤＴ手順が存在しない場合、待機するべき送信機会が存在しないと判定することができる。したがって、ＵＥは、接続状態に入って非ＳＤＴ ＤＲＢデータを送信できるようにするために、ＲＡＣＨ手順（レガシーＲＲＣ再開手順）を開始することができる。
【0183】
さらに、ｉ）ＵＥがＲＡＣＨ手順の自身の送信すべてを実行した後に非ＳＤＴトラフィックが到着し（Ｓ２４２０で「いいえ」）、かつｉｉ）ＳＤＴ手順の終了を示すメッセージを受信する前に非ＳＤＴトラフィックが到着し（Ｓ２４３０で「はい」）、かつｉｉｉ）ＳＤＴ ＤＲＢデータのゼロではないバッファサイズを示すバッファ状態報告をＵＥが送信していない（Ｓ２４４０で「いいえ」）場合、ＵＥは、接続状態に入って（Ｓ２４４２）非ＳＤＴ ＤＲＢデータを送信できるようにするために、ＲＡＣＨ手順（レガシーＲＲＣ再開手順）を開始することができる（Ｓ２４４１）。特に、ｉ）ＵＥがＲＡＣＨ手順の自身のすべての送信を実行し、かつｉｉ）ＳＤＴ ＤＲＢデータのゼロではないバッファサイズを示すバッファ状態報告をＵＥが送信していない場合、ＵＥは、待機するべき送信機会が存在しないと判定することができる。同様に、ＵＥがＢＳＲを送信したが、対応するＵＬグラントをすでに受信しており、それらのＵＬグラントを使用してスモールデータを送信した（それらのＵＬグラントを使用して、ＢＳＲに示したサイズのデータを送信した）場合、ＵＥは、待機するべき送信機会が存在しないと判定することができる。
【0184】
一方、ｉ）ＵＥがＲＡＣＨ手順の自身の送信すべてを実行した後に非ＳＤＴトラフィックが到着し（Ｓ２４２０で「いいえ」）、かつｉｉ）ＳＤＴ手順の終了を示すメッセージを受信する前に非ＳＤＴトラフィックが到着し（Ｓ２４３０で「はい」）、かつｉｉｉ）ＳＤＴ ＤＲＢデータのゼロではないバッファサイズを示すバッファ状態報告をＵＥが送信した（Ｓ２４４０で「はい」）場合、ＵＥは、待機するべき送信機会（すなわち、そのＢＳＲに応答して受信されることが予期されるＵＬグラントによって示されると予期される送信）が存在すると判定することができる。したがって、ＵＥは、そのＵＬグラントを待機する、および／またはＰＤＣＣＨを監視することができる。
【0185】
その予期されるＵＬグラントを、基地局からの対応するメッセージによってＳＤＴ手順が終了する前に受信した場合（Ｓ２４５０で「はい」）、ＵＥは、ＵＬグラントによって示されたリソースを使用する送信に、非ＳＤＴ ＤＲＢデータの検出を示すトラフィック指示を含めることができる（Ｓ２４５１）。ＵＬグラントの受信は、待機するべき送信機会が発生することを意味し得る。トラフィック指示に応答して、スケジューリングデバイスは、非アクティブ状態に戻ることを示すメッセージ（例えばＲＲＣＲｅｌｅａｓｅメッセージ）ではなく、接続状態への遷移を示すメッセージ（例えばＲＲＣＲｅｓｕｍｅメッセージ）によってＳＤＴ手順を終了することができる。したがって、ＵＥは、接続状態への遷移を示すメッセージを受信し（Ｓ２４５２）、接続状態（例えばＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態）に入ることができる（Ｓ２４５３）。その後、ＵＥは、非ＳＤＴ ＤＲＢデータを送信することができる。
【0186】
一方、ＵＥが、ＵＬグラントを受信する前に、ＳＤＴ手順を終了するメッセージ（例えばＲＲＣＲｅｌｅａｓｅメッセージ）を受信した場合（Ｓ２４５０で「いいえ」）、ＵＥは、Ｓ２４４１およびＳ２４４２に関連して上にすでに説明したように、新しいＲＡＣＨ手順を開始することができる。これは、予期されるＵＬグラントがもはや期待されないものと判定することを含むことができ、待機するべき送信機会が発生しないことを意味する。
【0187】
２．コンフィギュアドグラント（ＣＧ）手順
すでに上述したように、ＳＤＴ ＤＲＢデータを送信するための手順は、ＳＤＴ ＤＲＢデータを送信するためのコンフィギュアドグラント（ＣＧ）手順であってもよい。以下でさらに詳細に説明するように、ＣＧベースのＳＤＴ手順中に非ＳＤＴ ＤＲＢトラフィックが到着した場合、ＵＥは、ｉ）ＳＤＴ手順の終了前に受信した専用ＵＬリソースにおいて非ＳＤＴトラフィック指示をｇＮＢに送信する、または、ｉｉ）レガシーＲＲＣ再開手順を開始する、ことができる。ここで、専用ＵＬリソースとは、ＵＥが非アクティブ状態に入る前／入ったときに、ＳＤＴ ＤＲＢデータの送信用にＵＥに対して設定されているＣＧリソースとすることができる。
すでに上述したように、ＳＤＴ ＤＲＢデータを送信するための手順は、ＳＤＴ ＤＲＢデータを送信するためのコンフィギュアドグラント（ＣＧ）手順であってもよい。以下でさらに詳細に説明するように、ＣＧベースのＳＤＴ手順中に非ＳＤＴ ＤＲＢトラフィックが到着した場合、ＵＥは、ｉ）ＳＤＴ手順の終了前に受信した専用ＵＬリソースにおいて非ＳＤＴトラフィック指示をｇＮＢに送信する、または、ｉｉ）レガシーＲＲＣ再開手順を開始する、ことができる。ここで、専用ＵＬリソースとは、ＵＥが非アクティブ状態に入る前／入ったときに、ＳＤＴ ＤＲＢデータの送信用にＵＥに対して設定されているＣＧリソースとすることができる。
【0188】
ＵＥが（例えば回路１８３０、１８３５、および／または１９３６によって）、ＣＧベースのＳＤＴ手順中に非ＳＤＴ ＤＲＢデータの到着を検出したとき、ＣＧ手順の次のリソースが（時間領域において）次のＲＡＣＨリソースよりも早い場合、（例えばステップＳ２１２０の一部として回路１８３０、１８３５、または回路１９３７によって）待機するべき送信機会が存在すると判定することができる。特に、この判定ステップは、ＣＧ手順の（１つ以上の）次のリソースが、待機するべき送信機会であると判定することを含むことができる。その後、ＵＥ（例えば関連する回路）は、その（１つ以上の）次のＣＧリソースを使用してトラフィック指示を送信することができる。例えば、（上ですでに説明したように）その送信機会を待機した（Ｓ２１４０）後、ＵＥ（例えば回路１８３０）は、その送信機会を使用してトラフィック指示を送信するように送受信機を制御することができる。
【0189】
一方、ＣＧ手順の次のリソースが次のＲＡＣＨリソースよりも遅い場合、（例えば同じくステップＳ２１２０の一部として）待機するべき送信機会が存在しないと判定することができる。この場合、ＵＥは、上記次のＲＡＣＨリソースを使用して、接続状態に入るためにＲＡＣＨ手順を開始する（Ｓ２１３０）ことができる。特に、このステップは、ＲＡＣＨ手順の最初の送信（例えばＭｓｇ１またはＭｓｇＡ）を送信するために上記次のＲＡＣＨリソースを使用することを含むことができる。
【0190】
ＣＧベースのＳＤＴ手順の場合、判定ステップＳ２１２０は、次のＲＡＣＨリソースが次のＣＧリソースよりも早い（あるいは、次のＣＧリソースよりも遅くない）かどうかを判定すること、を含むことができることに留意されたい。
【0191】
言い換えれば、ＳＤＴ送信のためのＣＧリソースがＵＥに設定されているときに非ＳＤＴトラフィックが到着した場合、ＵＥは、どちらの遅延が短いかに応じて、ＣＧリソース（の一部）において非ＳＤＴトラフィック指示をスケジューリングデバイスに送信する、またはレガシーＲＲＣ再開手順を開始することができる。
【0192】
これに代えて、遅延しきい値をＵＥにシグナリングすることができる。その場合、ＵＥは、遅延しきい値と、次のＣＧリソースまでの時間とを比較し、それに応じて決定を行うことができる。例えば、ＵＥは、次のＣＧリソースまでの時間が遅延しきい値よりも小さい（あるいは遅延しきい値よりも大きくない）場合（たとえ次のＲＡＣＨリソースまでの遅延が次のＣＧリソースまでの遅延よりも小さい場合であっても）、次のＣＧリソースが、待機するべき送信機会であると判定することができる。言い換えれば、ＵＥは、以下の条件、すなわち、ｉ）次のＣＧリソースが次のＲＡＣＨリソースよりも早い（あるいは次のＲＡＣＨリソースよりも遅くない）、またはｉｉ）次のＣＧリソースまでの時間が遅延しきい値よりも小さい（あるいは遅延しきい値よりも大きくない）、のうちの少なくとも一方が該当する場合、次のＣＧリソースが、待機するべき送信機会であると判定することができる。したがって、ＵＥは、以下の条件、すなわち、ｉ）次のＣＧリソースが次のＲＡＣＨリソースよりも遅い（あるいは次のＲＡＣＨリソースよりも早くない）、およびｉｉ）次のＣＧリソースまでの時間が遅延しきい値よりも大きい（あるいは遅延しきい値よりも小さくない）、の両方が該当する場合、接続状態に入るためにＲＡＣＨ手順を開始するように決定することができる。
【0193】
このような遅延しきい値により、他のＵＥとのＲＡＣＨ衝突の確率などのトラフィック状況を考慮して、ＵＥが許容する遅延を柔軟に調整することができる。
【0194】
次のＣＧリソースが次のＲＡＣＨリソースと同じ遅延を有する場合（言い換えれば、次のＣＧリソースおよび次のＲＡＣＨリソースのどちらも、より早くない）、ＵＥはＣＧリソースを選択することができ、この選択は、他のＵＥとの競合が回避されるという利点がある。
【0195】
＜非ＳＤＴ ＤＲＢトラフィックの指示＞
トラフィック指示は、ＵＥが非ＳＤＴ ＤＲＢデータを検出したこと、非ＳＤＴ ＤＲＢデータが到着したこと、および／または、非ＳＤＴ ＤＲＢデータが到着すると予期されること、をスケジューリングデバイスに示す。したがって、ＵＥおよび基地局の両方は、以下でさらに説明するそれぞれのトラフィック指示を理解する。特に、ＵＥ（例えば回路１８３０および／または１８３５）は、それぞれのトラフィック指示を生成する、および／または、送信、特にスモールデータの送信に含めることができる。基地局（例えば回路１８８０、１８８５、および／または２０３６）は、送信、特にスモールデータの送信からトラフィック指示を取り出すことができる、および／または、取り出されたトラフィック指示を、ＵＥが意図しているとおりに解釈することができる。
トラフィック指示は、ＵＥが非ＳＤＴ ＤＲＢデータを検出したこと、非ＳＤＴ ＤＲＢデータが到着したこと、および／または、非ＳＤＴ ＤＲＢデータが到着すると予期されること、をスケジューリングデバイスに示す。したがって、ＵＥおよび基地局の両方は、以下でさらに説明するそれぞれのトラフィック指示を理解する。特に、ＵＥ（例えば回路１８３０および／または１８３５）は、それぞれのトラフィック指示を生成する、および／または、送信、特にスモールデータの送信に含めることができる。基地局（例えば回路１８８０、１８８５、および／または２０３６）は、送信、特にスモールデータの送信からトラフィック指示を取り出すことができる、および／または、取り出されたトラフィック指示を、ＵＥが意図しているとおりに解釈することができる。
【0196】
一般に、トラフィック指示は、非ＳＤＴ ＤＲＢが（例えば近い将来に）到着することをＵＥが予期していることを示すこともできる。言い換えれば、非ＳＤＴデータが実際に到着する前に、ＵＥがそのような到着を予期している場合、ＵＥは非ＳＤＴデータが到着するものと判定し、さらにトラフィック指示を使用して到着を基地局に示すことができる。
【0197】
一般に、トラフィック指示は、ｉ）アップリンクグラントによって示されたリソースを使用するＳＤＴ ＤＲＢデータの少なくとも一部、および／または、ｉｉ）ＳＤＴ ＤＲＢデータの量（例えばさらに送信される量）を示すバッファ状態報告（ＢＳＲ）、と一緒に送信することができる。一般に、非ＳＤＴ ＤＲＢデータのＢＳＲを、トラフィック指示を含むメッセージに含めることもできる、あるいはトラフィック指示とすることもできる。ただし、ＳＤＴ手順のトリガー時にＵＥが非ＳＤＴ ＤＲＢを再開しない場合、非ＳＤＴ ＤＲＢからのトラフィックがレイヤ２のバッファに到達し得ないため、ＵＥは非ＳＤＴ ＤＲＢのＢＳＲを生成できない場合がある。
【0198】
非ＳＤＴトラフィック指示は、非ＳＤＴトラフィックの到着をｇＮＢに伝えるためのものであり、以下にさらに説明するように、ＭＡＣレベルの指示またはＲＲＣレベルの指示のいずれかとすることができる。
【0199】
＜非ＳＤＴ ＤＲＢトラフィックのＭＡＣレベル指示＞
１．ＭＡＣサブヘッダによるトラフィック指示
一般に、トラフィック指示は、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングすることができ、ＬＣＩＤの事前定義値は、非ＳＤＴ ＤＲＢデータが検出されたことを示す。
１．ＭＡＣサブヘッダによるトラフィック指示
一般に、トラフィック指示は、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングすることができ、ＬＣＩＤの事前定義値は、非ＳＤＴ ＤＲＢデータが検出されたことを示す。
【0200】
例えば、非ＳＤＴトラフィックの到着を示すＬＣＩＤの事前定義値は、ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていないことを（さらに）示すことができる。このことは図２５に示してあり、トラフィック指示は、ＬＣＩＤインデックス＝５０を有する最後のＭＡＣサブヘッダに対応している。一般に、特定のＬＣＩＤインデックス（例えば図２５および以下の表１に示したようにインデックス＃５０）を有するＭＡＣサブヘッダを使用して、非ＳＤＴトラフィックの到着を示すことができ、このときサブヘッダの後ろにＢＳＲ ＭＡＣ ＣＥを付加しない。言い換えれば、トラフィック指示を含むＭＡＣサブフレーム（すなわち、その特定／所定のＬＣＩＤインデックスを有するＭＡＣサブヘッダ）は、ＭＡＣ ＣＥを伝えない。例えば、このＭＡＣサブフレームは、ＭＡＣサブヘッダから構成することができる。
【0201】
非ＳＤＴ ＤＲＢデータの到着を示すサブヘッダにＢＳＲ ＭＡＣ ＣＥを付加しないことで、ＵＥは、ＳＤＴ手順の開始時に非ＳＤＴ ＤＲＢを再開しないことができる。より具体的には、上位層（例えばＳＤＡＰ層）における非ＳＤＴデータの到着を認識する／検出すると、ＵＥはその時点でそのようなＭＡＣサブヘッダを送信して、非ＳＤＴデータの到着を通知することができる。ＵＥは非ＳＤＴデータのＢＳＲを送信する必要がないため、ＵＥは非ＳＤＴ ＤＲＢを再開する必要がない。さらに、ＭＡＣサブヘッダは通常８ビットのみを消費し、一方でＢＳＲ ＭＡＣ ＣＥは少なくとも１６ビット（ショートＢＳＲの８ビット＋サブヘッダの８ビット）を消費するため、オーバーヘッドを減らすことができる。
【表2】
【0202】
あるいは、非ＳＤＴトラフィックの到着を示すＬＣＩＤは、ＢＳＲ ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていることを（さらに）示すことができ、ＢＳＲ ＭＡＣ ＣＥは、さらに送信されるＳＤＴ ＤＲＢデータの量を示す。
【0203】
したがって、非ＳＤＴトラフィックが到着したときに、ＵＥがＳＤＴ ＤＲＢのいくつかの保留中のデータを依然として保持している場合、特定のＬＣＩＤインデックス番号（例えばインデックス＃５１）を有するＭＡＣサブヘッダを使用し、このサブヘッダの後に、残りのＳＤＴ ＤＲＢデータの量を示すショートＢＳＲ ＭＡＣ ＣＥを付加することによって、ＵＥはスケジューリングデバイスにそのような状況を通知することができる。このことは図２６に示してあり、トラフィック指示は、ＬＣＩＤインデックス＝５１を有する最後のＭＡＣサブヘッダに対応する。図から理解できるように、ＬＣＩＤインデックス＝５１を有するこのＭＡＣサブヘッダに、残りのＳＤＴ ＤＲＢデータのサイズを示すショートＢＳＲ ＭＡＣ ＣＥが付加されている。
【0204】
非ＳＤＴ ＤＲＢデータの到着を示すサブヘッダにＢＳＲ ＭＡＣ ＣＥを付加することにより、残りのＳＤＴ ＤＲＢデータのサイズを示すことが容易になり、非ＳＤＴ ＤＲＢのバッファサイズは報告されないことが予期されるため、ＳＤＴ手順の開始時にＵＥが非ＳＤＴ ＤＲＢを再開しなくてよいようにすることができる。
【0205】
あるいは、ＳＤＴ手順の開始時に非ＳＤＴ ＤＲＢを再開する場合、ＢＳＲ ＭＡＣ ＣＥを使用して、送信される非ＳＤＴ ＤＲＢデータの量を示すこともできることに留意されたい。
【0206】
さらに、一般に、（ＭＡＣ ＣＥが付加されていないこと、および付加されていることを示す）ＭＡＣサブヘッダの一方または両方を提供することができることに留意されたい。両方が提供される場合（例えば、規格に定義されている、またはスケジューリングデバイスによって設定される）、ＵＥは、適切な場合には（例えばバッファサイズがゼロでない場合）、ＳＤＴ ＤＲＢバッファサイズを示すためにＣＥが付加されている、トラフィック指示のためのＭＡＣサブヘッダを使用することができ、オーバーヘッドを削減するためには、ＣＥが付加されていない、トラフィック指示のためのＭＡＣサブヘッダを使用することができる。
【0207】
２．ＭＡＣ制御要素によるトラフィック指示
一般に、トラフィック指示を、ＭＡＣ制御要素（ＣＥ）の一部とすることができる。例えば、ＭＡＣ ＣＥのうちの１ビットが、非ＳＤＴ ＤＲＢデータが検出されたか否かを示し、ＭＡＣ ＣＥのうちの２ビットが、非アクティブ状態でのデータの送信をサポートするＬＣＧのうち、ＳＤＴ ＤＲＢデータの論理チャネルグループ（ＬＣＧ）を示し、ＭＡＣ ＣＥのうちの５ビットが、示されたＬＣＧに対応する、さらに送信されるＳＤＴ ＤＲＢデータ量を示す。
一般に、トラフィック指示を、ＭＡＣ制御要素（ＣＥ）の一部とすることができる。例えば、ＭＡＣ ＣＥのうちの１ビットが、非ＳＤＴ ＤＲＢデータが検出されたか否かを示し、ＭＡＣ ＣＥのうちの２ビットが、非アクティブ状態でのデータの送信をサポートするＬＣＧのうち、ＳＤＴ ＤＲＢデータの論理チャネルグループ（ＬＣＧ）を示し、ＭＡＣ ＣＥのうちの５ビットが、示されたＬＣＧに対応する、さらに送信されるＳＤＴ ＤＲＢデータ量を示す。
【0208】
言い換えれば、ＳＤＴ ＤＲＢのバッファ状態を報告するときに、新しいＢＳＲ ＭＡＣ ＣＥを使用して、非ＳＤＴ ＤＲＢデータの到着を示すことができる。図２７は、そのような例示的な新しいＭＡＣ ＣＥを示している。より具体的には、図２７の上段は、レガシーショートＢＳＲを示しており、下段は、トラフィック指示を含む例示的なＭＡＣ ＣＥを示している。図２７から理解できるように、レガシーショートＢＳＲ ＭＡＣ ＣＥは８ビットを含み、そのうちの３ビット（図２７では最初の３ビット）が、ＬＣＧ ＩＤを示すために使用され、（それ以外の）５ビット（図２７では最後の５ビット）が、バッファサイズを示すために使用される。ここで、各ＳＤＴ ＤＲＢは通常では１つのＬＣＧにマッピングされ（多対１のマッピングも可能である）、そのようなマッピングはｇＮＢによって設定されることに留意されたい。
【0209】
新しいＢＳＲ ＭＡＣ ＣＥは、ＵＥがどのＬＣＧを報告しているかを示すために２ビット（図２７では最初の２ビット）のみを使用するという点において、レガシーのショートＢＳＲ ＭＡＣ ＣＥとは異なる。例えば、いくつかのＬＣＧはサスペンドされ、いくつかのＬＣＧのみがアクティブである場合がある。言い換えれば、ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥにおいて有することのできるアクティブなＬＣＧの最大数を４とすることができる。したがって、新しいＢＳＲ ＭＡＣ ＣＥは、非アクティブ状態でのデータの送信をサポートするＬＣＧのバッファサイズを示すためにのみ使用することができる。言い換えれば、新しいＢＳＲ ＭＡＣ ＣＥでは、ＬＣＧを示すために使用されるビット数を減らし、空いたビットを再利用することによって、サスペンドされたＬＣＧ／ＤＲＢに関するＢＳＲが不可能である（トラフィックがＬ２バッファに流れないため）ことを利用する。
【0210】
さらに、新しいＢＳＲ ＭＡＣ ＣＥでは、依然として５ビット（図２７では最後の５ビット）を使用してバッファサイズを報告し、残りの１ビット（図２７では３番目のビット）を使用して、非ＳＤＴ ＤＲＢの到着を示す。図２７に示したビットの順序、特に非ＳＤＴトラフィックを示すビットの位置は例示に過ぎないことに留意されたい。例えば、非ＳＤＴトラフィックを示すビットの位置は、任意の他の位置、例えば最初または最後（８番目）の位置であってもよい。
【0211】
このような新しいＢＳＲ ＭＡＣ ＣＥを使用すると、新しいフォーマットではＳＤＴ ＤＲＢデータのＢＳＲのみならず非ＳＤＴトラフィックの到着を報告できるため、シグナリングオーバーヘッドを減らすことができる。また、非アクティブなＬＣＧのＢＳＲが期待されないため、ＵＥはＳＤＴ手順の開始時に非ＳＤＴ ＤＲＢを再開しないことができる。
【0212】
＜ＲＲＣレベルの指示＞
一般に、トラフィック指示は無線リソース制御（ＲＲＣ）レベルの指示であってもよい。このＲＲＣレベルの指示は、例えば、新しいＵＬ ＤＣＣＨメッセージの中で伝えることができる。例えば、新しいＤＣＣＨメッセージは、ほとんど空のメッセージであるＲＲＣＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣｏｍｐｌｅｔｅに類似したものとすることができる。このような例示的なＵＬ－ＤＣＣＨメッセージを以下に示す（新しい情報要素は太字にして下線を引いてある）。非ＳＤＴ ＤＲＢデータの到着の指示をシグナリングするために、メッセージタイプｉｎｄＮｏｎＳＤＴＤＲＢＡｒｒｉｖａｌが導入されている。
一般に、トラフィック指示は無線リソース制御（ＲＲＣ）レベルの指示であってもよい。このＲＲＣレベルの指示は、例えば、新しいＵＬ ＤＣＣＨメッセージの中で伝えることができる。例えば、新しいＤＣＣＨメッセージは、ほとんど空のメッセージであるＲＲＣＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣｏｍｐｌｅｔｅに類似したものとすることができる。このような例示的なＵＬ－ＤＣＣＨメッセージを以下に示す（新しい情報要素は太字にして下線を引いてある）。非ＳＤＴ ＤＲＢデータの到着の指示をシグナリングするために、メッセージタイプｉｎｄＮｏｎＳＤＴＤＲＢＡｒｒｉｖａｌが導入されている。
【表3】
【0213】
この例におけるＩＮＤＮｏｎＳＤＴＤＲＢＡｒｒｉｖａｌメッセージは、以下の形式的な記述を除いて特定の情報要素を有さず、これは非特許文献１３に規定されているＲＲＣＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣｏｍｐｌｅｔｅメッセージに極めて類似する。このメッセージが存在する（受信される）とき、それは以下を示す。
【表4】
【0214】
＜多重化のためのＵＥの基準＞
ＳＤＴ手順の開始時に非ＳＤＴ ＤＲＢも再開される場合、非ＳＤＴトラフィックのＢＳＲ報告も可能である。この場合、ＳＤＴ ＤＲＢデータの送信のためのＵＬグラントを受信すると、ＵＥは、ＵＬグラントによって示されるリソースを使用して、以下のうちの１つ以上を送信することを選択できる。
－ ＳＤＴ ＤＲＢのユーザデータ（例えばＳＤＴ ＤＲＢデータ）、
－ ＳＤＴトラフィックのＢＳＲ（例えば、さらに送信されるＳＤＴ ＤＲＢデータのサイズ）、
－ 非ＳＤＴ ＤＲＢデータの検出／到着の場合、非ＳＤＴ ＤＲＢの到着指示（例えばトラフィック指示）、
－ 非ＳＤＴ ＤＲＢデータの検出／到着の場合、非ＳＤＴトラフィックのＢＳＲ（例えば到着した／検出された非ＳＤＴ ＤＲＢデータのサイズ）
ＳＤＴ手順の開始時に非ＳＤＴ ＤＲＢも再開される場合、非ＳＤＴトラフィックのＢＳＲ報告も可能である。この場合、ＳＤＴ ＤＲＢデータの送信のためのＵＬグラントを受信すると、ＵＥは、ＵＬグラントによって示されるリソースを使用して、以下のうちの１つ以上を送信することを選択できる。
－ ＳＤＴ ＤＲＢのユーザデータ（例えばＳＤＴ ＤＲＢデータ）、
－ ＳＤＴトラフィックのＢＳＲ（例えば、さらに送信されるＳＤＴ ＤＲＢデータのサイズ）、
－ 非ＳＤＴ ＤＲＢデータの検出／到着の場合、非ＳＤＴ ＤＲＢの到着指示（例えばトラフィック指示）、
－ 非ＳＤＴ ＤＲＢデータの検出／到着の場合、非ＳＤＴトラフィックのＢＳＲ（例えば到着した／検出された非ＳＤＴ ＤＲＢデータのサイズ）
【0215】
選択の基準は、（ＳＤＴトラフィックと非ＳＤＴトラフィックの間の）優先順位の比較と、グラントのサイズとに基づくことができる。なお、非ＳＤＴデータのＢＳＲが送信される場合、非ＳＤＴデータの到着を示す追加のトラフィック指示は不要とすることができることに留意されたい。さらに、現在のＵＬグラントによって示されるリソースを使用してすべてのＳＤＴ ＤＲＢデータが送信される場合、ＳＤＴデータのＢＳＲは不要とすることができることに留意されたい。
【0216】
したがって、一般に、ＵＬグラントによって示されるリソースが十分である場合、ＵＥは、ユーザデータ全体と、非ＳＤＴデータのＢＳＲとを送信することができる。一方、ＵＬグラントによって示されたリソースが、ユーザデータ全体および非ＳＤＴデータのＢＳＲを送信するのに十分ではない場合、以下のようにする。
－ 非ＳＤＴデータの優先順位がＳＤＴデータの優先順位よりも高い場合、ＵＥは、ＵＬグラントによって示されるリソースを使用して、非ＳＤＴデータのＢＳＲ、ＳＤＴデータのＢＳＲ、およびＳＤＴの一部（この優先順位の順）を送信するように決定することができる。
－ ＳＤＴデータの優先順位が非ＳＤＴデータの優先順位よりも高い場合、ＵＥは、ＵＬグラントによって示されたリソースを使用して、以下を送信するように決定することができる。
〇 トラフィック指示およびＳＤＴデータ全体、または、
〇 リソースがトラフィック指示およびＳＤＴデータ全体を送信するのに十分ではない場合、トラフィック指示、ＳＤＴデータのＢＳＲ、およびＳＤＴデータの一部
－ 非ＳＤＴデータの優先順位がＳＤＴデータの優先順位よりも高い場合、ＵＥは、ＵＬグラントによって示されるリソースを使用して、非ＳＤＴデータのＢＳＲ、ＳＤＴデータのＢＳＲ、およびＳＤＴの一部（この優先順位の順）を送信するように決定することができる。
－ ＳＤＴデータの優先順位が非ＳＤＴデータの優先順位よりも高い場合、ＵＥは、ＵＬグラントによって示されたリソースを使用して、以下を送信するように決定することができる。
〇 トラフィック指示およびＳＤＴデータ全体、または、
〇 リソースがトラフィック指示およびＳＤＴデータ全体を送信するのに十分ではない場合、トラフィック指示、ＳＤＴデータのＢＳＲ、およびＳＤＴデータの一部
【0217】
例えば、ユーザデータ（サブヘッダを含む）のサイズが８８ビット、ＢＳＲ（サブヘッダを含む）の各々のサイズが１６ビット、非ＳＤＴトラフィックの到着指示が８ビットである場合、ＵＥは以下を送信するように選択することができる。
－ グラントが１００ビットのサイズを有し、非ＳＤＴトラフィックがＳＤＴトラフィックよりも高い優先順位を有する場合、ＵＥは、ＳＤＴトラフィックのＢＳＲ（１６ビット）と、非ＳＤＴトラフィックのＢＳＲ（１６ビット）と、６８ビットのユーザデータとを送信することができる（ユーザデータはセグメント化することができ、ユーザデータのうちの６８ビットが送信される）。したがって、ＵＬグラントを使用して１００ビットを送信する。
－ グラントが１００ビットのサイズを有し、ＳＤＴトラフィックが非ＳＤＴトラフィックよりも高い優先順位を有する場合、ＵＥは、ユーザデータ全体（８８ビット）と、非ＳＤＴ ＤＲＢの到着指示（８ビット）とを送信することができる。したがって、ＵＬグラントを使用して９６ビットを送信する。
－ グラントのサイズが１１０ビットであり、ＳＤＴトラフィックが非ＳＤＴトラフィックよりも高い優先順位を有する場合、ＵＥは、ユーザデータ全体と、非ＳＤＴトラフィックのＢＳＲとを送信することができる。したがって、ＵＬグラントを使用して１０４ビットを送信する。
－ グラントが１００ビットのサイズを有し、非ＳＤＴトラフィックがＳＤＴトラフィックよりも高い優先順位を有する場合、ＵＥは、ＳＤＴトラフィックのＢＳＲ（１６ビット）と、非ＳＤＴトラフィックのＢＳＲ（１６ビット）と、６８ビットのユーザデータとを送信することができる（ユーザデータはセグメント化することができ、ユーザデータのうちの６８ビットが送信される）。したがって、ＵＬグラントを使用して１００ビットを送信する。
－ グラントが１００ビットのサイズを有し、ＳＤＴトラフィックが非ＳＤＴトラフィックよりも高い優先順位を有する場合、ＵＥは、ユーザデータ全体（８８ビット）と、非ＳＤＴ ＤＲＢの到着指示（８ビット）とを送信することができる。したがって、ＵＬグラントを使用して９６ビットを送信する。
－ グラントのサイズが１１０ビットであり、ＳＤＴトラフィックが非ＳＤＴトラフィックよりも高い優先順位を有する場合、ＵＥは、ユーザデータ全体と、非ＳＤＴトラフィックのＢＳＲとを送信することができる。したがって、ＵＬグラントを使用して１０４ビットを送信する。
【0218】
上に説明したように優先順位に従ってグラントを使用することによって、付与されたリソースの効率的な使用を促進することができる。
【0219】
＜ＲＡ－ＳＤＴが設定されたＳＤＴトラフィックの処理＞
進行中のＳＤＴ手順中に非ＳＤＴトラフィックが到着した場合の上述した処理は、ＬＣＨの制限に関連付けられるトラフィックに適用することもできる。特に、上述した処理は、ＣＧ－ＳＤＴトラフィックの進行中の送信中にＲＡ－ＳＤＴトラフィックが到着する／検出される場合に適用することができる。言い換えれば、進行中のＳＤＴ手順が、スモールデータを送信するための進行中のＣＧ手順である場合、ＲＡ－ＳＤＴトラフィックの到着は、非ＳＤＴトラフィックの到着の場合に類似する方法で管理することができる。特に、ＵＥは、ＲＡ－ＳＤＴトラフィックの到着／検出を示すトラフィック指示を、スケジューリングデバイスに送信することができる。例えば、ＵＥは、ＣＧ－ＳＤＴ手順に関連付けられていないＬＣＨのＳＤＴトラフィックの到着時に、トラフィック指示をｇＮＢにシグナリングすることができる。このようなトラフィック指示は、ＲＡ－ＳＤＴのみが設定されたトラフィックの到着をｇＮＢに伝えるためのものである。ＵＥは、ＣＧ－ＳＤＴリソースを受信していない場合、または受信する見込みがない場合、ＲＡ－ＳＤＴ手順を開始することができる。言い換えれば、ＲＡ－ＳＤＴトラフィックは、上述した実施形態における非ＳＤＴトラフィックの役割を担う。例えば、非ＳＤＴトラフィックの到着／検出は、ＲＡ－ＳＤＴトラフィックの到着／検出に対応し、ＵＥによって送信されるトラフィック指示は、非ＳＤＴデータの到着ではなく、ＲＡ－ＳＤＴデータの到着を示す。
進行中のＳＤＴ手順中に非ＳＤＴトラフィックが到着した場合の上述した処理は、ＬＣＨの制限に関連付けられるトラフィックに適用することもできる。特に、上述した処理は、ＣＧ－ＳＤＴトラフィックの進行中の送信中にＲＡ－ＳＤＴトラフィックが到着する／検出される場合に適用することができる。言い換えれば、進行中のＳＤＴ手順が、スモールデータを送信するための進行中のＣＧ手順である場合、ＲＡ－ＳＤＴトラフィックの到着は、非ＳＤＴトラフィックの到着の場合に類似する方法で管理することができる。特に、ＵＥは、ＲＡ－ＳＤＴトラフィックの到着／検出を示すトラフィック指示を、スケジューリングデバイスに送信することができる。例えば、ＵＥは、ＣＧ－ＳＤＴ手順に関連付けられていないＬＣＨのＳＤＴトラフィックの到着時に、トラフィック指示をｇＮＢにシグナリングすることができる。このようなトラフィック指示は、ＲＡ－ＳＤＴのみが設定されたトラフィックの到着をｇＮＢに伝えるためのものである。ＵＥは、ＣＧ－ＳＤＴリソースを受信していない場合、または受信する見込みがない場合、ＲＡ－ＳＤＴ手順を開始することができる。言い換えれば、ＲＡ－ＳＤＴトラフィックは、上述した実施形態における非ＳＤＴトラフィックの役割を担う。例えば、非ＳＤＴトラフィックの到着／検出は、ＲＡ－ＳＤＴトラフィックの到着／検出に対応し、ＵＥによって送信されるトラフィック指示は、非ＳＤＴデータの到着ではなく、ＲＡ－ＳＤＴデータの到着を示す。
【0220】
主な違いは、両方のデータ（進行中の送信のデータと新たに検出されたデータ）が非アクティブ状態において送信されることである。その結果、待機するべき送信機会が存在しない場合、接続状態に入るためにＲＡＣＨ手順を開始する（Ｓ２１３０）代わりに、ＵＥはＲＡ手順を開始し、非アクティブ状態にとどまったままＲＡリソース（例えば第２の論理チャネルに関連付けられるＲＡリソース）を使用してＲＡ－ＳＤＴトラフィックを送信する。さらに、スケジューリングデバイスは、トラフィック指示の受信に応答して、ＵＥを接続状態に遷移させることなく、ＲＡ－ＳＤＴデータの送信のための１つ以上のグラントをＵＥに提供する。
【0221】
以下では、この手順についてさらに詳しく説明する。ただし、非ＳＤＴデータの場合について上述した説明のすべてが、ＲＡ－ＳＤＴデータの到着の場合にも適用されるわけではない。これに関して、いま説明した相違点を除けば、「非ＳＤＴデータ」の到着の処理に関して上で述べたすべてを、文脈が特にそうでないことを示さない限り、例えば「非ＳＤＴデータ」という用語を「ＲＡ－ＳＤＴデータ」という用語に置き換えることにより、「ＲＡ－ＳＤＴデータ」の到着の処理に適用することができることに留意されたい。
【0222】
特に、図２８（左側）に示したように、例示的な実施形態によれば、ユーザ機器（ＵＥ）２８１０が提供される。ＵＥ ２８１０は、送受信機２８２０および回路２８３０を備える。回路２８３０（例えば回路２８３５）は、動作時、第１の論理チャネルの第１のデータを非アクティブ状態において送信するための手順中に、第２の論理チャネルの第２のデータが非アクティブ状態において送信されることを検出する。第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順であり、第２の論理チャネルは、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。回路２８３０は、動作時、待機するべき送信機会が存在するか否かを判定する。この送信機会は、（ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、（ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路２８３０は、動作時、ＲＡリソースを使用して第２のデータを送信するためのＲＡ手順を開始する。待機するべき送信機会が存在すると判定され、その送信機会が発生すると、回路２８３０は、動作時、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように、送受信機２８２０を制御する。
【0223】
図２９は、回路２８３０、すなわちＲＡ－ＳＤＴデータの到着を処理する回路、の例示的な機能構造を示している。図示したように、ＲＡ－ＳＤＴデータ到着処理トラフィック指示処理回路２８３０は、ＲＡ－ＳＤＴデータ検出回路２９３６および送信機会判定回路２９３７を含むことができる。より具体的には、回路２９３６は、例えば、送信されるＲＡ－ＳＤＴデータが存在するか否かを検出または判定することによって、ＲＡ－ＳＤＴデータを検出する。また、回路２９３６は、ＲＡ－ＳＤＴの到着が予期されるか否かを判定することもできる。送信機会判定回路２９３７は、待機するべき送信機会が存在するか否かを判定することができる。さらに、回路２９３７は、待機するべき送信機会が存在すると判定した場合、待機するべき送信機会（例えばその送信機会のリソース）を求めることもできる。
【0224】
上述したＵＥに対応して、別の例示的な実施形態によれば、ＵＥによって実行される通信方法が提供される。図３１に示したように、この方法は、以下のステップ、すなわち、
－ 非アクティブ状態において第１の論理チャネルの第１のデータを送信するための手順中に、非アクティブ状態において第２の論理チャネルの第２のデータが送信されることを検出するステップＳ３１１０と、
－ 待機するべき送信機会が存在するか否かを判定するステップＳ３１２０と、
－ Ｓ３１２０で、待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない（Ｓ３１４０で「いいえ」）、と判定されたとき、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始するステップＳ３１３０と、
－ 待機するべき送信機会が存在すると判定され（Ｓ３１２０）、その送信機会が発生したとき（Ｓ３１４０で「はい」）、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するステップＳ３１５０と、
を含む。
－ 非アクティブ状態において第１の論理チャネルの第１のデータを送信するための手順中に、非アクティブ状態において第２の論理チャネルの第２のデータが送信されることを検出するステップＳ３１１０と、
－ 待機するべき送信機会が存在するか否かを判定するステップＳ３１２０と、
－ Ｓ３１２０で、待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない（Ｓ３１４０で「いいえ」）、と判定されたとき、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始するステップＳ３１３０と、
－ 待機するべき送信機会が存在すると判定され（Ｓ３１２０）、その送信機会が発生したとき（Ｓ３１４０で「はい」）、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するステップＳ３１５０と、
を含む。
【0225】
図２８（右側）にも示したように、別の例示的な実施形態によれば、スケジューリングデバイス２８６０が提供される。スケジューリングデバイス２８６０は、送受信機２８７０および回路２８８０を備える。回路２８８０は、動作時、非アクティブ状態にあるユーザ機器（ＵＥ）から、第１の論理チャネルの第１のデータを含む送信を受信するように、送受信機２８７０を制御する。回路２８８０は、動作時、第１のデータを含む受信された送信から、トラフィック指示を取得する。トラフィック指示は、第２の論理チャネルの第２のデータがＵＥによって検出されたことを示す。第２のデータは、非アクティブ状態にあるＵＥによって送信されるデータであり、トラフィック指示は、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ＬＣＩＤの事前定義値は、第２のデータが検出されたことを示す。
【0226】
図３０は、トラフィック指示処理回路２８８５の例示的な機能構造を示している。特に、トラフィック指示処理回路２８８５は、トラフィック指示評価回路３０３６およびスケジューリング回路３０３７を含むことができる。回路３０３６は、スモールデータを含む送信からトラフィック指示を取得して解釈する役割を担うことができる。さらに、回路３０３６が、受信された送信からトラフィック指示を取得すると、回路３０３７は、ＲＡ－ＳＤＴデータ（すなわち「第２のデータ」）を送信するためのグラントをＵＥに送信する役割を担うことができる。
【0227】
さらに、上述した基地局に対応して、スケジューリングデバイスによって実行される通信方法が提供される。図３２に示したように、この方法は、以下のステップ、すなわち、
－ 非アクティブ状態にあるＵＥから、第１の論理チャネルの第１のデータを含む送信を受信するステップＳ３２１０と、
－ 第１のデータを含む送信から、第２の論理チャネルの第２のデータがＵＥによって検出されたことを示すトラフィック指示を取得するステップＳ３２２０であって、ｉ）第２のデータが、非アクティブ状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、第２のデータが検出されたことを示す、ステップＳ３２２０と、
を含む。
－ 非アクティブ状態にあるＵＥから、第１の論理チャネルの第１のデータを含む送信を受信するステップＳ３２１０と、
－ 第１のデータを含む送信から、第２の論理チャネルの第２のデータがＵＥによって検出されたことを示すトラフィック指示を取得するステップＳ３２２０であって、ｉ）第２のデータが、非アクティブ状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、第２のデータが検出されたことを示す、ステップＳ３２２０と、
を含む。
【0228】
非ＳＤＴデータの到着の場合と同様に、待機するべき送信機会とは、（ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、（ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される送信機会、を意味することに留意されたい。
【0229】
ここで、ＲＡ－ＳＤＴトラフィックおよびＲＡ－ＳＤＴデータという用語は、それぞれ、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている論理チャネル（本明細書では第２の論理チャネルとも呼ぶ）のトラフィックおよびデータ、を意味することに留意されたい。特に、第２の論理チャネル（ＬＣＨ）には、非アクティブ状態において送信するためのＲＡリソースのみが設定されている、および／または関連付けられていることができる。ＲＡ－ＳＤＴデータは、第２のデータとも呼ばれることに留意されたい。非アクティブ状態においてデータを送信するためのＲＡリソースは、アクティブ状態に入るための（例えばｍｓｇ１を送信するための）ＲＡＣＨリソースと異なる、または同じであってもよいことに留意されたい。
【0230】
ＣＧ－ＳＤＴトラフィックおよびＣＧ－ＳＤＴデータという用語は、それぞれ、非アクティブ状態において送信するためのＣＧリソースが設定されている論理チャネル（本明細書では第１の論理チャネルとも呼ぶ）のトラフィックおよびデータを意味する。ＲＡ－ＳＤＴデータは第１のデータとも呼ぶことに留意されたい。第１のＬＣＨには、ＲＡリソースが設定されていてもよいし、ＲＡリソースが設定されていなくてもよいことに留意されたい。しかしながら、本実施形態は、第１のデータを送信するための手順が、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順である場合に関する。
【0231】
一般に、ＵＥには、複数の論理チャネル（ＬＣＨ）を設定することができる。ＬＣＨには、非アクティブ状態において送信するためのＲＡ－ＳＤＴリソースおよび／または非アクティブ状態において送信するためのＣＧ－ＳＤＴリソースを設定することができる。例えば、ＬＣＨには、（ｉ）ＲＡ－ＳＤＴ、または（ｉｉ）ＣＧ－ＳＤＴおよびＲＡ－ＳＤＴ、のいずれかを設定することができる。このことは図３３に示してあり、ＵＥには、それぞれＬＣＨ１およびＬＣＨ２として表されている２つの論理チャネルが設定されている。図示したように、ＬＣＨ１にはＣＧ－ＳＤＴおよびＲＡ－ＳＤＴが設定されており、ＬＣＨ２にはＲＡ－ＳＤＴのみが設定されている。ＬＣＨ１のトラフィックが利用可能である場合、ＣＧ－ＳＤＴ基準が満たされていれば、ＵＥはＣＧ－ＳＤＴを介してトラフィックを送信することができる。そうではなく基準が満たされていなければ、ＵＥはＲＡ－ＳＤＴを介してトラフィックを送信することができる。一方、ＬＣＨ２のトラフィックが利用可能である場合、ＵＥは、ＲＡ－ＳＤＴを介してのみトラフィックを送信することができる。一般に、既存のシグナリングを再利用して、ＬＣＨの制限を適用することもできる。制限がどのように設定されるかは、ｇＮＢに委ねることができる。言い換えれば、基地局は、各ＬＣＨにＲＡ－ＳＤＴおよび／またはＣＧ－ＳＤＴを設定することができる。
【0232】
すでに上述したように、トラフィック指示と、待機するべき送信が存在するか否かの判定と、進行中のＣＧ－ＳＤＴ手順中にＲＡ－ＳＤＴトラフィックが到着した場合の処理の別の態様は、非ＳＤＴトラフィックの到着の処理について上述した対応する態様と実質的に同様である。特に以下のとおりである。
【0233】
一般に、ＣＧ手順の次のリソースが、ＲＡリソースのうちの次のＲＡリソースよりも早い場合、待機するべき送信機会が存在すると判定する（Ｓ３１２０）ことができる。この場合、その送信機会を使用してトラフィック指示を送信することができる。さらに、ＣＧ手順の次のリソースが次のＲＡリソースよりも遅い場合、回路は、待機するべき送信機会が存在しないと判定し（Ｓ３１２０）、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する（Ｓ３１３０）ことができる。言い換えれば、ＵＥは、どちらの遅延が短いかに応じて、ＣＧリソースにおいてｇＮＢにトラフィック指示を送信するか、またはＲＡ－ＳＤＴ手順を開始することができる。
【0234】
しかしながら、本発明はこれに限定されず、一般に、ＵＥは、ＣＧ手順の次のリソースまでの時間と遅延しきい値との比較に基づいて、待機するべき送信機会が存在するか否かを判定する（Ｓ３１２０）こともできる。言い換えれば、ＵＥが次のＣＧリソースまでの時間と比較し、その比較の結果に基づいて決定を行うように、遅延しきい値をＵＥにシグナリングすることができる。例えば、ＵＥは、送信機会までの時間がしきい値より小さいかまたは等しい場合、その送信機会を待機することを決定する、および／または、送信機会までの時間がしきい値より大きい場合、その送信機会を待機しないことを決定することができる。ただし、送信機会までの時間がしきい値に等しい場合、ＵＥは待機しないと決定することもできる。さらに、一般に、ＵＥは、送信機会を待機するか否かを決定する際に、他の基準も考慮に入れることができる。このようなしきい値は、ｇＮＢによってシグナリングする、事前に設定する、または所定の値とすることができる。
【0235】
特に、トラフィック指示は、第２のデータの量を示す指示、および／または、さらに送信される第１のデータの量を示す指示、を含むことができる。言い換えれば、非ＳＤＴデータの到着の処理についてすでに上述したように、トラフィック指示は、バッファ状態報告をさらに含むことができる。
【0236】
さらに、非ＳＤＴデータの到着の場合と同様に、ＲＡ－ＳＤＴデータの到着の場合にも、トラフィック指示は、無線リソース制御（ＲＲＣ）レベルの指示、および／または媒体アクセス制御（ＭＡＣ）レベルの指示とすることができる。特に、図２５～図２７に関してすでに説明したように、トラフィック指示は、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってＭＡＣサブヘッダ内でシグナリングすることができ、ＬＣＩＤの事前定義値は、第２のデータが検出されたことを示す。例えば、特定のＬＣＩＤインデックス（例えばインデックス＃４９）を有するＭＡＣサブヘッダを使用して、ＢＳＲ ＭＡＣ ＣＥを付加して／付加せずに、トラフィックの到着を示すことができる。
【0237】
これに関して、ＵＥ（例えば回路２８３０）は、（ｉ）さらに送信される第１のデータの量、および／または（ｉｉ）第２のデータの量、を示すＢＳＲ ＭＡＣ ＣＥをＭＡＣサブヘッダに付加するか否かを決定することができることに留意されたい。この決定は、例えば、コンフィギュアドグラントのサイズに依存することができる。より具体的には、ＵＥは、送信機会のＣＧリソースがしきい値より大きいかまたは等しい場合、ＢＳＲを付加することを決定する、および／または、送信機会のサイズがしきい値より小さい場合、ＢＳＲを付加しないことを決定することができる。特に、いま説明したしきい値は、ＢＳＲのサイズに対応することができる。言い換えれば、コンフィギュアドグラントの未使用部分のサイズが（１つ以上の）ＢＳＲより大きいかまたは等しい場合、（１つ以上の）ＢＳＲを含めることができる。より具体的には、ＵＥは、コンフィギュアドグラントのサイズ（すなわちトラフィック指示の送信に使用される送信機会）が（１つ以上の）ＢＳＲを伝えるのに十分である場合、（１つ以上の）ＢＳＲを含めることができる。ここで「十分である」とは、例えば、コンフィギュアドグラントのサイズが、（ｉ）送信される第１の論理チャネルのデータ、（ｉｉ）トラフィック指示、および（ｉｉｉ）第１のデータおよび／または第２のデータの（１つ以上の）ＢＳＲ、を送信するのに十分であることを意味する。送信される第１の論理チャネルのデータとは、例えば、第１の論理チャネルの現在利用可能なデータ、ＵＥがコンフィギュアドグラントを使用して送信することを決定した第１の論理チャネルのデータ、および／または、第１の論理チャネルに関連付けられるサービスの例えばＱｏＳを考慮した結果として送信される第１の論理チャネルのデータ、とすることができる。
【0238】
しかしながら、本発明はこれに限定されず、一般に、ＬＣＩＤの事前定義値は、ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていないことを示すことができる。しかしながら、一般に、ＬＣＩＤは、バッファ状態報告（ＢＳＲ）ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていることを示すこともでき、ＢＳＲ ＭＡＣ ＣＥは、さらに送信される第１のデータの量を示す。これに代えて、またはこれに加えて、ＬＣＩＤは、第２のデータの量を示すＢＳＲ ＭＡＣ ＣＥがＭＡＣサブヘッダに付加されていることを示すことができる。
【0239】
また、ＲＡ－ＳＤＴデータの到着の場合にも、トラフィック指示は、媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）の一部とすることができ、この場合、（ｉ）ＭＡＣ ＣＥの１ビットが、第２のデータが検出されたか否かを示すことができる、（ｉｉ）ＭＡＣ ＣＥの２ビットが、非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、第１のデータの論理チャネルグループ（ＬＣＧ）を示すことができる、（ｉｉｉ）ＭＡＣ ＣＥの５ビットが、第２のデータの量を示すことができる、ことに留意されたい。これに代えて、非ＳＤＴ ＤＲＢデータの到着の場合についてすでに上述したように、５ビットは、さらに送信される第１のデータの量を示すことができる。
【0240】
＜ＲＡ－ＳＤＴトラフィック処理の利点＞
進行中のＣＧ－ＳＤＴ手順中にＲＡ－ＳＤＴデータが到着した場合の上述した処理では、オーバーヘッドを減らし、消費電力を低減し、ＬＣＨ１に対して進行中のＣＧ－ＳＤＴ送信にＲＡ－ＳＤＴ手順が影響を及ぼすことを防止する、ことができる。より具体的には、図３４に示したように、ＣＧ－ＳＤＴ手順がすでに進行している間にＵＥがＲＡ－ＳＤＴをトリガーすると、ＵＥのシグナリングオーバーヘッドが増加する可能性がある。図示したように、ＣＧリソースを通じて周期的に送信する必要のあるＬＣＨ１のトラフィックが利用可能である。ＬＣＨ１のその後の送信中に、ＬＣＨ２のトラフィックが利用可能になる。しかしながら、ＬＣＨ２はＣＧ設定にマッピングされていない。ＵＥが、ＣＧリソースが設定されていないＬＣＨ２のデータを送信するためにＲＡ－ＳＤＴをトリガーする場合、ＵＥのシグナリングオーバーヘッドが増加するのみならず、ＬＣＨ１の進行中のＣＧ－ＳＤＴ送信が影響を受ける可能性がある（例えばＵＥがＣＧ－ＳＤＴ手順とＲＡ－ＳＤＴ手順を同時に処理できないことがあるため）。しかしながら、上記の開示によれば、図３５に示したように、ＬＣＨ２のトラフィックが利用可能になったときに、ＬＣＨ２のトラフィックのトラフィック指示を次のＣＧリソースにおいて送信することができる（例えばＬＣＨ１のデータと多重化する）。このようにして、ＵＥはＲＡ－ＳＤＴ手順をトリガーすることを回避することができ、このことは、ＵＥのシグナリングオーバーヘッドのみならず消費電力の観点から有利であり得る。
進行中のＣＧ－ＳＤＴ手順中にＲＡ－ＳＤＴデータが到着した場合の上述した処理では、オーバーヘッドを減らし、消費電力を低減し、ＬＣＨ１に対して進行中のＣＧ－ＳＤＴ送信にＲＡ－ＳＤＴ手順が影響を及ぼすことを防止する、ことができる。より具体的には、図３４に示したように、ＣＧ－ＳＤＴ手順がすでに進行している間にＵＥがＲＡ－ＳＤＴをトリガーすると、ＵＥのシグナリングオーバーヘッドが増加する可能性がある。図示したように、ＣＧリソースを通じて周期的に送信する必要のあるＬＣＨ１のトラフィックが利用可能である。ＬＣＨ１のその後の送信中に、ＬＣＨ２のトラフィックが利用可能になる。しかしながら、ＬＣＨ２はＣＧ設定にマッピングされていない。ＵＥが、ＣＧリソースが設定されていないＬＣＨ２のデータを送信するためにＲＡ－ＳＤＴをトリガーする場合、ＵＥのシグナリングオーバーヘッドが増加するのみならず、ＬＣＨ１の進行中のＣＧ－ＳＤＴ送信が影響を受ける可能性がある（例えばＵＥがＣＧ－ＳＤＴ手順とＲＡ－ＳＤＴ手順を同時に処理できないことがあるため）。しかしながら、上記の開示によれば、図３５に示したように、ＬＣＨ２のトラフィックが利用可能になったときに、ＬＣＨ２のトラフィックのトラフィック指示を次のＣＧリソースにおいて送信することができる（例えばＬＣＨ１のデータと多重化する）。このようにして、ＵＥはＲＡ－ＳＤＴ手順をトリガーすることを回避することができ、このことは、ＵＥのシグナリングオーバーヘッドのみならず消費電力の観点から有利であり得る。
【0241】
＜ハードウェアおよびソフトウェアによる本開示の実施＞
本開示は、ソフトウェアによって、ハードウェアによって、またはハードウェアと協働するソフトウェアによって、実施することができる。上述した各実施形態の説明において使用される各機能ブロックは、その一部または全体を、集積回路などのＬＳＩによって実施することができ、各実施形態において説明した各プロセスは、その一部または全体を、同じＬＳＩまたはＬＳＩの組合せによって制御することができる。ＬＳＩは、チップとして個別に形成する、または、機能ブロックの一部またはすべてが含まれるように１個のチップを形成することができる。ＬＳＩは、自身に結合されたデータ入出力部を含むことができる。ここでＬＳＩは、集積度の違いに応じて、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、またはウルトラＬＳＩとも称される。しかしながら、集積回路を実施する技術は、ＬＳＩに限定されず、専用回路、汎用プロセッサ、または専用プロセッサを使用することによって実施されてもよい。さらには、ＬＳＩの製造後にプログラムすることのできるＦＰＧＡ（フィールドプログラマブルゲートアレイ）や、ＬＳＩ内部に配置されている回路セルの接続および設定を再設定できるリコンフィギャラブル・プロセッサを使用することもできる。本開示は、デジタル処理またはアナログ処理として実施することができる。半導体技術または別の派生技術が進歩する結果として、ＬＳＩが将来の集積回路技術に置き換わる場合、その将来の集積回路技術を使用して機能ブロックを集積化することができる。バイオテクノロジを適用することもできる。
本開示は、ソフトウェアによって、ハードウェアによって、またはハードウェアと協働するソフトウェアによって、実施することができる。上述した各実施形態の説明において使用される各機能ブロックは、その一部または全体を、集積回路などのＬＳＩによって実施することができ、各実施形態において説明した各プロセスは、その一部または全体を、同じＬＳＩまたはＬＳＩの組合せによって制御することができる。ＬＳＩは、チップとして個別に形成する、または、機能ブロックの一部またはすべてが含まれるように１個のチップを形成することができる。ＬＳＩは、自身に結合されたデータ入出力部を含むことができる。ここでＬＳＩは、集積度の違いに応じて、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、またはウルトラＬＳＩとも称される。しかしながら、集積回路を実施する技術は、ＬＳＩに限定されず、専用回路、汎用プロセッサ、または専用プロセッサを使用することによって実施されてもよい。さらには、ＬＳＩの製造後にプログラムすることのできるＦＰＧＡ（フィールドプログラマブルゲートアレイ）や、ＬＳＩ内部に配置されている回路セルの接続および設定を再設定できるリコンフィギャラブル・プロセッサを使用することもできる。本開示は、デジタル処理またはアナログ処理として実施することができる。半導体技術または別の派生技術が進歩する結果として、ＬＳＩが将来の集積回路技術に置き換わる場合、その将来の集積回路技術を使用して機能ブロックを集積化することができる。バイオテクノロジを適用することもできる。
【0242】
本開示は、通信の機能を有する任意の種類の装置、デバイス、またはシステム（通信装置と呼ばれる）によって実施することができる。
【0243】
通信装置は、送受信機および処理／制御回路を備えていることができる。送受信機は、受信機および送信機を備えている、および／または、受信機および送信機として機能することができる。送信機および受信機としての送受信機は、増幅器、ＲＦ変調器／復調器などを含むＲＦ（無線周波数）モジュールと、１つ以上のアンテナを含むことができる。
【0244】
このような通信装置の非限定的ないくつかの例としては、電話（例：携帯電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例：ラップトップ、デスクトップ、ノートブック）、カメラ（例：デジタルスチル／ビデオカメラ）、デジタルプレイヤー（デジタルオーディオ／ビデオプレイヤー）、ウェアラブルデバイス（例：ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、電子書籍リーダー、遠隔医療／テレメディシン（リモート医療・医薬）装置、通信機能を提供する車両（例：自動車、飛行機、船舶）、およびこれらのさまざまな組合せ、が挙げられる。
【0245】
通信装置は、携帯型または可搬型に限定されず、非携帯型または据置型である任意の種類の装置、デバイス、またはシステム、例えば、スマートホームデバイス（例：電化製品、照明、スマートメーター、制御盤）、自動販売機、および「モノのインターネット（ＩｏＴ：Internet of Things）」のネットワーク内の任意の他の「モノ」なども含むことができる。
【0246】
通信は、例えばセルラーシステム、無線ＬＡＮシステム、衛星システム、その他、およびこれらのさまざまな組合せを通じてデータを交換するステップ、を含むことができる。
【0247】
通信装置は、本開示の中で説明した通信の機能を実行する通信デバイスに結合されたコントローラやセンサーなどのデバイスを備えることができる。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号またはデータ信号を生成するコントローラまたはセンサー、を備えていることができる。
【0248】
通信装置は、インフラストラクチャ設備、例えば、上の非限定的な例における装置等の装置と通信する、またはそのような装置を制御する基地局、アクセスポイント、および任意の他の装置、デバイス、またはシステムなどを、さらに含むことができる。
【0249】
さらに、様々な実施形態は、ソフトウェアモジュールによって実施されてもよく、これらのソフトウェアモジュールは、プロセッサによって実行される、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体に格納することができる。特に、別の実装形態によれば、非一過性のコンピュータ可読記録媒体が提供される。記録媒体はプログラムを格納しており、プログラムが１つ以上のプロセッサによって実行されると、１つ以上のプロセッサが本開示による方法のステップを実行する。
【0250】
一例として、本発明を限定するものではないが、このようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭもしくは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶装置、フラッシュメモリ、または、命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用することができ、かつコンピュータによってアクセスすることができる任意の他の媒体、を備えることができる。また、あらゆる接続はコンピュータ可読媒体と称することができる。例えば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（ＤＳＬ：digital subscriber line）、または赤外線、無線、マイクロ波などの無線技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、マイクロ波などの無線技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体には、接続、搬送波、信号、または他の一過性の媒体は含まれず、代わりに、非一過性の有形記憶媒体が対象となることを理解されたい。本明細書で使用される磁気ディスクおよび光ディスクには、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク、およびブルーレイディスクが含まれ、磁気ディスクは通常では磁気的にデータを再生し、光ディスクはレーザーを使用して光学的にデータを再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれる。
【0251】
さらには、複数の異なる実施形態の個々の特徴は、個別に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。特定の実施形態に示した本開示には、多数の変更および／または修正を行い得ることが、当業者には理解されるであろう。したがって本明細書における実施形態は、あらゆる点において説明を目的としており、本発明を制限するものではないとみなされたい。
【0252】
＜さらなる態様＞
第１の態様によれば、ユーザ機器（ＵＥ）が提供される。本ＵＥは、送受信機および回路を備える。回路は、動作時、非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出する。回路は、動作時、待機するべき送信機会が存在するか否かを判定し、待機するべき送信機会は、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、動作時、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始する。待機するべき送信機会が存在すると判定され、送信機会が発生したとき、回路は、動作時、送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように、送受信機を制御する。
第１の態様によれば、ユーザ機器（ＵＥ）が提供される。本ＵＥは、送受信機および回路を備える。回路は、動作時、非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出する。回路は、動作時、待機するべき送信機会が存在するか否かを判定し、待機するべき送信機会は、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、動作時、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始する。待機するべき送信機会が存在すると判定され、送信機会が発生したとき、回路は、動作時、送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように、送受信機を制御する。
【0253】
第１の態様に加えて提供される第２の態様によれば、第１のデータを送信するための手順は、ＲＡＣＨ手順において開始される手順であり、待機するべき送信機会は、ｉ）ＲＡＣＨ手順の最初の送信である、ｉｉ）ＲＡＣＨ手順の一部として受信されたアップリンクグラントによって示されている、またはｉｉｉ）ＲＡＣＨ手順の完了後に第１のデータを送信するために受信されたアップリンクグラントによって示されている。
【0254】
第１の態様に加えて提供される第３の態様によれば、第１のデータを送信するための手順は、ＲＡＣＨ手順において開始される手順であり、ｉ）回路が、動作時、第１のデータを送信するように送受信機を制御した後、待機するべき送信機会が存在しないと判定する、またはｉｉ）待機するべき送信機会が、アップリンクグラントによって示されることが予期され、このアップリンクグラントは、ＲＡＣＨ手順の一部として、または、ＲＡＣＨ手順の完了後に第１のデータの一部を送信するために、受信されることが予期される。
【0255】
第１の態様に加えて提供される第４の態様によれば、アップリンクグラントは、回路が送受信機を制御して、ｉ）ＲＡＣＨ手順の第１の送信を送信した後、ｉｉ）さらに送信される第１のデータの量を示すバッファ状態報告（ＢＳＲ）を送信した後、および／またはｉｉｉ）このＢＳＲを送信した後に第１のデータの一部を送信した後、に受信されることが予期され、第１のデータの一部の量が、ＢＳＲによって示される量よりも小さい。
【0256】
第３の態様または第４の態様に加えて提供される第５の態様によれば、待機するべき送信機会は、予期されるアップリンクグラントが受信されておらず、かつ、もはや受信される見込みがないとき、もはや発生する見込みがなく、予期されるアップリンクグラントは、ｉ）送受信機が、第１のデータを送信するための手順の終了を示す指示を受信した場合、および／またはｉｉ）第１のデータの少なくとも一部の最初の送信または前の送信から所定の時間が経過した場合、もはや受信される見込みがない。
【0257】
第１の態様から第５の態様のうちの一態様に加えて提供される第６の態様によれば、トラフィック指示は、ｉ）アップリンクグラントによって示されるリソースを使用する、第１のデータの少なくとも一部、および／または、ｉｉ）第１のデータの量を示すバッファ状態報告（ＢＳＲ）、と一緒に送信される。
【0258】
第１の態様から第６の態様のうちの一態様に加えて提供される第７の態様によれば、ＲＡＣＨ手順は、４ステップＲＡＣＨ手順または２ステップＲＡＣＨ手順である。
【0259】
第１の態様に加えて提供される第８の態様によれば、第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順であり、回路は、動作時、ｉ）ＣＧ手順の次のリソースが次のＲＡＣＨリソースよりも早い場合、待機するべき送信機会が存在すると判定し、その送信機会を使用してトラフィック指示を送信するように送受信機を制御し、ｉｉ）ＣＧ手順の次のリソースが次のＲＡＣＨリソースよりも遅い場合、待機するべき送信機会が存在しないと判定し、接続状態に入るためにＲＡＣＨ手順を開始する。
【0260】
第１の態様から第８の態様のうちの一態様に加えて提供される第９の態様によれば、トラフィック指示は、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ＬＣＩＤの事前定義値は、第２のデータが検出されたことを示す。
【0261】
第９の態様に加えて提供される第１０の態様によれば、ＬＣＩＤの事前定義値は、ＭＡＣ制御要素ＣＥがＭＡＣサブヘッダに付加されていないことを示す。
【0262】
第９の態様に加えて提供される第１１の態様によれば、ＬＣＩＤは、ＢＳＲ ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていることを示し、ＢＳＲ ＭＡＣ ＣＥは、さらに送信される第１のデータの量を示す。
【0263】
第１の態様から第８の態様のうちの一態様に加えて提供される第１２の態様によれば、トラフィック指示は、ＭＡＣ制御要素（ＣＥ）の一部であり、ｉ）ＭＡＣ ＣＥの１ビットが、第２のデータが検出されたか否かを示し、ｉｉ）ＭＡＣ ＣＥの２ビットが、非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、第１のデータの論理チャネルグループ（ＬＣＧ）を示し、ｉｉｉ）ＭＡＣ ＣＥの５ビットが、示されたＬＣＧに対応する第１のデータの、さらに送信される量を示す。
【0264】
第１の態様から第８の態様のうちの一態様に加えて提供される第１３の態様によれば、トラフィック指示は、無線リソース制御（ＲＲＣ）レベルの指示である。
【0265】
第１４の態様によれば、ユーザ機器（ＵＥ）のための方法が提供される。本方法は、以下のステップ、すなわち、
－ 非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出するステップと、
－ 待機するべき送信機会が存在するか否かを判定するステップであって、待機するべき送信機会が、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される、ステップと、
－ 待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始するステップと、
－ 待機するべき送信機会が存在すると判定され、その送信機会が発生したとき、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するステップと、
を含む。
－ 非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出するステップと、
－ 待機するべき送信機会が存在するか否かを判定するステップであって、待機するべき送信機会が、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される、ステップと、
－ 待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始するステップと、
－ 待機するべき送信機会が存在すると判定され、その送信機会が発生したとき、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するステップと、
を含む。
【0266】
第１５の態様によれば、スケジューリングデバイスが提供される。本スケジューリングデバイスは、送受信機と回路とを備えており、回路は、動作時、非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するように、送受信機を制御する。回路は、動作時、第１のデータを含む送信から、ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得し、ｉ）第２のデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、第２のデータが検出されたことを示す。
【0267】
第１６の態様によれば、スケジューリングデバイスのための方法が提供される。本方法は、以下のステップ、すなわち、
－ 非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するステップと、
－ 第１のデータを含む送信から、ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得するステップであって、ｉ）第２のデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、第２のデータが検出されたことを示す、ステップと、
を含む。
－ 非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するステップと、
－ 第１のデータを含む送信から、ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得するステップであって、ｉ）第２のデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ｉｉｉ）ＬＣＩＤの事前定義値が、第２のデータが検出されたことを示す、ステップと、
を含む。
【0268】
第１５の態様または第１６の態様に加えて提供される第１７の態様によれば、第１のデータを含む送信は、ＲＡＣＨ手順において開始される手順の一部として送信される。
【0269】
第１７の態様に加えて提供される第１８の態様によれば、ＲＡＣＨ手順は、４ステップＲＡＣＨ手順または２ステップＲＡＣＨ手順である。
【0270】
第１５の態様または第１６の態様に加えて提供される第１９の態様によれば、第１のデータを含む送信は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順の一部として送信される。
【0271】
第１５の態様から第１９の態様のうちの一態様に加えて提供される第２０の態様によれば、ＬＣＩＤの事前定義値は、ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていないことを示す。
【0272】
第１５の態様から第１９の態様のうちの一態様に加えて提供される第２１の態様によれば、ＬＣＩＤは、ＢＳＲ ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていることを示し、ＢＳＲ ＭＡＣ ＣＥは、さらに送信される第１のデータの量を示す。
【0273】
第２２の態様によれば、スケジューリングデバイスが提供される。本スケジューリングデバイスは、送受信機と回路とを備えており、回路は、動作時、非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するように、送受信機を制御する。回路は、動作時、第１のデータを含む送信から、ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得し、ｉ）第２のデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣ制御要素（ＣＥ）の一部であり、ＭＡＣ ＣＥの１ビットが、第２のデータが検出されたか否かを示し、ＭＡＣ ＣＥの２ビットが、非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、第１のデータの論理チャネルグループ（ＬＣＧ）を示し、ＭＡＣ ＣＥの５ビットが、示されたＬＣＧに対応する第１のデータの、さらに送信される量を示す。
【0274】
第２３の態様によれば、スケジューリングデバイスのための方法が提供される。本方法は、以下のステップ、すなわち、
－ 非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するステップと、
－ 第１のデータを含む送信から、ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得するステップであって、ｉ）第２のデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣ制御要素（ＣＥ）の一部であり、ＭＡＣ ＣＥの１ビットが、第２のデータが検出されたか否かを示し、ＭＡＣ ＣＥの２ビットが、非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、第１のデータの論理チャネルグループ（ＬＣＧ）を示し、ＭＡＣ ＣＥの５ビットが、示されたＬＣＧに対応する第１のデータの、さらに送信される量を示す、ステップと、
を含む。
－ 非アクティブ状態にあるユーザ機器（ＵＥ）から、第１のデータを含む送信を受信するステップと、
－ 第１のデータを含む送信から、ＵＥによって第２のデータが検出されたことを示すトラフィック指示を取得するステップであって、ｉ）第２のデータが、接続状態にあるＵＥによって送信されるデータであり、ｉｉ）トラフィック指示が、ＭＡＣ制御要素（ＣＥ）の一部であり、ＭＡＣ ＣＥの１ビットが、第２のデータが検出されたか否かを示し、ＭＡＣ ＣＥの２ビットが、非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、第１のデータの論理チャネルグループ（ＬＣＧ）を示し、ＭＡＣ ＣＥの５ビットが、示されたＬＣＧに対応する第１のデータの、さらに送信される量を示す、ステップと、
を含む。
【0275】
第２４の態様によれば、ユーザ機器（ＵＥ）が提供される。本ＵＥは、送受信機と回路とを備える。回路は、動作時、非アクティブ状態において第１の論理チャネルの第１のデータを送信するための手順中に、第２の論理チャネルの第２のデータが非アクティブ状態において送信されることを検出する。
【0276】
第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順である。第２の論理チャネルには、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。回路は、動作時、待機するべき送信機会が存在するか否かを判定し、待機するべき送信機会は、（ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、（ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、動作時、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する。待機するべき送信機会が存在すると判定され、その送信機会が発生すると、回路は、動作時、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように、送受信機を制御する。
【0277】
第２４の態様に加えて提供される第２５の態様によれば、回路は、動作時、（ｉ）ＣＧ手順の次のリソースがＲＡリソースの次のＲＡリソースよりも早い場合、待機するべき送信機会が存在すると判定し、その送信機会を使用してトラフィック指示を送信するように送受信機を制御し、（ｉｉ）ＣＧ手順の次のリソースが次のＲＡリソースよりも遅い場合、待機するべき送信機会が存在しないと判定し、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する。
【0278】
第２４の態様に加えて提供される第２６の態様によれば、回路は、動作時、ＣＧ手順の次のリソースまでの時間と遅延しきい値との比較に基づいて、待機するべき送信機会が存在するか否かを判定する。
【0279】
第２４の態様から第２６の態様のうちの一態様に加えて提供される第２７の態様によれば、トラフィック指示は、媒体アクセス制御（ＭＡＣ）サブヘッダにおいて、ＭＡＣサブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ＬＣＩＤの事前定義値が、第２のデータが検出されたことを示す。
【0280】
第２７の態様に加えて提供される第２８の態様によれば、回路は、動作時、（ｉ）さらに送信される第１のデータの量、および／または（ｉｉ）第２のデータの量、を示すＢＳＲ ＭＡＣ ＣＥをＭＡＣサブヘッダに付加するか否かを決定する。
【0281】
第２７の態様に加えて提供される第２９の態様によれば、ＬＣＩＤの事前定義値は、ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていないことを示す。
【0282】
第２７の態様に加えて提供される第３０の態様によれば、ＬＣＩＤは、バッファ状態報告（ＢＳＲ）ＭＡＣ制御要素（ＣＥ）がＭＡＣサブヘッダに付加されていることを示し、ＢＳＲ ＭＡＣ ＣＥは、さらに送信される第１のデータの量を示す。
【0283】
第２４の態様から第３０の態様のうちの一態様に加えて提供される第３１の態様によれば、トラフィック指示は、第２のデータの量を示す指示を含む。
【0284】
第２４の態様から第２６の態様のうちの一態様に加えて提供される第３２の態様によれば、トラフィック指示は、媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）の一部であり、（ｉ）ＭＡＣ ＣＥの１ビットが、第２のデータが検出されたか否かを示し、（ｉｉ）ＭＡＣ ＣＥの２ビットが、非アクティブ状態におけるデータの送信をサポートするＬＣＧのうち、第１のデータの論理チャネルグループ（ＬＣＧ）を示し、（ｉｉｉ）ＭＡＣ ＣＥの５ビットが、第２のデータの量を示す。
【0285】
第２４の態様から第３１の態様のうちの一態様に加えて提供される第３３の態様によれば、トラフィック指示は、無線リソース制御（ＲＲＣ）レベルの指示、および／または媒体アクセス制御（ＭＡＣ）レベルの指示である。
【0286】
第３４の態様によれば、ユーザ機器（ＵＥ）のための方法が提供される。本方法は、非アクティブ状態において第１の論理チャネルの第１のデータを送信するための手順中に、非アクティブ状態において第２の論理チャネルの第２のデータが送信されることを検出するステップ、を含む。第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順である。第２の論理チャネルには、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。本方法は、待機するべき送信機会が存在するか否かを判定するステップをさらに含み、待機するべき送信機会は、（ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、（ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する。待機するべき送信機会が存在すると判定され、その送信機会が発生すると、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信する。
【0287】
第３５の態様によれば、スケジューリングデバイスが提供される。本スケジューリングデバイスは、送受信機と回路とを備える。回路は、動作時、（ｉ）送受信機を制御して、非アクティブ状態にあるユーザ機器（ＵＥ）から、第１の論理チャネルの第１のデータを含む送信を受信し、（ｉｉ）第１のデータを含む送信から、ＵＥによって第２の論理チャネルの第２のデータが検出されたことを示すトラフィック指示を取得する。第２のデータは、非アクティブ状態にあるＵＥによって送信されるデータであり、第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順である。第２の論理チャネルには、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。トラフィック指示は、媒体アクセス制御（ＭＡＣ）サブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ＬＣＩＤの事前定義値は、第２のデータが検出されたことを示す。
【0288】
第３６の態様によれば、スケジューリングデバイスのための方法が提供される。本方法は、（ｉ）非アクティブ状態にあるユーザ機器（ＵＥ）から、第１の論理チャネルの第１のデータを含む送信を受信するステップと、（ｉｉ）第１のデータを含む送信から、ＵＥによって第２の論理チャネルの第２のデータが検出されたことを示すトラフィック指示を取得するステップと、を含む。第２のデータは、非アクティブ状態にあるＵＥによって送信されるデータであり、第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順である。第２の論理チャネルには、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。トラフィック指示は、媒体アクセス制御（ＭＡＣ）サブヘッダ内の論理チャネルＩＤ（ＬＣＩＤ）の事前定義値によってシグナリングされ、ＬＣＩＤの事前定義値は、第２のデータが検出されたことを示す。
【0289】
要約すると、ユーザ機器（ＵＥ）、対応するスケジューリングデバイス、ならびにＵＥおよびスケジューリングデバイスのそれぞれの方法、が提供される。
【0290】
特に、本開示は、送受信機および回路を備えるＵＥを提供し、回路は、非アクティブ状態において第１のデータを送信するための手順中に、接続状態において第２のデータが送信されることを検出する。回路は、待機するべき送信機会が存在するか否かを判定する。待機するべき送信機会は、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、接続状態に入るためにランダムアクセスチャネル（ＲＡＣＨ）手順を開始する。待機するべき送信機会が存在すると判定され、その送信機会が発生すると、回路は、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように送受信機を制御する。
【0291】
本開示はまた、送受信機と回路とを備えるＵＥを提供し、回路は、非アクティブ状態において第１の論理チャネルの第１のデータを送信するための手順中に、非アクティブ状態において第２の論理チャネルの第２のデータが送信されることを検出する。より具体的には、第１のデータを送信するための手順は、第１のデータを送信するためのコンフィギュアドグラント（ＣＧ）手順であり、第２の論理チャネルには、（ｉ）非アクティブ状態において送信するためのＣＧリソースが設定されておらず、（ｉｉ）非アクティブ状態において送信するためのランダムアクセス（ＲＡ）リソースが設定されている。回路は、待機するべき送信機会が存在するか否かを判定する。待機するべき送信機会は、ｉ）第１のデータの少なくとも一部を送信するための送信機会であり、ｉｉ）第１のデータを送信するための手順の一部として発生すると予期される。待機するべき送信機会が存在しない、または待機するべき送信機会がもはや発生する見込みがない、と判定されたとき、回路は、ＲＡリソースを使用して第２のデータを送信するためにＲＡ手順を開始する。一方、待機するべき送信機会が存在すると判定され、その送信機会が発生すると、回路は、その送信機会を使用して、第２のデータの検出を示すトラフィック指示を送信するように、送受信機を制御する。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【国際調査報告】