前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >泛广电领域的卫星传输和公网传输

泛广电领域的卫星传输和公网传输

原创
作者头像
LiveVideoStack
修改2019-11-13 17:02:50
7970
修改2019-11-13 17:02:50
举报

随着广播电视的不断发展与消费者对于音画体验的要求不断提升,传输方式亟需与时俱进迎来新的变革。安徽广播电视台的张博力将从卫星传输、公网传输SRT协议理论入手,通过分析链路测试报告,给出4K卫星传输的链路搭建方案,并重点分析在实际应用中如何保证公网传输的安全性和可用性。

文 / 张博力

整理 / LiveVideoStack

大家好,我是来自安徽广播电视台的张博力,接下来我将为大家详细介绍泛广电领域的卫星传输和公网传输。

随着广播电视的不断发展与消费者对于音画体验的要求不断提升,传输方式亟需与时俱进迎来新的变革,这不禁让我们感到好奇:4K时代卫星传输能否胜任?公网传输作为一种新的选择,能否担当起主流广播电视服务的传输责任?

我是电视台的技术工作者,按照传统广电的理论,广播电视台的工作可以简单概括为以下几点:采、编、播、存、传——也就是采集、编辑、播出、存储、传输。但是现在,无论你是制作公司还是个人用户,只要拥有这五项工作所需要的设备,你就可以组建出属于自己的类广播电视系统,所以我们今天讨论的也是在泛广电领域下,卫星传输与公网传输的前世今生与未来发展。

现代泛广电领域的工作流程,按顺序可以简单概括为“制作”、“传输”与“分发”,这与之前传统广电领域“制作”、“分发”与“传输”的顺序有所不同,主要原因是这里我们分享与讨论的“传输”,是指从制作端到分发端的高效可靠低延迟B to B传输。

这里我们可以选用多种传输方式,最常见的就是传统广电领域使用多年的卫星传输和现在逐渐流行的公网传输。

1. 卫星传输

这里的卫星是同步轨道卫星,随地球一起自转,相对于地面的位置始终不变。转播车将数据沿卫星链路发送给同步轨道卫星,再借助卫星发送至电视台制作基地。不需要线缆、网络即可完成跨国甚至洲际间广播电视传输,稳定可靠。

1.1 卫星链路传输解析

上图展示的就是卫星链路的传输示意图。

首先在发射端,我们传输的数据肯定不能是基带信号而是经过信源编码的信号,这里以HEVC为例。HEVC编码完成的信号在传输之前还需要经过信道编码(FEC编码)、交织星座映射、I/Q调制与数字预失真以及SRRC滤波器等一系列处理,接下来还需经过上变频放大器(BUC)与高功率放大器(HPA)提高信号频率与功率,处理完毕的信号会通过天线沿上行链路传输至卫星转发器;卫星转发器这里接收信号后再将信号放大并发射,信号沿下行链路传输至制作基地的接收端并在接收端经过一系列与发射端反向的信号处理工作之后,基带信号才算是正式传输完毕。

上图展示的卫星传输链路设备图可以更直观地说明卫星传输链路的工作流程。首先,第一步信源编码需要超高清编码器,随后的调制则需要调制器的参与;接下来的上变频与高功放处理模块则是为了让信号更加稳定可靠地沿上行链路传输至卫星,而卫星天线则负责发射信号;由卫星天线发射的信号被高频头接收,并经过解调器的解调处理和解码器解码,获得目标信号,这也是安徽广播电视台构建的全国第一套KU波段车载4K卫星传输系统。

1.2 卫星链路传输面临的挑战

为什么说4K给卫星传输带来了新的挑战?我们知道4K相对于1080i,其分辨率提升到四倍,帧率提高到两倍而基带码流提高到8倍。如果使用传统H.264编码方式,4K下的码流是原有全高清码流的8倍,;而如果使用H.265进行编码,4K下的码流则是原有全高清码流的4倍,其所带来的编码效率提升是显而易见的。

尽管如此,4倍的码流提升对卫星传输而言也是一项艰巨的挑战,因为卫星传输是一种典型的带宽受限的传输系统。

一颗卫星由火箭送入太空,需要在太空工作十几年;十几年的技术发展突飞猛进,用户对于高质量音画体验的追求越来越高,但卫星的传输带宽却始终不变;而卫星无论是其发射代价还是运营维护成本都十分高昂,频繁升级其带宽也是不现实的。这就需要我们充分利用有限的卫星带宽资源实现传输质量的最大化,而究竟能充分利用到什么程度呢?数学家克劳德·香农给出了这个问题的答案。

1948年数学家克劳德·香农在论文《通信的数学原理》与《噪声下的通信》中,给出了在加性高斯白噪声信噪下信道的最大容量:

最大容量只由信噪比与带宽两个变量决定,也就是我们如果知道带宽与信噪比,就能推断出该条件下所能传输信号的最大码率。

例如在30dB的信噪比下,信号与噪声之比为1000倍,有线传输(同轴电缆等)所能承载的最大数据容量为带宽的10倍;如果是在卫星传输中常见的10dB信噪比下,那么最大容量为带宽的3.46倍。这一数值也就是10dB信噪比下卫星传输的极限值,使用卫星传输的广播电视行业也是在用一代代演进的标准逐步逼近这一极限值——香农极限。

1.3 卫星传输标准的演进

于是我们不能不说的就是卫星传输标准的演进。1993年,DVB-S正式被作为一套完整的适用于卫星传输的数字电视系统规范,我国也是率先采用了DVB-S。2005年推出的第二代卫星传输的数字电视系统规范DVB-S2采用了新的信道编码方式——LDPC内码与BHC外码,有效提高了频谱效率;2015年提出的扩展标准DVB-S2X则支持更低的滚降系数和更高阶的调制方式,进一步逼近了香农极限。

DVB-S2X是如何逼近香农极限呢?如下图所示,图线表示的是载噪比和频谱效率的比值,虚线是香农极限也就是上限。可以看到表示DVB-S2X的红色图线已经非常接近香农极限,而表示DVB-S2的蓝色图线略逊于DVB-S2X。在低滚降系数下信噪比和载噪比的数值是比较近似的,结合刚才的计算我们可以来看一下,以刚才我们提到的载噪比10dB为例,刚才我们计算的10dB下信道最大容量为带宽的3.46倍,观察图线我们可以发现DVB-S2X的频谱效率不到3倍,香农极限约为3.5倍,与我们的计算结果相符合。

1.4 DVB-S2

接下来我们需要了解DVB-S2的系统框架,下图展示的为DVB-S2的系统框图。

可以看到信号会首先被输入至模式适配与流适配工具,在这里进行合并分割、与结合基带信令的流适配;随后信号进入前向纠错编码处理,这里我们以3/4编码为例(可以简单理解为4个数据里面有3个有效数据1个纠错数据),前向纠错编码(BCH外码+LDPC内码+比特交织)之后信号会经过星座映射与物理层组帧,最后进入基带成形与正交调制阶段。非常重要的一点是在基带成形阶段其滚降系数在DVB-S2X标准下会发生很大变化,0.35可能降到0.05,滚降系数降低意味着信道编码效率的提高。

1.4.1 滚降系数

在相同带宽情况下,滚降系数0.05时符号率更高,波形中平坦的部分更宽,而0.2则相对较窄。尽管滚降系数提高了效率,但滚降系数越低其信号强度也越小。从图中我们也可以看到滚降系数为0.2时的信号,其强度要高于滚降系数为0.05时的信号。根据计算,如果滚降系数从0.2降到0.05,那么接收的信噪比会降0.6dB,这种信噪比的降低是否值得?

带宽=符号率*(1+滚降系数)其中符号率为单位时间内所能发送的符号数,也就是实际利用可以传输数据的有效带宽当中平坦的部分。

以卫星传输常租用的9M带宽来计算,当滚降系数为0.35时,传输所能使用的带宽仅为6.67M;而当滚降系数降低至0.05时,传输所能使用的带宽最高可达8.57M,相对前者提升了28.5%。以信噪比降低0.6dB为代价,换来28.5%的可用带宽提升,这对我们来说是非常划算的选择。可以说滚降系数的降低是一项非常出色的改进,应当善加利用。

低滚降所带来的28.5%的可用带宽提升实际上还无法满足4K的传输需求,所以我们还需要优化调制方式。下图坐标系中包含了卫星传输常见的调制方式,包括QPSK、8PSK、16APSK、32APSK。如何理解坐标系呢?坐标系的横轴与余弦初始相位同向,竖轴与其正交,该坐标系包含了调制所需的所有相位(调制)资源和幅度(调制)资源。

1.4.2 调制方式

首先,QPSK也就是二阶调制下,4个状态点均分360度,每个状态点相位相差90度;可以理解在接收端,相位相差90度的正交相位点易于识别和解调。接下来8PSK也就是三阶调制下,8个状态点均分360度,每个状态点相位相差45度,解调端解调的难度相对于二阶调制更大。

此时调制方式的发展面临瓶颈:如果从三阶调制升级到四阶调制,意味着16个状态点均分360度,状态点之间的相位差为22.5度,过小的欧拉距离极容易导致相位模糊和符号间干扰,继而造成接收端很难对信号进行有效解调。突破该瓶颈的解决方案是结合相位调制和幅度调制,如16APSK所示那样将外圈分为12个状态点而将内圈分为4个状态点,以此凑齐了16个状态点。有的状态点尽管同相位但幅度不同,通过幅度与相位双重调制,我们实现了四阶调制16APSK。四阶调制的意思是如果不考虑前向纠错带来的效率损失,其频谱效率可达4倍,实际频谱效率我们可以通过观察下图获知。

根据上图我们不难发现,在16APSK下,当LDPC纠错码率为3/4时(为保证信道可用,纠错是必需的过程) 频谱效率可达3倍。这样的频谱效率可以说是非常可观了,我们可以看到在32APSK下,当LDPC纠错码率为0.9时,频谱效率为4.5。要知道在符号率与带宽一定的情况下,更高的频谱效率意味着可以传输更高的码流,但是如此高性能高效率也是有一定代价的,那就是高阶调制和高纠错旅会大幅提升接收门限。

1.4.3 接收门限

根据上图表格我们可以看到,MOD=QPSK、COD=3/4而频谱效率为1.487时的接收门限为2.3,MOD=16APSK、COD=9/10而频谱效率为3.567时的接收门限为7.6,如此高的接收门限无论是对发射天线还是接收卫星而言都是一项巨大的挑战。如果追求极致的效率与极致的性能,我们也要付出极致的代价,甚至要冒着接收失败的风险,这无疑是得不偿失的。

我们可以认为低滚降系数与高阶调制可以提升频谱效率,而高阶调制与高纠错率却也提升了接收门限。但接收门限是一项必须被控制在合理范围之内的参数,如果接收门限过高那么就意味着连正常的信号接收都无法保证,其他性能指标的提升都是纸上谈兵。这时大家都会想到一个问题:为什么不能增加信噪比?只要信噪比增加的幅度追得上接收门限的提升,就可以不用担心此问题?在解答该问题之前我们需要对卫星传输链路进行详细分析。

1.5 卫星传输链路需求

由于受到硬件设备的客观限制,卫星链路传输中许多参数为固定值,想提升基于卫星链路传输信号的信噪比并不是一件容易的事情。例如转发器接收品质因数G/T与转发器最大下行EIRP均无法改变,都导致卫星传输链路当中信噪比不能无限制地增加。于是提升频谱效率的同时有效控制接收门限,是我们解决卫星传输4K广播电视信号需要践行的技术关键。如何找到二者之间的最佳平衡?通过大量的测试!

上图展示的测试数据结果是我们完成的可能是国内第一个KU波段的4K卫星链路信号测试,我们其实是使用了许多参数组合,在不同参数组合下选择不同的带宽和符号率并实际测量了接收信号的信号强度、载噪比、载噪比余量等,最后得出了最合适的四个参数组合(图中背景灰色高亮的四行数据)。观察这四组数据我们可以看到前三组数据的实际可用码率都在40Mbps左右,也就是说4K广播电视信号经过HEVC编码之后,如果码率在40Mbps左右,其质量可以说非常出色了,这也表示该三个信道可以满足4K广播电视信号的传输需求;如果带宽实在受限,例如只有与高清一样的9M带宽,那么我们只能选择合适的参数也就是第18组参数,可以在确保接收门限合适的情况下实现大概27Mbps的编码后码流。

总结以上内容,我们可以认为卫星传输链路具有以下三大需求:

  1. 足够大的可用比特率意味着经过信源编码后的码流可存储更多的信息,音画质量更加出色;
  2. 足够低的接收门限意味着信号需要能被稳定传输;
  3. 足够小的占用带宽则是源于卫星传输链路的特殊性,系统限制非常多。

但三个需求全都达到极致是不可能的,我们需要寻找到一个合适的平衡点,而寻找该平衡点的重要参数为以下三个:调制方式、前向纠错与滚降系数。这三个参数会在不同程度上同时影响频谱利用率与接收门限,这就使得每一条卫星链路的搭建都需要进行链路测试并寻找到合适的参数组合与设备选型。

传统基于卫星传输的广播电视系统,鉴于其高昂成本与复杂架构,只有大公司或公共电视台才有能力使用;而进入4K时代,成倍增长的数据传输量更是将卫星发射、链路组建和运维成本提到了新的高度。于是公网传输提供了一种新的选择,逐渐被应用在广播电视领域。

2. 公网传输

这里我们只讨论单播协议,更多的是指点对点的传输。有多种选择例如RTMP、SRT、ZIXI、UDP等。其中RTMP虽然门槛低但由于基于TCP,其无论是时延还是性能都不尽如人意;而基于UDP且带纠错与差错控制的协议如SRT、ZIXI等也是点对点传输,如果网络条件足够好,那么你也可以使用裸露的UDP协议。

接下来我们详细聊一聊SRT协议。

2.1 SRT协议与其特性

SRT为“Secure”、“Reliable”与“Transport”三个单词的首字母,意思是安全可靠传输协议,由Havision公司开发并将其开源,是一个基于UDP的传输协议。我想大家听到UDP心里不禁会产生疑问:UDP协议可靠吗?

实际上,尽管UDP的效率比较出色,但其并不是一个可靠的传输协议,无法对传输结果负责。

下图展示的是在模拟2%丢包的网络环境下使用UDP协议传输的测试结果,卫星链路传输与公网传输的目的是一致的,都是将信源编码后的视音频码流传输到目的地。这里对比编码后的视音频码流与经过公网传输后的码流,可以看到原来编码后的视音频码流具有固定的帧间隔与一定特性的可变比特率,但经过公网传输后的码流,其帧间隔变得不固定且码率特性也被完全改变,解码这样的信号是一项十分艰巨的挑战,甚至根本无法解码。

而如果使用加入纠错的SRT协议进行公共互联网传输,尽管编码后的视音频码流经过公网传输帧间隔变得不固定,但由于SRT协议封装中包含精准的时间戳,解码接收端可以通过该时间戳重现固定的帧间隔;更重要的是,通过规定延时量,同时划定了发送端缓冲区与接收端缓冲区,来自接收端的反馈信号(可以理解为后向纠错)通过一系列的设置、纠错、流量控制,使编码后的视音频码流拥有与原码流几乎一样的码率特性。下图展示的就是在模拟2%丢包的网络环境下使用SRT协议传输的测试结果。

为什么SRT可以实现这样的效果?简单分析,原因主要为以下五点:

● SRT以UDP协议为基础,具备稳定、可重复并具有连续吞吐量的数据包投递机制。(这种特性使得其非常适合用来传输实时的音视频广播电视信号。)

● 在UDP之上采用握手机制建立连接

● 使用了改进后的ARQ技术(后向纠错技术)

● 封装协议中带有精准的时间戳(用以实现精准的帧间隔)

● 通过设定延时量参数,统一规定了发送端和接收端缓冲区的大小

2.2 SRT协议原理

上述特性具体是如何实现的呢?下图展示了SRT协议的流程图

首先,SRT的握手远没有TCP的三次握手那么复杂,Caller与Listener之间进行的是一个简化版的握手,用以提高效率;握手之后Caller与Listener间进行重要信息的交换,整个SRT的第一项关键步骤就是Caller与Listener在这里交换了延时量与缓冲区的大小;随后Caller与Listener之间开始媒体数据的传输,同时也传输了为恢复帧间隔而封装的精准时间戳;SRT的第二项关键步骤是Listener向Caller同步控制信息,用以对抗公网中的抖动、丢包等一系列突发状况;最后,待至媒体数据传输完毕之后关闭传输。

这里你也许会感到好奇:控制信息是如何对抗公网中的抖动、丢包等一系列突发状况呢?如何实现差错控制和流量控制?实际上是通过ARQ技术也就是自动重发请求。

2.2.1 自动重发请求ARQ

ARQ技术的基本概念很简单:发送端在将数据包发送至接收端后并不急着把数据包删除,而是等待接收端给出ACK-肯定应答之后才会删除;而如果发送端在将数据包发送至接收端后,接收端给发送端反馈NCK-否定应答,那么发送端会向接收端重新发送数据包,这就是一种纠错机制;或者是在发送数据包之后等待一段时间,如果收到NCK-否定应答那么就会自动重发数据包。

以上图为例,假设发送端缓冲区发送五个数据包:1、2、3、4、5给接收端缓冲区,接收端缓冲区成功接收到这些数据包之后会向发送端缓冲区发送ACK——肯定应答,发送端接收到ACK——肯定应答之后会删除1、2、3、4、5这五个数据包并准备发送数据包6。

在成功接收数据包之后,接收端缓冲区会逐个拿出数据包输送至解码器以进行解码操作,最终输出相应的音视频;在解码的同时缓冲区窗口就会向前滑动,输送下一个待解码的数据包。

以上是不考虑丢包等异常状况的理想网络条件,如果考虑丢包呢?

如上图所示,假设数据包4出现了丢包的情况,那么此时接收端缓冲区需要检测到这一异常并立刻发送NAK-否定应答至发送端缓冲区,发送端会再次发送数据包4。而如果出现返回信息也就是ACK/NCK在网络中丢失,该如何应对?其实SRT对ARQ做出了大量改进,包括重发所有过期的ACK、定期重发NCK策略等。实际上SRT实现了ARQ的第三次飞跃,很好地解决了在网络中的丢包和抖动,可以说这是SRT协议中最重要的部分。

2.2.2 发送端缓冲区与接收端缓冲区

而在实际应用中我们应当如何理解发送端缓冲区与接收端缓冲区?

发送端缓冲区发送信号,只有在收到来自接收端的确认信息之后才会删除数据包,没有收到确认信息则不删除;这种情况下,如果发送端缓冲区充满了数据包,说明一直没有收到来自接收端的肯定应答,数据一直保存在发送端,这可能意味着传输出现了异常。所以SRT在实际应用中需要注意,发送端缓冲区的占用率越少越好。

接收端缓冲区的终极目的是将数据包输送给解码器以进行解码,我们以去自助餐厅吃饭为例:

解码器就像图中的壮汉,需要一直不停地吃,考虑动态码率VBR的作用,壮汉的胃口时大时小;一旦饿着,解码出的图像和声音就会中断。而餐盘其实就像接收端缓冲区,其中一定需要充满了食物也就是待解码数据。尽管一直有人在上菜,就像公网传输码流不断进行,但上菜时快时慢,就像网络带宽有波动,万一网络不好,上菜的速度没有壮汉吃的速度快,即会造成编码的中断,因此我们必须确保餐盘里始终充满了食物。

因此我们得出以下结论:接收端缓冲区必须充满了数据,以让其能够有效应对由于网络带宽波动造成的传输码流不稳定。所以SRT在实际应用中需要注意,接收端缓冲区的占用率越高越好。

将以上内容过渡到实际应用当中,可以帮助我们更好地理解这一规律——下图展示的是安徽广播电视台进行第一次5G直播时的状态监测图。

● 发送端状态分析

首先是发送端状态图:白色线为链路往返的时间,5G下的网络环境已经足够出色,于是可以看到链路往返一直处于较平稳的状态,说明网络环境与带宽质量一直处于较为理想的状态;黄色线为我们规定的延时量也就是发送端缓冲区的大小,之前我们也聊到发送端缓冲区其实占用的越少越好,根据图中可以看到当时占用的发送端缓冲区并不高。

但是即使是5G网络也有网络波动:图中可以看到在网络波动出现时缓冲区的占用也激增,即便如此仍留出了一半左右的安全冗余量。

● 接收端状态分析

接下来是接收端状态图:上图的上半部分中绿色线表示丢包率,可以看到5G网络下的丢包率非常低;下图红色线表示RTT链路往返时间,也是一直处于较为稳定的状态。

上图的下半部分,图中黑色线表示接收端缓冲区的上限也是延时量,最好的情况就是绿色线一直贴着黑色线波动,表示接收端缓冲区一直处于较为理想的高占用状态。

但是在5G网络中难免出现波动,可以看到出现波动时,接收端缓冲区被消耗到实际占用量接近缓冲区的一半,这就是因为网络有波动导致数据无法及时传输至接收端缓冲区,但解码却消耗了接收端缓冲区大量的数据。即便如此,经过大量的前期链路测试,我们仍保证了在波动中能够留出大约一半的安全冗余量。

2.3 公网传输条件

总结一下我们敢于使用公网传输广播电视信号的原因:首先SRT协议支持纠错,其次需要在正式商用之前进行大量的前期链路测试并为发送端缓冲区与接收端缓冲区留出合适且足够的安全冗余量。而在链路搭建阶段,进行网络链路测试时需要着重测试并关注网络带宽、丢包率与RTT也就是链路往返时间。

测试完毕之后,我们可以根据测试结果设定合适的延时量。下图所示表格来自Havision官方,根据计算结果与表格参数我们就可以寻找到不同网络环境下最佳延时量的设定,也就是规定缓冲区的大小。确定最佳延时量并设置完毕,经过一段时间的测试以观察反馈结果。

3. 实际应用

基于以上介绍的卫星链路与SRT协议下的公网传输链路,我们实现了安徽广播电视台首次5G现场直播。

下图展示了直播中所用到的5G链路设备,值得注意的是,由于SRT的开放特性,这里我们使用了三家不同厂商的设备,仍然可以兼容并实现良好协调的使用,这也是开源设备的好处。

3.1 SRT的多码率多格式分发

SRT可实现多码率多格式的分发,这里并不是分发到用户而是分发到不同平台。如果是基于SRT的硬件编码器,则可编码多个分辨率、格式不同的流并分发到不同的平台如电视台、CDN、私有云等。

3.2 SRT在节目制作中的应用

SRT也可应用于节目制作中,甚至在手机上安装一个软件即可收到解码完成的流,这也经常被我们用于节目测试。当然还有在进行一项节目时,编导、摄影师、记者等都希望接收到电视信号,SRT的这种应用可以帮助他们随时随地动态掌握节目进行状态。

3.3 其他商业化应用

基于以上内容,我们成功实现了以下应用案例:如安徽广播电视台首次5G直播、“长江之恋”十二省市联动大型直播以及超铁赛事在中国大陆的首次亮相,都是基于卫星链路与SRT协议下的公网传输,这也为我们探索未来广播电视传输技术发展积累了丰富的经验。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 卫星传输
    • 1.1 卫星链路传输解析
      • 1.2 卫星链路传输面临的挑战
        • 1.3 卫星传输标准的演进
          • 1.4 DVB-S2
            • 1.4.1 滚降系数
              • 1.4.2 调制方式
                • 1.4.3 接收门限
                  • 1.5 卫星传输链路需求
                  • 2. 公网传输
                    • 2.1 SRT协议与其特性
                      • 2.2 SRT协议原理
                        • 2.2.1 自动重发请求ARQ
                          • 2.2.2 发送端缓冲区与接收端缓冲区
                            • 2.3 公网传输条件
                            • 3. 实际应用
                              • 3.1 SRT的多码率多格式分发
                                • 3.2 SRT在节目制作中的应用
                                  • 3.3 其他商业化应用
                                  相关产品与服务
                                  云直播
                                  云直播(Cloud Streaming Services,CSS)为您提供极速、稳定、专业的云端直播处理服务,根据业务的不同直播场景需求,云直播提供了标准直播、快直播、云导播台三种服务,分别针对大规模实时观看、超低延时直播、便捷云端导播的场景,配合腾讯云视立方·直播 SDK,为您提供一站式的音视频直播解决方案。
                                  领券
                                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档