JP6964164B2 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
JP6964164B2
JP6964164B2 JP2020109187A JP2020109187A JP6964164B2 JP 6964164 B2 JP6964164 B2 JP 6964164B2 JP 2020109187 A JP2020109187 A JP 2020109187A JP 2020109187 A JP2020109187 A JP 2020109187A JP 6964164 B2 JP6964164 B2 JP 6964164B2
Authority
JP
Japan
Prior art keywords
enb
data
data transmission
random access
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020109187A
Other languages
English (en)
Other versions
JP2020162170A (ja
Inventor
真人 藤代
智春 山▲崎▼
ヘンリー チャン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kyocera Corp
Original Assignee
Kyocera Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kyocera Corp filed Critical Kyocera Corp
Publication of JP2020162170A publication Critical patent/JP2020162170A/ja
Priority to JP2021170462A priority Critical patent/JP7307134B2/ja
Application granted granted Critical
Publication of JP6964164B2 publication Critical patent/JP6964164B2/ja
Priority to JP2023107514A priority patent/JP2023123751A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/002—Transmission of channel access control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0833—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions
    • H04W48/06—Access restriction performed under specific conditions based on traffic conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Description

本発明は、移動通信システムにおける通信制御方法に関する。
近年、人が介在することなく通信を行うＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）及びＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）サービスを対象とした無線端末が注目されている。このような無線端末は、低コスト化、カバレッジ拡張、及び低消費電力化を実現することが求められる。このため、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、システム送受信帯域の一部のみに送受信帯域幅を制限した新たな無線端末のカテゴリが仕様化されている。
一実施形態に係る通信制御方法は、移動通信システムにおける方法である。前記通信制御方法は、基地局が、ランダムアクセスプロシージャ中にメッセージ３を利用して上りリンクユーザデータを送信するアーリーデータ伝送において送信することが許容される許容データ量を示すシステム情報ブロック（ＳＩＢ）を送信するステップと、ＲＲＣアイドルモードにある無線端末が、前記ＳＩＢを受信するステップと、前記無線端末が、前記基地局への送信データ量が前記ＳＩＢにより示される前記許容データ量以下である場合に、前記アーリーデータ伝送を行うと判断するステップとを備える。
前記通信制御方法は、前記アーリーデータ伝送を行うと判断した後、前記無線端末が、前記アーリーデータ伝送用のＰＲＡＣＨリソースの中から、ランダムアクセスプリアンブルの送信に用いるＰＲＡＣＨリソースを選択するステップと、前記無線端末が、前記選択されたＰＲＡＣＨリソースを用いて前記ランダムアクセスプリアンブルを前記基地局に送信するステップとをさらに備えてもよい。
前記通信制御方法において、前記アーリーデータ伝送用のＰＲＡＣＨリソースは、拡張カバレッジレベルごとに設けられており、前記選択するステップは、前記無線端末に適用される拡張カバレッジレベルに対応するＰＲＡＣＨリソースを選択するステップを含んでもよい。
前記通信制御方法は、前記基地局が、前記ランダムアクセスプリアンブルの受信に応じて、上りリンクグラントを含むランダムアクセス応答を前記無線端末に送信するステップをさらに備え、前記ランダムアクセス応答は、前記上りリンクグラントが前記アーリーデータ伝送用である否かを示す情報を含んでもよい。
前記通信制御方法は、前記無線端末が、前記ランダムアクセス応答を前記基地局から受信するステップと、前記無線端末が、前記ランダムアクセス応答に含まれる前記上りリンクグラントが前記アーリーデータ伝送用でない場合に、前記アーリーデータ伝送を中止するステップとをさらに備えてもよい。
一実施形態に係る通信制御方法は、ランダムアクセスプロシージャ中に基地局から無線端末に対して上りリンクユーザデータの送信を行うアーリーデータ伝送を制御するための通信制御方法である。前記通信制御方法は、前記基地局が、前記アーリーデータ伝送を伴わない前記ランダムアクセスプロシージャのための第１のタイマ値と、前記アーリーデータ伝送を伴う前記ランダムアクセスプロシージャのための第２のタイマ値とを前記無線端末に送信するステップＡと、前記無線端末が前記アーリーデータ伝送を行うと判断したことに応じて、前記無線端末が、前記第２のタイマ値を選択するステップＢと、前記無線端末が、前記アーリーデータ伝送により前記上りリンクデータを送信する際に、前記第２のタイマ値を設定したタイマを開始させるステップＣとを備える。
一実施形態に係る通信制御方法は、ランダムアクセスプロシージャ中に基地局から無線端末に対して下りリンクユーザデータの送信を行うアーリーデータ伝送を制御するための通信制御方法である。前記通信制御方法は、前記基地局が、前記アーリーデータ伝送におけるデータ量条件に関する情報を前記無線端末に送信するステップＡと、前記無線端末が、前記データ量条件に関する情報を前記基地局から受信するステップＢと、前記無線端末が、前記アーリーデータ伝送において前記基地局から受信するべき下りリンクユーザデータの量を推定するステップＣと、前記無線端末が、前記推定された下りリンクユーザデータの量が前記データ量条件を満たす場合に、前記アーリーデータ伝送を開始するステップＤとを備える。
一実施形態に係る通信制御方法は、ランダムアクセスプロシージャ中に、基地局から設定された最大ユーザデータ量以下の量のユーザデータを無線端末が送信又は受信するアーリーデータ伝送を制御するための通信制御方法である。前記通信制御方法は、前記無線端末が、前記無線端末が推奨する前記最大ユーザデータ量を決定するステップＡと、ＲＲＣコネクティッドモードにある前記無線端末が、前記無線端末が推奨する前記最大ユーザデータ量を示す情報を前記基地局に送信するステップＢとを備える。
実施形態に係るＬＴＥシステム（移動通信システム）の構成を示す図である。 実施形態に係るＵＥ（無線端末）の構成を示す図である。 実施形態に係るｅＮＢ（基地局）の構成を示す図である。 実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。 実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。 ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥが取り扱う周波数チャネルを示す図である。 ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥ向けのランダムアクセスプロシージャを示す図である。 第１実施形態に係る動作パターン１を示す図である。 第１実施形態に係る動作パターン２を示す図である。 第１実施形態に係る動作パターン３を示す図である。 第１実施形態に係る動作パターン４を示す図である。 図１１のシーケンスの変更例を示す図である。 第１実施形態の変更例１を示す図である。 第１実施形態の変更例１に係るＰＲＡＣＨリソース構成の一例を示す図である。 第１実施形態の変更例２を示す図である。 第１実施形態の変更例８に係るＭＡＣ ＰＤＵの一例を示す図である。 第１実施形態の変更例１４の動作の一例を示す図である。 第１実施形態の変更例１４の動作の他の例を示す図である。 第１実施形態の変更例１５の動作の一例を示す図である。 第１実施形態の変更例１７の動作の一例を示す図である。 第１実施形態の変更例１８の動作の一例を示す図である。 第２実施形態の動作パターン１の一例を示す図である。 第２実施形態の動作パターン２の一例を示す図である。 第２実施形態の動作パターン３の一例を示す図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。
［第１実施形態］
（第１実施形態の概要）
ＭＴＣやＩｏＴを対象とした無線端末は、一般的な無線端末に比べて、送受信すべきデータの量が少なく、データの送受信を行う頻度も少ない。よって、ＭＴＣやＩｏＴを対象とした無線端末が効率的に通信を行うために、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送（ｅａｒｌｙ ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎ）が検討されている。しかしながら、現状の移動通信システムはランダムアクセスプロシージャ中にデータを送信することを想定しておらず、アーリーデータ伝送を実現可能とする仕組みが存在しない。
そこで、本開示は、アーリーデータ伝送を実現可能とする通信制御方法を提供することを目的とする。
第１実施形態に係る通信制御方法は、移動通信システムにおける方法である。前記通信制御方法は、第１無線通信装置が、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送を行うか否かに関する情報を第２無線通信装置に送信するステップＡと、前記第２無線通信装置が前記情報を受信した後、前記第２無線通信装置が、当該受信した情報に基づいて前記アーリーデータ伝送を行うか否かを判断するステップＢとを備える。前記第１無線通信装置は無線端末及び基地局のうち一方であり、前記第２無線通信装置は前記無線端末及び前記基地局のうち他方である。前記ステップＡは、前記所定メッセージの送信タイミングよりも前に行われる。
（移動通信システム）
第１実施形態に係る移動通信システムの構成について説明する。図１は、第１実施形態に係る移動通信システムであるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムの構成を示す図である。ＬＴＥシステムは、３ＧＰＰ規格に基づく移動通信システムである。
ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。
ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、自身が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。
Ｅ−ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理する。ｅＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数に属する。
ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ−ＧＷ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。ＭＭＥは、ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するトラッキングエリア（ＴＡ）の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ及びＳ−ＧＷは、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。
図２は、ＵＥ１００（無線端末）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
図３は、ｅＮＢ２００（基地局）の構成を示す図である。ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢと接続される。バックホール通信部２４０は、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。
図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１レイヤ乃至第３レイヤに区分されている。第１レイヤは物理（ＰＨＹ）レイヤである。第２レイヤは、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤを含む。第３レイヤは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤを含む。ＰＨＹレイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤ、及びＲＲＣレイヤは、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤを構成する。
ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｅＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定する。
ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
ＲＲＣレイヤは、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードである。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドルモードである。
ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＭＭＥ３００ＣのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。
図５は、ＬＴＥシステムにおいて用いられる無線フレームの構成を示す図である。無線フレームは、時間軸上で１０個のサブフレームで構成される。各サブフレームは、時間軸上で２個のスロットで構成される。各サブフレームの長さは１ｍｓである。各スロットの長さは０．５ｍｓである。各サブフレームは、周波数軸上で複数個のリソースブロック（ＲＢ）を含む。各サブフレームは、時間軸上で複数個のシンボルを含む。各リソースブロックは、周波数軸上で複数個のサブキャリアを含む。具体的には、１２個のサブキャリア及び１つのスロットにより１つのＲＢが構成される。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）として用いられる領域である。各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）として用いることができる領域である。
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）として用いることができる領域である。
（ｅＭＴＣ及びＮＢ−ＩｏＴの概要）
ｅＭＴＣ及びＮＢ−ＩｏＴの概要について説明する。第１実施形態において、ＭＴＣ及びＩｏＴサービスを対象とした新たなカテゴリのＵＥ１００が存在するシナリオを想定する。新たなカテゴリのＵＥ１００は、システム送受信帯域（ＬＴＥ送受信帯域幅）の一部のみに送受信帯域幅が制限されるＵＥ１００である。新たなＵＥカテゴリは、例えば、カテゴリＭ１及びカテゴリＮＢ（Ｎａｒｒｏｗ Ｂａｎｄ）−ＩｏＴと称される。カテゴリＭ１は、ｅＭＴＣ（ｅｎｈａｎｃｅｄ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）ＵＥが属するカテゴリである。カテゴリＮＢ−ＩｏＴ（カテゴリＮＢ１）は、ＮＢ−ＩｏＴ ＵＥが属するカテゴリである。カテゴリＭ１は、ＵＥ１００（ｅＭＴＣ ＵＥ）の送受信帯域幅を例えば１．０８ＭＨｚ（すなわち、６リソースブロックの帯域幅）に制限する。カテゴリＮＢ−ＩｏＴ（カテゴリＮＢ１）は、ＵＥ１００（ＮＢ−ＩｏＴ ＵＥ）の送受信帯域幅を１８０ｋＨｚ（すなわち、１リソースブロックの帯域幅）にさらに制限する。このような狭帯域化により、ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥに要求される低コスト化及び低消費電力化が実現可能となる。
図６は、ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥが取り扱う周波数チャネルを示す図である。図６に示すように、ＬＴＥシステムのシステム周波数帯域の周波数帯域幅は１０ＭＨｚであり得る。システム送受信帯域の帯域幅は、例えば、５０リソースブロック＝９ＭＨｚである。ｅＭＴＣ ＵＥが対応可能な周波数チャネルの帯域幅は、６リソースブロック＝１．０８ＭＨｚ以内である。ｅＭＴＣ ＵＥが対応可能な６リソースブロック以内の周波数チャネルは、「狭帯域（ＮＢ：Ｎａｒｒｏｗ Ｂａｎｄ）」と称される。ＮＢ−ＩｏＴ ＵＥが対応可能な周波数チャネルの帯域幅は、１リソースブロック＝１８０ｋＨｚである。ＮＢ−ＩｏＴ ＵＥが対応可能な１リソースブロックの周波数チャネルは、「キャリア（ｃａｒｒｉｅｒ）」と称される。
ｅＭＴＣ ＵＥは、ＬＴＥ送受信帯域幅内で運用される。ＮＢ−ＩｏＴ ＵＥは、ＬＴＥ送受信帯域幅内で運用される形態、ＬＴＥ送受信帯域幅外のガードバンドで運用される形態、及びＮＢ−ＩｏＴ専用の周波数帯域内で運用される形態をサポートする。
ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥは、カバレッジ拡張を実現するために、繰り返し送信等を用いた強化カバレッジ（ＥＣ：Ｅｎｈａｎｃｅｄ Ｃｏｖｅｒａｇｅ）機能をサポートする。強化カバレッジ機能は、複数のサブフレームを用いて同一信号を繰り返し送信する繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）を含んでもよい。繰り返し送信の回数が多いほど、カバレッジを拡張することができる。強化カバレッジ機能は、送信信号の電力密度を上げる電力ブースト（ｐｏｗｅｒ ｂｏｏｓｔｉｎｇ）を含んでもよい。一例として、送信信号の周波数帯域幅を狭くする狭帯域送信により電力密度を上げる。送信信号の電力密度を上げるほど、カバレッジを拡張することができる。強化カバレッジ機能は、送信信号に用いるＭＣＳを下げる低ＭＣＳ（ｌｏｗｅｒ ＭＣＳ）送信を含んでもよい。データレートが低く、誤り耐性の高いＭＣＳを用いて送信を行うことにより、カバレッジを拡張することができる。
（ランダムアクセスプロシージャの概要）
図７は、ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥ向けのランダムアクセスプロシージャを示す図である。初期状態において、ＵＥ１００は、ＲＲＣアイドルモードにある。ＵＥ１００は、ＲＲＣコネクティッドモードに遷移するためにランダムアクセスプロシージャを実行する。このようなケースは、初期接続（Ｉｎｉｔｉａｌ ａｃｃｅｓｓ ｆｒｏｍ ＲＲＣ＿ＩＤＬＥ）と称される。初期接続時には、競合ベース（ｃｏｎｔｅｎｔｉｏｎ ｂａｓｅｄ）のランダムアクセスプロシージャが適用される。
ＵＥ１００は、ｅＮＢ２００のセルをサービングセルとして選択している。ＵＥ１００は、通常のカバレッジのための第１のセル選択基準（第１のＳ−ｃｒｉｔｅｒｉａ）が満たされず、強化カバレッジのための第２のセル選択基準（第２のＳ−ｃｒｉｔｅｒｉａ）が満たされた場合、自身が強化カバレッジに居ると判定してもよい。「強化カバレッジに居るＵＥ」とは、セルにアクセスするために強化カバレッジ機能（強化カバレッジモード）を用いることが必要とされるＵＥを意味する。なお、ｅＭＴＣ ＵＥは、強化カバレッジモードを用いることが必須である。ここでは、ＵＥ１００が強化カバレッジに居ると仮定して説明を進める。
ステップＳ１００１において、ｅＮＢ２００は、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）関連情報をブロードキャストシグナリング（例えば、ＳＩＢ）により送信する。ＰＲＡＣＨ関連情報は、強化カバレッジレベルごとに設けられた各種のパラメータを含む。一例として、強化カバレッジレベルは、強化カバレッジレベル０乃至３の合計４つのレベルが規定される。各種のパラメータは、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）閾値、ＰＲＡＣＨリソース、及び最大プリアンブル送信回数を含む。ＰＲＡＣＨリソースは、無線リソース（時間・周波数リソース）及び信号系列（プリアンブル系列）を含む。ＵＥ１００は、受信したＰＲＡＣＨ関連情報を記憶する。
ステップＳ１００２において、ＵＥ１００は、ｅＮＢ２００から送信される参照信号に基づいてＲＳＲＰを測定する。
ステップＳ１００３において、ＵＥ１００は、測定したＲＳＲＰを強化カバレッジレベルごとのＲＳＲＰ閾値と比較することにより、自身の強化カバレッジレベル（ＣＥレベル）を決定する。強化カバレッジレベルは、ＵＥ１００に必要とされる強化カバレッジの度合いを示す。強化カバレッジレベルは、少なくとも繰り返し送信における送信回数（すなわち、Ｒｅｐｅｔｉｔｉｏｎ回数）と関連する。
ステップＳ１００４において、ＵＥ１００は、自身の強化カバレッジレベルに対応するＰＲＡＣＨリソースを選択する。
ステップＳ１００５〜Ｓ１００８は、ランダムアクセスプロシージャを構成する。ステップＳ１００５において、ＵＥ１００は、選択したＰＲＡＣＨリソースを用いてＭｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。なお、「Ｍｓｇ」は、メッセージの略である。ｅＮＢ２００は、受信したＭｓｇ１に用いられたＰＲＡＣＨリソースに基づいて、ＵＥ１００の強化カバレッジレベルを特定する。
ステップＳ１００６において、ｅＮＢ２００は、ＵＥ１００に割り当てたＰＵＳＣＨリソースを示すスケジューリング情報を含むＭｓｇ２（ランダムアクセス応答）をＵＥ１００に送信する。ＵＥ１００は、Ｍｓｇ２を正常に受信するまで、自身の強化カバレッジレベルに対応する最大プリアンブル送信回数までＭｓｇ１を複数回送信し得る。
ステップＳ１００７において、ＵＥ１００は、スケジューリング情報に基づいて、Ｍｓｇ３をｅＮＢ２００に送信する。Ｍｓｇ３は、ＲＲＣ接続要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージであってもよい。
ステップＳ１００８において、ｅＮＢ２００は、Ｍｓｇ４をＵＥ１００に送信する。Ｍｓｇ４は、ＲＲＣ接続確立（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ）メッセージであってもよい。
ステップＳ１００９において、ＵＥ１００は、Ｍｓｇ４の受信に応じてＲＲＣコネクティッドモードに遷移する。その際、ＵＥ１００は、Ｍｓｇ ５：ＲＲＣ接続確立完了（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ）メッセージをｅＮＢ２００に送信してもよい。その後、ｅＮＢ２００は、特定した強化カバレッジレベルに基づいて、ＵＥ１００への繰り返し送信等を制御する。
（アーリーデータ伝送に係る動作）
第１実施形態に係るアーリーデータ伝送に係る動作について説明する。
アーリーデータ伝送は、ランダムアクセスプロシージャ中に所定メッセージを利用してデータ（ユーザデータ）を送信する伝送方法である。所定メッセージは、Ｍｓｇ１（ランダムアクセスプリアンブル）、Ｍｓｇ２（ランダムアクセス応答）、Ｍｓｇ３（例えば、ＲＲＣ接続要求メッセージ）、Ｍｓｇ４（ＲＲＣ接続確立メッセージ）、Ｍｓｇ ５（ＲＲＣ接続確立完了メッセージ）の少なくともいずれかである。なお、「所定メッセージを利用してデータを送信する」とは、データを所定メッセージに含めて送信すること、データを所定メッセージに追加して送信すること、及びデータを所定メッセージに関連付けて送信することの少なくともいずれかである。
アーリーデータ伝送は、ＲＲＣサスペンド状態のＵＥに適用されてもよい。ＲＲＣサスペンド状態は、ＲＲＣアイドルモードの一状態であって、ＵＥコンテキストがネットワークに保持される特殊な状態である。ＲＲＣサスペンド状態のＵＥがＲＲＣコネクティッドモードに復旧するためのランダムアクセスプロシージャでは、Ｍｓｇ３はＲＲＣ接続復旧要求（ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｓｕｍｅ ｒｅｑｕｅｓｔ）メッセージであり、Ｍｓｇ４はＲＲＣ接続復旧（ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｓｕｍｅ）メッセージであり、Ｍｓｇ ５はＲＲＣ接続復旧完了メッセージである。
第１実施形態に係る通信制御方法は、第１無線通信装置が、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送を行うか否かに関する情報を第２無線通信装置に送信するステップＡと、第２無線通信装置が情報を受信した後、第２無線通信装置が、当該受信した情報に基づいてアーリーデータ伝送を行うか否かを判断するステップＢとを備える。第１無線通信装置はＵＥ１００及びｅＮＢ２００のうち一方であり、第２無線通信装置はＵＥ１００及びｅＮＢ２００のうち他方である。ステップＡは、所定メッセージの送信タイミングよりも前に行われる。
第１実施形態に係る動作パターン１〜４の概要について説明する。動作パターン１〜４は、上述した「ランダムアクセスプロシージャの概要」（図７参照）における動作の少なくとも一部と組み合わせることができる。
第１実施形態に係る動作パターン１では、ステップＡは、ＵＥ１００が、アーリーデータ伝送を行うか否かに基づいて、ランダムアクセスプリアンブルの送信に適用するリソースを選択するステップと、ＵＥ１００が、当該選択したリソースが適用されたランダムアクセスプリアンブルを送信するステップとを含む。ステップＢにおいて、ｅＮＢ２００は、ランダムアクセスプリアンブルに適用されたリソースに基づいて、アーリーデータ伝送を行うか否かを判断する。
第１実施形態に係る動作パターン２では、ステップＡにおいて、ＵＥ１００は、ＵＥ１００がコネクティッドモードである間に、アーリーデータ伝送を行うことを示す通知をｅＮＢ２００に送信する。動作パターン２は、通知の送信後、ＵＥ１００がコネクティッドモードからアイドルモードに遷移するステップと、ｅＮＢ２００又は上位ネットワーク装置が、ＵＥ１００がアイドルモードである間において通知を保持するステップとを更に備える。ステップＢにおいて、ｅＮＢ２００は、ランダムアクセスプロシージャの際に、当該保持された通知に基づいてアーリーデータ伝送を行うか否かを判断する。
第１実施形態に係る動作パターン３では、ステップＡにおいて、ｅＮＢ２００は、ランダムアクセスプロシージャが開始されるよりも前において、アーリーデータ伝送を行うか否かを示す通知を、ページングメッセージ、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）、及びＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）の少なくともいずれかによってＵＥ１００に送信する。ステップＢにおいて、ＵＥ１００は、ｅＮＢ２００からの通知に基づいて、アーリーデータ伝送を行うか否かを判断する。
第１実施形態に係る動作パターン４では、ステップＡにおいて、ｅＮＢ２００は、ランダムアクセスプロシージャを開始するよりも前に、アーリーデータ伝送によって送信することが許容されるデータの量を示す情報をＵＥ１００に送信する。ステップＢにおいて、ＵＥ１００は、ｅＮＢ２００から通知されたデータの量と、当該ＵＥ１００がｅＮＢ２００に送信するデータの量とに基づいて、アーリーデータ伝送を行うか否かを判断する。
（１）動作パターン１
図８は、第１実施形態に係る動作パターン１を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。
図８に示すように、ステップＳ１０１において、ｅＮＢ２００は、ランダムアクセスプリアンブルの送信に利用可能なリソースであるＰＲＡＣＨリソース（ＰＲＡＣＨリソースプール）を示すＰＲＡＣＨリソース情報をシステム情報（ＳＩＢ）によって送信（ブロードキャスト）する。ＰＲＡＣＨリソースは、無線リソース（時間・周波数リソース）及び／又は信号系列（プリアンブル系列）を含む。
ＰＲＡＣＨリソースは、アーリーデータ伝送を行うこと（アーリーデータ伝送を行う意図）を示す第１リソースグループ（ＰＲＡＣＨリソースプール）と、アーリーデータ伝送を行わないことを示す第２リソースグループ（ＰＲＡＣＨリソースプール）とを含む。第１リソースグループと第２リソースグループとに分けられるＰＲＡＣＨリソースは、無線リソース（時間・周波数リソース）であってもよい。第１リソースグループと第２リソースグループとに分けられるＰＲＡＣＨリソースは、信号系列（プリアンブル系列）であってもよい。
ｅＮＢ２００は、第１リソースグループを示す情報と第２リソースグループを示す情報とをＳＩＢに含める。第２リソースグループは、従来と同様なＰＲＡＣＨリソースであってもよい。第１リソースグループは、従来のＰＲＡＣＨリソースとは別に確保されたＰＲＡＣＨリソースであってもよい。
第１リソースグループは、アーリーデータ伝送によって上りリンクデータを送信することを示す第１リソースサブグループと、アーリーデータ伝送によって下りリンクデータを受信することを示す第２リソースサブグループとを含んでもよい。さらに、第１リソースグループは、アーリーデータ伝送によって上りリンクデータの送信と下りリンクデータの受信の両方を行うことを示す第３リソースサブグループを含んでもよい。ｅＮＢ２００は、複数のリソースサブグループ（第１リソースサブグループ、第２リソースサブグループ、及び第３リソースサブグループ）の少なくともいずれかを示す情報をＳＩＢに含めてもよい。
ＲＲＣアイドルモードのＵＥ１００は、ｅＮＢ２００からＳＩＢを受信する。ＲＲＣアイドルモードのＵＥ１００は、ＲＲＣ接続を確立する必要が生じたと判断し、ランダムアクセスプロシージャの準備を開始する。ここで、ＵＥ１００は、ＵＥ１００内で上りリンクデータが発生したことに応じて、上りリンクデータを送信するために、ＲＲＣ接続を確立する必要が生じたと判断してもよい。ＵＥ１００は、自身宛のページングメッセージをｅＮＢ２００から受信したことに応じて、下りリンクデータを受信するために、ＲＲＣ接続を確立する必要が生じたと判断してもよい。
ステップＳ１０２において、ＲＲＣアイドルモードのＵＥ１００は、ＳＩＢで通知されたＰＲＡＣＨリソースの中から、ランダムアクセスプリアンブルの送信に適用するリソースを選択する。ＵＥ１００は、アーリーデータ伝送を行う場合、第１リソースグループ中のリソースを選択する。一方で、ＵＥ１００は、アーリーデータ伝送を行わない場合、第２リソースグループ中のリソースを選択する。アーリーデータ伝送を行うか否かは、次の１）〜７）の基準のうち少なくともいずれかに基づく。１）ＵＥ１００の能力、すなわち、ＵＥ１００がアーリーデータ伝送を行う能力を有するか否か。２）ＵＥ１００が送信又は受信するデータの優先度（例えば、ＱｏＳ）。３）ＵＥ１００の電力状態（例えば、バッテリ残量）。４）データの遅延削減の要否（例えば、早期ＴＣＰ ＡＣＫ送信の必要性）。５）ユーザのプリファレンス（例えば、手動設定に依る）。６）ネットワークからの指示（例えば、ＭＭＥなどによる機能制限や認証結果に基づく）。７）ｅＮＢからの指示（例えば、ｅＮＢがアーリーデータ送受信能力を有するか否かに基づく）。なお、「アーリーデータ伝送を行う」とは、ＵＥ１００がアーリーデータ伝送を行いたいことであってもよいし、アーリーデータ伝送を許容するか否かであってもよいし、アーリーデータ伝送が可能か否かであってもよい。
ＵＥ１００は、アーリーデータ伝送を行うか否かを上りリンクと下りリンクとで別々に判断してもよい。ＵＥ１００は、アーリーデータ伝送によって上りリンクデータを送信する場合、第１リソースサブグループ中のリソースを選択してもよい。ＵＥ１００は、アーリーデータ伝送によって下りリンクデータを受信する場合、第２リソースサブグループ中のリソースを選択してもよい。
ステップＳ１０３において、ＵＥ１００は、ステップＳ１０２で選択したリソースが適用されたＭｓｇ１（ランダムアクセスプリアンブル）を送信する。
ステップＳ１０４において、ｅＮＢ２００は、受信したランダムアクセスプリアンブルに適用されたリソースに基づいて、アーリーデータ伝送を行うか否かを判断する。例えば、第１リソースグループ中のリソースがランダムアクセスプリアンブルに適用されている場合、ｅＮＢ２００は、送信元のＵＥ１００についてアーリーデータ伝送を行うと判断する。さらに、ｅＮＢ２００は、リソースサブグループに基づいて、上りリンクのアーリーデータ伝送及び下りリンクのアーリーデータ伝送のいずれを行うかを判断してもよい。一方で、第２リソースグループ中のリソースがランダムアクセスプリアンブルに適用されている場合、ｅＮＢ２００は、送信元のＵＥ１００についてアーリーデータ伝送を行わないと判断する。
なお、動作パターン１において、時間・周波数リソースを分割するケースと信号系列リソースを分割するケースとを説明したが、時間・周波数リソースと信号系列リソースとを組み合わせて分割してもよい。例えば、時間・周波数リソースを第１リソースグループと第２リソースグループとに分割し、第１リソースグループにおいて信号系列リソースをリソースサブグループに分割してもよい。或いは、信号系列リソースを第１リソースグループと第２リソースグループとに分割し、第１リソースグループにおいて時間・周波数リソースをリソースサブグループに分割してもよい。
また、後述するように、上りリンクのアーリーデータ伝送は、下りリンクのアーリーデータ伝送とセットで用いられることがある。例えば、ＵＥ１００は、上りリンクのアーリーデータ伝送によって上りリンクデータをＭｓｇ３で送信し、当該データに対する応答データ（ＴＣＰ ＡＣＫ等）を下りリンクのアーリーデータ伝送によってＭｓｇ４で受信する。よって、Ｍｓｇ１によってアーリーデータ伝送の意図を通知することを可能とする条件は、「ＵＥ１００が上りリンクのアーリーデータ伝送及び下りリンクのアーリーデータ伝送の両方の能力を有している」という条件を含んでもよい。すなわち、上りリンクのアーリーデータ伝送及び下りリンクのアーリーデータ伝送の少なくとも一方の能力を有していないＵＥ１００は、Ｍｓｇ１によってアーリーデータ伝送の意図を通知することが禁止されてもよい。
さらに、アーリーデータ伝送の意図を通知するために用いられる新たなＰＲＡＣＨリソースプール（時間・周波数リソース）は、従来のＰＲＡＣＨリソースプール（時間・周波数リソース）とは別のリソースプールとして規定されることが好ましい。この場合、新たなＰＲＡＣＨリソースプールと従来のＰＲＡＣＨリソースプールとを重複しないように設定するか、又は新たなＰＲＡＣＨリソースプールと従来のＰＲＡＣＨリソースプールとを少なくとも一部重複して設定するかを、ｅＮＢ２００が決定し、ｅＮＢ２００が各ＰＲＡＣＨリソースプールをＵＥ１００に通知（例えば、ＳＩＢにより通知）してもよい。
（２）動作パターン２
図９は、第１実施形態に係る動作パターン２を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。また、動作パターン１と重複する説明を省略する。動作パターン２は、上りリンクのアーリーデータ伝送に適用されてもよいし、下りリンクのアーリーデータ伝送に適用されてもよい。
図９に示すように、ステップＳ２０１において、ＲＲＣコネクティッドモードのＵＥ１００は、アーリーデータ伝送を行うことを示す通知をｅＮＢ２００に送信する。例えば、ＵＥ１００は、次回のＲＲＣ接続の確立の際にアーリーデータ伝送を行う旨をｅＮＢ２００に通知する。ＵＥ１００は、ｅＮＢ２００に通知した内容（通知情報）を記憶する。上りリンクのアーリーデータ伝送を行うことを示す通知と下りリンクのアーリーデータ伝送を行うことを示す通知とが別々に定義されてもよい。通知は、ＵＥ１００の能力情報（アーリーデータ伝送に関する能力）を含んでもよい。ｅＮＢ２００は、ＵＥ１００からの通知を記憶する。ｅＮＢ２００は、当該通知を上位装置（例えば、ＭＭＥ３００）に転送してもよい。
ステップＳ２０２において、ｅＮＢ２００は、ＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージをＵＥ１００に送信する。ＲＲＣ接続解放メッセージは、ＵＥ１００をＲＲＣサスペンド状態に設定することを示す情報を含んでもよい。また、ＲＲＣ接続解放メッセージは、ＵＥ１００がアーリーデータ伝送を行ってよい（又は行わなければならない）ことを示す情報を含んでもよい。ＲＲＣ接続解放メッセージは、ＵＥ１００がアーリーデータ伝送を行ってはならないことを示す情報を含んでもよい。
ステップＳ２０３において、ＵＥ１００は、ＲＲＣ接続解放メッセージに応じて、ＲＲＣ接続を解放し、ＲＲＣコネクティッドモードからＲＲＣアイドルモードに遷移する。ＵＥ１００は、ＲＲＣサスペンド状態になってもよい。ＵＥ１００は、自身がアイドルモードである間において通知情報を保持する。
ステップＳ２０４において、ｅＮＢ２００は、ＵＥ１００がアイドルモードである間において通知情報を保持する。言い換えると、ｅＮＢ２００は、ＵＥ１００について次回のＲＲＣ接続の確立の際にアーリーデータ伝送を行う旨の情報を保持する。ｅＮＢ２００に加えて、又はｅＮＢ２００に代えて、ｅＮＢ２００の上位装置（例えば、ＭＭＥ３００）が通知情報を保持してもよい。ｅＮＢ２００及び／又はＭＭＥ３００が保持する情報は、ＵＥ１００の能力情報（アーリーデータ伝送に関する能力）を含んでもよい。ＵＥ１００及びｅＮＢ２００は、ＵＥ１００がアーリーデータ伝送を行わないと決めた時（Ｍｓｇ１で従来のＰＲＡＣＨリソースを使った時）に、通知情報をキャンセル（破棄）してもよい。
ステップＳ２０５において、ＵＥ１００は、Ｍｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。詳細については後述するが、ＵＥ１００は、ｅＮＢ２００からＵＥ個別に割り当てられた専用のプリアンブル系列（ｄｅｄｉｃａｔｅｄ ｐｒｅａｍｂｌｅ）を適用してランダムアクセスプリアンブルを送信してもよい。ｅＮＢ２００は、ＵＥ１００からのランダムアクセスプリアンブルを受信する。
ｅＮＢ２００は、アイドルモードのＵＥ１００宛てのページングメッセージを上位装置（例えば、ＭＭＥ３００）から受信してもよい。ページングメッセージは、宛先ＵＥの識別子と、上位装置が保持した通知情報との組み合わせを含んでもよい。ｅＮＢ２００は、ページングメッセージに含まれる情報を、ＵＥ１００についてアーリーデータ伝送を行うか否かの判断に用いてもよい。
専用のプリアンブル系列が適用される場合、ステップＳ２０６において、ｅＮＢ２００は、プリアンブル系列に基づいてＵＥ１００を識別する。そして、ｅＮＢ２００は、ステップＳ２０４で保持した通知情報に基づいて、アーリーデータ伝送を行うか否かを判断する。具体的には、ｅＮＢ２００は、識別されたＵＥ１００に対応する通知情報が保持されていれば、アーリーデータ伝送を行うと判断する。一方で、識別されたＵＥ１００に対応する通知情報が保持されていなければ、ｅＮＢ２００は、アーリーデータ伝送を行わないと判断する。
ステップＳ２０７において、ｅＮＢ２００は、Ｍｓｇ２（ランダムアクセス応答）をＵＥ１００に送信する。
ステップＳ２０８において、ＵＥ１００は、Ｍｓｇ３をｅＮＢ２００に送信する。
専用のプリアンブル系列が適用されない場合、ステップＳ２０９において、ｅＮＢ２００は、Ｍｓｇ３に基づいてＵＥ１００を識別する。そして、ｅＮＢ２００は、ステップＳ２０４で保持した通知情報に基づいて、アーリーデータ伝送を行うか否かを判断する。
（３）動作パターン３
図１０は、第１実施形態に係る動作パターン３を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。また、動作パターン１及び２と重複する説明を省略する。動作パターン３は、下りリンクのアーリーデータ伝送に適用される。
動作パターン３において、ランダムアクセスプロシージャを行うＵＥ１００は、ＲＲＣアイドルモード又はＲＲＣコネクティッドモードである。ＲＲＣアイドルモードのＵＥ１００は、競合ベースのランダムアクセスプロシージャを行う。一方で、ＲＲＣコネクティッドモードのＵＥ１００は、非競合ベース（ｎｏｎ−ｃｏｎｔｅｎｔｉｏｎ ｂａｓｅｄ）のランダムアクセスプロシージャを行うことが可能である。非競合ベースのランダムアクセスプロシージャでは、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）又は個別ＲＲＣシグナリング（ｄｅｄｉｃａｔｅｄ ｓｉｇｎａｌｉｎｇ）によって、ｅＮＢ２００からＵＥ個別に専用のプリアンブル系列が割り当てられる。非競合ベースのランダムアクセスプロシージャは、ハンドオーバ時や上りリンクのタイミング調整時等に適用される。
図１０に示すように、ステップＳ３０１において、ｅＮＢ２００は、ランダムアクセスプロシージャが開始されるよりも前において、アーリーデータ伝送を行うか否かを示す通知を、ページングメッセージ、ＤＣＩ、及びＰＤＳＣＨの少なくともいずれかによってＵＥ１００に送信する。
ページングメッセージを用いる場合、競合ベースのランダムアクセスプロシージャが適用されてもよい。ｅＮＢ２００は、宛先ＵＥの識別子とアーリーデータ伝送を行うか否かを示す情報との組み合わせ含むページングメッセージを送信する。このようなページングメッセージは、ＭＭＥ３００によって生成され、ＭＭＥ３００からｅＮＢ２００を介してＵＥ１００に送信されてもよい。
ＤＣＩ又はＰＤＳＣＨを用いる場合、ＵＥ１００はＲＲＣコネクティッドモードであってもよい。ＤＣＩ又はＰＤＳＣＨを用いる場合、非競合ベースのランダムアクセスプロシージャが適用されてもよい。ｅＮＢ２００は、ＵＥ１００宛てのＤＣＩ又はＰＤＳＣＨに、アーリーデータ伝送を行うか否かを示す情報を含める。ｅＮＢ２００は、間欠受信（ＤＲＸ）動作を行うＵＥ１００がＰＤＣＣＨを監視するタイミングであるＰａｇｉｎｇ ｏｃｃａｓｉｏｎにおいて、アーリーデータ伝送を行うか否かを示す情報を含むＤＣＩをＵＥ１００に送信してもよい。
アーリーデータ伝送に利用される所定メッセージがＭｓｇ１（ランダムアクセスプリアンブル）である場合、ｅＮＢ２００は、アーリーデータ伝送を行うか否かをＵＥ１００に通知する際に、アーリーデータ伝送用のＰＲＡＣＨリソースをＵＥ１００に通知してもよい。当該通知は、ページングメッセージ、ＤＣＩ、及びＰＤＳＣＨの少なくともいずれかによって行われる。ｅＮＢ２００は、予めＳＩＢによっていくつかのＰＲＡＣＨリソース（及びそのインデックスを含むリスト）をブロードキャストしてもよい。ｅＮＢ２００は、ＰＲＡＣＨリソースのインデックスを、ページングメッセージ、ＤＣＩ、及びＰＤＳＣＨの少なくともいずれかによって通知してもよい。
ステップＳ３０２において、ＵＥ１００は、ステップＳ３０１におけるｅＮＢ２００からの通知に基づいて、アーリーデータ伝送を行うか否かを判断する。アーリーデータ伝送を行うことが通知されている場合、ＵＥ１００は、アーリーデータ伝送を行うと判断してもよい。或いは、アーリーデータ伝送を行うことが通知されている場合であっても、ＵＥ１００は、アーリーデータ伝送を行わないと判断してもよい。この場合、ＵＥ１００は、ランダムアクセスプロシージャ中に、例えばＭｓｇ１（ランダムアクセスプリアンブル）又はＭｓｇ３（例えば、ＲＲＣ接続要求メッセージ）によって、アーリーデータ伝送を行わない旨をｅＮＢ２００に通知してもよい。
ランダムアクセスプロシージャが開始されると、ステップＳ３０３において、ＵＥ１００は、Ｍｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。アーリーデータ伝送を行う場合、ｅＮＢ２００は、ランダムアクセスプロシージャ中に、例えばＭｓｇ２（ランダムアクセス応答）又はＭｓｇ４（例えば、ＲＲＣ接続確立メッセージ）によって、下りリンクデータをＵＥ１００に送信する。
或いは、ｅＮＢ２００は、下りリンクのアーリーデータ伝送を行う旨を、ランダムアクセスプロシージャ中にＵＥ１００に通知してもよい。例えば、ｅＮＢ２００は、Ｍｓｇ４によって下りリンクデータを送信することを示す情報を、Ｍｓｇ２によってＵＥ１００に送信してもよい。
（４）動作パターン４
図１１は、第１実施形態に係る動作パターン４を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。また、動作パターン１〜３と重複する説明を省略する。動作パターン４は、上りリンクのアーリーデータ伝送に適用される。
図１１に示すように、ステップＳ４０１において、ｅＮＢ２００は、ランダムアクセスプロシージャを開始するよりも前に、アーリーデータ伝送によって送信することが許容されるデータの量（許容データ量）を示す情報をＵＥ１００に送信する。アーリーデータ伝送の許容データ量を示す情報は、許容データ量を示す閾値であってもよい。ｅＮＢ２００は、アーリーデータ伝送の許容データ量を示す情報をＳＩＢによってブロードキャストしてもよい。ｅＮＢ２００は、アーリーデータ伝送の許容データ量を示す情報をユニキャストメッセージ（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージ）によってＵＥ個別に送信してもよい。ＵＥ１００は、アーリーデータ伝送の許容データ量を示す情報を受信する。ＵＥ１００は、ＲＲＣアイドルモードであってもよい。
ｅＮＢ２００がＵＥ１００に通知する許容データ量は、１つのみであってもよいし、複数であってもよい。複数である場合、許容データ量とそのインデックスとの複数の組み合わせからなるリストが構成されてもよい。ｅＮＢ２００は、セルの負荷の状況などに基づいて、当該リストの中身（レコードの数）を変更してもよい。ＵＥ１００は、当該リストに基づいて、ｅＮＢ２００に送信する上りリンクデータの量に対応するインデックスをＭｓｇ１でｅＮＢ２００に通知することによって、アーリーデータ伝送によって送信するデータ量をｅＮＢ２００に示してもよい。
ステップＳ４０２において、ＵＥ１００は、ｅＮＢ２００から通知された許容データ量と、当該ＵＥ１００がｅＮＢ２００に送信するデータの量とに基づいて、アーリーデータ伝送を行うか否かを判断する。ｅＮＢ２００に送信するデータの量とは、ＵＥ１００内の上りリンクバッファに蓄積された上りリンクデータの量であってもよい。
かかる判断を行う主体は、ＵＥ１００のアクセスレイヤ（ＡＳ）であってもよいし、ＵＥ１００の上位レイヤであってもよい。上述したように、アクセスレイヤ（ＡＳ）は、ＰＨＹレイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤ、及びＲＲＣレイヤからなるレイヤである。アクセスレイヤ（ＡＳ）は、ｅＮＢ２００との無線通信を行うためのレイヤである。上位レイヤは、ＮＡＳレイヤ及びアプリケーションレイヤ等からなるレイヤであり、アクセスレイヤよりも上位に位置付けられる。ｅＮＢ２００に送信するデータ（すなわち、上りリンクデータ）は上位レイヤにおいて生成される。
判断主体がＵＥ１００のアクセスレイヤ（ＡＳ）である場合、ＵＥ１００の上位レイヤは、上りリンクのアーリーデータ伝送によってｅＮＢ２００に送信するデータの量をＵＥ１００のアクセスレイヤ（ＡＳ）に通知してもよい。ｅＮＢ２００に送信するデータの量は、データパケットのサイズであってもよいし、複数のデータパケットの総量であってもよい。データパケットは、ＰＤＣＰ ＳＤＵ（すなわち、ＩＰパケット）であってもよいし、ＮＡＳヘッダを含むＮＡＳ ＰＤＵであってもよい。例えば、ＵＥ１００のアクセスレイヤ（ＡＳ）は、ｅＮＢ２００からＳＩＢによって通知された許容データ量と、上位レイヤから通知されたデータパケットのサイズとに基づいて、アーリーデータ伝送を行うか否かを判断する。
一方、判断主体がＵＥ１００の上位レイヤである場合、アクセスレイヤは、ｅＮＢ２００から通知された許容データ量を上位レイヤに通知する。上位レイヤは、アクセスレイヤから通知された許容データ量と、ｅＮＢ２００に送信するデータパケットのサイズとに基づいて、アーリーデータ伝送を行うか否かを判断する。
ＵＥ１００は、ｅＮＢ２００に送信するデータの量が許容データ量以下である場合に、アーリーデータ伝送を行うと判断してもよい。この場合、ＵＥ１００は、ランダムアクセスプロシージャ中にアーリーデータ伝送によって上りリンクデータの送信が完了すると、ＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了してもよい。このような動作は、第１実施形態の変更例４で説明する。
ＵＥ１００は、ｅＮＢ２００に送信するデータの量が許容データ量を上回っている場合でも、アーリーデータ伝送を行うと判断してもよい。この場合、ＵＥ１００は、ランダムアクセスプロシージャ中にアーリーデータ伝送によって上りリンクデータを送信し、ＲＲＣコネクティッドモードに遷移した後、残りの上りリンクデータをｅＮＢ２００に送信してもよい。
ランダムアクセスプロシージャが開始されると、ステップＳ４０３において、ＵＥ１００は、Ｍｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。アーリーデータ伝送を行う場合、ＵＥ１００は、ランダムアクセスプロシージャ中に、例えばＭｓｇ１（ランダムアクセスプリアンブル）又はＭｓｇ３（例えば、ＲＲＣ接続要求メッセージ）によって、上りリンクデータをｅＮＢ２００に送信する。
図１１のシーケンスでは、ｅＮＢ２００に送信するデータ（すなわち、上りリンクデータ）の量が許容データ量を上回っている場合に、ＵＥ１００が、アーリーデータ伝送によって上りリンクデータを送信し、ＲＲＣコネクティッドモードに遷移した後、残りの上りリンクデータをｅＮＢ２００に送信する一例を説明した。しかしながら、上りリンクデータの量が許容データ量を少しだけ上回っている場合でもＲＲＣコネクティッドモードに遷移しなければならないため、非効率であり、ＵＥ１００の消費電力の点などで好ましくない。
よって、ＵＥ１００は、ｅＮＢ２００に送信するデータの量が、ｅＮＢ２００からブロードキャスト情報（ＳＩＢ）によって通知された許容データ量よりも多い場合に、複数回のＭｓｇ３送信を行ってもよい。複数回のＭｓｇ３送信のそれぞれは、データ送信を伴う。例えば、ＵＥ１００は、１回目のＭｓｇ３送信において許容データ量まで上りリンクデータを送信し、２回目のＭｓｇ３送信において残りの上りリンクデータを送信する。これにより、アーリーデータ伝送によって上りリンクデータの送信を完了させることができるため、ＵＥ１００がＲＲＣコネクティッドモードに遷移する必要がなくなる。
図１２は、図１１のシーケンスの変更例を示す図である。ここでは、図１１のシーケンスとの相違点について主として説明する。
図１２に示すように、ステップＳ４１１において、ｅＮＢ２００は、アーリーデータ伝送によって送信することが許容されるデータの量（許容データ量）を示すブロードキャスト情報（ＳＩＢ）をＵＥ１００に送信する。ＵＥ１００は、ｅＮＢ２００から通知された許容データ量と、ＵＥ１００がｅＮＢ２００に送信するデータ（上りリンクデータ）の量とに基づいて、上りリンクのアーリーデータ伝送を行うか否かを判断する。ここでは、ＵＥ１００は、上りリンクデータの量が許容データ量よりも多いものの、複数回のＭｓｇ３送信によって上りリンクデータの送信を完了させることができると判断し、上りリンクのアーリーデータ伝送を行うと判断する。
ランダムアクセスプロシージャが開始されると、ステップＳ４１２において、ＵＥ１００は、Ｍｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。ＵＥ１００は、許容データ量よりも多いデータを送信する意図をランダムアクセスプリアンブルによってｅＮＢ２００に通知してもよい。例えば、動作パターン１と同様でＰＲＡＣＨリソースを分割し、許容データ量よりも多いデータを送信する意図を表すためのリソースがＰＲＡＣＨリソース中に定義される。ＵＥ１００は、許容データ量よりも多いデータを送信する意図を表すためのリソースを選択し、選択したリソースを用いてランダムアクセスプリアンブルを送信する。ｅＮＢ２００は、プリアンブル送信に用いられたリソースを認識し、許容データ量よりも多いデータを送信する意図をＵＥ１００が有することを把握する。
ステップＳ４１３において、ｅＮＢ２００は、Ｍｓｇ２（ランダムアクセス応答）をＵＥ１００に送信する。ｅＮＢ２００は、複数回のＭｓｇ３送信のための情報をＭｓｇ２によってＵＥ１００に送信してもよい。かかる情報は、セミパーシステントスケジューリング（ＳＰＳ）の設定情報及び／又は活性化指示であってもよい。例えば、ｅＮＢ２００は、上りリンクの送信周期を示すＳＰＳ周期を含む設定情報をＵＥ１００に送信する。また、ｅＮＢ２００は、ＵＥ１００に割り当てた上りリンクリソース（時間・周波数リソース）を示す上りリンクグラントをＭｓｇ２によって送信する。ＳＰＳの設定情報は、ステップＳ４１１においてｅＮＢ２００からＵＥ１００に通知されてもよい。或いは、ＳＰＳの設定情報は仕様において定義され、ＵＥ１００に予め設定されてもよい。
ステップＳ４１４において、ＵＥ１００は、上りリンクグラントで示される時間・周波数リソースを用いて、データを伴うＭｓｇ３をｅＮＢ２００に送信する。ここで、ＵＥ１００は、ｅＮＢ２００から通知された許容データ量まで上りリンクデータをｅＮＢ２００に送信してもよい。ＵＥ１００は、上りリンクデータをＲＲＣメッセージ（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）に含める。或いは、ＵＥ１００は、上りリンクデータをＲＲＣメッセージに含めずに、ＭＡＣレイヤにおいて上りリンクデータ（ＤＴＣＨ）とＲＲＣメッセージ（ＣＣＣＨ）とを多重化して送信する。
ステップＳ４１５において、ＵＥ１００は、ステップＳ４１４のタイミングからＳＰＳ周期分の時間が経過した際に、２回目のＭｓｇ３送信を行う。ＵＥ１００は、上りリンクグラントで示される時間・周波数リソースを用いて、データを伴うＭｓｇ３をｅＮＢ２００に送信する。ここで送信されるＭｓｇ３は、ＲＲＣメッセージを含まずに、上りリンクデータを含むものであってもよい。
ＵＥ１００は、上りリンクデータの送信が完了するまで、ＳＰＳ設定に従って、データを伴うＭｓｇ３をｅＮＢ２００に複数回送信する。ＵＥ１００は、最後のＭｓｇ３送信において、上りリンクデータの送信完了を示す情報（例えば、エンドマーカ）を送信してもよい。ＵＥ１００は、上りリンクデータの送信完了を示すために「ＢＳＲ＝０」を用いてもよい。「ＢＳＲ＝０」の詳細については変更例８において説明する。ｅＮＢ２００は、ＵＥ１００の最後のＭｓｇ３送信を認識する。
ステップＳ４１６において、ｅＮＢ２００は、Ｍｓｇ４をＵＥ１００に送信する。ｅＮＢ２００は、ＳＰＳ送信を終了させるためにＭｓｇ４を用いてもよい。例えば、ｅＮＢ２００は、ＳＰＳ送信の停止を示す１ビットのインジケータを、Ｍｓｇ４によってＵＥ１００に送信してもよい。ＵＥ１００は、かかるＭｓｇ４の受信に応じてＳＰＳ送信を停止（かつ、ＳＰＳ設定を破棄）する。そして、ＵＥ１００は、ＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了してもよい。
ｅＮＢ２００は、ＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了させることをＭｓｇ４によって明示的にＵＥ１００に通知してもよい。この場合、Ｍｓｇ４送信は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｊｅｃｔメッセージの送信を含んでもよい。
或いは、ｅＮＢ２００は、ＲＲＣコネクティッドモードに遷移させることをＭｓｇ４によって明示的にＵＥ１００に通知してもよい。この場合、Ｍｓｇ４送信は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅメッセージの送信を含んでもよい。
図１２のシーケンスでは、許容データ量よりも多いデータを送信する意図をランダムアクセスプリアンブルによってｅＮＢ２００に通知し、ｅＮＢ２００がＳＰＳ送信をＵＥ１００に指示する一例を説明した。
しかしながら、ｅＮＢ２００は、かかるランダムアクセスプリアンブルの受信に応じて、許容データ量よりも多い量のデータを送信可能とする上りリンクグラントをＭｓｇ２によってＵＥ１００に送信してもよい。ｅＮＢ２００は、ランダムアクセスプリアンブル受信時おける上りリンクリソースに余裕がある場合に、かかる上りリンクグラントをＵＥ１００に送信してもよい。ＵＥ１００は、許容データ量よりも多い量のデータを送信可能とする上りリンクグラントをｅＮＢ２００から受信した場合、１回のＭｓｇ３送信で上りリンクデータの送信が完了し得る。
或いは、ｅＮＢ２００は、かかるランダムアクセスプリアンブルの受信時に上りリンクリソースの余裕が無い場合に、ランダムアクセスプリアンブルに対してランダムアクセス応答（Ｍｓｇ２）を送信しないか、又はＭｓｇ４においてＲｅｊｅｃｔをＵＥ１００に通知してもよい。
（第１実施形態のまとめ）
第１実施形態に係る通信制御方法は、第１無線通信装置が、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送を行うか否かに関する情報を第２無線通信装置に送信するステップＡと、第２無線通信装置が情報を受信した後、第２無線通信装置が、当該受信した情報に基づいてアーリーデータ伝送を行うか否かを判断するステップＢとを備える。第１無線通信装置はＵＥ１００及びｅＮＢ２００のうち一方であり、第２無線通信装置はＵＥ１００及びｅＮＢ２００のうち他方である。ステップＡは、所定メッセージの送信タイミングよりも前に行われる。このような通信制御方法によれば、第２無線通信装置は、第１無線通信装置から受信した情報に基づいて、所定メッセージの送信タイミング（すなわち、アーリーデータ伝送に利用可能なタイミング）よりも前にアーリーデータ伝送を行うか否かを予め判断することができる。例えば、アーリーデータ伝送を行うか否かに関する認識を第１無線通信装置及び第２無線通信装置（ＵＥ１００及びｅＮＢ２００）で合わせることが可能となる。よって、アーリーデータ伝送を実現可能とすることができる。
（変更例１）
図１３は、第１実施形態の変更例１を示す図である。第１実施形態の変更例１において、ＵＥ１００は、アーリーデータ伝送によって送信するデータ（上りリンクデータ）の量をランダムアクセスプリアンブルによってｅＮＢ２００に通知する。上述した第１実施形態における動作と異なる点を主として説明する。
図１３に示すように、ステップＳ５０１において、ｅＮＢ２００は、データ量とＰＲＡＣＨリソース（例えば、プリアンブル系列）との対応関係を示す情報、及びアーリーデータ伝送の最低保証リソース量を示す情報のうち少なくともいずれかをＳＩＢによってブロードキャストする。ＳＩＢに代えて、ページングメッセージを用いてもよい。
ステップＳ５０２において、ＵＥ１００は、アーリーデータ伝送によって送信するデータ（上りリンクデータ）の量に基づいて、ランダムアクセスプリアンブルの送信に適用するリソースを選択してもよい。例えば、ＵＥ１００は、ｅＮＢ２００から通知された対応関係に基づいて、アーリーデータ伝送によって送信するデータ（上りリンクデータ）の量に対応するプリアンブル系列を選択する。
ＵＥ１００は、ｅＮＢ２００から通知された最低保証リソース量に基づいて、アーリーデータ伝送によって送信するデータ（上りリンクデータ）の量をｅＮＢ２００に通知するか否かを判断してもよい。例えば、ＵＥ１００は、最低保証リソース量が十分である場合には、アーリーデータ伝送によって送信するデータの量をｅＮＢ２００に通知しないと判断してもよい。ＵＥ１００は、最低保証リソース量が十分でない場合には、アーリーデータ伝送によって送信するデータの量をｅＮＢ２００に通知すると判断してもよい。
ステップＳ５０３において、ＵＥ１００は、Ｍｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。ＵＥ１００は、アーリーデータ伝送によって送信するデータの量に対応するＰＲＡＣＨリソース（例えば、プリアンブル系列）を適用してランダムアクセスプリアンブルを送信してもよい。或いは、ＵＥ１００は、アーリーデータ伝送によって送信するデータの量を示す情報をランダムアクセスプリアンブルに付加して、ランダムアクセスプリアンブルを送信してもよい。
ステップＳ５０４において、ｅＮＢ２００は、ランダムアクセスプリアンブルによって通知されたデータ量に基づいて、ＵＥ１００に割り当てる上りリンク無線リソース（例えば、ＰＵＳＣＨリソース）の量を判断する。当該上りリンク無線リソースは、Ｍｓｇ３の送信に用いられる無線リソースであってもよい。ｅＮＢ２００がＵＥ１００に割り当てる上りリンク無線リソースの情報は、Ｍｓｇ２によってＵＥ１００に通知される。
なお、ｅＮＢ２００からＵＥ１００に最低保証リソース量を通知する一例を説明した。しかしながら、このような通知に代えて、上りリンクデータの量をランダムアクセスプリアンブルによってＵＥ１００が通知すべきか否かをｅＮＢ２００がＵＥ１００に設定してもよい。当該設定は、ＳＩＢによって行われてもよい。
或いは、上りリンクのアーリーデータ伝送を行う意図の通知に、上りリンクデータ量の暗示的な通知の意味を持たせてもよい。ｅＮＢ２００は、上りリンクのアーリーデータ伝送を行う意図の通知を、ＵＬ ｇｒａｎｔサイズをｅＮＢに一任すること、又はデータ量は報知されているＵＬ ｇｒａｎｔサイズ（最大許容ＵＬ ｇｒａｎｔサイズであってもよい）と等しいこと、又はアーリーデータ伝送に係るデータ量は当該報知されているＵＬ ｇｒａｎｔサイズが必要であること、とみなしてもよい。
第１実施形態の動作パターン１において、ＵＥ１００のアーリーデータ伝送を行う意図を、ＰＲＡＣＨリソースを用いてｅＮＢ２００に通知する一例を説明した。かかる通知は、ＣＥレベルごとに行われる必要があり得る。また、本変更例は、上りリンクデータの量を、ＰＲＡＣＨリソースを用いてｅＮＢ２００に通知するものである。これらの動作を併用する場合、ＰＲＡＣＨリソースの分割数を増やす必要がある。また、ＰＲＡＣＨ用に確保される１つのリソースプールは有限であるため、ＰＲＡＣＨリソースの分割数を増やすと、分割された各リソースグループのサイズが小さくなる。その結果、各リソースグループ内でＵＥ１００がリソースをランダムに選択しても、複数のＵＥが同じリソースを選択する確率、すなわち、リソースの衝突が発生する確率が高くなる。
よって、ＵＥ１００は、ランダムアクセス応答の受信タイミングよりも前に、複数回のランダムアクセスプリアンブル送信を行ってもよい。複数回のランダムアクセスプリアンブル送信のそれぞれにおいて、ＵＥ１００は、ｅＮＢ２００に通知すべき情報に基づいて、ランダムアクセスプリアンブルの送信に適用するリソースを選択する。これにより、時間方向に複数のＰＲＡＣＨリソースプールを確保し、利用可能なＰＲＡＣＨリソースの量を増やすことができる。
図１４は、ＰＲＡＣＨリソース構成の一例を示す図である。図１４に示す例において、ＵＥ１００は、所定時間内で２回のプリアンブル送信を行う。所定時間は、１サブフレームの時間であってもよいし、１無線フレームの時間であってもよい。２回のプリアンブル送信に対応する２つのＰＲＡＣＨリソースプール＃１及び＃２が設けられている。ＰＲＡＣＨリソースプール＃１及びＰＲＡＣＨリソースプール＃２は同一周波数上に設けられてもよい。各ＰＲＡＣＨリソースプールは、周波数方向に分割され、複数のリソースグループに区分される。各ＰＲＡＣＨリソースプールは、時間方向に分割されてもよい。
ＵＥ１００は、１回目のプリアンブル送信において、ＰＲＡＣＨリソースプール＃１の中からリソースを選択する。ＰＲＡＣＨリソースプール＃１は３つのリソースグループに分割されており、３つのリソースグループはＣＥレベル＃１〜＃３に対応する。例えば、上りリンクのアーリーデータ伝送を行う意図を有するＵＥ１００は、自身のＣＥレベルに対応するリソースグループを特定し、特定したリソースグループの中からリソースをランダムに選択し、選択したリソースを用いてランダムアクセスプリアンブルを送信する。ｅＮＢ２００は、ＵＥ１００から受信したランダムアクセスプリアンブルに対応するリソースグループを特定し、ＵＥ１００のＣＥレベルを把握する。
ＵＥ１００は、２回目のプリアンブル送信において、ＰＲＡＣＨリソースプール＃２の中からリソースを選択する。ＰＲＡＣＨリソースプール＃２は４つのリソースグループに分割されており、４つのリソースグループは上りリンクのデータ量＃１〜＃４に対応する。データ量＃１〜＃４のそれぞれはデータ量の範囲を示すインデックスである。例えば、上りリンクのアーリーデータ伝送を行う意図を有するＵＥ１００は、自身の上りリンクデータ量に対応するリソースグループを特定し、特定したリソースグループの中からリソースをランダムに選択し、選択したリソースを用いてランダムアクセスプリアンブルを送信する。ｅＮＢ２００は、ＵＥ１００から受信したランダムアクセスプリアンブルに対応するリソースグループを特定し、ＵＥ１００の上りリンクデータ量を把握する。
ＵＥ１００は、１回目のプリアンブル送信と２回目のプリアンブル送信とで同一のプリアンブル系列（信号系列）を適用してもよい。この場合、ｅＮＢ２００は、１回目のプリアンブル送信を行ったＵＥと２回目のプリアンブル送信を行ったＵＥとをプリアンブル系列に基づいて対応付ける。或いは、１回目のプリアンブル送信と２回目のプリアンブル送信とで、所定のパターン（例えば、周波数ホッピングパターン）に従って、リソースグループの中からリソースを選択してもよい。この場合、ｅＮＢ２００は、１回目のプリアンブル送信を行ったＵＥと２回目のプリアンブル送信を行ったＵＥとをリソース選択パターンに基づいて対応付ける。
ｅＮＢ２００は、ＵＥ１００から２回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルを受信すると、１回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答をＵＥ１００に送信してもよい。すなわち、ｅＮＢ２００は、２回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答を送信しない。これにより、後方互換性を担保することができる。或いは、ｅＮＢ２００は、ＵＥ１００から２回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルを受信すると、２回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答をＵＥ１００に送信してもよい。すなわち、ｅＮＢ２００は、１回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答を送信しない。
ｅＮＢ２００は、各ＰＲＡＣＨリソースプールに関する情報をＳＩＢによってＵＥ１００に通知してもよい。各ＰＲＡＣＨリソースプールに関する情報は、各ＰＲＡＣＨリソースプール及び各リソースグループに対応付けられた情報の種別、ＰＲＡＣＨリソースプールを構成するリソースの時間・周波数の範囲を示す情報、ＰＲＡＣＨリソースプール内の各リソースグループの時間・周波数の範囲を示す情報のうち少なくとも１つを含む。ｅＮＢ２００は、かかる情報を、ＰＲＡＣＨリソースプールごとに個別の情報要素（例えば、ＲＡＣＨ−ｃｏｎｆｉｇ）としてＵＥ１００に通知してもよい。各情報要素は、対応する情報の種別（ＣＥレベル又は上りリンクデータ量）を含んでもよいし、対応する情報の種別を情報要素の名前で表してもよい。
なお、図１４の例では、ＣＥレベル及び上りリンクデータ量をプリアンブル送信によってｅＮＢ２００に通知する一例を説明したが、ＣＥレベル及び上りリンクデータ量以外の情報（例えば、ＵＥカテゴリ、後述する変更例１４のタイマ値）をプリアンブル送信によってｅＮＢ２００に通知してもよい。また、連続的に行われるプリアンブル送信の回数は、２回に限らず、３回以上であってもよい。例えば、ＵＥ１００は、１回目のランダムアクセスプリアンブル送信によってＣＥレベルをｅＮＢ２００に通知し、２回目のランダムアクセスプリアンブル送信によってアーリーデータ伝送を行う意図をｅＮＢ２００に通知し、３回目のランダムアクセスプリアンブル送信によって上りリンクデータ量（すなわち、ＵＥ１００が希望するアップリンクグラントの量）をｅＮＢ２００に通知してもよい。或いは、１回目のランダムアクセスプリアンブル送信のためのＰＲＡＣＨリソースプール＃１と２回目のランダムアクセスプリアンブル送信のためのＰＲＡＣＨリソースプール＃２とを分け、かつ、ＰＲＡＣＨリソースプール＃２を２つのリソースグループに分ける。そして、アーリーデータ伝送を行う意図の通知用としてＰＲＡＣＨリソースプール＃２の一方のリソースグループを確保し、上りリンクデータ量の通知用としてＰＲＡＣＨリソースプール＃２の他方のリソースグループを確保してもよい。かかる場合、ｅＮＢ２００は、上りリンクデータ量の通知用のリソースグループ内のリソースを用いて上りリンクデータ量をｅＮＢ２００に通知したＵＥ１００を、アーリーデータ伝送を行う意図を有するＵＥであるとみなしてもよい。また、アーリーデータ伝送を行う意図の通知は、ＵＬ ｇｒａｎｔサイズをｅＮＢに一任すること、又はデータ量は報知されているＵＬ ｇｒａｎｔサイズ（最大許容ＵＬ ｇｒａｎｔサイズであってもよい）と等しいこと、又はアーリーデータ伝送に係るデータ量は当該報知されているＵＬ ｇｒａｎｔサイズが必要であること、とみなしてもよい。
図１４の例では、時間方向に複数のＰＲＡＣＨリソースプールを設ける一例を説明したが、周波数方向に複数のＰＲＡＣＨリソースプールを設けてもよい。
また、１回目のプリアンブル送信と２回目のプリアンブル送信とで同一のプリアンブル系列（信号系列）を適用することにより、１回目のプリアンブル送信と２回目のプリアンブル送信との紐付けを行う一例を説明した。しかしながら、プリアンブル系列により紐付けを行う場合に限らず、時間・周波数リソースにより紐付けを行なってもよい。例えば、図１４に示すように、１回目のランダムアクセスプリアンブル送信のためのＰＲＡＣＨリソースプール＃１と２回目のランダムアクセスプリアンブル送信のためのＰＲＡＣＨリソースプール＃２とのそれぞれに複数のリソースグループが含まれており、各リソースグループが長方形状に定義されると仮定する。かかる場合、長方形の４つの頂点のうち特定の１つの点を基準点と定める。ＵＥ１００は、１回目のランダムアクセスプリアンブル送信用のリソースグループにおいて、基準点を基準として所定の時間・周波数位置のリソースを選択する。そして、ＵＥ１００は、２回目のランダムアクセスプリアンブル送信用のリソースグループにおいて、基準点を基準として、１回目と同じ時間・周波数位置のリソースを選択する。このように、１回目及び２回目のランダムアクセスプリアンブル送信のそれぞれにおいて、時間・周波数リソースの相対位置を揃えることにより、ｅＮＢ２００は、１回目のプリアンブル送信と２回目のプリアンブル送信との紐付けを行うことが可能である。
さらに、図１４の例では、ＰＲＡＣＨリソースプールが時間・周波数リソースにより構成される一例を説明したが、ＰＲＡＣＨリソースプールがプリアンブル系列（信号系列）リソースにより構成されてもよい。
次に、複数回のランダムアクセスプリアンブル送信のうちの少なくとも１回においてｅＮＢ２００がプリアンブル受信に失敗する場合について説明する。ここでは、ＵＥ１００が、１回目のランダムアクセスプリアンブル送信によってＣＥレベルをｅＮＢ２００に通知し、２回目のランダムアクセスプリアンブル送信によってアーリーデータ伝送を行う意図（特に、上りリンクのアーリーデータ伝送を行う意図）をｅＮＢ２００に通知すると仮定する。表１に示すように、１回目のランダムアクセスプリアンブル送信（Ｆｉｒｓｔ ＰＲＡＣＨ）及び２回目のランダムアクセスプリアンブル送信（Ｓｅｃｏｎｄ ＰＲＡＣＨ）の少なくとも一方が送信失敗するケースとして、ケース１〜３がある。
Figure 0006964164
ケース１は、１回目のランダムアクセスプリアンブル送信及び２回目のランダムアクセスプリアンブル送信の両方が成功するケースである。ケース１において、ｅＮＢ２００は、ＵＥ１００のアーリーデータ伝送の意図を把握し、通常の上りリンクグラント（すなわち、アーリーデータ伝送により送信されるデータの量を加味していない上りリンクグラント）よりも多い量の上りリンクリソースをＵＥ１００に割り当ててＭｓｇ２で通知する。ＵＥ１００は、アーリーデータ伝送によってデータをＭｓｇ３で送信する。
ケース２は、１回目のランダムアクセスプリアンブル送信が成功し、２回目のランダムアクセスプリアンブル送信が失敗するケースである。ケース２において、ｅＮＢ２００は、通常のランダムアクセスプリアンブルを受信したと認識し、通常の上りリンクグラントをＭｓｇ２でＵＥ１００に通知する。ＵＥ１００は、データ送信に用いることが可能な上りリンクリソースが割り当てられなかったと判断し、データを含まないＭｓｇ３をｅＮＢ２００に送信する。
ケース３は、１回目のランダムアクセスプリアンブル送信が失敗し、２回目のランダムアクセスプリアンブル送信が成功するケースである。ケース３において、ｅＮＢ２００は、１回目のランダムアクセスプリアンブルを受信していないことから、２回目のランダムアクセスプリアンブルを受信しても、対応するＭｓｇ２を送信しない。ＵＥ１００は、Ｍｓｇ２をｅＮＢ２００から受信しないため、ランダムアクセスプロシージャを最初からやり直す。
ケース３において、ｅＮＢ２００は、２回目のランダムアクセスプリアンブルに基づいて、このランダムアクセスプリアンブルを送信したＵＥ１００を特定し、特定したＵＥ１００に対してＭｓｇ２を送信してもよい。例えば、ｅＮＢ２００は、２回目のランダムアクセスプリアンブルに適用されているプリアンブル系列及び／又はホッピングパターンに基づいてＵＥ１００を特定可能である。但し、ｅＮＢ２００は、１回目のランダムアクセスプリアンブルを受信していないため、このＵＥ１００のＣＥレベルを１回目のランダムアクセスプリアンブルに基づいて把握することができない。かかる場合、ｅＮＢ２００は、ＵＥ１００が通常のカバレッジにいる（すなわち、拡張されたカバレッジにいない）とみなして、Ｍｓｇ２送信の際に繰り返し送信を行わない。或いは、ｅＮＢ２００は、２回目のランダムアクセスプリアンブルに基づいてＣＥレベルを推定してもよい。具体的には、２回目のプリアンブル送信の際に繰り返し送信が適用される場合、ｅＮＢ２００は、受信に成功したプリアンブル送信の繰り返し回数をカウントし、カウント値からＣＥレベルを推定することが可能である。ｅＮＢ２００は、推定したＣＥレベルに基づいて、Ｍｓｇ２送信の際に繰り返し送信を行う。
なお、ランダムアクセスプリアンブルの複数回送信を行うか否かにかかわらず、上りリンクのアーリーデータ伝送を行う意図をプリアンブル送信によってｅＮＢ２００に通知したＵＥ１００は、データ送信に用いることが可能な上りリンクリソースが割り当てられなかった場合に、通常のＭｓｇ３（データを含まないＭｓｇ３）をｅＮＢ２００に送信しなければならないという制約があってもよい。
或いは、上りリンクのアーリーデータ伝送を行う意図をプリアンブル送信によってｅＮＢ２００に通知したＵＥ１００は、データ送信に用いることが可能な上りリンクリソースが割り当てられなかった場合に、ランダムアクセスプロシージャをやり直してもよい。ランダムアクセスプロシージャをやり直す場合、ＵＥ１００は、プリアンブル送信を改めて行い、上りリンクのアーリーデータ伝送を行う意図をプリアンブル送信によってｅＮＢ２００に改めて通知する。ＵＥ１００は、かかるランダムアクセスプロシージャのやり直しを、ｅＮＢ２００から許可されている場合に限り実施してもよい。すなわち、ＵＥ１００は、ｅＮＢ２００から許可されていない場合には、ランダムアクセスプロシージャのやり直しを行うことが禁止される。かかる許可を示す情報は、ｅＮＢ２００からＳＩＢによってブロードキャストされてもよいし、ＭＭＥからＵＥ１００に設定されてもよい。
（変更例２）
図１５は、第１実施形態の変更例２を示す図である。上述した第１実施形態における動作と異なる点を主として説明する。
図１５に示すように、ステップＳ６０１において、ＵＥ１００は、アーリーデータ伝送によってＭｓｇ１（ランダムアクセスプリアンブル）と共にデータをｅＮＢ２００に送信する。例えば、ＵＥ１００は、ランダムアクセスプリアンブルに続く新たなデータチャネルを用いてデータを送信する。但し、ランダムアクセスプリアンブルと共に送信されるデータは少量であってもよい。ＵＥ１００は、ステップＳ６０１で送信したデータを保持する。
ステップＳ６０２において、ｅＮＢ２００は、ランダムアクセスプリアンブルと共に送信されたデータを受信すると、当該受信したデータの少なくとも一部をＭｓｇ２（ランダムアクセス応答）によってＵＥ１００に返送する。ｅＮＢ２００は、当該受信したデータの全部をＵＥ１００に返送してもよい。
ステップＳ６０３において、ＵＥ１００は、ステップＳ６０１で送信したデータと、ｅＮＢ２００から返送されたデータとを比較する。ＵＥ１００は、比較の結果、一致すれば送信成功（ＡＣＫ）、不一致であれば送信失敗（ＮＡＣＫ）と判断する。送信失敗（ＮＡＣＫ）と判断した場合、ＵＥ１００は、次回のアップリンク送信時（ＰＵＳＣＨ送信時）に、送信に失敗したデータの再送を行う。また、ＵＥ１００は、判断結果（ＡＣＫ又はＮＡＣＫ）をＭｓｇ３によってｅＮＢ２００に通知してもよい。ＵＥ１００は、判断結果がＮＡＣＫである場合に限り、ｅＮＢ２００へのＮＡＣＫ通知を行ってもよい。
（変更例３）
第１実施形態の変更例３に係るＵＥ１００は、ＲＲＣアイドルモードにおいて、アーリーデータ伝送によってデータをｅＮＢ２００に送信する。その後、ＲＲＣアイドルモードのＵＥ１００は、ＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌ ＨｙｂｒｉｄＡＲＱ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ）を監視することによって、アーリーデータ伝送によって送信したデータに対応するＡＣＫ又はＮＡＣＫをｅＮＢ２００から受信する。
一般的に、ＵＥ１００は、ＲＲＣコネクティッドモードにおいてのみＰＨＩＣＨを監視する。しかしながら、上りリンクのアーリーデータ伝送に対するＡＣＫ／ＮＡＣＫをｅＮＢ２００がＰＨＩＣＨで通知することが想定される。よって、ＲＲＣアイドルモードのＵＥ１００であってもＰＨＩＣＨを監視することによって、アーリーデータ伝送が成功したか否かを把握することが可能となる。
（変更例４）
第１実施形態の変更例４において、ＵＥ１００又はｅＮＢ２００は、アーリーデータ伝送によってデータ送信が完了したか否かを判断する。アーリーデータ伝送によってデータ送信が完了したと判断された場合、ＵＥ１００は、ＲＲＣアイドルモードからＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する。これによって、効率的なデータ伝送が可能となる。
例えば、上りリンクのアーリーデータ伝送の場合、ＵＥ１００は、Ｍｓｇ４（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージ）をｅＮＢ２００から受信すると、失敗又は拒否を示すメッセージ（ｆａｉｌｕｒｅメッセージ）をｅＮＢ２００に送信することによって、ランダムアクセスプロシージャを終了させることができる。失敗又は拒否を示すメッセージには、失敗又は拒否の理由を示す情報（例えば、ｅａｒｌｙ ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｍｐｌｅｔｅｄ）を含めてもよい。
下りリンクのアーリーデータ伝送の場合、ｅＮＢ２００は、Ｍｓｇ４（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージ）によって、ランダムアクセスプロシージャを終了させる（すなわち、ｃｏｍｐｌｅｔｅする必要が無い）旨をＵＥ１００に通知し、ランダムアクセスプロシージャを終了させることができる。或いは、ｅＮＢ２００は、Ｍｓｇ４として、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージを送信してもよい。
下りリンクのアーリーデータ伝送の場合、ｅＮＢ２００は、ランダムアクセスプロシージャの前に、特殊なページングメッセージをＵＥ１００に送信することによって、小パケット（少量データ）の下りリンク送信である旨を通知してもよい。当該特殊なページングメッセージは、ＭＭＥ３００によって生成され、ｅＮＢ２００を介してＭＭＥ３００からＵＥ１００に送信されてもよい。当該特殊なページングメッセージは、ＵＥ１００の識別子と小パケット送信を示す情報との組み合わせを含んでもよい。ＵＥ１００は、当該特殊なページングメッセージを受信した場合、アーリーデータ伝送によってデータ送信が完了した後にＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する。
（変更例５）
第１実施形態の変更例５において、ｅＮＢ２００は、ランダムアクセスプリアンブルに適用すべきプリアンブル系列を示すプリアンブルインデックスをページングメッセージによってＵＥ１００に送信する。例えば、当該ページングメッセージは、ＵＥ１００の識別子とプリアンブルインデックスとの組み合わせを含んでもよい。
この動作に先立ち、ＭＭＥ３００は、ｅＮＢ２００にＳ１インターフェイスによって送信するＳ１ページングメッセージ内で、ＵＥの識別子（ＵＥ ＩＤ）と共に、”非競合ベースのランダムアクセスプロシージャ適用”の通知を行ってもよい。ＭＭＥ３００は、Ｓ１ページングメッセージ内で、ＵＥ ＩＤと共に、”アーリーデータ伝送適用”の通知を行ってもよい。また、予めｅＮＢ２００がＭＭＥ３００に対して（複数の）プリアンブルインデックスを通知しておき、ＭＭＥ３００は、このインデックスの中から、（必要に応じて）選んだものを、Ｓ１メッセージでｅＮＢ２００に通知してもよい。
ＵＥ１００（例えば、ＲＲＣアイドルモードのＵＥ）は、ｅＮＢ２００からページングメッセージを受信し、プリアンブルインデックスが示すプリアンブル系列を適用したランダムアクセスプリアンブルをｅＮＢ２００に送信する。ｅＮＢ２００は、ランダムアクセスプリアンブルに適用されたプリアンブル系列に基づいて、ランダムアクセスプリアンブルの送信元のＵＥ１００を識別することができる。
これによって、本来は競合ベースのランダムアクセスプロシージャが行われる状況下（例えば、初期接続時）において、非競合ベースのランダムアクセスプロシージャを行うことができる。従って、競合ベースのランダムアクセスプロシージャに用いられる競合解決処理（ｃｏｎｔｅｎｔｉｏｎ ｒｅｓｏｌｕｔｉｏｎ）を不要とすることができる。
（変更例６）
第１実施形態の変更例６において、ＵＥ１００又はｅＮＢ２００は、アーリーデータ伝送によってデータを送信する。アーリーデータ伝送によって送信されるデータには、当該データに対応するＡＣＫ又はＮＡＣＫの送信が適用されず、かつ、当該データを所定回数だけ繰り返して送信する繰り返し送信が適用される。これによって、ＡＣＫ又はＮＡＣＫを用いない場合でも、データ伝送の信頼性を向上させることができる。
ＵＥ１００又はｅＮＢ２００は、ＵＥ１００が強化カバレッジに居ない場合（すなわち、通常のカバレッジに居る場合）であっても、アーリーデータ伝送によって送信されるデータには繰り返し送信を適用する。一般的に、ＵＥ１００が通常のカバレッジに居る場合には、繰り返し送信は適用されない。一方で、第１実施形態の変更例６においては、ＵＥ１００が強化カバレッジに居るか否かにかかわらず、アーリーデータ伝送によって送信されるデータにはＡＣＫ又はＮＡＣＫの送信が適用されず、かつ、当該データを所定回数だけ繰り返して送信する繰り返し送信が適用される。
例えば、上りリンクのアーリーデータ伝送の場合、ｅＮＢ２００は、アーリーデータ伝送によって上りリンクデータを受信してもＡＣＫ／ＮＡＣＫをＵＥ１００に送信しない。但し、ＵＥ１００は、予め仕様で定められた回数又はｅＮＢ２００から設定された回数だけ下位レイヤにおいて同一信号の繰り返し送信を行う。
下りリンクのアーリーデータ伝送の場合、ＵＥ１００は、アーリーデータ伝送によって下りリンクデータを受信してもＡＣＫ／ＮＡＣＫをｅＮＢ２００に送信しない。但し、ｅＮＢ２００は、予め仕様で定められた回数又はＵＥ１００に通知した回数だけ下位レイヤにおいて同一信号の繰り返し送信を行う。
（変更例７）
第１実施形態の変更例７〜１０においては、アーリーデータ伝送においてデータ送信に利用する所定メッセージがＭｓｇ３であるシナリオを想定する。すなわち、第１実施形態の変更例７〜１０におけるアーリーデータ伝送は、上りリンクにおけるアーリーデータ伝送である。なお、Ｍｓｇ３は、上述したように、ＵＥ１００からｅＮＢ２００に対して送信されるメッセージであって、ＵＥ１００がアイドルモードからコネクティッドモードに遷移することを要求するために用いるメッセージである。アーリーデータ伝送において、Ｍｓｇ３によって送信するデータ（パケット）は、Ｍｓｇ３に内包されていてもよい。例えば、ＵＥ１００は、データＰＤＵを含むＲＲＣ接続要求メッセージを送信する。或いは、Ｍｓｇ３によって送信するデータ（パケット）は、Ｍｓｇ３とは異なるメッセージとして、Ｍｓｇ３と組み合わせて（連続的に）送信されてもよい。例えば、ＵＥ１００は、データ（パケット）を含むメッセージとＭｓｇ３とを含む１つのＭＡＣ ＰＤＵを送信してもよい。ＵＥ１００は、データ（パケット）を含むメッセージとＭｓｇ３とを別々のＭＡＣ ＰＤＵに含めて、当該別々のＭＡＣ ＰＤＵを同時又は連続的に送信してもよい。
以下の変更例７〜１１の説明において、Ｍｓｇ３がＲＲＣ接続要求メッセージである一例を説明するが、Ｍｓｇ３はＲＲＣ接続復旧要求メッセージであってよい。
変更例７において、上述したステップＡ（すなわち、アーリーデータ伝送を行うか否かに関する情報を送信するステップ）は、ｅＮＢ２００からＵＥ１００に対して送信されるランダムアクセス応答（Ｍｓｇ２）を構成するＭＡＣ ＲＡＲ（ＭＡＣ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｒｅｓｐｏｎｓｅ）によって、上りリンクにおけるアーリーデータ伝送の実行を指示するステップを含む。
一般的なランダムアクセス応答はＭＡＣ ＲＡＲとして構成されており、ランダムアクセスプリアンブルに基づいてｅＮＢ２００が決定したタイミングアドバンス（Ｔｉｍｉｎｇ Ａｄｖａｎｃｅ Ｃｏｍｍａｎｄ）と、ＲＲＣ接続要求メッセージの送信用にｅＮＢ２００がＵＥ１００に割り当てた上りリンクリソースに関する割当情報（ＵＬ ｇｒａｎｔ）と、ｅＮＢ２００がＵＥ１００に割り当てた一時的なＣ−ＲＮＴＩ（Ｔｅｍｐｏｒａｒｙ Ｃ−ＲＮＴＩ）とを有する。
変更例７において、ＵＥ１００からランダムアクセスプリアンブルを受信したｅＮＢ２００は、上述した第１実施形態又はその変更例に係る方法によって、上りリンクにおけるアーリーデータ伝送（すなわち、ＲＲＣ接続要求メッセージを用いたデータ伝送）をＵＥ１００に実行させるか否かを判断する。アーリーデータ伝送をＵＥ１００に実行させると判断した場合、ｅＮＢ２００は、ランダムアクセス応答を構成するＭＡＣ ＲＡＲによって、上りリンクにおけるアーリーデータ伝送の実行を指示する。例えば、ＭＡＣ ＲＡＲに新たなフィールドを設ける場合、ｅＮＢ２００は、当該新たなフィールドに、ＲＲＣ接続要求メッセージを用いたデータ伝送を実行させることを示すフラグ（許可ビット）を含める。ＲＲＣ接続要求メッセージを用いたデータ伝送を実行させない場合、ｅＮＢ２００は、当該新たなフィールドに、ＲＲＣ接続要求メッセージを用いたデータ伝送を実行させることを示すフラグを含めない（もしくは、当該フラグをゼロの値として含める）。
もしくは、ｅＮＢ２００は、アーリーデータ伝送をＵＥ１００に実行させるか否かを、ランダムアクセス応答を構成するＭＡＣ ＲＡＲとは異なるＭＡＣ ＣＥによってＵＥ１００に通知してもよい。当該異なるＭＡＣ ＣＥは、例えば「Ｅａｒｌｙ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ ＲＡＲ」と称されてもよい。この場合、ｅＮＢ２００は、上りリンク及び／又は下りリンクにおけるアーリーデータ伝送を示す識別子をＥａｒｌｙ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ ＲＡＲに含めてもよい。
なお、変更例１において説明したように、ＵＥ１００は、アーリーデータ伝送によって送信するデータ（上りリンクデータ）の量をランダムアクセスプリアンブルによってｅＮＢ２００に通知し得る。ｅＮＢ２００は、ＵＥ１００から通知された上りリンクデータの量に基づいて、ＵＥ１００に割り当てる上りリンク無線リソースの量を決定し、決定した上りリンク無線リソースを示す情報をランダムアクセス応答（ＭＡＣ ＲＡＲ）中のＵＬ ｇｒａｎｔに含める。
（変更例８）
上述した変更例４において、アーリーデータ伝送によってデータ送信が完了したと判断された場合、ＵＥ１００が、ＲＲＣアイドルモードからＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する動作を説明した。変更例８は、下りリンクにおけるアーリーデータ伝送の場合の動作例に関する。
変更例８において、ＵＥ１００は、ＲＲＣ接続要求メッセージによってデータ送信が完了する場合に、コネクティッドモードに遷移する必要がない（すなわち、ＲＲＣ接続を確立する必要がない）ことを示すフラグを含むＲＲＣ接続要求メッセージをＵＥ１００からｅＮＢ２００に送信する。当該フラグは、１ビットで構成される。
例えば、ＵＥ１００は、ｅＮＢ２００に送信すべきデータの量が、ＲＲＣ接続要求メッセージによって運搬可能な最大データ量以下である場合に、ＲＲＣ接続要求メッセージによってデータ送信が完了すると判断する。この場合、ＵＥ１００は、ＲＲＣ接続要求メッセージによってデータを送信する際に、コネクティッドモードに遷移する必要がないことを示すフラグをＲＲＣ接続要求メッセージに含める。その結果、ＲＲＣ接続要求メッセージには、アーリーデータ伝送によって送信されるデータと、コネクティッドモードに遷移する必要がないことを示すフラグとが含まれる。一方で、ｅＮＢ２００に送信すべきデータの量が、ＲＲＣ接続要求メッセージによって運搬可能な最大データ量を超える場合、ＵＥ１００は、ＲＲＣ接続要求メッセージによってデータ送信が完了しないと判断する。この場合、ＵＥ１００は、ＲＲＣ接続要求メッセージによってデータを送信する際に、コネクティッドモードに遷移する必要がないことを示すフラグをＲＲＣ接続要求メッセージに含めない（もしくは、当該フラグをゼロの値として含める）。
ｅＮＢ２００は、データ及びフラグを含むＲＲＣ接続要求メッセージをＵＥ１００から受信する。ここで、ｅＮＢ２００において、無線状態又はＲＲＣ接続要求メッセージの衝突等に起因して、ＲＲＣ接続要求メッセージに含まれるデータの受信エラー（データの復号失敗）が発生することがある。
ｅＮＢ２００がＲＲＣ接続要求メッセージに含まれるデータを正常に受信した場合、ｅＮＢ２００は、ＲＲＣ接続要求メッセージに含まれるフラグがＲＲＣ接続を確立する必要がないことを示していることから、ＵＥ１００に対するＭｓｇ４の送信を行わないか、又はＵＥ１００に対してＲＲＣ接続解放メッセージを送信する。一方で、ｅＮＢ２００においてＲＲＣ接続要求メッセージに含まれるデータの受信エラーが発生した場合、ｅＮＢ２００は、例えばＵＥ１００に対してＭｓｇ４を送信することによって、ＲＲＣ接続を確立するためにランダムアクセスプロシージャを継続する。ＵＥ１００は、ＲＲＣ接続要求メッセージに対するｅＮＢ２００からの応答の状況に基づいて、ＲＲＣ接続要求メッセージによるデータの送信が成功したか否かを判断する。
ここで、ｅＮＢ２００においてＲＲＣ接続要求メッセージに含まれるデータの受信エラーが発生した場合におけるＵＥ１００の動作について説明する。ＵＥ１００は、ＲＲＣ接続要求メッセージによるデータの送信が失敗したと判断した場合、次の０）〜４）のいずれかの動作を実行する。
０）ランダムアクセスプロシージャをランダムアクセスプリアンブル（Ｍｓｇ１）送信から再開する。具体的には、プリアンブル系列の選択（ｐｒｅａｍｂｌｅ ｓｅｌｅｃｔｉｏｎ）から再開してもよい。そして、Ｍｓｇ３において当該データを再送してもよい。
１）当該データを伴うＲＲＣ接続要求メッセージを再送する。この場合、ＵＥ１００は、コネクティッドモードに遷移する必要がないことを示すフラグをＲＲＣ接続要求メッセージに含める。
２）当該データを伴わないＲＲＣ接続要求メッセージを再送する。この場合、ＵＥ１００は、コネクティッドモードに遷移する必要がないことを示すフラグをＲＲＣ接続要求メッセージに含めない。ＵＥ１００は、コネクティッドモードに遷移した後に当該データを送信（再送）する。
３）ＵＥ１００からｅＮＢ２００に対して送信されるメッセージであって、コネクティッドモードへの遷移完了を通知するために用いるＭｓｇ５によって当該データを送信する。この場合、ＵＥ１００は、コネクティッドモードに遷移してもよい。或いは、ＵＥ１００は、Ｍｓｇ５の送信に代えてデータをｅＮＢ２００に送信してもよい。ｅＮＢ２００は、Ｍｓｇ６によって、ＵＥ１００からのデータの受信に成功したか否かをＵＥ１００に通知してもよい。
４）コネクティッドモードに遷移する。
変更例８において、ＵＥ１００は、コネクティッドモードに遷移する必要がない（すなわち、ＲＲＣ接続を確立する必要がない）ことを示すフラグを含むＲＲＣ接続要求メッセージに代えて、コネクティッドモードに遷移する必要がないことを示す情報を伴うＲＲＣ接続要求メッセージを送信してもよい。ＵＥ１００は、コネクティッドモードに遷移する必要がないことを示す情報を含むＭＡＣ ＣＥを送信してもよい。例えば、ＭＡＣ ＣＥは、バッファ状態報告（ＢＳＲ）である。ＢＳＲは、ＵＥ１００が上りリンク送信に利用可能なデータの量（すなわち、上りリンクの送信待ちデータの量）を示すＭＡＣ ＣＥである。
図１６は、ＭＡＣレイヤによって生成されるＭＡＣ ＰＤＵ（ＭＡＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）の一例を示す図である。図１６に示すように、ＭＡＣ ＰＤＵは、ＭＡＣレイヤよりも上位のレイヤからＭＡＣレイヤに提供されるＭＡＣ ＳＤＵ（ＭＡＣ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）を含む。ＲＲＣ接続要求メッセージ及びＲＲＣ接続復旧要求メッセージ等のＲＲＣメッセージは、ＲＲＣレイヤによって生成され、ＭＡＣ ＳＤＵとしてＭＡＣレイヤに提供される。アーリーデータ伝送によって送信される上りリンクデータは、ＰＤＣＰレイヤ及びＲＬＣレイヤを通じて、ＭＡＣ ＳＤＵとしてＭＡＣレイヤに提供される。上りリンクデータは、ＰＤＣＰレイヤ及びＲＬＣレイヤを介さずに、ＭＡＣ ＳＤＵとしてＭＡＣレイヤに提供されてもよい。
ＭＡＣ ＰＤＵは、ＭＡＣ ＳＤＵに加えて、ＭＡＣレイヤによって生成されるＭＡＣヘッダ及びＭＡＣ ＣＥ（ＭＡＣ Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）を含む。ＭＡＣ ＰＤＵは、ＭＡＣ ＰＤＵの空き領域を埋めるためのパディング（Ｐａｄｄｉｎｇ）をさらに含むことがある。図１６において、ＭＡＣ ＰＤＵが２つのＭＡＣ ＣＥを含む一例を例示しているが、ＭＡＣ ＣＥは３つ以上又は１つであってもよい。ＢＳＲを構成するＭＡＣ ＣＥは、上りリンク送信に利用可能なデータの量を示す値（インデックス）を格納するバッファサイズフィールドを含む。ＵＥ１００は、コネクティッドモードに遷移する必要がないことを示す情報として、上りリンク送信に利用可能なデータの量がゼロであることを示す値をバッファサイズフィールドに含める。かかるＢＳＲは、ＲＡＩ（Ｒｅｌｅａｓｅ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）と称されてもよい。
アーリーデータ伝送において、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータ送信が完了する場合、ＵＥ１００は、上りリンクデータ及びＲＲＣ接続要求メッセージを含む１又は複数のＭＡＣ ＳＤＵと、コネクティッドモードに遷移する必要がないことを示す情報（ＢＳＲ＝０）を含むＭＡＣ ＣＥとを、１つのＭＡＣ ＰＤＵによって纏めてｅＮＢ２００に送信してもよい。或いは、ＵＥ１００は、上りリンクデータ及びＲＲＣ接続要求メッセージを含む１又は複数のＭＡＣ ＳＤＵと、コネクティッドモードに遷移する必要がないことを示す情報（ＢＳＲ＝０）を含むＭＡＣ ＣＥとを、別々のＭＡＣ ＰＤＵによって連続的にｅＮＢ２００に送信してもよい。ｅＮＢ２００は、ＲＲＣ接続要求メッセージに伴う「ＢＳＲ＝０」に基づいて、ＵＥ１００をコネクティッドモードに遷移させる必要がないと判断する。
（変更例９）
第１実施形態の変更例９〜１２は、アーリーデータ伝送においてデータ送信に利用する所定メッセージがＭｓｇ４であるシナリオを想定する。すなわち、第１実施形態の変更例９〜１１におけるアーリーデータ伝送は、下りリンクにおけるアーリーデータ伝送である。なお、Ｍｓｇ４は、上述したように、ｅＮＢ２００からＵＥ１００に対して送信されるメッセージであって、ＵＥ１００をアイドルモードからコネクティッドモードに遷移させるために用いるメッセージである。
以下の変更例９〜１２の説明において、Ｍｓｇ４がＲＲＣ接続確立メッセージである一例を説明するが、Ｍｓｇ４はＲＲＣ接続復旧メッセージであってよい。
変更例９において、アイドルモードのＵＥ１００は、ランダムアクセスプロシージャを開始する。ＵＥ１００がアイドルモードである間は、ＵＥ１００のコンテキスト情報（ＵＥ１００の能力に関する情報を含む）をｅＮＢ２００が保持していない場合がある。この場合、ｅＮＢ２００は、下りリンクにおけるアーリーデータ伝送を取り扱う能力をＵＥ１００が有するか否かを把握しておらず、下りリンクにおけるアーリーデータ伝送を行うか否かの判断が難しい。
そこで、変更例９において、ＵＥ１００は、下りリンクにおけるアーリーデータ伝送に対応（サポート）しているか否かを、ランダムアクセスプリアンブル（Ｍｓｇ１）及びＲＲＣ接続要求メッセージのいずれかによってｅＮＢ２００に通知する。例えば、下りリンクにおけるアーリーデータ伝送を行う能力を有するＵＥ１００は、下りリンクにおけるアーリーデータ伝送を行う能力を有することを示す情報（識別子）を、ランダムアクセスプリアンブル（Ｍｓｇ１）及びＲＲＣ接続要求メッセージのいずれかによってｅＮＢ２００に送信する。ランダムアクセスプリアンブル（Ｍｓｇ１）を用いるケースでは、上述した第１実施形態の動作パターン１の方法を利用することができる。ｅＮＢ２００は、ＵＥ１００からの通知に基づいて、下りリンクにおけるアーリーデータ伝送にＵＥ１００が対応しているか否かを判断する。ここで、「ＵＥ１００が下りリンクにおけるアーリーデータ伝送に対応（サポート）している」、「ＵＥ１００が下りリンクにおけるアーリーデータ伝送を行う能力を有する」とは、下りリンクにおけるアーリーデータ伝送によってｅＮＢ２００から送信されるデータをＵＥ１００が「受信」する能力（機能）を有していることを意味してもよい。
なお、ＵＥ１００は、下りリンクにおけるアーリーデータ伝送を行う旨のページングメッセージ（上述した第１実施形態に係る動作パターン３参照）をｅＮＢ２００から受信している場合に限り、下りリンクにおけるアーリーデータ伝送の能力をランダムアクセスプリアンブルによってｅＮＢ２００に通知してもよい。当該ページングメッセージは、下りリンクにおけるアーリーデータ伝送を行うことを明示的に示す情報を含んでもよい。当該ページングメッセージは、下りリンクにおけるアーリーデータ伝送を行うことを暗示的に示す情報（例えば、下りリンクにおけるアーリーデータ伝送の能力を有することを示すランダムアクセスプリアンブルの送信に用いるＰＲＡＣＨリソースの情報）を含んでもよい。
また、ＵＥ１００は、下りリンクにおけるアーリーデータ伝送を指示する旨のＭｓｇ２（上述した変更例７参照）をｅＮＢ２００から受信している場合に限り、下りリンクにおけるアーリーデータ伝送の能力をＲＲＣ接続要求メッセージによってｅＮＢ２００に通知してもよい。当該Ｍｓｇ２は、下りリンクにおけるアーリーデータ伝送を行うことを明示的に示す情報を含んでもよい。当該Ｍｓｇ２は、下りリンクにおけるアーリーデータ伝送を行うことを暗示的に示す情報を含んでもよい。
（変更例１０）
変更例９において、ＵＥ１００が下りリンクにおけるアーリーデータ伝送に対応（サポート）しているか否かをＵＥ１００からｅＮＢ２００に通知する一例を説明した。しかしながら、コアネットワーク（ＥＰＣ２０）に設けられるモビリティ管理装置（ＭＭＥ３００）が、下りリンクにおけるアーリーデータ伝送を行う能力をＵＥ１００が有するか否かをｅＮＢ２００に通知してもよい。この動作に先立ち、ＵＥ１００は、下りリンクにおけるアーリーデータ伝送を行う能力を有することを示す情報をＭＭＥ３００に通知し、ＭＭＥ３００は、当該情報を含むＵＥコンテキストを一定期間（例えば、ＵＥ１００がＥＭＭ Ｒｅｇｉｓｔｅｒｅｄ状態の間）において保持してもよい。
ＭＭＥ３００は、当該能力を、ページングメッセージ（Ｓ１ページングメッセージ）によってｅＮＢ２００に通知してもよいし、ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰメッセージによってｅＮＢ２００に通知してもよい。ＭＭＥ３００は、ＮＡＳシグナリングによってデータをＵＥ１００に送信する際に、当該能力をＮＡＳシグナリング又はＳ１メッセージによってｅＮＢ２００に通知してもよい。
（変更例１１）
上述した変更例４において、アーリーデータ伝送によってデータ送信が完了したと判断された場合、ＵＥ１００が、ＲＲＣアイドルモードからＲＲＣコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する動作を説明した。変更例８は、下りリンクにおけるアーリーデータ伝送の場合の動作例に関する。
変更例１１において、ｅＮＢ２００は、下りリンクにおけるアーリーデータ伝送によってＵＥ１００に対して送信するデータの量に基づいて、当該データの送信に用いるメッセージ（所定メッセージ）として第１メッセージ及び第２メッセージのいずれかを決定する。第１メッセージは、ＵＥ１００をアイドルモードからコネクティッドモードに遷移させるために用いるＲＲＣ接続確立メッセージである。第２メッセージは、ＵＥ１００をアイドルモードに維持させるために用いるメッセージである。第２メッセージしてＲＲＣ接続解放メッセージを用いる一例を説明するが、第２メッセージは、新たなメッセージであってよい。
例えば、ｅＮＢ２００は、ＵＥ１００に送信すべきデータの量が、ＲＲＣ接続解放メッセージによって運搬可能な最大データ量以下である場合に、ＲＲＣ接続解放メッセージによってデータ送信が完了すると判断する。この場合、ｅＮＢ２００は、ＲＲＣ接続確立メッセージの送信に代えて、データを含むＲＲＣ接続解放メッセージをＵＥ１００に送信する。これによって、ランダムアクセスプロシージャを途中で中止し、ＵＥ１００がコネクティッドモードに遷移しないようにすることができる。一方で、ｅＮＢ２００は、ＵＥ１００に送信すべきデータの量が、ＲＲＣ接続解放メッセージによって運搬可能な最大データ量を超える場合に、ＲＲＣ接続解放メッセージによってデータ送信が完了しないと判断する。この場合、ｅＮＢ２００は、データを含むＲＲＣ接続確立メッセージをＵＥ１００に送信する。これによって、ランダムアクセスプロシージャをＵＥ１００に継続させることができる。
或いは、メッセージを異ならせることに代えて、ＲＲＣ接続確立メッセージによって、データ送信の終了をＵＥ１００に通知してもよい。例えば、ｅＮＢ２００は、ＵＥ１００に送信すべきデータの量が、ＲＲＣ接続確立メッセージによって運搬可能な最大データ量以下である場合に、ＲＲＣ接続確立メッセージによってデータ送信が完了すると判断する。この場合、ｅＮＢ２００は、データと、データ送信の終了を示す情報（いわゆる、エンドマーカ）とを含むＲＲＣ接続確立メッセージをＵＥ１００に送信する。これによって、ランダムアクセスプロシージャを途中で中止し、ＵＥ１００がコネクティッドモードに遷移しないようにすることができる。一方で、ｅＮＢ２００は、ＵＥ１００に送信すべきデータの量が、ＲＲＣ接続確立メッセージによって運搬可能な最大データ量を超える場合に、ＲＲＣ接続確立メッセージによってデータ送信が完了しないと判断する。この場合、ｅＮＢ２００は、データを含み、且つエンドマーカを含まないＲＲＣ接続確立メッセージをＵＥ１００に送信する。これによって、ランダムアクセスプロシージャをＵＥ１００に継続させることができる。
（変更例１２）
上述した変更例８において、ＵＥ１００が、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によるデータの送信が失敗したと判断した場合に、当該データを伴うＲＲＣ接続要求メッセージを再送する一例を説明した。
かかる再送動作は、下りリンクにおけるアーリーデータ伝送にも応用可能である。変更例９において、ｅＮＢ２００は、アーリーデータ伝送によって、データを伴うＲＲＣ接続確立メッセージ（Ｍｓｇ４）をＵＥ１００に送信し、その後、ＲＲＣ接続確立メッセージによるデータの送信が成功したか否かを判断する。ｅＮＢ２００は、かかる判断を、例えば、ＭＡＣレイヤにおけるＨＡＲＱ ＡＣＫ又はＨＡＲＱ ＮＡＣＫに基づいて行ってもよい。そして、ｅＮＢ２００は、Ｍｓｇ４によるデータの送信が失敗したと判断した場合、当該データを伴うＭｓｇ４を再送する。ＵＥ１００は、下りリンクにおけるアーリーデータ伝送が設定されており、Ｍｓｇ４受信に失敗した場合、Ｍｓｇ４再送において当該データも再送されると判断する。そして、ＵＥ１００（例えば、ＵＥ１００のＭＡＣレイヤよりも上位のレイヤ（ＲＲＣレイヤ等））は、Ｍｓｇ４を構成するＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）受信とデータ受信の両方を実施できるように待ち受けを行う。
（変更例１３）
変更例１３は、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送の両方に関連する実施例である。
変更例１３において、ＵＥ１００及び／又はｅＮＢ２００は、上りリンク及び下りリンクの一方におけるアーリーデータ伝送が行われるランダムアクセスプロシージャについて、上りリンク及び下りリンクの他方におけるアーリーデータ伝送を行わないと判断する。これにより、１つのＵＥ１００が行う１つのランダムアクセスプロシージャにおいては、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送のうち一方のみを実施可能とする。
１つのランダムアクセスプロシージャにおいて、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送の両方を実施可能とすると、アーリーデータ伝送に関する制御が複雑化する懸念がある。また、次のような問題が生じ得る。例えば、ＵＥ１００は、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータを送信した後、当該データに対応する応答データ（例えば、ＴＣＰ ＡＣＫ）がＲＲＣ接続確立メッセージ（Ｍｓｇ４）によって送信されるのを待たなければならない。かかる応答データは、ネットワークにおける遅延の影響等を受けるため、応答データがＲＲＣ接続確立メッセージ（Ｍｓｇ４）によって送信されるのをＵＥ１００が待ち続けることは好ましくない。よって、１つのランダムアクセスプロシージャにおいては、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送のうち一方のみを実施可能とすることによって、かかる問題を回避することができる。
変更例１３において、ＵＥ１００は、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータ送信を行う場合、ＲＲＣ接続確立メッセージ（Ｍｓｇ４）によってデータ受信を行わないと判断する。言い換えると、ＵＥ１００は、Ｍｓｇ３を用いる上りリンクのアーリーデータ伝送が行われるランダムアクセスプロシージャについて、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送を行わないと判断する。例えば、ＵＥ１００が、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送を行う旨をページングメッセージによって通知された場合（第１実施形態の動作パターン３参照）、又は、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送を行う旨をランダムアクセス応答によって通知された場合（変更例７参照）を想定する。かかる場合であっても、ＵＥ１００は、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータ送信を行う場合、ＲＲＣ接続確立メッセージ（Ｍｓｇ４）によってデータ受信を行う必要がない判断してもよい。また、ｅＮＢ２００は、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータ受信を行った場合、ＲＲＣ接続確立メッセージ（Ｍｓｇ４）によってデータ送信を行わないと判断してもよい。
変更例１３において、ＵＥ１００は、ＲＲＣ接続確立メッセージ（Ｍｓｇ４）によってデータ受信を行う場合、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータ送信を行わないと判断する。言い換えると、ＵＥ１００は、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送が行われるランダムアクセスプロシージャについて、Ｍｓｇ３を用いる上りリンクのアーリーデータ伝送を行わないと判断する。例えば、ＵＥ１００が、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送を行う旨をページングメッセージによって通知された場合（第１実施形態の動作パターン３参照）、又は、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送を行う旨をランダムアクセス応答（Ｍｓｇ２）によって通知された場合（変更例７参照）を想定する。かかる場合、ＵＥ１００が上りリンクの送信データを持っていても、ＵＥ１００は、Ｍｓｇ４を用いる下りリンクのアーリーデータ伝送を行うと判断し、Ｍｓｇ３を用いる上りリンクの送信データを行わないと判断してもよい。
変更例１３において、アーリーデータ伝送を行う能力を有するＵＥ１００が、アーリーデータ伝送を行う能力を有することを示す通知（識別子）を、ランダムアクセスプリアンブル（Ｍｓｇ１）及びＲＲＣ接続要求メッセージ（Ｍｓｇ３）のいずれかによってｅＮＢ２００に送信するシナリオを想定する（変更例９参照）。
かかるシナリオにおいて、下りリンクにおけるアーリーデータ伝送を行うことを示す情報がページングメッセージ又はＭｓｇ２によってｅＮＢ２００からＵＥ１００に送信されている場合、ｅＮＢ２００は、アーリーデータ伝送を行う能力を有することを示す通知をＵＥ１００から受信すると、当該通知を、下りリンクにおけるアーリーデータ伝送を行う能力を示すものであると解釈する。下りリンクにおけるアーリーデータ伝送を行う能力及び／又は意図を有するＵＥ１００は、下りリンクにおけるアーリーデータ伝送を行うことを示す情報をｅＮＢ２００から受信している場合に、アーリーデータ伝送を行う能力を有することを示す通知をｅＮＢ２００に送信することによって、下りリンクにおけるアーリーデータ伝送を行う能力及び／又は意図をｅＮＢ２００に通知する。
一方で、下りリンクにおけるアーリーデータ伝送を行うことを示す情報がページングメッセージ又はＭｓｇ２によってｅＮＢ２００からＵＥ１００に送信されていない場合、ｅＮＢ２００は、アーリーデータ伝送を行う能力を有することを示す通知をＵＥ１００から受信すると、当該通知を、上りリンクにおけるアーリーデータ伝送を行う能力及び／又は意図を示すものであると解釈する。上りリンクにおけるアーリーデータ伝送を行う能力及び／又は意図を有するＵＥ１００は、下りリンクにおけるアーリーデータ伝送を行うことを示す情報をｅＮＢ２００から受信していない場合に、アーリーデータ伝送を行う能力を有することを示す通知をｅＮＢ２００に送信することによって、上りリンクにおけるアーリーデータ伝送を行う能力及び／又は意図をｅＮＢ２００に通知する。
このように、下りリンクにおけるアーリーデータ伝送を行うことを示す情報が送信されているか否かに応じて、通知の意味合いを異ならせる。これによって、１種類の通知（例えば、１つの情報要素）が２通りの役割を果たすことができる。
（変更例１４）
変更例１４においては、変更例１３とは異なり、１つのランダムアクセスプロシージャにおいて、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送の両方を実施可能とするシナリオを想定する。
一般的なランダムアクセスプロシージャにおいて、ＵＥ１００は、データを伴わないＭｓｇ３を送信する場合、当該Ｍｓｇ３の送信時に、ｅＮＢ２００から送信されるＭｓｇ４の受信を待つべき待ち時間を定める第１のタイマを起動する。かかる第１のタイマは、Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒと称されることがある。第１のタイマは、ｅＮＢ２００からＳＩＢによってＵＥ１００に設定される。ＵＥ１００は、Ｍｓｇ４を受信することなく第１のタイマが満了すると、Ｍｓｇ４を受信するための処理（例えば、ＰＤＣＣＨの監視）を中止し、ランダムアクセスプロシージャをＭｓｇ１の送信から再開する。
しかしながら、上述したように、ＲＲＣ接続要求メッセージ（Ｍｓｇ３）によってデータを送信した後、当該データに対応する応答データ（例えば、ＴＣＰ ＡＣＫ）がＲＲＣ接続確立メッセージ（Ｍｓｇ４）によって送信される場合、第１のタイマでは待ち時間が足りない可能性がある。よって、変更例１４において、第１のタイマとは別に、アーリーデータ伝送向けの第２のタイマを導入する。第１のタイマ及び第２のタイマの両方が設定されたＵＥ１００は、Ｍｓｇ３送信がデータ送信を伴わない場合には第１のタイマを選択し、Ｍｓｇ３送信がデータ送信を伴う場合には第２のタイマを選択する。
変更例１４において、アーリーデータ伝送によってＵＥ１００がデータを伴うＭｓｇ３を送信する場合、ＵＥ１００は、ｅＮＢ２００からデータを伴って送信されるＭｓｇ４の受信を待つべき待ち時間を定める第２のタイマを起動する。第２のタイマに対応する待ち時間の長さは、第１のタイマに対応する待ち時間の長さと異なる。例えば、第２のタイマに設定される待ち時間を、第１のタイマに設定される待ち時間よりも長くすることが可能である。例えば、第２のタイマに設定可能な最大待ち時間は、第１のタイマに設定可能な最大待ち時間よりも長い。第２のタイマは、ｅＮＢ２００からＳＩＢによってＵＥ１００に設定される。或いは、ＲＲＣサスペンド状態のＵＥ１００についてはコンテキスト情報がネットワーク（及びＵＥ１００）において保持されるため、ＵＥ１００がコネクティッドモードにある間に第２のタイマを個別ＲＲＣメッセージによってＵＥ１００に設定し、ＵＥ１００がコネクティッドモードにある間は第２のタイマの設定をネットワークにおいて保持し、保持した設定をランダムアクセスプロシージャ時に用いてもよい。ＵＥ１００は、データを伴うＭｓｇ４を受信することなく第２のタイマが満了すると、Ｍｓｇ４を受信するための処理（例えば、ＰＤＣＣＨの監視）を中止し、ランダムアクセスプロシージャをＭｓｇ１の送信から再開する。
或いは、アーリーデータ伝送がｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥに適用されると仮定すると、ＵＥ１００の省電力化が優先され得る。よって、第２のタイマに設定される待ち時間を、第１のタイマに設定される待ち時間よりも短くしてもよい。これにより、Ｍｓｇ４を受信するための処理を早期に打ち切ることができる。
なお、第１のタイマ及び第２のタイマのそれぞれは、ＲＲＣレイヤにおいて管理されるタイマであってもよいし、ＭＡＣレイヤで管理されるタイマであってもよい。ＲＲＣレイヤにおいて管理される第１のタイマは、「Ｔ３００」と称されることがある。ＭＡＣレイヤにおいて管理される第１のタイマは、「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」と称されることがある。
第２のタイマのタイマ値（すなわち、Ｍｓｇ４の待ち時間）は、ｅＮＢ２００が決定してＵＥ１００に設定する場合に限らず、ＵＥ１００が決定してもよい。ＵＥ１００が上りリンクデータを送信してから上位レイヤのＡＣＫ（例えば、ＴＣＰ ＡＣＫ）がＵＥ１００に返ってくるまでの時間であるｒｏｕｎｄ ｔｒｉｐ時間は、ＵＥ１００の上位レイヤにおいて推定可能である。よって、第２のタイマのタイマ値をＵＥ１００が決定することにより、より適切なタイマ値を決定することができる。ＵＥ１００は、第２のタイマに設定するタイマ値を決定し、決定したタイマ値をｅＮＢ２００に対して通知してもよい。タイマ値の通知は、Ｍｓｇ３によって行なわれる。タイマ値の通知は、Ｍｓｇ１（プリアンブル送信）によって行なわれてもよい。
図１７は、変更例１４の動作の一例を示す図である。図１７において、サーバ５０は、コアネットワーク（ＥＰＣ）よりも上位のネットワーク（例えば、インターネット）に設けられる。また、図１７において、ｅＮＢ２００とサーバ５０との間のネットワークエンティティ（例えば、Ｓ−ＧＷ）の図示を省略している。
図１７に示すように、ステップＳ７０１において、ＵＥ１００は、第２のタイマに設定するタイマ値を決定する。ＵＥ１００は、ｒｏｕｎｄ ｔｒｉｐ時間の推定値に基づいて第２のタイマのタイマ値を決定してもよい。
ステップＳ７０２において、ＵＥ１００は、上りリンクのアーリーデータ伝送によって、データを伴うＭｓｇ３をｅＮＢ２００に送信する。ＵＥ１００は、決定したタイマ値をＭｓｇ３によってｅＮＢ２００に通知する。ｅＮＢ２００は、かかる通知によって、ＵＥ１００におけるＭｓｇ４待ち時間を把握することができる。
ＵＥ１００は、第２のタイマを使うことをＭｓｇ１（プリアンブル送信）によってｅＮＢ２００に通知してもよい。そして、ＵＥ１００は、第２のタイマの使用許可をＭｓｇ２でｅＮＢ２００から通知された場合のみ、第２のタイマを使用し、かつＭｓｇ３でタイマ値をｅＮＢ２００に通知してもよい。
ｅＮＢ２００は、タイマ値の候補（タイマ値の範囲ごとのインデックスからなるリスト）をブロードキャスト（例えば、ＳＩＢにより送信）してもよい。この場合、ＵＥ１００は、Ｍｓｇ３ではタイマ値のインデックスをｅＮＢ２００に通知してもよい。
ｅＮＢ２００は、第２のタイマのデフォルトのタイマ値をブロードキャスト（例えば、ＳＩＢにより送信）してもよい。この場合、ＵＥ１００は、基本的にデフォルトのタイマ値を利用する。ＵＥ１００は、デフォルトのタイマ値を上書きしたい場合に限りタイマ値を自律的に決定し、決定したタイマ値をＭｓｇ３によってｅＮＢ２００に通知してもよい。「Ｔ３００」の値をデフォルトのタイマ値としてもよいし、「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」の値をデフォルトのタイマ値としてもよい。また、ＵＥ１００が第２のタイマのタイマ値を決定する場合、ＵＥ１００は、デフォルトのタイマ値以上のタイマ値を決定しなければならないという制約があってもよい。
ｅＮＢ２００は、ＵＥ１００が設定可能なタイマ値の最大値をブロードキャスト（例えば、ＳＩＢにより送信）してもよい。ＵＥ１００は、ｅＮＢ２００からブロードキャストされる最大値以下のタイマ値を決定し、決定したタイマ値をｅＮＢ２００に通知する。但し、ＵＥ１００は、タイマ値として、ｅＮＢ２００からブロードキャストされる最大値を決定した場合には、決定したタイマ値をｅＮＢ２００に通知しなくてもよい。ｅＮＢ２００は、ＵＥ１００からタイマ値が通知されない場合に、ＵＥ１００が当該最大値を決定したとみなしてもよい。なお、ＵＥ１００は、ｅＮＢ２００から最大値がブロードキャストにより指定されない場合には、予め規定されたデフォルトの最大値を用いて、デフォルトの最大値以下のタイマ値を決定してもよい。
ｅＮＢ２００は、ＵＥ１００が設定可能なタイマ値の最小値をブロードキャスト（例えば、ＳＩＢにより送信）してもよい。ＵＥ１００は、ｅＮＢ２００からブロードキャストされる最小値以上のタイマ値を決定し、決定したタイマ値をｅＮＢ２００に通知する。但し、ＵＥ１００は、タイマ値として、ｅＮＢ２００からブロードキャストされる最小値を決定した場合には、決定したタイマ値をｅＮＢ２００に通知しなくてもよい。ｅＮＢ２００は、ＵＥ１００からタイマ値が通知されない場合に、ＵＥ１００が当該最小値を決定したとみなしてもよい。なお、ＵＥ１００は、ｅＮＢ２００から最小値がブロードキャストにより指定されない場合には、予め規定されたデフォルトの最小値を用いて、デフォルトの最小値以上のタイマ値を決定してもよい。
ステップＳ７０３において、ＵＥ１００は、Ｍｓｇ３の送信時に、決定したタイマ値が設定された第２のタイマを起動（開始）する。
ステップＳ７０４において、ｅＮＢ２００は、Ｍｓｇ３によってＵＥ１００から受信したデータをサーバ５０に転送する。
ステップＳ７０５において、サーバ５０は、応答データ（ＴＣＰ ＡＣＫ）をｅＮＢ２００に送信する。
ステップＳ７０６において、ｅＮＢ２００は、下りリンクのアーリーデータ伝送によって、応答データ（ＴＣＰ ＡＣＫ）を伴うＭｓｇ４をＵＥ１００に送信する。
図１７のシーケンスでは、Ｍｓｇ３送信が成功する場合を想定している。しかしながら、Ｍｓｇ３送信に失敗し、ＨＡＲＱ ＮＡＣＫ（再送要求）がｅＮＢ２００からＵＥ１００に送信され、ＵＥ１００がＨＡＲＱによってＭｓｇ３の再送を行う場合も想定される。ＵＥ１００は、第２のタイマを起動した後、ＨＡＲＱによってＭｓｇ３の再送を行う場合に、第２のタイマを再開（再起動）させることなく、第２のタイマを動作継続させてもよい。これにより、上位レイヤがｒｏｕｎｄ ｔｒｉｐ時間に基づいて設定するＴＣＰ ＡＣＫ待ち時間と、アクセスレイヤが設定するＭｓｇ４待ち時間とで不整合が生じることを回避できる。或いは、ＵＥ１００は、第２のタイマを起動した後、ＨＡＲＱによってＭｓｇ３の再送を行う場合に、第２のタイマを再開（再起動）してもよい。
上記の変更例１４の動作において、第１のタイマが「Ｔ３００」又は「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」であり、第２のタイマがアーリーデータ伝送用の新たなタイマであることを想定している。すなわち、アーリーデータ伝送を伴うランダムアクセスプロシージャのための第１のタイマと、アーリーデータ伝送を伴わないランダムアクセスプロシージャのための第２のタイマとを別々のタイマとして規定することを想定していた。
ここで、「Ｔ３００」は、ランダムアクセスプロシージャ（又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｐｒｏｃｅｄｕｒｅ）においてＵＥ１００がＭｓｇ３を送信してからＭｓｇ４（具体的には、ＲＲＣメッセージ）を受信するまでの最大待ち時間を規定するタイマであり、ＲＲＣレイヤにおいて管理される。「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」は、ランダムアクセスプロシージャにおいてＵＥ１００がＭｓｇ３を送信してからＭｓｇ４（具体的には、ＭＡＣ ＣＥ）を受信するまでの最大待ち時間を規定するタイマであり、ＭＡＣレイヤにおいて管理される。
しかしながら、かかる新たなタイマ（第２のタイマ）を導入することに変えて、第１のタイマ（「Ｔ３００」又は「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」）に設定するためのタイマ値として２種類のタイマ値を規定することにより、上記の変更例１４の動作と同様な動作を実現可能である。これにより、新たなタイマを導入する場合に比べて、システムの仕様変更の影響を小さくすることができる。また、２つのタイマ（第１のタイマと第２のタイマ）を設定する代わりに、１つのタイマ（第１のタイマ）だけを設定すればよくなるため、ＵＥ１００の処理負荷も低減される。
以下の変更例１４において、第１のタイマに設定するためのタイマ値として２種類のタイマ値を規定する場合の動作について説明する。ここでは、第１のタイマとして「Ｔ３００」を例示するが、第１のタイマは「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」であってもよい。
かかる場合、ｅＮＢ２００は、アーリーデータ伝送を伴わないランダムアクセスプロシージャのための第１のタイマ値と、アーリーデータ伝送を伴うランダムアクセスプロシージャのための第２のタイマ値とをＵＥ１００に送信する。第２のタイマ値は、第１のタイマ値よりも大きい値である。或いは、第２のタイマ値は、第１のタイマ値よりも小さい値であってもよい。
ｅＮＢ２００は、第１のタイマ値及び第２のタイマ値をブロードキャストで送信する。例えば、ｅＮＢ２００は、ＳＩＢ中の既存の情報要素である「Ｔ３００」（第１のタイマ値）と、ＳＩＢ中の新たな情報要素である「Ｔ３００−ＥＤＴ」とをＳＩＢにより送信する。ｅＮＢ２００は、第１のタイマ値及び第２のタイマ値を同一のＳＩＢに含めてもよいし、第１のタイマ値及び第２のタイマ値を互いに異なるＳＩＢに含めてもよい。
ＵＥ１００は、アーリーデータ伝送を行うと判断したことに応じて、第１のタイマ値及び第２のタイマ値のうち第２のタイマ値を選択して第１のタイマに設定する。そして、ＵＥ１００は、アーリーデータ伝送により上りリンクデータを送信する際に、第２のタイマ値を設定したタイマ（第１のタイマ）を開始させる。アーリーデータ伝送により上りリンクデータを送信するとは、具体的には、ＵＥ１００が、Ｍｓｇ３の送信時に上りリンクユーザデータを送信することを意味する。
図１８は、２種類のタイマ値を規定する場合の動作を示す図である。
図１８に示すように、ステップＳ７５１において、ｅＮＢ２００は、第１のタイマ値及び第２のタイマ値をブロードキャストで送信する。ｅＮＢ２００は、第１のタイマ値及び第２のタイマ値を所定の周期で送信する。
ステップＳ７５２において、ＲＲＣアイドルモードにあるＵＥ１００は、ネットワークに送信するべき上りリンクデータが発生したことを検知し、ランダムアクセスプロシージャを開始する必要があると判断する。
ステップＳ７５３において、ＵＥ１００は、アーリーデータ伝送（ＥＤＴ）を行うか否かを判断する。例えば、ＵＥ１００は、送信したい上りリンクデータ量がｅＮＢ２００からブロードキャストで設定された最大上りリンクデータ量（トランスポートブロックサイズ）以下である場合には、ＥＤＴを行うと判断する。
アーリーデータ伝送を行わずに通常のランダムアクセスプロシージャを行うと判断した場合（ステップＳ７５３：ＮＯ）、ステップＳ７５４において、ＵＥ１００は、第１のタイマ値を選択し、第１のタイマ値をタイマ（第１のタイマ）に設定する。そして、ステップＳ７５５において、ＵＥ１００は、通常のランダムアクセスプロシージャを開始する。
一方で、アーリーデータ伝送を行うと判断した場合（ステップＳ７５３：ＹＥＳ）、ステップＳ７５６において、ＵＥ１００は、第２のタイマ値を選択し、第２のタイマ値をタイマ（第１のタイマ）に設定する。そして、ステップＳ７５７において、ＵＥ１００は、アーリーデータ伝送を伴うランダムアクセスプロシージャを開始する。
ランダムアクセスプロシージャが開始されると、ステップＳ７５８において、ＵＥ１００及びｅＮＢ２００は、Ｍｓｇ１及びＭｓｇ２の送受信を行う。なお、ＵＥ１００及びｅＮＢ２００は、アーリーデータ伝送を伴うか否かに応じて、Ｍｓｇ１及びＭｓｇ２の中身を異ならせてもよい。
ステップＳ７５９において、ＵＥ１００は、Ｍｓｇ３をｅＮＢ２００に送信する。アーリーデータ伝送を行う場合、ＵＥ１００は、Ｍｓｇ３の送信に伴って上りリンクデータをｅＮＢ２００に送信する。ＵＥ１００は、Ｍｓｇ３の送信時にタイマ（第１のタイマ）を開始させる。
ステップＳ７６０において、ＵＥ１００は、ｅＮＢ２００からＭｓｇ４を正常に受信したか否かを判定する。ｅＮＢ２００からＭｓｇ４を正常に受信した場合（ステップＳ７６０：ＹＥＳ）、ステップＳ７６１において、ＵＥ１００は、タイマ（第１のタイマ）を停止させ、ランダムアクセスプロシージャを終了する又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ メッセージを送信した後にランダムアクセスプロシージャを終了する。ＵＥ１００は、通常のランダムアクセスプロシージャを行った場合、ＲＲＣコネクティッドモードに遷移する。一方で、アーリーデータ伝送を行った場合、ＵＥ１００は、ＲＲＣコネクティッドモードに遷移せずに、ＲＲＣアイドルモードを維持する。なお、ＵＥ１００がｅＮＢ２００からＭｓｇ４を正常に受信したとは、ＵＥ１００が、ｅＮＢ２００から受信したＵＥ１００宛てのＭｓｇ４をデコードし、Ｍｓｇ４の中身を取得できたことを意味してもよい。
一方で、ｅＮＢ２００からＭｓｇ４を正常に受信せずにタイマ（第１のタイマ）が満了した場合（ステップＳ７６０：ＮＯ、ステップＳ７６２：ＹＥＳ）、ステップＳ７６３において、ＵＥ１００は、ランダムアクセスプロシージャを最初から再開する（やり直す）又はランダムアクセスプロシージャを終了する。
なお、図１８のフローでは、ＵＥ１００は、アーリーデータ伝送を行うか否かをランダムアクセスプロシージャ開始前に判定（ステップＳ７５３）している。しかしながら、ＵＥ１００は、Ｍｓｇ１でＥＤＴ（Early Data Transmission） Ｉｎｄｉｃａｔｉｏｎを送信若しくは、アーリーデータ伝送（ＥＤＴ）用のＰＲＡＣＨ（Physical Random Access Channel）設定を用いて送信し、かつ、Ｍｓｇ２でアーリーデータ伝送（ＥＤＴ）を行う事が許可された場合、Ｍｓｇ２でアーリーデータ伝送に関するリソースを含むＥＤＴ Ｇｒａｎｔを受信した場合、アーリーデータ伝送（ＥＤＴ）用のＤＣＩを受信した場合又はアーリーデータ伝送（ＥＤＴ）実施するのに十分な上りリンクリソースを含むＵＬ Ｇｒａｎｔを受信した場合において、Ｍｓｇ３で上りリンクのアーリーデータ伝送（ＵＬ ＥＤＴ）を行った（ユーザデータをＭｓｇ３と一緒に送信した）時に、アーリーデータ伝送を行う（又は行っている）と判定してもよい。かかる場合、ＵＥ１００は、Ｍｓｇ２を受信するまではタイマ（第１のタイマ）にタイマ値を設定せずに、Ｍｓｇ２を受信した後にタイマ（第１のタイマ）にタイマ値を設定する。
なお、ＵＥ１００は、上記のいずれかの場合にアーリーデータ伝送を行うと判断してもよい。つまり、ＵＥ１００は、上記の場合において、Ｍｓｇ１を送信した際、Ｍｓｇ２を受信した際、又はＭｓｇ３を送信した場合のいずれかをもって、アーリーデータ伝送を行う（又は行っている）と判定してもよい。
（変更例１５）
上述した変更例１４において、上位レイヤのＡＣＫをＭｓｇ４によってｅＮＢ２００からＵＥ１００に送信する一例を説明した。この場合、ＵＥ１００は、Ｍｓｇ３送信後、Ｍｓｇ４を受信するまで（又は第２のタイマが満了するまで）、サブフレームごとにＰＤＣＣＨのモニタを継続しなければならない。特に、上位レイヤのＡＣＫが遅延した場合、ＵＥ１００がＰＤＣＣＨをモニタし続けることで、消費電力が増加する懸念がある。
変更例１５においては、ｅＮＢ２００は、上位レイヤのＡＣＫの到着を待たずにＭｓｇ４をＵＥ１００に送信することにより、ＵＥ１００がＰＤＣＣＨの継続的なモニタを打ち切ることができるようにする。また、ｅＮＢ２００は、Ｍｓｇ４の送信後にＵＥ１００にデータ（上位レイヤのＡＣＫ）を送信する予定であることをＭｓｇ４によってＵＥ１００に通知する。このＭｓｇ４送信は、ＵＥ１００をＲＲＣアイドルモードに維持させることを示す情報の送信を含んでもよい。これにより、ＵＥ１００は、ＲＲＣアイドルモードを維持しつつ、下りリンクデータの受信を待つことができる。すなわち、ＵＥ１００は、Ｍｓｇ４を受信すると、ＲＲＣコネクティッドモードに遷移することなく、下りリンクデータ（上位レイヤのＡＣＫ）の待ち受けを行う。下りリンクデータの待ち受け中において、ＵＥ１００は、ＤＲＸ（Ｄｉｓｃｏｎｔｉｎｕｅｓ Ｒｅｃｅｐｔｉｏｎ）によって、不連続なサブフレームにおいてＰＤＣＣＨを間欠的にモニタしてもよい。
図１９は、変更例１５の動作の一例を示す図である。図１９において、サーバ５０は、コアネットワーク（ＥＰＣ）よりも上位のネットワーク（例えば、インターネット）に設けられる。また、図１９において、ｅＮＢ２００とサーバ５０との間のネットワークエンティティ（例えば、Ｓ−ＧＷ）の図示を省略している。
図１９に示すように、ステップＳ７１１において、ＵＥ１００は、上りリンクのアーリーデータ伝送によって、データを伴うＭｓｇ３をｅＮＢ２００に送信する。
ステップＳ７１２において、ｅＮＢ２００は、Ｍｓｇ３によってＵＥ１００から受信したデータをサーバ５０に転送する。
ステップＳ７１３において、ｅＮＢ２００は、Ｍｓｇ４をＵＥ１００に送信する。ｅＮＢ２００は、ＵＥ１００をＲＲＣアイドルモードに維持させる旨の情報と、Ｍｓｇ４の送信後に下りリンクデータの送信（すなわち、下りリンクのアーリーデータ伝送）を行う予定である旨の予告通知とをＭｓｇ４によってＵＥ１００に送信する。ｅＮＢ２００は、例えば次の１）〜３）の何れかの方法によって、下りリンクのアーリーデータ伝送を行うか否かを判断する。
１）ｅＮＢ２００は、過去のトラフィックパターン等を学習し、学習結果に基づいて下りリンクのアーリーデータ伝送を行うか否かを判断する。
２）ＭＭＥからｅＮＢ２００に下りリンクのアーリーデータ伝送の意図が通知され、ｅＮＢ２００は、ＭＭＥからの通知に基づいて下りリンクのアーリーデータ伝送を行うか否かを判断する。
３）Ｍｓｇ３にてＵＥ１００からｅＮＢ２００に下りリンクのアーリーデータ伝送が発生する可能性（上位レイヤＡＣＫの有無）を通知し、ｅＮＢ２００は、ＵＥ１００からの通知に基づいて下りリンクのアーリーデータ伝送を行うか否かを判断する。
Ｍｓｇ４によってｅＮＢ２００からＵＥ１００に送信される予告通知は、下りリンクのアーリーデータ伝送の発生予想タイミング（例えば、１０秒後）を示す情報を含んでもよい。予告通知は、ＭＡＣ ＣＥに含まれてもよいし、ＲＲＣメッセージに含まれてもよい。
ステップＳ７１４において、Ｍｓｇ４を受信したＵＥ１００は、下りリンクデータの受信待ち時間を規定するタイマを起動してもよい。当該タイマのタイマ値（閾値）は、ｅＮＢ２００からＵＥ１００に対して、ＳＩＢ、Ｍｓｇ４、又はＭｓｇ２によって設定されてもよい。ＵＥ１００は、下りリンクデータを受信することなくタイマが満了すると、下りリンクデータの待ち受けを終了してもよい。
ステップＳ７１５において、ＵＥ１００は、ＤＲＸを開始し、ＰＤＣＣＨを間欠的にモニタする。ＤＲＸの設定情報は、ｅＮＢ２００からＵＥ１００に対してＳＩＢ又はＭｓｇ４によって通知されてもよい。かかるＤＲＸ動作は、ＲＲＣコネクティッドモードのＤＲＸに準じた動作としてもよいし、ＲＲＣアイドルモードのＤＲＸに準じた動作としてもよい。
ＲＲＣコネクティッドモードのＤＲＸに準じた動作とする場合について説明する。ステップＳ７１５で開始されるＤＲＸにおいてｅＮＢ２００からＵＥ１００に設定されるＤＲＸサイクルは、ＲＲＣコネクティッドモードのＤＲＸにおいて設定可能なＤＲＸサイクルよりも長いことが好ましい。現状、ＲＲＣコネクティッドモードのＤＲＸサイクルの最大値は、１０２４無線フレーム分の時間（すなわち、１０．２４秒）である。１０．２４秒よりも長いＤＲＸサイクルを設定する方法として、ｅＤＲＸ（ｅｘｔｅｎｄｅｄ ＤＲＸ）の仕組みを応用し、次のａ）及びｂ）のいずれかの方法を用いることができる。ｅＤＲＸにおいては、ハイパーフレームが導入される。ハイパーフレームは、１０２４無線フレーム分の時間長を有する時間単位である。現在のハイパーフレーム番号（Ｈ−ＳＦＮ）はｅＮＢ２００からＳＩＢによってブロードキャストされる。
ａ）ＵＥ１００は、「Ｈ−ＳＦＮ ｍｏｄ ｍ ＝ ０」を満たすＨ−ＳＦＮを受信Ｈ−ＳＦＮとして決定する。ｅＮＢ２００は、かかる計算式における「ｍ」の値をＵＥ１００に設定する。ＵＥ１００は、決定した受信Ｈ−ＳＦＮ内において、従来のＲＲＣコネクティッドモードのＤＲＸ動作を行う。具体的には、ＵＥ１００は、設定されたＤＲＸサイクルでウェイクアップし、ウェイクアップ状態においてＰＤＣＣＨをモニタする。ＵＥ１００は、「Ｈ−ＳＦＮ ｍｏｄ ｍ ＝ ０」を満たさないＨ−ＳＦＮにおいてスリープ状態（すなわち、ＰＤＣＣＨをモニタしない状態）を維持することができる。
ｂ）ＵＥ１００は、連続する２つのハイパーフレームを１セットとして用いて、１０２４無線フレーム以上の長さのＤＲＸサイクルに対応可能とする。１つのハイパーフレームは、０から１０２３までの無線フレーム番号（ＳＦＮ）を有する１０２４個の無線フレームからなる。ＵＥ１００は、１つのセットを構成する１つ目のハイパーフレーム（例えば偶数番のハイパーフレーム）において０から１０２３までＳＦＮをカウントした後、当該１つのセットを構成する２つ目のハイパーフレーム（例えば奇数番のハイパーフレーム）の最初の無線フレームをＳＦＮ＝１０２４とカウントし、当該２つ目のハイパーフレームの２番目の無線フレームをＳＦＮ＝１０２５とカウントする。このように、ＵＥ１００は、１つ目のハイパーフレームにおけるＳＦＮのカウント値を２つ目のハイパーフレームにおいて引き継ぐことによりカウントを継続する。これにより、ＵＥ１００は、１０２４無線フレーム分の時間（すなわち、１０．２４秒）よりも長い時間のＤＲＸサイクルを用いてＤＲＸ動作を行うことができる。
次に、ＲＲＣアイドルモードのＤＲＸに準じた動作とする場合について説明する。従来のＲＲＣアイドルモードのＤＲＸの決定には、ＤＲＸサイクルとＵＥ１００のＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）とが用いられる。ＩＭＳＩは、複数のＵＥ間でページングオケージョン（すなわち、ＰＤＣＣＨモニタのタイミング）を分散させるために用いられる。しかしながら、ランダムアクセスプロシージャ中においてはｅＮＢ２００がＵＥ１００のＩＭＳＩを未だ取得していないことが想定される。一方、Ｍｓｇ３には、Ｓ−ＴＭＳＩ（ＳＡＥ Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）又はＲｅｓｕｍｅ ＩＤが含まれるため、ｅＮＢ２００は、ランダムアクセスプロシージャ中にＵＥ１００のＳ−ＴＭＳＩ又はＲｅｓｕｍｅ ＩＤを取得することができる。よって、ｅＮＢ２００及びＵＥ１００は、ＩＭＳＩの代わりにＳ−ＴＭＳＩ又はＲｅｓｕｍｅ ＩＤを用いてページングオケージョンを決定する。
ステップＳ７１６において、サーバ５０は、応答データ（ＴＣＰ ＡＣＫ）をｅＮＢ２００に送信する。
ステップＳ７１７において、ｅＮＢ２００は、下りリンクのアーリーデータ伝送によって、応答データ（ＴＣＰ ＡＣＫ）をＵＥ１００に送信する。ＵＥ１００は、下りリンクデータを受信する。
なお、ＵＥ１００は、下りリンクデータとしてＴＣＰ ＮＡＣＫを受信した場合、ランダムアクセスプロシージャを開始し、上りリンクのアーリーデータ伝送を行なってもよい。
図１９の動作において、ＵＥ１００は、データを伴うＭｓｇ３を送信（ステップＳ７１１）してから下りリンクデータ送信の予告を受信（ステップＳ７１３）するまでは、ＲＲＣレイヤにおいて管理される「Ｔ３００」タイマ及び／又はＭＡＣレイヤにおいて管理される「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」を動作させており、ＰＤＣＣＨを連続的に監視する。そして、ＵＥ１００は、下りリンクデータ送信の予告（ステップＳ７１３）の受信に応じてタイマを起動し（ステップＳ７１４）、このタイマの動作中はＤＲＸ動作を行う（ステップＳ７１５）。
データ送信の予告が導入されない場合にも、かかる２段階のタイマを用いて受信動作を切り替えることが可能である。
かかる動作は、ＵＥ１００が、ランダムアクセスプロシージャ中に、ｅＮＢ２００に対してＲＲＣメッセージ（Ｍｓｇ３）を送信するとともにユーザデータを送信するアーリーデータ伝送を実行するステップと、ＵＥ１００が、アーリーデータ伝送の実行に応じて、第１のタイマを起動するステップと、ＵＥ１００が、第１のタイマが動作している間は、下りリンク制御チャネル（ＰＤＣＣＨ）を連続的に監視する第１の受信動作を実行するステップと、ＵＥ１００が、第１のタイマが満了したことに応じて、第２のタイマを起動するステップと、ＵＥ１００が、第２のタイマが動作している間は、第１の受信動作とは異なる第２の受信動作を実行するステップと、を備える。第２の受信動作は、第１の受信動作に比べて、下りリンク制御チャネルを監視する頻度が少ない受信動作である。例えば、第２の受信動作は、下りリンク制御チャネル（ＰＤＣＣＨ）を間欠的に監視する間欠受信（ＤＲＸ）動作である。
ここで、第１のタイマは、ＲＲＣレイヤにおいて管理される「Ｔ３００」タイマ又はＭＡＣレイヤにおいて管理される「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」であってもよい。通常、ｅＮＢ２００からの応答（例えばＭｓｇ４）を受信することなく「Ｔ３００」タイマや「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」が満了すると、ＵＥ１００は、ランダムアクセスプロシージャの失敗（ｃｏｎｔｅｎｔｉｏｎ ｒｅｓｏｌｕｔｉｏｎ ｆａｉｌｕｒｅ等）と判断してランダムアクセスプロシージャをやり直す。しかしながら、アーリーデータ伝送を実行する場合には、ＵＥ１００は、第１のタイマ（「Ｔ３００」タイマ又は「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」）が満了しても、ランダムアクセスプロシージャが失敗したと判断せずにランダムアクセスプロシージャを継続する。
或いは、第１のタイマは、「Ｔ３００」タイマ及び「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」とは異なる新たなタイマであってもよい。ＵＥ１００は、アーリーデータ伝送を行う場合には、「Ｔ３００」タイマ及び「Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ」を起動せずに、かかる新たなタイマを起動する（変更例１４参照）。
一方、下りリンクデータ送信の予告が導入される場合、ｅＮＢ２００は、ＵＥ１００からＲＲＣメッセージ及びユーザデータを受信した後、下りリンクデータ送信の予告（所定のメッセージ）をＵＥ１００に送信する（ステップＳ７１３）。ＵＥ１００は、第１のタイマが動作中に所定のメッセージを受信したことに応じて、第１のタイマを停止し、第１の受信動作を停止する。ＵＥ１００は、第１のタイマの停止（第１の受信動作を停止）に応じて、第２のタイマを起動する。
なお、所定のメッセージとしては、Ｍｓｇ４におけるＭＡＣレイヤのＣｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎを用いてもよい。このＣｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎには、データ送信の予告を示すフラグ（１ビット識別子）が付加されてもよい。そして、ｅＮＢ２００は、下りリンクデータ送信時（ステップＳ７１７）において、下りリンクデータと共に、Ｍｓｇ４におけるＲＲＣレイヤのＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＳｅｔｕｐをＵＥ１００に送信する。
（変更例１６）
変更例１６は、変更例１４及び変更例１５に関連する変更例である。変更例１６について、変更例１４及び変更例１５との相違点を主として説明する。
変更例１６において、ＵＥ１００は、Ｍｓｇ３を利用して上りリンクのアーリーデータ伝送を行う。ＵＥ１００は、アーリーデータ伝送の実行に応じて、ｅＮＢ２００から送信される応答の受信を待つべき待ち時間を定めるタイマを起動する。「タイマ」は、変更例１４に係る第１のタイマ又は第２のタイマであってもよいし、変更例１５に係るタイマであってもよい。「ｅＮＢ２００から送信される応答」は、ｅＮＢ２００からデータを伴って送信されるＭｓｇ４又はｅＮＢ２００からデータを伴わずに送信されるＭｓｇ４であってもよいし（変更例１４参照）、ｅＮＢ２００からＭｓｇ４（予告通知）の送信後に送信されるデータであってもよい（変更例１５参照）。
そして、ＵＥ１００は、タイマに対応する待ち時間の終了タイミングに基づいて定められるＰＤＣＣＨ監視タイミングまで、ＰＤＣＣＨの監視を省略する。例えば、ＵＥ１００は、タイマが満了した時点のサブフレームにおいてのみ、ＰＤＣＣＨを監視する。これにより、タイマが動作中はＵＥ１００の受信機をオフにすることができるため、ＵＥ１００の消費電力を削減できる。
ＵＥ１００は、タイマが満了した時点のサブフレームに代えて、タイマが満了した直後のサブフレーム（すなわち、タイマが満了した時点のサブフレームの次のサブフレーム）、又はタイマが満了してから規定時間経過後のサブフレームにおいてのみ、ＰＤＣＣＨを監視してもよい。或いは、ＵＥ１００は、タイマが満了した時点のサブフレームに代えて、タイマが満了する直前のサブフレーム（すなわち、タイマが満了する時点のサブフレームの１つ前のサブフレーム）、又はタイマが満了するサブフレームの規定時間前のサブフレームにおいてのみ、ＰＤＣＣＨを監視してもよい。
或いは、ＵＥ１００は、タイマが満了する時点を基準として定められる複数のタイミング（複数のサブフレーム）においてのみ、ＰＤＣＣＨを監視してもよい。例えば、ＵＥ１００は、タイマが満了した時点のサブフレームと、タイマが満了した直後のサブフレーム又はタイマが満了してから規定時間経過後のサブフレームとにおいてのみ、ＰＤＣＣＨを監視してもよい。ＵＥ１００は、タイマが満了した時点のサブフレームと、タイマが満了する直前のサブフレーム又はタイマが満了するサブフレームの規定時間前のサブフレームとにおいてのみ、ＰＤＣＣＨを監視してもよい。
なお、ｅＮＢ２００は、ＵＥ１００に設定されたタイマ値を把握しており、ＵＥ１００におけるＰＤＣＣＨ監視タイミングを推定できる。ｅＮＢ２００がＰＤＣＣＨ監視タイミングにおいて応答（例えば、データを伴うＭｓｇ４）をＵＥ１００に送信する場合、ＵＥ１００は、ＰＤＣＣＨ監視タイミングにおいて応答を受信できる。
ＵＥ１００は、変更例１６に係る動作を、以下の条件の少なくとも１つを満たした場合に限り実行してもよい。かかる条件は、従来のタイマ（Ｔ３００、Ｃｏｎｔｅｎｔｉｏｎ ｒｅｓｏｌｕｔｉｏｎ ｔｉｍｅｒ）を用いる場合に限り適用されるとしてもよい。
条件１：Ｍｓｇ１でアーリーデータ伝送の意図（ＥＤＴ Ｉｎｄｉｃａｔｉｏｎ）を通知したこと
条件２：Ｍｓｇ２でアーリーデータ伝送用の上りリンクグラント（一般的な上りリンクグラントよりもサイズが大きい）を受信したこと
条件３：Ｍｓｇ３でアーリーデータ伝送（データ送信）を実施したこと
（変更例１７）
上述した第１実施形態において、上りリンクのアーリーデータ伝送においてＵＥ１００が送信可能なデータ量の最大値をｅＮＢ２００がＵＥ１００に設定する一例について説明した。これにより、ＵＥ１００は、自身の上りリンクデータの全てを上りリンクのアーリーデータ伝送によって送信可能であるか否かを判定し、送信可能であると判定した場合にはアーリーデータ伝送を開始し、そうではない場合にはアーリーデータ伝送を開始しないようにすることが可能である。
上述したように、Ｍｓｇ３を利用した上りリンクのアーリーデータ伝送の後に、Ｍｓｇ４を利用した下りリンクのアーリーデータ伝送が続く場合、アップリンク（Ｍｓｇ３）及び下りリンク（Ｍｓｇ４）の１セットだけでデータ送受信を完了させることができる場合に限りアーリーデータ伝送を適用してもよい。よって、ＵＥ１００は自身の下りリンクデータの全てを下りリンクのアーリーデータ伝送によって受信可能であるか否かも判定し、受信可能であると判定した場合に限りアーリーデータ伝送を開始してもよい。
変更例１７において、下りリンクのアーリーデータ伝送においてＵＥ１００が受信可能なデータ量の最大値をｅＮＢ２００がＵＥ１００に設定する一例について主として説明する。また、変更例１７において、上りリンクのアーリーデータ伝送がＭｓｇ３を利用して行われ、下りリンクのアーリーデータ伝送がＭｓｇ４を利用して行われることを想定する。
変更例１７において、ｅＮＢ２００は、アーリーデータ伝送におけるデータ量条件に関する情報をブロードキャストメッセージ（ＳＩＢ）によりＵＥ１００に送信する。例えば、ｅＮＢ２００は、データ量条件に関する情報として、アーリーデータ伝送においてｅＮＢ２００が送信可能な下りリンクデータ量の最大値（最大トランスポートブロックサイズ）を示す情報を送信する。なお、ｅＮＢ２００がデータ量条件に関する情報を含むブロードキャストメッセージ（ＳＩＢ）を送信することにより、ＲＲＣアイドルモードにあるＵＥ１００であってもブロードキャストメッセージを受信できる。
ＵＥ１００は、データ量条件に関する情報をｅＮＢ２００から受信する。また、ＵＥ１００は、アーリーデータ伝送においてｅＮＢ２００から受信するべき下りリンクユーザデータの量を推定する。例えば、ＵＥ１００は、自身が実行するアプリケーションの種類等に基づいて、ｅＮＢ２００から受信するべき下りリンクユーザデータの量を推定する。具体的には、ＵＥ１００は、アーリーデータ伝送を利用可能なアプリケーションのプロトコル構成により下りリンクユーザデータの量を推定する。例えば、ＵＥ１００は、ＴＣＰレイヤを用いるアプリケーションである場合はＴＣＰのＡＣＫデータ量を下りリンクユーザデータの量と推定する。加えて、アプリケーションレイヤにおいてサーバからデータ受信完了のレスポンスなどがある場合、当該レスポンスデータ量を、当該下りリンクユーザデータの量に加える。このような推定は、アプリケーションレイヤにおいて実施されてもよく、当該下りリンクユーザデータの量はアプリケーションレイヤからＮＡＳレイヤ及び／又はＡＳレイヤへ通知されてもよい。もしくは、ＮＡＳレイヤ及び／又はＡＳレイヤで推定を実施する場合は、過去のアプリケーションレイヤの挙動の履歴を保持しておくことにより、当該履歴に含まれる過去の挙動から下りリンクユーザデータの量を推定することも可能である。
そして、ＵＥ１００は、推定された下りリンクユーザデータの量がデータ量条件を満たす場合に、アーリーデータ伝送を開始する。例えば、ＵＥ１００は、推定された下りリンクユーザデータの量が、ｅＮＢ２００から設定された最大下りリンクデータ量以下である場合に、アーリーデータ伝送を開始する。一方で、ＵＥ１００は、推定された下りリンクユーザデータの量が、ｅＮＢ２００から送信及び設定された最大下りリンクデータ量を上回る場合には、アーリーデータ伝送を開始せずに通常のランダムアクセスプロシージャを開始する。
ｅＮＢ２００は、データ量条件に関する情報として、アーリーデータ伝送においてｅＮＢ２００が送信可能な下りリンクデータ量の最小値（最小トランスポートブロックサイズ）を示す情報を送信してもよい。ＵＥ１００は、推定された下りリンクユーザデータの量が、ｅＮＢ２００から設定された最小下りリンクデータ量以上である場合に、アーリーデータ伝送を開始する。一方で、ＵＥ１００は、推定された下りリンクユーザデータの量が、ｅＮＢ２００から設定された最小下りリンクデータ量を下回る場合には、アーリーデータ伝送を開始せずに通常のランダムアクセスプロシージャを開始する。詳細については第２実施形態において説明するが、データ量が小さいとパディングビットが増えて効率が悪いため、ＲＲＣコネクティッドモードに遷移させてから必要最小限のリソースをｅＮＢ２００がＵＥ１００に割り当てることにより、パディングビットの増加を抑制できる。また、ＲＲＣコネクティッドモードに遷移させれば、例えば、複数ＵＥのデータを１つのリソース又はトランスポートブロックに多重化するような高度な処理や、単一ＵＥにおいてデータをその他シグナリングなどと一緒に送信するといった処理も可能である。
或いは、ＵＥ１００は、推定された下りリンクユーザデータの量が、ｅＮＢ２００から設定された最小下りリンクデータ量を下回る場合には、ランダムアクセスプロシージャを開始せずにＲＲＣアイドルモードを維持してもよい。
図２０は、変更例１７の動作の一例を示す図である。
図２０に示すように、ステップＳ７７１において、ｅＮＢ２００は、アーリーデータ伝送における最大下りリンクデータ量を示す最大下りリンクデータ量情報をブロードキャストで送信する。ＲＲＣアイドルモードにあるＵＥ１００は、ｅＮＢ２００から最大下りリンクデータ量情報を受信する。
ｅＮＢ２００は、アーリーデータ伝送における最大上りリンクデータ量を示す最大上りリンクデータ量情報をブロードキャストでさらに送信してもよい。ＲＲＣアイドルモードにあるＵＥ１００は、ｅＮＢ２００から最大上りリンクデータ量情報を受信する。
ステップＳ７７２において、ＵＥ１００は、ランダムアクセスプロシージャの開始契機を検知する。かかる開始契機は、例えば、送信すべき上りリンクデータがＵＥ１００において発生したこと、又はＵＥ１００がページングメッセージを受信したこと等である。
ステップＳ７７３において、ＵＥ１００は、アーリーデータ伝送においてｅＮＢ２００から受信するべき下りリンクユーザデータの量を推定する。具体的には、ＵＥ１００は、ｅＮＢ２００からＭｓｇ４送信時にＵＥ１００に送信される下りリンクユーザデータの量を推定する。
ステップＳ７７４において、ＵＥ１００は、推定した下りリンクユーザデータ量が、ｅＮＢ２００から設定された最大下りリンクデータ量以下であるか否かを判定する。推定した下りリンクユーザデータ量が最大下りリンクデータ量以下である場合（ステップＳ７７４：ＹＥＳ）、ステップＳ７７５において、ＵＥ１００は、アーリーデータ伝送を伴うランダムアクセスプロシージャを開始する。一方で、推定した下りリンクユーザデータ量が最大下りリンクデータ量を上回る場合（ステップＳ７７４：ＮＯ）、ステップＳ７７６において、ＵＥ１００は、アーリーデータ伝送を伴わない通常のランダムアクセスプロシージャを開始する。
なお、ステップＳ７７４において、ＵＥ１００は、送信すべき上りリンクユーザデータ量が、ｅＮＢ２００から設定された最大上りリンクデータ量以下であるか否かをさらに判定してもよい。ＵＥ１００は、推定した下りリンクユーザデータ量が最大下りリンクデータ量以下であり、かつ、推定した上りリンクユーザデータ量が最大上りリンクデータ量以下である場合に、アーリーデータ伝送を伴うランダムアクセスプロシージャを開始する。そうではない場合、ＵＥ１００は、アーリーデータ伝送を伴わない通常のランダムアクセスプロシージャを開始する。
なお、アーリーデータ伝送における最大上りリンクデータ量と最大下りリンクデータ量とが同じであると規定されている場合、ｅＮＢ２００は、最大下りリンクデータ量をＵＥ１００に通知しなくてもよい。かかる場合、ＵＥ１００は、推定した下りリンクデータ量が、ｅＮＢ２００から設定された最大上りリンクデータ量以下である場合に、アーリーデータ伝送が可能であると判定してもよい。
なお、図２０において、ｅＮＢ２００が、アーリーデータ伝送における最大下りリンクデータ量を示す最大下りリンクデータ量情報をブロードキャストで送信する一例について説明した。しかしながら、ｅＮＢ２００は、最大下りリンクデータ量情報をユニキャストで送信してもよい。かかるユニキャストメッセージを送信する場合、ｅＮＢ２００がＵＥ個別にデータ量条件を設定できる。
例えば、ｅＮＢ２００は、ＵＥ１００がＲＲＣコネクティッドモードであるときに、最大下りリンクデータ量情報を含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信する。ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージの受信に応じてＲＲＣアイドルモードに遷移するとともに、この最大下りリンクデータ量情報を記憶する。ここで、ｅＮＢ２００は、ＲＲＣアイドルモードのサブ状態であるサスペンド状態にＵＥ１００を移行させてもよい。サスペンド状態の場合、ＵＥ１００のコンテキスト情報がｅＮＢ２００において維持される。
そして、ＵＥ１００は、ＲＲＣアイドルモードにおいてランダムアクセスプロシージャを開始する。ＵＥ１００がサスペンド状態である場合、ｅＮＢ２００は、ランダムアクセスプロシージャの際にＵＥ１００のコンテキスト情報を参照し、このＵＥ１００に最大下りリンクデータ量が設定されていることを認識する。一方で、ＵＥ１００がサスペンド状態でない場合、ｅＮＢ２００は、ＵＥ１００のコンテキスト情報を有していないため、最大下りリンクデータ量が設定されていること及び／又は設定されている最大下りリンクデータ量を、ランダムアクセスプロシージャ中（例えば、Ｍｓｇ３送信時）にＵＥ１００からｅＮＢ２００に通知する。
（変更例１８）
上述したように、アーリーデータ伝送における最大データ量（最大トランスポートブロックサイズ）をｅＮＢ２００がＵＥ１００に設定する場合、ｅＮＢ２００が、最適な最大データ量を決定することが難しい。具体的には、ＵＥ１００がアーリーデータ伝送によって送受信するデータ量（トランスポートブロックサイズ）は、ＵＥ１００が実行するアプリケーションの種類や状況に応じて変化する。アーリーデータ伝送における最大データ量の設定が過大であると、無駄なリソースが発生し得る。一方で、アーリーデータ伝送における最大データ量の設定が過小であると、この最大トランスポートブロックサイズを超えるデータを送受信したいＵＥ１００がアーリーデータ伝送を利用できないため、アーリーデータ伝送による消費電力削減・遅延削減の効果が損なわれる。
変更例１８において、ＵＥ１００は、アーリーデータ伝送において送受信すべきユーザデータの量を判定する。例えば、ＵＥ１００は、上りリンクのアーリーデータ伝送によりＵＥ１００が送信したい上りリンクデータの量を判定する。かかる判定に加えて又はかかる判定に代えて、ＵＥ１００は、下りリンクのアーリーデータ伝送によりＵＥ１００が受信したい下りリンクデータの量を判定してもよい。そして、ＵＥ１００は、自身がＲＲＣコネクティッドモードにあるときに、判定されたユーザデータの量に基づいて、ＵＥ１００が推奨する最大データ量（最大トランスポートブロックサイズ）を示す情報をｅＮＢ２００に送信する。かかる推奨最大データ量は、上りリンクの推奨最大データ量であってもよいし、下りリンクの推奨最大データ量であってもよい。
かかる最大データ量の通知は、アーリーデータ伝送を行う能力を有するＵＥ１００のみが行うとしてもよい。かかる場合、ｅＮＢ２００は、ＵＥ１００からの通知をＵＥ能力情報としてＵＥコンテキストに保存してもよい。
ｅＮＢ２００は、アーリーデータ伝送についての推奨最大データ量の情報を多数のＵＥ１００から収集し、収集した情報に対する統計処理を行うことにより、アーリーデータ伝送における最適な最大データ量を決定する。例えば、ｅＮＢ２００は、上りリンクのアーリーデータ伝送についての推奨最大データ量の情報を収集し、収集した情報に基づいて、上りリンクのアーリーデータ伝送における最適な最大データ量を決定する。ｅＮＢ２００は、下りリンクのアーリーデータ伝送についての推奨最大データ量の情報を収集し、収集した情報に基づいて、下りリンクのアーリーデータ伝送における最適な最大データ量を決定してもよい。ｅＮＢ２００は、最適な最大データ量を決定した後、決定した最大データ量をＵＥ１００に設定する。例えば、ｅＮＢ２００は、決定した最大データ量を示す情報をブロードキャストすることにより、ｅＮＢ２００のセル内のＵＥ１００に当該最大データ量を設定する。
図２１は、変更例１８の動作の一例を示す図である。ここでは、Ｍｓｇ３を利用したアーリーデータ伝送における推奨最大上りリンクデータ量をＵＥ１００からｅＮＢ２００に通知する一例について説明する。なお、以下の例は、推奨最大上りリンクデータ量を例にして説明しているが、推奨最大下りリンクデータ量に置き換えても適用することができる。
図２１に示すように、ステップＳ７８１において、ｅＮＢ２００は、アーリーデータ伝送における推奨最大上りリンクデータ量の通知の送信を要求又は設定する情報をＵＥ１００に送信する。ｅＮＢ２００は、かかる情報を、ランダムアクセスプロシージャにおけるＭｓｇ４（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ メッセージ）、ユニキャストメッセージである測定設定（Ｍｅａｓｕｒｅｍｅｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）、ＵＥ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ及び／又はＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔ）の設定メッセージに含めてもよい。もしくは、ｅＮＢ２００は、ブロードキャストメッセージによって、当該通知を許可又は要求する情報をＵＥ１００に報知してもよい。但し、ステップＳ７８１は必須ではなく、省略可能である。
ステップＳ７８２において、ＵＥ１００は、アーリーデータ伝送における推奨最大上りリンクデータ量を決定する。例えば、ＵＥ１００は、上りリンクデータの発生に応じてランダムアクセスプロシージャを行う際に当該上りリンクデータの量を記憶しており、記憶している上りリンクデータの量を推奨最大上りリンクデータ量として決定する。
ステップＳ７８３において、ＵＥ１００は、決定した推奨最大上りリンクデータ量を示す情報をｅＮＢ２００に送信する。ＵＥ１００は、かかる情報を、測定報告に含めてもよいし、ランダムアクセスプロシージャのＭｓｇ５（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｃｏｍｐｌｅｔｅ）又はＵＥ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージに含めてもよい。なお、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ及びＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｃｏｍｐｌｅｔｅは、ランダムアクセスプロシージャの直後にＵＥ１００からｅＮＢ２００に送信されるメッセージと位置付けてもよい。
なお、ＲＲＣアイドルモードにあるＵＥ１００は、自身において発生した上りリンクデータの量が、ｅＮＢ２００から設定された最大上りリンクデータ量を超える場合には、アーリーデータ伝送を伴わない通常のランダムアクセスプロシージャを開始するとともに、当該上りリンクデータの量を記憶してもよい。そして、ＵＥ１００は、通常のランダムアクセスプロシージャによりＲＲＣコネクティッドモードに遷移した後に、記憶している上りリンクデータの量を推奨最大上りリンクデータ量としてｅＮＢ２００に通知してもよい。
ステップＳ７８４において、ｅＮＢ２００は、ＵＥ１００から通知された推奨最大上りリンクデータ量に基づいて最適な最大上りリンクデータ量を決定する。ｅＮＢ２００は、最適な最大上りリンクデータ量を決定した後、決定した最大上りリンクデータ量をブロードキャストすることにより、ｅＮＢ２００のセル内のＵＥ１００に当該最大上りリンクデータ量を設定する。
或いは、ｅＮＢ２００は、最大データ量（最大上りリンクデータ量）をブロードキャストでＵＥ１００に設定する場合に限らず、最大データ量をユニキャスト（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）でＵＥ１００に設定してもよい。かかる場合、ｅＮＢ２００は、ＵＥ１００から通知された推奨最大データ量に基づいて、当該ＵＥ１００に対して最適な最大データ量を決定し、決定した最大データ量をユニキャストで当該ＵＥ１００に設定する。
なお、本変更例において、ｅＮＢ２００が、ＵＥ１００から通知された推奨最大上りリンクデータ量に基づいて、ＵＥ１００に設定する最大上りリンクデータ量を決定する一例について説明した。しかしながら、詳細については第２実施形態において説明するが、最大上りリンクデータ量の範囲内で複数のブラインドデコーディング閾値をＵＥ１００に設定し得る。具体的には、ＵＥ１００は、自身が送信するユーザデータ量よりも大きい最小のブラインドデコーディング閾値を特定し、特定したブラインドデコーディング閾値に対する不足分をパディングデータにより埋める。よって、パディングデータを少なくするために、ｅＮＢ２００は、ＵＥ１００から通知された推奨最大上りリンクデータ量に基づいて、ＵＥ１００に設定するブラインドデコーディング閾値を決定してもよい。
［第２実施形態］
第２実施形態について、第１実施形態との相違点を主として説明する。第２実施形態においては、ランダムアクセスプロシージャ中にＭｓｇ３を利用して上りリンクのアーリーデータ伝送を行う場合を想定する。ＵＥ１００は、ランダムアクセスプロシージャ中にｅＮＢ２００に対してＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージ）の送信に加えてユーザデータの送信を行う。
ｅＮＢ２００は、ランダムアクセスプロシージャ中に、上りリンク無線リソースを割り当てる上りリンクグラントを含むＭｓｇ２（ランダムアクセス応答）をＵＥ１００に送信する。ＵＥ１００がＲＲＣメッセージ（Ｍｓｇ３）に伴うユーザデータをｅＮＢ２００に送信する場合、ＵＥ１００に割り当てられる上りリンク無線リソースに対応する割り当てデータサイズ（すなわち、トランスポートブロックサイズ）は、ＲＲＣメッセージ及びユーザデータの合計サイズと一致していることが望ましい。なお、トランスポートブロックサイズは、上りリンクグラントにより割り当てられる上りリンク無線リソースの量（例えば、リソースブロック数）及びＭＣＳによって定められる。ｅＮＢ２００は、ＵＥ１００に割り当てたトランスポートブロックサイズを想定して復号処理を行う。
しかしながら、ＵＥ１００に割り当てられるトランスポートブロックサイズは、ＲＲＣメッセージ及びユーザデータの合計サイズと一致しているとは限らない。ＵＥ１００に割り当てられるトランスポートブロックサイズがＲＲＣメッセージ及びユーザデータの合計サイズよりも大きい場合、ＵＥ１００は、ｅＮＢ２００が復号処理を適切に行うことができるように、余分に割り当てられた上りリンク無線リソース内においてパディングデータを送信する必要がある。ここで、余分に割り当てられた上りリンク無線リソースが多い場合、ＵＥ１００は多くのパディングデータを送信する必要があり、パディングデータを送信するためにＵＥ１００の消費電力が増大する問題がある。第２実施形態は、かかる問題点を解決するための実施形態である。
（１）動作パターン１
第２実施形態の動作パターン１において、ｅＮＢ２００は、ランダムアクセスプロシージャ中に、周期的な上りリンク無線リソースを割り当てる上りリンクグラントをＵＥ１００に送信する。かかるリソース割り当ては、セミパーシステントスケジューリング（ＳＰＳ）と称されることがある。但し、従来のＳＰＳは、ランダムアクセスプロシージャ中に適用されない。
第２実施形態の動作パターン１に係るＳＰＳにおいて、ＳＰＳの設定情報（例えば、上りリンク送信周期）は、ｅＮＢ２００によってＵＥ１００に送信されるＳＩＢに含まれる。また、動作パターン１において、Ｍｓｇ２によりＵＥ１００に送信される上りリンクグラントは、ＵＥ１００に割り当てる上りリンク無線リソース（リソースブロック）の情報を含み、かつ、ＳＰＳをアクティブ化させるものである。すなわち、かかる上りリンクグラントは、ＵＥ１００に周期的な上りリンク無線リソースを割り当てる。
ＵＥ１００は、かかる上りリンクグラントの受信に応じて、ランダムアクセスプロシージャ中に、周期的な上りリンク無線リソースを用いて複数回の上りリンク送信を行う。具体的には、ＵＥ１００は、ＳＰＳ設定情報に従った上りリンク送信周期で、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いて上りリンク送信を行う。
このようにして、ＵＥ１００が複数回の上りリンク送信を行うことにより、１回の上りリンク送信に用いる上りリンク無線リソースの量を少なくすることができる。また、ＵＥ１００は、ＲＲＣメッセージとユーザデータとを異なるタイミング（異なるサブフレーム）で送信できる。例えば、ＵＥ１００は、複数回の上りリンク送信において、１回目の上りリンク送信において少なくともＲＲＣメッセージを送信し、２回目の上りリンク送信においてユーザデータの少なくとも一部を送信する。よって、ＵＥ１００は、多くのパディングデータを送信する必要がない。
また、第２実施形態の動作パターン１において、ｅＮＢ２００は、周期的な上りリンク無線リソースを用いた上りリンク送信の最大送信回数を設定する情報をＵＥ１００に送信する。これにより、ｅＮＢ２００は、上りリンクデータの復号処理を行うべき回数を適切に把握できる。ｅＮＢ２００は、最大送信回数を設定する情報をＳＩＢにより送信してもよいし、上りリンクグラント（Ｍｓｇ２）により送信してもよい。ＵＥ１００は、設定された最大送信回数を超えない範囲内において複数回の上りリンク送信を行う。
図２２は、第２実施形態の動作パターン１の一例を示す図である。初期状態においてＵＥ１００はＲＲＣアイドルモードであってもよい。
図２２に示すように、ステップＳ８０１において、ｅＮＢ２００は、ＳＰＳ設定情報をＳＩＢにより送信する。ＵＥ１００は、ＳＰＳ設定情報を受信して記憶する。ｅＮＢ２００は、最大送信回数を設定する情報をＳＩＢにより送信してもよい。ここでは最大送信回数が３回であると仮定して説明を進める。
ステップＳ８０２において、ＵＥ１００は、ランダムアクセスプリアンブル（Ｍｓｇ１）をｅＮＢ２００に送信する。
ステップＳ８０３において、ｅＮＢ２００は、ＳＰＳをアクティブ化させる上りリンクグラントを含むランダムアクセス応答（Ｍｓｇ２）をＵＥ１００に送信する。上りリンクグラントは、１回分の上りリンク送信に用いるべき上りリンク無線リソース（リソースブロック）の情報を含む。ここで、１回分のリソース割り当てサイズ（トランスポートブロックサイズ）は、ＲＲＣメッセージのサイズと合致させてもよい。ｅＮＢ２００は、最大送信回数（３回）を設定する情報をＭｓｇ２により送信してもよい。
ステップＳ８０４（１回目の上りリンク送信）において、ＵＥ１００は、上りリンクグラントの受信に応じて、割り当てられた上りリンク無線リソース（リソースブロック）を用いてＲＲＣメッセージ（Ｍｓｇ３）をｅＮＢ２００に送信する。
ステップＳ８０５（２回目の上りリンク送信）において、ＵＥ１００は、ＳＰＳ送信周期に従ったサブフレームにおいて、割り当てられた上りリンク無線リソース（リソースブロック）を用いて、ユーザデータの一部をｅＮＢ２００に送信する。
ステップＳ８０６（３回目の上りリンク送信）において、ＵＥ１００は、ＳＰＳ送信周期に従ったサブフレームにおいて、割り当てられた上りリンク無線リソース（リソースブロック）を用いて、残りのユーザデータをｅＮＢ２００に送信する。ここで、上りリンク送信回数が最大送信回数に達したため、ＵＥ１００は、ＳＰＳを非アクティブ化する。また、ＵＥ１００は、ＳＰＳ設定情報を破棄してもよい。
なお、最大送信回数に達する前にユーザデータの送信が終了した場合（例えば、ステップＳ８０５で全てのユーザデータを送信した場合）、ＵＥ１００は、ＳＰＳ送信周期に従ったサブフレーム（ステップＳ８０６のタイミング）において上りリンク送信を行わなくてもよい。或いは、ＵＥ１００は、最後の上りリンク送信の際（ステップＳ８０６のタイミング）に、データ送信の終了を示す情報をｅＮＢ２００に送信してもよい。かかる情報（エンドマーカ）は、ＭＡＣ ＣＥにより送信されてもよい。
ステップＳ８０７において、ｅＮＢ２００は、Ｍｓｇ４をＵＥ１００に送信する。ｅＮＢ２００は、複数回の上りリンク送信のうち、どの上りリンク送信の受信処理に成功したか、及び／又はどの上りリンク送信の受信処理に失敗したかをＭｓｇ４によりＵＥ１００に通知してもよい。例えば、ｅＮＢ２００は、１回目のみ受信ＯＫであったことを通知したり、２回目以降も受信ＯＫであったことを通知したりする。
なお、本動作パターンにおいては、ＵＥ１００がＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔの入ったＭＡＣ ＰＤＵ）の送信後にユーザデータを送信する一例を説明したが、ＵＥ１００は、ユーザデータを先に送信し、データ送信が終了した後にＲＲＣメッセージを送信してもよい。かかる場合、ｅＮＢ２００は、このＲＲＣメッセージの受信により、ユーザデータの送信が終了したことを認識できる。
（２）動作パターン２
第２実施形態の動作パターン２において、ｅＮＢ２００は、ランダムアクセスプロシージャ中に、上りリンク無線リソースを割り当てる上りリンクグラントをＭｓｇ２によりＵＥ１００に送信する。
ＵＥ１００は、上りリンクグラントの受信に応じて、ランダムアクセスプロシージャ中に、上りリンク無線リソースを用いてＲＲＣメッセージ（Ｍｓｇ３）の繰り返し送信を行う。これにより、ＲＲＣメッセージに冗長性を持たせて、ｅＮＢ２００がＲＲＣメッセージの受信処理（復号処理）に成功する確率を高めることができる。ＵＥ１００は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いて、ＲＲＣメッセージの繰り返し送信に加えて、ユーザデータの繰り返し送信を行ってもよい。これにより、ユーザデータにも冗長性を持たせることができる。
ｅＮＢ２００は、復号処理において、繰り返し送信されたＲＲＣメッセージのソフト合成及び繰り返し送信されたユーザデータのソフト合成を行う。このように、第２実施形態の動作パターン２においては、パディングデータの送信に代えて冗長送信を行うことにより、上りリンクグラントにより割り当てられた上りリンク無線リソースを有効に活用できる。
・ＨＡＲＱリダンダンシーバージョン
ＵＥ１００は、ＲＲＣメッセージの繰り返し送信において、ＨＡＲＱリダンダンシーバージョン（すなわち、冗長構成）の異なるＲＲＣメッセージを送信してもよい。また、ＵＥ１００は、ユーザデータの繰り返し送信において、ＨＡＲＱリダンダンシーバージョンの異なるユーザデータを送信してもよい。これにより、ｅＮＢ２００における復号成功率をさらに高めることができる。
例えば、ＵＥ１００は、複数のＲＲＣメッセージ（又は複数のユーザデータ）を互いに異なるＭＡＣ ＰＤＵに格納し、ＨＡＲＱリダンダンシーバージョンの異なる複数のＭＡＣ ＰＤＵからなるセットを送信する。ＭＡＣ ＰＤＵは、ＭＡＣヘッダと、ＭＡＣ ＣＥと、ＭＡＣ ＳＤＵとを含む（図１６参照）。ＲＲＣメッセージ（又はユーザデータ）は、ＭＡＣ ＳＤＵに相当する。
なお、冗長送信の第１の例として、ＭＡＣ ＳＤＵのみを冗長化し、１つのＭＡＣ ＰＤＵ内に複数のＭＡＣ ＳＤＵを格納して送信してもよい。かかる場合、リダンダンシーバージョンは１つだけとしつつ、次のような方法で冗長化によるゲインを得ることができる。具体的には、ＵＥ１００は、レートマッチング前のビット列生成の際にはＲＲＣメッセージ及びユーザデータのサイズに相当するビット長（ＴＢＳサイズ１）から生成する。そして、ＵＥ１００は、レートマッチング処理時に、送信するビット列を循環バッファ（ｃｉｒｃｕｌａｒ ｂｕｆｆｅｒ）から取り出す際には、ｅＮＢ２００より割り当てられたリソース・ＭＣＳに応じたビット長を取り出す。これにより、リダンダンシーバージョンは１つだけであるが、循環バッファの同じ部分を繰り返す場合に比べて冗長化によるゲインが得られる。ｅＮＢ２００は、総当たり復号（ブラインドデコーディング）の際に、ｅＮＢ２００より割り当てられたリソース・ＭＣＳに相当するビット長（ＴＢＳサイズ２、ｅＮＢ２００にとって既知）に応じて、ＴＢＳサイズ１（ｅＮＢ２００にとって未知）を、ＴＢＳサイズ２の３／４、ＴＢＳサイズ２の１／２、ＴＢＳサイズ２の１／４といったように所定の比率で定義するようにしておくことで、ブラインドデコードが可能である。
冗長送信の第２の例として、ＭＡＣヘッダも含めて冗長化し、ＨＡＲＱリダンダンシーバージョンの異なる複数のＭＡＣ ＰＤＵを送信してもよい。
・送信電力
繰り返し送信（冗長送信）を行う場合、ＵＥ１００は、繰り返し送信を行わない場合に比べて送信電力を低下させてもよい。これにより、ＵＥ１００の消費電力を削減できる。
ＵＥ１００は、繰り返し送信回数に応じて送信電力を調整する。ＵＥ１００は、繰り返し送信回数が多いほど、送信電力を低下させてもよい。例えば、ＵＥ１００は、３個のＭＡＣ ＰＤＵを冗長送信する場合、１個のＭＡＣ ＰＤＵを送信する場合に比べて、送信電力を３分の１としてもよい。なお、送信電力を低下させても、ｅＮＢ２００におけるソフト合成ゲインで補うことが可能である。
・ソフト合成の具体例１
ＵＥ１００は、繰り返し送信を行う場合に、当該繰り返し送信を行うこと（及び／又は繰り返し送信回数）をｅＮＢ２００に通知してもよい。これにより、ｅＮＢ２００は、適切なソフト合成を行うことができる。
かかる通知の具体例として、ＵＥ１００は、Ｍｓｇ３における上りリンクの復調参照信号（ＤＭＲＳ）のパターンにより通知を行なってもよい。ＤＭＲＳのパターンとは、ＤＭＲＳの信号系列であってもよいし、ＤＭＲＳのリソース配置パターン（例えば、リソースエレメントの配置パターン）であってもよい。
ＵＥ１００は、繰り返し送信を行う場合と行わない場合とでＤＭＲＳのパターンを異ならせる。ＵＥ１００は、繰り返し送信回数に応じてＤＭＲＳのパターンを異ならせてもよい。
・ソフト合成の具体例２
繰り返し送信の通知を送信することに代えて、ｅＮＢ２００は、繰り返し送信回数の候補の数だけ受信処理（復号処理）を試行してもよい。ここで繰り返し送信回数の候補はゼロ（すなわち、繰り返し送信を行わない）を含む。
このように、ｅＮＢ２００は、ブラインドデコーディングにより、繰り返し送信されたＲＲＣメッセージ（及び繰り返し送信されたユーザデータ）を総当たりで復号する。これにより、繰り返し送信の通知が無くても、ｅＮＢ２００が適切なソフト合成を行うことができる。
繰り返し送信されたＲＲＣメッセージ（及び繰り返し送信されたユーザデータ）をｅＮＢ２００がブラインドデコーディングにより復号するために、以下のような方法を適用する。図２３Ａおよび図２３Ｂは、第２実施形態の動作パターン２に係る繰り返し送信方法の一例を示す図である。
ＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）及びユーザデータ（Ｄａｔａ）の合計サイズが割り当てデータサイズよりも大きい場合において、ＵＥ１００は、図２３Ａに示すように、予め規定された繰り返し送信パターンに従って繰り返し送信を行う。ｅＮＢ２００は、予め規定された繰り返し送信パターンに従ってブラインドデコーディングを行う。
図２３Ａの例では、上りリンクグラント（ＵＬ ｇｒａｎｔ）により割り当てられた割り当てデータサイズは、ＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）及びユーザデータ（Ｄａｔａ）の合計サイズの２倍よりも大きい。かかる場合、割り当てデータサイズの２分の１のサイズを１単位として、この単位ごとに繰り返し送信を行う。また、割り当てデータサイズの２分の１のサイズに満たない部分についてはパディングデータを配置する。ｅＮＢ２００は、割り当てデータサイズの２分の１のサイズを１単位として、この単位ごとにブラインドデコーディングを行う。
或いは、ＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）及びユーザデータ（Ｄａｔａ）の合計サイズが割り当てデータサイズよりも大きい場合において、ＵＥ１００は、ＲＲＣメッセージのみを繰り返し送信してもよい。ＲＲＣメッセージのデータサイズは既知であるため、ｅＮＢ２００は、ＲＲＣメッセージのみが繰り返し送信されていると仮定してブラインドデコーディングを行う。
一方、ＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）及びユーザデータ（Ｄａｔａ）の合計サイズが割り当てデータサイズよりも小さい場合において、ＵＥ１００は、図２３Ｂに示すように、予め規定された繰り返し送信パターンに従って繰り返し送信を行う。例えば、割り当てデータサイズがＲＲＣメッセージのデータサイズの２倍以上である場合、ＵＥ１００は、ＲＲＣメッセージの繰り返し送信を行う。ＵＥ１００は、余りの部分についてはパディングデータを配置する。ｅＮＢ２００は、ＲＲＣメッセージのみが繰り返し送信されていると仮定してブラインドデコーディングを行う。
ＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）及びユーザデータ（Ｄａｔａ）の合計サイズが割り当てデータサイズよりも小さい場合において、ｅＮＢ２００は、ＲＲＣメッセージのみが繰り返し送信されているケース、ＲＲＣメッセージのみが送信されているケース、及びＲＲＣメッセージと共にユーザデータが送信されているケースの３パターンそれぞれについて復号を試みても良い。
なお、ＵＥ１００は、どのような繰り返し送信パターンを適用するかを示す情報を、ＲＲＣメッセージに付随するＭＡＣヘッダ又はＭＡＣ ＣＥ等によりｅＮＢ２００に通知してもよい。
（３）動作パターン３
第２実施形態の動作パターン３において、ｅＮＢ２００は、アーリーデータ伝送におけるユーザデータの送信に使用可能な複数のリソースプールを示す情報を例えばＳＩＢによりブロードキャストする。複数のリソースプールは、使用可能な無線リソースの量（すなわち、使用可能なトランスポートブロックサイズ）が互いに異なっている。
ＵＥ１００は、ｅＮＢ２００からの上りリンクグラントの受信に応じてアーリーデータ伝送を行う際に、複数のリソースプールの中から選択したリソースプールを用いてユーザデータを送信する。これにより、ＵＥ１００が送信したいユーザデータの量（サイズ）に見合ったリソースプールを選択可能になるため、送信すべきパディングデータをなくす又は削減することができる。なお、ｅＮＢ２００は、各リソースプールにおいてユーザデータの受信（復号）を試みて、いずれかのリソースプールにおいてユーザデータを受信（復号）する。
ＵＥ１００は、選択したリソースプールを用いてユーザデータ及びＲＲＣメッセージを纏めて送信してもよい。或いは、ＵＥ１００は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いてＲＲＣメッセージを送信し、その後、選択したリソースプールを用いてユーザデータを送信してもよい。
ＵＥ１００は、ユーザデータの量に基づいて、複数のリソースプールの中からユーザデータの送信に用いるリソースプールを選択してもよい。例えば、ＵＥ１００は、ｅＮＢ２００に送信するユーザデータの量（データサイズ）と、各リソースプールに対応するトランスポートブロックサイズとを比較し、最適なリソースプールを選択する。
ＵＥ１００は、ユーザデータの優先度を考慮してリソースプールを選択してもよい。例えば、選択したリソースプール内で、送信に用いる上りリンク無線リソース（リソースブロック）を選択可能である場合、リソースプールが大きいほど、ＵＥ１００間のリソースの衝突に起因する干渉が生じる可能性が低い。よって、ＵＥ１００は、高優先度である場合に、より大きいリソースプールを選択してもよい。或いは、ｅＮＢ２００は、リソースプール毎に、使用可能な優先度情報を通知してもよい。なお、ＵＥ１００において、優先度は上位レイヤ（例えばアプリケーションレイヤ）で特定され、上位レイヤからＡＳ（例えばＲＲＣレイヤ、ＭＡＣレイヤ）に通知されてもよい。優先度は、アプリケーションサーバによってＵＥ１００に予め設定される、又はＭＭＥなどが認証してＵＥ１００に設定してもよい。また、リソースプールは、ＣＥレベル毎に提供されてもよい。
図２４は、第２実施形態の動作パターン３の一例を示す図である。図２４において、時間方向の１つの区画は１つのサブフレームに相当し、時間方向は上りリンク周波数帯に相当する。
まず、ＵＥ１００は、ＳＩＢを受信することによりユーザデータ用のリソースプール及びランダムアクセスプリアンブル（Ｍｓｇ１）用のリソースプールを把握する。そして、ＵＥ１００は、図２４に示すように、サブフレームＳＦａにおいて、ランダムアクセスプリアンブル用の複数のリソースプールの中から１つのリソースプールを選択し、選択したリソースプールを用いてランダムアクセスプリアンブルを送信する。図２４の例では、ランダムアクセスプリアンブル用のリソースプール＃１はユーザデータ用のリソースプール＃１（例えば、１０００ビットのサイズ）と対応付けられており、ランダムアクセスプリアンブル用のリソースプール＃２はユーザデータ用のリソースプール＃２（例えば、１００ビットのサイズ）と対応付けられている。但し、ランダムアクセスプリアンブル用のリソースプールが１つのみであり、ランダムアクセスプリアンブル用のリソースプールとユーザデータ用のリソースプールとが対応付けられていなくてもよい。
次に、ｅＮＢ２００は、いずれかのリソースプールにおいてランダムアクセスプリアンブルを受信し、このリソースプールの使用を許可する場合にはランダムアクセス応答（Ｍｓｇ２）をＵＥ１００に送信する。Ｍｓｇ２は、ｅＮＢ２００がＵＥ１００に割り当てた一時的な識別子（Ｔｅｍｐｏｒａｒｙ Ｃ−ＲＮＴＩ）を含む。ＵＥ１００は、Ｍｓｇ２を受信した場合、アーリーデータ伝送が許可されたと見なす。そして、ＵＥ１００は、サブフレームＳＦｂにおいて、ランダムアクセス応答における上りリンクグラントにより割り当てられた上りリンク無線リソースを用いて、ＲＲＣメッセージ（Ｍｓｇ３）をｅＮＢ２００に送信する。ＵＥ１００は、一時的な識別子（Ｔｅｍｐｏｒａｒｙ Ｃ−ＲＮＴＩ）をＲＲＣメッセージに含めて送信する。
次に、ＵＥ１００は、サブフレームＳＦｃにおいて、選択したリソースプールを用いてユーザデータをｅＮＢ２００に送信する。ＵＥ１００は、一時的な識別子（Ｔｅｍｐｏｒａｒｙ Ｃ−ＲＮＴＩ）をユーザデータに含めて送信する。
（４）動作パターン４
第２実施形態の動作パターン４において、ｅＮＢ２００は、ランダムアクセスプロシージャ中に、上りリンク無線リソースを割り当てる上りリンクグラントをＵＥ１００に送信する。ＵＥ１００は、上りリンクグラントに対応する割り当てデータサイズがＲＲＣメッセージ及びユーザデータの合計サイズよりも大きい場合、上りリンク無線リソースを用いてアーリーデータ伝送を行うか、又は上りリンク無線リソースを用いてＲＲＣメッセージのみを送信するか判断する。ＵＥ１００は、アーリーデータ伝送を行うために必要なパディングデータの量に基づいて、かかる判断を行う。ｅＮＢ２００は、ＵＥ１００がＲＲＣメッセージのみを送信するケース及びＵＥ１００がアーリーデータ伝送を行うケースの両方について受信処理（復号処理）を試みる。
ＲＲＣメッセージのみを送信する場合、ｅＮＢ２００がＲＲＣメッセージのデータサイズを把握可能であるため、ＵＥ１００によるパディングデータの送信は不要である。一方、アーリーデータ伝送を行う場合、すなわち、ＲＲＣメッセージと共にユーザデータを送信する場合、ｅＮＢ２００がユーザデータの量を把握していない。このため、割り当てデータサイズでの送信を行うためにＵＥ１００によるパディングデータの送信が必要になり得る。
例えば、ＵＥ１００は、割り当てデータサイズに基づいて、アーリーデータ伝送を行うために必要なパディングデータの量を判定する。判定したパディングデータの量が閾値よりも多い場合、ＵＥ１００は、パディングデータの送信に起因する消費電力が大きいとみなして、アーリーデータ伝送を行わずに、ＲＲＣメッセージのみを送信する。これにより、パディングデータの送信に起因するＵＥ１００の消費電力の増加を回避できる。
［その他の実施形態］
第２実施形態と第１実施形態及びその変更例とを組み合わせて実施してもよいし、第１実施形態の変更例１〜１５において２以上の変更例を組み合わせて実施してもよい。また、第１実施形態の変更例１〜１５は、第１実施形態に係る動作を前提とせずに、変更例に係る動作を単独で実施してもよい。
上述した実施形態及びその変更例において、ＣＰ（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）ソリューション及びＵＰ（Ｕｓｅｒ Ｐｌａｎｅ）ソリューションを特に区別していなかったが、実施形態及びその変更例に係る動作をＣＰソリューション及びＵＰソリューションの両方に適用可能である。ＣＰソリューションでは、アーリーデータ伝送において、データをＲＲＣメッセージに含める。ＵＰソリューションでは、アーリーデータ伝送において、データをＲＲＣメッセージに含めずに、ＭＡＣレイヤにおいてデータ（ＤＴＣＨ）とＲＲＣメッセージ（ＣＣＣＨ）とを多重化して送信する。
ＵＰソリューションでは、Ｍｓｇ３に対応するＲＲＣメッセージがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージであり、Ｍｓｇ４に対応するＲＲＣメッセージがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅメッセージである。通常、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅを受信すると、ＰＤＣＰエンティティを確立（再確立）する。しかしながら、アーリーデータ伝送を行う場合、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅを受信する前に、データ送信を行うためにＰＤＣＰエンティティを既に確立（再確立）していると考えられる。よって、ＵＥ１００は、アーリーデータ伝送を行うためにＰＤＣＰエンティティを確立（再確立）した後、アイドルモードからコネクティッドモードへの遷移指示（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ）をｅＮＢ２００から受信し得る。この場合、ＵＥ１００は、ＰＤＣＰエンティティの確立（再確立）をスキップし、確立済みのＰＤＣＰエンティティを維持してもよい。
上述した実施形態において、ＭＴＣやＩｏＴを対象とした無線端末（ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥ）を用いる一例を説明した。しかしながら、本開示はｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥに限定されない。一般的なＵＥに対して、上述した実施形態に係る動作を適用してもよい。
実施形態では、主にＲＲＣアイドル、サスペンド、コネクテッドを例に挙げて説明したが、これに限らない。ＲＲＣライトコネクションやＩＮＡＣＴＩＶＥの状態に適用してもよい。ＲＲＣライトコネクションは、ＲＲＣコネクティッドモードの一状態であって、ＲＲＣアイドルモードのプロシージャの一部が適用される特殊な状態である。ＩＮＡＣＴＩＶＥは、第５世代移動通信システムにおいて導入されることが想定されており、ＲＲＣコネクティッドモード及びＲＲＣアイドルモードとは異なるＲＲＣ状態である。上述した実施形態における「ＲＲＣアイドルモード」を「ＩＮＡＣＴＩＶＥモード」と読み替えてもよい。
実施形態では強化カバレッジに居るＵＥを例に挙げて説明したが、これに限らない。ノーマルカバレッジに居るＵＥに対して、上述した実施形態に係る動作を適用してもよい。具体的には、ＲＡＣＨプロシージャにおいて、ＲＳＲＰ測定に基づくＣＥレベル判定を行わなくてもよい。
上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本開示はＬＴＥシステムに限定されない。ＬＴＥシステム以外の移動通信システム（例えば、第５世代移動通信システム）に対して、上述した実施形態に係る動作を適用してもよい。
ＵＥ１００及びｅＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
［付記１］
（１．はじめに）
ＬＴＥ用のさらに強化されたＭＴＣ（ｅＦｅＭＴＣ）の新しいワークアイテムはＲＡＮ＃７５で承認され、ＷＩＤはＲＡＮ２が主要なＷＧとして考慮すべきいくつかの目標を特定する。目的は、ＢＬ／ＣＥ ＵＥのためのマシンタイプ通信のために以下の改善を指定することである。［．．．］
改善された遅延：
［．．．］
・アーリーデータ伝送をサポートする［ＲＡＮ２主導、ＲＡＮ１、ＲＡＮ３］
・少なくともＲＲＣサスペンド／レジュームの場合、ランダムアクセスプロシージャ（ＰＲＡＣＨ送信後かつＲＲＣ接続セットアップが完了する前）中の専用リソース上での電力消費／待ち時間利得の評価及びＤＬ／ＵＬデータ送信の必要なサポートの指定。
この付記では、これらの改善のための検討事項について検討する。
（２．検討）
（２．１．改善されたレイテンシ − アーリーデータ伝送）
ＷＩＤは、「少なくともＲＲＣサスペンド／レジュームのケースにおいて、ランダムアクセスプロシージャ（ＰＲＡＣＨ送信後、ＲＲＣ接続セットアップが完了する前に）中の専用リソース上の電力消費／待ち時間利得を評価し、ＤＬ／ＵＬデータ送信に必要なサポートを指定する」と明確と述べている。アーリーデータ伝送による遅延性能の向上は、さまざまなＭＴＣデバイスの実装を考慮して、追加の電力消費につながる可能性がある。追加の電力消費がいくつかのＭＴＣ実装で必要になる場合、ＵＥは、レガシー・ユース・ケースの負担を避けるために、レガシーＲＡＣＨプロシージャ、すなわち、非アーリーデータ伝送モードを選択することを許可されるべきである。
提案１：アーリーデータ伝送のソリューションは、追加の電力消費を最小限に抑えるべきである。例えば、ＵＥは、レガシーＲＡＣＨプロシージャ、すなわち「非アーリーデータ伝送モード」を選択することを許可されるべきである。
ＷＩＤはまた、アーリーデータ伝送がＭｓｇ１の後で実行されるべきであり、Ｍｓｇ５の前に実行されるべきであること、すなわち、拡張の候補がＭｓｇ２、Ｍｓｇ３及びＭｓｇ４であることを述べている。他方で、何らかの制御シグナリングがＭｓｇ２の前やＭｓｇ４の後でさえも送信されることが可能であることが期待できる。
提案２：アーリーデータ伝送に関連する制御シグナリングがメッセージ２、メッセージ３、メッセージ４に送信されることが必要とされる必要はない。
アーリー伝送のためのデータが小さなパケット、大きなサイズのデータ及び／又は両方として想定されているかどうかは、ＷＩＤにおいて識別されていない。例えば、小さなデータのみが想定される場合、例えば、ＲＡＣＨプロシージャ内であっても、データ送信が完了するとすぐにＵＥがＲＲＣ ＩＤＬＥに遷移する方が良い場合がある。アーリー伝送のためのデータサイズによってソリューションが異なると考えられる。したがって、ＲＡＮ２はまずデータサイズの仮定を検討し、決定すべきである。
提案３：ＲＡＮ２は、アーリー伝送のために仮定されたデータサイズ（すなわち、小さなパケット、大きいパケット、又はその両方）を検討すべきである。
アーリーデータ伝送が、競合ベースのＲＡＣＨプロシージャ、競合のないＲＡＣＨプロシージャ、又はその両方においてのみ開始され得るかどうかについては、ＷＩＤは明確に言及していない。ソリューションの仮定は、２つのプロシージャ間で異なり、例えば、ＰＤＣＣＨ命令が仮定され得るかどうかは異なる。したがって、ＲＡＮ２は、アーリーデータ伝送のための仮定であるＲＡＣＨプロシージャを明確にすべきである。
提案４：ＲＡＮ２は、アーリーデータ伝送が競合ベースのＲＡＣＨプロシージャ、競合のないＲＡＣＨプロシージャ、又はその両方に適用可能かどうかを検討すべきである。
図２５に、一般的なＲＡＣＨプロシージャ（競合ベース／フリー）を示す。
（２．２．電力消費の改善−セル再選択のための緩やかなモニタ）
ＷＩＤは、「（再）設定によって、セル（再）選択のための軽減されたＵＥモニタリングを可能にする」と述べている。（再）設定の必要性にかかわらず、固定のＵＥは、セルの再選択がまれであるため、緩やかなモニタを実行することを許可されるべきである。ＷＩＤにおいて意図されたように（再）設定が必要な場合、ネットワークがＩＤＬＥモードＵＥがセル再選択を実行するかどうかを知ることができないので、いくつかのＵＥアシスタント情報、例えば、セル再選択の報告の数や固定ＵＥインディケーション等が必要になり得る。
提案５：固定ＵＥがセル再選択のための緩やかなモニタ下で動作することが許可されるかどうかを設定可能でなければならない。
［付記２］
（１．はじめに）
ＲＡＮ２＃９９はＬＴＥ（ｅＦｅＭＴＣ）のさらに高度なＭＴＣの検討を開始し、アーリーデータ伝送の機能に関する合意は以下のように達成された。
合意事項
制御プレーンとユーザプレーンＣＩｏＴＥＰＳ最適化のためのＭｓｇ３におけるアーリーＵＬデータ伝送をサポートする。
制御プレーン及びユーザプレーンＣＩｏＴＥＰＳ最適化のためのＭｓｇ４におけるアーリーＤＬデータ送信をサポートする。
合意事項
アーリーデータ伝送機能は、ＣＰを使用してデータを送信するだけのＡＳセキュリティが確立されていない場合に考慮される。
アーリーデータ伝送機能は、ＣＰ及び／又はＵＰを使用してデータを送信するためにＡＳセキュリティが確立されたときに考慮される。
この付記では、アーリーデータ伝送に必要な拡張の詳細について説明する。
（２．検討）
以下のセクションでは、説明を簡単にするために、アーリーＵＬデータ送信及びアーリーＤＬデータ送信を別々に説明し、既存のランダムアクセスプロシージャをベースラインとみなす。
（２．１．アーリーＵＬデータ伝送）
（２．１．１．Ｅメールディスカッションの明確化）
ＵＥがＭｓｇ３でアーリーＵＬデータ送信を実行しようとする場合、ＳＩＢはＭｓｇ１で使用される特定のプリアンブルを提供する。換言すれば、ＳＩＢが特定のプリアンブルを有するそのようなインディケーションを含まない場合、アーリーＵＬデータ送信は許可されない。
・Ｍｓｇ１は、アーリーＵＬデータ送信がこのランダムアクセスプロシージャにあるかどうかにかかわらず、特定のプリアンブルでＵＥの意図を含む。
・Ｍｓｇ２は、既存のランダムアクセス応答に加えて、ＵＥの意図が受け入れられるかどうかを示する。
・Ｍｓｇ３は、このランダムアクセスプロシージャ内でデータ送信が完了したかどうか、すなわちＵＥがＲＲＣ Ｃｏｎｎｅｃｔｅｄに移行する必要があるかどうかをｅＮＢに通知するためのデータ及び拡張ＲＲＣ接続（再開）要求を含む。
・Ｍｓｇ４は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ／Ｒｅｓｕｍｅ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅのいずれかである可能性がある。つまり、Ｍｓｇ４でネットワークが応答し、Ｍｓｇ３の受信が競合解消を完了し、必要に応じてＮＡＳ ＰＤＵを含むことを確認する。
ｅＮＢの観点からは、ＳＩＢがアーリーＵＬデータ送信が許可されているか否か、すなわちＵｐ−ＣＩｏＴ−ＥＰＳ−最適化などのようなＳＩＢインディケーションが最小限であることを示すことが必要である。次に、ＵＥは、ｅＮＢにアーリーＵＬデータ送信を使用する意図を示すために、メッセージ１に特定のプリアンブルを含めることができる。しかしながら、たとえＵＥがＭｓｇ１に特定のプリアンブルを含むとしても、ｅＮＢはアーリーＵＬデータ送信を拒絶する必要がある他の理由があるかもしれないので、アーリーＵＬデータ送信を受け入れるかどうかを決定する選択肢を依然として有するべきである。これは、Ｍｓｇ２を介してＵＥに伝えられてもよい。したがって、アーリーＵＬデータ送信が承認される前に２段階の許可が必要である。
提案１：ＲＡＮ２は、ＳＩＢに提供された特定のプリアンブルをＭｓｇ１に送信してｅＮＢに対してＭｓｇ３におけるアーリーデータ伝送を行う旨を通知し、ｅＮＢはＭｓｇ２においてアーリーデータ伝送が許容可能である否かを通知することに合意すべきである。
アーリーデータ伝送の主な目的の１つは、ＵＥの電力消費を低減することであるので、データ送信が完了するとすぐに、ＵＥはＩＤＬＥに解放されるべきである。ＲＡＩ（Ｒｅｌｅａｓｅ Ａｓｓｉｓｔａｎｃｅ Ｉｎｄｉｃａｔｉｏｎ）は、この目的のために再利用可能である。一方、送信されるデータパケットが小さく、Ｍｓｇ３の制限されたサイズ内で完全に送信されることができる場合、ＵＥはＲＲＣ接続に移行する必要がないと想定される。ＵＥがそのようなコネクションレスデータ送信を要求することが許可されている場合、その要求は以下のオプションの１つを用いてｅＮＢに伝達される必要がある。
オプション１ａ：ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ ＲｅｑｕｅｓｔのＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ及び／又はＲｅｓｕｍｅ ＣａｕｓｅのＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅにｓｐａｒｅ１を設定する。
オプション１ｂ：ＲＲＣ接続要求及び／又はＲＲＣ接続復旧要求にスペアＩＥがある。
オプション１ｃ：Ｍｓｇ３にＲＡＩ（つまり、ＢＳＲ＝０）を指定する。
オプション１ｄ：新しいＲＲＣメッセージ、例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ−ｌｅｓｓ Ｒｅｑｕｅｓｔ。
オプション１ａ〜１ｃは、オプション１ｄより仕様の影響が少ない。シグナリングオーバーヘッドの観点からは、オプション１ａと１ｂはオプション１ｃと同じであるが、オプション１よりも優れている。技術的な意味合いでは、オプション１ｂはオプション１ａよりも柔軟性がある。アーリーＵＬデータ伝送は一般に確立／再開の原因には関連していないため、特に今後のリリースでの潜在的なニーズを考慮している。従って、オプション１ｂが好ましい。
提案２：ＲＡＮ２は、ＵＬデータ送信がＭｓｇ３内で完了したかどうかをｅＮＢに通知するために、ＲＲＣ接続（再開）要求に１ビットインディケーションを含めることに合意すべきである。
（２．１．２．再送方式）
ＷＩＤは、アーリーデータ伝送が専用のリソース上で実行されると述べている。
アーリーＵＬデータ伝送のためのＲＡＮ２の現在の合意が実際に専用リソースでサポートされているかどうかをさらに検討すべきである。ＲＡＮ２は、Ｍｓｇ３リソースがＭｓｇ２内の専用ＵＬグラントによって割り当てられる「Ｍｓｇ３におけるアーリーＵＬデータ送信」に合意した。現在のＭｓｇ３は、最終的にＵＬ−ＳＣＨを介してＰＵＳＣＨにマッピングされるＣＣＣＨ論理チャネルを介してＲＲＣ接続要求又はＲＲＣ接続復旧要求のいずれかを搬送するが、ＵＥ間の物理リソースの競合は未解決である。アーリーＵＬデータ送信は、ＩＤＬＥのＵＥに対してのみ、すなわち競合ベースのランダムアクセスプロシージャでサポートされる。
考察１：Ｍｓｇ３では、競合はＲＡＣＨプロシージャに基づいて解決されない。
Ｍｓｇ３では、競合が解決されていないので、複数のＵＥからより多くのＵＬ干渉が予期される。言い換えると、Ｍｓｇ３における初期ＵＬデータの受信エラーが発生する可能性がある。アーリーＵＬデータ送信がうまく受信されない場合、ＵＥが何をすべきか、すなわちｅＮＢによってうまく受信されなかったＵＬデータを再送する方法は依然として不明である。
提案３：ＲＡＮ２は、ＵＥがｅＮＢによってデータが正常に受信されなかった場合、ＵＥがアーリーＵＬデータをどのように再送すべきかについて検討すべきである。
提案３が納得のいくものである場合、再送スキームの４つのオプションが考慮される。
オプション２ａ：ＵＥは、Ｍｓｇ１からのランダムアクセスプロシージャを再開する。すなわち、前のプロシージャはキャンセルされる。
オプション２ｂ：ＵＥは、失敗したデータ、すなわち「Ｍｓｇ３におけるアーリーＵＬデータ再送信」を伴うＭｓｇ３を再送信することができる。
オプション２ｃ：ＵＥは、Ｍｓｇ５で失敗したデータを再送信することができる。つまり、データだけが失敗した場合である。
オプション２ｄ：ＵＥは、ＲＲＣ接続後にのみ、失敗したデータを再送することが許可される。
オプション２ａは、現在の仕様、すなわち、Ｍｓｇ３バッファをフラッシュし、ランダムアクセスリソース選択から再開するように調整される。オプション２ａを使用しても、アーリーＵＬデータ再送信のためにレガシーバックオフ時間又は新しいバックオフ時間を適用するかどうか、及び再送信回数に制限があるかどうかは不明である。オプション２ｂはオプション２ａに従うことができ、すなわち、ＵＥは、次のＭｓｇ３タイミングで失敗したデータを含む。オプション２ｃは、同じＭＣＳが適用されていると仮定して、ＲＲＣ接続（再開）要求が正常に受信されている間にデータが受信されなかった可能性が低いため、まれなケースである。オプション２ｄは、失敗したデータの再送信が許可されていることを除いて、現在の仕様と一致している。
提案４：ＲＡＮ２は、アーリーＵＬデータ送信に失敗した場合、ＵＥは（現在のように）ランダムアクセスプロシージャを再開し、次のＭｓｇ３のデータを再送することが許可されるべきであることに合意すべきである。
いずれにしても、ＵＥは、Ｍｓｇ３バッファがフラッシュされても、受信成功の確認までアーリー伝送のためのデータを維持すべきである。
（２．２．ＤＬアーリーデータ伝送）
（２．２．１．Ｅメールディスカッションの考察）
Ｅメールディスカッションでは、アーリーＤＬデータ送信とアーリーＵＬデータ送信の両方について共同で検討したため、ＤＬの側面は詳細には考慮されていない可能性がある。次のセクションでは、そのような詳細について説明する。
（２．２．２．アーリーＤＬデータ伝送のＵＥのサポート）
ＲＡＮ２は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ／Ｒｅｓｕｍｅ／Ｒｅｌｅａｓｅに加えてＭｓｇ４でデータを受信する必要がある、Ｍｓｇ４でのアーリーＤＬデータ送信をサポートすることに合意した。しかし、ｅＮＢは、ＵＥがアーリーＤＬデータ受信が可能であるかどうか、特に中断されていないだけでなく、中断されていないＵＥについて、常にＵＥが知ることができるのは疑問である。両方のＣＩｏＴＥＰＳＣＰ／ＵＰ最適化のための統一されたソリューションを考慮して、ＵＥはアーリーＤＬデータを受信できるかどうかをＮＷ、すなわちｅＮＢ又はＭＭＥに通知することができる。
提案５：ＲＡＮ２は、アーリーＤＬデータ受信をサポートするか否かをＵＥがＮＷに通知すべきであることに合意すべきである。
ｅＮＢの観点から、ＵＥの能力をＮＷ、すなわちＭＭＥ又はＵＥに伝達するための２つの選択肢がある。ＭＭＥがｅＮＢに通知する場合、いくつかのＳ１メッセージが、ＰＡＧＩＮＧ又はＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴなど、エンハンスされる必要があることは明らかであり、ＲＡＮ２はＲＡＮ３と議論すべきである。一方、ＵＥがｅＮＢに通知する場合、いくつかのオプションが以下のように考えられる。
オプション３ａ：ＵＥ能力のアーリーＤＬデータ受信のために新しいＩＥが追加される。
オプション３ｂ：ＵＥがアーリーＤＬデータ受信をサポートする場合、Ｍｓｇ１又はＭｓｇ３でインディケーションが送信される。
オプション３ａは、ＵＥの能力をｅＮＢに提供する簡単な方法であるが、ｅＮＢは、Ｍｓｇ４の後にＵＥが転送されるので、ＵＥがもはや接続中又は中断中でなくてもコンテキストを保持する必要がある。オプション３ｂは、「ハンドシェイク」の一種であるため、ＵＥは、ＤＬデータ受信が開始される前に、すなわちページング又はＭｓｇ２において、アーリーＤＬデータ受信が意図されているかどうかを知る必要がある。
提案６：ＲＡＮ２は、ＵＥがアーリーＤＬデータ受信をサポートしているかどうか、すなわちＵＥ又はＭＭＥによってｅＮＢがどのように通知されるかを検討するべきである。
提案６にかかわらず、ＵＥは、それが起こる前にアーリーＤＬデータ受信をセットアップする必要があるかどうかを知る必要がある。
提案７：ＲＡＮ２は、アーリーＤＬデータ受信が必要であるかどうかをＵＥがページング又はＭｓｇ２で通知されるべきであることに合意すべきである。
（２．２．３．再送方式）
アーリーＤＬデータ送信が専用／非競合リソース、すなわちＭｓｇ４上で実行されると仮定する。しかし、そのようなリソースでも受信エラーが発生するため、ＵＥの動作を明確にする必要がある。アーリーＤＬデータ送信がページング又はＭｓｇ２、すなわち提案７に示されると、ＵＥがＭｓｇ４上で送信されるデータをモニタすることは簡単である。提案４と同様に、ＤＬデータがＵＥによって受信されなかった場合のＤＬデータの再送信の手段が必要である。
提案８：ＲＡＮ２は、Ｍｓｇ４が受信されなかった場合、Ｍｓｇ４に対してアーリーＤＬデータ再送信が実行されることに合意すべきである。
（２．２．４．同時のアーリーＵＬ／ＤＬデータ送信）
単一のランダムアクセスプロシージャの中でアーリーデータ伝送がＵＬとＤＬの両方で同時にサポートされるべきかどうかは依然として不明である。一般に、ＵＬデータ送信は、次のＤＬに対して上位レイヤ確認応答を必要とし、その逆、例えばＴＣＰ ＡＣＫを必要とすることがある。ＵＥがＭｓｇ３でＵＬデータ送信を送信することを決定した後に、１つのランダムアクセスプロシージャ内でＭｓｇ４におけるＤＬデータ受信として確認応答を送信することが可能であるかもしれない。Ｍｓｇ４のＤＬデータ送信には同じプロシージャでＭｓｇ３を続けることはできません。ＵＬデータ送信としての上位レイヤ確認応答は、次のランダムアクセスプロシージャで発生する次のＭｓｇ３で送信されなければならないか、又はＵＥはＲＲＣ接続に移行することもできるが、それはアーリーＤＬデータを送信する目的を否定する。
しかし、そのような上位レイヤの確認応答にどれだけの遅延が必要かは不明である。上位レイヤ往復がランダムアクセスプロシージャ内で行われ、上位レイヤの肯定応答が遅れた場合、ＵＥはＭｓｇ３送信後にＭｓｇ４を長時間モニタし続けることができ、これによりＵＥの不要な電力消費が引き起こされる。したがって、１回のランダムアクセスプロシージャでアーリーＵＬデータ送信又はアーリーＤＬデータ送信がサポートされることは合理的である。
提案９：ＲＡＮ２は、１つのランダムアクセスプロシージャがただ１つのアーリーデータ伝送、すなわちアーリーＵＬデータ送信又はアーリーＤＬデータ送信のいずれかをサポートすることに合意すべきである。
［付記３］
（１．はじめに）
ＲＡＮ２＃９９ｂｉｓは、以下のように多くの合意を得てＥａｒｌｙ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ（ＥＤＴ）機能の重要な進展を達成した。
合意事項
・ＰＲＡＣＨパーティショニングは、Ｍｓｇ３においてアーリーデータ伝送を使用するＵＥの意図を示すために使用される。下位互換性は保持される。更なる検討が必要：ＰＲＡＣＨプールに関する詳細、例えば、ＰＲＡＣＨ分割のプリアンブル／時間／周波数／キャリアドメイン。
・ＵＬ ＥＤＴプロシージャ中のＣＰに関して、ＵＥがデータが適合しないグラントを受信した場合、ＵＥはＭｓｇ３のデータを送信しない。ＵＰソリューションの場合、グラントがＵＬデータサイズよりも小さい場合は、ＥＤＴグラントがＵＬデータに使用できるかどうかは更なる検討が必要である。
・認証メカニズムを導入する必要があるかどうかは更なる検討が必要である。
・Ｍｓｇ３の最大グラントサイズは、ＣＥごとにブロードキャストされる。ＵＥがＰＲＡＣＨパーティショニングを介してＭｓｇ３に必要なグラントサイズを示すかどうかは更なる検討が必要である。
・ＬＳをＲＡＮ１に送信し、ＰＵＳＣＨ伝送用の従来のＴＢＳテーブルがＥＤＴに使用されていると仮定していることを示す。
・Ｍｓｇ４は、ＵＥがＲＲＣ接続モード又はＲＲＣアイドルモードに移行するかどうかを決定する。ＥＤＴのＭｓｇ４の内容は更なる検討が必要である。
・ＥＤＴを使用する意図は、データ、すなわちＮＡＳシグナリングのためではない。
・レガシープロシージャのＭｓｇ５に含まれる以下のパラメータのいずれかがＭｓｇ３ ｆｏｒ ＥＤＴに含まれるべきかどうかＬＳをＲＡＮ３／ＳＡ２／ＣＴ１に送る：ｓｅｌｅｃｔｅｄ ＰＬＭＮ−Ｉｄｅｎｔｉｔｙ、ｒｅｇｉｓｔｅｒｅｄ ＭＭＥ、ｇｕｍｍｅｉ−Ｔｙｐｅ、ａｔｔａｃｈ Ｗｉｔｈｏｕｔ ＰＤＮ−Ｃｏｎｎｅｃｔｉｖｉｔｙ、ｕｐ−ＣＩｏＴ−ＥＰＳ最適化、ｃｐ−ＣＩｏＴ−ＥＰＳ最適化、ｄｃｎ−ＩＤ。
・ＲＡＮ２は、ＣＰに対するＳ−ＴＭＳＩを仮定し、ＵＰソリューションについてのｒｅｓｕｍｅＩＤ及びｓｈｏｒｔＲｅｓｕｍｅＭＡＣ−１は、それぞれＭＭＥ及びｅＮＢでＵＥを識別するのに十分である。我々は、この仮定をＬＳ．ｔｏＲＡＮ３、ＳＡ２、ＳＡ３、ＣＴ１に提供する。
・ＣＰソリューションのために、データ用のＮＡＳ ＰＤＵは、Ｍｓｇ３で送信されたＲＲＣメッセージにカプセル化され、ＣＣＣＨ ＳＤＵとして送信される。
・ＵＰソリューションの場合、ＳＲＢ０はＭｓｇ３でＲＲＣメッセージを送信するために使用される。
・ＵＰソリューションでは、Ｍｓｇ３のＭＡＣにＣＣＣＨ（ＲＲＣメッセージ）とＤＴＣＨ（ＵＰデータ）が多重化されている。
・ＵＰの場合、ＡＳセキュリティはＭｓｇ３を送信する前に再開され、Ｍｓｇ３で送信されるデータはＡＳセキュリティによって保護される。
・ＣＰソリューションの場合、ＤＬ内のＮＡＳＰＤＵデータは、Ｍｓｇ４で送信されたＲＲＣメッセージにカプセル化され、ＣＣＣＨＳＤＵとして送信される。
・ＵＰソリューションの場合、ＤＬデータは、Ｍｓｇ４内のＭＡＣ、すなわちＤＣＣＨ（ＲＲＣメッセージ）及びＤＴＣＨ（ＵＰデータ）に任意に多重化することができる。
・更なる検討が必要：ＵＰソリューションの場合：固定接続の場合、つまりＣＣＣＨ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑ）＋ＤＣＣＨ（固定接続によるＮＡＳ ＰＤＵ）
この付記では、ＥＤＴの基本機能を完成させるための残りの課題について検討する。
（２．検討）
（２．１．ユースケース）
検討の間、ＥＤＴプロシージャは、例えば、上位レイヤのセンサデータについてはＵＬ ＥＤＴによって開始され、対応する上位レイヤＡＣＫについてはＤＬ ＥＤＴによって終了するという共通の理解のように見える。すなわち、上位レイヤの往復はＥＤＴプロシージャ内で行われる。
他方、ＵＬのみのＥＤＴプロシージャ及び／又はＤＬのみのＥＤＴプロシージャは、いくつかの場合にも有用である。（より多くの比較については図２６を参照。図２６は、ＥＤＴのプロシージャを示す。）
・ＵＤＰタイプのデータ送信、すなわち、上位レイヤのＡＣＫなし。
・上位レイヤの往復での遅延が長い、すなわち、上位レイヤのＡＣＫが応答する前にある時間を必要とする。
・アプリケーションサーバからデバイスへのコマンド、つまり通信はＤＬによってトリガされる。
「ＣＰソリューションの場合、ＤＬ内のＮＡＳ ＰＤＵデータは、Ｍｓｇ４で送信されたＲＲＣメッセージにカプセル化され、ＣＣＣＨ ＳＤＵとして送信されることができる」、「ＵＰソリューションの場合、ＤＬデータは、Ｍｓｇ４においてＭＡＣ、すなわちＤＣＣＨ（ＲＲＣメッセージ）及びＤＴＣＨ（ＵＰデータ）に任意に多重化されうる。すなわち、ＵＥはデータなしでＭｓｇ４を受信することができる。」と合意されているため、ＵＬのみのＥＤＴプロシージャがサポートされていると考えられる。
考察１：現在の合意事項では、ＵＬのみのＥＤＴプロシージャがサポートされている。
一方、現在の合意事項ではＤＬ−ｏｎｌｙ ＥＤＴプロシージャのサポートは依然として不明である。ＤＬ−ＥＤＴ伝送の可用性は、ＵＥの観点からＭｓｇ４を受信するまで知ることができず、ＤＬ ＥＤＴ受信の能力は不可能であったため、想定されるＵＬ ＥＤＴ対応ＵＥがＤＬＥ ＤＴもサポートしている場合、ｅＮＢの観点からＵＬ ＥＤＴなしで通知される。したがって、ＤＬのみのＥＤＴプロシージャがサポートされている場合、さらなる検討はいくつかの拡張、例えばページングにおける通知に取り組むべきである。
注：ＵＬ ＥＤＴ機能が可能なＵＥはＤＬ ＥＤＴ機能も可能であると仮定している。
提案１：ＲＡＮ２は、ＤＬ専用のＥＤＴプロシージャがサポートされているかどうかについて検討すべきである。
（２．２．ＥＤＴインディケーションの詳細）
ＲＡＮ２＃９９ｂｉｓでは、「ＰＲＡＣＨパーティショニングは、Ｍｓｇ３でアーリーデータ伝送を使用するＵＥの意図を示すために使用されている。下位互換性は保持される。更なる検討が必要：ＰＲＡＣＨパーティショニングのプリアンブル／時間／周波数／搬送波ドメインなどのＰＲＡＣＨプールに関する詳細」及び「Ｍｓｇ３の最大可能グラントサイズはＣＥごとにブロードキャストされる。ＵＥがＰＲＡＣＨパーティショニングを介してＭｓｇ３に必要なグラントサイズを示す場合、それは更なる検討が必要である。」と合意された。
Ｅメールディスカッションでは、更なる検討が必要、すなわちＭｓｇ１とＰＲＡＣＨパーティショニングの詳細に関する追加情報について説明した。Ｍｓｇ１に関する追加情報に関しては、ＥＤＴインディケーションがＣＥごとに設定されているが、ＵＥカテゴリは必要ではないという意見が大半を占めているようである。ＥＤＴインディケーションに関する合意はないが、これは将来の拡張である可能性がある。
提案２：ＲＡＮ２は、Ｍｓｇ１のＥＤＴインディケーションがＣＥごとに設定され、Ｍｓｇ１のグラントサイズインディケーションが将来の拡張として考慮されるべきであることに合意すべきである。
ＰＲＡＣＨ分割の詳細については、ソフトパーティショニング（又は非専用ＰＲＡＣＨリソース）とハードパーティショニング（又は専用ＰＲＡＣＨリソース）の２つの方向が示唆された。特に、ＮＢ−ＩｏＴの一部の導入シナリオでは限られたリソースの場合に、ＰＲＡＣＨの性能低下を引き起こす可能性があるため、ＰＲＡＣＨフラグメンテーションが許容可能かどうかが問題である。
たとえば、最適化されていないＮＷでＰＲＡＣＨリソースをソフトパーティショニングで共有することにはいくつかの利点があるが、パーティショニングの数はハードパーティショニングと変わりない。例えば、ハードパーティショニングの場合、３つのレガシーＣＥレベル、３ＥＤＴ ３ＣＥレベルのために、ＰＲＡＣＨリソースには６つのパーティションが必要である。ソフトパーティショニングの場合、６つのＰＲＡＣＨスペース（３つのＣＥレベルｘ２つの異なるプリアンブル）も必要である。これは、物理的な踏み外しがないこと、すなわち、ＵＥをどのように分離するかという違いがあることを意味する。
注：ハードパーティショニングでは、ｅＮＢがレガシーＰＲＡＣＨリソースとＥＤＴ Ｉｎｄｉｃａｔｉｏｎ ＰＲＡＣＨリソースを重複リソースで設定する場合、共有ＰＲＡＣＨリソースが可能になる。
したがって、我々の見解では、分割方法（例えば、ソフト又はハード）にかかわらず、専用又は非専用リソースのいずれに関係なく、最適化されたＮＷにおいてＰＲＡＣＨ性能は最終的には類似している。
考察２：ＰＲＡＣＨのパフォーマンスは、最終的にＥメールディスカッションで提案されたソリューション間で類似している。
これまでＥメールで検討されていなかった代替ソリューションとして、ＵＥからの複数のＰＲＡＣＨ送信を定義してレガシーＰＲＡＣＨとＵＬ−ＥＤＴ ＰＲＡＣＨを区別できるかどうかを検討する必要もある。例えば、ＵＥは、レガシー目的（すなわち、ＣＥレベルの決定）のための第１のＰＲＡＣＨを送信し、ＥＤＴインディケーションのための第２のＰＲＡＣＨ（すなわち、ＥＤＴが第２のものを送信することを要求するＵＥのみ）を送信する。ｅＮＢは、各ＰＲＡＣＨショットの２つのＰＲＡＣＨスペース上でブラインドデコードを実行することができる（図２７参照。図２７は、複数のＰＲＡＣＨ送信によるＥＤＴインディケーションを示す）。２つのＰＲＡＣＨは同じサブフレーム上で送信することができる。このアプローチでは、レガシーＵＥは現状のように最初のＰＲＡＣＨのみを送信するため、４つのＰＲＡＣＨリソース（最初のＰＲＡＣＨでは３つのＣＥレベル、２つ目は１つのＥＤＴインディケーション）が必要である。しかしながら、このソリューションの欠点は、明らかにＵＥが追加のＰＲＡＣＨ送信を必要とすることであり、それによって追加の電力消費が生じるが、ＰＲＡＣＨ性能低下（例えば、衝突）による電力消費に類似し得る。
提案３：ＲＡＮ２は、１つの追加のＰＲＡＣＨ空間を有する複数のＰＲＡＣＨ送信がＥＤＴインディケーションに有用であるかどうかを検討すべきである。
提案４：提案２と提案３が合意に達すると、ＲＡＮ２は後でグラントサイズインディケーションが追加のＰＲＡＣＨ空間にマッピングされるかどうか検討すべきである。
（２．３．ＥＤＴの失敗事例）
（２．３．１．ＵＬグラント障害（Ｍｓｇ１／Ｍｓｇ２））
ＲＡＮ２は、「ＵＬＥＤＴプロシージャ中のＣＰに関して、ＵＥがデータ適合しないグラントを受信した場合、ＵＥはＭｓｇ３のデータを送信しない。ＵＰソリューションの場合、グラントがＵＬデータサイズよりも小さい場合、ＥＤＴグラントがＵＬデータに使用できる場合は更なる検討が必要である。」と合意した。少なくともＣＰソリューションの場合、ＵＥがＭｓｇ１にＥＤＴ Ｉｎｄｉｃａｔｉｏｎを送信しても、ｅＮＢはＭｓｇ２上のレガシーサイズＵＬグラントを持つＥＤＴプロシージャを拒否することがある。それはＥＤＴプロシージャの観点からは失敗事例とみなすことができる。
考察３：少なくともＣＰソリューションの場合、ＵＬグラントがデータサイズに適合しない場合、ＥＤＴプロシージャは失敗する。
現在の合意は、データがＭｓｇ３上で送信できるかどうか、すなわち、ＵＬグラントが予想よりも小さい場合にＵＥが何をすべきかについて言及していないという状態のみを言う。したがって、失敗時のＵＥの動作は、例えばテストのために特定されるべきである。いくつかのオプションは次のように考慮する必要がある。
オプション１：ＵＥは、レガシーＭｓｇ３（すなわち、データなし）を送信する。
オプション２：ＵＥは、ＥＤＴプロシージャを再試行することができる（すなわち、Ｍｓｇ１から開始する）。
オプション１は、検討の最中に私たちの印象からのベースラインかもしれない。オプション２は、現在の動作と幾分異なる。すなわち、対応するＵＬグラントを受信しても、ＵＥはＰＵＳＣＨ送信をスキップする。しかし、ＥＤＴは新しい機能であるため、例えば、ｅＮＢがこの機能を許可する場合にのみ、オプションでオプション２を導入して、不要なＵＥの電力消費を最小限に抑えてＲＲＣ接続に移行させることを検討する価値がある。
提案５：ＲＡＮ２は、少なくともＣＰソリューションのために、ＵＬグラントサイズがＵＬ ＥＤＴに十分でない場合、ＵＥがレガシーＭｓｇ３を送信することに合意すべきである。
提案６：ＲＡＮ２は、ＵＬグラントサイズが十分に大きくない場合に、ＵＥがＥＤＴインディケーションを再送することを任意に許可されているか否かを検討すべきである。
（２．３．２．受信失敗（Ｍｓｇ３／Ｍｓｇ４））
ＥＤＴプロシージャにおけるデータの受信失敗の処理方法については検討されていない。
これまでのＵＬ ＥＤＴの検討では、ＵＥの挙動は、ＵＥがＭｓｇ４を受信する場合のみを想定していたが、ＵＥがＭｓｇ４を受信しない場合には何が起こるかはまだ明確ではない。いくつかのオプションが検討されたが、ＵＥが現在のランダムアクセスプロシージャに従う、すなわちランダムアクセスリソース選択から再開することにより、ＵＬ ＥＤＴもまた再試行されることがより簡単であり得る。
提案７：ＲＡＮ２は、現状のように、競合解決が成功しなかったと考えられる場合、ＵＥがランダムアクセスリソース選択からランダムアクセスプロシージャ（及びＵＬ ＥＤＴプロシージャ）を再開することに合意すべきである。
競合解決が成功しなかったと考えられるときに、現在ＨＡＲＱバッファがフラッシュされているので、再送信のためのデータが格納される場所について検討すべきである。ＣＰソリューションの観点からは、トラフィックデータは、ＲＲＣメッセージ内にＮＡＳ ＰＤＵとしてカプセル化される。データ伝送が首尾よく完了するまで、トラフィックデータをＲＲＣレイヤにカプセル化することが可能である。一方、ＵＰソリューション策の観点から、ＤＴＣＨ上のトラフィックデータはＭＡＣレイヤに多重化されているので、トラフィックデータはＲＲＣレイヤに格納されず、ユーザプレーンレイヤの１つに格納される。競合解決が成功しなかったとみなされても、ＣＰ及びＵＰに対する共通のＵＥ動作を有するという観点から、ＭＡＣレイヤは、ＨＡＲＱバッファをフラッシュしてはならない。
考察４：ＲＲＴ又はＭＡＣで、ＵＬ ＥＤＴが正常に完了するまでどのレイヤにデータが格納されているかは不明である。
提案８：ＲＡＮ２は、ＭＡＣレイヤがＵＬ ＥＤＴにおけるデータ再送信を処理することに合意すべきである。
ＤＬ ＥＤＴでは、Ｍｓｇ４の受信失敗がＨＡＲＱフィードバックによって示される。したがって、データの再送信は、現在のＨＡＲＱ再送信に単に従うことができる。
提案９：ＲＡＮ２は、現在と同じように、Ｍｓｇ４ ＨＡＲＱ再送信を介してＤＬ ＥＤＴ再送信が実行されることに合意すべきである。
（２．３．３．Ｔ３００及び競合解決タイマ障害（Ｍｓｇ３／Ｍｓｇ４）
現在の仕様では、ＲＲＣのＭｓｇ３とＭｓｇ４の間に２つのタイマ（Ｔ３００とＭＡＣのｍａｃ−Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒ）がある。Ｔ３００の値は、ＬＴＥでは１００ｍｓ〜２０００ｍｓ、ＮＢ−ＩｏＴでは２５００ｍｓ〜６００００ｍｓである。ｍａｃ−Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒの値は、ＬＴＥではｓｆ８〜ｓｆ６４、ＮＢ−ＩｏＴではｐｐ１〜ｐｐ６４である。これらのタイマが満了すると、ＵＥは、ＲＲＣ接続確立／再開又は競合解決がそれぞれ成功していないとみなす。
ＵＬ ＥＤＴがセンサデータ伝送用であり、ＤＬ ＥＤＴがＴＣＰ ＡＣＫ用である場合（図２６の「完全ＥＤＴプロシージャ」）、ＥＤＴプロシージャにおけるＭｓｇ４伝送は、上位レイヤでの往復時間に依存し、従来のＭｓｇ４よりも遅れている可能性が高い。したがって、不要なエラーを防ぐために、より長いタイマ値を定義するのは簡単である。
提案１０：ＲＡＮ２は、Ｍｓｇ３上のＵＬ ＥＤＴとＭｓｇ４上のＤＬ ＥＤＴの間で動作するタイマのより長い値を定義する必要がある。
しかし、それは、Ｍｓｇ４の受信まで連続的なＰＤＣＣＨモニタのために追加のＵＥ電力消費を引き起こす可能性がある。したがって、ＤＲＴのような受信モードをＥＤＴプロシージャに導入する必要がある。
提案１１：ＲＡＮ２は、ＥＤＴプロシージャにおいて（すなわち、Ｍｓｇ３送信からＭｓｇ４受信までの間に）不連続受信が許容されるかどうかを検討すべきである。
さらに、ｅＮＢがタイマ値をどのように設定するかは疑問がある。なぜなら、上位レイヤメッセージのためにＴＣＰ ＡＣＫが返ってくるときは分からないからである。セル内に様々なアプリケーションを実装しているＵＥが多数存在すると想定されているので、すべてのＵＥに対して適切なタイマ値を設定することは困難であるように思われる。
１つの可能性はＭｓｇ２の専用設定であるが、アプリケーションレイヤの知識なしにタイマ値を決定することはまだ困難である。一方、ＵＥは、上位レイヤにおけるタイムアウト設定に基づいて適切なタイマ値を設定するのを助けることができる。例えば、ＵＥは、Ｍｓｇ３上の自己設定タイマ値をｅＮＢに通知することができる。
提案１２：ＲＡＮ２は、ＵＥがＭｓｇ３上の自己設定タイマ値をｅＮＢに通知することを許可されているかどうかを検討すべきである。
提案１０〜提案１２のいずれかが好ましい場合、ＥＤＴのためのタイマの概念はレガシータイマとは異なる。また、ＥＤＴ可能なＵＥが、例えば、より大きなパケット送信のためにレガシーＲＲＣ接続確立／再開を開始することも可能であり、これにより、レガシータイマがこの場合に適用可能である。したがって、ＥＤＴのタイマがレガシータイマを再使用するか、新しいタイマを定義するかについて検討する価値はある。
提案１３：ＲＡＮ２は、ＥＤＴ用のタイマがレガシータイマを再利用するのか、新しいタイマを定義するのかについて検討すべきである。
図２８に、上位レイヤのラウンドトリップ時間による遅延を示す。
（２．４．承認メカニズム）
議長メモでは、「承認メカニズムを導入する必要があるかどうかは更なる検討が必要である」。このような承認メカニズムはＥメールディスカッションでは範囲外であった。
我々の理解では、ＥＤＴはＡＳの機能性であり、ＮＷやＵＥの立場ではコストがかからない（ＣＥとは異なる）。さらに、ＮＷは、ＰＲＡＣＨ分割パラメータ及び／又はＳＩＢからの可能な最大グラントサイズを除去することによって、ＥＤＴ機能を常に無効にすることができる。したがって、認証メカニズムを導入する技術的な理由はない。
提案１４：ＲＡＮ２は、ＥＤＴの認証メカニズムが不要であることに合意すべきである。
［付記４］
（１．はじめに）
ＲＡＮ２＃１００は、Ｍｓｇ１上のＥａｒｌｙＤａｔａＴｒａｎｓｍｉｓｓｉｏｎ（ＥＤＴ）インディケーションの詳細を検討し、以下の合意を達成した。
合意事項
・ＵＥは、ＵＥが送信しようとするユーザデータを含むＭｓｇ３のサイズがＣＥあたりのＭｓｇ３ブロードキャストの最大可能ＴＢＳサイズと等しいかそれよりも小さい場合、Ｍｓｇ１でＥＤＴを開始する。
・拡張されたカバレッジレベルごとに、ＥＤＴインディケーション用のＰＲＡＣＨ区分化が設定される。
・作業の前提：このケースのセグメンテーションのサポートは優先されない。
・動作仮定：ＣＥごとのレガシー又は最大ＴＢＳブロードキャスト以外の意図されたデータサイズを示すために、ＰＲＡＣＨリソース分割はサポートされない。
・Ｍｓｇ３でのパディング問題の解決方法
・ＵＥカテゴリはＭｓｇ１に示されない。
・ＥＤＴインディケーションのために、ＰＲＡＣＨリソースは、物理レイヤリソース、プリアンブル／サブキャリアに関してレガシーｅＭＴＣ又はＮＢ−ＩｏＴのように設定することができる。
・ＥＤＡＣＨインディケーションのためのＰＲＡＣＨリソースプール、すなわち物理レイヤリソース、プリアンブル／サブキャリアは、レガシーＲＡＣＨプロシージャのためのＰＲＡＣＨリソースプールとは別個である。
パディングの問題にどのように対処するかについて、更なる検討が必要として認識された。この問題は、ＵＬＥＤＴのためのＵＬグラントが、ＵＥが送信しようとするデータサイズが不一致である場合に発生する。問題の詳細は、対応するＥメールディスカッションに詳しく記載されている。
この付記では、Ｅメールディスカッションの補足説明が提供されている。
（２．検討）
パディング問題の解決法は、Ｅメールディスカッションで以下のように提案され、要約されている。
上記のパディング問題に関する以下のソリューションが提示された。
１．（Ｎ）ＰＲＡＣＨパーティショニング。ここで、ＵＥは、Ｍｓｇ１を使用するＥＤＴ Ｍｓｇ３のための意図されたデータサイズ／ＴＢＳを示す。
２．ネットワークは、複数のトランスポートブロックサイズと、ＵＬグラント情報の組み合わせとを提供する。ＵＥがＭｓｇ３における意図されたデータ送信を考慮して選択するためのＲＡＲメッセージ内のＲＵ、ＰＲＢ、繰り返し回数
３．ネットワークは、Ｍｓｇ３送信のために二重（又はそれ以上）のグラントを提供する。
４．Ｍｓｇ１とのデータサイズの表現とＲＡＲの柔軟なグラントの組み合わせ。
５．パディング領域でのＭＡＣ ＳＤＵ又はＰＤＵの繰り返し（この解決方法の詳細は不明であるが、より良い理解のために詳細に説明する）
６．複数の「ＣＥあたりの最大ＴＢＳブロードキャスト」に関連するＭｓｇ３送信用の複数の共通ＵＬリソースプールなどの暗黙的な割り当て（この解決方法の詳細は不明であるが、より良い理解のために詳細に説明する）。
７．ＵＰのみ：レガシーＭｓｇ３伝送用のパディングを避けるためのセグメンテーション。
（２．１．ソリューション５（ＭＡＣ ＰＤＵの反復））
このソリューションは、冗長機会としてパディング領域を使用する。換言すれば、サブフレーム上の既存の反復スキームは、送信内で行われる。例を図２９と図３０に示す。図２９は、ＵＬグラントが意図したデータサイズより大きい場合を示す。図３０は、ＵＬグラントが意図したデータサイズより小さい場合を示す。
１つの可能性は物理レイヤであるが、どのレイヤ内のエンティティが追加の冗長性プロセスを実行するのは更なる検討が必要である。例えば、ＵＥは、ＭＡＣＰＤＵからビット列を生成し、循環バッファに格納し、ＵＬグラントサイズに従ってビットを送信する。
長所と短所は次のように予想される：
長所：パディングビットの送信と比較して、反復を補償するためにＲｘソフト合成利得及び／又はＴｘ電力低減の可能性。
短所：繰り返しが物理レイヤで処理される場合、ＲＡＮ１の影響がある可能性がある。
（２．２．ソリューション６（共通のＵＬリソースプール））
このソリューションは、ＥＤＴのための共通のＵＬリソースプールを提供し、それにより、リソースプールは、モード２／タイプ１サイドリンク送信、すなわち複数のＵＥによって使用される共通リソースに類似する。レガシーＭｓｇ３リソースは、（現状のように）ＵＬグラントによって常に提供されると仮定することができるが、ＵＥは、レガシーＭｓｇ３で使用される同じ一時Ｃ−ＲＮＴＩを有する共通リソースプールを使用してデータ部分を送信することができる。共通リソースプールの設定は、ＳＩＢで提供されている。このソリューションは、複数のＵＬ許可ソリューションの「半静的」バージョンと見なすことができ、それによって、データを対象とする第２のグラントリソースが複数のＵＥによって共有される。
図３１に、ＵＬ送信用の共通リソースプールを示す。
長所と短所は次のように考えられる。
長所：Ｍｓｇ２への変更は必要ない。ＵＥは、サイドリンクのような送信を仮定して、（サイズが共通リソースを超えない限り）パディングなしでデータを送信することができる。ＥＤＴがＩＤＬＥモードプロシージャであると考えると、Ｍｏｄｅ２／Ｔｙｐｅ１リソースの場合と同様に、共通リソースの使用も合理的である。これは、Ｍｓｇ２が変更される必要がないという考えを再び強調している専用シグナリングなしでリソースを割り当てることができることを意味する。
短所：共通リソースを使用すると衝突が発生する。
［付記５］
（１．はじめに）
ＲＡＮ２＃１００は、ＥＤＴ機能の見通しを形成するために達成された。しかし、詳細についてはまだ多くの更なる検討が必要であり、そのうちの１つは以下の通りである。
合意事項
ＣＰソリューション
［．．．］
・Ｔ３００とｍａｃ−ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒの変更が必要かどうかは更なる検討が必要
この付記において、タイマの側面のさらなる考察が検討される。
（２．検討）
（２．１．前提）
検討の間、ＥＤＴプロシージャはＵＬ ＥＤＴ、例えば上位レイヤのセンサデータで開始され、ＤＬ ＥＤＴ、例えば対応する上位レイヤＡＣＫ、すなわち上位レイヤの往復で終了するという共通の理解であると思われる、ＥＤＴプロシージャ（すなわち、図２６の「完全ＥＤＴプロシージャ」を参照）内で行われる。
考察１：一般的なＥＤＴプロシージャには、ＵＬ ＥＤＴとＤＬ ＥＤＴ（ランダムアクセスプロシージャ内）が含まれている。
他方、ＵＬのみのＥＤＴプロシージャ及び／又はＤＬのみのＥＤＴプロシージャは、以下の場合にも有用である（図２６を参照）。
ＵＤＰタイプのデータ送信、すなわち、上位レイヤのＡＣＫなし。
上位レイヤの往復でより長い遅延、すなわち、上位レイヤのＡＣＫは、応答の前に一定の時間を必要とする。
アプリケーションサーバからデバイスへのコマンド、すなわち通信はＤＬによってトリガされる。
Ｍｓｇ４のＤＬデータは、ＣＰ／ＵＰに関係なく、「ＣＰソリューションの場合、ＤＬ内のＮＡＳ ＰＤＵデータは、Ｍｓｇ４で送信されたＲＲＣメッセージにカプセル化されていても、オプションでカプセル化されていてもよいため、ＣＣＣＨ ＳＤＵとして送信され、ＵＰソリューションの場合、Ｍｓｇ４のＭＡＣ（すなわち、ＤＣＣＨ（ＲＲＣメッセージ）及びＤＴＣＨ（ＵＰデータ））でＤＬデータを任意に多重化することができる。
考察２：ＵＬのみのＥＤＴプロシージャは、現在の合意事項に基づいてサポートされている。
一方、ＤＬ−ＥＤＴ伝送は、Ｍｓｇ４を受信するまでＵＥがＤＬ ＥＤＴ伝送が発生するかどうかを知らず、ｅＮＢはＵＥのＤＬ ＥＤＴ能力を知らないので、現在の合意事項に基づいて、ＤＬ−ｏｎｌｙＥＤＴプロシージャのサポートは依然として不明である。
提案１：ＲＡＮ２は、ＤＬ専用のＥＤＴプロシージャがサポートされているかどうかについて検討すべきである。
（２．２．Ｔ３００及び競合解決タイマ）
（２．２．１．Ｍｓｇ４遅延の問題）
現在の仕様では、ＲＲＣのＭｓｇ３とＭｓｇ４の間に２つのタイマ（Ｔ３００とＭＡＣのｍａｃ−Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒ）がある。Ｔ３００の値は、ＬＴＥでは１００ｍｓ〜２０００ｍｓ、ＮＢ−ＩｏＴでは２５００ｍｓ〜６００００ｍｓである。ｍａｃ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒの値は、ＬＴＥではｓｆ８〜ｓｆ６４、ＮＢ−ＩｏＴではｐｐ１〜ｐｐ６４と異る。これらのタイマが満了すると、ＵＥは、ＲＲＣ接続確立／再開又は競合解決がそれぞれ成功していないとみなす。これらの既存のタイマがＥＤＴの下で期限切れになる場合、ＵＥの動作がどのようにすべきかは依然として決定されていないが、現在のランダムアクセスプロシージャがＥＤＴプロシージャのベースラインであることも事実である。したがって、タイマに関してさらに考慮する必要がある。
センサデータがＵＬ ＥＤＴを介して送信され、対応するＴＣＰ ＡＣＫがＤＬ ＥＤＴを介して送信される場合（すなわち、図２６の「完全ＥＤＴプロシージャ」を参照）、ＥＤＴプロシージャにおけるＭｓｇ４送信は、おそらく従来のＭｓｇ４それは上位レイヤからの往復時間に依存する。
考察３：Ｍｓｇ３とＭｓｇ４の間の持続時間は、上位レイヤからの往復時間のために、最大レガシータイマを超える可能性が高い。
したがって、不要な障害を防ぐために、より長いタイマ値を定義するのは簡単である。
提案２：ＲＡＮ２は、Ｆｕｌｌ ＥＤＴプロシージャのために、Ｍｓｇ３上のＵＬ ＥＤＴとＭｓｇ４上のＤＬ ＥＤＴとの間で動作するタイマのより長い値を定義すべきである。
（２．２．２．Ｍｓｇ４受信用のＤＲＸ）
提案２が納得のいくものであれば、既存のＴ３００とｍａｃ−Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒのタイマ値を拡張するのは簡単である。しかし、これは、Ｍｓｇ４の受信まで連続的なＰＤＣＣＨモニタリングのために追加のＵＥ電力消費を引き起こし、それによってＭｓｇ４は前のセクションで説明したようにＥＤＴで遅延することがある。このような不必要な電力消費を避けるために、何らかの種類のＤＲＸのような受信モードがＥＤＴプロシージャに導入されるべきである。
例えば、簡単なソリューションのために、ＵＥは、タイマが満了する直前のサブフレーム、すなわち「ワンショット」モニタリングにおいてのみ、ＰＤＣＣＨをモニタすることができる。高レイテンシ通信のようないくつかのＭＴＣ／ＮＢ−ＩｏＴユースケースでは、連続モニタリングよりもうまくいく可能性がある。
提案３：ＲＡＮ２は、ＥＤＴプロシージャにおいて（すなわち、Ｍｓｇ３送信からＭｓｇ４受信までの間に）不連続受信が許容されるかどうかを検討すべきである。
（２．２．３．タイマ値の設定）
さらに、ｅＮＢがタイマ値をどのように設定するかは疑問がある。なぜなら、ＴＣＰ ＡＣＫが上位レイヤのメッセージから到着するとき、ｅＮＢには未知であるからである。セル内に様々なアプリケーションを実装する多数のＵＥが存在すると仮定して、ｅＮＢがすべてのＵＥに対して適切なタイマ値を設定することは困難である。
考察４：異なるＵＥが異なるアプリケーションを使用する可能性があることを考慮して、適切なタイマ値を設定することは困難である。
１つの可能性は、Ｍｓｇ２の専用シグナリングを使用してタイマを設定することであるが、ｅＮＢでアプリケーションレイヤの知識なしにタイマ値を決定することは依然として困難である。一方、ＵＥは、上位レイヤにおけるそのタイムアウト設定に基づいて適切なタイマ値を設定するのを助けることができる。例えば、ＵＥは、Ｍｓｇ３上の自己設定タイマ値をｅＮＢに通知することができる。
提案４：ＲＡＮ２は、ＵＥがＭｓｇ３上の自己設定タイマ値をｅＮＢに通知することを許可されているかどうかを検討すべきである。
（２．２．４．タイマの定義）
上記の提案（提案２〜提案４）の１つ又は複数が納得性がある場合、ＥＤＴのタイマの概念は従来のタイマとは異なる。また、ＥＤＴ可能なＵＥが、例えば、より大きなパケット送信のためにレガシーＲＲＣ接続確立／再開を開始することも可能であり、これにより、レガシータイマがこの場合に適用可能である。この意味で、既存のタイマをそのまま維持し、既存のタイマを拡張するのではなく、ＥＤＴ固有の新しいタイマを定義する方が簡単である。
提案５：ＲＡＮ２は、レガシータイマではなく、ＵＬ ＥＤＴ（Ｍｓｇ３以上）とＤＬ ＥＤＴ（Ｍｓｇ４以上）の間で動作する新しいタイマを定義することに合意すべきである。
［付記６］
（１．はじめに）
ＲＡＮ２＃１００は、ＥＤＴ機能の見通しを形成するために達成された。しかし、詳細についてはまだ多くの更なる検討が必要であり、そのうちの１つは以下の通りである。
合意事項
ＣＰソリューション
［．．．］
・Ｔ３００とｍａｃ−ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒの変更が必要かどうかは更なる検討が必要
この付記において、タイマの側面のさらなる考察が検討される。
（２．検討）
（２．１．前提）
提案１：ＲＡＮ２は、ＤＬ専用のＥＤＴプロシージャがサポートされているかどうかについて検討すべきである。
（２．２．Ｔ３００及び競合解決タイマ）
（２．２．１．Ｍｓｇ４遅延の問題）
考察１：ＥＤＴにおけるＭｓｇ３とＭｓｇ４の間の持続時間は、上位レイヤからの往復時間のために、従来よりも長くなる。
ｍａｃ−Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒに関しては、アーリーコンテンションレゾリューションを使用してタイマ満了を防ぐことができた。ＮＢ−ＩｏＴＵＥの場合、Ｒｅｌ−１４以降がアーリーコンテンションレゾリューションをサポートすることは合意されたが、それがオプションであるかどうかは更なる検討が必要である。
提案２：アーリーコンテンションレゾリューションがＥＤＴ対応ＮＢ−ＩｏＴ ＵＥによってサポートされている場合、ＲＡＮ２はｍａｃ−Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｔｉｍｅｒへの変更が不要であることに合意すべきである。
Ｔ３００に関しては、上位レイヤからの往復時間の影響を直接受ける。ＣＥモードＢの再送や再送などを考慮して、タイマ値を拡張することが提案されている。
したがって、Ｔ３００の満了による不要な障害を防ぐために、より長いタイマ値を定義するのは簡単である。
提案３：ＲＡＮ２は、Ｔ３００の満了による不要な障害を防ぐために、Ｍｓｇ３上のＵＬＥＤＴとＭｓｇ４上のＤＬＥＤＴとの間で動作するタイマのためにより長い値を定義すべきである。
（２．２．２．Ｍｓｇ４受信用のＤＲＸ）
提案３が納得のいくものであれば、既存のＴ３００のタイマ値を拡張するのは簡単である。しかし、これは、Ｍｓｇ４の受信まで連続的なＰＤＣＣＨモニタリングのために追加のＵＥ電力消費を引き起こし、それによってＭｓｇ４は前のセクションで説明したようにＥＤＴで遅延することがある。このような不必要な電力消費を避けるために、何らかの種類のＤＲＸのような受信モードがＥＤＴプロシージャに導入されるべきである。
例えば、単純なソリューションとして、ＵＥは、タイマが満了する直前のサブフレーム、すなわち「ワンショット」モニタリングにおいてのみ、ＰＤＣＣＨをモニタすることができる。高遅延通信［１０］のようないくつかのＭＴＣ／ＮＢ−ＩｏＴユースケースでは、連続モニタリングよりもうまくいく可能性がある。
提案４：ＲＡＮ２は、ＥＤＴプロシージャにおいて（すなわち、Ｍｓｇ３送信からＭｓｇ４受信までの間に）不連続受信が許容されるかどうかを検討すべきである。
（２．２．３．タイマ値の設定）
さらに、ｅＮＢがタイマ値をどのように設定するかは疑問である。というのは、ＴＣＰＡＣＫが上位レイヤのメッセージから到着するとき、ｅＮＢには未知であるからである。セルには様々なアプリケーションを実装する多数のＵＥが存在すると仮定されているので、ｅＮＢが全てのＵＥに対して適切なタイマ値を設定することは困難である。
考察４：異なるＵＥが異なるアプリケーションを使用する可能性があることを考慮して、適切なタイマ値を設定することは困難である。
１つの可能性は、Ｍｓｇ２に専用のシグナリングを使用してタイマを設定することであるが、ｅＮＢでアプリケーションレイヤの知識なしにタイマ値を決定することは依然として困難である。一方、ＵＥは、上位レイヤにおけるそのタイムアウト設定に基づいて適切なタイマ値を設定するのを助けることができる。例えば、ＵＥは、Ｍｓｇ３上の自己設定タイマ値をｅＮＢに通知することができる。
提案５：ＲＡＮ２は、ＵＥがＭｓｇ３上の自己設定タイマ値をｅＮＢに通知することを許可されているかどうかを検討すべきである。
（２．２．４．タイマの定義）
上記の提案（提案３〜提案５）の１つ又は複数が合意可能である場合、ＥＤＴのタイマの概念は従来のタイマとは異なる。ＥＤＴ可能なＵＥが、例えば、より大きなパケット送信のためにレガシーＲＲＣ接続確立／再開を開始することも可能であり、これによりレガシータイマがこの場合に適用可能である。この意味で、既存のタイマをそのまま維持し、既存のタイマを拡張するのではなく、ＥＤＴ固有の新しいタイマを定義する方が簡単である。
提案６：ＲＡＮ２は、レガシータイマではなく、ＵＬ ＥＤＴ（Ｍｓｇ３以上）とＤＬ ＥＤＴ（Ｍｓｇ４以上）の間で動作する新しいタイマを定義することに合意すべきである。
［付記７］
（１．はじめに）
ＲＡＮ２＃１０１はＵＬ ＥＤＴのパディング問題のソリューションとして以下のように合意した。
合意事項
・ＥＤＴ ＵＬグラントは、提供されたＵＬグラントが従来のＭｓｇ３のものでない限り、システム情報においてブロードキャストされる最大ＴＢサイズを常に許可するものとする。
・ＥＤＴ ＵＬグラントは、ＵＥがＵＬデータに基づいて提供されるＴＢサイズのセットから適切なＴＢサイズ、ＭＣＳ、繰り返し回数、及びＲＵ（ＮＢ−ＩｏＴのために）を選択することを可能にする。可能なＴＢサイズ、ＭＣＳ、繰り返し回数、及びＲＵ（ＮＢ−ＩｏＴの場合）のセットがどのように提供されるか（例えば仕様書にハードコードされる）は更なる検討が必要である。これは保留中のＲＡＮ１確認事項である。
・ＲＡＮ２は、システム情報でブロードキャストされる最大ＴＢサイズの８つの候補値を想定している。ＲＡＮ２は、ブロードキャストされる各最大ＴＢサイズについて、最大４つの可能なＴＢサイズ、すなわちブラインド復号オプションが許容されると仮定する。
・ｅＭＴＣの場合、必要な場合にのみ、ＭＡＣ ＲＡＲの予約ビットをｅＭＴＣのＥＤＴ機能に使用できる。
・可能な最大及び最小ＴＢサイズの合意を含む上記の合意をキャプチャしてＲＡＮ１にＬＳを送り、ＲＡＮ１に確認を依頼する。
この付記では、ソリューションの仕組みについてさらに検討する。
（２．検討）
現在の仮定の下でのソリューションにおけるＴＢＳの関連は、図３２に示すように表すことができる。図３２は、ＥＤＴのＵＬグラントサイズと実際のＵＬ送信を示す。
ＵＥの観点から、４つのブラインド復号オプションを有するＥＤＴのためのＵＬグラントは、ＵＥが必要なパディングビットを最小化するＴＢＳを選択することを可能にする。しかしながら、ＥＤＴのための付与されたＵＬデータサイズが（少なくともＣＰソリューションのために）「適合」しない場合、ＵＥはレガシープロシージャを開始し、ＲＲＣ Ｃｏｎｎｅｃｔｅｄに移行することができる。したがって、ＵＥの観点から、最大ＴＢＳ及びブラインド符号化オプションの数は可能な限り高く設定されるべきである。
考察１：ＵＥは、最大ＴＢＳ及び／又はブラインド復号オプションがそのＵＬデータサイズで良好な「適合」である場合にＥＤＴを開始することができる。
対照的に、ＮＷの観点から、最大ＴＢＳは、リソースの無駄を最小限に抑えるために、実際的に実現可能な低い値に設定する必要がある。したがって、いくつかの実装では、最大ＴＢＳ値の設定がより保守的になる傾向がある。しかしながら、この設定は、何台のＵＥがＥＤＴを利用するか、すなわち、ＮＷがＵＥの低電力動作をサポートするかどうかに関して直接の影響を有する。ＮＷは、様々なＭＴＣアプリケーションを有するＵＥの必要なＵＬデータサイズを認識していない可能性があるので、ＮＷ実装が最大ＴＢＳ及びブラインド復号オプションを最適化するための適切な手段を有するかどうかはまだはっきりしていない。
考察２：ＥＤＴの有用性は、最適な最大ＴＢＳ設定に依存する。
考察３：最大ＴＢＳ及びブラインド復号オプションの設定は、ＭＴＣアプリケーションのＵＬデータサイズ要件に基づいている必要がある。
上記の見解を考慮して、ＮＷ最適化の一部として、ＵＥがその意図されたアプリケーションについてフィードバック（特に、ＵＬデータサイズ）を提供する必要があるかどうかを検討すべきである。
ＵＥがＲＲＣ ＩＤＬＥに戻る（例えば、ＲＡＩを送信する）前に、ＵＥは、支援情報としてＥＤＴのためのその好ましいＴＢＳをｅＮＢに通知する機会を有することができる。支援情報は、以下の場合に意味がある。
・ケース１：ＢＳＲと同様に、情報を次のＥＤＴの予想データサイズとして使用することができる。これにより、ＳＩＢの設定を変更するための参照の１つになる。
・ケース２：ＵＥ能力と同様に、情報は、次のＥＤＴ可能性のためにＮＣＣがＵＥに提供されるべきかどうかを決定するために使用されてもよい。
・ケース３：ＭＤＴと同様に、情報は統計分析やＮＷ最適化に使用できる。
したがって、ＥＤＴの運用に関連する支援情報を導入すべきである。
提案１：ＲＡＮ２は、ＵＥがＴＢＳ設定最適化、例えばその好ましいＴＢＳのための支援情報を送信することを可能にすることに合意すべきである。
さらに、ＵＥがレガシーにフォールバックする場合、すなわち、例えば、追加のＵＬデータがアプリケーションによって生成されたために、Ｍｓｇ１にＥＤＴインディケーションを送信してＥＤＴにＵＬグラントを受信した後でも、ＵＥがレガシーＭｓｇ３を送信する場合がある。そのケースを考慮する必要がある場合、ＥＤＴ ＵＬグラントは、合意された４つのオプションに加えて、従来のＭｓｇ３サイズのブラインド復号オプションを常に許可する必要がある。
提案２：ＲＡＮ２は、合意された４つのオプションに加えて、ＥＤＴ ＵＬグラントが常にレガシーＭｓｇ３サイズのブラインド復号オプションを許可すべきかどうかについて検討すべきである。
［相互参照］
本願は、米国仮出願第６２／５４３４６９号（２０１７年８月１０日出願）、米国仮出願第６２／５６０７７５号（２０１７年９月２０日出願）、米国仮出願第６２／５６４４３０号（２０１７年９月２８日出願）、米国仮出願第６２／５８６９８１号（２０１７年１１月１６日出願）、米国仮出願第６２／６２７３１３号（２０１８年２月７日出願）、米国仮出願第６２／６３０９１５号（２０１８年２月１５日出願）、米国仮出願第６２／６５２４３６号（２０１８年４月４日出願）の優先権を主張し、その内容のすべてが本願明細書に組み込まれている。

Claims (4)

  1. ランダムアクセスプロシージャ中に上りリンクユーザデータを送信するアーリーデータ伝送を制御するための通信制御方法であって、
    基地局が、前記アーリーデータ伝送を伴わない前記ランダムアクセスプロシージャのための第１のタイマ値と、前記アーリーデータ伝送を伴う前記ランダムアクセスプロシージャのための第２のタイマ値とをユーザ装置に送信するステップと、
    前記ユーザ装置が、前記アーリーデータ伝送を行うと判断したことに応じて、前記第２のタイマ値を選択するステップと、
    前記ユーザ装置が、前記アーリーデータ伝送により前記上りリンクデータを送信する際に、前記第２のタイマ値を設定したタイマを開始させるステップと、を備える、
    通信制御方法。
  2. 前記タイマは、前記ランダムアクセスプロシージャにおいて前記ユーザ装置がＭｓｇ３を送信してからＭｓｇ４を受信するまでの最大待ち時間を規定するタイマであり、
    前記アーリーデータ伝送において、前記ユーザ装置が、前記Ｍｓｇ３の送信時に前記上りリンクユーザデータを送信する、
    請求項１に記載の通信制御方法。
  3. ユーザ装置であって、
    ランダムアクセスプロシージャ中に上りリンクユーザデータを送信するアーリーデータ伝送を伴わない前記ランダムアクセスプロシージャのための第１のタイマ値と、前記アーリーデータ伝送を伴う前記ランダムアクセスプロシージャのための第２のタイマ値とを基地局から受信する処理と、
    前記アーリーデータ伝送を行うと判断したことに応じて、前記第２のタイマ値を選択する処理と、
    前記アーリーデータ伝送により前記上りリンクデータを送信する際に、前記第２のタイマ値を設定したタイマを開始させる処理と、を行う
    ユーザ装置。
  4. 基地局であって、
    ランダムアクセスプロシージャ中に上りリンクユーザデータを送信するアーリーデータ伝送を伴わない前記ランダムアクセスプロシージャのための第１のタイマ値と、前記アーリーデータ伝送を伴う前記ランダムアクセスプロシージャのための第２のタイマ値とを送信する処理を行う制御部を備える
    基地局。
JP2020109187A 2017-08-10 2020-06-24 通信制御方法 Active JP6964164B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021170462A JP7307134B2 (ja) 2017-08-10 2021-10-18 通信制御方法
JP2023107514A JP2023123751A (ja) 2017-08-10 2023-06-29 通信制御方法

Applications Claiming Priority (15)

Application Number Priority Date Filing Date Title
US201762543469P 2017-08-10 2017-08-10
US62/543,469 2017-08-10
US201762560775P 2017-09-20 2017-09-20
US62/560,775 2017-09-20
US201762564430P 2017-09-28 2017-09-28
US62/564,430 2017-09-28
US201762586981P 2017-11-16 2017-11-16
US62/586,981 2017-11-16
US201862627313P 2018-02-07 2018-02-07
US62/627,313 2018-02-07
US201862630915P 2018-02-15 2018-02-15
US62/630,915 2018-02-15
US201862652436P 2018-04-04 2018-04-04
US62/652,436 2018-04-04
JP2019535634A JP6732231B2 (ja) 2017-08-10 2018-08-06 通信制御方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2019535634A Division JP6732231B2 (ja) 2017-08-10 2018-08-06 通信制御方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021170462A Division JP7307134B2 (ja) 2017-08-10 2021-10-18 通信制御方法

Publications (2)

Publication Number Publication Date
JP2020162170A JP2020162170A (ja) 2020-10-01
JP6964164B2 true JP6964164B2 (ja) 2021-11-10

Family

ID=65272236

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2019535634A Active JP6732231B2 (ja) 2017-08-10 2018-08-06 通信制御方法
JP2020109187A Active JP6964164B2 (ja) 2017-08-10 2020-06-24 通信制御方法
JP2021170462A Active JP7307134B2 (ja) 2017-08-10 2021-10-18 通信制御方法
JP2023107514A Pending JP2023123751A (ja) 2017-08-10 2023-06-29 通信制御方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2019535634A Active JP6732231B2 (ja) 2017-08-10 2018-08-06 通信制御方法

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2021170462A Active JP7307134B2 (ja) 2017-08-10 2021-10-18 通信制御方法
JP2023107514A Pending JP2023123751A (ja) 2017-08-10 2023-06-29 通信制御方法

Country Status (5)

Country Link
US (2) US11716754B2 (ja)
EP (3) EP3651503B1 (ja)
JP (4) JP6732231B2 (ja)
CN (2) CN114630448A (ja)
WO (1) WO2019031427A1 (ja)

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109863783B (zh) * 2017-04-28 2022-05-31 Lg 电子株式会社 根据edt发送数据的方法
EP3755067A4 (en) * 2018-02-14 2020-12-30 Huawei Technologies Co., Ltd. INFORMATION PROCESSING METHOD AND DEVICE
WO2019157752A1 (zh) 2018-02-14 2019-08-22 华为技术有限公司 随机接入方法及装置
WO2019185588A1 (en) * 2018-03-27 2019-10-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods providing early redirection in wireless devices
JPWO2019194296A1 (ja) * 2018-04-04 2021-01-07 京セラ株式会社 通信制御方法
CN110831240B (zh) * 2018-08-07 2023-07-18 财团法人资讯工业策进会 在随机接入程序进行提早数据传输的基站与用户设备
BR112021002355A2 (pt) * 2018-08-09 2021-05-04 Zte Corporation recurso dedicado pré-configurado para transmissões em modo ocioso
CN110831197B (zh) * 2018-08-09 2023-10-10 北京三星通信技术研究有限公司 用于rrc空闲态上行传输的方法及设备
WO2020034303A1 (en) * 2018-09-20 2020-02-20 Zte Corporation Methods, apparatus and systems for scheduling resources in a wireless communication
CN110958688B (zh) * 2018-09-26 2024-01-09 夏普株式会社 用户设备及其执行的方法、基站及其执行的方法
US11259331B2 (en) 2018-09-27 2022-02-22 Ofinno, Llc RACH type switching
US11671858B2 (en) * 2018-09-28 2023-06-06 Lg Electronics Inc. Relaxed measurement based on data transmission
KR20200088161A (ko) * 2019-01-14 2020-07-22 삼성전자주식회사 이동통신 시스템에서 2 단계 랜덤 엑세스 과정을 통해 사용자 데이터를 전송하는 방법 및 장치
WO2020166618A1 (ja) * 2019-02-12 2020-08-20 京セラ株式会社 通信制御方法、ユーザ装置、及び基地局
CN113383607A (zh) * 2019-02-14 2021-09-10 瑞典爱立信有限公司 随机接入过程
US11812480B2 (en) 2019-03-28 2023-11-07 Telefonaktiebolaget Lm Ericsson (Publ) Indication of user equipment reply to early data transmission
WO2020222520A1 (en) * 2019-05-02 2020-11-05 Lg Electronics Inc. Method and apparatus for combining mo edt procedure with mt edt procedure in a wireless communication system
WO2020237442A1 (zh) * 2019-05-24 2020-12-03 Oppo广东移动通信有限公司 用于随机接入的方法及设备
WO2020263283A1 (en) * 2019-06-28 2020-12-30 Nokia Technologies Oy Early data transmission for dual connectivity or carrier aggregation
CN115767783A (zh) * 2019-07-04 2023-03-07 Oppo广东移动通信有限公司 一种数据传输方法及装置、网络设备、终端
CN111800858B (zh) 2019-07-11 2023-01-03 维沃移动通信有限公司 Edt数据的发送方法和设备
CN111836396B (zh) * 2019-08-06 2022-02-08 维沃移动通信有限公司 一种随机接入请求资源的选择方法、终端及网络设备
CN114245992A (zh) * 2019-08-20 2022-03-25 高通股份有限公司 在空闲和/或非活动模式下针对移动台终止的小数据接收的寻呼
EP4030866A4 (en) * 2019-09-13 2022-10-26 Kyocera Corporation COMMUNICATION CONTROL PROCEDURES
EP4035483A4 (en) * 2019-09-25 2023-05-03 Telefonaktiebolaget LM Ericsson (publ.) OPTIMIZATION FOR EARLY DATA TRANSMISSION (EDT)
CN112566273B (zh) * 2019-09-26 2022-12-23 维沃移动通信有限公司 一种数据接收、发送方法、终端及网络侧设备
CN112584496B (zh) * 2019-09-27 2023-06-30 维沃移动通信有限公司 一种资源使用方法及通信设备
KR20220068253A (ko) * 2019-09-30 2022-05-25 베이징 시아오미 모바일 소프트웨어 컴퍼니 리미티드 정보 처리 방법 및 장치, 통신 기기 및 저장 매체
CN114642026A (zh) * 2019-12-04 2022-06-17 华为技术有限公司 一种通信方法、装置及设备
CN115665870A (zh) * 2020-02-01 2023-01-31 上海朗帛通信技术有限公司 一种被用于无线通信的通信节点中的方法和装置
US20230122070A1 (en) * 2020-04-09 2023-04-20 Qualcomm Incorporated Discontinuous reception during early data transfer
WO2021207982A1 (zh) * 2020-04-15 2021-10-21 Oppo广东移动通信有限公司 一种数据传输方法、终端设备、网络设备
WO2021217042A1 (en) * 2020-04-24 2021-10-28 Qualcomm Incorporated Release assistance during early data transmission
WO2021226793A1 (en) * 2020-05-11 2021-11-18 Qualcomm Incorporated Low-latency transmit for rolling comments
WO2021232434A1 (zh) * 2020-05-22 2021-11-25 Oppo广东移动通信有限公司 基于随机接入流程的波束链路恢复方法、装置和设备
CN111800816B (zh) * 2020-07-06 2022-06-10 重庆邮电大学 一种终端实现最小路测功能的方法
US20230224952A1 (en) * 2020-07-21 2023-07-13 Qualcomm Incorporated Uplink data transfer over random access or dedicated uplink resources
US20220312489A1 (en) * 2020-08-06 2022-09-29 Apple Inc. User Equipment (UE) RACH Procedures for Reduced Latency in High-Propagation-Delay Networks
KR102600396B1 (ko) 2020-08-31 2023-11-08 오피노 엘엘씨 소형 데이터 송신을 위한 후속 데이터 정보
US20220078875A1 (en) * 2020-09-08 2022-03-10 Asustek Computer Inc. Method and apparatus for timer control for rrc connection resume procedure in a wireless communication system
EP4207916A4 (en) * 2020-09-28 2024-02-14 Guangdong Oppo Mobile Telecommunications Corp Ltd SMALL DATA TRANSMISSION METHOD AND APPARATUS AND TERMINAL DEVICE
EP4223013A1 (en) * 2020-09-30 2023-08-09 Lenovo (Beijing) Limited Methods and apparatuses for random access
TW202224482A (zh) * 2020-10-08 2022-06-16 香港商翼勝科技有限公司 小資料傳輸方法、用戶設備和基地台
WO2022079876A1 (ja) * 2020-10-15 2022-04-21 株式会社Ｎｔｔドコモ 端末
US20230397198A1 (en) * 2020-10-21 2023-12-07 Nokia Technologies Oy Small data transmission procedure to random access procedure fallback
US20240057170A1 (en) * 2020-12-30 2024-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Random access for wireless communication network
EP4278848A1 (en) * 2021-01-14 2023-11-22 Ofinno, LLC Pdcch reception for rrc connection made through small data transmission
JPWO2022180713A1 (ja) * 2021-02-25 2022-09-01
CN115134933A (zh) * 2021-03-25 2022-09-30 夏普株式会社 确定随机接入过程是否成功的方法以及用户设备
US11675733B2 (en) 2021-06-15 2023-06-13 Itron, Inc. Techniques for release assistance indication assertion
US11818658B2 (en) * 2021-06-15 2023-11-14 Itron, Inc. Techniques for release assistance indication assertion
US11830354B2 (en) 2021-06-15 2023-11-28 Itron, Inc. Techniques for release assistance indication assertion
CN113260085B (zh) * 2021-06-21 2021-11-09 北京智联安科技有限公司 一种提高上行数据传输效率的方法及装置
WO2023135760A1 (ja) * 2022-01-14 2023-07-20 株式会社Ｎｔｔドコモ 端末及び通信方法
WO2024011549A1 (zh) * 2022-07-14 2024-01-18 北京小米移动软件有限公司 多物理随机接入信道prach传输方法及装置
CN117440369B (zh) * 2023-12-20 2024-02-27 深圳市佳贤通信科技股份有限公司 基于家庭小站系统的用户快速识别方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010232811A (ja) 2009-03-26 2010-10-14 Nippon Syst Wear Kk 輻輳時の規制情報表示方法、および、規制情報表示システム
CN102223729B (zh) 2010-04-16 2016-06-29 中兴通讯股份有限公司 控制机器类型通信设备接入网络的方法及系统
US20120254890A1 (en) * 2011-04-01 2012-10-04 Renesas Mobile Corporation Small Data Transmission For Detached Mobile Devices
CA2844411C (en) 2011-08-11 2017-01-31 Intel Corporation Extended access barring
JP2014143616A (ja) * 2013-01-24 2014-08-07 Ntt Docomo Inc ユーザ装置、ゲートウェイ装置、無線基地局、移動通信システム及び移動通信方法
CN103763748A (zh) * 2014-01-23 2014-04-30 中国联合网络通信集团有限公司 一种数据传输方法及装置
US10009926B2 (en) * 2014-07-11 2018-06-26 Qualcomm Incorporated Methods and apparatus for connectionless access
US10251191B2 (en) * 2014-08-25 2019-04-02 Lg Electronics Inc. Method and apparatus for scheduling request in a wireless communication system
CN105830498B (zh) 2014-10-20 2020-02-14 华为技术有限公司 一种目标小区选择方法和终端
JP6481908B2 (ja) * 2014-10-23 2019-03-13 インテル アイピー コーポレーション マシン・タイプ・コミュニケーション（ｍｔｃ）機器のための接続制御
WO2016122394A1 (en) * 2015-01-30 2016-08-04 Telefonaktiebolaget Lm Ericsson (Publ) Method for enhancing the uplink performance of coverage-limited devices
JP6397994B2 (ja) 2015-04-10 2018-09-26 京セラ株式会社 通信方法、ユーザ端末及びプロセッサ
US10299244B2 (en) * 2015-06-19 2019-05-21 Qualcomm Incorporated Small data transmission in a wireless communications system
US20170099660A1 (en) * 2015-10-01 2017-04-06 Electronics And Telecommunications Research Institute Method and apparatus for transmitting uplink data
US20180014274A1 (en) 2016-07-06 2018-01-11 Mediatek Inc. Paging Context Handling For Multi-Carrier Load Distribution In Mobile Communications
US20180324854A1 (en) 2017-05-04 2018-11-08 Qualcomm Incorporated Uplink small data transmission for enhanced machine-type-communication (emtc) and internet of things (iot) communication
EP3813482B1 (en) * 2017-07-27 2023-04-12 LG Electronics, Inc. Method and apparatus for performing edt
US10397833B2 (en) * 2017-07-27 2019-08-27 Lg Electronics Inc. Method and apparatus for performing EDT
EP3949561A1 (en) * 2019-03-29 2022-02-09 Telefonaktiebolaget LM ERICSSON (PUBL) Preconfigured uplink resources - configuration for ta validity in entire cell

Also Published As

Publication number Publication date
JP2020162170A (ja) 2020-10-01
JP2022009214A (ja) 2022-01-14
WO2019031427A1 (ja) 2019-02-14
CN110999404A (zh) 2020-04-10
JP7307134B2 (ja) 2023-07-11
EP3955690B1 (en) 2023-06-07
JP2023123751A (ja) 2023-09-05
EP4236400A3 (en) 2023-09-13
JPWO2019031427A1 (ja) 2020-05-28
US20230337274A1 (en) 2023-10-19
JP6732231B2 (ja) 2020-07-29
CN114630448A (zh) 2022-06-14
EP3651503A1 (en) 2020-05-13
EP3651503A4 (en) 2020-07-08
US20220256587A1 (en) 2022-08-11
US11716754B2 (en) 2023-08-01
EP4236400A2 (en) 2023-08-30
EP3651503B1 (en) 2021-11-03
EP3955690A1 (en) 2022-02-16

Similar Documents

Publication Publication Date Title
JP6964164B2 (ja) 通信制御方法
US11350445B2 (en) Communication control method for controlling a user equipment to perform early data transmission
US9949282B2 (en) Method for transmitting MAC PDUs
JP5719058B2 (ja) Ｍａｃｐｄｕを送信する方法
US8307252B2 (en) Method and apparatus for performing random access procedures
CN102474350B (zh) 在无线通信系统中控制物理下行链路信道的监视操作的方法
WO2013120458A1 (zh) 数据传输方法、基站及用户设备
CN111147202A (zh) 一种车联网的数据传输方法、发送终端和网络侧设备

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200624

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210921

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211018

R150 Certificate of patent or registration of utility model

Ref document number: 6964164

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150