研究文章|开放获取
El Hassane Khabbiza,Rachid El Alami,Hassan Qjidaa, "一种降低高速接入网络中IPTV系统单播带宽的新方法",国际数字多媒体广播杂志, 卷。2017, 文章的ID2456814, 9 页面, 2017. https://doi.org/10.1155/2017/2456814
一种降低高速接入网络中IPTV系统单播带宽的新方法
抽象的
对于互联网协议电视(IPTV)等基于ip的视频传输系统来说,频道切换时间是一个关键的体验质量(QOE)度量。最近提出了一种有趣的基于对等辅助传输的信道变更加速方案,该方案包括在IP主干网中部署一个FCC服务器(Fast channel change server),以便在每次信道变更后发送普通组播流之前将单播流发送到机顶盒。但是,由于FCC服务器发送给机顶盒的单播流量巨大,因此部署该解决方案会导致网络带宽占用过大。在本文中,我们提出了一种新的解决方案,通过在用户机顶盒上部署FCC服务器功能来减少单播业务的带宽占用。这意味着,在每个信道更改请求之后,机台将从另一个机台而不是中央服务器接收单播流量。使用这种方法,单播流量将不经过IP网络;它将是一个点对点通信通过接入网络。大量的仿真结果表明,我们的新解决方案的鲁棒性。
1.介绍
最近,IPTV (Internet Protocol Television)解决方案利用IP网络的扩大和网民的增加,提供组播电视、视频点播(VOD)、暂停直播电视(PLTV)等多种服务,得到了广泛的应用。
与传统电视带宽大、不向每个用户提供单个视频传输不同,IPTV的分发要求在性能和可靠性方面都有严格的要求,时延更低,抖动控制更严格,丢包更小,以保证预期的视频质量。
数字1说明了IPTV系统的基本拓扑结构。当用户切换到特定频道(或打开机顶盒)时,机顶盒使用IGMP (Internet group Management Protocol)协议发送加入相应组播组的请求。1].成功后,IPTV平台通过AGR (aggregate Router)、AN (Access Node)、HG (Home Gateway)将RTP (Real-Time Transport Protocol)包封装的视频流发送给用户。
每次信道改变时,机顶盒发送IGMP多播消息加入新信道;在这一变化期间,机顶盒必须等待更多的可解码帧的到来,这被称为i帧。为了解决这一问题,人们提出了许多减少等待时间的技术;最著名的技术之一是单播对等协助解决方案,它包括更快地发送i帧以允许机顶盒解码多播流,而不是等待原始i帧的到达。
本文的目标是提出一种新的方法,通过使机顶盒之间能够通信来减少信道变化时单播流量的带宽占用。使用这种方法,机顶盒将加入流,解码它,并显示在用户屏幕上。此外,在同一时间,机顶盒可以缓冲这个流几秒钟,以将它传送到另一个机顶盒(属于同一个AN),以防该机顶盒需要它。
本文组织如下。部分2评论用于减少通道更改时间的方法。所提出的方法详细说明3..节4,我们评估我们的方法,然后在Section中给出一个结论5.
2.相关工作
视频流由一系列按一定间隔(通常每33.3或40毫秒)拍摄的帧(或照片)组成;该流的比特率将非常高,SDTV(标准清晰度电视)最高可达200mb /s, HDTV(高清晰度电视)最高可达1gb /s [2].
由于网络带宽是稀缺资源,因此最近已经使用了许多压缩技术来节省网络带宽和存储。因此,已经开发了有效的媒体流方案,例如MPEG-2和MPEG-4,利用帧之间的时间相关性。这种相关性可以显着提高压缩效率。
该方案中的视频流被压缩成一系列帧,这些帧分组在一组图片(GOP)中,如图所示2.每个GOP由三个帧组成:i帧、p帧和b帧。i帧是参考帧,利用了帧内像素的空间相关性,它与其他帧非常独立。P-帧和b -帧是预测帧,总是依赖于待解码的其他帧;它们不能单独被破译。
为了解码视频流,解码器需要一个i帧,它是参考帧,因为它是解码所有GOP的基本信息。为了增加播放时间和减少延迟,强烈建议频繁发送i帧。但是,频繁传输i帧会增加视频流的比特率,因为这些帧比P帧和b帧要大。
GOP大小的选择应该非常适合在GOP大小和解码延迟之间有一个平均值。一般来说,在播放性能和压缩效率之间存在权衡;在实践中,GOP持续时间通常选择在1到3秒之间。
2.1.信道变化的延迟
在传统电视系统中,频道转换时间(CCT)几乎是同步的(约200毫秒),用户只需要改变载波频率,解调内容,然后在电视屏幕上显示即可。
随着视频流的数字化和压缩,信道变化时间(CCT)显著增加;一般来说,在IPTV系统中,它有三个底层组件[3.]:(我)解码延迟:用户输入信道变化和接收可解码的多播数据之间的时间。(2)IGMP延迟:处理IGMP的离开和加入消息所需的时间。(3)缓冲延迟:在在用户电视上显示内容之前缓冲内容所需的时间。
在过去的几年里,许多技术[4]已被建议作为缓解IPTV系统的CCT的解决方案。这些技术大多集中在减少基于辅助流(从i帧开始)的解码延迟上。这个辅助流发送到新加坡旅游局当用户更改频道为了让新加坡旅游局赶上前面I-frame并开始解码和显示它在屏幕上没有必须等到原始I-frame的到来,这将有助于减少有条件现金援助。
有三种基本技术可以利用辅助流。
技术1.prejoin基于用户行为或与当前通道并行的相邻通道的下一个通道最可能[5- - - - - -7].通过这种方式,机顶盒将非常快速地解码新信道的流,因为它在切换信道之前已经收到了i帧。
技巧2.将带有频繁i帧的低质量辅助流编码到每个频道的常规流中[8,9].
技巧3.该技术是基于FCC单播的,这包括在网络中部署一个快速通道更改(FCC)服务器,以便在每个通道改变请求后通过更高的速度将其传送到STB的STB [10- - - - - -12].
2.2.FCC Unicast-Based
基于单播的FCC是由于其简单性和可靠性,运营商部署的最受欢迎的频道变更解决方案,并且在其他网络元件中不需要进行任何修改以实现它。数字3.展示了一个简单的基于FCC单播解决方案的IPTV系统的拓扑结构4说明了该技术的工作机理。
该解决方案包括在IP主干网内部安装一个FCC服务器,以覆盖最大数量的ANs;此服务器连接到多播源,以捕获每个频道内容流的最后几秒钟。一旦IPTV用户按下遥控器上的按钮改变频道,新加坡旅游局将立即发送一个通信委员会要求FCC服务器并行请求单播的IGMP留言之前为了离开多播组对应于前面的通道。FCC服务器从新频道向机顶盒发送短视频流,以便立即回放,从过去的某个入口点开始。
FCC服务器以比通道数据速率快的数据速率将数据发送到机顶盒,几秒钟后赶上该通道的多播流,然后FCC服务器指示机顶盒加入新通道。
加入新通道并接收到第一个组播包后,机顶盒通知FCC停止单播流[13].
2.3.FCC单播带宽评估
基于FCC的单播没有考虑传输带宽的限制,因为单播流与组播流并行使用,向终端用户提供IPTV业务。当用户由于自己的行为(寻找有趣的节目)或为了避免商业广告(广告)而频繁或同时切换频道时,带宽限制就变得越来越严重。
该带宽将被添加到组播带宽和其他业务的带宽(特别是当AN向终端用户提供其他业务时),如HSI(高速互联网)、VoIP (IP语音)和POTS(普通旧电话服务),这会导致AN和AGR之间、AGR和IP骨干网之间的拥塞问题。
单播总带宽()在频道变化期间消耗一个,是所有单播流量的总和()发送给每台机顶盒(如图所示)5),可以用以下函数表示:
3.新的FCC单播解决方案
为了减少连接到一个AN的所有IPTV用户在信道变化过程中所消耗的单播带宽,我们提出了一种新的解决方案,如图所示6,它包括在每个用户机顶盒上与中央FCC服务器并行地实现FCC服务器功能,中央FCC服务器将充当FCC控制器(FCCC),同时作为传统的FCC服务器。一旦机顶盒接收到信道流,它将解码并将其显示在用户屏幕上,同时可以缓冲该流几秒钟,以将其传送到另一个机顶盒(属于同一AN),以防该机顶盒需要它。
我们的提案主要针对高速接入网技术,如VDSL(非常高比特率数字用户线)[14]、GPON(千兆无源光网络)[15,以及提供大量上行带宽的以太网。
为了确定用户的物理位置,我们将利用动态访问协议,如DHCP [16动态主机配置协议(Dynamic Host Configuration Protocol)和PPPOE [17](以太网的点对点协议),因为它们是用于IPTV身份验证的最流行的协议。
我们建议启用DHCP选项82 [18]或PPPOE选项82 [19](取决于AN的访问协议DHCP或PPPOE)。这样,信息将通过DHCP发现或PPPoE活动发现启动(PADI)消息发送到Access Server。一旦访问服务器获取此信息,它将将其转发(使用STB IP地址)到FCC服务器以构建FCC数据库(图7)。
3.1.可能的场景
在每个频道改变的过程中,可能会发生五种情况。
场景1(在FCC期间,机顶盒一直加入同一频道)。数字8显示此场景中的工作流和主要步骤。当用户想要切换到新的通道时,STB1向FCCC服务器发送一个FCC请求;FCCC服务器会先更新FCC数据库中与STB1相关的信息,包括信道变更的时间、STB的IP地址、新信道的ID。
更改通道的时间将被添加到该数据库中,以方便验证缓冲区实现,并决定该机顶盒是否可以作为其他机顶盒的FCC。
当FCCC服务器发现一个STB已经连接到同一个AN,并且正在用一个满的缓冲区加入新的通道时,FCCC服务器将请求这个STB (STB2)发送流到STB1。
在某个点上,STB2指示STB1加入新通道。当STB1加入新通道并接收到第一个组播报文后,通知STB2停止单播流。
场景2(在FCC期间,机顶盒更换通道)。如果STB在FCC周期内更改通道,则STB(接收器)将请求FCCC通过向FCCC报告最后一个RTP序列号来恢复流传送[20.].
场景三(FCC期间机顶盒关闭)。如果在FCC期间关闭STB,则STB(接收器)将请求FCCC通过向FCCC报告最后一个RTP序列号来恢复流传送。
场景4(在流交付过程中出现一些丢包情况)。如果在流传输过程中出现丢包,STB(接收端)可以向FCCC服务器索要丢失的RTP包,并上报该RTP包的序列号。
场景5(没有能够满足需求的机顶盒)。如果FCCC服务器没有找到任何满足FCC服务器要求的STB,它将按照前面FCC unicast - based部分所描述的那样,自行交付单播流。
图中的数据报9恢复新解决方案的主要步骤。
3.2.FCCC算法
本贡献的新颖之处在于,新的FCC控制器服务器(FCC controller server,简称FCCC)具有两个功能:第一个功能是普通的FCC服务器,第二个功能是FCC控制服务器,它将控制并选择合适的STB作为本地FCC服务器。
FCCC根据从接入服务器接收到的信息和通道更改请求构建FCC数据库。数据库由多个数据库组成;每个接入节点在FCCC中都有自己的数据库,我们将FCCC数据库视为一个矩阵(图10),其中列数为在线机顶盒的数量,行数为缓冲区时间除以时间采样间隔。
一旦FCCC服务器收到一个FCC请求,它将更新数据库中STB的条目。要保存内存,FCC服务器将仅记录大约几秒钟的信息。例如,在图中10,此时STB4正从通道3切换到通道1,FCCC服务器收到STB的通道更改请求后,会及时更新STB4对应的第4行从3频道到1频道。
然后,FCCC服务器将分析所有矩阵行以检查一个STB是否具有通道的完整缓冲区1.验证后,结果将是STB2,因为该STB在长期高于缓冲持续时间的时间内接收到该频道的流量。表示STB2具有完整的缓冲区,因此可以用作FCC服务器。
为了避免上行流量拥塞和负载问题,FCCC在FCC期间不会对机顶盒进行多次选择。每次FCC选择完成后,FCCC会启动一个倒计时定时器(定时器时间等于FCC的时间),并将其绑定到所选的STB上;这样,FCCC将不会选择这个STB,因为定时器还没有过期;定时器到期后,可以再次选择STB作为FCC服务器。
一般情况下,由FCCC服务器计算STB ID, STB ID可以作为用户的FCC服务器在瞬间基于以下功能: 在哪里(我) 为单位矩阵;(2) 方阵的大小是多少 ,带有向量元素在主对角线上,其他地方为零: (3) 列向量有大小吗 ,其中包含了当时每个机顶盒的信息 ;这个向量将被用来排除机顶盒,它在瞬间被关闭 ;即使是它的缓冲区也充满了FCCC数据库;(iv) 为无穷大整数,应用因子忽略小于1的值;(v) 方阵的大小是多少 ,它由对角值组成,每个对角值都等于矩阵的行数和,矩阵的元素 ,其他地方和零: (vi) 是一个大小为m的方阵,由对角值组成每个对角值等于矩阵的行元素的乘法吗 ,其他地方和零: (七) 为信道变化矩阵,其中包含每个用户最新的信道变化信息;它是由列和行;(八) ;(第九) 为采样间隔,即获取信息的点之间的距离;(x)缓冲区持续时间为FCC缓冲区的持续时间;(十一) 为在线机顶盒数量;(十二) 列向量有大小吗 ,数字以1递增。
请注意(我)在主函数中,矩阵P,年代,C是否已修改,以通过应用函数消除非一个元素和 .(2)如果上述功能的结果为零,则这意味着没有所描述的要求的STB;在这种情况下,FCCC应负责将单播流传递到STB .
4.绩效评估
要确认所提出的方案的性能和效率,我们在使用MATLAB之间创建了单播带宽的模拟。
我们已经在这个例子中考虑过了(图11),我们有120个用户,总共可以更改多达60个SD通道(每个通道的速度是3 Mb/s),经常持续1200秒。FCC缓冲区的容量为3秒。
该方案降低了信道变化过程中FCCC发送给机顶盒的单播带宽;本地FCC (stb)服务器代替中心FCCC服务器转发信道变更时所需的单播流量。
数字12在通道数量方面显示带宽行为;用户数量在60个用户时固定,并且在400秒的时间内,它们可以执行多达40个通道更改。我们在这个例子中备注,当信道的数量较小到用户号码时,我们方案的效率非常重要,因为查找更多用户观看相同频道的概率很高。这意味着当用户切换到新频道时,我们有更高的机会查找观看相同的通道的用户,这可以支持发送单播流而不是中央FCC服务器。
增加频道的数量意味着用户在频道浏览过程中有了更多的选择,所以当用户切换到一个新的频道时,就很难找到更多的人在观看同一频道。
在旧方案中,所有用户在信道变化过程中所消耗的单播带宽与用户数量成正比,而在新方案中,当用户数量大于信道数量时,单播带宽降低。这意味着,一旦我们有更多用户观看如图所示的同一频道,我们就有了良好的优化13.
数字14以观看时长表示带宽行为;旧方案和新方案在观看时间较长时表现出相似的行为,但当用户频繁切换频道时,新方案在节省带宽方面更优。
综上所述,该方案的仿真结果表明,该方案能够很好地管理AN上行端口的带宽,特别是当有大量的信道更改请求和用户数量高于可用信道数量时。
5.结论和未来的工作
本文提出了一种新的解决方案,通过在用户机顶盒上实现单播对等辅助解决方案,有效地管理IPTV信道变化过程中IP网络单播流量的带宽资源。这意味着如果有一个STB已经加入了一个通道,并且这个通道被连接到同一个接入节点的另一个STB请求,这个STB可以将FCC单播流量传递给它的邻居,而不是中央FCC服务器(FCCC)。在没有机顶盒加入该频道的情况下,FCCC将按照传统的基于单播的FCC方法,自行将单播流量发送给机顶盒。
整个流程由中央FCC服务器根据从机顶盒接收到的信道更改请求和从访问服务器接收到的机顶盒位置收集的信息进行控制。
我们的解决方案不需要任何额外的资源或新的硬件集成在其他网络元素;它只需要在FCC服务器和用户机顶盒上进行一些软件升级。对于未来的发展,我们将扩展这个新的解决方案,通过利用用户机顶盒之间的通信来优化PLTV(暂停直播电视)的单播带宽。
的利益冲突
作者声明他们没有利益冲突。
参考文献
- S. Shoaf和M. Bernstein,“IPTV网络IGMP简介”,2006。
- F. M. V. Ramos,《减轻IPTV的快速延迟》IEEE通讯杂志,卷。51,没有。8,pp。128-133,2013。视图:出版商的网站|谷歌学者
- V. Joseph和S. Mulugu,《部署下一代组播应用:标签交换组播用于MPLS vpn、VPLS和批发以太网》。2011年摩根考夫曼。
- 田旭,程勇,沈旭,“基于目标组播的IP视频传输快速信道消除”,IEEE并行和分布式系统汇刊,第24卷,第2期2, pp. 327-341, 2013。视图:出版商的网站|谷歌学者
- C. Cho, I. Han, Y. Jun, H. Lee,“利用相邻组加入-离开方法改善IPTV服务的频道切换时间”,在第六次国际先进通信技术会议的诉讼程序:宽带汇聚网络基础设施,PP。2004年2月971-975。视图:谷歌学者
- J. O. Farmer和S. Thomas,“最小化Ip视频的频道切换时间”,2006。
- C. Y. Lee,C.K. Hong,K. Y. Lee,基于用户的频道选择行为,“减少了IPTV中的信道剪接时间”,IEEE广播汇刊第56期3,页321 - 330,2010。视图:出版商的网站|谷歌学者
- J. M. Boyce和A. M. Tourapis,“用于Dsl系统的快速信道切换的方法和设备”,“WO/2005/ 112465,2005”。视图:谷歌学者
- J. Boyce和A. Tourapis,“快速有效的频道改变[机顶盒应用]”,在2005年技术论文摘要的诉讼程序。消费电子国际会议,2005年。,第1-2页,美国内华达州拉斯维加斯,2005年1月。视图:出版商的网站|谷歌学者
- N.德格兰德,K.拉文斯,D. De Vleeschauwer, a.l.Bell, R. Sharpe,“提高用户感知IPTV服务的质量”IEEE通讯杂志第46卷,第46期2, pp. 94 - 100,2008。视图:出版商的网站|谷歌学者
- H. a . Goosen和E. J. Rak,包括快速频道转换机制的视频流系统,2011。
- N.科恩,“数字电视的快速频道切换”,美国,2006/0143669 A1, 2006。
- R. Haimi-Cohen和J. P. Hearn,“延迟组播加入的快速信道更改处理”,美国8,161,515 B2, 2012。
- 国际电信联盟建议,G. 993.2 (02/2006)的立场。教派,电联。
- G. ITU, 984.1:千兆无源光网络(GPON):一般特性,ITU- t, 2008年3月。
- R. Droms,动态主机配置协议,RFC编辑器RFC2131, 1997年。视图:出版商的网站|谷歌学者
- L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone,和R. Wheeler,“一种通过以太网传输PPP (PPPoE)的方法”,RFC编辑器RFC2516, 1999年。视图:出版商的网站|谷歌学者
- M. Patrick, " DHCP中继代理信息选项"RFC编辑器RFC3046, 2001年。视图:出版商的网站|谷歌学者
- V. Mammoliti, G. Zorn, P. Arberg,和R. Rennison,“DSL论坛供应商特定半径属性”,RFC编辑器RFC4679, 2006年。视图:出版商的网站|谷歌学者
- B. Ver, A. Begen, T. Van,和Z. Vax,“基于单播的多播RTP会话快速获取”,RFC编辑器RFC6285, 2011年。视图:出版商的网站|谷歌学者
版权
版权所有©2017 El Hassane Khabbiza等人。这是一篇发布在知识共享署名许可协议如果正确引用了原始工作,则允许在任何媒体中进行无限制使用,分发和再现。