版本说明书

Transcription

1 华为 ilab 极致体验 VR 技术白皮书 面向 VR 业务的承载网络需求白皮书 (2016) 华为 ilab 发布

2 1 VR 业务和应用概述 虚拟现实 (VR) 被誉为 下一代互联网 和 下一代计算平台 根据业界的共识,VR 是计算机构造出虚拟环境 (Virtual Environment), 这一环境可以来自复制的真实世界, 也可以是想象的灵境, 人在这一具备立体空间信息的虚拟环境之中进行实时的互动 VR 具有多感知性 (Multi-Sensory), 根据 J.J.Gibson 提出的概念模型 : 人的感知系统可划分为视觉 听觉 触觉 嗅 / 味觉和方向感等 5 部分 因此 VR 应当在视觉 听觉 触觉 运动 嗅觉 味觉向用户提供全方位的表现, MPEG 研讨会议上, 也认为 VR 是一种不同于视频和音频的新媒体类型 根据这一定义,VR 的概念覆盖了很多种关键技术和应用形态 例如 VR 涉及的关键技术包括 : 360 全景视频 ; 自由视角技术 (Freeview-point); 计算机图形学 (Computer Graphics); 光场技术 (Light Field ) 等 基于上述关键技术,VR 可以衍生出很多应用形态 (application) 例如基于 360 全景视频技术的在线点播和事件直播, 基于自由视角技术的在线点播和事件直播, 基于计算机图形学的 VR 单机游戏 VR 联网游戏 VR 仿真环境等 1

3 这些应用形态也会对应到不同的市场场景 (scenarios), 例如高盛将 VR 的市场领域分为游戏 事件直播 娱乐视频 医疗保健 房地产 零售 教育 工程和军事 VR 的三要素是 : Spatial 用户感知到的虚拟环境信息是立体空间的, 蕴含着海量信息 Interact 用户能够和虚拟环境中的空间数据以及其他用户进行信息互动, 信息在用户间形成连接与流动 Real-Time 用户在虚拟环境中的信息互动是实时的, 要求信息连接的实时性 根据 VR 的三要素, 无论是哪一种 VR 应用, 在变为网络在线应用时都涉及海量信息的实时连接和流动, 都会不可避免地对网络架构产生新的影响和挑战 2

4 2 VR 360 视频是最先繁荣的在线 VR 业务 2.1 VR 360 视频产业发展趋势分析 VR 360 视频提供了观察者所在物理位置上水平方向 ( 经度 )360 度 垂直方向 ( 纬度 ) 180 度全包围的物理空间视域, 用户可以通过改变头部的位置 或者通过鼠标 遥控器等输入设备实现视角的切换, 从而带来身临其境的体验 结合对用户 技术 硬件 内容 标准等产业要素的分析, 我们认为在 VR 的诸多关键技术和应用形态中, 基于全景视频 (Panoramas) 技术的 VR 360 视频将成为最先繁荣的在线 (Online)VR 应用 根据高盛 2016 年发布的 VR/AR 产业报告, 基于 360 全景技术的 VR 事件直播和 VR 视频娱乐到 2020 年将拥有 5200 万用户, 其中事件直播 2400 万, 视频娱乐 2800 万, 占 VR 应用领域全部预期用户 (1 亿 3 千万 ) 的 40%, 而到了 2025 年,VR 360 视频的用户群将达到 1 亿 7 千 4 百万, 其中事件直播 9500 万, 视频娱乐 7900 万 3

5 单位 : 万 目前, 在互联网行业的率先布局带动下,VR 360 视频的内容源和用户群已初具规模 : 近一年来的在线 VR 360 视频内容源增长迅速 Youtube 设置了 360 视频专区, 新上传的 VR 360 视频达 8000 多部 ; 为 Samsung Gear 和 Oculus CV1 提供内容的 Oculus 360 Video 市场片源数量已达 1000 部以上 ;Vrideo 是专注于 360 视频的内容平台, 为 HTC Vive Oculus 和 Samsung Gear 提供高质量的 360 视频在线内容, 其中全视角 4K 分辨率的 360 视频已达 400 多部, 占其总量的 70%; 国内传统的互联网视频公司优酷 乐视和爱奇艺也已设置 360 视频专区, 专注于内容生态的建设, 片源多为自制的综艺类节目, 数量也已有数百部 ;Next VR 的在线业务包括 VR 360 直播 / 回放 VR 360 电影和纪录片点播, 已成功地为 NBA 美国高尔夫球公开赛 国际冠军杯等知名赛事进行了高质量的 VR 360 直播 VR 360 视频消费同样飞速增长 VR 视频的用户群和点击量也颇为可观, 特别是热门视频 Youtube TOP N 的热门 360 视频日均点击可达 20.5 万, 优酷 VR 频道热门 360 视频日均可达点击 4 万,Samsung Gear 也已拥有 100 万月活跃用户 2.2 VR 360 视频用户行为趋势分析 用户业务渗透率预测 VR 360 视频业务的用户渗透率及其带来的流量趋势, 对分析其对承载网架构的影响至关重要 2016 年互联网女皇玛丽 米克尔发布的 互联网趋势 报告显示,2015 年底全球互联网用户已达 30 亿, 增长率呈稳定下降趋势, 连续四年维持在 10%~9% 之间 我们结合历史数据和咨询公司分析报告数据, 使用几种常用方法得到的全球互联网用户趋势数据如下 : 4

6 年份 线性趋势预测 (9%~8% 之间 ) 30 亿 38 亿 44 亿 58 亿 二项式趋势预测 30 亿 38 亿 44 亿 62 亿 分析师报告 / 36 亿 (emarketer) / 47 亿 ( 微软 ) 结合上述数据, 我们可取 2020 年和 2025 年的全球互联网用户数的预测值为 44 亿和 60 亿 根据高盛报告给出的 VR 360 视频用户数预测, 届时用户渗透率如下 : 应用业务渗透率 2020 年 2025 年 VR 娱乐视频 0.55% 1.32% VR 事件直播 0.65% 1.58% 用户观看习惯和平均流量预测 如前文所述, 在 2016 年现有的 VR 技术下, 由于终端和内容的体验问题, 用户单次观看时长很难超过 20 分钟 在 VR 360 视频普及的过渡期, 业界会采用传统终端和 HMD 互补的折衷方案 而随着终端和内容的体验的改善, 用户单次观看时长也在不断增加 我们预测到 2020 年, 用户单次观看时长最长可达到 60 分钟, 到 2025 年, 用户单次观看时长最长可达到 120 分钟以上, 与现在的传统长视频观看习惯相仿 (1) 视频娱乐 中国 VR 用户行为调查 (2016) 指出, 目前 VR 用户的日均使用时间是 34 分钟, 用于观看 VR 360 视频的时间约为 10 分钟 高盛报告则认为,VR 娱乐视频的潜在用户群与今天的 Netflix 在线视频用户类似 从长期角度讲, 这也是 VR 视频内容的目标市场,2025 年 VR 娱乐视频应当达到 Netflix 传统视频用户的收视水平 而据 TDG Research 在 2015 年的研究表明 Netflix 全球范围内的订阅用户日平均观看时长达到 93 分钟, 这也是我们预测在 2025 年 VR 360 娱乐视频用户的日均观看时长 考虑到终端的特点, 我们认为 VR 360 娱乐视频的更多应用场合是家庭客厅, 在用户在晚间休闲时段 (19:00-23:00) 和其他时段的使用时间占比为 8:2, 也就是说, 晚间休闲时段平均每小时用户观看时长可以视为日均观看时长的 20% 由于一个用户群在并发使用业务时流量的削峰填谷效应, 可以视作用户使用业务产生的总流量在一小时内是均匀分布的, 基于这个推论我们可以近似得到观看娱乐视频的用户产生的平均流量 5

7 年份 日均观看时长 ( 分钟 ) 晚间休闲时段 (19:00-23:00) 比例 80% 80% 80% 晚间休闲时段 (19:00-23:00) 每小时每用户产生业务时长 ( 分钟 ) 晚间休闲时段 (19:00-23:00) 流量 B:VR 360 视频码率 2*60*B* N1/ *60*B* N1/ *60*B* N1/3600 N1: 网内 VR 娱乐视频用户数 (2) 事件直播 根据高盛 2016 年报告, 最初用户每年将观看 2 场事件直播 随着内容的丰富, 观看数量会越来越多,2025 年将达到近 4 场 演唱会的时间长度多在 1.5 小时到 2 小时之间 ; 一场 NBA 篮球赛的直播时间长度在 2~2.5 小时之间 ; 一场足球赛的直播时间长度在 2 小时左右 综合取一场事件直播长度为 2 小时 考虑到事件直播的收视具有极其明显的潮汐效应, 使用日均观看时长无法合理反映事件直播的用户习惯, 应引入收视率来衡量其对网络的影响 收视率是指某一时段内收看某一节目的人数占观众总人数的百分比, 我们认为一个直播事件可根据其影响范围和关注度, 分为重大事件 ( 如奥运会开幕式, 抗战 70 周年阅兵 ) 热点事件 ( 如美国总统大选 ) 和一般事件 ( 如演唱会 综艺节目只有特定兴趣和偏好的用户会关注 ) 我们将获取到的历史上这些事件的直播收视率数据, 作为分析的参考 同时由于公知性常识, 我们认为某个量级的事件收视率不会随着时代变迁而发生巨大变化, 影响不同年代事件直播流量的因素更多取决于 VR 360 视频的码率和事件直播用户总数 重大事件热点事件一般事件 收视率 R 8%-15% 2%-8% 0.5%-2% 事件直播期间流量 B:VR 360 视频码率 N2: 网内 VR 事件直播用户数 N2*R*B (3) 叠加情况 : 年份 直播事件发生在晚间休闲时段 (19:00-23:00) 2*60*B*N1/3600+ N2*R*B 10.4*60*B*N1/3600+ N2*R*B 18.6*60*B*N1/ N2*R*B 直播事件发生在其他时段 N2*R*B( 其他时段的点播流量和晚间休闲时段相比较小, 可忽略 ) 6

8 3 VR 360 视频的业务原理和网络要求 3.1 全视角和 FOV 用户在虚拟环境中的视野可以认为是一个空间球, 左右横向全视角展开是 360 度, 上下纵向展开是 180 度 用户在使用终端时, 单眼实际看到的视觉信息只是全部球面数据的一部分, 这部分面积由终端提供的视场角决定 (Field of View, 即 FOV) 如 FOV 为 90 度, 则单眼可视信息仅为球面信息的 1/8;FOV 为 120 度, 单眼可视信息仅为球面信息的 2/9 如果在电视 /Pad/Phone 等传统终端上使用 VR, 视场角远小于 90 度, 则不涉及这一概念 3.2 画质体验和交互体验 VR 面临的体验问题可分为感官体验问题和生理体验问题, 业界迫切需要克服生理体验问题以加速 VR 普及 目前生理体验主要有四类问题, 业界也在探索这些问题的改进方向 问题 1: 视觉信息质量 根据众所周知的常识, 过低的画面质量引发的视觉疲劳会带来眩晕感 业界近几年的重点努力方向是 VR 360 视频的内容质量优化, 提升分辨率和画质效果 问题 2: 头动和视野延迟 ( Motion-to-Photons Latency, MTP) 业界的主流观点认为, MTP 延迟不能超过 20ms, 否则会引起眩晕感 目前领先的 VR 终端厂商如 Oculus HTC Vive 已经通过提升端到端软硬件性能, 从传感追踪元件 显示屏技术 GPU 入手, 已经将 Motion-to-Photons Latency 本地化削减至了 20ms 7

9 问题 3: 运动感知冲突 如果运动反馈输出缺失, 导致人的身体运动与眼睛看到的虚拟信息不匹配, 因而产生眩晕感 要解决这个问题, 需要业界丰富 VR 终端的多感知性, 提供包括视觉 听觉 触觉和动作反馈的融合能力, 充分发挥 VR 新媒体的作用 问题 4: 视觉辐辏调节冲突 (vergence-accommodation conflict): 即调焦冲突, 存在于利用双目视差原理的显示终端上 由于屏幕发出的光线并没有深度信息, 眼睛的焦点就定在屏幕上, 眼睛的焦点调节与视觉景深不匹配, 从而产生眩晕 这一体验问题需要新技术解决, 即通过光场记录和投影技术, 记录并还原光从空间立体中的点发射的强度和角度, 让人眼的视觉辐辏和焦点匹配 这一技术将在未来发展的更为成熟 本章节主要对业界近年重点突破的两个问题进行阐述, 视觉信息质量对应画质体验, 头动和视野延迟对应交互体验 画质体验 由于虚拟现实中存在视觉全视角和 FOV 的区别, 传统意义上描述 OTT 视频的分辨率对应于 VR 360 视频的球面全视角分辨率, 真正决定 VR 360 视频画质体验的是单眼分辨率 (FOV 分辨率 ), 可换算为在 FOV 区域中每个角度可见的像素数量 (Pixels per degree, PPD) PPD 数值越高, 视场的像素密度越高, 画质体验就越好 正常视力的用户可分辨的 PPD 是 60, 如果 PPD 大于等于 60, 普通人眼将无法分辨像素点的间隔 以 Youtube 的在线 VR 360 视频为例,4K 分辨率的片源, 使用 H.264 编码最高等级的平均码率约 20Mbps, 但球面全视角 4K 分辨率在单眼下的实际可视分辨率为仅为 960*960, 对应到 90 度视场角的仅有每度 10 个像素, 远远低于正常视力视网膜要求的 60 个 PPD, 实际视频体验比在传统 TV/PC/Pad 上看 SD 视频还差 屏幕类型 屏幕大小 ( 英寸 ) 观看距离 ( 米 ) 宽度 ( 米 ) 高度 ( 米 ) 水平分辨率 垂直分辨率 PPD FOV TV PC Pad 由上述例子可知, 由于 VR 的沉浸性终端 (HMD) 拥有远高于传统终端 (TV/PC/Pad/Phone) 的视场角, 决定了要达到同样等级的画质体验, 相同的 PPD 要求 VR 360 视频具有更高的单眼分辨率和全视角分辨率 全视角的 4K 分辨率远不能达到满意的视频质量, 加大分辨率到 8K 及以上是必须的 以 FOV=90 为例, 全视角分辨率达到 8K 时, 单眼分辨率为 1920*1920, 对应 PPD=22; 全视角分辨率升级 12K 时, 单眼分辨率为 2880*2880, PPD 仅提高到 32 在后文中, 我们会对 VR 360 视频的画质体验演进路线进行阐述 交互体验 根据学术界的研究成果, 从用户和虚拟环境 (VE) 之间的交互体验角度进行分类,VR 应用可分为弱交互式 VR(Weak-Interactive VR) 和交互式 VR(Interactive VR) VR 360 视频属于弱交互式 VR 的一种, 用户只能被动体验虚拟环境中预先拍摄好的内容, 用户可以通过转头等方式改变视点, 但用户无法和虚拟环境之间发生实质性交互行为 由此可知,VR 360 视频的交互体验主要反映在头动和视野延迟 ( Motion-to-Photons Latency,MTP) 上, 业界的主流观点认为, 在使用沉浸式终端时,MTP 不能超过 20ms, 8

10 否则会引起眩晕感 也就是说, 用户在通过转头等方式改变视角时, 终端 网络和云端处理的整体时延应保证头动和 FOV 画面改变的一致性,FOV 画面的更新延迟不应超过 20ms 的现象, 也不应出现全部 / 部分视野无画面信息的现象 3.3 投影技术和编码技术 投影技术 投影技术和编码技术决定了 VR 360 视频的媒体文件以何种格式生产和组织, 及其包含的媒体信息量 这对量化达到某个用户体验要满足的网络要求至关重要 VR 360 视频需要解决如何将用户看到的空间球信息转变为平面的媒体格式, 这就用到了传统视频没有涉及的投影技术 目前,Equirectangular projection(erp, 等角投影 ) 是当前 VR 360 视频主流格式, 但画质存在失真, 压缩效率存在瓶颈 这种投影方式使用了一种经典的地图经纬线投影的思想, 将球面展开为平面矩形 等角投影的经纬线正交成 90, 没有角度变形, 但面积变形最大, 主要依靠增大面积变形而达到保持角度不变, 球面赤道部分投影展开后失真小, 越向两极失真越大 由于球面两极区域展开后, 靠增大面积保持角度不变, 引入了更多的无效冗余像素, 导致视频文件编码压缩效率不佳 国外 Youtube Oculus Samsung Gear, 国内优酷 爱奇艺均采用此种投影格式生产 VR 360 媒体文件 Platonic solid projection(psp, 多面体投影 ) 是业界关注的新方向, 具有失真小 压缩效率高的特点 它利用了另一大类经典的地图投影思想, 按相等经差与纬差的经纬线将球面划分为许多球面梯形, 投影到某种多面体上, 此处的多面体可以为四面体 立方体 金字塔 12 面体等 由于每个梯形单独投影, 因此失真极其微小 在 2016 年 5 月的 MPEG 会议上,Samsung 提交了关于 PSP 投影格式的提案 9

11 Projections 3D Model 2D Projection Vertexes Area Ratio Tetrahedron (4 faces) x 2.11x Cube (6 faces) x 1.22x Octahedron (8 faces) x 1.05x Dodecahedron (12 faces) x 0.84x Icosahedron (20 faces) x 0.77x 编码技术 VR 360 视频可以采用普通视频的编码技术进行压缩 目前应用最多的视频编码技术是 H.264, 业界公认的下一代编码技术是 HEVC 和 VP9 根据业界的测试结论, 在保证同 10

12 等画质的前提下,HEVC 和 VP9 的压缩效率大约比 H.264 的最新版本提升 30% 左右 MPEG 等标准组织的最新研究进展表明, 对应于 HEVC 的下一代编码技术 (H.266) 的压缩效率最多能比 HEVC 再提升 30% 对于具有景深 (3D) 效果的 VR 360 视频, 是通过左右眼具有双目视差的两个图像进行合成, 形成立体效果 体现在媒体格式上, 是将左右眼对应的两幅画面编码到同一帧, 可以为左右排列或上下排列格式 从无压缩的信息量上看,3D 效果的 VR 360 视频是 2D 效果的两倍, 由于 3D 左右眼内容具有较高的相关性, 达到同等的画面质量, 压缩效率可以进一步的提升 根据业界的测试结果显示, 使用相同的编码技术版本,3D 效果的 VR 360 视频压缩效率最多可以比 2D 效果的 VR 360 视频再提升 25% 3.4 网络传输技术路线 VR 360 视频的在线传输有两种主要的技术路线 : 全视角传输方案和 FOV 传输方案 全视角传输方案 所谓的全视角传输方案就是将 360 度环绕的画面都传输给终端, 当用户头部转动需要切换画面时, 所有的处理都在终端本地完成 VR 全景视频在相同单眼可视分辨率情况下, 由于帧率 位深 360 度等原因, 码率要比普通平面视频大很多, 前者一般是后者的 5-10 倍, 以单眼 8K 的极致全景 VR 视频为例, 观看时要求的带宽达到 5G, 这对于网络来说是个极大的挑战, 成本也大大增加 虽然整个全景视频是 360 的, 但是观看者在观看时, 实际只能看到当前视野部分, 看不到的部分只是占了网络带宽, 而没有真正用到, 对网络资源造成了比较大的浪费 针对这种情况, 业界提出了基于视角进行有差别传输 VR 视频的 FOV(Field of View) 传输方案 FOV 传输方案 全视角传输方案 而 FOV 传输方案则主要传输当前视角中的可见画面 一般都是将 360 度全景视野划分为若干个视角, 每个视角生成一个视频文件, 只包含视角内高分辨率和周围部分低分辨率视觉信息, 终端根据用户当前视角姿态位置, 向服务器请求对应的视角文件 当头部转动视角发生变化时, 终端向服务器请求新视角对应的视角文件 Facebook 公布的基于 FOV 方式传输的方案中, 一共划分了 30 个视角, 每个视角文件大小, 只有原始文件的 20%, 传输码率也相应的只有原来的 20%, 大大降低了观看 VR 视频的带宽要求, 并且提高带宽的有效利用率 这种方案也存在不足, 就是所有视角的视频文件大小总和是原始文件的 6 倍, 在服务器上会占用比较多的存储空间, 但相对来说, 带宽资源更加宝贵 下文将对这两种方案展开阐述 在全视角传输方案中, 终端接收到的一帧数据中包含了用户可看到的空间球对应的全部视角信息 用户改变视角的交互信号在本地终端完成处理, 终端根据视角信息从已缓存到本地的帧中解出对应的 FOV 信息, 在播放器中进行矫正还原, 使用户看到正常视角的视觉信息 因此交互体验要求的 20ms 由终端来保证, 不涉及网络时延和云端时延 这种方案对带宽的要求较高, 时延要求较低 属于 带宽换时延 的传输方案 这种传输方案可以直接利用现有的主流视频传输技术如 MPEG.DASH HAS HLS HPD 等, 11

13 3.4.2 FOV 传输方案 主要在终端播放器增加了从全视角帧中投影还原出 FOV 信息的功能, 本文不再对其流程进行冗述 在 FOV 传输方案中, 终端接收到的一帧数据中不再包含空间球的无差别全部视角信息, 而是根据用户的视角姿态构造对应的帧数据, 一帧数据中只包含等于或大于视场角的部分视觉信息, 终端需要判断用户转头改变视角的姿态位置, 并将交互信号发向云端, 请求新的姿态对应的帧数据 因此交互体验要求的 20ms 既包含终端处理时延, 也包含网络传输时延和云端处理时延 这种方案的带宽要求降低, 时延要求变高 (E2E<20ms), 属于 时延换带宽 的传输方案 这种方案可以利用现有的主流视频传输技术如 MPEG.DASH HAS HLS HPD 等, 但对媒体文件的生成机制 云端和终端的处理机制都有相应要求, 形成特有的流程 下文将对其流程展开阐述 (1) 姿态定义 : 定义枚举用户在空间球中的视角姿态位置, 并进行 1~N 的编号, 每个编号 i 对应一个视角范围, 视角范围可以正好等于 FOV, 也可以大于 FOV (2) 媒体生成 : 根据视角姿态位置编号, 生成对应的 N 个媒体文件, 存放在云端服务器 并在云端服务器上编制对应的媒体描述文件 (MPD) (3) 终端播放 VR 360 视频, 首先向云端请求获取媒体描述文件 (MPD), 得到用户视角姿态位置和媒体文件的对应关系 (4) 终端根据用户当前视角姿态位置 i, 请求对应的媒体文件 i, 以及 VR 360 视频开始播放的时间点 t0 云端接收到请求后, 寻址到对应的媒体文件 t0 时刻开始传输 终端接收到可支持播放的最小缓冲数据量 b0 时开始播放, 并继续向云端获取后续媒体文件内容 (5) 在时间 t1, 用户改变视角, 对于每一个约定的视角改变度 Φ, 终端识别出对应的视角姿态位置为 j, 位置 i 和位置 j 为连续相邻的两个位置 终端请求对应的媒体文件 j, 以及 VR 360 视频开始播放的时间点 t1+δt 终端接收到可支持播放的最小缓冲数据量 b0, 并在播放完媒体文件 i 剩余的 Δt 时长后, 开始播放媒体文件 j, 并继续向云端获取后续媒体文件内容 Facebook 在 2016 年初公布了一种基于金字塔投影的 FOV 传输方案 金字塔投影属于 PSP 投影技术的一种, 可减小媒体文件的平均码率到 ERP 投影原画质的 20% 同时牺牲部分画质体验来降低对 E2E 20ms 交互的要求, 属于一种改良后的折中 FOV 方案 12

14 如图所示, 将用户在虚拟环境中的视觉信息对应的全部球面数据放入金字塔投影 用户视点正前方的平面为 FOV 平面, 使用高分辨率编码 ; 其余四个平面为非 FOV 平面, 分辨率从与 FOV 平面相交的边到视角反方向的顶点逐渐降低 将金字塔展开后加以调整, 可将全部 360 度的球面视觉信息置入到矩形中 这种矩形帧格式编码压缩效率很高, 金字塔投影的码率可减小到 ERP 投影原画质的 20% 在传输技术上,Facebook 使用与现有技术兼容的网络传输技术以存储换时延, 并牺牲部分画质体验保证交互体验 要点如下 : (1) 对用户头部平均分布的不同姿态位置进行编号, 预生成对应的 30 个锥形全视角文件存放在服务器 ( 存储换时延 ), 和现有的 MPEG-DASH 流化方案兼容. (2) 在用户头部姿态未改变时, 默认解码高分辨率的 FOV 平面 (3) 当用户头部位置交互变化未超过请求阈值时, 用户看到的视场信息由大部分 FOV 平面 ( 高分辨率 ) 和小部分非 FOV 平面 ( 低分辨率 ) 组成, 牺牲部分画质体验保证交互体验 (4) 当用户头部位置变化超过请求阈值时, 用户看到的视场信息暂时由小部分 FOV 平面 ( 高分辨率 ) 和大部分非 FOV 平面 ( 低分辨率 ) 组成, 同时请求新的姿态对应的锥形全视角文件, 待 Buffer 获得足够数据后将视场信息更换为 FOV 平面 ( 高分辨率 ), 牺牲短时间内的部分画质体验保证交互体验 13

15 除 Facebook 外, 其他相关公司也在进行 FOV 传输方案的相关研究, 华为公司也开始了几种 FOV 方案的研发 目前业界还没有形成统一标准, 各家公司的方案细节 对网络需求也存在具体的差异 3.5 网络要求分析 在线点播 VR 360 视频在线点播基于 TCP 传输, 其网络要求由三个因素决定 : 即时加载 流畅播放和视角交互 其中全视角传输方案的视角交互在终端侧完成, 不涉及网络要求 (1) 即时加载 即时加载是指用户开始点播 VR 360 视频时, 需要等待多久可以看到虚拟环境信息的呈现 即时加载主要分为三个阶段, 即即时加载信令交互阶段 (X1) 最小解码缓冲媒体报文下载阶段 (Y), 以及播放器播放加载准备阶段 (Z) 如果用户对即时加载时间的要求为 T1, 那么应满足 X1+Y+Z T1 如果设定 Rate vr 为 VR 360 视频的平均码率,Buffer time 为终端最小解码缓冲媒体报文时长,Ds 为 TCP 慢启动阶段的数据量,,X1*RTT 为即时加载信令交互阶段往返时延, S*RTT 为 TCP 慢启动时延,Z 为终端播放器加载准备时延 那么端到端 TCP 吞吐量需求应满足 : 如果设定 P 为丢包率 (PLR,Packet Loss Rate), BW 为物理带宽,MSS 为最小传输单元,RTT 为终端到服务器时延 根据经典 TCP 吞吐量公式有 : 14

16 综上所述, 可得到公式 : (2) 流畅播放 用户在观看 VR 360 视频的过程中, 端到端 TCP 吞吐量应始终满足大于平均码率倍数 N, 即 : 此处暂取 N=1.5 (3) 视角交互 视角交互的要求是指用户在发生视角姿态位置变化时, 网络要求应满足何种条件才能使头动和视野延迟 ( Motion-to-Photons Latency, MTP) 小于目标值, 同时将用户对视场信息劣化 ( 出现黑屏 部分画面无信息或者部分画面质量下降 ) 的察觉程度减小到最少 视角交互主要分为三个阶段, 即视角变化信令交互阶段 (X2) 最小解码缓冲媒体报文下载阶段 (Y), 以及播放器播放加载准备阶段 (Z) 如果用户对 MTP 的要求为 T2,T2 通常取 20ms; 用户对转头过程中视场信息劣化的时间要求为 T3, 那么应满足 X2+Y+Z min(t2,t3) 本文以 Facebook 基于金字塔投影的 FOV 传输方案为实例进行分析, 由于 Facebook 方案通过牺牲短时间内的部分画质体验来保证交互体验,T2 的要求也在终端侧得到满足, 只需满足 T3 要求即可 如果设定 Ratevr 为 VR 360 视频的平均码率,Buffertime 为终端最小解码缓冲媒体报文时间,Ds 为 TCP 慢启动阶段的数据量,,X2*RTT 为视角变化信令交互阶段往返时延,S*RTT 为 TCP 慢启动时延,Z 为终端播放器加载准备时延 那么端到端 TCP 吞吐量需求应满足 : 如果设定 P 为丢包率 (PLR,Packet Loss Rate), BW 为物理带宽,MSS 为最小传输单元,RTT 为终端到服务器时延 根据经典 TCP 吞吐量公式有 : 综上所述, 可得到公式 : 根据上述分析, 我们将在线点播的网络要求概括如下 : 15

17 传输方案带宽要求时延和丢包率要求 全视角传输方案 FOV 传输方案 (Facebook) 在线直播 VR 360 视频在线直播的网络要求由三个因素决定 : 即时加载 流畅播放和视角交互 其中全视角传输方案的视角交互在终端侧完成, 不涉及网络要求 此处讨论基于 UDP 传输的 VR 360 视频直播网络要求, 基于 TCP 传输的直播网络要求同在线点播 (1) 即时加载 即时加载是指用户加入 VR 360 视频直播频道时, 需要等待多久可以看到虚拟环境信息的呈现 即时加载主要分为三个阶段, 即即时加载信令交互阶段 (X1) 1 个完整的 I 帧下载阶段 (Y), 以及播放器播放加载准备阶段 (Z) 如果用户对即时加载时间的要求为 T1, 那么应满足 X1+Y1+Z1 T1 为加快直播频道切换速度, 一般都会部署 FCC(Fast Channel Change) 方案, 为保证 FCC 方案可正常工作, 还需要保证每用户带宽 平均码率的 1.3 倍 如果设定 Ratevr 为 VR 360 视频平均码率,GopTime 为 Gop 报文时长,T1 为频道切换目标值,X1*RTTjoin 为信令交互 ( 通常为加入组播组 ) 阶段往返时延, Tload 为终端播放器加载准备时延 那么端到端 UCP 吞吐量需求应满足 : 由于基于 UDP 的直播业务本身对时延并不敏感, 但是从上面公式可以看出分母必须要大于 0,RTT 一般是不小于 RTTjoin, 又有 : (2) 流畅播放 用户在观看 VR 360 视频直播的过程中, 应满足全程播放无黑屏 无花屏 参考 TR-126 的标准要求,4K 分辨率直播无花屏要求的网络丢包率 <10-6 目前业界在应用层通过 RET 丢包重传等技术降低视频对丢包率的要求, 可以降到 10-4 左右 更高分辨率的网络丢包率要求有待研究 即 : (3) 视角交互 视角交互的要求是指用户在发生视角姿态位置变化时, 网络要求应满足何种条件才能使头动和视野延迟 ( Motion-to-Photons Latency, MTP) 小于目标值, 同时将用户对视场信 16

18 息劣化 ( 出现黑屏 部分画面无信息或者部分画面质量下降 ) 的察觉程度减小到最少 视角交互主要分为三个阶段, 即视角变化信令交互阶段 (X2) 最小解码缓冲媒体报文下载阶段 (Y), 以及播放器播放加载准备阶段 (Z) 如果用户对 MTP 的要求为 T2,T2 通常取 20ms; 用户对转头过程中视场信息劣化的时间要求为 T3, 那么应满足 X2+Y+Z min(t2,t3) 本文以 Facebook 基于金字塔投影的 FOV 传输方案为实例进行分析, 由于 Facebook 方案通过牺牲短时间内的部分画质体验来保证交互体验,T2 的要求也在终端侧得到满足, 只需满足 T3 要求即可 如果设定 Ratevr 为 VR 360 视频平均码率,GopTime 为 Gop 报文时长,T3 为视场信息劣化时间目标值, X2*RTTjoin 为信令交互 ( 通常为加入组播组 ) 阶段往返时延, Tload 为终端播放器加载准备时延 那么端到端 UCP 吞吐量需求应满足 : 同时有 根据上述分析, 我们将在线直播 ( 基于 UDP) 的网络要求概括如下 : 带宽要求 时延和丢包率要求 全视角传输方案 FOV 传输方案 (Faceb ook) 3.6 体验和技术演进路线 VR 360 视频的发展以体验为主线, 是画质不断提升, 信息量不断增大的过程 传输技术和网络技术的匹配度决定了画质体验和交互体验能达到的程度 我们认为,VR 360 视频体验的演进可经历如下阶段 : 发展早期阶段, 入门体验阶段, 进阶体验阶段和极致体验阶段 当前发展阶段属于 VR 发展早期阶段, 尚未进入入门体验阶段 对于每个阶段, 我们都对终端 内容 体验和网络, 以及到来时间点进行预判 17

19 3.6.1 发展早期阶段 发展早期阶段的 VR 360 视频, 称之为 Pre- VR 我们认为这一阶段应当以当前 (2016 年 ) 可普遍获取的软硬件最高水准作为衡量基准,HMD 终端以 Samsung Gear 为代表, 内容以 Youtube 上 4K 分辨率的 VR 360 视频为代表 1. 终端 : 视场角 :90 度 屏幕分辨率 :2K 2. 内容 : 全视角分辨率 :3840*1920 单眼分辨率 :960*960 景深 :2D 为主流 色深 :8bit 帧率 :30fps 压缩率 :165:1 编码标准 :H.264 平均码率 :16Mbps 3. 体验 : PPD: 入门体验阶段 等效 TV 屏分辨率 :240P 连续体验时间 : 受终端和体验问题限制, 最长不超过 20 分钟 4. 点播网络要求 : 流畅播放带宽需求 : 25Mbps( 基于全视角传输方案, 本阶段主流 ) 5. 直播网络要求 : 流畅播放带宽需求 : 20.8Mbps( 基于全视角传输方案, 本阶段主流 ) 入门体验阶段的 VR 360 视频, 称之为 Entry-Level VR 我们认为这一阶段会持续两年左右, 我们认为应当在当前 (2016 年 ) 可普遍获取的软硬件最高水准上再提升一步, 终端屏幕分辨率提升至 4K, 全视角分辨率提升至 8K, 使用户看到的画面质量可接近于在 PC 上观看 480P 的 PPD 效果 1. 终端 : 视场角 :90 度 屏幕分辨率 :4K 2. 内容 : 全视角分辨率 :7680*3840 单眼分辨率 :1920*1920 景深 :2D 为主流 色深 :8bit 18

20 帧率 :30fps 压缩率 :165:1 编码标准 :H.264 平均码率 :64Mbps 3. 体验 : PPD: 进阶体验阶段 等效 TV 屏分辨率 :480P 连续体验时间 : 受终端和体验问题限制, 最长不超过 20 分钟 4. 点播网络要求 : 流畅播放带宽需求 : 100Mbps( 基于全视角传输方案, 本阶段主流 ) 5. 直播网络要求 : 流畅播放带宽需求 : 83.2Mbps( 基于全视角传输方案, 本阶段主流 ) 进阶体验阶段的 VR 360 视频, 称之为 Advanced VR 在这一阶段,HMD 终端的屏幕分辨率 芯片性能 人体工程, 内容的质量, 都有较大的提高, 我们预计在 3 到 5 年产业的发展可实现这一阶段目标 1. 终端 : 视场角 :120 度 屏幕分辨率 :8K 2. 内容 : 全视角分辨率 :11520*5760 单眼分辨率 :3840*3840 景深 :2D 为主流 色深 :10bit(HDR) 帧率 :60fps 压缩率 :215:1 编码标准 :HEVC/VP9 平均码率 :279Mbps 3. 体验 : PPD:32 等效 TV 屏分辨率 :2K 最长连续体验时间 :20~60 分钟 4. 点播网络要求 : 流畅播放带宽需求 :418Mbps( 基于全视角传输方案, 本阶段主流 ) 19

21 5. 直播网络要求 : 极致体验阶段 流畅播放带宽需求 :361.4Mbps( 基于全视角传输方案, 本阶段主流 ) 极致体验阶段的 VR 360 视频, 称之为 Ultimate VR 在这一阶段,HMD 终端和内容的发展可使用户拥有最佳使用体验, 我们预计产业需要在 10 年的长期发展后可全面进入这一阶段 1. 终端 : 视场角 :120 度 屏幕分辨率 :16K 2. 内容 : 全视角分辨率 :23040*11520 单眼分辨率 :7680*7680 景深 :3D 成为主流 色深 :12bit 帧率 :120fps 压缩率 :350:1 编码标准 :H.266 平均码率 :3.29Gbps 3. 体验 : PPD: 演进路线小结 等效 TV 屏分辨率 :4K 最长连续体验时间 :>60 分钟 4. 点播网络要求 : 流畅播放带宽需求 :4.93Gbps( 基于全视角传输方案 ) 987Mbps( 基于 Facebook 方案, 本阶段主流 ) 即时交互带宽需求 :2.35Gbps( 基于 Facebook 方案, 本阶段主流 ) 5. 直播网络要求 : 流畅播放带宽需求 :4.277Gbps( 基于全视角传输方案 ) 856Mbps( 基于 Facebook 方案, 本阶段主流 ) 即时交互带宽需求 :2.35Gbps( 基于 Facebook 方案, 本阶段主流 ) 在入门体验阶段, 由于 Entry-Level 级 VR 画质体验不高, 业界会优选全视角传输方案, 以保证良好的交互体验 在这一阶段,VR 用户的渗透率和绝对数量不会很高, 从用户端到端网络带宽要求看, 满足 8K 视频流畅播放的带宽也可满足 VR 360 视频的要求 在进阶体验阶段, 由于 Advanced 级 VR 的画质体验得到提升, 继续全视角传输方案对网络带宽要求变高, 在网络带宽 Ready 的条件下仍可保证良好交互体验 20

22 Ultimate 级 VR, 单眼画质达到视网膜级, 全视角传输对网络带宽的要求太高, 必须采用 FOV 传输, 对网络低时延提出一定要求 如使用 Facebook 的折中 FOV 方案, 那么牺牲一部分画质体验, 同时降低了对网络带宽和时延的要求 在入门体验阶段和进阶体验阶段, 由于用户可接受的连续体验时间不长, 和其他传统业务相比, 一个家庭用户的巨大的带宽需求是短时的 ; 而在极致体验阶段,FOV 传输方案在转头时触发的突发带宽需求, 也远高于未转头时稳定观看的带宽需求 由此可见, 在 VR 360 视频演进的各个阶段, 都将存在短时按需的高带宽要求 综上所述, 我们对 VR 360 视频演进路线的判断可小结如下 : Standard Pre-VR Entry-Level VR Advanced VR Ultimate VR 连续体验时间 <20 分钟 <20 分钟 20~60 分钟 >60 分钟 预计时间 Now~2 年 Now~2 年 3~5 年 5~10 年 视频分辨率 全视角 4K 2D 视频 (Youtube) ( 全画面分辨率 3840*1920) 全视角 8K 2D 视频 ( 全画面分辨率 7680*3840) 全视角 12K 2D 视频 全画面分辨率 11520*5760 全视角 24K 3D 视频 全画面分辨率 23040*11520 单眼分辨率 960*960[ 通过眼镜观看, 视场角 90 度 ] 1920*1920 [ 通过眼镜观看, 视场角 90 度 ] 3840*3840[ 通过专业头显观看, 视场角 120 度 ] 7680*7680[ 通过专业头显观看, 视场角 120 度 ] PPD( 注 1) 等效传统 TV 屏分辨率 240P 480P 2K 4K 色深 (bit) (HDR) 12 压缩率 ( 注 2) 165:1 165:1 215:1( 注 2) 350:1(3D) ( 注 2) 帧率 典型视频码率 16M 64M 279M 3.29G 典型网络带宽需求 ( 注 3) 典型网络 RTT 需求 ( 注 4) 典型网络丢包需求 ( 注 4) 25Mbps 100Mbps 418Mbps 1Gbps(FOV) ( 注 5) 40ms 30ms 20ms 10ms 1.4E-4 1.5E-5 1.9E-6 5.5E-8 注 1:PPD, 也即 Pix per Degree, 普通人视网膜能达到 60 个 PPD 的分辨度 注 2: 压缩分别基于 H.264 HEVC 和 H.266 发展的经验值计算, 3D 左右眼内容的相关性很高, 可以做大比例的压缩而不会损失太多质量 注 3: 典型网络带宽, 点播按照码率的 1.5 倍估算 21

23 注 4: 网络时延与丢包, 先确定目标时延值, 根据网络带宽, 由 TCP 吞吐量公式计算得到丢包 注 5: 快速转动头部时, 突发带宽可能需要 2.35Gbps,1Gbps 智能满足正常流畅播放 22

24 4 面向 VR 业务的承载网 4.1 VR 业务对网络影响分析 VR 的流量特征 如果把宽带上网比作涓涓细流的小溪, 而且经常季节性的断流, 那么视频 ( 包括高清 4K/8K) 就是额尔齐斯河, 而 VR 就是长江 亚马逊, 他们不同业务之间对管道带宽的需求差别是如此大, 经常是 10 倍 百倍的差距 普通宽带上网, 一般峰值 ( 短暂 ) 在 20M~30M 就可以获得相当好的上网体验, 但对于高清视频 4K/8K 视频, 要获得良好的体验, 就必须有持续的 30M~100M 带宽保证, 而对于 VR 视频, 要获得极佳使用体验, 就需要超 Gbit 的入户带宽 但罗马不是一日建成的, 要到达极致的 VR 体验, 整个产业链需要一个持续的 缓慢的爬坡过程, 无论是终端 网络 内容, 还是潜在用户的培养 既然 VR 是未来社会的一个重要业务, 兵马未动, 粮草先行, 作为运送内容的管道, 就需要提前分析 VR 业务与当前管道的差距, 做到承载网络先于业务 ready, 为保障 VR 业务顺利发展做好准备 下面对 VR 业务流特征进行详细的分析 特征 1 :VR 视频是典型的大象流 相对目前已经存在的上网 视频业务,VR 绝对是传说的大象流, 而且是贯穿整个城域网 接入网的大象流 ( 以前的大象流或许只在 DCI 城域出口 骨干网存在 ), 传输一路极致体验的 VR 内容就会需要端到端几个 Gbit 带宽, 而且这个带宽是一直延伸到用户家里的 同时, 由于 VR 视频是个人独自观看的 (VR 眼镜是最常用的终端 ), 一个用户家里同时存在几路 VR 业务的概率大大增加, 相比于大屏 4K/8K 视频的家庭式观看, VR 业务消耗的带宽还可能继续翻倍 虽然未来技术的发展, 压缩算法的改进, 单路 VR 业务需要的传输带宽还有进一步的降低空间, 但入户带宽超 Gbit, 甚至 10Gbit 是一个大概率事件 在 VR 视频带宽面前, 其它业务对带宽的消耗基本可以忽略 23

25 图 4-1 网络中主要业务带宽比较示意图 特征 2: 网络流量潮汐现象更明显 受限商业模式和 VR 设备本身的限制 ( 长时间佩戴, 容易产生头晕甚至晕厥等不适感 ), VR 用户的持续在线时间不会太长, 这样的业务特征, 又加上本身的大象流特征, 必然造成流量的波峰和波谷差别更大, 尤其当热点事件来临时 (100 倍的差异 ) 对于汇聚整个城域的 BRAS/CR 设备, 以及承载这些流量的链路, 动态申请链路资源 设备能力按需弹性扩缩容就是一个非常重要的特性 特征 3: 对时延和丢包率的要求更高 VR 业务除了对带宽要求很高外, 对网络时延和丢包率要求也很高, 在网络上传输 VR 视频, 除了直播外, 大量点播的内容都是基于 TCP 来传输的 (OTT VR 直播也是基于 TCP 传输 ), 而影响 TCP 吞吐量的两个因子 : 时延和丢包, 在传输大码流的 VR 业务前就显得更加重要 从网络角度来讲, 降低时延和丢包率就是网络义不容辞的责任 时延, 从端到端角度来看, 除了本身由于距离产生的光在光纤的传输时延 ( 光在光纤传输产生的时延, 短期内很难有大的突破, 光在光纤传输的速度是在真空传输速度的 2/3, 大约 200KM/ms), 影响更大的是设备在转发引入的转发时延 路由设备在转发时, 是一个存储 转发机制, 当流量突发引起入方向或者出方向排队, 就会引入较大的排队时延, 而在尽力而为 统计复用的 IP 网络中, 拥塞排队是不可避免的 这种拥塞包括真实业务流量超过实际物理带宽瓶颈而引起的拥塞, 也包括业务本身由于 burst 机制产生的瞬时拥塞 ( 假拥塞 ), 都会产生较大时延, 严重时甚至会产生丢包 丢包对 TCP 的吞吐量影响更大 当然, 链路本身的质量老化 ( 光功率衰减和光纤插头灰尘 磨损等 ) 设备的存储跳变等也会产生丢包, 但毕竟是小概率事件 相对于光纤传输, 铜线 Wi-Fi 等由于解决本身的不可靠传输问题 ( 干扰导致丢包 ), 丢包重传是一种常态, 这种丢包重传严重制约了 TCP 的吞吐量, 并引入了更大的时延 VR 业务家庭带宽估算 入门体验阶段 (Entry-Level VR): VR 视频 : 单节目带宽 100M 普通视频 :2 个 4K 视频节目, 每个节目带宽 25M 上网业务 :10M 带宽 24

26 家庭总带宽 :160M, 入户接入带宽要求 >200M 进阶体验阶段 (Advanced VR): VR 视频 : 单节目带宽 :400M, 可能会多屏, 按 2 个屏计算 普通视频 :2 个 4K 视频节目, 每个节目带宽 25M, 和多路 VR 同时并发可能不大, 可忽略 上网业务 :20M 带宽, 和多路 VR 同时并发可能不大, 可忽略 家庭总带宽 :870M, 入户接入带宽要求 1G 极致体验阶段 (Ultimate VR): VR 视频 : 2.35G(FOV 方式传输 ), 按 2 屏计算 其他业务 : 普通视频 上网业务共计 200M 家庭总带宽 : 4.9G, 入户带宽要求 5G( 按 FOV 方式计算, 后面均按该值算 ) VR 业务对网络的影响 VR 业务作为一个新兴业务, 由于对网络传输带宽的巨大需求, 必然对当前的网络架构产生一定影响, 本章节主要分析 VR 业务对入户带宽 接入网 城域网 家庭网等方面的影响 对网络的影响主要体现在三个方面 : 更大容量的设备 新的业务传输方案 新的网络架构 1. 入户带宽 :Gbit 入户 甚至超 Gbit 入户,10Gbit 入户 ( 极致 VR 多路 VR) 2. 接入网络 :10G/40G/100G PON 大面积部署,OLT 上行单链路支持 400G 端口, 3. 城域网络 :10T 量级单板,PB 级设备交换容量 4. 设备和链路支持动态扩容 : 潮汐的波峰和波谷 100 倍差别, 按需申请设备和链路资源能够显著降低运营的成本 ( 功耗 噪音 ) 5. 家庭网络 : 对无线 Wi-Fi 要求更高,802.11ad,snap 高速传输,Wi-Fi 支持组播, 甚至其它的无线传输协议 4.2 家庭网络 VR 由于其观看设备的限制, 决定其使用场所主要是在家庭, 同时由于其超高的带宽要求, 以及家庭中越来越多的终端, 很可能不同使用者会分布在不同的房间中, 因此对以 Wi-Fi 为主的家庭网络在带宽 时延 覆盖性方面提出了极高的要求, 但是当前的家庭 Wi-Fi 还面临着比较大的挑战 当前家庭 Wi-Fi 网络承载 VR 业务存在的问题 超大带宽无法满足 : 当前家庭使用的 Wi-Fi 还大部分为 n, 最大带宽为 300M 左右, 但每个 Advanced VR 视频所需要的带宽超过 400M, 未来极致 VR 视频所需带宽更是达到 2.35G(FOV 方式 ) 甚至 5G( 全视角方式 ); 25

27 不同业务相互影响 : 除了 VR 视频业务, 在同一网络中的上网 下载及其它非 VR 视频业务, 相互之间会抢占资源, 相互影响 ; 信号覆盖问题 : 家中各种物体都会对 Wi-Fi 信号造成一定的衰减, 尤其是承重墙和金属, 这些都会导致家庭不同位置的信号强度存在差异, 甚至有些位置没信号 ; 信道拥堵和干扰 : 在城市中, 住宅楼内当前普遍使用的 2.4G 频段存在太多的信号源, 这些信号之间相互影响, 同时无绳电话 微波炉 蓝牙这些无线设备都可能会对 2.4G 频段无线信号造成影响 ; 超大带宽 高性能 全覆盖 Wi-Fi 家庭网络解决方案 新的 Wi-Fi 标准设备 : 对于 Advanced VR 来说, 可以使用当前已经商用的 ac 标准的 Wi-Fi 路由器, 其空口带宽可以达到 1G-1.3G, 能满足要求 ; 对于极致体验的 Ultimate VR 要求的家庭接入 5G 带宽需求, 需要使用未来速率更高的 ac Wave2( 空口速率可达 6.93G), 或者 ad( 又称 WiGig, 吞吐量可以达到 7G) 或者 ax, 甚至标准还在制定中的 ay Wi-Fi 设备 按业务区分承载 : 根据各种业务特征, 选择合适的频段 SSID 比如普通的上网业务, 对网络要求不高, 可通过 2.4G 频段 Wi-Fi 承载 ; 普通视频 4K, 以及 Advanced VR 对网络要求相对较高, 通过 5G Wi-Fi 承载 ;Ultimate VR 通过 60G Wi-Fi (802.11ad/802.11ay) 或 5G Wi-Fi(802.11ac Wave2/802.11ax) 承载 分布式 Wi-Fi 方案 : 频段越高, 无线穿越物体的能力就越差, 为了在家庭内任何地点能达到理想的连接速度, 家庭的 Wi-Fi 网络将从集中式部署方式走向分布式, 家庭部署多个 Wi-Fi 接入点 ( 即 AP), 满足家庭不同终端在任意位置的多样需求 Wi-Fi Repeater PLC AP 和 ETH AP 等三种分布式接入方式实现灵活扩展 即插即用, 以及支持无缝切换体验 ; 对于 Advanced VR, 在带宽满足的情况下三种方式均可以, 对于 Ultimate VR 业务, 建议采用 ETH AP 减少无线信号干扰 : 主要有两方面, 一是信道的选择, 与当前环境中其他 AP 已经使用的信道不要相同, 减少干扰 ; 二是家用电器, 特别是容易造成干扰的电器, 比如微波炉和 Wi-Fi 源保持一定距离, 同时家中不使用未经 EMI 认证的电器 更好地支持组播 : 支持 DMS(Directed Multicast Service) 和 GCR(Groupcast with Retries), 在 Wi-Fi 环境下更好的传输组播数据 小结 :VR 业务对家庭 Wi-Fi 网络的要求 下一代 Wi-Fi 协议标准, 更宽的频谱 MU-MIMO Beamforming 等技术广泛使用 : ac/802.11ad/802.11ax/802.11ay,5G/60G 频段 对直播业务支持更友好, 需要 Wi-Fi 更好支持组播, 当然终端也要开放组播功能 提供业务区别承载能力 : 不同业务使用不同 SSID 不同频段进行隔离 分布式 Wi-Fi 方案提升整个家庭的信号覆盖 4.3 接入网 接入网在整个网络中, 起着对终端用户进行汇聚的作用, 是运营商最靠近用户的网络 随着技术的不断发展, 目前存在的接入技术主要有两种, 铜线接入 FTTB/C 和光纤接入 FTTH, 铜线技术细分为 ADSL VDSL2 Vectoring Super Vectoring G.fast, 光纤接入分为 GPON 和 EPON 接入 26

28 4.3.1 光纤接入技术分析 下面针对 VR 视频业务分别对这些接入技术进行分析 光纤接入技术在人类对于带宽需求不断提高的过程中, 发挥着重要的作用, 从最初的 GPON 上行 1G/ 下行 2.5G,EPON 上行 1G/ 下行 1G, 发展到今天上行 2.5G/ 下行 10G 的 GPON, 上行 10G/ 下行 10G 的 EPON 也已经开始规模商用,40G PON 的产品也已经成熟, 待成本等问题解决后也可进行商用,100G PON 已经有样机 超高带宽并且传输距离远, 使得光纤接入已经成为了接入网新建和改造的首选 下面针对 VR 视频业务, 对 FTTH 中的技术分别进行介绍 图 4-2 光纤接入技术演进 G PON: VR 入门体验阶段, 主要还是普通视频业务, 每户的接入带宽 200M, 端口下行带宽 1G, 按 30% 并发率计算, 每个端口下可带 16 个用户, 分光比设置建议不超过 1:16 到 VR 进阶体验阶段, 每户接入带宽 1G 时,G PON 端口不具备优势, 不建议使用 10G PON:VR 入门体验阶段, 家庭接入带宽只有 200M, 足够使用 ;VR 进阶体验阶段, 家庭接入带宽 1G, 并发率按照 30% 计算,10G 端口可以带 33 个用户, 分光比建议设置为 1:32 到 VR 极致体验阶段, 每户接入带宽要求已经达到 5G, 这是 10G PON 分由于光比太低会导致成本上升, 建议将来平滑演进到 40G/100G PON 来承载 40G PON: 由于当前还未商用,VR 入门体验阶段先不考虑, 假设从 VR 进阶体验阶段 40G PON 开始成熟商用 VR 进阶体验阶段单用户接入带宽 1G, 并发率按 40% 计算, 每端口可以带 100 用户, 分光比可根据实际情况配置为 1:64 或 1:128 VR 极致体验阶段, 单用户带宽达到 5G, 并发率按 40% 计算, 每端口可带 20 个用户, 分光比建议 1:16 100G PON: 当前 100G PON 处在样机阶段, 标准还在制定中, 距规模商用时间较长, 结合 VR 发展过程演进, 只分析未来 100G PON 支持极致 VR 的网络设计 极致 VR 每家庭接入带宽 5G(FOV 方式 ), 并发率按 40% 计算, 每端口可带 50 个用户, 分光比建议不超过 1:64 不过, 由于 FOV 方式是在可能牺牲头部转动瞬间的体验为代价来换取带宽, 因此将来带宽足够大时, 可以直接传输全视角视频来获得更好的体验, 这种情况下按照单连接带宽 4.93G, 家庭接入带宽 10G, 并发率 40% 计算, 每端口可带 25 用户, 分光比可设置在 1:16 OLT 架构 : 随着视频的普及, 用户带宽越来越大, 并发几率也大大增加,OLT 作为接入网络的核心节点, 处理能力面临极大的挑战 传统集中式架构通过主控交换芯片集中转发, 已经成为整个设备的瓶颈, 需要采用分布式架构将业务处理分散到每个业务单板上, 27

29 4.3.2 铜线接入技术分析 同时可靠性也可以得到提高 另外, 为了应付视频流突发, 接口板还要具备一定的缓存能力 ( 还有 ONT 也需要加大缓冲 ), 避免由于拥塞而出现丢包 ADSL/VDSL2:: ADSL 的下行速度最高 25M,VDSL2 下行带宽最高 50M, 用来上网可以, 但是对于视频业务来说,4K/8K 要求的 30M-100M 速率已经无法达到, 更别说动辄以 Gbps 为单位计的 VR 视频了, 因此无法满足需求 Vectoring: 在 VDSL 线路基础上, 通过远端串扰抵消来提升线路速率的 Vectoring 技术, 下行带宽可最高达 120M, 虽然可以观看 4K/8K 视频, 但再包括 VR 视频的话, 入门阶段家庭带宽也需要 200M, 因此不建议使用 SuperVectoring: 在 Vectoring 技术基础上, 将工作频段由 17MHz 扩展到 35MHz, 增加了下行带宽, 在 300 米内可以达到 300M,300 米到 700 米 100M,VR 入门体验阶段, 可以使用 SuperVectoring, 随着分辨率进一步提升, 在进阶及极致体验阶段无法满足带宽要求 G.fast: 在使用 Vectoring 技术的基础上, 将工作频段提高到 106MHz, 使得传输带宽可以达到 1Gbps, 但是要保证带宽, 传输距离不能超过 100 米, 适合光纤到门口的情况部署 不过由于 G.fast 1Gbps 的带宽是上下行带宽之和, 实际下行带宽无法真正达到 1G( 比如上行 200M, 下行 800M, 可调整 ), 当上网 4K/8K 视频业务同时存在情况下, 最多也只能观看一路 Advanced VR 视频 从上述分析结果可以看出, 铜线接入技术除了 SuperVectoring 和 G.fast 外, 都不建议部署在观看 VR 视频的网络, 其中 SuperVectoring 也只是在 VR 入门体验阶段使用, G.fast 可以较好的观看 Advanced VR, 但是多路同时观看时仍然会带宽不足, 虽然利用现有铜线可以降低成本, 但是长期来看, 还是要部署 PON 接入线路, 来满足将来要求越来越高的视频应用 另外, 铜线接入技术随着带宽的增加, 工作频段也在提高, 而频率提高会导致有效传输距离的急剧下降, 每个接入设备支持的范围也大大降低, 同时和光纤接入技术相比有比较大的时延, 这些都说明在未来带宽要求比较高的 VR 业务网络中, 不再适合部署铜线接入技术, 除非有新的突破 小结 :VR 视频对接入网要求 表 4-1 接入技术对 VR 支持情况汇总 分光比 下行带宽 入门 VR (100M) GPON 1:32 30M 1:64 10M 10G PON 1:32 300M 1:64 100M 进阶 VR (418M) 极致 VR 2.35G (FOV) 4.93G( 全视角 ) 40G PON 1:32 1G 28

30 分光比下行带宽入门 VR (100M) 进阶 VR (418M) 极致 VR 2.35G (FOV) 4.93G( 全视角 ) 1:64 500M 100G PON 1:16 6G 1:32 3G 1:64 1.5G G.fast / 800M Super Vectoring / 300M Vectoring / 120 备注 :G.fast 带宽 1G 是上下行总和, 这里按上行 200M, 下行 800M VR 入门体验阶段, 家庭接入带宽 200M, 可采用 SuperVectoring G.fast 和 10G PON 接入技术, 但由于铜线受距离 串扰等因素影响较大, 开通业务前先要进行线路质量评估, 至少满足百兆接入带宽 VR 进阶体验阶段, 家庭接入带宽 1G, 可采用 40G PON 技术 VR 极致体验阶段, 家庭接入带宽 5G, 需要采用未来的 100G PON 接入技术 随着设备处理能力的增加,OLT 架构需要从集中式转变为分布式, 突破处理瓶颈, 接口板具备一定的缓存能力 4.4 城域网 随着 VR 4K/8K 等视频业务的发展, 用户带宽达到 G bit, 甚至超 G bit, 城域网的流量将会呈十倍 百倍 甚至千倍的激增 同时由于视频业务自身持续时间长的特点, 导致整个网络上下行收敛比的下降 29

31 图 4-3 不同业务收敛比对比 流量急剧增长和收敛模型的改变, 以及 VR 4K 等视频对带宽 时延 丢包率都有很高的要求, 使传统的高汇聚 高收敛网络面临承载的挑战 : 网络效率低 : 视频流量增长后, 端到端网络设备都需要扩容, 汇聚层次越多, 收敛比越低, 同步扩容的端到端设备规模就越大 ;CDN 部署位置高, 内容远离最终用户, 业务流经过的网络设备众多, 占用大量的网络资源 并且经过的设备数量越多, 出现瓶颈, 发生拥塞的概率也越大, 端到端时延也会增加 用户体验差 : 多种业务并发时, 随着网络利用率的提升, 丢包和时延会同步提升, 降低视频业务体验 ; 在轻载网络中,98.7% 的突发丢包发生在从高带宽向低带宽过度的汇聚节点, 丢包率的提升, 降低视频业务体验 基于上述原因, 首先需要对传统网络的层次和网络结构进行简化,CDN 下移到 BNG, 甚至 CO, 提高整个城域网的传输效率 图 4-4 城域架构简化 该架构主要特点 : 消除 LSW 汇聚层和城域汇聚层,BNG 向上直连 CR, 向下下沉到网络边缘,OLT 直通 BNG,OTN 到 CO 30

32 网络简化了, 设备的能力也需要进一步提升 下面对简化后的城域网模型进行评估 : OLT 上下行收敛比 :1:2 BNG 上下行收敛比 :1:2 CR 上下行收敛比 :1:2 每个 OLT 4000 用户 每个 BNG 带 20 个 OLT 每个 CR 带 10 个 BNG 表 4-2 流量模型评估 VR 入门 VR 进阶 VR 极致 用户带宽需求 (Mbps) 渗透率 15% 30% 40% 并发率 10% 20% 30% 带宽需求 CR 上行 (G) CR 下行 (G) BNG 上行 (G) BNG 下行 (G) OLT 上行 (G) OLT 下行 (G) CR(G) BNG(G) OLT(G) 从上面表格可以看出, 由于视频业务的普及, 未来对城域设备的处理能力要求是极高的 : BNG: 在 VR 进阶体验阶段, 整机处理能力要求 3.6T; 在 VR 极致体验阶段整机处理能力要求 36T, 如果考虑链路利用率不超过 70%, 两个阶段的整机处理能力要分别达到 5T 和 50T CR: 在 VR 进阶体验阶整机处理能力要求 7T; 在 VR 极致体验阶段, 整机处理能力达到 180T, 按照链路利用率 70% 计算, 两个阶段 CR 实际要达到的处理能力分别为 10T 和 257T; 由于上面的 CR 容量是根据每 CR 下挂 10 个 BNG 算出来的, 当前现网不少城市都只有两个 CR 连到骨干网, 互为备份和分担, 按照这种网络模型计算的话,500 万人口的城市, 在 VR 极致体验阶段,CR 的容量将会达到 /4000/20*180T/10=1125T, 考虑到实际使用时为了避免拥塞丢包, 链路利用率要保持在 70% 以下,CR 的容量需要 1607T, 也就是说需要处理能力在 P bit 量级的超级路由器 31

33 虽然随着 VR 对网络要求的提高, 网络从设备到链路的能力也不断提高, 但是对于 VR 视频这种高带宽 低时延 低丢包率的业务, 如果无差别的承载在网络上, 由于流量突发和不同业务对资源的抢占, 仍然无法保证最终的体验 针对 VR 业务的特点, 下面具体展开介绍几项进一步提升用户体验的技术 4.5 配套 FOV 传输技术的网络方案 VR 点播网络方案 视频传输根据观看实时性和传输方式不同, 分为基于单播的点播, 和基于组播的直播, 下面针对这两种方式情况分别对 VR FOV 传输进行分析 由于 FOV 传输方式有多个视角文件, 服务器需要维护每个角度文件的 url 及角度关系信息, 客户端初始请求节目时, 服务器将该信息发送给客户端 客户端可以使用服务器建议的起始视角文件作为初始观看视频流, 也可以自己选择 表 4-3 VR 点播各视角及 url( 以 12 个视角为例 ) 节目 url 集合 角度 是否起始视角 节目 a url a1 0 是 url a2 +30 url a3 +60 url a 节目 b url b1 0 是 url b2 +30 url b3 +60 url b 一旦初始视角文件选定, 就需要以当前视角为参考, 维护其他各视角对应的视角文件, 在头部转动到新的角度时, 可以准确计算出对应的视角文件 32

34 图 4-5 FOV VR 点播过程过程 节目请求 : 客户端根据访问页面上的连接, 向服务器发出观看请求 在实际中, 这个交互一般是客户端向 WEB 服务器发出观看请求,WEB 服务器将视频的 url 返回给客户端, 客户端根据获取到的 url 对访问视频服务器, 下载视频流 由于 FOV VR 传输的视频来说,url 会有多个,WEB 服务器返回的是所请求节目包含的所有视角视频文件 url 以及角度关系信息 头部转动 : 客户端在请求到初始 url 的同时, 要记录当前的视角, 并根据从 WEB 服务器获取到的各视角视频文件 url 之间的角度关系, 将个 URL 映射到本地的各视角, 在观看过程中如果发生头部转动, 用对应 url 加上时间偏移信息向视频服务器请求新视角的视频文件 当头部转动视角发生改变时, 客户端需要请求新视角的视频流, 如下图所示,V1 为原视角的视频流,V2 为新视角的视频流 在 V2 的视频流到达之前, 为了不中断观看, 需要继续使用 V1 缓冲的内容进行观看 当 V2 视频缓冲数据达到可播放条件时, 将观看内容切换到 V2 图 4-6 点播时头部转动切换视角视频流 从头部转动到新视角视频缓冲数据可以播放, 处理过程包括如下几部分 : A. 传感器感知及处理 33

35 B. 由请求 V1 数据切换到请求 V2 数据 C. 下载 V2 数据 D. 加载显示 V2 数据 VR 直播网络方案 根据当前 V1 观看位置不同, 请求 V2 视频流的起始位置也有所不同 : 1. 如果当前 V1 观看的 GOP 刚开始播放, 剩余时间足够下载 V2 的最小播放缓冲数据, 则 V2 可以从 V1 当前播放 GOP 的下一个 GOP 开始请求数据 ; 2. 如果当前 V1 观看的 GOP 剩余时间非常少, 不足以下载 V2 的最小播放缓冲数据, 则 V2 需要从 V1 当前观看的 GOP 的下下个 GOP 开始请求数据 例如当前 V1 观看到 GOP1, 在开始观看 GOP2 之前无法把 V2 的最小播放数据下载完成, 则 V2 就要从 GOP3 开始请求数据, 当 V1 播放完 GOP2 再播放 V2 的 GOP3 内容 上面描述假设从 V1 切换到 V2 播放时, 切换的最小单位是 GOP, 如果播放器可以进行帧级的切换, 则可以在 V2 最小缓冲数据下载完成后,V1 当前 GOP 未播放完时, 就将观看内容切换到 V2, 达到更好的体验 不过进行帧级的切换需要更多的计算和渲染, 对硬件要求比更高 采用单播方式传输的直播, 和点播在本质上没什么差异, 不再叙述 对于采用组播方式传输的 FOV VR 视频直播, 每个节目包含多个视角的视频流, 每个视角对应一个组播组地址, 客户端选择不同的视角观看, 就是选择不同的组播组地址 和点播类似, 直播时服务器也要维护每个节目不同角度和对应文件的关系, 只是对于组播来说, 不同的是直播访问的地址是组播地址 在点播开始时, 客户端先向服务器请求节目信息, 获取每个节目包含的组播地址列表及相互之间的角度关系 表 4-4 FOV VR 直播节目视角集合信息 节目 组播地址列表 角度 是否起始视角 节目 a 是 节目 b 是

36 下图是 VR 直播初始加入组播组的过程, 这里把 ONT 作为 IGMP Proxy 设备, 实际上 BNG OLT 也可以作为 IGMP Proxy, 但是由于 VR 视频码流比较大, 达到 Gbps 级别, 因此建议 IGMP Proxy 的位置尽量靠近用户, 尽量减轻网络的带宽压力 客户端初始请求节目信息时, 获取到节目的组播地址列表和角度信息, 以及服务器建议的起始视角组播地址, 客户端在选择初始观看内容时, 可以用服务器给的起始视角的组播地址, 也可以自己选择 虽然初始组播地址的选择可以由客户端自己确定, 但是一旦初始视角选定, 客户端就需要以当前视角为参考, 根据从服务器下载的视角和组播地址对应关系, 建立本地各个视角与组播地址的对应关系, 以便头部转动角度发生变化的时候, 切换到对应的组播组 图 4-7 VR 直播加入组播组 客户端获取到组播地址后, 加入组播组过程没有变化 如果观看过程中头部没有转动或转动未超过一定阈值, 该视频流的观看会持续下去, 但观看内容出现少部分低清晰 当头部转动角度超过阈值后, 由于视角偏出了之前 FOV 的高分辨率区域, 观看内容的分辨率会下降, 就需要切换视频流到新视角对应的组播组 图 4-8 FOV VR 直播角度切换 35

37 另外, 以前通过 IPTV 观看传统视频时, 由于人在 场外, 而且有切换画面的思想准备, 组播组切换时间要求不高, 但 VR 由于其特有的沉浸 在场特点, 头部转动时视角切换时间要求非常高, 否则很容易感觉到画面的不连贯, 以及由于画面分辨率下降而感觉到不适 如果说以前的 IPTV 频道切换时间 2s 可以接受, 那么现在 VR 观看时切换的时间可能只有原来的十分之一 但由于组播是以固定码率传送数据, 因此为了加快切换速度, 可以使用单播将新视角将要获取的数据以更高的速率下载到本地并显示, 达到用户头部转动感知不到视频流切换的最佳效果, 不过这个时候需要多一次从单播数据到组播数据的帧拼接处理 4.6 服务可定制的网络 当前网络的现状和运营商的困境 服务可定制的网络 当前互联网应用越来越多, 并且还不断的有新的应用出现, 不同的应用由其自身的特点, 决定其需要不同的网络能力来匹配 在众多的应用中, 视频类应用在互联网流量中所占比重已经超过 70%, 并且未来还将越来越大 视频的发展, 从 360p 720p 1080p 到今天的 4K, 甚至 8K, 人们对视觉体验的要求越来越高, 目前已经达到了人眼可分辨的极限, 但人类对感官体验的追求是无止境的, 虚拟现实的出现使人们在观看视频时由被动旁观看转向了身临其境 主动参与 相比于传统的 视觉 + 听觉, 虚拟现实将视觉 听觉 触觉反馈等多维度信息进行综合, 从 2D 的图像 / 视频增强为 3D 全息的图像 / 视频, 从直接的看和听增强为多维度的互动体验 当前基于 IP 的互联网设计的初衷, 是提供尽力而为的数据传输, 但是越来越多的应用, 对数据传输的要求也各种各样, 当前的 QoS 机制除了为少数特定应用提供一定的质量保证外, 绝大部分数据都在巨大的网络洪流中被无差别的的传输 而视频作为当前网络流量占比绝对的业务, 对带宽和时延要求都比较高的业务, 但实际上网络绝大部分视频流量都和普通上网流量没有差别, 在这种情况下非常容易受到影响, 导致比较差的体验 在这个过程中, 运营商仅仅成为数据传输的管道 在网络提速降费的趋势下, 一方面宽带的价格在降低, 另一方面运营商还要不断加大对网络基础设施建设的投入, 但是效果并不明显, 民众仍然不满意, 长此以往, 运营商会缺乏足够的动力对基础网络设施持续扩容 从目前看, 简单地按照流量收费无法增加运营商的收入, 并且对所有 OTT 业务按照流量统一收费会制约互联网的创新, 影响到整个互联网生态圈的蓬勃发展 据调查, 85% 的用户愿意为更好的业务体验支付最高 25% 溢价 也就是说, 如果运营商可以为某些用户提供更好的服务质量, 那么, 得到高质量服务的用户愿意支付相关费用 例如, 2014 年 Netflix 同意向美国运营商 Comcast 付费, 确保其用户获得更快的网速 所以, 运营商应该把拥有的宝贵网络资源变为真正可运营的商品, 而不是无差别的单一管道 虚拟现实由于其沉浸感让人们的体验达到了新的高度, 同时也正是由于这种身临其境的感觉, 使得体验时的画面相当于 3 米处观看 1050 英寸的屏幕, 对于视频的分辨率 刷新率 时延提出了更高的要求 在虚拟现实环境下, 如果达到人眼可以分辨的最高分辨率,VR 全景视频播放需要的带宽将达到 2.35G(FOV 方式 ) 甚至 5G( 全视角方式 ) 若只是视频内容方只提供内容, 运营商提供管道, 通过普通的数据转发, 任何一个节点的拥塞, 都无法保证这样要求极高的大象流端到端的质量 解决这个问题有两个方向 : 一是网络自身感知承载的业务特征及传输需求, 根据需要为业务提供保障 ; 二是网络不感知具体业务, 由业务的归属方或使用者向网络申请满足传输需求的资源 由于业务的多样性和易变特点, 感知所有业务特征会导致网络复杂化, 并且造成和业务的强耦合, 对业 36

38 务和网络的发展均不利, 比较合适的第二个方向, 即管道提供者, 也就是运营商提供差异化的可定制服务, 由业务根据自身需要按需定制, 这种服务要满足按需 动态 开放 端到端的要求 按需 : 包括两方面, 一是具体业务的网络要求, 比如带宽 时延 丢包率 抖动, 可基于源地址 目的地址 五元组, 或其他业务特征, 对流量 / 业务对象进行识别, 满足该对象的流量要求 ; 二是针对网络本身而言, 随着承载的业务不断增加, 网络资源也要能够根据业务需求相应动态扩容, 反之, 业务需求降低时, 网络资源也随之缩容 动态 : 由于视频或其他需要质量保证的业务对网络的要求不同, 发生和持续时间存在不确定性, 网络设备对业务的 QoS 不是提前静态配置预留, 而是在会话发生时进行秒级端到端计算, 在沿途各节点分配资源和调度, 业务终止时资源立即释放, 供其他业务使用, 提高资源的利用率 开放 : 运营商提供友好 明确 完善的接口, 在 OTT 需要为视频业务定制网络质量保证时调用进行定制, 包括服务申请 调整 释放 计费 对账 结算等 端到端 : 业务数据流在网络上是串行经过每个节点的, 整个路径上任何一个节点的拥塞, 都会导致整个业务受影响, 因此如果要保证业务的质量, 需要端到端进行统一管理和计算, 确保每个节点都为业务提供了足够的质量保证 这就需要有一个集中的管理单元, 实时获取承载业务的网络上各设备的状态 ( 带宽 时延 抖动 ), 当发生业务请求时, 能够根据各设备的状态, 计算出合理的路径, 并向路径上每个设备下发资源预留指令, 完成整个路径的准备 图 4-9 基于业务定制网络服务 vnet( 虚拟网络 ) 需要说明一下的是, 基于流端到端分配网络资源, 对于一旦发生, 会持续使用网络资源的业务比较合适, 比如视频业务 另外, 视频源也必须确保发送码率在申请的网络资源范围内, 否则无法保证最终的体验 当前已经有些根据业务进行网络资源定制的技术研究, 比如说 vnet 和 DetNet 下面简单介绍一下这两种技术 vnet 的原理是根据业务的不同特点, 按需动态创建逻辑专网, 主要包含以下几方面 : (1) 业务协同 : 业务驱动 能力开放 切片协同 (2) 切片管理 : 网络切片生命周期管理 37

39 (3) 资源管理 : 虚拟资源管理,ICT 统一业务分发和维护 (4) 网络管理 : 根据虚拟资源需求, 进行资源预留和数据面隔离 图 4-10 vnet 逻辑专网 DetNet( 确定网络 ) DetNet 的目标是针对特定业务流提供基于二层或者三层的有限时延 低丢包率 低抖动以及高可靠性的服务, 将不同领域的专网迁移到分组交换网中 同时, 融合基于二层操作的 TSN(Time Sensitive Network, 时间敏感网络 ), 扩展针对二层 三层的通用架构 主要技术包含 : (1) 资源预留 : 应用根据需要发起请求, 在流量经过的每一节点上都进行资源预留, 如带宽 buffer 等, 采用这种方式消除阻塞导致性能无法保障情况, 同时在同步性要求较高的 DetNet 流量之间, 需要基于时间的资源共享 (2) 明确路径 :DetNet flow 经过的路径不会轻易改变, 即使面对网络出现突发情况, 中间传输节点不需要进行额外的处理, 减少传输时间, 该路径采用 MPLS TE LSP (3) 丢包保护机制 : 为防止在包传输路径上设备出现故障情况, 对包进行复制, 并在多条路径中传输, 并在接收端对包进行排序, 并且消除重复收到的包 4.7 网络动态自适应技术 -NDSA 承载网络为了适应 VR 业务的大潮汐现象, 必须考虑一种新的方案来满足业务要求, 降低网络的 CAPEX 和 OPEX 一个基本思路就是在潮汐的低谷, 暂时关闭或者释放资源给其它业务, 这些资源包括链路资源 波分资源 转发设备资源, 也可以通过关闭资源来达到降低设备功耗, 进而降低 OPEX; 通过释放资源给其它业务, 来降低总的 CAPEX 这种潮汐的动态性, 与以前上网和普通高清视频的明星不同之处在于, 潮汐的波峰和波谷差距更大, 而且波谷存续的实际更长, 如果说原来视频业务的波峰和波谷是 10 倍差距, 那么 VR 业务的波峰和波谷可能有 100 倍的差距, 同样, 网络的动态申请和释放, 可能给运营商网络带来更大的价值, 给运营商带来更大的成本节省 38

40 链路资源在不同 BRAS 和 OLT 之间灵活调配 根据资源动态申请方式和时机的差异, 下面介绍一下三种不同的方案 : 基于链路利用率阈值动态调整 控制器持续采集设备的链路利用率, 当检测到某一关键链路资源或者设备资源达到某个设定的阈值时, 控制器开始通知相关设备开启池化预留的资源, 包括传输资源 转发设备的端口 转发单板, 如果是 NFV 设备, 需要申请更多的 VM 来加入转发设备来, 以更好的应对即将到来潮汐的波峰流, 提供最佳的 VR 业务体验 同样, 当检测到链路流量持续一段时间内 ( 如 :10 分钟 ) 低于阈值时, 可以采取暂时关闭一些多余的链路 设备端口和单板, 释放一些 VM 来到达降低功耗的目前, 同时也可以把不用的资源释放给其它业务使用 也就是说整个过程是动态的 按需的 39

41 图 4-11 基于链路利用率阈值动态调整 业务按需申请 当一个 VR 用户点击了一个 VR 视频业务时, 最先获得这个信息是提供 VR 服务的业务平台 业务平台这时需要向网络的控制器发送一个请求, 并将该用户的信息送给控制器 控制器会基于该用户的信息 ( 通常是用户的源 IP 和业务平台的地址, 该业务的码流等 ), 进行端到端路径还原, 检查整个转发路径上链路资源和转发资源的利用率, 并叠加上即将开始的 VR 业务, 是否能满足用户的业务要求, 如果不能很好满足业务带宽要求, 就需要提前申请相应的链路和转发资源 图 4-12 业务按需申请 基于时间规律动态调整 我们知道, 任何一个业务, 都具有本身潮汐规律, 比如每天的 20~22 点是业务的高峰期, 比如每个周末业务比平时明显大几倍, 再比如近期是否有体育赛事等热点事件, 都是可以提前找到相应的规律 同样,VR 视频业务也不例外, 也是可以找到一些类似的规律, 做到资源提前准备, 提前申请, 以保障 VR 业务的体验 40

42 图 4-13 基于时间规律动态调整 当然, 上面这些方案, 在具体的实施和应用过程, 并不是互斥的, 可以根据需要叠加部署 在极大限度的保障业务体验的基础上, 尽可能降低网络的 OPEX, 同时方案部署也不要过分复杂, 另外该方案的部署也不会增加本身太多的部署成本, 在方案的成本和复杂度之间取得一个良好的折中 4.8 OTT VR 直播方案 SAMF 方案概述 从 4K 视频业务开始, 由于业务本身码流的增长, 所需要的网络带宽持续增高, 传统的使用 TCP 单播来做直播的方案貌似难以为继, 尤其是热点事件的视频直播 每一个用户一个单流, 整个直播业务所需要的总网络带宽就是 : 用户数 * 单流的带宽 当热点事件来临时, 在线用户数持续破纪录, 又加上 4K 视频单流需要消耗更大带宽, 给 OTT 的直播带来了很大的挑战 对于 OTT 内容提供商而言, 更多在线用户, 就意味着更多的收入 ( 包括用户付费和广告等 ), 虽然 4K 等更大码流视频可以吸引更多喜欢高质量视频的用户, 但也会给 OTT 带来更大的投入成本, 为了保证高峰期的用户体验,OTT 内容提供商必须按照热点事件的最大在线用户数向运营商购买网络出口带宽, 甚至可能出现增量不增收的现象 当然, 有的 OTT 提供商, 为了增加在线用户的最大容量, 在热点事件来临时, 降低了业务的码流, 但这个方法是个双刃剑, 降低了码流, 虽然降低了对网络的要求, 但也降低用户的观看体验, 对长期的用户发展是不利的 相比于 4K 高清视频,VR 视频在这个问题上的表现更加突出 如果说高清视频带来的成本压力,OTT 内容提供商还能勉强承受, 那么 VR 视频直播带来的超级大象流, 且随着在线用户数的叠加, 所带来的带宽消耗, 是非常惊人的 如果一个用户观看 VR 视频需要消耗的带宽是 1G, 但十万用户就是 100T,1000W 用户就是 10000T, 这么大带宽, 估计没有几个 OTT 能够承受, 连运营商的网络短期也很难满足 为了解决上面提到的问题, 就需要考虑可能的解决方案 SAMF(Shared Adaptive Multicast Framework) 方案从原理上讲很简单, 就是将单播承载的直播业务流, 在网络上传播时, 转成组播来承载, 以降低对网络带宽的占用 从组播角度来讲, 带宽占用与在线用户数没有关系, 只与组播频道数目相关, 同时由于热点事件相对集中, 直播频道数目反而是不多的 对于 OTT VR 直播内容提供商而言,CDN 出口带宽就不再是一个瓶颈 ( 一个频道一个业务流, 与在线用户数无关 ), 可以极大降低网络出口的带宽要求, 网络带宽可能是原来的十万分之一, 甚至千万分之一, 同时还 41

43 能保证用户的收视体验 当然, 这种方式涉及到商业模式的改变, 需要网络提供商进一步开放网络能力, 与 OTT 厂商共同协作才能完成 要端到端部署该方案, 首先运营商要开放自己的网络, 给 OTT VR 厂商提供使用网络组播的能力 ( 目前网络组播的能力只有运营商自营的 IPTV 业务在使用 ) 图 4-14 SAMF 方案原理图 从上图可以看出, 整个业务流量模型发生较大变化, 由原来的几个用户几份流, 变成只需要传输一个流 ( 对一个直播频道而言 ), 极大降低了网络带宽消耗, 也就意味着网络使用成本的降低 与普通的 TV 大屏不同,TV 大屏位置相对固定, 有线连接能够满足要求, 而对于 VR 眼镜而言, 无线连接是更容易被最终用户接受的方式 由于终端与家庭网关最后几米无线 Wi-Fi 对组播支持的不够友好, 还需要将组播流转为单播流 ( 注 : 新的 Wi-Fi 协议可能对组播转发支持更友好 ) SAMF 方案工作流程 SAMF 将传统 E2E 单播转变为单播 组播 单播三段式架构 图 4-15 SAMF 方案处理流程 第一段 :U2M 设备与 OTT 头端之间 ( 单播 ):U2M 实现对各种 OTT 头端流媒体协议的支持, 将其转成组播流下发 U2M 与 OTT 头端之间采用 TCP 单播, 首先使用单播是对接为了降低 U2M 设备与 OTT 头端的对接难度, 其次使用 TCP/HTTP 是为了维持原来头端系统媒体流的格式 (HLS,DASH 等 ) 不变化 第二段 :U2M 设备与 M2U 设备之间 ( 组播 ):U2M 设备与 M2U 设备之间使用标准的组播转发, 使用组播的好处也就是方案的核心, 能够极大的降低对网络带宽的消耗, 同时 M2U 无需和 OTT 头端交互而支持各种直播流媒体协议 第三段 :M2U 设备与终端 APP 之间 ( 单播 ): 上文已经提到, 由于 Wi-Fi 不能很好的支持组播流,M2U 转成单播发给终端 APP 目前看是较好的选择 但传输协议具体是使用 UDP 还是 TCP, 需要对比一下这两种方式优缺点 42

44 表 4-5 M2U 与终端 APP 之间传输方式 方案对比频道支持数流媒体协议扩展改造难度优势劣势 UDP 方式 无缓存, 受上行带宽限制 10Gbps 上行带宽可支持 500 频道 一般 UDP 方式较少, 代表为 GUIC 小 我司提供封装好的 UDP 通信 SDK,OTT APP 只需要调用 SDK 标准接口 1. 可支持加密视频流 2. 带宽需求小 3. 性能强 转发时延低 4. 可随板转发, 成本低 1. APP 必须适配修改 2. 需部署丢包重传机制 TCP/HTTP 方式 基于存储限制约 30 个, 也受下行带宽瓶颈限制 一般只会对最热门频道 (<=10) 做 M2U 方便 目前业界主流直播流媒体协议都是基于 HTTP 的 极小 遵循当前主流 HLS 下载方式, 基本不需改动 1. APP 无需修改 2. 支持丢包重传 3. M2U 不生成索引文件和分片, 无需解密视频流 1. M2U 性能受限且规格较低 2. 技术复杂 成本过高 通过上表分析可以看出, 使用 UDP 方式能够有效降低对网络设备的要求, 使 M2U 设备尽量不理解和参与具体的业务, 也不会涉及到传输层以上的处理, 能够降低对转发设备的 CPU 和存储的要求, 是方案的优先选择, 缺点是 OTT APP 需要基于新的协议 (SDK) 来适配 同时由于 APP 在播放时, 至少需要一个完整的分片文件和索引文件 ( 下面以 OTT 视频最常用的 HLS 为例 ), 通过 UDP 方式接收的第一个报文, 可能不是一个分片文件的第一个报文, 就会出现不能马上播放的情况, 需要等待下一个分片文件的报文, 这个问题增加了用户点击节目到开发播放的时间 ( 最坏情况下需要多等待一个 TS 分片时间 : 默认 10S) 当然, 方案可以考虑使用原来的单播流程来传输第一个 TS 分片, 等组播方式完整收到一个 TS 后在切换组播方式, 通过这种方式可以大大减少用户的等待时间 ( 注 : 完整的方案会涉及到 BSS/OSS 系统的对接, 本白皮书仅讨论业务工作流程 ) 43

45 图 4-16 U2M 业务处理流程 U2M 业务处理流程 : 首先, 支持新的 SDK 的终端 APP 浏览节目单 ( 获取节目单是原来的流程 ), 当用户选中确定的直播频道后,OTT 头端会根据选择的直播频道 ( 点播流程不变 ), 与直播平台进行交互 : 将 OTT 名称 频道 ID 用户 IP 等信息发送给直播平台, 直播平台返回 OTT 头端组播 URL, 并下发给 U2M 节目源单播 IP 和组播组地址 U2M 使用单播 IP 与 OTT 头端交互, 获取视频内容, 并进行视频内容进行存储, 存储后的内容使用组播进行发送 ) 图 4-17 M2U 业务处理流程 44

46 M2U 业务处理流程 : 终端 APP 将 OTT 头端返回组播 URL, 作为参数调用 SDK 函数, SDK 函数会解析里面的组播信息并发送给 M2U 设备,M2U 设备根据收到的信息, 想直播平台请求组播地址, 并加入相应的组播组, 通过组播方式获取视频内容 M2U 设备将获取的视频内容, 单播给终端 APP 4.9 对网络架构影响分析 从前面描述可以看出,VR 业务的发展, 对网络产生了显著的影响, 网络架构也要随之做出相应的改变, 这些变化主要体现在以下几方面 : 1. 超大带宽 2. 网络容量动态自适应 3. 网络能力进一步灵活开放 ( 组播等 ) 4. 与业务协同 ( 按需服务定制 差异化传输 ), 网络对业务不再是黑盒 图 4-18 面向 VR 的承载网 事物的发展是循序渐进的,VR 的发展同样遵循这个规律, 从入门体验阶段, 到进阶体验阶段, 再到极致体验阶段, 从使用者渗透率 并发率, 到 VR 视频的分辨率 刷新率 色深, 以及编解码技术都不断提高, 同样它对网络架构的影响, 也是分步骤平滑演进的, 这个过程对承载网的要求也不断变化, 网络也相应会逐步演进 上面描述的几个特征, 对不同阶段的 VR 影响和重要性不同, 可以逐步落地到网络架构中 45

47 5 VR 应用业务发展及未来网络展望 VR 是一个全新的平台, 除了全景视频和游戏等娱乐方向, 必将发展更多面向行业应用, 例如购物 看房 旅游 教育等, 会带来更多的商业模式创新, 如同 Pokemon Go 带来 位置赞助 一样 这些行业有很大的市场空间, 势必会给一些从业者带来新的机会 因此,VR 业务是面向未来的战略制高点之一, 行业内有远见的从业者都意识到这个机会, 把 VR 作为重要的业务战略 站在未来往回看,VR 必将和 AR( 增强现实 ) 一起, 逐步走向融合 MR AR 和 MR 对网络会带来新的要求和挑战 AR 和 MR 除了带来更多的信息量, 另一个变化就是更多的计算在云端完成, 这个变化一方便要求网络要能提供更低的时延更高的带宽, 特别是上行带宽, 另一方便, 要求网络和云更加协调和融合, 成为按需的具备存储 计算和信息传递的 智能管道 大带宽的同事也对网络效率, 特别是能效比提出了更高的要求, 持续降低每比特的传输成本尤为重要 总之,VR 需要一个大带宽 低时延 高能效的网络, 同时对网络的按需能力也提出了新的要求 基础通信技术的进步, 及 SDN/NFV 等架构大力发展, 为打造面向 VR 体验的承载网奠定了坚实的基础 用户对体验的追求是永无止境的, 普通视频从 SD 发展到 4K, 充分印证了这一点 我们相信,VR 也会尽快进入到 2K 甚至 4K 阶段 当前阶段的 VR 产品, 从某种意义上来说快速培养了用户习惯, 普及了消费者对 VR 业务的认知, 对产业发展有一定的积极作用, 但我们也应认识到, 真正的 VR 可以做得更好 因此,VR 产业迫切需要一个基于体验的标准化评估体系, 该体系一方便有利于推动 VR 产品的成熟, 同时, 也有利于引导产业从内容 配套产品 承载网络等各个环节快速弥补短板, 加快 VR 应用的普及 华为正在展开相关研究, 也期望产业链伙伴一起, 共同推动标准的成熟和产业的发展, 为建立更好的全连接世界贡献力量 46