具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
需要说明的是,本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。
下面对本申请实施例涉及的若干名词进行简单介绍:
MPTCP(MultipaTH TCP):是多路径TCP(TransmissionControl Protocol,传输控制协议),与传统单路径TCP相比,在传输数据时使用多条传输路径传输数据,以此来提高带宽资源利用率。
UDP(User Datagram Protocol,用户数据报协议):一种无需建立连接就可以发送封装的数据包的传输层协议。
QUIC(Quick Udp Internet Connection,快速UDP互联网连接):是指基于UDP的一种传输层协议。
MPQUIC(Mutipath QUIC,多路径QUIC):支持同时在多条基于QUIC的传输路径上传输数据,通过多路径传输提高整体的传输效率。
QoE(Quality of Experience,体验质量)反映设备、网络、系统或应用为用户提供的服务质量。在自适应视频流中,QoE通常包括视频质量、卡顿时间及视频质量的平滑程度等信息。
DASH(Dynamic Adaptive Streaming over HTTP,基于HTTP的动态自适应流):是一种自适应流媒体的传输协议;
ABR(Adaptive BitRate,自适应码率)算法:是一种根据网络环境及播放缓冲区水平,动态选择视频块的质量级别的算法。
自适应视频流:一种码率可以随着网络环境及播放缓冲区水平进行动态调整的视频流。对于点播场景而言(如DASH标准下),其调整码率粒度通常为视频块级别。
重注入:在多路径传输场景中,在其他传输路径上重传某一传输路径的数据包,以优化多路径的传输性能,重注入的数据包可以是任何未发送或已发送但未被接收端确认的数据包。
RTT(Round-Trip Time,往返时延):是指从发送端发送数据开始,到收到来自接收端的确认所经历的时延。
ACK(Acknowledgement,确认信息):在数据通信中,接收端发给发送端的一种传输控制类消息,表示发来的数据已确认接收。
码率(Bit Rate):也称比特率或位速率,是单位时间内传输的数据量(如视频数据),单位是bps(bit per second,比特每秒),一般使用kbps(千比特每秒)或Mbps(百万比特每秒)。
应用:为用户提供应用服务的应用程序,具有网络传输的用户接口功能,可以通过传输层为其提供与对端应用之间的通信服务,应用处于网络协议规定中的应用层中。
传输层:是网络协议规定中的传输层,主要负责在两端应用之间提供通信服务。由于同一端可能同时运行多个应用,因此传输层具有复用和分用功能。
实际应用中,在一些视频服务或其他涉及大规模数据传输的服务中,通常采用多路径传输方式,例如QUIC(MPQUIC)进行多路径传输。一方面能够利用多条路径的带宽,提高数据传输的吞吐量,另一方面有利于提高数据传输的鲁棒性,即在一条路径的性能下降时,可以在其他路径上完成数据传输。然而,研究发现当出现多路径队首阻塞问题会降低多路径传输的性能,这是因为在发生多路径队首阻塞时,需要等待非空闲路径上的数据包,导致多路径传输性能取决于传输速度最慢的传输路径。
以图1a为例,服务端设备中的数据包调度器对两条路径进行调度,将数据包从两条不同的路径发送给客户端设备,有的数据包,如图1a中的数据包2、数据包3和数据包4通过传输速度相对较快的快路径传输,能够提前到达客户端设备;有的数据包,如图1a中的数据包1,通过传输速度相对较慢的非空闲路径传输,导致数据包1到达客户端设备的时间比较晚。即便数据包1的发送时间早于数据包2、数据包3和数据包4,由于非空闲路径的因素,已经到达客户端设备的数据包2、数据包3和数据包4,需要等待数据包1到达客户端设备后,才可以一起提交给客户端设备上的应用进行处理,这就是多路径队首阻塞。由此可知,多路径队首阻塞问题会导致多路径的整体传输性能下降。
重注入被广泛应用于解决队首阻塞问题,其原理是利用空闲路径重传非空闲路径上的数据包,在空闲路径的性能优于阻塞路径的情况下,就能提前完成传输,有效提升多路径的传输性能。以客户端设备向服务端设备请求传输视频块为例,客户端设备向服务端设备请求视频块,服务端设备根据客户端设备的请求,通过其与客户端设备之间的多条传输路径向客户端设备发送视频块的所有数据包;在将所有数据包发出后等待ACK返回的最后1个RTT(针对最后发出的数据包给客户端设备留出返回ACK的时间),此时,服务端设备开始执行重注入操作。执行重注入操作时,服务端设备查看非空闲路径上有哪些数据包没有收到ACK,如果非空闲路径上有数据包没有收到ACK,且快路径上处于空闲状态,就可以通过快路径重新发送非空闲路径上没有收到ACK的数据包,以便于这些数据包能够被快速传输到客户端设备,提高整体传输效率。
在重注入过程中,重注入的数据包会引起数据冗余,冗余数据的传输会消耗额外的流量资源。另外,执行数据包的重传需要选择重传使用的传输路径,如果被选择的传输路径的传输性能后来变差了,可能导致重传数据包的再次堵塞,这不仅会消耗额外流量,还会造成带宽资源的浪费。再者,发送完所有数据包之后,自动执行重注入操作,有可能会执行不必要的重注入,这也会引起流量和带宽资源的浪费。因此,有必要提供一种重注入控制方法,能够在保证多路径传输性能的情况下,减少传输的冗余数据量,节约重注入引起的流量和带宽资源的浪费。
基于上述,本申请实施例提供一种多路径传输的重注入控制方法、电子设备以及存储介质,在本实施例中,在多路径传输的重注入过程中引入应用请求对应的预期传输时间,以应用请求对应的预期传输时间作为允许执行重注入操作的时间依据,能够在更加合理的时间利用多路径中的空闲路径对非空闲路径上的数据包进行重传(即执行重注入操作)。由于在多路径传输中执行重注入操作,所以能够保证多路径传输的性能,又因为重注入操作的执行是以应用请求对应的预期传输时间为依据的,所以既能保证应用的用户体验,又能在一定程度上减少被执行重注入的数据包,减少多路径传输中的冗余数据量,节约流量和带宽资源。
以下结合附图,详细说明本申请各实施例提供的技术方案。
本申请实施例提供的多路径传输的重注入控制方法可以应用于第一端和第二端之间基于多路径的数据传输过程中。第一端可以理解为数据传输过程中发送端,第二端可以理解为数据传输过程中的接收端。第一端例如可以是客户端设备,相应地,第二端例如可以是服务端设备,即在客户端设备通过多路径向服务端设备发送数据的过程中可以采用本申请实施例提供的重注入控制方法;或者,第一端例如可以是服务端设备,第二端例如可以是客户端设备,即在服务端设备通过多路径向客户端设备发送数据的过程中也可以采用本申请实施例提供的重注入控制方法,但并不以此为限。
在此说明,本申请实施例中的第一端和第二端运行有对应的应用,两端的应用可以通过两端之间的多条传输路径进行多路径数据传输,并在多路径传输过程中采用本申请实施例提供的重注入控制方法解决拥堵路径上数据包的重传问题,提高多路径传输的性能。换句话说,本申请实施例提到的多路径传输以及多路径传输中的重注入控制方法应用在第一端的传输层与第二端的传输层之间。其中,客户端设备的应用可作为应用客户端,主要面向用户,支持与用户交互,响应用户的请求,并向服务端设备上的应用请求相关服务或数据;相应地,服务端设备上的应用可作为应用服务端,主要响应应用客户端的请求并进行处理,为应用客户端提供数据存储等各种服务。另外,从应用所实现的功能来看,本申请实施例并不对应用的实现形态进行限定,例如可以是视频类应用、邮件服务类应用、在线购物类应用、游戏类应用等等。
下面结合图1b和图1c,对本申请实施例提供的多路径传输场景进行说明。
如图1b所示,第一端为客户端,第二端为服务端,客户端与服务端之间存在多条传输路径,在图1b中,以Wi-Fi(Wireless Fidelity,无线保真)、5G(5Generation,5代)和4G(4Generation,4代)三条传输路径为例进行图示,但并不局限于这些传输路径。客户端设备上的应用需要向服务端设备上的应用发送第一数据,第一数据例如可以包括向服务端设备上的应用请求第二数据的数据请求或需要上传到服务端设备的应用数据等;此时,客户端设备可响应客户端设备上的应用的数据传输需求,通过与服务端设备之间的多条传输路径向服务端设备发送第一数据,简称为对第一数据进行多路径传输。其中,在对第一数据进行多路径传输时,可以将第一数据封装为至少一个数据包,通过多条传输路径传输第一数据中的数据包。
如图1c所示,第一端为服务端设备,第二端为客户端设备,客户端设备与服务端设备之间存在多条传输路径,在图1c中,以Wi-Fi、5G和4G三条传输路径为例进行图示,但并不局限于这些传输路径,例如还可以包括蓝牙、红外等其它传输路径。服务端设备上的应用向客户端设备上的应用发送第二数据,第二数据例如可以包括向客户端设备上的应用返回的应用数据或者向客户端设备上的应用发送的通知消息等;此时,服务端设备可响应服务端设备上的应用的数据传输需求,通过与客户端设备之间的多条传输路径向客户端设备发送第二数据,简称为对第二数据进行多路径传输。其中,在对第二数据进行多路径传输时,可以将第二数据封装为至少一个数据包,通过多条传输路径传输第二数据中的数据包。
在本申请各实施例中,并不限定使用多条传输路径对第一数据或第二数据进行多路径传输的方式,例如,可以是完全冗余传输方式对第一数据或第二数据进行多路径传输,也可以是辅助冗余传输方式对第一数据或第二数据进行多路径传输。其中,完全冗余传输方式是指对待传输的任意数据包,在首次发送该数据包的情况下,同时在两条或两条以上的传输路径上传输该数据包;辅助冗余传输方式是指对待传输的任意数据包,在首次发送该数据包的情况下,选择其中一条传输路径并在选择的传输路径上传输该数据包,并会针对未收到对端的确认信息的数据包进行重传。
在上述对第一数据或第二数据进行多路径传输的过程中,可以采用本申请实施例提供的重注入控制方法利用处于空闲状态的传输路径对处于非空闲状态的传输路径上的数据包进行重传。下面分情况简单说明:
对第一数据进行多路径传输的情况:如图1b所示,客户端设备可以根据其应用的性能要求确定应用对第一数据的预期传输时间,该预期传输时间是指客户端设备上的应用希望第一数据传输到服务端设备所需的时长;通过客户端设备与服务端设备之间的多条传输路径向服务端设备发送第一数据中的数据包;以该预期传输时间为依据,启动重注入操作,即通过处于空闲状态的传输路径向服务端设备重传处于非空闲状态的传输路径上的数据包。
对第二数据进行多路径传输的情况:如图1c所示,客户端设备根据其应用的性能要求确定应用对第二数据的预期传输时间,该预期传输时间是指客户端设备上的应用希望第二数据从服务端设备传输到客户端设备所需的时长;通过客户端设备与服务端设备之间的多条传输路径中的至少一条传输路径向服务端设备发送该预期传输时间。对服务端设备来说,可通过多条传输路径中的至少一条传输路径接收客户端设备发送的其应用对第二数据的预期传输时间;通过服务端设备与客户端设备之间的多条传输路径向客户端设备发送第二数据中的数据包;以该预期传输时间为依据,启动重注入操作,即通过处于空闲状态的传输路径向服务端设备重传处于非空闲状态的传输路径上的数据包。
在本申请实施例中,针对完全冗余传输的重注入控制过程和针对辅助冗余传输的重注入控制过程有所不同,在这里对这两种情况的重注入控制过程简单说明一下。对于完全冗余传输的情况,在通过处于空闲状态的传输路径向对端重传处于非空闲状态的传输路径上的数据包时,在处于空闲状态的传输路径上进行重传的数据包包括:处于非空闲状态的传输路径上的已发送但未收到对端的确认信息的已发送数据包,以及处于非空闲状态的传输路径上尚未发送数据包。对于辅助冗余传输的情况,在通过处于空闲状态的传输路径向对端重传处于非空闲状态的传输路径上的数据包时,在处于空闲状态的传输路径上进行重传的数据包包括:处于非空闲状态的传输路径上的已发送但未收到对端的确认信息的已发送数据包。
关于上述对第一数据或第二数据进行多路径传输时的重注入控制方法的详细描述可参见下述实施例,在下述实施例中,以第二端向第一端请求数据,第一端向第二端传输数据为例展开描述。
图2a为本申请实施例提供的一种多路径传输的重注入控制方法的流程图。该方法应用于第一端,参见图2a,该方法可以包括以下步骤:
201、第一端确定应用请求对应的预期传输时间,该应用请求用于向第一端请求待传输数据;
202、第一端通过与第二端之间的多条传输路径,向第二端发送待传输数据中的数据包;
203、第一端根据预期传输时间,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
在本实施例中,第一端需要向第二端发送待传输数据,根据第一端和第二端所属应用场景的不同,待传输数据也会有所不同,例如包括但不限于:音视频数据、文本数据、图像数据、应用安装包或数据压缩包。
实际应用中,待传输数据是根据第二端发送的应用请求确定并向第二端传输的。在第一端根据第二端的应用请求确定待传输数据的情况下,第二端通过与第一端之间的至少一条传输路径向第一端发送应用请求,应用请求包括待传输数据的标识信息,第一端通过至少一条传输路径接收第二端发送的应用请求,根据该应用请求中包括的待传输数据的标识信息,确定待传输数据,进而通过与第一端之间的多条传输路径向第二端传输待传输数据。
进一步可选的,在一些自适应数据传输场景中,例如自适应视频流传输场景,第一端可以针对待传输数据编码为多个不同码率的版本,例如5Mbps、8Mbps、16Mbps等,不同传输码率的数据对应的应用层的处理效果不同,通常来说,码率越高,应用层的处理效果越好。在自适应视频流场景中,应用层的处理效果是指视频质量、分辨率和/或清晰度,或者也可以通过用户的QoE进行表示。为了更好地优化第二端的应用层的数据处理效果,第二端还可以确定待传输数据的码率,请求第一端返回所需码率的待传输数据。为了便于描述和区分,将第一端请求使用的码率版本称为目标码率。基于此,第一端还可以通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的目标码率。在一可选实施例中,第二端可以将目标码率携带在应用请求中一并发送给第一端,即第一端可以通过至少一条传输路径接收第二端发送的应用请求,该应用请求包括待传输数据的标识信息和目标码率;从多个码率对应的待传输数据中,确定与目标码率对应的待传输数据,这样可向第二端发送目标码率对应的待传输数据。
以自适应视频流为例,自适应视频流包括多个视频块,每个视频块可以编码成多个不同码率的版本,在播放效果方面不同码率对应不同的清晰度和质量。每个视频块被编码成的不同码率,例如5Mbps、8Mbps、16Mbps,对应的分辨率分别为480P、720P和1080P,分辨率越高,视频播放的画面质量(如清晰度)越高。在自适应视频流场景中,第一端为服务端设备,第二端为客户端设备,待传输数据为任一视频块,客户端设备可以运行ABR算法,基于客户端设备上的应用(即播放器)的网络吞吐量,动态选择待传输的视频块的目标码率,由于目标码率与播放器的网络吞吐量适配,所以在提升视频播放质量的同时,有利于减少卡顿时间,提升播放器的QoE。
在上述实施例中,并不限定第二端向第一端发送应用请求所使用的至少一条传输路径。可选地,第二端可以随机从多条传输路径中选择一条传输路径,或者,也可以根据多条传输路径的路径质量参数,从中选择质量较好的一条传输路径,或者,也可以采用多条传输路径对应用请求进行多路径传输,如完全冗余的多路径传输方式,或辅助冗余的多路径传输方式,并在该多路径传输中采用本申请实施例提供的重注入控制方法针对应用请求的传输过程进行重注入操作。
在本实施例中,第一端需要确定应用请求对应的预期传输时间。在第一端是服务端设备,第二端是客户端设备的情况下,可由客户端设备(即第二端)获取应用请求对应的预期传输时间,这里的预期传输时间是指客户端设备(即第二端)希望待传输数据从服务端设备传输到客户端设备所需的时间长度,该时间是从服务端设备开始传输待传输数据的第一个数据包开始算起的。
其中,客户端设备获取应用请求对应的预期传输时间的方式包括:根据应用请求对应的应用(即客户端设备上发出应用请求的应用)的网络吞吐量,确定待传输数据对应的目标码率,根据目标码率确定待传输数据的数据大小;根据待传输数据的数据大小和网络吞吐量,生成应用请求对应的预期传输时间。在该方式中,基于应用的网络吞吐量和待传输数据的目标码率来确定该预期传输时间,充分考虑了应用的性能要求,有利于提升应用的QoE。
进一步,在生成预期传输时间时,可以对网络吞吐量与待传输数据的数据大小进行一定数值计算,得到预期传输时间。可选地,将待传输数据的大小与网络吞吐量的比值作为预期传输时间。假设预期传输时间记为D,待传输数据的大小记为K,应用的网络吞吐量记为T,则D=K/T。或者,也可以将待传输数据的大小乘以一定权重,按照公式D=w*K/T得到预期传输时间,w为权重。其中,在待传输数据为视频块的情况下,可以根据视频块对应的目标码率S预估视频块的大小K,根据公式K=S*L得到视频块的大小,其中,L为视频块的时长。
对于第一端是服务端设备,第二端是客户端设备的情况,第二端需要向第一端发送应用请求对应的预期传输时间。可选地,第二端可以通过多条传输路径中的至少一条传输路径向第一端发送该预期传输时间,相应地,第一端可以通过多条传输路径中的至少一条传输路径接收第二端发送的预期传输时间。在本实施例中,并不限定第二端向第一端发送预期传输时间所使用的至少一条传输路径。可选地,第二端可以随机从多条传输路径中选择一条传输路径,或者,也可以根据多条传输路径的路径质量参数,从中选择质量较好的一条传输路径,或者,也可以采用多条传输路径对预期传输时间进行多路径传输,如完全冗余的多路径传输方式,或辅助冗余的多路径传输方式,并在该多路径传输中采用本申请实施例提供的重注入控制方法针对预期传输时间的传输过程进行重注入操作。
进一步,在第一端是服务端设备,第二端是客户端设备的情况下,本申请实施例并不限定第二端向第一端发送预期传输时间的方式,也不限定第二端向第一端发送预期传输时间与向第一端发送应用请求的先后顺序。例如,可以采用传输层协议已有的QoE帧承载该预期传输时间,通过至少一条传输路径向第二端发送该QoE帧;相应地,第二端接收第一端通过至少一条传输路径发送的QoE帧,从QoE帧中解析出预期传输时间。该QoE帧独立于第二端发送给第一端的应用请求,应用请求是一HTTP请求,具体可视采用的传输层协议而定。或者,可以对应用请求进行拓展,增加新的字段,用来承载该预期传输时间,第一端将预期传输时间携带在应用请求的拓展字段中,通过至少一条传输路径发送给第二端;相应地,第二端接收第一端通过至少一条传输路径发送的应用请求,从应用请求中获取待传输数据的标识信息、目标码率以及预期传输时间。
在本实施例中,对多条传输路径使用的传输层协议不做限制,例如可以是但不限于:QUIC、UDP或TCP等。进一步可选的,为了更好地提升应用层的QoE,多条传输路径使用的传输层协议为QUIC,则多路径传输为MPQUIC。
在本实施例中,待传输数据被封装为至少一个数据包,第一端可以通过与第二端之间的多条传输路径,向第二端发送待传输数据中的数据包。实际应用中,通过多条传输路径向第二端发送待传输数据包中的数据包时,可以采用完全冗余传输方式,也可以采用辅助冗余传输方式。即针对至少一个数据包中任意数据包,第一端通过多条传输路径中的部分传输路径,向第二端发送该数据包,以实现辅助冗余传输,也可以通过多条传输路径中的全部传输路径,向第二端发送该数据包,以实现完全冗余传输。
在本实施例中,第一端根据预期传输时间对待传输数据的多路径传输过程进行重注入控制,即第一端根据预期传输时间,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包,以通过重注入操作提高多路径传输性能。
进一步可选地,第一端根据预期传输时间,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包时,可以获取待传输数据的发送完成时间;根据预期传输时间与发送完成时间,确定重注入执行时间;在重注入执行时间到达时,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
在本实施例中,待传输数据的发送完成时间是指第一端发送完待传输数据包含的最后一个数据包的时间。需要说明的是,发送完成时间并不等于至少一个数据包的传输完成时间。具体地,在第一端向第二端传输完至少一个数据包中的最后一个数据包后,第一端记录最后一个数据包的发送时间,将所记录的时间作为待传输数据的发送完成时间,该发送完成时间可以俗称为最后一个RTT时间。当然,也可以根据其它方式定义本实施例中至少一个数据包的发送完成时间,例如可以在最后一个数据包的发送时间上加上一个预设的浮动时间,作为待传输数据的发送完成时间,对此不做限制。
在本实施例中,第一端根据预期传输时间和待传输数据的发送完成时间,确定重注入执行时间,并在重注入执行时间到达的情况下进行重注入操作。实际应用中,重注入执行时间可能是发送完成时间,也可能晚于发送完成时间。在重注入执行时间到达时,第一端执行重注入操作,因为该预期传输时间是根据应用的性能要求确定的,所以以此确定重注入执行时间,能够满足应用的性能要求,可选地,应用的性能要求可通过能够反映用户体验的一些性能参数来表征;另外,在重注入执行时间晚于发送完成时间的情况下,相比于按照发送完成时间进行重注入操作,相当于延迟了执行重注入操作的时间,能够在满足应用程的性能要求的基础上给多条传输路径上的数据包留出更多的传输时间,使得更多数据包能够在执行重注入操作之前被传输至第二端,进而可以减少执行重注入操作时需要进行重传的数据包的数量,减少冗余数据量,进而节约流量和带宽资源。
进一步可选的,为了更好地进行重注入控制,根据预期传输时间与发送完成时间,确定重注入执行时间时,可以根据预期传输时间和重注入程度调整参数,生成允许重注入时间,重注入程度调整参数为预设值或实时获取;在允许重注入时间晚于发送完成时间的情况下,确定允许重注入时间为重注入执行时间。进一步可选地,在允许重注入时间早于发送完成时间的情况下,确定发送完成时间为重注入执行时间,在该情况下,以发送完成时间为准进行重注入操作,能够优先保证待传输数据的正常发送过程,降低重注入操作对正常数据传输过程的影响。
在本实施例中,重注入程度调整参数用于控制允许重注入的激进程度,通过该重注入程度调整参数可以对允许重注入操作的时间早晚进行一定程度的控制。例如,如果该重注入程度调整参数取值为1,表示在预期传输时间到达时允许重注入操作;如果该重注入程度调整参数取值小于1,表示在预期传输时间之前允许重注入操作(可以理解为提前允许重注入);如果该重注入程度调整参数取值大于1,表示在预期传输时间之后允许重注入操作(可以理解为滞后允许重注入)。在本实施例中,通过重注入程度调整参数,能够根据应用场景或应用需求,在预期传输时间的基础上灵活控制允许重注入的激进程度,做到在预期传输时间之前、之后或在预期传输时间到达时允许重注入,具有更高灵活性。
相对于预期传输时间,无论是提前允许重注入的情况,还是滞后允许重注入的情况,最终确定的重注入执行时间都有可能早于发送完成时间,也有可能晚于发送完成时间,并以两者中相对较晚的时间作为重注入执行时间。在图2b和图2c中,均以提前允许重注入的情况为例,对允许重注入时间、预期传输时间、重注入执行时间和发送完成时间之间的关系进行了示例性说明。如图2b所示,预期传输时间晚于发送完成时间,且在提前允许重注入的情况下,允许重注入时间早于预期传输时间但晚于发送完成时间,则允许重注入时间即为重注入执行时间,这意味着会在允许重注入时间执行重注入操作。如图2c所示,预期传输时间早于发送完成时间,且在提前允许重注入的情况下,允许重注入时间早于预期传输时间且早于发送完成时间,则发送完成时间即为重注入执行时间,这意味着会在发送完成时间执行重注入操作。
进一步可选的,为了更好地进行重注入控制,在实时获取重注入程度调整参数时,可以在确定预期传输时间的情况下,实时获取多条传输路径的网络状态信息和/或应用层使用的数据缓存区的缓存水平;根据网络状态信息和/或数据缓存区的缓存水平,确定重注入程度调整参数。
其中,若基于网络状态信息反映传输路径的传输速度较快,可以将重注入程度调整参数朝着滞后允许重注入的方向调整,即确定重注入程度调整参数大于1,而且重注入程度调整参数的取值越大,越晚允许执行重注入操作,只要能够满足应用层的性能要求即可;若基于网络状态信息反映传输路径的传输速度较慢,可以将重注入程度调整参数朝着提前允许重注入的方向调整,即确定重注入程度调整参数小于1,而且重注入程度调整参数的取值越小,越早允许执行重注入操作,以能够满足应用层的性能要求为主。
其中,数据缓存区的缓存水平反映数据缓存区所缓存的数据量,若所缓存的数据量较少,为了让应用层有足够的数据进行处理,可以将重注入程度调整参数朝着提前允许重注入的方向调整,即确定重注入程度调整参数小于1,而且重注入程度调整参数的取值越小,越早允许执行重注入操作,有利于尽快为应用层传输所需的数据,满足应用程的性能要求。若所缓存的数据量较多,可以将重注入程度调整参数朝着滞后允许重注入的方向调整,确定重注入程度调整参数大于1,而且重注入程度调整参数的取值越大,越晚允许执行重注入操作,只要能够满足应用层的性能要求即可。
实际应用中,可以对预期传输时间和重注入程度调整参数进行诸如相乘、相加等各种类型的数值计算,得到允许重注入时间。进一步可选的,为了更好地进行重注入控制,根据预期传输时间和重注入程度调整参数,生成允许重注入时间时,可以对预期传输时间和重注入程度调整参数进行数值计算,得到中间态时间;根据多条路径的往返时延,确定参考时延;将中间态时间与参考时延的差值,作为允许重注入时间。
假设允许重注入时间记为E,重注入程度调整参数记为β,预期传输时间记为D,参考时延记为R。其中,E=β×D-R。β大于1时,例如为1.2,表示允许滞后执行重注入操作;β小于1时,例如为0.8,表示允许提前执行重注入操作。参考时延R可以根据多条传输路径的往返时延得到,例如可以对多条传输路径的往返时延求均值、加权求和得到,也可以从中选择最大往返时间,或者最小往返时延作为参考时延R。
在本申请各实施例中,第一端执行重注入操作是指第一端通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
具体而言,第一端可以根据多条传输路径的网络状态信息,识别传输路径是处于空闲状态还是处于非空闲状态。将处于空闲状态的传输路径可以称作为空闲路径,处于非空闲状态的传输路径可以称作为非空闲路径,非空闲路径是指传输性能不佳相对比较忙碌的传输路径,其传输性能不佳可能是受限于路径本身的物理性能,也可能是因为发生拥堵,对于发生拥堵的路径可称为拥塞路径。在一可选实施例中,针对每条传输路径,以传输窗口方式进行数据包的传输,每条传输路径具有一定数量的传输窗口,对于具有空闲窗口的传输路径为空闲路径,对于没有空闲窗口的传输路径为非空闲路径。
本申请实施例对在空闲路径和非空闲路径上传输的数据包的数量不做限定。空闲路径可能是因为需要传输的数据包的数量较少,也可能是因为其路径质量较好,所以才会成为空闲路径。相应地,非空闲路径可能是因为需要传输的数据包的数量较多,也可能是因为其路径质量较差,相对比较忙碌,故被称为非空闲路径。
在本实施例中,各条传输路径的网络状态信息例如包括但不限于:空闲窗口的数量。其中,根据各条传输路径是否具有空闲窗口,以及空闲窗口的数量,可以确定多条传输路径中处于空闲状态的空闲路径。关于对空闲路径的定义,本申请实施例不做限定,例如可以将具有空闲窗口的传输路径作为空闲路径,或者也可以将具有空闲窗口且空闲窗口的数量达到第一数量阈值的传输路径作为空闲路径。相应地,关于非空闲路径的定义也不做限定,例如可以将没有空闲窗口的传输路径作为非空闲路径,也可以将没有空闲窗口且具有待传输数据包且待传输数据包的数量大于第二数量阈值的传输路径作为非空闲路径。
进一步,网络状态信息还可以包括路径质量参数。路径质量参数例如包括但不限于:带宽、丢包率、时延、抖动。其中,带宽(又称作吞吐量)是指单位时间内传输的数据量,单位通常是:每秒比特数(bps);带宽反映了网络的传输能力,越大越好。丢包率是指所丢失数据包数量占所发送数据包的比率;丢包率反映了网络可靠性,越小越好。时延是指数据包从发送开始到接收所耗费的时间,单位通常是毫秒(ms);时延反映了网络的速度,越小越好。抖动反映了网络的稳定性,越小越好。在该情况下,关于空闲路径和非空闲路径的定义,还可以与路径质量相结合。例如,可以将具有空闲窗口且路径质量满足一定质量要求的传输路径作为空闲路径;相应地,将不具有空闲窗口且路径质量不满足质量要求的传输路径作为非空闲路径,等等。
其中,根据多条传输路径的网络状态信息,从多条传输路径中确定处于空闲状态的传输路径(即空闲路径)和处于非空闲状态的传输路径(即非空闲路径)。进一步可选地,根据上述对空闲路径的定义,可能识别到1条或多条空闲路径。若空闲路径为1条,则直接将该空闲路径作为目标传输路径;在空闲路径为多条的情况下,根据多条空闲路径的路径质量参数从中选择质量较佳的空闲路径作为目标传输路径;然后,通过目标传输路径向第二端重新发送非空闲路径上的数据包。
实际应用中,在空闲路径为多条的情况下,若路径质量参数有1个,可以根据该路径质量参数选择路径质量满足对应要求(例如大于设定质量阈值)的至少一条空闲路径作为目标传输路径。若路径质量参数有多个,针对每条空闲路径可以将多个路径质量参数进行加权求和,得到每条空闲路径的整体路径质量,从中选择整体路径质量满足对应要求(例如大于设定质量阈值)的至少一条空闲路径作为目标传输路径。除此方式之外,在路径质量参数为多个的情况下,可以对多个路径质量参数进行优先级排序;然后,根据路径质量参数的优先级,从多个空闲路径中选择目标传输路径。在根据路径质量参数的优先级,从多个空闲路径中选择目标传输路径时,带宽的优先级高于丢包率,丢包率的优先级高于时延,则带宽越高,对应的空闲路径的优先级越高;在相同带宽的情况下,丢包率越小的空闲路径的优先级越高;在相同带宽和丢包率的情况下,时延越小的空闲路径的优先级越高。
在非空闲路径为一条的情况,可以通过目标传输路径向第二端重新发送该非空闲路径上的数据包。在非空闲路径为多条的情况下,可以根据多条非空闲路径的路径质量参数从中选择质量较差的非空闲路径,通过目标传输路径向第二端重新发送从中选择的质量较差的非空闲路径上的数据包。
无论是哪种情况,在通过目标传输路径向第二端重新发送非空闲路径上的数据包时,包括:若采用完全冗余传输方式,则可以通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的未收到第二端的确认信息的已发送数据包和未发送数据包;若采用辅助冗余传输方式,则可以通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的未收到第二端的确认信息的已发送数据包。
本申请实施例提供的技术方案,在多路径传输的重注入过程中引入应用请求对应的预期传输时间,以应用请求对应的预期传输时间作为允许执行重注入操作的时间依据,能够在更加合理的时间利用多路径中的空闲路径对非空闲路径上的数据包进行重传(即执行重注入操作)。由于在多路径传输中执行重注入操作,所以能够保证多路径传输的性能,又因为重注入操作的执行是以应用请求对应的预期传输时间为依据的,所以既能保证应用的用户体验,又能在一定程度上减少被执行重注入的数据包,减少多路径传输中的冗余数据量,节约流量资源。
值得注意的是,第一端为服务端设备,第二端为客户端设备的情况,与第一端为客户端设备,第二端为服务端设备的情况,区别在于:在第一端是客户端设备,第二端为服务端设备的情况下,第一端可以主动向第二端发送待传输数据,此时,第一端确定待传输数据对应的预期传输时间,而不是应用请求对应的预期传输时间,待传输数据是指第一端需要向第二端传输的数据,待传输数据对应的预期传输时间是指第一端上的应用希望待传输数据传输到第二端所需的时间,其它操作与前述实施例相同或相似不再逐一展开描述。
为了更好地理解本申请实施例提供的技术方案,以自适应视频流传输场景为例,结合图3对基于多路径传输的自适应视频流场景的重注入过程进行说明。参见图3,按照TCP/IP协议的分层架构,客户端设备自上而下包括应用层和传输层,服务端设备自上而下包括应用层和传输层。客户端设备的应用程中包含播放器,服务端设备的应用层中包含网页服务端(web server),客户端设备的传输层中包含传输客户端,服务端设备的传输层中包含传输服务端;播放器与网页服务端之间采用HTTP协议,传输客户端与传输服务端之间存在多条传输路径,以使客户端设备与服务端设备之间能够基于多路径进行传输,例如,传输路径1为Wi-Fi链路,传输路径2为Cellular链路,传输层协议以使用QUIC为例进行图示。
客户端设备中的播放器播放自适应视频流,所播放的自适应视频流由服务端设备中的web server提供,也即播放器请求web server发送自适应视频流。web server本地缓存自适应视频流,自适应视频流分割成多个视频块,web server对同一视频块缓存多个码率版本,例如对同一视频块同时缓存码率为5Mbps、8Mbps、16Mbps的视频块。
播放器向web server请求视频块以及基于多路径传输视频块并在多路径传输过程中执行重注入操作的过程如下:
S1、客户端设备中的播放器运行ABR算法基于播放器的网络吞吐量从多个码率中确定目标码率,以及根据目标码率生成视频块的大小,根据播放器的网络吞吐量和视频块的大小生成此次请求视频块对应的预期传输时间。
S2、客户端设备中的播放器将预期传输时间提供给客户端设备中的传输客户端,客户端设备中的传输客户端通过传输路径1和/或传输路径2向服务端设备的传输服务端发送包括预期传输时间的QoE帧。在图3中,以通过传输路径1传输预期传输时间为例进行图示。当然,也可以对请求获取视频块的HTTP请求进行拓展,利用HTTP请求中的扩展字段传输预期传输时间。
S3、服务端设备的传输服务端从QoE帧中解析出预期传输时间,以及将预期传输时间传输给服务端设备的web server。
S4、客户端设备中的播放器经传输客户端通过传输路径1和/或传输路径2向服务端设备的传输服务端发送请求获取视频块的HTTP请求,HTTP请求包括视频块标识和目标码率。在图3中,以通过传输路径2传输HTTP请求为例进行图示。
S5、服务端设备的传输服务端将该请求获取视频块的HTTP请求转发给服务端设备的web server。
S6、服务端设备的web server响应HTTP请求,获取视频块标识对应的目标码率下的视频块,将视频块拆分为多个数据包,将视频块的数据包传给服务端设备的传输服务端,由该传输服务端通过传输路径1和传输路径2将多个数据包发送给客户端设备的播放器使用。
S7、服务端设备的传输服务端开始传输视频块中的数据包,并以当前时间作为视频块的起始传输时刻,在多个数据包中的最后一个数据包从服务端设备发出后,将最后一个数据包的发送时间作为视频块的发送完成时间。
S8、在多个数据包的传输过程中,服务端设备的传输服务端会根据预期传输时间和重注入程度调整参数生成允许重注入时间,并会判断允许重注入时间是否在发送完成时间之前到达,若是,则将该发送完成时间作为重注入执行时间,并在发送完最后一个数据包时,开始执行重注入操作;若否,则将允许重注入时间作为重注入执行时间,并在该时间到达时,开始执行重注入操作。
针对基于多路径传输的自适应视频流场景的重注入控制,通过感知播放器的网络吞吐量等性能要求来控制数据传输过程中的重注入行为,使得数据传输过程能够配合播放器共同优化用户的视频观看体验(例如为QoE),在降低冗余数据的同时,提升视频的质量并降低卡顿,从而帮助提升用户观看率和用户留存率。
需要说明的是,上述实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤201至步骤203的执行主体可以为设备A;又比如,步骤201和202的执行主体可以为设备A,步骤203的执行主体可以为设备B;等等。
另外,在上述实施例及附图中的描述的一些流程中,包含了按照特定顺序出现的多个操作,但是应该清楚了解,这些操作可以不按照其在本文中出现的顺序来执行或并行执行,操作的序号如201、202等,仅仅是用于区分开各个不同的操作,序号本身不代表任何的执行顺序。另外,这些流程可以包括更多或更少的操作,并且这些操作可以按顺序执行或并行执行。需要说明的是,本文中的“第一”、“第二”等描述,是用于区分不同的消息、设备、模块等,不代表先后顺序,也不限定“第一”和“第二”是不同的类型。
图4为本申请实施例提供的一种多路径传输的重注入控制装置的结构示意图。该装置可以配置在第一端,第一端与第二端通过多路径进行数据传输。其中,第一端是客户端设备,第二端是服务端设备,或者,第一端是服务端设备,第二端是客户端设备。如图4所示,该装置包括:
确定模块41,用于确定应用请求对应的预期传输时间,该应用请求用于向第一端请求待传输数据;
多路径传输模块42,用于通过与第二端之间的多条传输路径,向第二端发送待传输数据中的数据包;
重注入控制模块43,用于根据预期传输时间,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
进一步可选的,重注入控制模块43具体用于:获取待传输数据的发送完成时间;根据预期传输时间与发送完成时间,确定重注入执行时间;在重注入执行时间到达时,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
进一步可选的,重注入控制模块43根据预期传输时间与发送完成时间,确定重注入执行时间时,具体用于:根据预期传输时间和重注入程度调整参数,生成允许重注入时间,重注入程度调整参数为预设值或实时获取;在允许重注入时间晚于发送完成时间的情况下,确定允许重注入时间为重注入执行时间;在允许重注入时间早于发送完成时间的情况下,确定发送完成时间为重注入执行时间。
进一步可选的,重注入控制模块43实时获取重注入程度调整参数时,具体用于:在确定所述预期传输时间的情况下,实时获取多条传输路径的网络状态信息和/或应用层使用的数据缓存区的缓存水平;根据网络状态信息和/或数据缓存区的缓存水平,确定重注入程度调整参数。
进一步可选的,重注入控制模块43根据预期传输时间和重注入程度调整参数,生成允许重注入时间时,具体用于:对预期传输时间和重注入程度调整参数进行数值计算,以得到中间态时间;根据多条路径的往返时延,确定参考时延;将中间态时间与参考时延的差值,作为允许重注入时间。
进一步可选的,确定模块41具体用于:通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的预期传输时间。其中,第二端获取该预期传输时间的方式为:根据所述应用请求对应的应用的网络吞吐量,确定待传输数据对应的目标码率,根据目标码率确定待传输数据的数据大小;根据网络吞吐量和待传输数据的数据大小,生成应用请求对应的预期传输时间。
进一步可选的,多路径传输模块42通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的预期传输时间时,具体用于:接收第二端通过至少一条传输路径发送的QoE帧,QoE帧中包括预期传输时间;或者从应用请求的拓展字段中获取预期传输时间。
在一可选实施例中,多条传输路径使用的传输层协议为QUIC、UDP或TCP,对此不做限定。
进一步可选的,在通过与第二端之间的多条传输路径,向第二端发送待传输数据中的数据包之前,多路径传输模块42还用于:通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的应用请求,应用请求包括待传输数据的标识信息和目标码率;从多个码率对应的待传输数据中,确定与目标码率对应的待传输数据。
进一步可选的,重注入控制模块43通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包时,具体用于:根据多条传输路径的网络状态信息,从多条传输路径中确定处于空闲状态的传输路径和处于非空闲状态的传输路径,网络状态信息包括空闲窗口的数量和路径质量参数;在处于空闲状态的传输路径为多条的情况下,根据多条处于空闲状态的传输路径的路径质量参数从中选择目标传输路径,通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
进一步可选地,重注入控制模块43通过所述目标传输路径向所述第二端重新发送处于非空闲状态的传输路径上的数据包时,具体用于:在完全冗余传输方式下,通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的未收到第二端的确认信息的已发送数据包和未发送数据包;或者,在辅助冗余传输方式下,通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的未收到第二端的确认信息的已发送数据包。
图4所示的装置可以执行图2a所示的方法,其实现原理和技术效果不再赘述。对于上述实施例中的图4所示的其中各个模块执行操作的具体方式已经在前述实施例中进行了详细描述,此处将不做详细阐述说明。
图5为本申请实施例提供的一种电子设备的结构示意图。如图5所示,该电子设备包括:存储器51和处理器52;
存储器51,用于存储计算机程序,并可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令,消息,图片,视频等。
处理器52,与存储器51耦合,用于执行存储器51中的计算机程序,以用于:确定应用请求对应的预期传输时间,该应用请求用于向第一端请求待传输数据;通过与第二端之间的多条传输路径,向第二端发送待传输数据中的数据包;根据预期传输时间,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
在一可选实施例中,处理器52根据预期传输时间,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包,包括:获取待传输数据的发送完成时间;根据预期传输时间与发送完成时间,确定重注入执行时间;在重注入执行时间到达时,通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
在一可选实施例中,处理器52根据预期传输时间与发送完成时间,确定重注入执行时间,包括:根据预期传输时间和重注入程度调整参数,生成允许重注入时间,重注入程度调整参数为预设值或实时获取;在允许重注入时间晚于发送完成时间的情况下,确定允许重注入时间为重注入执行时间;在允许重注入时间早于发送完成时间的情况下,确定发送完成时间为重注入执行时间。
在一可选实施例中,处理器52实时获取重注入程度调整参数的步骤,包括:在确定预期传输时间的情况下,实时获取多条传输路径的网络状态信息和/或应用层使用的数据缓存区的缓存水平;根据网络状态信息和/或数据缓存区的缓存水平,确定重注入程度调整参数。
在一可选实施例中,处理器52根据预期传输时间和重注入程度调整参数,生成允许重注入时间,包括:对预期传输时间和重注入程度调整参数进行数值计算,以得到中间态时间;根据多条路径的往返时延,确定参考时延;将中间态时间与参考时延的差值,作为允许重注入时间。
在一可选实施例中,处理器52确定应用请求对应的预期传输时间,包括:通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的预期传输时间。其中,第二端获取应用层对对待传输数据的预期传输时间的方式为:根据应用请求对应的应用的网络吞吐量,确定待传输数据对应的目标码率,根据目标码率确定待传输数据的数据大小;根据网络吞吐量和待传输数据的数据大小,生成应用请求对应的预期传输时间。
在一可选实施例中,处理器52在通过与第二端之间的多条传输路径,向第二端发送待传输数据中的至少一个数据包之前,还用于:通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的应用请求,应用请求包括待传输数据的标识信息和目标码率;从多个码率对应的待传输数据中,确定与目标码率对应的待传输数据。
在一可选实施例中,处理器52通过与第二端之间的多条传输路径中的至少一条传输路径,接收第二端发送的预期传输时间,包括:接收第二端通过至少一条传输路径发送的体验质量QoE帧,QoE帧中包括预期传输时间;或者,从应用请求的拓展字段中获取预期传输时间。
在一可选实施例中,多条传输路径可以使用QUIC协议、UDP协议或TCP协议,对此不做限定。
在一可选实施例中,处理器52通过处于空闲状态的传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包,包括:根据多条传输路径的网络状态信息,从多条传输路径中确定处于空闲状态的传输路径和处于非空闲状态的传输路径,网络状态信息包括空闲窗口的数量和路径质量参数;在处于空闲状态的传输路径为多条的情况下,根据多条处于空闲状态的传输路径的路径质量参数从中选择处于空闲状态的目标传输路径;通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的数据包。
进一步可选地,重注入控制模块43通过所述目标传输路径向所述第二端重新发送处于非空闲状态的传输路径上的数据包时,具体用于:在完全冗余传输方式下,通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的未收到第二端的确认信息的已发送数据包和未发送数据包;或者,在辅助冗余传输方式下,通过目标传输路径向第二端重新发送处于非空闲状态的传输路径上的未收到第二端的确认信息的已发送数据包。
进一步,如图5所示,该电子设备还包括:通信组件53、显示器54、电源组件55、音频组件56等其它组件。图5中仅示意性给出部分组件,并不意味着电子设备只包括图5所示组件。另外,图5中虚线框内的组件为可选组件,而非必选组件,具体可视电子设备的产品形态而定。本实施例的电子设备可以实现为台式电脑、笔记本电脑、智能手机或IOT(物联网,Internet of things)设备等终端设备,也可以是常规服务端、云服务端或服务端阵列等服务端设备。若本实施例的电子设备实现为台式电脑、笔记本电脑、智能手机等终端设备,可以包含图5中虚线框内的组件;若本实施例的电子设备实现为常规服务端、云服务端或服务端阵列等服务端设备,则可以不包含图5中虚线框内的组件。
关于处理器执行各动作的详细实施过程可参见前述方法实施例或设备实施例中的相关描述,在此不再赘述。
相应地,本申请实施例还提供一种存储有计算机程序的计算机可读存储介质,当计算机程序被处理器执行时,致使处理器能够实现上述方法实施例中的各步骤。
上述存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(Static Random-AccessMemory,SRAM),电可擦除可编程只读存储器(Electrically Erasable Programmable read only memory,EEPROM),可擦除可编程只读存储器(Erasable Programmable Read Only Memory,EPROM),可编程只读存储器(Programmable read-only memory,PROM),只读存储器(Read-Only Memory,ROM),磁存储器,快闪存储器,磁盘或光盘。
上述通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络,如Wi-Fi(WirelessFidelity,无线保真)、2G(2Generation,2代)、3G(3Generation,3代)、4G(4Generation,4代)/LTE(long Term Evolution,长期演进)、5G(5Generation,5代)等移动通信网络,或它们的组合。在一个示例性实施例中,通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,所述通信组件还包括近场通信(NearField Communication,NFC)模块,以促进短程通信。例如,在NFC模块可基于射频识别(Radio Frequency Identification,RFID)技术,红外数据协会(The Infrared DataAssociation,IrDA)技术,超宽带(Ultra Wide Band,UWB)技术,蓝牙(Bluetooth,BT)技术和其他技术来实现。
上述显示器包括屏幕,其屏幕可以包括液晶显示器(Liquid Crystal Display,LCD)和触摸面板(Touch Panel,TP)。如果屏幕包括触摸面板,屏幕可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与所述触摸或滑动操作相关的持续时间和压力。
上述电源组件,为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统,一个或多个电源,及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
上述音频组件,可被配置为输出和/或输入音频信号。例如,音频组件包括一个麦克风(microphone,MIC),当音频组件所在设备处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中,音频组件还包括一个扬声器,用于输出音频信号。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(Central ProcessingUnit,CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RandomAccess Memory,RAM)和/或非易失性内存等形式,如只读存储器(Read Only Memory,ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变化内存(Phase Change RAM,PRAM)、静态随机存取存储器(Static Random-Access Memory,SRAM)、动态随机存取存储器(DynamicRandom Access Memory,DRAM)、其他类型的随机存取存储器(Random Access Memory,RAM)、只读存储器(Read Only Memory,ROM)、电可擦除可编程只读存储器(Electrically-Erasable Programmable Read-Only Memory,EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(Digital versatile disc,DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。