[第1実施形態]
(第1実施形態の概要)
MTCやIoTを対象とした無線端末は、一般的な無線端末に比べて、送受信すべきデータの量が少なく、データの送受信を行う頻度も少ない。よって、MTCやIoTを対象とした無線端末が効率的に通信を行うために、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送(early data transmission)が検討されている。しかしながら、現状の移動通信システムはランダムアクセスプロシージャ中にデータを送信することを想定しておらず、アーリーデータ伝送を実現可能とする仕組みが存在しない。
そこで、本開示は、アーリーデータ伝送を実現可能とする通信制御方法を提供することを目的とする。
第1実施形態に係る通信制御方法は、移動通信システムにおける方法である。前記通信制御方法は、第1無線通信装置が、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送を行うか否かに関する情報を第2無線通信装置に送信するステップAと、前記第2無線通信装置が前記情報を受信した後、前記第2無線通信装置が、当該受信した情報に基づいて前記アーリーデータ伝送を行うか否かを判断するステップBとを備える。前記第1無線通信装置は無線端末及び基地局のうち一方であり、前記第2無線通信装置は前記無線端末及び前記基地局のうち他方である。前記ステップAは、前記所定メッセージの送信タイミングよりも前に行われる。
(移動通信システム)
第1実施形態に係る移動通信システムの構成について説明する。図1は、第1実施形態に係る移動通信システムであるLTE(Long Term Evolution)システムの構成を示す図である。LTEシステムは、3GPP規格に基づく移動通信システムである。
LTEシステムは、無線端末(UE:User Equipment)100、無線アクセスネットワーク(E−UTRAN:Evolved−UMTS Terrestrial Radio Access Network)10、及びコアネットワーク(EPC:Evolved Packet Core)20を備える。
UE100は、移動型の通信装置である。UE100は、自身が在圏するセル(サービングセル)を管理するeNB200との無線通信を行う。
E−UTRAN10は、基地局(eNB:evolved Node−B)200を含む。eNB200は、X2インターフェイスを介して相互に接続される。eNB200は、1又は複数のセルを管理する。eNB200は、自セルとの接続を確立したUE100との無線通信を行う。eNB200は、無線リソース管理(RRM)機能、ユーザデータ(以下、単に「データ」という)のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、UE100との無線通信を行う機能又はリソースを示す用語としても用いられる。1つのセルは1つのキャリア周波数に属する。
EPC20は、モビリティ管理エンティティ(MME)及びサービングゲートウェイ(S−GW)300を含む。MMEは、UE100に対する各種モビリティ制御等を行う。MMEは、NAS(Non−Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するトラッキングエリア(TA)の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。S−GWは、データの転送制御を行う。MME及びS−GWは、S1インターフェイスを介してeNB200と接続される。
図2は、UE100(無線端末)の構成を示す図である。UE100は、受信部110、送信部120、及び制御部130を備える。
受信部110は、制御部130の制御下で各種の受信を行う。受信部110は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部130に出力する。
送信部120は、制御部130の制御下で各種の送信を行う。送信部120は、アンテナ及び送信機を含む。送信機は、制御部130が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部130は、UE100における各種の制御を行う。制御部130は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPU(Central Processing Unit)と、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
図3は、eNB200(基地局)の構成を示す図である。eNB200は、送信部210、受信部220、制御部230、及びバックホール通信部240を備える。
送信部210は、制御部230の制御下で各種の送信を行う。送信部210は、アンテナ及び送信機を含む。送信機は、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
受信部220は、制御部230の制御下で各種の受信を行う。受信部220は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。
制御部230は、eNB200における各種の制御を行う。制御部230は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPUと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
バックホール通信部240は、X2インターフェイスを介して隣接eNBと接続される。バックホール通信部240は、S1インターフェイスを介してMME/S−GW300と接続される。バックホール通信部240は、X2インターフェイス上で行う通信及びS1インターフェイス上で行う通信等に用いられる。
図4は、LTEシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。図4に示すように、無線インターフェイスプロトコルは、OSI参照モデルの第1レイヤ乃至第3レイヤに区分されている。第1レイヤは物理(PHY)レイヤである。第2レイヤは、MAC(Medium Access Control)レイヤ、RLC(Radio Link Control)レイヤ、及びPDCP(Packet Data Convergence Protocol)レイヤを含む。第3レイヤは、RRC(Radio Resource Control)レイヤを含む。PHYレイヤ、MACレイヤ、RLCレイヤ、PDCPレイヤ、及びRRCレイヤは、AS(Access Stratum)レイヤを構成する。
PHYレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。UE100のPHYレイヤとeNB200のPHYレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
MACレイヤは、データの優先制御、ハイブリッドARQ(HARQ)による再送処理、及びランダムアクセスプロシージャ等を行う。UE100のMACレイヤとeNB200のMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。eNB200のMACレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS))及びUE100への割当リソースブロックを決定する。
RLCレイヤは、MACレイヤ及びPHYレイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。UE100のRLCレイヤとeNB200のRLCレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
RRCレイヤは、制御情報を取り扱う制御プレーンでのみ定義される。UE100のRRCレイヤとeNB200のRRCレイヤとの間では、各種設定のためのRRCシグナリングが伝送される。RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。UE100のRRCとeNB200のRRCとの間に接続(RRC接続)がある場合、UE100はRRCコネクティッドモードである。UE100のRRCとeNB200のRRCとの間に接続(RRC接続)がない場合、UE100はRRCアイドルモードである。
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。UE100のNASレイヤとMME300CのNASレイヤとの間では、NASシグナリングが伝送される。UE100は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。
図5は、LTEシステムにおいて用いられる無線フレームの構成を示す図である。無線フレームは、時間軸上で10個のサブフレームで構成される。各サブフレームは、時間軸上で2個のスロットで構成される。各サブフレームの長さは1msである。各スロットの長さは0.5msである。各サブフレームは、周波数軸上で複数個のリソースブロック(RB)を含む。各サブフレームは、時間軸上で複数個のシンボルを含む。各リソースブロックは、周波数軸上で複数個のサブキャリアを含む。具体的には、12個のサブキャリア及び1つのスロットにより1つのRBが構成される。1つのシンボル及び1つのサブキャリアにより1つのリソースエレメント(RE)が構成される。UE100に割り当てられる無線リソース(時間・周波数リソース)のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム(又はスロット)により特定できる。
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル(PDCCH:Physical Downlink Control Channel)として用いられる領域である。各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル(PDSCH:Physical Downlink Shared Channel)として用いることができる領域である。
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル(PUCCH:Physical Uplink Control Channel)として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル(PUSCH:Physical Uplink Shared Channel)として用いることができる領域である。
(eMTC及びNB−IoTの概要)
eMTC及びNB−IoTの概要について説明する。第1実施形態において、MTC及びIoTサービスを対象とした新たなカテゴリのUE100が存在するシナリオを想定する。新たなカテゴリのUE100は、システム送受信帯域(LTE送受信帯域幅)の一部のみに送受信帯域幅が制限されるUE100である。新たなUEカテゴリは、例えば、カテゴリM1及びカテゴリNB(Narrow Band)−IoTと称される。カテゴリM1は、eMTC(enhanced Machine Type Communications)UEが属するカテゴリである。カテゴリNB−IoT(カテゴリNB1)は、NB−IoT UEが属するカテゴリである。カテゴリM1は、UE100(eMTC UE)の送受信帯域幅を例えば1.08MHz(すなわち、6リソースブロックの帯域幅)に制限する。カテゴリNB−IoT(カテゴリNB1)は、UE100(NB−IoT UE)の送受信帯域幅を180kHz(すなわち、1リソースブロックの帯域幅)にさらに制限する。このような狭帯域化により、eMTC UE及びNB−IoT UEに要求される低コスト化及び低消費電力化が実現可能となる。
図6は、eMTC UE及びNB−IoT UEが取り扱う周波数チャネルを示す図である。図6に示すように、LTEシステムのシステム周波数帯域の周波数帯域幅は10MHzであり得る。システム送受信帯域の帯域幅は、例えば、50リソースブロック=9MHzである。eMTC UEが対応可能な周波数チャネルの帯域幅は、6リソースブロック=1.08MHz以内である。eMTC UEが対応可能な6リソースブロック以内の周波数チャネルは、「狭帯域(NB:Narrow Band)」と称される。NB−IoT UEが対応可能な周波数チャネルの帯域幅は、1リソースブロック=180kHzである。NB−IoT UEが対応可能な1リソースブロックの周波数チャネルは、「キャリア(carrier)」と称される。
eMTC UEは、LTE送受信帯域幅内で運用される。NB−IoT UEは、LTE送受信帯域幅内で運用される形態、LTE送受信帯域幅外のガードバンドで運用される形態、及びNB−IoT専用の周波数帯域内で運用される形態をサポートする。
eMTC UE及びNB−IoT UEは、カバレッジ拡張を実現するために、繰り返し送信等を用いた強化カバレッジ(EC:Enhanced Coverage)機能をサポートする。強化カバレッジ機能は、複数のサブフレームを用いて同一信号を繰り返し送信する繰り返し送信(repetition)を含んでもよい。繰り返し送信の回数が多いほど、カバレッジを拡張することができる。強化カバレッジ機能は、送信信号の電力密度を上げる電力ブースト(power boosting)を含んでもよい。一例として、送信信号の周波数帯域幅を狭くする狭帯域送信により電力密度を上げる。送信信号の電力密度を上げるほど、カバレッジを拡張することができる。強化カバレッジ機能は、送信信号に用いるMCSを下げる低MCS(lower MCS)送信を含んでもよい。データレートが低く、誤り耐性の高いMCSを用いて送信を行うことにより、カバレッジを拡張することができる。
(ランダムアクセスプロシージャの概要)
図7は、eMTC UE及びNB−IoT UE向けのランダムアクセスプロシージャを示す図である。初期状態において、UE100は、RRCアイドルモードにある。UE100は、RRCコネクティッドモードに遷移するためにランダムアクセスプロシージャを実行する。このようなケースは、初期接続(Initial access from RRC_IDLE)と称される。初期接続時には、競合ベース(contention based)のランダムアクセスプロシージャが適用される。
UE100は、eNB200のセルをサービングセルとして選択している。UE100は、通常のカバレッジのための第1のセル選択基準(第1のS−criteria)が満たされず、強化カバレッジのための第2のセル選択基準(第2のS−criteria)が満たされた場合、自身が強化カバレッジに居ると判定してもよい。「強化カバレッジに居るUE」とは、セルにアクセスするために強化カバレッジ機能(強化カバレッジモード)を用いることが必要とされるUEを意味する。なお、eMTC UEは、強化カバレッジモードを用いることが必須である。ここでは、UE100が強化カバレッジに居ると仮定して説明を進める。
ステップS1001において、eNB200は、PRACH(Physical Random Access Channel)関連情報をブロードキャストシグナリング(例えば、SIB)により送信する。PRACH関連情報は、強化カバレッジレベルごとに設けられた各種のパラメータを含む。一例として、強化カバレッジレベルは、強化カバレッジレベル0乃至3の合計4つのレベルが規定される。各種のパラメータは、RSRP(Reference Signal Received Power)閾値、PRACHリソース、及び最大プリアンブル送信回数を含む。PRACHリソースは、無線リソース(時間・周波数リソース)及び信号系列(プリアンブル系列)を含む。UE100は、受信したPRACH関連情報を記憶する。
ステップS1002において、UE100は、eNB200から送信される参照信号に基づいてRSRPを測定する。
ステップS1003において、UE100は、測定したRSRPを強化カバレッジレベルごとのRSRP閾値と比較することにより、自身の強化カバレッジレベル(CEレベル)を決定する。強化カバレッジレベルは、UE100に必要とされる強化カバレッジの度合いを示す。強化カバレッジレベルは、少なくとも繰り返し送信における送信回数(すなわち、Repetition回数)と関連する。
ステップS1004において、UE100は、自身の強化カバレッジレベルに対応するPRACHリソースを選択する。
ステップS1005〜S1008は、ランダムアクセスプロシージャを構成する。ステップS1005において、UE100は、選択したPRACHリソースを用いてMsg1(ランダムアクセスプリアンブル)をeNB200に送信する。なお、「Msg」は、メッセージの略である。eNB200は、受信したMsg1に用いられたPRACHリソースに基づいて、UE100の強化カバレッジレベルを特定する。
ステップS1006において、eNB200は、UE100に割り当てたPUSCHリソースを示すスケジューリング情報を含むMsg2(ランダムアクセス応答)をUE100に送信する。UE100は、Msg2を正常に受信するまで、自身の強化カバレッジレベルに対応する最大プリアンブル送信回数までMsg1を複数回送信し得る。
ステップS1007において、UE100は、スケジューリング情報に基づいて、Msg3をeNB200に送信する。Msg3は、RRC接続要求(RRC Connection Request)メッセージであってもよい。
ステップS1008において、eNB200は、Msg4をUE100に送信する。Msg4は、RRC接続確立(RRC Connection Setup)メッセージであってもよい。
ステップS1009において、UE100は、Msg4の受信に応じてRRCコネクティッドモードに遷移する。その際、UE100は、Msg 5:RRC接続確立完了(RRC Connection Setup Complete)メッセージをeNB200に送信してもよい。その後、eNB200は、特定した強化カバレッジレベルに基づいて、UE100への繰り返し送信等を制御する。
(アーリーデータ伝送に係る動作)
第1実施形態に係るアーリーデータ伝送に係る動作について説明する。
アーリーデータ伝送は、ランダムアクセスプロシージャ中に所定メッセージを利用してデータ(ユーザデータ)を送信する伝送方法である。所定メッセージは、Msg1(ランダムアクセスプリアンブル)、Msg2(ランダムアクセス応答)、Msg3(例えば、RRC接続要求メッセージ)、Msg4(RRC接続確立メッセージ)、Msg 5(RRC接続確立完了メッセージ)の少なくともいずれかである。なお、「所定メッセージを利用してデータを送信する」とは、データを所定メッセージに含めて送信すること、データを所定メッセージに追加して送信すること、及びデータを所定メッセージに関連付けて送信することの少なくともいずれかである。
アーリーデータ伝送は、RRCサスペンド状態のUEに適用されてもよい。RRCサスペンド状態は、RRCアイドルモードの一状態であって、UEコンテキストがネットワークに保持される特殊な状態である。RRCサスペンド状態のUEがRRCコネクティッドモードに復旧するためのランダムアクセスプロシージャでは、Msg3はRRC接続復旧要求(RRC connection resume request)メッセージであり、Msg4はRRC接続復旧(RRC connection resume)メッセージであり、Msg 5はRRC接続復旧完了メッセージである。
第1実施形態に係る通信制御方法は、第1無線通信装置が、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送を行うか否かに関する情報を第2無線通信装置に送信するステップAと、第2無線通信装置が情報を受信した後、第2無線通信装置が、当該受信した情報に基づいてアーリーデータ伝送を行うか否かを判断するステップBとを備える。第1無線通信装置はUE100及びeNB200のうち一方であり、第2無線通信装置はUE100及びeNB200のうち他方である。ステップAは、所定メッセージの送信タイミングよりも前に行われる。
第1実施形態に係る動作パターン1〜4の概要について説明する。動作パターン1〜4は、上述した「ランダムアクセスプロシージャの概要」(図7参照)における動作の少なくとも一部と組み合わせることができる。
第1実施形態に係る動作パターン1では、ステップAは、UE100が、アーリーデータ伝送を行うか否かに基づいて、ランダムアクセスプリアンブルの送信に適用するリソースを選択するステップと、UE100が、当該選択したリソースが適用されたランダムアクセスプリアンブルを送信するステップとを含む。ステップBにおいて、eNB200は、ランダムアクセスプリアンブルに適用されたリソースに基づいて、アーリーデータ伝送を行うか否かを判断する。
第1実施形態に係る動作パターン2では、ステップAにおいて、UE100は、UE100がコネクティッドモードである間に、アーリーデータ伝送を行うことを示す通知をeNB200に送信する。動作パターン2は、通知の送信後、UE100がコネクティッドモードからアイドルモードに遷移するステップと、eNB200又は上位ネットワーク装置が、UE100がアイドルモードである間において通知を保持するステップとを更に備える。ステップBにおいて、eNB200は、ランダムアクセスプロシージャの際に、当該保持された通知に基づいてアーリーデータ伝送を行うか否かを判断する。
第1実施形態に係る動作パターン3では、ステップAにおいて、eNB200は、ランダムアクセスプロシージャが開始されるよりも前において、アーリーデータ伝送を行うか否かを示す通知を、ページングメッセージ、DCI(Downlink Control Information)、及びPDSCH(Physical Downlink Shared Channel)の少なくともいずれかによってUE100に送信する。ステップBにおいて、UE100は、eNB200からの通知に基づいて、アーリーデータ伝送を行うか否かを判断する。
第1実施形態に係る動作パターン4では、ステップAにおいて、eNB200は、ランダムアクセスプロシージャを開始するよりも前に、アーリーデータ伝送によって送信することが許容されるデータの量を示す情報をUE100に送信する。ステップBにおいて、UE100は、eNB200から通知されたデータの量と、当該UE100がeNB200に送信するデータの量とに基づいて、アーリーデータ伝送を行うか否かを判断する。
(1)動作パターン1
図8は、第1実施形態に係る動作パターン1を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。
図8に示すように、ステップS101において、eNB200は、ランダムアクセスプリアンブルの送信に利用可能なリソースであるPRACHリソース(PRACHリソースプール)を示すPRACHリソース情報をシステム情報(SIB)によって送信(ブロードキャスト)する。PRACHリソースは、無線リソース(時間・周波数リソース)及び/又は信号系列(プリアンブル系列)を含む。
PRACHリソースは、アーリーデータ伝送を行うこと(アーリーデータ伝送を行う意図)を示す第1リソースグループ(PRACHリソースプール)と、アーリーデータ伝送を行わないことを示す第2リソースグループ(PRACHリソースプール)とを含む。第1リソースグループと第2リソースグループとに分けられるPRACHリソースは、無線リソース(時間・周波数リソース)であってもよい。第1リソースグループと第2リソースグループとに分けられるPRACHリソースは、信号系列(プリアンブル系列)であってもよい。
eNB200は、第1リソースグループを示す情報と第2リソースグループを示す情報とをSIBに含める。第2リソースグループは、従来と同様なPRACHリソースであってもよい。第1リソースグループは、従来のPRACHリソースとは別に確保されたPRACHリソースであってもよい。
第1リソースグループは、アーリーデータ伝送によって上りリンクデータを送信することを示す第1リソースサブグループと、アーリーデータ伝送によって下りリンクデータを受信することを示す第2リソースサブグループとを含んでもよい。さらに、第1リソースグループは、アーリーデータ伝送によって上りリンクデータの送信と下りリンクデータの受信の両方を行うことを示す第3リソースサブグループを含んでもよい。eNB200は、複数のリソースサブグループ(第1リソースサブグループ、第2リソースサブグループ、及び第3リソースサブグループ)の少なくともいずれかを示す情報をSIBに含めてもよい。
RRCアイドルモードのUE100は、eNB200からSIBを受信する。RRCアイドルモードのUE100は、RRC接続を確立する必要が生じたと判断し、ランダムアクセスプロシージャの準備を開始する。ここで、UE100は、UE100内で上りリンクデータが発生したことに応じて、上りリンクデータを送信するために、RRC接続を確立する必要が生じたと判断してもよい。UE100は、自身宛のページングメッセージをeNB200から受信したことに応じて、下りリンクデータを受信するために、RRC接続を確立する必要が生じたと判断してもよい。
ステップS102において、RRCアイドルモードのUE100は、SIBで通知されたPRACHリソースの中から、ランダムアクセスプリアンブルの送信に適用するリソースを選択する。UE100は、アーリーデータ伝送を行う場合、第1リソースグループ中のリソースを選択する。一方で、UE100は、アーリーデータ伝送を行わない場合、第2リソースグループ中のリソースを選択する。アーリーデータ伝送を行うか否かは、次の1)〜7)の基準のうち少なくともいずれかに基づく。1)UE100の能力、すなわち、UE100がアーリーデータ伝送を行う能力を有するか否か。2)UE100が送信又は受信するデータの優先度(例えば、QoS)。3)UE100の電力状態(例えば、バッテリ残量)。4)データの遅延削減の要否(例えば、早期TCP ACK送信の必要性)。5)ユーザのプリファレンス(例えば、手動設定に依る)。6)ネットワークからの指示(例えば、MMEなどによる機能制限や認証結果に基づく)。7)eNBからの指示(例えば、eNBがアーリーデータ送受信能力を有するか否かに基づく)。なお、「アーリーデータ伝送を行う」とは、UE100がアーリーデータ伝送を行いたいことであってもよいし、アーリーデータ伝送を許容するか否かであってもよいし、アーリーデータ伝送が可能か否かであってもよい。
UE100は、アーリーデータ伝送を行うか否かを上りリンクと下りリンクとで別々に判断してもよい。UE100は、アーリーデータ伝送によって上りリンクデータを送信する場合、第1リソースサブグループ中のリソースを選択してもよい。UE100は、アーリーデータ伝送によって下りリンクデータを受信する場合、第2リソースサブグループ中のリソースを選択してもよい。
ステップS103において、UE100は、ステップS102で選択したリソースが適用されたMsg1(ランダムアクセスプリアンブル)を送信する。
ステップS104において、eNB200は、受信したランダムアクセスプリアンブルに適用されたリソースに基づいて、アーリーデータ伝送を行うか否かを判断する。例えば、第1リソースグループ中のリソースがランダムアクセスプリアンブルに適用されている場合、eNB200は、送信元のUE100についてアーリーデータ伝送を行うと判断する。さらに、eNB200は、リソースサブグループに基づいて、上りリンクのアーリーデータ伝送及び下りリンクのアーリーデータ伝送のいずれを行うかを判断してもよい。一方で、第2リソースグループ中のリソースがランダムアクセスプリアンブルに適用されている場合、eNB200は、送信元のUE100についてアーリーデータ伝送を行わないと判断する。
なお、動作パターン1において、時間・周波数リソースを分割するケースと信号系列リソースを分割するケースとを説明したが、時間・周波数リソースと信号系列リソースとを組み合わせて分割してもよい。例えば、時間・周波数リソースを第1リソースグループと第2リソースグループとに分割し、第1リソースグループにおいて信号系列リソースをリソースサブグループに分割してもよい。或いは、信号系列リソースを第1リソースグループと第2リソースグループとに分割し、第1リソースグループにおいて時間・周波数リソースをリソースサブグループに分割してもよい。
また、後述するように、上りリンクのアーリーデータ伝送は、下りリンクのアーリーデータ伝送とセットで用いられることがある。例えば、UE100は、上りリンクのアーリーデータ伝送によって上りリンクデータをMsg3で送信し、当該データに対する応答データ(TCP ACK等)を下りリンクのアーリーデータ伝送によってMsg4で受信する。よって、Msg1によってアーリーデータ伝送の意図を通知することを可能とする条件は、「UE100が上りリンクのアーリーデータ伝送及び下りリンクのアーリーデータ伝送の両方の能力を有している」という条件を含んでもよい。すなわち、上りリンクのアーリーデータ伝送及び下りリンクのアーリーデータ伝送の少なくとも一方の能力を有していないUE100は、Msg1によってアーリーデータ伝送の意図を通知することが禁止されてもよい。
さらに、アーリーデータ伝送の意図を通知するために用いられる新たなPRACHリソースプール(時間・周波数リソース)は、従来のPRACHリソースプール(時間・周波数リソース)とは別のリソースプールとして規定されることが好ましい。この場合、新たなPRACHリソースプールと従来のPRACHリソースプールとを重複しないように設定するか、又は新たなPRACHリソースプールと従来のPRACHリソースプールとを少なくとも一部重複して設定するかを、eNB200が決定し、eNB200が各PRACHリソースプールをUE100に通知(例えば、SIBにより通知)してもよい。
(2)動作パターン2
図9は、第1実施形態に係る動作パターン2を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。また、動作パターン1と重複する説明を省略する。動作パターン2は、上りリンクのアーリーデータ伝送に適用されてもよいし、下りリンクのアーリーデータ伝送に適用されてもよい。
図9に示すように、ステップS201において、RRCコネクティッドモードのUE100は、アーリーデータ伝送を行うことを示す通知をeNB200に送信する。例えば、UE100は、次回のRRC接続の確立の際にアーリーデータ伝送を行う旨をeNB200に通知する。UE100は、eNB200に通知した内容(通知情報)を記憶する。上りリンクのアーリーデータ伝送を行うことを示す通知と下りリンクのアーリーデータ伝送を行うことを示す通知とが別々に定義されてもよい。通知は、UE100の能力情報(アーリーデータ伝送に関する能力)を含んでもよい。eNB200は、UE100からの通知を記憶する。eNB200は、当該通知を上位装置(例えば、MME300)に転送してもよい。
ステップS202において、eNB200は、RRC接続解放(RRC Connection Release)メッセージをUE100に送信する。RRC接続解放メッセージは、UE100をRRCサスペンド状態に設定することを示す情報を含んでもよい。また、RRC接続解放メッセージは、UE100がアーリーデータ伝送を行ってよい(又は行わなければならない)ことを示す情報を含んでもよい。RRC接続解放メッセージは、UE100がアーリーデータ伝送を行ってはならないことを示す情報を含んでもよい。
ステップS203において、UE100は、RRC接続解放メッセージに応じて、RRC接続を解放し、RRCコネクティッドモードからRRCアイドルモードに遷移する。UE100は、RRCサスペンド状態になってもよい。UE100は、自身がアイドルモードである間において通知情報を保持する。
ステップS204において、eNB200は、UE100がアイドルモードである間において通知情報を保持する。言い換えると、eNB200は、UE100について次回のRRC接続の確立の際にアーリーデータ伝送を行う旨の情報を保持する。eNB200に加えて、又はeNB200に代えて、eNB200の上位装置(例えば、MME300)が通知情報を保持してもよい。eNB200及び/又はMME300が保持する情報は、UE100の能力情報(アーリーデータ伝送に関する能力)を含んでもよい。UE100及びeNB200は、UE100がアーリーデータ伝送を行わないと決めた時(Msg1で従来のPRACHリソースを使った時)に、通知情報をキャンセル(破棄)してもよい。
ステップS205において、UE100は、Msg1(ランダムアクセスプリアンブル)をeNB200に送信する。詳細については後述するが、UE100は、eNB200からUE個別に割り当てられた専用のプリアンブル系列(dedicated preamble)を適用してランダムアクセスプリアンブルを送信してもよい。eNB200は、UE100からのランダムアクセスプリアンブルを受信する。
eNB200は、アイドルモードのUE100宛てのページングメッセージを上位装置(例えば、MME300)から受信してもよい。ページングメッセージは、宛先UEの識別子と、上位装置が保持した通知情報との組み合わせを含んでもよい。eNB200は、ページングメッセージに含まれる情報を、UE100についてアーリーデータ伝送を行うか否かの判断に用いてもよい。
専用のプリアンブル系列が適用される場合、ステップS206において、eNB200は、プリアンブル系列に基づいてUE100を識別する。そして、eNB200は、ステップS204で保持した通知情報に基づいて、アーリーデータ伝送を行うか否かを判断する。具体的には、eNB200は、識別されたUE100に対応する通知情報が保持されていれば、アーリーデータ伝送を行うと判断する。一方で、識別されたUE100に対応する通知情報が保持されていなければ、eNB200は、アーリーデータ伝送を行わないと判断する。
ステップS207において、eNB200は、Msg2(ランダムアクセス応答)をUE100に送信する。
ステップS208において、UE100は、Msg3をeNB200に送信する。
専用のプリアンブル系列が適用されない場合、ステップS209において、eNB200は、Msg3に基づいてUE100を識別する。そして、eNB200は、ステップS204で保持した通知情報に基づいて、アーリーデータ伝送を行うか否かを判断する。
(3)動作パターン3
図10は、第1実施形態に係る動作パターン3を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。また、動作パターン1及び2と重複する説明を省略する。動作パターン3は、下りリンクのアーリーデータ伝送に適用される。
動作パターン3において、ランダムアクセスプロシージャを行うUE100は、RRCアイドルモード又はRRCコネクティッドモードである。RRCアイドルモードのUE100は、競合ベースのランダムアクセスプロシージャを行う。一方で、RRCコネクティッドモードのUE100は、非競合ベース(non−contention based)のランダムアクセスプロシージャを行うことが可能である。非競合ベースのランダムアクセスプロシージャでは、DCI(Downlink Control Information)又は個別RRCシグナリング(dedicated signaling)によって、eNB200からUE個別に専用のプリアンブル系列が割り当てられる。非競合ベースのランダムアクセスプロシージャは、ハンドオーバ時や上りリンクのタイミング調整時等に適用される。
図10に示すように、ステップS301において、eNB200は、ランダムアクセスプロシージャが開始されるよりも前において、アーリーデータ伝送を行うか否かを示す通知を、ページングメッセージ、DCI、及びPDSCHの少なくともいずれかによってUE100に送信する。
ページングメッセージを用いる場合、競合ベースのランダムアクセスプロシージャが適用されてもよい。eNB200は、宛先UEの識別子とアーリーデータ伝送を行うか否かを示す情報との組み合わせ含むページングメッセージを送信する。このようなページングメッセージは、MME300によって生成され、MME300からeNB200を介してUE100に送信されてもよい。
DCI又はPDSCHを用いる場合、UE100はRRCコネクティッドモードであってもよい。DCI又はPDSCHを用いる場合、非競合ベースのランダムアクセスプロシージャが適用されてもよい。eNB200は、UE100宛てのDCI又はPDSCHに、アーリーデータ伝送を行うか否かを示す情報を含める。eNB200は、間欠受信(DRX)動作を行うUE100がPDCCHを監視するタイミングであるPaging occasionにおいて、アーリーデータ伝送を行うか否かを示す情報を含むDCIをUE100に送信してもよい。
アーリーデータ伝送に利用される所定メッセージがMsg1(ランダムアクセスプリアンブル)である場合、eNB200は、アーリーデータ伝送を行うか否かをUE100に通知する際に、アーリーデータ伝送用のPRACHリソースをUE100に通知してもよい。当該通知は、ページングメッセージ、DCI、及びPDSCHの少なくともいずれかによって行われる。eNB200は、予めSIBによっていくつかのPRACHリソース(及びそのインデックスを含むリスト)をブロードキャストしてもよい。eNB200は、PRACHリソースのインデックスを、ページングメッセージ、DCI、及びPDSCHの少なくともいずれかによって通知してもよい。
ステップS302において、UE100は、ステップS301におけるeNB200からの通知に基づいて、アーリーデータ伝送を行うか否かを判断する。アーリーデータ伝送を行うことが通知されている場合、UE100は、アーリーデータ伝送を行うと判断してもよい。或いは、アーリーデータ伝送を行うことが通知されている場合であっても、UE100は、アーリーデータ伝送を行わないと判断してもよい。この場合、UE100は、ランダムアクセスプロシージャ中に、例えばMsg1(ランダムアクセスプリアンブル)又はMsg3(例えば、RRC接続要求メッセージ)によって、アーリーデータ伝送を行わない旨をeNB200に通知してもよい。
ランダムアクセスプロシージャが開始されると、ステップS303において、UE100は、Msg1(ランダムアクセスプリアンブル)をeNB200に送信する。アーリーデータ伝送を行う場合、eNB200は、ランダムアクセスプロシージャ中に、例えばMsg2(ランダムアクセス応答)又はMsg4(例えば、RRC接続確立メッセージ)によって、下りリンクデータをUE100に送信する。
或いは、eNB200は、下りリンクのアーリーデータ伝送を行う旨を、ランダムアクセスプロシージャ中にUE100に通知してもよい。例えば、eNB200は、Msg4によって下りリンクデータを送信することを示す情報を、Msg2によってUE100に送信してもよい。
(4)動作パターン4
図11は、第1実施形態に係る動作パターン4を示す図である。上述した「ランダムアクセスプロシージャの概要」における動作と異なる点を主として説明する。また、動作パターン1〜3と重複する説明を省略する。動作パターン4は、上りリンクのアーリーデータ伝送に適用される。
図11に示すように、ステップS401において、eNB200は、ランダムアクセスプロシージャを開始するよりも前に、アーリーデータ伝送によって送信することが許容されるデータの量(許容データ量)を示す情報をUE100に送信する。アーリーデータ伝送の許容データ量を示す情報は、許容データ量を示す閾値であってもよい。eNB200は、アーリーデータ伝送の許容データ量を示す情報をSIBによってブロードキャストしてもよい。eNB200は、アーリーデータ伝送の許容データ量を示す情報をユニキャストメッセージ(例えば、RRC Connection Releaseメッセージ)によってUE個別に送信してもよい。UE100は、アーリーデータ伝送の許容データ量を示す情報を受信する。UE100は、RRCアイドルモードであってもよい。
eNB200がUE100に通知する許容データ量は、1つのみであってもよいし、複数であってもよい。複数である場合、許容データ量とそのインデックスとの複数の組み合わせからなるリストが構成されてもよい。eNB200は、セルの負荷の状況などに基づいて、当該リストの中身(レコードの数)を変更してもよい。UE100は、当該リストに基づいて、eNB200に送信する上りリンクデータの量に対応するインデックスをMsg1でeNB200に通知することによって、アーリーデータ伝送によって送信するデータ量をeNB200に示してもよい。
ステップS402において、UE100は、eNB200から通知された許容データ量と、当該UE100がeNB200に送信するデータの量とに基づいて、アーリーデータ伝送を行うか否かを判断する。eNB200に送信するデータの量とは、UE100内の上りリンクバッファに蓄積された上りリンクデータの量であってもよい。
かかる判断を行う主体は、UE100のアクセスレイヤ(AS)であってもよいし、UE100の上位レイヤであってもよい。上述したように、アクセスレイヤ(AS)は、PHYレイヤ、MACレイヤ、RLCレイヤ、PDCPレイヤ、及びRRCレイヤからなるレイヤである。アクセスレイヤ(AS)は、eNB200との無線通信を行うためのレイヤである。上位レイヤは、NASレイヤ及びアプリケーションレイヤ等からなるレイヤであり、アクセスレイヤよりも上位に位置付けられる。eNB200に送信するデータ(すなわち、上りリンクデータ)は上位レイヤにおいて生成される。
判断主体がUE100のアクセスレイヤ(AS)である場合、UE100の上位レイヤは、上りリンクのアーリーデータ伝送によってeNB200に送信するデータの量をUE100のアクセスレイヤ(AS)に通知してもよい。eNB200に送信するデータの量は、データパケットのサイズであってもよいし、複数のデータパケットの総量であってもよい。データパケットは、PDCP SDU(すなわち、IPパケット)であってもよいし、NASヘッダを含むNAS PDUであってもよい。例えば、UE100のアクセスレイヤ(AS)は、eNB200からSIBによって通知された許容データ量と、上位レイヤから通知されたデータパケットのサイズとに基づいて、アーリーデータ伝送を行うか否かを判断する。
一方、判断主体がUE100の上位レイヤである場合、アクセスレイヤは、eNB200から通知された許容データ量を上位レイヤに通知する。上位レイヤは、アクセスレイヤから通知された許容データ量と、eNB200に送信するデータパケットのサイズとに基づいて、アーリーデータ伝送を行うか否かを判断する。
UE100は、eNB200に送信するデータの量が許容データ量以下である場合に、アーリーデータ伝送を行うと判断してもよい。この場合、UE100は、ランダムアクセスプロシージャ中にアーリーデータ伝送によって上りリンクデータの送信が完了すると、RRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了してもよい。このような動作は、第1実施形態の変更例4で説明する。
UE100は、eNB200に送信するデータの量が許容データ量を上回っている場合でも、アーリーデータ伝送を行うと判断してもよい。この場合、UE100は、ランダムアクセスプロシージャ中にアーリーデータ伝送によって上りリンクデータを送信し、RRCコネクティッドモードに遷移した後、残りの上りリンクデータをeNB200に送信してもよい。
ランダムアクセスプロシージャが開始されると、ステップS403において、UE100は、Msg1(ランダムアクセスプリアンブル)をeNB200に送信する。アーリーデータ伝送を行う場合、UE100は、ランダムアクセスプロシージャ中に、例えばMsg1(ランダムアクセスプリアンブル)又はMsg3(例えば、RRC接続要求メッセージ)によって、上りリンクデータをeNB200に送信する。
図11のシーケンスでは、eNB200に送信するデータ(すなわち、上りリンクデータ)の量が許容データ量を上回っている場合に、UE100が、アーリーデータ伝送によって上りリンクデータを送信し、RRCコネクティッドモードに遷移した後、残りの上りリンクデータをeNB200に送信する一例を説明した。しかしながら、上りリンクデータの量が許容データ量を少しだけ上回っている場合でもRRCコネクティッドモードに遷移しなければならないため、非効率であり、UE100の消費電力の点などで好ましくない。
よって、UE100は、eNB200に送信するデータの量が、eNB200からブロードキャスト情報(SIB)によって通知された許容データ量よりも多い場合に、複数回のMsg3送信を行ってもよい。複数回のMsg3送信のそれぞれは、データ送信を伴う。例えば、UE100は、1回目のMsg3送信において許容データ量まで上りリンクデータを送信し、2回目のMsg3送信において残りの上りリンクデータを送信する。これにより、アーリーデータ伝送によって上りリンクデータの送信を完了させることができるため、UE100がRRCコネクティッドモードに遷移する必要がなくなる。
図12は、図11のシーケンスの変更例を示す図である。ここでは、図11のシーケンスとの相違点について主として説明する。
図12に示すように、ステップS411において、eNB200は、アーリーデータ伝送によって送信することが許容されるデータの量(許容データ量)を示すブロードキャスト情報(SIB)をUE100に送信する。UE100は、eNB200から通知された許容データ量と、UE100がeNB200に送信するデータ(上りリンクデータ)の量とに基づいて、上りリンクのアーリーデータ伝送を行うか否かを判断する。ここでは、UE100は、上りリンクデータの量が許容データ量よりも多いものの、複数回のMsg3送信によって上りリンクデータの送信を完了させることができると判断し、上りリンクのアーリーデータ伝送を行うと判断する。
ランダムアクセスプロシージャが開始されると、ステップS412において、UE100は、Msg1(ランダムアクセスプリアンブル)をeNB200に送信する。UE100は、許容データ量よりも多いデータを送信する意図をランダムアクセスプリアンブルによってeNB200に通知してもよい。例えば、動作パターン1と同様でPRACHリソースを分割し、許容データ量よりも多いデータを送信する意図を表すためのリソースがPRACHリソース中に定義される。UE100は、許容データ量よりも多いデータを送信する意図を表すためのリソースを選択し、選択したリソースを用いてランダムアクセスプリアンブルを送信する。eNB200は、プリアンブル送信に用いられたリソースを認識し、許容データ量よりも多いデータを送信する意図をUE100が有することを把握する。
ステップS413において、eNB200は、Msg2(ランダムアクセス応答)をUE100に送信する。eNB200は、複数回のMsg3送信のための情報をMsg2によってUE100に送信してもよい。かかる情報は、セミパーシステントスケジューリング(SPS)の設定情報及び/又は活性化指示であってもよい。例えば、eNB200は、上りリンクの送信周期を示すSPS周期を含む設定情報をUE100に送信する。また、eNB200は、UE100に割り当てた上りリンクリソース(時間・周波数リソース)を示す上りリンクグラントをMsg2によって送信する。SPSの設定情報は、ステップS411においてeNB200からUE100に通知されてもよい。或いは、SPSの設定情報は仕様において定義され、UE100に予め設定されてもよい。
ステップS414において、UE100は、上りリンクグラントで示される時間・周波数リソースを用いて、データを伴うMsg3をeNB200に送信する。ここで、UE100は、eNB200から通知された許容データ量まで上りリンクデータをeNB200に送信してもよい。UE100は、上りリンクデータをRRCメッセージ(例えば、RRC Connection Request)に含める。或いは、UE100は、上りリンクデータをRRCメッセージに含めずに、MACレイヤにおいて上りリンクデータ(DTCH)とRRCメッセージ(CCCH)とを多重化して送信する。
ステップS415において、UE100は、ステップS414のタイミングからSPS周期分の時間が経過した際に、2回目のMsg3送信を行う。UE100は、上りリンクグラントで示される時間・周波数リソースを用いて、データを伴うMsg3をeNB200に送信する。ここで送信されるMsg3は、RRCメッセージを含まずに、上りリンクデータを含むものであってもよい。
UE100は、上りリンクデータの送信が完了するまで、SPS設定に従って、データを伴うMsg3をeNB200に複数回送信する。UE100は、最後のMsg3送信において、上りリンクデータの送信完了を示す情報(例えば、エンドマーカ)を送信してもよい。UE100は、上りリンクデータの送信完了を示すために「BSR=0」を用いてもよい。「BSR=0」の詳細については変更例8において説明する。eNB200は、UE100の最後のMsg3送信を認識する。
ステップS416において、eNB200は、Msg4をUE100に送信する。eNB200は、SPS送信を終了させるためにMsg4を用いてもよい。例えば、eNB200は、SPS送信の停止を示す1ビットのインジケータを、Msg4によってUE100に送信してもよい。UE100は、かかるMsg4の受信に応じてSPS送信を停止(かつ、SPS設定を破棄)する。そして、UE100は、RRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了してもよい。
eNB200は、RRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了させることをMsg4によって明示的にUE100に通知してもよい。この場合、Msg4送信は、RRC Connection Releaseメッセージ又はRRC Connection Rejectメッセージの送信を含んでもよい。
或いは、eNB200は、RRCコネクティッドモードに遷移させることをMsg4によって明示的にUE100に通知してもよい。この場合、Msg4送信は、RRC Connection Setupメッセージ又はRRC Connection Resumeメッセージの送信を含んでもよい。
図12のシーケンスでは、許容データ量よりも多いデータを送信する意図をランダムアクセスプリアンブルによってeNB200に通知し、eNB200がSPS送信をUE100に指示する一例を説明した。
しかしながら、eNB200は、かかるランダムアクセスプリアンブルの受信に応じて、許容データ量よりも多い量のデータを送信可能とする上りリンクグラントをMsg2によってUE100に送信してもよい。eNB200は、ランダムアクセスプリアンブル受信時おける上りリンクリソースに余裕がある場合に、かかる上りリンクグラントをUE100に送信してもよい。UE100は、許容データ量よりも多い量のデータを送信可能とする上りリンクグラントをeNB200から受信した場合、1回のMsg3送信で上りリンクデータの送信が完了し得る。
或いは、eNB200は、かかるランダムアクセスプリアンブルの受信時に上りリンクリソースの余裕が無い場合に、ランダムアクセスプリアンブルに対してランダムアクセス応答(Msg2)を送信しないか、又はMsg4においてRejectをUE100に通知してもよい。
(第1実施形態のまとめ)
第1実施形態に係る通信制御方法は、第1無線通信装置が、ランダムアクセスプロシージャ中に所定メッセージを利用してデータを送信するアーリーデータ伝送を行うか否かに関する情報を第2無線通信装置に送信するステップAと、第2無線通信装置が情報を受信した後、第2無線通信装置が、当該受信した情報に基づいてアーリーデータ伝送を行うか否かを判断するステップBとを備える。第1無線通信装置はUE100及びeNB200のうち一方であり、第2無線通信装置はUE100及びeNB200のうち他方である。ステップAは、所定メッセージの送信タイミングよりも前に行われる。このような通信制御方法によれば、第2無線通信装置は、第1無線通信装置から受信した情報に基づいて、所定メッセージの送信タイミング(すなわち、アーリーデータ伝送に利用可能なタイミング)よりも前にアーリーデータ伝送を行うか否かを予め判断することができる。例えば、アーリーデータ伝送を行うか否かに関する認識を第1無線通信装置及び第2無線通信装置(UE100及びeNB200)で合わせることが可能となる。よって、アーリーデータ伝送を実現可能とすることができる。
(変更例1)
図13は、第1実施形態の変更例1を示す図である。第1実施形態の変更例1において、UE100は、アーリーデータ伝送によって送信するデータ(上りリンクデータ)の量をランダムアクセスプリアンブルによってeNB200に通知する。上述した第1実施形態における動作と異なる点を主として説明する。
図13に示すように、ステップS501において、eNB200は、データ量とPRACHリソース(例えば、プリアンブル系列)との対応関係を示す情報、及びアーリーデータ伝送の最低保証リソース量を示す情報のうち少なくともいずれかをSIBによってブロードキャストする。SIBに代えて、ページングメッセージを用いてもよい。
ステップS502において、UE100は、アーリーデータ伝送によって送信するデータ(上りリンクデータ)の量に基づいて、ランダムアクセスプリアンブルの送信に適用するリソースを選択してもよい。例えば、UE100は、eNB200から通知された対応関係に基づいて、アーリーデータ伝送によって送信するデータ(上りリンクデータ)の量に対応するプリアンブル系列を選択する。
UE100は、eNB200から通知された最低保証リソース量に基づいて、アーリーデータ伝送によって送信するデータ(上りリンクデータ)の量をeNB200に通知するか否かを判断してもよい。例えば、UE100は、最低保証リソース量が十分である場合には、アーリーデータ伝送によって送信するデータの量をeNB200に通知しないと判断してもよい。UE100は、最低保証リソース量が十分でない場合には、アーリーデータ伝送によって送信するデータの量をeNB200に通知すると判断してもよい。
ステップS503において、UE100は、Msg1(ランダムアクセスプリアンブル)をeNB200に送信する。UE100は、アーリーデータ伝送によって送信するデータの量に対応するPRACHリソース(例えば、プリアンブル系列)を適用してランダムアクセスプリアンブルを送信してもよい。或いは、UE100は、アーリーデータ伝送によって送信するデータの量を示す情報をランダムアクセスプリアンブルに付加して、ランダムアクセスプリアンブルを送信してもよい。
ステップS504において、eNB200は、ランダムアクセスプリアンブルによって通知されたデータ量に基づいて、UE100に割り当てる上りリンク無線リソース(例えば、PUSCHリソース)の量を判断する。当該上りリンク無線リソースは、Msg3の送信に用いられる無線リソースであってもよい。eNB200がUE100に割り当てる上りリンク無線リソースの情報は、Msg2によってUE100に通知される。
なお、eNB200からUE100に最低保証リソース量を通知する一例を説明した。しかしながら、このような通知に代えて、上りリンクデータの量をランダムアクセスプリアンブルによってUE100が通知すべきか否かをeNB200がUE100に設定してもよい。当該設定は、SIBによって行われてもよい。
或いは、上りリンクのアーリーデータ伝送を行う意図の通知に、上りリンクデータ量の暗示的な通知の意味を持たせてもよい。eNB200は、上りリンクのアーリーデータ伝送を行う意図の通知を、UL grantサイズをeNBに一任すること、又はデータ量は報知されているUL grantサイズ(最大許容UL grantサイズであってもよい)と等しいこと、又はアーリーデータ伝送に係るデータ量は当該報知されているUL grantサイズが必要であること、とみなしてもよい。
第1実施形態の動作パターン1において、UE100のアーリーデータ伝送を行う意図を、PRACHリソースを用いてeNB200に通知する一例を説明した。かかる通知は、CEレベルごとに行われる必要があり得る。また、本変更例は、上りリンクデータの量を、PRACHリソースを用いてeNB200に通知するものである。これらの動作を併用する場合、PRACHリソースの分割数を増やす必要がある。また、PRACH用に確保される1つのリソースプールは有限であるため、PRACHリソースの分割数を増やすと、分割された各リソースグループのサイズが小さくなる。その結果、各リソースグループ内でUE100がリソースをランダムに選択しても、複数のUEが同じリソースを選択する確率、すなわち、リソースの衝突が発生する確率が高くなる。
よって、UE100は、ランダムアクセス応答の受信タイミングよりも前に、複数回のランダムアクセスプリアンブル送信を行ってもよい。複数回のランダムアクセスプリアンブル送信のそれぞれにおいて、UE100は、eNB200に通知すべき情報に基づいて、ランダムアクセスプリアンブルの送信に適用するリソースを選択する。これにより、時間方向に複数のPRACHリソースプールを確保し、利用可能なPRACHリソースの量を増やすことができる。
図14は、PRACHリソース構成の一例を示す図である。図14に示す例において、UE100は、所定時間内で2回のプリアンブル送信を行う。所定時間は、1サブフレームの時間であってもよいし、1無線フレームの時間であってもよい。2回のプリアンブル送信に対応する2つのPRACHリソースプール#1及び#2が設けられている。PRACHリソースプール#1及びPRACHリソースプール#2は同一周波数上に設けられてもよい。各PRACHリソースプールは、周波数方向に分割され、複数のリソースグループに区分される。各PRACHリソースプールは、時間方向に分割されてもよい。
UE100は、1回目のプリアンブル送信において、PRACHリソースプール#1の中からリソースを選択する。PRACHリソースプール#1は3つのリソースグループに分割されており、3つのリソースグループはCEレベル#1〜#3に対応する。例えば、上りリンクのアーリーデータ伝送を行う意図を有するUE100は、自身のCEレベルに対応するリソースグループを特定し、特定したリソースグループの中からリソースをランダムに選択し、選択したリソースを用いてランダムアクセスプリアンブルを送信する。eNB200は、UE100から受信したランダムアクセスプリアンブルに対応するリソースグループを特定し、UE100のCEレベルを把握する。
UE100は、2回目のプリアンブル送信において、PRACHリソースプール#2の中からリソースを選択する。PRACHリソースプール#2は4つのリソースグループに分割されており、4つのリソースグループは上りリンクのデータ量#1〜#4に対応する。データ量#1〜#4のそれぞれはデータ量の範囲を示すインデックスである。例えば、上りリンクのアーリーデータ伝送を行う意図を有するUE100は、自身の上りリンクデータ量に対応するリソースグループを特定し、特定したリソースグループの中からリソースをランダムに選択し、選択したリソースを用いてランダムアクセスプリアンブルを送信する。eNB200は、UE100から受信したランダムアクセスプリアンブルに対応するリソースグループを特定し、UE100の上りリンクデータ量を把握する。
UE100は、1回目のプリアンブル送信と2回目のプリアンブル送信とで同一のプリアンブル系列(信号系列)を適用してもよい。この場合、eNB200は、1回目のプリアンブル送信を行ったUEと2回目のプリアンブル送信を行ったUEとをプリアンブル系列に基づいて対応付ける。或いは、1回目のプリアンブル送信と2回目のプリアンブル送信とで、所定のパターン(例えば、周波数ホッピングパターン)に従って、リソースグループの中からリソースを選択してもよい。この場合、eNB200は、1回目のプリアンブル送信を行ったUEと2回目のプリアンブル送信を行ったUEとをリソース選択パターンに基づいて対応付ける。
eNB200は、UE100から2回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルを受信すると、1回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答をUE100に送信してもよい。すなわち、eNB200は、2回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答を送信しない。これにより、後方互換性を担保することができる。或いは、eNB200は、UE100から2回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルを受信すると、2回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答をUE100に送信してもよい。すなわち、eNB200は、1回目のプリアンブル送信によって送信されたランダムアクセスプリアンブルに対応するランダムアクセス応答を送信しない。
eNB200は、各PRACHリソースプールに関する情報をSIBによってUE100に通知してもよい。各PRACHリソースプールに関する情報は、各PRACHリソースプール及び各リソースグループに対応付けられた情報の種別、PRACHリソースプールを構成するリソースの時間・周波数の範囲を示す情報、PRACHリソースプール内の各リソースグループの時間・周波数の範囲を示す情報のうち少なくとも1つを含む。eNB200は、かかる情報を、PRACHリソースプールごとに個別の情報要素(例えば、RACH−config)としてUE100に通知してもよい。各情報要素は、対応する情報の種別(CEレベル又は上りリンクデータ量)を含んでもよいし、対応する情報の種別を情報要素の名前で表してもよい。
なお、図14の例では、CEレベル及び上りリンクデータ量をプリアンブル送信によってeNB200に通知する一例を説明したが、CEレベル及び上りリンクデータ量以外の情報(例えば、UEカテゴリ、後述する変更例14のタイマ値)をプリアンブル送信によってeNB200に通知してもよい。また、連続的に行われるプリアンブル送信の回数は、2回に限らず、3回以上であってもよい。例えば、UE100は、1回目のランダムアクセスプリアンブル送信によってCEレベルをeNB200に通知し、2回目のランダムアクセスプリアンブル送信によってアーリーデータ伝送を行う意図をeNB200に通知し、3回目のランダムアクセスプリアンブル送信によって上りリンクデータ量(すなわち、UE100が希望するアップリンクグラントの量)をeNB200に通知してもよい。或いは、1回目のランダムアクセスプリアンブル送信のためのPRACHリソースプール#1と2回目のランダムアクセスプリアンブル送信のためのPRACHリソースプール#2とを分け、かつ、PRACHリソースプール#2を2つのリソースグループに分ける。そして、アーリーデータ伝送を行う意図の通知用としてPRACHリソースプール#2の一方のリソースグループを確保し、上りリンクデータ量の通知用としてPRACHリソースプール#2の他方のリソースグループを確保してもよい。かかる場合、eNB200は、上りリンクデータ量の通知用のリソースグループ内のリソースを用いて上りリンクデータ量をeNB200に通知したUE100を、アーリーデータ伝送を行う意図を有するUEであるとみなしてもよい。また、アーリーデータ伝送を行う意図の通知は、UL grantサイズをeNBに一任すること、又はデータ量は報知されているUL grantサイズ(最大許容UL grantサイズであってもよい)と等しいこと、又はアーリーデータ伝送に係るデータ量は当該報知されているUL grantサイズが必要であること、とみなしてもよい。
図14の例では、時間方向に複数のPRACHリソースプールを設ける一例を説明したが、周波数方向に複数のPRACHリソースプールを設けてもよい。
また、1回目のプリアンブル送信と2回目のプリアンブル送信とで同一のプリアンブル系列(信号系列)を適用することにより、1回目のプリアンブル送信と2回目のプリアンブル送信との紐付けを行う一例を説明した。しかしながら、プリアンブル系列により紐付けを行う場合に限らず、時間・周波数リソースにより紐付けを行なってもよい。例えば、図14に示すように、1回目のランダムアクセスプリアンブル送信のためのPRACHリソースプール#1と2回目のランダムアクセスプリアンブル送信のためのPRACHリソースプール#2とのそれぞれに複数のリソースグループが含まれており、各リソースグループが長方形状に定義されると仮定する。かかる場合、長方形の4つの頂点のうち特定の1つの点を基準点と定める。UE100は、1回目のランダムアクセスプリアンブル送信用のリソースグループにおいて、基準点を基準として所定の時間・周波数位置のリソースを選択する。そして、UE100は、2回目のランダムアクセスプリアンブル送信用のリソースグループにおいて、基準点を基準として、1回目と同じ時間・周波数位置のリソースを選択する。このように、1回目及び2回目のランダムアクセスプリアンブル送信のそれぞれにおいて、時間・周波数リソースの相対位置を揃えることにより、eNB200は、1回目のプリアンブル送信と2回目のプリアンブル送信との紐付けを行うことが可能である。
さらに、図14の例では、PRACHリソースプールが時間・周波数リソースにより構成される一例を説明したが、PRACHリソースプールがプリアンブル系列(信号系列)リソースにより構成されてもよい。
次に、複数回のランダムアクセスプリアンブル送信のうちの少なくとも1回においてeNB200がプリアンブル受信に失敗する場合について説明する。ここでは、UE100が、1回目のランダムアクセスプリアンブル送信によってCEレベルをeNB200に通知し、2回目のランダムアクセスプリアンブル送信によってアーリーデータ伝送を行う意図(特に、上りリンクのアーリーデータ伝送を行う意図)をeNB200に通知すると仮定する。表1に示すように、1回目のランダムアクセスプリアンブル送信(First PRACH)及び2回目のランダムアクセスプリアンブル送信(Second PRACH)の少なくとも一方が送信失敗するケースとして、ケース1〜3がある。
ケース1は、1回目のランダムアクセスプリアンブル送信及び2回目のランダムアクセスプリアンブル送信の両方が成功するケースである。ケース1において、eNB200は、UE100のアーリーデータ伝送の意図を把握し、通常の上りリンクグラント(すなわち、アーリーデータ伝送により送信されるデータの量を加味していない上りリンクグラント)よりも多い量の上りリンクリソースをUE100に割り当ててMsg2で通知する。UE100は、アーリーデータ伝送によってデータをMsg3で送信する。
ケース2は、1回目のランダムアクセスプリアンブル送信が成功し、2回目のランダムアクセスプリアンブル送信が失敗するケースである。ケース2において、eNB200は、通常のランダムアクセスプリアンブルを受信したと認識し、通常の上りリンクグラントをMsg2でUE100に通知する。UE100は、データ送信に用いることが可能な上りリンクリソースが割り当てられなかったと判断し、データを含まないMsg3をeNB200に送信する。
ケース3は、1回目のランダムアクセスプリアンブル送信が失敗し、2回目のランダムアクセスプリアンブル送信が成功するケースである。ケース3において、eNB200は、1回目のランダムアクセスプリアンブルを受信していないことから、2回目のランダムアクセスプリアンブルを受信しても、対応するMsg2を送信しない。UE100は、Msg2をeNB200から受信しないため、ランダムアクセスプロシージャを最初からやり直す。
ケース3において、eNB200は、2回目のランダムアクセスプリアンブルに基づいて、このランダムアクセスプリアンブルを送信したUE100を特定し、特定したUE100に対してMsg2を送信してもよい。例えば、eNB200は、2回目のランダムアクセスプリアンブルに適用されているプリアンブル系列及び/又はホッピングパターンに基づいてUE100を特定可能である。但し、eNB200は、1回目のランダムアクセスプリアンブルを受信していないため、このUE100のCEレベルを1回目のランダムアクセスプリアンブルに基づいて把握することができない。かかる場合、eNB200は、UE100が通常のカバレッジにいる(すなわち、拡張されたカバレッジにいない)とみなして、Msg2送信の際に繰り返し送信を行わない。或いは、eNB200は、2回目のランダムアクセスプリアンブルに基づいてCEレベルを推定してもよい。具体的には、2回目のプリアンブル送信の際に繰り返し送信が適用される場合、eNB200は、受信に成功したプリアンブル送信の繰り返し回数をカウントし、カウント値からCEレベルを推定することが可能である。eNB200は、推定したCEレベルに基づいて、Msg2送信の際に繰り返し送信を行う。
なお、ランダムアクセスプリアンブルの複数回送信を行うか否かにかかわらず、上りリンクのアーリーデータ伝送を行う意図をプリアンブル送信によってeNB200に通知したUE100は、データ送信に用いることが可能な上りリンクリソースが割り当てられなかった場合に、通常のMsg3(データを含まないMsg3)をeNB200に送信しなければならないという制約があってもよい。
或いは、上りリンクのアーリーデータ伝送を行う意図をプリアンブル送信によってeNB200に通知したUE100は、データ送信に用いることが可能な上りリンクリソースが割り当てられなかった場合に、ランダムアクセスプロシージャをやり直してもよい。ランダムアクセスプロシージャをやり直す場合、UE100は、プリアンブル送信を改めて行い、上りリンクのアーリーデータ伝送を行う意図をプリアンブル送信によってeNB200に改めて通知する。UE100は、かかるランダムアクセスプロシージャのやり直しを、eNB200から許可されている場合に限り実施してもよい。すなわち、UE100は、eNB200から許可されていない場合には、ランダムアクセスプロシージャのやり直しを行うことが禁止される。かかる許可を示す情報は、eNB200からSIBによってブロードキャストされてもよいし、MMEからUE100に設定されてもよい。
(変更例2)
図15は、第1実施形態の変更例2を示す図である。上述した第1実施形態における動作と異なる点を主として説明する。
図15に示すように、ステップS601において、UE100は、アーリーデータ伝送によってMsg1(ランダムアクセスプリアンブル)と共にデータをeNB200に送信する。例えば、UE100は、ランダムアクセスプリアンブルに続く新たなデータチャネルを用いてデータを送信する。但し、ランダムアクセスプリアンブルと共に送信されるデータは少量であってもよい。UE100は、ステップS601で送信したデータを保持する。
ステップS602において、eNB200は、ランダムアクセスプリアンブルと共に送信されたデータを受信すると、当該受信したデータの少なくとも一部をMsg2(ランダムアクセス応答)によってUE100に返送する。eNB200は、当該受信したデータの全部をUE100に返送してもよい。
ステップS603において、UE100は、ステップS601で送信したデータと、eNB200から返送されたデータとを比較する。UE100は、比較の結果、一致すれば送信成功(ACK)、不一致であれば送信失敗(NACK)と判断する。送信失敗(NACK)と判断した場合、UE100は、次回のアップリンク送信時(PUSCH送信時)に、送信に失敗したデータの再送を行う。また、UE100は、判断結果(ACK又はNACK)をMsg3によってeNB200に通知してもよい。UE100は、判断結果がNACKである場合に限り、eNB200へのNACK通知を行ってもよい。
(変更例3)
第1実施形態の変更例3に係るUE100は、RRCアイドルモードにおいて、アーリーデータ伝送によってデータをeNB200に送信する。その後、RRCアイドルモードのUE100は、PHICH(Physical channel HybridARQ Indicator Channel)を監視することによって、アーリーデータ伝送によって送信したデータに対応するACK又はNACKをeNB200から受信する。
一般的に、UE100は、RRCコネクティッドモードにおいてのみPHICHを監視する。しかしながら、上りリンクのアーリーデータ伝送に対するACK/NACKをeNB200がPHICHで通知することが想定される。よって、RRCアイドルモードのUE100であってもPHICHを監視することによって、アーリーデータ伝送が成功したか否かを把握することが可能となる。
(変更例4)
第1実施形態の変更例4において、UE100又はeNB200は、アーリーデータ伝送によってデータ送信が完了したか否かを判断する。アーリーデータ伝送によってデータ送信が完了したと判断された場合、UE100は、RRCアイドルモードからRRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する。これによって、効率的なデータ伝送が可能となる。
例えば、上りリンクのアーリーデータ伝送の場合、UE100は、Msg4(例えば、RRC Connection Setupメッセージ)をeNB200から受信すると、失敗又は拒否を示すメッセージ(failureメッセージ)をeNB200に送信することによって、ランダムアクセスプロシージャを終了させることができる。失敗又は拒否を示すメッセージには、失敗又は拒否の理由を示す情報(例えば、early data transmission completed)を含めてもよい。
下りリンクのアーリーデータ伝送の場合、eNB200は、Msg4(例えば、RRC Connection Setupメッセージ)によって、ランダムアクセスプロシージャを終了させる(すなわち、completeする必要が無い)旨をUE100に通知し、ランダムアクセスプロシージャを終了させることができる。或いは、eNB200は、Msg4として、RRC Connection Releaseメッセージを送信してもよい。
下りリンクのアーリーデータ伝送の場合、eNB200は、ランダムアクセスプロシージャの前に、特殊なページングメッセージをUE100に送信することによって、小パケット(少量データ)の下りリンク送信である旨を通知してもよい。当該特殊なページングメッセージは、MME300によって生成され、eNB200を介してMME300からUE100に送信されてもよい。当該特殊なページングメッセージは、UE100の識別子と小パケット送信を示す情報との組み合わせを含んでもよい。UE100は、当該特殊なページングメッセージを受信した場合、アーリーデータ伝送によってデータ送信が完了した後にRRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する。
(変更例5)
第1実施形態の変更例5において、eNB200は、ランダムアクセスプリアンブルに適用すべきプリアンブル系列を示すプリアンブルインデックスをページングメッセージによってUE100に送信する。例えば、当該ページングメッセージは、UE100の識別子とプリアンブルインデックスとの組み合わせを含んでもよい。
この動作に先立ち、MME300は、eNB200にS1インターフェイスによって送信するS1ページングメッセージ内で、UEの識別子(UE ID)と共に、”非競合ベースのランダムアクセスプロシージャ適用”の通知を行ってもよい。MME300は、S1ページングメッセージ内で、UE IDと共に、”アーリーデータ伝送適用”の通知を行ってもよい。また、予めeNB200がMME300に対して(複数の)プリアンブルインデックスを通知しておき、MME300は、このインデックスの中から、(必要に応じて)選んだものを、S1メッセージでeNB200に通知してもよい。
UE100(例えば、RRCアイドルモードのUE)は、eNB200からページングメッセージを受信し、プリアンブルインデックスが示すプリアンブル系列を適用したランダムアクセスプリアンブルをeNB200に送信する。eNB200は、ランダムアクセスプリアンブルに適用されたプリアンブル系列に基づいて、ランダムアクセスプリアンブルの送信元のUE100を識別することができる。
これによって、本来は競合ベースのランダムアクセスプロシージャが行われる状況下(例えば、初期接続時)において、非競合ベースのランダムアクセスプロシージャを行うことができる。従って、競合ベースのランダムアクセスプロシージャに用いられる競合解決処理(contention resolution)を不要とすることができる。
(変更例6)
第1実施形態の変更例6において、UE100又はeNB200は、アーリーデータ伝送によってデータを送信する。アーリーデータ伝送によって送信されるデータには、当該データに対応するACK又はNACKの送信が適用されず、かつ、当該データを所定回数だけ繰り返して送信する繰り返し送信が適用される。これによって、ACK又はNACKを用いない場合でも、データ伝送の信頼性を向上させることができる。
UE100又はeNB200は、UE100が強化カバレッジに居ない場合(すなわち、通常のカバレッジに居る場合)であっても、アーリーデータ伝送によって送信されるデータには繰り返し送信を適用する。一般的に、UE100が通常のカバレッジに居る場合には、繰り返し送信は適用されない。一方で、第1実施形態の変更例6においては、UE100が強化カバレッジに居るか否かにかかわらず、アーリーデータ伝送によって送信されるデータにはACK又はNACKの送信が適用されず、かつ、当該データを所定回数だけ繰り返して送信する繰り返し送信が適用される。
例えば、上りリンクのアーリーデータ伝送の場合、eNB200は、アーリーデータ伝送によって上りリンクデータを受信してもACK/NACKをUE100に送信しない。但し、UE100は、予め仕様で定められた回数又はeNB200から設定された回数だけ下位レイヤにおいて同一信号の繰り返し送信を行う。
下りリンクのアーリーデータ伝送の場合、UE100は、アーリーデータ伝送によって下りリンクデータを受信してもACK/NACKをeNB200に送信しない。但し、eNB200は、予め仕様で定められた回数又はUE100に通知した回数だけ下位レイヤにおいて同一信号の繰り返し送信を行う。
(変更例7)
第1実施形態の変更例7〜10においては、アーリーデータ伝送においてデータ送信に利用する所定メッセージがMsg3であるシナリオを想定する。すなわち、第1実施形態の変更例7〜10におけるアーリーデータ伝送は、上りリンクにおけるアーリーデータ伝送である。なお、Msg3は、上述したように、UE100からeNB200に対して送信されるメッセージであって、UE100がアイドルモードからコネクティッドモードに遷移することを要求するために用いるメッセージである。アーリーデータ伝送において、Msg3によって送信するデータ(パケット)は、Msg3に内包されていてもよい。例えば、UE100は、データPDUを含むRRC接続要求メッセージを送信する。或いは、Msg3によって送信するデータ(パケット)は、Msg3とは異なるメッセージとして、Msg3と組み合わせて(連続的に)送信されてもよい。例えば、UE100は、データ(パケット)を含むメッセージとMsg3とを含む1つのMAC PDUを送信してもよい。UE100は、データ(パケット)を含むメッセージとMsg3とを別々のMAC PDUに含めて、当該別々のMAC PDUを同時又は連続的に送信してもよい。
以下の変更例7〜11の説明において、Msg3がRRC接続要求メッセージである一例を説明するが、Msg3はRRC接続復旧要求メッセージであってよい。
変更例7において、上述したステップA(すなわち、アーリーデータ伝送を行うか否かに関する情報を送信するステップ)は、eNB200からUE100に対して送信されるランダムアクセス応答(Msg2)を構成するMAC RAR(MAC Random Access Response)によって、上りリンクにおけるアーリーデータ伝送の実行を指示するステップを含む。
一般的なランダムアクセス応答はMAC RARとして構成されており、ランダムアクセスプリアンブルに基づいてeNB200が決定したタイミングアドバンス(Timing Advance Command)と、RRC接続要求メッセージの送信用にeNB200がUE100に割り当てた上りリンクリソースに関する割当情報(UL grant)と、eNB200がUE100に割り当てた一時的なC−RNTI(Temporary C−RNTI)とを有する。
変更例7において、UE100からランダムアクセスプリアンブルを受信したeNB200は、上述した第1実施形態又はその変更例に係る方法によって、上りリンクにおけるアーリーデータ伝送(すなわち、RRC接続要求メッセージを用いたデータ伝送)をUE100に実行させるか否かを判断する。アーリーデータ伝送をUE100に実行させると判断した場合、eNB200は、ランダムアクセス応答を構成するMAC RARによって、上りリンクにおけるアーリーデータ伝送の実行を指示する。例えば、MAC RARに新たなフィールドを設ける場合、eNB200は、当該新たなフィールドに、RRC接続要求メッセージを用いたデータ伝送を実行させることを示すフラグ(許可ビット)を含める。RRC接続要求メッセージを用いたデータ伝送を実行させない場合、eNB200は、当該新たなフィールドに、RRC接続要求メッセージを用いたデータ伝送を実行させることを示すフラグを含めない(もしくは、当該フラグをゼロの値として含める)。
もしくは、eNB200は、アーリーデータ伝送をUE100に実行させるか否かを、ランダムアクセス応答を構成するMAC RARとは異なるMAC CEによってUE100に通知してもよい。当該異なるMAC CEは、例えば「Early Data Transmission RAR」と称されてもよい。この場合、eNB200は、上りリンク及び/又は下りリンクにおけるアーリーデータ伝送を示す識別子をEarly Data Transmission RARに含めてもよい。
なお、変更例1において説明したように、UE100は、アーリーデータ伝送によって送信するデータ(上りリンクデータ)の量をランダムアクセスプリアンブルによってeNB200に通知し得る。eNB200は、UE100から通知された上りリンクデータの量に基づいて、UE100に割り当てる上りリンク無線リソースの量を決定し、決定した上りリンク無線リソースを示す情報をランダムアクセス応答(MAC RAR)中のUL grantに含める。
(変更例8)
上述した変更例4において、アーリーデータ伝送によってデータ送信が完了したと判断された場合、UE100が、RRCアイドルモードからRRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する動作を説明した。変更例8は、下りリンクにおけるアーリーデータ伝送の場合の動作例に関する。
変更例8において、UE100は、RRC接続要求メッセージによってデータ送信が完了する場合に、コネクティッドモードに遷移する必要がない(すなわち、RRC接続を確立する必要がない)ことを示すフラグを含むRRC接続要求メッセージをUE100からeNB200に送信する。当該フラグは、1ビットで構成される。
例えば、UE100は、eNB200に送信すべきデータの量が、RRC接続要求メッセージによって運搬可能な最大データ量以下である場合に、RRC接続要求メッセージによってデータ送信が完了すると判断する。この場合、UE100は、RRC接続要求メッセージによってデータを送信する際に、コネクティッドモードに遷移する必要がないことを示すフラグをRRC接続要求メッセージに含める。その結果、RRC接続要求メッセージには、アーリーデータ伝送によって送信されるデータと、コネクティッドモードに遷移する必要がないことを示すフラグとが含まれる。一方で、eNB200に送信すべきデータの量が、RRC接続要求メッセージによって運搬可能な最大データ量を超える場合、UE100は、RRC接続要求メッセージによってデータ送信が完了しないと判断する。この場合、UE100は、RRC接続要求メッセージによってデータを送信する際に、コネクティッドモードに遷移する必要がないことを示すフラグをRRC接続要求メッセージに含めない(もしくは、当該フラグをゼロの値として含める)。
eNB200は、データ及びフラグを含むRRC接続要求メッセージをUE100から受信する。ここで、eNB200において、無線状態又はRRC接続要求メッセージの衝突等に起因して、RRC接続要求メッセージに含まれるデータの受信エラー(データの復号失敗)が発生することがある。
eNB200がRRC接続要求メッセージに含まれるデータを正常に受信した場合、eNB200は、RRC接続要求メッセージに含まれるフラグがRRC接続を確立する必要がないことを示していることから、UE100に対するMsg4の送信を行わないか、又はUE100に対してRRC接続解放メッセージを送信する。一方で、eNB200においてRRC接続要求メッセージに含まれるデータの受信エラーが発生した場合、eNB200は、例えばUE100に対してMsg4を送信することによって、RRC接続を確立するためにランダムアクセスプロシージャを継続する。UE100は、RRC接続要求メッセージに対するeNB200からの応答の状況に基づいて、RRC接続要求メッセージによるデータの送信が成功したか否かを判断する。
ここで、eNB200においてRRC接続要求メッセージに含まれるデータの受信エラーが発生した場合におけるUE100の動作について説明する。UE100は、RRC接続要求メッセージによるデータの送信が失敗したと判断した場合、次の0)〜4)のいずれかの動作を実行する。
0)ランダムアクセスプロシージャをランダムアクセスプリアンブル(Msg1)送信から再開する。具体的には、プリアンブル系列の選択(preamble selection)から再開してもよい。そして、Msg3において当該データを再送してもよい。
1)当該データを伴うRRC接続要求メッセージを再送する。この場合、UE100は、コネクティッドモードに遷移する必要がないことを示すフラグをRRC接続要求メッセージに含める。
2)当該データを伴わないRRC接続要求メッセージを再送する。この場合、UE100は、コネクティッドモードに遷移する必要がないことを示すフラグをRRC接続要求メッセージに含めない。UE100は、コネクティッドモードに遷移した後に当該データを送信(再送)する。
3)UE100からeNB200に対して送信されるメッセージであって、コネクティッドモードへの遷移完了を通知するために用いるMsg5によって当該データを送信する。この場合、UE100は、コネクティッドモードに遷移してもよい。或いは、UE100は、Msg5の送信に代えてデータをeNB200に送信してもよい。eNB200は、Msg6によって、UE100からのデータの受信に成功したか否かをUE100に通知してもよい。
4)コネクティッドモードに遷移する。
変更例8において、UE100は、コネクティッドモードに遷移する必要がない(すなわち、RRC接続を確立する必要がない)ことを示すフラグを含むRRC接続要求メッセージに代えて、コネクティッドモードに遷移する必要がないことを示す情報を伴うRRC接続要求メッセージを送信してもよい。UE100は、コネクティッドモードに遷移する必要がないことを示す情報を含むMAC CEを送信してもよい。例えば、MAC CEは、バッファ状態報告(BSR)である。BSRは、UE100が上りリンク送信に利用可能なデータの量(すなわち、上りリンクの送信待ちデータの量)を示すMAC CEである。
図16は、MACレイヤによって生成されるMAC PDU(MAC Protocol Data Unit)の一例を示す図である。図16に示すように、MAC PDUは、MACレイヤよりも上位のレイヤからMACレイヤに提供されるMAC SDU(MAC Service Data Unit)を含む。RRC接続要求メッセージ及びRRC接続復旧要求メッセージ等のRRCメッセージは、RRCレイヤによって生成され、MAC SDUとしてMACレイヤに提供される。アーリーデータ伝送によって送信される上りリンクデータは、PDCPレイヤ及びRLCレイヤを通じて、MAC SDUとしてMACレイヤに提供される。上りリンクデータは、PDCPレイヤ及びRLCレイヤを介さずに、MAC SDUとしてMACレイヤに提供されてもよい。
MAC PDUは、MAC SDUに加えて、MACレイヤによって生成されるMACヘッダ及びMAC CE(MAC Control Element)を含む。MAC PDUは、MAC PDUの空き領域を埋めるためのパディング(Padding)をさらに含むことがある。図16において、MAC PDUが2つのMAC CEを含む一例を例示しているが、MAC CEは3つ以上又は1つであってもよい。BSRを構成するMAC CEは、上りリンク送信に利用可能なデータの量を示す値(インデックス)を格納するバッファサイズフィールドを含む。UE100は、コネクティッドモードに遷移する必要がないことを示す情報として、上りリンク送信に利用可能なデータの量がゼロであることを示す値をバッファサイズフィールドに含める。かかるBSRは、RAI(Release Assistance Information)と称されてもよい。
アーリーデータ伝送において、RRC接続要求メッセージ(Msg3)によってデータ送信が完了する場合、UE100は、上りリンクデータ及びRRC接続要求メッセージを含む1又は複数のMAC SDUと、コネクティッドモードに遷移する必要がないことを示す情報(BSR=0)を含むMAC CEとを、1つのMAC PDUによって纏めてeNB200に送信してもよい。或いは、UE100は、上りリンクデータ及びRRC接続要求メッセージを含む1又は複数のMAC SDUと、コネクティッドモードに遷移する必要がないことを示す情報(BSR=0)を含むMAC CEとを、別々のMAC PDUによって連続的にeNB200に送信してもよい。eNB200は、RRC接続要求メッセージに伴う「BSR=0」に基づいて、UE100をコネクティッドモードに遷移させる必要がないと判断する。
(変更例9)
第1実施形態の変更例9〜12は、アーリーデータ伝送においてデータ送信に利用する所定メッセージがMsg4であるシナリオを想定する。すなわち、第1実施形態の変更例9〜11におけるアーリーデータ伝送は、下りリンクにおけるアーリーデータ伝送である。なお、Msg4は、上述したように、eNB200からUE100に対して送信されるメッセージであって、UE100をアイドルモードからコネクティッドモードに遷移させるために用いるメッセージである。
以下の変更例9〜12の説明において、Msg4がRRC接続確立メッセージである一例を説明するが、Msg4はRRC接続復旧メッセージであってよい。
変更例9において、アイドルモードのUE100は、ランダムアクセスプロシージャを開始する。UE100がアイドルモードである間は、UE100のコンテキスト情報(UE100の能力に関する情報を含む)をeNB200が保持していない場合がある。この場合、eNB200は、下りリンクにおけるアーリーデータ伝送を取り扱う能力をUE100が有するか否かを把握しておらず、下りリンクにおけるアーリーデータ伝送を行うか否かの判断が難しい。
そこで、変更例9において、UE100は、下りリンクにおけるアーリーデータ伝送に対応(サポート)しているか否かを、ランダムアクセスプリアンブル(Msg1)及びRRC接続要求メッセージのいずれかによってeNB200に通知する。例えば、下りリンクにおけるアーリーデータ伝送を行う能力を有するUE100は、下りリンクにおけるアーリーデータ伝送を行う能力を有することを示す情報(識別子)を、ランダムアクセスプリアンブル(Msg1)及びRRC接続要求メッセージのいずれかによってeNB200に送信する。ランダムアクセスプリアンブル(Msg1)を用いるケースでは、上述した第1実施形態の動作パターン1の方法を利用することができる。eNB200は、UE100からの通知に基づいて、下りリンクにおけるアーリーデータ伝送にUE100が対応しているか否かを判断する。ここで、「UE100が下りリンクにおけるアーリーデータ伝送に対応(サポート)している」、「UE100が下りリンクにおけるアーリーデータ伝送を行う能力を有する」とは、下りリンクにおけるアーリーデータ伝送によってeNB200から送信されるデータをUE100が「受信」する能力(機能)を有していることを意味してもよい。
なお、UE100は、下りリンクにおけるアーリーデータ伝送を行う旨のページングメッセージ(上述した第1実施形態に係る動作パターン3参照)をeNB200から受信している場合に限り、下りリンクにおけるアーリーデータ伝送の能力をランダムアクセスプリアンブルによってeNB200に通知してもよい。当該ページングメッセージは、下りリンクにおけるアーリーデータ伝送を行うことを明示的に示す情報を含んでもよい。当該ページングメッセージは、下りリンクにおけるアーリーデータ伝送を行うことを暗示的に示す情報(例えば、下りリンクにおけるアーリーデータ伝送の能力を有することを示すランダムアクセスプリアンブルの送信に用いるPRACHリソースの情報)を含んでもよい。
また、UE100は、下りリンクにおけるアーリーデータ伝送を指示する旨のMsg2(上述した変更例7参照)をeNB200から受信している場合に限り、下りリンクにおけるアーリーデータ伝送の能力をRRC接続要求メッセージによってeNB200に通知してもよい。当該Msg2は、下りリンクにおけるアーリーデータ伝送を行うことを明示的に示す情報を含んでもよい。当該Msg2は、下りリンクにおけるアーリーデータ伝送を行うことを暗示的に示す情報を含んでもよい。
(変更例10)
変更例9において、UE100が下りリンクにおけるアーリーデータ伝送に対応(サポート)しているか否かをUE100からeNB200に通知する一例を説明した。しかしながら、コアネットワーク(EPC20)に設けられるモビリティ管理装置(MME300)が、下りリンクにおけるアーリーデータ伝送を行う能力をUE100が有するか否かをeNB200に通知してもよい。この動作に先立ち、UE100は、下りリンクにおけるアーリーデータ伝送を行う能力を有することを示す情報をMME300に通知し、MME300は、当該情報を含むUEコンテキストを一定期間(例えば、UE100がEMM Registered状態の間)において保持してもよい。
MME300は、当該能力を、ページングメッセージ(S1ページングメッセージ)によってeNB200に通知してもよいし、INITIAL CONTEXT SETUPメッセージによってeNB200に通知してもよい。MME300は、NASシグナリングによってデータをUE100に送信する際に、当該能力をNASシグナリング又はS1メッセージによってeNB200に通知してもよい。
(変更例11)
上述した変更例4において、アーリーデータ伝送によってデータ送信が完了したと判断された場合、UE100が、RRCアイドルモードからRRCコネクティッドモードに遷移することなくランダムアクセスプロシージャを終了する動作を説明した。変更例8は、下りリンクにおけるアーリーデータ伝送の場合の動作例に関する。
変更例11において、eNB200は、下りリンクにおけるアーリーデータ伝送によってUE100に対して送信するデータの量に基づいて、当該データの送信に用いるメッセージ(所定メッセージ)として第1メッセージ及び第2メッセージのいずれかを決定する。第1メッセージは、UE100をアイドルモードからコネクティッドモードに遷移させるために用いるRRC接続確立メッセージである。第2メッセージは、UE100をアイドルモードに維持させるために用いるメッセージである。第2メッセージしてRRC接続解放メッセージを用いる一例を説明するが、第2メッセージは、新たなメッセージであってよい。
例えば、eNB200は、UE100に送信すべきデータの量が、RRC接続解放メッセージによって運搬可能な最大データ量以下である場合に、RRC接続解放メッセージによってデータ送信が完了すると判断する。この場合、eNB200は、RRC接続確立メッセージの送信に代えて、データを含むRRC接続解放メッセージをUE100に送信する。これによって、ランダムアクセスプロシージャを途中で中止し、UE100がコネクティッドモードに遷移しないようにすることができる。一方で、eNB200は、UE100に送信すべきデータの量が、RRC接続解放メッセージによって運搬可能な最大データ量を超える場合に、RRC接続解放メッセージによってデータ送信が完了しないと判断する。この場合、eNB200は、データを含むRRC接続確立メッセージをUE100に送信する。これによって、ランダムアクセスプロシージャをUE100に継続させることができる。
或いは、メッセージを異ならせることに代えて、RRC接続確立メッセージによって、データ送信の終了をUE100に通知してもよい。例えば、eNB200は、UE100に送信すべきデータの量が、RRC接続確立メッセージによって運搬可能な最大データ量以下である場合に、RRC接続確立メッセージによってデータ送信が完了すると判断する。この場合、eNB200は、データと、データ送信の終了を示す情報(いわゆる、エンドマーカ)とを含むRRC接続確立メッセージをUE100に送信する。これによって、ランダムアクセスプロシージャを途中で中止し、UE100がコネクティッドモードに遷移しないようにすることができる。一方で、eNB200は、UE100に送信すべきデータの量が、RRC接続確立メッセージによって運搬可能な最大データ量を超える場合に、RRC接続確立メッセージによってデータ送信が完了しないと判断する。この場合、eNB200は、データを含み、且つエンドマーカを含まないRRC接続確立メッセージをUE100に送信する。これによって、ランダムアクセスプロシージャをUE100に継続させることができる。
(変更例12)
上述した変更例8において、UE100が、RRC接続要求メッセージ(Msg3)によるデータの送信が失敗したと判断した場合に、当該データを伴うRRC接続要求メッセージを再送する一例を説明した。
かかる再送動作は、下りリンクにおけるアーリーデータ伝送にも応用可能である。変更例9において、eNB200は、アーリーデータ伝送によって、データを伴うRRC接続確立メッセージ(Msg4)をUE100に送信し、その後、RRC接続確立メッセージによるデータの送信が成功したか否かを判断する。eNB200は、かかる判断を、例えば、MACレイヤにおけるHARQ ACK又はHARQ NACKに基づいて行ってもよい。そして、eNB200は、Msg4によるデータの送信が失敗したと判断した場合、当該データを伴うMsg4を再送する。UE100は、下りリンクにおけるアーリーデータ伝送が設定されており、Msg4受信に失敗した場合、Msg4再送において当該データも再送されると判断する。そして、UE100(例えば、UE100のMACレイヤよりも上位のレイヤ(RRCレイヤ等))は、Msg4を構成するRRCメッセージ(RRC Connection Reconfiguration)受信とデータ受信の両方を実施できるように待ち受けを行う。
(変更例13)
変更例13は、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送の両方に関連する実施例である。
変更例13において、UE100及び/又はeNB200は、上りリンク及び下りリンクの一方におけるアーリーデータ伝送が行われるランダムアクセスプロシージャについて、上りリンク及び下りリンクの他方におけるアーリーデータ伝送を行わないと判断する。これにより、1つのUE100が行う1つのランダムアクセスプロシージャにおいては、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送のうち一方のみを実施可能とする。
1つのランダムアクセスプロシージャにおいて、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送の両方を実施可能とすると、アーリーデータ伝送に関する制御が複雑化する懸念がある。また、次のような問題が生じ得る。例えば、UE100は、RRC接続要求メッセージ(Msg3)によってデータを送信した後、当該データに対応する応答データ(例えば、TCP ACK)がRRC接続確立メッセージ(Msg4)によって送信されるのを待たなければならない。かかる応答データは、ネットワークにおける遅延の影響等を受けるため、応答データがRRC接続確立メッセージ(Msg4)によって送信されるのをUE100が待ち続けることは好ましくない。よって、1つのランダムアクセスプロシージャにおいては、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送のうち一方のみを実施可能とすることによって、かかる問題を回避することができる。
変更例13において、UE100は、RRC接続要求メッセージ(Msg3)によってデータ送信を行う場合、RRC接続確立メッセージ(Msg4)によってデータ受信を行わないと判断する。言い換えると、UE100は、Msg3を用いる上りリンクのアーリーデータ伝送が行われるランダムアクセスプロシージャについて、Msg4を用いる下りリンクのアーリーデータ伝送を行わないと判断する。例えば、UE100が、Msg4を用いる下りリンクのアーリーデータ伝送を行う旨をページングメッセージによって通知された場合(第1実施形態の動作パターン3参照)、又は、Msg4を用いる下りリンクのアーリーデータ伝送を行う旨をランダムアクセス応答によって通知された場合(変更例7参照)を想定する。かかる場合であっても、UE100は、RRC接続要求メッセージ(Msg3)によってデータ送信を行う場合、RRC接続確立メッセージ(Msg4)によってデータ受信を行う必要がない判断してもよい。また、eNB200は、RRC接続要求メッセージ(Msg3)によってデータ受信を行った場合、RRC接続確立メッセージ(Msg4)によってデータ送信を行わないと判断してもよい。
変更例13において、UE100は、RRC接続確立メッセージ(Msg4)によってデータ受信を行う場合、RRC接続要求メッセージ(Msg3)によってデータ送信を行わないと判断する。言い換えると、UE100は、Msg4を用いる下りリンクのアーリーデータ伝送が行われるランダムアクセスプロシージャについて、Msg3を用いる上りリンクのアーリーデータ伝送を行わないと判断する。例えば、UE100が、Msg4を用いる下りリンクのアーリーデータ伝送を行う旨をページングメッセージによって通知された場合(第1実施形態の動作パターン3参照)、又は、Msg4を用いる下りリンクのアーリーデータ伝送を行う旨をランダムアクセス応答(Msg2)によって通知された場合(変更例7参照)を想定する。かかる場合、UE100が上りリンクの送信データを持っていても、UE100は、Msg4を用いる下りリンクのアーリーデータ伝送を行うと判断し、Msg3を用いる上りリンクの送信データを行わないと判断してもよい。
変更例13において、アーリーデータ伝送を行う能力を有するUE100が、アーリーデータ伝送を行う能力を有することを示す通知(識別子)を、ランダムアクセスプリアンブル(Msg1)及びRRC接続要求メッセージ(Msg3)のいずれかによってeNB200に送信するシナリオを想定する(変更例9参照)。
かかるシナリオにおいて、下りリンクにおけるアーリーデータ伝送を行うことを示す情報がページングメッセージ又はMsg2によってeNB200からUE100に送信されている場合、eNB200は、アーリーデータ伝送を行う能力を有することを示す通知をUE100から受信すると、当該通知を、下りリンクにおけるアーリーデータ伝送を行う能力を示すものであると解釈する。下りリンクにおけるアーリーデータ伝送を行う能力及び/又は意図を有するUE100は、下りリンクにおけるアーリーデータ伝送を行うことを示す情報をeNB200から受信している場合に、アーリーデータ伝送を行う能力を有することを示す通知をeNB200に送信することによって、下りリンクにおけるアーリーデータ伝送を行う能力及び/又は意図をeNB200に通知する。
一方で、下りリンクにおけるアーリーデータ伝送を行うことを示す情報がページングメッセージ又はMsg2によってeNB200からUE100に送信されていない場合、eNB200は、アーリーデータ伝送を行う能力を有することを示す通知をUE100から受信すると、当該通知を、上りリンクにおけるアーリーデータ伝送を行う能力及び/又は意図を示すものであると解釈する。上りリンクにおけるアーリーデータ伝送を行う能力及び/又は意図を有するUE100は、下りリンクにおけるアーリーデータ伝送を行うことを示す情報をeNB200から受信していない場合に、アーリーデータ伝送を行う能力を有することを示す通知をeNB200に送信することによって、上りリンクにおけるアーリーデータ伝送を行う能力及び/又は意図をeNB200に通知する。
このように、下りリンクにおけるアーリーデータ伝送を行うことを示す情報が送信されているか否かに応じて、通知の意味合いを異ならせる。これによって、1種類の通知(例えば、1つの情報要素)が2通りの役割を果たすことができる。
(変更例14)
変更例14においては、変更例13とは異なり、1つのランダムアクセスプロシージャにおいて、上りリンクにおけるアーリーデータ伝送及び下りリンクにおけるアーリーデータ伝送の両方を実施可能とするシナリオを想定する。
一般的なランダムアクセスプロシージャにおいて、UE100は、データを伴わないMsg3を送信する場合、当該Msg3の送信時に、eNB200から送信されるMsg4の受信を待つべき待ち時間を定める第1のタイマを起動する。かかる第1のタイマは、Contention Resolution Timerと称されることがある。第1のタイマは、eNB200からSIBによってUE100に設定される。UE100は、Msg4を受信することなく第1のタイマが満了すると、Msg4を受信するための処理(例えば、PDCCHの監視)を中止し、ランダムアクセスプロシージャをMsg1の送信から再開する。
しかしながら、上述したように、RRC接続要求メッセージ(Msg3)によってデータを送信した後、当該データに対応する応答データ(例えば、TCP ACK)がRRC接続確立メッセージ(Msg4)によって送信される場合、第1のタイマでは待ち時間が足りない可能性がある。よって、変更例14において、第1のタイマとは別に、アーリーデータ伝送向けの第2のタイマを導入する。第1のタイマ及び第2のタイマの両方が設定されたUE100は、Msg3送信がデータ送信を伴わない場合には第1のタイマを選択し、Msg3送信がデータ送信を伴う場合には第2のタイマを選択する。
変更例14において、アーリーデータ伝送によってUE100がデータを伴うMsg3を送信する場合、UE100は、eNB200からデータを伴って送信されるMsg4の受信を待つべき待ち時間を定める第2のタイマを起動する。第2のタイマに対応する待ち時間の長さは、第1のタイマに対応する待ち時間の長さと異なる。例えば、第2のタイマに設定される待ち時間を、第1のタイマに設定される待ち時間よりも長くすることが可能である。例えば、第2のタイマに設定可能な最大待ち時間は、第1のタイマに設定可能な最大待ち時間よりも長い。第2のタイマは、eNB200からSIBによってUE100に設定される。或いは、RRCサスペンド状態のUE100についてはコンテキスト情報がネットワーク(及びUE100)において保持されるため、UE100がコネクティッドモードにある間に第2のタイマを個別RRCメッセージによってUE100に設定し、UE100がコネクティッドモードにある間は第2のタイマの設定をネットワークにおいて保持し、保持した設定をランダムアクセスプロシージャ時に用いてもよい。UE100は、データを伴うMsg4を受信することなく第2のタイマが満了すると、Msg4を受信するための処理(例えば、PDCCHの監視)を中止し、ランダムアクセスプロシージャをMsg1の送信から再開する。
或いは、アーリーデータ伝送がeMTC UE及びNB−IoT UEに適用されると仮定すると、UE100の省電力化が優先され得る。よって、第2のタイマに設定される待ち時間を、第1のタイマに設定される待ち時間よりも短くしてもよい。これにより、Msg4を受信するための処理を早期に打ち切ることができる。
なお、第1のタイマ及び第2のタイマのそれぞれは、RRCレイヤにおいて管理されるタイマであってもよいし、MACレイヤで管理されるタイマであってもよい。RRCレイヤにおいて管理される第1のタイマは、「T300」と称されることがある。MACレイヤにおいて管理される第1のタイマは、「Contention Resolution timer」と称されることがある。
第2のタイマのタイマ値(すなわち、Msg4の待ち時間)は、eNB200が決定してUE100に設定する場合に限らず、UE100が決定してもよい。UE100が上りリンクデータを送信してから上位レイヤのACK(例えば、TCP ACK)がUE100に返ってくるまでの時間であるround trip時間は、UE100の上位レイヤにおいて推定可能である。よって、第2のタイマのタイマ値をUE100が決定することにより、より適切なタイマ値を決定することができる。UE100は、第2のタイマに設定するタイマ値を決定し、決定したタイマ値をeNB200に対して通知してもよい。タイマ値の通知は、Msg3によって行なわれる。タイマ値の通知は、Msg1(プリアンブル送信)によって行なわれてもよい。
図17は、変更例14の動作の一例を示す図である。図17において、サーバ50は、コアネットワーク(EPC)よりも上位のネットワーク(例えば、インターネット)に設けられる。また、図17において、eNB200とサーバ50との間のネットワークエンティティ(例えば、S−GW)の図示を省略している。
図17に示すように、ステップS701において、UE100は、第2のタイマに設定するタイマ値を決定する。UE100は、round trip時間の推定値に基づいて第2のタイマのタイマ値を決定してもよい。
ステップS702において、UE100は、上りリンクのアーリーデータ伝送によって、データを伴うMsg3をeNB200に送信する。UE100は、決定したタイマ値をMsg3によってeNB200に通知する。eNB200は、かかる通知によって、UE100におけるMsg4待ち時間を把握することができる。
UE100は、第2のタイマを使うことをMsg1(プリアンブル送信)によってeNB200に通知してもよい。そして、UE100は、第2のタイマの使用許可をMsg2でeNB200から通知された場合のみ、第2のタイマを使用し、かつMsg3でタイマ値をeNB200に通知してもよい。
eNB200は、タイマ値の候補(タイマ値の範囲ごとのインデックスからなるリスト)をブロードキャスト(例えば、SIBにより送信)してもよい。この場合、UE100は、Msg3ではタイマ値のインデックスをeNB200に通知してもよい。
eNB200は、第2のタイマのデフォルトのタイマ値をブロードキャスト(例えば、SIBにより送信)してもよい。この場合、UE100は、基本的にデフォルトのタイマ値を利用する。UE100は、デフォルトのタイマ値を上書きしたい場合に限りタイマ値を自律的に決定し、決定したタイマ値をMsg3によってeNB200に通知してもよい。「T300」の値をデフォルトのタイマ値としてもよいし、「Contention Resolution timer」の値をデフォルトのタイマ値としてもよい。また、UE100が第2のタイマのタイマ値を決定する場合、UE100は、デフォルトのタイマ値以上のタイマ値を決定しなければならないという制約があってもよい。
eNB200は、UE100が設定可能なタイマ値の最大値をブロードキャスト(例えば、SIBにより送信)してもよい。UE100は、eNB200からブロードキャストされる最大値以下のタイマ値を決定し、決定したタイマ値をeNB200に通知する。但し、UE100は、タイマ値として、eNB200からブロードキャストされる最大値を決定した場合には、決定したタイマ値をeNB200に通知しなくてもよい。eNB200は、UE100からタイマ値が通知されない場合に、UE100が当該最大値を決定したとみなしてもよい。なお、UE100は、eNB200から最大値がブロードキャストにより指定されない場合には、予め規定されたデフォルトの最大値を用いて、デフォルトの最大値以下のタイマ値を決定してもよい。
eNB200は、UE100が設定可能なタイマ値の最小値をブロードキャスト(例えば、SIBにより送信)してもよい。UE100は、eNB200からブロードキャストされる最小値以上のタイマ値を決定し、決定したタイマ値をeNB200に通知する。但し、UE100は、タイマ値として、eNB200からブロードキャストされる最小値を決定した場合には、決定したタイマ値をeNB200に通知しなくてもよい。eNB200は、UE100からタイマ値が通知されない場合に、UE100が当該最小値を決定したとみなしてもよい。なお、UE100は、eNB200から最小値がブロードキャストにより指定されない場合には、予め規定されたデフォルトの最小値を用いて、デフォルトの最小値以上のタイマ値を決定してもよい。
ステップS703において、UE100は、Msg3の送信時に、決定したタイマ値が設定された第2のタイマを起動(開始)する。
ステップS704において、eNB200は、Msg3によってUE100から受信したデータをサーバ50に転送する。
ステップS705において、サーバ50は、応答データ(TCP ACK)をeNB200に送信する。
ステップS706において、eNB200は、下りリンクのアーリーデータ伝送によって、応答データ(TCP ACK)を伴うMsg4をUE100に送信する。
図17のシーケンスでは、Msg3送信が成功する場合を想定している。しかしながら、Msg3送信に失敗し、HARQ NACK(再送要求)がeNB200からUE100に送信され、UE100がHARQによってMsg3の再送を行う場合も想定される。UE100は、第2のタイマを起動した後、HARQによってMsg3の再送を行う場合に、第2のタイマを再開(再起動)させることなく、第2のタイマを動作継続させてもよい。これにより、上位レイヤがround trip時間に基づいて設定するTCP ACK待ち時間と、アクセスレイヤが設定するMsg4待ち時間とで不整合が生じることを回避できる。或いは、UE100は、第2のタイマを起動した後、HARQによってMsg3の再送を行う場合に、第2のタイマを再開(再起動)してもよい。
上記の変更例14の動作において、第1のタイマが「T300」又は「Contention Resolution timer」であり、第2のタイマがアーリーデータ伝送用の新たなタイマであることを想定している。すなわち、アーリーデータ伝送を伴うランダムアクセスプロシージャのための第1のタイマと、アーリーデータ伝送を伴わないランダムアクセスプロシージャのための第2のタイマとを別々のタイマとして規定することを想定していた。
ここで、「T300」は、ランダムアクセスプロシージャ(又はRRC Connection Establishment Procedure)においてUE100がMsg3を送信してからMsg4(具体的には、RRCメッセージ)を受信するまでの最大待ち時間を規定するタイマであり、RRCレイヤにおいて管理される。「Contention Resolution timer」は、ランダムアクセスプロシージャにおいてUE100がMsg3を送信してからMsg4(具体的には、MAC CE)を受信するまでの最大待ち時間を規定するタイマであり、MACレイヤにおいて管理される。
しかしながら、かかる新たなタイマ(第2のタイマ)を導入することに変えて、第1のタイマ(「T300」又は「Contention Resolution timer」)に設定するためのタイマ値として2種類のタイマ値を規定することにより、上記の変更例14の動作と同様な動作を実現可能である。これにより、新たなタイマを導入する場合に比べて、システムの仕様変更の影響を小さくすることができる。また、2つのタイマ(第1のタイマと第2のタイマ)を設定する代わりに、1つのタイマ(第1のタイマ)だけを設定すればよくなるため、UE100の処理負荷も低減される。
以下の変更例14において、第1のタイマに設定するためのタイマ値として2種類のタイマ値を規定する場合の動作について説明する。ここでは、第1のタイマとして「T300」を例示するが、第1のタイマは「Contention Resolution timer」であってもよい。
かかる場合、eNB200は、アーリーデータ伝送を伴わないランダムアクセスプロシージャのための第1のタイマ値と、アーリーデータ伝送を伴うランダムアクセスプロシージャのための第2のタイマ値とをUE100に送信する。第2のタイマ値は、第1のタイマ値よりも大きい値である。或いは、第2のタイマ値は、第1のタイマ値よりも小さい値であってもよい。
eNB200は、第1のタイマ値及び第2のタイマ値をブロードキャストで送信する。例えば、eNB200は、SIB中の既存の情報要素である「T300」(第1のタイマ値)と、SIB中の新たな情報要素である「T300−EDT」とをSIBにより送信する。eNB200は、第1のタイマ値及び第2のタイマ値を同一のSIBに含めてもよいし、第1のタイマ値及び第2のタイマ値を互いに異なるSIBに含めてもよい。
UE100は、アーリーデータ伝送を行うと判断したことに応じて、第1のタイマ値及び第2のタイマ値のうち第2のタイマ値を選択して第1のタイマに設定する。そして、UE100は、アーリーデータ伝送により上りリンクデータを送信する際に、第2のタイマ値を設定したタイマ(第1のタイマ)を開始させる。アーリーデータ伝送により上りリンクデータを送信するとは、具体的には、UE100が、Msg3の送信時に上りリンクユーザデータを送信することを意味する。
図18は、2種類のタイマ値を規定する場合の動作を示す図である。
図18に示すように、ステップS751において、eNB200は、第1のタイマ値及び第2のタイマ値をブロードキャストで送信する。eNB200は、第1のタイマ値及び第2のタイマ値を所定の周期で送信する。
ステップS752において、RRCアイドルモードにあるUE100は、ネットワークに送信するべき上りリンクデータが発生したことを検知し、ランダムアクセスプロシージャを開始する必要があると判断する。
ステップS753において、UE100は、アーリーデータ伝送(EDT)を行うか否かを判断する。例えば、UE100は、送信したい上りリンクデータ量がeNB200からブロードキャストで設定された最大上りリンクデータ量(トランスポートブロックサイズ)以下である場合には、EDTを行うと判断する。
アーリーデータ伝送を行わずに通常のランダムアクセスプロシージャを行うと判断した場合(ステップS753:NO)、ステップS754において、UE100は、第1のタイマ値を選択し、第1のタイマ値をタイマ(第1のタイマ)に設定する。そして、ステップS755において、UE100は、通常のランダムアクセスプロシージャを開始する。
一方で、アーリーデータ伝送を行うと判断した場合(ステップS753:YES)、ステップS756において、UE100は、第2のタイマ値を選択し、第2のタイマ値をタイマ(第1のタイマ)に設定する。そして、ステップS757において、UE100は、アーリーデータ伝送を伴うランダムアクセスプロシージャを開始する。
ランダムアクセスプロシージャが開始されると、ステップS758において、UE100及びeNB200は、Msg1及びMsg2の送受信を行う。なお、UE100及びeNB200は、アーリーデータ伝送を伴うか否かに応じて、Msg1及びMsg2の中身を異ならせてもよい。
ステップS759において、UE100は、Msg3をeNB200に送信する。アーリーデータ伝送を行う場合、UE100は、Msg3の送信に伴って上りリンクデータをeNB200に送信する。UE100は、Msg3の送信時にタイマ(第1のタイマ)を開始させる。
ステップS760において、UE100は、eNB200からMsg4を正常に受信したか否かを判定する。eNB200からMsg4を正常に受信した場合(ステップS760:YES)、ステップS761において、UE100は、タイマ(第1のタイマ)を停止させ、ランダムアクセスプロシージャを終了する又はRRC Connection Complete メッセージを送信した後にランダムアクセスプロシージャを終了する。UE100は、通常のランダムアクセスプロシージャを行った場合、RRCコネクティッドモードに遷移する。一方で、アーリーデータ伝送を行った場合、UE100は、RRCコネクティッドモードに遷移せずに、RRCアイドルモードを維持する。なお、UE100がeNB200からMsg4を正常に受信したとは、UE100が、eNB200から受信したUE100宛てのMsg4をデコードし、Msg4の中身を取得できたことを意味してもよい。
一方で、eNB200からMsg4を正常に受信せずにタイマ(第1のタイマ)が満了した場合(ステップS760:NO、ステップS762:YES)、ステップS763において、UE100は、ランダムアクセスプロシージャを最初から再開する(やり直す)又はランダムアクセスプロシージャを終了する。
なお、図18のフローでは、UE100は、アーリーデータ伝送を行うか否かをランダムアクセスプロシージャ開始前に判定(ステップS753)している。しかしながら、UE100は、Msg1でEDT(Early Data Transmission) Indicationを送信若しくは、アーリーデータ伝送(EDT)用のPRACH(Physical Random Access Channel)設定を用いて送信し、かつ、Msg2でアーリーデータ伝送(EDT)を行う事が許可された場合、Msg2でアーリーデータ伝送に関するリソースを含むEDT Grantを受信した場合、アーリーデータ伝送(EDT)用のDCIを受信した場合又はアーリーデータ伝送(EDT)実施するのに十分な上りリンクリソースを含むUL Grantを受信した場合において、Msg3で上りリンクのアーリーデータ伝送(UL EDT)を行った(ユーザデータをMsg3と一緒に送信した)時に、アーリーデータ伝送を行う(又は行っている)と判定してもよい。かかる場合、UE100は、Msg2を受信するまではタイマ(第1のタイマ)にタイマ値を設定せずに、Msg2を受信した後にタイマ(第1のタイマ)にタイマ値を設定する。
なお、UE100は、上記のいずれかの場合にアーリーデータ伝送を行うと判断してもよい。つまり、UE100は、上記の場合において、Msg1を送信した際、Msg2を受信した際、又はMsg3を送信した場合のいずれかをもって、アーリーデータ伝送を行う(又は行っている)と判定してもよい。
(変更例15)
上述した変更例14において、上位レイヤのACKをMsg4によってeNB200からUE100に送信する一例を説明した。この場合、UE100は、Msg3送信後、Msg4を受信するまで(又は第2のタイマが満了するまで)、サブフレームごとにPDCCHのモニタを継続しなければならない。特に、上位レイヤのACKが遅延した場合、UE100がPDCCHをモニタし続けることで、消費電力が増加する懸念がある。
変更例15においては、eNB200は、上位レイヤのACKの到着を待たずにMsg4をUE100に送信することにより、UE100がPDCCHの継続的なモニタを打ち切ることができるようにする。また、eNB200は、Msg4の送信後にUE100にデータ(上位レイヤのACK)を送信する予定であることをMsg4によってUE100に通知する。このMsg4送信は、UE100をRRCアイドルモードに維持させることを示す情報の送信を含んでもよい。これにより、UE100は、RRCアイドルモードを維持しつつ、下りリンクデータの受信を待つことができる。すなわち、UE100は、Msg4を受信すると、RRCコネクティッドモードに遷移することなく、下りリンクデータ(上位レイヤのACK)の待ち受けを行う。下りリンクデータの待ち受け中において、UE100は、DRX(Discontinues Reception)によって、不連続なサブフレームにおいてPDCCHを間欠的にモニタしてもよい。
図19は、変更例15の動作の一例を示す図である。図19において、サーバ50は、コアネットワーク(EPC)よりも上位のネットワーク(例えば、インターネット)に設けられる。また、図19において、eNB200とサーバ50との間のネットワークエンティティ(例えば、S−GW)の図示を省略している。
図19に示すように、ステップS711において、UE100は、上りリンクのアーリーデータ伝送によって、データを伴うMsg3をeNB200に送信する。
ステップS712において、eNB200は、Msg3によってUE100から受信したデータをサーバ50に転送する。
ステップS713において、eNB200は、Msg4をUE100に送信する。eNB200は、UE100をRRCアイドルモードに維持させる旨の情報と、Msg4の送信後に下りリンクデータの送信(すなわち、下りリンクのアーリーデータ伝送)を行う予定である旨の予告通知とをMsg4によってUE100に送信する。eNB200は、例えば次の1)〜3)の何れかの方法によって、下りリンクのアーリーデータ伝送を行うか否かを判断する。
1)eNB200は、過去のトラフィックパターン等を学習し、学習結果に基づいて下りリンクのアーリーデータ伝送を行うか否かを判断する。
2)MMEからeNB200に下りリンクのアーリーデータ伝送の意図が通知され、eNB200は、MMEからの通知に基づいて下りリンクのアーリーデータ伝送を行うか否かを判断する。
3)Msg3にてUE100からeNB200に下りリンクのアーリーデータ伝送が発生する可能性(上位レイヤACKの有無)を通知し、eNB200は、UE100からの通知に基づいて下りリンクのアーリーデータ伝送を行うか否かを判断する。
Msg4によってeNB200からUE100に送信される予告通知は、下りリンクのアーリーデータ伝送の発生予想タイミング(例えば、10秒後)を示す情報を含んでもよい。予告通知は、MAC CEに含まれてもよいし、RRCメッセージに含まれてもよい。
ステップS714において、Msg4を受信したUE100は、下りリンクデータの受信待ち時間を規定するタイマを起動してもよい。当該タイマのタイマ値(閾値)は、eNB200からUE100に対して、SIB、Msg4、又はMsg2によって設定されてもよい。UE100は、下りリンクデータを受信することなくタイマが満了すると、下りリンクデータの待ち受けを終了してもよい。
ステップS715において、UE100は、DRXを開始し、PDCCHを間欠的にモニタする。DRXの設定情報は、eNB200からUE100に対してSIB又はMsg4によって通知されてもよい。かかるDRX動作は、RRCコネクティッドモードのDRXに準じた動作としてもよいし、RRCアイドルモードのDRXに準じた動作としてもよい。
RRCコネクティッドモードのDRXに準じた動作とする場合について説明する。ステップS715で開始されるDRXにおいてeNB200からUE100に設定されるDRXサイクルは、RRCコネクティッドモードのDRXにおいて設定可能なDRXサイクルよりも長いことが好ましい。現状、RRCコネクティッドモードのDRXサイクルの最大値は、1024無線フレーム分の時間(すなわち、10.24秒)である。10.24秒よりも長いDRXサイクルを設定する方法として、eDRX(extended DRX)の仕組みを応用し、次のa)及びb)のいずれかの方法を用いることができる。eDRXにおいては、ハイパーフレームが導入される。ハイパーフレームは、1024無線フレーム分の時間長を有する時間単位である。現在のハイパーフレーム番号(H−SFN)はeNB200からSIBによってブロードキャストされる。
a)UE100は、「H−SFN mod m = 0」を満たすH−SFNを受信H−SFNとして決定する。eNB200は、かかる計算式における「m」の値をUE100に設定する。UE100は、決定した受信H−SFN内において、従来のRRCコネクティッドモードのDRX動作を行う。具体的には、UE100は、設定されたDRXサイクルでウェイクアップし、ウェイクアップ状態においてPDCCHをモニタする。UE100は、「H−SFN mod m = 0」を満たさないH−SFNにおいてスリープ状態(すなわち、PDCCHをモニタしない状態)を維持することができる。
b)UE100は、連続する2つのハイパーフレームを1セットとして用いて、1024無線フレーム以上の長さのDRXサイクルに対応可能とする。1つのハイパーフレームは、0から1023までの無線フレーム番号(SFN)を有する1024個の無線フレームからなる。UE100は、1つのセットを構成する1つ目のハイパーフレーム(例えば偶数番のハイパーフレーム)において0から1023までSFNをカウントした後、当該1つのセットを構成する2つ目のハイパーフレーム(例えば奇数番のハイパーフレーム)の最初の無線フレームをSFN=1024とカウントし、当該2つ目のハイパーフレームの2番目の無線フレームをSFN=1025とカウントする。このように、UE100は、1つ目のハイパーフレームにおけるSFNのカウント値を2つ目のハイパーフレームにおいて引き継ぐことによりカウントを継続する。これにより、UE100は、1024無線フレーム分の時間(すなわち、10.24秒)よりも長い時間のDRXサイクルを用いてDRX動作を行うことができる。
次に、RRCアイドルモードのDRXに準じた動作とする場合について説明する。従来のRRCアイドルモードのDRXの決定には、DRXサイクルとUE100のIMSI(International Mobile Subscriber Identity)とが用いられる。IMSIは、複数のUE間でページングオケージョン(すなわち、PDCCHモニタのタイミング)を分散させるために用いられる。しかしながら、ランダムアクセスプロシージャ中においてはeNB200がUE100のIMSIを未だ取得していないことが想定される。一方、Msg3には、S−TMSI(SAE Temporary Mobile Subscriber Identity)又はResume IDが含まれるため、eNB200は、ランダムアクセスプロシージャ中にUE100のS−TMSI又はResume IDを取得することができる。よって、eNB200及びUE100は、IMSIの代わりにS−TMSI又はResume IDを用いてページングオケージョンを決定する。
ステップS716において、サーバ50は、応答データ(TCP ACK)をeNB200に送信する。
ステップS717において、eNB200は、下りリンクのアーリーデータ伝送によって、応答データ(TCP ACK)をUE100に送信する。UE100は、下りリンクデータを受信する。
なお、UE100は、下りリンクデータとしてTCP NACKを受信した場合、ランダムアクセスプロシージャを開始し、上りリンクのアーリーデータ伝送を行なってもよい。
図19の動作において、UE100は、データを伴うMsg3を送信(ステップS711)してから下りリンクデータ送信の予告を受信(ステップS713)するまでは、RRCレイヤにおいて管理される「T300」タイマ及び/又はMACレイヤにおいて管理される「Contention Resolution timer」を動作させており、PDCCHを連続的に監視する。そして、UE100は、下りリンクデータ送信の予告(ステップS713)の受信に応じてタイマを起動し(ステップS714)、このタイマの動作中はDRX動作を行う(ステップS715)。
データ送信の予告が導入されない場合にも、かかる2段階のタイマを用いて受信動作を切り替えることが可能である。
かかる動作は、UE100が、ランダムアクセスプロシージャ中に、eNB200に対してRRCメッセージ(Msg3)を送信するとともにユーザデータを送信するアーリーデータ伝送を実行するステップと、UE100が、アーリーデータ伝送の実行に応じて、第1のタイマを起動するステップと、UE100が、第1のタイマが動作している間は、下りリンク制御チャネル(PDCCH)を連続的に監視する第1の受信動作を実行するステップと、UE100が、第1のタイマが満了したことに応じて、第2のタイマを起動するステップと、UE100が、第2のタイマが動作している間は、第1の受信動作とは異なる第2の受信動作を実行するステップと、を備える。第2の受信動作は、第1の受信動作に比べて、下りリンク制御チャネルを監視する頻度が少ない受信動作である。例えば、第2の受信動作は、下りリンク制御チャネル(PDCCH)を間欠的に監視する間欠受信(DRX)動作である。
ここで、第1のタイマは、RRCレイヤにおいて管理される「T300」タイマ又はMACレイヤにおいて管理される「Contention Resolution timer」であってもよい。通常、eNB200からの応答(例えばMsg4)を受信することなく「T300」タイマや「Contention Resolution timer」が満了すると、UE100は、ランダムアクセスプロシージャの失敗(contention resolution failure等)と判断してランダムアクセスプロシージャをやり直す。しかしながら、アーリーデータ伝送を実行する場合には、UE100は、第1のタイマ(「T300」タイマ又は「Contention Resolution timer」)が満了しても、ランダムアクセスプロシージャが失敗したと判断せずにランダムアクセスプロシージャを継続する。
或いは、第1のタイマは、「T300」タイマ及び「Contention Resolution timer」とは異なる新たなタイマであってもよい。UE100は、アーリーデータ伝送を行う場合には、「T300」タイマ及び「Contention Resolution timer」を起動せずに、かかる新たなタイマを起動する(変更例14参照)。
一方、下りリンクデータ送信の予告が導入される場合、eNB200は、UE100からRRCメッセージ及びユーザデータを受信した後、下りリンクデータ送信の予告(所定のメッセージ)をUE100に送信する(ステップS713)。UE100は、第1のタイマが動作中に所定のメッセージを受信したことに応じて、第1のタイマを停止し、第1の受信動作を停止する。UE100は、第1のタイマの停止(第1の受信動作を停止)に応じて、第2のタイマを起動する。
なお、所定のメッセージとしては、Msg4におけるMACレイヤのContention Resolutionを用いてもよい。このContention Resolutionには、データ送信の予告を示すフラグ(1ビット識別子)が付加されてもよい。そして、eNB200は、下りリンクデータ送信時(ステップS717)において、下りリンクデータと共に、Msg4におけるRRCレイヤのRRC Connection SetupをUE100に送信する。
(変更例16)
変更例16は、変更例14及び変更例15に関連する変更例である。変更例16について、変更例14及び変更例15との相違点を主として説明する。
変更例16において、UE100は、Msg3を利用して上りリンクのアーリーデータ伝送を行う。UE100は、アーリーデータ伝送の実行に応じて、eNB200から送信される応答の受信を待つべき待ち時間を定めるタイマを起動する。「タイマ」は、変更例14に係る第1のタイマ又は第2のタイマであってもよいし、変更例15に係るタイマであってもよい。「eNB200から送信される応答」は、eNB200からデータを伴って送信されるMsg4又はeNB200からデータを伴わずに送信されるMsg4であってもよいし(変更例14参照)、eNB200からMsg4(予告通知)の送信後に送信されるデータであってもよい(変更例15参照)。
そして、UE100は、タイマに対応する待ち時間の終了タイミングに基づいて定められるPDCCH監視タイミングまで、PDCCHの監視を省略する。例えば、UE100は、タイマが満了した時点のサブフレームにおいてのみ、PDCCHを監視する。これにより、タイマが動作中はUE100の受信機をオフにすることができるため、UE100の消費電力を削減できる。
UE100は、タイマが満了した時点のサブフレームに代えて、タイマが満了した直後のサブフレーム(すなわち、タイマが満了した時点のサブフレームの次のサブフレーム)、又はタイマが満了してから規定時間経過後のサブフレームにおいてのみ、PDCCHを監視してもよい。或いは、UE100は、タイマが満了した時点のサブフレームに代えて、タイマが満了する直前のサブフレーム(すなわち、タイマが満了する時点のサブフレームの1つ前のサブフレーム)、又はタイマが満了するサブフレームの規定時間前のサブフレームにおいてのみ、PDCCHを監視してもよい。
或いは、UE100は、タイマが満了する時点を基準として定められる複数のタイミング(複数のサブフレーム)においてのみ、PDCCHを監視してもよい。例えば、UE100は、タイマが満了した時点のサブフレームと、タイマが満了した直後のサブフレーム又はタイマが満了してから規定時間経過後のサブフレームとにおいてのみ、PDCCHを監視してもよい。UE100は、タイマが満了した時点のサブフレームと、タイマが満了する直前のサブフレーム又はタイマが満了するサブフレームの規定時間前のサブフレームとにおいてのみ、PDCCHを監視してもよい。
なお、eNB200は、UE100に設定されたタイマ値を把握しており、UE100におけるPDCCH監視タイミングを推定できる。eNB200がPDCCH監視タイミングにおいて応答(例えば、データを伴うMsg4)をUE100に送信する場合、UE100は、PDCCH監視タイミングにおいて応答を受信できる。
UE100は、変更例16に係る動作を、以下の条件の少なくとも1つを満たした場合に限り実行してもよい。かかる条件は、従来のタイマ(T300、Contention resolution timer)を用いる場合に限り適用されるとしてもよい。
条件1:Msg1でアーリーデータ伝送の意図(EDT Indication)を通知したこと
条件2:Msg2でアーリーデータ伝送用の上りリンクグラント(一般的な上りリンクグラントよりもサイズが大きい)を受信したこと
条件3:Msg3でアーリーデータ伝送(データ送信)を実施したこと
(変更例17)
上述した第1実施形態において、上りリンクのアーリーデータ伝送においてUE100が送信可能なデータ量の最大値をeNB200がUE100に設定する一例について説明した。これにより、UE100は、自身の上りリンクデータの全てを上りリンクのアーリーデータ伝送によって送信可能であるか否かを判定し、送信可能であると判定した場合にはアーリーデータ伝送を開始し、そうではない場合にはアーリーデータ伝送を開始しないようにすることが可能である。
上述したように、Msg3を利用した上りリンクのアーリーデータ伝送の後に、Msg4を利用した下りリンクのアーリーデータ伝送が続く場合、アップリンク(Msg3)及び下りリンク(Msg4)の1セットだけでデータ送受信を完了させることができる場合に限りアーリーデータ伝送を適用してもよい。よって、UE100は自身の下りリンクデータの全てを下りリンクのアーリーデータ伝送によって受信可能であるか否かも判定し、受信可能であると判定した場合に限りアーリーデータ伝送を開始してもよい。
変更例17において、下りリンクのアーリーデータ伝送においてUE100が受信可能なデータ量の最大値をeNB200がUE100に設定する一例について主として説明する。また、変更例17において、上りリンクのアーリーデータ伝送がMsg3を利用して行われ、下りリンクのアーリーデータ伝送がMsg4を利用して行われることを想定する。
変更例17において、eNB200は、アーリーデータ伝送におけるデータ量条件に関する情報をブロードキャストメッセージ(SIB)によりUE100に送信する。例えば、eNB200は、データ量条件に関する情報として、アーリーデータ伝送においてeNB200が送信可能な下りリンクデータ量の最大値(最大トランスポートブロックサイズ)を示す情報を送信する。なお、eNB200がデータ量条件に関する情報を含むブロードキャストメッセージ(SIB)を送信することにより、RRCアイドルモードにあるUE100であってもブロードキャストメッセージを受信できる。
UE100は、データ量条件に関する情報をeNB200から受信する。また、UE100は、アーリーデータ伝送においてeNB200から受信するべき下りリンクユーザデータの量を推定する。例えば、UE100は、自身が実行するアプリケーションの種類等に基づいて、eNB200から受信するべき下りリンクユーザデータの量を推定する。具体的には、UE100は、アーリーデータ伝送を利用可能なアプリケーションのプロトコル構成により下りリンクユーザデータの量を推定する。例えば、UE100は、TCPレイヤを用いるアプリケーションである場合はTCPのACKデータ量を下りリンクユーザデータの量と推定する。加えて、アプリケーションレイヤにおいてサーバからデータ受信完了のレスポンスなどがある場合、当該レスポンスデータ量を、当該下りリンクユーザデータの量に加える。このような推定は、アプリケーションレイヤにおいて実施されてもよく、当該下りリンクユーザデータの量はアプリケーションレイヤからNASレイヤ及び/又はASレイヤへ通知されてもよい。もしくは、NASレイヤ及び/又はASレイヤで推定を実施する場合は、過去のアプリケーションレイヤの挙動の履歴を保持しておくことにより、当該履歴に含まれる過去の挙動から下りリンクユーザデータの量を推定することも可能である。
そして、UE100は、推定された下りリンクユーザデータの量がデータ量条件を満たす場合に、アーリーデータ伝送を開始する。例えば、UE100は、推定された下りリンクユーザデータの量が、eNB200から設定された最大下りリンクデータ量以下である場合に、アーリーデータ伝送を開始する。一方で、UE100は、推定された下りリンクユーザデータの量が、eNB200から送信及び設定された最大下りリンクデータ量を上回る場合には、アーリーデータ伝送を開始せずに通常のランダムアクセスプロシージャを開始する。
eNB200は、データ量条件に関する情報として、アーリーデータ伝送においてeNB200が送信可能な下りリンクデータ量の最小値(最小トランスポートブロックサイズ)を示す情報を送信してもよい。UE100は、推定された下りリンクユーザデータの量が、eNB200から設定された最小下りリンクデータ量以上である場合に、アーリーデータ伝送を開始する。一方で、UE100は、推定された下りリンクユーザデータの量が、eNB200から設定された最小下りリンクデータ量を下回る場合には、アーリーデータ伝送を開始せずに通常のランダムアクセスプロシージャを開始する。詳細については第2実施形態において説明するが、データ量が小さいとパディングビットが増えて効率が悪いため、RRCコネクティッドモードに遷移させてから必要最小限のリソースをeNB200がUE100に割り当てることにより、パディングビットの増加を抑制できる。また、RRCコネクティッドモードに遷移させれば、例えば、複数UEのデータを1つのリソース又はトランスポートブロックに多重化するような高度な処理や、単一UEにおいてデータをその他シグナリングなどと一緒に送信するといった処理も可能である。
或いは、UE100は、推定された下りリンクユーザデータの量が、eNB200から設定された最小下りリンクデータ量を下回る場合には、ランダムアクセスプロシージャを開始せずにRRCアイドルモードを維持してもよい。
図20は、変更例17の動作の一例を示す図である。
図20に示すように、ステップS771において、eNB200は、アーリーデータ伝送における最大下りリンクデータ量を示す最大下りリンクデータ量情報をブロードキャストで送信する。RRCアイドルモードにあるUE100は、eNB200から最大下りリンクデータ量情報を受信する。
eNB200は、アーリーデータ伝送における最大上りリンクデータ量を示す最大上りリンクデータ量情報をブロードキャストでさらに送信してもよい。RRCアイドルモードにあるUE100は、eNB200から最大上りリンクデータ量情報を受信する。
ステップS772において、UE100は、ランダムアクセスプロシージャの開始契機を検知する。かかる開始契機は、例えば、送信すべき上りリンクデータがUE100において発生したこと、又はUE100がページングメッセージを受信したこと等である。
ステップS773において、UE100は、アーリーデータ伝送においてeNB200から受信するべき下りリンクユーザデータの量を推定する。具体的には、UE100は、eNB200からMsg4送信時にUE100に送信される下りリンクユーザデータの量を推定する。
ステップS774において、UE100は、推定した下りリンクユーザデータ量が、eNB200から設定された最大下りリンクデータ量以下であるか否かを判定する。推定した下りリンクユーザデータ量が最大下りリンクデータ量以下である場合(ステップS774:YES)、ステップS775において、UE100は、アーリーデータ伝送を伴うランダムアクセスプロシージャを開始する。一方で、推定した下りリンクユーザデータ量が最大下りリンクデータ量を上回る場合(ステップS774:NO)、ステップS776において、UE100は、アーリーデータ伝送を伴わない通常のランダムアクセスプロシージャを開始する。
なお、ステップS774において、UE100は、送信すべき上りリンクユーザデータ量が、eNB200から設定された最大上りリンクデータ量以下であるか否かをさらに判定してもよい。UE100は、推定した下りリンクユーザデータ量が最大下りリンクデータ量以下であり、かつ、推定した上りリンクユーザデータ量が最大上りリンクデータ量以下である場合に、アーリーデータ伝送を伴うランダムアクセスプロシージャを開始する。そうではない場合、UE100は、アーリーデータ伝送を伴わない通常のランダムアクセスプロシージャを開始する。
なお、アーリーデータ伝送における最大上りリンクデータ量と最大下りリンクデータ量とが同じであると規定されている場合、eNB200は、最大下りリンクデータ量をUE100に通知しなくてもよい。かかる場合、UE100は、推定した下りリンクデータ量が、eNB200から設定された最大上りリンクデータ量以下である場合に、アーリーデータ伝送が可能であると判定してもよい。
なお、図20において、eNB200が、アーリーデータ伝送における最大下りリンクデータ量を示す最大下りリンクデータ量情報をブロードキャストで送信する一例について説明した。しかしながら、eNB200は、最大下りリンクデータ量情報をユニキャストで送信してもよい。かかるユニキャストメッセージを送信する場合、eNB200がUE個別にデータ量条件を設定できる。
例えば、eNB200は、UE100がRRCコネクティッドモードであるときに、最大下りリンクデータ量情報を含むRRC Connection ReleaseメッセージをUE100に送信する。UE100は、RRC Connection Releaseメッセージの受信に応じてRRCアイドルモードに遷移するとともに、この最大下りリンクデータ量情報を記憶する。ここで、eNB200は、RRCアイドルモードのサブ状態であるサスペンド状態にUE100を移行させてもよい。サスペンド状態の場合、UE100のコンテキスト情報がeNB200において維持される。
そして、UE100は、RRCアイドルモードにおいてランダムアクセスプロシージャを開始する。UE100がサスペンド状態である場合、eNB200は、ランダムアクセスプロシージャの際にUE100のコンテキスト情報を参照し、このUE100に最大下りリンクデータ量が設定されていることを認識する。一方で、UE100がサスペンド状態でない場合、eNB200は、UE100のコンテキスト情報を有していないため、最大下りリンクデータ量が設定されていること及び/又は設定されている最大下りリンクデータ量を、ランダムアクセスプロシージャ中(例えば、Msg3送信時)にUE100からeNB200に通知する。
(変更例18)
上述したように、アーリーデータ伝送における最大データ量(最大トランスポートブロックサイズ)をeNB200がUE100に設定する場合、eNB200が、最適な最大データ量を決定することが難しい。具体的には、UE100がアーリーデータ伝送によって送受信するデータ量(トランスポートブロックサイズ)は、UE100が実行するアプリケーションの種類や状況に応じて変化する。アーリーデータ伝送における最大データ量の設定が過大であると、無駄なリソースが発生し得る。一方で、アーリーデータ伝送における最大データ量の設定が過小であると、この最大トランスポートブロックサイズを超えるデータを送受信したいUE100がアーリーデータ伝送を利用できないため、アーリーデータ伝送による消費電力削減・遅延削減の効果が損なわれる。
変更例18において、UE100は、アーリーデータ伝送において送受信すべきユーザデータの量を判定する。例えば、UE100は、上りリンクのアーリーデータ伝送によりUE100が送信したい上りリンクデータの量を判定する。かかる判定に加えて又はかかる判定に代えて、UE100は、下りリンクのアーリーデータ伝送によりUE100が受信したい下りリンクデータの量を判定してもよい。そして、UE100は、自身がRRCコネクティッドモードにあるときに、判定されたユーザデータの量に基づいて、UE100が推奨する最大データ量(最大トランスポートブロックサイズ)を示す情報をeNB200に送信する。かかる推奨最大データ量は、上りリンクの推奨最大データ量であってもよいし、下りリンクの推奨最大データ量であってもよい。
かかる最大データ量の通知は、アーリーデータ伝送を行う能力を有するUE100のみが行うとしてもよい。かかる場合、eNB200は、UE100からの通知をUE能力情報としてUEコンテキストに保存してもよい。
eNB200は、アーリーデータ伝送についての推奨最大データ量の情報を多数のUE100から収集し、収集した情報に対する統計処理を行うことにより、アーリーデータ伝送における最適な最大データ量を決定する。例えば、eNB200は、上りリンクのアーリーデータ伝送についての推奨最大データ量の情報を収集し、収集した情報に基づいて、上りリンクのアーリーデータ伝送における最適な最大データ量を決定する。eNB200は、下りリンクのアーリーデータ伝送についての推奨最大データ量の情報を収集し、収集した情報に基づいて、下りリンクのアーリーデータ伝送における最適な最大データ量を決定してもよい。eNB200は、最適な最大データ量を決定した後、決定した最大データ量をUE100に設定する。例えば、eNB200は、決定した最大データ量を示す情報をブロードキャストすることにより、eNB200のセル内のUE100に当該最大データ量を設定する。
図21は、変更例18の動作の一例を示す図である。ここでは、Msg3を利用したアーリーデータ伝送における推奨最大上りリンクデータ量をUE100からeNB200に通知する一例について説明する。なお、以下の例は、推奨最大上りリンクデータ量を例にして説明しているが、推奨最大下りリンクデータ量に置き換えても適用することができる。
図21に示すように、ステップS781において、eNB200は、アーリーデータ伝送における推奨最大上りリンクデータ量の通知の送信を要求又は設定する情報をUE100に送信する。eNB200は、かかる情報を、ランダムアクセスプロシージャにおけるMsg4(RRC Connection Setup メッセージ)、ユニキャストメッセージである測定設定(Measurement Configuration)、UE Information Requestメッセージ及び/又はMDT(Minimization of Drive Test)の設定メッセージに含めてもよい。もしくは、eNB200は、ブロードキャストメッセージによって、当該通知を許可又は要求する情報をUE100に報知してもよい。但し、ステップS781は必須ではなく、省略可能である。
ステップS782において、UE100は、アーリーデータ伝送における推奨最大上りリンクデータ量を決定する。例えば、UE100は、上りリンクデータの発生に応じてランダムアクセスプロシージャを行う際に当該上りリンクデータの量を記憶しており、記憶している上りリンクデータの量を推奨最大上りリンクデータ量として決定する。
ステップS783において、UE100は、決定した推奨最大上りリンクデータ量を示す情報をeNB200に送信する。UE100は、かかる情報を、測定報告に含めてもよいし、ランダムアクセスプロシージャのMsg5(RRC Connection Setup Complete又はRRC Connection Resume Complete)又はUE Information Responseメッセージに含めてもよい。なお、RRC Connection Setup Complete及びRRC Connection Resume Completeは、ランダムアクセスプロシージャの直後にUE100からeNB200に送信されるメッセージと位置付けてもよい。
なお、RRCアイドルモードにあるUE100は、自身において発生した上りリンクデータの量が、eNB200から設定された最大上りリンクデータ量を超える場合には、アーリーデータ伝送を伴わない通常のランダムアクセスプロシージャを開始するとともに、当該上りリンクデータの量を記憶してもよい。そして、UE100は、通常のランダムアクセスプロシージャによりRRCコネクティッドモードに遷移した後に、記憶している上りリンクデータの量を推奨最大上りリンクデータ量としてeNB200に通知してもよい。
ステップS784において、eNB200は、UE100から通知された推奨最大上りリンクデータ量に基づいて最適な最大上りリンクデータ量を決定する。eNB200は、最適な最大上りリンクデータ量を決定した後、決定した最大上りリンクデータ量をブロードキャストすることにより、eNB200のセル内のUE100に当該最大上りリンクデータ量を設定する。
或いは、eNB200は、最大データ量(最大上りリンクデータ量)をブロードキャストでUE100に設定する場合に限らず、最大データ量をユニキャスト(例えば、RRC Connection Release)でUE100に設定してもよい。かかる場合、eNB200は、UE100から通知された推奨最大データ量に基づいて、当該UE100に対して最適な最大データ量を決定し、決定した最大データ量をユニキャストで当該UE100に設定する。
なお、本変更例において、eNB200が、UE100から通知された推奨最大上りリンクデータ量に基づいて、UE100に設定する最大上りリンクデータ量を決定する一例について説明した。しかしながら、詳細については第2実施形態において説明するが、最大上りリンクデータ量の範囲内で複数のブラインドデコーディング閾値をUE100に設定し得る。具体的には、UE100は、自身が送信するユーザデータ量よりも大きい最小のブラインドデコーディング閾値を特定し、特定したブラインドデコーディング閾値に対する不足分をパディングデータにより埋める。よって、パディングデータを少なくするために、eNB200は、UE100から通知された推奨最大上りリンクデータ量に基づいて、UE100に設定するブラインドデコーディング閾値を決定してもよい。
[第2実施形態]
第2実施形態について、第1実施形態との相違点を主として説明する。第2実施形態においては、ランダムアクセスプロシージャ中にMsg3を利用して上りリンクのアーリーデータ伝送を行う場合を想定する。UE100は、ランダムアクセスプロシージャ中にeNB200に対してRRCメッセージ(RRC Connection Requestメッセージ又はRRC Connection Resume Requestメッセージ)の送信に加えてユーザデータの送信を行う。
eNB200は、ランダムアクセスプロシージャ中に、上りリンク無線リソースを割り当てる上りリンクグラントを含むMsg2(ランダムアクセス応答)をUE100に送信する。UE100がRRCメッセージ(Msg3)に伴うユーザデータをeNB200に送信する場合、UE100に割り当てられる上りリンク無線リソースに対応する割り当てデータサイズ(すなわち、トランスポートブロックサイズ)は、RRCメッセージ及びユーザデータの合計サイズと一致していることが望ましい。なお、トランスポートブロックサイズは、上りリンクグラントにより割り当てられる上りリンク無線リソースの量(例えば、リソースブロック数)及びMCSによって定められる。eNB200は、UE100に割り当てたトランスポートブロックサイズを想定して復号処理を行う。
しかしながら、UE100に割り当てられるトランスポートブロックサイズは、RRCメッセージ及びユーザデータの合計サイズと一致しているとは限らない。UE100に割り当てられるトランスポートブロックサイズがRRCメッセージ及びユーザデータの合計サイズよりも大きい場合、UE100は、eNB200が復号処理を適切に行うことができるように、余分に割り当てられた上りリンク無線リソース内においてパディングデータを送信する必要がある。ここで、余分に割り当てられた上りリンク無線リソースが多い場合、UE100は多くのパディングデータを送信する必要があり、パディングデータを送信するためにUE100の消費電力が増大する問題がある。第2実施形態は、かかる問題点を解決するための実施形態である。
(1)動作パターン1
第2実施形態の動作パターン1において、eNB200は、ランダムアクセスプロシージャ中に、周期的な上りリンク無線リソースを割り当てる上りリンクグラントをUE100に送信する。かかるリソース割り当ては、セミパーシステントスケジューリング(SPS)と称されることがある。但し、従来のSPSは、ランダムアクセスプロシージャ中に適用されない。
第2実施形態の動作パターン1に係るSPSにおいて、SPSの設定情報(例えば、上りリンク送信周期)は、eNB200によってUE100に送信されるSIBに含まれる。また、動作パターン1において、Msg2によりUE100に送信される上りリンクグラントは、UE100に割り当てる上りリンク無線リソース(リソースブロック)の情報を含み、かつ、SPSをアクティブ化させるものである。すなわち、かかる上りリンクグラントは、UE100に周期的な上りリンク無線リソースを割り当てる。
UE100は、かかる上りリンクグラントの受信に応じて、ランダムアクセスプロシージャ中に、周期的な上りリンク無線リソースを用いて複数回の上りリンク送信を行う。具体的には、UE100は、SPS設定情報に従った上りリンク送信周期で、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いて上りリンク送信を行う。
このようにして、UE100が複数回の上りリンク送信を行うことにより、1回の上りリンク送信に用いる上りリンク無線リソースの量を少なくすることができる。また、UE100は、RRCメッセージとユーザデータとを異なるタイミング(異なるサブフレーム)で送信できる。例えば、UE100は、複数回の上りリンク送信において、1回目の上りリンク送信において少なくともRRCメッセージを送信し、2回目の上りリンク送信においてユーザデータの少なくとも一部を送信する。よって、UE100は、多くのパディングデータを送信する必要がない。
また、第2実施形態の動作パターン1において、eNB200は、周期的な上りリンク無線リソースを用いた上りリンク送信の最大送信回数を設定する情報をUE100に送信する。これにより、eNB200は、上りリンクデータの復号処理を行うべき回数を適切に把握できる。eNB200は、最大送信回数を設定する情報をSIBにより送信してもよいし、上りリンクグラント(Msg2)により送信してもよい。UE100は、設定された最大送信回数を超えない範囲内において複数回の上りリンク送信を行う。
図22は、第2実施形態の動作パターン1の一例を示す図である。初期状態においてUE100はRRCアイドルモードであってもよい。
図22に示すように、ステップS801において、eNB200は、SPS設定情報をSIBにより送信する。UE100は、SPS設定情報を受信して記憶する。eNB200は、最大送信回数を設定する情報をSIBにより送信してもよい。ここでは最大送信回数が3回であると仮定して説明を進める。
ステップS802において、UE100は、ランダムアクセスプリアンブル(Msg1)をeNB200に送信する。
ステップS803において、eNB200は、SPSをアクティブ化させる上りリンクグラントを含むランダムアクセス応答(Msg2)をUE100に送信する。上りリンクグラントは、1回分の上りリンク送信に用いるべき上りリンク無線リソース(リソースブロック)の情報を含む。ここで、1回分のリソース割り当てサイズ(トランスポートブロックサイズ)は、RRCメッセージのサイズと合致させてもよい。eNB200は、最大送信回数(3回)を設定する情報をMsg2により送信してもよい。
ステップS804(1回目の上りリンク送信)において、UE100は、上りリンクグラントの受信に応じて、割り当てられた上りリンク無線リソース(リソースブロック)を用いてRRCメッセージ(Msg3)をeNB200に送信する。
ステップS805(2回目の上りリンク送信)において、UE100は、SPS送信周期に従ったサブフレームにおいて、割り当てられた上りリンク無線リソース(リソースブロック)を用いて、ユーザデータの一部をeNB200に送信する。
ステップS806(3回目の上りリンク送信)において、UE100は、SPS送信周期に従ったサブフレームにおいて、割り当てられた上りリンク無線リソース(リソースブロック)を用いて、残りのユーザデータをeNB200に送信する。ここで、上りリンク送信回数が最大送信回数に達したため、UE100は、SPSを非アクティブ化する。また、UE100は、SPS設定情報を破棄してもよい。
なお、最大送信回数に達する前にユーザデータの送信が終了した場合(例えば、ステップS805で全てのユーザデータを送信した場合)、UE100は、SPS送信周期に従ったサブフレーム(ステップS806のタイミング)において上りリンク送信を行わなくてもよい。或いは、UE100は、最後の上りリンク送信の際(ステップS806のタイミング)に、データ送信の終了を示す情報をeNB200に送信してもよい。かかる情報(エンドマーカ)は、MAC CEにより送信されてもよい。
ステップS807において、eNB200は、Msg4をUE100に送信する。eNB200は、複数回の上りリンク送信のうち、どの上りリンク送信の受信処理に成功したか、及び/又はどの上りリンク送信の受信処理に失敗したかをMsg4によりUE100に通知してもよい。例えば、eNB200は、1回目のみ受信OKであったことを通知したり、2回目以降も受信OKであったことを通知したりする。
なお、本動作パターンにおいては、UE100がRRCメッセージ(RRC Connection Requestの入ったMAC PDU)の送信後にユーザデータを送信する一例を説明したが、UE100は、ユーザデータを先に送信し、データ送信が終了した後にRRCメッセージを送信してもよい。かかる場合、eNB200は、このRRCメッセージの受信により、ユーザデータの送信が終了したことを認識できる。
(2)動作パターン2
第2実施形態の動作パターン2において、eNB200は、ランダムアクセスプロシージャ中に、上りリンク無線リソースを割り当てる上りリンクグラントをMsg2によりUE100に送信する。
UE100は、上りリンクグラントの受信に応じて、ランダムアクセスプロシージャ中に、上りリンク無線リソースを用いてRRCメッセージ(Msg3)の繰り返し送信を行う。これにより、RRCメッセージに冗長性を持たせて、eNB200がRRCメッセージの受信処理(復号処理)に成功する確率を高めることができる。UE100は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いて、RRCメッセージの繰り返し送信に加えて、ユーザデータの繰り返し送信を行ってもよい。これにより、ユーザデータにも冗長性を持たせることができる。
eNB200は、復号処理において、繰り返し送信されたRRCメッセージのソフト合成及び繰り返し送信されたユーザデータのソフト合成を行う。このように、第2実施形態の動作パターン2においては、パディングデータの送信に代えて冗長送信を行うことにより、上りリンクグラントにより割り当てられた上りリンク無線リソースを有効に活用できる。
・HARQリダンダンシーバージョン
UE100は、RRCメッセージの繰り返し送信において、HARQリダンダンシーバージョン(すなわち、冗長構成)の異なるRRCメッセージを送信してもよい。また、UE100は、ユーザデータの繰り返し送信において、HARQリダンダンシーバージョンの異なるユーザデータを送信してもよい。これにより、eNB200における復号成功率をさらに高めることができる。
例えば、UE100は、複数のRRCメッセージ(又は複数のユーザデータ)を互いに異なるMAC PDUに格納し、HARQリダンダンシーバージョンの異なる複数のMAC PDUからなるセットを送信する。MAC PDUは、MACヘッダと、MAC CEと、MAC SDUとを含む(図16参照)。RRCメッセージ(又はユーザデータ)は、MAC SDUに相当する。
なお、冗長送信の第1の例として、MAC SDUのみを冗長化し、1つのMAC PDU内に複数のMAC SDUを格納して送信してもよい。かかる場合、リダンダンシーバージョンは1つだけとしつつ、次のような方法で冗長化によるゲインを得ることができる。具体的には、UE100は、レートマッチング前のビット列生成の際にはRRCメッセージ及びユーザデータのサイズに相当するビット長(TBSサイズ1)から生成する。そして、UE100は、レートマッチング処理時に、送信するビット列を循環バッファ(circular buffer)から取り出す際には、eNB200より割り当てられたリソース・MCSに応じたビット長を取り出す。これにより、リダンダンシーバージョンは1つだけであるが、循環バッファの同じ部分を繰り返す場合に比べて冗長化によるゲインが得られる。eNB200は、総当たり復号(ブラインドデコーディング)の際に、eNB200より割り当てられたリソース・MCSに相当するビット長(TBSサイズ2、eNB200にとって既知)に応じて、TBSサイズ1(eNB200にとって未知)を、TBSサイズ2の3/4、TBSサイズ2の1/2、TBSサイズ2の1/4といったように所定の比率で定義するようにしておくことで、ブラインドデコードが可能である。
冗長送信の第2の例として、MACヘッダも含めて冗長化し、HARQリダンダンシーバージョンの異なる複数のMAC PDUを送信してもよい。
・送信電力
繰り返し送信(冗長送信)を行う場合、UE100は、繰り返し送信を行わない場合に比べて送信電力を低下させてもよい。これにより、UE100の消費電力を削減できる。
UE100は、繰り返し送信回数に応じて送信電力を調整する。UE100は、繰り返し送信回数が多いほど、送信電力を低下させてもよい。例えば、UE100は、3個のMAC PDUを冗長送信する場合、1個のMAC PDUを送信する場合に比べて、送信電力を3分の1としてもよい。なお、送信電力を低下させても、eNB200におけるソフト合成ゲインで補うことが可能である。
・ソフト合成の具体例1
UE100は、繰り返し送信を行う場合に、当該繰り返し送信を行うこと(及び/又は繰り返し送信回数)をeNB200に通知してもよい。これにより、eNB200は、適切なソフト合成を行うことができる。
かかる通知の具体例として、UE100は、Msg3における上りリンクの復調参照信号(DMRS)のパターンにより通知を行なってもよい。DMRSのパターンとは、DMRSの信号系列であってもよいし、DMRSのリソース配置パターン(例えば、リソースエレメントの配置パターン)であってもよい。
UE100は、繰り返し送信を行う場合と行わない場合とでDMRSのパターンを異ならせる。UE100は、繰り返し送信回数に応じてDMRSのパターンを異ならせてもよい。
・ソフト合成の具体例2
繰り返し送信の通知を送信することに代えて、eNB200は、繰り返し送信回数の候補の数だけ受信処理(復号処理)を試行してもよい。ここで繰り返し送信回数の候補はゼロ(すなわち、繰り返し送信を行わない)を含む。
このように、eNB200は、ブラインドデコーディングにより、繰り返し送信されたRRCメッセージ(及び繰り返し送信されたユーザデータ)を総当たりで復号する。これにより、繰り返し送信の通知が無くても、eNB200が適切なソフト合成を行うことができる。
繰り返し送信されたRRCメッセージ(及び繰り返し送信されたユーザデータ)をeNB200がブラインドデコーディングにより復号するために、以下のような方法を適用する。図23Aおよび図23Bは、第2実施形態の動作パターン2に係る繰り返し送信方法の一例を示す図である。
RRCメッセージ(RRC Connection Request)及びユーザデータ(Data)の合計サイズが割り当てデータサイズよりも大きい場合において、UE100は、図23Aに示すように、予め規定された繰り返し送信パターンに従って繰り返し送信を行う。eNB200は、予め規定された繰り返し送信パターンに従ってブラインドデコーディングを行う。
図23Aの例では、上りリンクグラント(UL grant)により割り当てられた割り当てデータサイズは、RRCメッセージ(RRC Connection Request)及びユーザデータ(Data)の合計サイズの2倍よりも大きい。かかる場合、割り当てデータサイズの2分の1のサイズを1単位として、この単位ごとに繰り返し送信を行う。また、割り当てデータサイズの2分の1のサイズに満たない部分についてはパディングデータを配置する。eNB200は、割り当てデータサイズの2分の1のサイズを1単位として、この単位ごとにブラインドデコーディングを行う。
或いは、RRCメッセージ(RRC Connection Request)及びユーザデータ(Data)の合計サイズが割り当てデータサイズよりも大きい場合において、UE100は、RRCメッセージのみを繰り返し送信してもよい。RRCメッセージのデータサイズは既知であるため、eNB200は、RRCメッセージのみが繰り返し送信されていると仮定してブラインドデコーディングを行う。
一方、RRCメッセージ(RRC Connection Request)及びユーザデータ(Data)の合計サイズが割り当てデータサイズよりも小さい場合において、UE100は、図23Bに示すように、予め規定された繰り返し送信パターンに従って繰り返し送信を行う。例えば、割り当てデータサイズがRRCメッセージのデータサイズの2倍以上である場合、UE100は、RRCメッセージの繰り返し送信を行う。UE100は、余りの部分についてはパディングデータを配置する。eNB200は、RRCメッセージのみが繰り返し送信されていると仮定してブラインドデコーディングを行う。
RRCメッセージ(RRC Connection Request)及びユーザデータ(Data)の合計サイズが割り当てデータサイズよりも小さい場合において、eNB200は、RRCメッセージのみが繰り返し送信されているケース、RRCメッセージのみが送信されているケース、及びRRCメッセージと共にユーザデータが送信されているケースの3パターンそれぞれについて復号を試みても良い。
なお、UE100は、どのような繰り返し送信パターンを適用するかを示す情報を、RRCメッセージに付随するMACヘッダ又はMAC CE等によりeNB200に通知してもよい。
(3)動作パターン3
第2実施形態の動作パターン3において、eNB200は、アーリーデータ伝送におけるユーザデータの送信に使用可能な複数のリソースプールを示す情報を例えばSIBによりブロードキャストする。複数のリソースプールは、使用可能な無線リソースの量(すなわち、使用可能なトランスポートブロックサイズ)が互いに異なっている。
UE100は、eNB200からの上りリンクグラントの受信に応じてアーリーデータ伝送を行う際に、複数のリソースプールの中から選択したリソースプールを用いてユーザデータを送信する。これにより、UE100が送信したいユーザデータの量(サイズ)に見合ったリソースプールを選択可能になるため、送信すべきパディングデータをなくす又は削減することができる。なお、eNB200は、各リソースプールにおいてユーザデータの受信(復号)を試みて、いずれかのリソースプールにおいてユーザデータを受信(復号)する。
UE100は、選択したリソースプールを用いてユーザデータ及びRRCメッセージを纏めて送信してもよい。或いは、UE100は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いてRRCメッセージを送信し、その後、選択したリソースプールを用いてユーザデータを送信してもよい。
UE100は、ユーザデータの量に基づいて、複数のリソースプールの中からユーザデータの送信に用いるリソースプールを選択してもよい。例えば、UE100は、eNB200に送信するユーザデータの量(データサイズ)と、各リソースプールに対応するトランスポートブロックサイズとを比較し、最適なリソースプールを選択する。
UE100は、ユーザデータの優先度を考慮してリソースプールを選択してもよい。例えば、選択したリソースプール内で、送信に用いる上りリンク無線リソース(リソースブロック)を選択可能である場合、リソースプールが大きいほど、UE100間のリソースの衝突に起因する干渉が生じる可能性が低い。よって、UE100は、高優先度である場合に、より大きいリソースプールを選択してもよい。或いは、eNB200は、リソースプール毎に、使用可能な優先度情報を通知してもよい。なお、UE100において、優先度は上位レイヤ(例えばアプリケーションレイヤ)で特定され、上位レイヤからAS(例えばRRCレイヤ、MACレイヤ)に通知されてもよい。優先度は、アプリケーションサーバによってUE100に予め設定される、又はMMEなどが認証してUE100に設定してもよい。また、リソースプールは、CEレベル毎に提供されてもよい。
図24は、第2実施形態の動作パターン3の一例を示す図である。図24において、時間方向の1つの区画は1つのサブフレームに相当し、時間方向は上りリンク周波数帯に相当する。
まず、UE100は、SIBを受信することによりユーザデータ用のリソースプール及びランダムアクセスプリアンブル(Msg1)用のリソースプールを把握する。そして、UE100は、図24に示すように、サブフレームSFaにおいて、ランダムアクセスプリアンブル用の複数のリソースプールの中から1つのリソースプールを選択し、選択したリソースプールを用いてランダムアクセスプリアンブルを送信する。図24の例では、ランダムアクセスプリアンブル用のリソースプール#1はユーザデータ用のリソースプール#1(例えば、1000ビットのサイズ)と対応付けられており、ランダムアクセスプリアンブル用のリソースプール#2はユーザデータ用のリソースプール#2(例えば、100ビットのサイズ)と対応付けられている。但し、ランダムアクセスプリアンブル用のリソースプールが1つのみであり、ランダムアクセスプリアンブル用のリソースプールとユーザデータ用のリソースプールとが対応付けられていなくてもよい。
次に、eNB200は、いずれかのリソースプールにおいてランダムアクセスプリアンブルを受信し、このリソースプールの使用を許可する場合にはランダムアクセス応答(Msg2)をUE100に送信する。Msg2は、eNB200がUE100に割り当てた一時的な識別子(Temporary C−RNTI)を含む。UE100は、Msg2を受信した場合、アーリーデータ伝送が許可されたと見なす。そして、UE100は、サブフレームSFbにおいて、ランダムアクセス応答における上りリンクグラントにより割り当てられた上りリンク無線リソースを用いて、RRCメッセージ(Msg3)をeNB200に送信する。UE100は、一時的な識別子(Temporary C−RNTI)をRRCメッセージに含めて送信する。
次に、UE100は、サブフレームSFcにおいて、選択したリソースプールを用いてユーザデータをeNB200に送信する。UE100は、一時的な識別子(Temporary C−RNTI)をユーザデータに含めて送信する。
(4)動作パターン4
第2実施形態の動作パターン4において、eNB200は、ランダムアクセスプロシージャ中に、上りリンク無線リソースを割り当てる上りリンクグラントをUE100に送信する。UE100は、上りリンクグラントに対応する割り当てデータサイズがRRCメッセージ及びユーザデータの合計サイズよりも大きい場合、上りリンク無線リソースを用いてアーリーデータ伝送を行うか、又は上りリンク無線リソースを用いてRRCメッセージのみを送信するか判断する。UE100は、アーリーデータ伝送を行うために必要なパディングデータの量に基づいて、かかる判断を行う。eNB200は、UE100がRRCメッセージのみを送信するケース及びUE100がアーリーデータ伝送を行うケースの両方について受信処理(復号処理)を試みる。
RRCメッセージのみを送信する場合、eNB200がRRCメッセージのデータサイズを把握可能であるため、UE100によるパディングデータの送信は不要である。一方、アーリーデータ伝送を行う場合、すなわち、RRCメッセージと共にユーザデータを送信する場合、eNB200がユーザデータの量を把握していない。このため、割り当てデータサイズでの送信を行うためにUE100によるパディングデータの送信が必要になり得る。
例えば、UE100は、割り当てデータサイズに基づいて、アーリーデータ伝送を行うために必要なパディングデータの量を判定する。判定したパディングデータの量が閾値よりも多い場合、UE100は、パディングデータの送信に起因する消費電力が大きいとみなして、アーリーデータ伝送を行わずに、RRCメッセージのみを送信する。これにより、パディングデータの送信に起因するUE100の消費電力の増加を回避できる。
[その他の実施形態]
第2実施形態と第1実施形態及びその変更例とを組み合わせて実施してもよいし、第1実施形態の変更例1〜15において2以上の変更例を組み合わせて実施してもよい。また、第1実施形態の変更例1〜15は、第1実施形態に係る動作を前提とせずに、変更例に係る動作を単独で実施してもよい。
上述した実施形態及びその変更例において、CP(Control Plane)ソリューション及びUP(User Plane)ソリューションを特に区別していなかったが、実施形態及びその変更例に係る動作をCPソリューション及びUPソリューションの両方に適用可能である。CPソリューションでは、アーリーデータ伝送において、データをRRCメッセージに含める。UPソリューションでは、アーリーデータ伝送において、データをRRCメッセージに含めずに、MACレイヤにおいてデータ(DTCH)とRRCメッセージ(CCCH)とを多重化して送信する。
UPソリューションでは、Msg3に対応するRRCメッセージがRRC Connection Resume Requestメッセージであり、Msg4に対応するRRCメッセージがRRC Connection Resumeメッセージである。通常、UE100は、RRC Connection Resumeを受信すると、PDCPエンティティを確立(再確立)する。しかしながら、アーリーデータ伝送を行う場合、UE100は、RRC Connection Resumeを受信する前に、データ送信を行うためにPDCPエンティティを既に確立(再確立)していると考えられる。よって、UE100は、アーリーデータ伝送を行うためにPDCPエンティティを確立(再確立)した後、アイドルモードからコネクティッドモードへの遷移指示(RRC Connection Resume)をeNB200から受信し得る。この場合、UE100は、PDCPエンティティの確立(再確立)をスキップし、確立済みのPDCPエンティティを維持してもよい。
上述した実施形態において、MTCやIoTを対象とした無線端末(eMTC UE及びNB−IoT UE)を用いる一例を説明した。しかしながら、本開示はeMTC UE及びNB−IoT UEに限定されない。一般的なUEに対して、上述した実施形態に係る動作を適用してもよい。
実施形態では、主にRRCアイドル、サスペンド、コネクテッドを例に挙げて説明したが、これに限らない。RRCライトコネクションやINACTIVEの状態に適用してもよい。RRCライトコネクションは、RRCコネクティッドモードの一状態であって、RRCアイドルモードのプロシージャの一部が適用される特殊な状態である。INACTIVEは、第5世代移動通信システムにおいて導入されることが想定されており、RRCコネクティッドモード及びRRCアイドルモードとは異なるRRC状態である。上述した実施形態における「RRCアイドルモード」を「INACTIVEモード」と読み替えてもよい。
実施形態では強化カバレッジに居るUEを例に挙げて説明したが、これに限らない。ノーマルカバレッジに居るUEに対して、上述した実施形態に係る動作を適用してもよい。具体的には、RACHプロシージャにおいて、RSRP測定に基づくCEレベル判定を行わなくてもよい。
上述した実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、本開示はLTEシステムに限定されない。LTEシステム以外の移動通信システム(例えば、第5世代移動通信システム)に対して、上述した実施形態に係る動作を適用してもよい。
UE100及びeNB200が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD−ROMやDVD−ROM等の記録媒体であってもよい。UE100及びeNB200が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
[付記1]
(1.はじめに)
LTE用のさらに強化されたMTC(eFeMTC)の新しいワークアイテムはRAN#75で承認され、WIDはRAN2が主要なWGとして考慮すべきいくつかの目標を特定する。目的は、BL/CE UEのためのマシンタイプ通信のために以下の改善を指定することである。[...]
改善された遅延:
[...]
・アーリーデータ伝送をサポートする[RAN2主導、RAN1、RAN3]
・少なくともRRCサスペンド/レジュームの場合、ランダムアクセスプロシージャ(PRACH送信後かつRRC接続セットアップが完了する前)中の専用リソース上での電力消費/待ち時間利得の評価及びDL/ULデータ送信の必要なサポートの指定。
この付記では、これらの改善のための検討事項について検討する。
(2.検討)
(2.1.改善されたレイテンシ − アーリーデータ伝送)
WIDは、「少なくともRRCサスペンド/レジュームのケースにおいて、ランダムアクセスプロシージャ(PRACH送信後、RRC接続セットアップが完了する前に)中の専用リソース上の電力消費/待ち時間利得を評価し、DL/ULデータ送信に必要なサポートを指定する」と明確と述べている。アーリーデータ伝送による遅延性能の向上は、さまざまなMTCデバイスの実装を考慮して、追加の電力消費につながる可能性がある。追加の電力消費がいくつかのMTC実装で必要になる場合、UEは、レガシー・ユース・ケースの負担を避けるために、レガシーRACHプロシージャ、すなわち、非アーリーデータ伝送モードを選択することを許可されるべきである。
提案1:アーリーデータ伝送のソリューションは、追加の電力消費を最小限に抑えるべきである。例えば、UEは、レガシーRACHプロシージャ、すなわち「非アーリーデータ伝送モード」を選択することを許可されるべきである。
WIDはまた、アーリーデータ伝送がMsg1の後で実行されるべきであり、Msg5の前に実行されるべきであること、すなわち、拡張の候補がMsg2、Msg3及びMsg4であることを述べている。他方で、何らかの制御シグナリングがMsg2の前やMsg4の後でさえも送信されることが可能であることが期待できる。
提案2:アーリーデータ伝送に関連する制御シグナリングがメッセージ2、メッセージ3、メッセージ4に送信されることが必要とされる必要はない。
アーリー伝送のためのデータが小さなパケット、大きなサイズのデータ及び/又は両方として想定されているかどうかは、WIDにおいて識別されていない。例えば、小さなデータのみが想定される場合、例えば、RACHプロシージャ内であっても、データ送信が完了するとすぐにUEがRRC IDLEに遷移する方が良い場合がある。アーリー伝送のためのデータサイズによってソリューションが異なると考えられる。したがって、RAN2はまずデータサイズの仮定を検討し、決定すべきである。
提案3:RAN2は、アーリー伝送のために仮定されたデータサイズ(すなわち、小さなパケット、大きいパケット、又はその両方)を検討すべきである。
アーリーデータ伝送が、競合ベースのRACHプロシージャ、競合のないRACHプロシージャ、又はその両方においてのみ開始され得るかどうかについては、WIDは明確に言及していない。ソリューションの仮定は、2つのプロシージャ間で異なり、例えば、PDCCH命令が仮定され得るかどうかは異なる。したがって、RAN2は、アーリーデータ伝送のための仮定であるRACHプロシージャを明確にすべきである。
提案4:RAN2は、アーリーデータ伝送が競合ベースのRACHプロシージャ、競合のないRACHプロシージャ、又はその両方に適用可能かどうかを検討すべきである。
図25に、一般的なRACHプロシージャ(競合ベース/フリー)を示す。
(2.2.電力消費の改善−セル再選択のための緩やかなモニタ)
WIDは、「(再)設定によって、セル(再)選択のための軽減されたUEモニタリングを可能にする」と述べている。(再)設定の必要性にかかわらず、固定のUEは、セルの再選択がまれであるため、緩やかなモニタを実行することを許可されるべきである。WIDにおいて意図されたように(再)設定が必要な場合、ネットワークがIDLEモードUEがセル再選択を実行するかどうかを知ることができないので、いくつかのUEアシスタント情報、例えば、セル再選択の報告の数や固定UEインディケーション等が必要になり得る。
提案5:固定UEがセル再選択のための緩やかなモニタ下で動作することが許可されるかどうかを設定可能でなければならない。
[付記2]
(1.はじめに)
RAN2#99はLTE(eFeMTC)のさらに高度なMTCの検討を開始し、アーリーデータ伝送の機能に関する合意は以下のように達成された。
合意事項
制御プレーンとユーザプレーンCIoTEPS最適化のためのMsg3におけるアーリーULデータ伝送をサポートする。
制御プレーン及びユーザプレーンCIoTEPS最適化のためのMsg4におけるアーリーDLデータ送信をサポートする。
合意事項
アーリーデータ伝送機能は、CPを使用してデータを送信するだけのASセキュリティが確立されていない場合に考慮される。
アーリーデータ伝送機能は、CP及び/又はUPを使用してデータを送信するためにASセキュリティが確立されたときに考慮される。
この付記では、アーリーデータ伝送に必要な拡張の詳細について説明する。
(2.検討)
以下のセクションでは、説明を簡単にするために、アーリーULデータ送信及びアーリーDLデータ送信を別々に説明し、既存のランダムアクセスプロシージャをベースラインとみなす。
(2.1.アーリーULデータ伝送)
(2.1.1.Eメールディスカッションの明確化)
UEがMsg3でアーリーULデータ送信を実行しようとする場合、SIBはMsg1で使用される特定のプリアンブルを提供する。換言すれば、SIBが特定のプリアンブルを有するそのようなインディケーションを含まない場合、アーリーULデータ送信は許可されない。
・Msg1は、アーリーULデータ送信がこのランダムアクセスプロシージャにあるかどうかにかかわらず、特定のプリアンブルでUEの意図を含む。
・Msg2は、既存のランダムアクセス応答に加えて、UEの意図が受け入れられるかどうかを示する。
・Msg3は、このランダムアクセスプロシージャ内でデータ送信が完了したかどうか、すなわちUEがRRC Connectedに移行する必要があるかどうかをeNBに通知するためのデータ及び拡張RRC接続(再開)要求を含む。
・Msg4は、RRC Connection Setup/Resume又はRRC Connection Releaseのいずれかである可能性がある。つまり、Msg4でネットワークが応答し、Msg3の受信が競合解消を完了し、必要に応じてNAS PDUを含むことを確認する。
eNBの観点からは、SIBがアーリーULデータ送信が許可されているか否か、すなわちUp−CIoT−EPS−最適化などのようなSIBインディケーションが最小限であることを示すことが必要である。次に、UEは、eNBにアーリーULデータ送信を使用する意図を示すために、メッセージ1に特定のプリアンブルを含めることができる。しかしながら、たとえUEがMsg1に特定のプリアンブルを含むとしても、eNBはアーリーULデータ送信を拒絶する必要がある他の理由があるかもしれないので、アーリーULデータ送信を受け入れるかどうかを決定する選択肢を依然として有するべきである。これは、Msg2を介してUEに伝えられてもよい。したがって、アーリーULデータ送信が承認される前に2段階の許可が必要である。
提案1:RAN2は、SIBに提供された特定のプリアンブルをMsg1に送信してeNBに対してMsg3におけるアーリーデータ伝送を行う旨を通知し、eNBはMsg2においてアーリーデータ伝送が許容可能である否かを通知することに合意すべきである。
アーリーデータ伝送の主な目的の1つは、UEの電力消費を低減することであるので、データ送信が完了するとすぐに、UEはIDLEに解放されるべきである。RAI(Release Assistance Indication)は、この目的のために再利用可能である。一方、送信されるデータパケットが小さく、Msg3の制限されたサイズ内で完全に送信されることができる場合、UEはRRC接続に移行する必要がないと想定される。UEがそのようなコネクションレスデータ送信を要求することが許可されている場合、その要求は以下のオプションの1つを用いてeNBに伝達される必要がある。
オプション1a:RRC Connection Resume RequestのRRC Connection Request及び/又はResume CauseのEstablishment Causeにspare1を設定する。
オプション1b:RRC接続要求及び/又はRRC接続復旧要求にスペアIEがある。
オプション1c:Msg3にRAI(つまり、BSR=0)を指定する。
オプション1d:新しいRRCメッセージ、例えば、RRC Connection−less Request。
オプション1a〜1cは、オプション1dより仕様の影響が少ない。シグナリングオーバーヘッドの観点からは、オプション1aと1bはオプション1cと同じであるが、オプション1よりも優れている。技術的な意味合いでは、オプション1bはオプション1aよりも柔軟性がある。アーリーULデータ伝送は一般に確立/再開の原因には関連していないため、特に今後のリリースでの潜在的なニーズを考慮している。従って、オプション1bが好ましい。
提案2:RAN2は、ULデータ送信がMsg3内で完了したかどうかをeNBに通知するために、RRC接続(再開)要求に1ビットインディケーションを含めることに合意すべきである。
(2.1.2.再送方式)
WIDは、アーリーデータ伝送が専用のリソース上で実行されると述べている。
アーリーULデータ伝送のためのRAN2の現在の合意が実際に専用リソースでサポートされているかどうかをさらに検討すべきである。RAN2は、Msg3リソースがMsg2内の専用ULグラントによって割り当てられる「Msg3におけるアーリーULデータ送信」に合意した。現在のMsg3は、最終的にUL−SCHを介してPUSCHにマッピングされるCCCH論理チャネルを介してRRC接続要求又はRRC接続復旧要求のいずれかを搬送するが、UE間の物理リソースの競合は未解決である。アーリーULデータ送信は、IDLEのUEに対してのみ、すなわち競合ベースのランダムアクセスプロシージャでサポートされる。
考察1:Msg3では、競合はRACHプロシージャに基づいて解決されない。
Msg3では、競合が解決されていないので、複数のUEからより多くのUL干渉が予期される。言い換えると、Msg3における初期ULデータの受信エラーが発生する可能性がある。アーリーULデータ送信がうまく受信されない場合、UEが何をすべきか、すなわちeNBによってうまく受信されなかったULデータを再送する方法は依然として不明である。
提案3:RAN2は、UEがeNBによってデータが正常に受信されなかった場合、UEがアーリーULデータをどのように再送すべきかについて検討すべきである。
提案3が納得のいくものである場合、再送スキームの4つのオプションが考慮される。
オプション2a:UEは、Msg1からのランダムアクセスプロシージャを再開する。すなわち、前のプロシージャはキャンセルされる。
オプション2b:UEは、失敗したデータ、すなわち「Msg3におけるアーリーULデータ再送信」を伴うMsg3を再送信することができる。
オプション2c:UEは、Msg5で失敗したデータを再送信することができる。つまり、データだけが失敗した場合である。
オプション2d:UEは、RRC接続後にのみ、失敗したデータを再送することが許可される。
オプション2aは、現在の仕様、すなわち、Msg3バッファをフラッシュし、ランダムアクセスリソース選択から再開するように調整される。オプション2aを使用しても、アーリーULデータ再送信のためにレガシーバックオフ時間又は新しいバックオフ時間を適用するかどうか、及び再送信回数に制限があるかどうかは不明である。オプション2bはオプション2aに従うことができ、すなわち、UEは、次のMsg3タイミングで失敗したデータを含む。オプション2cは、同じMCSが適用されていると仮定して、RRC接続(再開)要求が正常に受信されている間にデータが受信されなかった可能性が低いため、まれなケースである。オプション2dは、失敗したデータの再送信が許可されていることを除いて、現在の仕様と一致している。
提案4:RAN2は、アーリーULデータ送信に失敗した場合、UEは(現在のように)ランダムアクセスプロシージャを再開し、次のMsg3のデータを再送することが許可されるべきであることに合意すべきである。
いずれにしても、UEは、Msg3バッファがフラッシュされても、受信成功の確認までアーリー伝送のためのデータを維持すべきである。
(2.2.DLアーリーデータ伝送)
(2.2.1.Eメールディスカッションの考察)
Eメールディスカッションでは、アーリーDLデータ送信とアーリーULデータ送信の両方について共同で検討したため、DLの側面は詳細には考慮されていない可能性がある。次のセクションでは、そのような詳細について説明する。
(2.2.2.アーリーDLデータ伝送のUEのサポート)
RAN2は、RRC Connection Setup/Resume/Releaseに加えてMsg4でデータを受信する必要がある、Msg4でのアーリーDLデータ送信をサポートすることに合意した。しかし、eNBは、UEがアーリーDLデータ受信が可能であるかどうか、特に中断されていないだけでなく、中断されていないUEについて、常にUEが知ることができるのは疑問である。両方のCIoTEPSCP/UP最適化のための統一されたソリューションを考慮して、UEはアーリーDLデータを受信できるかどうかをNW、すなわちeNB又はMMEに通知することができる。
提案5:RAN2は、アーリーDLデータ受信をサポートするか否かをUEがNWに通知すべきであることに合意すべきである。
eNBの観点から、UEの能力をNW、すなわちMME又はUEに伝達するための2つの選択肢がある。MMEがeNBに通知する場合、いくつかのS1メッセージが、PAGING又はINITIAL CONTEXT SETUP REQUESTなど、エンハンスされる必要があることは明らかであり、RAN2はRAN3と議論すべきである。一方、UEがeNBに通知する場合、いくつかのオプションが以下のように考えられる。
オプション3a:UE能力のアーリーDLデータ受信のために新しいIEが追加される。
オプション3b:UEがアーリーDLデータ受信をサポートする場合、Msg1又はMsg3でインディケーションが送信される。
オプション3aは、UEの能力をeNBに提供する簡単な方法であるが、eNBは、Msg4の後にUEが転送されるので、UEがもはや接続中又は中断中でなくてもコンテキストを保持する必要がある。オプション3bは、「ハンドシェイク」の一種であるため、UEは、DLデータ受信が開始される前に、すなわちページング又はMsg2において、アーリーDLデータ受信が意図されているかどうかを知る必要がある。
提案6:RAN2は、UEがアーリーDLデータ受信をサポートしているかどうか、すなわちUE又はMMEによってeNBがどのように通知されるかを検討するべきである。
提案6にかかわらず、UEは、それが起こる前にアーリーDLデータ受信をセットアップする必要があるかどうかを知る必要がある。
提案7:RAN2は、アーリーDLデータ受信が必要であるかどうかをUEがページング又はMsg2で通知されるべきであることに合意すべきである。
(2.2.3.再送方式)
アーリーDLデータ送信が専用/非競合リソース、すなわちMsg4上で実行されると仮定する。しかし、そのようなリソースでも受信エラーが発生するため、UEの動作を明確にする必要がある。アーリーDLデータ送信がページング又はMsg2、すなわち提案7に示されると、UEがMsg4上で送信されるデータをモニタすることは簡単である。提案4と同様に、DLデータがUEによって受信されなかった場合のDLデータの再送信の手段が必要である。
提案8:RAN2は、Msg4が受信されなかった場合、Msg4に対してアーリーDLデータ再送信が実行されることに合意すべきである。
(2.2.4.同時のアーリーUL/DLデータ送信)
単一のランダムアクセスプロシージャの中でアーリーデータ伝送がULとDLの両方で同時にサポートされるべきかどうかは依然として不明である。一般に、ULデータ送信は、次のDLに対して上位レイヤ確認応答を必要とし、その逆、例えばTCP ACKを必要とすることがある。UEがMsg3でULデータ送信を送信することを決定した後に、1つのランダムアクセスプロシージャ内でMsg4におけるDLデータ受信として確認応答を送信することが可能であるかもしれない。Msg4のDLデータ送信には同じプロシージャでMsg3を続けることはできません。ULデータ送信としての上位レイヤ確認応答は、次のランダムアクセスプロシージャで発生する次のMsg3で送信されなければならないか、又はUEはRRC接続に移行することもできるが、それはアーリーDLデータを送信する目的を否定する。
しかし、そのような上位レイヤの確認応答にどれだけの遅延が必要かは不明である。上位レイヤ往復がランダムアクセスプロシージャ内で行われ、上位レイヤの肯定応答が遅れた場合、UEはMsg3送信後にMsg4を長時間モニタし続けることができ、これによりUEの不要な電力消費が引き起こされる。したがって、1回のランダムアクセスプロシージャでアーリーULデータ送信又はアーリーDLデータ送信がサポートされることは合理的である。
提案9:RAN2は、1つのランダムアクセスプロシージャがただ1つのアーリーデータ伝送、すなわちアーリーULデータ送信又はアーリーDLデータ送信のいずれかをサポートすることに合意すべきである。
[付記3]
(1.はじめに)
RAN2#99bisは、以下のように多くの合意を得てEarly Data Transmission(EDT)機能の重要な進展を達成した。
合意事項
・PRACHパーティショニングは、Msg3においてアーリーデータ伝送を使用するUEの意図を示すために使用される。下位互換性は保持される。更なる検討が必要:PRACHプールに関する詳細、例えば、PRACH分割のプリアンブル/時間/周波数/キャリアドメイン。
・UL EDTプロシージャ中のCPに関して、UEがデータが適合しないグラントを受信した場合、UEはMsg3のデータを送信しない。UPソリューションの場合、グラントがULデータサイズよりも小さい場合は、EDTグラントがULデータに使用できるかどうかは更なる検討が必要である。
・認証メカニズムを導入する必要があるかどうかは更なる検討が必要である。
・Msg3の最大グラントサイズは、CEごとにブロードキャストされる。UEがPRACHパーティショニングを介してMsg3に必要なグラントサイズを示すかどうかは更なる検討が必要である。
・LSをRAN1に送信し、PUSCH伝送用の従来のTBSテーブルがEDTに使用されていると仮定していることを示す。
・Msg4は、UEがRRC接続モード又はRRCアイドルモードに移行するかどうかを決定する。EDTのMsg4の内容は更なる検討が必要である。
・EDTを使用する意図は、データ、すなわちNASシグナリングのためではない。
・レガシープロシージャのMsg5に含まれる以下のパラメータのいずれかがMsg3 for EDTに含まれるべきかどうかLSをRAN3/SA2/CT1に送る:selected PLMN−Identity、registered MME、gummei−Type、attach Without PDN−Connectivity、up−CIoT−EPS最適化、cp−CIoT−EPS最適化、dcn−ID。
・RAN2は、CPに対するS−TMSIを仮定し、UPソリューションについてのresumeID及びshortResumeMAC−1は、それぞれMME及びeNBでUEを識別するのに十分である。我々は、この仮定をLS.toRAN3、SA2、SA3、CT1に提供する。
・CPソリューションのために、データ用のNAS PDUは、Msg3で送信されたRRCメッセージにカプセル化され、CCCH SDUとして送信される。
・UPソリューションの場合、SRB0はMsg3でRRCメッセージを送信するために使用される。
・UPソリューションでは、Msg3のMACにCCCH(RRCメッセージ)とDTCH(UPデータ)が多重化されている。
・UPの場合、ASセキュリティはMsg3を送信する前に再開され、Msg3で送信されるデータはASセキュリティによって保護される。
・CPソリューションの場合、DL内のNASPDUデータは、Msg4で送信されたRRCメッセージにカプセル化され、CCCHSDUとして送信される。
・UPソリューションの場合、DLデータは、Msg4内のMAC、すなわちDCCH(RRCメッセージ)及びDTCH(UPデータ)に任意に多重化することができる。
・更なる検討が必要:UPソリューションの場合:固定接続の場合、つまりCCCH(RRC Connection Resume Req)+DCCH(固定接続によるNAS PDU)
この付記では、EDTの基本機能を完成させるための残りの課題について検討する。
(2.検討)
(2.1.ユースケース)
検討の間、EDTプロシージャは、例えば、上位レイヤのセンサデータについてはUL EDTによって開始され、対応する上位レイヤACKについてはDL EDTによって終了するという共通の理解のように見える。すなわち、上位レイヤの往復はEDTプロシージャ内で行われる。
他方、ULのみのEDTプロシージャ及び/又はDLのみのEDTプロシージャは、いくつかの場合にも有用である。(より多くの比較については図26を参照。図26は、EDTのプロシージャを示す。)
・UDPタイプのデータ送信、すなわち、上位レイヤのACKなし。
・上位レイヤの往復での遅延が長い、すなわち、上位レイヤのACKが応答する前にある時間を必要とする。
・アプリケーションサーバからデバイスへのコマンド、つまり通信はDLによってトリガされる。
「CPソリューションの場合、DL内のNAS PDUデータは、Msg4で送信されたRRCメッセージにカプセル化され、CCCH SDUとして送信されることができる」、「UPソリューションの場合、DLデータは、Msg4においてMAC、すなわちDCCH(RRCメッセージ)及びDTCH(UPデータ)に任意に多重化されうる。すなわち、UEはデータなしでMsg4を受信することができる。」と合意されているため、ULのみのEDTプロシージャがサポートされていると考えられる。
考察1:現在の合意事項では、ULのみのEDTプロシージャがサポートされている。
一方、現在の合意事項ではDL−only EDTプロシージャのサポートは依然として不明である。DL−EDT伝送の可用性は、UEの観点からMsg4を受信するまで知ることができず、DL EDT受信の能力は不可能であったため、想定されるUL EDT対応UEがDLE DTもサポートしている場合、eNBの観点からUL EDTなしで通知される。したがって、DLのみのEDTプロシージャがサポートされている場合、さらなる検討はいくつかの拡張、例えばページングにおける通知に取り組むべきである。
注:UL EDT機能が可能なUEはDL EDT機能も可能であると仮定している。
提案1:RAN2は、DL専用のEDTプロシージャがサポートされているかどうかについて検討すべきである。
(2.2.EDTインディケーションの詳細)
RAN2#99bisでは、「PRACHパーティショニングは、Msg3でアーリーデータ伝送を使用するUEの意図を示すために使用されている。下位互換性は保持される。更なる検討が必要:PRACHパーティショニングのプリアンブル/時間/周波数/搬送波ドメインなどのPRACHプールに関する詳細」及び「Msg3の最大可能グラントサイズはCEごとにブロードキャストされる。UEがPRACHパーティショニングを介してMsg3に必要なグラントサイズを示す場合、それは更なる検討が必要である。」と合意された。
Eメールディスカッションでは、更なる検討が必要、すなわちMsg1とPRACHパーティショニングの詳細に関する追加情報について説明した。Msg1に関する追加情報に関しては、EDTインディケーションがCEごとに設定されているが、UEカテゴリは必要ではないという意見が大半を占めているようである。EDTインディケーションに関する合意はないが、これは将来の拡張である可能性がある。
提案2:RAN2は、Msg1のEDTインディケーションがCEごとに設定され、Msg1のグラントサイズインディケーションが将来の拡張として考慮されるべきであることに合意すべきである。
PRACH分割の詳細については、ソフトパーティショニング(又は非専用PRACHリソース)とハードパーティショニング(又は専用PRACHリソース)の2つの方向が示唆された。特に、NB−IoTの一部の導入シナリオでは限られたリソースの場合に、PRACHの性能低下を引き起こす可能性があるため、PRACHフラグメンテーションが許容可能かどうかが問題である。
たとえば、最適化されていないNWでPRACHリソースをソフトパーティショニングで共有することにはいくつかの利点があるが、パーティショニングの数はハードパーティショニングと変わりない。例えば、ハードパーティショニングの場合、3つのレガシーCEレベル、3EDT 3CEレベルのために、PRACHリソースには6つのパーティションが必要である。ソフトパーティショニングの場合、6つのPRACHスペース(3つのCEレベルx2つの異なるプリアンブル)も必要である。これは、物理的な踏み外しがないこと、すなわち、UEをどのように分離するかという違いがあることを意味する。
注:ハードパーティショニングでは、eNBがレガシーPRACHリソースとEDT Indication PRACHリソースを重複リソースで設定する場合、共有PRACHリソースが可能になる。
したがって、我々の見解では、分割方法(例えば、ソフト又はハード)にかかわらず、専用又は非専用リソースのいずれに関係なく、最適化されたNWにおいてPRACH性能は最終的には類似している。
考察2:PRACHのパフォーマンスは、最終的にEメールディスカッションで提案されたソリューション間で類似している。
これまでEメールで検討されていなかった代替ソリューションとして、UEからの複数のPRACH送信を定義してレガシーPRACHとUL−EDT PRACHを区別できるかどうかを検討する必要もある。例えば、UEは、レガシー目的(すなわち、CEレベルの決定)のための第1のPRACHを送信し、EDTインディケーションのための第2のPRACH(すなわち、EDTが第2のものを送信することを要求するUEのみ)を送信する。eNBは、各PRACHショットの2つのPRACHスペース上でブラインドデコードを実行することができる(図27参照。図27は、複数のPRACH送信によるEDTインディケーションを示す)。2つのPRACHは同じサブフレーム上で送信することができる。このアプローチでは、レガシーUEは現状のように最初のPRACHのみを送信するため、4つのPRACHリソース(最初のPRACHでは3つのCEレベル、2つ目は1つのEDTインディケーション)が必要である。しかしながら、このソリューションの欠点は、明らかにUEが追加のPRACH送信を必要とすることであり、それによって追加の電力消費が生じるが、PRACH性能低下(例えば、衝突)による電力消費に類似し得る。
提案3:RAN2は、1つの追加のPRACH空間を有する複数のPRACH送信がEDTインディケーションに有用であるかどうかを検討すべきである。
提案4:提案2と提案3が合意に達すると、RAN2は後でグラントサイズインディケーションが追加のPRACH空間にマッピングされるかどうか検討すべきである。
(2.3.EDTの失敗事例)
(2.3.1.ULグラント障害(Msg1/Msg2))
RAN2は、「ULEDTプロシージャ中のCPに関して、UEがデータ適合しないグラントを受信した場合、UEはMsg3のデータを送信しない。UPソリューションの場合、グラントがULデータサイズよりも小さい場合、EDTグラントがULデータに使用できる場合は更なる検討が必要である。」と合意した。少なくともCPソリューションの場合、UEがMsg1にEDT Indicationを送信しても、eNBはMsg2上のレガシーサイズULグラントを持つEDTプロシージャを拒否することがある。それはEDTプロシージャの観点からは失敗事例とみなすことができる。
考察3:少なくともCPソリューションの場合、ULグラントがデータサイズに適合しない場合、EDTプロシージャは失敗する。
現在の合意は、データがMsg3上で送信できるかどうか、すなわち、ULグラントが予想よりも小さい場合にUEが何をすべきかについて言及していないという状態のみを言う。したがって、失敗時のUEの動作は、例えばテストのために特定されるべきである。いくつかのオプションは次のように考慮する必要がある。
オプション1:UEは、レガシーMsg3(すなわち、データなし)を送信する。
オプション2:UEは、EDTプロシージャを再試行することができる(すなわち、Msg1から開始する)。
オプション1は、検討の最中に私たちの印象からのベースラインかもしれない。オプション2は、現在の動作と幾分異なる。すなわち、対応するULグラントを受信しても、UEはPUSCH送信をスキップする。しかし、EDTは新しい機能であるため、例えば、eNBがこの機能を許可する場合にのみ、オプションでオプション2を導入して、不要なUEの電力消費を最小限に抑えてRRC接続に移行させることを検討する価値がある。
提案5:RAN2は、少なくともCPソリューションのために、ULグラントサイズがUL EDTに十分でない場合、UEがレガシーMsg3を送信することに合意すべきである。
提案6:RAN2は、ULグラントサイズが十分に大きくない場合に、UEがEDTインディケーションを再送することを任意に許可されているか否かを検討すべきである。
(2.3.2.受信失敗(Msg3/Msg4))
EDTプロシージャにおけるデータの受信失敗の処理方法については検討されていない。
これまでのUL EDTの検討では、UEの挙動は、UEがMsg4を受信する場合のみを想定していたが、UEがMsg4を受信しない場合には何が起こるかはまだ明確ではない。いくつかのオプションが検討されたが、UEが現在のランダムアクセスプロシージャに従う、すなわちランダムアクセスリソース選択から再開することにより、UL EDTもまた再試行されることがより簡単であり得る。
提案7:RAN2は、現状のように、競合解決が成功しなかったと考えられる場合、UEがランダムアクセスリソース選択からランダムアクセスプロシージャ(及びUL EDTプロシージャ)を再開することに合意すべきである。
競合解決が成功しなかったと考えられるときに、現在HARQバッファがフラッシュされているので、再送信のためのデータが格納される場所について検討すべきである。CPソリューションの観点からは、トラフィックデータは、RRCメッセージ内にNAS PDUとしてカプセル化される。データ伝送が首尾よく完了するまで、トラフィックデータをRRCレイヤにカプセル化することが可能である。一方、UPソリューション策の観点から、DTCH上のトラフィックデータはMACレイヤに多重化されているので、トラフィックデータはRRCレイヤに格納されず、ユーザプレーンレイヤの1つに格納される。競合解決が成功しなかったとみなされても、CP及びUPに対する共通のUE動作を有するという観点から、MACレイヤは、HARQバッファをフラッシュしてはならない。
考察4:RRT又はMACで、UL EDTが正常に完了するまでどのレイヤにデータが格納されているかは不明である。
提案8:RAN2は、MACレイヤがUL EDTにおけるデータ再送信を処理することに合意すべきである。
DL EDTでは、Msg4の受信失敗がHARQフィードバックによって示される。したがって、データの再送信は、現在のHARQ再送信に単に従うことができる。
提案9:RAN2は、現在と同じように、Msg4 HARQ再送信を介してDL EDT再送信が実行されることに合意すべきである。
(2.3.3.T300及び競合解決タイマ障害(Msg3/Msg4)
現在の仕様では、RRCのMsg3とMsg4の間に2つのタイマ(T300とMACのmac−Contention Resolution Timer)がある。T300の値は、LTEでは100ms〜2000ms、NB−IoTでは2500ms〜60000msである。mac−Contention Resolution Timerの値は、LTEではsf8〜sf64、NB−IoTではpp1〜pp64である。これらのタイマが満了すると、UEは、RRC接続確立/再開又は競合解決がそれぞれ成功していないとみなす。
UL EDTがセンサデータ伝送用であり、DL EDTがTCP ACK用である場合(図26の「完全EDTプロシージャ」)、EDTプロシージャにおけるMsg4伝送は、上位レイヤでの往復時間に依存し、従来のMsg4よりも遅れている可能性が高い。したがって、不要なエラーを防ぐために、より長いタイマ値を定義するのは簡単である。
提案10:RAN2は、Msg3上のUL EDTとMsg4上のDL EDTの間で動作するタイマのより長い値を定義する必要がある。
しかし、それは、Msg4の受信まで連続的なPDCCHモニタのために追加のUE電力消費を引き起こす可能性がある。したがって、DRTのような受信モードをEDTプロシージャに導入する必要がある。
提案11:RAN2は、EDTプロシージャにおいて(すなわち、Msg3送信からMsg4受信までの間に)不連続受信が許容されるかどうかを検討すべきである。
さらに、eNBがタイマ値をどのように設定するかは疑問がある。なぜなら、上位レイヤメッセージのためにTCP ACKが返ってくるときは分からないからである。セル内に様々なアプリケーションを実装しているUEが多数存在すると想定されているので、すべてのUEに対して適切なタイマ値を設定することは困難であるように思われる。
1つの可能性はMsg2の専用設定であるが、アプリケーションレイヤの知識なしにタイマ値を決定することはまだ困難である。一方、UEは、上位レイヤにおけるタイムアウト設定に基づいて適切なタイマ値を設定するのを助けることができる。例えば、UEは、Msg3上の自己設定タイマ値をeNBに通知することができる。
提案12:RAN2は、UEがMsg3上の自己設定タイマ値をeNBに通知することを許可されているかどうかを検討すべきである。
提案10〜提案12のいずれかが好ましい場合、EDTのためのタイマの概念はレガシータイマとは異なる。また、EDT可能なUEが、例えば、より大きなパケット送信のためにレガシーRRC接続確立/再開を開始することも可能であり、これにより、レガシータイマがこの場合に適用可能である。したがって、EDTのタイマがレガシータイマを再使用するか、新しいタイマを定義するかについて検討する価値はある。
提案13:RAN2は、EDT用のタイマがレガシータイマを再利用するのか、新しいタイマを定義するのかについて検討すべきである。
図28に、上位レイヤのラウンドトリップ時間による遅延を示す。
(2.4.承認メカニズム)
議長メモでは、「承認メカニズムを導入する必要があるかどうかは更なる検討が必要である」。このような承認メカニズムはEメールディスカッションでは範囲外であった。
我々の理解では、EDTはASの機能性であり、NWやUEの立場ではコストがかからない(CEとは異なる)。さらに、NWは、PRACH分割パラメータ及び/又はSIBからの可能な最大グラントサイズを除去することによって、EDT機能を常に無効にすることができる。したがって、認証メカニズムを導入する技術的な理由はない。
提案14:RAN2は、EDTの認証メカニズムが不要であることに合意すべきである。
[付記4]
(1.はじめに)
RAN2#100は、Msg1上のEarlyDataTransmission(EDT)インディケーションの詳細を検討し、以下の合意を達成した。
合意事項
・UEは、UEが送信しようとするユーザデータを含むMsg3のサイズがCEあたりのMsg3ブロードキャストの最大可能TBSサイズと等しいかそれよりも小さい場合、Msg1でEDTを開始する。
・拡張されたカバレッジレベルごとに、EDTインディケーション用のPRACH区分化が設定される。
・作業の前提:このケースのセグメンテーションのサポートは優先されない。
・動作仮定:CEごとのレガシー又は最大TBSブロードキャスト以外の意図されたデータサイズを示すために、PRACHリソース分割はサポートされない。
・Msg3でのパディング問題の解決方法
・UEカテゴリはMsg1に示されない。
・EDTインディケーションのために、PRACHリソースは、物理レイヤリソース、プリアンブル/サブキャリアに関してレガシーeMTC又はNB−IoTのように設定することができる。
・EDACHインディケーションのためのPRACHリソースプール、すなわち物理レイヤリソース、プリアンブル/サブキャリアは、レガシーRACHプロシージャのためのPRACHリソースプールとは別個である。
パディングの問題にどのように対処するかについて、更なる検討が必要として認識された。この問題は、ULEDTのためのULグラントが、UEが送信しようとするデータサイズが不一致である場合に発生する。問題の詳細は、対応するEメールディスカッションに詳しく記載されている。
この付記では、Eメールディスカッションの補足説明が提供されている。
(2.検討)
パディング問題の解決法は、Eメールディスカッションで以下のように提案され、要約されている。
上記のパディング問題に関する以下のソリューションが提示された。
1.(N)PRACHパーティショニング。ここで、UEは、Msg1を使用するEDT Msg3のための意図されたデータサイズ/TBSを示す。
2.ネットワークは、複数のトランスポートブロックサイズと、ULグラント情報の組み合わせとを提供する。UEがMsg3における意図されたデータ送信を考慮して選択するためのRARメッセージ内のRU、PRB、繰り返し回数
3.ネットワークは、Msg3送信のために二重(又はそれ以上)のグラントを提供する。
4.Msg1とのデータサイズの表現とRARの柔軟なグラントの組み合わせ。
5.パディング領域でのMAC SDU又はPDUの繰り返し(この解決方法の詳細は不明であるが、より良い理解のために詳細に説明する)
6.複数の「CEあたりの最大TBSブロードキャスト」に関連するMsg3送信用の複数の共通ULリソースプールなどの暗黙的な割り当て(この解決方法の詳細は不明であるが、より良い理解のために詳細に説明する)。
7.UPのみ:レガシーMsg3伝送用のパディングを避けるためのセグメンテーション。
(2.1.ソリューション5(MAC PDUの反復))
このソリューションは、冗長機会としてパディング領域を使用する。換言すれば、サブフレーム上の既存の反復スキームは、送信内で行われる。例を図29と図30に示す。図29は、ULグラントが意図したデータサイズより大きい場合を示す。図30は、ULグラントが意図したデータサイズより小さい場合を示す。
1つの可能性は物理レイヤであるが、どのレイヤ内のエンティティが追加の冗長性プロセスを実行するのは更なる検討が必要である。例えば、UEは、MACPDUからビット列を生成し、循環バッファに格納し、ULグラントサイズに従ってビットを送信する。
長所と短所は次のように予想される:
長所:パディングビットの送信と比較して、反復を補償するためにRxソフト合成利得及び/又はTx電力低減の可能性。
短所:繰り返しが物理レイヤで処理される場合、RAN1の影響がある可能性がある。
(2.2.ソリューション6(共通のULリソースプール))
このソリューションは、EDTのための共通のULリソースプールを提供し、それにより、リソースプールは、モード2/タイプ1サイドリンク送信、すなわち複数のUEによって使用される共通リソースに類似する。レガシーMsg3リソースは、(現状のように)ULグラントによって常に提供されると仮定することができるが、UEは、レガシーMsg3で使用される同じ一時C−RNTIを有する共通リソースプールを使用してデータ部分を送信することができる。共通リソースプールの設定は、SIBで提供されている。このソリューションは、複数のUL許可ソリューションの「半静的」バージョンと見なすことができ、それによって、データを対象とする第2のグラントリソースが複数のUEによって共有される。
図31に、UL送信用の共通リソースプールを示す。
長所と短所は次のように考えられる。
長所:Msg2への変更は必要ない。UEは、サイドリンクのような送信を仮定して、(サイズが共通リソースを超えない限り)パディングなしでデータを送信することができる。EDTがIDLEモードプロシージャであると考えると、Mode2/Type1リソースの場合と同様に、共通リソースの使用も合理的である。これは、Msg2が変更される必要がないという考えを再び強調している専用シグナリングなしでリソースを割り当てることができることを意味する。
短所:共通リソースを使用すると衝突が発生する。
[付記5]
(1.はじめに)
RAN2#100は、EDT機能の見通しを形成するために達成された。しかし、詳細についてはまだ多くの更なる検討が必要であり、そのうちの1つは以下の通りである。
合意事項
CPソリューション
[...]
・T300とmac−contention Resolution Timerの変更が必要かどうかは更なる検討が必要
この付記において、タイマの側面のさらなる考察が検討される。
(2.検討)
(2.1.前提)
検討の間、EDTプロシージャはUL EDT、例えば上位レイヤのセンサデータで開始され、DL EDT、例えば対応する上位レイヤACK、すなわち上位レイヤの往復で終了するという共通の理解であると思われる、EDTプロシージャ(すなわち、図26の「完全EDTプロシージャ」を参照)内で行われる。
考察1:一般的なEDTプロシージャには、UL EDTとDL EDT(ランダムアクセスプロシージャ内)が含まれている。
他方、ULのみのEDTプロシージャ及び/又はDLのみのEDTプロシージャは、以下の場合にも有用である(図26を参照)。
UDPタイプのデータ送信、すなわち、上位レイヤのACKなし。
上位レイヤの往復でより長い遅延、すなわち、上位レイヤのACKは、応答の前に一定の時間を必要とする。
アプリケーションサーバからデバイスへのコマンド、すなわち通信はDLによってトリガされる。
Msg4のDLデータは、CP/UPに関係なく、「CPソリューションの場合、DL内のNAS PDUデータは、Msg4で送信されたRRCメッセージにカプセル化されていても、オプションでカプセル化されていてもよいため、CCCH SDUとして送信され、UPソリューションの場合、Msg4のMAC(すなわち、DCCH(RRCメッセージ)及びDTCH(UPデータ))でDLデータを任意に多重化することができる。
考察2:ULのみのEDTプロシージャは、現在の合意事項に基づいてサポートされている。
一方、DL−EDT伝送は、Msg4を受信するまでUEがDL EDT伝送が発生するかどうかを知らず、eNBはUEのDL EDT能力を知らないので、現在の合意事項に基づいて、DL−onlyEDTプロシージャのサポートは依然として不明である。
提案1:RAN2は、DL専用のEDTプロシージャがサポートされているかどうかについて検討すべきである。
(2.2.T300及び競合解決タイマ)
(2.2.1.Msg4遅延の問題)
現在の仕様では、RRCのMsg3とMsg4の間に2つのタイマ(T300とMACのmac−Contention Resolution Timer)がある。T300の値は、LTEでは100ms〜2000ms、NB−IoTでは2500ms〜60000msである。mac−ContentionResolutionTimerの値は、LTEではsf8〜sf64、NB−IoTではpp1〜pp64と異る。これらのタイマが満了すると、UEは、RRC接続確立/再開又は競合解決がそれぞれ成功していないとみなす。これらの既存のタイマがEDTの下で期限切れになる場合、UEの動作がどのようにすべきかは依然として決定されていないが、現在のランダムアクセスプロシージャがEDTプロシージャのベースラインであることも事実である。したがって、タイマに関してさらに考慮する必要がある。
センサデータがUL EDTを介して送信され、対応するTCP ACKがDL EDTを介して送信される場合(すなわち、図26の「完全EDTプロシージャ」を参照)、EDTプロシージャにおけるMsg4送信は、おそらく従来のMsg4それは上位レイヤからの往復時間に依存する。
考察3:Msg3とMsg4の間の持続時間は、上位レイヤからの往復時間のために、最大レガシータイマを超える可能性が高い。
したがって、不要な障害を防ぐために、より長いタイマ値を定義するのは簡単である。
提案2:RAN2は、Full EDTプロシージャのために、Msg3上のUL EDTとMsg4上のDL EDTとの間で動作するタイマのより長い値を定義すべきである。
(2.2.2.Msg4受信用のDRX)
提案2が納得のいくものであれば、既存のT300とmac−Contention Resolution Timerのタイマ値を拡張するのは簡単である。しかし、これは、Msg4の受信まで連続的なPDCCHモニタリングのために追加のUE電力消費を引き起こし、それによってMsg4は前のセクションで説明したようにEDTで遅延することがある。このような不必要な電力消費を避けるために、何らかの種類のDRXのような受信モードがEDTプロシージャに導入されるべきである。
例えば、簡単なソリューションのために、UEは、タイマが満了する直前のサブフレーム、すなわち「ワンショット」モニタリングにおいてのみ、PDCCHをモニタすることができる。高レイテンシ通信のようないくつかのMTC/NB−IoTユースケースでは、連続モニタリングよりもうまくいく可能性がある。
提案3:RAN2は、EDTプロシージャにおいて(すなわち、Msg3送信からMsg4受信までの間に)不連続受信が許容されるかどうかを検討すべきである。
(2.2.3.タイマ値の設定)
さらに、eNBがタイマ値をどのように設定するかは疑問がある。なぜなら、TCP ACKが上位レイヤのメッセージから到着するとき、eNBには未知であるからである。セル内に様々なアプリケーションを実装する多数のUEが存在すると仮定して、eNBがすべてのUEに対して適切なタイマ値を設定することは困難である。
考察4:異なるUEが異なるアプリケーションを使用する可能性があることを考慮して、適切なタイマ値を設定することは困難である。
1つの可能性は、Msg2の専用シグナリングを使用してタイマを設定することであるが、eNBでアプリケーションレイヤの知識なしにタイマ値を決定することは依然として困難である。一方、UEは、上位レイヤにおけるそのタイムアウト設定に基づいて適切なタイマ値を設定するのを助けることができる。例えば、UEは、Msg3上の自己設定タイマ値をeNBに通知することができる。
提案4:RAN2は、UEがMsg3上の自己設定タイマ値をeNBに通知することを許可されているかどうかを検討すべきである。
(2.2.4.タイマの定義)
上記の提案(提案2〜提案4)の1つ又は複数が納得性がある場合、EDTのタイマの概念は従来のタイマとは異なる。また、EDT可能なUEが、例えば、より大きなパケット送信のためにレガシーRRC接続確立/再開を開始することも可能であり、これにより、レガシータイマがこの場合に適用可能である。この意味で、既存のタイマをそのまま維持し、既存のタイマを拡張するのではなく、EDT固有の新しいタイマを定義する方が簡単である。
提案5:RAN2は、レガシータイマではなく、UL EDT(Msg3以上)とDL EDT(Msg4以上)の間で動作する新しいタイマを定義することに合意すべきである。
[付記6]
(1.はじめに)
RAN2#100は、EDT機能の見通しを形成するために達成された。しかし、詳細についてはまだ多くの更なる検討が必要であり、そのうちの1つは以下の通りである。
合意事項
CPソリューション
[...]
・T300とmac−contention Resolution Timerの変更が必要かどうかは更なる検討が必要
この付記において、タイマの側面のさらなる考察が検討される。
(2.検討)
(2.1.前提)
提案1:RAN2は、DL専用のEDTプロシージャがサポートされているかどうかについて検討すべきである。
(2.2.T300及び競合解決タイマ)
(2.2.1.Msg4遅延の問題)
考察1:EDTにおけるMsg3とMsg4の間の持続時間は、上位レイヤからの往復時間のために、従来よりも長くなる。
mac−Contention Resolution Timerに関しては、アーリーコンテンションレゾリューションを使用してタイマ満了を防ぐことができた。NB−IoTUEの場合、Rel−14以降がアーリーコンテンションレゾリューションをサポートすることは合意されたが、それがオプションであるかどうかは更なる検討が必要である。
提案2:アーリーコンテンションレゾリューションがEDT対応NB−IoT UEによってサポートされている場合、RAN2はmac−Contention Resolution Timerへの変更が不要であることに合意すべきである。
T300に関しては、上位レイヤからの往復時間の影響を直接受ける。CEモードBの再送や再送などを考慮して、タイマ値を拡張することが提案されている。
したがって、T300の満了による不要な障害を防ぐために、より長いタイマ値を定義するのは簡単である。
提案3:RAN2は、T300の満了による不要な障害を防ぐために、Msg3上のULEDTとMsg4上のDLEDTとの間で動作するタイマのためにより長い値を定義すべきである。
(2.2.2.Msg4受信用のDRX)
提案3が納得のいくものであれば、既存のT300のタイマ値を拡張するのは簡単である。しかし、これは、Msg4の受信まで連続的なPDCCHモニタリングのために追加のUE電力消費を引き起こし、それによってMsg4は前のセクションで説明したようにEDTで遅延することがある。このような不必要な電力消費を避けるために、何らかの種類のDRXのような受信モードがEDTプロシージャに導入されるべきである。
例えば、単純なソリューションとして、UEは、タイマが満了する直前のサブフレーム、すなわち「ワンショット」モニタリングにおいてのみ、PDCCHをモニタすることができる。高遅延通信[10]のようないくつかのMTC/NB−IoTユースケースでは、連続モニタリングよりもうまくいく可能性がある。
提案4:RAN2は、EDTプロシージャにおいて(すなわち、Msg3送信からMsg4受信までの間に)不連続受信が許容されるかどうかを検討すべきである。
(2.2.3.タイマ値の設定)
さらに、eNBがタイマ値をどのように設定するかは疑問である。というのは、TCPACKが上位レイヤのメッセージから到着するとき、eNBには未知であるからである。セルには様々なアプリケーションを実装する多数のUEが存在すると仮定されているので、eNBが全てのUEに対して適切なタイマ値を設定することは困難である。
考察4:異なるUEが異なるアプリケーションを使用する可能性があることを考慮して、適切なタイマ値を設定することは困難である。
1つの可能性は、Msg2に専用のシグナリングを使用してタイマを設定することであるが、eNBでアプリケーションレイヤの知識なしにタイマ値を決定することは依然として困難である。一方、UEは、上位レイヤにおけるそのタイムアウト設定に基づいて適切なタイマ値を設定するのを助けることができる。例えば、UEは、Msg3上の自己設定タイマ値をeNBに通知することができる。
提案5:RAN2は、UEがMsg3上の自己設定タイマ値をeNBに通知することを許可されているかどうかを検討すべきである。
(2.2.4.タイマの定義)
上記の提案(提案3〜提案5)の1つ又は複数が合意可能である場合、EDTのタイマの概念は従来のタイマとは異なる。EDT可能なUEが、例えば、より大きなパケット送信のためにレガシーRRC接続確立/再開を開始することも可能であり、これによりレガシータイマがこの場合に適用可能である。この意味で、既存のタイマをそのまま維持し、既存のタイマを拡張するのではなく、EDT固有の新しいタイマを定義する方が簡単である。
提案6:RAN2は、レガシータイマではなく、UL EDT(Msg3以上)とDL EDT(Msg4以上)の間で動作する新しいタイマを定義することに合意すべきである。
[付記7]
(1.はじめに)
RAN2#101はUL EDTのパディング問題のソリューションとして以下のように合意した。
合意事項
・EDT ULグラントは、提供されたULグラントが従来のMsg3のものでない限り、システム情報においてブロードキャストされる最大TBサイズを常に許可するものとする。
・EDT ULグラントは、UEがULデータに基づいて提供されるTBサイズのセットから適切なTBサイズ、MCS、繰り返し回数、及びRU(NB−IoTのために)を選択することを可能にする。可能なTBサイズ、MCS、繰り返し回数、及びRU(NB−IoTの場合)のセットがどのように提供されるか(例えば仕様書にハードコードされる)は更なる検討が必要である。これは保留中のRAN1確認事項である。
・RAN2は、システム情報でブロードキャストされる最大TBサイズの8つの候補値を想定している。RAN2は、ブロードキャストされる各最大TBサイズについて、最大4つの可能なTBサイズ、すなわちブラインド復号オプションが許容されると仮定する。
・eMTCの場合、必要な場合にのみ、MAC RARの予約ビットをeMTCのEDT機能に使用できる。
・可能な最大及び最小TBサイズの合意を含む上記の合意をキャプチャしてRAN1にLSを送り、RAN1に確認を依頼する。
この付記では、ソリューションの仕組みについてさらに検討する。
(2.検討)
現在の仮定の下でのソリューションにおけるTBSの関連は、図32に示すように表すことができる。図32は、EDTのULグラントサイズと実際のUL送信を示す。
UEの観点から、4つのブラインド復号オプションを有するEDTのためのULグラントは、UEが必要なパディングビットを最小化するTBSを選択することを可能にする。しかしながら、EDTのための付与されたULデータサイズが(少なくともCPソリューションのために)「適合」しない場合、UEはレガシープロシージャを開始し、RRC Connectedに移行することができる。したがって、UEの観点から、最大TBS及びブラインド符号化オプションの数は可能な限り高く設定されるべきである。
考察1:UEは、最大TBS及び/又はブラインド復号オプションがそのULデータサイズで良好な「適合」である場合にEDTを開始することができる。
対照的に、NWの観点から、最大TBSは、リソースの無駄を最小限に抑えるために、実際的に実現可能な低い値に設定する必要がある。したがって、いくつかの実装では、最大TBS値の設定がより保守的になる傾向がある。しかしながら、この設定は、何台のUEがEDTを利用するか、すなわち、NWがUEの低電力動作をサポートするかどうかに関して直接の影響を有する。NWは、様々なMTCアプリケーションを有するUEの必要なULデータサイズを認識していない可能性があるので、NW実装が最大TBS及びブラインド復号オプションを最適化するための適切な手段を有するかどうかはまだはっきりしていない。
考察2:EDTの有用性は、最適な最大TBS設定に依存する。
考察3:最大TBS及びブラインド復号オプションの設定は、MTCアプリケーションのULデータサイズ要件に基づいている必要がある。
上記の見解を考慮して、NW最適化の一部として、UEがその意図されたアプリケーションについてフィードバック(特に、ULデータサイズ)を提供する必要があるかどうかを検討すべきである。
UEがRRC IDLEに戻る(例えば、RAIを送信する)前に、UEは、支援情報としてEDTのためのその好ましいTBSをeNBに通知する機会を有することができる。支援情報は、以下の場合に意味がある。
・ケース1:BSRと同様に、情報を次のEDTの予想データサイズとして使用することができる。これにより、SIBの設定を変更するための参照の1つになる。
・ケース2:UE能力と同様に、情報は、次のEDT可能性のためにNCCがUEに提供されるべきかどうかを決定するために使用されてもよい。
・ケース3:MDTと同様に、情報は統計分析やNW最適化に使用できる。
したがって、EDTの運用に関連する支援情報を導入すべきである。
提案1:RAN2は、UEがTBS設定最適化、例えばその好ましいTBSのための支援情報を送信することを可能にすることに合意すべきである。
さらに、UEがレガシーにフォールバックする場合、すなわち、例えば、追加のULデータがアプリケーションによって生成されたために、Msg1にEDTインディケーションを送信してEDTにULグラントを受信した後でも、UEがレガシーMsg3を送信する場合がある。そのケースを考慮する必要がある場合、EDT ULグラントは、合意された4つのオプションに加えて、従来のMsg3サイズのブラインド復号オプションを常に許可する必要がある。
提案2:RAN2は、合意された4つのオプションに加えて、EDT ULグラントが常にレガシーMsg3サイズのブラインド復号オプションを許可すべきかどうかについて検討すべきである。
[相互参照]
本願は、米国仮出願第62/543469号(2017年8月10日出願)、米国仮出願第62/560775号(2017年9月20日出願)、米国仮出願第62/564430号(2017年9月28日出願)、米国仮出願第62/586981号(2017年11月16日出願)、米国仮出願第62/627313号(2018年2月7日出願)、米国仮出願第62/630915号(2018年2月15日出願)、米国仮出願第62/652436号(2018年4月4日出願)の優先権を主張し、その内容のすべてが本願明細書に組み込まれている。