CN112019587B - 用于基于网络拥塞的延迟下载的方法、用户装置及介质 - Google Patents

Abstract

本申请涉及基于网络拥塞的延迟下载。本发明公开了为用户装置(UE)调度下载的方式。该UE被配置为建立与网络的连接并接收用户发起的下载的指示，确定要立即执行下载还是在后续时间执行下载，当要在后续时间执行下载时，确定要在其期间发起下载的时间窗口并在该时间窗口期间发起下载。

Description

用于基于网络拥塞的延迟下载的方法、用户装置及介质

技术领域

本申请涉及基于网络拥塞的延迟下载。

背景技术

用户装置(UE)可建立与多个不同网络或网络类型中至少一者的连接。当连接时，UE可从远程端点下载数据。例如，UE可经由网络连接从服务器下载视频文件。在网络拥塞期间，出于多种不同原因中的任何原因，下载可能会停滞并且花费比用户可预期的时间更长的时间。因此，网络拥塞可能不利地影响与UE相关联的用户体验。

发明内容

一些示例性实施方案涉及一种由被配置为建立与网络的连接的用户装置(UE)执行的方法。该方法包括接收用户发起的下载的指示，确定要立即执行下载还是在后续时间执行下载，当要在后续时间执行下载时，确定要在期间发起下载的时间窗口并在该时间窗口期间发起下载。

其他示例性实施方案涉及一种具有收发器和处理器的用户装置(UE)。该收发器被配置为建立与网络的连接。该处理器被配置为接收用户发起的下载的指示，确定要立即执行下载还是在后续时间执行下载，当要在后续时间执行下载时，确定要在在其期间发起下载的时间窗口并在该时间窗口期间发起下载。

另外的示例性实施方案涉及一种包括指令集的非暂态计算机可读存储介质。该指令在由处理器执行时使该处理器执行操作。该操作包括接收用户发起的下载的指示，基于(i)用户输入、(ii)下载的大小或(iii)网络拥塞的指示中的至少一者来确定要立即执行下载还是在后续时间执行下载，当要在后续时间执行下载时，至少基于从运营商接收的信息确定要在其期间发起下载的时间窗口，并且在该时间窗口期间发起下载。

附图说明

图1示出了根据本文所述的各种示例性实施方案的示例性网络布置。

图2示出了根据本文所述的各种示例性实施方案的示例性UE。

图3示出了根据各种示例性实施方案的示例性布置。

图4示出了根据各种示例性实施方案，供UE基于网络拥塞来延迟下载的示例性方法。

图5示出了根据各种示例性实施方案，供UE基于网络拥塞来延迟下载的示例性方法。

具体实施方式

参考以下描述及相关附图可进一步理解示例性实施方案，其中类似的元件具有相同的附图标号。示例性实施方案描述了供用户装置(UE)改善与经由网络连接从远程端点下载数据相关联的用户体验的方式。示例性实施方案避免了与在网络拥塞期间下载数据相关联的成本，同时以方便的方式使得期望的内容可供用户使用。

示例性实施方案是关于UE来描述的。然而，UE的使用仅仅是出于说明的目的。示例性实施方案能够与可建立与网络的连接并且被配置有用于与该网络交换信息和数据的硬件、软件和/或固件的任何电子部件一起利用。因此，本文所述的UE用于代表任何电子部件。

UE可建立与多个不同网络或多种不同类型的网络中的至少一种网络的连接。当网络是蜂窝网络时，UE和网络可经由对应网络的基站进行通信。在一个示例中，网络可以是长期演进(LTE)网络，并且基站可以是演进节点B(eNB)。在另一个示例中，网络可以是5G新无线电(NR)网络，并且基站可以是下一代节点B(gNB)。然而，提供对特定网络或特定类型的基站的参考仅是出于示意性说明的目的。本领域技术人员将理解，网络可为任何类型的网络，并且基站可为对应网络内的任何类型的基站。

还参照UE执行经由网络连接从远程端点下载数据的应用程序来描述示例性实施方案。例如，应用程序可经由网络连接从服务器下载视频文件。然后，视频文件可被存储在UE上并可供用户离线观看。然而，提供对视频文件的提及仅是出于示意性说明的目的。示例性实施方案可应用于经由网络连接下载任何类型的数据的应用程序。

出于多种不同原因中的任何原因，网络拥塞可能导致下载停滞并且花费比用户可预期的时间更长的时间。在整个本说明书中，术语网络拥塞通常可以指这样的场景：所连接的UE的数量和/或由网络交换的数据的量使得网络在特定覆盖区域处的有限硬件、软件、固件和/或射频(RF)资源变得紧张，这可能导致与网络相关联的服务的质量下降。不仅在网络拥塞期间网络资源受限，所连接的UE的存在及其对RF频谱的相应使用可能生成干扰并导致信号冲突。因此，网络拥塞的影响可能会不利地影响与保持和利用网络连接相关的多个不同方面。

从用户的角度来看，网络拥塞是不方便的，因为网络拥塞的不利影响可能会阻止UE在合理的时间量内下载数据。例如，在网络拥塞期间，用户可能必须等待相当长的时间才能完成视频文件的下载。因此，视频文件可能无法供用户在期望的时间观看。网络拥塞的不利影响还可能导致UE经历经由网络连接下载数据的功率和/或处理成本的增加。然而，UE可能无法减轻网络拥塞的不利影响，因为网络拥塞是网络侧的问题，与UE的行为无关。

示例性实施方案涉及将一项或多项下载延迟到网络拥塞很轻微或没有网络拥塞的时间段。因此，虽然UE可能无法减轻网络拥塞的不利影响，但是当存在网络拥塞时，UE可避免通常与执行某些操作相关联的功率和/或处理成本增加。例如，如下所述，基于要下载的文件的大小，可以为用户提供立即下载数据或将下载调度为在预期没有网络拥塞的时间窗口期间发生的选项。一旦(例如，立即或在时间窗口期间)发起下载，UE就可监测关于网络拥塞的指示，然后基于这些指示调节下载的执行。

图1示出了根据各种示例性实施方案的示例性网络布置100。示例性网络布置100包括UE 110。本领域的技术人员将理解，UE 110可为被配置为经由网络通信的任何类型的电子部件，例如，移动电话、平板电脑、台式计算机、智能电话、平板手机、嵌入式设备、可穿戴设备、物联网(IoT)设备等。还应当理解，实际网络布置可包括由任意数量的用户使用的任意数量的UE。因此，出于说明的目的，只提供了具有单个UE 110的示例。

UE 110可被配置为与一个或多个网络直接通信。在网络配置100的示例中，UE 110可与之无线通信的网络是LTE无线电接入网络(LTE-RAN)120、5G新无线电(NR)无线电接入网络(5G NR-RAN)122、传统无线电接入网络(RAN)124和无线本地接入网络(WLAN)126。然而，应当理解，UE 110还可与其他类型的网络通信，并且UE 110还可通过有线连接来与网络通信。因此，UE 110可包括与LTE-RAN 120通信的LTE芯片组、与5G NR-RAN 122通信的5G NR芯片组、与传统RAN 124通信的传统芯片组以及与WLAN 126通信的ISM芯片组。

LTE-RAN 120、5G NR-RAN 122和传统RAN 124可以是可由蜂窝提供商(例如，Verizon、AT&T、Sprint、T-Mobile等)部署的蜂窝网络的部分。这些网络120、122、124可包括例如被配置为从配备有适当蜂窝芯片组的UE发送和接收通信流量的小区或基站(NodeB、eNodeB、HeNB、eNBS、gNB、gNodeB、宏蜂窝基站、微蜂窝基站、小蜂窝基站、毫微微蜂窝基站等)。WLAN 126可包括任何类型的无线局域网(WiFi、热点、IEEE 802.11x网络等)。

UE 110可经由演进节点B(eNB)120A连接到LTE-RAN 120。本领域技术人员将理解，可以执行供UE 110连接至LTE-RAN 120的任何相关过程。例如，如上所讨论，可以使LTE-RAN120与特定的蜂窝提供商相关联，在提供商处，UE 110和/或其用户具有合同和凭据信息(例如，存储在SIM卡上)。一旦检测到了LTE-RAN 120的存在，UE 110就可以传输对应的凭据信息，以便与LTE-RAN 120相关联。更具体地，UE 110可与特定基站(例如，LTE-RAN 120的eNB120A)相关联。如上所述，对LTE-RAN 120的使用是出于示意性说明的目的，并且可使用任何类型的网络。例如，UE 110也可经由下一代节点B(gNB)122A连接至5G NR-RAN 122。

除网络120、122、124和126之外，网络布置100还包括蜂窝核心网130、互联网140、IP多媒体子系统(IMS)150和网络服务主干160。蜂窝核心网130可被视为管理蜂窝网络的操作和流量的部件的互连集合。蜂窝核心网130还管理在蜂窝网络与互联网140之间流动的流量。IMS 150通常可被描述为用于使用IP协议将多媒体服务递送至UE 110的架构。IMS 150可与蜂窝核心网130和互联网140通信以将多媒体服务提供至UE 110。网络服务主干160与互联网140和蜂窝核心网130直接或间接通信。网络服务主干160可通常被描述为一组部件(例如，服务器、网络存储布置等)，其实施一套可用于扩展UE 110与各种网络通信的功能的服务。

图2示出了根据各种示例性实施方案的示例性UE 110。将参照图1的网络布置100来描述UE 110。UE 110可表示任何电子设备，并且可包括处理器205、存储器布置210、显示设备215、输入/输出(I/O)设备220、收发器225以及其他部件230。其他部件230可包括例如音频输入设备、音频输出设备、提供有限功率源的电池、数据采集设备、用于将UE 110电连接到其他电子设备的端口、用于检测UE 110的状况的传感器等。

处理器205可被配置为执行UE 110的多个引擎。例如，引擎可包括延迟下载引擎235。延迟下载引擎235可收集指示何时存在网络拥塞和/或预期存在网络拥塞的信息。基于所收集的信息，延迟下载引擎235可以将下载调度为在不存在网络拥塞的情况期间发生。

上述引擎各自作为由处理器205执行的应用程序(例如，程序)仅是示例性的。与引擎相关联的功能也可被表示为UE 110的独立的结合部件，或者可为耦接到UE 110的模块化部件，例如，具有或不具有固件的集成电路。例如，集成电路可包括用于接收信号的输入电路和用于处理信号和其他信息的处理电路。引擎也可被体现为一个应用程序或分开的多个应用程序。此外，在一些UE中，针对处理器205描述的功能性在两个或更多个处理器诸如基带处理器和应用处理器之间分担。可以按照UE的这些或其他配置中的任何配置实施示例性实施方案。

存储器210可以是被配置为存储与由UE 110执行的操作相关的数据的硬件组件。显示设备215可以是被配置为向用户显示数据的硬件组件，而I/O设备220可以是使得用户能够进行输入的硬件组件。显示设备215和I/O设备220可以是独立的部件或者可被集成在一起(诸如触摸屏)。收发器225可以是被配置为建立与LTE-RAN 120、5G NR-RAN 122、传统RAN 124、WLAN 126等的连接的硬件部件。因此，收发器225可在多个不同的频率或信道(例如，连续频率组)上操作。

当连接到LTE-RAN 120时，UE 110可被配置为处于多种不同的操作状态中的一种。一种操作状态可被表征为RRC空闲状态，并且另一操作状态可被表征为RRC连接状态。RRC是指无线电资源控制(RRC)协议。本领域的技术人员将理解，当UE 110处于RRC连接状态时，UE110和LTE-RAN 120可被配置为交换信息和/或数据。信息和/或数据的交换可允许UE 110执行经由网络连接可用的功能性。此外，本领域的技术人员将理解，当UE 110连接到LTE-RAN120并且处于RRC空闲状态时，UE 110一般不会与网络交换数据，并且在网络内无线电资源未被分配给UE 110。然而，当UE 110处于RRC空闲状态时，UE 110可监测由网络传输的信息和/或数据。本领域的技术人员将理解，RRC空闲状态和连接状态是与LTE网络相关联的术语。在整个此说明书中，这些术语通常用于描述当连接到任何网络时UE 110可处于的状态并且这些状态表现出上文针对RRC空闲状态和RRC连接状态所述的特性。

当UE 110在RRC空闲状态下预占第一网络的第一小区时，UE 110可能无法与网络交换数据。为了与网络交换数据，UE 110可从RRC空闲状态转换到RRC连接状态。例如，当处于RRC空闲状态时，UE 110可侦听诸如但不限于以下的信息：主同步信号(PSS)和辅同步信号(SSS)、主信息块(MIB)、广播消息、系统信息块(SIB)、寻呼消息等。作为响应，UE 110可向网络发出请求，该请求指示UE 110希望转到RRC连接状态。从RRC空闲状态到RRC连接状态的成功转变可包括UE 110与第一网络的第一小区之间的消息交换。在RRC连接状态下，可在第一网络的第一小区和UE 110之间建立网络上下文(context)。因此，UE 110可被分配无线电资源，并且UE 110可以能够与网络交换数据。从RRC连接状态转变到RRC空闲状态可被称为RRC连接释放，并且从RRC空闲状态转变到RRC连接状态可被称为RRC连接设置或RRC连接重建。然而，提供对RRC连接建立、RRC连接重建和RRC连接释放的标引仅是出于示意性说明的目的。其他网络可通过不同的名称来指代类似的操作。

示例性实施方案不限于RRC连接状态和RRC空闲状态。例如，当UE 110在5G NR-RAN122内操作时，UE 110可被配置为处于RRC非活动状态。在RRC非活动模式下，UE 110保持RRC连接，同时使信令和功率消耗最小化。如上所述，提供对任何特定操作状态的参考仅是出于示意性说明的目的，示例性实施方案可适用于UE 110的任何合适的操作状态。

图3示出了根据各种示例性实施方案的示例性布置300。示例性布置300包括UE110、网络310和服务器320。如上所述，示例性实施方案涉及由UE 110执行应用程序经由网络连接从远程端点下载数据。为了提供应用程序可如何从远程端点下载数据的一般示例，考虑UE 110执行经由网络连接305从服务器320下载视频文件的应用程序的以下示例性方面。

应用程序和服务器可根据应用层协议进行通信。例如，应用层协议可以是超文本传输协议(HTTP)。然而，对HTTP的提及仅是出于示意性说明的目的，存在HTTP的若干变型(例如，HTTP/2、安全超文本传输协议(HTTPS)等)和可利用的其他类型的协议。示例性实施方案可应用于根据任何适当的协议进行通信的应用程序和远程端点。

在该示例中，服务器320存储了授权正由UE 110执行的应用程序访问的视频文件。根据HTTP，视频文件可由统一资源定位符(URL)在网络之内进行识别和定位。因此，正由UE110执行的应用程序可使用对应的URL来访问视频文件。

服务器320经由网络连接315连接到网络310。网络310可以是多个互连的网络。例如，网络310可包括UE 110侧的网络布置100和由服务器320用于互联网协议(IP)连接的另一网络。

UE 110经由网络连接305连接到网络310。UE 110的应用程序可根据应用程序的应用编程接口(API)配置有各种目的和任务。目的和任务可使得应用程序能够访问服务器320并参与数据传输。例如，UE 110的应用程序和服务器320可建立URL会话。在URL会话内，应用程序可执行使得应用程序能够检索视频文件的数据传输任务。

下载进行的速率至少部分地取决于网络连接305。因此，在UE 110可经由网络连接305经历无服务或有限服务的网络拥塞期间，视频文件的下载可能会停滞并花费不合理的时间量。这会产生较差的用户体验，并且可能增加经由网络连接305下载数据的功率和/或处理成本。示例性实施方案涉及在网络拥塞很轻微或没有网络拥塞的情况期间执行下载，因此可以避免与网络拥塞相关联的成本增加。

图4示出了根据各种示例性实施方案，供UE 110基于网络拥塞来延迟下载的示例性方法400。将参照图1的网络布置100和图2的UE 110来描述方法400。

在405中，应用程序确定要进行下载。例如，用户输入可向应用程序指示用户已选择视频文件以供下载并存储在本地用于离线观看。然而，对视频文件的提及仅是出于示意性说明的目的。在操作期间，应用程序可被配置为从远程端点下载多种不同类型的数据，包括但不限于后台数据、配置信息、软件更新、多媒体数据(例如，音频、视频等)、可自由支配数据、广告等。一些类型的数据的下载可基于其他因素来触发，包括但不限于计划表、周期性、预先确定的条件、事件的类型等。示例性实施方案可应用于出于任何适当原因而被触发的任何类型的数据的下载。

在410中，UE 110确定要立即执行下载还是在后续时间执行下载。如果要在后续时间执行下载，则方法400继续进行到415，而如果要立即执行下载，则方法400继续进行到435。

如下所述，410中的确定可基于多个不同因素中的任何一个或多个因素。然而，示例性实施方案不限于基于任何特定的一组标准进行该确定。在一个方面，该特征为用户提供了便利，即能够在用户不打算播放内容时在第一时间浏览应用程序必须提供的内容(例如，视频文件、音频文件等)，然后在用户确实打算播放内容时在后续时间使内容可用。在另一方面，该特征允许UE 110避免与在网络拥塞期间执行下载相关联的成本增加。因此，可基于与用户便利性和/或UE 110效率相关的任何适当的标准来作出该确定。

在一些示例性实施方案中，410中的确定可响应于用户输入而作出。在一个示例中，可利用请求用户在两个选项之间进行选择的通知/提示来提示用户。在另一个示例中，用户输入可以是来自405的相同用户输入(例如，用户在405中选择表示“今晚下载”的链接)。

在其他示例性实施方案中，410中的确定可基于待下载的数据量。随着待下载的数据量的增加，下载的持续时间连同功率和/或处理成本一起增加。因此，下载量越大，下载在网络拥塞期间可能越难以完成。因此，UE 110可被配置为在特定时间窗口期间或者当网络状况较不拥塞时下载超过预先确定的大小(例如，300兆字节(MB)、500MB、700MB等)的文件。因此，如果要进行的下载超过预先确定的大小并且当前不在指定的时间窗口内，则方法400可继续进行到415，在此将确定下载被调度在期间发生的时间窗口。要下载的数据量也可以是考虑因素，因为用户的蜂窝计划可将UE 110限制为每天、每月等的一定量的数据。此外，UE 110是连接到归属网络还是另一运营商的网络(例如，漫游)也可以是考虑因素，因为与UE 110相关联的数据预算在漫游时可以是不同的。因此，可延迟特定大小的下载以防止UE110在当天/月过早使用过量的数据预算，因为这可防止执行其他数据传输。

在一些示例性实施方案中，410中的确定可基于在基带处理器处是否识别到网络拥塞的指示。如果识别到网络拥塞的指示，则下载可延迟到后续时间。如上所述，网络拥塞的影响可能会不利地影响与保持和利用网络连接相关的多个不同方面。当在基带处理器处识别出指示这些影响的网络状况时，这可向UE 110指示存在网络拥塞。例如，从基站接收到多个(例如，2、4、6、7个等)连续的RRC连接拒绝可提供网络拥塞的指示。类似地，响应于建立对非接入层(NAS)服务的接入的尝试，NAS服务拒绝可提供网络拥塞的指示。网络拥塞的另一指示可以是接收到大小相对于缓冲区状态报告(BSR)较小的多个下行链路授权。网络拥塞的其他指示可包括，但不限于低吞吐量、低信号与干扰加噪声比(SINR)、多次无线电链路控制(RLC)重传、授权到达之间的时间、多次混合自动重传请求(HARQ)重传、高发射功率、差的参考信号接收功率(RSRP)、基站被禁阻/列入黑名单的时间量等。因此，UE 110可以考虑各种链路质量度量和射频(RF)条件中的任何一种，以确定要立即进行下载还是在后续时间进行下载。然而，对特定指示的任何提及仅是出于示意性说明的目的，示例性实施方案可适用于在基带处理器处识别的网络拥塞的任何适当指示。

在415中，UE 110确定下载被调度在期间发生的时间窗口。如下所述，时间窗口可基于多个不同因素中的任何因素。然而，示例性实施方案不限于基于任何特定的一组标准进行该确定，可以使用任何适当依据作出确定。

在一个示例性实施方案中，UE 110可以调度在夜间(例如，晚上8点至上午8点)进行下载。

由于网络拥塞与所连接的UE的数量和/或正在交换的数据量相关，网络拥塞的存在可能遵循该区域内的人类活动的周期性模式。例如，通常在白天存在更多的利用基于蜂窝的服务的活动UE，而不是在夜晚，因为在白天通常有更多的人使用其UE。因此，网络拥塞可能在白天更有可能发生，因此下载可被延迟到夜间以避免网络拥塞更有可能发生的情况。

在另一个示例性实施方案中，用户可选择进行下载的时间窗口。在一个方面，示例性实施方案旨在向用户提供由于网络拥塞而导致的下载缓慢的不方便问题的便利解决方案。因此，用户可将时间窗口设定为在任何时间开始，并且可以是对用户而言方便的任何长度。例如，用户可能在白天不使用UE 110，但通常在晚上花费大量时间执行语音呼叫。因此，用户可将时间窗口设定为用户不打算使用UE 110的时间段，使得下载不干扰其他操作的执行。类似地，UE 110(例如，延迟下载引擎235)可以分析每日数据使用模式并基于数据使用模式调度时间窗口，以避免干扰用户的活动。

在其他示例性实施方案中，时间窗口可基于从与运营商相关联的网络实体(例如，服务器)接收的信息。例如，运营商可确定何时和何处存在网络拥塞。然后，运营商可以向UE110提供时间窗口的指示，该时间窗口将被优选为供UE 110以高效率的方式经由网络连接执行下载。在其他另外的示例性实施方案中，该时间窗口可基于从第三方实体接收的信息。例如，该UE的生产商可收集特定地理区域中的多个UE的信息(例如，众包信息)，并且可从该众包信息确定UE所连接的网络正在发生拥塞，并且可确定拥塞较少的时间窗口。然后可以将该信息发送到UE 110。

其他因素可涉及应用程序的提供商。例如，在某些时间，远程端点可能未联机，期望的内容可能不可用，和/或下载内容的货币价格可能增加。相反，在某些时间，应用程序的使用可能在第一时间与一种货币价格相关联，在第二时间与不同货币价格相关联。因此，可基于期望内容的可用性和/或货币价格来调度下载。

在420中，UE 110确定在时间窗口期间是否满足第一预先确定的条件。第一预先确定的条件可以向UE 110指示可以发起下载。因此，如果满足420中的第一预先确定的条件，则方法400继续进行到425，在此发起下载。如果不满足第一预先确定的条件，则方法400返回到420，在此UE 110继续监测第一预先确定的条件。如下所述，第一预先确定的条件可基于多个不同因素中的任一个或多个因素。然而，示例性实施方案不限于基于任何特定的一组标准进行该确定，可以按任何适当依据作出确定。

在410中所考虑的因素和在420中所考虑的因素之间可存在显著的重叠。在410中作出的确定和在420中作出的确定通常都针对相同场景(例如，立即下载或在后续时间下载)，并且都旨在向用户提供便利性，同时避免在网络拥塞期间低效率使用功率和/或处理资源。因此，410和420中的确定可基于类似因素。

例如，一个示例性因素可为是否在基带处理器处识别到网络拥塞的指示。上文参照410描述了可在基带处理器处识别的关于网络拥塞的指示的类型的示例。因此，第一预先确定的条件可包括可向UE 110指示网络连接的质量足以使下载以高效率方式发生的多个不同链路质量度量和/或RF条件中的任一者。

另一个示例性因素可以是从运营商接收的信息。例如，UE 110可经由网络连接从网络实体接收指示，该指示向UE 110指示网络的与UE 110相关的部分当前未经历网络拥塞，因此可发起下载。其他因素可包括，但不限于可用数据预算的百分比、WiFi连接、UE 110已不活动的预先确定的时间量(例如，10分钟、15分钟、30分钟、1小时等)、是否将警报设定为在预先确定的时间量内响起、电池寿命、UE 110是否插入、热压力、存储器可用性、CPU的使用等。

在425中，发起下载。因此，应用程序可建立URL会话并开始执行数据传输任务。

在430中，UE 110确定是否满足第二预先确定的条件。第二预先确定的条件可以向UE 110指示存在网络拥塞，因此应该暂停或取消下载。410、420和430中的确定可基于类似因素。

例如，在下载进行的同时，UE 110可监测提供网络拥塞的指示的各种链路质量度量。如果一个或多个链路质量度量指示下载不能以期望的速度进行(例如，连接问题、服务受限、无服务、高拥塞)，则方法400可返回到420，并且UE 110可监测第一预先确定的条件以确定何时恢复或重新发起下载。在一些示例性实施方案中，当暂停或取消下载时，UE 110可以监测指示特定连接问题或服务受限/没有服务的原因已被解决的特定条件。例如，UE 110可监测在多个连续的RRC连接拒绝或释放之后成功的RRC连接，或者可监测特定链路质量度量改善预先确定的量。在其他示例性实施方案中，UE 110可以在恢复或重新发起下载之前实现保护定时器。

返回到430，如果不满足第二预先确定的条件，则下载可完成并且方法400可结束。因此，在该示例中，视频文件可立即用于离线观看。

返回到410，如果确定要立即执行下载，则方法400继续进行到435。在435中，发起下载。因此，应用程序可建立URL会话并开始执行数据传输任务。一旦在435中发起下载，方法400就可前进到430，在此确定是否满足第二预先确定的条件。如上所述，第二预先确定的条件可以向UE 110指示存在网络拥塞，因此应该暂停或取消下载。因此，当满足第二预先确定的条件时，可暂停或取消下载，并且方法400可返回到410。如果不满足第二预先确定的条件，则下载可完成并且方法400可结束。

图5示出了根据各种示例性实施方案，供UE 110基于网络拥塞来延迟下载的示例性方法500。将参照图1的网络布置100、图2的UE 110以及图4的方法400对方法500进行描述。

在505中，当应用程序用户界面在前台时，UE 110接收用户发起的下载的指示。当应用程序用户界面在前台时(例如，当前被显示)，这可指示用户想要尽可能快地获得期望的内容。因此，不管网络拥塞存在与否，当应用程序用户界面在前台时，UE 110可尝试经由网络连接从远程端点下载数据。

与方法400相比，方法500可涉及不太直接和明确的用户输入。例如，在方法400的410中，用户可以肯定地选择下载被立即执行还是被调度在后续时间执行。在方法500中，可基于应用程序用户界面是否在前台来作出这些确定。

在510中，UE 110确定应用程序用户界面不再在前台并且启动定时器。例如，另一个应用程序用户界面现在可处于前台，主屏幕可被显示，锁定屏幕可被显示，屏幕保护程序可被显示，或者显示器可被关闭。

定时器可被设定为任何适当的预先确定的持续时间(例如，10秒、20秒、30秒、1分钟等)。在定时器的持续时间期间，UE 110可继续尝试经由网络连接从远程端点下载数据。如果在定时器到期之前使应用程序用户界面返回前台，则定时器可被重置。此外，如果下载在定时器到期之前完成，则期望的内容可用，因此方法500结束。

在515中，定时器到期，并且UE 110监测关于网络拥塞的指示。这里，关于网络拥塞的指示可类似于上文参照410、420和430所讨论的指示。例如，可在基带处理器处识别的关于网络拥塞的指示。UE 110可监测可向UE 110指示网络连接的质量足以使下载以高效率方式继续的多个不同链路质量度量和/或RF条件中的任一者。

在520中，UE 110确定是否已经识别网络拥塞的指示。如果没有识别到网络拥塞的指示，则方法500继续进行到525，在此完成下载。如果识别到网络拥塞的指示，则可暂停/取消下载，并且方法500继续进行到530。

在530中，要在后来的时间完成下载。例如，在一个示例性实施方案中并且类似于方法400的415，UE 110可以确定下载被调度在期间发生的时间窗口。一旦作出调度，就可执行420-430。

在另一个示例性实施方案中并且类似于方法400的420，UE 110可以监测预先确定的条件，该预先确定的条件向UE 110指示可通过方便和/或高效率的方式进行下载。如果满足预先确定的条件，则可恢复或重新启动下载(例如，可执行425-430)。

尽管本专利申请描述了各自具有不同特征的各种实施方案的各种组合，本领域的技术人员将会理解，一个实施方案的任何特征均可以任何未被公开否定的方式与其他实施方案的特征或者在功能上或逻辑上不与本发明所公开的实施方案的设备的操作或所述功能不一致的特征相组合。

本领域的技术人员将理解，可以任何合适的软件配置或硬件配置或它们的组合来实现上文所述的示例性实施方案。用于实现示例性实施方案的示例性硬件平台可包括例如具有兼容操作系统的基于Intel x86的平台、Windows OS、Mac平台和MAC OS、具有操作系统诸如iOS、Android等的移动设备。在其他示例中，上述方法的示例性实施方案可被体现为包括存储在非暂态计算机可读存储介质上的代码行的程序，在进行编译时，该程序可在处理器或微处理器上执行。

如上所述，本技术的一个方面是收集和使用可从特定和合法来源获得的数据，以改善与经由网络连接下载数据相关联的用户体验。本公开设想，在一些实例中，该所采集的数据可包括唯一地识别或可用于识别具体人员的个人信息数据。此类个人信息数据可包括人口统计数据、基于位置的数据、在线标识符、电话号码、电子邮件地址、家庭地址、与用户的健康或健身级别相关的数据或记录(例如，生命特征测量、药物信息、锻炼信息)、出生日期或任何其他个人信息。

本公开认识到在本发明技术中使用此类个人信息数据可用于使用户受益。例如，个人信息可用于将下载的执行延迟到后续时间和/或确定下载被调度在期间发生的时间窗口。

本公开设想负责收集、分析、公开、传输、存储或其他使用此类个人信息数据的实体将遵守既定的隐私政策和/或隐私实践。具体地，将期望此类实体实现和一贯地应用一般公认为满足或超过维护用户隐私的行业或政府所要求的隐私实践。关于使用个人数据的此类信息应当被突出并能够被用户方便地访问，并应当随数据的采集和/或使用变化而被更新。用户的个人信息应被收集仅用于合法使用。另外，此类收集/共享应仅发生在接收到用户同意或在适用法律中所规定的其他合法根据之后。此外，此类实体应考虑采取任何必要步骤，保卫和保障对此类个人信息数据的访问，并确保有权访问个人信息数据的其他人遵守其隐私政策和流程。另外，这种实体可使其本身经受第三方评估以证明其遵守广泛接受的隐私政策和实践。此外，应针对被收集和/或访问的特定类型的个人信息数据调整政策和实践，并使其适用于适用法律和标准，包括可用于施加较高标准的辖区专有的考虑因素。例如，在美国，对某些健康数据的收集或获取可能受联邦和/或州法律的管辖，诸如健康保险流通和责任法案(HIPAA)；而其他国家的健康数据可能受到其他法规和政策的约束并应相应处理。

不管前述情况如何，本公开还预期用户选择性地阻止使用或访问个人信息数据的实施方案。即本公开预期可提供硬件元件和/或软件元件，以防止或阻止对此类个人信息数据的访问。

此外，本公开的目的是应管理和处理个人信息数据以最小化无意或未经授权访问或使用的风险。一旦不再需要数据，通过限制数据收集和删除数据可最小化风险。此外，并且当适用时，包括在某些健康相关应用程序中，数据去标识可用于保护用户的隐私。可在适当时通过移除标识符、控制所存储数据的量或特异性(例如，在城市级别而不是在地址级别收集位置数据)、控制数据如何被存储(例如，在用户间汇集数据)和/或其他方法诸如差异化隐私来促进去标识。

因此，虽然本公开广泛地覆盖了使用个人信息数据来实现一个或多个各种所公开的实施方案，但本公开还预期各种实施方案也可在无需访问此类个人信息数据的情况下被实现。即，本发明技术的各种实施方案不会由于缺少此类个人信息数据的全部或一部分而无法正常进行。例如，下载的执行可延迟到后续时间和/或基于聚合的非个人信息数据或绝对最小量的个人信息来确定下载被调度在期间发生的时间窗口，诸如内容仅在用户的设备上处理并且不被提供给操作应用程序和/或远程端点的实体。

对本领域的技术人员而言将显而易见的是，可在不脱离本公开的实质或范围的前提下对本公开进行各种修改。因此，本公开旨在涵盖本公开的修改形式和变型形式，但前提是这些修改形式和变型形式在所附权利要求及其等同形式的范围内。

优先权声明/以引用方式并入

本专利申请要求2019年5月31日提交的名称为“Deferred Download Based onNetwork Congestion”(基于网络拥塞的延迟下载)的美国临时专利申请62/855,070的优先权，其全文以引用方式并入本文。

Claims (16)

1.一种由被配置为建立与网络的连接的用户装置UE执行的方法，包括：

接收用户发起的下载的指示；

至少基于对应的应用程序用户界面是否在前台，确定要立即执行所述下载还是在后续时间执行所述下载；

当要在所述后续时间执行所述下载时，确定要在其期间发起所述下载的时间窗口；

在从所述前台移除所述应用程序用户界面时启动定时器，其中所述定时器被设定为预先确定的持续时间，并且在所述定时器的所述持续时间期间启动所述下载；

当所述定时器到期时，在继续执行所述下载的同时监测网络拥塞的指示；以及

在所述时间窗口期间发起所述下载。

2.根据权利要求1所述的方法，其中确定要立即执行所述下载还是在后续时间执行所述下载还基于(i)用户输入、(ii)所述下载的大小或(iii)网络拥塞的指示中的至少一者。

3.根据权利要求2所述的方法，其中所述网络拥塞的指示基于以下中的至少一者：链路质量度量、网络连接的射频(RF)状况或由所述UE的基带处理器确定的从所述网络接收多个拒绝消息。

4.根据权利要求1所述的方法，其中所述时间窗口基于从运营商或第三方中的一者接收的信息。

5.根据权利要求4所述的方法，其中从所述运营商或所述第三方接收的所述信息指示以下中的一者：(i)网络拥塞何时不太可能存在，或者(ii)与在第一时间使用应用程序相关联的第一价格和与在第二时间使用所述应用程序相关联的第二价格。

6.根据权利要求1所述的方法，其中所述时间窗口基于以下中的至少一者：(i)用户输入，(ii)所述UE中的预配置调度，(iii)由所述UE收集的使用信息，或(iv)从请求所述下载的应用程序的提供商接收的信息。

7.根据权利要求1所述的方法，其中在所述时间窗口期间发起所述下载至少基于(i)由所述UE确定的网络拥塞的指示或(ii)从运营商接收的信息。

8.根据权利要求1所述的方法，还包括：

在发生所述下载时，确定是否已发生网络拥塞状况；

当已发生所述网络拥塞状况时，暂停所述下载；以及

将所述下载重新调度到后来的时间。

9.根据权利要求8所述的方法，其中所述暂停所述下载包括以下中的一者：删除所述下载的已经完成的部分或存储所述下载的已经完成的所述部分。

10.一种用户装置UE，包括：

收发器，所述收发器被配置为建立与网络的连接；以及

处理器，所述处理器被配置为：

接收用户发起的下载的指示；

至少基于对应的应用程序用户界面是否在前台，确定要立即执行所述下载还是在后续时间执行所述下载；

当要在所述后续时间执行所述下载时，确定要在其期间发起所述下载的时间窗口；

在从所述前台移除所述应用程序用户界面时启动定时器，其中所述定时器被设定为预先确定的持续时间，并且在所述定时器的所述持续时间期间启动所述下载；

当所述定时器到期时，在继续执行所述下载的同时监测网络拥塞的指示；以及

在所述时间窗口期间发起所述下载。

11.根据权利要求10所述的UE，其中确定要立即执行所述下载还是在后续时间执行所述下载还基于以下中的至少一者：(i)用户输入；(ii)所述下载的大小；(iii)网络拥塞的指示，其中所述网络拥塞的指示基于链路质量度量或网络连接的射频(RF)状况中的至少一者；或者

(iv)由所述UE的所述处理器确定的从所述网络接收多个拒绝消息。

12.根据权利要求10所述的UE，其中所述时间窗口基于从运营商或第三方中的一者接收的信息，其中从所述运营商或所述第三方接收的所述信息指示以下中的一者：(i)网络拥塞何时不太可能存在，或者(ii)与在第一时间使用应用程序相关联的第一价格和与在第二时间使用所述应用程序相关联的第二价格。

13.根据权利要求10所述的UE，其中所述时间窗口基于以下中的至少一者：(i)用户输入，(ii)所述UE中的预配置调度，(iii)由所述UE收集的使用信息，或(iv)从请求所述下载的应用程序的提供商接收的信息。

14.根据权利要求10所述的UE，其中在所述时间窗口期间发起所述下载至少基于(i)由所述UE确定的网络拥塞的指示或(ii)从运营商接收的信息。

15.根据权利要求10所述的UE，其中所述处理器被进一步配置为：

在发生所述下载时，确定是否已发生网络拥塞状况；

当已发生所述网络拥塞状况时，暂停所述下载；以及

将所述下载重新调度到后来的时间。

16.一种包括指令集的非暂态计算机可读存储介质，所述指令在由处理器执行时使所述处理器执行如权利要求1-9中任一项所述的方法的操作。