5G 的网络延迟时间 1 毫秒是怎么做到的？
更新一下，很多人在评论中问，我补充一下题目。 5G中要求的延迟是空口延迟<1ms，端到端延迟（就是下文中的那个公式之和）<5ms. 因为目前我无法了解华为、爱立信等设备厂商的实际网络结构，所以这个回答就围绕「5G网络可能怎么把网络延迟降低到目标」这个话题来谈谈吧。  可能大家会觉得，延迟是我们能体验到的数据包传输时间，是这个。 或者是这个。 这样理解大略上是没错的，但是它只是通信系统延迟的一小部分。而实际上，我们需要把移动通信的延迟做更精确划分，来帮助优化延迟体验。 通常，移动通信中的术语「延迟」，不仅仅是用户能体验到的玩游戏/下载/上网所能感受到的数据延迟，而且会包含终端设备从空闲态 (比如关机、飞行模式等）到连接态（比如连入通信网络）所需的延迟、当终端移动时，从一个基站切换到另外一个基站所需的延迟等等。。 前者被称为用户平面延迟（User plane latency）主要用以描述数据包在网络中传输的延迟，后者被称为控制平面延迟（Control plane latency），主要用以描述控制数据在网络中传输的延迟。 5G中的低延迟主要聚焦于用户平面延迟，当然对控制平面延迟也有要求。  控制平面延迟 很多人好奇为什么手机开机需要很久才能连上网，那么我们以4G LTE-FDD系统为例来解释 控制平面延迟， 当一个用户(UE）连入基站（eNode B）时，会经过如上图所示18个步骤，才能连入LTE网络。从上述18个步骤，我们可以稍微计算一下大概延迟是多少。 0.5ms(1. 随机接入调度）+ 1ms（2. 随机接入序文）+ 3ms（3+4，基站处理延迟+序文检测和传输）+5ms（5. 用户处理延迟）+1ms （6. 远程连接建立请求）+ 4ms（7. 基站处理延迟）+1ms（8. 远程连接建立序文）+ 15ms（9.用户处理延迟）+ 1ms（10.连接建立序文）+ 4ms（11. 基站处理延迟）+ 13ms（13. MME处理延迟）+4ms（15. eNode B处理延迟）+1.5ms（16. 安全模式命令+RRC连接序文）+20ms（17.用户处理延迟）+1.5ms (18.  安全模式命令+RRC连接序文) =80ms延迟（平均）  用户平面延迟 控制平面延迟主要影响网络切换，而大家觉得玩游戏卡顿，延迟高，这都要归功于用户平面延迟了。那么我们可以回顾一下LTE系统的组成部分，就可以看到延迟由那几部分组成。 用户平面延迟 ： 用户设备和基站之间的无线时延 T_{无线} 、基站和核心网之间的回传延迟 T_{回传} 、核心网延迟 T_{核心} 和互联网传输延迟 T_{互联网} 。 那么我们平常在电脑上或者手机上能够看到的延迟xxx ms, 就应当是这些的总和再乘以2（数据包往返时间），公式就是下边这个了！ T_{端到端} = (T_{无线}+ T_{回传}+ T_{核心} + T_{互联网}) \times 2 基于此，如果我们想要降低移动通信系统中的延迟，就可以从上述各点来压缩时间。为了更好地理解5G可能怎么减轻时延，我们一个一个来介绍：  1. 无线延迟T_{无线} 熟悉通信结构的同学可能知道，用户终端和基站之间的数据交互涉及很多信号处理模块，比如信道编码、速率匹配、循环冗余检测、预编码、调制解调、OFDM帧生成、时频资源配置、帧同步、交织等等等等。与这些算法所占用的时间相比，电磁波在空中传输的时间其实并不算多。 当前4G通信系统中的无线时延大约在5ms左右。ITU认为，低延迟通信的无线传播时延 T_{无线} 应当低于0.5ms，才能满足一些例如智能电网发电机组相位同步的要求。  无线时延解决方案1：更改帧参数 在目前的LTE系统中，一个无线帧（传输时间10ms）由10个子帧（1ms）构成，而每个子帧又可以被分为2个时频资源块（Resource Block）。这0.5ms的时频资源块大约会由6或者7个OFDM符号（时域）和12个/每个占据15KHz带宽的子载波（频域）构成，那么很容易得到OFDM符号长度应当是 \frac{1}{\Delta f} = 66.67 \mu s 。 LTE系统采用OFDM信号传输数据，为了保证OFDM信号的正交性，各个符号之间必须存在一定的间隔，如上述现行LTE配置中，因为上述配置得到的传输时间间隔（TTI）最小1ms。 传输时间间隔是无线时延的一大影响因素，TTI越大，时延越大。因为TTI主要来自OFDM帧保护间隔，所以可以理解，TTI会随帧参数改变。因此，5G中的一个重要举措就是引入了可变的帧参数和帧结构，用以适应不同场景下的时延需求。 无线时延解决方案2：非正交多址 正如之前所说，为了保证OFDM信号的正交性，系统需要花费大量时隙和信号用来做保护间隔，那么如果我们采用非正交信号，是否能减少这些时延？ 答案是可以的。比如5G中呼声很高的候选滤波器组多载波（FBMC）和广义多载波（UFMC），根据[1]中的结果，这种改进的FBMC可以比OFDM提高10%左右的时间效率，在短码情况下，UFMC甚至可能会比FBMC要更好一些。 无线延迟解决方案3：新型调制和编码 前一段时间的5G投票风波大家还可能记忆犹新。5G候选方案中有三种编码方式：LDPC，Polar和Turbo码。根据华为和日本运营商NTT Docomo的对比，Polar码在长、短码的空口和帧结构测试中，都比Turbo码表现出色，尤其以短码更为明显。 附上对比表（这个表是其它公司做的，这里Polor码在长码部分表现并不突出）： 可见时延是5G中需要考虑的重要因素，5G投票中胜出的LDPC码和Polar码均在某个方面的时延表现出众。 针对传统的IFFT模块，5G中也有考虑采用新型的IFFT技术，比如把串行模块并行化，来降低IFFT所需要的内存同时提高运算速度。  2. 回传和核心网延迟T_{回传}+ T_{核心} 之前在其它答案里有谈到，现在LTE系统核心网的重要问题是服务网关和分组数据网关依然存在一定耦合，换句话说，控制信令和用户数据之间的数据通路依然是耦合状态。用户数据依然需要通过一些控制信令网元，这样的结构不利于低时延通信。 因此，核心网的关键问题是需要解耦用户平面和控制平面。根据这种思路，最好的方式是把网元尽量虚拟化，软件定义网（SDN）和网络虚拟化功能（NFV）是两个最好的候选方案。 网元虚拟化有很多好处，例如可以建设中心机房，来降低能源需求；可以完成针对业务的切片操作，针对不同业务做针对性优化；也可以更方便部署边缘计算单元，更好的降低延迟。 T_{核心}的主要处理方式是SDN和NFV，那么回传延迟T_{回传}可能怎么优化？ 目前存在两种思路：  3. T_{互联网} 互联网延迟 实际上，现在阻碍低延迟通信的最大因素之一是回程链路容量不足，目前大量基站采取共享回传链路的方式传输数据，当用户量爆发式增长时，回传链路容量必然会成为瓶颈，从而导致数据大量重传，导致延迟提升。 针对这种情况，以及互联网中因为数据传输距离过长导致的延迟，最好的解决方案是采用各种缓存。 正如上图所示，为了降低网络延迟，5G中设计了多种多样的缓存，比如本地缓存、端到端缓存、小基站缓存、宏基站缓存等等。 无所不用其极的缓存= =。  大概这样可以把网络延迟优化了吧，但是能不能到1ms，还要看这么多技术叠加起来能起到什么作用。 完。  [1]   N. Michailow, I. Gaspar, S. Krone, M. Lentmaier, and G. Fettweis, “Generalized frequency division multiplexing: Analysis of an alter- native multi-carrier technique for next generation cellular systems,” in Proc. Int. Symp. Wireless Commun. Syst. (ISWCS), Paris, France, Aug. 2012, pp. 171–175. [2]  M. Sybis, K. Wesolowski, K. Jayasinghe, V. Venkatasubramanian, and V. Vukadinovic, “Channel coding for ultra-reliable low-latency commu- nication in 5G systems,” in Proc. IEEE Veh. Technol. Conf. (VTC Fall), Montreal, QC, Canada, Sep. 2016, pp. 1–5. [3]   S.Zhang,X.Xu,Y.Wu,andL.Lu,“5G:Towardsenergy-efficient,low- latency and high-reliable communications networks,” in Proc. IEEE Int. Conf. Commun. Syst. (ICCS), Nov. 2014, pp. 197–201. [4] M. Agiwal, A. Roy, and N. Saxena, “Next generation 5G wireless networks: A comprehensive survey,” IEEE Commun. Surveys Tuts., vol. 18, no. 3, pp. 1617–1655, 3rd Quart., 2016. [5] Parvez I, Rahmati A, Guvenc I, et al. A survey on low latency towards 5G: RAN, core network and caching solutions[J]. IEEE Communications Surveys & Tutorials, 2018, 20(4): 3098-3130. 