用户设备、基站、流媒体自适应传输系统和方法
【专利摘要】本发明涉及通信【技术领域】，公开了一种流媒体自适应传输方法，包括：用户设备实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率；所述用户设备将速率保障请求发送至基站，所述速率保障请求包括所述传输速率；所述用户设备接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的待传输数据。还公开了一种用户设备、基站及流媒体自适应传输系统。本发明实施例中通过用户设备与基站的实时协商，由基站确保用户设备所需要的传输速率指标，用户设备根据协商的速率指标请求相应的内容，从而保证了在无线环境下流媒体服务的用户体验。
【专利说明】用户设备、基站、流媒体自适应传输系统和方法
【技术领域】
[0001]本发明涉及计算机及通信【技术领域】，尤其涉及一种用户设备、基站、流媒体自适应传输系统和方法。
【背景技术】
[0002]无线通信在全球得到了广泛地应用，极大地方便了人们之间的沟通。无线通信可以提供各种服务，包括语音通话和网页下载等等。典型的无线通信系统或网络，如:长期演进(long term evolut1n, LTE)系统通过基站在一个蜂窝小区内为多个用户设备(userequipment, UE)提供无线链路实现无线通信，这种无线连接通常是使用共享的无线频谱。
[0003]随着互联网的发展，新业务不断涌现，但很多业务在无线网络上的性能还不能满足人们的需求。移动流媒体业务分为在线播放和下载播放，在线播放同时还支持直播和点播。在线播放与下载播放相比，可以大大缩短启动延时，避免了用户必须等待整个文件全部从服务器上下载完成后才能观看的缺点。在移动流媒体在线播放的过程中，理想的情况是传输带宽保持比传输的媒体内容编码带宽略大。然而媒体内容编码本身的速率可能是变化的，比如:动态比特率(variable bit rate, VBR)视频或音频；同时无线网络由于无线频谱共享的问题，使得每个用户所需要的无线资源并不总是能得到保障；此外，用户与基站通信的无线信道又存在衰变的特点，导致无线通信速率的波动，这进一步影响了流媒体传输的稳定性，导致用户接收终端在播放过程中出现停顿或马赛克现象，影响用户的媒体播放感受。无线视频通话也会出现同样的问题。
[0004]基于超文本传输协议的动态自适应流媒体(dynamic adaptive streaming overHTTP，DASH)被用于在互联网上提供流媒体在线直播和点播的良好体验。DASH在超文本传输协议(hypertest transfer protocol,HTTP)上传输高速视频、音频数据。HTTP在互联网上已经得到很好的支持，且很容易穿透防火墙，这降低了 DASH的实现成本。客户端基于HTTP协议自适应地从服务器请求内容也极大地减轻了服务器的压力，使得服务器不需要存储大量用户的状态，这可以有效增加服务器服务用户的数量。DASH典型应用如图1所示。在服务器上存储有媒体表示描述(media presentat1n descript1n, MPD)文件和媒体片断文件。MH)文件中包含有媒体片断文件的相关信息，如:媒体片断文件的时间长度、文件大小、播放起始时刻、文件存放的网址、媒体类型、分辨率等。而媒体片断文件则存放流媒体播放的实际数据，可以存在一个或多个文件中，一般采用多个文件的方式，在一个文件中存放的是一个片断，比如2秒钟的媒体内容。为了适应不同的网络带宽情况，同样的媒体内容会以不同的编码速率存放在不同文件中，比如针对5Mbps，2Mbps，500Kbps的传输速率，可以准备三个不同的文件，平均编码速率分别为4.8Mbps, 1.7Mbps，490Kbps，存放在服务器上，传输速率必须高于媒体文件的编码速率，才能使媒体文件在线流畅的播放。
[0005]当用户希望接受DASH服务时，首先终端需要从服务器上获取MPD文件，文件获取可以通过多种方式，比如通过广播方式，或通过HTTP请求直接从服务器上获取。终端获得MPD文件后，就知道了服务器上的媒体片断文件的信息，比如媒体片断文件的类型，存放在什么地方，每个片断有多长，文件大小是多少等等。终端可以同时测量从服务器到终端的整个网络的传输带宽，确定需要从服务器申请多大传输速率的媒体片断文件，例如当终端测定网络传输带宽大于5Mbps时，终端就可以向服务器申请针对5Mbps传输速率的媒体片断(即平均编码速率小于且更接近于5Mbps的媒体文件);如果网络传输带宽只有3Mbps时，则终端只向服务器申请针对2Mbps传输速率的媒体片断文件，而不会申请针对5Mbps的文件，以避免造成网络传输的拥塞，影响用户的体验。
[0006]上述方法在有线环境应用可以将自适应处理的压力放在终端上，从而减轻服务器的负担，增大服务器同时服务用户的数量。但当该方法应用于无线环境时，或当整个传输过程中至少部分包含无线传输时，由于前述无线问题的存在，导致终端测量得到的传输速率并不能在无线网络中得到保障，因此其性能会产生明显恶化。
[0007]目前已有一些方案实现了在无线环境下在线播放移动流媒体，其中，现有的一种在UE (user equipment,用户设备)上配置最低速率的方法,如图2所示。UE根据网络提供的选项选择GBR(guaranteed bit rate,保证比特率),并通过请求消息发给网络确认,在确认后就可根据商定的GBR进行通信。但该方案中以用户输入的方式进行GBR的选择，对应图2中的第二个步骤:选择特定的比特速率。除了这一方法之外，在该方案中，没有公开其它如何选择速率的方法，以保证移动流媒体业务的体验。结合无线环境的客观条件变化，如:信道衰变等，加上媒体文件本身的大小的变化，即媒体编码压缩率的变化，如=VBR视频，通过用户进行选择，显然不能支持传输速率的实时自适应调整。
[0008]现有的一种传输流媒体的方法通过接收方至少获取传输的最大比特速率或最大业务数据单元(service data unit)大小,从而达到预留网络资源的目的。在该方法中，当用户选择一个多媒体进行观看时，无线用户设备发送请求给无线网络，该请求被送至流媒体服务器。流媒体服务器检查请求内容，并获取相关信息，其中至少应包含最大比特速率。该信息然后从流媒体服务器传送到无线网络和无线用户设备。无线用户设备发送至少包含最大比特速率的请求给无线网络，并由无线网络选择承载服务(bearer service)，无线网络选择的传输参数可能比请求的速率低。无线网络的选择结果将被传回无线用户设备，并建立连接，进行通信。该方案与DASH方法不同，这一方法需要服务器获取最大比特速率的信息，而且需要把该信息传回无线网络及无线用户设备。对比DASH方法中完全由终端确定速率，并直接请求相关内容的做法，该方法将增大服务器的负担。其次，通过最大比特速率预留资源的做法是传统CS (circuit switched，电路连接)通信的方法，这种方法会导致资源的浪费，因为预留的资源不能被分配给其他用户使用。如前所述，在无线通信中，宝贵的无线频谱资源是以共享的方式同时为多个用户服务，针对媒体编码压缩率不同的情况，尤其是当提供VBR视频服务时，这种根据最大比特速率预留资源的方式极大地浪费了无线频谱资源。最后，在DASH方法中，MPD文件被传送给无线用户设备进行分析，分析结果不必发送给无线网络。因此无线网络并不知道用户媒体业务的真实需求，由无线网络选择的承载服务可能并不能满足用户的体验需求，但在上述方法中，无线用户设备并没有针对这种情况执行相应补救措施。
【发明内容】
[0009]本发明实施例提供的用户设备、基站、流媒体自适应传输系统和方法，以解决现有技术中在无线环境中传输流媒体时无法保障传输速率的问题。
[0010]为了解决上述技术问题，本发明实施例公开了如下技术方案:
[0011]第一方面，提供一种流媒体自适应传输方法，包括:
[0012]用户设备实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率；
[0013]所述用户设备将速率保障请求发送至基站，所述速率保障请求包括所述传输速率；
[0014]所述用户设备接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的待传输数据。。
[0015]在第一方面的第一种可能的实现方式中，所述用户设备实时确定待传输数据的传输速率具体包括:
[0016]实时监测用户设备中缓存占用大小；
[0017]从所述数据发送端获取媒体表示描述MPD文件；
[0018]根据所述缓存占用大小、MPD文件中的待传输媒体文件的大小及未来预定时间段计算平均传输速率，并以所述平均传输速率作为未来预定时间段内的所述传输速率。
[0019]在第一方面的第二种可能的实现方式中，所述用户设备实时确定待传输数据的传输速率具体包括:
[0020]所述用户设备与所述数据发送端实时协商确定所述数据发送端的上行传输速率，将所述用户设备能保障的下行传输速率发送至数据发送端，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率。
[0021]在第一方面的第三种可能的实现方式中，所述速率保障请求中还包括:所述用户设备向基站请求的一个或多个大于所述传输速率的速率。
[0022]在第一方面的第四种可能的实现方式中，所述用户设备将速率保障请求发送至基站的同时还向基站请求包括:丢包率、误码率及最大时延至少之一的服务质量指标。
[0023]在第一方面的第五种可能的实现方式中，所述根据基站提供的包括传输速率选项的协商请求确定传输速率具体包括:在所述传输速率选项中的速率均不满足所述数据发送端要求的最低传输速率时停止传输；或以所述传输速率选项中大于等于所述最低传输速率的速率为传输速率。
[0024]第二方面，提供一种流媒体自适应传输方法，包括:
[0025]基站接收用户设备发送的包括传输速率的速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认是否能够保障所述传输速率，若能，则向所述用户设备发送确认所述传输速率可用的消息，否则，向所述用户设备发送包括所述基站能够保障的传输速率选项的协商请求。
[0026]在第二方面的第一种可能的实现方式中，在确认所述用户设备请求的传输速率后还包括:配置包括丢包率、误码率及最大时延至少之一的服务质量指标。
[0027]在第二方面的第二种可能的实现方式中，还包括:所述基站根据用户设备实时上报的传输信道情况，向所述用户设备发送包括基站当前能够保障的传输速率选项的协商请求。
[0028]第三方面，提供一种用户设备，包括:
[0029]自适应调节单元，用于实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率；
[0030]请求单元，用于将速率保障请求发送至基站，所述速率保障请求包括所述传输速率；
[0031]数据请求单元，用于接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的所述待传输数据。
[0032]在第三方面的第一种可能的实现方式中，所述自适应调节单元具体包括:
[0033]缓存监测单元，用于在实时确定待传输数据的传输速率时监测所述用户设备中缓存占用大小；
[0034]Mro文件获取单元，用于从所述数据发送端获取所述待传输数据的媒体表示描述MPD文件；
[0035]传输速率计算单元，用于根据所述缓存占用大小、Mro文件中的待传输媒体文件的大小及未来预定时间段计算平均传输速率，并以所述平均传输速率作为未来预定时间段内的所述传输速率。
[0036]在第三方面的第二种可能的实现方式中，所述自适应调节单元具体包括:
[0037]速率协商单元，用于在实时确定待传输数据的传输速率时与所述数据发送端实时协商确定所述数据发送端的上行传输速率，将所述用户设备能保障的下行传输速率发送至数据发送端，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率。
[0038]在第三方面的第三种可能的实现方式中，所述速率保障请求中还包括:所述用户设备向基站请求的一个或多个大于所述传输速率的速率。
[0039]在第三方面的第四种可能的实现方式中，所述请求单元还用于在将速率保障请求发送至基站的同时还向基站请求包括:丢包率、误码率及最大时延至少之一的服务质量指标。
[0040]在第三方面的第五种可能的实现方式中，所述自适应调节单元还包括:
[0041]速率选择单元，用于在所述基站提供的包括传输速率选项的协商请求中的传输速率选项的速率均不满足所述数据发送端要求的最低传输速率时触发所述连接传输单元停止传输；或以所述传输速率选项中大于等于所述最低传输速率的速率为传输速率。
[0042]第四方面，提供一种基站，其特征在于，包括步骤:
[0043]速率确认单元，用于接收用户设备发送的包括传输速率的速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认是否能够保障所述传输速率，若能，则向所述用户设备发送确认所述传输速率可用的消息，否则，向所述用户设备发送包括所述基站能够保障的传输速率选项的协商请求。
[0044]在第四方面的第一种可能的实现方式中，所述速率确认单元还用于在确认所述用户设备请求的传输速率后配置包括丢包率、误码率及最大时延至少之一的服务质量指标。
[0045]在第四方面的第二种可能的实现方式中，还包括:
[0046]速率调节单元，用于根据用户设备实时上报的传输信道情况，向所述用户设备发送包括基站当前能够保障的传输速率选项的协商请求。
[0047]第五方面，提供一种流媒体自适应传输系统，包括:数据发送端设备、用户设备及基站，所述用户设备和数据发送端设备均连接所述基站；
[0048]所述用户设备实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率，并将包括所述传输速率的速率保障请求发送至基站，在接收到所述基站回复的确认所述传输速率可用的消息后，向所述数据发送端设备请求与所述传输速率相应编码速率的所述待传输数据；
[0049]所述基站接收所述速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认能够保障所述速率保障请求时将确认所述传输速率可用的消息发送至所述用户设备；或根据当前传输信道条件和基站自身能提供的频谱资源确认不能够保障所述速率保障请求时将包括传输速率选项的协商请求发送至所述用户设备；
[0050]所述数据发送端设备接收所述用户设备发送的请求，并向所述用户设备传输与所述传输速率相应编码速率的所述待传输数据。
[0051]本发明实施例中，通过用户设备与基站的实时协商，由基站确保用户设备所需要的传输速率指标，用户设备根据协商的速率指标请求相应的内容，从而保证了在无线环境下服务的用户体验，即在播放流畅的情况下，保证画面相对清晰。
【专利附图】
【附图说明】
[0052]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0053]图1是现有的DASH系统示意；
[0054]图2是现有技术中的配置最低速率方法流程图；
[0055]图3是本发明实施例的一种流媒体自适应传输方法流程图；
[0056]图4是本发明实施例的一种流媒体自适应传输方法中用户设备自适应播放流媒体的流程图；
[0057]图5是本发明实施例的一种流媒体自适应传输方法中基站保障自适应流媒体播放品质的流程图；
[0058]图6是本发明实施例中UE自适应视频通话过程。
[0059]图7是本发明实施例的一种用户设备结构示意图；
[0060]图8是本发明实施例的一种基站结构示意图；
[0061]图9是本发明实施例的一种流媒体自适应传输系统结构不意图；
【具体实施方式】
[0062]为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0063]与有线网络中传输流媒体数据不同，在无线蜂窝通信中，基站需要对共享的无线频谱资源在多个用户之间的分配进行调度，因此，用户设备UE请求的传输速率保障是否能得到支持，需要由基站确认。
[0064]如图3所示，本发明第一实施例中提供的流媒体自适应传输方法，包括:
[0065]步骤S310，用户设备(UE)实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率。
[0066]对于用户设备向流媒体服务器请求流媒体的场景，用户设备实时确定待传输数据的传输速率具体包括:
[0067]实时监测用户设备中缓存占用大小；
[0068]从所述数据发送端获取媒体表示描述MPD文件；
[0069]根据所述缓存占用大小、MPD文件中的待传输媒体文件的大小及未来预定时间段计算平均传输速率，并以所述平均传输速率作为未来预定时间段内的传输速率。
[0070]所述平均传输速率的计算方式为:根据MPD文件中的待传输媒体文件大小减去所述缓存占用大小，再除以所述预定时间段的方式计算所述平均传输速率。
[0071]在MPD文件中包含有媒体片断的大小信息，UE知道自己缓存中已经存储了多少内容，利用未来一段时间，如2秒内的媒体片断的大小，减去已经存储在缓存中的内容的大小，除以2秒钟，则计算出未来所需要的平均传输速率。为了使传输更加流畅，无线系统实际保障的传输速率应该比这个数值略高。
[0072]对于视频通话的场景，确定待传输数据的传输速率的方式为:所述用户设备与所述数据发送端实时协商确定所述数据发送端的上行传输速率，将所述用户设备(视频及音频数据接收端)能保障的下行传输速率发送至数据发送端，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率，假设为Vmin,即数据发送端的上行传输速率和用户设备的下行传输速率都确定为Vmin。在视频通话场景下，数据发送端通常是对端UE(视频及音频数据发送端)
[0073]在上述两种场景中，基站可能无法满足用户设备请求的速率保障，此时基站会向用户设备发送包括传输速率选项的协商请求。所述根据基站提供的包括传输速率选项的协商请求确定传输速率具体包括:在所述传输速率选项中的速率均不满足所述数据发送端要求的最低传输速率时停止传输；或以所述传输速率选项中大于等于所述最低传输速率的速率为传输速率。
[0074]步骤S320，所述用户设备将速率保障请求发送至基站，所述速率保障请求包括所述传输速率。用户设备还可以向基站请求一个或多个大于所述传输速率的速率。例如:针对平均编码速率为4.8Mbps, 1.7Mbps, 490Kbps的情况，UE可以向基站申请4.8Mbps, 1.7Mbps,490Kbps三种GBR速率的保障的传输速率，或要求更高的传输速率，即:5Mbps，2Mbps，500Kbps的传输速率，也可以只向基站申请前两个较高速率的请求，即5Mbps和2Mbps。基站根据实际情况，可以从中选择合适的数值，比如:2Mbps的速率，与UE进行确认，如果UE同意，则最终协商确定的传输速率就是2Mbps。
[0075]进一步地，为了保障传输质量，同时还向基站申请包括丢包率、误码率及最大时延至少之一的服务质量(Quality of Service, QoS)指标。
[0076]步骤S330，所述用户设备接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的待传输数据。对于在线播放流媒体的场景，UE与流媒体服务器建立连接后，按该传输速率请求相应编码速率的流媒体数据。例如，当基站与UE协商确认2Mbps的GBR速率后，UE需要从流媒体服务器申请所对应的媒体片断文件，即1.7Mbps的媒体片断文件,这样才能在保证流畅播放的前提下,尽可能使流媒体播放的画面保持最清晰，用户体验也最好。对于视频通话的场景UE与对端UE建立连接后，按该传输速率接收对端UE的视、音频数据。
[0077]以用户设备自适应播放流媒体为例说明如下:本实施例的方法具体流程如图4所
/Jn ο
[0078]UE可以向基站申请全部的GBR速率请求，即5Mbps，2Mbps，500Kbps的传输速率，也可以只向基站申请前两个较高速率的请求，即5Mbps，2Mbps。在请求GBR时也可以申请其它QoS指标，比如丢包率，误码率，最大时延等。这种请求可以通过高层信令的方式发送给基站，也可以用其它消息的方式发给基站。基站收到UE的一个或多个GBR请求后，确认是否可以为UE提供其中的一种速率的保障。如果可以，则基站确认UE的请求，并开始配置相应的QoS参数；如果基站不能为UE提供其中任何一种GBR的保障，则基站通知UE需要重新协商GBR参数，并提供一个或多个可选择的速率。
[0079]UE收到基站重新协商QoS的消息或信令后，根据基站提供的选择项，结合MPD文件中提供的媒体片断文件信息，确定是否可以在基站提供的速率范围内继续请求流媒体业务。如果基站提供的GBR保障小于服务器上的最低媒体速率的要求，例如基站只能提供GBR=400Kbps,小于服务器上最低媒体编码速率490Kbps的传输速率要求，则UE可以选择停止业务，或选择没有服务品质保障的流媒体业务。如果基站提供的GBR保障小于UE申请的最小GBR请求，但仍然能保障最低速率的体验，例如在UE只申请了 5Mbps和2Mbps的速率请求的情况下，基站回复只能提供800Kbps的速率保障，则UE可以考虑降低服务品质要求，重新向基站申请500Kbps的GBR保障，并在基站确认之后，开始向服务器请求490Kbps编码速率所对应的媒体片断文件。
[0080]在UE接收数据过程中，基站可能因为信道条件变化等原因，导致实际为UE提供的平均传输速率高于GBR的数值，由此造成UE缓存数据的累积。当UE缓存数据累积到足够大时，UE可以结合MPD文件中提供的媒体片断文件大小的信息，决定是否可以与基站重新协商新的GBR的大小，以减轻基站的压力，并降低业务收费。同时，基站也需要根据用户信道条件的变化，考量是否能够维持已经协商的GBR的品质保障。如果因为用户信道条件变差，而导致基站不能维持GBR的保障，则基站可以向UE发送变更GBR的请求。当UE收到基站的GBR变更请求后，UE需要检查新的GBR是否能保障流媒体业务的要求，如果新GBR过低，则UE需要考虑是否中止业务。
[0081]在UE接收数据过程中，数据从服务器传输到UE时，也可能因为有线网络出现拥塞而导致实际接收速率下降。此时，UE也需要与基站重新协商新的GBR数值，以避免无线频谱资源的浪费，并降低业务收费。
[0082]本实施例中通过用户设备与基站的实时协商，由基站确保用户设备所需要的传输速率指标，用户设备根据协商的速率指标请求相应的内容，从而保证了在无线环境下服务的用户体验，即在播放流畅的情况下，保证画面相对清晰。
[0083]本发明第二实施例中提供的流媒体自适应传输方法，包括:基站接收用户设备发送的包括传输速率的速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认是否能够保障所述传输速率，若能，则向所述用户设备发送确认所述传输速率可用的消息，否则，向所述用户设备发送包括所述基站能够保障的传输速率选项的协商请求。
[0084]为了保证传输质量，在确认所述用户设备请求的传输速率后还包括:配置包括丢包率、误码率及最大时延至少之一的服务质量指标。
[0085]进一步地，在传输数据的过程中，由于基站自身或信道原因(比如:基站可用资源少，用户信道差等)无法保障用户设备请求的传输速率，因此基站还根据用户设备实时上报的传输信道情况，向所述用户设备发送包括基站当前能够保障的传输速率选项的协商请求。
[0086]同样以用户设备自适应播放流媒体为例说明如下:本实施例的方法中基站保障自适应流媒体播放品质的流程如图5所示。
[0087]基站需要确认UE申请的业务为流媒体播放业务。在确定为流媒体业务之后，由于UE可以从服务器获取MPD文件并选择相应的下载速率，因此基站需要等待UE主动申请GBR的需求。在UE发送GBR请求后，基站根据自己的资源管理方法确定能否满足UE的其中一个GBR请求。如果UE请求的GBR配置都不合适，则基站选择一些比较接近UE请求的速率，并发送给UE供其挑选。如果UE请求的GBR配置至少有一个可以保障，则基站向UE发送确认信息，通知UE可以按照该GBR配置建立连接，进行通信。在与UE完成GBR的确认后，基站完成相应的配置，并提供对应的数据下行通信服务。
[0088]在UE接收数据服务的过程中，UE可能根据需要重新协商GBR参数。同时，用户在移动过程中，可能因为信道条件变差，而使得原先能够得到保障的GBR速率不再能得到满足。这时，基站也需要向UE发起GBR重新协商的过程。
[0089]上述流媒体自适应传输方法也适用于视频通话的场景。其流程如图6所示。
[0090]在视频通话过程中，数据发送端通常是对端的UE，本端UE (即视频及语音数据接收端)的GBR需求改为通过与对端UE (即视频及语音数据发送端)协商确定。本端UE与对端UE实时协商确定该对端UE的上行传输速率，将本端UE能保障的下行传输速率发送至对端UE，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率，假设为Vmin,即对端UE的上行传输速率和本端UE的下行传输速率都确定为Vniint5速率协商完成后，其它过程基本同于UE自适应流媒体播放的过程。
[0091]本发明通过用户设备与基站的实时协商，由基站确保用户设备所需要的传输速率指标，用户设备根据协商的速率指标请求相应的内容，从而保证了在无线环境下服务的用户体验，即在播放流畅的情况下，保证画面相对清晰。
[0092]如图7所示，本发明第三实施例中提供的用户设备包括:自适应调节单元710、请求单元720及连接传输单元730。
[0093]自适应调节单元710用于实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率。本实施例中，自适应调节单元710包括:
[0094]缓存监测单元，用于在实时确定待传输数据的传输速率时监测所述用户设备中缓存占用大小。
[0095]MPD文件获取单元，用于在从数据发送端获取媒体表示描述MPD文件。数据发送端通常是提供在线播放的媒体数据的流媒体服务器。
[0096]传输速率计算单元，用于根据所述缓存占用大小、Mro文件中的待传输媒体文件的大小及未来预定时间段计算平均传输速率，并以所述平均传输速率作为未来预定时间段内的传输速率。具体计算方式为:根据Mro文件中的待传输媒体文件大小减去所述缓存占用大小，再除以所述预定时间段的方式计算所述平均传输速率。
[0097]在MPD文件中包含有媒体片断的大小信息，UE知道自己缓存中已经存储了多少内容，利用未来一段时间，如2秒内的媒体片断的大小，减去已经存储在缓存中的内容的大小，除以2秒钟，则计算出未来所需要的平均传输速率。为了使传输更加流畅，无线系统实际保障的传输速率应该比这个数值略高。
[0098]为了用于视频通话，自适应调节单元710还包括速率协商单元，用于与所述数据发送端实时协商确定所述数据发送端的上行传输速率,将本端UE (视频及音频数据接收端)能保障的下行传输速率发送至数据发送端，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率，假设为Vmin,即数据发送端的上行传输速率和用户设备的下行传输速率都确定为Vmin。在视频通话场景下，数据发送端通常是对端UE(视频及音频数据发送端)。
[0099]请求单元720用于将速率保障请求发送至基站，所述速率保障请求包括所述传输速率。具体地，速率保障请求中还可以包括向基站申请一个或多个大于所述传输速率的速率。例如:针对平均编码速率为4.8Mbps，1.7Mbps，490Kbps的情况，UE可以向基站申请4.8Mbps，1.7Mbps, 490Kbps三种GBR速率的保障的传输速率，或要求更高的传输速率，即:5Mbps, 2Mbps, 500Kbps的传输速率，也可以只向基站申请前两个较高速率的请求，即5Mbps和2Mbps。基站根据实际情况，可以从中选择合适的数值，比如:2Mbps的速率，与UE进行确认，如果UE同意，则最终协商确定的传输速率就是2Mbps。
[0100]进一步地，为了保证传输质量，还向基站请求包括丢包率、误码率及最大时延至少之一的服务质量(Quality of Service, QoS)指标。这些请求的指标可以以单独的请求发送，也可以包含在速率保障请求中发送至基站。
[0101]连接传输单元730用于接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的所述待传输数据。对于在线播放流媒体的场景，UE与流媒体服务器建立连接后，按该传输速率请求相应编码速率的流媒体数据。例如，当基站与UE协商确认2Mbps的GBR速率后，UE需要从流媒体服务器申请所对应的媒体片断文件，即1.7Mbps的媒体片断文件,这样才能在保证流畅播放的前提下,尽可能使流媒体播放的画面保持最清晰，用户体验也最好。对于视频通话的场景UE与对端UE建立连接后，按该传输速率接收对端UE的视、音频数据。
[0102]由于基站自身或信道原因(比如:基站可用资源少，用户信道差等等)无法保障用户设备请求的传输速率，此时基站会向用户设备发送包括可保障的传输速率选项。因此，自适应调节单元710还包括:速率选择单元，用于在所述基站提供的包括传输速率选项的协商请求中的传输速率选项的速率均不满足所述数据发送端要求的最低传输速率时触发所述连接传输单元停止传输；或以所述传输速率选项中大于等于所述最低传输速率的速率为传输速率。UE收到基站重新协商QoS的消息或信令后，根据基站提供的选择项，结合MPD文件中提供的媒体片断文件信息，确定是否可以在基站提供的速率范围内继续请求流媒体业务。如果基站提供的GBR保障小于服务器上的最低媒体速率的要求，例如基站只能提供GBR=400Kbps,小于服务器上最低媒体编码速率490Kbps的传输速率要求，则UE可以选择停止业务，或选择没有服务品质保障的流媒体业务。如果基站提供的GBR保障小于UE申请的最小GBR请求，但仍然能保障最低速率的体验，例如在UE只申请了 5Mbps和2Mbps的速率请求的情况下，基站回复只能提供800Kbps的速率保障，则UE可以考虑降低服务品质要求，重新向基站申请500Kbps的GBR保障，并在基站确认之后，开始向服务器请求编码速率为490Kbps的媒体片断文件。
[0103]在用户设备接收流媒体数据过程中，数据传输速率的要求会随时发生变化，在UE接收数据过程中，基站可能因为信道条件变化等原因，导致实际为UE提供的平均传输速率高于GBR的数值，由此造成UE缓存数据的累积。当UE缓存数据累积到足够大时，UE可以结合MPD文件中提供的媒体片断文件大小的信息，决定是否可以与基站重新协商新的GBR的大小，以减轻基站的压力，并降低业务收费。此时，自适应调节单元710的缓存监测单元通过实时监测用户设备缓存的变化，计算单元根据缓存大小按上述计算方式重新计算并确定所述传输速率。
[0104]如图8所示，本发明第四实施例中提供的基站包括:速率确认单元810，用于接收UE发送的包括传输速率的速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认是否能够保障请求的速率，若能，则向所述UE发送确认消息，否则，向所述UE发送包括所述基站能够保障的传输速率选项的协商请求。
[0105]对于在线播放流媒体数据的场景，基站需要确认UE申请的业务为流媒体播放业务。在确定为流媒体业务之后，由于UE可以从服务器获取MPD文件并选择相应的下载速率，因此基站需要等待UE主动申请GBR的需求。在UE发送一个或多个GBR请求后，基站根据自己的资源管理方法确定能否满足UE的其中一个GBR请求。如果UE请求的GBR配置都不合适，则基站选择一些比较接近UE请求的速率，并发送给UE供其挑选。如果UE请求的GBR配置至少有一个可以保障，则基站向UE发送确认信息，通知UE可以按照该GBR配置建立连接，进行通信。在与UE完成GBR的确认后，基站完成相应的配置，并提供对应的数据下行通信服务。
[0106]为了保证传输质量，速率确认单元810还用于在确认UE请求的传输速率后配置包括丢包率、误码率和/或最大时延的QoS指标。
[0107]进一步地，由于基站自身或信道原因(比如:基站可用资源少，用户信道差等等)无法保障用户设备请求的传输速率，因此基站还包括:速率调节单元820，用于根据用户设备实时上报的传输信道情况，向所述用户设备发送包括基站当前能够保障的传输速率选项的协商请求。在传输过程中，基站也需要根据用户信道条件的变化，考量是否能够维持已经协商的传输速率的品质保障。如果因为用户信道条件变差，而导致基站不能维持传输速率的保障，则速率调节单元820可以向UE发送变更传输速率的请求。当UE收到基站的传输速率变更请求后，UE需要检查新的传输速率是否能保障流媒体业务的要求，若能保障，则重新向基站请求新的传输速率；若新传输速率过低，则UE需要考虑是否中止业务。
[0108]如图9所示，本发明第五实施例中提供的流媒体自适应传输系统包括:用户设备910、基站920和数据发送端设备930。用户设备910实时确定待传输数据的传输速率或根据基站920提供的包括传输速率选项的协商请求确定传输速率，并将包括传输速率的速率保障请求发送至基站920，在接收到基站920回复的确认传输速率可用的消息后，向数据发送端设备930请求与传输速率相应编码速率的待传输数据；
[0109]基站920接收速率保障请求，并根据当前传输信道条件和基站920自身能提供的频谱资源确认能够保障速率保障请求时将确认传输速率可用的消息发送至用户设备910 ；或根据当前传输信道条件和基站920自身能提供的频谱资源确认不能够保障速率保障请求时将包括传输速率选项的协商请求发送至用户设备910 ；
[0110]数据发送端设备930接收用户设备910发送的请求，并向用户设备910传输与传输速率相应编码速率的待传输数据。
[0111]本领域普通技术人员将会理解，本发明的各个方面、或各个方面的可能实现方式可以被具体实施为系统、方法或者计算机程序产品。因此，本发明的各方面、或各个方面的可能实现方式可以采用完全硬件实施例、完全软件实施例(包括固件、驻留软件等等)，或者组合软件和硬件方面的实施例的形式，在这里都统称为“电路”、“模块”或者“系统”。此夕卜，本发明的各方面、或各个方面的可能实现方式可以采用计算机程序产品的形式，计算机程序产品是指存储在计算机可读介质中的计算机可读程序代码。
[0112]计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质包含但不限于电子、磁性、光学、电磁、红外或半导体系统、设备或者装置，或者前述的任意适当组合，如随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或者快闪存储器)、光纤、便携式只读存储器(CD-ROM)。
[0113]计算机中的处理器读取存储在计算机可读介质中的计算机可读程序代码，使得处理器能够执行在流程图中每个步骤、或各步骤的组合中规定的功能动作；生成实施在框图的每一块、或各块的组合中规定的功能动作的装置。
[0114]计算机可读程序代码可以完全在用户的计算机上执行、部分在用户的计算机上执行、作为单独的软件包、部分在用户的计算机上并且部分在远程计算机上，或者完全在远程计算机或者服务器上执行。也应该注意，在某些替代实施方案中，在流程图中各步骤、或框图中各块所注明的功能可能不按图中注明的顺序发生。例如，依赖于所涉及的功能，接连示出的两个步骤、或两个块实际上可能被大致同时执行，或者这些块有时候可能被以相反顺序执行。
[0115]显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
【权利要求】
1.一种流媒体自适应传输方法，其特征在于，包括步骤: 用户设备实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率； 所述用户设备将速率保障请求发送至基站，所述速率保障请求包括所述传输速率； 所述用户设备接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的待传输数据。
2.如权利要求1所述的流媒体自适应传输方法，其特征在于，所述用户设备实时确定待传输数据的传输速率具体包括: 实时监测用户设备中缓存占用大小； 从所述数据发送端获取媒体表示描述MPD文件； 根据所述缓存占用大小、MPD文件中的待传输媒体文件的大小及未来预定时间段计算平均传输速率，并以所述平均传输速率作为未来预定时间段内的所述传输速率。
3.如权利要求1所述的流媒体自适应传输方法，其特征在于，所述用户设备实时确定待传输数据的传输速率具体包括: 所述用户设备与所述数据发送端实时协商确定所述数据发送端的上行传输速率，将所述用户设备能保障的下行传输速率发送至数据发送端，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率。
4.如权利要求1?3中任一项所述的流媒体自适应传输方法，其特征在于，所述速率保障请求中还包括:所述用户设备向基站请求的一个或多个大于所述传输速率的速率。
5.如权利要求1?3中任一项所述的流媒体自适应传输方法，其特征在于，所述用户设备将速率保障请求发送至基站的同时还向基站请求包括:丢包率、误码率及最大时延至少之一的服务质量指标。
6.如权利要求1?3中任一项所述的流媒体自适应传输方法，其特征在于，所述根据基站提供的包括传输速率选项的协商请求确定传输速率具体包括:在所述传输速率选项中的速率均不满足所述数据发送端要求的最低传输速率时停止传输；或以所述传输速率选项中大于等于所述最低传输速率的速率为传输速率。
7.一种流媒体自适应传输方法，其特征在于，包括步骤: 基站接收用户设备发送的包括传输速率的速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认是否能够保障所述传输速率，若能，则向所述用户设备发送确认所述传输速率可用的消息，否则，向所述用户设备发送包括所述基站能够保障的传输速率选项的协商请求。
8.如权利要求7所述的流媒体自适应传输方法，其特征在于，在确认所述用户设备请求的传输速率后还包括:配置包括丢包率、误码率及最大时延至少之一的服务质量指标。
9.如权利要求7所述的流媒体自适应传输方法，其特征在于，还包括:所述基站根据用户设备实时上报的传输信道情况，向所述用户设备发送包括基站当前能够保障的传输速率选项的协商请求。
10.一种用户设备，其特征在于，包括: 自适应调节单元，用于实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率； 请求单元，用于将速率保障请求发送至基站，所述速率保障请求包括所述传输速率；数据请求单元，用于接收到基站回复的确认所述传输速率可用的消息后，向数据发送端请求与所述传输速率相应编码速率的所述待传输数据。
11.如权利要求10所述的用户设备，其特征在于，所述自适应调节单元具体包括: 缓存监测单元，用于在实时确定待传输数据的传输速率时监测所述用户设备中缓存占用大小； MPD文件获取单元，用于从所述数据发送端获取所述待传输数据的媒体表示描述MPD文件； 传输速率计算单元，用于根据所述缓存占用大小、MPD文件中的待传输媒体文件的大小及未来预定时间段计算平均传输速率，并以所述平均传输速率作为未来预定时间段内的所述传输速率。
12.如权利要求10所述的用户设备，其特征在于，所述自适应调节单元具体包括: 速率协商单元，用于在实时确定待传输数据的传输速率时与所述数据发送端实时协商确定所述数据发送端的上行传输速率，将所述用户设备能保障的下行传输速率发送至数据发送端，并选择上行传输速率和下行传输速率较小的速率作为最终确定的传输速率。
13.如权利要求10?12中任一项所述的用户设备，其特征在于，所述速率保障请求中还包括:所述用户设备向基站请求的一个或多个大于所述传输速率的速率。
14.如权利要求10?12中任一项所述的用户设备，其特征在于，所述请求单元还用于在将速率保障请求发送至基站的同时还向基站请求包括:丢包率、误码率及最大时延至少之一的服务质量指标。
15.如权利要求10?12中任一项所述的用户设备，其特征在于，所述自适应调节单元还包括: 速率选择单元，用于在所述基站提供的包括传输速率选项的协商请求中的传输速率选项的速率均不满足所述数据发送端要求的最低传输速率时触发所述连接传输单元停止传输；或以所述传输速率选项中大于等于所述最低传输速率的速率为传输速率。
16.—种基站,其特征在于,包括: 速率确认单元，用于接收用户设备发送的包括传输速率的速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认是否能够保障所述传输速率，若能，则向所述用户设备发送确认所述传输速率可用的消息，否则，向所述用户设备发送包括所述基站能够保障的传输速率选项的协商请求。
17.如权利要求16所述的基站，其特征在于，所述速率确认单元还用于在确认所述用户设备请求的传输速率后配置包括丢包率、误码率及最大时延至少之一的服务质量指标。
18.如权利要求16所述的基站，其特征在于，还包括: 速率调节单元，用于根据用户设备实时上报的传输信道情况，向所述用户设备发送包括基站当前能够保障的传输速率选项的协商请求。
19.一种流媒体自适应传输系统，其特征在于，包括:数据发送端设备、用户设备及基站，所述用户设备和数据发送端设备均连接所述基站；所述用户设备实时确定待传输数据的传输速率或根据基站提供的包括传输速率选项的协商请求确定所述传输速率，并将包括所述传输速率的速率保障请求发送至基站，在接收到所述基站回复的确认所述传输速率可用的消息后，向所述数据发送端设备请求与所述传输速率相应编码速率的所述待传输数据； 所述基站接收所述速率保障请求，并根据当前传输信道条件和基站自身能提供的频谱资源确认能够保障所述速率保障请求时将确认所述传输速率可用的消息发送至所述用户设备；或根据当前传输信道条件和基站自身能提供的频谱资源确认不能够保障所述速率保障请求时将包括传输速率选项的协商请求发送至所述用户设备； 所述数据发送端设备接收所述用户设备发送的请求，并向所述用户设备传输与所述传输速率相应编码速率的所述待传输数据。
【文档编号】H04W28/22GK104254109SQ201310256579
【公开日】2014年12月31日 申请日期:2013年6月25日 优先权日:2013年6月25日
【发明者】周雷 申请人:华为技术有限公司