本発明の様々な例は、一般に、端末と無線ネットワークとの間でデータを通信することに関する。本発明の様々な例は、特に、データを通信するためのデータ接続を確立するために、ネットワークアクセスを実行することに関する。特定の例によれば、ネットワークアクセスに優先順位を付けることができる。
無線通信システムでは、端末(モバイルデバイスまたはユーザ機器(User Equipment:UE)と呼ばれることもある)および基地局(Base Station:BS)は、通常、データ接続を使用してデータを通信する。データ接続は、ランダムアクセス手順を使用して、UEとネットワークの間にセットアップされる。これには、UEによって実行されるネットワークアクセスが含まれる。次に、スペクトル上のリソースを、データを通信するためにUEに割り当てることができる。これは、時にはリソーススケジューリングと呼ばれる。リソーススケジューリングは、データ接続によって促進される。
基準実装によると、ネットワークアクセスからリソーススケジューリングまでの上記種々のプロセスは、エネルギー効率が悪くなる可能性があり、かなりの時間を必要とすることがある。したがって、データの通信までの待ち時間が長くなる。これは、特に、エネルギー効率の高い操作に関して最適化される、モノのインターネット(Internet of Things:IOT)デバイスに関連し得る。
方法は、ダウンリンク制御メッセージを通信することを含むものである。当該ダウンリンク制御メッセージは、ネットワークと端末との間の最初のデータ接続を使用して通信される。ダウンリンク制御メッセージは、予約済みリソースのタイミングを示すものである。予約済みリソースは、ネットワークと端末の間の通信用に確保される。予約済みリソースは、ネットワークが予測したデータ送信の予測されたサイズに基づいて大きさを決定することができる。この方法はまた、最初のデータ接続の接続解除を実行することも含んでいる。この方法はまた、前記タイミングに従うとともに予約済みリソースを使用し、ネットワークアクセスを実行して、端末とネットワークとの間に第2のデータ接続を確立することも含むものである。
たとえば、予約済みリソースは、当該端末のために排他的または半排他的に確保され得る。したがって、端末が予約済みリソースにアクセスするときには、当該端末と他の端末との間に衝突がないか、または減少する可能性がある。他の端末と、予約済みリソース上の端末との同時スケジューリングは回避することができる。
このような技術により、端末によるタイムリーな再接続を容易にすることが可能である。これにより、データ接続の解除後にデータを送信する必要がある場合に、待ち時間を増加させるリスクを冒すことなく最初のデータ接続を解除できるため、エネルギー消費の低減に役立つ。
当該タイミングには、時間ドメイン、周波数ドメイン、およびコードドメインの少なくとも1つで定義される予約済みリソースを示す、スケジューリング情報を含めることができる。
これにより、第2のデータ接続の確立を動的にスケジューリングすることが可能である。時間ドメイン、周波数ドメイン、コードドメインでの多重化が可能になる。
たとえば、スケジューリング情報は、ネットワークアクセスのためのプリアンブルシーケンスを示し得る。
これは、コードドメインでの多重化の実行を補助する。直交プリアンブルシーケンス、たとえば、Zadoff-Chuシーケンス、またはウォルシュ-アダマールコードを使用できる。
スケジューリング情報は、リソースグリッドの時間-周波数リソース要素を示すことができる。プリアンブルシーケンスは、時間-周波数リソース要素において通信され得る。これは、時間-周波数ドメインで多重化を実行するために役立つ。リソース要素は、変調スキームのシンボルおよびサブキャリアによって定義され得る。
前記タイミングには、前記予約済みリソースを含むネットワークの無線リンクにおける少なくとも1つの送信フレームのシーケンス番号、および端末により実装されるタイマーのタイマー初期化値のうちの少なくとも1つが含まれ得る。これは、予約済みリソースの時間オフセット、たとえば、現在の時刻から10分超、または30分超の時間オフセットのスケジューリングに役立つ。シーケンス番号空間でのラップアラウンドを使用すると、リソースの再発や半永続的なスケジューリングが可能になる可能性がある。
たとえば、端末は、接続解除とネットワークアクセスとの間でページング不可能として、ネットワークに登録され得る。これは、ディープスリープモードで端末を操作するのに役立ち、それにより電力消費を削減できる。
端末は、少なくとも15秒間、必要に応じ少なくとも60秒間、更に必要に応じ少なくとも10分間はページング不可として登録できる。これにより、データ通信のニーズに合わせて調整された大きな電力消費を提供することができる。
当該方法は更に、データ送信のタイミングを予測すること、および前記データ送信のタイミングの予測に基づいて予約済みリソースのタイミングを決定すること、ならびにネットワークアクセスの実行および第2のデータ接続の使用に応答してデータ送信を実行することを含むことができる。
これは、予測されたデータ送信を考慮して、ネットワークとの再接続を調整する補助となり得る。データのジャストインタイム配信が提供され得る。
データ送信のタイミングは、パケットデータネットワーク応答時間、および端末によって実行されるアプリケーションの反復報告スケジュールのうちの少なくとも1つに基づいて予測され得る。
これにより、マシン型通信アプリケーションが容易になる。
この方法は更に、第1のデータ接続を使用して、端末からネットワークノードへと、ダウンリンク制御メッセージを要求するためのアップリンク制御メッセージを通信することを含むことができ、このアップリンク制御メッセージは、予約済みリソースのタイミングを示す。
それによって、端末はタイミングを制御することができる。これは、アップリンクデータのジャストインタイム配信を促進するのに役立つ。
ダウンリンク制御メッセージは、アップリンク制御メッセージによって示されるタイミングの肯定応答を含み得る。これにより、端末とネットワークとの間の予約済みリソースの双方向での交渉が提供され得る。
たとえば、アップリンク制御メッセージは更に、データ送信のサイズ、および任意にデータ送信の方向性を示し得る。これは、データ送信のための、追加のスケジューリング要求を通信する必要性を回避するために役立つ。
上記のデータ送信は、アップリンクデータ送信であり得る。当該方法は更に、第2のデータ接続の前記確立に応答して、ネットワークノードから端末へと、更なる予約済みリソースを示すスケジューリング情報を含んだ更なるダウンリンク制御メッセージを通信することを含み得る。当該更なる予約済みリソースのサイズは、アップリンク制御メッセージにより示されるデータ送信のサイズに従い得る。アップリンクデータ送信は、更なる予約済みリソースを使用して実行できる。
このような技術は、第2のデータ接続の確立と、アップリンクデータ送信の実行との間の時間的オーバーヘッドを低減するのに役立つ。
この方法では、ネットワークアクセスの前記実行とアップリンクデータ送信の前記実行との間に、端末からネットワークノードへのアップリンクスケジューリング要求を通信することを含まなくてよい。これにより、制御シグナリングのオーバーヘッドが低減される。
ダウンリンク制御メッセージは、リソースを予約するネットワークにおける複数のセルのうちの1つのセルに関連した識別情報を含み得る。たとえば、第1のデータ接続は、ネットワークにおける複数のセルのうちの第1のセルを介することができ、第2のデータ接続は、ネットワークにおける複数のセルのうちの第2のセルを介することができる。
これは、端末のモビリティをサポートするのに役立つ。セル間スケジューリングがサポートされ得る。
当該方法は更に、接続解除の前記実行とネットワークアクセスの前記実行との間において、端末の受信機を継続的に非アクティブ状態で動作させることを含み得る。
これは、消費電力の低減に役立つ。
このネットワークアクセスは、予約済みリソースを使用して非競合ベースで実行され得る。
これにより、長いバックオフ時間が回避される。タイムリーな再接続が容易になる。
ダウンリンク制御メッセージは、更なる予約済みリソースを示す更なるスケジューリング情報を含み得る。この方法は更に、第2のデータ接続を使用し、更なる予約済みリソースを使用してデータを送信することを含むことができる。
これは、短い待ち時間でのデータ送信を容易にするために役立つ。
コンピュータプログラム製品には、プログラムコードが含まれている。プログラムコードを実行すると、少なくとも1つのプロセッサに対して或る方法を実行させる。この方法は、ネットワークと端末との間の第1のデータ接続を使用し、当該ネットワークのネットワークノードから端末へと、ネットワークと端末の間の通信のために予約された予約リソースのタイミングを示すダウンリンク制御メッセージを通信し、また第1のデータ接続の接続解除を実行し、また前記タイミングに従うとともに予約済みリソースを使用し、ネットワークアクセスを実行して、端末とネットワークとの間に第2のデータ接続を確立する。予約済みリソースは、当該ネットワークによって予測されたデータ送信の予測されたサイズに基づいて大きさが決定されてよい。
コンピュータプログラムはプログラムコードを含んでいる。プログラムコードを実行すると、少なくとも1つのプロセッサに対して或る方法を実行させる。当該方法は、ネットワークと端末との間の第1のデータ接続を使用し、ネットワークのネットワークノードから端末へと、ネットワークおよび端末の間の通信のために予約された予約済みリソースのタイミングを示すダウンリンク制御メッセージを通信し、また前記第1のデータ接続の接続解除を実行し、また前記タイミングに従うとともに予約済みリソースを使用し、ネットワークアクセスを実行して、端末とネットワークとの間に第2のデータ接続を確立する。予約済みリソースは、ネットワークによって予測されたデータ送信の予測サイズに基づいて大きさが決定されてよい。
デバイスは、ネットワークと端末との間の第1のデータ接続を使用し、ネットワークのネットワークノードから端末へと、ネットワークと端末との間の通信のために予約された予約済みリソースのタイミングを示すダウンリンク制御メッセージを通信し、また前記第1のデータ接続の接続解除を実行し、また、前記タイミングに従うとともに予約済みリソースを使用し、ネットワークアクセスを実行して、端末とネットワークとの間に第2のデータ接続を確立するように設定された制御回路を含む。前記予約済みリソースは、ネットワークによって予測されたデータ送信の予測されたサイズに基づいて大きさが決定されてよい。
方法は、第2のUEのためでなく第1のUEのために、ネットワークアクセスのためのリソースを予約することによって、第2のUEのネットワークアクセスよりも第1のUEのネットワークアクセスを優先することを含む。この方法は更に、予約済みリソースのタイミングを第1のUEにシグナリングすることを含み得る。必要に応じて、予約済みリソース自体は、たとえば、スケジューリング情報を使用して、第1のUEにシグナリングされてよい。
上述の特徴および以下で更に説明する特徴は、示されたそれぞれの組み合わせだけでなく、本発明の範囲から逸脱することなく、他の組み合わせで、または単独で使用され得ることを理解されたい。
図1は、様々な例に従った、無線リンク上で通信するBSおよびUEを概略的に示す。
図2は、様々な例に従った、UEおよびPSをより詳細に概略的に示す。
図3は、様々な例に従った、BSを含むネットワークのアーキテクチャを概略的に示す。
図4は、様々な例に従った、UEの種々の動作モードを概略的に示す。
図5は、UEの動作モードに従って、更に様々な例に従った異なる状態にあるUEの受信機の動作を概略的に示す。
図6は、様々な例に従ってUEにより実行されるIOTアプリケーションの反復報告スケジュールによる、UEとBSとの間の通信のシグナリング図である。
図7は、UEとBSの間での通信のシグナリング図であり、様々な例に従って、UEとパケットデータネットワークのサーバとの間で通信されるデータの往復時間を示す。
図8は、UEとBSとの間の通信のシグナリング図であり、様々な例に従って、データを通信する前にネットワークアクセスを実行するための予約済みリソースの使用を示す。
図9は、様々な例に従って、ネットワークアクセスを実行するための予約済みリソースを概略的に示す。
図10は、UEとBSおよび更なるBSとの間の通信のシグナリング図であり、様々な例に従って、データを通信する前にネットワークアクセスを実行するために、予約済みリソースを使用することを示す。
図11は、様々な例に従った方法のフローチャートである。
図12は、様々な例に従った方法のフローチャートである。
実施形態の詳細な説明
以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。以下の実施形態の説明は、限定的な意味で解釈されるべきではないことを理解されたい。本発明の範囲は、以下に説明される実施形態または図面によって限定されることを意図するものではなく、それらは単なる例示として解釈されるものである。
図面は、概略図と見なされるべきであり、図面に示される要素は、必ずしも一定の縮尺で示されている訳ではない。むしろ、様々な要素は、それらの機能および一般的な目的が当業者に明らかになるように表現されている。図面に示され、または本明細書に記載される機能ブロック、デバイス、コンポーネント、または他の物理的もしくは機能的ユニット間の任意の接続または結合は、間接的な接続または結合によって実装されてもよい。コンポーネント間の結合はまた、無線接続を介して確立することもできる。機能ブロックは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせにおいて実装されてよい。
以下では、データを通信する技術について説明する。詳細に言えば、たとえば、データを通信する必要性に応答して、ネットワークにアクセスする技術について説明する。
本明細書に記載されている技術は、リソース効率およびエネルギー効率のよいネットワークへのアクセスを容易にする。本明細書で説明する技術は、ネットワークへの待ち時間の短いアクセスを容易にする。これにより、待ち時間が短く且つエネルギー効率の高いデータ通信が容易になる。
本明細書に記載される技術は、IOTデバイスに関連して使用され得る。具体的には、本明細書で説明される技術は、第3世代パートナーシッププロジェクト(Third Generation Partnership Project:3GPP)マシン型通信(Machine Type Communication:MTC)デバイスに関連して採用され得る。本明細書で説明される技術は、3GPP狭帯域IOT(Narrowband IOT:NB-IOT)デバイスに関連して採用され得る。
上記で説明したように、本明細書で記載する技術は、ネットワークにおけるUEとBSとの間でのデータの送信および/または受信(通信)を容易にすることができる。たとえば、アップリンク(Uplink:UL)データおよび/またはダウンリンク(Downlink:DL)データが通信され得る。たとえば、UEおよび/またはネットワークで実行されるサービスに関連付けられ得るペイロードデータが通信され得る。たとえば、ペイロードデータは、UEと、UEへのアクセスを提供するネットワークが接続されるパケットデータネットワーク(Packet Data Network:PDN)との間で通信され得る。
実施例によれば、DL制御メッセージは、ネットワークからUEへと通信される。DL制御メッセージは、予約済みリソースのタイミングを示す。たとえば、リソースは、ネットワークとUEの間での通信のために、排他的または半排他的に予約され得る。DL制御メッセージは、ネットワークと端末との間の最初のデータ接続を使用して通信され得る。たとえば、最初のデータ接続によって実装される物理DL制御チャネル(Physical DL Control Channel:PDCCH)のような制御チャネルは、DL制御メッセージを通信するために使用され得る。その後、最初のデータ接続の接続解除が実行され得る。続いて、タイミングに従うとともに予約済みリソースを使用してネットワークアクセスを実行し、UEとネットワークの間に第2のデータ接続を確立することができる。次いで、この第2のデータ接続を使用してデータを通信することができる。
一般的なルールとして、ネットワークアクセス用に予約されたリソースのタイミングは、目的のデータ送信のタイミングと相関するか、または時間整合される。たとえば、予約済みリソースのタイミングは、第2のデータ送信を確立するための幾らかのヘッドルームを得るために、データ送信のタイミングから所与の量だけオフセットさせることができる。
このような技術は、幾つかのシナリオにおいて、データを通信するためにデータ接続が必要になる時点を予測できる可能性があるとの発見に基づいている。こうして、それぞれのデータ接続を確立するために、ネットワークへの待ち時間が短く且つ効率的なアクセスが可能になるように、ネットワークアクセスのための予約済みリソースを提供することが可能になり得る。ネットワークアクセスおよび確立されたデータ接続に基づき、たとえばデータのサイズ等を考慮して、データを通信するためのリソースを柔軟にスケジュールすることが可能である。
具体的には、このような技術は、たとえばLoRaアライアンスプロトコル(www.LoRa-Alliance.orgを参照、2017年9月23日検索)による従来の実装と比較した場合、一定の利点を有する。このようなソリューションでは、競合ベースのUL送信の後に、データを受信できる2つの短いDL受信ウィンドウが自動的に続く。2番目の受信ウィンドウは、最初の受信ウィンドウ内でデータが受信されない場合にのみ開かれる。各受信ウィンドウ間の待ち時間は、通信システムごとに固定され、ネットワークによって通知される。このような固定受信ウィンドウは、低い複雑さおよび低いエネルギー消費を目的とし、またULデータ中心のIOTアプリケーションに焦点を当てている。ダウンリンク送信機会間の固定された時間間隔は、固定された時間間隔の間でのUEの省エネルギー状態への移行を容易にする。しかし、そのようなソリューションはそれほど柔軟性を持ったものではない。たとえば、データの通信に依存するアプリケーションが固定時間間隔よりも速い応答期間を必要とする場合、またはより大量のデータが必要な場合は、固定サイズの送信ウィンドウに対応でき、予想される挙動からの逸脱は単純に説明できない。更に、ULデータの競合ベースの通信により、たとえば、無線リンクが混雑している場合には、ULデータを通信するための待ち時間が増加する可能性がある。
本明細書に記載する技術によって、UEとネットワークとの間でのエネルギー効率のよいデータ通信が提供される。同時に、上記の制限および欠点に適応するための更に高度なスケジューリングの柔軟性が提供される。これは、柔軟なスケジューリングを容易にするデータ接続をセットアップすることによって達成される。
図1は、本明細書に開示される技術から利益を得ることができる無線通信ネットワーク100を概略的に示す。ネットワーク100は、複数のセルを含むセルラーネットワークであってよく、各セルは、1つまたは複数のBSに関連付けられる。ネットワークは、3G、4G長期進化(Long Term Evolution:LTE)、または今後の5G新無線(New Radio:NR)のような、3GPP標準化ネットワークである。他の例としては、米国電気電子技術者協会(Institute of Electrical and Electronics Engineers:IEEE)が指定したネットワークのような、ポイントツーポイントネットワーク、たとえば、802.11×Wi-FiプロトコルまたはBluetooth(登録商標)プロトコルが含まれる。更なる例には、3GPP NB-IOTまたはeMTCネットワークが含まれる。
ネットワーク100は、BS101およびUE102を含む。たとえば、UE102は、スマートホン、携帯電話、テーブル、ノート、コンピュータ、スマートTV、MTCデバイス、LOTデバイス、センサ、アクチュエータ等を含む群から選択されてよい。
MTCデバイスまたはIOTデバイスは、典型的には、データトラフィック容量に対する要件が低から中程度で、待ち時間要件が緩いデバイスである。更に、MTCまたはIOTデバイスを使用した通信は、複雑さを抑え、低コストを達成すべきである。更に、MTCまたはIOTデバイスのエネルギー消費は、バッテリー駆動のデバイスを比較的長い時間機能させるために、比較的低くなければならない。バッテリーの寿命は十分に長くなければならない。たとえば、IOTデバイスは、NB-IOT RATを介してEPSに接続され得る。
無線リンク111が、BS101とUE102の間に確立される。無線リンク111は、BS101からUE102へのDLリンクを含み、更に、UE102からBS101へのULリンクを含む。時分割複信(Time-Division Duplexing:TDD)、周波数分割複信(Frequency-Division Duplexing:FDD)、空間分割複信(Space-Division Duplexing:SDD)、および/またはコード分割複信(Code-Division Duplexing:CDD)を使用して、ULとDL間の干渉を緩和できる。同様に、TDD、FDD、SDD、および/またはCDDは、無線リンク111(図1には示されていない)上で通信する複数のUE間の干渉を緩和するために採用され得る。これは、非競合ベースまたは競合フリーの通信を実装するのに役立つ。このために、無線リソース(以下、単にリソースと呼ぶ)を使用することができる。
図1の挿入図(破線)は、リソースに関する態様を示している。時間-周波数リソース要素261は、時間-周波数リソースグリッド251で定義される。図1の挿入図は、単一の送信フレーム260についての時間-周波数リソースグリッド251を示す。送信フレーム260は、時間ドメインで無線リンク111上の送信を構成する。送信フレーム260の例は、階層的順序で、サブフレーム、フレーム、およびスーパーフレームを含む。
図1の例では、各時間-周波数リソース261は、直交周波数分割多重(ODFM)変調スキームのサブキャリアによって形成され得る。各時間-周波数リソース要素261は、時間領域で単一のシンボルを運ぶことができる。各時間-周波数リソース要素261は、BS101および所与のUEとの間の通信のために予約され得る。このような時間-周波数リソース要素は、時には専用リソースと呼ばれる。予約のために、スケジューリング情報が、BS101によってそれぞれのUEに提供され得る。
時間周波数リソース261の幾つかは、BS101と所与のUEとの間の通信のために予約されない場合がある。むしろ、UEがスケジューリング情報を受信する機会を持つことがなかったそのような共有リソースに基づいて、ネットワークへの競合ベースのアクセスが実装される可能性がある。
図1においては、時間-周波数リソース要素261に関連してTDDおよびFDDが説明されたが、他の例では、非競合ベースの通信を実装するためにCDDおよび/またはSDDを使用し、したがって少なくとも1つの空間ドメインまたはコードドメインで定義されたリソースに依存することが可能である。
図2は、BS101およびUE102の更なる詳細を概略的に示す。BS101は、プロセッサ1011およびインターフェース1012を含む。インターフェース1012は、1つまたは複数のアンテナを含むことができる。インターフェース102は、無線リンク111で通信するように設定され得る。BS101は更に、メモリ1015、たとえば不揮発性メモリを更に含む。メモリは、プロセッサ1011によって実行され得るプログラムコードを格納し得る。プログラムコードを実行することにより、プロセッサ1011は、UE102とのRA手順に参加すること、UE102のネットワークアクセスに参加すること、更なるUEのネットワークアクセスよりもUE102によるネットワークアクセスを優先させること、UE102によるネットワークアクセスのために予約済みリソースを割り当てること、FDD、TDD、SDD、および/またはCDDを実行して、予約済みリソースを提供すること、予約済みリソースのタイミングを示すDL制御メッセージをUE102に送信することに関する技術を実行することができる。したがって、プロセッサ1011およびメモリ1015は制御回路を形成する。
UE102は、プロセッサ1021およびインターフェース1022を含む。インターフェース1022は、1つまたは複数のアンテナを含み得る。インターフェース1022は、無線リンク111で通信するように設定され得る。UE102は更に、メモリ1025、たとえば不揮発性メモリを含む。メモリ1025は、プロセッサ1021によって実行され得るプログラムコードを格納し得る。プログラムコードを実行すると、プロセッサ1021は、BS101とのRA手順に参加すること、BS101を介してネットワークへのネットワークアクセスを実行すること、BS101から、少なくとも1つの予約済みリソースのタイミングを示すDL制御メッセージを受信すること等に関して技術を実行することができる。したがって、プロセッサ1021およびメモリ1025は、制御回路を形成する。
図3は、幾つかの例示的な実装によるセルラーネットワーク100のアーキテクチャに関する態様を示している。特に、図3の例によるセルラーネットワーク100は、3GPP LTEアーキテクチャを実装し、これは進化型パケットシステム(Evolved Packet System:EPS)と呼ばれることもある。しかし、これは例示のみを目的とするものである。特に、様々なシナリオが、例示のみを目的として、3GPP LTE無線アクセス技術(Radio Access Technology:RAT)に従って動作するUE102とBS102の間の無線リンク111の関連において説明される。同様の手法は、様々な種類の3GPP指定RAT、たとえば、モバイルシステム用グローバルシステム(Global Systems for Mobile Communications:GSM(登録商標))、広帯域コード分割多重送信(Wideband Code Division Multiplex:WCDMA(登録商標))、汎用パケット無線サービス(General Packet Radio Service:GPRS)、GSM進化のための拡張データレート(Enhanced Data Rates for GSM Evolution:EDGE)、拡張GPRS(Enhanced GPRS:EGPRS)、ユニバーサルモバイルテレコミュニケーションシステム(Universal Mobile Telecommunications System:UMTS)、高速パケットアクセス(High Speed Packet Access:HSPA)、および関連するセルラーネットワークの対応するアーキテクチャに容易に適用できる。ネットワーク100は、3GPP NRプロトコルに従って動作している可能性がある。更なる特定の例は、3GPP NB-IOT RATである。3GPP NB-IOT RATは、3GPP LTE RAT、即ち、進化型UMTS地上無線アクセス(Evolved UMTS Terrestrial Radio Access:E-UTRA)に基づくことができる。更に、NB-IOT RATは、図3に示されるようにEPSと組み合わされてもよい。本明細書に開示される様々な例は、代替的または追加的に、3GPP NB-IOT RATのために容易に実装され得る。同様に、本明細書で説明される技術は、MTCに使用され得る。他の例には、他のタイプのネットワーク、たとえば、米国電気電子技術者協会(IEEE)の802.11X無線ローカルエリアネットワーク、Bluetooth、Zigbee(登録商標)が含まれる。
UE102は、ネットワーク100に登録される。図3に示すように、UE102は、セルラーネットワーク100のBS101への無線リンク111を介して、ネットワーク100に接続される。BS101およびUE102は、進化型UMTS地上無線アクセス技術(E-UTRAN)を実装する。したがって、BS101は、図3では進化型ノードB(Evolved Node B:eNB)とラベル付けされている。NRにおいて、BS101は、gノードB(g Node B:gNB)として知られている。他の例では、UE102はネットワーク100に登録され得るが、アクティブなデータ接続160は維持されない可能性がある。接続160をセットアップするために、競合ベースまたは非競合ベースのランダムアクセス(Random Access:RA)手順を含むネットワークアクセスが、UE102およびBS101によって実行され得る。
無線リンク111上での通信は、UL方向および/またはDL方向であり得る。BS101は、サービングゲートウェイ(Serving Gateway:SGW)117によって実装されたゲートウェイノードに接続されている。SGW117は、ペイロードデータをルーティングおよび転送することができ、UE102のハンドオーバの際にはモビリティアンカーとして機能することができる。
SGW117は、パケットデータネットワークゲートウェイ(Packet Data Network Gateway:PGW)118によって実装されるゲートウェイノードに接続される。PGW118は、パケットデータネットワーク(PDN;図3には示されていない)に向かうデータのためのセルラーネットワーク110の出口点および入口点として機能する。この目的のために、PGW118は、パケットデータネットワークのアクセスポイントノード121と接続される。アクセスポイントノード121は、アクセスポイント名(Access Point Name:APN)によって一意に識別される。APNは、PDNへのアクセスを求めるためにUE102によって使用される。
3GPP NRシナリオでは、SGW117およびPGW117の機能は、ユーザプレーン機能(User Plane Function:UPF)によって実装され得る。
PGW118は、UE102のパケット化されたペイロードデータのための、エンドツーエンドデータ接続160のエンドポイントであり得る。データ接続160は、特定のアプリケーションのペイロードデータを通信するために使用され得る。異なるアプリケーション/サービスは、異なるデータ接続160を使用するか、または少なくとも部分的に、特定のデータ接続を共有することができる。データ接続160は、サービス固有のデータを通信するために使用される1つまたは複数のベアラによって実装され得る。QoSクラス識別子(QoS Class Identifier:QCI)によって示されるサービス品質パラメーターの特定の組を特徴とするEPSベアラ。データ接続は、無線リンク111上で通信するために、BS101およびUE102によって実装される送信プロトコルスタックのレイヤ2またはレイヤ3上で少なくとも部分的に定義され得る。たとえば、3GPP LTE E-UTRANに関連して、データ接続160は、無線リソース制御(Radio Resource Control:RRC)層上で実装され得る。
コアネットワークの制御層には、モビリティ管理エンティティ(Mobility Management Entity:MME)116が含まれる。MME116機能は、3GPP NRフレームワークにおけるアクセスおよびモビリティ管理機能(Mobility Management Function:AMF)およびセッション管理機能(Session Management Function:SMF)によって実装できる。
ホーム加入者サーバ(Home Subscriber Server:HSS)115は、認証および加入情報のようなユーザおよび加入者関連情報を含むリポジトリを含む。3GPP NRでは、そのような機能は認証サーバ機能(Authentication Server Function:AUSF)および/または統合データ管理(Unified Data Management:UDM)機能によって実装される。
ポリシーおよび課金ルール機能(Policy and Charging Rules Function:PCRF)は、ポリシー制御を実装して、特定のQoSを容易にする。それぞれの機能は、3GPP NRフレームワークにおけるポリシー制御機能(Policy Control Function:PCF)によって実装される。
MME116は、ページングおよびアクセス資格情報のようなモビリティおよびセキュリティタスクを取り扱う。MME116はまた、UE102の動作モード、たとえば、UE102がコネクテッドモードまたは切断モードの何れで動作するかの追跡を維持する。MME116は、非アクセス層(Non-Access Stratum:NAS)接続、即ち、RRC層の上の層に実装された制御接続の終点である。
MME116は、ページング機能を制御することができる。したがって、MME116によって維持されるレジストリが存在し得、これは特定のUEがページング可能であるか、またはページング不可能であるかを識別する。これは、当該UEの特定の動作モードに依存する場合がある。次に、この動作モードは、データ接続160の有無に関連付けられることができる。図4は、そのような動作モードに関連した態様を示している。
図4は、UE102が動作できる異なる動作モード301~304に関する態様を示している。図4に示された全ての状態において、UE102はネットワーク100に登録することができる。即ち、3GPP LTEではEMM登録され、または3GPP NRではMM登録されることができる。したがって、対応するエントリーはMME116に保持され得る。
コネクテッドモード301では、データ接続160がセットアップされる。たとえば、デフォルトのベアラおよび任意に1つまたは複数の専用ベアラが、UE102とネットワーク100との間にセットアップされ得る。
電力消費を低減するために、コネクテッドモード301から、不連続受信(Discontinuous Reception:DRX)サイクルを採用するコネクテッドモード302(コネクテッドモードDRX)に移行することが可能である。
DRXサイクルは、オン期間およびオフ期間を含む(図4には示されていない)。オフ期間中は、UE102のインターフェースはデータを受信するのに適さない。たとえば、アナログおよび/またはデジタルのフロントエンドは、少なくとも部分的にパワーダウンされ得る。DRXサイクルのタイミングは、UE102とBS101との間で同期され、それにより、BS101は、任意のDL送信を、コネクテッドモードのDRXサイクルのオン期間に合わせることができる。データ接続160は、オフ期間中であっても、モード302で確立されたまま維持される。データ接続160は解除されない。
更なる電力削減を達成するために、1つまたは複数の切断モード303、304に移行することが可能である。ここでデータ接続160は解除され、セットアップされない。
切断モード303、304の一例は、アイドルモード303である。アイドルモード303は、ここでも、UE102のアイドルモードDRXサイクルに関連付けられている。しかし、アイドルモード303のDRXサイクルのオン期間中は、UE102のインターフェースはページングを受信するためだけに適合している。たとえば、これは、アイドルモード303におけるDRXサイクルのオン期間中に、UEが監視する必要がある周波数帯域幅を制限するのに役立つ。これは、たとえば、コネクテッドモード302と比較した場合、電力消費を更に削減するのに役立つ。
たとえば、コネクテッドモード301からアイドルモード303に移行するときは、データ接続160を解除することが可能である。UE102は、以前にネットワーク100により提供されたタイミング情報に従って、アイドルモード303からコネクテッドモード301へと自動的に移行することができる。これは、予約済みリソースへのネットワークアクセスを含むことができる。
切断モードの更なる例は、DRXなしのアイドルモードである。ここで、UE102のインターフェース1022は、スリープ状態で継続的に動作している。したがって、UE102は、ページング不能としてネットワーク100に登録される。DRXサイクルは実装されていない。UE102は、ネットワーク100によって以前に提供されたタイミング情報に従って、アイドルモード304からコネクテッドモード301に自動的に移行することができる。これは、予約済みリソースへのネットワークアクセスを含むことができる。モード304は、特別の大きなエネルギー節約を提供する。具体的には、ページングを容易にするために、受信機をアクティブな状態で繰り返し動作させることは要求されない可能性がある。
図4は、シナリオの単なる一例である。他の例では、より少なく、より多い、または異なるモードが使用され得る。たとえば、3GPP NRの関連においては、RRC非アクティブコネクテッド(RRC-INACTIVE CONNECTED)モードを使用できる。3GPP(テクニカルレポート)TR23.799、次世代システムのためのアーキテクチャに関する研究、V.1.2.1(2016年11月)を参照されたい。ここでは、UEはRAN環境の一部を保持する。これらのパーツは、ネットワークに再接続したときにも有効のまま残る。このようなパーツには、アクセス層(Access Stratum:AS)のセキュリティ環境、UE機能情報などが含まれる。
図5は、異なるモード301~304の間の移行に関する態様を示す。
まず、UE102は、コネクテッドモード301で動作する。これにより、高レベルの持続的な電力消費が発生する。UE102のインターフェース1022は、アクティブ状態381にある。データ接続160が確立され、制御データまたはペイロードデータを通信するために使用され得る。
次に、電力消費を低減するために、DRXを使用するコネクテッドモード302がアクティブ化される。ここでは、DRXサイクルのオン期間371およびオフ期間372が示されている。オフ期間372の間、インターフェース130は、信号を受信し、また信号を送信するのに適さない非アクティブ状態383にある。非アクティブ状態383は、低エネルギー消費に関連付けられている。コネクテッドモード302では、データ接続160が確立され、制御データまたはペイロードデータを通信するために使用され得る。
次に、電力消費を更に低減するために、アイドルモード303がアクティブ化される。これには、データ接続160の接続解除の実行が伴う。ここでも、アイドルモード303は、オン期間371およびオフ期間372を含むDRXサイクルを使用する。アイドルモード303におけるオン期間371は、コネクテッドモード302におけるオン期間371と比較すると、低電力消費と関連付けられる。何故なら、アイドルモード303の間、コネクテッドモード302に比較すると、インターフェースの機能が低下する可能性があるからである。したがって、UE102のインターフェースは、オン期間371の間、省電力状態382で動作する。アイドルモード303の間、インターフェースの受信機はページング信号の受信のみを予測してよい。これは、帯域幅を制限したり、複雑な復調機能の必要性を制限したりするのに役立つ。アイドルモード303におけるオフ期間372の間、UE102はページング不可能である。幾つかのシナリオでは、オフ期間372は、たとえば、数分または数時間程度の比較的長い期間を有し得る。たとえば、持続時間372のそれぞれの持続時間は、20分より小さくなくてもよく、任意に50分より小さくなくてもよい。
最後に、UE102は、アイドルモード304で動作する。ここでは、UE102のインターフェース1022は、非アクティブ状態383において継続的且つ連続的に動作する。したがって、UE102はページングされることができない。一貫して、UE102は、ページング不可能であるとしてネットワーク100に登録され得る。次に、所定のタイミング501に従って、UE102は、コネクテッドモード301へ再び移行する。これには、ネットワークアクセスが含まれる。
図5では、UE102がタイミング501に従ってコネクテッドモード301に移行するシナリオが示されているが、他のシナリオでは、UE102はタイミング501に従って別のモード、たとえばモード302または303へ移行することも可能である。
更に、図5では、UE102がモード302、303を介してアイドルモード304に移行するシナリオが示されているが、他のシナリオでは、コネクテッドモード301からアイドルモード304への直接移行が可能である。
図6は、UE102とBS101との間のデータ401の通信のシグナリング図である。図6の例では、ULデータ401がUE102からBS101に通信されるシナリオが示されているが、同様のシナリオが、BS101からUE102へのDLデータの通信にも適用可能であり得る。
図6は、ULデータ401を通信することに関する態様を示す。具体的には、図6は、特定のタイミング550に従ってULデータ401を通信することに関する態様を示す。タイミングは、UE102によって実行されるアプリケーションの反復報告スケジュールに関連付けられことができる。
最初に、5001において、データ401は、UE102のUL送信バッファに到着する。たとえば、データ401は、UE102により実装されたアプリケーションによって提供され得る。次に、5002において、データ401は、UE102によって送信され、その後、BS101によって受信される。
これは、それぞれ5003、5004および5005、5006で繰り返される。図6から理解されるように。データ401を提供するアプリケーションは、特定の再発するタイミング550に従ってデータを提供する。たとえば、タイミング550は、周期性を定義することができる。ただし、厳密な周期性は要求されない。何れの場合でも、データ401がUE102のUL送信バッファに到着するタイミング550には、先験的知識が幾つか存在し得る。
タイミング550に関するそのような先験的な知識が利用可能である例示的なシナリオは、IOTアプリケーションに関連し得る。たとえば、IOTアプリケーションは、UE102のセンサにおけるセンサデータの幾つかの報告を実施できる。送信は、タイミング550を定義する反復報告スケジュールに従って実施できる。たとえば、そのようなシナリオにおいて、タイミング550は、UE102におけるセンサの送信の一時的解像度によって定義することができる。
図7は、ULデータ405およびDLデータ406を通信することに関する態様を示す。DLデータ406は、たとえば要求-応答ペアとして、ULデータ405に関連付けられる。たとえば、ULデータ405ならびにDLデータ406の両方は、UE102によって実装された1つの同じアプリケーションに関係し得る。即ち、図7は、特定のタイミング551に従ってデータ405、406を通信することに関する態様を示す。
最初に、5005において、データ405はUE102のUL送信バッファに到着する。たとえば、データ405は、UE102によって実装されるアプリケーションによって提供され得る。次に、5006において、データ405はUE102によって送信され、その後、BS101によって受信される。BS101は5007において、データ接続160に沿って、データ405をAPN121に転送する。データ405の意図された受信者は、アクセスポイントノード121が接続されているPDNのサーバであり得る。
ここでもまた、データ405によってトリガーされた応答データ406のタイミング551に関する先験的知識が存在する。データ406は、5008においてAPN121からBS101によって受信され、その後、5009においてUE102に転送される。タイミング551は、ネットワーク100とPDNとの間の通信の往復時間および/または待ち時間に基づいて予測可能であり、当該PDNは、前記データ405が向けられ且つそこからデータ406が生じるサーバをホストする。したがって、タイミング551は、PDNの応答時間で推定され得る。
シナリオにおけるタイミング550、551の典型的なタイムスケールが、図6および図7に示されている。図6および7は、数秒、数十秒、または更に数分のオーダーであり得る。たとえば、様々なIOTアプリケーションは、10分ごと、または1時間ごとなどで測定レポートを提供し得る。典型的には、たとえば、データ405に含まれるトランザクションに関連する何らかの処理待ち時間が必要とされるならば、往復時間551は、秒のオーダーであり得る。
図6および図7のシナリオにおいて、データ401~403、405~406は、データ接続160を使用して通信することができる。以下、データ401~403、405~406を通信するデータ接続164の、適時またはジャストインタイムの解除および再確立を容易にする技術について説明する。具体的には、タイミング550、551に関する先験的知識を考慮に入れる。これは、接続解除後にデータ接続を再確立するために、UE102によるネットワークアクセスに優先順位を付けることによって達成される。例示的な技術は、図8に関連して示される。
図8は、UE102とBS101の間の通信のシグナリング図である。図8は、UE102によるネットワークアクセスの優先順位付けに関連した態様を示している。図8のシナリオは、図6および図7に関連して上記で示したように、データ送信を容易にするために使用され得るであろう。
5011において、UL制御メッセージ451(図8では事前スケジューリング要求とラベル付けされている)がUE102によって送信され、続いてBS101によって受信される。UL制御メッセージ451は、後続のDL制御メッセージ452を要求するためのものである(図8では事前スケジューリング許可とラベル付けされている)。一般に、UL制御メッセージ451は任意である。
5012において、DL制御メッセージ452がBS101によって送信され、その後、UE102によって受信される。
図8のシナリオにおいて、制御メッセージ451、452は、既存のデータ接続160を使用して通信される。図8に示すように、UE102は、制御メッセージ451、452を通信するときにはコネクテッドモード301で動作する。たとえば、制御メッセージ451、452は、それぞれ物理UL制御チャネル(Physical UL Control Channel:PUCCH)およびPDCCHを使用して通信され得る。
DL制御メッセージ452は、タイミング501を示している。タイミング501は、5013におけるデータ接続の接続解除453の後に、5014において、ネットワークアクセス454のためにUE102用に予約された1つまたは複数のリソースに関連付けられる。ネットワークアクセス用のリソースを予約することにより、UE102によるネットワークアクセスは優先付けされることができる。
リソースは、5017における後続のデータ送信407を容易にするために、ネットワークアクセス454と、それに伴うデータ接続160の確立がジャストインタイムで実行されるように予約される。これにより、UE102は、その間にエネルギー消費を低減することが可能になる、タイミング501は、5013における接続解除453を容易にする。したがって、UE102は、アイドルモード303またはアイドルモード304に移行できる。これはエネルギー消費を低減する。
タイミング501は、データ407の通信が予測される時点に関する先験的知識に基づいて設定されてもよい。たとえば、タイミング501は、図6のシナリオに関連して示されるように、予測されたタイミング550に従って決定されてもよく、または図7のシナリオに関連して示されるように、予測されたタイミング551に従って決定されてもよい。したがって、UE102は次に、アイドルモード303、304(ページング不可能として登録されてもされなくてもよい)で、少なくとも15秒間、任意選択で少なくとも60秒間、更に任意選択で少なくとも10分間動作することができる。これは、UE102の受信機を非アクティブ状態383で継続的に動作させ、それによってエネルギーを節約することを容易にする。
特定のシナリオによっては、UL制御メッセージ451がタイミング501を示すことも可能であろう。このようなシナリオは、特に、データ407が予測される時点が、IOTアプリケーションのレポートスケジュールのような、UE中心のプロセスによって管理される場合に適用される。UL制御メッセージ541が既にタイミング501を示している場合、DL制御メッセージ542は、UL制御メッセージ541によって提案されたタイミング501を肯定的または否定的に確認応答することができる。しかしながら、UL制御メッセージ542がタイミング501を示さないならば、DL制御メッセージ542は、タイミング501を示す標識を含み得る。たとえば、DL制御メッセージ542は、無線リンク111における送信フレーム260のシーケンス番号またはUE102で実装されたタイマーのタイマー初期化値の少なくとも1つを含んだ標識を含み得る。
たとえば、次に、ブロードキャストされた信号、たとえば情報ブロックからの送信フレームにおけるシーケンス番号を監視することが可能であるかもしれない。次いで、UE102は、タイミング501に基づいて、ブロードキャストされたシーケンス番号と同期された次のアクティビティを待つことができる。
タイミング501に従って、UE102は、ネットワークアクセス453を実行して以前に解除したネットワーク100とのデータ接続160を確立する、5014。具体的には、5014において、UE102は、ランダムアクセスプリアンブル(時には、ランダムアクセス(RA)メッセージ1とも称される)を送信する。次に、5015において、BS101は、RA応答メッセージ455(時には、RAメッセージ2とも称される)を送信する。
データ接続160のセットアップは、ネットワークアクセス453と、任意に後続のRRC制御シグナリング(図8には図示せず)によって達成され得る。
5016において、BSは、後続のデータ送信407(たとえばULデータおよび/またはDLデータ)のためのスケジューリング情報を含むスケジューリング許可456を送信する。
5014において、UE102によるネットワークアクセスを優先させるために、タイミング501は、プリアンブル455を通信するために無線リンク111で予約された1つまたは複数のリソース261に関連付けられ得る。これは、図9に関連してより詳細に説明される。
図9は、予約済みリソース258のタイミング501に関する態様を概略的に示している。特に、図8のシナリオにおいて、タイミング501は、予約済みリソース258を含む送信フレーム263のシーケンス番号を含むことができる。図8のシナリオにおいて、予約済みリソースは時間ドメインおよび周波数ドメインで定義される。具体的には、予約済みリソースは、UE102による使用のために排他的に割り当てられる2つの時間-周波数リソース要素258を含む。したがって、予約済みリソースは、UE102専用である。UE102が、予約された時間-周波数リソース要素258を使用してネットワークアクセス454の一部としてプリアンブルを送信しようと試みるとき、更なるUEとのクロストークまたは干渉が軽減され得る。たとえば、BS101は、予約された時間-周波数リソース要素258上で送信するための更なるUEをスケジュールしなくてよい。
図8には、予約済みリソース258が時間ドメインおよび周波数ドメインで定義されるシナリオが示されているが、他の例では、予約済みリソースは、時間ドメインまたは周波数ドメインの何れか一方で定義され得る。更に、時間ドメインおよび/または周波数ドメインで予約済みリソース258を定義する代わりに、またはそれに加えて、予約済みリソースをコードドメインまたは空間ドメインで定義することができる。コードドメインでリソースを予約するシナリオ例は、一組の候補プリアンブルからネットワークアクセス454のために使用されるプリアンブルを選択することを含む。異なる候補プリアンブルは、コードドメインにおいて互いに直交し得る。次に、UE102による排他的または半排他的な使用のために特定の候補プリアンブルを予約することにより、更なるUEとのクロストークまたは干渉を軽減することができる。空間ドメインでは、アンテナアレイを使用したビームフォーミングを使用できる。
一般に、予約済みリソースを使用することにより、ネットワークアクセス454は非競合ベースで実装できる。これは、特に、予約されていないリソースに基づく競合ベースのアクセス手順が使用される実装とは異なる。競合ベースのアクセス手順における時間-周波数リソース要素は、典型的には、BS101によってブロードキャストされる情報ブロックを使用してアナウンスされ、またネットワークアクセスを実行しようとする任意のUEによって使用され得る。同様に、プリアンブルは、同時に2つ以上のUEによって選択され得る。したがって、競合ベースのアクセス手順では、衝突が発生する可能性がある。そこで、典型的には、ランダムなバックオフが実装され、これはエネルギー消費および待ち時間を増大させる。予約済みリソースにより、衝突が完全に回避される非競合ベースのRA手順が可能になり、または少なくとも、競合ベースのRA手順と比較したときには衝突の可能性が顕著に減少する。
一般的なルールとして、予約済みリソースは、UE102が使用するために排他的または少なくとも半排他的に予約され得る。たとえば、1つ以上の候補プリアンブルが全てのUEのサブセット用に予約される可能性がある。そこで、そのような半排他的に予約済みリソースは、既にクロストークまたは干渉をある程度低減している可能性がある。更に別のシナリオにおいて、タイミング501は複数の予約済みリソースを示し得、UEは、予約済みリソースの或るサブセットのみを使用することに関して、ある程度の柔軟性を有し得る。こうして、全てのUEのサブセットにリソースを半排他的に予約することにより、スペクトル効率を向上させることができる。複数のUE間で、半排他的に予約済みリソースが再利用されることがあり得る。
DL制御メッセージ452は、幾つかの例において、正確に予約済みリソースを指定しない場合がある。むしろ、DL制御メッセージ452により示されるタイミング501は、たとえば、上記で説明したように、それぞれの送信フレーム260のシーケンス番号に基づいて、および/またはタイマー初期化値に基づいて、予約済みリソースが発生する時点を指定することができる。次に、UE102によって使用されるべき特定の予約済みリソースが、たとえば、固定されたルールセットに従って事前定義され得る。たとえば、各送信フレーム260-1~260-3において再発する特定の時間-周波数リソース要素258は、そのような優先順位付けされたネットワークアクセスに固定的に関連付けられ得る。次に、UE102は、DL制御メッセージ452によって示されるタイミング501、ならびに固定ルールセットの両方に基づいて、どの特定のリソース要素258を使用すべきかを結論付けることができる。同様の考慮事項が適用され得るのは、UEがコードドメイン内の複数の優先順位付けされた候補プリアンブルシーケンスへのアクセスを与えられ、特定の選択がUE102によって実行される場合である。
更なる例において、DL制御メッセージ452は、正確な予約済みリソースを指定することができる。ここで、DL制御メッセージ452はタイミングを含むことができ、このタイミングは時間ドメイン、周波数ドメイン、およびコードドメインのうちの少なくとも1つで定義された予約リソースを示すスケジューリング情報によって実装され得る。たとえば、このスケジューリング情報は、ネットワークアクセスのプリアンブルシーケンスを示すことができる。スケジューリング情報がリソースグリッド253の時間-周波数リソース要素を示すことも可能である。その後、プリアンブルシーケンスは、スケジューリング情報によって示される時間-周波数リソース要素において通信されることができる。
何れの場合も、予約済みリソース258を提供することにより、5014におけるネットワークアクセスの優先順位付けを達成できる。5014におけるこのようなネットワークアクセスの優先順位付けにより、そうでなければ競合ベースのネットワークアクセスについて発生する時間のかかるバックオフ手順を回避できる。これにより、5017におけるデータ407の通信に関連したエネルギー消費および待ち時間も低減される。
再び図8を参照する。517におけるデータ407の通信に関連したエネルギー消費および待ち時間を更に低減するための技術が利用可能である。即ち、幾つかのシナリオでは、データ407が通信されるべき時点を予測することだけでなく、この予測に基づいて、タイミング501を決定することが可能かもしれない。通信されるデータ407のサイズが予測され得るシナリオも考えられる。たとえば、データ407は、以前に伝達された比較可能なデータに関する履歴情報に基づいて予測され得る。
そこで、データ407の予測サイズに関するそのような情報が利用可能であれば、更なるDL制御メッセージとして5016で通信されるスケジューリング許可456が、この予測サイズに基づくことが可能であろう。具体的には、スケジューリング許可456によって、データ407を通信するためにUE102に割り当てられたリソースは、データ407の予測サイズに基づいて大きさが決定されるであろう。換言すれば、予約済みリソース258は、ネットワーク100によって予測されたデータ407送信の予測サイズに基づいて大きさが決定される。こうして、5017においてデータ407を通信する前、および5014でのネットワークアクセスの後に、UE102がスケジューリング要求をBS101に送信する必要はない。
幾つかの例では、UL制御メッセージ451が5011で通信され、これはデータ407のサイズを示すことが可能である。そのようなシナリオは、特に、データ407がULデータである場合に適用され得る。したがって、UL制御メッセージ451は、データ407の送信の方向性をも示すことが可能であろう。UL制御メッセージ451によって示されるサイズに基づいて、スケジューリング情報が、スケジューリング許可456に含まれ得る。5017でデータ407を通信する前、および5014でのネットワークアクセスの後に、UE102からBS101へのスケジューリング要求の通信を必要としないことにより、データ407の送信までの待ち時間が更に短縮される。
ネットワーク、具体的にはBS101がデータ407の予測サイズに関する知識を持っていれば(これは特に、当該データがDLデータであるシナリオに適用される)は、UL制御メッセージ451がサイズを示すことは要求されない。
図8は、スケジューリング許可456が5066で送信されるシナリオを示している。他の例では、DL制御メッセージ452は、5017でのデータ送信407に使用される更なる予約リソースのスケジューリング情報を既に含む可能性があるであろう。これは待ち時間を更に減少させる。
図8は、アイドルモード304においてUE102を動作させている間に、UEモビリティが発生しないシナリオである。しかし、アイドルモード304でUE102を動作させている間に、UEモビリティが発生するシナリオが考えられる。そのようなシナリオが図10に関連して示される。
図10は、UE102とBS101との間の通信を示すシグナリング図である。図10のシグナリング図はまた、UE102とBS105との間の通信を示す。BS101、105は、セルラーネットワーク100の異なるセルに関連付けられる。
シナリオ図10は、一般的には図8のシナリオに対応する。しかし、シナリオ図10では、アイドルモード304でUE102を動作させている間に、UEのモビリティが発生する。換言すれば、UE102はBS101に関連付けられたセルから、BS105に関連付けられたセルへと移動する。これは、最初はBS101に関連付けられたセルに滞在しており、次いでBS105に関連付けられたセルに滞在するUE102を指称し得る。
このモビリティを説明するために、5060において、スケジューリング制御メッセージ460がBS105によって送信され、BS101によって受信されるとする。スケジューリング制御メッセージ460は、予約済みリソースのタイミングを示し、当該リソースはBS105によって予約される。たとえば、スケジューリング制御メッセージ460が既に、5062において次に送信されるDL制御メッセージ452の中に含められるべきスケジューリング情報を含んでいることが可能であろう。一般に、5062は5012に対応することができる。タイミング501の指示に加えて、DL制御メッセージ452はまた、BS105の需要に関連する識別情報(たとえば、一意のセル識別子)を含むことが可能である。したがって、UE102は、どの特定のBS105が、DL制御メッセージ452に示されるタイミングに関連付けられた予約済みリソースを提供するかを知ることができる。
BS101は、BS105によっても予約された同じリソースを予約してよく、または予約しなくてもよい。
5063は、一般に5013に対応する。ここでは、BS101に関連付けられたセルを介した、UE102とネットワーク100との間のデータ接続160は解除される。次に、UEのモビリティが生じる。UE102は、BS105に関連付けられたセルのカバレッジに移動する。
次に、5065において、UE102によるBS105へのプリアンブルシーケンスの送信を含んだ、ネットワークアクセス454が実行される。その後、BS105は、5066においてRA応答メッセージ455で応答し、その後、BS105に関連付けられたセルを介して、UE102とネットワーク100の間でデータ接続160が確立される。
したがって、5065におけるUE102からBS105へのRAプリアンブル455の通信もまた、図8に関連して上記で説明したようにして優先付けすることができる。5066は5015に対応する。5067は5016に対応する。5068は5017に対応する。
図10から理解されるように、ここでは、5062よりも前のネットワーク100とのデータ接続を使用して、UE102からBS101へとUL制御メッセージ451は通信されない。しかしながら、UL制御メッセージ451がUE102からBS101へと通信されることは、可能である。したがって、当該UL制御メッセージ451に含まれる任意の情報(一般に、図8に関連して上述したUL制御メッセージ451に対応し得る)は、BS101によってBS105に転送され得る。次いで、BS105は、BS101によって転送されたそのような情報に基づいて、スケジューリング制御メッセージ460によって示されたタイミングを決定することができる。
図11は、様々な例による方法のフローチャートである。たとえば、図11による方法は、メモリ1025と組み合わせて、UE102の制御回路、即ちプロセッサ1021によって実行することができる。たとえば、プログラムコードは、メモリ1025からプロセッサ1021によってロードすることができる(図2を参照のこと)。
プロセッサ1021によるプログラムコードの実行は、プロセッサ1021に、図11の例に従う方法を実行させることができる。図11において、破線はオプションのブロックを示す。
最初に、オプションのブロック8001において、UL制御メッセージが送信される。たとえば、図8の例によるUL制御メッセージ451が送信され得るであろう。UL制御メッセージは、予測される将来のデータ送信のタイミングに関する情報を含み得るため、事前スケジューリング要求と称され得る。したがって、UL制御メッセージは、タイミングに従った、ネットワークアクセスのための1つまたは複数の予約済みリソースについての要求であることができ、それによって、ネットワークアクセスによりデータ接続を適時に確立し、データ送信を容易にする。
任意に、UL制御メッセージは、後続のデータ送信のデータのサイズを示す標識および/または後続のデータ送信の方向性(ULおよび/またはDL)を示す標識をも含むことができる。そのようなオプションの情報は、後続のデータ送信のスケジューリングを容易にすることができ、たとえば、別のスケジューリング要求が必要とされない可能性がある(図8参照、ここでは5014におけるネットワークアクセス454と、5016におけるスケジューリング許可456との間で、追加のスケジューリング要求は要求されない)。
次に、ブロック8002においてDL制御メッセージが受信される。たとえば、図8の例によるDL制御メッセージ452が受信できるであろう。このDL制御メッセージは、ネットワークアクセスのために予約済みリソースのタイミングを示す標識を含み得るため、事前スケジューリング許可と称することができる。詳細に言えば、当該タイミングは、時間ドメインおよび/または周波数ドメインおよび/またはコードドメインおよび/または空間ドメインにおいて、予約済みリソースを明示的に識別するスケジューリング情報に対応する可能性がある。たとえば、当該タイミングは、リソースグリッドの特定の時間-周波数リソース要素を明示的に識別するスケジューリング情報によって実装されてよい。たとえば、スケジューリング情報は、ネットワークアクセスの際に使用されるべきプリアンブルシーケンスを識別する標識を含み得る。その代わりに、またはそれに加えて、当該タイミングは、リソースが予約される時点を示し得る。したがって、当該タイミングには、送信フレームのシーケンス番号、またはリソースが予約された時点までカウントダウンするタイマーの初期値が含まれることが可能であろう。
ブロック8001、8002を実行するとき、それぞれのUEは、コネクテッドモード(図4のコネクテッドモード301、302を参照)にある可能性がある。したがって、データ接続が確立され得る。次に、ブロック8003において、ブロック8002でのDL制御メッセージ、および任意に8001でのUL制御メッセージを通信するために使用されたこのデータ接続が解除される。これには、レイヤ2またはレイヤ3制御シグナリング、たとえば3GPP LTEフレームワークの無線リソース制御(RRC)接続解除メッセージが含まれ得る。したがって、ブロック8003は、アイドル動作モード(図4のアイドルモード303、304を参照)への移行に対応し得る。
ブロック8004では、ネットワークアクセスが実行される。これは、ネットワークとの更なるデータ接続(図3、データ接続160を参照されたい)を確立することを含み得る。ネットワークアクセスには、ランダムアクセスが含まれ得る。ここでは、リソースが半排他的または排他的に予約されているかどうかに応じて、競合ベースまたは非競合ベースのネットワークアクセスが一般的に可能である。したがって、ブロック8004は、コネクテッドモード(図4におけるコネクテッドモード301、302を参照されたい)への移行に対応し得る。
ブロック8003および8004の間で、それぞれのUEの受信機は、データを受信するのに適さない非アクティブ状態(図5の非アクティブ状態383を参照)において継続的、持続的、および連続的に動作し得る。或いは、DRXサイクルが可能であろう。スケジューリングの柔軟性とエネルギー節約との間の望ましいバランスに応じて、UEはページング可能である場合とそうでない場合があり得る。
原則として、特別に予約済みリソースが提供されないシナリオと比較すると、予約済みリソースを提供することにより、ブロック8004でのネットワークアクセスの際の衝突と、それに続くバックアップの可能性を低減できる。したがって、待ち時間および信頼性を向上させることができる。予約済みリソースは、少なくとも1つの更なるUEによるアクセスを阻止することができる。
最後に、ブロック8005においてデータ送信が実施される。たとえば、ブロック8005において、受信されたDLデータおよび/またはULデータは、ネットワークアクセスに関連してブロック8004で確立されたデータ接続を使用して送信されてよい。
ブロック8005におけるデータ送信は、スケジューリング許可により示されるリソースを使用して実装することができる。たとえば、専用のスケジューリング許可が、ブロック8004と8005との間で受信され得る(図8、スケジューリング許可456を参照のこと)。或いは、ブロック8002で受信されたDL制御メッセージが、既にそれぞれのスケジューリング情報を含んでいることも可能であろう。
図12は、様々な例による方法のフローチャートである。たとえば、図12による方法は、BS101の制御回路、即ち、メモリ1015と組み合わせたプロセッサ1011(図2参照)によって実行することができる。たとえば、プログラムコードは、プロセッサ1011によってメモリ1025からロードされ得る。プロセッサ1011によるプログラムコードの実行は、プロセッサ1011に対して、図12の例による方法を実行させることができる。図12において、破線はオプションのブロックを示す。
オプションのブロック8011では、UL制御メッセージが受信される。ブロック8011は、ブロック8001と相互に関連している。
次に、これもオプションであるブロック8012において、第1のスケジューリング制御メッセージが送信される。たとえば、第1のスケジューリング制御メッセージは、たとえば、隣接セルに関連付けられた1つまたは複数の基地局に送信され得る。第1のスケジューリング制御メッセージは、ブロック8011で受信されたUL制御メッセージとともに提供される情報を含み得る。そのような情報は、将来のデータ送信に関連したタイミングに関する情報、データ送信のサイズに関する情報、および/またはデータ送信の方向性に関する情報を含み得る。たとえば、第1のスケジューリング制御メッセージが、ブロック8011において、そこからUL制御メッセージが受信されるUEの識別、および/またはUEに関連するユーザの身元を含むことも可能である。
次に、これもオプションのブロックであるブロック8013では、第2のスケジューリング制御メッセージが受信される(たとえば、第2のスケジューリング制御メッセージは、図10のスケジューリング制御メッセージ460に対応し得る)。たとえば、第2のスケジューリング制御メッセージは、ブロック8012において、第1のスケジューリング制御メッセージが送信された1つまたは複数の基地局のうちの少なくとも1つから受信され得る。
詳細に言えば、ブロック8013で受信された第2のスケジューリング制御メッセージは、ブロック8012で送信された第1のスケジューリング制御メッセージに応答するものであり得る。
スケジューリング制御メッセージは、ブロック8014において送信されたDL制御メッセージに後で含まれる情報を含み得る。ブロック8014は、ブロック8002と相互に関連している。したがって、ブロック8013で受信された第2のスケジューリング制御メッセージは、ブロック8013において、第2のスケジューリング制御メッセージがそこから受信されるそれぞれの基地局によって予約済みリソースのタイミングを示す標識を含み得る。
8015においては、それを介してDL制御メッセージが8014で送信されており、またそれを介して、任意にUL制御メッセージがブロック8011で受信されているデータ接続が解除される。ブロック8015は、ブロック8003と相互に関連する。
オプションのブロック8016はブロック8004に対応する。オプションのブロック8017はブロック8005に対応する。
要約すると、意図された将来のデータ送信のタイミングを示す上記技術が開示されてきた。具体的に言えば、データ送信を容易にするために、UEによるネットワークアクセスを優先付けする技術が開示されてきた。これは、様々な例に従って、ネットワークアクセスのための予約済みリソースのタイミングを示す、DL制御メッセージを通信することによって達成される。たとえば、当該タイミングは、予約済みリソースに関連付けられたタイムスタンプに対応し得る。このタイミングは、送信フレーム番号またはタイマー値等を含み得る。任意に、DL制御メッセージは、予約済みリソースに関する情報、即ち、スケジューリング情報を含み得る。スケジューリング情報は、リソースグリッドの時間-周波数リソース要素を示し得る。任意に、DL制御メッセージは、意図されたデータ送信のサイズおよび/または意図されたデータ送信の方向性を示し得る。たとえば、本明細書で説明される様々なシナリオでは、サイズはリソース要素に関して、またはバイトに関して表現され得る。任意に、DL制御メッセージには、ネットワークアクセス用にリソースが予約されている特定のセルに関連付けられたセル同一性を含めることができる。これは、UEモビリティシナリオに対処するのに役立つ。
DL制御メッセージは、たとえばUL制御メッセージに応じた応答として送信されてもよく、またはネットワークにより開始されてもよい。たとえば、意図されたデータ送信のサイズおよび/または意図されたデータ送信のタイミングおよび/または(意図されたデータ送信の)方向性は、UL制御メッセージによって、UEにより要求され得る。
DL制御メッセージの受信に応答して、UEは通信を継続し、最終的にはアイドルモードに入ることができる。アイドルモードに移行するためのレガシー手順、たとえば、非アクティブタイマーの実装などを採用することができる。DL制御メッセージによって示されるタイミングに従って、UEは、予約済みリソースを使用してネットワークアクセスを実行することが予測される。ここでは、予約済みリソースに基づいて、非競合ベースのアクセス手順を使用することができる。データ接続が再度確立されると、データはULおよび/またはDL送信用にスケジュールされる。このスケジューリングは、UL制御メッセージおよび/またはDL制御メッセージで以前に示されたサイズに基づくことができる。これにより、UEからネットワークへと更にスケジューリング要求を送信する必要がなくなる。データのスケジューリング情報を送信するために、レガシー手順を採用することが一般に可能である。
上記で提示したような技術は、アプリケーションの応答時間を調整することを可能にする一方で、UEが、その後のデータ送信の間の非アクティブ状態において、そのインターフェースを操作できるようにする。アプリケーションの応答待ち時間とUEのエネルギー消費量との間のバランス調整を達成できる。
そのような技術は、バッテリー駆動のIOTデバイスに適用され得るものであり、この場合は、特に、個々のデータ送信のサイズが比較的小さく、且つアイドルモードへの移行が保証されるように応答を待つための時間が比較的長い。
本発明を特定の好ましい実施形態に関して示し、且つ説明してきたが、本明細書を読んで理解したときに、当業者には均等物および改変が思い浮かぶであろう。本発明は、そのような均等物および改変の全てを包含し、添付の特許請求の範囲によってのみ制限されるものである。
たとえば、上記の様々なシナリオが3GPP LTEネットワークの文脈で説明されてきたが、同様の技術は、3GPP NRネットワークまたは別の種類またはタイプのネットワークとの関連においても容易に適用され得るものである。