自适应速率控制和业务管理的系统和方法与流程

文档序号:11455689阅读:352来源:国知局
相关申请的交叉引用本申请要求于2014年9月5日提交的美国临时申请第62/046,874号的优先权和权益,该美国临时申请与2014年3月4日提交的美国临时申请第61/947,982号有关。
背景技术
::1.
技术领域
:本发明的实施方式的各个方面涉及自适应速率控制和业务管理的系统和方法。2.
背景技术
:电子装置(包括便携式电子装置例如智能电话或平板电脑)的高带宽应用例如流视频使用的不断增加对无线数据网络例如蜂窝数据网络提出极大需求。目前,存在试图利用同一限制网络带宽的大量便携式装置以及在这些装置上运行应用(“app”)。虽然在装置上缓存服务器内容有助于针对同一数据的重复请求,但在许多这些高带宽应用的情况下经常或通常不是这种情况,例如当在便携式装置上实时地观看视频内容或收听音频内容时。当前移动通信系统例如蜂窝网络经受由于加速需求超出限制容量而引起的问题。容量受到以下限制:每个移动网络运营商的有限无线频谱、达到现有频谱的频谱容量的物理极限的技术以及接入新频谱的长期监管提前时间。同时,来自更多用户的变得移动并且移动装置变得更快/更智能的需求超出可用容量。容量不足的结果是网络拥塞、用户体验差、移动服务的盈利机会错失。用户需求与网络移动网络容量之间的不匹配存在很多原因,例如更快的装置、日益增加的数据荒或“嘈杂”应用以及移动视频的增长。移动视频消费是一个特别的问题,因为它比任何其他移动活动都更快地增加数据消耗,这主要归因于自适应视频流自动使用高达所有可用网络容量的固有行为。尽管自适应视频流被设计成允许装置针对较慢的网络将视频质量自动向下调节,但这也使得实现针对较快的网络将视频质量自动向上调节的相反行为,这种相反行为可能会导致用户意外高的数据使用。不幸的是,用户或移动网络运营商没有足够的洞察力或控制权来管理其数据使用,因此这种需求/容量不匹配通常导致用户体验差和/或终端用户成本高。移动运营商几乎或根本不能从网络查看到可能会过于繁琐或使用过多数据的特定应用,因此缺乏精确地调整/限制其对移动网络的影响。他们具有部署在网络中的现有工具例如智能交换机和代理服务器,用于监视和/或控制来自特定用户的数据消耗,但这些工具缺乏足够的粒度,因为它们无法可靠地识别用于特定业务的特定app。对于终端用户,他们几乎或根本没有控制权来管理其数据消耗,例如防止高带宽视频流耗尽其数据计划或允许/阻止特定app在漫游时使用数据。这阻止终端用户能够管理其数据消耗、成本和用户体验。技术实现要素:本发明的实施方式的各个方面涉及监视和控制便携式装置例如智能电话上的业务。其他方面涉及自适应速率控制和业务管理的系统和方法。本发明的实施方式的各个方面通过提供对来自移动装置内的应用级数据使用的检测和控制来解决这些和其他问题。更详细地,本发明的各个方面通过限制提供给移动app的数据速率例如利用自适应视频流来提供数据消耗的大幅降低。其他方面通过突发地接收去往app/装置的数据来减少无线电信令和蜂窝拥塞,从而减少装置连接至小区塔以接收数据所需要的总的时间量。另外其他方面提供了对移动app被允许/限制的网络容量的精细粒度跟踪和控制。因此,本发明的实施方式提供了处理由移动装置上的app执行的移动业务的能力。处理这种“带内”业务的能力使得各种监视和控制功能能够应用于移动app业务。在装置内处理这种业务的能力使得这些功能能够跨由装置所接入的任何网络。本发明的实施方式提供了可以在移动装置上实现带内监视和控制的多种方式,诸如使用代理配置、vpn隧道装置或者移动app内的请求拦截。本发明的实施方式涉及提高或优化数据流应用(诸如视频或音频)的带宽。本发明的实施方式涉及暂时存储一些内容(诸如预取接下来的几个视频块),包括服从视频或音频流技术的文件,例如调整多媒体流的质量以使可用带宽的比特率与其相匹配以传输流的abr(自适应比特率)。本发明的实施方式涉及自适应比特率(abr)控制(例如优化app以便以使利用现有协议的带宽使用最小化的方式来请求数据)以及连接控制(例如使连接到网络所需要的连接时间最小化以尽可能高效地获取数据)。本发明的实施方式涉及数据速度的比特率控制、预取流块(在app请求流块之前,以避免稍后打开连接)、基于策略的规则,其用于确定用于对数据速度的比特率控制的期望比特率控制速度以及在预取流块(例如视频流块)时的预取量,以及用于允许或不允许某些请求(例如,控制或限制app对网络的使用)。例如,对数据速度的比特率控制可以用于例如减少带宽使用,并且在一些情况下可以与预取流块结合以减小连接时间,例如对于流内容(例如视频)。基于策略的规则的用于控制这些的另一术语是“端点业务管理”,其可以用于限制app可以执行的请求的类型和频率。所有这些技术的关键方面是它们先前未在端点装置例如智能电话或平板电脑上被启用。在本发明的一种实施方式中,自适应比特率确定如何传送数据并且优化来自客户端的请求以利用这一点(缓冲多余内容直到用户真正想要它们)。在其他实施方式中,比特率控制确定如何将数据快速传送至请求它的app。例如,这可以适用于“自适应比特率流”,其中app具有对要请求的项目的多个尺寸的选择(例如,在多个分辨率下的相同视频)并且减慢速度将导致app选择较小尺寸的版本(由此使用较少的带宽)。在本发明的一种实施方式中,连接控制试图充分利用连接周期,然后断开连接以允许其他应用/用户接入网络直到其再次需要接入。在本发明的一种实施方式中,业务管理增加了系统当前不可用的许多可用性特征(安全性、使用监视等)。在一个或更多个实施方式中,这些特征可以是(对于终端用户而言的)可用性或者对于网络运营商(例如蜂窝提供商)而言的控制/保护。在一些实施方式中,它们可以依赖于或者具有位于端点装置上的业务流的中心点的业务管理器(例如代理),使得它们可以应用策略并且做出决策。在本发明的一种实施方式中,提供了一种在便携式通信装置上的通信业务管理的方法,该便携式通信装置具有计算机处理器和与计算机服务器的网络连接以用于利用处理器通过网络发送或接收数据。该方法包括:由在处理器上运行的业务管理器应用识别在处理器上运行并且通过网络传送去往或来自服务器的第一数据的第一应用;由业务管理器应用拦截去往或来自第一应用的第一数据的电子业务;以及由业务管理器应用控制去往或来自第一应用或者去往或来自服务器的第一数据的传送速率。对第一数据的传送速率的控制可以包括将由第一应用所感知的网络的当前速度节流成小于网络的当前速度的第一数据速率。第一数据的电子业务可以包括使用超文本传输协议的安全协议(https)传输的数据。对第一数据的传送速率的控制可以包括将去往或来自服务器的第一数据的传送速率节流成小于网络的当前速度的第一数据速率。第一数据的电子业务可以包括自适应比特率流。第一数据的电子业务可以包括渐进流。第一应用可以能够支持由清单控制的具有不同对应分辨率的多个数据速率。对第一数据的传送速率的控制可以包括编辑清单以隐藏或去除数据速率中的超过第一数据速率的数据速率。第一应用可以能够支持具有不同对应分辨率的多个数据速率。对第一数据的传送速率的控制可以包括使对数据速率中的超过第一数据速率的数据速率的接入失败或阻挡所述接入。该方法还可以包括:由业务管理器应用识别在处理器上运行并且通过网络传送去往或来自服务器的第二数据的第二应用;由业务管理器应用拦截去往或来自第二应用的第二数据的电子业务;以及由业务管理器应用控制去往或来自第二应用或者去往或来自服务器的第二数据的传送速率。对第一数据和第二数据的传送速率的控制可以包括同时限制第一数据和第二数据的传送速率使得第一数据的传送速率超过第二数据的传送速率。对电子业务的拦截可以包括使用在处理器上运行的内部代理。对电子业务的拦截可以包括使用处理器上的虚拟专用网络(vpn)接口。对电子业务的拦截可以包括在处理器上运行修改的第一应用,所述修改的第一应用被配置成请求对电子业务的拦截。在本发明的另一个实施方式中,提供了一种用于通信业务管理的系统。该系统包括:便携式通信装置,其具有计算机处理器和与计算机服务器的网络连接以用于利用处理器通过网络发送或接收数据;以及耦接至处理器的非易失性存储装置。该非易失性存储装置存储有下述指令,该指令在由处理器执行时使得处理器:识别在处理器上运行并且通过网络传送去往或来自服务器的第一数据的第一应用;拦截去往或来自第一应用的第一数据的电子业务;以及控制去往或来自第一应用或者去往或来自服务器的第一数据的传送速率。指令在由处理器执行时还可以使得处理器通过将由第一应用所感知的网络的当前速度节流成小于网络的当前速度的第一数据速率来控制第一数据的传送速率。第一数据的电子业务可以包括使用超文本传输协议的安全协议(https)传输的数据。指令在由处理器执行时还可以使得处理器通过将去往或来自服务器的第一数据的传送速率节流成小于网络的当前速度的第一数据速率来控制第一数据的传送速率。第一数据的电子业务可以包括自适应比特率流。第一数据的电子业务可以包括渐进流。第一应用可以能够支持由清单控制的具有不同对应分辨率的多个数据速率。指令在由处理器执行时还可以使得处理器通过编辑清单以隐藏或去除传送速率中的超过第一数据速率的数据速率来控制第一数据的传送速率。第一应用可以能够支持具有不同对应分辨率的多个数据速率。指令在由处理器执行时还可以使得处理器通过使对数据速率中的超过第一数据速率的数据速率的接入失败或阻挡所述接入来控制第一数据的传送速率。指令在由处理器执行时还可以使得处理器:识别在处理器上运行并且通过网络传送去往或来自服务器的第二数据的第二应用;拦截去往或来自第二应用的第二数据的电子业务;以及控制去往或来自第二应用或者去往或来自服务器的第二数据的传送速率。指令在由处理器执行时还可以使得处理器通过同时限制第一数据和第二数据的传送速率使得第一数据的传送速率超过第二数据的传送速率来控制第一数据和第二数据的传送速率。指令在由处理器执行时还可以使得处理器通过使用在处理器上运行的内部代理来拦截电子业务。指令在由处理器执行时还可以使得处理器通过使用处理器上的虚拟专用网络(vpn)接口来拦截电子业务。指令在由处理器执行时还可以使得处理器通过在处理器上运行修改的第一应用来拦截电子业务,所述修改的第一应用被配置成请求对电子业务的拦截。附图说明附图与说明书一起示出了本发明的示例实施方式。这些附图与说明书一起用于更好地说明本发明的各个方面和原理。图1是根据本发明的实施方式的适于与装置上业务管理实现一起使用的示例性移动装置(例如智能电话)架构的示意图。图2至图5是根据本发明的实施方式的使得能够实现对app与服务器之间的网络业务的监视和控制的代理内的软件组件的框图。图6是示出根据本发明的实施方式的通过代理处理app与服务器之间的请求的处理时序图。图7是根据本发明的另一实施方式的使得能够实现对app与服务器之间的网络业务的监视和控制的代理内的软件组件的框图。图8是示出根据本发明的另一实施方式的通过代理处理app与服务器之间的请求的处理时序图。具体实施方式现在将参照附图来描述本发明的示例实施方式。在附图中,相同或相似的附图标记始终指代相同或相似的元件。在本文中,在描述本发明的实施方式时使用术语“可以”是指“本发明的一个或更多个实施方式”。另外,在描述本发明的实施方式时使用替代语言例如“或”是指针对所列出的每个相应项的“本发明的一个或更多个实施方式”。在一个或更多个实施方式中,提供了用于管理移动装置内的网络业务的系统和方法。参考图1至图8来描述示例性实施方式。图1是根据本发明的实施方式的适于与装置上业务管理实现一起使用的示例性移动装置(例如智能电话)架构100的示意图。例如,移动装置可以是android电话。出于说明的目的,将假设移动装置是android智能电话。此外,尽管这样的移动装置可以能够支持许多用户,但为了便于描述,将假设移动装置专用于特定用户,因此术语“用户”和“移动装置”(或以个人或便携方式使用的任何计算装置)自始至终可以作为同义词使用。根据本发明的一个或更多个实施方式,移动装置上的一般架构(例如架构100)提供集中式代理130,该集中式代理130可以监视或控制源自应用(例如移动app或仅是“app”)到例如移动装置例如经由wi-fi或蜂窝网络接入的应用服务器(或app服务器)250的数据业务。这种方法使得能够跨多个网络(例如wifi和蜂窝)以及跨多个app来执行业务管理并且使得业务管理能够被集中管理,然而本发明不限于此。在其他实施方式中,业务管理可以以分布的方式执行,例如利用在每个app内运行的代理,其中,这些app以协作的方式工作使得整体装置业务被有效地集中管理。智能电话100的app和其他可编程组件可以例如被实现为存储在智能电话100的非暂态存储装置上并且被配置成在智能电话100的一个或更多个处理器上执行的计算机指令集。代理130还可以管理特定网站的业务,例如来自网络浏览器。因此,为了便于描述,当涉及由代理130管理的内容的类别时,诸如“应用”、“app”、“网站”或“站点”的术语在本申请中可以互换地使用。代理130可以从许多不同的机制被接合,例如(例如经由操作系统(os)网络设置)使用套接字层120的代理服务器、(例如经由os网络设置)使用网络隧道(tun)装置230的虚拟专用网络(vpn)服务,或者嵌入在使用拦截层150的app内。代理130可以在java虚拟机(jvm)160上运行。代理可以包括用于管理物理存储装置例如闪存170或其他非易失性存储装置上的缓存内容的缓存引擎110。在不失一般性的情况下,这样的装置有时被称为“磁盘”,尽管它可以是任何类型的非暂态存储装置例如固态驱动器。另外,缓存的或任何其他存储的内容可以全部或部分地存储在易失性存储器例如随机存取存储器上,并且该易失性存储器可以与非易失性存储器结合使用,例如以分层的方式,其中最近接入的内容在被转移至较慢的非易失性存储之前被存储在较快的易失性存储器中。代理130可以以各种形状因素例如应用、内核驱动器或者在移动装置上的os内运行,并且可以被配置成例如经由os网络设置来接收网络连接。在一个或更多个实施方式中,代理服务器可以在jvm中运行。代理130可以用作代表客户端应用的中介。例如,代理130可以对另一jvm165中运行的app180的请求进行服务。app180可能想要使用例如诸如httpurl连接(httpurlconnection)190的android服务来接入因特网。这里,http代表超文本传输协议,url代表统一资源定位符(例如网址)。然后,httpurl连接190可以调用网络服务200来接入因特网。网络服务200可以例如使用接入点名称(apn)210(例如,诸如3g的移动网络)或wi-fi连接220来接入因特网。网络服务200可以被配置成将来自app180的请求路由到apn或wifi连接或者使用全局应用于系统的代理配置的代理服务器130。网络服务200还可以使用各种其他方式例如经由网络隧道(tun)装置230或ip路由表(也称为“iptable”)将来自app180的请求路由到代理130。网络服务200可以被配置成直接或间接地指定代理(例如,作为由装置上运行的app直接检测到和使用的全局系统代理或者通过apn210或wi-fi连接220上的设置间接地)来接入因特网,使得可以通过标准通信层例如由代理130接收的套接字120(例如,用于连接至因特网的网络套接字)来发送请求。代理130进而可以通过网络服务200(同时绕过apn或wi-fi代理配置以避免循环回到自身)向app服务器250做出请求,该app服务器250对请求进行服务并且向代理130返回任何响应通信。然后,代理可以监视或控制app与服务器之间的通信。代理130还可以在逆向经由相同的描述阶段通过网络套接字120将响应返回至app180之前经由缓存引擎110缓存一些响应、不缓存响应或缓存全部响应。代替使用apn或wi-fi连接上的代理配置,网络服务200还可以被配置成通过各种其他方式将请求路由到代理服务器130。例如,另一种方法是使用网络隧道(tun)230来建立vpn连接,该vpn连接可以将网络活动路由到vpn服务140以处理网络传输。然后,vpn服务140可以将请求路由到代理130以使用套接字120(视情况)来管理app与app服务器250之间的业务,以对请求进行服务并且经由网络隧道230返回响应。用于连接代理130的另一机制是使用app内的拦截层(例如,拦截层150和拦截层155)来将业务重定向到代理进程。例如,在上述示例中,在使httpurl连接190调用网络服务200以接入因特网之前或替代使httpurl连接190调用网络服务200以接入因特网,httpurl连接可以使拦截层150拦截来自app180的请求并将其业务直接转发到代理130。从拦截器150到代理130的转发可以通过网络服务200或者通过使用标准的进程间通信机制——如对本领域普通技术人员明显的,例如消息队列、命名管道或共享存储器——来执行。除了在单独的进程中——例如,在jvm160内——操作的代理130之外,在其他实施方式中,代理130可以嵌入在请求进程例如jvm165或浏览器185(例如网络浏览器)内。然后,代理130可以管理app的网络业务,而不需要任何进程间通信。在另一示例中,网络浏览器185寻求接入因特网。类似于上面的app180,网络浏览器185可以通过多种不同的方法利用代理130。例如,网络浏览器185可以被配置为通过使用网络套接字125来接入因特网,网络套接字125然后可以使用网络服务200采用例如如上所述的套接字120或vpn服务140来接入app服务器250和/或代理130。以相似的方式,拦截层155可以被添加到网络浏览器185,网络浏览器185然后可以拦截来自网络浏览器185的请求并将其业务转发到代理130。更详细地,上述技术可以集成到现有的接口中,并且可以区分安全套接字层(ssl,例如,加密的)通信和非ssl(例如,未加密的)通信。可以例如在网络堆栈中的集中位置中为非ssl通信启用与应用的集成。例如,代理130可以被配置为用于网络协议的全部或子集的代理,例如仅用于http、https或两者。类似地,代理130可以被配置为用于网络接口的全部或子集的代理,例如用于蜂窝、wifi或两者。例如,对于apn210接入,蜂窝接入点可以被设置为代理130。对于iptables接入,可以设置相应的因特网协议(ip)路由表条目。对于vpn服务,vpn客户端(例如vpn服务140)可以将业务路由到代理130。对于wi-fi,可以为每个wi-fi接入点(ap)设置代理130。对于全局系统代理,系统可以将所有应用业务的业务引导到代理130。此外,与使用加密通信——例如ssl或tls——的应用的集成可能需要接入未加密的网络数据。存在这里可以使用的许多方法。对于中间人方法,可以通过经由受信任的证书颁发机构(ca)模拟服务器来获得对加密数据的接入。对于软件开发工具包(sdk)方法(例如,利用图1中的拦截层155),可以在加密层之上使用挂接到缓存引擎110的建立时间链接。对于重新链接方法,现有app可以被反编译并重新链接以使用自定义替换应用编程接口(api),例如使用httpurl连接190。对于替代方法,例如使用如网络浏览器185的浏览器,在拦截已经被接入的地方可以提供app的替代版本。这可能特别适用于广泛使用的开源app。虽然图1主要针对移动装置的架构100,但是装置上业务管理还可以需要其他组件,例如被配置为在移动装置100的一个或更多个处理器上运行的软件组件。图2至图5是根据本发明的实施方式的代理130内的使得能够监测和控制app310和服务器250之间的网络业务的软件组件的框图。在图2中,在移动装置100内运行的app310与app服务器250进行通信,并且代理130将使用先前讨论的任何方法——例如通过系统代理设置或vpn——拦截app的网络业务。在代理130内,在本发明的一个或更多个实施方式中,存在执行网络业务监测和控制的逻辑软件组件,并且这些软件组件可以包括可以处理与app310连接的数据路径325的客户端处理机(clienthandler)320和可以处理与app服务器250连接的数据路径335的请求处理机(requesthandler)330。取决于用于拦截app的网络业务的方法,例如网络套接字或对于本领域普通技术人员明显的任何其他标准的进程间通信机制,app310和客户端处理机320之间的数据路径325可以通过不同的机制进行。取决于app310通常如何与app服务器250通信,例如采用使用tcp/ip的网络套接字,请求处理机330和app服务器250之间的数据路径335也可以通过不同的机制进行。通过将与app310连接的内部数据路径和与app服务器250连接的外部数据路径分离,这允许代理130分别控制app310和app服务器250的数据速率,例如将数据以比可以实际传送去往/来自app服务器250(通过数据路径335)更慢的速率传送去往/来自app310(通过数据路径325)。根据本发明的另一个实施方式,可以使用比特率管理机(bitratemanager)340来管理去往/来自app310或去往/来自app服务器250的适当比特率(也称为数据速率)。这允许单独的软件组件实现对于比特率的一个或更多个策略,例如对于不同用户的不同比特率,对于不同app的不同比特率,基于先前数据消耗的不同比特率,对于不同网络类型的不同比特率,以及对本领域普通技术人员明显的其他变型。对于不同用户实现比特率的策略可以包括用户或用户类别的列表,其中用户类别可以是任何用户组,例如按装置类型(例如,智能手机对平板电脑)、装置模型或数据计划。对于不同app实现不同比特率的策略可以包括每app或app类别比特率的列表,其中app类别可以是任何分组的app,例如按功能(例如,视频、社交、电子邮件等)、按供应商或按一些其他类别(例如,工作对个人)。[01]基于app的策略也可以基于app运行的方式或时间,例如当app对用户可见(例如,在与后台相反的前台运行)时允许更高的比特率,或者在正在运行较高优先级的app时对于低优先级app执行较低的比特率。对于不同网络类型实现不同比特率的策略可以包括每网络类型(例如,wifi、lte、hspa、cdma等)比特率的列表或特定网络——例如,特定蜂窝塔或wifi热点——的列表。基于网络的策略还可以基于与网络相关联的所有权或成本,例如当接入用户数据计划的运营商拥有的家庭网络时较高的比特率而当用户在由另一运营商拥有的网络上漫游时较低的比特率。由比特率管理机管理的速率限制不限于仅在位级别,并且还可以包括以其他增量或单位对业务的速率的限制,例如通过请求、分组(例如tcp段或ip分组)、网络连接、或对本领域普通技术人员明显的其他粒度。例如,可以期望通过某些网络类型的“聊天”app来限制请求的频率以控制/最小化它们可能导致的拥塞,因为一些类型的网络(例如,2g和3g蜂窝网络)可能具有有限数量的可以同时支持的连接。上述策略中的任何策略可以是例如由用户提供的、由app预配置的、或者从外部系统例如管理服务器接收的。上述策略中的任何策略也可以扩展到具有多个或可变速率限制,例如基于先前的数据使用或业务活动而变化的速率限制。例如,基于app的策略可以允许随着app的数据消耗增加而减少多个比特率级别,例如以允许具有较低数据消耗的app在较高(甚至无限制)的比特率下运行,同时在较高带宽app超过一个或更多个阈值时限制所述较高带宽app。例如,当app310执行从app服务器250接收数据的请求时,该请求将最初由客户端处理机320接收,客户端处理机320然后将其传递给处理该请求所需的适当类型的请求处理机330。代理130可以支持一个或更多个类型的请求处理机,例如图3中的可以将请求传递到app服务器250的通过处理机(passthroughhandler)331。另一种类型的请求处理机可以是图4中的来自缓存服务处理机(servefromcachehandler)332,其可以通过根据需要与缓存引擎110和app服务器250进行交互来验证缓存的数据的新鲜度使用来自缓存的内容响应所述请求。另一类型的请求处理机可以是图5中的节流处理机(throttlinghandler)333,其可以例如通过以比可以以另外的方式由外部网络或服务器支持的速率低的速率发送请求数据或接收响应数据来控制与app服务器250连接的数据路径的速率。在本发明的实施方式中,每个类型的请求处理机可以被实现为请求处理机超类的子类。请求处理机负责响应请求并向客户端处理机320提供响应,客户端处理机320然后将响应传送到app310。当客户端处理机320从请求处理机接收到响应数据时,它可以将响应数据发送到app310,并且可以基于由比特率管理机340提供至其的速率限制来控制数据被发送的速率。客户端处理机320可以以对普通技术人员明显的各种方法来实现速率限制,例如通过每时间间隔发送特定量直到整个响应被传送为止。在本发明的一个实施方式中,客户端处理机320可以被配置成每秒向app310传送数据,以便从app服务器250接收数据,客户端处理机320将以每秒不高于由比特率管理机340指定的每秒速率限制的量传送数据。例如,如果比特率管理机340向客户端处理机320指示应将app310的数据速率限制为每秒1000千位,那么客户端处理机320将向app310传送每秒最高达1000千位,直到整个响应被传送。这允许请求处理机330以与客户端处理机320将该数据传送到app310的速率不同(例如更高)的速率从app服务器250接收数据。请求处理机330可以通过将数据存储在可以是易失性或非易失性的装置存储器中以比客户端处理机320将数据发送到app310更高的速率从app服务器250接收数据。非易失性存储器可以更丰富,因此如果需要缓冲大量数据,则可以使用非易失性存储器,例如当以与客户端处理机320向app310传送的速率相比显著更高的速率从app服务器250接收数据时。根据本发明的实施方式,当客户端处理机320尚未准备好将所接收的数据发送到app310时,节流处理机333可以管理缓冲,例如将从app服务器250接收的数据的一部分存储到非易失性存储器。节流处理机333也可以对从app服务器250接收数据的数量或速率进行限制,例如避免超出装置上可用的存储器或存储装置。例如,数据路径335可以是基于tcp的网络套接字,并且节流处理机333可以停止从网络套接字接收数据,这将导致当该网络套接字上的tcp接收窗口已满时,app服务器250停止发送数据。诸如节流处理机333的请求处理机可以分析从app服务器250接收的数据,以确定从app服务器250接收数据的速率。在一些情况下,可以期望以视频app实际消耗数据的速率来接收视频数据,以避免接收如果用户停止观看(但是继续接收)视频而将不会被消耗的视频数据。这种方法可以应用于不同类型的app,因为app消耗数据的速率与网络/服务器能够快速传送该数据的速率之间通常几乎没有关系。例如,mpeg-4视频可以以低于移动装置可以当前从网络/服务器接收该视频数据的速率的比特率进行编码,例如当该装置在未被占用的蜂窝基站上具有良好的蜂窝信号时。因此,如果以2mbps的比特率编码mpeg-4视频,并且装置正在以4mbps接收该数据,如果用户没有观看整个视频,则有可能浪费大量例如50%所接收的视频数据。本发明的一个或更多个实施方式可以通过将视频编码比特率与网络传送比特率匹配来解决这个问题。根据本发明的实施方式,代理130可以通过解析从app服务器250接收的数据来协调视频和网络比特率。当app310请求来自app服务器250的视频时,节流处理机333可以解析所接收的数据以确定视频编码比特率,其可以用于确定将从app服务器250接收数据的速率。例如,使用先前的示例,当节流处理机333检测到以2mbps编码的视频时,可以确保以等效速率从app服务器250接收数据,所述等效速率可能调整得稍高以适应网络传送速率中的任何已知/检测到的变化。通过限制到app310的数据传送速率,本发明的实施方式可以基于诸如自适应比特率(abr)视频流的速率来减少适应其数据大小的内容的数据消耗。abr流技术的示例包括http上的动态自适应流(dash)、用于flash的adobe自适应流、http实时流(hls)和微软平滑流。例如,youtube视频被编码为各种视频分辨率,每个视频分辨率都对应于特定的数据传送速率,使得youtubeapp请求可以由其感知的数据传送速率支持的最高视频分辨率。下表显示了与每个视频分辨率质量对应的youtubeapp的估计数据使用率,其中只有当感知到的网络速度超过与该视频对应的数据使用率时,youtubeapp才会选择该分辨率。代理130可以通过使用在所需视频分辨率处或恰好高于所需视频分辨率的比特率限制来有效地控制youtubeapp选择哪个分辨率。对abr流应用比特率限制的结果是,与最高可能分辨率相比,可以显著降低总数据消耗,达到超过90%,而不会导致视频的任何延迟或缓冲。唯一的影响在于较低分辨率的视频,并且用户可能愿意观看较低分辨率的视频以节省其数据使用成本。如表所示,数据使用差异在每个分辨率等级之间是显著的,并且通常比分辨率的相应增加更快。例如,从360p到720p的分辨率增加2倍将导致数据消耗增加3.4倍。只有一个分辨率等级的减少可能会显著降低数据使用,例如从1080p到720p的分辨率降低为33%,但在数据使用减少方面将减少53%。在小型移动装置上,用户可辨别的可视质量差异可能很小,同时提供50%以上的数据节约。图6是示出根据本发明的实施方式的通过代理处理app和服务器之间的请求的进程时序图。图6示出了限制比特率的本发明的实施方式,以例如减少蜂窝连接上的数据消耗。当app310执行对来自app服务器250的诸如视频的数据的请求时,客户端处理机320在步骤410拦截该请求。客户端处理机320可以确定如何处理该请求,或者可以向请求管理机(requestmanager)350提供该请求以进行可以分配节流处理机333来处理请求的确定。节流处理机333可以在步骤415与比特率管理机340协商,以例如基于与app相关联的策略、网络类型或正被请求的数据类型来确定适合于应用的比特率限制。客户端处理机320在步骤420向节流处理机333提交请求,节流处理机333处理与app服务器250的交互以处理该请求。当app服务器250在步骤425开始发送针对请求的响应时,节流处理机333可以解析响应,例如以确定应该从服务器接收数据的速率。当从app服务器250接收到响应数据时,在步骤430,节流处理机333可以将响应数据存储在易失性存储器、非易失性存储器或其组合中。当从app服务器250接收到数据时,客户端处理机320在步骤435可以将存储的响应数据传送到app310,这可以以与由节流处理机333从app服务器250接收的速率不同的速率发生。当在步骤440接收到对于第一请求的另外响应数据时,上述继续。当响应完成时,app310可以在步骤445继续发出对于后续数据的另外的请求,例如对于分解成可以通过httpurl可单独寻址的分离的基于时间的块的abr视频流。可以假设图6持续到app310所请求的数据完成,这对本领域普通技术人员是明显的。根据本发明的另一个实施方式,可以通过其他方式来控制比特率限制,例如通过修改由app服务器250报告的流的列表。例如,若干abr流方法依赖于使服务器经由称为清单的列表将可用流通知app。当最初请求视频时,app将从服务器获取清单,并且选择要播放的流,其中选择通常将基于app感知的网络速度。因此,控制比特率的另一种方法是修改从服务器接收到的清单,例如限制到app的可用流。例如,当app310从app服务器250请求清单时,代理130可以在将清单传送到app310之前修改清单并从其中移除较高分辨率的视频流,从而限制app310仅能够播放清单中剩余的流。这有效地允许代理130将app310限制在由比特率管理机340指定的策略中允许的那些流。该方法可以应用于服务器向客户端提供多个流或向客户端广告多个流的任何流传输方式,其中可用流集然后可以通过本发明的实施方式被修改。根据本发明的另一个实施方式,可以控制比特率限制的另一种方式是通过拒绝或以另外的方式阻止接入由服务器提供或广告的流集内的一个或更多个流。例如,代理130可以允许接入由app310所请求的一个或更多个可用流,同时阻止接入其他流,这将有效地允许代理130将app310限制在由比特率管理机340指定的策略中允许的那些流。存在可以阻止接入流的多种方式,包括拒绝连接、返回请求的错误或允许请求超时。这种方法可以选择性地应用于支持它的特定app,因为一些app可能无法正确支持某些阻止机制,并且可能需要以特定方式阻止。根据本发明的另一实施方式,代理130可以支持突发地接收数据,使得装置从app服务器250如何接收数据的大小或频率不同于app310可以如何以另外方式请求或接收数据。例如,由于用户可能无法观看整个视频,因此可以期望仅下载所观看的视频的下一局部部分,例如接下来的30秒,而不是整个5分钟的渐进视频。在这种情况下,例如,快速网络和快速服务器会允许整个5分钟视频被下载,即使用户仅观看了10秒钟,所有这些仍然不利于用户的数据计划。另一方面,可能不希望一次下载的视频太少,例如对于abr视频通常一次仅下载7秒,因为这可能会阻止蜂窝无线电和连接在任何时候成为空闲。在这种情况下,蜂窝无线电可以保持在活动的高功率模式下,因为其不活动定时器可能比每次下载的视频量(例如,5秒)长(例如15秒)。在蜂窝网络中,这可能导致增加的信号塔信令、拥塞和装置电池消耗。根据网络的类型和实际速度,可以期望以不同的突发尺寸接收数据,以便在足够下载之间进行平衡以允许蜂窝无线电变得空闲而不下载太多以避免浪费不消耗的数据。图7是根据本发明的另一实施方式的代理130内的使能够监测和控制app310和服务器250之间的网络业务的软件组件的框图。图7示出了本发明的实施方式,其中突发处理机(burstinghandler)334是提供用于从app服务器250突发地请求或接收数据的一种类型的请求处理机,使得该数据可以以与在没有代理130或突发处理机334的情况下由app310以另外的方式进行的不同的量或者不同的频率被请求或接收。突发处理机334在数据路径335上从app服务器250请求数据,独立于客户端处理机320在数据路径325上向app310发送/接收数据。突发处理机334可以与比特率管理机340协调以基于各种因素(例如,提高或最大化效率和性能)确定从app服务器250请求/接收数据的适当速率。例如,增加或最大化蜂窝连接的空闲时间的因素可以包括网络类型(例如,lte、edge等)、有效网络速度、网络不活动定时器(例如,15秒)以及视频编码比特率。作为又一示例,我们可以使用以下等式基于期望的网络空闲时间、网络传送比特率和视频编码比特率来计算所需的突发(burst)尺寸:<期望空闲时间>/<比特率比率>*<视频编码比特率>=<突发尺寸>在此,比特率比率是视频编码比特率和网络传送比特率之间的比率,例如当以2mb每秒编码视频并且来自网络的数据传送速率为每秒4mb时的值为0.5。例如,采用该相同的比特率比率,如果期望的空闲时间为45秒,例如以允许15秒的不活动时间窗口后跟30秒的休眠时间窗口,则突发尺寸被计算为:45秒/0.5*2mb/秒=180mb应当注意,可以由于其他原因而考虑另外的因素来确定突发尺寸,例如以改善装置的电池寿命、避免视频流的停止、或对本领域普通技术人员明显的其他场景。图8是示出根据本发明的另一实施方式的通过代理130在app310和服务器250之间处理请求的进程时序图。图8示出了执行突发的本发明的实施方式,例如以增加或最大化蜂窝连接的空闲时间。当app310执行对来自app服务器250的诸如视频的数据的请求时,客户端处理机320拦截该请求。客户端处理机320可以在步骤510确定如何处理该请求或者可以向请求管理机350提供该请求以进行可以分配突发处理机334来处理请求的确定。客户端处理机320在步骤515将请求提交给突发处理机334,突发处理机334处理与app服务器250的交互以处理该请求。当app服务器250在步骤520开始发送针对该请求的响应时,突发处理机334可以解析响应,例如以确定应该从服务器接收数据的速率,并且还可以与客户端处理机320协调以设置数据应传送到app310的速率。随着从app服务器250接收到响应数据,在步骤525,突发处理机334可以将响应数据存储在易失性存储器、非易失性存储器或其组合中。突发处理机334可以计算突发尺寸并且基于诸如实现最小的蜂窝空闲时间的策略在步骤530开始接收另外的数据直到所确定的突发尺寸。如果数据流包括一个或更多个可单独寻址的数据块,例如每个数据块通过httpurl单独寻址,则突发处理机334可以发出必要的请求以接收数据直到目标突发尺寸。当接收到目标突发尺寸的数据时,突发处理机334然后可以在步骤535停止接收数据,其可以包括关闭相关联的网络连接,例如开始目标空闲时间开始的tcp连接。当从app服务器250接收到数据时,客户端处理机320在步骤540可以将存储的响应数据传送到app310,这可以以与由突发处理机334从app服务器250接收的速率不同的速率发生。这在步骤545中继续并且根据需要超出,直到在第一个突发中接收到的数据已被传送到app310。当下一个突发已准备好开始时,突发处理机334在步骤550可以开始从app服务器250请求后续数据,并且在步骤555开始存储对于客户端处理机320的下一个突发,客户端处理机320然后可以以可以与由突发处理机334从app服务器250接收的速率不同的速率将随后的响应数据传送到app310。如对本领域普通技术人员明显的,假定图8可以持续到app310所请求的数据完成。虽然已经结合某些示例性实施方式描述了本发明,但是应当理解,本发明不限于所公开的实施方式,而是本发明旨在覆盖对本领域普通技术人员明显的在不脱离由所附权利要求及其等同物限定的本发明的精神和范围的情况下的各种修改和等同布置。当前第1页12当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1