[发明专利]用于多媒体服务的快速频道切换的客户端配置和管理

说明书

技术领域

本发明涉及用于快速频道切换(FCC)的客户端配置和管理以及IPTV，互联网电视，有线电视和类似服务的可靠传输。

背景技术

IPTV(互联网协议电视)的广播频道通常采用IP多播技术传输。有线电视的广播频道通常采用射频传输技术传输。

IPTV的早期试验和部署包括一组非常有限的VOD(视频点播)标题、少量的用户并且主要是作为面向传统广播方法的免费点播服务。然而，由于IPTV变得更加成功和更广泛地部署，需要提供更多的VOD标题和广播频道，例如5000个VOD标题和几百个广播频道，并且每个服务供应商可能拥有许多用户，甚至达到数百万。因此，现在已经开始展开了与传统广播或卫星系统的竞争。

IP系统的一个传统优势是存在返回IP路径，同服务传输一样，它提供了同一基础设施上的实时交互和控制的手段。类似地，有线电视系统也有返回路径。然而，为了利用交互性，IPTV或有线电视服务应该更优先地提供更好的或者至少是相同的用户体验和像更传统的服务(例如模拟天线广播电视频道)那样的服务质量。

区别于传统的广播，由于其多播传输特性，通常不是所有的电视频道立即提供给IPTV系统中的客户端。此外，使用了数字差分编码。本质上讲这意味着电视画面作为关键帧发送，然后是一连串增量帧，增量帧只包含一个增量帧相比于另一个改变了的数据。在传输若干增量帧(通常是20个)之后，传输另一个关键帧，等等。这意味着客户端设备的用户当“调”到一个新的频道时会遭遇由于直到接收一个关键帧才开始正确显示频道而产生的固有延迟。因此，只能够在关键帧或在一个完全编码的视频帧开始处的随机接入点(RAP)加入流。

上述两个因素导致了IPTV系统中相对缓慢的频道切换时间。

为了改进频道切换体验，已经使用FCC单元。FCC单元缓存广播频道的内容滑动窗口(例如上一个30秒或上一分钟)。内容能够响应于来自客户端装置从RAP开始的频道切换请求而随后被传输，可选地以高于编码比特率的速率。这可以使得尽管客户端最初收到一个可以说滞后“真实时间”30秒的RAP，系统可通过选择性丢帧的方法追上，以便在相对短的时期之后使用户有效地观看实时传输。这当然增强了当用户观看直播体育赛事等节目时的体验。来自FCC服务器的数据可以作为专用(所谓的单播)流而被传输。

通常用一组待缓存的BTV(广播电视)频道(例如多级地址)来预先配置/预先供给FCC单元。为了推广这一做法，先前已采用分布式结构。这包括一组接近网络边缘/接入节点的FCC单元，例如DSLAM中的FCC单元。例如在ETSI TSl83084V2.1.1中描述了FCC功能性。

传输质量(QOD)也有类似要求。由于IP传输的不可靠性，可能会出现数据包丢失，这会降低观看体验。为了保证高质量且一致的多媒体数据的传输，已经开发了Retr(重传)单元。Retr单元缓存广播频道的内容滑动窗口。丢失的数据可以随后响应于客户端的Retr请求而被传输。从本质上讲，如果客户端收到的部分数据损坏或不完整，可请求重传(Retr)这些数据。

典型的FCC/Retr系统的分布式结构以及大量的网络边缘的单元、频道列表中的地区变化、频道受欢迎度的本地变化和频道受欢迎度随时间的变化，需要一种特殊的方法来部署FCC/Retr系统。当说起FCC/Retr单元(或服务器)时，是指该服务器可以提供FCC服务或Retr服务或者两者皆可。

FCC和Retr单元可以结合成为一个单独的FCC/Retr单元。

通常需要用若干FCC/Retr服务的参数来预先配置用户设备(例如IPTV机顶盒)。这可以包括：

-针对其而支持FCC服务的频道，

-针对其而支持Retr服务的频道，

-接入点的关于请求FCC或Retr服务中任一种的接入细节，

-关于所述服务中任一种的服务配置参数，例如本地客户端缓冲器大小、最小线路带宽或其它数据。

应当指出，在特定的网络中，FCC或Retr的可用性并不自动保证在用户设备(UE)上的服务。这是因为UE可能没有所要求的服务能力或实际的互联网连接(例如DSL线)可能没有足够的带宽或质量来传输特定的服务。这都需要在UE提供期间加以考虑。当服务提供商必须考虑分布式的且通常是分层的FCC/Retr结构、大量的可用频道(其中一些可能不能很好地适用于FCC和/或Retr)、频道的可用性和受欢迎性的地区和本地变化以及频道受欢迎度随时间的变化的时候，对客户端受欢迎度的管理变得更加复杂。