2023年12月20日发(作者：凤丝)

Cloud VR网络方案白皮书Cloud VR网络方案白皮书华为iLab·极致体验华为iLab发布| 1

2 |

Cloud VR网络方案白皮书前言Cloud VR，是将云计算的理念及技术引入到VR业务应用中，借助高速稳定的承载网络，云端的显示输出和声音输出等经过编码压缩后传输到用户终端，实现VR业务的内容上云、渲染上云。目前，较好的用户体验大多依赖高性能设备做本地渲染，Cloud

VR让用户无需购置昂贵主机或高端PC即可轻松享受各种VR业务，将促进VR业务的普及。2017年，我们围绕Cloud VR业务发布了《面向Cloud VR的承载网络白皮书》。2018年，我们继续围绕VR用户体验的提升为主线，结合Cloud VR最新的技术发展趋势和商用部署经验，进一步细化分析了Cloud VR不同阶段下的承载网络需求，给出了Cloud VR网络承载方案以及网络演进方向，为运营商部署Cloud VR业务提供参考。| 3

目录Contents前 言

1 Cloud VR概述1.1 Cloud VR业务场景概述1.2 Cloud VR发展的三个阶段1.3 Cloud VR网络的发展策略2 Cloud VR网络要求2.1 影响Cloud VR体验的关键因素2.2 Cloud VR要求确定性低时延 2.2.1 VR业务时延要求 2.2.2 Could VR网络时延分配2.3 Cloud VR要求n*4K视频带宽 2.3.1 Cloud VR网络带宽的影响因素 2.3.2 Cloud VR的带宽要求2.4 Cloud VR的丢包要求2.5 Cloud VR网络需求汇总3 起步阶段Cloud VR网络解决方案3.1 目标网络架构3.2 家庭网规划设计 3.2.1 Cloud VR家庭网面临的挑战 3.2.2 Cloud VR家庭网规划建议3.3 接入网设计：10G PON为主，EPON/GPON受限开通3.4 城域网规划设计：基于4K承载网进行扩容升级3.5 Cloud VR承载设计 3.5.1 4K承载方案现状 3.5.2 双通道场景Cloud VR承载方案8464 |

Cloud VR网络方案白皮书 3.5.3 单通道场景Cloud VR承载方案 3.5.4 投屏承载方案建议 3.5.5 Cloud VR承载方案建议总结3.6 带宽与QOS部署设计

3.6.1 带宽规划方法

3.6.2 QOS部署建议3.7 Cloud VR运维方案28293 舒适体验阶段Cloud VR网络设想4.1 目标网络架构设想

4.2 家庭网方案设想 4.2.1 802.11ac 4*4 MIMO 4.2.2 802.11ax技术4.3 接入网技术要求4.4 城域网技术要求

4.5 带宽时延可保障方案设想5 理想体验阶段Cloud VR网络展望5.1 Wi-Fi技术演进：60GHz5.2 接入技术演进：25G/50G/100G PON5.3 确定性低时延的云网协同网络383844454546A 缩略语48| 5

Cloud VR概述1.1 Cloud VR业务场景概述VR是计算机构造出虚拟环境，人在这一具备立体空间信息的虚拟环境之中进行实时的互动。VR业务场景日趋丰富，中国信通院、华为iLab、华为C&SI商业咨询部在VR产业研究及海内外行业洞察过程中，将Cloud VR场景划分为Cloud VR 2C应用场景和Cloud VR 2B应用场景两大类，如下表：表1-1 Cloud VR业务场景根据高盛发布的VR/AR产业报告以及当前运营商业务开展的情况预测，VR应用最先普及和推广的将是巨幕影院、VR 360°全景视频、VR直播、VR游戏和VR教育。这些应用场景的业务从交互维度上可分为VR弱交互业务和VR强交互业务两大类。

VR弱交互业务当前主要是VR视频业务，包含巨幕影院、360°全景视频、VR直播等，用户可以在一定程度上选择视点和位置，但用户与虚拟环境中的实体不发生实际的交互（如触摸）。强交互VR包含VR游戏、VR家庭健身、VR社交等，用户可通过交互设备与虚拟环境进行互动，虚拟空间图像需对交互行为作出实时响应而生成。1 |

Cloud VR网络方案白皮书1.2 Cloud VR发展的三个阶段Cloud VR业务的发展以体验为主线，是画质、交互感等不断提升，沉浸感越来越好的演进过程。内容制作技术、传输技术和网络技术的匹配度决定了Cloud VR沉浸体验能达到的程度。我们认为，Cloud VR业务体验提升的演进可经历如下三个阶段：起步阶段、舒适体验阶段和理想体验阶段。起步阶段在起步阶段，内容以4K VR为代表，终端屏幕分辨率为2K~4K，用户看到的画面质量相当于在传统TV上观看240P/380P的PPD（Pixels Per Degree，角度像素密度）效果。对于VR视频业务，主要考虑全视角传输方案。对于强交互VR业务，需要比视频更高的帧率以保障用户业务体验；另外强交互VR不存在全视角传输，只有FOV（(Field of View，视场角）传输方式，需要终端支持异步渲染等技术，用户才能获得流畅的体验。舒适体验阶段在舒适体验阶段，内容以8K VR为代表，终端屏幕分辨率为4K~8K，芯片性能、人体工程有所提升，用户看到的画面质量相当于在传统TV上观看480P的效果。这个阶段，Cloud VR各类业务的良好体验要求对网络的带宽、时延要求也将显著提高。对于VR视频业务，全视角传输方案依然会被首先考虑，以保证良好的观看和交互体验；但随着全视角8K的3D视频出现，超过百兆的带宽需求会促进FOV方案的使用。对于强交互VR业务，分辨率相比前一阶段进一步提升，带宽需求也进一步增大。理想体验阶段在理想体验阶段，内容以12K或者24K VR为代表，终端屏幕分辨率为8K~16K，终端和内容的发展可使用户获得最佳的使用体验。另外H.266视频编码标准、光场渲染技术等将广泛应用。对于VR视频业务，继续全视角传输方案对网络带宽要求变高，而采用FOV方案成为主流，可以极大降低对带宽的要求。对于强交互VR业务，分辨率的显著提升使得带宽的需求进一步增大，用户交互体验的提升要求更低的网络时延。| 2

1.3 Cloud VR网络的发展策略

Cloud VR不同发展阶段对网络传输的需求有较大的差别，结合具体传输技术的发展和演进，网络在不同阶段的发展策略建议如下：1. Cloud VR起步阶段：新建Wi-Fi家庭网络，扩容改造4K Ready承载网· 家庭网络建议增加部署高性能的5GHz Wi-Fi AP进行Cloud VR业务承载，并通过合理的规划避免与原有上网业务干扰。· 承载网基于4K ready网络进行扩容改造，具体包括OLT PON升级、OLT上行扩容、城域网扁平化、OTN到CO等。2. Cloud VR舒适体验阶段：升级增强Wi-Fi家庭网络和承载网，构建带宽时延可保障的网络· 家庭网络Wi-Fi建议采用 4*4 MIMO技术或802.11ax技术。

· 承载网持续升级扩容：接入FTTH需全面升级为10G EPON/GPON；城域网需更大容量更高集成度的硬件设备，面向云化应采用CU分离架构；云渲染服务器适当下沉。· 需构建带宽时延可保障的网络，核心诉求包括意图感知、质量感知、问题识别、网络优化等。3. Cloud VR理想体验阶段：网络需向更大带宽、更低时延方向演进· 60G Wi-Fi可能会被应用，固定接入网络将向25G/50G/100G PON 技术演进。· 云渲染服务器需要下移至城域边缘，网络将向云网协同技术方向演进。3 |

Cloud VR网络方案白皮书Cloud VR网络要求2.1 影响Cloud VR体验的关键因素虚拟现实体验具有3I的特征，分别是沉浸感（Immersion）、交互性（Interaction）和想象性（Imagination），其主要优势也是这三个特征体现的。· 沉浸感：是指利用计算机产生的三维立体图像，让人置身于一种虚拟环境中，就像在真实的客观世界中一样，能给人一种身临其境的感觉。· 交互性：在计算机生成的这种虚拟环境中，人们可以利用一些传感设备进行交互，感觉像在真实客观世界中一样。· 想象性：虚拟环境可使用户沉浸其中萌发联想。与其相对应，虚拟现实的体验评价也主要有三个因素：真实感、交互感和愉悦感。· 真实感：主要跟分辨率、色深、帧率、编码压缩技术等相关，过低的画面质量和音频质量都会导致感觉不真实，让人无法沉浸其中，同时也影响交互感。要带来愉悦的真实感受，要求Cloud VR承载网络的带宽要能满足高画面质量传输的要求。· 交互感：区别于本地VR系统，Cloud VR在计算、渲染上云后，远端处理产生的时延直接影响VR体验的交互性，进而影响沉浸感和想象性，特别是由于时延导致的晕动症是Cloud VR面临和必须解决的最大问题。此外加载、切换、手柄操作的响应迟滞时间也直接影响VR的交互感，可以说，交互感与Cloud VR承载网络的时延强有关。· 愉悦感：主要取决于VR体验流畅程度，这跟卡顿、花屏次数、时长占比等网络因素强相关，当愉悦感降低，用户就无法很好地沉浸在里面萌发想象。愉悦的体验感受要求Cloud VR承载网络的带宽、时延、丢包等指标均需满足VR用户体验的要求。图2-1 Cloud VR体验关键因素与网络的关系图| 4

切换时间、加载时长有轻微影响，不是必须满足的指标，可根据现网情况适当放宽要求。但Could VR的强交互业务画面是由云2.2 Cloud VR要求确定性低时延端实时渲染生成的，时延对画面的刷新质量、用户交互感有直接影响，时延成了必须满足的确定性指标。从理论和实测结果看，起步阶段要求≤20ms，舒适体验阶段和理想体验阶段的时延要求会进一步严格（预计舒适体验阶段要求≤15ms、理想体验阶段要求≤8ms），对网络提出了新的挑战。2.2.1 VR业务时延要求对于Could VR视频业务，参考4K视频的分析，网络时延在20~40ms即能满足要求，不同的时延只是对画面加载时间产生影响。但是对于Could VR强交互业务，为了保证用户的交互感和愉悦感，对时延有如下三个要求：1. MTP时延要求≤20毫秒（端云异步渲染方案下MTP时间不再依赖网络和云渲染，可由终端保证）。2. 云渲染及流化时延要求为30~70毫秒。· 在起步阶段，云渲染及流化时延建议≤70毫秒，画面黑边和质量的劣化在可接受范围。· 在舒适体验阶段，云渲染及流化时延建议≤50毫秒，此时基本消除黑边现象。· 理想体验阶段，云渲染及流化时延建议≤30毫秒，此时位置移动时画面的扭曲将让人无法察觉。3. 操作响应时延要求≤100毫秒。 操作响应时延由云渲染及流化时延，加上终端的二次渲染、异步扭曲和刷新呈现构成。操作响应时延减去云渲染及流化时延的要求70ms后，剩余30ms，大于终端对二次渲染、异步扭曲和刷新呈现的MTP时延要求。 因此只要保证云渲染及流化时延要求，就能同时满足操作响应时延要求。图2-2 端云异步渲染技术方案下的MTP、云渲染及流化时延、操作响应时延5 |

Cloud VR网络方案白皮书2.2.2 Could VR网络时延分配云渲染及流化时延分为云端处理、网络传输、终端处理三部分，不同阶段的时延规划建议参见下图；图2-3 强交互VR业务端到端时延规划建议把网络的时延再分解到家庭Wi-Fi、固定接入网、城域网络各部分，时延建议如下表：阶段起步阶段舒适体验阶段理想体验阶段端到端网络RTT≤20 ms≤15ms≤8 ms家庭Wi-Fi≤10ms≤7ms≤5ms固定接入网≤2ms≤2ms≤2ms城域承载≤8ms≤6ms≤1ms对于不考虑VR强交互业务，只发放VR视频业务的网络，如果要求播放或切换频道时画面加载时间在1s以内，那么网络时延要求在20ms以内；如果对画面加载时间不作要求，则对网络时延的要求可以放宽至30ms~40ms，对VR视频的体验也不会有太大影响。| 6

2.3 Cloud VR要求n*4K视频带宽Could VR的沉浸性终端拥有远高于传统TV的视场角，为了实现与4K视频一样的清晰度，其分辨率、帧率、码率都必须高于4K视频业务，对网络有着更高的带宽要求。经实测和理论分析，Cloud VR的带宽要求如下表所示：2.3.1 Cloud VR网络带宽的影响因素影响Cloud VR网络带宽需求的因素主要有分辨率、帧率、色深、视场角、编码压缩技术、传输方式等方面。◆ 分辨率：由于VR的沉浸性终端拥有远高于传统TV的视场角，决定了要达到同样等级的画质体验，要求VR具有更高的单眼分辨率和全视角分辨率。全视角的4K分辨率并不能达到满意的视频质量，加大分辨率到8K及以上是必须的。以FOV=90为例，全视角分辨率达到8K时，单眼分辨率为1920*1920，对应PPD=22，实际画面体验只相当于传统SD视频。◆ 帧率：帧率需要达到一定标准以上，画面才能达到动作清晰流畅无模糊残影。帧率过低会导致画面变差，甚至让一些游戏玩者产生头晕恶心等强烈不适感。Could VR游戏的帧率最好在90帧/秒以上，VR视频的要求会低一些，30帧/秒即可达到较好效果。◆ 色深： 在Cloud VR起步阶段，图像清晰度不高的情况下，对色深要求不高，一般为8Bit即可。后续随着分辨率提升，色深也会相应提升至10~12Bit。◆ 视场角：用户在虚拟环境中的视野可以认为是一个空间球，左右横向全视角展开是360度，上下纵向展开是180度。用户在使用终端时，单眼实际看到的视觉信息只是全部球面数据的一部分，这部分面积由终端提供的视场角FOV决定。人眼的左右眼的水平视场为160°、垂直视场为150°，双眼水平视场为200°左右。当前Cloud VR起步阶段的VR终端设备（如电视、VR眼镜）可支持的视角大约在90°~110°之间，单眼通过VR终端设备看到的有效球面信号小于球面全景信号的19%。将来随着产业发展，市场角扩大可使用户获得更好的体验。◆ 编码压缩技术：Could VR起步阶段主要采用的编码技术是H.264。在引入8K内容后，需要升级为H.265，在保证同等画质的前提下，其压缩比相对于H.264的最新版本可提升30%左右。MPEG等标准组织的最新研究进展表明，对应于HEVC的下一代编码技术（H.266）的压缩比能比HEVC再提升30%左右。随着分辨率的提升，理想体验阶段可考虑使用。◆ 传输方式：VR画面的在线传输有两种主要的技术路线：全视角传输方案和FOV传输方案。全视角传输方案就是将360度环绕的画面都传输给终端，当用户头部转动需要切换画面时，终端即时(Just-in-time)完成包括码流解析、视频解码和画面渲染等处理，用户看不到的那部分信息网络资源造成了比较大的浪费。FOV（Field of View）传输方案是基于视角进行有差别传输VR画面的方案，主要关注当前视角区域画面的高质量传输。FOV传输具体实现的技术还未统一，华为推荐的Tile Wise传输方案采用低质量全视角+高质量可视区域传输，在内容准备侧，将VR画面划分为多个tile，每个区域对应一个可以独立解码的码流；同时再准备一个低质量的全视角的VR码流；客户端获取一个全视角的低质量的码流，以及高质量的根据视角选择的tile。7 |

Cloud VR网络方案白皮书图2-4 Tile Wise传输方案2.3.2 Cloud VR视频业务的带宽要求Cloud VR视频业务的带宽要求对于VR视频业务，起步阶段主要采用全视角传输，后面随着产业的发展，分辨率提升，为了节省网络带宽，可以逐渐选择采用FOV方案进行传输。全视角方案下，码率的计算方式如下：平均码率 = （传输画面像素点* 每像素比特位* 帧率） / 压缩比对于2D视频，传输画面像素点 = 全视角分辨率，对于3D视频，传输画面像素点约为2D的两倍。色深为8bit时，抽样后每像素比特位为12，色深为10bit时，每像素比特位为15，色深为12bit时，每像素比特位为18。由于视频流并不是完全平稳的，有流量突发的情况，所以根据4K视频的测试经验，当网络带宽≥平均码率1.5倍时，可保证视频流畅播放，所以网络带宽需求按照1.5倍于平均码率来计算，即：网络带宽 = 1.5 * 平均码率

FOV方案下，当采用传输低质量全视角+高质量可视区域的Tile Wise传输方案，网络带宽约为全视角方案所需带宽的53%。| 8

基于上述的计算模型，对于Coud VR发展三个阶段的VR视频业务带宽估算结果如下：注1：起步阶段的4K压缩比基于H.264取业界典型值，后面阶段的压缩比根据业界经验测算得到，主要考虑编码方式、帧率、分辨率因素：（1）编码从H.264到H.265，H.265到H.266压缩比预计分别提升30%左右；（2）帧率提高一倍，压缩比预计提升50%左右；（3）分辨率提升一倍，压缩比预计提升15%左右。强交互业务的带宽要求对于强交互VR业务，都是基于当前视角进行实时渲染，全部采用FOV方式。强交互业务流由I帧和P帧组成，I帧含有所在图像所有的信息，采用帧内编码恢复自身图像；P帧是前向预测帧，根据前一个I帧或者P帧结合算法恢复自身图像；每个GOP（Group of Pictures）时间内包含一个I帧和N个P帧，其中N= GOP时间*帧率-1。强交互业务采用端云异步渲染，把画面扭曲到新的视角时，为减小或消灭新的视角范围内黑边对体验的影响，VR需要进行超视角画面的渲染和传输，建议各个方向都超出6度。端云异步渲染根据景深或运动矢量等信息调整物体间的位置关系，每一帧画面需额外传输15%的景深和运动矢量信息。码率的计算如下：平均码率 =（ I帧大小* 1 + P帧大小* GOP时间*帧率）*（1+冗余纠错信息）/ GOP时间帧大小 = （传输画面像素点* 每像素比特位）* 额外景深信息 / 压缩比9 |

Cloud VR网络方案白皮书其中冗余纠错信息按10%估算，平均GOP时间为2秒，异步扭曲超视角渲染角度建议为12（每个方向6度），FOV额外画面约为10%。强交互业务云端以帧率生成并发送I帧和P帧，网络带宽需要满足快速完成I帧和P帧发送的要求。为了保证画面质量，保证云渲染和流化时延，起步阶段预留给帧数据发送时间约为10~15ms，舒适体验阶段为5~10ms，理想体验阶段为4ms。帧数据发送时间 = 帧大小 / 带宽，所以P帧需要的带宽为P帧大小/帧发送时间。由于I帧比较大，且每个GOP时间内只有一帧，如果要求每个I帧都及时发送，对带宽要求太过严格。当I帧发送不及时，终端未能及时收到的时候，可以使用插帧技术（利用上一帧数据）来生成画面（参见下图），但是插帧对体验有一定的影响，建议最大插帧不超过2帧，否则对业务体验影响明显。所以I帧需要在3个帧周期内发送完成，而P帧需要在每个阶段预留给帧发送的时间内发送完成。即：带宽需求 = MAX[ I帧大小/( 3*帧周期），P帧大小/帧发送时间]基于上述的计算模型，对于Coud VR发展三个阶段的强交互业务单用户带宽估算结果如下：注1：强交互业务内容为实时渲染生成，没有全景画面，内容分辨率是指需要渲染的画面的分辨率。注2：起步阶段的4K压缩比基于H.264取业界典型值，后面阶段的压缩比根据业界经验测算得到，主要考虑编码方式、帧率、分辨率因素：（1）编码从H.264到H.265，H.265到H.266压缩比预计分别提升30%左右；（2）帧率提高一倍，压缩比预计提升50%左右；（3）分辨率提升一倍，压缩比预计提升15%左右。| 10

2.4 Cloud VR的丢包要求视频点播业务目前一般使用TCP传输，丢包对TCP影响是降低通量，卡顿。根据TCP吞吐量评估的经典公式：在确定的RTT和带宽通量要求下，可计算得到视频点播业务网络丢包要求如下：强交互业务和视频直播业务建议使用UDP传输，丢包对造成花屏、黑屏等问题。参考4K视频已经测试的数据，在无RET重传情况下，丢包在1E-5时，对体验会有轻微影响，在1E-6时，影响已经无法感知。所以此类业务丢包率要求建议如下：11 |

Cloud VR网络方案白皮书2.5 Cloud VR网络需求汇总基于上面的分析，相对于传统视频业务， Cloud VR视频主要是对网络的带宽提出了更高要求；而VR强交互业务则对网络的带宽和时延等同时提出了更高的要求。如下表，Cloud VR业务沿着体验提升的主线，在三个阶段的不同网络要求，包括带宽、时延、丢包率，并按照VR视频业务和VR强交互业务分类表述。表2-1 Cloud VR不同发展阶段对网络KPI的要求注1：强交互业务内容为实时渲染生成，没有全景画面，内容分辨率是指需要渲染的画面的分辨率。注2：带宽需求按单个VR终端用户计算。注3：VR视频业务对网络RTT并没有很严格的要求小于20ms，但时延较小的情况下进行切换频道，开始播放等操作时画面加载的时间比较短。如果对画面加载时间没有太高要求，那么网络RTT可以也放宽至30~40ms。| 12

起步阶段Cloud VR网络解决方案本章节主要从理论上分析起步阶段Cloud VR业务的承载网络部署方案，部分方案还没有在现网中部署。现网已商用部署方案请参考华为iLab发布的《Cloud VR解决方案实践报告》。3.1 目标网络架构在Cloud VR起步阶段，单路VR业务带宽要求为80Mbps，同时开通4K IPTV和上网业务后，用户带宽建议为VR 80Mbps + 4K IPTV 50Mbps + HSI 100Mbps = 230Mbps及以上。其中，VR的投屏业务通过4K IPTV通道下载，要求头端对VR投屏流量压缩到4K视频的带宽水平。如果头端压缩不了投屏流量，则带宽变成VR 80Mbps + 4K IPTV（含投屏）80Mbps + HSI 100Mbps = 260Mbps。考虑到当前大部分头端对投屏业务没有做压缩，后续统一按260Mbps带宽进行计算。在Cloud VR起步阶段，网络RTT要求为20ms，分解到各段网络如下表所示：表3-1 Cloud VR起步阶段时延要求分解端到端网络RTT≤20 ms家庭Wi-Fi≤10ms固定接入网≤2ms城域承载≤8msCloud VR起步阶段的建网目标是基于已有的网络实施局部改造，实现Cloud VR业务的快速低成本部署。为此，起步阶段Cloud VR网络解决方案核心理念是“基于Wi-Fi的家庭网”+“基于4K ready的承载网”+“利旧CDN/新建云渲染服务器”，如下图所示：图3-1 起步阶段Cloud VR承载网目标架构◆ 基于Wi-Fi的家庭网：传统4K机顶盒往往建议使用网线接入网络，而Cloud VR头盔则要求必须Wi-Fi接入，所以需要构建基于Wi-Fi的家庭网来实现Cloud VR业务承载。其中重点的则是高性能Wi-Fi AP的部署。13 |

Cloud VR网络方案白皮书◆ 基于4K ready的承载网：为了低成本快速部署Cloud VR业务，可以依托4K Ready的极简承载网络架构，根据Cloud VR带宽时延要求进行局部调整，包括：· GPON/EPON升级10G GPON/EPON· OLT上行端口扩容升级· 城域网扩容升级/OTN一跳直达等◆ 利旧CDN/新增云渲染服务器：在起步阶段，可以复用现有的CDN资源进行Cloud VR视频的内容分发，同时新增云渲染服务器进行Cloud VR游戏的内容分发。一般要求CDN/云渲染服务器部署在城域内。该解决方案可以带来如下好处：◆ 最大程度复用现网资源：复用IP网络、光网络、FTTH接入网、CDN资源等，按需进行容量升级就可以解决大部分问题。◆ 尽可能降低部署难度：通过复用上网通道进行Cloud VR承载，可以避免重新布放一套VLAN、IP地址、认证账号。◆ 创造家庭新产品/服务销售机会：基于Cloud VR高体验保障诉求，为运营商创造面向消费者销售新家庭网关、以及智能组网服务的机会。3.2 家庭网规划设计3.2.1 Cloud VR家庭网面临的挑战为了保证移动便利性，VR头盔一般采用Wi-Fi无线连接方式，在进行Wi-Fi部署时，普遍存在三类问题和挑战：5GHz Wi-Fi可用信道少，承载Cloud VR时存在规划难题现有Wi-Fi网关的能力参差不齐

Cloud VR如何与现有家庭业务共存而相互不影响| 14

5G Wi-Fi可用信道少，存在规划难题2.4G Hz频段信道少且相互重叠，按20MHz频宽计算也只有3个独立信道，总频宽不足80Mhz，难以承载Cloud VR业务。5GHz Wi-Fi理论最大激活速率可达3466Mbps，比较适合用于承载Cloud VR。图3-2 欧洲5G Wi-Fi频谱规划5G Wi-Fi频谱分布如上图所示（不同国家不同，以欧洲为例）：20MHz频谱支持19个，40MHz频谱支持9个，80MHz频谱支持4个，160MHz频谱支持2个。其中大部分是DFS信道，非DFS信道数量很少，在常用的80MHz上只有1个可用信道。从市场已有的消费级AP能力看，为了降低实现复杂度，大部分不支持DFS信道，导致家庭网络中的5G Wi-Fi集中拥挤在非DFS信道中，产生较为严重的干扰。干扰会引发空口竞争和冲突，报文需要等较长时间才能得到发送机会，或者发送时遇到冲突需要重新发送，使得报文的发送时延变大。如果时延超过设备容忍时长，或者重传次数超过阈值，就会表现为丢包。同时，干扰会导致Wi-Fi可用速率变低，如果低于Cloud VR所需带宽，就会发生报文队列持续增长的现象，最终溢出丢包。图3-3 干扰引发时延和丢包示意图综上，Cloud VR在部署时，首先要解决5G Wi-Fi的信道如何规划利用的挑战。15 |

Cloud VR网络方案白皮书现有Wi-Fi网关性能能力参差不齐目前市面上支持5GHz Wi-Fi的设备有很多，但价格和性能却参差不齐。根据iLab实验室针对几款较为常见的5GHz Wi-Fi产品来进行测试发现，不同产品型号对干扰环境的适应程度有较大差异，测试结果如下表所示：表3-2 不同型号设备支持的干扰不一样根据测试结果可以发现：◆ 在无干扰的情况下，5个型号的设备都能够满足RTT时延要求；◆ 存在两路邻频干扰的情况下，4个型号的设备都能够满足RTT时延要求，1个型号的设备无法满足RTT时延要求；◆ 存在1路邻频干扰和1路同频干扰的情况下，只有2个型号的设备都能够满足RTT时延要求，3个型号的设备无法满足RTT时延要求；◆ 存在2路同频干扰的情况下，只有1个型号的设备都能够满足RTT时延要求，4个型号的设备无法满足RTT时延要求；由此可见，Cloud VR在部署时，选择高性能的Wi-Fi产品是关键。Cloud VR如何与现有家庭业务共存而相互不影响Cloud VR是基于4K ready网络增量开通的业务，需要考虑与已有的4K IPTV业务、HSI业务进行共存，避免不同业务间产生冲突干扰。在4K Ready承载网中，由于IPTV推荐采用有线方式接入，上网业务采用Wi-Fi方式接入，所以核心是如何保证上网业务的Wi-Fi不对Cloud VR的Wi-Fi产生影响。| 16

3.2.2 Cloud VR家庭网规划建议为了解决上述挑战，Cloud VR家庭网 络部署时，需重点考虑如下方面：· 需选择合适的Wi-Fi频宽和信道。 需要给VR业务选择适合的5G Wi-Fi频宽，确保有足够的带宽承载；同时，由于5G Wi-Fi信道少，需要运营商对信道进行合理规划。· 需要定义和选择高性能的Wi-Fi网关。· 需要选择合适的组网形态，确保Cloud VR与现有家庭业务共存而相互不影响。Wi-Fi建议选择80MHz频宽、2*2 MIMO，运营商提供信道规划服务5GHz Wi-Fi可选的频宽包括20MHz、40MHz、80MHz、160MHz四种选择，不同的频宽支持的速率不一样。考虑到当前市面上大部分VR头盔支持2*2 MIMO，因此后续计算以2*2 MIMO为基础进行。下图是2*2

MIMO情况下，不同频宽在不同MCS（Modulation and Coding Scheme）制式下的最大理论速率。表3-3 Wi-Fi速率表实际上，由于5GHz Wi-Fi信道少，大规模部署5GHz Wi-Fi后，同频干扰可能无法规避。在考虑存在两路同频干扰情况下，Wi-Fi速率按照MCS6制式，考虑50%占空比以及40%传输损耗后，实际数据速率约为MCS6速率*50%*(1-40%)，即：20M频宽支持速率为39Mbps，40M频宽速率为81Mbps，80MHz频宽速率为175Mbps，160MHz频宽速率为350Mbps。考虑到160MHz频宽基本没有终端支持，推荐Cloud VR使用80MHz频宽进行承载。不同国家的5GHz频段规划不一样，5GHz Wi-Fi可使用的信道数量也不一样。以欧洲为例，当采用80MHz频宽时，5G Wi-Fi只有4个信道可供部署。由于信道选择过程复杂，用户很少具备Wi-Fi部署的工程能力，建议运营商需要提供上门安装服务，对现场的Wi-Fi信道情况进行扫描识别，并基于扫描结果设置合适的Wi-Fi信道和合理的Wi-Fi网关安装位置。17 |

Cloud VR网络方案白皮书高性能Wi-Fi网关要求：抗干扰能力强，支持雷达信道和千兆端口为避免低性能Wi-Fi网关对Cloud VR业务体验造成影响，建议构建高性能Wi-Fi网关标准进行产品筛选。根据iLAB测试结果，该标准主要包括：◆ 在2~4路同频干扰的情况下，支持小于10ms的稳定空口传输时延和80Mbps以上的稳定空口传输速率。◆ 支持雷达频段设置和雷达自动检测功能。 5G可用信道少，以欧洲为例，5G Wi-Fi只有4个信道可部署，其中3个为DFS信道。为了避免所有家庭都集中到一个非DFS信道上产生大量同频干扰，需要考虑把DFS信道也利用起来。对于运行在DFS信道的Wi-Fi网关，需要支持DFS定期检测功能，检测当前信道是否存在雷达干扰，如果检测到干扰，则需要切换到其他信道。◆ 具备2个及以上的千兆端口，支持灵活的组网方式，减少线路改造的需求。Cloud VR家庭网络部署建议：采用高性能独立AP承载Cloud VR业务Cloud VR是基于4K ready网络增量开通的业务，需考虑与现有的4K IPTV、上网业务共存的问题，IPTV采用有线方式接入，所以核心问题是如何保障使用Wi-Fi接入的上网业务和Cloud VR业务互不影响。为了解决此问题，有如下三种部署方案：◆ 方案1：新增高性能专用AP承载Cloud VR业务: VR业务体验有保障，推荐部署。◆ 方案2：利旧现网的ONT/HGW承载Cloud VR业务：现网ONT/HGW只支持一个5GHz频段，故Cloud VR业务只能和上网业务通过这同一个5GHz Wi-Fi频段进行承载，VR业务体验会受到影响，同时现网ONT/HGW性能一般较弱，不支持雷达信道 ，可用信道少，易产生冲突。不推荐部署。◆ 方案3：将现网ONT替换成高性能三频Wi-Fi ONT（2*5GHz + 1*2.4GHz）:当前存在大量ONT部署在弱电箱的情况，更换ONT也无法为Cloud VR业务提供Wi-Fi接入，并且，当前市面上暂无可用的支持三频Wi-Fi ONT产品。暂不用考虑此方案。| 18

下面对推荐部署的方案1进行详细描述：在具体部署时，根据ONT部署位置的差异，选择不同的连接方式，分为2个场景：场景1：ONT部署在弱电箱时，AP存在两种接入方式ONT部署在弱电箱时，主要的组网方式是ONT通过网线连接客厅的HGW，上网业务由HGW的5GHz

Wi-Fi/2.4GHz Wi-Fi接入， IPTV业务接入由HGW的ETH口接入。部署Cloud VR业务时，新增的AP可以通过如下两种方式接入：方式1：AP通过网线直连HGW，改造简单，现网千兆HGW情况下推荐选用在该接入方式下，无需改动原家庭组网的连接关系，改造简单。但是Cloud VR业务流量先经过HGW转发至AP，对HGW的带宽要求较高，在起步阶段，Cloud VR带宽需求为80Mbps，可以利旧千兆HGW和百兆HGW；在舒适体验阶段，Cloud VR带宽需求为260Mbps，只能利旧千兆HGW，所以此方式比较适合现网千兆HGW的情况。方式2：AP串接在ONT和HGW之间，改造较复杂，现网百兆HGW情况下推荐选用在该接入方式下，需要改动原家庭组网的连接关系，并将PPPoE拨号上移至ONT，改造较复杂。但是，由于新增AP负责Cloud VR业务的分流，现网HGW的流量不变，即使是百兆HGW也可利旧，所以此方式比较适合现网百兆HGW的情况。图3-4 新增Cloud VR专用AP组网示意图（ONT部署弱电箱）19 |

Cloud VR网络方案白皮书场景2：ONT部署在客厅桌面，AP网线直连ONTONT部署在客厅桌面时，上网业务由ONT的5G Wi-Fi和2.4G Wi-Fi接入， IPTV业务接入由ONT的ETH口接入。部署Cloud VR业务时，新增的Cloud VR专用AP只能通过网线与ONT连接。具体布线图如下图所示。图3-5 新增Cloud VR专用AP组网示意图（ONT部署客厅桌面）| 20

3.3 接入网设计：10G PON为主，EPON/GPON受限开通在起步阶段，分解给接入网的时延要求为≤2ms，使得铜线和Cable不适合用于承载Cloud VR，只有FTTH一种方案是合适的。当前主流的FTTH制式为GPON、EPON，正常情况下，时延即可满足起步阶段VR的要求，重点需要考察带宽的满足度，分析如下表所示：表3-4 FTTH用户可获得带宽情况注：用户可获得带宽 = 容量/分光比/收敛比由于Cloud VR叠加4K IPTV和上网业务的带宽诉求是260Mbps或更高。因此，不管是EPON还是GPON都不能大规模开通起步阶段Cloud VR业务，只能受限开通少量用户。为了大规模满足VR的带宽需求，需要逐步将FTTH接入方式升级到10G EPON/10G GPON，即使在分光比1:64情况下，考虑50%收敛，每用户可获得带宽达到312Mbps，完全可满足起步阶段Cloud VR业务的带宽需求。EPON和GPON向10G EPON/10G GPON演进升级建议如下：EPON向10G EPON演进：EPON和10G EPON的上行波长重合，可以通过时分复用方式共用同一ODN；下行波长没有重叠，可以基于波长范围接收对应的波长。因此，EPON向10G EPON演进时ODN无需变动，需要增加10G EPON单板，将EPON 用户平滑割接到10G EPON，原EPON的ONT可以继续使用，按需替换为10G EPON的ONT。值得注意的是，在混跑的情况下，由于EPON和10G EPON上行速率不一致，用户的上行带宽规划会比较复杂。21 |

Cloud VR网络方案白皮书图3-6 EPON/10G EPON波长范围图3-7 EPON升级到10G EPON部署建议GPON向10G GPON演进：如下图所示，GPON和10G GPON的上行波长没有重合，可以通过波分复用方式共用同一ODN，下行波长没有重叠，可以基于波长范围接收对应的波长。由于 GPON与10G

GPON相互独立，带宽可以独立规划。图3-8 GPON/10G GPON波长范围| 22

GPON向10G GPON演进存在两种方案，方案一外置WDM1r合波器方案：即通过外置WDM1r合波器将10G GPON口和GPON口的波长合波后通过同一主干光纤传输，原GPON的ONT可以继续使用，按需替换为10G GPON的ONT。由于部署WDM1r合波器会引入额外衰耗，对于新部署的GPON建议预留2-3dBm的光预算，现网已经部署的PON口，如果光预算不足，建议通过升级大功率光模块解决。图3-9 GPON升级到10G GPON方案二Combo板方案（推荐）：即板内集成10G GPON和GPON能力，光模块内置合波器，之前将现网的PON口割接到Combo单播的PON口承载，原GPON的ONT可以继续使用，按需替换10G

GPON ONT。3.4 城域网规划设计：基于4K承载网进行扩容升级在Cloud VR起步阶段，可以复用4K网络架构进行业务承载，如下图所示：图3-10 起步阶段Cloud VR城域架构：复用4K城域架构与4K城域类似，Cloud VR城域主要包含如下技术措施：23 |

Cloud VR网络方案白皮书· 网络扁平化，降低无效收敛： OLT接入设备应直连城域网网关BNG，BNG一跳直达城域核心CR设备。· BNG下沉：BNG下沉可以降低网络中布放VPLS等技术带来的复杂度，同时可支撑CDN/云渲染服务器位置自由布放，减少时延。· OTN到CO：网络扁平化过程中会伴随大量的光纤建设诉求，通过波分设备进一步下沉到城域边缘/OLT站点，提供超大带宽、低时延和零丢包的互联基础管道，支撑网络扁平化实施。· 实时监控网络链路利用率，超过Cloud VR要求的负载门限时及时扩容，避免突发引起的拥塞丢包。在起步阶段，Cloud VR预计部署规模较小，假设用户渗透率考虑30%左右，并发率预计低于IPTV的水平（各地水准不同，假设OLT为50%，城域边缘为20%、城域核心为10%）。根据上述数据，可以计算得到Cloud VR在城域网增加的容量诉求如下：◆ OLT上行端口容量诉求：OLT设备用户数（按1500用户算）* VR用户渗透率30%*并发率50%*起步阶段VR码率（按40Mbps算）=

9Gbps◆ 城域边缘设备容量诉求： 边缘设备用户数（按2万用户算）*VR用户渗透率30%*并发率20%*起步阶段VR码率（按40Mbps算）= 48Gbps◆ 城域核心设备容量诉求：边缘设备用户数（按100万用户算）*VR用户渗透率30%*并发率10%*舒适体验阶段VR码率（按40Mbps算）= 1.2Tbps可以看出来，起步阶段Cloud VR部署后，对城域网会带来一定的扩容升级诉求，建议要做好相应的扩容规划，避免拥塞影响体验：◆ OLT上行口建议至少升级到2*10GE◆ 城域边缘设备至少升级为2*100GE上联城域核心◆ 城域核心设备建议升级为400Gbps/槽位或者Tbps/槽位的集群平台除了带宽之外，城域网的时延要求为8ms以内（含CDN网络），建议城域设备整体转发时延<1ms、CDN网络转发时延<1ms，剩余6ms用于光纤距离和排队缓存产生的时延，要求CDN/云渲染服务器的布放位置在城域内。| 24

3.5 Cloud VR承载设计3.5.1 4K承载方案现状Cloud VR承载网是基于4K ready的视频承载网的基础上进行改造和演进的，因此有必要先理清楚4K IPTV承载方案的现状。图3-11 4K IPTV承载方案如上图所示，4K IPTV承载方案分为两部分：· 城域网的IPTV承载：组播主要使用NG-MVPN、PIM+VPLS组播技术，这些技术本身已经比较成熟，VR可以直接共享使用，本白皮书不作赘述。· 接入段的IPTV承载：当前主流方案是基于双通道的方式进行IPTV承载，有少量运营商采用了单通道方案。不同的模式下，Cloud VR的承载方式有不同的选择。25 |

Cloud VR网络方案白皮书3.5.2 双通道场景Cloud VR承载方案双通道场景下，STB接入ONT的专用IPTV端口，进行独立的拨号，使用专用的IP地址，这种方案是历史上IPTV使用专网承载遗留下来的，当前依然是主流方案。图3-12 双通道 IPTV承载方案随着VR业务的加入，双通道场景有3种可选的承载方案：方案1：复用HSI通道承载VR（推荐）如下图所示：VR头盔跟其他上网终端一样，从ONT获取IP地址，复用PPPoE上网通道承载。图3-13 复用HSI通道承载VR方案在本方案下，头盔不需要任何特殊处理即可接入网络，实施起来最为简单，是推荐的部署方案。本方案默认不提供VR组播业务，VR直播通过点播方式下发。如果未来用户数较大，可以将组播分离出来单独推送到ONT，不影响上述拨号方式。| 26

方案2：VR独立通道承载如下图所示：VR独立通道承载方案在4K IPTV承载方案的基础上，增加一个IPoE逻辑通道承载VR业务，此时在ONT上需要预留一个VR AP专用的端口，将此端口与独立的IPoE通道的桥接WAN口进行绑定。图3-14 VR独立通道承载方案VR独立通道方案改造涉及从ONT到BRAS间的规划VR专用通道的VLAN、IP地址、路由策略，新增VR单播通道认证的AAA服务器和DHCP Server，此外涉及OSS业务下发系统改造，改造方案比较复杂。不建议使用。方案3：复用IPTV通道承载VR如下图所示：VR业务通过IPTV通道进行承载，ONT将Cloud VR的专用AP接入的专用端口绑定到已有的IPTV通道上。VR头盔与机顶盒一样，通过IPTV通道进行IPoE拨号认证。图3-15 复用IPTV通道承载VR方案在本方案下，VR头盔发放时需要在AAA添加相应的IPoE账号，在VR头盔上线时，需要头盔支持DHCP

Option60/61字段进行相应的IPoE认证过程，改造过程同样较为复杂。不建议使用。27 |

Cloud VR网络方案白皮书3.5.3 单通道场景Cloud VR承载方案单通道场景下，一般ONT放在弱电箱，客厅与弱电箱之间的网线用于上网HGW连接，导致STB没有独立的网线连接到ONT的专用IPTV口，只能复用Internet通道。在增加Cloud VR头盔和相应的AP后， Cloud VR承载方案也只能是继续沿用单通道进行统一承载，如下图：图3-16 单通道Cloud VR承载方案| 28

3.5.4 投屏承载方案建议VR投屏是指“通过特定程序处理将Cloud VR用户在终端中观看到的图像画面通过电视屏幕展现出来”的过程，它可以在用户体验过程中将虚拟世界画面同步分享给他人，是VR业务的刚性需求。为了实现Cloud

VR投屏，需要头盔、机顶盒、头端等相互传递信令和数据交互。当前主要有两种Cloud VR投屏方案：云端XMPP投屏和本地DLNA投屏方案，如下图所示：图3-17 投屏方案对比示意图云端（XMPP）投屏方案（推荐）此方案由Cloud VR云端系统同步流量到IPTV系统，机顶盒到IPTV系统拉取投屏流量。机顶盒的流量与头盔的流量相互独立，网络需要两份带宽。此方案已经在商用试点使用，相对成熟可靠，建议使用。本地（DLNA）投屏方案（不推荐）此方案由头盔与STB之间通过DLNA传输投屏流量，因为Wi-Fi AP与终端需要处理转发两份流量，实测体验效果差，终端功耗大，同时，此方案要求头盔与机顶盒使用相同的地址段（即Cloud VR复用IPTV通道），现网条件较难满足。因此，本方案不推荐使用。29 |

Cloud VR网络方案白皮书3.5.5 Cloud VR承载方案建议总结· 在城域段，由于Cloud VR复用Internet通道，建议优选IP组播/单播技术进行Cloud VR承载。· 在接入段，运营商网络一般同时混合存在双通道和单通道承载的情况，不管是双通道还是单通道，均建议Cloud VR复用Internet通道进行承载，使得Cloud VR头盔可以像手机终端一样快速接入网络，不需要特别的网络部署改造。图3-18 推荐的VR部署方案· 在投屏方案上，当前云端投屏方案对Cloud VR头盔的认证能力、Wi-Fi能力、CPU能力要求低，实际使用效果比本地投屏好，建议选用云端投屏。| 30

3.6 带宽与QOS部署设计3.6.1 带宽规划方法在对网络进行容量规划时，首先要对业务流量速率、用户数以及站点情况进行建模，基于建模结果可以获得全网以及各个站点的流量预测，最后再叠加端口保护以及链路容量冗余度等，获得相对准确的站点容量要求。容量规划过程如下图所示：图3-19 VR网络容量规划方法· 业务建模的目标是获得每用户的平均上网速率、IPTV点播平均码率、Cloud VR点播（含游戏）平均码率、IPTV直播流量、Cloud VR直播流量等数据，计算方法如下：平均上网速率≈城域核心设备的出口流量（扣除IPTV和VR后）/下挂用户数。IPTV平均点播码率 = ∑IPTV点播视频码率*点播时长占比。如果4K/高清码率的时长占比高则平均点播码率高，如果标清码率的观看时长占比高则平均点播码率低。Cloud VR点播(含游戏)码率 = ∑Cloud VR点播码率*使用时长占比。直播流量总和=∑频道码率*频道数，直播频道包括IPTV直播频道和VR直播频道· 用户建模的目标是获得全网宽带用户数以及视频用户数以及后续的增长目标数据，这部分数据通常由运营商的市场部门根据已有数据叠加商业发展目标做出判断。用户建模的结果通常如下表所示：表3-5 用户建模结果· 站点建模的主要目标是定义站点拓扑、站点数量、站点并发率和收敛比等信息，为后续计算站点容量做准备。站点建模一般涉及的信息如下图所示：31 |

Cloud VR网络方案白皮书图3-20 站点建模示意图经过上述的业务建模、用户建模和站点建模后，就可以推导计算站点的容量需求了，一般计算过程如下：· 站点上网流量 = 站点下挂宽带用户数*设备每用户平均上网速率;· 站点IPTV点播流量 = 站点IPTV点播并发用户数*点播用户平均码率；· 站点Cloud VR点播（含游戏）流量 = 站点Cloud VR点播并发用户数*Cloud VR平均码率；· 站点直播流量 =直播流量总和（含VR直播）*设备的直播频道推送比例；· 站点经过的流量大小 = 站点上网流量 + 站点IPTV点播流量 + 站点 Cloud VR点播(含游戏)流量 + 站点直播流量根据站点流量大小，结合网络拓扑，可进一步估算出站点的设备端口诉求。3.6.2 QOS部署建议由于不同的业务对网络要求不一样，需要对业务进行分类，不同优先级的业务进入不同的端口优先级队列进行QoS保障：◆ IPTV直播/VR直播业务：对丢包敏感，影响用户面广，需要高优先级保证◆ VR游戏：强交互的VR游戏，对时延比较敏感，需要高优先级保证◆ IPTV/VR点播业务：符合流量规划的情况下优先保证自营点播业务◆ 互联网OTT业务：保证一个基本带宽，尽力转发表3-6 视频业务优先级分配建议| 32

有了优先级定义后，需要网络节点执行相应的动作才能使得QOS生效。QOS动作包括Remark优先级、CAR/Shaping、Schedule三种，不同的网络节点需要部署三种动作的一种到多种（如上图所示），典型的部署规则如下：图3-21 E2E QoS部署建议· Remark优先级部署：一般上行在ONT基于不同端口或者DHCP报文特征来识别IPTV流量并进行优先级remark，下行在CR基于IPTV或者VR地址段或者端口+VLAN来识别对应业务进行优先级remark。· CAR/Shaping限速：一般在BRAS对用户上下行进行按套餐设定的限速，可以使用CAR或者shaping方式。CAR限速不使用缓存，没有调度过程，不会引入排队时延，但突发会被透传到下游，适用于下游设备缓存较大的场景；Shaping通过队列对用户流量进行整形，流量的突发会被平抑到10ms级别，对下游的冲击会比较小，整形过程会引入时延抖动，适用于下游设备缓存较小的场景。在Cloud VR场景中，建议选用CAR方式，减少shaping引入的时延抖动。在Cloud VR的部署中，由于推荐VR业务复用Internet通道，为了避免VR业务因为Internet套餐限速而产生影响，建议部署DAA把VR业务分离出来单独限速。如下图所示，组播业务通过独立子接口承载，不限速；机顶盒点播业务通过IPoE拨号限速，上网业务和VR业务通过同一PPPoE拨号承载，上网业务通过PPPoE拨号进行限速，通过在PPPoE上网通道部署DAA，将VR业务分离出来采用DAA CAR单独限速，防止上网业务对VR业务的冲击。图3-22 PPPoE上网通道部署DAA示意图33 |

Cloud VR网络方案白皮书· Schedule部署：Schedule部署的核心目标是优先保证VR和IPTV流量，同时不至于“饿死”HSI业务，不同的网络节点可以使用稍微不同的Schedule策略。· 城域网设备：由于存在众多业务，城域网一般采用SP+WFQ调度模式。其中：语音、管理业务、直播等小流量重要性高的业务一般采用SP调度模式；视频、企业业务、HSI等业务则采用WFQ调度模式。WFQ的队列权重非常关键，需要根据各业务的流量大小进行设置。举例：假设某站点组播流量0.7Gbps、点播流量2.5Gbps，且两个设备间使用2*10GE捆绑，则组播流量占比为3.5%，点播流量占比12.5%。实际考虑到端口聚合hash不均匀以及部分突发因素，建议实际组播队列权重配置为10%或以上，点播队列权重为25%或以上。· 接入OLT：如果OLT涉及业务很多，则与城域网一样进行SP+WFQ的调度规划。如果OLT仅涉及宽带业务，也可以仅使用默认的SP调度，避免复杂的规划部署。对于PON口而言，由于它按分光比规划，预留带宽比较充足，即使使用SP调度，也极低概率出现上网流量被视频冲击导致“饿死”现象。对于OLT上行口而言，视频上行流量很小，也极难出现上网流量被视频冲击导致“饿死”现象。· Wi-Fi空口：如果视频业务和普通上网业务共享Wi-Fi信道，建议使用Wi-Fi标准的WMM机制对视频进行优先抢占无线信道，确保视频流量优先转发。| 34

3.7 Cloud VR体验保障方案当前Cloud VR的运维体系尚未构建完整，如何进行Cloud VR的运维还是一个难题。从4K IPTV的质差问题分类来看，60%以上的问题发生在家庭Wi-Fi侧，所以短期内建议先从家庭网络入手，通过Wi-Fi

Sense方案分析定位家庭侧Wi-Fi指标来进行Cloud VR业务保障。该方案的核心组件是Netopen服务器，负责与ONT及Cloud VR专用AP进行通信，获取相应的Wi-Fi指标进行综合分析，找出家庭组网中存在的问题，并给出优化措施。其实现过程如下：图3-23 Wi-Fi Sense体验保障35 |

Cloud VR网络方案白皮书1. 家庭网关通过PPPoE上网通道从BRAS获取IP地址后，通过该域名向Netopen注册。2. 家庭网关集成指标采集插件，多维度实时采集家庭网络的指标上报为Netopen，如上图所示，家庭网关周期性监控邻居Wi-Fi信息、家庭拓扑、下挂设备、下挂设备信号强度、下挂设备下载速率等关键信息，周期性上报给Netopen。3. Netopen收到家庭网关上报的数据后，基于信道干扰、Wi-Fi覆盖、终端连接、设备、配置等维度分析，对可能影响体验的因素生成告警信息，同时生成历史数据报表。运营商收到用户的VR体验投诉后，可以通过Netopen先判断家庭网络拓扑、VR头盔Wi-Fi强度、协商速率等终端指标，先分析是否由于VR头盔移动引入的问题，再判断信道的信道干扰、配置、设备等多维度综合分析引起VR体验质差原因。如下图，通过Wi-Fi终端的信号强度和协商速率的历史曲线，发现终端的Wi-Fi由于信号强度减弱导致的协商速率下降，从而导致VR体验劣化。| 36

图3-24 终端Wi-Fi信号强度弱导致VR质差示意图对于非信号强度和协商速率导致的视频质量下降，同频干扰是可能性较大的原因之一。如下图，当发现严重干扰时，Netopen通过告警通报信道出现劣化，可人工重选Wi-Fi信道进行调优。图3-25 Wi-Fi信道干扰弱导致VR质差示意图37 |

Cloud VR网络方案白皮书舒适体验阶段Cloud VR网络设想本章节主要从理论上分析舒适体验阶段Cloud VR业务的承载网络部署方案，当前尚未有实际商用案例，仅做理论探讨。4.1 目标网络架构设想在Cloud VR舒适体验阶段，单路VR业务带宽要求为260Mbps，同时开通4K IPTV和上网业务后，用户带宽建议VR 260Mbps + 4K IPTV 50Mbps + HSI 100Mbps = 400Mbps。其中，VR的投屏业务通过4K IPTV通道下载，要求头端对VR投屏流量压缩到4K视频的带宽水平。如果头端压缩不了投屏流量，则带宽变成VR 260Mbps + 4K IPTV（含投屏） 260Mbps + HSI 100Mbps = 620Mbps。在未来，我们认为大部分头端可以对投屏业务进行压缩，后续统一按400Mbps带宽进行计算。在Cloud VR舒适体验阶段，网络RTT要求为15ms，分解到各段网络如下表所示：| 38

表4-1 Cloud VR舒适体验阶段时延要求分解在这个阶段，Cloud VR业务带宽和时延的要求都变得比较高，需要进一步升级增强Wi-Fi接入技术、承载网技术，同时考虑构建一种新的网络架构，实现带宽时延的双重保障。基于此，舒适体验阶段Cloud VR解决方案核心理念是“升级增强的家庭网/承载网” +“带宽时延可保障的网络”，如下图所示：图4-1 舒适体验阶段VR目标架构◆ 升级增强的家庭网：家庭组网上，建议与起步阶段一样使用独立AP，但Wi-Fi能力需要升级，速率达到>260Mbps和时延达到<7ms的目标。◆ 升级增强的承载网：接入全面部署10G PON，城域网演进到N*100Gbps/Tbps容量，云渲染服务器适当下移。◆ 时延带宽可保障的网络：引入带宽时延可保障的理念进行网络重构。39 |

Cloud VR网络方案白皮书4.2 家庭网方案设想在舒适体验阶段，建议继续沿用起步阶段的组网方式，采用独立高性能AP承载Cloud VR业务，但Wi-Fi性能需达到>260Mbps速率和<7ms时延的要求，需要升级为802.11ac 4*4 MIMO或802.11ax技术。4.2.1 802.11ac 4*4 MIMO在Cloud VR起步阶段，5GHz Wi-Fi采用80MHz频宽，家庭5G Wi-Fi考虑存在两路弱干扰，VR头盔支持2*2 MIMO，Wi-Fi速率按照MCS6制式的速率，考虑50%占空比以及40%传输损耗，80MHz频宽速率为175Mbps。在舒适体验阶段，AP和VR头盔可以通过支持更高的空间流来提升带宽，如下图所示：◆ 如果采用3*3 MIMO，考虑一定干扰劣化时，连接速率为MCS5等级，实际可获得速率为780Mbps*50%占空比*60%效率 = 234Mbps，承载舒适体验阶段VR存在风险。◆ 如果采用4*4 MIMO，考虑一定干扰劣化时，连接速率为MCS5等级，实际可获得速率为1040Mbps*50%占空比*60%效率 = 312Mbps，能够满足舒适体验阶段VR的要求。因此，建议AP和VR头盔可以通过升级支持4*4 MIMO来满足舒适体验阶段VR诉求。表4-2 802.11ac 3*3MIMO&4*4MIMO对应的Wi-Fi速率表| 40

4.2.2 802.11ax技术802.11ax标准是基于5G Wi-Fi标准802.11ac的改进，它相比802.11ac主要在几个方面做了改进：（1）引入OFDMA可提升同一信道带宽的利用效率。（2）引入1024QAM，物理速率可提升接近40%。（3）子载波载波数是802.11ac的4倍，可以覆盖更远的范围。（4）支持上行MU-MIMO可增加空口效率，为多用户场景提供了更好的传输效率。802.11ax最大可实现10Gbps理想空口速率，去除开销、信号衰减等导致的带宽损失，实际数据速率可以达到舒适体验阶段和理想体验阶段VR的要求。当前802.11ax标准已成熟，但支持的产品较少。4.3 接入网技术要求在舒适体验阶段，Cloud VR与IPTV、HSI业务接入带宽共计需要400Mbps。在前一章节已分析得知EPON/GPON不适合用于大规模开展起步阶段Cloud VR业务，因此更不适合用于大规模开展舒适体验阶段Cloud VR业务，只建议考虑10G EPON/GPON。如下表所示，10G EPON/GPON在1:64情况下无法达到400Mbps带宽，需要控制用户的实际安装数量，但在1:32情况下可以达到舒适体验阶段Cloud VR业务带宽诉求。41 |

Cloud VR网络方案白皮书4.4 城域网技术要求在舒适体验阶段，Cloud VR业务预计会得到大规模部署，用户渗透率考虑至少50%以上，并发率至少达到IPTV的水平（各地水准不同，假设OLT为50%，城域边缘为30%、城域核心为20%）。根据上述数据，可以计算得到Cloud VR在城域网增加的容量诉求为：◆ OLT上行端口容量诉求：OLT设备用户数（按1500用户算）* VR用户渗透率50%*并发率50%*起步阶段VR码率（按90Mbps算）= 33.75Gbps◆ 城域边缘设备容量诉求： 边缘设备用户数（按2万用户算）*VR用户渗透率50%*并发率30%*舒适体验阶段VR码率（按90Mbps算）= 270Gbps◆ 城域核心设备容量诉求：核心设备用户数（按100万用户算）*VR用户渗透率50%*并发率20%*舒适体验阶段VR码率（按90Mbps算）= 9Tbps因此，舒适体验阶段Cloud VR大规模部署后，对城域网的容量诉求是非常巨大的，需要更高速率和集成度的单板/设备：◆ OLT上行口建议至少升级到4*10GE，有条件的可以考虑直接升级到2*100GE◆ 城域边缘设备至少升级为4*100GE上联城域核心◆ 城域核心设备建议升级为Tbps/槽位的集群平台除了带宽之外，城域网的时延要求压缩到6ms以内（含CDN网络），建议城域设备整体转发时延<1ms、CDN网络转发时延<1ms，剩余4ms用于光纤距离和排队缓存产生的时延，要求CDN/云渲染服务器的布放在城域以内。在该阶段，城域网的云化架构已逐步开始部署，为了降低转发时延，建议云化架构采用CU分离（即控制面云化，转发面继续采用物理设备）的方式，不建议采用全软化的vBRAS方式。| 42

图4-2 城域网CU分离的云化架构更适合Cloud VR承载4.5 带宽时延可保障方案设想带宽可保障主要通过传统的Wi-Fi/PON升级以及城域网扩容等方式实现。时延可保障则是一个新的课题，当前尚未有成熟的架构和商用方案。下面仅对方案诉求和部分内涵进行探讨。理论上，带宽时延可保障的网络有四个诉求，如下图所示：图4-3 带宽时延可保障的网络诉求◆ 意图感知：由于网络中同时存在多种业务，重要性和所需的SLA诉求并不相同，为了实现Cloud VR的最佳保障，需要基于意图感知来识别Cloud VR业务并理解其SLA诉求。◆ 质量感知：质量感知诉求是测量和评估Cloud VR的业务质量及相应的网络质量，形成相应的数据库，为后续的问题识别、问题优化提供输入来源。◆ 问题识别：基于质量感知所采集的数据，可以使用大数据技术、AI技术进行问题归类分析，找出网络的瓶颈点。◆ 网络优化：对于网络瓶颈点，实施自动化/人工的优化措施，使得网络始终处于Cloud VR最佳承载状态。比如，对于Wi-Fi瓶颈，可以通过自动化的信道调优等技术进行速率提升。对于网络容量不足问题，则需要通过人工扩容的方式解决问题。网络优化除了上述工程方法外，还可能通过一些技术手段提升产品能力，降低Cloud VR的带宽消耗和时延要求。包括但不限于：低时延Wi-Fi、降低投屏代理带宽消耗、直播使用FOV等。43 |

Cloud VR网络方案白皮书5 理想体验阶段Cloud VR网络展望随着VR头戴显示终端的屏幕分辨率、芯片性能等硬件性能的提升，以及VR内容的质量的提高，VR视频会逐渐向理想体验阶段（全视角12K、24K）演进，带宽诉求达到1Gbps以上，网络RTT要求≤8ms，分解到各段网络如下表所示：表5-1 Cloud VR理想体验阶段时延要求分解在理想体验阶段，网络需要向“更高的带宽”和“更低的时延”的方向演进：◆ 家庭网Wi-Fi技术：支持X*Gbps带宽速率，建议采用802.11ax 或60GHz Wi-Fi技术承载，可以进一步降低干扰从而降低时延。◆ 接入技术：接入需要升级到25G/50G PON，来实现每用户Gbps接入。◆ 确定性低时延承载网： 云渲染服务器进一步下沉到城域边缘，同时利用网络分片和云网协同等技术获得确定性低时延的网络保障。| 44

2023年12月20日发(作者：凤丝)

Cloud VR网络方案白皮书Cloud VR网络方案白皮书华为iLab·极致体验华为iLab发布| 1

2 |

Cloud VR网络方案白皮书前言Cloud VR，是将云计算的理念及技术引入到VR业务应用中，借助高速稳定的承载网络，云端的显示输出和声音输出等经过编码压缩后传输到用户终端，实现VR业务的内容上云、渲染上云。目前，较好的用户体验大多依赖高性能设备做本地渲染，Cloud

VR让用户无需购置昂贵主机或高端PC即可轻松享受各种VR业务，将促进VR业务的普及。2017年，我们围绕Cloud VR业务发布了《面向Cloud VR的承载网络白皮书》。2018年，我们继续围绕VR用户体验的提升为主线，结合Cloud VR最新的技术发展趋势和商用部署经验，进一步细化分析了Cloud VR不同阶段下的承载网络需求，给出了Cloud VR网络承载方案以及网络演进方向，为运营商部署Cloud VR业务提供参考。| 3

目录Contents前 言

1 Cloud VR概述1.1 Cloud VR业务场景概述1.2 Cloud VR发展的三个阶段1.3 Cloud VR网络的发展策略2 Cloud VR网络要求2.1 影响Cloud VR体验的关键因素2.2 Cloud VR要求确定性低时延 2.2.1 VR业务时延要求 2.2.2 Could VR网络时延分配2.3 Cloud VR要求n*4K视频带宽 2.3.1 Cloud VR网络带宽的影响因素 2.3.2 Cloud VR的带宽要求2.4 Cloud VR的丢包要求2.5 Cloud VR网络需求汇总3 起步阶段Cloud VR网络解决方案3.1 目标网络架构3.2 家庭网规划设计 3.2.1 Cloud VR家庭网面临的挑战 3.2.2 Cloud VR家庭网规划建议3.3 接入网设计：10G PON为主，EPON/GPON受限开通3.4 城域网规划设计：基于4K承载网进行扩容升级3.5 Cloud VR承载设计 3.5.1 4K承载方案现状 3.5.2 双通道场景Cloud VR承载方案8464 |

Cloud VR网络方案白皮书 3.5.3 单通道场景Cloud VR承载方案 3.5.4 投屏承载方案建议 3.5.5 Cloud VR承载方案建议总结3.6 带宽与QOS部署设计

3.6.1 带宽规划方法

3.6.2 QOS部署建议3.7 Cloud VR运维方案28293 舒适体验阶段Cloud VR网络设想4.1 目标网络架构设想

4.2 家庭网方案设想 4.2.1 802.11ac 4*4 MIMO 4.2.2 802.11ax技术4.3 接入网技术要求4.4 城域网技术要求

4.5 带宽时延可保障方案设想5 理想体验阶段Cloud VR网络展望5.1 Wi-Fi技术演进：60GHz5.2 接入技术演进：25G/50G/100G PON5.3 确定性低时延的云网协同网络383844454546A 缩略语48| 5

Cloud VR概述1.1 Cloud VR业务场景概述VR是计算机构造出虚拟环境，人在这一具备立体空间信息的虚拟环境之中进行实时的互动。VR业务场景日趋丰富，中国信通院、华为iLab、华为C&SI商业咨询部在VR产业研究及海内外行业洞察过程中，将Cloud VR场景划分为Cloud VR 2C应用场景和Cloud VR 2B应用场景两大类，如下表：表1-1 Cloud VR业务场景根据高盛发布的VR/AR产业报告以及当前运营商业务开展的情况预测，VR应用最先普及和推广的将是巨幕影院、VR 360°全景视频、VR直播、VR游戏和VR教育。这些应用场景的业务从交互维度上可分为VR弱交互业务和VR强交互业务两大类。

VR弱交互业务当前主要是VR视频业务，包含巨幕影院、360°全景视频、VR直播等，用户可以在一定程度上选择视点和位置，但用户与虚拟环境中的实体不发生实际的交互（如触摸）。强交互VR包含VR游戏、VR家庭健身、VR社交等，用户可通过交互设备与虚拟环境进行互动，虚拟空间图像需对交互行为作出实时响应而生成。1 |

Cloud VR网络方案白皮书1.2 Cloud VR发展的三个阶段Cloud VR业务的发展以体验为主线，是画质、交互感等不断提升，沉浸感越来越好的演进过程。内容制作技术、传输技术和网络技术的匹配度决定了Cloud VR沉浸体验能达到的程度。我们认为，Cloud VR业务体验提升的演进可经历如下三个阶段：起步阶段、舒适体验阶段和理想体验阶段。起步阶段在起步阶段，内容以4K VR为代表，终端屏幕分辨率为2K~4K，用户看到的画面质量相当于在传统TV上观看240P/380P的PPD（Pixels Per Degree，角度像素密度）效果。对于VR视频业务，主要考虑全视角传输方案。对于强交互VR业务，需要比视频更高的帧率以保障用户业务体验；另外强交互VR不存在全视角传输，只有FOV（(Field of View，视场角）传输方式，需要终端支持异步渲染等技术，用户才能获得流畅的体验。舒适体验阶段在舒适体验阶段，内容以8K VR为代表，终端屏幕分辨率为4K~8K，芯片性能、人体工程有所提升，用户看到的画面质量相当于在传统TV上观看480P的效果。这个阶段，Cloud VR各类业务的良好体验要求对网络的带宽、时延要求也将显著提高。对于VR视频业务，全视角传输方案依然会被首先考虑，以保证良好的观看和交互体验；但随着全视角8K的3D视频出现，超过百兆的带宽需求会促进FOV方案的使用。对于强交互VR业务，分辨率相比前一阶段进一步提升，带宽需求也进一步增大。理想体验阶段在理想体验阶段，内容以12K或者24K VR为代表，终端屏幕分辨率为8K~16K，终端和内容的发展可使用户获得最佳的使用体验。另外H.266视频编码标准、光场渲染技术等将广泛应用。对于VR视频业务，继续全视角传输方案对网络带宽要求变高，而采用FOV方案成为主流，可以极大降低对带宽的要求。对于强交互VR业务，分辨率的显著提升使得带宽的需求进一步增大，用户交互体验的提升要求更低的网络时延。| 2

1.3 Cloud VR网络的发展策略

Cloud VR不同发展阶段对网络传输的需求有较大的差别，结合具体传输技术的发展和演进，网络在不同阶段的发展策略建议如下：1. Cloud VR起步阶段：新建Wi-Fi家庭网络，扩容改造4K Ready承载网· 家庭网络建议增加部署高性能的5GHz Wi-Fi AP进行Cloud VR业务承载，并通过合理的规划避免与原有上网业务干扰。· 承载网基于4K ready网络进行扩容改造，具体包括OLT PON升级、OLT上行扩容、城域网扁平化、OTN到CO等。2. Cloud VR舒适体验阶段：升级增强Wi-Fi家庭网络和承载网，构建带宽时延可保障的网络· 家庭网络Wi-Fi建议采用 4*4 MIMO技术或802.11ax技术。

· 承载网持续升级扩容：接入FTTH需全面升级为10G EPON/GPON；城域网需更大容量更高集成度的硬件设备，面向云化应采用CU分离架构；云渲染服务器适当下沉。· 需构建带宽时延可保障的网络，核心诉求包括意图感知、质量感知、问题识别、网络优化等。3. Cloud VR理想体验阶段：网络需向更大带宽、更低时延方向演进· 60G Wi-Fi可能会被应用，固定接入网络将向25G/50G/100G PON 技术演进。· 云渲染服务器需要下移至城域边缘，网络将向云网协同技术方向演进。3 |

Cloud VR网络方案白皮书Cloud VR网络要求2.1 影响Cloud VR体验的关键因素虚拟现实体验具有3I的特征，分别是沉浸感（Immersion）、交互性（Interaction）和想象性（Imagination），其主要优势也是这三个特征体现的。· 沉浸感：是指利用计算机产生的三维立体图像，让人置身于一种虚拟环境中，就像在真实的客观世界中一样，能给人一种身临其境的感觉。· 交互性：在计算机生成的这种虚拟环境中，人们可以利用一些传感设备进行交互，感觉像在真实客观世界中一样。· 想象性：虚拟环境可使用户沉浸其中萌发联想。与其相对应，虚拟现实的体验评价也主要有三个因素：真实感、交互感和愉悦感。· 真实感：主要跟分辨率、色深、帧率、编码压缩技术等相关，过低的画面质量和音频质量都会导致感觉不真实，让人无法沉浸其中，同时也影响交互感。要带来愉悦的真实感受，要求Cloud VR承载网络的带宽要能满足高画面质量传输的要求。· 交互感：区别于本地VR系统，Cloud VR在计算、渲染上云后，远端处理产生的时延直接影响VR体验的交互性，进而影响沉浸感和想象性，特别是由于时延导致的晕动症是Cloud VR面临和必须解决的最大问题。此外加载、切换、手柄操作的响应迟滞时间也直接影响VR的交互感，可以说，交互感与Cloud VR承载网络的时延强有关。· 愉悦感：主要取决于VR体验流畅程度，这跟卡顿、花屏次数、时长占比等网络因素强相关，当愉悦感降低，用户就无法很好地沉浸在里面萌发想象。愉悦的体验感受要求Cloud VR承载网络的带宽、时延、丢包等指标均需满足VR用户体验的要求。图2-1 Cloud VR体验关键因素与网络的关系图| 4

切换时间、加载时长有轻微影响，不是必须满足的指标，可根据现网情况适当放宽要求。但Could VR的强交互业务画面是由云2.2 Cloud VR要求确定性低时延端实时渲染生成的，时延对画面的刷新质量、用户交互感有直接影响，时延成了必须满足的确定性指标。从理论和实测结果看，起步阶段要求≤20ms，舒适体验阶段和理想体验阶段的时延要求会进一步严格（预计舒适体验阶段要求≤15ms、理想体验阶段要求≤8ms），对网络提出了新的挑战。2.2.1 VR业务时延要求对于Could VR视频业务，参考4K视频的分析，网络时延在20~40ms即能满足要求，不同的时延只是对画面加载时间产生影响。但是对于Could VR强交互业务，为了保证用户的交互感和愉悦感，对时延有如下三个要求：1. MTP时延要求≤20毫秒（端云异步渲染方案下MTP时间不再依赖网络和云渲染，可由终端保证）。2. 云渲染及流化时延要求为30~70毫秒。· 在起步阶段，云渲染及流化时延建议≤70毫秒，画面黑边和质量的劣化在可接受范围。· 在舒适体验阶段，云渲染及流化时延建议≤50毫秒，此时基本消除黑边现象。· 理想体验阶段，云渲染及流化时延建议≤30毫秒，此时位置移动时画面的扭曲将让人无法察觉。3. 操作响应时延要求≤100毫秒。 操作响应时延由云渲染及流化时延，加上终端的二次渲染、异步扭曲和刷新呈现构成。操作响应时延减去云渲染及流化时延的要求70ms后，剩余30ms，大于终端对二次渲染、异步扭曲和刷新呈现的MTP时延要求。 因此只要保证云渲染及流化时延要求，就能同时满足操作响应时延要求。图2-2 端云异步渲染技术方案下的MTP、云渲染及流化时延、操作响应时延5 |

Cloud VR网络方案白皮书2.2.2 Could VR网络时延分配云渲染及流化时延分为云端处理、网络传输、终端处理三部分，不同阶段的时延规划建议参见下图；图2-3 强交互VR业务端到端时延规划建议把网络的时延再分解到家庭Wi-Fi、固定接入网、城域网络各部分，时延建议如下表：阶段起步阶段舒适体验阶段理想体验阶段端到端网络RTT≤20 ms≤15ms≤8 ms家庭Wi-Fi≤10ms≤7ms≤5ms固定接入网≤2ms≤2ms≤2ms城域承载≤8ms≤6ms≤1ms对于不考虑VR强交互业务，只发放VR视频业务的网络，如果要求播放或切换频道时画面加载时间在1s以内，那么网络时延要求在20ms以内；如果对画面加载时间不作要求，则对网络时延的要求可以放宽至30ms~40ms，对VR视频的体验也不会有太大影响。| 6

2.3 Cloud VR要求n*4K视频带宽Could VR的沉浸性终端拥有远高于传统TV的视场角，为了实现与4K视频一样的清晰度，其分辨率、帧率、码率都必须高于4K视频业务，对网络有着更高的带宽要求。经实测和理论分析，Cloud VR的带宽要求如下表所示：2.3.1 Cloud VR网络带宽的影响因素影响Cloud VR网络带宽需求的因素主要有分辨率、帧率、色深、视场角、编码压缩技术、传输方式等方面。◆ 分辨率：由于VR的沉浸性终端拥有远高于传统TV的视场角，决定了要达到同样等级的画质体验，要求VR具有更高的单眼分辨率和全视角分辨率。全视角的4K分辨率并不能达到满意的视频质量，加大分辨率到8K及以上是必须的。以FOV=90为例，全视角分辨率达到8K时，单眼分辨率为1920*1920，对应PPD=22，实际画面体验只相当于传统SD视频。◆ 帧率：帧率需要达到一定标准以上，画面才能达到动作清晰流畅无模糊残影。帧率过低会导致画面变差，甚至让一些游戏玩者产生头晕恶心等强烈不适感。Could VR游戏的帧率最好在90帧/秒以上，VR视频的要求会低一些，30帧/秒即可达到较好效果。◆ 色深： 在Cloud VR起步阶段，图像清晰度不高的情况下，对色深要求不高，一般为8Bit即可。后续随着分辨率提升，色深也会相应提升至10~12Bit。◆ 视场角：用户在虚拟环境中的视野可以认为是一个空间球，左右横向全视角展开是360度，上下纵向展开是180度。用户在使用终端时，单眼实际看到的视觉信息只是全部球面数据的一部分，这部分面积由终端提供的视场角FOV决定。人眼的左右眼的水平视场为160°、垂直视场为150°，双眼水平视场为200°左右。当前Cloud VR起步阶段的VR终端设备（如电视、VR眼镜）可支持的视角大约在90°~110°之间，单眼通过VR终端设备看到的有效球面信号小于球面全景信号的19%。将来随着产业发展，市场角扩大可使用户获得更好的体验。◆ 编码压缩技术：Could VR起步阶段主要采用的编码技术是H.264。在引入8K内容后，需要升级为H.265，在保证同等画质的前提下，其压缩比相对于H.264的最新版本可提升30%左右。MPEG等标准组织的最新研究进展表明，对应于HEVC的下一代编码技术（H.266）的压缩比能比HEVC再提升30%左右。随着分辨率的提升，理想体验阶段可考虑使用。◆ 传输方式：VR画面的在线传输有两种主要的技术路线：全视角传输方案和FOV传输方案。全视角传输方案就是将360度环绕的画面都传输给终端，当用户头部转动需要切换画面时，终端即时(Just-in-time)完成包括码流解析、视频解码和画面渲染等处理，用户看不到的那部分信息网络资源造成了比较大的浪费。FOV（Field of View）传输方案是基于视角进行有差别传输VR画面的方案，主要关注当前视角区域画面的高质量传输。FOV传输具体实现的技术还未统一，华为推荐的Tile Wise传输方案采用低质量全视角+高质量可视区域传输，在内容准备侧，将VR画面划分为多个tile，每个区域对应一个可以独立解码的码流；同时再准备一个低质量的全视角的VR码流；客户端获取一个全视角的低质量的码流，以及高质量的根据视角选择的tile。7 |

Cloud VR网络方案白皮书图2-4 Tile Wise传输方案2.3.2 Cloud VR视频业务的带宽要求Cloud VR视频业务的带宽要求对于VR视频业务，起步阶段主要采用全视角传输，后面随着产业的发展，分辨率提升，为了节省网络带宽，可以逐渐选择采用FOV方案进行传输。全视角方案下，码率的计算方式如下：平均码率 = （传输画面像素点* 每像素比特位* 帧率） / 压缩比对于2D视频，传输画面像素点 = 全视角分辨率，对于3D视频，传输画面像素点约为2D的两倍。色深为8bit时，抽样后每像素比特位为12，色深为10bit时，每像素比特位为15，色深为12bit时，每像素比特位为18。由于视频流并不是完全平稳的，有流量突发的情况，所以根据4K视频的测试经验，当网络带宽≥平均码率1.5倍时，可保证视频流畅播放，所以网络带宽需求按照1.5倍于平均码率来计算，即：网络带宽 = 1.5 * 平均码率

FOV方案下，当采用传输低质量全视角+高质量可视区域的Tile Wise传输方案，网络带宽约为全视角方案所需带宽的53%。| 8

基于上述的计算模型，对于Coud VR发展三个阶段的VR视频业务带宽估算结果如下：注1：起步阶段的4K压缩比基于H.264取业界典型值，后面阶段的压缩比根据业界经验测算得到，主要考虑编码方式、帧率、分辨率因素：（1）编码从H.264到H.265，H.265到H.266压缩比预计分别提升30%左右；（2）帧率提高一倍，压缩比预计提升50%左右；（3）分辨率提升一倍，压缩比预计提升15%左右。强交互业务的带宽要求对于强交互VR业务，都是基于当前视角进行实时渲染，全部采用FOV方式。强交互业务流由I帧和P帧组成，I帧含有所在图像所有的信息，采用帧内编码恢复自身图像；P帧是前向预测帧，根据前一个I帧或者P帧结合算法恢复自身图像；每个GOP（Group of Pictures）时间内包含一个I帧和N个P帧，其中N= GOP时间*帧率-1。强交互业务采用端云异步渲染，把画面扭曲到新的视角时，为减小或消灭新的视角范围内黑边对体验的影响，VR需要进行超视角画面的渲染和传输，建议各个方向都超出6度。端云异步渲染根据景深或运动矢量等信息调整物体间的位置关系，每一帧画面需额外传输15%的景深和运动矢量信息。码率的计算如下：平均码率 =（ I帧大小* 1 + P帧大小* GOP时间*帧率）*（1+冗余纠错信息）/ GOP时间帧大小 = （传输画面像素点* 每像素比特位）* 额外景深信息 / 压缩比9 |

Cloud VR网络方案白皮书其中冗余纠错信息按10%估算，平均GOP时间为2秒，异步扭曲超视角渲染角度建议为12（每个方向6度），FOV额外画面约为10%。强交互业务云端以帧率生成并发送I帧和P帧，网络带宽需要满足快速完成I帧和P帧发送的要求。为了保证画面质量，保证云渲染和流化时延，起步阶段预留给帧数据发送时间约为10~15ms，舒适体验阶段为5~10ms，理想体验阶段为4ms。帧数据发送时间 = 帧大小 / 带宽，所以P帧需要的带宽为P帧大小/帧发送时间。由于I帧比较大，且每个GOP时间内只有一帧，如果要求每个I帧都及时发送，对带宽要求太过严格。当I帧发送不及时，终端未能及时收到的时候，可以使用插帧技术（利用上一帧数据）来生成画面（参见下图），但是插帧对体验有一定的影响，建议最大插帧不超过2帧，否则对业务体验影响明显。所以I帧需要在3个帧周期内发送完成，而P帧需要在每个阶段预留给帧发送的时间内发送完成。即：带宽需求 = MAX[ I帧大小/( 3*帧周期），P帧大小/帧发送时间]基于上述的计算模型，对于Coud VR发展三个阶段的强交互业务单用户带宽估算结果如下：注1：强交互业务内容为实时渲染生成，没有全景画面，内容分辨率是指需要渲染的画面的分辨率。注2：起步阶段的4K压缩比基于H.264取业界典型值，后面阶段的压缩比根据业界经验测算得到，主要考虑编码方式、帧率、分辨率因素：（1）编码从H.264到H.265，H.265到H.266压缩比预计分别提升30%左右；（2）帧率提高一倍，压缩比预计提升50%左右；（3）分辨率提升一倍，压缩比预计提升15%左右。| 10

2.4 Cloud VR的丢包要求视频点播业务目前一般使用TCP传输，丢包对TCP影响是降低通量，卡顿。根据TCP吞吐量评估的经典公式：在确定的RTT和带宽通量要求下，可计算得到视频点播业务网络丢包要求如下：强交互业务和视频直播业务建议使用UDP传输，丢包对造成花屏、黑屏等问题。参考4K视频已经测试的数据，在无RET重传情况下，丢包在1E-5时，对体验会有轻微影响，在1E-6时，影响已经无法感知。所以此类业务丢包率要求建议如下：11 |

Cloud VR网络方案白皮书2.5 Cloud VR网络需求汇总基于上面的分析，相对于传统视频业务， Cloud VR视频主要是对网络的带宽提出了更高要求；而VR强交互业务则对网络的带宽和时延等同时提出了更高的要求。如下表，Cloud VR业务沿着体验提升的主线，在三个阶段的不同网络要求，包括带宽、时延、丢包率，并按照VR视频业务和VR强交互业务分类表述。表2-1 Cloud VR不同发展阶段对网络KPI的要求注1：强交互业务内容为实时渲染生成，没有全景画面，内容分辨率是指需要渲染的画面的分辨率。注2：带宽需求按单个VR终端用户计算。注3：VR视频业务对网络RTT并没有很严格的要求小于20ms，但时延较小的情况下进行切换频道，开始播放等操作时画面加载的时间比较短。如果对画面加载时间没有太高要求，那么网络RTT可以也放宽至30~40ms。| 12

起步阶段Cloud VR网络解决方案本章节主要从理论上分析起步阶段Cloud VR业务的承载网络部署方案，部分方案还没有在现网中部署。现网已商用部署方案请参考华为iLab发布的《Cloud VR解决方案实践报告》。3.1 目标网络架构在Cloud VR起步阶段，单路VR业务带宽要求为80Mbps，同时开通4K IPTV和上网业务后，用户带宽建议为VR 80Mbps + 4K IPTV 50Mbps + HSI 100Mbps = 230Mbps及以上。其中，VR的投屏业务通过4K IPTV通道下载，要求头端对VR投屏流量压缩到4K视频的带宽水平。如果头端压缩不了投屏流量，则带宽变成VR 80Mbps + 4K IPTV（含投屏）80Mbps + HSI 100Mbps = 260Mbps。考虑到当前大部分头端对投屏业务没有做压缩，后续统一按260Mbps带宽进行计算。在Cloud VR起步阶段，网络RTT要求为20ms，分解到各段网络如下表所示：表3-1 Cloud VR起步阶段时延要求分解端到端网络RTT≤20 ms家庭Wi-Fi≤10ms固定接入网≤2ms城域承载≤8msCloud VR起步阶段的建网目标是基于已有的网络实施局部改造，实现Cloud VR业务的快速低成本部署。为此，起步阶段Cloud VR网络解决方案核心理念是“基于Wi-Fi的家庭网”+“基于4K ready的承载网”+“利旧CDN/新建云渲染服务器”，如下图所示：图3-1 起步阶段Cloud VR承载网目标架构◆ 基于Wi-Fi的家庭网：传统4K机顶盒往往建议使用网线接入网络，而Cloud VR头盔则要求必须Wi-Fi接入，所以需要构建基于Wi-Fi的家庭网来实现Cloud VR业务承载。其中重点的则是高性能Wi-Fi AP的部署。13 |

Cloud VR网络方案白皮书◆ 基于4K ready的承载网：为了低成本快速部署Cloud VR业务，可以依托4K Ready的极简承载网络架构，根据Cloud VR带宽时延要求进行局部调整，包括：· GPON/EPON升级10G GPON/EPON· OLT上行端口扩容升级· 城域网扩容升级/OTN一跳直达等◆ 利旧CDN/新增云渲染服务器：在起步阶段，可以复用现有的CDN资源进行Cloud VR视频的内容分发，同时新增云渲染服务器进行Cloud VR游戏的内容分发。一般要求CDN/云渲染服务器部署在城域内。该解决方案可以带来如下好处：◆ 最大程度复用现网资源：复用IP网络、光网络、FTTH接入网、CDN资源等，按需进行容量升级就可以解决大部分问题。◆ 尽可能降低部署难度：通过复用上网通道进行Cloud VR承载，可以避免重新布放一套VLAN、IP地址、认证账号。◆ 创造家庭新产品/服务销售机会：基于Cloud VR高体验保障诉求，为运营商创造面向消费者销售新家庭网关、以及智能组网服务的机会。3.2 家庭网规划设计3.2.1 Cloud VR家庭网面临的挑战为了保证移动便利性，VR头盔一般采用Wi-Fi无线连接方式，在进行Wi-Fi部署时，普遍存在三类问题和挑战：5GHz Wi-Fi可用信道少，承载Cloud VR时存在规划难题现有Wi-Fi网关的能力参差不齐

Cloud VR如何与现有家庭业务共存而相互不影响| 14

5G Wi-Fi可用信道少，存在规划难题2.4G Hz频段信道少且相互重叠，按20MHz频宽计算也只有3个独立信道，总频宽不足80Mhz，难以承载Cloud VR业务。5GHz Wi-Fi理论最大激活速率可达3466Mbps，比较适合用于承载Cloud VR。图3-2 欧洲5G Wi-Fi频谱规划5G Wi-Fi频谱分布如上图所示（不同国家不同，以欧洲为例）：20MHz频谱支持19个，40MHz频谱支持9个，80MHz频谱支持4个，160MHz频谱支持2个。其中大部分是DFS信道，非DFS信道数量很少，在常用的80MHz上只有1个可用信道。从市场已有的消费级AP能力看，为了降低实现复杂度，大部分不支持DFS信道，导致家庭网络中的5G Wi-Fi集中拥挤在非DFS信道中，产生较为严重的干扰。干扰会引发空口竞争和冲突，报文需要等较长时间才能得到发送机会，或者发送时遇到冲突需要重新发送，使得报文的发送时延变大。如果时延超过设备容忍时长，或者重传次数超过阈值，就会表现为丢包。同时，干扰会导致Wi-Fi可用速率变低，如果低于Cloud VR所需带宽，就会发生报文队列持续增长的现象，最终溢出丢包。图3-3 干扰引发时延和丢包示意图综上，Cloud VR在部署时，首先要解决5G Wi-Fi的信道如何规划利用的挑战。15 |

Cloud VR网络方案白皮书现有Wi-Fi网关性能能力参差不齐目前市面上支持5GHz Wi-Fi的设备有很多，但价格和性能却参差不齐。根据iLab实验室针对几款较为常见的5GHz Wi-Fi产品来进行测试发现，不同产品型号对干扰环境的适应程度有较大差异，测试结果如下表所示：表3-2 不同型号设备支持的干扰不一样根据测试结果可以发现：◆ 在无干扰的情况下，5个型号的设备都能够满足RTT时延要求；◆ 存在两路邻频干扰的情况下，4个型号的设备都能够满足RTT时延要求，1个型号的设备无法满足RTT时延要求；◆ 存在1路邻频干扰和1路同频干扰的情况下，只有2个型号的设备都能够满足RTT时延要求，3个型号的设备无法满足RTT时延要求；◆ 存在2路同频干扰的情况下，只有1个型号的设备都能够满足RTT时延要求，4个型号的设备无法满足RTT时延要求；由此可见，Cloud VR在部署时，选择高性能的Wi-Fi产品是关键。Cloud VR如何与现有家庭业务共存而相互不影响Cloud VR是基于4K ready网络增量开通的业务，需要考虑与已有的4K IPTV业务、HSI业务进行共存，避免不同业务间产生冲突干扰。在4K Ready承载网中，由于IPTV推荐采用有线方式接入，上网业务采用Wi-Fi方式接入，所以核心是如何保证上网业务的Wi-Fi不对Cloud VR的Wi-Fi产生影响。| 16

3.2.2 Cloud VR家庭网规划建议为了解决上述挑战，Cloud VR家庭网 络部署时，需重点考虑如下方面：· 需选择合适的Wi-Fi频宽和信道。 需要给VR业务选择适合的5G Wi-Fi频宽，确保有足够的带宽承载；同时，由于5G Wi-Fi信道少，需要运营商对信道进行合理规划。· 需要定义和选择高性能的Wi-Fi网关。· 需要选择合适的组网形态，确保Cloud VR与现有家庭业务共存而相互不影响。Wi-Fi建议选择80MHz频宽、2*2 MIMO，运营商提供信道规划服务5GHz Wi-Fi可选的频宽包括20MHz、40MHz、80MHz、160MHz四种选择，不同的频宽支持的速率不一样。考虑到当前市面上大部分VR头盔支持2*2 MIMO，因此后续计算以2*2 MIMO为基础进行。下图是2*2

MIMO情况下，不同频宽在不同MCS（Modulation and Coding Scheme）制式下的最大理论速率。表3-3 Wi-Fi速率表实际上，由于5GHz Wi-Fi信道少，大规模部署5GHz Wi-Fi后，同频干扰可能无法规避。在考虑存在两路同频干扰情况下，Wi-Fi速率按照MCS6制式，考虑50%占空比以及40%传输损耗后，实际数据速率约为MCS6速率*50%*(1-40%)，即：20M频宽支持速率为39Mbps，40M频宽速率为81Mbps，80MHz频宽速率为175Mbps，160MHz频宽速率为350Mbps。考虑到160MHz频宽基本没有终端支持，推荐Cloud VR使用80MHz频宽进行承载。不同国家的5GHz频段规划不一样，5GHz Wi-Fi可使用的信道数量也不一样。以欧洲为例，当采用80MHz频宽时，5G Wi-Fi只有4个信道可供部署。由于信道选择过程复杂，用户很少具备Wi-Fi部署的工程能力，建议运营商需要提供上门安装服务，对现场的Wi-Fi信道情况进行扫描识别，并基于扫描结果设置合适的Wi-Fi信道和合理的Wi-Fi网关安装位置。17 |

Cloud VR网络方案白皮书高性能Wi-Fi网关要求：抗干扰能力强，支持雷达信道和千兆端口为避免低性能Wi-Fi网关对Cloud VR业务体验造成影响，建议构建高性能Wi-Fi网关标准进行产品筛选。根据iLAB测试结果，该标准主要包括：◆ 在2~4路同频干扰的情况下，支持小于10ms的稳定空口传输时延和80Mbps以上的稳定空口传输速率。◆ 支持雷达频段设置和雷达自动检测功能。 5G可用信道少，以欧洲为例，5G Wi-Fi只有4个信道可部署，其中3个为DFS信道。为了避免所有家庭都集中到一个非DFS信道上产生大量同频干扰，需要考虑把DFS信道也利用起来。对于运行在DFS信道的Wi-Fi网关，需要支持DFS定期检测功能，检测当前信道是否存在雷达干扰，如果检测到干扰，则需要切换到其他信道。◆ 具备2个及以上的千兆端口，支持灵活的组网方式，减少线路改造的需求。Cloud VR家庭网络部署建议：采用高性能独立AP承载Cloud VR业务Cloud VR是基于4K ready网络增量开通的业务，需考虑与现有的4K IPTV、上网业务共存的问题，IPTV采用有线方式接入，所以核心问题是如何保障使用Wi-Fi接入的上网业务和Cloud VR业务互不影响。为了解决此问题，有如下三种部署方案：◆ 方案1：新增高性能专用AP承载Cloud VR业务: VR业务体验有保障，推荐部署。◆ 方案2：利旧现网的ONT/HGW承载Cloud VR业务：现网ONT/HGW只支持一个5GHz频段，故Cloud VR业务只能和上网业务通过这同一个5GHz Wi-Fi频段进行承载，VR业务体验会受到影响，同时现网ONT/HGW性能一般较弱，不支持雷达信道 ，可用信道少，易产生冲突。不推荐部署。◆ 方案3：将现网ONT替换成高性能三频Wi-Fi ONT（2*5GHz + 1*2.4GHz）:当前存在大量ONT部署在弱电箱的情况，更换ONT也无法为Cloud VR业务提供Wi-Fi接入，并且，当前市面上暂无可用的支持三频Wi-Fi ONT产品。暂不用考虑此方案。| 18

下面对推荐部署的方案1进行详细描述：在具体部署时，根据ONT部署位置的差异，选择不同的连接方式，分为2个场景：场景1：ONT部署在弱电箱时，AP存在两种接入方式ONT部署在弱电箱时，主要的组网方式是ONT通过网线连接客厅的HGW，上网业务由HGW的5GHz

Wi-Fi/2.4GHz Wi-Fi接入， IPTV业务接入由HGW的ETH口接入。部署Cloud VR业务时，新增的AP可以通过如下两种方式接入：方式1：AP通过网线直连HGW，改造简单，现网千兆HGW情况下推荐选用在该接入方式下，无需改动原家庭组网的连接关系，改造简单。但是Cloud VR业务流量先经过HGW转发至AP，对HGW的带宽要求较高，在起步阶段，Cloud VR带宽需求为80Mbps，可以利旧千兆HGW和百兆HGW；在舒适体验阶段，Cloud VR带宽需求为260Mbps，只能利旧千兆HGW，所以此方式比较适合现网千兆HGW的情况。方式2：AP串接在ONT和HGW之间，改造较复杂，现网百兆HGW情况下推荐选用在该接入方式下，需要改动原家庭组网的连接关系，并将PPPoE拨号上移至ONT，改造较复杂。但是，由于新增AP负责Cloud VR业务的分流，现网HGW的流量不变，即使是百兆HGW也可利旧，所以此方式比较适合现网百兆HGW的情况。图3-4 新增Cloud VR专用AP组网示意图（ONT部署弱电箱）19 |

Cloud VR网络方案白皮书场景2：ONT部署在客厅桌面，AP网线直连ONTONT部署在客厅桌面时，上网业务由ONT的5G Wi-Fi和2.4G Wi-Fi接入， IPTV业务接入由ONT的ETH口接入。部署Cloud VR业务时，新增的Cloud VR专用AP只能通过网线与ONT连接。具体布线图如下图所示。图3-5 新增Cloud VR专用AP组网示意图（ONT部署客厅桌面）| 20

3.3 接入网设计：10G PON为主，EPON/GPON受限开通在起步阶段，分解给接入网的时延要求为≤2ms，使得铜线和Cable不适合用于承载Cloud VR，只有FTTH一种方案是合适的。当前主流的FTTH制式为GPON、EPON，正常情况下，时延即可满足起步阶段VR的要求，重点需要考察带宽的满足度，分析如下表所示：表3-4 FTTH用户可获得带宽情况注：用户可获得带宽 = 容量/分光比/收敛比由于Cloud VR叠加4K IPTV和上网业务的带宽诉求是260Mbps或更高。因此，不管是EPON还是GPON都不能大规模开通起步阶段Cloud VR业务，只能受限开通少量用户。为了大规模满足VR的带宽需求，需要逐步将FTTH接入方式升级到10G EPON/10G GPON，即使在分光比1:64情况下，考虑50%收敛，每用户可获得带宽达到312Mbps，完全可满足起步阶段Cloud VR业务的带宽需求。EPON和GPON向10G EPON/10G GPON演进升级建议如下：EPON向10G EPON演进：EPON和10G EPON的上行波长重合，可以通过时分复用方式共用同一ODN；下行波长没有重叠，可以基于波长范围接收对应的波长。因此，EPON向10G EPON演进时ODN无需变动，需要增加10G EPON单板，将EPON 用户平滑割接到10G EPON，原EPON的ONT可以继续使用，按需替换为10G EPON的ONT。值得注意的是，在混跑的情况下，由于EPON和10G EPON上行速率不一致，用户的上行带宽规划会比较复杂。21 |

Cloud VR网络方案白皮书图3-6 EPON/10G EPON波长范围图3-7 EPON升级到10G EPON部署建议GPON向10G GPON演进：如下图所示，GPON和10G GPON的上行波长没有重合，可以通过波分复用方式共用同一ODN，下行波长没有重叠，可以基于波长范围接收对应的波长。由于 GPON与10G

GPON相互独立，带宽可以独立规划。图3-8 GPON/10G GPON波长范围| 22

GPON向10G GPON演进存在两种方案，方案一外置WDM1r合波器方案：即通过外置WDM1r合波器将10G GPON口和GPON口的波长合波后通过同一主干光纤传输，原GPON的ONT可以继续使用，按需替换为10G GPON的ONT。由于部署WDM1r合波器会引入额外衰耗，对于新部署的GPON建议预留2-3dBm的光预算，现网已经部署的PON口，如果光预算不足，建议通过升级大功率光模块解决。图3-9 GPON升级到10G GPON方案二Combo板方案（推荐）：即板内集成10G GPON和GPON能力，光模块内置合波器，之前将现网的PON口割接到Combo单播的PON口承载，原GPON的ONT可以继续使用，按需替换10G

GPON ONT。3.4 城域网规划设计：基于4K承载网进行扩容升级在Cloud VR起步阶段，可以复用4K网络架构进行业务承载，如下图所示：图3-10 起步阶段Cloud VR城域架构：复用4K城域架构与4K城域类似，Cloud VR城域主要包含如下技术措施：23 |

Cloud VR网络方案白皮书· 网络扁平化，降低无效收敛： OLT接入设备应直连城域网网关BNG，BNG一跳直达城域核心CR设备。· BNG下沉：BNG下沉可以降低网络中布放VPLS等技术带来的复杂度，同时可支撑CDN/云渲染服务器位置自由布放，减少时延。· OTN到CO：网络扁平化过程中会伴随大量的光纤建设诉求，通过波分设备进一步下沉到城域边缘/OLT站点，提供超大带宽、低时延和零丢包的互联基础管道，支撑网络扁平化实施。· 实时监控网络链路利用率，超过Cloud VR要求的负载门限时及时扩容，避免突发引起的拥塞丢包。在起步阶段，Cloud VR预计部署规模较小，假设用户渗透率考虑30%左右，并发率预计低于IPTV的水平（各地水准不同，假设OLT为50%，城域边缘为20%、城域核心为10%）。根据上述数据，可以计算得到Cloud VR在城域网增加的容量诉求如下：◆ OLT上行端口容量诉求：OLT设备用户数（按1500用户算）* VR用户渗透率30%*并发率50%*起步阶段VR码率（按40Mbps算）=

9Gbps◆ 城域边缘设备容量诉求： 边缘设备用户数（按2万用户算）*VR用户渗透率30%*并发率20%*起步阶段VR码率（按40Mbps算）= 48Gbps◆ 城域核心设备容量诉求：边缘设备用户数（按100万用户算）*VR用户渗透率30%*并发率10%*舒适体验阶段VR码率（按40Mbps算）= 1.2Tbps可以看出来，起步阶段Cloud VR部署后，对城域网会带来一定的扩容升级诉求，建议要做好相应的扩容规划，避免拥塞影响体验：◆ OLT上行口建议至少升级到2*10GE◆ 城域边缘设备至少升级为2*100GE上联城域核心◆ 城域核心设备建议升级为400Gbps/槽位或者Tbps/槽位的集群平台除了带宽之外，城域网的时延要求为8ms以内（含CDN网络），建议城域设备整体转发时延<1ms、CDN网络转发时延<1ms，剩余6ms用于光纤距离和排队缓存产生的时延，要求CDN/云渲染服务器的布放位置在城域内。| 24

3.5 Cloud VR承载设计3.5.1 4K承载方案现状Cloud VR承载网是基于4K ready的视频承载网的基础上进行改造和演进的，因此有必要先理清楚4K IPTV承载方案的现状。图3-11 4K IPTV承载方案如上图所示，4K IPTV承载方案分为两部分：· 城域网的IPTV承载：组播主要使用NG-MVPN、PIM+VPLS组播技术，这些技术本身已经比较成熟，VR可以直接共享使用，本白皮书不作赘述。· 接入段的IPTV承载：当前主流方案是基于双通道的方式进行IPTV承载，有少量运营商采用了单通道方案。不同的模式下，Cloud VR的承载方式有不同的选择。25 |

Cloud VR网络方案白皮书3.5.2 双通道场景Cloud VR承载方案双通道场景下，STB接入ONT的专用IPTV端口，进行独立的拨号，使用专用的IP地址，这种方案是历史上IPTV使用专网承载遗留下来的，当前依然是主流方案。图3-12 双通道 IPTV承载方案随着VR业务的加入，双通道场景有3种可选的承载方案：方案1：复用HSI通道承载VR（推荐）如下图所示：VR头盔跟其他上网终端一样，从ONT获取IP地址，复用PPPoE上网通道承载。图3-13 复用HSI通道承载VR方案在本方案下，头盔不需要任何特殊处理即可接入网络，实施起来最为简单，是推荐的部署方案。本方案默认不提供VR组播业务，VR直播通过点播方式下发。如果未来用户数较大，可以将组播分离出来单独推送到ONT，不影响上述拨号方式。| 26

方案2：VR独立通道承载如下图所示：VR独立通道承载方案在4K IPTV承载方案的基础上，增加一个IPoE逻辑通道承载VR业务，此时在ONT上需要预留一个VR AP专用的端口，将此端口与独立的IPoE通道的桥接WAN口进行绑定。图3-14 VR独立通道承载方案VR独立通道方案改造涉及从ONT到BRAS间的规划VR专用通道的VLAN、IP地址、路由策略，新增VR单播通道认证的AAA服务器和DHCP Server，此外涉及OSS业务下发系统改造，改造方案比较复杂。不建议使用。方案3：复用IPTV通道承载VR如下图所示：VR业务通过IPTV通道进行承载，ONT将Cloud VR的专用AP接入的专用端口绑定到已有的IPTV通道上。VR头盔与机顶盒一样，通过IPTV通道进行IPoE拨号认证。图3-15 复用IPTV通道承载VR方案在本方案下，VR头盔发放时需要在AAA添加相应的IPoE账号，在VR头盔上线时，需要头盔支持DHCP

Option60/61字段进行相应的IPoE认证过程，改造过程同样较为复杂。不建议使用。27 |

Cloud VR网络方案白皮书3.5.3 单通道场景Cloud VR承载方案单通道场景下，一般ONT放在弱电箱，客厅与弱电箱之间的网线用于上网HGW连接，导致STB没有独立的网线连接到ONT的专用IPTV口，只能复用Internet通道。在增加Cloud VR头盔和相应的AP后， Cloud VR承载方案也只能是继续沿用单通道进行统一承载，如下图：图3-16 单通道Cloud VR承载方案| 28

3.5.4 投屏承载方案建议VR投屏是指“通过特定程序处理将Cloud VR用户在终端中观看到的图像画面通过电视屏幕展现出来”的过程，它可以在用户体验过程中将虚拟世界画面同步分享给他人，是VR业务的刚性需求。为了实现Cloud

VR投屏，需要头盔、机顶盒、头端等相互传递信令和数据交互。当前主要有两种Cloud VR投屏方案：云端XMPP投屏和本地DLNA投屏方案，如下图所示：图3-17 投屏方案对比示意图云端（XMPP）投屏方案（推荐）此方案由Cloud VR云端系统同步流量到IPTV系统，机顶盒到IPTV系统拉取投屏流量。机顶盒的流量与头盔的流量相互独立，网络需要两份带宽。此方案已经在商用试点使用，相对成熟可靠，建议使用。本地（DLNA）投屏方案（不推荐）此方案由头盔与STB之间通过DLNA传输投屏流量，因为Wi-Fi AP与终端需要处理转发两份流量，实测体验效果差，终端功耗大，同时，此方案要求头盔与机顶盒使用相同的地址段（即Cloud VR复用IPTV通道），现网条件较难满足。因此，本方案不推荐使用。29 |

Cloud VR网络方案白皮书3.5.5 Cloud VR承载方案建议总结· 在城域段，由于Cloud VR复用Internet通道，建议优选IP组播/单播技术进行Cloud VR承载。· 在接入段，运营商网络一般同时混合存在双通道和单通道承载的情况，不管是双通道还是单通道，均建议Cloud VR复用Internet通道进行承载，使得Cloud VR头盔可以像手机终端一样快速接入网络，不需要特别的网络部署改造。图3-18 推荐的VR部署方案· 在投屏方案上，当前云端投屏方案对Cloud VR头盔的认证能力、Wi-Fi能力、CPU能力要求低，实际使用效果比本地投屏好，建议选用云端投屏。| 30

3.6 带宽与QOS部署设计3.6.1 带宽规划方法在对网络进行容量规划时，首先要对业务流量速率、用户数以及站点情况进行建模，基于建模结果可以获得全网以及各个站点的流量预测，最后再叠加端口保护以及链路容量冗余度等，获得相对准确的站点容量要求。容量规划过程如下图所示：图3-19 VR网络容量规划方法· 业务建模的目标是获得每用户的平均上网速率、IPTV点播平均码率、Cloud VR点播（含游戏）平均码率、IPTV直播流量、Cloud VR直播流量等数据，计算方法如下：平均上网速率≈城域核心设备的出口流量（扣除IPTV和VR后）/下挂用户数。IPTV平均点播码率 = ∑IPTV点播视频码率*点播时长占比。如果4K/高清码率的时长占比高则平均点播码率高，如果标清码率的观看时长占比高则平均点播码率低。Cloud VR点播(含游戏)码率 = ∑Cloud VR点播码率*使用时长占比。直播流量总和=∑频道码率*频道数，直播频道包括IPTV直播频道和VR直播频道· 用户建模的目标是获得全网宽带用户数以及视频用户数以及后续的增长目标数据，这部分数据通常由运营商的市场部门根据已有数据叠加商业发展目标做出判断。用户建模的结果通常如下表所示：表3-5 用户建模结果· 站点建模的主要目标是定义站点拓扑、站点数量、站点并发率和收敛比等信息，为后续计算站点容量做准备。站点建模一般涉及的信息如下图所示：31 |

Cloud VR网络方案白皮书图3-20 站点建模示意图经过上述的业务建模、用户建模和站点建模后，就可以推导计算站点的容量需求了，一般计算过程如下：· 站点上网流量 = 站点下挂宽带用户数*设备每用户平均上网速率;· 站点IPTV点播流量 = 站点IPTV点播并发用户数*点播用户平均码率；· 站点Cloud VR点播（含游戏）流量 = 站点Cloud VR点播并发用户数*Cloud VR平均码率；· 站点直播流量 =直播流量总和（含VR直播）*设备的直播频道推送比例；· 站点经过的流量大小 = 站点上网流量 + 站点IPTV点播流量 + 站点 Cloud VR点播(含游戏)流量 + 站点直播流量根据站点流量大小，结合网络拓扑，可进一步估算出站点的设备端口诉求。3.6.2 QOS部署建议由于不同的业务对网络要求不一样，需要对业务进行分类，不同优先级的业务进入不同的端口优先级队列进行QoS保障：◆ IPTV直播/VR直播业务：对丢包敏感，影响用户面广，需要高优先级保证◆ VR游戏：强交互的VR游戏，对时延比较敏感，需要高优先级保证◆ IPTV/VR点播业务：符合流量规划的情况下优先保证自营点播业务◆ 互联网OTT业务：保证一个基本带宽，尽力转发表3-6 视频业务优先级分配建议| 32

有了优先级定义后，需要网络节点执行相应的动作才能使得QOS生效。QOS动作包括Remark优先级、CAR/Shaping、Schedule三种，不同的网络节点需要部署三种动作的一种到多种（如上图所示），典型的部署规则如下：图3-21 E2E QoS部署建议· Remark优先级部署：一般上行在ONT基于不同端口或者DHCP报文特征来识别IPTV流量并进行优先级remark，下行在CR基于IPTV或者VR地址段或者端口+VLAN来识别对应业务进行优先级remark。· CAR/Shaping限速：一般在BRAS对用户上下行进行按套餐设定的限速，可以使用CAR或者shaping方式。CAR限速不使用缓存，没有调度过程，不会引入排队时延，但突发会被透传到下游，适用于下游设备缓存较大的场景；Shaping通过队列对用户流量进行整形，流量的突发会被平抑到10ms级别，对下游的冲击会比较小，整形过程会引入时延抖动，适用于下游设备缓存较小的场景。在Cloud VR场景中，建议选用CAR方式，减少shaping引入的时延抖动。在Cloud VR的部署中，由于推荐VR业务复用Internet通道，为了避免VR业务因为Internet套餐限速而产生影响，建议部署DAA把VR业务分离出来单独限速。如下图所示，组播业务通过独立子接口承载，不限速；机顶盒点播业务通过IPoE拨号限速，上网业务和VR业务通过同一PPPoE拨号承载，上网业务通过PPPoE拨号进行限速，通过在PPPoE上网通道部署DAA，将VR业务分离出来采用DAA CAR单独限速，防止上网业务对VR业务的冲击。图3-22 PPPoE上网通道部署DAA示意图33 |

Cloud VR网络方案白皮书· Schedule部署：Schedule部署的核心目标是优先保证VR和IPTV流量，同时不至于“饿死”HSI业务，不同的网络节点可以使用稍微不同的Schedule策略。· 城域网设备：由于存在众多业务，城域网一般采用SP+WFQ调度模式。其中：语音、管理业务、直播等小流量重要性高的业务一般采用SP调度模式；视频、企业业务、HSI等业务则采用WFQ调度模式。WFQ的队列权重非常关键，需要根据各业务的流量大小进行设置。举例：假设某站点组播流量0.7Gbps、点播流量2.5Gbps，且两个设备间使用2*10GE捆绑，则组播流量占比为3.5%，点播流量占比12.5%。实际考虑到端口聚合hash不均匀以及部分突发因素，建议实际组播队列权重配置为10%或以上，点播队列权重为25%或以上。· 接入OLT：如果OLT涉及业务很多，则与城域网一样进行SP+WFQ的调度规划。如果OLT仅涉及宽带业务，也可以仅使用默认的SP调度，避免复杂的规划部署。对于PON口而言，由于它按分光比规划，预留带宽比较充足，即使使用SP调度，也极低概率出现上网流量被视频冲击导致“饿死”现象。对于OLT上行口而言，视频上行流量很小，也极难出现上网流量被视频冲击导致“饿死”现象。· Wi-Fi空口：如果视频业务和普通上网业务共享Wi-Fi信道，建议使用Wi-Fi标准的WMM机制对视频进行优先抢占无线信道，确保视频流量优先转发。| 34

3.7 Cloud VR体验保障方案当前Cloud VR的运维体系尚未构建完整，如何进行Cloud VR的运维还是一个难题。从4K IPTV的质差问题分类来看，60%以上的问题发生在家庭Wi-Fi侧，所以短期内建议先从家庭网络入手，通过Wi-Fi

Sense方案分析定位家庭侧Wi-Fi指标来进行Cloud VR业务保障。该方案的核心组件是Netopen服务器，负责与ONT及Cloud VR专用AP进行通信，获取相应的Wi-Fi指标进行综合分析，找出家庭组网中存在的问题，并给出优化措施。其实现过程如下：图3-23 Wi-Fi Sense体验保障35 |

Cloud VR网络方案白皮书1. 家庭网关通过PPPoE上网通道从BRAS获取IP地址后，通过该域名向Netopen注册。2. 家庭网关集成指标采集插件，多维度实时采集家庭网络的指标上报为Netopen，如上图所示，家庭网关周期性监控邻居Wi-Fi信息、家庭拓扑、下挂设备、下挂设备信号强度、下挂设备下载速率等关键信息，周期性上报给Netopen。3. Netopen收到家庭网关上报的数据后，基于信道干扰、Wi-Fi覆盖、终端连接、设备、配置等维度分析，对可能影响体验的因素生成告警信息，同时生成历史数据报表。运营商收到用户的VR体验投诉后，可以通过Netopen先判断家庭网络拓扑、VR头盔Wi-Fi强度、协商速率等终端指标，先分析是否由于VR头盔移动引入的问题，再判断信道的信道干扰、配置、设备等多维度综合分析引起VR体验质差原因。如下图，通过Wi-Fi终端的信号强度和协商速率的历史曲线，发现终端的Wi-Fi由于信号强度减弱导致的协商速率下降，从而导致VR体验劣化。| 36

图3-24 终端Wi-Fi信号强度弱导致VR质差示意图对于非信号强度和协商速率导致的视频质量下降，同频干扰是可能性较大的原因之一。如下图，当发现严重干扰时，Netopen通过告警通报信道出现劣化，可人工重选Wi-Fi信道进行调优。图3-25 Wi-Fi信道干扰弱导致VR质差示意图37 |

Cloud VR网络方案白皮书舒适体验阶段Cloud VR网络设想本章节主要从理论上分析舒适体验阶段Cloud VR业务的承载网络部署方案，当前尚未有实际商用案例，仅做理论探讨。4.1 目标网络架构设想在Cloud VR舒适体验阶段，单路VR业务带宽要求为260Mbps，同时开通4K IPTV和上网业务后，用户带宽建议VR 260Mbps + 4K IPTV 50Mbps + HSI 100Mbps = 400Mbps。其中，VR的投屏业务通过4K IPTV通道下载，要求头端对VR投屏流量压缩到4K视频的带宽水平。如果头端压缩不了投屏流量，则带宽变成VR 260Mbps + 4K IPTV（含投屏） 260Mbps + HSI 100Mbps = 620Mbps。在未来，我们认为大部分头端可以对投屏业务进行压缩，后续统一按400Mbps带宽进行计算。在Cloud VR舒适体验阶段，网络RTT要求为15ms，分解到各段网络如下表所示：| 38

表4-1 Cloud VR舒适体验阶段时延要求分解在这个阶段，Cloud VR业务带宽和时延的要求都变得比较高，需要进一步升级增强Wi-Fi接入技术、承载网技术，同时考虑构建一种新的网络架构，实现带宽时延的双重保障。基于此，舒适体验阶段Cloud VR解决方案核心理念是“升级增强的家庭网/承载网” +“带宽时延可保障的网络”，如下图所示：图4-1 舒适体验阶段VR目标架构◆ 升级增强的家庭网：家庭组网上，建议与起步阶段一样使用独立AP，但Wi-Fi能力需要升级，速率达到>260Mbps和时延达到<7ms的目标。◆ 升级增强的承载网：接入全面部署10G PON，城域网演进到N*100Gbps/Tbps容量，云渲染服务器适当下移。◆ 时延带宽可保障的网络：引入带宽时延可保障的理念进行网络重构。39 |

Cloud VR网络方案白皮书4.2 家庭网方案设想在舒适体验阶段，建议继续沿用起步阶段的组网方式，采用独立高性能AP承载Cloud VR业务，但Wi-Fi性能需达到>260Mbps速率和<7ms时延的要求，需要升级为802.11ac 4*4 MIMO或802.11ax技术。4.2.1 802.11ac 4*4 MIMO在Cloud VR起步阶段，5GHz Wi-Fi采用80MHz频宽，家庭5G Wi-Fi考虑存在两路弱干扰，VR头盔支持2*2 MIMO，Wi-Fi速率按照MCS6制式的速率，考虑50%占空比以及40%传输损耗，80MHz频宽速率为175Mbps。在舒适体验阶段，AP和VR头盔可以通过支持更高的空间流来提升带宽，如下图所示：◆ 如果采用3*3 MIMO，考虑一定干扰劣化时，连接速率为MCS5等级，实际可获得速率为780Mbps*50%占空比*60%效率 = 234Mbps，承载舒适体验阶段VR存在风险。◆ 如果采用4*4 MIMO，考虑一定干扰劣化时，连接速率为MCS5等级，实际可获得速率为1040Mbps*50%占空比*60%效率 = 312Mbps，能够满足舒适体验阶段VR的要求。因此，建议AP和VR头盔可以通过升级支持4*4 MIMO来满足舒适体验阶段VR诉求。表4-2 802.11ac 3*3MIMO&4*4MIMO对应的Wi-Fi速率表| 40

4.2.2 802.11ax技术802.11ax标准是基于5G Wi-Fi标准802.11ac的改进，它相比802.11ac主要在几个方面做了改进：（1）引入OFDMA可提升同一信道带宽的利用效率。（2）引入1024QAM，物理速率可提升接近40%。（3）子载波载波数是802.11ac的4倍，可以覆盖更远的范围。（4）支持上行MU-MIMO可增加空口效率，为多用户场景提供了更好的传输效率。802.11ax最大可实现10Gbps理想空口速率，去除开销、信号衰减等导致的带宽损失，实际数据速率可以达到舒适体验阶段和理想体验阶段VR的要求。当前802.11ax标准已成熟，但支持的产品较少。4.3 接入网技术要求在舒适体验阶段，Cloud VR与IPTV、HSI业务接入带宽共计需要400Mbps。在前一章节已分析得知EPON/GPON不适合用于大规模开展起步阶段Cloud VR业务，因此更不适合用于大规模开展舒适体验阶段Cloud VR业务，只建议考虑10G EPON/GPON。如下表所示，10G EPON/GPON在1:64情况下无法达到400Mbps带宽，需要控制用户的实际安装数量，但在1:32情况下可以达到舒适体验阶段Cloud VR业务带宽诉求。41 |

Cloud VR网络方案白皮书4.4 城域网技术要求在舒适体验阶段，Cloud VR业务预计会得到大规模部署，用户渗透率考虑至少50%以上，并发率至少达到IPTV的水平（各地水准不同，假设OLT为50%，城域边缘为30%、城域核心为20%）。根据上述数据，可以计算得到Cloud VR在城域网增加的容量诉求为：◆ OLT上行端口容量诉求：OLT设备用户数（按1500用户算）* VR用户渗透率50%*并发率50%*起步阶段VR码率（按90Mbps算）= 33.75Gbps◆ 城域边缘设备容量诉求： 边缘设备用户数（按2万用户算）*VR用户渗透率50%*并发率30%*舒适体验阶段VR码率（按90Mbps算）= 270Gbps◆ 城域核心设备容量诉求：核心设备用户数（按100万用户算）*VR用户渗透率50%*并发率20%*舒适体验阶段VR码率（按90Mbps算）= 9Tbps因此，舒适体验阶段Cloud VR大规模部署后，对城域网的容量诉求是非常巨大的，需要更高速率和集成度的单板/设备：◆ OLT上行口建议至少升级到4*10GE，有条件的可以考虑直接升级到2*100GE◆ 城域边缘设备至少升级为4*100GE上联城域核心◆ 城域核心设备建议升级为Tbps/槽位的集群平台除了带宽之外，城域网的时延要求压缩到6ms以内（含CDN网络），建议城域设备整体转发时延<1ms、CDN网络转发时延<1ms，剩余4ms用于光纤距离和排队缓存产生的时延，要求CDN/云渲染服务器的布放在城域以内。在该阶段，城域网的云化架构已逐步开始部署，为了降低转发时延，建议云化架构采用CU分离（即控制面云化，转发面继续采用物理设备）的方式，不建议采用全软化的vBRAS方式。| 42

图4-2 城域网CU分离的云化架构更适合Cloud VR承载4.5 带宽时延可保障方案设想带宽可保障主要通过传统的Wi-Fi/PON升级以及城域网扩容等方式实现。时延可保障则是一个新的课题，当前尚未有成熟的架构和商用方案。下面仅对方案诉求和部分内涵进行探讨。理论上，带宽时延可保障的网络有四个诉求，如下图所示：图4-3 带宽时延可保障的网络诉求◆ 意图感知：由于网络中同时存在多种业务，重要性和所需的SLA诉求并不相同，为了实现Cloud VR的最佳保障，需要基于意图感知来识别Cloud VR业务并理解其SLA诉求。◆ 质量感知：质量感知诉求是测量和评估Cloud VR的业务质量及相应的网络质量，形成相应的数据库，为后续的问题识别、问题优化提供输入来源。◆ 问题识别：基于质量感知所采集的数据，可以使用大数据技术、AI技术进行问题归类分析，找出网络的瓶颈点。◆ 网络优化：对于网络瓶颈点，实施自动化/人工的优化措施，使得网络始终处于Cloud VR最佳承载状态。比如，对于Wi-Fi瓶颈，可以通过自动化的信道调优等技术进行速率提升。对于网络容量不足问题，则需要通过人工扩容的方式解决问题。网络优化除了上述工程方法外，还可能通过一些技术手段提升产品能力，降低Cloud VR的带宽消耗和时延要求。包括但不限于：低时延Wi-Fi、降低投屏代理带宽消耗、直播使用FOV等。43 |

Cloud VR网络方案白皮书5 理想体验阶段Cloud VR网络展望随着VR头戴显示终端的屏幕分辨率、芯片性能等硬件性能的提升，以及VR内容的质量的提高，VR视频会逐渐向理想体验阶段（全视角12K、24K）演进，带宽诉求达到1Gbps以上，网络RTT要求≤8ms，分解到各段网络如下表所示：表5-1 Cloud VR理想体验阶段时延要求分解在理想体验阶段，网络需要向“更高的带宽”和“更低的时延”的方向演进：◆ 家庭网Wi-Fi技术：支持X*Gbps带宽速率，建议采用802.11ax 或60GHz Wi-Fi技术承载，可以进一步降低干扰从而降低时延。◆ 接入技术：接入需要升级到25G/50G PON，来实现每用户Gbps接入。◆ 确定性低时延承载网： 云渲染服务器进一步下沉到城域边缘，同时利用网络分片和云网协同等技术获得确定性低时延的网络保障。| 44