基于动态接收分集的方法和设备与流程

本公开一般地涉及无线通信。更具体地，本公开涉及基于动态接收分集的方法和被配置为执行这类方法的设备。

背景技术：

各种因素可能影响移动设备的功耗。例如，功耗可能取决于蜂窝调制解调器中所使用的接收天线或接收路径的数量。在lte、3g、wifi等框架内，蜂窝调制解调器可以包括多个接收和发送路径，该多个接收和发送路径被配置为执行动态接收分集或多输入多输出(mimo)技术。

无线通信网络中采用的方法和设备必须不断改善。具体地，期望提供改善在这类网络中进行操作的设备的性能的方法。此外，期望提供降低这些设备的功耗的方法。

基于这些原因以及另外的原因，存在对于本发明的需求。

技术实现要素：

根据本公开的一个方面，提供了一种客户端处的方法，包括：在第一动态接收分集天线端口处从服务器接收数据；对来自服务器的数据的数据吞吐量进行评估；以及基于数据吞吐量来选择性地激活或禁用被耦合到第二动态接收分集天线端口的电路

根据本公开的另一方面，提供了一种方法，包括：在第一动态接收分集天线端口处从服务器接收数据；监测调度请求到服务器的传输；以及如果在大于预定时间阈值的时间间隔期间未检测到调度请求的传输，则选择性地激活被耦合到第二动态接收分集天线端口的电路。

根据本公开的又一方面，提供了一种设备，包括：第一动态接收分集天线端口和第二动态接收分集天线端口，各自被配置为从服务器接收数据；评估单元，被配置为对来自服务器的数据的数据吞吐量进行评估；以及控制单元，被配置为基于数据吞吐量来选择性地激活或禁用被耦合到第二动态接收分集天线端口的电路。

附图说明

附图被包括以提供对本公开的示例的进一步理解，并且附图被合并到本说明书中并构成本说明书的一部分。附图示出了示例，并且与描述一起用于解释示例的原理。其它示例和示例的很多预期优势将很容易地被理解，这是由于通过参照下面的具体实施方式它们将变得更好理解。

图1示意性示出了无线通信系统100，包括客户端10和服务器20。

图2a示出了基于服务器和客户端之间的数据通信的时间/序列图。

图2b示意性示出了图2a的时间/序列图的第一部分中的数据通信。

图2c示意性示出了图2a的时间/序列图的第二部分中的数据通信。

图2d示意性示出了图2a的时间/序列图的第三部分中的数据通信。

图3示意性示出了根据本公开的、可以作为无线通信系统中的客户端进行操作的用户设备300。

图4示意性示出了根据本公开的基于动态接收分集的方法400。

图5示意性示出了根据本公开的基于动态接收分集的方法500。

图6示意性示出了根据本公开的被配置为执行基于动态接收分集的方法的设备600。

图7示意性示出了根据本公开的基于动态接收分集的方法700。方法700包括基于评估标准来选择性地激活设备的电路的动作。

图8示意性示出了根据本公开的基于动态接收分集的方法800。方法800包括基于评估标准来选择性地激活设备的电路的动作。

图9a示出了基于服务器和客户端之间的数据通信的时间/序列图。在数据通信期间，仅一个被耦合到相应天线端口的接收器电路在客户端中是活跃的。

图9b示出了基于服务器和客户端之间的数据通信的时间/序列图。在数据通信期间，两个接收器电路(各自被耦合到相应天线端口)在客户端中是活跃的。

具体实施方式

在下面的具体实施方式中，参照形成该具体实施方式的一部分的附图，并且在附图中通过图解的方式示出示例，本发明可以按照这些示例被实施。在不脱离本公开的范围的情况下，其它示例可以被利用并且可以做出结构的或逻辑的变化。因此，下面的具体实施方式不被认为具有限制性意义，并且本发明的范围由所附权利要求来限定。

除非另外特别指出，否则本文所描述的各种示例的特征可以互相组合。此外，相似的标号可以指定相应的相同或相似的部分。

如本说明书中所采用的那样，术语“耦合”和/或“连接”一般并不意味着元件必须被直接耦合或连接在一起；中间的功能元件可被提供在“耦合”或“连接”的元件之间。然而，尽管未被限制于此含义，但术语“耦合”和/或“连接”也可以被理解为可选地公开了元件被直接地耦合或连接在一起而没有被提供在“耦合”或“连接”的元件之间的中间元件的实现方式。

本文描述了用于对设备进行操作的设备和方法。结合所描述的设备做出的论述也适用于相应的方法，反之亦然。例如，如果描述了方法的具体动作，则用于执行该方法的相应设备可包括用于以适当方式执行动作的组件，即使这类组件未在图中被明确描述或示出。此外，除非另外特别指出，否则本文所描述的各个方面和示例的特征可以互相结合。

本文所描述的示例可以被实现在分立电路、部分集成的电路或者完全集成的电路中。另外，实施例可被实现在单个半导体芯片上或互相连接的多个半导体芯片上。另外，应当理解，实施例可被实现在软件中或专用硬件中、或部分实现在软件中并且部分实现在专用硬件中。

本文所描述的方法和设备可用于各种无线通信网络。术语“网络”、“系统”、“无线电通信系统”和“无线通信系统”在本文中可以作为同义词使用。

本文所描述的方法和设备可以被实现在无线通信网络(尤其是基于cdma、wcdma、lte和/或ofdm标准或基于wifi标准的通信网络、以及mimo通信系统)中。本文所描述的方法和设备还可以被实现在移动设备(或移动站或用户设备(ue))或基站(nodeb、enodeb)中。所描述的设备可以包括集成电路和/或无源元件，并且可以根据各种技术来制造。例如，电路可以被设计为逻辑集成电路、模拟集成电路、混合信号集成电路、存储器电路和/或集成无源元件。

本文所描述的方法和设备可被配置为发送和/或接收无线电信号。无线电信号可以是或可包括由无线电发送设备(或无线电发送器或发射机)发射的射频信号，其中无线电频率在大约3hz到300ghz的范围内。频率范围可以与用于产生并检测无线电波的交流电信号的频率相对应。

图1示意性示出了无线通信系统或网络100，包括客户端10和服务器20。客户端10例如可以与用户设备(ue)相对应，ue可以表示任意种类的移动电话、智能电话、膝上型计算机、平板、蜂窝调制解调器、视频游戏控制台等。ue还可以被称为移动终端、移动设备、移动站等。服务器20例如可以与nodeb相对应，nodeb还可以被称为基站、enodeb、基站收发器站等。例如，网络100可以基于lte、3g、wifi等。

客户端10和服务器20之间的通信可以基于通信协议。在一个示例中，这类通信协议可以与传输控制协议(tcp)相对应，tcp可以被视为互联网协议组(ip)的协议。就这一点而言，tcp还可以被称为tcp/ip。tcp可以对在可被连接到局域网、内联网或公共互联网的设备上运行的程序之间的传输数据提供可靠的、有序的和经误差校验的传送(或传送失败的通知)。传输数据可以与可被称为分组的信息片段相对应。具体地，分组可以是八位位组(字节)的序列并且可以包括头部，头部后跟随主体。头部可以标识分组的源和目的地，并且还可以包括控制信息。分组的主体可以包括要被传送的数据。具体地，tcp可以驻留在传输层处。例如，当浏览器连接到万维网上的服务器时，tcp可以由网络浏览器使用。tcp具体地可以被用于传送电子邮件和将文件从一个位置传送到另一位置。tcp中封装的通信协议例如是http、https、smtp、pop3、imap、ssh、ftp、telnet等。

客户端10和服务器20之间的tcp连接可以基于三向握手来建立。在第一动作中，客户端10可向网络100或外部网络上的服务器20发送syn数据分组。syn数据分组的目标可以是查询服务器20是否对新的连接开放。当服务器20从客户端10接收到syn分组时，服务器20可以在第二动作中进行响应并且返回确认接收。确认接收可以与ack数据分组或syn/ack数据分组相对应。在第三动作中，客户端10可以从服务器20接收syn/ack数据分组，并且可以用ack数据分组进行响应。当完成所述三个动作(或“握手”)时，客户端10和服务器20二者都已接收对连接的确认，从而使得连接被创建，并且全双工通信可以被建立。

图2a示出了例如基于客户端10和服务器20之间的数据通信的时间/序列图。图示的横轴按秒表示时间，而纵轴表示从服务器20成功发送到客户端10的数据的吞吐量，即经由无线电通信信道的成功消息传送的速率。在图2a中，纵轴具体表示由服务器20发送并且在客户端10处被成功接收的序列或数据分组的数量。在这里，数据分组的成功接收可以与包括从客户端10发送到服务器20以ack数据分组形式的接收确认的数据分组的接收相对应。例如，图2a的数据通信可以与客户端10从服务器20下载数据文件相对应。数据文件例如可以与文本文件、网页、图像文件等相对应。在图2a中，假设客户端10和服务器20之间的连接已经被建立。也就是说，图2a不一定包括与客户端10和服务器20之间的三向握手有关的数据传输。

图2a的图示包括被标记为“非连续dl(下载)活动”的数据传输的第一部分，其后跟随被标记为“连读dl活动”的数据传输的第二部分。第一部分和第二部分中的图所示的离散部分表示在客户端10处已从服务器20成功接收的数据分组。间隙被布置在这些传送的数据分组之间。在这类间隙的时间段期间，不存在任何数据在客户端10和服务器20之间被交换。具体地，将由客户端10从服务器20下载的文件的传输可能被暂停。下面结合图2b和图2c描述了在图2a的时间/序列图的第一部分和第二部分中客户端10和服务器20之间传送的具体数据。

从图2a中可以看出，在tcp传输的开始处，可能不存在任何连续的dl(和ul)活动。相反，针对大约0.5秒的第一时间间隔(即，在非连续dl活动的第一部分中)，仅dltcp数据的一小部分从服务器20被发送到客户端10。在图2a中，所示出的图的梯度可以具体随时间而增加。图示的增加表示单位时间在客户端10处被成功接收的数据分组的数量增加。图示的梯度的增加具体地可以源于慢启动算法，慢启动算法可以被用在tcp传输的开始处。

图2b示意性示出了图2a的时间/序列图的第一部分中的非连续dl(和ul)活动期间的数据通信。在第一时间间隔i中，服务器20向客户端10发送dltcp分组数据。例如，dltcp数据分组可以包括将由客户端10从服务器20下载的数据文件的片段。在接收dltcp数据分组后，客户端10可以用调度请求进行响应，以在ul中发送tcpack并且进一步请求另外的dltcp数据分组从服务器20到客户端10的传输(或传输的调度)。客户端10通过向服务器20发送上行链路(ul)tcpack数据分组来确认对dltcp数据分组的接收。通常，执行第一时间间隔i的所描述动作所需的时间可以是任意的，并且可以取决于所考虑的情境。具体地，所需时间可以在大约10毫秒到大约30毫秒的范围内，更具体地在大约18毫秒到大约22毫秒的范围内，并且其值甚至具体地可以为大约20毫秒。在第二时间间隔ii中，客户端10没有从服务器20接收到数据。第二间隔ii因此可以与结合图2a所描述的非连续dl活动中的间隙中的一个间隙相对应。在数据传输的非连续dl活动部分期间，间隙的长度可以在大约75毫秒到大约85毫秒的范围内，并且其值具体地可以为大约80毫秒。

在下面的时间间隔中，结合时间间隔i和ii所描述的动作可以被重复，直到客户端10和服务器20之间的数据传输可以离开非连续dl活动并且可以进入图2a中所示的连续dl活动。也就是说，第三时间间隔iii期间的数据传输可以类似于如上所述的第一时间间隔i的数据传输，第四时间间隔iv期间的数据传输可以类似于所描述的第二时间间隔ii的数据传输，第五时间间隔v(未示出)期间的数据传输可以类似于第一时间间隔i的数据传输，等等。时间间隔i和ii的数据传输可以被重复大约5到6次(即大约0.5秒)，直到客户端10和服务器20之间的数据传输可以进入第二部分的连续dl活动。

图2c示意性示出了图2a的时间/序列图的第二部分中的连续dl(和ul)活动的开始处的数据通信。图2c可以被视为非连续活动和连续活动之间的转换期间的数据通信的图示，但图2c还可以被视为连续活动期间的数据通信的简化图示。对连续活动期间的数据通信的更详细图示结合图2d进行了描述。在第一时间间隔i’中，服务器20可以向客户端10发送另外的dltcp数据分组。在接收dltcp数据分组后，客户端10可以通过向服务器20发送上行链路(ul)tcpack数据分组来确认对dltcp数据分组的接收。与图2b中的非连续数据传输的时间间隔i相比，客户端10不必用另外的调度请求对服务器20进行响应。执行第一时间间隔i’的所描述动作所需的时间的值可以为大约20毫米或更小。

在第二时间间隔ii’中，在客户端10处可以没有数据从服务器20被接收。第二间隔ii’因此可以与结合图2a所描述的dl活动的连续部分中的间隙相对应。在数据传输的连续部分期间，间隙的长度可以在大约10毫秒到大约50毫秒的范围内。在下面的时间间隔中，时间间隔i’和ii’的动作可以被重复，特别是直到客户端10和服务器20之间的数据传输(例如，文件下载)完成。也就是说，第三时间间隔iii’期间的数据传输可以类似于第一时间间隔i’的数据传输，第四时间间隔iv’期间的数据传输可以类似于第二时间间隔ii’的数据传输，第五时间间隔v’(未示出)期间的数据传输可以类似于第一时间间隔i’的数据传输，等等。

从上面可以看出，在非连续dl活动期间，在客户端10和服务器20之间的数据传输的开始处，只要客户端10和服务器20之间无稳定和连续的数据传输被建立，客户端10就可能需要向服务器20发送调度请求。在数据传输已变稳定(即，所发送的数据分组之间的间隙的大小低于特定时间值)时，可以无需另外的调度请求从客户端10被发送到服务器20。

图2b和图2c中的间隙(参见例如时间间隔ii和ii’)的大小可以取决于各种因素。例如，间隙大小可以取决于慢启动算法的应用。在这里，间隙可以被视为空闲时间，在空闲时间中，任何额外的数据传输都未被(尚未被)实现。由于在连续dl活动的部分中慢启动算法对间隙大小的影响可能变得不相关，因此部分ii的间隙大小具体地可以大于部分ii’的间隙大小。此外，间隙大小可以取决于可以由服务器20调度的客户端的数量。如果服务器20与多个客户端进行通信，则仅减少的资源可以被调度用于一个特定客户端(例如所考虑的客户端10)。换句话说，与第一客户端通信的间隔期间的时间可以被服务器20用于与不同的第二客户端进行通信。此外，间隙大小可以取决于所发送的数据分组的往返延迟时间(rtd)(或往返时间(rtt))。rtd(或rtt)可以被定义为要被发送(例如，从服务器20到客户端10)的信号所需的时间长度加上对要被接收(例如，从客户端10到服务器20)的信号进行确认所需的时间长度。由于在连续数据传输期间所发送的数据分组的数量可能增加，并且针对不同数据分组的往返时间可能不同，因此事实上，图2a的图可能变得模糊或失真，尤其是在连续dl活动的部分中。

图2d示意性示出了连续活动期间的数据通信。在这里，dltcp数据分组可以从服务器20被发送到客户端10，并且ultcpack数据分组可以从客户端10被发送到服务器20。在图2d中，客户端侧的箭头指示dltcp数据分组和ultcpack数据分组是互相关联的。如之前所提到的，例如由于不同的往返时间，相关联的dltcp数据分组和ultcpack数据分组不一定按连续方式很好地被排序，而是可能被混合，这导致如上所述的模糊活动。例如由于其它用户在该相应时间实例中被服务，在连续dltcp数据分组之间可能发生时间间隙。类似地，在连续ultcpack数据分组之间可能发生时间间隙。要注意的是，dltcp数据分组和与之前的dl数据相关联的ultcpack数据分组可以在同一时间实例被发送。

在客户端10和服务器20之间的通信期间，数据吞吐量可能受拥塞窗口和接收窗口(或传输窗口)中的至少一者的限制。拥塞窗口可以被配置为控制和/或避免例如服务器20和客户端10之间的数据通信的拥塞，从而使得不超出网络的容量。拥塞窗口的大小可以通过估计客户端10和服务器20之间的拥塞程度来计算。具体地，拥塞窗口可以由服务器20维护。

接收窗口可以被配置为控制和/或避免超出客户端10处理数据的容量。接收窗口可以确定或对应于在不对服务器20进行确认的情况下客户端10可以接受的数据量。通常，如果服务器20尚未接收到针对其已发送到客户端10的第一分组的确认，则服务器20可以停止和等待。如果等待超过特定限度，则服务器20可以重新发送所发送的数据分组，从而使得基于tcp的通信可以实现可靠的数据传输。从客户端10被发送到服务器20的每个tcp段可以包含接收窗口的当前值。例如，如果服务器20可以从客户端10接收确认编号为5000的字节的ack消息，并且还指定接收窗口的大小为10000字节，则在已发送编号为15000的字节后，服务器20不必发送另外的数据分组，即使所设置的拥塞窗口可以允许这样的传输。

即使网络中无任何分组丢失，接收窗口也可以限制客户端10和服务器20之间的数据连接的吞吐量。由于tcp可以在等待确认之前发送多达窗口大小的数据，因此可能不总是利用网络的全带宽。具体地，由接收窗口的大小引起的吞吐量的限制可以示例性地由下面的不等式指定：th≤rwin/rtt。在这里，量th可以表示吞吐量的大小，量rwin可以表示接收窗口的大小，并且量rtt可以表示用于发送数据分组的(一个或多个)路径的往返时间的大小。

接收窗口的大小具体地可以由tcp通信的客户端10侧指示，并且可以与客户端10已分配用于相应连接的自由接收存储器的量相对应。否则，由于缺乏存储器空间，客户端10可能面临丢失接收到的分组的风险。

根据如上所述，吞吐量因此可能受限于tcp接收窗口。tcp服务器可以执行特定流控制，例如慢启动和拥塞避免，并且还可以通过tcp传输窗口限制吞吐量。在一个示例中，在tcp通信的开始处，tcp接收窗口尚未充分打开，从而使得当tcp传输窗口被命中(hit)时连接吞吐量可能被覆盖。即使当接收窗口被命中时，无线链路也可以支持更多的吞吐量。

图3示意性示出了可以作为无线通信系统中的客户端(例如图1的客户端10)进行操作的用户设备300。ue300可以用于执行本文所描述的根据本公开的任意方法。例如，ue300可用于结合图2a到图2c所描述的情境中。

ue300可以包括第一接收天线12a和第二接收天线12b，具体地为第一动态接收分集天线12a和第二动态接收分集天线12b。在图3中，为了简单起见，仅示出了两个接收天线12a、12b。然而，图3的示例可以被扩展为任意数量的接收天线。接收天线12a、12b中的每个接收天线可以被配置为从例如可作为服务器(例如图1的服务器20)进行操作的nodeb接收下行链路无线电信号。此外，接收天线12a、12b可以被配置为将接收到的信号转换为表示接收到的下行链路信号的电信号。ue300可以被配置为执行任意天线切换方案和/或可以基于任意动态接收分集技术。ue300的接收器分集(rxdiv)或天线分集(也可被称为空间分集)可以提供采用两个或多个接收天线的数个无线分集方案中的任意无线分集方案的应用。

为了简单起见，图3仅示出了ue300的接收部分。然而，ue300还可以包括多个发送天线，为了简单起见，未示出多个发送天线。在发送和接收时都使用多个天线可以产生多输入多输出(mimo)系统。在链路的两端处都使用分集技术可以被称为空时编码。

ue300还可以包括第一天线端口14a，具体地为第一动态接收分集天线端口14a，其可以被耦合到第一接收天线12a。天线端口14a可以提供第一接收天线12a和可包括可被配置为处理表示接收到的下行链路信号的电信号的组件的电路之间的耦合。ue300还可以包括第二天线端口14b，具体地为第二动态接收分集天线端口14b，其可以被耦合到第二接收天线12b。第一接收天线端口14a可以类似于第二接收天线端口14b。

ue300还可以包括第一接收器电路16a，其可以被耦合到第一接收天线端口14a。第一接收器电路16a可以被配置为处理从第一天线端口14a接收到的电信号。例如，第一接收器电路16a可以包括或可以是瑞克(rake)接收器、均衡器、ofdm接收器、以及其它适当接收器中的至少一个的一部分，这取决于所考虑的ue或客户端的类型。第一接收器电路16a可以包括一个或多个天线放大器，一个或多个天线放大器可以被配置为放大或减弱接收到的信号。此外，第一接收器电路16a可以包括模拟到数字(adc)转换器，adc转换器可以被配置为将接收到的模拟信号转换为数字信号。此外，第一接收器电路16a可以包括一个或多个混频器，一个或多个混频器可以被配置为将接收到的信号下混频到基带(或中间带)。此外，第一接收器电路16a可以包括一个或多个解调器和/或一个或多个解码器，一个或多个解调器可以被配置为解调接收到的信号，一个或多个解码器可以被配置为解码接收到的信号。例如，调制(解调)方案(星座)可以是基于相位键控(qpsk)或正交幅度调制(例如，16qam或256qam)的。ue300还可以包括第二接收器电路16b，其可以被耦合到第二接收天线端口14b。第二接收器电路16b可以类似于第一接收器电路16a。

ue300还可以包括组合单元18，组合单元18可以被配置为将从第一接收器电路16a和第二接收器电路16b接收到的多个信号进行组合。接收器电路16a和16b中的每个接收器电路可以接收已经由例如nodeb发送到ue300的信号的独立副本。在组合单元18中，这些独立的样本可以按适当的方式被组合。组合单元18的具体实现方式具体可以取决于所考虑的ue或客户端的类型。在一个非限制示例中，组合单元18可以与最大比组合单元相对应。

ue300还可以包括处理单元22，处理单元22可以被耦合到组合单元18并且被配置为处理从组合单元18接收到的信号。例如，处理单元22可以与数字信号处理器或应用处理器相对应。处理单元22可以被配置为运行一个或多个软件程序。例如，协议栈软件可以在处理单元22上运行。这样的协议栈软件可以被配置为根据ue300和服务器(例如nodeb)之间的tcp协议来控制数据传输。就这一点而言，处理单元22例如可以被配置为监测调度请求从客户端10到服务器20的传输。协议栈软件例如可以被配置为检测客户端10和服务器20之间的数据传输的中止，中止由接收窗口引起。

ue300还可以包括控制单元24，控制单元24还可以被称为分集控制器。控制单元24可以被耦合到组合单元18和处理单元22中的至少一者。此外，控制单元24可以被耦合到第一接收器电路16a和第二接收器电路16b中的至少一者。控制单元24可以被配置为选择性地激活或禁用接收器电路16a、16b中的一者或二者。为此，控制单元24可以被配置为通过打开或关闭接收器电路16a、16b来控制分集接收器的功率。具体地，控制单元24可以被配置为激活(禁用)将被激活(禁用)的接收器电路的一部分。就这一点而言，天线端口14a、14b可以或可以不被视为接收器电路16a、16b的一部分。在一个示例中，天线端口和adc之间布置的相应接收器电路的所有组件可以被禁用，而adc的下游布置的组件仍可以保持活跃。

对接收器电路16a、16b中的一者或多者的激活和/或禁用可以基于如下讨论的一个或多个评估标准。具体地，选择性地激活/禁用接收器电路16a、16b中的一者或多者的决定可以基于对ue300和服务器(例如nodeb)之间的数据吞吐量的评估。控制单元24可以从组合单元18和/或处理单元22接收这类评估可基于的数据。

图4示意性示出了根据本公开的基于动态接收分集的方法400。方法400可被视为说明本公开的基本概念的示例。方法400可以通过另外的动作(例如通过结合图7和图8的方法700和方法800所描述的一个或多个动作)来扩展。

在动作30中，在客户端的第一动态接收分集天线端口处从服务器接收数据。返回参照图3，客户端可以与ue300相对应，ue300可以从服务器在例如第一天线端口14a处接收数据。在进一步的动作32中，评估服务器和客户端之间的数据吞吐量。返回参照图3，ue300的组件(例如，处理单元22和/或控制单元24)可以评估ue300和服务器之间所发送的数据的吞吐量。用于评估数据吞吐量的示例是例如如下结合图7和图8的方法700和方法800所讨论的。在进一步的动作34中，被耦合到客户端的第二动态接收分集天线端口的电路基于对数据吞吐量的评估来选择性地被激活或被禁用。返回参照图3，例如，控制单元24可以激活/禁用被耦合到第二天线端口14b的第二接收器电路16b。通过禁用接收器电路，客户端在其操作期间的功耗可以被降低。

图5示意性示出了根据本公开的基于动态接收分集的方法500。方法500可被视为说明本公开的基本概念的示例。方法500可以通过另外的动作(例如通过结合图7和图8的方法700和方法800所描述的一个或多个动作)来扩展。

在动作36中，在客户端的第一动态接收分集天线端口处从服务器接收数据。返回参照图3，客户端例如可以与ue300相对应，ue300可以从服务器在例如第一天线端口14a处接收数据。在进一步的动作38中，监测调度请求从客户端到服务器的传输。返回参照图3，例如，可以在处理单元22上运行的协议栈软件可以被配置为控制和监测调度请求的传输。在进一步的动作40中，如果在大于预定第一时间阈值的时间间隔期间未检测到调度请求的传输，则被耦合到第二动态接收分集天线端口的电路选择性地被激活。返回参照图3，如果在所考虑的时间间隔期间未检测到调度请求的传输，则控制单元24可以从处理单元22接收信号。基于这样的触发信号，除了已经处于活跃状态的第一接收器电路16a之外，控制单元24然后还可以例如激活第二接收器电路16b。

图6示意性示出了根据本公开的被配置为执行基于动态接收分集的方法的设备600。例如，设备600可以被配置为执行图4的方法400。设备600可以包括第一动态接收分集天线端口42a和第二动态接收分集天线端口42b。天线端口42a、42b中的每个天线端口可以被配置为从服务器(未示出)接收数据。设备600还可以包括评估单元44，评估单元44可以被配置为评估服务器和设备600之间的数据吞吐量。设备600还可以包括控制单元46，控制单元46可以被配置为基于对数据吞吐量的评估来选择性地激活或禁用被耦合到第二动态接收分集天线端口42b的电路48。

图6的设备600可以被视为本发明的基本概念。因此，设备600以通用方式被示出，并且当然还可以包括另外的组件，为了简单起见，未示出另外的组件。例如，设备600还可以包括结合图3所描述的一个或多个组件。图3的设备300可以被视为设备600的更详细的实现方式。就这一点而言，设备600的评估单元44可以用设备300的处理单元22和控制单元24中的一者或多者来标识。此外，设备600的控制单元46可以用设备300的控制单元24来标识，并且设备600的电路48可以用设备300的第二接收器电路16b来标识。

图7示意性示出了根据本公开的基于动态接收分集的方法700。方法700可以被视为方法400和方法500的增强版本。在客户端和服务器之间的通信中，方法700可以由网络的客户端执行，其中通信例如可以是基于tcp的。例如，设备300和设备600中的每个设备可以被配置为执行方法700。在下文中，结合图3的设备300描述了方法700。在这种情况下，下文中所描述的一个或多个动作可以由设备300的处理单元22和控制单元24中的至少一者来执行。

在动作50中，客户端可以监测数据分组是否被客户端接收。例如，客户端可以是分集接收器，分集接收器可以与图3的设备300类似。在执行动作50时，第一接收器电路16a可以被激活，而第二接收器电路16b可以被禁用。就这一点而言，第二天线端口14b可以或可以不被视为第二接收器电路16b的一部分。如果未接收到数据分组，则动作50可以在预定时间间隔过去之后再次被执行。如果检测到对数据分组的接收，则进一步的动作52可以被执行。

在动作52中，客户端可以决定第二接收器电路16b是否可以被激活或这样的激活是否可以被延迟。动作52的决定可以取决于另外的动作54的结果。在动作54中，客户端和服务器之间的数据吞吐量可以被评估。具体地，这样的评估可以由客户端执行。下面描述了评估数据吞吐量的各种示例性可能。如果客户端决定第二接收器电路16b的激活被延迟，即第二接收器电路16b尚不被激活，则进一步的动作56可以被执行。

在动作56中，客户端可以监测另外的数据分组是否被客户端接收。如果检测到对数据分组的接收，则动作52可以再次被执行，从而考虑动作54的评估。如果未接收到数据分组，则进一步的动作58可以被执行。换句话说，包括动作52和56的环路可以被重复，直到无另外的数据分组被客户端接收。在该连接中，监测动作56可以基于预定时间段被周期性地重复。

在动作58中，客户端可以监测在预定时间间隔值y期间另外的数据分组是否已经被客户端接收。例如，所考虑的时间间隔值y可以从动作56的第一性能开始。在非限制性示例中，时间间隔的值y可以在大约90毫秒到大约110毫秒的范围内，并且其值具体地可以为大约100毫米。如果时间间隔的值y尚未过去，则动作56可以再次被执行。如果针对时间间隔y的持续时间客户端未接收到任何数据分组，则动作50可以被再次执行。

现在返回参照动作52。如果客户端决定第二接收器电路16b被激活(即，对第二接收器电路16b的激活不再被延迟)，则进一步的动作60可以被执行。在动作60中，第二接收器电路16b可以被激活。在一个示例中，第二接收器电路16b的所有组件可以被激活。在另外的示例中，第二接收器电路16b的仅被选择的组件可以被激活。例如，对接收器电路的激活可以与对接收器电路被考虑的相应组件进行通电的动作相对应。

在进一步的动作62中，在第二接收器电路16b已被激活后，客户端可以监测另外的数据分组是否被客户端接收到。例如，动作62可以类似于动作50和动作56中的一者。如果检测到对另外的数据分组的接收，则之前激活的组件维持激活并且数据接收可以继续，即动作62可以再次被执行。如果未接收到另外的数据分组，则另外的动作64可以被执行。

在动作64中，客户端可以监测在预定时间间隔值x期间另外的数据分组是否已经被客户端接收。动作64例如可以类似于动作58。在一个示例中，时间间隔的值x可以在大约90毫秒到大约110毫秒的范围内，并且其值具体地可以为大约100毫米。动作58和动作64的时间间隔x和y可以彼此类似或可以彼此不同。

如果针对时间间隔x的持续时间客户端未接收到任何数据分组，则进一步的动作66可以被执行。否则，动作62可以再次被执行。在动作66中，之前在动作60中被激活的组件可以被禁用。如果动作66已被执行并且相应的组件被禁用，则动作50可以再次被执行。

在图7中，动作52到动作58被布置在虚线矩形中。在另外的方法中，矩形中的动作可以被省略。在这种情况下，如果在动作50中数据分组被接收到，则第二接收器电路16b可以立即被激活，而无需另外评估服务器和客户端之间的数据吞吐量(如动作54中所执行的)。由于对第二接收器电路16b的激活可以引起客户端的功耗增加，因此包括矩形的动作可以降低客户端的功耗。

已结合图3的设备300示例性描述了方法700，图3的设备300包括被耦合到相应接收器电路的两个接收天线端口。要理解的是，方法700还可以被扩展到包括两个以上接收天线端口和耦合到其的接收器电路的设备。例如，这类扩展方法的另外的动作可以延迟对这类另外的接收器电路的激活。

返回参照动作54，在下文中讨论了针对评估服务器和客户端之间的数据吞吐量的示例。针对评估所描述的可能性可以按任意方式被结合。

在一个示例中，图7的动作54中的评估数据吞吐量可以包括以下动作：监测调度请求从客户端到服务器的传输。在这里，如果在大于预定时间阈值的时间间隔期间未检测到调度请求从客户端到服务器的传输，则可以执行对第二接收器电路16b的激活。例如，时间阈值可以在大约90毫秒到大约110毫秒的范围内，并且其值具体地可以为大约100毫米。返回参照图2a的情境，在连续dl活动的部分中可能需要第二接收器电路16b，从而使得激活电路是合理的。在连续dl活动的部分中，客户端不必向服务器发送调度请求。连续dl活动的状态可以通过所述对调度请求的传输的监测来检测。例如，调度请求的传输可以由处理单元22和控制单元24中的至少一者来监测。在一个示例中，传输可以由运行在数字信号处理器上的协议栈软件来监测。具体地，只要客户端在非连续dl活动部分中操作，调度请求就可以被检测到。

在另外的示例中，图7的动作54中的评估数据吞吐量可以包括以下动作：基于在客户端处从服务器接收到的数据来检测数据速率。在这里，如果检测到的数据速率大于数据速率阈值，则可以执行对第二接收器电路16b的激活。例如，数据速率阈值可以在大约5兆比特每秒到大约15兆比特每秒的范围内，并且其值具体地可以为大约10兆比特每秒。返回参照图2a的情境，在连续dl活动的部分期间可能需要第二接收器电路16b，从而使得当该状态被检测到时可以激活电路。连续dl活动的状态可以通过检测所接收的数据速率的速率来确定，尤其当数据速率超过数据速率阈值时。例如，数据速率可以由处理单元22和控制单元24中的至少一者来检测。在一个示例中，数据速率可以由运行在数字信号处理器上的协议栈软件来确定。

在另外的示例中，图7的动作54中的评估数据吞吐量可以包括以下动作：检测在客户端处从服务器接收第一数据分组和在客户端处从服务器接收后续第二数据分组之间的持续时间。在这里，如果持续时间小于时间阈值，则可以执行对第二接收器电路16b的激活。例如，时间阈值可以在大约10毫秒到大约50毫秒的范围内。返回参照图2a的情境，在连续dl活动的部分期间可能需要第二接收器电路16b。连续dl活动的状态可以通过检测客户端处接收到的两个后续数据分组之间的间隙的大小来检测。如果间隙的大小小于时间阈值，则可以假设客户端已经在连续dl活动部分中进行操作。

在另外的示例中，图7的动作54中的评估数据吞吐量可以包括以下动作：检测客户端和服务器之间的数据传输的中止，其中中止可以是基于接收窗口的。在这里，如果未检测到中止，则可以执行对第二接收器电路16b的激活。返回参照图2a，接收窗口的大小可以随时间而增加。也就是说，接收窗口的大小在开始文件下载时是很小的，从而使得服务器和客户端之间的数据通信有时可能被中止。通常，中止可能在非连续dl活动部分和/或连续活动部分中发生。如果检测到这样的中止，则使得第二接收器电路16b禁用是合理的。随着接收窗口的大小增加，之前的中止可能结束，从而使得接收窗口不必再限制客户端和服务器之间的数据传输。当由接收窗口引起的中止不再被检测到时，激活第二接收器电路16b是合理的。

例如，检测客户端和服务器之间的数据传输的中止可以包括以下动作：检查由客户端接收的数据分组。客户端可以接收数据分组，并且可以基于对数据分组的数据检查来检测接收到的数据分组是否与tcp数据分组相对应。相应的信息例如可以被包括在数据分组的头部中。针对tcp数据分组的情况，客户端可以检测数据分组的序列号。基于已知的序列号和关于当前接收窗口的额外信息，可以确定数据通信的中止是否由接收窗口的当前大小引起。数据检查和对中止的检测例如可以由图3的处理单元22和控制单元24中的至少一者来执行。

例如，客户端和服务器之间的数据传输的中止可以由协议栈软件来检测，协议栈软件例如可以运行在数字信号处理器上。具体地，协议栈软件可以在任意给定时间了解接收到的数据分组的序列号和当前接收窗口的大小。基于该信息，软件可以确定数据通信的中止是否由接收窗口的当前大小引起。协议栈软件可以被配置为生成触发信号并且将该信号发送到控制单元，控制单元可以被配置为选择性地激活和禁用被耦合到动态接收分集天线端口的一个或多个电路。返回参照图3的设备300，运行在处理单元22上的tcp软件可以监测客户端和服务器之间的数据通信是否基于接收窗口而被中止。如果检测到中止的结束，则处理单元22可以生成触发信号并且将该触发信号发送到控制单元24。在接收触发信号后，控制单元24可以激活第二接收器电路16b。

在另外的示例中，图7的动作54中的评估数据吞吐量可以包括以下动作：确定第一数据吞吐量，第一数据吞吐量基于服务器和客户端的第一接收器电路16a之间发送的数据；确定第二数据吞吐量，第二数据吞吐量基于服务器和第一接收器电路16a之间发送的数据以及服务器和第二接收器电路16b之间发送的数据。在另外的动作中，第一数据吞吐量和第二数据吞吐量可以进行比较。基于比较的结果，接收器电路中的一个或多个可以被激活或被禁用。

例如，相对吞吐量可以被考虑用于客户端和服务器之间的吞吐量的评估。相对吞吐量例如可以与第一数据吞吐量除以第二数据吞吐量或与第二数据吞吐量除以第一数据吞吐量相对应。这样的相对吞吐量可以表示延迟对第二接收器电路的激活的测量和/或指示符。相对吞吐量可以估计使用mimo接收(即第二接收器电路被激活)是否可能有更多吞吐量。在该连接中，吞吐量可以基于每个tti(传输时间间隔)/子帧的吞吐量、每个prb(物理资源块)的吞吐量、以及每个prb的每个tti/子帧的吞吐量中的至少一者。

对客户端和服务器之间的吞吐量(具体地为如上所述的相对吞吐量)的评估还可以是基于小区负载的。如果所考虑的小区是满载的(例如包括自有的数据连接)，则对第二接收器电路的激活可以提供增加的吞吐量，因为客户端不太可能得到更多的资源。如果小区不是满载的，则ue还可以通过从网络得到更多的资源来实现增加的吞吐量，而无需激活第二接收器电路。因此，第二天线接收器电路可以被禁用，因为天线不一定表示对数据通信的限制因素。例如，小区负载估计可以是基于以下值中的一个或多个的：rssi(接收信号强度指示)、rsrp(参考信号接收功率)、rsrq(参考信号接收质量)、以及snr(信噪比)。在无线标准中，基站可以广播小区负载比特或指示符以使得ue能够调整其通信行为，从而改善总体网络性能。这样的小区负载指示符还可用于确定相对吞吐量或对客户端和服务器之间的吞吐量进行评估。

针对检测相对吞吐量，客户端例如可以实现短测试序列，短测试序列可以定期运行。在该测试序列中，客户端可以从仅使用一个接收器电路的操作模式切换到使用两个或甚至更多个接收器电路的操作模式。客户端然后可以确定通过激活额外的(一个或多个)接收器电路是否提高了吞吐量，并且可以相应地做出反应。

图8示意性示出了根据本公开的基于动态接收分集的方法800。方法800可以被视为方法400和方法500的增强版本。在客户端和服务器之间的通信期间，方法800可以由客户端执行。在一个示例中，通信例如可以是基于tcp的。例如，设备300和设备600中的每个设备可以被配置为执行方法800。在下文中，结合图3的设备300描述了方法800。在这种情况下，下文中所描述的一个或多个动作例如可以由设备300的处理单元22和控制单元24中的至少一者来执行。

在动作70中，客户端可以监测数据分组是否被客户端接收。例如，客户端可以是分集接收器，分集接收器可以与图3的设备300类似。在执行动作70时，第一接收器电路16a和第二接收器电路16b可以被激活。如果未接收到任何数据分组，则进一步的动作72可以被执行。

在动作72中，客户端可以监测在预定时间间隔值x期间另外的数据分组是否被客户端接收。动作72例如可以类似于图7的动作64。在一个示例中，时间间隔的值x可以在大约90毫秒到大约110毫秒的范围内，并且其值具体地可以为大约100毫米。如果针对时间间隔x的持续时间客户端未接收到任何数据分组，则进一步的动作74可以被执行。否则，动作70可以再次被执行。

在动作74中，第二接收器电路16b中的至少一个组件可以被禁用。就这一点而言，第二天线端口14b可以或可以不被视为第二接收器电路16b的一部分。如果动作74已被执行并且相应的组件被禁用，则动作70可以再次被执行。

返回参照动作70，如果另外的数据分组被客户端接收，则进一步的动作76可以被执行。在动作76中，可以决定第二接收器电路16b是否被激活。动作76的决定可以取决于另外的动作78的结果。在动作78中，客户端和服务器之间的数据吞吐量可以被评估。具体地，这样的评估可以由客户端执行。下面描述了评估数据吞吐量的各种可能性。如果决定第二接收器电路16b被禁用，则动作74可以被执行。否则，动作70可以被执行。

在图8中，动作76到动作78被布置在虚线矩形中。在另外的方法中，矩形中的动作可以被省略。在这种情况下，如果在动作70中数据分组被接收到，则第二接收器电路16b可以维持活跃，而无需基于动作78另外评估第二接收器电路16b是否可被禁用。由于对第二接收器电路16b的激活可以引起客户端的功耗增加，因此额外应用矩形中的动作76和动作78可以降低客户端的功耗。

返回参照动作78，在下文中讨论了针对评估服务器和客户端之间的数据吞吐量的示例。所描述的可能性可以按任意方式被结合。此外，已结合图7的动作54讨论了用于评估客户端和服务器之间的数据吞吐量的各种示例。这些示例可适用于动作78。

在一个示例中，图8的动作78中的评估数据吞吐量可以包括以下动作：监测调度请求从客户端到服务器的传输。在这里，如果检测到调度请求的传输，则可以执行第二接收器电路16b的禁用(参见方法800的动作76)。返回参照图2a的情境，在非连续dl活动的部分(其中，调度请求可以从客户端被发送到服务器)期间不一定需要第二接收器电路16b。非连续dl活动的状态可以通过如上所述的对调度请求的传输的监测来检测。

在另外的示例中，图8的动作78中的评估数据吞吐量可以包括以下动作：基于在客户端处接收到的数据来检测数据速率。在这里，如果检测到的数据速率小于数据速率阈值，则可以执行对第二接收器电路16b的禁用。就这一点而言，结合方法700的动作54所做的所有论述也适用于动作78。返回参照图2a，数据速率具体地可以被用于检测客户端和服务器之间的数据传输是否位于非连续dl活动的部分中。

在另外的示例中，图8的动作78中的评估数据吞吐量可以包括以下动作：检测在客户端处从服务器接收第一数据分组和在客户端处从服务器接收后续第二数据分组之间的持续时间。在这里，如果持续时间大于时间阈值，则可以执行对第二接收器电路16b的禁用。就这一点而言，结合方法700的动作54所做的所有论述也适用于动作78。返回参照图2a，数据速率具体地可以被用于检测客户端和服务器之间的数据传输是否位于非连续dl活动的部分中。

在另外的示例中，图8的动作78中的评估数据吞吐量可以包括以下动作：检测客户端和服务器之间的数据传输的中止，其中中止可以是基于接收窗口的。在这里，如果检测到这样的中止，则可以执行对第二接收器电路16b的禁用。在客户端和服务器之间的通信期间，网络中的吞吐量可能不受接收窗口的当前大小的限制。然而，还可能发生这样的情况：接收窗口的大小改变为使得服务器和客户端之间的通信可能被中止的值。如果检测到这样的中止，则禁用第二接收器电路16b是合理的。

图9a示出了基于服务器和客户端之间的数据通信的时间/序列图。与图2a类似，横轴按秒表示时间，并且纵轴表示从服务器被发送到客户端的经确认的数据的吞吐量。例如，客户端可以与图3的设备300相对应。在这种情况下，在数据通信期间，仅第一接收器电路16a是活跃的，而第二接收器电路16b未被激活。

图9b示出了基于服务器和客户端之间的数据通信的时间/序列图。在数据通信期间，客户端的两个接收器电路被激活。也就是说，不同于图9a，在数据通信期间，第一接收器电路16a是活跃的，并且第二接收器电路16b也是活跃的。

更具体地，图9a和图9b的情境可以涉及文件的lteftp/tcp下载，其中图示出了文件下载的初始阶段。在这两种情况中，客户端例如可以与智能电话相对应，其中唯一的差别可能是在图9a的情况中，第二接收器电路保持不被使用。

图9a和图9b示出了文件下载的最初8到9秒的吞吐量。在图9a中，总吞吐量由图a表示，图a对应于与单个活跃接收器电路相关联的吞吐量。在图9b中，考虑两个mimo层的总吞吐量由图b表示，而仅考虑一个mimo层的吞吐量由图b’表示。在图9a和图9b中，文件下载在不同的时间开始。因此，横轴的明确标记被省略，而是在每个图中示出了长度大约为10秒的间隔。

可以看出，这两个设备的吞吐量首先上升到略低于10mbps的水平。在此时，针对两个天线设备的吞吐量的增加甚至可以略微减慢。在大约4到5秒后，吞吐量开始更快速地上升。在总共大约7到8秒后，仅使用单个接收器电路的设备的吞吐量位于略大于20mbps处。

在总共大约7到8秒后，就吞吐量而言，两个天线设备可以胜过单个天线设备。然而，在初始阶段期间，第二天线(即第二接收器电路)可能没有增益。因此，在最初7到8秒中，禁用第二接收器电路是合理的，从而使得可以节省功率。此外，在最初8秒中传送的数据的总量可以是8秒×10mbps的量级，即大约80兆比特＝10mb。该数据量可能大于网页的大小(例如大约1mb)。由于http(可用于文件下载)可以是基于tcp的，因此对于客户端来说在文件下载和网站下载之间不存在看得见的差异。由于1mb网站的下载仅花费大约1秒，因此如果在客户端和服务器之间的一个特定建立的连接期间检测到的数据量小于预定数据量阈值，使得第二接收器电路不活跃是合理的，这是因为使用第二接收器电路没有任何吞吐量增益。相反，第二接收器电路的激活可能消耗不必要的功率。例如，数据量阈值可以是大约1mb。在一个示例中，客户端和服务器之间“特定建立的连接”可以被定义为客户端和服务器之间在直接互相跟随的两个三向握手之间的时间期间的数据连接。在另外的示例中，客户端和服务器之间“特定建立的连接”可以被定义为在建立连接的三向握手和对建立的连接的后续中止之间的时间期间的数据连接。

示例

下文与另外的实施例有关。

示例1是一种方法，包括：在客户端的第一动态接收分集天线端口处从服务器接收数据；评估服务器和客户端之间的数据吞吐量；以及基于对数据吞吐量的评估来选择性地激活或禁用被耦合到客户端的第二动态接收分集天线端口的电路。

在示例2中，示例1的主题可以可选地包括：评估数据吞吐量包括监测调度请求从客户端到服务器的传输。

在示例3中，示例2的主题可以可选地包括：如果在大于预定第一时间阈值的时间间隔期间未检测到调度请求的传输，则选择性地激活被耦合到第二动态接收分集天线端口的电路。

在示例4中，示例3的主题可以可选地包括：第一时间阈值是100毫秒。

在示例5中，前述示例之一的主题可以可选地包括：如果检测到调度请求的传输，则选择性地禁用被耦合到第二动态接收分集天线端口的电路。

在示例6中，前述示例之一的主题可以可选地包括：评估数据吞吐量包括基于在客户端处接收到的数据来检测数据速率。

在示例7中，示例6的主题可以可选地包括以下各项中的至少一项：如果检测到的数据速率大于数据速率阈值，则选择性地激活被耦合到第二动态接收分集天线端口的电路；以及如果检测到的数据速率小于数据速率阈值，则选择性地禁用被耦合到第二动态接收分集天线端口的电路。

在示例8中，示例7的主题可以可选地包括：数据速率阈值是10兆比特每秒。

在示例9中，前述示例之一的主题可以可选地包括：评估数据吞吐量包括基于在客户端处接收到的数据来检测数据量。

在示例10中，示例9的主题可以可选地包括：如果在客户端和服务器之间的一个特定建立的连接期间检测到的数据量大于数据量阈值，则选择性地激活被耦合到第二动态接收分集天线端口的电路。

在示例11中，示例10的主题可以可选地包括：数据量阈值是1兆字节。

在示例12中，前述示例之一的主题可以可选地包括：评估数据吞吐量包括检测在客户端处接收第一数据分组和在客户端处接收后续第二数据分组之间的持续时间。

在示例13中，示例12的主题可以可选地包括以下各项中的至少一项：如果持续时间小于第二时间阈值，则选择性地激活被耦合到第二动态接收分集天线端口的电路；以及如果持续时间大于第二时间阈值，则选择性地禁用被耦合到第二动态接收分集天线端口的电路。

在示例14中，示例13的主题可以可选地包括：第二时间阈值在大约10毫秒到大约50毫秒的范围内。

在示例15中，前述示例之一的主题可以可选地包括：评估数据吞吐量包括检测客户端和服务器之间的数据传输的中止，其中中止是基于接收窗口的。

在示例16中，示例15的主题可以可选地包括以下各项中的至少一项：如果未检测到中止，则选择性地激活被耦合到第二动态接收分集天线端口的电路；以及如果检测到中止，则选择性地禁用被耦合到第二动态接收分集天线端口的电路。

在示例17中，示例15或16的主题可以可选地包括：检测客户端和服务器之间的数据传输的中止包括检查由客户端接收的数据分组。

在示例18中，示例15或16的主题可以可选地包括：中止由协议栈软件来检测。

在示例19中，前述示例之一的主题可以可选地包括：由协议栈软件生成触发信号，并且将该触发信号发送到控制单元，该控制单元被配置为选择性地激活和禁用被耦合到第二动态接收分集天线端口的电路。

在示例20中，前述示例之一的主题可以可选地包括：评估数据吞吐量包括：基于服务器和第一动态接收分集天线端口之间发送的数据来确定第一数据吞吐量；以及基于服务器和第一动态接收分集天线端口之间发送的数据以及服务器和第二动态接收分集天线端口之间发送的数据来确定第二数据吞吐量。

在示例21中，示例20的主题可以可选地包括：有选择激活或禁用电路包括将第一数据吞吐量与第二数据吞吐量进行比较。

示例22是一种方法，包括：在客户端的第一动态接收分集天线端口处从服务器接收数据；监测调度请求从客户端到服务器的传输；以及如果在大于预定时间阈值的时间间隔期间未检测到调度请求的传输，则选择性地激活被耦合到第二动态接收分集天线端口的电路。

在示例23中，示例22的主题可以可选地包括：时间阈值是100毫秒。

在示例24中，示例22或23的主题可以可选地包括：如果检测到调度请求的传输，则选择性地禁用被耦合到第二动态接收分集天线端口的电路。

示例25是一种设备，包括：第一动态接收分集天线端口和第二动态接收分集天线端口，各自被配置为从服务器接收数据；评估单元，被配置为评估服务器和设备之间的数据吞吐量；以及控制单元，被配置为基于对数据吞吐量的评估来选择性地激活或禁用被耦合到客户端的第二动态接收分集天线端口的电路。

在示例26中，示例25的主题可以可选地包括监测单元，监测单元被配置为监测调度请求从设备到服务器的传输。

在示例27中，示例25或26的主题可以可选地包括应用处理器，应用处理器被配置为运行协议栈软件，其中协议栈软件被配置为检测设备和服务器之间的数据传输的中止。

在示例28中，示例25或26的主题可以可选地包括应用处理器，应用处理器被配置为运行协议栈软件，其中协议栈软件被配置为生成触发信号并且将该触发信号发送到控制单元。

示例29是一种设备，包括：用于从服务器接收数据的第一接收装置；用于从服务器接收数据的第二接收装置；用于评估服务器和设备之间的数据吞吐量的评估装置；以及用于基于对数据吞吐量的评估来选择性地激活或禁用被耦合到客户端的第二动态接收分集天线端口的电路的控制装置。

在示例30中，示例29的主题可以可选地包括用于监测调度请求从设备到服务器的传输的监测装置。

在示例31中，示例29或30的主题可以可选地包括用于运行协议栈软件的处理装置，其中协议栈软件被配置为检测设备和服务器之间的数据传输的中止。

在示例32中，示例29或30的主题可以可选地包括用于运行协议栈软件的处理装置，其中协议栈软件被配置为生成触发信号并且将该触发信号发送到控制单元。

示例33是一种网络，包括：服务器；以及客户端，其中客户端包括示例22到29中的一个示例的设备。

示例34是一种其上存储有计算机指令的计算机可读介质，当指令由计算机执行时，使得计算机执行示例1到21中的一个示例的方法。

此外，尽管可能已经针对数个实现方式中的仅一个实现方式公开了本公开的特定特征或方面，但是这样的特征或方面可与如任意给定或特定应用所期望的并有益于任意给定或特定应用的其它实现方式的一个或多个其它特征或方面结合。此外，就详细描述或权利要求中使用术语“包括”、“具有”、“带有”或它们的其它变体这方面来说，这类术语以类似于术语“包含”的方式旨在是包含的。此外，要理解的是，本公开的各方面可被实现在分立电路、部分集成电路或完全集成电路或编程装置中。此外，术语“示例性”、“例如”和“比如”仅意味着作为示例，而不是最佳的或最优的。

此外，具体地关于由上述组件或结构(配件、设备、电路、系统等)执行的各种功能，除非另有说明，否则用于描述这类组件的术语(包括对“装置”的提及)旨在与执行所述组件的具体功能的任意组件或结构(例如，即功能等同)相对应，即使在结构上并不等同于执行本发明所示的示例性实现方式中的功能的所公开的结构。例如，任意组件或结构可以包括执行指令的处理器，以便执行各种功能中的至少一部分。

尽管本文已经示出和描述了具体的方面，但是本领域普通技术人员应当理解的是，在不脱离本公开的范围的情况下，可针对所示出和描述的具体方面替换各种替换和/或等同的实现方式。该申请旨在覆盖本文所讨论的具体方面的任何改编或变型。