具体实施方式
图3示出了根据本申请的无线资源管理器的第一实施方式。图3的无线资源管理器整体由参考符号30来表示,并被配置为将基站32的通信资源分配给用户实体,其中一个用户实体以34来代表。用户实体34例如是诸如移动电话、笔记本电脑等的移动终端,但也可为固定式装置。用户实体34能够通过无线信道36经由其天线(antenna)或天线装置(antennas)(未示出)来与基站32通信。基站32适当地管理通信数据(即,下行链路和上行链路数据)在通信信道36上的多路复用,并且还可具有一个或多个天线装置(未示出)。特别地,基站32将用于各个用户实体34的下行链路数据适当地多路复用到由基站32输出的发送信号上。为此,可使用不同的多路复用方案。例如,基站32可使用OFDM,并且特别地,可使用LTE。在任何情况下,基站32能以时变方式将通信信道的通信资源分布或分配给包括用户实体34的用户实体,从而使基站32的通信资源到用户实体的分配(还被称为调度)适应当前资源状况。例如,基站32可依靠以下参数的任何组合来执行调度:
1)由基站32服务的用户实体34的数量,即,在基站32进行了注册的用户实体34的数量,即,将被分配基站的通信资源的用户实体34的数量。
2)与单个用户实体交换的通信数据的类型,例如,通信数据的类型从HTTP请求的数据等中区分实时(低延迟)的媒体数据(诸如,语音信号)。
3)分配给被服务的用户实体的用户配置文件,配置文件被分配有例如用于下行链路和/或上行链路的不同的最大比特率和/或最小比特率或者定义用户实体之间的优先级,其中,RRM30在分配通信资源时偏向(favor)具有较高优先级的用户实体而不是具有较低优先级的用户实体。
4)来自用户实体的信道质量反馈,其指示用户实体的当前接收质量状况,即,一方面的基站32与另一方面的单个被服务的用户实体34之间的信道质量,其中,基站32通过例如来自用户实体的相应信道反馈信号来测量信道质量。
5)来自用户实体的信道速率请求,其指示用户实体希望分配进一步的带宽。
在一个以上的基站32和38可服务一个用户实体的情况下,数量涉及由所有当前服务的基站或至少当前可被用于服务某些区域的用户实体的基站所服务的用户实体的数量。当确定通信资源的分配时,还可考虑这些基站之间的交互。在这种情况下,诸如由RRM30聚合的子载波(subcarrier)的信息或由RRM30得出的关于用户实体34的信息(诸如,小区之间的移交)可进一步在基站32与38之间共享,并由较高等级的RRM30收集和使用。
基站32可具有不同的选项/参数,以不同地将通信资源分配给用户实体。这对于下行和上行通信均是如此。例如,基站32可通过以下设置的任何组合来执行调度:
1)子载波与被服务用户实体的关联,例如,OFDM子载波。一般来说,在LTE使用的子载波的最大数量为20MHz带宽。自然地,这可被修改。对于LTE的后继方案(称为先进的LTE),正在讨论使用20MHz至100MHz的多载波。这称为载波聚合。也就是说,子载波也可为聚合子载波。
2)时隙与被服务用户实体的关联或到被服务用户实体的分配。
3)其中用户实体必须能够与基站32通信的基站小区的空间覆盖范围,该空间覆盖范围通过使用例如MIMO技术来更改。
4)单个子载波与调制星座的关联
在不通过任何刚刚提到的设置选项来实施调度的情况下,基站32可不使用相应的传输特征,而是改为使用固定设置。例如,基站32在下行链路内可不使用时分多路复用和/或在上行链路内无时分多路复用,或者相应的时分多路复用可随着时间是固定。这关于涉及子载波的分配的频分多路复用的MIMO功能同样适用。
在任何情况下,根据所分配的通信资源,每个用户实体34体验用于下行链路和上行链路的有效传输带宽。
还应注意的是,图3的无线资源管理器30可包括在基站32中、作为基站32的一部分或容纳在基站32中。然而,无线资源管理器30还可被布置地与基站32物理地分离。特别地,无线资源管理器30甚至可以不特别与特定基站关联。无线资源管理器30可对一个以上的基站的小区内的较高数量的用户实体进行无线资源管理。例如,图3示出了一个进一步可选的基站38,其通信资源可选地也可由无线资源管理器30来控制。特别地,基站32和38可与无线资源管理器30一起形成允许用户实体同时由一个以上基站的服务的无线网络。即,当前存在于两个基站小区的重叠区域内的用户实体可具有由无线资源管理器30分配给它的两个基站的通信资源。因此,这种情况下,用户实体34的有效可用通信带宽可为由服务基站32和38的每一个提供或分配给它的有效带宽的总和。自然地,可增加服务基站的数量。
在任何情况下,目前为止所描述的涉及无线资源管理器30的功能的问题是运行于在其中一个用户实体(例如,用户实体34)上的客户端40试图从服务器42获取具有尽可能高的信息内容等级的版本的媒体内容。客户端可例如是运行在用户实体的操作系统上的应用程序,诸如,浏览器、VoIP(IP语音)应用程序等,但也存在其它可能。反过来,服务器可为运行在主机(诸如,计算机)、另一个移动用户实体、工作站或网络上的程序,诸如VoIP应用程序或媒体内容服务器。
例如,想象用户实体34的客户端40试图从服务器42下载媒体内容44,并且该媒体内容44在服务器42上具有不同的版本可用,不同的版本由媒体呈现描述46来描述,媒体呈现描述46也可由客户端40从服务器42下载。不同版本的媒体内容44可在以下参数的任何子组的任何组合方面不同:
1)空间分辨率
2)时间分辨率
3)视图数量(number of views)
4)位深度
5)信噪比
6)音频信道的数量。
即,媒体内容44可为视频。数据流量(经由其客户端40从服务器42获得媒体内容44)至少可通过无线资源管理器30来测量(survey,调查),如虚线48所示,虚线48示出了服务器42与客户端40之间的数据流量分别经过基站32或者基站32和38,其中,数据流量的内容可由无线资源管理器30进行检查,如箭头50所示。可替代地,数据流量甚至可经过无线资源管理器30,如虚线箭头52所示,从而根据该替代方案,无线资源管理器30不仅能够检查还能拦截或以其它方式影响在客户端40与服务器42之间的数据流量的一部分。
数据流量可使用任何适当的协议,诸如,HTTP。底层传输协议可为TCP或UDP。
然而,尽管对实施例的描述集中在HTTP流媒体上,但数据传输本身也可以不同方式来实施,诸如经由RTP[IETF RFC3550]。因此,由SDP[IETF RFC4566](会话描述协议)文件提给出对会话中的媒体的描述。从本申请的意义上说,这种SDP文件被视为“MPD”,并且允许从其选择不同媒体特征(诸如,不同的编码参数)的描述。
由于媒体内容44的各个版本传达关于媒体内容44的不同信息量,允许按照为了在客户端40无中断地播放各个版本所需的必要最小要求传输带宽将这些版本划分等级。
通常,客户端40被配置为向用户提供具有关于媒体内容44的最高可能的信息的版本。最高可能的版本可被定义为仍然可通过由用户实体34上可用的设备(诸如,通过用户实体34上可用的显示器和扬声器,或通过媒体播放器、解码器等)呈现给用户的版本。更确切地说,尽管未在图3中示出,用户实体34可包括用于显示媒体内容44的帧顺序的显示器和用于再现伴随帧顺序的可选音频信号的一个或多个扬声器。在后面的情况下,客户端40可尝试给用户提供仍可由例如由户实体34的显示器再现的具有最高空间分辨率的版本的媒体内容44。
最后,客户端40例如通过HTTP请求向服务器42请求所需版本的媒体内容44。为了使客户端40能够决定要提供给用户的版本,在从服务器42到客户端40的数据流量内为客户端40提供媒体呈现描述46。例如,客户端40从服务器42请求媒体内容44的媒体呈现描述46,服务器42反过来通过向客户端40发送媒体呈现描述46而做出响应。如上所述,媒体呈现描述46向客户端40指示在服务器42上的媒体内容44的可用版本以及这些版本所需的最低要求传输带宽。由此,客户端40评估由无线资源管理器30提供或分配给用户实体34的当前可用的有效带宽,并且通常选择具有最高等级的版本,并相应地要求仍然低于或等于由视频无线资源管理器30提供的有效带宽的最高最低要求传输带宽。
但是,如在本申请的说明书的介绍部分所描述的,由于运行在用户实体上的所有客户端40试图为用户提供相应媒体内容的最大带宽版本,因此施加在基站32的通信资源上的压力(strain)很高,尽管如果客户端40将降低其请求的版本等级,该压力将不必这么高。
由此,根据图3的实施方式,无线资源管理器30被配置为根据从相应服务器42到运行在相应用户实体34上的相应客户端40的数据流量内的媒体呈现描述46,将基站32的通信资源分配给包括用户实体34的用户实体。从以下说明可清楚地看出,由RRM利用所述的对MPD46的依赖性分配的通信资源可尤其关于(pertain,属于)代表全部通信资源的主要部分的上行链路和/或下行链路通信资源,而全部通信资源反过来还可包括控制信令,诸如,TCP的确认反馈循环或上文所述的质量反馈。
更确切地说,无线资源管理器30被配置为检查描述从服务器42到客户端40的数据流量内的视频内容44具有不同带宽的版本,并在将基站32的通信资源分配给用户实体34所属的用户实体时,将由媒体呈现描述提供的信息与其他输入参数一起考虑在内。
例如,如果由于要服务的用户实体34的数量较高而使当前施加在基站32的通信资源上的压力较高,则无线资源管理器30可决定由客户端40当前从服务器42请求的媒体内容44的版本对客户端40当前不可用,并相应地减少分配给用户实体34的通信资源的量,从而有效地降低提供给用户实体34的有效带宽。换句话说,无线资源管理器30在高压力情况下可决定客户端40应至少在高压力施加在基站32的通信资源上的期间临时将媒体内容44的较高等级版本切换为其较低等级版本。当然,RRM30可预先检查这种低带宽版本是否存在。自然地,客户端还可出于某些原因(例如,为了优化由小区中的客户端观看的视频质量)获得具有较高带宽的版本,以获得最低可接受的视频质量或信息量。换句话说,RRM30不一定仅仅为了优化小区吞吐量来将通信资源分配给客户端。RRM30还可将小区中的所有客户端的视频质量作为考虑因素。换句话说,当然,存在客户端总是申请最大质量的情况。这种客户端的实例是在下文示例性描述的处于自动切换模式的客户端。
从另一方面说,无线资源管理器30可被配置为:如果被分配通信资源的一个以上的用户实体34的客户端40当前正在经由至少一个基站32下载相应的媒体内容44,则根据来自相应的服务器和客户端对中的相应数据流量内的相应媒体呈现描述46,执行通信资源到一个以上的用户实体34的分配,从而优化成本函数,成本函数至少取决于客户端的每个媒体内容44的版本的质量测量和最小带宽。更确切地说,被优化的成本函数可在总带宽与对客户端的每个媒体内容33的版本确定的总质量测量之间形成折衷。该优化导致客户端获得用于相比最初申请的分配给客户端的媒体内的较低质量版本的带宽,以及导致客户端获得用于相比最初申请的分配给客户端的媒体内容的较高质量版本的带宽。用于单个媒体内容的版本的“质量测量”不需要被区间标度。由qualityRanking提供的顺序尺度(ordinal scale)是足够的。即,顺序尺度可仅与单个媒体内容相关。在所有客户端40的所有媒体内容中,顺序性不需要有效。但是,可在优化成本函数中包括额外信息,诸如,相应媒体内容的编码复杂性的测量,即,媒体内容的平均速率/失真测量。这种编码复杂性测量可以非常粗糙。例如,下文所述的contentCharacteristic就属于这种特征。所有这种信息可包括在由相应客户端请求的相应媒体内容的媒体呈现描述46中。
另外,无线资源管理器30可记录由客户端40请求的媒体内容44的版本的历史记录,以在施加在基站30的通信资源上的压力再次降低的期间,利用历史记录来重新给相应客户端40分配更高量的通信资源。
反过来,客户端40通过评估由无线资源管理器30提供的当前有效带宽将认识到在RRM30决定减少分配的通信资源量的情况下将媒体内容44的当前请求和下载的版本仅利用中断呈现给用户。换句话说,客户端40将认识到给用户再现媒体内容44的媒体播放器的媒体缓冲区由于经由无线通信路径36的可用传输带宽的降低而变空。当客户端40按照其所希望的或客户端所希望的自由地对这种情况做出响应时,客户端40的一个合理选择是向服务器42发送请求媒体内容44的较低等级版本(即,与媒体内容44的当前下载版本相比,与较低的必须最小传输带宽相关的版本)的请求。
总而言之,根据图3的实施方式,除了根据如上所述的可用资源、由用户实体反馈指示的信道质量、来自向关联用户实体的资源请求的数量、用户实体之间的优先级等之外,无线资源管理器30还根据在相应的服务器和运行在相应用户实体的客户端对之间传输的数据流量内的媒体呈现描述46来执行调度。
关于图3的实施方式,应注意,客户端30可例如表示运行在用户实体处理器上的软件。可替代地,客户端可实施为硬件或可编程的硬件。
因此,图3显示了被配置为根据从服务器42到运行于其中一个用户实体32上的客户端40的数据流量内的媒体呈现描述46来将基站32的通信资源分配给用户实体34的无线资源管理器。
在下文中,将对图3的实施方式的可能的实施进行说明。根据该可能的实施,客户端30使用经由HTTP的视频流以从服务器42获取媒体内容44。特别地,用于经由HTTP的视频流的底层传输协议可为TCP[RFC793]。
实际上,此处指出的含义对共享在下文中所述的特性的每个协议都有效。此处考虑的协议为具有拥塞控制机制的基于ACK(确认)/NACK(否定确认)或诸如用于TCP的SACK(选择性确认)的任何其它类型的确认的接收的面向连接的协议。可能地,这些协议可额外地使用重传机制以处理与拥塞控制机制的吞吐量自适应结果并行的丢包。这种协议的实例将是当用于经由HTTP的视频流的底层传输协议是TCP[RFC793]时。TCP例如使用确认消息(ACK)和流量控制机制(例如,通过慢启动、拥塞避免、快速重传和快速恢复的拥塞控制)为流数据传输提供增强特征以提供可靠性。流量控制指示发送器在内部缓冲区没有溢流的情况下可接收多少字节。相关媒体和状态速率在图4和表1中示出。如图4所示,丢包对所接收的TCP吞吐量产生影响,并且预计具有上述特征的任何其它协议也存在同样的问题。另外,以下方程示出了基于丢包(p)、往返时间(RTT)和最大传输单位(MTU)的对TCP吞吐量的精确估算结果[18]。因此,在传输中跟踪网络层丢包是一种非常有效的技术,以允许无线资源管理器适当地分配基站32的通信资源。因此,32可从PHY层信息(诸如,丢失的无线帧/MAC层分组数据单元和高层MTU尺寸以及在30的MAC缓冲器100上的TCP丢包(参见图13))得出在较高网络层(诸如例如用于TCP的传输层)上的实际丢包率。
表1可用时间和速率
参照图3,例如,无线资源管理器30可以不同方式检查客户端40当前正在下载MPD46中的哪个版本的媒体内容。例如,RRM30可通过检查从客户端40到服务器42的媒体请求来确定客户端44当前经由基站32下载的媒体内容44的版本。但是,RRM30确定客户端的接收媒体吞吐量的吞吐量量度并根据确定的吞吐量量度预测客户端44当前通过至少一个基站32下载了媒体呈现描述46中媒体内容44的哪个版本时,可通过较少的跟踪操作在RRM30上进行较简单处理。作为吞吐量测量,可使用其自身的分配带宽。可替代地,RRM30可尝试通过评估从相应用户实体34发送给基站32的质量反馈来估计相应客户端40的实际接收媒体内容的带宽相对于相应用户实体上的原始分配带宽的偏差/下降量,如上文所述。可替代地,用户实体的附加功能可告知RRM30实际接收的媒体内容吞吐速率。
尽管以上描述假设无线资源管理器测量从服务器42到客户端40的数据流量,以获得媒体呈现描述46,但这整体可替代地转移到用户实体,例如,用户实体内的在用户实体的收发级与客户端之间的某些实体(例如,参见图7)。即,可假设该监测可通过用户实体内的监测级来进行。监测级可将MPD30转发回RRM30,或至少将其一个子部分(诸如摘录)或从MPD的一个子部分中得出的参数组转发回RRM30,其中,摘录或参数组反过来可足以描述在服务器32上可用的媒体内容及其版本。因此,用户实体34可被配置为与无线资源基站32通信并且可具有运行在其上的客户端40,如上文所述,其中,然而,用户实体34可被额外地配置为测量从服务器42到客户端40的数据流量,以从数据流量中得出媒体呈现描述46,并将媒体呈现描述至少部分地转发给无线资源管理器30。稍后,将示出用户实体可具有运行在其上的代替客户端40的服务器,但是,RM仍然起着相同作用,即,通过测量从该服务器到用户实体之外的任何客户端的数据流量来得出MPD。
另外,在下文所述的图3的实施中,客户端40和服务器42可使用DASH以将媒体内容44从服务器42传输给客户端40。DASH为媒体呈现描述定义特定的结构或句法。根据DASH,MPD使用标签来规定用于建立DASH客户端与DASH HTTP服务器之间的逻辑信道所需的参数。标签可为可选的,用字母O标记,或为强制的,用字母M标记。
为了实施图3的实施方式,可使用从MPEG DASH标准(ISO/IEC23009-1[3])获得的MPD标签的组合。
特别地,可考虑使用依赖于minBufferTime标签的强制性bandwidth标签,并且因此其是准强制性的。
MPD可构成的标签包括:
表2MPD标签
即,对于每个可用版本(表示),图3的MPD46可具有参数bandwidth、minBufferTime和可选的qualityRanking。
从上面看出,MPD46甚至可在每个版本中仅包括这些参数的前两个,即,bandwidth和minBufferTim。
MPD的示例如以下列表1中示出。该实例可与例如由配置文件属性识别的DASH标准[3]的特定配置文件对应。媒体呈现时间被规定为3256秒,最小缓冲时间为1.2秒。给出两个表示的片段的URL(同一资源定位符),其中一个表示要求64KB或32KB带宽,并且其中通过将包括在每个表示的相应SegmentList单元中的两个替代的BaseURL和SegmentURL级联来创建片段的URL。片段的持续时间由SegmentList单元中的持续时间属性来给出。
列表1用于具有两种不同表示的视频片段的媒体分组(packet)描述(MPD)的实例
此外,在下面详细描述的图3的实施方式的实施可嵌入LTE系统中。即,基站32或者基站32和38以及无线资源管理器30可作为LTE系统的一部分。
已经对LTE提出了不同的改进。对于具有2x2/4x4MIMO的LTE Rel.8,移动至与多入多出(MIMO)增强的结合的正交频分多址接入(OFDMA)以及从电路交换网络到分组交换网络的转移导致了达到150/300Mbps的峰值吞吐量的移动网络。LTE的一个重大成就是实现了具有在控制平面的低于50ms的延迟和用户平面的上的低于5ms的延迟的ITU-R[15]延迟要求,这对于低的端到端延迟来说是重要的。
LTE实施快速重传机制:在物理层(PHY)和媒体访问控制(MAC)层采用自动重复请求(ARQ)和混合ARQ(HARQ)机制,这要求在接收器上的快速重新排序。因此,导致实时TCP业务的性能退化的重排序缓冲可能造成额外的跳动和延迟,特别是如果未识别HTTP/TCP视频业务并且运行过多(over-the-top)作为尽力服务。在[12]中评估了LTE的移交期间的TCP性能,并且显示需要采用专门的数据包转发技术和数据包重新排序以达到高TCP性能。
另外,LTE在基站(演进节点B(eNB))中引入了分散调度和多用户无线资源管理(RRM)。分散式方法要求设计具有QoS支持的新的突发跨层调度算法,以实现用于不同流量业务的端到端QoS,诸如,HTTP/TCP直播(live steaming)。
RRM实体(即,30)负责无线资源管理,该无线资源管理包括:在短期时间帧内为UE(即,34)分配资源(其也被称为调度);以及在较长时间帧内进行的长期资源分配(其依赖于不同的参数,例如,UE反馈、用户服务需求等)。从基于MIMO OFDMA的LTE中使用的时间-频率-空间网格中获取要分配的资源。资源量取决于使用的LTE参数带宽、FDD或TDD模式以及MIMO模式。
当实施其中使用DASH来传输媒体内容并将无线资源管理器30嵌入LTE系统中的图3的实施方式时,其结果可在图5中示出。为了便于理解图5的实施方式如何实施图3所示的元件(element)的功能,图5中重新使用了图3的参考符号,并且上面参照图3对这些元件进行的说明和描述应同样适用于图5。这也意味着,RRM30不需要物理地包括在基站32之内。另一方面,无论何时图3中缺少对应的参考符号时,图5中重新使用图2的某些参考符号。因此,客户端40被示出为可通信地连接至服务器42,因此,只要涉及基站32之外的数据流量部分,数据流量就会经过HDTP高速缓存16,诸如因特网。另外,示出了DASH内容准备级14,媒体呈现描述46的内容可最初可来源于此。
在描述图5的实施示例的操作模式时,也可将其称为使用在LTE上的DASH的无线资源管理。可使用VC作为媒体内容的版本的可能表示。由于图5的实施遵循图3的实施方式,图5的RRM30的功能实现了无源(passive,被动)信令,以更有效地将无线资源分配给客户端。
特别地,DASH客户端40向服务器42发出视频片段的HTTP请求。RRM单元30采用深度数据包(deep packet)检查50来检查由特定用户或客户端40请求的MPD46。根据在MPD46内定义的bandwidth和minBufferTime标签,调度程序和长期RRM30为给定的minBufferTime实现所请求的带宽。然而,如果LTE的PHY数据管道不支持所请求的带宽,则RRM30自动地尝试确保为MPD46或‘sidx’框和MPD内的媒体内容的AVC视频片段规定的下一个较低带宽。DASH客户端40根据LTE的RRM30的数据速率限制,通过例如向MPD46中列出的具有较低速率要求的服务发送HTTP获得52来调整其HTTP获得请求52。
这确保:
1.确保HTTP视频流的服务递送。
2.防止向尝试获得尽可能多的资源的特定用户过度地供应资源。
3.因此,2允许为LTE小区内的其它用户节省给定时间-频率-空间网格的资源。这减少了IP吞吐量的变化,并因此允许至多个用户的各种流量混合的平稳服务递送。
4.TCP将最佳地适应由LTE系统分配的数据速率。
由于蜂窝系统中的无线资源在附接至相同eNB的所有用户之间共享,分配给一个用户的资源量会影响对其它用户可用的资源量。因此,即使一个用户拥有非常好的信道条件,RRM30也可选择减少用于该用户的资源量,以利于支持其它用户。考虑比特率和内容特征(内容的类型,例如,电影、新闻、体育)或qualityRanking,能够对小区中的所有用户执行整体视频质量优化。
RRM30可按由客户端40请求的数据块的顺序识别技巧模式(例如,快进(fast forward)、快退(fast rewind)、跳过(jump))的使用。使用技巧模式之后,客户端必须通过DPI对minBufferTime/新缓冲检测执行新的再缓冲。DPI表示深度数据包检查。这意味着基站调度程序查看IP数据包中的内容并基于其检查结果来形成其决定。传统上,RRM在MAC层上运行并且不会查看由ISO-OSI模型中提出的IP层。
关于刚刚通过参照图5描述的细节来描述的图3的实施方式的实施,应注意,图5将图3的实施方式具体化的各个方面可单独转移到图3中。这例如适用于以下情况:用于数据流量的TCP协议的使用,用于定义管理器30、基站32和用户实体34的相应功能的LTE系统的使用,以及定义MPD46的至少部分内容与服务器42和客户端40的功能的DASH流媒体架构的使用。
根据图3至图5的实施方式,视频资源管理器30基于对从服务器42到客户端40的数据流量内的媒体呈现描述的评估来直接命令分别到单个用户实体及其客户端40的速率分配,如图5中的“R”所示,并相应地将基站32的通信资源分配给用户实体。根据下述实施方式,资源管理器30的这个功能为可选的。
图6示出了根据本发明的进一步的实施方式的无线资源管理器。如上所述,关于图3和图6中共同示出的元件的功能和互连,上文参照图3进行的描述保持不变。即,无线资源管理器30以上文所述的方式将基站32的通信资源分配给用户实体34,除了该分配对媒体呈现描述46的依赖是可选的。此外,根据图6的实施方式,无线资源管理器30被布置为使得客户端40与服务器42之间的数据流量经过无线资源管理器30,从而使无线资源管理器30能够如下文所述地影响该数据流量。
特别地,根据图6的实施方式,无线资源管理器30还(即,除上文参照图3描述的功能之外)被配置为检查从服务器42到运行在用户实体34上的客户端40的数据流量内的描述媒体内容44的不同带宽的版本的媒体呈现描述46以及从客户端40到服务器42的媒体请求60,媒体请求60请求所需版本的媒体内容44。基于这两个检查,资源管理器30根据描述至少关于发送请求60的用户实体34的当前资源状况的信息和发给用户实体34的媒体呈现描述决定:1)将媒体请求60转发给服务器42(未修改的),或者,可替代地,2)使媒体请求60不产生(lead to,导向)发送给客户端40的媒体内容44的所需版本。例如,资源管理器30可经由2a)将媒体请求60修改到使所修改的媒体请求请求较低带宽的媒体内容44的程度或者2b)拦截媒体请求44并进行模拟或指示服务器42从服务器42向用户实体34或客户端40发回不可用的响应来使媒体请求60不产生发送给客户端40的所需版本的媒体内容44。可替代地,对较低带宽的响应可通过RRM30来执行,或者可使任何其他反馈通过服务器来执行以指示客户端相应地改变其请求。
这意味着:如上文参照图3所述的,无线资源管理器30可具有对当前资源状况信息的访问权。特别地,无线资源管理器30不仅具有对关于用户实体34的该当前资源状况信息的访问权,而且具有有用户实体的当前资源状况信息的访问权。基于该信息,无线资源管理器30获知当前施加在基站32的通信资源上的压力,并且获知对于用户实体34可用的通信资源。此外,无线资源管理器30具有对媒体呈现描述46的访问权并对其进行检查,由此无线资源管理器30获知用户实体34上的客户端40试图下载的媒体内容44的替代版本。
基于全部信息(即,当前资源状况信息和媒体呈现描述46),无线资源管理器30能够确定基站32当前承受的负载是否足够低,以判断仅将媒体请求60以不经修改的版本转发给服务器42是否合适。然而,如果无线资源管理器30从当前资源状况信息和媒体呈现描述,确定不应从其它用户实体传输媒体内容44的当前请求版本所需的部分带宽(例如因为剩余带宽不足以为所有其它用户实体的客户端提供它们所请求的媒体内容的最低带宽版本),则无线资源管理器30决定将媒体请求60修改到所修改的媒体请求请求较低带宽版本的程度。因此,服务器42通过向客户端40发送较低带宽版本来对该修改请求做出答复,客户端40能够处理对其请求的答复实际上是对较低带宽版本的请求的答复的情况。例如,较低带宽版本与原始所需的媒体内容44的版本的不同之处仅在于省略了特定媒体流部分,特定媒体流部分的省略不会干扰在负责再现媒体内容的用户实体34上的媒体解码器。即,较低带宽版本可以是可升级的(scalable)媒体内容的较低信息等级,或者较低带宽版本为另一媒体文件(然而其利用相同的编码方案来编码)。
替代修改媒体请求60,服务器42还可拦截媒体请求44并进行模拟或者通知服务器从服务器42向客户端40发回不可用的响应。在这两种情况下,客户端40将接收到来自服务器42的答复,根据该答复,所需版本在服务器上是不可用的,即使在媒体呈现描述46中指示了。尽管客户端40可以任何方式自由地对该答复做出反应,但一个合理的反应方式将涉及(involve)客户端40向服务器42重新发送具有新请求的另一个请求,然而,从服务器42请求媒体内容44的较低带宽版本,从而有效地产生与上述媒体请求的修改产生的状况相同的状况,即,服务器42向客户端40发回较低带宽版本。
因此,在上面确定的三种决定选项1)至2b)中,在无线资源管理器的决定中涉及的第一步可为:检查是否存在可用的媒体内容44的任何较低带宽版本。基于媒体呈现描述46来执行该检查。第二步可涉及检查当前资源状况信息以确定选项2a)或2b)中的任何一个是否合理。
下面参照图7对图6的实施方式的进一步扩展或概括进行描述。图7更详细地示出了用户实体34的实施方式。根据下面参照图7所述的实施方式,关于媒体请求60的处理(即,转发、修改和/或拦截)的附加无线资源管理器功能从无线资源管理器30沿着服务器42与客户端40之间的数据流量转移到用户实体域34中,并且特别地,转移到用户实体传输级70与客户端40之间的某处。然而,应理解,这仅仅为实例,并且该功能也可由位于别处的另一个实体承担。
特别地,图7将用户实体34示出为包括一个或多个天线72、收发级70、资源管理器74、客户端40、媒体再现器76和实际上用于将媒体呈现给用户的硬件(包括,例如,显示器78和一个或多个扬声器80)。所有这些元件按它们提及的顺序彼此串联连接。发送级70负责执行与基站32的通信,从而各个数据路径对后续或更高层应用(诸如由客户端40表示的那些)是透明的。收发级70执行例如(解)多路复用(诸如OFDM(解)多路复用的、时分(解)多路复用)、对基站32的接收质量反馈、信道评估等。另外,收发级70能够向基站32发送请求增加分配给相应用户实体34的带宽的请求,这些请求的发送例如由任何后续模块(诸如客户端40)来触发。收发级70可实施为硬件或者硬件、可编程硬件和/或软件的组合或者其任何组合。
资源管理器74连接在收发级70与客户端40之间,因此能够对从客户端40经由分别由收发级70和天线72表示的无线接口到服务器42的媒体请求执行上述无线资源管理器的关于修改、转发和/或拦截的功能。即,资源管理器74可经由收发级70具有对当前资源状况信息的访问权。特别地,收发级70告知资源管理器74由于无线资源管理器30当前对用户实体的通信资源分配(见图6)而产生的当前可用传输速率。此外,资源管理器74能够检查从服务器42到客户端40的数据流量内的媒体呈现描述46。通过检查从客户端40到服务器42的媒体请求60,因此资源管理器74能够执行上面参照图6描述的相同决定,即,在上面讨论的转发媒体请求、或可替代地修改媒体请求、或拦截媒体请求并进行模拟或通知服务器42发回不可用的响应的决定选项中的决定。自然地,与资源管理器30相比,资源管理器74仅具有对当前资源状况信息的合适子组的访问权。然而,当全面地考虑在基站32上的资源状况时,资源管理器74可避免客户端40请求相对对其它用户的服务器基站32不公平或者可能无法由客户端40频繁传输的媒体内容44的版本。
关于图6和图7的实施方式,应注意,资源管理器30和74可分别被配置为仅在选项1)与2)或者1)与3)之间切换。另外,关于资源管理器74,应注意,其可被配置为利用由无线资源管理器30发送给用户实体34的长期通信资源保证作为当前资源状况信息的一部分。
因此,图6和图7展示了被配置为如下的资源管理器:检查在从服务器42到运行在用户实体34上的客户端40的数据流量内的描述不同带宽的媒体内容44的版本的媒体呈现描述46;检查从客户端40到服务器42请求所需版本的媒体内容44的媒体请求60;以及根据当前资源状况信息和媒体呈现描述46,决定(1)将媒体请求60转发给服务器,或者可替代地,(2)将媒体请求60修改到使所修改的媒体请求请求较低带宽的媒体内容44的程度,或者拦截媒体请求60并进行模拟或通知服务器42从服务器42向客户端40发回不可用的响应。
类似于上面参照图3至图5描述的实施方式,在下文中,描述图6和图7的实施方式的可能的实施。即,这些可能的实施假定无线通信系统为LTE系统,媒体内容的流媒体(streaming)使用DASH。与图5和图3的关系相同的方式,图8再次使用之前使用的参考符号,并且因此图6和图7中的元件的功能的描述应同样适用于图8中示出的具有相同参考符号的元件。
结合DASH,LTE RRM30可检查由所有附接的UE34请求的MPD46。如果给定的UE具有良好的无线信道并发起高带宽请求60,则LTERRM30可发送状态代码触发(trigger),即,状态代码注入(injection),从而HTTP DASH服务器42发送W3C HTTP状态代码80,以指示该带宽不可用。可能的W3C HTTP状态代码在下面列出。因此,LTE RRM30可强制UE34请求较低数据速率,而不需要直接给UE34发信令。这节省了用于信令的资源,该资源可替代地用于数据,例如,这些资源可被调度给其它Ue34。UE的TCP/IP服务通过eNB RRM算法自动地适应所分配的速率,该速率可从MPDbandwidth标签获得。
eNB RRM单元30检查由UE34请求的MPD46。另外,它可从移动性管理实体(MME)(图8中未示出)中获得信息。根据用户配置文件,例如,移动速度、移交统计和所请求的MPD,RRM实体30可通过经由W3C HTTP状态代码的间接信令80强制分配较高或较低的视频质量(参见,例如,http://www.w3.org/Protocols/rfc2616/rfc2616-seclQ.html)
在上面对图8的描述中,假定服务器42上可用的媒体内容44的版本可单独地得到(即,在非升级版本中),然而它们包括不同的信息内容。然而,上面对图8的描述可容易转移到以下情况:媒体内容44的可用的不同带宽版本可以一个媒体流的形式得到,然而,这个媒体流以可升级的方式编码,诸如,SVC或MVC流。在这种情况下,图8的无线资源管理器30的操作模式可描述为如下。
LTE RRM实体30利用深度数据包检查50来检查由特定用户请求的MPD 46。LTE调度程序30根据可用的无线资源评估由给定用户请求的带宽量。如果请求带宽超过用于给定SVC或MVC层的可用带宽,则LTERRM实体30可触发HTTP DASH服务器42以向用户40发送W3C HTTP状态代码。DASH客户端40内的SVC/MVC解码器70接收错误状态代码,并自动地请求要求较低带宽的较低SVC或MVC层,并且因此节省了LTE系统上的无线资源。
由于给定用户的较差信道质量或由于请求资源的其它用户的数量,限制了无线资源。LTE RRM30可强制具有良好信道质量的用户牺牲资源,将该资源随后可被分配给承受更差信道质量的用户。
根据LTE RRM30内的优先级策略,RRM30在允许较高SVC/MVC层的HTTP请求之前,可通过触发W3C HTTP状态代码80使用MPD46来确保最低SVC/MVC层(基层)的服务递送。
HTTP DASH服务器42可发送以下W3C HTTP状态代码的其中之一:
·404未不到
·466超过流速率(RFC中的tbs.)
·503服务不可用
·509超过带宽限制
在开始对本申请的下一个实施方式进行描述之前,应注意,当去掉资源管理器74时,图7中所示的用户实体34的一般结构通常也适用于所有其它的实施方式。媒体再现器76可为能够解码从服务器42接收的媒体内容44的媒体解码器。客户端40和媒体再现器76可彼此耦接并彼此通信。媒体再现器甚至可部分地集成在客户端40内。
根据图3至图5的实施方式,根据媒体呈现描述的检查结果来适配分配给单个用户实体的通信资源并且特别是分配本身。根据图6至图8的后续实施方式,客户端与服务器之间的数据流量的属于从客户端发送给服务器的媒体请求的部分受到影响,以实现基站通信资源的更有效利用或者获得基站通信资源到用户实体的更公平分配。根据两个实施方式,无线资源管理器30还能根据下文所述的实施例将物理层上的LTE闭环(closed-loop)反馈考虑在内。即,以下可能的实施是为了表示图5和图8的实施例的更详细说明。即,根据当前可能的实施,无线资源管理(RRM)调度程序30将来自LTE的物理层上的LTE闭环反馈考虑在内,以在LTEEMB 32上决定媒体内容44的哪种视频表示或版本最适合DASH客户端。再次,根据图3的实施方式和图5的实施,资源管理器30间接地通过相应地将通信资源分配给相应表示专用于的相应客户端40来设法下载最适合的表示或版本。而根据图6的实施方式和图8的实施,如上所述,无线资源管理器30通过客户端适当地影响客户端媒体请求来设法达到最适合的表示的下载。
例如,RRM单元30在(H.264/)SVC层的情况下,当在媒体内容44的AVC片段的不同表示之间进行选择时,或者在(H.264/)MVC的情况下,当在2D或3D视频递送之间做决定时,将LTE闭环反馈考虑在内。LTE eNB RRM30可检查MPD46,以在图3和图5的情况下将RRM参数调整为指定于特定视频片段的参数,并在图6和图8的情况下影响HTTP设置(set)请求。
UE40可将无线信道的质量量度(即信道质量反馈(CQI)以及视频缓冲器的缓冲级别(参见表3)发送给eNB RRM实体30。可通过定期或不定期地发送峰值与均值之比(PAR)(例如,峰值与均值速率比(PARR))指示(indicator)来减少反馈信息。利用该信息,eNB RRM实体30可在知晓用于HTTP流媒体服务的缓冲器的情况下执行多用户调度。
被用于计算PAR和/或PARR的物理层(PHY)数据的信道质量量度可涉及如在LTE标准中定义的以下参数的一个或任意组合:
·CQI:信道质量指示
·RI:等级(rank)指示
·PHY层数据速率
·PHY层延迟和跳动(jitter)
·RSRP:参考信号接收功率
·RSSI:接收信号强度指示
·RSRQ:参考信号接收质量。
此处,RSRQ通过下式定义:
RSRQ=N×RSRP/RSSI.
其中,N为测量了RSSI值的资源块的数量。
从上述实施细节中可以看出,图3和图6的无线资源管理器30可分别采用由客户端的用户实体向基站所发出的物理层上的闭环反馈。这意味着,发送侧的系统可依赖跨层(cross-layer)信息以改善视频传输,而接收侧不需要任何跨层接口。另外,RRM可基于信道估计还可为一个或多个客户端分配多少带宽以提高其视频质量。
例如,图3和图6的RRM30可被配置为确定分配给用户实体的平均带宽,并根据所确定的平均带宽预测当前由相应的客户端(诸如,44)下载的是媒体呈现描述46中的媒体内容44的哪个版本。这形成了得出客户端的状态的简单方法。对于每个客户端,RRM30仅需要识别相应客户端40正在接收的平均带宽,并据此预测其选择的媒体速率。
另外,如上所述,无线资源管理器30还可尝试得出媒体缓冲状态信息,即,指示运行在相应用户实体上的客户端的缓冲状态的类型的信息。换句话说,无线资源管理器30可利用关于用户实体34接收状态的信息以确定相应的用户实体实际上是否能有效地、正确地接收所分配的带宽。利用该信息,无线资源管理器30能够通过考虑最低带宽信息(如上所述,无线资源管理器30可从媒体呈现描述46中获得)来模拟运行在用户实体上的客户端的缓冲状态。通过该措施,无线资源管理器30能够模拟或模拟运行在用户实体34上的客户端40的缓冲状态,并由此推断客户端的行为和客户端的优先级。例如,与模拟结果显示缓冲器已满的客户端40相比,可为模拟结果显示缓冲器用完(run out)媒体数据的客户端40分配较高的优先级。
自然地,上述根据客户端40与相应服务器之间的数据流量来模拟缓冲状态或得出媒体缓冲状态信息的可能实施在计算上非常复杂并且所获得的精度可能很低。
因此,图3的实施方式可以如下方式扩展:无线资源管理器30还可被配置为不仅根据媒体呈现描述46(除当前资源状况信息之外),而且根据从来自运行相应客户端40的相应用户实体的信道质量反馈得出的媒体缓冲状态信息,来将基站32的通信资源分配给用户实体。特别地,所得出的媒体缓冲状态信息可通过模拟相应用户实体客户端40的缓冲器的上述模拟来得出,缓冲器利用相应用户实体34的估计的有效比特率来填充,并被输入在媒体呈现描述46中指示的呈现带宽。
当然,关于图6的无线资源管理器30也是如此。即,无线资源管理器30可使用模拟结果以决定对用户实体客户端40的媒体请求的影响。
此此外,图7的实施方式也可这样扩展。即,图7的资源管理器74可使用当前资源状况信息以模拟客户端的媒体缓冲状态并相应地进行动作,以作为无线通信社区的一部分保护基站的通信资源抵抗两个贪婪的客户端40。
然而,如刚刚描述的,客户端缓冲状态的“模拟”可能经受高度的不确定性,并且因此,可以如下方式对图3和图6的实施方式进行修改:无线资源管理器30不需要得出或模拟用户实体客户端的缓冲状态,而是改为无线资源管理器30采用来自客户端40的数据流量内的明确的媒体缓冲状态信息。基于从客户端40到服务器42的数据流量内的媒体呈现描述46和媒体缓冲状态信息,由于更精确的缓冲状态估计,无线资源管理器30可更精确地执行通信资源分配。在来自客户端40的数据流量内的媒体缓冲状态信息中,后者将明确地指示当前媒体缓冲状态,即,当前媒体缓冲器的填充水平。下面将对具体的可能的实施进行详细描述。
但是,根据替代实施方式,图3的无线资源管理器30可替代地可根据来自客户端40的数据流量内的媒体缓冲状态信息而不根据媒体呈现描述46来执行基站32的通信资源到用户实体的分配。仅测量多个用户实体客户端40的媒体缓冲状态便使无线资源管理器30能够获得可用基站通信资源到用户实体的更公平分配。
因此,图3还涉及被配置为根据运行在其中一个用户实体上的客户端的媒体缓冲状态信息来将基站32的通信资源分配给用户实体34的无线资源管理器30。通信资源到用户实体的分配可进一步基于一个或多个上述可能的实施方式的一个或多个进行来执行,诸如,基站32的通信资源必须按适当比例分配给其的用户实体34的数量、在用户实体与基站之间交换的通信数据的类型等。此外,在将通信资源分配给用户实体时,可根据媒体缓冲状态信息(即,子载波、时隙和基站小区的空间覆盖范围)来调整上述设置。如上所述,媒体缓冲状态信息可从客户端40到服务器42的数据流量内的明确信令中提取,或可基于从用户实体34到基站32的信道质量反馈通过模拟用户实体的缓冲状态来得出媒体缓冲状态信息。
第二种可能的实施也属于图6和图7的实施方式。代替当前资源状况信息和媒体呈现描述46的使用,图6和图8的无线资源管理器30和资源管理器74可分别被配置为根据来自客户端40的数据流量内的媒体缓冲状态信息执行执行关于对媒体请求60的处理方式的决定。
因此,上述实施方式还展示了被配置为执行以下操作的资源管理器:检查在从服务器42到运行在用户实体34上的客户端40的数据流量内的描述不同带宽的媒体内容44的版本的媒体呈现描述46;检查从客户端40到服务器42的请求所需版本的媒体内容44的媒体请求60;从客户端40接收媒体缓冲状态信息;以及根据媒体缓冲状态信息和媒体呈现描述46根据决定(1)将媒体请求60转发给服务器,或者可替代地,(2)将媒体请求60修改到使所修改的媒体请求请求较低带宽的媒体内容44的程度,或者拦截媒体请求60并进行模拟,或者指示服务器42从服务器42向客户端40发回不可用的响应。
下面描述作为图3、图6和图7的替代描述的刚刚描述的实施方式的可能的实施。该详细的实施的标题可为“在LTE上的具有闭环反馈over thetop(OTT)的DASH”。根据该可能实施,利用客户端直接反馈over the top,例如,质量量度,诸如在表3中定义的BufferLevel,在LTE系统的DPI调度程序30上更精确地跟踪客户端的BufferLevel。
表3:缓冲器级别的质量量度
可能产生的实施在图9中示出。通过比较图9的实施与图5的可能实施,可以看出,图5的实施增加了从用户实体34到RRM30的LTE反馈90,其中,后者(即,RRM30)使用LTE反馈(即,来自用户实体34的信道质量反馈)以执行更佳的通信资源速率分配R。
在下文中,关于上述实施方式,描述关于客户端40的实施方式的某些可能实施细节。如上所述,客户端的行为可由相应客户端发行商自由地设置,并且因此,上述实施方式并没有对客户端的行为进行过多描述。另一方面,为了增强对上述实施方式的全面理解,下文假定客户端为DASH客户端,对可能的客户端行为进行了描述。
如在[ISO/IEC23009-1]中定义的DASH是一种客户端驱动自适应技术,但它并没有规定客户端的行为并为不同的实施提供了完全的自由度。然而,由客户端报告的MPD和QM包括某些重要信息,可从这些重要的信息预测客户端行为。该重要信息涉及以下信令:
·minBufferTime
·bandwidth
·隐性分配LTE客户端速率,如果有足够数据可用,则可由客户端测量为TCP吞吐量
·客户端根据预期的播放延迟/潜在中断(outage)适应TCP吞吐量
·QM,由客户端报告
·位流切换标记
DASH客户端的目标是基于其设备特性以它可支持的最高质量连续地播放流媒体内容。为了连续地播放,在客户端上的缓冲器在任何时间都不应为空的。MPD中的mmBufferTime向客户端保证,如果这些数据量在会话开始时就存储在其缓冲器内,如果它们至少以与bandwidth中所指示的值一样高的速率下载,则它们可播放显示具有bandwidth的视频版本。因此,客户端应在开始播放视频之前预先缓冲至少这些数据量,并且当其缓冲器充满度改变时基于其相对于minBufferTime的大小切换到具有不同bandwidth的不同视频版本。由于客户端的缓冲器充满度对基站来说是未知,并且其估计可能是复杂或不准确的,例如,当使用技巧模式时,来自用户的QM报告(特别是上述QM)对于预测用户行为可以是有效的工具。
另外,DASH客户端在逻辑上分成如图10所示的两个部件:DASH接入(access)客户端40a和MPEG媒体引擎40b,如图7所示。
·DASH访问客户端40a:该实体负责分析MPD46,执行调度算法,并将媒体64以格式92传递给MPEG媒体引擎40b。
·MPEG媒体引擎40b:该实体负责处理媒体数据92,即,解码、重构等。
参考图7的以上描述,实施利用用户实体和/或客户端的上述任何有利功能的增强DASH客户端有两种可能的选择。这些可能的选择是:
·具有跨层DASH访问客户端:跨层访问客户端从物理层获取测量结果,并可能从LTE网络接收额外的信令。采用这种额外的智能方式,可执行对信道的更佳的估计和增强自适应调度。
·然而,通常,预料已经实施的DASH客户端,例如,在浏览器等中的DASH客户端的实施方式中,自适应是通过监控例如客户端缓冲器级别或下载指定数据量所需的时间在较高层中进行的。在这种情况下,一种可能的实施是具有负责自适应的外部“媒体管理器”部件(参见图8和图9)。类似于与之前描述的一个,但DASH客户度将不会意识到这点。为了避免这种“重复的”DASH访问客户端(DASH访问客户端也执行自适应),在MPD级上需要额外的信令:可添加新属性,例如,automaticSwitching,其将指示DASH访问客户端在DASH客户端之外(即,在接收设备中,通过“资源管理器”74)执行了了自适应。MPD中包含的automaticSwitching指示客户端,服务器或中间的任何设备可根据所选择和请求的表示将视频速率调整为符合视频的配置文件和级别,因此客户端不应再进行任何媒体速率自适应。
第二种情况,即,具有“资源管理器”的情况在图11中示出。从图11中可以看出,与客户端/服务器数据流量相比,资源管理器74使用在较低OSI层上的数据100,以用作如上所述的资源管理器。
特别地,资源管理器74可执行自适应和媒体请求,或也可执行DPI或修改用户请求等。另外,“媒体管理器”可与RRM交换关于物理层信息和资源分配的某些附加信令消息,以执行比在仅使用较高层信息的普通DASH客户端上能够做到的自适应更智能的自适应。
关于图6和图7的实施方式以及对应的实施,诸如,图8,应注意,这些图中所示的实施方式可以替代方式来实施以产生替代实施方式,由此,媒体请求影响被媒体呈现描述影响代替,以实现更好的资源管理。然而,也可使用关于这些附图的上述功能与下文所述的功能的组合。
特别地,根据所描述的图6的替代实施方式,无线资源管理器30被配置为检查从运行在用户实体34上的客户端40到服务器42的媒体呈现描述请求,媒体呈现描述请求从服务器42请求媒体呈现描述46。资源管理器30随后检查从服务器42到客户端40的数据流量内的媒体呈现描述46,并基于当前资源状况信息和媒体呈现描述46决定应采用以下哪个选项:1)将媒体呈现描述46转发给客户端40,作为对媒体呈现描述请求的答复,即,将媒体呈现描述46保持不变,或者2)拦截媒体呈现描述46,减少媒体呈现描述46,从而仅描述不同带宽的媒体内容44的版本的合适子组,并向客户端40发送减少的媒体呈现描述,作为对媒体呈现描述请求的答复。再次,尽管无线资源管理器30没有直接通知客户端40将媒体内容的请求版本改变为其较低带宽版本,但由于媒体呈现描述46的减少,客户端40非常可能改变用于媒体内容44的另外的媒体请求,以请求这种低带宽版本。
再次,上述功能不仅对从用户实体的角度看在基站之外产生的无线资源管理器30有效,也对在用户实体本身之内产生的图7的资源管理器74有效。以上参照图7所述的所有可能的实施细节也分别适用于上面所述的图6和图7的替代实施方式。
因此,图6和图7也揭示了被配置为执行以下操作的资源管理器:检查从运行在用户实体34上的客户端40到服务器42的媒体呈现描述请求,媒体呈现描述请求从服务器42请求媒体呈现描述46,媒体呈现描述46描述不同带宽的媒体内容44的版本;检查从服务器42到客户端40的数据流量内的媒体呈现描述46;基于当前资源状况信息和媒体呈现描述46决定1)将媒体呈现描述46转发给客户端40,作为对媒体呈现描述请求的答复,或者(2)拦截媒体呈现描述46并对其进行修改。
例如,拦截和修改可能涉及资源管理器减少媒体呈现描述46,以仅描述不同带宽的媒体内容44的版本的合适子组,并向客户端40发送减少的媒体呈现描述,作为对媒体呈现描述请求的答复。也可在MPD46中增加信息来作为对客户端40的反馈:以通知客户端40例如将质量量度(诸如下面所述的明确缓冲状态信息)发送给RRM30而不是服务器32,或指示协议变化,即,下面详细描述的从单播到多播的变化;或者使客户端40知晓处于中间的设备(即,资源管理器本身)可对客户端40请求的媒体44进行调整,从而客户端40不应对速率进行调整。自然地,协议变化指示可由RRM30通过执行或使其它设备(例如,服务器32)执行与所指示的协议变化对应的协议转换来进行。
与影响媒体请求的情况相同,资源管理器可被配置为检查媒体呈现描述46,以在媒体呈现描述46内识别媒体内容44的具有与其相关联的较低最小带宽的版本作为媒体内容44的所需版本,其中,无线资源管理器被配置为:如果存在这种具有与其相关联的较低最小带宽的版本时,根据当前资源状况信息执行决定。资源管理器可为无线资源管理器,并进一步被配置为执行将基站的通信资源分配到用户实体(运行客户端的用户实体所属的用户实体)。然而,可替代地,资源管理器可布置在用户实体内,在用户实体的收发级70与客户端40之间,其中,资源管理器被配置为从收发级70获得当前资源状况信息。此外,资源管理器可被配置为基于从用户实体到基站的信道质量反馈(由当前资源状况信息组成)来模拟用户实体的缓冲状态,并根据用户实体的缓冲状态来执行决定。
接着,利用关于实现媒体数据流的可能性的这些细节以DASH推送服务的形式描述关于上述实施方式的可能实施细节。
LTE上的DASH业务可通过所谓的推送服务来增强。例如,参见图12。有两种可能的方法:
1.HTTP服务器推送
○DASH客户端40连接至HTTP服务器42,HTTP服务器42反过来执行TCP/服务握手和通道建立
○服务器42随后将视频数据推送给DASH客户端40。
2.LTE代理推送
○DASH客户端40连接至LTE eNB内的LTE代理服务器,LTE代理服务器执行TCP/服务握手和通道建立
○LTE RRM实体30使用HTTP获得以从HTTP服务器42中检索视频数据表示
○LTE RRM30将视频数据推送给DASH客户端12
推送信息可在MPD中规定,推送信息是指推送表示。在用SVC或MVC的情况下,该信息可包括要推送给DASH客户端的层。此处,MPD46告知eNB RRM30潜在的速率切换,从而也可为其他用户优化无线资源的使用。例如,在LTE代理推送的情况下,LTE RRM30可决定推送具有较低质量和较低速率要求的服务,以为其它用户节省资源。
换句话说,在所有的上述实施方式中,基站可用作执行代理推送处理的站点。更确切地说,无线资源管理器可用作这种站点。
本文还呈现了图6的实施方式的进一步替代性描述,其中,以下替代性描述应被理解为:下文所述的无线资源管理器的功能可代替无线资源管理器30的上述空间功能,据此,其影响客户端与服务器之间的数据流量,或可表示无线资源管理器30的附加功能。
在任何情况下,根据下文所述的实施方式,图6的无线资源管理器30,除了将基站32的通信资源分配给用户实体34之外,额外地被配置为测量在运行于多个用户实体34上的客户端40与一个或多个服务器42之间的数据流量,以检查数据流量内是否存在关于共同媒体内容的媒体呈现描述46。根据检查结果,无线资源管理器随后决定:(1)除了媒体内容44的单播版本之外,向客户端40提供共同媒体内容44的多播版本;或者(2)使用于客户端40下载共同媒体内容44的协议从单播协议改变为多播协议。
然而,上述功能还可在处于图6所示的负责执行基站通信资源到用户实体的分配的无线资源管理器30的外部或与其分离的无线资源管理器内执行。客户端与服务器之间的数据流量的测量以及通过相应媒体呈现描述请求对是否存在由一个以上的客户端共同要求(order)的媒体呈现描述的检查,可独立于分配过程来执行。当考虑相应客户端40从要接收的单播版本切换到相同内容的多播版本的结果时,更易理解所产生的优势。由于其它客户端所需的比特率可被瓦解(collapse)为仅一个媒体流的事实,该切换可为这些客户端产生更多可用的比特率。
毫无疑问,提出的选择性选项(1)和(2)不应被理解为根据该实施方式的无线资源管理器实际上被配置为或能够执行这两个选项。相反,无线资源管理器基于检查结果决定是否应触发选项1或2中的任一个。更确切地说,在从一个或多个服务器到不同的一个客户端的数据流量内不存在与共同媒体内容44相关的媒体呈现描述的情况下,无线资源管理器不改变客户端40与服务器42之间的数据流量。在这种情况下,无线资源管理器既不执行选项1,也不执行选项2。再确切地说,在对任何数据流量的操纵不会节省很多比特率的情况下,无线资源管理器不改变相应的数据流量。然而,想象多个用户分别决定切换到直播(例如,足球赛或任何其它新闻直播)的情况。在这种情况下,能够为所有这些客户端从单播流媒体切换为多播流媒体将是有利的。根据第一种选项,无线资源管理器在意识到数据流量内的重叠媒体呈现描述时,被配置为操作至客户端40(其通过相应的媒体呈现描述请求请求关于媒体直播的媒体呈现描述)的媒体呈现描述。该修改改变原始媒体呈现描述到除了或代替媒体内容44的单播版本可用之外仅多播版本可用的程度。由此,至少这些新加入的客户端40会考虑或不得不考虑多播版本。根据第二种选择,无线资源管理器30在意识到数据流量内的重叠媒体呈现描述的情况下,被配置为改变例如来自客户端的请求共同媒体内容44的各个媒体请求,以将其从请求单播版本改变为请求多播版本。替代修改方案也是可行的。
因此,图6还揭示了被配置为执行以下操作的无线资源管理器:测量在运行在用户实体34上的客户端40与一个或多个服务器32之间的数据流量,并检查从一个或多个服务器32到不同客户端40的数据流量内是否存在与共同媒体内容44相关的媒体呈现描述,其中,无线资源管理器被配置为根据检查结果除了供应媒体内容44的单播版本之外向客户端40供应共同媒体内容44的多播版本;或者,无线资源管理器被配置为根据检查结果使用于客户端40下载共同媒体内容的协议从单播协议改变为多播协议。该无线资源管理器还可负责基站32的通信资源到用户实体34的分配。上述实施方式可与任何其它实施方式结合。
下面描述上述实施方式的更具体的实施。根据该具体实施,实现了DASH单播和广播/多播切换。如上所述,这种切换有利于直播服务以减少小区使用率。在这方面,应注意,上述实施方式不仅仅在考虑与一个或多个共同基站32相关联或锁定到一个或多个共同基站32的用户时可用。相反,包括其所有小区和将基站本身互连的高速链路(backbone)的一般无线网络,由于使用单播协议请求流媒体内容的客户端的数量过大,会在无意中处于紧张状态,可替代地,该流媒体内容也可由多播协议来执行。
由此,基站/LTE网络向单播用户递送直播服务。如果请求服务的用户数量增加,则应将服务切换到多播/广播服务,以减少对移动网络基础架构的高速链路和无线链路的数据速率需求。
·例如,从HTTP切换到FLUTE(经由UDP的广播文件下载协议)
用户请求HTTP服务的数据服务。Http服务器经由FLUTE协议返回HTTP获得请求。
<RedundantURL>http://cdn1.example.com/</RedundantURL>
<RedundantlJRL>flute://cdn2.example.com/session-description.sdp</RedundantURL>
可基于MPD中的指示,例如包含至FLUTE(FLUTE-经由单向传输的文件递送)[IETF RFC3926]会话的描述的链接的“冗余URL”,在例如会话描述协议SDP[IETF RFC4566]中应用协议变化。冗余URL表示具有替代传输特性的替代媒体位置,诸如,从HTTP到FLUTE的协议变化。另外,协议变化还可包括源位置从单播到多播地址的变化。
明显地,参照图3和图6以及对应实施例,用户实体当前可由一个以上的基站32服务。即,用户实体可经由除了RRM调度程序为其执行RRM的基站的另一基站接收MPD。终端需要通过基础IP连接以接收MPD,在这种情况下,该连接在无线系统(例如,LTE)上利用LTE的RRM单元建立。因此,为了接收MPD,UE需要具有由RRM分配的某些资源。在当前的LTE Rel.8/9中,终端连接至与具有唯一小区标识符(Cell-ID)的单个基站(以特定频率运行,例如,2.6GHz,具有10或20Mhz带宽)连接。在这种情况下,UE仅可使用底层LTE网络获得MPD。在下一步骤中,可采用已具有现有LTE的多频带技术。多频带是指,例如,我们具有运行在800MHz的一个基站和运行在2.6GHz的另一个基站。由于每个基站都有自己的小区ID,终端可同时与两个基站连接。因此,终端可具有一个以上的IP接入点,在此处的实例中,IP接入点数量为两个,可使用一个基站检索MPD,并且使用另一个基站实际检索数据。在这种情况下,可独立使用两个RRM单元。这还可扩展到其它技术,例如,使用用于分配MPD的LTE,使用用于获得数据的Wifi。这种多频带方法要求在客户端内的一定程度的智能性,客户端基于当前网络负荷或信道质量等决定采用哪种技术。
对于上文关于对与客户端40相关联的缓冲状态的模拟的描述,应注意,模拟的缓冲状态也可以是用户实体34内位于别处的另一缓冲器。例如,模拟的缓冲状态实际上还可与用户实体的收发级内的MAC层缓冲器相关。参见例如图13,图13示出了上述在收发级70内的MAC层缓冲器的实例(pedant),即,缓冲器区100。缓冲器100还可位于基站32内。换句话说,图13示出了在客户端40与服务器32之间的部分数据路径的的可能的实施,包括客户端40的可能的实施。与以上所有附图不同,图13还示出了MAC层实体,例如,MAC层缓冲器100,即,位于RRM30之外的客户端40的另一侧的网络缓冲器。为了完整起见,还示出了与用户实体的收发级70对应的基站的收发级102。收发级70还容纳了MAC层实体,诸如,特别是另一MAC层缓冲器,然而在图13中未示出。顺便提及,图3的RRM30还可监控该MAC层缓冲器中为客户端40缓存的媒体内容的量,以模拟用户实体的缓冲状态。
还需要进一步指出的是,除上述功能之外或代替上述功能,图7或图13中的RM74可免除图3的RRM30测量服务器与客户端之间的数据流量以得到MPD的过程。因此,资源管理器74可被用于完全地分析和检查媒体呈现描述,并将其转换(translate)为仅包括客户端支持的用于被请求媒体服务的潜在比特率操作点的子组媒体呈现描述,例如,特定HTTP流媒体会话。即,所转换的媒体呈现描述可表示在相应服务器上可用的媒体内容44的版本的基本描述,即,上文参照图3所述的媒体呈现描述的类型。如上所述,在所转换的媒体呈现描述内仅可指示单个版本的信息密度之间的等级,即,非常粗略的各个版本的质量测量。可替代地,如上所述,对于每个版本,在用于每个相关媒体内容版本(即,根据用户实体的设施可呈现给用户实体上的用户的那些媒体内容版本)的转换媒体呈现描述内可指示用于将相应版本呈现给用户所需的最低带宽。随后可将该转换的MPD例如在PHY/MAC层上转发给无线资源管理器30,以使其使用这些比特率操作点为特定客户端及其控制下的其它客户端进行进一步的调度和无线资源分配决定。允许进行自适应的视频服务的类似,即,允许支持不同比特率、各自操作点的服务,可使用服务质量参数信令(诸如在[19]中所定义的)来指示。因此,可在表6中增加新的流量类别,诸如,“自适应非对话视频和自适应视频”,以指示服务的特性。这些新类别可进一步要求用于无线资源管理器上的资源分配的一组可选速率的指示,即,所转换的MPD的指示。保证最低比特率(GBR)的信令需要扩展,以允许最低速率和/或其它有意义操作点的信令用于服务。就最低比特率而言,应注意,所转换的媒体呈现描述可指示根据在高OSI数据流量级别(诸如,TCP级别)或在某些较低OSI层级别测量的比特率的最低比特率,诸如根据由基站或无线资源管理器30分配的最低比特率。上文对实际分配和传输的比特率与在媒体内容传输中实际有效的比特率之间的差异进行了讨论,该差异是由于例如在NACK或ACK上的丢包和重传造成的。
如上所述,通过引入将分别在用户实体与基站之间交换的新类型或种类的通信数据(诸如上述“自适应非对话通信”),并在该新通信数据类型的激活的协议过程中(即,该专用承载)中传输所转换的MPD,可将存在用户实体34内的由资源管理器74从实际媒体呈现描述46中得出的转换的媒体呈现描述的传输集成到任何现有无线资源网络中,诸如,LTE中。图15以示例方式详细示出了该可能的集成。在此,LTE被示例地用作无线资源网络的代表,但原则上,图15的描述也容易地转移到其它无线资源网络。特别地,图15示出了在创建这种示例承载(即,“自适应非对话通信”)以及将转换媒体呈现描述传输给无线资源管理器30的过程中执行的连续步骤。特别地,图15沿时间轴110以时间顺序通过下文详细说明的相应方框和相关箭头示出了所有这些步骤,其中,这些方框和相关箭头沿水平方向绘制,以贯穿在相应步骤中涉及的相应实体,即,数据流量链的实体:用户实体40、基站32、无线资源管理器30、移动性管理实体112、分组网关114和媒体服务器42。如上所述,移动管理实体112还与无线资源网络的所有基站连接,甚至可至少部分地实施在硬件上,如无线资源管理器30。如上所述,移动性管理实体112负责管理用户的访问数据,例如,记录用户的支付账户、管理用户的配置文件,所述配置文件指示特定用户权利,诸如,可分配给相应用户的最大带宽、对特定通信数据类型的限制等。另外,移动管理实体112还可负责处理用户实体从一个基站的小区转移到另一个基站的小区的移交。分组网关114负责将实体40、32、30和112所属的无线资源网络与外部(即,因特网等)连接。通过虚线116示例性地示出无线资源管理器30和移动性管理实体112可集成为一个单元,而点线118表示无线资源管理器30可位于基站32内。
从图15中可以看出,假定用户实体40已附接到无线资源网络,并且已激活了默认承载,从而用户实体40能够经由无线资源网络执行最小任务,例如,执行对因特网的低复杂度接入任务。附接和默认承载激活的步骤如116所示。更确切地说,只要涉及用户实体域,则步骤116通过收发级70执行。随后,假设用户或用户实体34上的客户端40使用在当前实例中的默认承载会话向媒体服务器42发送MPD请求118。媒体服务器42在步骤120中发回MPD,其中,在用户实体34内的资源管理器74在步骤122中分析该MPD,以如上所述地将步骤120的MPD转换为转换的MPD。随后,在步骤124中触发专用承载激活,例如,“自适应非对话通信”的激活。例如,触发124可由请求在步骤122中分析的MPD所涉及的媒体内容的用户实体34的用户或其上的客户端40来引起。响应于触发124,资源管理器74和收发级70互相协作,以在步骤126中将承载资源分配请求发送给基站32,由此通知基站32在步骤128中分别将相应的分配请求转发给无线资源管理器30和移动管理实体112。分配请求包括利用例如以下更详细描述的句法转换的上述媒体呈现描述。随后,移动性管理实体112在步骤130中使用承载资源命令通知分组网关114将会创建相应的承载资源,其中,创建过程本身在步骤132中进行。由此,从步骤128开始,无线资源管理器30就知道了转换媒体呈现描述的内容,但专用承载的激活还没有确认。由此,移动管理实体112通过在步骤134中向基站32发送专用承载激活请求而启动另一个确认进程,基站32随后在步骤136中将该请求转发给用户实体34,特别是收发级70。随后,在步骤140中,收发级70向基站32发送专用承载激活接受信号,基站32随后在步骤142中相应地通知无线资源管理器30和移动管理实体112。从此时开始,无线资源管理器30能够通过使用资源管理器74在步骤120至128中发送给资源管理器30的转换的媒体呈现描述来执行上述无线资源分配,即,调度。由此,当考虑将无线资源分配给由基站32和无线资源网络分别服务的所有用户实体时,用户实体34上的客户端40与媒体服务器42之间的媒体传输会话144可由无线资源管理器30有效地控制。
对于图15,应注意的是,一般来说,建立专用无线承载有两种方法。第一种方法是客户端驱动法。此处,UE34经由默认承载与因特网连接,如图15所示。基于对之前由客户端40发出的MPD请求118的响应120,用户实体的RM74接收对应的MPD文件以进行检查,并相应地触发124专用无线承载。这可通过向移动性管理实体112(MME)发出126ESM承载资源分配请求来触发专用承载激活来完成(参见[20]中第8.3.8节),。该消息126包含定义了所需演进分组系统(EPS)服务质量信息(即,所转换的MPD)的信息单元(IE)。
另一种方法是网络驱动法。此处,P-GW114触发无线承载的建立,这在移交程序期间保持所需的QoS承载是必需的。在这两种情况下,都发送包含EPS服务质量信息(参见[20]中第9.9.4.3节)的ESM激活专用承载请求消息(参见[20]中第8.3.3节),如下表所示。与[20]相比,该表进行了扩展或修改以包含具有最低唯一替代高比特率的GBR的信令以及具有替代比特率的非GBR的信令,即,转换的MPD。在如图15所示的UE触发专用承载的情况下,其提供了诸如在MPD中发现的替代比特率的信息单元。在网络触发专用承载的情况下,替代比特率和转换的MPD在移交的情况下应分别由对应的P-GW提供,或由资源管理器(74)在检查MPD之后提供。因此,P-GW需要告知RRM关于MPD位置或其内容。在[20]中,其它消息,即,承载资源修改请求(第8.3.10节)和激活默认EPS承载请求(第8.3.6节)还包含在表3中所示的EPS服务质量信息消息,并且可用于提供上述替代比特率。
表3示出了当前定义的服务单元的EPS质量。
可添加更多八位字节,如表4所示。保证比特率中所示的比特率与必须保证的最低带宽对应,例如,为最低质量/最低信息密度区域的保证的最低带宽,而用于下行和上行链路的替代比特率指可用于原始MPD46中发现的下载内容的比特率。根据QCI字段的值确定是否显示替代比特率的字段。如果使用(例如)表5中定义的新QCI值,则应显示用于下行链路或上行链路的替代比特率。这个机制实现了反向兼容性。如果不知道QCI值,则根据是否存在保证比特率选择另一个GBR或非GBR QCI。
表4替代比特率的服务信息单元的扩展的EPS质量
另一种方法是,在使用服务信息消息的EPS质量(ESM承载资源分配请求、ESM激活专用承载请求、承载资源修改请求和激活默认EPS承载请求)的情况下,在服务信息消息的EPS质量中添加附加消息,随后将EPS服务质量信息消息添加到上述消息中。这可使服务消息的EPS质量保持不变。扩展内容可如下表5所示。这种情况下,应获取服务信息消息的EPS质量中的保证比特率值,但QCI值可能会被扩展消息覆盖。替代比特率还可在该扩展消息中描述。
表5携带服务信息单元的EPS质量的替代比特率的附加消息
如图15所示,MME112必须与核心网络的其它部分(即,S-GW和P-GW114)交换消息,以建立用于服务的具有指定QoS的承载。S-GW是基站(eNB)与其它EPC(演进分组核心)实体(例如,P-GW)之间的网关。P-GW(有时也称为PDN-GW=分组数据网络网关)是EPC与因特网/高速链路之间的接口。因此,LTE网络中的所有数据的传输路线为:UE(终端)<->eNB<->S-GW<->P-GW<->因特网/高速链路。
另外的消息的交换包括从MME到S-GW和从S-GW到P-GW的GTP-C承载资源命令(参见[21]中第7.2.5节)、从P-GW114到S-GW和从S-GW到MME112的GTP-C创建承载请求(参见[21]中第7.2.3节),以及告知无线资源管理器30要提供的QoS特性的E-RAB创建请求/响应(参见[22]中第8.2.1.1节和第8.2.1.2节)。上述这些消息应必须相应地扩展为表4和表5中的扩展名。例如,对于GTP-C承载资源命令,[21]中第8.16节中的流量QoS IE应用本文定义的替代比特率进行扩展,例如,如表6所示。对于GTP-C创建承载请求,[21]中第8.15节中的承载QoS IE应用本文定义的替代比特率进行扩展,例如,如表7所示。对应E-RAB创建请求,MME112应将协商的替代比特率插入[22]中第9.2.1.15节中的E-RAB级别QoS参数中。为了达到这个目的,E-RAB级别QoS应通过添加上文定义的附加替代比特率而进行扩展,例如,如表8和表9所示。
表6:服务的流量质量(流量QoS)
表7:服务的承载级别质量(承载QoS)
表8:E-RAB创建请求或E-RAB级别Qos参数
表8:ABR-QoS:自适应比特率(ABR)QoS的替代比特率
与上述过程相似,移交可由eNodeB发起,如[23]所述。在这种情况下,承载创建或承载保持(具有相同的QoS特性)并不是由发出ESM承载资源分配请求的MME或P-GW来发起,而是在3GPP[24]中定义的X2接口内进行。在这种情况下,上文所述的具有替代比特率的扩展的句法必须包括在合适的消息内。具体地说,对于接口X2,定义包含E-RAB级别QoS参数IE/组名的移交请求消息(参见[23]中第9.1.1.1节)。[23]中第9.2.9节对该IE进行了定义,其扩展应如表8所示。该消息的句法应与上述E-RAB创建请求相同。
另外,除上述功能之外或者代替上述功能,资源管理器74可将例如通过更高级别TCP会话所见的实际接收吞吐量作为信息转发给无线资源管理器30,以使其识别实际产生的应用吞吐量,以未特定客户端及其控制下的其它客户端进行进一步的调度和无线资源分配决定。一般来说,可运行客户端40的用户实体34可与无线资源基站32通信,其中,用户实体34可被配置为确定实际接收的媒体内容吞吐量或由客户端40从服务器42中检索的媒体内容的缓冲状态,并通知无线资源管理器30所确定的媒体内容吞吐量或缓冲状态。该确定可涉及客户端40向假定负责用户实体内的相应任务的资源管理器74发送相应的信息。
关于图3至图5的实施方式,应指出的是,上述说明主要涉及下行链路的情况,即,无线资源管理器向用户实体34分配下行链路通信资源的情况,但上述实施方式也适用于上行链路的情况。总体来说,例如,在图3至图5以及涉及无线资源管理器30的功能(根据其执行通信资源的分配)的所有其它实施方式中,无线资源管理器可更一般地被配置为根据从服务器到客户端的数据流量内的媒体呈现描述将至少一个基站32的通信资源(即,下行链路和/或上行链路通信资源)分配给用户实体34,其中,服务器和客户端的其中一个运行在其中一个用户实体34上,但运行在用户实体34上的这一个不一定为客户端。下文将对其进行详细明确地说明。参见例如图16。应注意的一点是,服务器和客户端可在一个共同的用户实体上运行,并且因此,“服务器和客户端的其中一个”应被理解为“至少一个。
图16与图3对应,除了客户端40与服务器42调换:服务器42运行在用户实体34上,而客户端40相对于用户实体34位于基站32的另一侧。当考虑图7所示的用户实体的可能内部结构的更详细说明时,服务器32可被认为是代替图7中的客户端40。这意味着:无线资源管理器30可测量服务器42与客户端40之间的数据流量。特别地,无线资源管理器30可检查其中的媒体呈现描述46。基于此,无线资源管理器30可将基站32的上行链路通信资源分配给用户实体,用户实体中的用户实体34是运行服务器42的用户实体。原则上,关于资源管理器30的潜在行为的所有上述讨论保持不变。即,资源管理器30也可检查和记录从客户端40到服务器42的媒体请求,并根据其评估等执行上行链路通信资源的分配。
考虑上文所述的图3至图5的实施方式的扩展(无线资源管理器30的一部分功能从RRM30转移到位于一方面的服务器42与另一方面的收发级70之间的资源管理器74上,参见例如图7)时,一方面的图3至图5的实施方式与另一方面的图16的实施方式之间的一致性保持有效。即,这对图16的情况同样成立:资源管理器74可被配置为免除RRM30对用户实体34上的服务器42与客户端40之间的数据流量的测量。即,即使在这种情况(即,服务器42运行在用户实体34上)下,也可以类似方式管理上行链路带宽的资源,即,资源管理器74向无线资源管理器30指示替代比特率,即,转换的MPD,并且RRM30使用转换的MPD基于此执行上行链路资源的分配。资源管理器74可在包含扩展服务消息的EPS质量上述ESM消息中指示用于上行链路的替代比特率,如表4所示。
参见例如图14。在左手侧,图14示出了与图15相似的流程图,即,使用时间轴110,通过沿水平方向分布相应实体并且通过与相应方框关联的箭头来示出相应实体,从而区分在相应方框中所示的相应步骤涉及的实体,在这些实体之间进行相应步骤。在图14的右手侧,再次示出图15的情况,即,客户端处于用户实体上的情况。在左手侧,示出了服务器42运行在用户实体34上的情况。实际上,运行在一个用户实体上的客户端和运行在另一个用户实体上的服务器可构成传输媒体内容的一对设备。例如,这种情况发生在电视会议中,其中,运行在用户实体34’上的服务器向运行在用户实体34”上的客户端传输关于在用户实体34’上例如通过用户实体的各个摄像头捕捉的视频会议的参与者的视频。但是,也可能存在其它使用情况。例如,客户端可能会从在其他地方的用户实体34’上的媒体服务器上下载文件。在这种情况下,在一方面的用户实体34’上的服务器与另一方面的用户实体34”上的客户端之间的数据流量的参与实体在图14中按以下从左到右的顺序示出:用户实体34’、用户实体34’当前附接至的基站32’、负责分配基站32’的通信资源的无线资源管理器30’、负责控制基站32’和无线资源管理器30’所属的无线资源网络的移动管理实体112’、属于同一无线资源网络的分组网关114’、以及均属于基站32”所属的并且客户端34”附接至的无线资源网络的分组网关114”的移动性管理实体112”、负责分配基站32”的通信资源的无线资源管理器30”、基站32”本身以及用户实体34”。如图14所示,用户实体34”将在步骤116’中以与用户实体34”在步骤116中所做的相同的方式执行附接和默认承载激活。如上文参照图15所述的,处于用户实体34”上的客户端可在步骤118中向处于用户实体34’上的服务器发送MPD请求,随后用户实体34’上的服务器在步骤120中将MPD发回给用户实体34”。随后,在步骤122中,处于用户实体34”上的资源管理器74分析MPD,随后按上文所述的步骤126至142激活专用承载,此后,资源管理器30在随后发生于客户端与服务器之间的媒体传输会话144内根据用户实体34”的资源管理器74转发的转换MPD分配基站32”的下行链路通信资源。在上行链路域一侧,采取类似的步骤。处于用户实体34’上的服务器42以与上文参照图15所述的步骤126至142相似的方法激活专用承载,即,自适应对话或非对话通信型会话,随后,在媒体传输会话144内,无线资源管理器30’根据由用户实体34’上的服务器在承载资源分配请求126内转发的转换媒体呈现描述分配基站32’的上行链路资源。
应指出的是,图14仅示例性地示出服务器和客户端均处于连接至相应无线资源网络的用户实体上的情况。图14的示例还可适用于客户端并非运行在用户实体上而是运行在例如固定式计算机上的情况。另外,应指出的是,示出的情景也可发生在一个共同的无线资源网络内,并且RRM’和RRM”和/或MME’和MME”相同。
顺便提及,应注意的是,在上述所有实施方式中,媒体内容44所处的服务器可与用作用于提供媒体呈现描述的服务器的实体分离。更一般地,MPD46可来自不同于提供媒体内容44本身的服务器的另一个实体或服务器。这种可能方案如例如在图14中示出,关于箭头来源和目标的虚线分别与步骤120和118对应。特别地,该潜在的MPD来源如150中的虚线所示。在存在该额外MPD来源150的情况下,仍然可由资源管理器74通知无线资源管理器30’所转换的媒体呈现描述。但是,在这种情况下,资源管理器74将代替检查用户实体34”上的客户端与用户实体34’上的服务器之间的数据流量,而是通知用户实体34’上的服务器向用户实体34”上的资源管理器74提供所转换的媒体呈现描述。
因此,换句话说,图14左侧的用户实体34被设置为媒体服务器,右侧的用户实体34被设置为客户端40。客户端请求从MPD来源150中请求MPD,MPD来源150可为网络中的任何服务器(一个特殊情况是,具有MPD的服务器是用户实体34’上的媒体服务器)。由于媒体服务器已知在MPD上传播的媒体的特性(其已在MPD上被告知),其利用该信息在所述ESM消息中指示替代比特率并创建上行链路比特率对其特别重要的承载(服务器需要上传数据)。但是,客户端需要分析接收的MPD并使用上述信息以进行其中下行链路比特率特别重要的承载分配(客户端40需要下载数据)。但是,由于可使用TCP,下行链路比特率对服务器来说也非常重要,上行链路比特率对客户端也非常重要。
有一种特殊情况,例如,在会话情景中,其中,每个用户实体34具有同时运行在其上的媒体服务器和客户端。在这种情况下,用户实体34将请求媒体呈现描述(例如,MPD或SDP)请求,并基于在其相应服务器上提供的媒体特性和假定作为客户端40接收的媒体特性来使用该信息描述上行链路和下行链路的替代比特率。
在用户实体34同时具有媒体服务器和客户端的这种情景中,可由两个不同eNodeB负责参与对话的不同用户实体34。为每个eNodeB运行的并且负责用户实体34的无线资源管理器30独立地运行,优化用于不同用户的每个空中接口。这种方案的问题在于,优化一个用户实体34的无线资源时,并不考虑另一个用户实体34的空中接口。因此,可能做出不是最佳的决定。例如,如果从一个用户实体34上传的数据量大于可在与第一个用户实体34通信的另一个用户实体34上下载的数据量,与存在“下载问题”的用户实体34协作的无线资源管理器30将会丢弃某些数据。一个解决方案是,扩展在X2接口[23]中定义的消息,并基于MPD或SDP中定义的信息添加提供关于将为每个用户保证的资源的具体信息的消息。这样,两个eNB执行将在SDP或MPD中如贯穿该文件所定义的信息考虑在内的协作式资源分配。新消息可为,例如,UE资源状态报告,并且包含资源分配IE,如表9、表10和表11所示。
第二种实施方式揭示了在不知晓媒体的情况下进行的协作式资源分配,如下文所述。参见例如图3。图3仅示出了一个无线资源管理器30,但如上所述,多个无线资源管理器的系统可构成所有无线资源管理器30互相独立运行的无线系统,其中,每个无线资源管理器30通过优化,仅基于在其自己的基站32上传输的信息,例如,上文所述的来自用户实体34的质量反馈、要服务的用户实体34的数量等将其至少一个基站32的通信资源分配给处于其基站32的覆盖范围内的用户实体34。参见上文的说明。即,每个RRM互相独立进行自己的调度过程。但是,根据当前实施例,突破了调度的独立性,即,RRM也将用于其UE的当前无线资源分配信息分配到外部,以用于其它RRM。在上述实例中,无线资源管理器不需要使用媒体呈现描述内的信息(如果有的话)。但是,根据现在所述的实施方式,可避免独立运行的无线资源管理器30不利地将不匹配的通信资源分配给无意中具有运行在其上的客户端和服务器通信对的用户实体。这可通过以下方法实现。
特别地,无线资源管理器测量朝向运行在其中一个用户实体34上的服务器或客户端的数据流量或在无线资源管理器之间交换的某些控制消息,以获得关于当前分配给服务器和客户端的另一个的保证通信资源或服务器和客户端的另一个的缓冲状态的信息。在服务器运行在当前由无线资源管理器30服务的用户实体34上的情况下,该服务器的缓冲状态可形成例如输出缓冲状态,即,输出缓冲器的填充水平(level)。这在例如直播或电视会议的情况下是非常有意义的。在客户端40运行在用户实体34上的情况下,缓冲状态将是客户端的输入缓冲器的填充水平。应强调的是,根据本实施方式,无线资源管理器30(参见图3)获得关于由另一个无线资源管理器30服务的服务器或客户端的该信息。仅客户端/服务器对的对应部分运行在由无线资源管理器30本身服务的用户实体34上。根据本实施方式,无线资源管理器30使用关于在其它位置被服务的用户实体上运行的客户端/服务器对应部分的该信息,以执行服务用户实体34的至少一个基站32的通信资源的分配。通过该措施,可避免无线资源管理器30在例如客户端/服务器对应部分的缓冲状态较高或当前分配给运行客户端/服务器对应部分的外部用户实体的保证通信资源较低的情况下,将多余增加的通信资源分配给某些用户实体34。
为了使其清楚,参照图17,图17示出了包括多个无线资源管理器的这种系统。在LTE架构中,RRM将来自上述eNodeB。其中一个无线资源管理器示例性地用30表示,另一个用30’表示。实际上仅示出了两个管理器,但这仅为示例。两个管理器30和30’分别分配其在至少一个基站32和32’上的通信资源。分配或调度过程互相独立地进行,除了涉及如下所述控制信号或数据流量插入的交互。
在图17中,一个用户实体34被示例性地示出为由属于无线资源管理器30的基站32服务,并且另一个用户实体34’由属于无线资源管理器30’的基站32’服务。客户端40运行在用户实体34上,并且服务器42被示例性地示出为运行在用户实体34’上。两者通过图17中的虚线所示的数据流量互相通信。数据流量可为远程通信型、下载型等。如上文参照图3所述的,数据流量不需要经过无线资源管理器30和30’。为了与测量和检查数据流量,两个无线资源管理器30和30’仅具有对数据流量的访问权将足够了。
为了避免RRM30与30’之间产生误优化(miss-optimization),两者都对另一个RRM互相通知当前的UE缓冲状态和当前的保证比特率。
根据第一种替代方案,两个RRM可互相保持对对方未知。在例如服务器或客户端由因特网中的无线系统的外部服务的情况下,可将相应信息插入在客户端/服务器数据流中以避免误优化。
无线资源管理器30’例如能够测量从服务器32到客户端40的数据流量,以获得关于当前分配给运行客户端40的用户实体34的保证通信资源或该客户端40的缓冲状态的信息。通过该措施,无线资源管理器30’能避免为服务器42消耗过多通信资源,尽管例如客户端40的缓冲状态已经较高或者当前分配给用户实体34的保证通信资源较低。另一方面,无线资源管理器30能够测量从客户端40到服务器42的数据流量,以获得关于当前分配给用户实体34’的保证信息资源或服务器42的缓冲状态的信息。以相同的方式,无线资源管理器30通过使用该信息能够避免为用户实体34分配过多的通信资源,尽管例如服务器42的缓冲状态接近空的填充水平的状态或当前分配给用户实体34’的保证通信资源很低。
如上所述,保证通信资源可由无线资源管理器30和30’在将其基站32的通信资源分配给其服务的用户实体34的过程中确定。即,无线资源管理器30和30’分别将保证通信资源以特定时间间隔为单位(例如,以3至10秒的时间间隔为单位)分配给用户实体34和34’。其在这些时间间隔内分配通信资源时也遵循(obey,遵守)保证通信资源。无线资源管理器30和30’可使用在时间间隔内固定的保证通信资源,或可改变分配给用户实体的通信资源,但仅在由保证通信资源施加的限制范围内变化。
来自外部无线资源管理器的域的缓冲状态或保证通信资源的信息可以多种不同方法进入经由数据流量对客户端/服务器对应部分提供服务的无线资源管理器的域。例如,无线资源管理器30和30’可被配置为将分配给其服务的用户实体的保证通信资源的信息插入来自运行在其服务的用户实体上的客户端40或服务器42的数据流量内。无线资源管理器30’例如可将关于分配给用户实体34’的保证通信资源的信息插入从服务器42到客户端40的数据流内,无线资源管理器30随后可将关于分配给用户实体34的保证通信资源的信息插入从客户端40到服务器42的数据流量内。此外,插入过程并不一定必须由无线资源管理器30和30’本身进行。如以上实施方式所述,这种插入过程也可由分别运行在用户实体34和34’上的资源管理器74来执行。在这种情况下,无线资源管理器30和30’将分别告知用户实体34和34’其保证通信资源,即,分配给运行它们的用户实体34和34’的保证通信资源,并且该信息将由资源管理器74进行测量和检查,资源管理器74随后代替无线资源管理器执行上述插入过程。
根据第二种替代方案,两个RRM30和30’经由控制信号199互相对另一个RRM通知当前UE缓冲状态和关于其本身服务的UE的当前保证比特率。在LTE架构中,例如,这种控制信号可经由例如X2接口、S-GW等,使用例如HSS作为引导控制信号交换路径的操作者(operator)在RRM之间进行交换。根据该实例,无线资源管理器30和30’将执行例如以下步骤:1)实现运行于其本身服务的用户实体上的客户端或服务器设法创建立即(immediate)传输会话,即,涉及该客户端或服务器的媒体传输会话开始;2)检查作为所创建的媒体传输会话的另一方的对应部分,即,服务器或客户端是否由无线系统的任何其它RRM提供服务;3)如果是,在媒体传输会话中加入控制信号199。控制信号的路径经由例如HSS进行引导。例如,无线资源管理器30经由控制信号199对无线资源管理器30’通知客户端的缓冲状态,其中,无线资源管理器30可通过用户实体34内的资源管理74的模拟或反馈已获得了如上所述的该信息。或者,无线资源管理器30可经由控制信号199对无线资源管理器30’通知分配给用户实体34的保证无线资源。无线资源管理器30’在媒体传输会话期间在相反方向进行相同步骤。即,无线资源管理器30’经由控制信号199对无线资源管理器30通知服务器的缓冲状态和/或用于用户实体34’的保证无线资源。
自然地,上述实施方式还可与上文所述的任何实施方式进行组合。只要在实施方式中,运行在由无线资源管理器本身服务的用户实体上的客户端或服务器的缓冲状态被无线资源管理器用于执行通信资源分配,就适用于这一点。
表9扩展了[23]中第9.2.13节的消息类型表,具体如下:
表9:新消息类型——UE资源状态报告
表10示出了UE资源状态报告的句法
表10:UE资源状态报告句法
表11示出了UE分配资源信息IE的句法
表11:UE分配资源信息(版本1)
可替代地,基于SDP或MPD(基于媒体特性)的各种比特率可被提供最大支持比特率,如下表所示:
表11:UE分配资源信息(版本2)
表6:标准化QCI特性[cp.19]
如上所述,上述实施例还特别揭示了客户端-例如,软件、硬件或可编程硬件-用于运行在与无线资源基站32通信的用户实体34上,客户端40被配置为从服务器42中检索媒体呈现描述和媒体内容44,媒体呈现描述46描述媒体内容44的不同带宽的版本,客户端被配置为可通过来自无线资源管理器30的信号通知从正常模式转换到从属模式,无线资源管理器30负责将基站32的通信资源分配给用户实体,其中,客户端被配置为在正常模式下向服务器42请求由客户端基于分配给用户实体的通信资源确定的版本的媒体内容44,在从属模式下向服务器42请求由客户端不考虑分配给用户实体的通信资源而确定的版本的媒体内容44。客户端可进一步被配置为在正常模式下向服务器42请求由客户端基于分配给用户实体的通信资源和媒体内容的缓冲状态来确定的版本的媒体内容44。客户端还可进一步被配置为在从属模式下向服务器42连续请求与媒体呈现描述46中的不同带宽的版本中的最高带宽版本对应的版本的媒体内容44。即,客户端行为可通过例如MPD中的automaticSwitching指示符来控制:可对客户端通知,处于中间的装置可调整所选的处于中间片段的比特率,以优化小区资源,因此,客户端本身不应对比特率变化做出反应。
上文在设备的背景下对某些方面进行了说明,但应明确的是,这些方面也代表对应方法的描述,其中的框或装置与方法步骤或方法步骤的特征对应。相似地,在方法步骤的背景下说明的各个方面也代表对应框的描述或对应设备的项目或特征。某些或所有方法步骤可由(或利用)硬件设备,例如,微处理器、可编程计算机或电子电路来执行。在某些实施方式中,一个或多个最重要的方法步骤可由这种设备来执行。
根据特定实施要求,本发明的实施方式可实施为硬件或软件。可使用其中存储有电子可读控制信号与可编程计算机系统协作(或能够与其协作)的数字存储介质,例如,软盘、DVD、蓝光光盘、CD、ROM、PROM、EPROM、EEPROM或FLASH存储器来执行实施方式,从而执行相应方法。因此,数字存储介质可为计算机可读介质。
根据本发明的某些实施方式包括数据载体,该数据载体包括能与可编程计算机系统协作的电子可读控制信号,从而执行本文所述的一个方法。
一般来说,本发明的实施方式可被实施为具有程序代码的计算机程序产品,当计算机程序产品运行在计算机上时,程序代码可被操作为用于执行其中一个方法。程序代码可例如存储在机器可读载体上。
其他实施方式包括用于执行本文所述的其中一个方法的计算机程序,所述计算机程序存储于机器可读载体上。
换句话说,本发明方法的实施方式因此为具有程序代码的计算机程序,当计算机程序运行在计算机上时,所述程序代码用于执行本文所述的其中一个方法。
因此,本发明方法的进一步的实施方式为数据载体(或数字存储介质或计算机可读介质),数据载体包括记录在其上的、用于执行本文所述的其中一个方法的计算机程序。数据载体、数字存储介质或记录介质一般为有形和/或非过渡(non-transitionary)载体或介质。
因此,本发明方法的进一步的实施方式为代表用于执行本文所述的其中一个方法的计算机程序的数据流或信号序列。数据流或信号序列可被配置为例如经由数据通信连接,例如,经由因特网来传输。
进一步的实施方式包括处理装置,例如,被配置为执行本文所述的其中一个方法的计算机或可编程逻辑装置。
进一步的实施方式包括具有安装在其上的用于执行本文所述的其中一个方法的计算机程序的计算机。
根据本发明的进一步的实施方式包括被配置为将用于执行本文所述的其中一个方法的计算机程序传输(例如,电地或光学地)给接收器的装置或系统。接收器可为,例如,计算机、移动装置、存储装置等。装置或系统可例如)包括用于将计算机程序传输给接收器的文件服务器。
在某些实施方式中,可编程逻辑器件(例如,现场可编程门阵列)可被用于执行本文所述的方法的某些或所有功能。在某些实施方式中,现场可编程门阵列可与微处理器协作,以执行本文所述的其中一个方法。一般来说,优选地,所述方法由任何硬件装置进行。
上述实施方式仅为本发明的原理的举例说明。应理解,本文描述的布置和细节的修改和变形对本领域技术人员是显而易见的。因此,目的在于本发明仅受所附专利权利要求的范围的限制,而不受通过本文的实施方式的描述和说明呈现的具体细节的限制。
缩写和符号列表
参考列表
[1]思科白皮书,“Cisco Visual Networking Index:Forecast and Methodology,2009-2014”,2010年6月.
[2]思科白皮书,“Cisco Visual Networking Index:Global Mobile Data-Traffic ForecastUpdate”,2010–2015.
[3]Information technology–Dynamic adaptive streaming over HTTP(DASH)–Part1,“Media presentation description and segment formats,ISO/IEC DIS23009-1”,2011年8月.
[4]3GPP,“Transparent end-to-end Packet-switched Streaming Service(PSS);Protocolsand codecs(第9版);3GPP TS26.234V9.3.0(2010-06):Adaptive HTTPStreaming”.
[5]A.Zambelli,“”IIS smooth streaming technical overview”.微软公司,2009”.
[6]HTTP Live Streaming Architecture,“Technical report,Apple Inc.,”2010.
[7]T.Wiegand,G.J.Sullivan,G.和A.Luthra,“Overview of theH.264/AVC Video Coding Standard”,IEEE Transactions on Circuits and Systemsfor Video Technology,2003.
[8]A.Tacz,A.Temesvary和N.Reider,“Handover Performance in3GPP Long TermEvolution(LTE)Systems”,Mobile and wireless Communications Summit,2007.
[9]T.Stockhammer,M.Walter和G.Liebl,“Optimized H.264-Based BitstreamSwitching for Wireless”,ICME,2005.
[10]S.Sharma,D.Gillies和W.Feng,“On the Goodput of TCP NewReno in MobileNetworks”,ICCCN,2010.
[11]H.Schwarz,D.Marpe和T.Wiegand,“Overview of the scalable video codingextension of the H.264/AVC standard”,IEEE Transactions on Circuits and Systemsfor Video Technology,2007.
[12]T.Schierl,Y.Sanchez,R.Globisch,C.Hellge和T.Wiegand,“Priority-basedMedia Delivery using SVC with RTP and HTTP streaming”,Springer MultimediaTools and Application,2010年9月.
[13]W.Mulder和T.Wirth,“Are we ready for the femtolution?”,IEEE COMSOC MMTCE-letter,2010年9月.
[14]ITU-R,Report M.2134,“Requirements related to technical performance forIMT-Advanced radio interface(s),Approved in Nov2008”.
[15]3GPP,“Physical layer;General description(Release8);3GPP TS25.201V8.1.0(2008-05):Adaptive HTTP Streaming”.
[16]3GPP,“Evolved Universal Terrestrial Radio Access(E-UTRA)and evolvedUniversal Terrestrial Radio Access Network(E-UTRAN);Overall description(Release8);3GPP TS36.300V8.12.0(2010-03):Adaptive HTTP Streaming”.
[17]Leekwijck,Y.Sánchez,T.Schierl,C.Hellge,T.Wiegand,D.Hong,D.DeVleeschauwer和W.Van,“iDASH:improved Dynamic Adaptive Streaming overHTTP using Scalable Video Coding”,ACM Mmsys,2011.
[18]J.Mahdavi和S.Floyd.TCP-friendly unicast rate-based flow control.1997年1月.
[19]3GPP TS23202,Policy and charging control architecture,第113GPP TS版.
[20]24301,Non-Access-Stratum(NAS)protocol for Evolved Packet System(EPS)
[21]3GPP TS29274,Evolved Packet System(EPS);Evolved General Packet RadioService(GPRS)Tunnelling Protocol for Control plane(GTPv2-C);Stage3
[22]3GPP TS36413,Evolved Universal Terrestrial Radio Access Network(E-UTRAN);S1Application Protocol(S1AP)
[23]3GPP TS36423,3rd Generation Partnership Project;Technical Specification GroupRadio Access Network;Evolved Universal Terrestrial Radio Access Network(E-UTRAN);X2application protocol(X2AP)(第11版)
[24]3GPP TS36420,3rd Generation Partnership Project;Technical Specification GroupRadio Access Network;Evolved Universal Terrestrial Radio Access Network(E-UTRAN);X2general aspects and principles(第11版)