IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ アップル インコーポレイテッドの特許一覧

<>
  • 特許-制御チャネルの監視なしのデータ受信 図1
  • 特許-制御チャネルの監視なしのデータ受信 図2
  • 特許-制御チャネルの監視なしのデータ受信 図3
  • 特許-制御チャネルの監視なしのデータ受信 図4
  • 特許-制御チャネルの監視なしのデータ受信 図5
  • 特許-制御チャネルの監視なしのデータ受信 図6
  • 特許-制御チャネルの監視なしのデータ受信 図7
  • 特許-制御チャネルの監視なしのデータ受信 図8
  • 特許-制御チャネルの監視なしのデータ受信 図9
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-02-06
(45)【発行日】2024-02-15
(54)【発明の名称】制御チャネルの監視なしのデータ受信
(51)【国際特許分類】
   H04W 76/27 20180101AFI20240207BHJP
   H04W 8/22 20090101ALI20240207BHJP
   H04W 68/00 20090101ALI20240207BHJP
   H04W 74/08 20240101ALI20240207BHJP
   H04W 52/02 20090101ALI20240207BHJP
【FI】
H04W76/27
H04W8/22
H04W68/00
H04W74/08
H04W52/02 110
【請求項の数】 17
(21)【出願番号】P 2022548919
(86)(22)【出願日】2020-02-12
(65)【公表番号】
(43)【公表日】2023-04-05
(86)【国際出願番号】 CN2020074917
(87)【国際公開番号】W WO2021159327
(87)【国際公開日】2021-08-19
【審査請求日】2022-08-12
(73)【特許権者】
【識別番号】503260918
【氏名又は名称】アップル インコーポレイテッド
【氏名又は名称原語表記】Apple Inc.
【住所又は居所原語表記】One Apple Park Way,Cupertino, California 95014, U.S.A.
(74)【代理人】
【識別番号】100094569
【弁理士】
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100103610
【弁理士】
【氏名又は名称】▲吉▼田 和彦
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100086771
【弁理士】
【氏名又は名称】西島 孝喜
(74)【代理人】
【識別番号】100139712
【弁理士】
【氏名又は名称】那須 威夫
(74)【代理人】
【識別番号】100170209
【弁理士】
【氏名又は名称】林 陽和
(72)【発明者】
【氏名】シュ ファンリ
(72)【発明者】
【氏名】バンガラ サルマ ヴイ
(72)【発明者】
【氏名】チャン ダウェイ
(72)【発明者】
【氏名】フ ハイジン
(72)【発明者】
【氏名】シカリ ムルタザ エイ
(72)【発明者】
【氏名】グルムーシー セチュラマン
(72)【発明者】
【氏名】ロブレカール スリラン エイ
(72)【発明者】
【氏名】ゼン ウェイ
(72)【発明者】
【氏名】キム ユチュル
(72)【発明者】
【氏名】チェン ユチン
(72)【発明者】
【氏名】ウー ジビン
【審査官】青木 健
(56)【参考文献】
【文献】特表2017-510124(JP,A)
【文献】特表2010-524329(JP,A)
【文献】特表2020-504536(JP,A)
【文献】Apple,UE assistance information,3GPP TSG RAN WG2 #105 R2-1901838,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_105/Docs/R2-1901838.zip>,2019年02月15日
(58)【調査した分野】(Int.Cl.,DB名)
H04W 4/00 - 99/00
H04B 7/24 - 7/26
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1,4
(57)【特許請求の範囲】
【請求項1】
ネットワークに接続されたユーザ機器(UE)において、
前記ネットワークからデータを受信するアプリケーションを実行することと、
UE支援情報を前記ネットワークに伝送することであって、前記UE支援情報は、前記アプリケーションのために前記ネットワークから受信する前記データのトラフィックパターンに対応していることと、
無線リソース制御(RRC)非アクティブ状態に入ることと、
物理ダウンリンク制御チャネル(PDCCH)を監視することなく前記RRC非アクティブ状態中に前記ネットワークから前記データを受信することと、
を含む、方法。
【請求項2】
前記UE支援情報は、ランダムアクセスチャネル(RACH)要求内で伝送される、請求項1に記載の方法。
【請求項3】
前記UEが前記ネットワークとのRRC接続状態にあるときに、前記UE支援情報は伝送される、請求項1に記載の方法。
【請求項4】
前記アプリケーションに関連付けられた前記トラフィックパターンを判定することを更に含む、請求項1に記載の方法。
【請求項5】
前記アプリケーションはストリーミングアプリケーションである、請求項1に記載の方法。
【請求項6】
第2のアプリケーションを実行することと、
前記UEが前記RRC非アクティブ状態にあるときに、前記第2のアプリケーションのための入力データ伝送を前記アプリケーションのための前記データの受信とアラインすることと、
を更に含む、請求項1に記載の方法。
【請求項7】
前記UEが前記ネットワークと同期していないことを判定することと、
前記UEが前記ネットワークと同期していないときにタイマを開始することであって、前記UEは前記タイマの長さの間、RRC接続状態のままにすることと、
前記ネットワークからのダウンリンクデータ伝送のために前記タイマの前記長さの間に制御チャネルを監視することと、
前記タイマが満了するときに前記RRC非アクティブ状態に遷移することと、
を更に含む、請求項1に記載の方法。
【請求項8】
ネットワークと通信するように構成された送受信機と、
動作を実行するように構成されたプロセッサとを備え、前記動作は、
前記ネットワークからデータを受信するアプリケーションを実行することと、
UE支援情報を前記ネットワークに伝送することであって、前記UE支援情報は、前記アプリケーションのために前記ネットワークから受信する前記データのトラフィックパターンに対応していることと、
無線リソース制御(RRC)非アクティブ状態に入ることと、
物理ダウンリンク制御チャネル(PDCCH)を監視することなく前記RRC非アクティブ状態中に前記ネットワークから前記データを受信することと、
を含む、ユーザ機器(UE)。
【請求項9】
前記UE支援情報は、ランダムアクセスチャネル(RACH)要求内で伝送される、請求項に記載のUE。
【請求項10】
前記UEが前記ネットワークとのRRC接続状態にあるときに、前記UE支援情報は伝送される、請求項に記載のUE。
【請求項11】
前記動作は、前記アプリケーションに関連付けられた前記トラフィックパターンを判定することを更に含む、請求項に記載のUE。
【請求項12】
前記プロセッサは、アプリケーションプロセッサとベースバンドプロセッサを含み、前記アプリケーションプロセッサは前記アプリケーションを実行する、請求項に記載のUE。
【請求項13】
前記動作は、
第2のアプリケーションを実行することと、
前記UEが前記RRC非アクティブ状態にあるときに、前記第2のアプリケーションの入力データ伝送を前記アプリケーションのための前記データの受信とアラインすることと、を更に含む、請求項に記載のUE。
【請求項14】
前記動作は、
前記UEが前記ネットワークと同期していないことを判定することと、
前記UEが前記ネットワークと同期していないときにタイマを開始することであって、前記UEは前記タイマの長さの間、RRC接続状態のままにすることと、
前記ネットワークからのダウンリンクデータ伝送のために前記タイマの前記長さの間に制御チャネルを監視することと、
前記タイマが満了するときに前記RRC非アクティブ状態に遷移することと、
を更に含む、請求項に記載のUE。
【請求項15】
UE支援情報をネットワークに伝送するように構成された回路であって、前記UE支援情報は、アプリケーションのために前記ネットワークから受信するデータのトラフィックパターンに対応している回路と、
無線リソース制御(RRC)非アクティブ状態に入るように構成された回路と、
物理ダウンリンク制御チャネル(PDCCH)を監視することなく前記RRC非アクティブ状態中に前記ネットワークから前記データを受信するように構成された回路と、
を備える、集積回路。
【請求項16】
前記UE支援情報は、ランダムアクセスチャネル(RACH)要求内で伝送される、請求項15に記載の集積回路。
【請求項17】
前記UE支援情報は、前記ネットワークとのRRC接続状態の間に伝送される、請求項15に記載の集積回路。
【発明の詳細な説明】
【背景技術】
【0001】
ユーザ機器(UE)は、ネットワーク(例えば、ロングタームエボリューション(LTE)ネットワーク、5G新無線(NR)ネットワークなど)に接続することができる。ネットワークに接続されると、UEは、UE上で実行中の様々なアプリケーションに関連するネットワークからのデータを受信することができる。場合によっては、このデータは、音声又はビデオリアルタイムHTTPトラフィックであり得る。実際、現在、40%~50%のセルラーデータトラフィックがこのタイプのトラフィックであると推定され、より多くのユーザがオーディオコンテンツ及びビデオコンテンツをモバイルデバイスにストリーミングするにつれて、数が経時的に増大すると推定される。
【0002】
このトラフィックをサポートするために、UEは、新しいデータの到着を予想してチャネルを維持するために電力を連続的に使用している。具体的には、UEは、物理ダウンリンク制御チャネル(PDCCH)を監視し、DLトラフィックがネットワークによって送信されている時を判定しなければならない。DRX(不連続受信)などの節電を試みるために開発されてきたいくつかの技法がある。しかし、これらの技法は、ストリーミング動作中のUEのバッテリ寿命を有意な量まで拡張していない。加えて、UEがより大きな周波数範囲を監視しなければならないことになるため、5G NRでは、これらの動作中に消費電力が大幅に増えることが予想される。
【発明の概要】
【0003】
いくつかの例示的な実施形態によれば、方法は、ネットワークに接続されたユーザ機器(UE)によって実行される。方法は、ネットワークからデータを受信するアプリケーションを実行することと、UE支援情報をネットワークに伝送することであって、UE支援情報はアプリケーションのためにネットワークから受信されるデータのトラフィックパターンに対応していることと、無線リソース制御(RRC)非アクティブ状態に入ることと、RRC非アクティブ状態中にネットワークからデータを受信することと、を含む。
【0004】
更なる例示的な実施形態は、送受信機及びプロセッサを有するユーザ機器(UE)を備える。送受信機は、ネットワークと通信するように構成されている。プロセッサは、ネットワークからデータを受信するアプリケーションを実行することと、UE支援情報をネットワークに伝送することであって、UE支援情報は、アプリケーションのためにネットワークから受信されるデータのトラフィックパターンに対応していることと、無線リソース制御(RRC)非アクティブ状態に入ることと、RRC非アクティブ状態中にネットワークからデータを受信することとを含む動作を実行するように構成されている。
【0005】
更なる例示的な実施形態は、UE支援情報をネットワークに伝送するように構成された回路であって、UE支援情報は、アプリケーションのためにネットワークから受信されるデータのトラフィックパターンに対応している回路と、無線リソース制御(RRC)非アクティブ状態に入るように構成された回路と、RRC非アクティブ状態にある間にネットワークからデータを受信するように構成された回路と、を有する集積回路を含む。
【図面の簡単な説明】
【0006】
図1】様々な例示的な実施形態による例示的なネットワーク配置(network arrangement)を示す図である。
図2】様々な例示的な実施形態による例示的なUEを示す。
図3】データトラフィックパターンと、当該トラフィックパターンに使用される現在のPDCCH監視を示す。
図4】様々な例示的な実施形態による、UEがRRC非アクティブ状態でネットワークからDLトラフィックを受信することを可能にする第1の例示的なシグナリング図を示す。
図5】様々な例示的な実施形態による、UEがRRC非アクティブ状態でネットワークからDLトラフィックを受信することを可能にする第2の例示的なシグナリング図を示す。
図6】様々な例示的な実施形態による、UEがRRC非アクティブ状態でネットワークからDLトラフィックを受信することを可能にする第3の例示的なシグナリング図を示す。
図7】様々な例示的な実施形態による、UEがRRC非アクティブ状態でネットワークからDLトラフィックを受信することを可能にする第4の例示的なシグナリング図を示す。
図8】様々な例示的な実施形態による、UEがRRC非アクティブ状態でネットワークからDLトラフィックを受信することを可能にする第5の例示的なシグナリング図を示す。
図9】様々な例示的な実施形態による、UEがRRC非アクティブ状態でネットワークからDLトラフィックを受信することを可能にする第6の例示的なシグナリング図を示す。
【発明を実施するための形態】
【0007】
例示的な実施形態は、以下の説明及び関係する添付の図面を参照して更に理解することができ、同様の要素は、同じ参照番号が付されている。例示的な実施形態は、物理ダウンリンク制御チャネル(PDCCH)を監視する必要なしにネットワークからデータを受信することに関する。より具体的には、例示的な実施形態は、DLデータを受信するときにUEをRRC非アクティブ状態のままにすることが可能になる。UEはRRC非アクティブ状態のままになるため、UEはPDCCHを監視する必要はないので、監視に関連付けられた電力を節約する。
【0008】
本明細書全体を通して、「DLデータ」及び「ストリーミングデータ」という用語は、ネットワークからUEに送信されているデータを指すために交換可能的に使用される。例示的な実施形態は、オーディオ及び/又はビデオストリーミングデータに関して説明されているが、当業者であれば、例示的な実施形態が任意のタイプのデータのダウンリンク(DL)中に使用され得ることを理解するであろう。以下でより詳細に説明するように、例示的な実施形態は、DLデータトラフィックパターンが概して予測可能であるときに使用され得る。
【0009】
加えて、本明細書全体を通して、例示的な実施形態は、ダウンリンク(DL)データ、例えば、ネットワークからUEに送信されるデータを参照して説明される。しかし、当業者であれば、例示的な実施形態がアップリンク(UL)、例えば、UEからネットワークに送信されるデータにも適用され得ることを理解するであろう。当業者であれば、例示的な実施形態をULに実装するための変形を理解するであろう。
【0010】
例示的な実施形態は、UEに関して説明されている。しかし、UEの使用は、単に例示目的で提供されているにすぎない。例示的な実施形態は、ネットワークと情報(例えば、制御情報)及び/又はデータをやりとりするためのハードウェア、ソフトウェア、及び/又はファームウェアで構成されている任意の電子コンポーネントと共に使用されてもよい。したがって、本明細書に記載されるUEは、任意の好適な電子デバイスを表すために使用される。
【0011】
加えて、例示的な実施形態は、LTE又は5G NRネットワークであるネットワークを参照して説明される。しかし、例示的な実施形態は、LTE及び/又は5G NRネットワークについて本明細書に記載する動作の原理に従って、任意のネットワーク(セルラー又は非セルラ)で実装され得ることを理解されたい。
【0012】
また、例示的な実施形態は、PDCCHに関しても説明されている。LTE及び5G NRでは、PDCCHは、ネットワークからUEにダウンリンク制御情報(DCI)を搬送する。例えば、PDCCHは、いつ(時間)及びどこで(周波数)DLトラフィックがUEに送信されているかを理解するための情報をUEに提供する。例示的な実施形態がLTE及び/又は5Gネットワークを参照して説明されているときに、PDCCHという用語が使用されることを理解されたい。他のタイプのネットワークは、異なる名称によって説明される同様の概念を有し得る。例示的な実施形態の文脈において、PDCCHの監視は、DLデータに関して排除されているか、又は大幅に低減されている。
【0013】
図1は、様々な例示的な実施形態による例示的なネットワーク配置100を示す。例示的なネットワーク配置100はUE110を含む。当業者であれば、UE110が、ネットワークを介して通信するように構成された任意のタイプの電子コンポーネント、例えば、接続された車のコンポーネント、携帯電話、タブレットコンピュータ、スマートフォン、ファブレット、埋め込みデバイス、ウェアラブル、IoT(Internet of Things)デバイスなどであってもよいことを理解するであろう。また、実際のネットワーク配置は、任意の数のユーザによって使用されている任意の数のUEを含み得ることを理解されたい。したがって、一つのUE110の例は、単に例示目的で提供されているにすぎない。
【0014】
UE110は、1つ以上のネットワークと直接通信することができる。ネットワーク構成100の例では、UE110が無線通信し得るネットワークは、5G NR無線アクセスネットワーク(5G NR-RAN)120、LTE無線アクセスネットワーク(LTE-RAN)122及び無線ローカルアクセスネットワーク(WLAN)124である。UE110はまた、他のタイプのネットワークと通信してもよく、UE110はまた、有線接続を介してネットワークと通信してもよい。したがって、UE110は、5G NR-RAN120と通信するために5G NRチップセットを含んでもよく、LTE-RAN122と通信するためにLTEチップセットを含んでもよく、及びWLAN124と通信するためにISMチップセットを含んでもよい。
【0015】
5G NR-RAN120及びLTE-RAN122は、セルラープロバイダ(例えば、Verizon、AT&T、Sprint、T-Mobileなど)によって配備され得るセルラーネットワークの一部であってもよい。これらのネットワーク120、122は、例えば、適切なセルラーチップセットを備えるUEからトラフィックを送受信するように構成されているセル又は基地局(NodeB、eNodeB、HeNB、eNBS、gNB、gNodeB、マクロセル、マイクロセル、スモールセル、フェムトセルなど)を含んでもよい。WLAN124は、任意のタイプの無線ローカルエリアネットワーク(WiFi、ホットスポット、IEEE 802.11xネットワークなど)を含んでもよい。
【0016】
UE110は、gNB120Aを介して5G NR-RANに接続することができる。gNB120Aは、マッシブマイモ(multiple in multiple out、MIMO)機能を実行するために必要なハードウェア(例えば、アンテナアレイ)、ソフトウェア、及び/又はファームウェアで構成されてもよい。マッシブMIMOとは、複数のUEについて複数のビームを生成するように構成されている基地局を指し得る。単一のgNB120Aへの言及は単に例示のためである。例示的な実施形態は、任意の適切な数のgNBに適用されてもよい。UE110はまた、eNB122Aを介してLTE-RAN122に接続することができる。
【0017】
当業者であれば、UE110が5G NR-RAN120及びLTE-RAN122に接続するために、任意の関連付け手順が実行され得ることが理解されよう。例えば、上記のように、5G NR-RAN120及びLTE-RAN122は、UE110及び/又はそのユーザが(例えば、SIMカード上に記憶された)契約情報及び認証情報を有する特定のセルラープロバイダに関連付けられてもよい。5G NR-RAN120の存在を検出すると、UE110は、5G NR-RAN120と関連付けるために、対応する認証情報を伝送してもよい。より具体的には、UE110は、特定の基地局(例えば、5G NR-RAN120のgNB120A、LTE-RAN122のeNB122A)に関連付けられてもよい。
【0018】
ネットワーク120、122及び124に加えて、ネットワーク配置100はまた、セルラーコアネットワーク130、インターネット140、IPマルチメディアサブシステム(IP Multimedia Subsystem、IMS)150、及びネットワークサービスバックボーン160を含む。セルラーコアネットワーク130は、セルラーネットワークの動作及びトラフィックを管理するコンポーネントからなる相互接続されたセットであると考えることができる。セルラーコアネットワーク130はまた、セルラーネットワークとインターネット140との間を流れるトラフィックを管理する。IMS150は、一般に、IPプロトコルを使用してマルチメディアサービスをUE110に配信するためのアーキテクチャとして説明され得る。IMS150は、セルラーコアネットワーク130及びインターネット140と通信し、マルチメディアサービスをUE110に提供することができる。ネットワークサービスバックボーン160は、インターネット140及びセルラーコアネットワーク130と直接的又は間接的に通信する。ネットワークサービスバックボーン160は、一般に、様々なネットワークと通信するUE110の機能を拡張するために使用され得るサービスの一式を実装するコンポーネント(例えば、サーバ、ネットワーク記憶装置(network storage arrangement)など)からなるセットとして説明され得る。
【0019】
UE110は、複数の異なる動作状態のうちの1つにあるように構成され得る。1つの動作状態はRRCアイドル状態として特徴付けられてもよく、別の動作状態はRRC非アクティブ状態として特徴付けられてもよく、また別の動作状態はRRC接続状態として特徴付けられてもよい。RRCは、無線リソース制御(RRC)プロトコルを指す。当業者であれば、UE110がRRC接続状態にある場合に、UE110並びに5G NR-RAN120及び/又はLTE-RAN122が、情報及び/又はデータをやりとりするように構成され得ることを理解するであろう。情報及び/又はデータのやりとりは、UE110がネットワーク接続を介して利用可能な機能を実行することを可能にし得る。さらに、当業者であれば、UE110がRRCアイドル状態にある場合に、UE110が一般に、ネットワークによりデータをやりとりせずに、無線リソースがネットワーク内のUE110に割り当てられていないことを理解するであろう。RRC非アクティブ状態では、UE110は、シグナリング及び電力消費を最小限に抑えながらRRC接続を維持する。しかし、UE110がRRCアイドル状態又はRRC非アクティブ状態にある場合には、UE110は、ネットワークによって伝送される情報及び/又はデータを監視することができる。本明細書全体を通して、これらの用語は、一般に、UE110が任意のネットワークに接続された時の状態、また、RRCアイドル、RRC接続、及びRRC非アクティブ状態について上述した特性を呈する状態を説明するために使用されている。以下でより詳細に説明するように、例示的な実施形態は、UE110がRRC非アクティブ状態にあるときにDLトラフィックを受信することを可能にし得る。
【0020】
図2は、様々な例示的な実施形態による例示的なUE110を示す。図1のネットワーク配置100に関して、UE110について説明する。UE110は、プロセッサ205、メモリ配置(memory arrangement)210、表示デバイス215、入力/出力(Input/Output、I/O)デバイス220、送受信機225、及び他のコンポーネント230を含み得る。他のコンポーネント230は、例えば、SIMカード、埋込型SIM(eSIM)、オーディオ入力デバイス、オーディオ出力デバイス、電源、データ取得デバイス、UE110を他の電子デバイスに電気的に接続するためのポートなどを含み得る。
【0021】
プロセッサ205は、UE110の複数のエンジンを実行するように構成され得る。例えば、エンジンは、DLトラフィックエンジン235を含み得る。DLトラフィックエンジン235は、ネットワークとDLトラフィックをコーディネート(coordinate)するために使用され得、UE110をRRC非アクティブ状態のままにさせ、PDCCHを監視せずにDLトラフィックを受信することを可能にする。UE110と、RRC非アクティブ状態中にUE110がDLトラフィックを受信することを容易にするネットワーク(5G NR-RAN120又はLTE-RAN122)との間の様々な例示的なシグナリングを説明するために、複数のシグナリング図が以下に提供される。シグナリングの一部として、UE支援情報をネットワークに提供し、UE110(例えば、DLトラフィックエンジン235)は、UE110がRRC非アクティブ状態でDLデータを受信できるように、ダウンロード用のDLデータをフォーマット化する際にネットワークを支援することができる。シグナリング図を説明するにあたって、UE支援情報を、以下でより詳細に説明する。
【0022】
プロセッサ205によって実行されるアプリケーション(例えばプログラム)である上記のエンジンはそれぞれ、例示に過ぎない。エンジンに関連付けられた機能はまた、UE110の別個の内蔵コンポーネントとして表されてもよいし、又はUE110に結合されたモジュラーコンポーネント、例えば、ファームウェアを有する集積回路若しくは有さない集積回路であってもよい。例えば、集積回路は、信号を受信するための入力回路と、信号及び他の情報を処理するための処理回路と、を含み得る。エンジンはまた、1つのアプリケーション又は別個のアプリケーションとして具現化されてもよい。加えて、いくつかのUEにおいて、プロセッサ205について説明されている機能は、ベースバンドプロセッサ及びアプリケーションプロセッサなどの2つ以上のプロセッサ間で分割されている。例示的な実施形態は、UEのこれらの構成又は他の構成のうちのいずれかで実装されてもよい。
【0023】
メモリ配置210は、UE110によって実行される動作に関するデータを記憶するように構成されたハードウェアコンポーネントであってもよい。表示デバイス215は、データをユーザに示すように構成されたハードウェアコンポーネントであってもよく、I/Oデバイス220は、ユーザが入力を行うことを可能にするハードウェアコンポーネントであってもよい。表示デバイス215及びI/Oデバイス220は、別個のコンポーネントであってもよく、又はタッチスクリーンのように一緒に一体化されてもよい。送受信機225は、5G NR-RAN120、WLAN122などとの接続を確立するように構成されたハードウェアコンポーネントであってもよい。したがって、送受信機225は、様々な異なる周波数又はチャネル(例えば、連続周波数のセット)で動作することができる。
【0024】
図3は、データトラフィックパターン300及び、当該トラフィックパターンに使用される現在のPDCCH監視340の例を示す。上記のように、このデータトラフィックパターンは、UE110にストリーミングされているオーディオデータ及び/又はビデオデータの例である。しかし、上記のように、例示的な実施形態は、このタイプのデータに限定されない。図3の上部グラフ300は、グラフ300の領域310に示すように、バッファリング目的で最初に大きなダウンロードがあることを示している。次いで、データは、無線状態に基づいた所定のパターンでダウンロードされる。このトラフィックパターンは典型的には、短時間のデータバーストであり、その後、何らデータが伝送されない時間が伴う。データバーストは様々な特性を有し得る。例えば、第1のセットのデータバースト320は、最長持続時間データバーストである。データバースト330は、データ量に関しては、ピークデータバーストである。データバーストの残りは、持続時間及びデータの量に関して変化する。
【0025】
下部グラフ340は、RRC接続状態中にデータをダウンロードする従来の方法でのPDCCHの監視を示す。この下部グラフ340から分かるように、DRXが使用されても、UE110はPDCCHを絶えず監視しているので、大量の電力を使用する。対照的に、例示的な実施形態は、DLデータを受信する際に、UE110がPDCCHを監視する必要性を最小限に抑える。例えば、UE110がRRC非アクティブ状態にあるとき(UE110がDLデータを受信しているか、又はDLデータを受信していないかにかかわらず)、UE110は、PDCCHを監視していない。PDCCHを監視する時間を短縮することにより、UE110は、この監視に関連付けられた電力消費を低減させている。
【0026】
図4は、様々な例示的な実施形態による、UE110がRRC非アクティブ状態でネットワーク405からDLトラフィックを受信することを可能にする第1の例示的なシグナリング図400を示す。図4のシグナリング図400では、ネットワーク405は、5G NR-RAN120又はLTE-RAN122のいずれかであると考えることができ、また、UE110は、gNB120A又はeNB122Aのうち1つに接続され得る。図4を参照して説明された例示的な実施形態では、UE支援情報は、ネットワーク405とUE110との間で実行されるランダムアクセスチャネル(RACH)手順中にネットワーク405に提供される。
【0027】
UE110は、最初はRRC非アクティブ状態410にあると考えることができる。以下で説明するように、UE110は、この状態にあるときにDLトラフィックを受信することができる。ネットワーク405は、ページ420をUE110に送信する。ページ410は、指定されたアクション、例えば、ネットワーク405は、UE110に対する音声呼び出しを行った、UE110はスケジューリング要求(SR)をネットワーク405に送信したこと等に応答して送信され得、又は所定のスケジュールされた時間に送信され得る。ネットワーク405は、UE110がRRC非アクティブ状態にあるときにDLデータが送信されていることを理解するために、ネットワーク405は、UE110に、RRC接続状態に入るように定期的に要求して、RRC非アクティブ状態中にDLデータを配信するためのパラメータ(例えば、UE支援情報)が正しいことを保証にすることができる。UE支援情報及びUE支援情報をネットワーク405に提供する方法は、以下でより詳細に論じる。
【0028】
ページ410に応答して、UE110は、RACH要求430をネットワーク405に送信する。RACH要求430は、UE110からの要求であり、ネットワーク405とのRRC接続状態を確立する。当業者であれば、通常RACH要求430で提供される情報を理解するであろう。しかし、RACH要求430で通常提供される情報に加えて、UE110がRRC非アクティブ状態に遷移したときにネットワーク405がデータをUE110に継続してストリーミングすることを可能にするために、追加情報をネットワーク405に提供することができる。この追加情報は、本明細書全体を通してUE支援情報と称される。UE支援情報は、DLデータのためのトラフィックパターンの特性を説明するデータのセットである。上記のように、例示的な実施形態は、UE110がRRC非アクティブ状態にあるときにDLデータを伝送するネットワーク405を対象とする。これらの伝送が成功するためには、ネットワーク405は、UE110が期待するDLデータの伝送方法でDLデータを伝送するべきである。UE110は、UE110上で実行されている特定のアプリケーションのトラフィックパターン、例えば、図3のグラフ300に示されるストリーミングアプリケーションのための例示的なトラフィックパターンを理解するであろう。次いで、UE110は、既知のトラフィックパターンに対応するUE支援情報をネットワーク405に提供することができ、ネットワーク405はUE支援情報に従ってDLデータを配信することができる。アプリケーションのトラフィックパターンを判定する例示的な方法は、以下でより詳細に説明される。
【0029】
UE支援情報は、例えば、RACH要求430に含まれる媒体アクセス制御(MAC)制御要素(CE)に含まれ得る。UE支援情報は、最小許可サイズ、最小許可周波数及び最小許可持続時間を含み得る。これらのパラメータは単なる例示であり、DLデータの送信に関する情報をネットワーク405に提供するために、UE支援情報にも含まれる他のタイプの情報が存在し得ることを理解されたい。図3を参照して上述したように、DLトラフィックパターンは、一般に、UE110によって既知であり得る。したがって、UE110は、UE支援情報をネットワーク405に提供することができ、UE110がRRC非アクティブ状態にあるときにDLデータを受信することを可能にするようにネットワークがDLデータ伝送をフォーマットすることができる。
【0030】
UE支援情報をより詳細に論じる前に、トラフィックパターンは様々な方法で判定され得ることに留意されたい。第1の例では、UE110は、特定のアプリケーション(例えば、ビデオストリーミングサービス)についての経験を有し、アプリケーションの以前の使用に基づいて発生するであろうトラフィックパターンを理解することができる。第2の例では、UE110は、アプリケーションの現在の使用のためのトラフィックパターンを判定する時間に、アプリケーションに通常の方法で(例えば、PDCCHを監視することを含むRRC接続状態を使用して)データをストリーミングすることを可能にすることができ、現在のトラフィックパターンが判定された後に、UE110は、例示的な実施形態を使用するように切り替えることができる。第3の例では、アプリケーションを、アプリケーションタイプにグループ化することができ(例えば、ビデオストリーミングアプリケーションは第1のタイプであってもよく、オーディオストリーミングアプリケーション(ポッドキャスト、音楽ストリーミング)は第2のタイプであってもよい、など)、また、UE110は、各アプリケーションタイプのトラフィックパターンを理解することができる。したがって、アプリケーションが起動されるときに、UE110は、関連したアプリケーションタイプと、当該アプリケーションタイプに関連付けられたトラフィックパターンを理解することができる。第4の例では、UE110は、現在実行されているアプリケーションのトラフィックパターンをクラウドソーシングすることができる。さらに、現在の無線接続の質、ネットワークのタイプなどの他の要因も、アプリケーションのトラフィックパターンに影響を及ぼし得る。
【0031】
したがって、UE110がトラフィックパターンを認識すると、UE110は、例えば、RACH要求430のMAC CEを介して、UE支援情報をネットワーク405に提供することができる。また上記のように、UE支援情報は、最小許可サイズ、最小許可周波数及び最小許可持続時間を含み得る。これらのパラメータが提供され、UE110がデータをリスニングして受信するように、RRC非アクティブ状態にあるときに、ネットワーク405がストリーミングデータをUE110に送信することを可能にする。最小許可サイズは提供され、ネットワーク405がストリーミングデータをUE110に提供するために必要な許可の最小サイズを理解する。例えば、グラフ300に示す例示的なトラフィックパターンが現在のトラフィックパターンであると考えたとすれば、UE110は、図3に示す最大のデータのバーストを収容するように最小許可サイズをデータバースト330として設定することができる。最小許可周波数は、データバーストのそれぞれの間の時間に基づくことがある。最小許可持続時間は、データバーストの最長持続時間に基づくことがある。例えば、図3に示すように、データバースト320は、これらのバーストがデータに関して最大バーストではないとしても、ピーク持続時間を有する。
【0032】
RACH要求430に応答して、ネットワーク405は、UE110がデータをネットワークに伝送するアップリンク(UL)許可を含むRACH応答440を提供することができる。RACH応答440を受信すると、UE110は、RACH応答440で提供されるUL許可(複数可)を使用して、データ450をネットワーク405に送信することができる。ネットワーク405は、HARQ ACK460を提供して、ネットワーク405がデータ450を受信していることを示すことができる。データ450及びHARQ ACK460は、UE110がRRC接続状態にある間に、データ及びHARQ ACKの複数のやりとりが存在し得るため、破線で示されている。ULデータ450が送信及び肯定応答された後、UE110は、RRC非アクティブ状態470に遷移することができる。
【0033】
しかし、UE110はRRC非アクティブ状態470にある間に、ネットワーク405は、RACH要求430でネットワークに提供された情報に基づいて、DLデータ(例えば、ストリーミングデータ)をUE110に継続して伝送することができる。上記のように、RRC非アクティブ状態では、UE110は、RRC接続状態又はRRCアイドル状態の場合よりも、より受動的な方法でネットワーク405を監視し続けることができる。この監視は、PDCCHを監視せずにデータチャネルを監視することを含み得る。UE110は、(例えば、RACH要求430で)UE支援情報をネットワーク405に提供しているため、UE110は、ストリーミングデータのデータバーストがいつネットワーク405によって送信されるかを理解するであろう。したがって、このようにして、UE110は、PDCCHを絶えず監視することによって電力を無駄にする必要なく、RRC非アクティブ状態でDLデータを受信することができる。
【0034】
加えて、上記の例示的な実施形態は、単一のストリーミングアプリケーションを実行するUE110を参照して説明されてきたが、UE110は、他のアプリケーションを同時に動作させていることがあることを理解されたい。例えば、UE110は、ストリーミングアプリケーションと同時にアクティブである電子メールアプリケーション、ナビゲーションアプリケーションなどを有することがある。これらの他のアプリケーションはまた、フォアグラウンドデータ又はバックグラウンドデータを含むDLデータも受信することができる。UE110は、これらの他の実行アプリケーションをストリーミングアプリケーションと提携させる(align)ことができるので、これらのアプリケーションのDLデータもRRC非アクティブ状態中に受信される。UE110は、これらの他のアプリケーションを説明するためのMAC CEで提供されるUE支援情報を変更できること(例えば、最小許可サイズの変更など)を理解されたい。
【0035】
また、例示的な実施形態は、DLデータを受信する際にUE110をRRC非アクティブ状態のままにする必要がないことも理解されたい。例えば、実行アプリケーションのうちの1つ以上がDLデータのRRC接続状態を必要とするため、UE110がRRC接続状態に遷移してDLデータを受信するシナリオが存在し得る。
【0036】
加えて、UE110はまた、ストリーミングアプリケーションが実行中にもUE支援情報を変更することができる。例えば、無線状態は、ストリーミングアプリケーションが実行中にも経時的に変化する場合があり、これによりトラフィックパターンは変更し得る。UE110は、この変更されたトラフィックパターンを判定し、次に利用可能なRACH要求中に更新された追加のデータをネットワーク405に送信して、ネットワーク405がDLデータを配信する方法を変更することができる。したがって、ストリーミングアプリケーションが開始されると、DLデータを配信する方法は静的である必要はない。
【0037】
図5は、様々な例示的な実施形態による、UE110がRRC非アクティブ状態でネットワーク505からDLトラフィックを受信することを可能にする第2の例示的なシグナリング図500を示す。この場合も、ネットワーク405は、5G NR-RAN120又はLTE-RAN122のいずれかであると考えることができ、UE110は、gNB120A又はeNB122Aのうちの1つに接続され得る。シグナリング図500は、ネットワーク405とUE110との間で実行されるRACH手順中に、UE支援情報がネットワーク405に提供されるという点で、シグナリング図400と同様である。RRC非アクティブ状態510、ページ520、及びRACH要求530のためのシグナリングは、シグナリング図400内の対応する信号と同様である。RACH要求530は、UE110のRRC非アクティブ状態中に、ネットワーク505がDLデータを提供するために使用することになるUE支援情報を含むであろう。
【0038】
しかし、この例では、UE110はRACH応答540を受信しない。当業者であれば、例えば、無線チャネルの劣化、干渉、ネットワーク505が元のRACH要求530などを受信していないなどのような、UE110がRACH応答540を受信しない様々な理由があり得ることを理解するであろう。図5の例では、UE110は、RACH要求550をネットワーク505に再伝送する。この再伝送は、例えば、UE支援情報とともにMAC CEを含む、元のRACH要求530と同じ情報を含むであろう。次いで、UE110はRACH応答560を受信でき、シグナリングは図4を参照して上述したのと同じ方法で継続する。この場合も、ネットワーク505がUE110からUE支援情報を受信しているため、ネットワーク505は、RRC非アクティブ状態590中にDLデータを伝送することができる。
【0039】
図6は、様々な例示的な実施形態による、UE110がRRC非アクティブ状態でネットワーク605からDLトラフィックを受信することを可能にする第3の例示的なシグナリング図600を示す。この場合も、ネットワーク605は、5G NR-RAN120又はLTE-RAN122のいずれかであると考えることができ、UE110は、gNB120A又はeNB122Aのうちの1つに接続され得る。図6を参照して説明される例示的な実施形態では、UE支援情報は、UE110がネットワーク605とRRC接続状態にあるときにネットワーク605に提供される。
【0040】
図6では、UE110は最初に、ネットワーク605とRRC接続状態にあると考えることができる。RRC接続状態中は、UE110は、ネットワーク605とデータをやりとりすることができる。このデータのやりとりの一部として、UE110は、UE支援情報メッセージ610でUE支援情報をネットワーク605に提供することができる。しかし、UE110は、ネットワーク605とのRRC接続状態中にやりとりされる任意のメッセージの一部として、UE支援情報を提供することができることを理解されたい。UE支援情報は、シグナリング図400を参照して上述したものと同じであってもよいが、例えば、図4のRACH手順中とは対照的に、RRC接続状態中の様々な時間に配信される。
【0041】
次いで、UE110は、RRC非アクティブ状態620に遷移することができる。RRC非アクティブ状態中に、ネットワーク605は、以前のRRC接続状態中に提供されるUE支援情報に基づいて、DLデータをUE110に伝送することができる。後になって、UE110は、ネットワーク605と更に情報をやりとりするために、RRC接続状態に入ることを望む場合がある。RRC接続状態に入るために、UE110は、RACH要求630をネットワーク605に伝送する。UE支援情報は、最後のRRC接続状態中に事前に伝送されていたため、RACH要求630は、シグナリング図400で行われたようにUE支援情報を含まなくてもよい。
【0042】
ネットワーク605は、UE110に対してアップリンクグラント(複数可)を含むRACH応答640を伝送し、UE110はRRC接続状態に入る。RRC接続状態中に、UE110は、データ650をネットワーク605に伝送し、HARQ ACK660を受信して、データ650がネットワーク605によって受信されたことを確認する。データ650の伝送が完了すると、UE110は、RRC非アクティブ状態670に遷移する。この場合も、このRRC非アクティブ状態670の間は、UE110は、UE支援情報に従ってネットワーク605からDLデータの受信を継続することができる。
【0043】
本実施例では、UE110は、(例えば、データ650に関連付けられた)最新のRRC接続状態中の追加UE支援情報を送信しなかったことを理解されたい。したがって、ネットワーク605は、UE支援情報メッセージ610で受信したUE支援情報に従ってDLデータを送信し続ける。しかし、UE110は、(例えば、データのやりとり650に対応する)最新のRRC接続状態中の追加UE支援情報メッセージを送信して、UE支援情報を変更することができる。したがって、ネットワーク605がRRC非アクティブ状態670中にDLデータを伝送する場合、ネットワーク605は、新たに受信したUE支援情報に従ってDLデータを送信することができる。
【0044】
図7は、様々な例示的な実施形態による、UE110がRRC非アクティブ状態でネットワーク705からDLトラフィックを受信することを可能にする第4の例示的なシグナリング図700を示す。この場合も、ネットワーク705は、5G NR-RAN120又はLTE-RAN122のいずれかであると考えることができ、UE110は、gNB120A又はeNB122Aのうちの1つに接続され得る。シグナリング図700は、UE110がネットワーク705とRRC接続状態にあるときに、UE支援情報がネットワーク705に提供されるという点でシグナリング図600と同様である。
【0045】
図7では、UE110は最初は、ネットワーク705とRRC接続状態にあると考えることができる。RRC接続状態の間は、UE110は、ネットワーク705とデータをやりとりすることができる。このデータのやりとりの一部として、UE110は、UE支援情報メッセージ710でUE支援情報をネットワーク705に提供することができる。次いで、UE110は、RRC非アクティブ状態720に遷移することができる。RRC非アクティブ状態の間、ネットワーク705は、以前のRRC接続状態中に提供されるUE支援情報に基づいて、DLデータをUE110に伝送することができる。後になって、UE110は、ネットワーク705と更に情報をやりとりするために、RRC接続状態に入ることを望む場合がある。RRC接続状態に入るためには、UE110は、RACH要求730をネットワーク705に伝送することになる。UE支援情報は、最後のRRC接続状態中に事前に伝送されていたため、RACH要求730は、UE支援情報を含まなくてもよい。
【0046】
しかし、この例では、UE110はRACH応答740を受信しない。図7の例では、UE110は、RACH要求750をネットワーク705に再伝送する。次いで、UE110は、RACH応答760を受信でき、シグナリングは図6を参照して上述したのと同じ方法で継続する。この場合も、ネットワーク705は、以前のRRC接続状態中にUE110からUE支援情報(例えば、UE支援情報メッセージ710)を受信しているため、ネットワーク705は、RRC非アクティブ状態790中にDLデータを伝送することができる。
【0047】
図8は、様々な例示的な実施形態による、UE110がRRC非アクティブ状態でネットワーク805からDLトラフィックを受信することを可能にする第5の例示的なシグナリング図800を示す。この場合も、ネットワーク805は、5G NR-RAN120又はLTE-RAN122のいずれかであると考えることができ、UE110は、gNB120A又はeNB122Aのうちの1つに接続され得る。シグナリング図800は、UE支援情報がネットワーク405とUE110との間で実行されるRACH手順中にネットワーク805に提供されるという点でシグナリング図400と同様である。810~860のシグナリングは、シグナリング図400内の対応する信号410~460と同様であり、再び説明しない。
【0048】
上記のように、データ850及びHARQ ACK860は、UE110とネットワーク805との間の複数のやりとりメッセージを含み得る。HARQ ACK860が送信されるたびに、トラッキングエリアコード(TAC)が、HARQ ACKに含まれ得る。UE110はまた、時間アライメントタイマ(Time Alignment Timer:TAT)を含み得る。TATは、TACを受信するたびにリセットされる。TATが満了するときに、UE110は、TATの長さについてネットワーク805からメッセージを受信しておらず、UE110は、現在ネットワーク805と同期していないと想定する。シグナリング図800は、UE110が更なるタイマ870を実装できることを示し、その時間は、UE110とネットワーク805との間で取り決められ得る。UE110がネットワーク805と同期していない場合(同期外れ)880であっても、ネットワーク805は、依然としてUE110にデータを送信することができる。すなわち、UE110は、タイマ870がアクティブである時間中、UE110が同期していない(同期外れ)場合880であっても、RRC接続状態のままなので、UE110はネットワーク805から追加のデータを受信できる。例えば、UE110は、この時間中にPDCCHを監視し、ネットワーク805から追加のDLデータに関する情報を受信することができる。タイマ870が満了すると、UE110は、RRC非アクティブ状態890に遷移し、上記のようにDLデータの受信を継続することができる。
【0049】
図9は、様々な例示的な実施形態による、UE110がRRC非アクティブ状態でネットワーク905からDLトラフィックを受信することを可能にする第6の例示的なシグナリング図900を示す。この場合も、ネットワーク905は、5G NR-RAN120又はLTE-RAN122のいずれかであると考えることができ、UE110は、gNB120A又はeNB122Aのうちの1つに接続され得る。シグナリング図900は、UE110がネットワーク905とRRC接続状態にあるときに、UE支援情報がネットワーク805に提供され、ネットワーク905に提供されるという点で、シグナリング図600と同様である。910~960のシグナリングは、シグナリング図600の対応する信号610~660と同様であり、再び説明しない。
【0050】
シグナリング図800と同様に、シグナリング図900は、UE110が更なるタイマ970を実装することもできることを示し、その時間はUE110とネットワーク905との間で、UE110がネットワーク905と同期していない(同期外れ)980ときに開始されることに取り決められ得る。上記のように、UE110は、タイマ970がアクティブである時間中にUE110が同期していない(同期外れ)980場合であっても、RRC接続状態のままなので、UE110はネットワーク905から追加のデータを受信でき、例えば、UE110は、この時間中にPDCCHを監視し、ネットワーク905から追加のDLデータに関する情報を受信することができる。タイマ970が満了すると、UE110はRRC非アクティブ状態990に遷移し、上記のようにDLデータの受信を継続することができる。
【0051】
シグナリング図400~900は、UEがRRC非アクティブ状態にあるときに、ネットワークがUEにDLデータを伝送することを可能にするために、UE及びネットワークによって使用され得る様々なシグナリングを示す。UEがRRC非アクティブ状態でデータを受信するとき、UEは、PDCCHを監視する必要がなく、このことは、UEは、従来の方法と同様にPDCCHの絶えず続く監視に関連するエネルギーを消費する必要がないことを意味する。
【0052】
上記の例示的な実施形態は、任意の好適なハードウェア構成若しくはソフトウェア構成又はこれらの組み合わせにおいて実装されてもよいことが、当業者には理解されよう。例示的実施形態を実現するための例示的なハードウェアプラットフォームとして、例えば、互換性のあるオペレーティングシステムを有するIntel(登録商標)x86をベースとしたプラットフォーム、Windows OS、Macプラットフォーム及びMAC OS、iOS、Android(登録商標)等のオペレーティングシステムを有するモバイルデバイスを挙げることができる。別の実施例においては、上記の方法の例示的実施形態は、コンパイルされると、プロセッサ又はマイクロプロセッサにおいて実行することができる非一時的コンピュータ可読記憶媒体に記憶されたコード行を含むプログラムとして実行することができる。
【0053】
本出願は、それぞれが様々な組み合わせにおいて異なる特徴を有する様々な実施形態を記載するが、一実施形態の特徴のうちのいずれかは、具体的に否認されない方法で、又は開示された実施形態のデバイスの動作若しくは記載された機能と機能的若しくは論理的に矛盾しない方法で、他の実施形態の特徴と組み合わされてもよいことが、当業者には理解されよう。
【0054】
個人特定可能な情報の使用は、ユーザのプライバシーを維持するための業界又は政府の要件を満たす又は超えると一般に認識されているプライバシーポリシー及びプラクティスに従うべきであることに十分に理解されたい。特に、個人特定可能な情報データは、意図されない又は許可されていないアクセス又は使用のリスクを最小限に抑えるように管理及び取り扱いされるべきであり、許可された使用の性質はユーザに明確に示されるべきである。
【0055】
様々な修正形態が、本開示の精神又は範囲から逸脱することなく本開示においてなされてもよいことが当業者には明らかである。したがって、本開示は、添付の特許請求の範囲及びそれらの均等物の範囲内で、本開示の修正形態及び変形形態を網羅することが意図されている。
図1
図2
図3
図4
図5
図6
図7
図8
図9