一 、问题背景
现在的智能终端普遍存在多种无线资源，比如比较常见的Wifi链接和蜂窝(Celluar)链接，目前的智能终端设备，普遍的做法是在同一时间，终端只使用其中一种无线资源作为通信传输。随着用户的移动，受限于无线资源存在的覆盖区域限制，势必会发生在多种无线资源之间的链路切换，而这个切换就会带来断开和重建链路的时间开销，反映在用户感知上就会出现卡顿或者断流，严重影响用户的数据体验。下图是Zoom应用在Wifi链路切换到Celluar链路的时延情况，从图中可以看出，断链时间达到15s以上。
图一 Wifi切换到蜂窝时延示例
下面以wifi和Celluar之间的切换为例进行问题的剖析以及探讨一些相关技术。
二、问题剖析
我们以Wifi链路切换到Celluar链路为例，如下图所示，我们做以下的定义：
Wifi信号覆盖区域为区域2，其中强信号覆盖区域为区域1，区域2黄色部分定义为Wifi弱信号区域，且越靠近边界，信号越弱，假设C点为无法继续维持Wifi数据传输的临界点。
Celluar信号覆盖区域为区域3，假定在区域3内都为强信号区域（Celluar的覆盖半径比Wifi大很多，所以这里Celluar的弱信号区域不做标注）
用户开始处于A位置，然后移动到E区域。在A区域的位置，终端基于功耗等考虑，并没有和Celluar建立RRC连接，不占用无线资源。
图二 Wifi切换到蜂窝过程模型
用户开始移动后，到了B点的位置，由于Wifi信号变弱，此时Wifi数据传输的质量开始变差，但由于还没有差到无法传输的地步，所以终端还是会继续以Wifi作为数据传输链路，直至到了C点，终端发现Wifi已经无法维持传输，则开始启用Celluar作为新的传输链路，但如前所述，此时终端和基站之间用于数据传输的无线资源尚未建立，所以必然有一个建链的过程，直至到了D，终端和基站之间的无线链路建立成功，但问题又来了，如果应用是基于TCP的连接方式，应用原本的TCP连接是基于Wifi链路的，此时基于Celluar链路的TCP连接是一个全新的连接，所以需要花一定的时间进行Socket的重建，直至E点在新的链路上恢复。所以从A点移动到E点的过程中，可以认为从B点到E点的用户数据体验都可能是不太好的。
我们定义：
B->C点的时间为T1: 从Wifi信号变差到终端检测到需要采用行动的时间。
C->D点的时间为T2: 重新建立Celluar的无线链路的时间。
D->E点的时间为T3: 应用从Wifi TCP连接切换到Celluar TCP连接所需要的时间。
所以问题的核心变成了如何让T1/T2/T3的时间变最短，同时也要兼顾功耗和成本(包括终端流量开销和网络改造成本)，针对这一问题，比较直观能想到的一种方式就是模仿Celluar不同Cell之间的切换策略，由UE对测量到的Wifi和Celluar信号上报给网络侧，由网络侧进行统一的资源调度(如专利CN104754661所描述的)，但直到现在，Wifi和Celluar之间无线资源统一调度策略都未打通，所以这种方式目前还只停留在理论可行的阶段，并没有被应用到实际的用户使用场景。
随着系统的演进以及应用的更加智能化，目前如果不考虑少许的功耗和网络资源的消耗，基本上T2已经可以认为趋紧于0，相对粗暴的做法就是让Celluar无线资源一直存在，无论终端是否使用，永远作为备用链路存在着。所以这个问题就可以简化为对T1/T3的处理。
三、关键技术
1.链路指标动态评估
在平常使用导航软件的时候，到了分叉路口，导航软件根据拥堵情况，红绿灯数量，路程长度等综合的计算和评估，从而给出更快道路提示，引导用户进行提前的道路切换和拥堵规避，主动选择更快的一条路径通过。
图三 导航软件的道路切换提醒
同样的，我们也可以把Wifi链路和Celluar链路抽象成两条交通道路，通过相关的技术指标，比如应用本身的时延，链路的RSRP信号质量，RTT等信息对当前链路质量和目标链路质量进行评估，而不是等到完全断链才进行链路的重新选择，从而达到T1时间的缩减以及提前准备好数据链路从而减少T2。
图四 链路切换抽象模型
基于链路动态评估是完全的终端行为，不会引入额外的流量和功耗消耗，但其解决不了如下的几个问题：
不同的应用对Qos的要求不一致，很难精确评估切换的时机，换句话说，就是无法使T1等于0。
链路的状况随着用户的移动随时随地发生着变化，容易引起Wifi和Celluar的乒乓切换。
目标链路的状况比较难精确评估，导致切换的目标链路未必是最佳的选择。
2. QUIC(Quick UDP Internet Connection)
对于所有基于HTTP协议的应用来说，由于HTTP是建立在TCP协议之上的，所有 HTTP 协议的瓶颈及其优化技巧都是基于 TCP 协议本身的特性。由于一条 TCP 连接是由五元组标识的（源 IP，源端口，目的 IP，目的端口，协议号），当终端在 WIFI 和 Celluar网络切换时，客户端的 IP 肯定会发生变化，需要重新建立和服务端的 TCP 连接，所以必然会产生T3的额外消耗，而QUIC的连接迁移特性正好可以弥补这一问题。
QUIC是谷歌制定的一种基于UDP的低时延的互联网传输层协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上TCP。QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC融合了包括TCP，TLS，HTTP/2等协议的特性，但基于UDP传输。
图五 QUIC协议架构模型
QUCI的一大技术特点就是连接迁移，就是当其中任何一个元素发生变化时，这条连接依然维持着，能够保持业务逻辑不中断。当然这里面主要关注的是客户端的变化，因为客户端不可控并且网络环境经常发生变化，而服务端的 IP 和端口一般都是固定的。当用户的地址发生变化时，如 WIFI 切换到 Celluar(比如4G/5G) 场景，基于 TCP 的 HTTP 协议无法保持连接的存活（如上所述，IP会引起变化）。
那 QUIC 是如何做到连接迁移呢？很简单，QUIC是基于UDP协议的，任何一条 QUIC 连接摒弃了 IP+端口+协议号的五元组标识概念，而是以一个 64 位的随机数作为 ID 来标识，这样就算 IP 或者端口发生变化时，只要 ID 不变，这条连接依然维持着，上层业务逻辑感知不到变化，不会中断，也就不需要重连，从而提高业务层的体验。由于这个 ID 是客户端随机产生的，并且长度有 64 位，所以冲突概率非常低。
图六 基于TCP和QUIC的链路切换模型
基于QUIC底层技术实现的上层业务，无论应用本身是基于HTTP，TCP还是UDP，都不再有遇到底层链接发生变化后的重建链路的过程，从而可以把T3趋向于零。但QUIC无法解决T1的问题。当然QUIC还有很多其它的技术特性，如：0RTT建链，多流复用，精细拥塞控制，可靠传输等，由于和本文讨论内容无直接关系，不展开讨论。
3. MPTCP(Multipath TCP)
顾名思义，MPTCP是对TCP的扩展演进，允许通信双方同时建立多条TCP连接进行数据传输，充分利用多条路径从而提高吞吐（聚合）或者提高可靠性(冗余)。
图七 MPTCP协议架构模型
从图可以看出，MPTCP是在Socket和TCP层之间增加了一个MPTCP层，MPTCP层之下是多个TCP子流，MPTCP层负责多个TCP子流的建立、管理和数据分发，TCP子流就是普通的TCP。
根据子流的使用情况和包调度策略，MPTCP使用模式一般是如下三种：
Aggregation（聚合）：不同自流传输不同的数据，适用于高吞吐场景
Redundant（冗余）：不同自流传输相同的数据，适用于高可靠场景
Backup（备用）:一些子流设置为Backup（备用）模式，Backup子流默认不使用，只有在没有可用的子流时，backup子流才启用，适用于链路快速切换，高可靠场景。
如下图所示，要配合终端MPTCP的功能，需要搭配支持对应功能的服务器设备，为了最大限度地解决T1~T3的问题，比较好的选择是采用冗余模式，这样需要也同样需要服务器端对收到的数据包进行选择使用，从而实现“1+1 = Strong 1” 的目的。
图八 基于MPTCP数据传输网络模型
当然，使用这种模式，终端的代价也是显然易见的：会有额外的流量开销和功耗开销。再加上需要服务器侧的紧密配合，所以使用场景也相对会受限。
四、小结
综上所述，针对上述几种方案，从以下几个问题比较来看，各有优缺点。实际使用过程中，可以结合实际需求选择最为适合的方法。
当然，随着人工智能技术的进步，如果可以对用户的行动轨迹和使用习惯做出准确的预测，同时结合精确室内定位技术，可以不增加流量、功耗、网路资源的额外开销情况下，来解决不同通信系统之间链路的真正无缝切换。
