等辅助内容交付，以减少时移电视业务的IPTV系统带宽

摘要

随着伟大的技术，出现了新的需求和要求。在接入宽带速率方面取得的进展突出了对IPTV (Internet Protocol Television，互联网协议电视)服务的需求，特别是视频点播(VOD)和时移电视(TSTV)，这导致了对这些服务所消耗的带宽使用效率的巨大需求。IPTV服务提供商考虑优化解决方案，以减轻服务负载，特别是在访问节点上行链路上。本文介绍了一种基于对等辅助TSTV内容传输的TSTV专用带宽优化方案，该方案由用户机顶盒(set-top-boxes)辅助中心TSTV服务器完成服务。为此，对于每个TSTV请求，STB将从相邻的STB而不是中央服务器接收TSTV流。通过该方法，单播流量不会通过IP网络;它将是接入网内的点对点通信。仿真结果验证了所提方法的有效性。

1.简介

近年来，随着IP网络的扩展和宽频用户的增加，多播电视、视频点播(VOD)和时移电视(TSTV)等多种服务的推出，IPTV服务得到了广泛的应用[1]。

传统的电视采用大带宽没有用户特定的视频传输。IPTV在另一方面，对性能和可靠性的严格要求，此外需要抖动的紧密控制旁小延迟和丢包，以确保预期的最终用户体验。在过去的几年中，提出对IPTV和带宽管理许多研究。肯Kerpez等。[2建议通过本地化的点对点(P2P)视频减少带宽。作者的三]强调了在今天的IPTV解决方案的无线传输的相关性。乔治·Acher等。[4个]介绍拟议的NetCeiver架构的硬件和软件实现，该架构可同时传送多达六个完整转发器的服务。在[5个]提出了一种基于网络骨干网的IPTV多播系统的设计方案，利用资源预留算法来预留带宽。

如图所示1，在IPTV系统中的标准拓扑中，STB通过连接参数经由访问服务器提供。使用DHCP（动态主机配置协议）6个]或PPPOE(以太网点对点协议)[7个]和接入授予，当用户选择特定的信道（在他的STB或换台转动），他的STB被相应地发送加入使用IGMP协议（因特网组管理协议）[相应的多播组的请求八,9个]。接收该请求的IPTV平台会传送即时传送协议(RTP) [10]将视频流封装在IP包中，通过AGR(聚合路由器)、AN(访问节点)和HG(家庭网关)传递给用户。

视频内容的数字化、压缩和分组化显著增加了信道变化时间（CCT）。通常在IPTV系统中，这种延迟有三种基本类型[11]：(我)解码延迟：这是一个信道改变的用户输入并接收解码的多播数据的时间之间。（ⅱ）IGMP延迟:处理IGMP离开和加入消息所需的时间。（三）缓冲延迟:在用户电视上显示内容之前缓冲内容所需的时间。

在过去的几年中，许多技术[12,13]已被提议作为IPTV系统中的CCT的缓解措施。基于单播的FCC (Fast Channel Change)是运营商在世界范围内最流行的信道变化解决方案，因为它简单、可靠，并且与现有的网络元素兼容，不需要进行任何修改。

2.1。FCC基于单播的

此溶液中，通过在图的典型的拓扑结构如图所示2，是基于FCC服务器从多播源记录每个频道的内容流的最后几秒钟。这样的服务器安装在IP主干中，以覆盖大量的访问节点。改变观看频道的IPTV用户不仅通过机顶盒发送IGMP leave消息，以便离开前一个多播组对应于前一个频道，而且还向FCC服务器发送FCC请求，以请求单播视频内容。因此，FCC服务器响应STB，发送一个片段的视频流的新请求的通道，立即播放，从过去的某个入口点开始。FCC服务器将数据发送到STB的速率比信道的速率快，但是在时间上要晚一些，以便赶上所请求的信道的多播流，然后指示STB通过IGMP加入多播信道组[14- - - - - -16]。

在加入新信道并接收到第一个多播数据包后，机管局通知FCC停止发送单播流[17- - - - - -19]。数字三展示了这种技术的工作机理。

2.2。时移电视服务

一个IPTV的最重要的特点就是与内容服务器，即VOD交互的能力。当用户可以选择观看什么，为什么不看什么，他错过了。这是时移电视（TSTV）20个]。这种有利可图的服务促使IPTV运营商通过扩展TSTV平台容量(存储)和在接入网层增加更多的区域服务器来投资其可伸缩性，同时保持较低的带宽使用率。

在IP主干内部署的TSTV服务器，为了覆盖最大数量的ANs，根据操作员策略和服务器容量，不断地循环记录多播实时信道内容的最后几个小时或几天。

使用EPG(电子程序指南)，如图4个，用户选择具有特定时移的信道;然后STB向TSTV服务器发送一个包含相关信息的请求。在接收请求时，TSTV服务器通过单播将内容流的确切请求部分发送到STB。

普通的IPTV信道是通过多播传输的，随着用户数量的增长，多播具有很高的可扩展性。另一方面，TSTV内容通常是使用单播来传送的，随着需求的增加，单播会给TSTV服务器和所有系统组件带来沉重的负担，直到最终用户机顶盒（stb）出现为止[21岁]。随着IPTV用户数量的快速增长和视频观看习惯的转变，IPTV服务商及相关介入者迫切需要有效降低TSTV内容的巨大吞吐量，寻找内容交付的替代方案[21岁- - - - - -23个]。

三。提议的方法

3.1。新的解决方案架构

在[24个我们描述并分析了一种新的解决方案，以减少TSTV业务在IP骨干网中的单播带宽消耗;在本文中，我们将强调图中所示的这种新的TSTV服务模型的健壮性5个通过先进的网络模拟。

我们的解决方案主要是在TSTV服务器控制的每个用户STB上实现一些TSTV server light功能，除了TSTV服务器的角色外，TSTV服务器还将充当TSTV控制器。用户请求的多播信道流将被解码并显示在用户电视上，同时在本地录制一段特定的时间，以便在需要时提供给相邻的STB(属于同一AN的STB)。

这个新方案是完全由具有关于存储在数据库TSTV所有活IPTV用户和用户TSTV所有必要的信息，TSTV服务器控制（图6个)。要建立和更新这个数据库包含所有有关机顶盒的历史信息和信道（直播电视频道）的名单，在过去看着每个STB，我们将采取现有的FCC解决方案的好处。

TSTV服务器应完全了解当前和历史频道的观看情况。这可以通过在每个频道更改事件之后向TSTV服务器发送一个额外的FCC请求来实现，如图所示7个。

我们的建议主要是针对高速接入网络技术，如VDSL（甚高速数字用户线路）25个]，GPON（千兆无源光网络[26个]，以及提供较大上行链路带宽的以太网。

用户的物理位置是判断STB相邻关系的强制性条件。这些信息将从通常用于IPTV访问保证的动态访问协议(DHCP和PPPOE)中提取。

DHCP选择82 [27个]或PPPOE选择82 [28个]应在访问节点上启用，以便用户位置信息将通过DHCP discover或PPPOE Active Discovery Initiation（PADI）消息报告给访问服务器[29个]。一旦访问服务器获取此信息，它会转发（STB与IP地址）时移电视服务器建立TSTV数据库（图八)。

图中的数据报9个总结了新的解决方案的主要步骤;当STB_R（“R”为接收器）请求从TSTV服务器TSTV内容时，TSTV服务器将触发最佳内容源STB_S（“S”为源极）匹配条件：(我)STB_S和STB_R应该连接到同一个访问节点。（ⅱ）STB_S应该有请求的内容。（三）如果STB_S已经将TSTV流发送到另一个STB_R以节省stb的上行带宽，则STB_S将被排除。

满足这些条件的STB_S将由TSTV服务器指示通过单播流将选择的内容发送到STB_R，否则，如果没有匹配条件的STB, TSTV服务器将自己授予STB_R请求。

如果STB_S在TSTV流期间被关闭，STB_R将请求TSTV服务器通过报告确切的中断时间来恢复所需内容的流交付。

如果在流传送期间有一些包丢失，STB_R可以通过报告该包的序列号从STB_请求丢失的RTP包[18]。

3.2条。新的求解算法

在该算法中，来选择将要STB“i”的在时刻“J”被提供服务的STB_S（单播流的源），则TSTV服务器运行图的算法10。

4.绩效评估

4.1条。GNS3上的新解决方案仿真

在这一部分中，我们将在实验室环境中测试解决方案。为了实现的灵活性，采用了仿真软件。只使用开源软件或免费软件。我们将在下面详细介绍使用的软件和版本。

思科GNS3(图形网络模拟器-3)[30个的性能、稳定性、易用性、开源特性以及与VMs(虚拟机)集成的可能性，以及与本地或远程接口或设备的连接的可能性。使用了软件的最新可用版本(V1.3.13供参考)。由于多播路由已经成为一项基本功能，任何类型的路由器都可以完成这项工作。使用的路由器和版本是GNS3提供的预先存在的路由器(路由器版本C3660-TELCOENTK9-M v12.4)。

在IPTV源是由视频广播在安装在基于Linux的虚拟机的IP软件仿真。甲骨文的VirtualBox虚拟机作为虚拟机管理程序。VirtualBox是一个小型的开源和方便的管理程序。所使用的版本是5.0.16 r105871。

运行视频广播软件只需要基本的功能，所以我们选择了最轻便的Linux操作系统Lubuntu 17.10，以便为多播服务器和接收器创建实例，使主机上的负载最小化。为了模拟STB，我们使用了Lubuntu的虚拟机，就像安装了VLC播放器的多播服务器一样。

我们使用了著名的强大而稳定的视频广播和播放器VLC (v2.2.6版本)[31个，具有很多功能的开源软件。它的一些最强大的特性是能够读取网络流、记录流并使用脚本将其输出。

甲MPEG-4 [32个320x258分辨率和30.1 MB大小的示例视频是内容流。

4.1.1。网络拓扑结构

如图所示11为了建立labl3网络，使用了三个类似的路由器。给出了相应的互连IP地址。为了模拟一个访问节点(一个)，使用一个带有交换结构的路由器。用户家庭网关也采用同类型路由器进行仿真;多播服务器和用户STB是lubuntuvm和VLC。

组播服务器，用户STB和HomeGW给予静态IP缺省网关先连接的路由器。所述HomeGW被使能IGMP v2协议以请求来自网络的多播流量。接入节点（AN）（路由器）与转换功能，包括IGMP Snooping设备。该L3路由网络经由OSPF [放心33个]在其上PIM SM [34个]已启用在中提供多播路由。

4.1.2条。现有直播多播服务的仿真

由于使用了PIM-SM，多播流将从穿过RP（集合点）开始，然后沿着从AGR直接经过的短路径树进行。在三个点上进行跟踪，以说明到达用户1的多播流。

当检查跟踪点时，流量实际上是从组播源(10.10.10.2)流出到所选组播地址224.1.1.1的目的地。路由器有效地通过这个流，它到达用户1。安装在STB_1中的视频播放器允许我们正确地观看接收到的流，因为用户1是多播组的成员。所有结果如图所示12。

方法中启用IGMP窥探，因此对面的用户2不接收任何流。

组播仿真成功TSTV业务也应模拟，建立正确的整体解决方案。下面的部分将被然后致力于TSTV业务模拟。

4.1.3。现有时移电视业务的模拟

按照正常的行为，用户2将从TSTV服务器请求TSTV内容。我们在两点上进行了跟踪，以说明到达用户2的单播流。

在检查跟踪点时，流量实际上是从TSTV服务器(10.10.10.2)流出的，这次的目的地是用户2的ip地址(192.168.22.2)的单播地址。路由器有效地通过该流并到达用户2。STB_2中安装的视频播放器允许我们在读取指向用户2 IP地址的流时正确地观看接收到的流。所有结果如图所示13。

由于TSTV用户是由TSTV服务器提供服务的，因此链路agran上的负载将与请求此服务的用户一样多。

模拟结果表明，用户1能够观看多播流，用户2能够从TSTV服务器观看TSTV流。通过构建IPTV和TSTV业务的所有组件，我们将介绍所提出的TSTV解决方案。

4.1.4。仿真了所提出的TSTV方案

解决方案首先由邻居观看和录制多播视频内容，然后在TSTV控制下将其发送给请求用户。这两个步骤将在下一部分详细介绍。(我)观看和录制多播。

如解决方案中提出并在先前的图中所示，用户1将开始在预定的时间段内本地记录请求的业务。流正在到达STB_1并将其记录为文件“记录.mp4”.（ⅱ）记录的流中继到用户2。

在此阶段，为了在上行链路上通知更改，用户1停止请求多播流，用户2将使用解决方案中建议的来自用户1的记录内容(图1)14)。

此内容将以用户2单播地址作为目的地流式输出。

在建议的解决方案中，从TSTV服务器到图中跟踪中确认的用户2之间没有通信流15. TSTV单播将从STB 1流到目标STB 2。从STB 1追踪到STB 2的相同流量。

视频内容是在用户2侧没有区别毛毡流成功有看头。

综上所述，使用类似于典型IPTV和TSTV网络的实验室环境，TSTV用户能够在不重用链路AGR-AN的情况下，由连接到同一接入节点的邻居用户中继请求的视频服务。

所提出的解决方案的基础上，对多播内容和共享与邻近用户在指定时间内一个TSTV服务器控制记录，然后成功通过减少上行链路负载来显示一个现实的效率。

4.2条。基于Matlab的带宽优化仿真

在这个采样环境中，我们假设有100个实时IPTV用户、60个要观看的标准定义频道(每个频道的带宽为3 Mb/s)和80个TSTV用户能够在TSTV服务器上请求录制的IPTV内容(这60个频道)。

我们的示例用户的IPTV和TSTV实时仿真同时启动了20分钟(1200秒);live IPTV STB_S接收多播内容，对其进行解码，并将其发送到电视屏幕，同时使用指定时间内的内置本地DVR对其进行录制(对于本示例，最大录制时间为50秒)。

数字16描述了接入节点的上行链路的行为。在开始的时候，没有STB已经记录在本地频道内容。所有机顶盒都接收来自所述服务器TSTV的TSTV流，消耗然后接入节点的上行链路带宽。此后的最小观看和达到记录时间;机顶盒开始分享内容与邻国机顶盒和用户停止从TSTV服务器请求它。因此，接入节点的上行链路带宽下降显着。

5.结论

本文提出了一种新的解决方案，通过在用户机台上实现单播同行辅助解决方案，有效地管理TSTV业务在IP网络上消耗的单播流量的带宽资源。这意味着如果有一个STB已经加入了一个通道，并且这个通道被连接到同一个访问节点的另一个STB请求，这个STB可以将TSTV单播流量发送到它的邻居而不是中央TSTV服务器。在没有STB拥有此内容的情况下，TSTV服务器将按照常规的TSTV解决方案自行将单播流量交付给请求用户STB。

全过程由中央服务器TSTV基于从从访问服务器接收的机顶盒和机顶盒位置接收信道改变请求中收集的信息来控制。

我们的解决方案并不需要在其他网络元素的任何额外的资源或新加硬件的整合。它只需要时移电视服务器和用户STB上都有些软件升级或者调整。对于未来的发展，我们将扩大这一新的解决方案从用户机顶盒之间的通信以效益优化VOD（视频点播）的单播带宽。

数据可用性

用于支持本研究结果的数据包括在文章中。

信息披露

我们的研究是由我们自己资助的。

利益冲突

作者声明，这篇论文的发表没有任何利益冲突。

参考

M. Verhoeyen，D.德Vleeschauwer，和D·罗宾逊，“内容存储架构来推动IPTV服务”贝尔实验室技术期刊卷。13，没有。3，第29-44，2008年。查看在：发布者网站|谷歌学术搜索
K. Kerpez，Y.洛，和F. J. Effenberger，“通过局部对等网络（P2P）视频带宽还原，”国际数字多媒体广播杂志， 2010年卷，文章ID 562832, 10页，2010年。查看在：发布者网站|谷歌学术搜索
T. Jursonovics和S. Imre，“用于IPTV解决方案的无线家庭网络中的带宽管理”，国际数字多媒体广播杂志卷。2013年，文章编号474212，7页，2013。查看在：发布者网站|谷歌学术搜索
一个可扩展的DVB分发的软件和硬件IPTV架构，"国际数字多媒体广播杂志卷。2009年，文章编号617203，9页，2009年。查看在：发布者网站|谷歌学术搜索
T. H. Szymanski的和D.吉尔伯特，“互联网骨干网的IPTV组播系统的设计，”国际数字多媒体广播杂志， vol. 2010, Article ID 169140, 14页，2010。查看在：发布者网站|谷歌学术搜索
R、 Droms，“动态主机配置协议”，技术代表，网络工作组，1997，https://tools.ietf.org/pdf/rfc2131.pdf。查看在：谷歌学术搜索
L. Mamakos，K.利德尔，J.埃瓦茨，D.卡雷尔，D.西蒙和R.惠勒，“用于发射以太网上点对点协议的一种方法（PPPoE的），”技术。众议员，1999。查看在：谷歌学术搜索
肖夫和伯恩斯坦，介绍IGMP用于IPTV网络，2006年。
蔡宏杰，“减少IPTV频道的时间，基于观众的上网行为和偏好，”在2008年IEEE宽带多媒体系统与广播国际研讨会论文集，2008年宽带多媒体研讨会论文集，BMSB，美国，2008年4月。查看在：谷歌学术搜索
H、 Schulzrinne，S.Casner，R.Frederick和V.Jacobson，“RTP：用于实时应用的传输协议本备忘录状态”控制RFC3550, 2003年。查看在：发布者网站|谷歌学术搜索
“部署下一代启用多播的应用:为MPLS、VPNs、VPLS和批发以太网标记交换多播，”摩根考夫曼,2012年。查看在：谷歌学术搜索
十、 Tian，Y.Cheng和X.Shen，“IP视频传输的快速频道切换和面向目的地的多播”IEEE交易在并行与分布式系统，第24卷，no。2，第327-341页，2013年。查看在：发布者网站|谷歌学术搜索
C.-Ch。温家宝和Ch.-S。吴，“QoS在基于混合树的显式路由组播网络上支持IPTV服务架构”，国际数字多媒体广播杂志卷。2012年，文章编号263470，11页，2012。查看在：发布者网站|谷歌学术搜索
T. Arul和A. Shoufan， "通过IPTV免费订阅付费电视，"系统体系结构杂志，第64卷，第37-49页，2016年。查看在：发布者网站|谷歌学术搜索
Yoon, S. Park和S. Choe，“在GEPON中实现快速IPTV频道转换的EIGMP”，IEEE交易消费电子，第57卷，第2期，第484-4911911页。查看在：发布者网站|谷歌学术搜索
A. Nikoukar，I.-S.黄某，A. T.列姆和J.-Y.李，“减轻IPTV激活时间增强EPON系统”光通信和网络杂志，第8卷第1期。6、第451-461页，2016。查看在：发布者网站|谷歌学术搜索
R.海米-Cohen和P. J.赫恩，“迟组播加入快速信道改变处理，”美国8161515 B2,2012年。查看在：谷歌学术搜索
B、 Ver，A.Begen，T.Van和Z.Vax，“基于单播的多播RTP会话快速获取”，技术代表RFC62852011年。查看在：发布者网站|谷歌学术搜索
E. H. Khabbiza，R.埃尔阿拉米和H. Qjidaa，“一种新的方法，以减少在高速接入网络的IPTV系统的单播带宽，”国际数字多媒体广播杂志， 2017卷，文章ID 2456814, 9页，2017。查看在：发布者网站|谷歌学术搜索
第4a卷-IPTV协议序列示例，[V2.3]-[2014-01-24]，“开放式IPTV论坛第2版规范”http://www.oipf.tv/web-spec/volume4a.html。
Y.-F.R.陈，R.亚娜，D. Stern等，“斑马马：使用IPTV的数据支持STB辅助VOD内容传递”。多媒体系统，第16卷，第3期，第199-214页，2010年。查看在：发布者网站|谷歌学术搜索
卓，李，吴，徐，“时移电视服务器集群的高效缓存放置方案”，IEEE交易消费电子，第54卷，否。4、1947-1955年，2008年。查看在：发布者网站|谷歌学术搜索
向，吴，林，王，“时移电视在HFC网路上的分段修补”，IEEE交易消费电子卷。53，没有。3，第891-897，2007。查看在：发布者网站|谷歌学术搜索
E. H. Khabbiza, R. El Alami和H. Qjidaa，“优化时移电视带宽的新解决方案”，in2018年国际会议的智能系统和计算机视觉，ISCV 2018论文集，第1-5页，摩洛哥，2018年4月。查看在：谷歌学术搜索
Itu-T，超高速数字用户线收发器，2004。
Itu-T， " G.984.1千兆比特无源光网络(GPON):一般特性，"网络，第1-43，2008年。查看在：谷歌学术搜索
DHCP中继代理资讯选项>，技术代表3046,2001。查看在：发布者网站|谷歌学术搜索
五Mammoliti，G佐恩，P. Arberg和R.雷尼森，“DSL论坛供应商特定的RADIUS属性，”技术。众议员。4679，2006年。查看在：发布者网站|谷歌学术搜索
D、 I.艾伦，“NFVI的ENF选择，20160156718，2016”。查看在：谷歌学术搜索
“红花蜜”Chris Welsh, GNS3网络模拟指南。帕克特出版有限公司，2013年。
法伦、拉特雷、比利安、达乌德、戈蒂埃和斯坦纳克，VLC用户指南，2003。
J.凡德尔米尔，D.麦基，五斯瓦米纳坦，D.歌手，和P. Gentric，“rfc3640：RTP负载格式MPEG-4基本流的运输，”Netw。工作。Gr，2003。查看在：谷歌学术搜索
RFC 2328, J. Moy，“互联网工程任务组”，Netw。工作。Gr Ascend Com, 1998。
B.芬纳，M.汉德利，H.布鲁克和I. Kouvelas，“协议无关组播 - 稀疏模式（PIM-SM）：协议规范（修订版），”Netw。工作。GrRFC4601，2006年。查看在：发布者网站|谷歌学术搜索