潜在的网络拥塞。
[0048]响应于来自所述移动HAS客户端10的分别的请求，所述HAS服务器110以被请求的比特率向所述移动HAS客户端10提供被请求的视频内容。所述移动HAS客户端10随后将接收的视频内容向终端用户播放。
[0049]如上所述，传统网络中的移动HAS在所述移动HAS客户端10和所述HAS服务器110之间主要利用无线尽力而为(BE)数据连接和应用层信令以试图将被请求的视频比特率与估计的至所述移动HAS客户端10的可用带宽相匹配。
[0050]为了提供更稳定的视频质量并避免比特率选择中的乒乓效应，每个移动HAS客户端维护RDA阈值(例如与缓冲区占用水平相关)以使得用于下一段的选择的比特率的下降仅在特定的阈值被达到时发生，而不会由间歇的数据包丢失或延迟所导致。
[0051]该必要的阈值机制在移动HAS客户端的比特率选择中引入了大量的惯性(inertia)，其可以在拥塞开始之后使得由HAS流量导致的无线网络的过载持续一段时间(例如，大约数十秒到数分钟)。作为此类过载的结果，服务小区可能开始丢包，使得TCP重传，进一步促成了过载状况的加剧。
[0052]众所周知，伴随着延长的拥塞/过载状况，网络有效吞吐量可降低至明显地低于其能力，并且一些移动HAS客户端可达到导致视频冻结的缓冲区空状态。对于其它移动HAS客户端，速率下降可超过限度使得RDA调整引起后续的视频质量振荡直至该过程收敛，其可能需要大约数十秒到数分钟的时间。同时，改变网络状况可能延长收敛周期，其可加重这些问题。
[0053]如上所述，在移动HAS客户端的RDA变体/定制利用多种启发法以试图识别移动HAS客户端潜在的网络拥塞。然而，这些启发法不能精确地识别拥塞，因为它们缺乏完整的网络视角并且独立的应用于每一个个体的移动HAS客户端。此外，移动HAS客户端不能从接入网接收任何拥塞的指示，因此HAS客户端无法靠自己来识别拥塞。
[0054]示例性实施例提供了用于在小区层对HAS流量的更快的拥塞解决方案和/或用于个人HAS客户端的速率选择更快的收敛至更稳定的水平(例如，在一些仿真结果中大约数秒)的方法、设备和计算机可读存储介质。
[0055]依照至少一个示例性实施例，在网络单元(例如，eNB、PGW、SGW、MME等等)的拥塞控制功能模块通知移动HAS客户端服务小区内检测到拥塞。响应于所述检测到拥塞的通知，所述HAS客户端进入特殊的拥塞模式。在所述特殊的拥塞模式操作中，所述移动HAS客户端将对内容的下一段的请求的发送延迟一延迟时间间隔，计算在所述延迟时间间隔之后用于将被请求的下一段的降低的比特率，并且在所述延迟时间间隔期满之后，以所述降低的比特率请求下一段。该方法有助于所有移动HAS客户端更快的收敛至更稳定的速率。
[0056]设置所述延迟时间间隔的持续时间以使得有足够的时间用于有待解决的小区拥塞，但仍然留下足够满的视频播放缓冲区以便不在终端用户处导致视频中断。在一个示例中，所述延迟时间间隔的持续时间可等于或大体等于几个视频内容的段的播放持续时间。所述延迟时间间隔的长度也可考虑对移动HAS客户端的当前被请求段的剩余处理/转发。即，例如，所述延迟时间间隔的持续时间可被如此设置以致在完成用于每个移动HAS客户端的当前被请求段的处理/转发之后，有足够的时间用于待解决的小区拥塞。
[0057]图2A和2B为流程图，示出了根据示例性实施例用于拥塞解决方案的方法。图2A和2B中展示的所述方法经由携带HAS段的数据包的互联网协议(IP)报头中的显式拥塞通知(ECN)来利用基于标准的信令。
[0058]众所周知，所述ECN为对IP和TCP的扩展，并且在互联网工程任务组(IETF)征求评议文件(RFC) 3168 (2001)中被定义。ECN允许网络拥塞的端对端通知而不丢弃数据包。
[0059]至少根据该示例性实施例，所述ECN可由eNB105处的拥塞控制功能块22在发送具有HAS段的IP数据包至所述移动HAS客户端10之前添加至该携带HAS段的数据包的IP报头中。图2A中的流程图示出了拥塞控制功能块22的示例性操作/功能，而图2B中的流程图示出了移动HAS客户端10的示例性操作/功能。
[0060]为了例示的目的以及在讨论示例性实施例中的简单，假定拥塞是由选择了太高的比特率分辨率(又被称为“比特率”)的移动HAS客户端所引起的，这样，在服务eNB处调节用于后续HAS段的被请求的比特率至更合适的较低值对于解决该拥塞状况是足够的。然而，示例性实施例还可适用于由HAS流量和非HAS流量(例如，网页浏览、FTP、电子邮件检查等等)的组合引起的拥塞的状况。此外，为简单起见，图2A和2B中所示示例性实施例将参考单个的HAS客户端进行描述。然而，应注意相同的或实质上相同的方法适用于同时或并行地多个移动HAS客户端。
[0061 ] 参考图2A，在利用由服务eNB 105提供的无线资源的移动HAS客户端10和HAS服务器I1之间的活动移动HAS会话持续期间，在步骤S402拥塞控制功能块22在服务eNB105处检测拥塞(例如，持续的拥塞)。所述拥塞控制功能块22和/或所述eNB105可在所述服务eNB105处以任何已知的方式检测拥塞。因为用于检测小区拥塞的方法为已知的，详细的讨论被省略。在一个示例中，通过将朝向eNB105的流量与小区能力相比较、基于UE报告的被选择速率超过小区能力等等，当小区缓冲区的内容超过阈值时，服务eNB105可以检测拥塞。然而，示例性实施例不应受限于这些示例。
[0062]在步骤S404中，拥塞控制功能块22通知移动HAS客户端10检测到的拥塞。在一个示例中，拥塞控制功能块22通过依照IETF RFC 3168在来自HAS服务器110的携带HAS段的数据包IP报头中设置CE (拥塞经历)代码点标志来经由显式的拥塞通知(ECN)向移动HAS客户端10发送检测到拥塞的信号。如稍后参考图2B更详细的讨论的，来自拥塞控制功能块22的拥塞通知导致移动HAS客户端10进入特殊的拥塞模式，其有利于在服务eNB105处检测到的拥塞的解决方案。
[0063]在通知移动HAS客户端10检测到拥塞并且在等待周期之后，拥塞控制功能块22在步骤S414确定检测到的拥塞是否已经被解决。在一个示例中，所述等待周期可能是大约2到4秒。备选地，所述等待周期可被省略并且拥塞控制功能块22可立即和/或连续地在步骤S414确定检测到的拥塞是否已经被解决。所述拥塞控制功能块22和/或eNB105可以以任何已知的方式确定小区拥塞是否已经被解决。因为用于检测拥塞已经被解决的方法为已知的，详细的讨论被省略。在一个示例中，通过将朝向eNB105的流量与小区能力相比较、基于UE报告的被选择的速率超过小区能力等等，当小区缓冲区的内容降到阈值以下时，eNB105可检测到拥塞已经被解决。然而，示例性实施例不应仅限于这些示例。
[0064]如果拥塞控制功能块22检测到服务eNB105处的检测到的拥塞已经被解决，那么在步骤S416，拥塞控制功能块22通知移动HAS客户端10所述拥塞已经被解决。在至少一个示例性实施例中，通过在检测到所述拥塞已经被解决之后重置(或清除)将被发送至移动HAS客户端10的(来自)携带下一 HAS段的数据包IP报头中的CE代码点标志位，拥塞控制功能块22经由ECN通知移动HAS客户端10所述检测到的拥塞已经被解决。
[0065]返回步骤S414，如果拥塞控制功能块22在等待周期后仍检测拥塞，那么过程返回至步骤S404，其中拥塞控制功能块22继续在发送至移动HAS客户端10的携带HAS段信息的数据包IP报头中列入被设置的CE代码点标志。然后所述过程继续上述所讨论的步骤，直到服务eNB105处的拥塞被解决。在图2A中展示的示例中，拥塞控制功能块22继续在携带HAS段的数据包中列入被设置的ECN标志，直到服务eNB105处的拥塞被解决。
[0066]现在转向图2B，在步骤S403，移动HAS客户端10接收由图2A中拥塞控制功能块22在步骤S402发送的检测到拥塞的通知。在该示例性实施例中，移动HAS客户端周期性地检查接收到的(携带HAS段的)IP数据包中被设置的CE代码点标志位(还被称为拥塞指示符或拥塞指示符比特)。在一个示例中，移动HAS客户端10可以大约2至6秒的间隔周期性地检查接收到的IP数据包。备选地，移动HAS客户端10可检查每个接收到的IP数据包中的被设置的CE代码点标志位。
[0067]在步骤S405，响应于从拥塞控制功能块22接收拥塞通知(例如，被设置的CE代码点标志)，移动HAS客户端10进入上述的特殊的拥塞模式。
[0068]在特殊的拥塞模式中，在步骤S406移动HAS客户端10确定在移动HAS客户端10处的播放缓冲区B是否为低的、耗尽的或接近空的。在一个示例中，移动HAS客户端10通过将播放缓冲区B当前内容水平与阈值相比较来确定播放缓冲区B是否是耗尽的。所述阈值可以是大约4秒的播放持续时间。
[0069]在步骤S406，如果移动HAS客户端10确定播放缓冲区B不是耗尽的，那么在步骤S408移动HAS客户端10确定延迟时间间隔的持续时间，在所述延迟时间间隔期间延迟或停止从HAS服务器110请求后续的视频段。
[0070]在至少该示例性实施例中，延迟时间间隔的长度可基于移动HAS客户端10处的视频段的平均播放持续时间来确定。例如，延迟时间间隔的长度可等于或大体上等于至少两个视频段的平均播放持续时间。在另一示例中，当移动