特許 7405265 端末装置及び基地局

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

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

(11)【特許番号】

(24)【登録日】2023-12-18

(45)【発行日】2023-12-26

(54)【発明の名称】端末装置及び基地局

(51)【国際特許分類】

   H04W 76/25 20180101AFI20231219BHJP

   H04W 72/23 20230101ALI20231219BHJP

   H04W 72/1268 20230101ALI20231219BHJP

   H04W 74/08 20090101ALI20231219BHJP

   H04W 72/20 20230101ALI20231219BHJP

【ＦＩ】

H04W76/25

H04W72/23

H04W72/1268

H04W74/08

H04W72/20

【請求項の数】 14

(21)【出願番号】P 2022544417

(86)(22)【出願日】2020-01-22

(65)【公表番号】

(43)【公表日】2023-03-16

(86)【国際出願番号】 CN2020073897

(87)【国際公開番号】W WO2021147029

(87)【国際公開日】2021-07-29

【審査請求日】2022-09-21

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】リャン リン

(72)【発明者】

【氏名】ワン ガン

【審査官】長谷川 未貴

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０２７９３７５（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１９／０２５３１９７（ＵＳ，Ａ１）

【文献】Alcatel-Lucent, Alcatel-Lucent Shanghai Bell，Considerations on RACH for LC-MTC，R2-153673，2015年08月14日

【文献】ZTE，Remaining issues for EDT，3GPP TSG RAN WG2 #100 R2-1712982，2017年11月17日

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

ＩＰＣ Ｈ０４Ｂ ７／２４ － ７／２６

Ｈ０４Ｗ ４／００ － ９９／００

ＤＢ名 ３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

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

【請求項1】

端末装置であって、
基地局から、設定されたスケジューリングＲＮＴＩ（ＣＳ－ＲＮＴＩ）を含む無線リソース制御（ＲＲＣ）リリースメッセージを受信する手段と、
前記ＲＲＣリリースメッセージに基づいて、スモールデータ送信（ＳＤＴ）のための手順を実行する手段と、
前記ＳＤＴのための前記手順において、非アクティブ状態を保持しながら、前記ＣＳ－ＲＮＴＩに基づいて、アップリンク送信を実行する手段と、
前記ＳＤＴのための前記手順において、前記端末装置のセル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ）に宛てられた物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視する手段と、
を備える端末装置。

【請求項2】

前記監視する手段は、前記Ｃ－ＲＮＴＩに宛てられた前記ＰＤＣＣＨを、タイマが満了するまで監視する、
請求項１に記載の端末装置。

【請求項3】

前記タイマの値は、システム情報においてブロードキャストされる、
請求項２に記載の端末装置。

【請求項4】

前記監視する手段は、ＲＲＣリリースメッセージを受信するまで、前記Ｃ－ＲＮＴＩに宛てられた前記ＰＤＣＣＨを監視する、
請求項１に記載の端末装置。

【請求項5】

アップリンクグラント又はダウンリンク割当の少なくとも１つがダウンリンク制御情報（ＤＣＩ）において運ばれ、前記ＤＣＩは、前記Ｃ－ＲＮＴＩに宛てられた前記ＰＤＣＣＨにおいて送信され、
前記ＳＤＴのための前記手順は、前記アップリンクグラント又は前記ダウンリンク割当の少なくとも１つに基づく、
請求項１から４のいずれか１つに記載の端末装置。

【請求項6】

前記アップリンクグラントに基づいて、後続のアップリンク送信を行う手段をさらに備える、
請求項５に記載の端末装置。

【請求項7】

前記ＳＤＴのための前記手順は、設定されたグラントに基づく、
請求項１から６のいずれか１つに記載の端末装置。

【請求項8】

基地局であって、
端末装置へ、設定されたスケジューリングＲＮＴＩ（ＣＳ－ＲＮＴＩ）を含む無線リソース制御（ＲＲＣ）リリースメッセージを送信する手段と、
前記ＲＲＣリリースメッセージに基づいて実行されるスモールデータ送信（ＳＤＴ）のための手順において、前記端末装置が非アクティブ状態を保持しながら実行するアップリンク送信を、前記ＣＳ－ＲＮＴＩに基づいて受信する手段と、
前記ＳＤＴのための前記手順において、前記端末装置のセル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ）に宛てられた物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を送信する手段と、
を備える基地局。

【請求項9】

前記Ｃ－ＲＮＴＩに宛てられた前記ＰＤＣＣＨは、タイマが満了するまで、前記端末装置によって監視される、
請求項８に記載の基地局。

【請求項10】

前記タイマの値を、システム情報においてブロードキャストする手段をさらに備える、
請求項９に記載の基地局。

【請求項11】

前記Ｃ－ＲＮＴＩに宛てられた前記ＰＤＣＣＨは、ＲＲＣリリースメッセージが前記端末装置によって受信されるまで、前記端末装置によって監視される、
請求項８に記載の基地局。

【請求項12】

アップリンクグラント又はダウンリンク割当の少なくとも１つがダウンリンク制御情報（ＤＣＩ）において運ばれ、前記ＤＣＩは、前記Ｃ－ＲＮＴＩに宛てられた前記ＰＤＣＣＨにおいて送信され、
前記ＳＤＴのための前記手順は、前記アップリンクグラント又は前記ダウンリンク割当の少なくとも１つに基づく、
請求項８から１１のいずれか１つに記載の基地局。

【請求項13】

前記アップリンクグラントに基づいて、後続のアップリンク送信が行われる、
請求項１２に記載の基地局。

【請求項14】

前記ＳＤＴのための前記手順は、設定されたグラントに基づく、
請求項８から１３のいずれか１つに記載の基地局。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、電気通信分野に関し、特にスモールデータ送信の通信のための方法、デバイス、及びコンピュータ記憶媒体に関する。

【背景技術】

【0002】

一般的に、非アクティブ状態の端末デバイスであっても、送信すべきスモールで低頻度のデータトラフィック（以下、ＳＤＴとも称する）を有することがある。第３世代パートナーシッププロジェクト（３ＧＰＰ）リリース１６までは、非アクティブ状態でデータ送信をサポートできず、端末デバイスは、いかなるダウンリンク及びアップリンクのデータに対しても接続を再開しなければならない。接続の確立とその後の非アクティブ状態へのリリースは、データパケットがどれ程小さく頻度が低いものであっても、データ送信ごとに発生する。これは、不要な電力消費と信号のオーバーヘッドにつながる。

【0003】

こうした状況の中、３ＧＰＰリリース１７では、非アクティブ状態でのランダムアクセスチャネル（ＲＡＣＨ）に基づくスモールデータ送信が承認されている。無線リソース制御（ＲＲＣ）メッセージなしでスモールデータ送信を実行することができれば、シグナリングのオーバーヘッドをさらに削減することができる。そのため、ＲＲＣシグナリングなしでスモールデータ送信を実行する方法が議論の的となっている。

【発明の概要】

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

【0004】

概して、本開示の実施形態は、スモールデータ送信の通信のための方法、デバイス、及びコンピュータ記憶媒体を提供する。

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

【0005】

第１の態様において、通信のための方法が提供される。前記方法は、非アクティブ状態の端末デバイスにおいて、メディアアクセス制御層の第１制御要素を生成することであって、前記第１制御要素が前記端末デバイスの第１アイデンティティを運ぶことと、ネットワークデバイスに前記第１制御要素とアップリンクデータを送信することと、を含む。

【0006】

第２の態様において、通信のための方法が提供される。前記方法は、ネットワークデバイスにおいて、端末デバイスからメディア制御層の第１制御要素とアップリンクデータとを受信することであって、前記第１制御要素が前記端末デバイスの第１アイデンティティを運ぶことと、前記アップリンクデータをコアネットワーク要素に送信することと、を含む。

【0007】

第３の態様では、端末デバイスが提供される。前記端末デバイスは、プロセッサと、プロセッサに結合されるメモリとを含む。メモリには命令が格納されており、前記命令は、プロセッサにより実行された場合に、端末デバイスに、本開示の第１の態様にかかる方法を実行させる。

【0008】

第４の態様では、ネットワークデバイスが提供される。前記ネットワークデバイスは、プロセッサと、プロセッサに結合されるメモリとを含む。メモリには命令が格納されており、前記命令は、プロセッサにより実行された場合に、ネットワークデバイスに、本開示の第２の態様にかかる方法を実行させる。

【0009】

第５の態様において、命令が格納されたコンピュータ可読媒体が提供される。前記命令は、少なくとも１つのプロセッサ上で実行された場合に、前記少なくとも１つのプロセッサに、本開示の第１の態様に基づく方法を実行させる。

【0010】

第６の態様において、命令が格納されたコンピュータ可読媒体が提供される。前記命令は、少なくとも１つのプロセッサ上で実行された場合に、前記少なくとも１つのプロセッサに、本開示の第２の態様に基づく方法を実行させる。

【0011】

本開示のその他の特徴は、以下の説明により容易に理解できるはずである。

【図面の簡単な説明】

【0012】

図面において本開示のいくつかの実施形態をさらに詳細に説明することで、本開示の上述及びその他の目的、特徴及び有益な効果がさらに明らかになるはずである。

【0013】

【図1】本開示のいくつかの実施形態を実施可能な例示的通信ネットワークを示す。

【0014】

【図2】本開示のいくつかの実施形態にかかるスモールデータ送信のための通信プロセスを説明する模式図を示す。

【0015】

【図3】本開示のいくつかの実施形態にかかる４ステップＲＡＣＨ手順の間の通信プロセスを説明する模式図を示す。

【0016】

【図4】本開示のいくつかの実施形態にかかる２ステップＲＡＣＨ手順の間の通信プロセスを説明する模式図を示す。

【0017】

【図5】本開示のいくつかの実施形態にかかる、端末デバイスで実施される例示的な通信方法を示す。

【0018】

【図6】本開示のいくつかの実施形態にかかる、端末デバイスについての第１認証情報及び第１アイデンティティを運ぶメディアアクセス制御層の制御要素（ＭＡＣ ＣＥ）の実装を説明する模式図を示す。

【0019】

【図7】本開示のいくつかの実施形態にかかる、端末デバイスについての第１認証情報及び第１アイデンティティを運ぶＭＡＣ ＣＥの別の実装を説明する模式図を示す。

【0020】

【図8】本開示のいくつかの実施形態にかかる、４ステップＲＡＣＨ手順のための、コンテンション解決情報（contention resolution information）を運ぶＭＡＣ ＣＥの実装を説明する模式図を示す。

【0021】

【図9】本開示のいくつかの実施形態にかかる、２ステップＲＡＣＨ手順のための、コンテンション解決情報を運ぶ成功したランダムアクセス応答（ＲＡＲ）の実装を説明する模式図を示す。

【0022】

【図10】本開示のいくつかの実施形態にかかる、端末デバイスで実施される別の例示的な通信方法を示す。

【0023】

【図11】本開示のいくつかの実施形態にかかる、端末デバイスで実施される別の例示的な通信方法を示す。

【0024】

【図12】本開示のいくつかの実施形態にかかる、ネットワークデバイスで実施される例示的な通信方法を示す。

【0025】

【図13】本開示のいくつかの実施形態にかかる、ネットワークデバイスで実施される別の例示的な通信方法を示す。

【0026】

【図14】本開示の実施形態を実施するのに適したデバイスの概略ブロック図である。

【0027】

全ての図において、同一又は類似の図面符号は、同一又は類似の要素を示す。

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

【0028】

以下、いくつかの例示的な実施形態を参照して、本開示の原理を説明する。理解すべき点として、これらの実施形態は、単に説明を目的とし、当業者が本開示を理解し実施する際の助けとなるものであり、本開示の範囲に対する何らかの限定を暗示するものではない。本明細書で説明する開示内容は、以下に説明する方法以外に、様々な方法で実施可能である。

【0029】

以下の説明及び請求項において、別に定義がある場合を除き、文中で使用される全ての技術用語・科学用語は、本開示が属する分野の当業者が通常理解するものと同じ意味を有する。

【0030】

文中で使用される用語「端末デバイス」は、無線又は有線での通信能力を有する全てのデバイスを指す。端末デバイスの例には、ユーザ端末（ＵＥ）、パーソナルコンピュータ、デスクトップコンピュータ、移動電話、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、携帯コンピュータ、タブレット、ウェアラブルデバイス、モノのインターネット（ＩｏＴ）デバイス、すべてのインターネット（ＩｏＥ）デバイス、マシンタイプコミュニケーション（ＭＴＣ）デバイス、Ｖ２Ｘ通信用の車載デバイス（Ｘは歩行者、車両又はインフラ／ネットワークを表す）、デジタルカメラのような画像取込デバイス、ゲーム機器、音楽保存再生装置、又は無線若しくは有線によるインターネットへのアクセス・閲覧を可能にするインターネットツール等が含まれるが、これらに限定されない。「端末デバイス」という用語は、ＵＥ、移動局、加入者局、移動端末、ユーザ端末又は無線デバイスと互換的に使用することができる。また、用語「ネットワークデバイス」は、端末デバイスが通信可能なセル又はカバレッジを、提供又は管理可能なデバイスを指す。ネットワークデバイスの例には、ノードＢ（ＮｏｄｅＢ又はＮＢ）、進化型ＮｏｄｅＢ（ｅＮｏｄｅＢ又はｅＮＢ）、次世代ＮｏｄｅＢ（ｇＮＢ）、送信／受信ポイント（ＴＲＰ）、リモートラジオユニット（ＲＲＵ）、無線ヘッド（ＲＨ）、リモート無線ヘッド（ＲＲＨ）、例えばフェムトノード、ピコノード等の低電力ノードが含まれるが、これらに限定されない。

【0031】

１つの実施形態において端末デバイスは、第１ネットワークデバイス及び第２ネットワークデバイスと接続してもよい。第１ネットワークデバイス及び第２ネットワークデバイスのうち、一方はマスターノードであり、他方はセカンダリノードであり得る。第１ネットワークデバイスと第２ネットワークデバイスは、異なるＲＡＴを使用してもよい。１つの実施形態において第１ネットワークデバイスは、第１ＲＡＴデバイスであり、第２ネットワークデバイスは、第２ＲＡＴデバイスであり得る。１つの実施形態では、第１ＲＡＴデバイスはｅＮＢであり、第２ＲＡＴデバイスはｇＮＢである。異なるＲＡＴに関連する情報は、第１ネットワークデバイス及び第２ネットワークデバイスの少なくとも一方から端末デバイスに送信されてもよい。１つの実施形態において、第１情報は、第１ネットワークデバイスから端末デバイスに送信されてもよく、第２情報は、第２ネットワークデバイスから、直接又は第１ネットワークデバイスを介して端末デバイスに送信されてもよい。１つの実施形態では、第２ネットワークデバイスによって設定された、端末デバイスの設定と関連する情報が、第２ネットワークデバイスから第１ネットワークデバイスを介して送信されてもよい。また、第２ネットワークデバイスによって設定された、端末デバイスの再設定と関連する情報が、第２ネットワークデバイスから、直接又は第１ネットワークデバイスを介して端末デバイスに送信されてもよい。

【0032】

文中で使用される場合、文脈の中で他に明記していない限り、単数形式である「１つ」、「１つの」及び「当該」は、複数形式を含むことを意味する。用語「含む」及びその変形は、「…を含むが、これらに限定されない」という意味の、開放式の用語であると解釈される。用語「…に基づいて」は、「少なくとも部分的に基づく」と解釈される。用語「１つの実施形態」及び「実施形態」は、「少なくとも１つの実施形態」と解釈される。用語「別の実施形態」は、「少なくとも１つの別の実施形態」と解釈される。用語「第１」、「第２」等は、異なるか又は同一の対象を指すことができる。以下の説明では、その他の定義も、明確及び暗黙のものとして含むことができる。

【0033】

いくつかの例示において、値、プロセス又は装置は、「最適」、「最低」、「最高」、「最小」、「最大」等と称される。理解すべき点として、こうした説明は、使用される複数の機能のオプションから、選択可能であると示すことを意図しており、こうした選択は、他の選択と比べて、より優れていたり、より小さかったり、より高かったり、又はより好ましかったりする必要はない。

【0034】

図１は、本開示の実施形態を実施可能な例示的な通信ネットワーク１００の模式図を示す。図１に示すように、通信ネットワーク１００は、ネットワークデバイス１１０と、ネットワークデバイス１１０がサービスを提供する端末デバイス１２０とを含む。ネットワークデバイス１１０は、無線通信チャネルのようなチャネルを介して端末デバイス１２０と通信してもよい。

【0035】

通信ネットワーク１００はさらに、コアネットワーク１３０内に位置するコアネットワーク要素１３１を含んでもよい。例えば、いくつかの実施形態では、コアネットワーク要素１３１は、ユーザプレーン機能（ＵＰＦ）を実行してもよい。コアネットワーク要素１３１は任意の他の追加機能を実行してもよく、本願ではこの点について限定しないことに留意されたい。

【0036】

端末デバイス１２０は、ネットワークデバイス１１０を介してコアネットワーク要素１３１と通信してもよい。例えば、端末デバイス１２０はデータパケット（すなわち、アップリンクデータ）をネットワークデバイス１１０に送信してもよく、また、ネットワークデバイス１１０はアップリンクデータをコアネットワーク要素１３１に送信してもよい。したがって、コアネットワーク要素１３１はデータパケット（すなわち、ダウンリンクデータ）をネットワークデバイス１１０に送信してもよく、ネットワークデバイス１１０はダウンリンクデータを端末デバイス１２０に送信してもよい。

【0037】

理解すべき点として、図１におけるデバイスの数は説明を目的として示されたものであり、本開示に対する何らかの限定を暗示するものではない。ネットワーク１００は、本開示の実施に適した任意の適切な数のネットワークデバイス及び／又は端末デバイス及び／又はコアネットワーク要素を含んでもよい。

【0038】

ネットワーク１００の通信は、任意の適切な規格に適合していてもよい。任意の適切な規格には移動通信用グローバルシステム（ＧＳＭ）、ロングタームエボリューション（ＬＴＥ）、ＬＴＥ－アドバンスト（ＬＴＥ－Ａ）、広帯域符号分割多元接続（ＷＣＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、ＧＳＭ ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）、マシンタイプコミュニケーション（ＭＴＣ）等が含まれるが、これらに限定されない。また、現在既知の又は将来開発される任意の世代の通信プロトコルに基づき、通信を実行してもよい。通信プロトコルの例として、第１世代（１Ｇ）、第２世代（２Ｇ）、２．５Ｇ、２．７５Ｇ、第３世代（３Ｇ）、第４世代（４Ｇ）、４．５Ｇ、第５世代（５Ｇ）の通信プロトコルが含まれるが、これらに限定されない。

【0039】

上述したように、非アクティブ状態の端末デバイス１２０であっても、送信すべきスモールで低頻度のデータトラフィックを有することがある。いくつかの実施形態において、スモールで低頻度のデータトラフィックは、インスタントメッセージング（ＩＭ）サービス（ｗｈａｔｓａｐｐ、ＱＱ、ｗｅｃｈａｔ等）からのトラフィック、ＩＭ／メールクライアントや他のアプリケーションからのハートビート／キープアライブのトラフィック、様々なアプリケーションからのプッシュ通知等のスマートフォンアプリケーションを含んでもよい。いくつかの実施形態において、スモールで低頻度のデータトラフィックは、例えばウェアラブル（定期的な位置情報等）、センサ（温度、圧力測定値を定期的に又はイベントトリガ方式で送信する産業用無線センサネットワーク（Industrial Wireless Sensor Networks）等）、定期的なメーター測定値を送信するスマートメーター及びスマートメーターネットワークからのトラフィック等のスマートフォン以外のアプリケーションを含んでもよい。

【0040】

現在、シグナリングのオーバーヘッドを削減するために、ＲＲＣメッセージを必要としないＲＡＣＨベースの方式でスモールデータ送信を実行することが提案されている。しかし、より詳細な方式は提案されていない。本開示の実施形態は、スモールデータ送信のための通信方式を提供する。この方式により、端末デバイスの非アクティブ状態において、信号のオーバーヘッドを低減しつつスモールデータ送信を実現することができる。以下、図面を参照し、本開示の原理及び実施について詳細に説明する。

【0041】

図２は、本開示のいくつかの実施形態にかかるスモールデータ送信のための通信プロセス２００の模式図を示す。議論を目的として、図１を参照しつつプロセス２００を説明する。プロセス２００は、図１に示す端末デバイス１２０、ネットワークデバイス１１０及びコアネットワーク要素１３１に関わっていてもよい。

【0042】

図２に示すように、非アクティブ状態の端末デバイス１２０は、第１メディアアクセス制御層の制御要素（ＭＡＣ ＣＥ）を生成する（２１０）。第１ＭＡＣ ＣＥは、端末デバイス１２０の第１アイデンティティを運ぶ。第１アイデンティティは、非アクティブ状態において端末デバイス１２０が使用するアイデンティティである。いくつかの実施形態において、第１アイデンティティは、非アクティブ状態の端末デバイス１２０の一時的なアイデンティティ、例えば、非アクティブの無線ネットワーク一時識別子（Ｉ－ＲＮＴＩ）であってもよい。

【0043】

いくつかの実施形態において、端末デバイス１２０で送信されるアップリンクデータがスモールで低頻度のデータトラフィックに関連付けられている場合、端末デバイス１２０は第１ＭＡＣ ＣＥを生成してもよい。いくつかの実施形態において、第１ＭＡＣ ＣＥは新たに定義されてもよい。第１アイデンティティを運ぶ第１ＭＡＣ ＣＥは、第１アイデンティティを運ぶＲＲＣメッセージと比較して、信号のオーバーヘッドを大幅に削減することができる。

【0044】

第１ＭＡＣ ＣＥが生成された後、端末デバイス１２０は第１ＭＡＣ ＣＥとアップリンクデータを送信する。いくつかの実施形態において、端末デバイス１２０は物理アップリンク共有チャネル（ＰＵＳＣＨ）において第１ＭＡＣ ＣＥとアップリンクデータを送信してもよい。いくつかの実施形態において、端末デバイス１２０は４ステップＲＡＣＨ手順の間に第１ＭＡＣ ＣＥとアップリンクデータを送信してもよい。いくつかの実施形態において、端末デバイス１２０は２ステップＲＡＣＨ手順の間に第１ＭＡＣ ＣＥとアップリンクデータを送信してもよい。

【0045】

したがって、第１ＭＡＣ ＣＥとアップリンクデータを受信すると、ネットワークデバイス１１０はアップリンクデータをコアネットワーク要素１３１に送信する。いくつかの実施形態において、端末デバイス１２０は、いかなるコンテンション解決も待たずにアップリンクデータをネットワークデバイス１１０に送信するだけでよい。この場合、ネットワークデバイス１１０は、端末デバイス１２０に対してコンテンション解決タイマ又はＲＡＲウィンドウを設定しなくてもよい。いくつかの代替的な実施形態において、端末デバイス１２０は、コンテンション解決の結果を受信してもよい。図３及び図４を参照しながら、これについてより詳細に説明する。

【0046】

図３は、本開示のいくつかの実施形態にかかる４ステップＲＡＣＨ手順の間の通信プロセス３００を説明する模式図を示す。議論を目的として、図１を参照しつつプロセス３００を説明する。プロセス３００は、図１に示す端末デバイス１２０、ネットワークデバイス１１０及びコアネットワーク要素１３１に関わっていてもよい。

【0047】

図３に示すように、非アクティブ状態の端末デバイス１２０は、ネットワークデバイス１１０にランダムプリアンブルシーケンスを送信してもよい（３０１）。いくつかの実施形態において、端末デバイス１２０はＲＡＣＨにおいてランダムプリアンブルシーケンスを送信してもよい。いくつかの実施形態において、端末デバイス１２０で送信されるアップリンクデータがスモールで低頻度のデータトラフィックに関連付けられている場合、端末デバイス１２０はランダムプリアンブルシーケンスを送信してもよい。したがって、端末デバイス１２０はネットワークデバイス１１０からＲＡＲを受信してもよい（３０２）。ＲＡＲは、一時セル無線ネットワーク一時識別子（ＴＣ－ＲＮＴＩ：Temporary Cell Radio Network Temporary Identifier）を含んでもよい。

【0048】

その後、端末デバイス１２０は、端末デバイス１２０の第１アイデンティティ（例えば、Ｉ－ＲＮＴＩ）を運ぶ第１ＭＡＣ ＣＥを生成してもよい（３０３）。いくつかの実施形態において、第１ＭＡＣ ＣＥはさらに、端末デバイス１２０についての第１認証情報を運んでもよく、第１アイデンティティと第１認証情報は第１ＭＡＣ ＣＥの異なるフィールドにある。いくつかの代替的な実施形態において、端末デバイス１２０はさらに、端末デバイス１２０についての第１認証情報を運ぶ第２ＭＡＣ ＣＥを生成してもよい（３０４）。第１認証情報は、ネットワークデバイス１１０において端末デバイス１２０の有効性を検証するために用いられる。例えば、第１認証情報は、整合性のためのショートメッセージ認証コード（ＳｈｏｒｔＭＡＣ－Ｉ：short message authentication code for integrity）の形式であってもよい。

【0049】

端末デバイス１２０は、第１ＭＡＣ ＣＥとアップリンクデータをネットワークデバイス１１０に送信してもよい（３０５）。端末デバイス１２０がネットワークデバイス１１０によって検証される必要があるいくつかの実施形態において、端末デバイス１２０は、第１ＭＡＣ ＣＥ、アップリンクデータ、及び第２ＭＡＣ ＣＥをネットワークデバイス１１０に送信してもよい。いくつかの実施形態において、端末デバイス１２０は、第１ＭＡＣ ＣＥ、アップリンクデータ、第２ＭＡＣ ＣＥ、及びバッファ状態報告（ＢＳＲ）をネットワークデバイス１１０に送信してもよい。ＢＳＲは、送信すべき残りのアップリンクデータの量を示してもよい。

【0050】

送信３０５について、送信メッセージはＴＣ－ＲＮＴＩによってスクランブルされる。いくつかの実施形態において、ネットワークデバイス１１０がアップリンクデータをコアネットワーク要素１３１に転送し、コアネットワーク要素１３１からのダウンリンクデータを待つ必要がある場合、拡張コンテンション解決タイマが起動されてもよい。４ステップＲＡＣＨ手順用のいくつかの実施形態において、より長いコンテンション解決タイマが使用されてもよく、例えば、ＥＮＵＭＥＲＡＴＥＤ｛ｓｆ８、ｓｆ１６、ｓｆ２４、ｓｆ３２、ｓｆ４０、ｓｆ４８、ｓｆ５６、ｓｆ６４、ｓｆ８０、ｓｆ１００、ｓｆ１２０、ｓｆ１６０、ｓｆ２００、ｓｆ２４０、ｓｆ４８０、ｓｆ９６０、ｓｆ１９２０、ｓｆ３８４０、ｓｆ５７６０、ｓｆ７６８０、ｓｆ１０２４０｝が使用されてもよい。

【0051】

いくつかの実施形態において、拡張コンテンション解決タイマは、システムメッセージによってブロードキャストされてもよい。いくつかの代替的な実施形態において、拡張コンテンション解決タイマは、専用のＲＲＣメッセージを使用して端末デバイス１２０に設定してもよい。

【0052】

ネットワークデバイス１１０による端末デバイス１２０の検証が必要とされるいくつかの実施形態において、ネットワークデバイス１１０は、第２ＭＡＣ ＣＥから第１認証情報を判定し、第１認証情報に基づいて端末デバイス１２０の有効性を検証してもよい（３０６）。いくつかの実施形態において、端末デバイス１２０が有効であると判定された場合、ネットワークデバイス１１０は、アップリンクデータをコアネットワーク要素１３１に送信してもよい（３０７）。いくつかの実施形態において、端末デバイス１２０が無効であると判定された場合、ネットワークデバイス１１０はアップリンクデータを破棄してもよい。コアネットワーク要素１３１から送信されるべきダウンリンクデータがあるいくつかの実施形態では、ネットワークデバイス１１０は、コアネットワーク要素１３１からダウンリンクデータを受信してもよい（３０８）。

【0053】

ネットワークデバイス１１０は、コンテンション解決情報を運ぶ第３ＭＡＣ ＣＥを生成し（３０９）、第３ＭＡＣ ＣＥをネットワークデバイス１１０に送信してもよい（３１０）。いくつかの実施形態において、コンテンション解決情報は、コンテンション解決が成功した端末デバイスの識別子アイデンティティを含んでもよい。いくつかの実施形態において、ネットワークデバイス１１０は物理ダウンリンク共有チャネル（ＰＤＳＣＨ）において第３ＭＡＣ ＣＥを送信してもよい。

【0054】

コンテンション解決情報には、端末デバイス１２０の第１アイデンティティが含まれるものと仮定する。端末デバイス１２０においてネットワークデバイス１１０の検証が必要とされるいくつかの実施形態において、ネットワークデバイス１１０は、ネットワークデバイス１１０についての第２認証情報を運ぶ第４ＭＡＣ ＣＥを生成してもよい。例えば、第２認証情報はＳｈｏｒｔＭＡＣ－Ｉの形式であってもよい。この場合、ネットワークデバイス１１０は、第３ＭＡＣ ＣＥとともに第４ＭＡＣ ＣＥを端末デバイス１２０に送信してもよい。

【0055】

ネットワークデバイス１１０が、送信すべきアップリンクデータがまだ残っていることを示すＢＳＲを受信するいくつかの実施形態では、ネットワークデバイス１１０は、第３ＭＡＣ ＣＥを有するアップリンクグラント情報を端末デバイス１２０に送信してもよい。いくつかの追加の実施形態において、ネットワークデバイス１１０は、第３ＭＡＣ ＣＥ、第４ＭＡＣ ＣＥ、及びアップリンクグラント情報を端末デバイス１２０に送信してもよい。

【0056】

ネットワークデバイス１１０がコアネットワーク要素１３１から端末デバイス１２０宛のダウンリンクデータを受信するいくつかの実施形態では、ネットワークデバイス１１０は、第３ＭＡＣ ＣＥ、第４ＭＡＣ ＣＥ、アップリンクグラント情報、及びダウンリンクデータを端末デバイス１２０に送信してもよい。

【0057】

端末デバイス１２０の第１アイデンティティを含む第３ＭＡＣ ＣＥを受信すると、端末デバイス１２０は、ＴＣ－ＲＮＴＩをセル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ）として使用して後続のデータ送信を実行してもよい。この時点では、端末デバイス１２０は非アクティブ状態のままである。

【0058】

いくつかの実施形態において、端末デバイス１２０は、ネットワークデバイス１１０から受信した第２認証情報に基づいて、ネットワークデバイス１１０の有効性を検証してもよい（３１１）。ネットワークデバイス１１０が有効であると判定された場合、端末デバイス１２０は、受信したダウンリンクデータを受け入れてもよい。ネットワークデバイス１１０が無効であると判定された場合、端末デバイス１２０は、受信したダウンリンクデータを破棄してもよい。

【0059】

端末デバイス１２０は、残りのアップリンクデータの少なくとも一部とＢＳＲをネットワークデバイス１１０に送信してもよい（３１２）。いくつかの実施形態において、アップリンクグラント情報を受信したことに応じて、端末デバイス１２０は、期間終了までダウンリンクチャネルを監視してもよい。いくつかの代替的な実施形態では、残りのアップリンクデータの少なくとも一部を送信した（３１２）ことに応じて、端末デバイス１２０は、期間終了までダウンリンクチャネルを監視してもよい。

【0060】

残りのアップリンクデータの少なくとも一部を受信すると、ネットワークデバイス１１０は、それをコアネットワーク要素１３１に送信してもよい（３１３）。ネットワークデバイス１１０は、別のダウンリンクデータ及び別のアップリンクグラント情報があれば、それを受信し（３１４）、それらを端末デバイス１２０に送信してもよい（３１５）。端末デバイス１２０は残りのアップリンクデータをネットワークデバイス１１０に送信してもよく（３１６）、ネットワークデバイス１１０はそれをコアネットワーク要素１３１に送信してもよい（３１７）。

【0061】

ネットワークデバイス１１０がデータ送信の終了を示す接続リリースメッセージを送信するまで（３１８）、上述のように、端末デバイス１２０の非アクティブ状態においてＣ－ＲＮＴＩを利用することでアップリンク及びダウンリンクのデータ送信を繰り返してもよい。ＲＲＣＲｅｌｅａｓｅメッセージ等の接続リリースメッセージを受信した場合、端末デバイス１２０は、端末デバイス１２０の非アクティブ状態を初期化してもよい。

【0062】

図４は、本開示のいくつかの実施形態にかかる２ステップＲＡＣＨ手順の間の通信プロセス４００を説明する模式図を示す。議論を目的として、図１を参照しつつプロセス４００を説明する。プロセス４００は、図１に示す端末デバイス１２０、ネットワークデバイス１１０及びコアネットワーク要素１３１に関わっていてもよい。

【0063】

図４に示すように、非アクティブ状態の端末デバイス１２０は、端末デバイス１２０の第１アイデンティティ（例えば、Ｉ－ＲＮＴＩ）を運ぶ第１ＭＡＣ ＣＥを生成してもよい（４０１）。いくつかの実施形態において、第１ＭＡＣ ＣＥはさらに、端末デバイス１２０についての第１認証情報を運んでもよく、第１アイデンティティと第１認証情報は第１ＭＡＣ ＣＥの異なるフィールドにある。いくつかの代替的な実施形態において、端末デバイス１２０はさらに、端末デバイス１２０についての第１認証情報を運ぶ第２ＭＡＣ ＣＥを生成してもよい（４０２）。第１認証情報は、ネットワークデバイス１１０において端末デバイス１２０の有効性を検証するために用いられる。例えば、第１認証情報はＳｈｏｒｔＭＡＣ－Ｉの形式であってもよい。

【0064】

端末デバイス１２０で送信されるアップリンクデータがスモールで低頻度のデータトラフィックに関連付けられている場合、端末デバイス１２０は、ランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ及びアップリンクデータをネットワークデバイス１１０に送信してもよい（４０３）。いくつかの実施形態において、端末デバイス１２０は、ＲＡＣＨにおいてランダムプリアンブルシーケンスを送信し、ＰＵＳＣＨにおいて第１ＭＡＣ ＣＥとアップリンクデータを送信してもよい。端末デバイス１２０がネットワークデバイス１１０によって検証される必要があるいくつかの実施形態において、端末デバイス１２０は、ネットワークデバイス１１０にランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ、アップリンクデータ、及び第２ＭＡＣ ＣＥを送信してもよい。いくつかの実施形態において、端末デバイス１２０は、ランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ、アップリンクデータ、第２ＭＡＣ ＣＥ、及びＢＳＲをネットワークデバイス１１０に送信してもよい。

【0065】

送信４０３について、送信メッセージはランダムアクセスＲＮＴＩ（ＲＡ－ＲＮＴＩ）とランダムアクセスプリアンブル識別子（ＲＡＰＩＤ）によってスクランブルされる。いくつかの実施形態において、ネットワークデバイス１１０がアップリンクデータをコアネットワーク要素１３１に転送し、コアネットワーク要素１３１からのダウンリンクデータを待つ必要がある場合には、拡張ＲＡＲウィンドウが起動されてもよい。２ステップＲＡＣＨ手順のためのいくつかの実施形態では、ＲＡＲウィンドウは、８０ｍｓ、１６０ｍｓ、３２０ｍｓ、６４０ｍｓ・・・にさらに拡大する必要があり、これには３ビット、４ビット、５ビット、６ビット・・・が必要とされ、システムフレーム番号（ＳＦＮ）の最下位ビット（ＬＳＢ）はダウンリンク制御情報（ＤＣＩ）スケジューリングメッセージ（ｍｓｇＢ）に含められる。

【0066】

いくつかの実施形態において、拡張ＲＡＲウィンドウは、システムメッセージによってブロードキャストされてもよい。いくつかの代替的な実施形態では、専用のＲＲＣメッセージを使用することによって、拡張ＲＡＲウィンドウを端末デバイス１２０に設定してもよい。

【0067】

ネットワークデバイス１１０による端末デバイス１２０の検証が必要とされるいくつかの実施形態において、ネットワークデバイス１１０は、第２ＭＡＣ ＣＥから第１認証情報を判定し、第１認証情報に基づいて端末デバイス１２０の有効性を検証してもよい（４０４）。いくつかの実施形態において、端末デバイス１２０が有効である場合、ネットワークデバイス１１０は、コアネットワーク要素１３１にアップリンクデータを送信してもよい（４０５）。いくつかの実施形態において、端末デバイス１２０が無効である場合、ネットワークデバイス１１０は、アップリンクデータを破棄してもよい。コアネットワーク要素１３１から送信されるべきダウンリンクデータがあるいくつかの実施形態では、ネットワークデバイス１１０は、コアネットワーク要素１３１からそのダウンリンクデータを受信してもよい（４０６）。

【0068】

ネットワークデバイス１１０は、コンテンション解決情報を生成し（４０７）、成功したＲＡＲにおいてコンテンション解決情報を端末デバイス１２０（４０８）。いくつかの実施形態において、コンテンション解決情報は、コンテンション解決が成功した端末デバイスのアイデンティティを含んでもよい。いくつかの実施形態において、ネットワークデバイス１１０はＰＤＳＣＨにおいてコンテンション解決情報を送信してもよい。

【0069】

コンテンション解決情報には、端末デバイス１２０の第１アイデンティティが含まれるものと仮定する。端末デバイス１２０でネットワークデバイス１１０の検証が必要とされるいくつかの実施形態では、ネットワークデバイス１１０は、ネットワークデバイス１１０についての第２認証情報を運ぶ第４ＭＡＣ ＣＥを生成してもよい。例えば、第２認証情報はＳｈｏｒｔＭＡＣ－Ｉの形式であってもよい。この場合、ネットワークデバイス１１０は、コンテンション解決情報を有する第４ＭＡＣ ＣＥを端末デバイス１２０に送信してもよい。いくつかの実施形態において、ネットワークデバイス１１０はＰＤＳＣＨにおいて第４ＭＡＣ ＣＥとコンテンション解決情報を送信してもよい。

【0070】

ネットワークデバイス１１０が、送信すべきアップリンクデータがまだ残っていることを示すＢＳＲを受信するいくつかの実施形態において、ネットワークデバイス１１０は、コンテンション解決情報とともにアップリンクグラント情報を端末デバイス１２０に送信してもよい。いくつかの追加の実施形態において、ネットワークデバイス１１０は、コンテンション解決情報、第４ＭＡＣ ＣＥ、及びアップリンクグラント情報を端末デバイス１２０に送信してもよい。いくつかの実施形態において、ネットワークデバイス１１０は、ＰＤＳＣＨにおいてコンテンション解決情報及び第４ＭＡＣ ＣＥを送信し、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）においてアップリンクグラント情報を送信してもよい。

【0071】

ネットワークデバイス１１０がコアネットワーク要素１３１から端末デバイス１２０宛のダウンリンクデータを受信するいくつかの実施形態では、ネットワークデバイス１１０は、コンテンション解決情報、第４ＭＡＣ ＣＥ、アップリンクグラント情報、及びダウンリンクデータを端末デバイス１２０に送信してもよい。

【0072】

端末デバイス１２０の第１アイデンティティを含むコンテンション解決情報を受信すると、端末デバイス１２０は、成功したＲＡＲのＣ－ＲＮＴＩを使用して、後続のデータ送信を実行してもよい。この時点では、端末デバイス１２０は非アクティブ状態のままである。

【0073】

いくつかの実施形態において、端末デバイス１２０は、ネットワークデバイス１１０から受信した第２認証情報に基づいて、ネットワークデバイス１１０の有効性を検証してもよい（４０９）。ネットワークデバイス１１０が有効であると判定された場合、端末デバイス１２０は、受信したダウンリンクデータを受け入れてもよい。ネットワークデバイス１１０が無効であると判定された場合、端末デバイス１２０は、受信したダウンリンクデータを破棄してもよい。

【0074】

端末デバイス１２０は、残りのアップリンクデータの少なくとも一部とＢＳＲをネットワークデバイス１１０に送信してもよい（４１０）。いくつかの実施形態において、端末デバイス１２０はＰＤＳＣＨにおいて残りのアップリンクデータとＢＳＲを送信してもよい。いくつかの実施形態において、アップリンクグラント情報を受信したことに応じて、端末デバイス１２０は、期間終了までダウンリンクチャネルを監視してもよい。いくつかの代替的な実施形態では、残りのアップリンクデータの少なくとも一部を送信した（４１０）ことに応じて、端末デバイス１２０は、期間終了までダウンリンクチャネルを監視してもよい。

【0075】

残りのアップリンクデータの少なくとも一部を受信すると、ネットワークデバイス１１０は、それをコアネットワーク要素１３１に送信してもよい（４１１）。ネットワークデバイス１１０は、別のダウンリンクデータと別のアップリンクグラント情報があれば、それを受信し（４１２）、それらを端末デバイス１２０に送信してもよい（４１３）。端末デバイス１２０は、残りのアップリンクデータをネットワークデバイス１１０に送信してもよく（４１４）、ネットワークデバイス１１０はそれをコアネットワーク要素１３１に送信してもよい（４１５）。

【0076】

ネットワークデバイス１１０がデータ送信終了を示す接続リリースメッセージを送信するまで（４１６）、上述のように、端末デバイス１２０の非アクティブ状態においてＣ－ＲＮＴＩを利用してアップリンク及びダウンリンクのデータ送信を繰り返してもよい。ＲＲＣＲｅｌｅａｓｅメッセージ等の接続リリースメッセージを受信した場合、端末デバイス１２０は、端末デバイス１２０の非アクティブ状態を初期化してもよい。図４のステップ４０９～４１６の動作は、図３のステップ３１１～３１８の動作と類似していることがわかる。

【0077】

図２～図４で説明したプロセスにより、信号のオーバーヘッドを低減しつつ、端末デバイスの非アクティブ状態におけるスモールデータ送信を適切に実行することができる。これらのプロセスに対応して、本願の実施形態は、端末デバイスとネットワークデバイスでそれぞれ実施される通信方法も提供する。図５～図１４を参照しながら、これについてより詳細に説明する。

【0078】

図５は、本開示のいくつかの実施形態にかかる、端末デバイスで実施される例示的な通信方法５００を示す。方法５００は例えば、図１に示す端末デバイス１２０において実行されてもよい。議論を目的として、以下では図１を参照して方法５００を説明する。理解すべき点として、方法５００は、図示されていない付加的ブロックを含んでもよく、且つ／又は、図示されたいくつかのブロックを省略してもよく、この点において、本開示の範囲は限定されない。

【0079】

図５に示すように、ブロック５１０において、端末デバイス１２０は、端末デバイス１２０の第１アイデンティティを運ぶ第１ＭＡＣ ＣＥを生成する。いくつかの実施形態において、第１ＭＡＣ ＣＥはさらに、端末デバイス１２０についての第１認証情報を運んでもよく、第１アイデンティティと第１認証情報は第１ＭＡＣ ＣＥの異なるフィールドにある。図６は、本開示のいくつかの実施形態にかかる、端末デバイスについての第１認証情報及び第１アイデンティティを運ぶＭＡＣ ＣＥ ６１０の実装を示す模式図６００を示す。

【0080】

いくつかの実施形態において、ＭＡＣ ＣＥ ６１０は固定サイズを有し、Ｉ－ＲＮＴＩフィールドとＳＨＯＲＴＭＡＣ－Ｉフィールドを含む２つのフィールドから構成されてもよい。Ｉ－ＲＮＴＩフィールドは、端末デバイス１２０のＭＡＣ ｅｎｔｉｔｙのＩ－ＲＮＴＩを含む。いくつかの実施形態では、Ｉ－ＲＮＴＩフィールドの長さは、図６のバイト６１１～６１５に示すように、４０ビットであってもよい。ＳＨＯＲＴＭＡＣ－Ｉフィールドには、ネットワークデバイス１１０における端末デバイス１２０の認証を容易にするために認証トークンが含まれている。いくつかの実施形態においてＳＨＯＲＴＭＡＣ－Ｉフィールドの長さは、図６のバイト６１６～６１７に示すように、１６ビットであってもよい。

【0081】

いくつかの代替的な実施形態において、端末デバイス１２０はさらに、端末デバイス１２０についての第１認証情報を運ぶ第２ＭＡＣ ＣＥを生成してもよい。第２ＭＡＣ ＣＥは第１ＭＡＣ ＣＥと分離されている。図７は、本開示のいくつかの実施形態にかかる、第１アイデンティティを運ぶＭＡＣ ＣＥ ７１０と、第１認証情報を運ぶＭＡＣ ＣＥ ７２０の別の実装の模式図７００を示す。

【0082】

いくつかの実施形態において、ＭＡＣ ＣＥ ７１０は、固定サイズを有し、Ｉ－ＲＮＴＩフィールドとして定義される個別のフィールドを含んでもよい。このフィールドは、端末デバイス１２０のＭＡＣ ｅｎｔｉｔｙのＩ－ＲＮＴＩを含む。いくつかの実施形態において、Ｉ－ＲＮＴＩフィールドの長さは、図７のバイト７１１～７１５に示すように、４０ビットであってもよい。

【0083】

いくつかの実施形態において、ＭＡＣ ＣＥ ７２０は、固定サイズを有し、ＳＨＯＲＴＭＡＣ－Ｉフィールドとして定義される個別のフィールドを含んでもよい。このフィールドには、ネットワークデバイス１１０における端末デバイス１２０の認証を容易にするために認証トークンが含まれている。いくつかの実施形態においてＳＨＯＲＴＭＡＣ－Ｉフィールドの長さは、図７のバイト７２１～７２２に示すように、１６ビットであってもよい。

【0084】

図５に戻ると、ブロック５２０において、端末デバイス１２０は、第１ＭＡＣ ＣＥとアップリンクデータをネットワークデバイス１１０に送信する。いくつかの実施形態において、アップリンクデータはスモールで低頻度のデータトラフィックに関連付けられていてもよい。いくつかの実施形態において、端末デバイス１２０は、第１ＭＡＣ ＣＥ、第２ＭＡＣ ＣＥ、及びアップリンクデータをネットワークデバイス１１０に送信してもよい。いくつかの代替的な実施形態において、端末デバイス１２０は、第１ＭＡＣ ＣＥ、アップリンクデータ、及びＢＳＲをネットワークデバイス１１０に送信してもよい。ＢＳＲは、送信すべき残りのアップリンクデータの量を示してもよい。いくつかの代替的な実施形態において、端末デバイス１２０は、第１ＭＡＣ ＣＥ、第２ＭＡＣ ＣＥ、アップリンクデータ、及びＢＳＲをネットワークデバイス１１０に送信してもよい。

【0085】

２ステップＲＡＣＨ手順に基づくいくつかの実施形態において、端末デバイス１２０は、ランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ、及びアップリンクデータをネットワークデバイス１１０に送信してもよい。いくつかの代替的な実施形態において、端末デバイス１２０は、ランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ、第２ＭＡＣ ＣＥ、及びアップリンクデータをネットワークデバイス１１０に送信してもよい。いくつかの代替的な実施形態において、端末デバイス１２０は、ランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ、アップリンクデータ、及びＢＳＲをネットワークデバイス１１０に送信してもよい。いくつかの代替的な実施形態において、端末デバイス１２０は、ランダムプリアンブルシーケンス、第１ＭＡＣ ＣＥ、第２ＭＡＣ ＣＥ、アップリンクデータ、及びＢＳＲをネットワークデバイス１１０に送信してもよい。

【0086】

４ステップＲＡＣＨ手順に基づくいくつかの実施形態において、端末デバイス１２０はネットワークデバイス１１０にランダムプリアンブルシーケンスを送信し、ネットワークデバイス１１０からランダムプリアンブルシーケンスに対するＲＡＲを受信してもよい。ＲＡＲを受信したことに従って、端末デバイス１２０は第１アイデンティティが第１ＭＡＣ ＣＥで運ばれるようにしてもよい。

【0087】

いくつかの実施形態において、ネットワークデバイス１１０は、端末デバイス１２０に対してコンテンション解決タイマ又はＲＡＲウィンドウを設定しなくてもよい。これは、端末デバイス１２０が、アップリンクデータをネットワークデバイス１１０に送信するだけで、いかなるコンテンション解決も待たないことを意味する。

【0088】

いくつかの代替的な実施形態において、ネットワークデバイス１１０は、図３の送信３０５及び図４の送信４０３と結び付けて上述したように、端末デバイス１２０に対して拡張コンテンション解決タイマ又はＲＡＲウィンドウを設定してもよい。この場合、端末デバイス１２０はネットワークデバイス１１０からコンテンション解決情報を受信してもよい。

【0089】

４ステップＲＡＣＨ手順に基づくいくつかの実施形態では、図８に示すようにコンテンション解決情報を運ぶために第３ＭＡＣ ＣＥを定義してもよい。図８は、本開示のいくつかの実施形態にかかる、４ステップＲＡＣＨ手順のための、コンテンション解決情報を運ぶＭＡＣ ＣＥ ８１０の実装の模式図８００を示す。いくつかの実施形態において、ＭＡＣ ＣＥ ８１０は、固定サイズを有し、コンテンション解決アイデンティティ（CONTENTION RESOLUTION IDENTITY）フィールドとして定義される個別のフィールドを含んでもよい。いくつかの実施形態においてコンテンション解決アイデンティティフィールドの長さは、図８のバイト８１１～８１６に示すように、４８ビットであってもよい。

【0090】

図６に示すように、第１ＭＡＣ ＣＥ ６１０が第１アイデンティティと第１認証情報を運ぶいくつかの実施形態において、コンテンション解決アイデンティティフィールドはＵＬ ＣＣＣＨ ＳＤＵ又は第１ＭＡＣ ＣＥの最初の４８ビットを含んでもよく、ＵＬ ＣＣＣＨ ＳＤＵが４８ビットより長い場合、当該フィールドはＵＬ ＣＣＣＨ ＳＤＵの最初の４８ビットを含んでもよい。

【0091】

図７に示すように、第１ＭＡＣ ＣＥ ７１０が第１アイデンティティを搬送し第２ＭＡＣ ＣＥ ７２０が第１認証情報を運ぶいくつかの代替的な実施形態において、コンテンション解決アイデンティティフィールドはＵＬ ＣＣＣＨ ＳＤＵ又は第１ＭＡＣ ＣＥ ７１０を含んでもよく、ＵＬ ＣＣＣＨ ＳＤＵが４８ビットより長い場合、当該フィールドはＵＬ ＣＣＣＨ ＳＤＵの最初の４８ビットを含んでもよい。第１ＭＡＣ ＣＥ ７１０の場合、当該フィールドの最上位ビット（ＭＳＢ）は、パディングビット０（ｐａｄｄｉｎｇ ｂｉｔ ０）として設定されるべきである。

【0092】

２ステップＲＡＣＨ手順に基づくいくつかの実施形態において、コンテンション解決情報は、図９に示すように、成功したＲＡＲに含まれてもよい。図９は、本開示のいくつかの実施形態にかかる、２ステップＲＡＣＨ手順のための、コンテンション解決情報を運ぶ成功したＲＡＲ ９１０の実装を説明する模式図９００を示す。いくつかの実施形態において、コンテンション解決アイデンティティフィールドは、成功したＲＡＲ ９１０に含まれてもよい。いくつかの実施形態において、コンテンション解決アイデンティティフィールドの長さは、図９のバイト９１１～９１６に示すように、４８ビットであってもよい。その他のフィールド９１７～９２１は、従来の成功したＲＡＲのものと類似するため、ここではその詳細を省略する。

【0093】

図６に示すように、第１ＭＡＣ ＣＥ ６１０が第１アイデンティティ及び第１認証情報の両方を運ぶいくつかの実施形態において、コンテンション解決アイデンティティフィールドは、ＵＬ ＣＣＣＨ ＳＤＵ又は第１ＭＡＣ ＣＥの最初の４８ビットを含んでよく、ＵＬ ＣＣＣＨ ＳＤＵが４８ビットより長い場合、当該フィールドはＵＬ ＣＣＣＨ ＳＤＵの最初の４８ビットを含んでもよい。

【0094】

図７に示すように、第１ＭＡＣ ＣＥ ７１０が第１アイデンティティを運び第２ＭＡＣ ＣＥ ７２０が第１認証情報を運ぶいくつかの代替的な実施形態において、コンテンション解決アイデンティティフィールドはＵＬ ＣＣＣＨ ＳＤＵ又は第１ＭＡＣ ＣＥ ７１０を含んでもよく、ＵＬ ＣＣＣＨ ＳＤＵが４８ビットより長い場合、当該フィールドはＵＬ ＣＣＣＨ ＳＤＵの最初の４８ビットを含んでもよい。第１ＭＡＣ ＣＥ ７１０の場合、当該フィールドのＭＳＢは、パディングビット０（padding bit 0）として設定されるべきである。

【0095】

以下では、コンテンション解決情報を受信した後の動作について、図１０を参照しながらさらに説明する。図１０は、本開示のいくつかの実施形態にかかる、端末デバイスで実施される別の例示的な通信方法１０００を示す。方法１０００は例えば、図１に示す端末デバイス１２０において実行されてもよい。議論を目的として、以下では図１を参照して方法１０００を説明する。理解すべき点として、方法１０００は、図示されていない付加的ブロックを含んでもよく、且つ／又は、図示されたいくつかのブロックを省略してもよく、この点において、本開示の範囲は限定されない。

【0096】

ブロック１０１０において、端末デバイス１２０は、コンテンション解決情報が第１アイデンティティを含むか否かを判定してもよい。コンテンション解決情報が第１アイデンティティを含む場合、ブロック１０２０において、端末デバイス１２０は、ネットワークデバイス１１０についての第２認証情報を受信したか否かを判定してもよい。いくつかの実施形態において、第２認証情報は第４ＭＡＣ ＣＥにおいて運ばれてもよい。図７のＭＡＣ ＣＥ７２０が示すように、第４ＭＡＣ ＣＥは新たに定義されてもよい。いくつかの実施形態では、第２ＭＡＣ ＣＥにおいて第２認証情報が運ばれてもよい。こうすると、端末デバイス１２０からネットワークデバイス１１０へ第１認証情報を運ぶ第２ＭＡＣ ＣＥが、ネットワークデバイス１１０から端末デバイス１２０へ第２認証情報を運ぶために再利用される。したがって、対応するオーバーヘッドがさらに削減される。

【0097】

第４ＭＡＣ ＣＥを受信したと判定した場合、端末デバイス１２０は、ブロック１０３０において、ネットワークデバイス１１０についての参照認証情報（例えば、Ｓｈｏｒｔ ＭＡＣ－Ｉ）を決定してもよい。いくつかの実施形態において、端末デバイス１２０は、ｓｈｏｒｔ ＭＡＣ－ＩをＭＡＣ－Ｉの１６個の最下位ビットに設定することによって、ｓｈｏｒｔ ＭＡＣ－Ｉの値を算出してもよい。ＭＡＣ－Ｉは、ｉ）ＡＳＮ．１符号化ＶａｒＳＤＴＭＣ－Ｉｎｐｕｔで、ｉｉ）ＵＥ非アクティブＡＳコンテキスト内のＫ_{ＲＲＣｉｎｔ}キーと、以前に設定された整合性保護アルゴリズム（integrity protection algorithm）を用いて、ｉｉｉ）ＣＯＵＮＴ、ＢＥＡＲＥＲ及びＤＩＲＥＣＴＩＯＮ用のすべての入力ビットをバイナリの１に設定することで、算出される。

【0098】

ブロック１０４０において、端末デバイス１２０は、第２認証情報と参照認証情報に基づいて、ネットワークデバイス１１０を認証してもよい。いくつかの実施形態において、端末デバイス１２０は、自身が算出した参照認証情報を、ネットワークデバイス１１０から受信した第２認証情報と照合してもよい。参照認証情報が第２認証情報と一致する場合、端末デバイス１２０は、ネットワークデバイス１１０が有効であると判定してもよい。参照認証情報が第２認証情報と一致しない場合、端末デバイス１２０はネットワークデバイス１１０が無効であると判定し、受信したダウンリンクデータを破棄してもよい。

【0099】

ブロック１０１０において、コンテンション解決情報が第１アイデンティティを含まないと判定した場合、端末デバイス１２０は、ブロック１０５０において、第１ＭＡＣ ＣＥとアップリンクデータの再送を実行してもよい。ブロック１０６０において、端末デバイス１２０は、再送が失敗したか否かを判定してもよい。再送が失敗したと判定した場合、ブロック１０７０において、端末デバイス１２０は、再送回数が所定値より多いか否かを判定してもよい。いくつかの実施形態において、当該所定値は、システムメッセージによってブロードキャストされてもよい。いくつかの代替的な実施形態では、専用のＲＲＣメッセージを使用することによって、当該所定値を端末デバイス１２０に設定してもよい。

【0100】

再送回数が当該所定値未満である場合、端末デバイス１２０はブロック１０５０において再び、再送を実行してもよい。再送回数が当該所定値以上である場合、端末デバイス１２０は、コンテンション失敗と判定してもよい。コンテンション失敗の場合、ブロック１０８０において、端末デバイス１２０は、ランダムアクセス手順を実行することによってネットワークデバイス１１０との接続を確立し、端末デバイス１２０を接続状態にすることができる。

【0101】

ブロック１０９０において、端末デバイス１２０は接続状態でアップリンクデータをネットワークデバイス１１０に送信してもよい。いくつかの追加の実施形態において、端末デバイス１２０はさらに、ネットワークデバイス１１０に対して、アップリンクデータの送信に関連付けられている、コンテンション失敗に関する情報を送信してもよい。いくつかの実施形態において、コンテンション失敗に関する情報は、アップリンクデータのサイズや、使用されたランダムアクセス手順等を含んでもよい。コンテンション失敗に関する情報はこれに限らないことに留意されたい。

【0102】

このように、コンテンション解決が成功しなかった場合、端末デバイス１２０は、スモールデータの再送を実行してもよい。所定回数の再試行後に再送が失敗した場合、端末デバイス１２０は、従来のデータ送信、すなわち、端末デバイス１２０が接続状態に入った後でのみデータを送信する状態にフォールバックしてもよい。

【0103】

以下では、成功したコンテンション解決を受信した後の動作について、図１１を参照しながらさらに説明する。図１１は、本開示のいくつかの実施形態にかかる、端末デバイスで実施される別の例示的な通信方法１１００を示す。方法１１００は例えば、図１に示す端末デバイス１２０において実行されてもよい。議論を目的として、以下では図１を参照して方法１１００を説明する。理解すべき点として、方法１１００は、図示されていない付加的ブロックを含んでもよく、且つ／又は、図示されたいくつかのブロックを省略してもよく、この点において、本開示の範囲は限定されない。

【0104】

ブロック１１１０において、端末デバイス１２０は、アップリンクグラント情報を受信したか否かを判定してもよい。端末デバイス１２０がアップリンクグラント情報を受信したと判定した場合、ブロック１１２０において、端末デバイス１２０は、後続のデータ送信用に端末デバイス１２０の第２アイデンティティを決定してもよい。いくつかの実施形態において、第２アイデンティティはＣ－ＲＮＴＩであってもよい。４ステップＲＡＣＨ手順に基づくいくつかの実施形態では、ＲＡＲ内のＴＣ－ＲＮＴＩをＣ－ＲＮＴＩとして使用することによって第２アイデンティティを決定してもよい。２ステップＲＡＣＨ手順に基づくいくつかの実施形態では、成功したＲＡＲ内に含まれるＣ－ＲＮＴＩを使用することによって第２アイデンティティを決定してもよい。

【0105】

ブロック１１３０において、端末デバイス１２０は、アップリンクグラント情報と第２アイデンティティに基づいて、後続のアップリンクデータをネットワークデバイス１１０に送信してもよい。スモールデータ送信で送信される後続のＵＬデータ又はＤＬデータがある場合、端末デバイス１２０は、ＤＣＩでＵＬグラント又はＤＬ割当を受信することを期待することになる。ブロック１１４０において、端末デバイス１２０は、期間終了まで、端末デバイス１２０に関連付けられているダウンリンクチャネルを監視してもよい。例えば、ダウンリンクチャンネルは、Ｃ－ＲＮＴＩにアドレス指定されたＰＤＣＣＨであってもよい。

【0106】

いくつかの実施形態において、当該期間は一定の値であってもよい。いくつかの代替的な実施形態において、当該期間は、システムメッセージにおいてブロードキャストされてもよい。いくつかの代替的な実施形態では、端末デバイス１２０が接続状態にあるときに、専用のＲＲＣメッセージを介して当該期間を設定してもよい。例えば、専用のＲＲＣメッセージは、ＵＥコンテキストに格納されているＲＲＣＲｅｌｅａｓｅ又はＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージであってもよい。

【0107】

いくつかの実施形態において、端末デバイス１２０はアップリンクグラント情報の受信に応じて、例えば、Ｃ－ＲＮＴＩが利用可能になった後にスモールデータ送信のためのアップリンクグラント情報を受信するたびに、ダウンリンクチャネルの監視を開始してもよい。いくつかの代替的な実施形態において、端末デバイス１２０は後続のアップリンクデータの送信に応じて、例えば、Ｃ－ＲＮＴＩが利用可能になった後にスモールアップリンクデータを送信するたびに、ダウンリンクチャネルの監視を開始してもよい。

【0108】

期間が終了するいくつかの実施形態では、端末デバイス１２０は、ＰＤＣＣＨの監視を停止し、Ｃ－ＲＮＴＩをリリースしてもよい。この場合、送信する後続のスモールアップリンクデータがあれば、端末デバイス１２０は再びＲＡＣＨ手順を開始しなければならない。いくつかの実施形態において、ＰＤＣＣＨの監視は、ＲＲＣシグナリングを利用したスモールデータ送信にも適用可能である。

【0109】

いくつかの代替的な実施形態において、端末デバイス１２０は、後続のデータ送信を実行するために、予め設定されたグラント情報を使用してもよい。いくつかの実施形態において、端末デバイス１２０は、ネットワークデバイス１１０からの接続リリースメッセージにおいて、接続状態で設定された端末デバイス１２０の第３アイデンティティと、設定されたグラント情報との指示を受信し、設定されたグラント情報と第３アイデンティティとに基づいて、ネットワークデバイス１１０に後続のアップリンクデータを送信してもよい。例えば、当該指示に基づいて、端末デバイス１２０は、対応する設定されたグラント情報及び第３アイデンティティをＵＥコンテキストから取得し、取得した設定されたグラント情報及び第３アイデンティティを使用して、スモールデータ送信を実行してもよい。第３アイデンティティは、設定されたスケジューリングＲＮＴＩ（ＣＳ－ＲＮＴＩ）であってもよい。

【0110】

いくつかの代替的な実施形態において、端末デバイス１２０は、ネットワークデバイス１１０からの接続リリースメッセージにおいて、新たに設定されたグラント情報及び第３アイデンティティを受信し、受信した設定されたグラント情報及び第３アイデンティティを使用して、スモールデータ送信を実行してもよい。

【0111】

図１２は、本開示のいくつかの実施形態にかかる、ネットワークデバイスで実施される例示的な通信方法１２００を示す。方法１２００は例えば、図１に示すネットワークデバイス１１０において実行されてもよい。議論を目的として、以下では図１を参照して方法１２００を説明する。理解すべき点として、方法１２００は、図示されていない付加的ブロックを含んでもよく、且つ／又は、図示されたいくつかのブロックを省略してもよく、この点において、本開示の範囲は限定されない。

【0112】

図１２に示すように、ブロック１２１０において、ネットワークデバイス１１０は、端末デバイス１２０から第１ＭＡＣ ＣＥとアップリンクデータを受信する。第１ＭＡＣ ＣＥは、非アクティブ状態での端末デバイス１２０の第１アイデンティティを運ぶ。２ステップＲＡＣＨ手順に基づくいくつかの実施形態において、ネットワークデバイス１１０は、端末デバイス１２０から第１ＭＡＣ ＣＥ、アップリンクデータ、及びランダムプリアンブルシーケンスを受信してもよい。４ステップＲＡＣＨ手順に基づくいくつかの実施形態においても、ネットワークデバイス１１０は、端末デバイス１２０からランダムプリアンブルシーケンスを受信し、当該ランダムプリアンブルシーケンスに対するＲＡＲを端末デバイス１２０に送信してもよい。

【0113】

ブロック１２２０において、ネットワークデバイス１１０は、コアネットワーク要素１３１にアップリンクデータを送信する。このように、端末デバイス１２０の非アクティブ状態において、スモールデータ送信を適切に実行することができる。

【0114】

いくつかの実施形態において、第１ＭＡＣ ＣＥはさらに、端末デバイス１２０についての第１認証情報を運んでもよく、図６と結び付けて説明したように、第１アイデンティティと第１認証情報は、第１ＭＡＣ ＣＥの異なるフィールドにある。いくつかの実施形態において、ネットワークデバイス１１０は端末デバイス１２０から、第１ＭＡＣ ＣＥ、アップリンクデータ、及び端末デバイス１２０についての第１認証情報を運ぶ第２ＭＡＣ ＣＥを受信してもよい。第１ＭＡＣ ＣＥと第２ＭＡＣ ＣＥは、それぞれ図７のＭＡＣ ＣＥ ７１０とＭＡＣ ＣＥ ７２０に示すように定義されてもよい。

【0115】

図１３を参照して、第１認証情報を受信した後の動作について説明する。図１３は、本開示のいくつかの実施形態にかかる、ネットワークデバイスで実施される別の例示的な通信方法１３００を示す。方法１３００は例えば、図１に示すネットワークデバイス１１０において実行されてもよい。議論を目的として、以下では図１を参照して方法１３００を説明する。理解すべき点として、方法１３００は、図示されていない付加的ブロックを含んでもよく、且つ／又は、図示されたいくつかのブロックを省略してもよく、この点において、本開示の範囲は限定されない。

【0116】

ブロック１３１０において、ネットワークデバイス１１０は、端末デバイス１２０についての参照認証情報を決定してもよい。いくつかの実施形態において、ネットワークデバイス１１０は、以下に示すＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔに基づいて参照認証情報を決定してもよい。
VarResumeMAC-Input ::= SEQENCE {
sourcePhysCellId PhysCellId,
targetCellIdentity CellIdentity,
source-c-RNTI RNTI-Value

}

【0117】

ブロック１３２０において、ネットワークデバイス１１０は、第１認証情報と参照認証情報に基づいて、端末デバイス１２０を検証してもよい。いくつかの実施形態において、ネットワークデバイス１１０は、自身が算出した参照認証情報を、端末デバイス１２０から受信した第１認証情報と照合してもよい。参照認証情報が第１認証情報と一致する場合、ネットワークデバイス１１０は、端末デバイス１２０が有効であると判定してもよい。いくつかの実施形態において、端末デバイス１２０が有効であると判定された後、ネットワークデバイス１１０は、アップリンクデータをコアネットワーク要素１３１に送信してもよい。

【0118】

参照認証情報が第１認証情報と一致しない場合、ネットワークデバイス１１０は、端末デバイス１２０が無効であると判定してもよい。いくつかの実施形態において、端末デバイス１２０が無効であると判定された場合、ネットワークデバイス１１０は受信したアップリンクデータを破棄してもよい。

【0119】

ネットワークデバイス１１０は、端末デバイス１２０が非アクティブ状態になる直前に端末デバイス１２０にサービスを提供したネットワークデバイス（以下、最後にサービスを提供したネットワークデバイスとも称する）であると仮定する。ブロック１３３０において、ネットワークデバイス１１０は、端末デバイス１２０についての第１認証情報に基づいて、ネットワークデバイス１１０についての第２認証情報を決定してもよい。いくつかの実施形態において、第１認証情報に関連付けられているＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔについて、ネットワークデバイス１１０は、ターゲットセルに対する物理セル識別子（ＰＣＩ）を使用するとともに、ソースセルに対するセル識別子（ＣＩＤ）を使用して、第２認証情報を決定してもよい。例えば、ＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔは以下のように修正されてもよい。
ＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔ ：：＝ ＳＥＱＵＥＮＣＥ ｛
ｓｏｕｒｃｅＣｅｌｌＩｄｅｎｔｉｔｙ ＣｅｌｌＩｄｅｎｔｉｔｙ，
ｔａｒｇｅｔＰｈｙＣｅｌｌＩｄ ＰｈｙｓＣｅｌｌＩｄ，
ｓｏｕｒｃｅ－ｃ－ＲＮＴＩ ＲＮＴＩ－Ｖａｌｕｅ
｝

【0120】

いくつかの代替的な実施形態において、ネットワークデバイス１１０は、第１認証情報に関連付けられているＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔ内のパラメータの順序を変更することによって、第２認証情報を決定してもよい。例えば、ＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔは以下のように修正されてもよい。
ＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔ ：：＝ ＳＥＱＵＥＮＣＥ ｛
ｔａｒｇｅｔＣｅｌｌＩｄｅｎｔｉｔｙ ＣｅｌｌＩｄｅｎｔｉｔｙ，
ｓｏｕｒｃｅＰｈｙｓＣｅｌｌＩｄ ＰｈｙｓＣｅｌｌＩｄ，
ｓｏｕｒｃｅ－ｃ－ＲＮＴＩ ＲＮＴＩ－Ｖａｌｕｅ
｝

【0121】

いくつかの代替的な実施形態において、ネットワークデバイス１１０は、第１認証情報に関連付けられているＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔのパラメータの１つを削除することによって、第２認証情報を決定してもよい。例えば、ＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔは以下のように修正されてもよい。
ＶａｒＳＤＴＭＡＣ－Ｉｎｐｕｔ ：：＝ ＳＥＱＵＥＮＣＥ ｛
ｓｏｕｒｃｅＰｈｙｓＣｅｌｌＩｄ ＰｈｙｓＣｅｌｌＩｄ，
ｓｏｕｒｃｅ－ｃ－ＲＮＴＩ ＲＮＴＩ－Ｖａｌｕｅ
｝

【0122】

ブロック１３４０において、ネットワークデバイス１１０は、端末デバイス１２０に第２認証情報を送信してもよい。いくつかの実施形態において、ネットワークデバイス１１０は、第２認証情報を運ぶ第４ＭＡＣ ＣＥを生成し、コンテンション解決情報と第４ＭＡＣ ＣＥを端末デバイス１２０に送信してもよい。いくつかの実施形態において、図７のＭＡＣ ＣＥ７２０が示すように、第４ＭＡＣ ＣＥを新たに定義してもよい。いくつかの代替的な実施形態において、ネットワークデバイス１１０は、端末デバイス１２０に第２認証情報を送信するために第２ＭＡＣ ＣＥを再利用してもよい。

【0123】

ネットワークデバイス１１０が端末デバイス１２０に最後にサービスを提供したネットワークデバイスではない、いくつかの実施形態において、第２認証情報は、最後にサービスを提供したネットワークデバイスによって決定されてもよく、最後にサービスを提供したネットワークデバイスからネットワークデバイス１１０に送信されてもよい。例えば、Ｘｎメッセージ（ＵＥコンテキスト取得応答（RETRIEVE UE CONTEXT RESPONSE）メッセージ又はＵＥコンテキスト取得失敗（RETRIEVE UE CONTEXT FAILURE）メッセージ等）において、第２認証情報を送信してもよい。

【0124】

いくつかの実施形態において、ネットワークデバイス１１０は、端末デバイス１２０から第１ＭＡＣ ＣＥ、アップリンクデータ、及びＢＳＲを受信してもよい。ＢＳＲは、送信すべき残りのアップリンクデータの量を示す。残りのアップリンクデータがある場合、ネットワークデバイス１１０は、アップリンクグラント情報を端末デバイス１２０に送信してもよい。

【0125】

いくつかの実施形態において、ネットワークデバイス１１０は、端末デバイス１２０にコンテンション解決情報を送信してもよい。４ステップＲＡＣＨ手順に基づくいくつかの実施形態では、第３ＭＡＣ ＣＥにおいてコンテンション解決情報を運んでもよい。２ステップＲＡＣＨ手順に基づくいくつかの実施形態では、コンテンション解決情報をランダムアクセス応答メッセージに配置してもよい。いくつかの代替的な実施形態において、ネットワークデバイス１１０は、コンテンション解決情報とアップリンクグラント情報を端末デバイス１２０に送信してもよい。いくつかの追加の実施形態において、ネットワークデバイス１１０は、アップリンクグラント情報と、後続のデータ送信のための端末デバイス１２０の第２アイデンティティとに基づいて、後続のアップリンクデータを受信してもよい。第２アイデンティティはＣ－ＲＮＴＩであってもよい。

【0126】

いくつかの代替的な実施形態において、ネットワークデバイス１１０は、接続リリースメッセージにおいて、接続状態で設定された端末デバイス１２０の第３アイデンティティと、設定されたグラント情報との指示を端末デバイス１２０に送信し、設定されたグラント情報と第３アイデンティティとに基づいて、端末デバイス１２０から後続のアップリンクデータを受信してもよい。第３アイデンティティは、ＣＳ－ＲＮＴＩであってもよい。

【0127】

いくつかの実施形態において、ネットワークデバイス１１０は、端末デバイス１２０の非アクティブ状態の初期化のための接続リリースメッセージにおいて、データ送信終了の指示を端末デバイス１２０に送信してもよい。例えば、ネットワーク装置１１０がスモールデータ送信を終了したい場合、ネットワーク装置１１０は、ＲＲＣリリースメッセージを利用して、端末装置１２０を正常な非アクティブ状態にするように、すなわち、非アクティブ状態でパラメータを初期化するように指示を送信することができる。例えば、端末デバイス１２０にパケットデータ収束プロトコル（ＰＤＣＰ：Packet Data Convergence Protocol）エンティティを中断させ、ＰＤＣＣＨ監視を停止させる。

【0128】

いくつかの実施形態において、ネットワークデバイス１１０は、コアネットワーク要素１３１からダウンリンクデータを受信し、コンテンション解決情報とダウンリンクデータを端末デバイス１２０に送信してもよい。コンテンション失敗が発生したいくつかの実施形態において、ネットワークデバイス１１０は、コンテンション失敗に関する情報を端末デバイス１２０から受信してもよい。

【0129】

明確なＲＲＣシグナリングが存在しないいくつかの実施形態において、ＰＤＣＰシーケンス番号（ＳＮ）及びハイパーフレーム番号（ＨＦＮ）の値（ＣＯＵＮＴ値とも称する）は、非アクティブ状態でのスモールデータ送信ごとに計上されるように維持されてもよい。これにより、同じセキュリティキーで同じＣＯＵＮＴ値が複数回使用されることを防ぎ、スモールデータ送信中のセキュリティを確保する。ネットワーク装置１１０が次のスモールデータ送信のためのセキュリティキーの更新を望むいくつかの実施形態では、ネットワーク装置１１０は、Ｎｅｘｔ Ｈｏｐ Ｃｈａｉｎｉｎｇ Ｃｏｕｎｔｅｒ（ＮＣＣ）を有するＲＲＣＲｅｌｅａｓｅメッセージを送信してもよい。

【0130】

図１４は、本開示の実施形態を実施するのに適したデバイス１４００の概略ブロック図である。デバイス１４００は、図１に示すネットワークデバイス１１０又は端末デバイス１２０の別の例示の実現であると考えることができる。したがって、デバイス１４００は、ネットワークデバイス１１０若しくは端末デバイス１２０で実現することができ、又はネットワークデバイス１１０若しくは端末デバイス１２０の少なくとも一部として実現することができる。

【0131】

図に示すように、デバイス１４００は、プロセッサ１４１０、プロセッサ１４１０に結合されるメモリ１４２０、プロセッサ１４１０に結合される適切な送信機（ＴＸ）及び受信機（ＲＸ）１４４０、並びにＴＸ／ＲＸ１４４０に結合される通信インタフェースを含む。メモリ１４２０は、プログラム１４３０の少なくとも一部を格納する。ＴＸ／ＲＸ１４４０は双方向通信に用いられる。ＴＸ／ＲＸ１４４０は、通信のための少なくとも１つのアンテナを有し、実際には本願で述べたアクセスノードは、複数のアンテナを有してもよい。通信インタフェースは、他のネットワーク要素と通信を行う際に必要な任意のインタフェース、例えば、ｅＮＢ／ｇＮＢ間の双方向通信用のＸ２／Ｘｎインタフェース、モビリティ管理エンティティ（ＭＭＥ：Mobility Management Entity）／アクセス・モビリティ管理機能（ＡＭＦ：Access and Mobility Management Function）／ＳＧＷ／ＵＰＦとｅＮＢ／ｇＮＢとの間の通信用のＳ１／ＮＧインタフェース、ｅＮＢ／ｇＮＢと中継ノード（ＲＮ）との間の通信用のＵｎインタフェース、又はｅＮＢ／ｇＮＢと端末デバイスとの間の通信用のＵｕインタフェースを表してもよい。

【0132】

プログラム１４３０がプログラム命令を含むと仮定すると、当該プログラム命令が、関連するプロセッサ１４１０により実行された場合、これにより、デバイス１４００は、本明細書で図１～図１３を参照して論じたように、本開示の実施形態に基づき操作を行うことができるようになる。本明細書の実施形態は、デバイス１４００のプロセッサ１４１０が実行可能なコンピュータソフトウェアにより実施するか、ハードウェアにより実施するか、又はソフトウェア及びハードウェアの組合せにより実施してもよい。プロセッサ１４１０は、本発明の各実施形態を実施するように設定することができる。また、プロセッサ１４１０及びメモリ１４２０の組合せは、本開示の各実施形態を実施するのに適した処理手段１４５０を構成してもよい。

【0133】

メモリ１４２０は、ローカルの技術ネットワークに適した任意のタイプであってよく、任意の適切なデータ記憶技術により実現してもよい。例として、コンピュータが読み取り可能な非一時的記憶媒体、半導体による記憶デバイス、磁気記憶デバイス及びシステム、光学記憶デバイス及びシステム、固定メモリ及び取り外し可能メモリ等が挙げられるが、これらに限定されない。デバイス１４００には１つのメモリ１４２０しか示されていないが、デバイス１４００には複数の物理上異なるメモリモジュールを設置してもよい。例として、プロセッサ１４１０は、ローカルの技術ネットワークに適した任意のタイプであってよく、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号処理器（ＤＳＰ）、及びマルチコアプロセッサ構成に基づくプロセッサのうち、１つ又は複数を含んでもよいが、これらに限定されない。デバイス１４００は複数のプロセッサ、例えば、マスタープロセッサを同期させるクロックに時間的に従属する特定用途向け集積回路チップを有してもよい。

【0134】

通常、本開示の各実施形態は、ハードウェア若しくは専用回路、ソフトウェア、論理、又はそれらの任意の組合せにおいて実施してもよい。いくつかの態様はハードウェアによって実現し、他の態様はコントローラ、マイクロプロセッサ又は他のコンピュータデバイスが実行するファームウェア又はソフトウェアによって実現してもよい。本開示の実施形態の各態様は、ブロック図、フローチャートとして図示されて説明され、又は他のいくつかの図形によって示されているが、理解すべき点として、本明細書に記載のブロック、装置、システム、技術又は方法は、例えば、ハードウェア、ソフトウェア、ファームウェア、専用回路若しくは論理、汎用ハードウェア若しくはコントローラ若しくは他のコンピュータデバイス、又はそれらの組合せにおいて実現してもよいが、これらに限定されない。

【0135】

本開示はさらに、コンピュータが読み取り可能な非一時的記憶媒体に、有形記憶される少なくとも１つのコンピュータプログラム製品を提供する。コンピュータプログラム製品は、図２～図１３を参考に上述したプロセス又は方法を実行するために、対象の実プロセッサ又は仮想プロセッサ上のデバイスにおいて実行されプログラムモジュールに含まれる、コンピュータが実行可能な命令等を含む。一般的に、プログラムモジュールは、特定のタスクを実行するか、又は特定の抽象データタイプを実現するルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造等を含む。プログラムモジュールの機能は、各実施形態での必要に応じて、プログラムモジュール間で組み合わせるか、又は分割してもよい。プログラムモジュールのマシン可読命令は、ローカルデバイス又は分散型デバイスにおいて実行してもよい。分散型デバイスにおいて、プログラムモジュールはローカルの記憶媒体及びリモートの記憶媒体の両方に置いてもよい。

【0136】

本開示の方法を実行するためのプログラムコードは、１種類又は複数種類のプログラミング言語の任意の組合せにより記述してもよい。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ又はその他のプログラム可能なデータ処理装置のプロセッサ又はコントローラに提供してもよく、プログラムコードがプロセッサ又はコントローラによって実行されると、フローチャート及び／又はブロック図に指定された機能／操作を実現することができる。プログラムコードは全てマシン上で実行するか、部分的にマシン上で実行するか、独立したソフトウェアパッケージとして実行するか、マシン上で部分的に実行するとともにリモートのマシン上で部分的に実行するか、又は全てリモートのマシン若しくはサーバ上で実行してもよい。

【0137】

上述のプログラムコードは、マシン可読媒体上に含まれていてよく、当該マシン可読媒体は、命令実行システム、装置若しくはデバイスにより使用されるプログラム、又は、命令実行システム、装置若しくはデバイスと結合して使用されるプログラムを含むか又は格納する任意の有形媒体であり得る。マシン可読媒体は、マシン可読信号媒体又はマシン可読記憶媒体であり得る。マシン可読媒体は、電子、磁気、光学、電磁気、赤外線若しくは半導体のシステム、装置若しくはデバイス、又は前述の任意の適切な組合せを含んでもよいが、これらに限定されない。マシン可読記憶媒体のより具体的な例には、１つ若しくは複数のケーブルの電気的接続、携帯用コンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去・書き込み可能なリードオンリーメモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、携帯型コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、光学的記憶装置、磁気記憶装置、又は前述の任意の適切な組合せが含まれる。

【0138】

なお、操作について、特定の順序で説明を行ったが、所望の結果を得るために、こうした操作を示された特定の順序で実行するか若しくは順に実行するか、又は、図示された全ての操作を実行することが求められる、と理解されるべきではない。いくつかの状況では、複数のタスク及び並行処理が有利である可能性がある。同様に、上述の議論では、いくつかの特定の実施の詳細が含まれるが、これらの詳細は本開示の範囲に対する限定であると解釈されるべきではなく、特定の実施形態が持つ特徴についての説明であると解釈されるべきである。個々の実施形態の文脈において説明したいくつかの特徴は、ある１つの実施形態において組み合わせて実現されてもよい。逆に、１つの実施形態の文脈において説明された各種特徴は、複数の実施形態において単独で、又は任意の適切なサブ的な組合せにより、実現されてもよい。

【0139】

本開示について、構造的特徴及び／又は方法・動作の専門の言葉で説明したが、添付の請求項によって限定される本開示は、必ずしも上述の具体的な特徴又は動作に限定されないと理解されるべきである。前述の具体的な特徴や動作はむしろ、請求項を実現する例示的形態として開示されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】