Proactive Migration

这一章涉及到非常多 5G 底层通信协议的专业细节，很容易把人绕晕

因此让 gemini 生动讲解一下

核心目标与困境：给行驶中的汽车换引擎

目标：

你想给系统升级，需要把用户从“旧的基站大脑（源 DU）”无缝转移到“新的基站大脑（目标 DU）”，且用户看视频、打游戏完全感觉不到断网

做法：

手机网络里本来就有“切换（Handover）”功能（比如你从一个基站走到另一个基站）。Atlas 想利用这个现成的功能

困境：

切换是需要时间的。在这个“交接过渡期”，旧 DU 还没完全撒手，新 DU 已经开始接管

这意味着，新旧两个 DU 必须同时通过同一个天线设备（RU）和手机对话

但在现有的 5G 设计里，一个 RU 只能被一个 DU 独占，根本不知道怎么同时听两个大脑的指挥！

如图 3 所示，Atlas 在中间加了一个“智能中间件（Fronthaul NF）”，用来强行让两个 DU 共享一个 RU

为什么简单的共享行不通

如果让两个 DU 共享一个 RU，我们最容易想到的办法有两个，但都不行：

(1) 轮流说话（时间共享）： 这半毫秒旧 DU 说，下半毫秒新 DU 说

失败原因：

5G 规定，基站必须在每一毫秒都发送“控制指令”（告诉手机该怎么做）

如果你让旧 DU 闭嘴哪怕一毫秒，手机就会以为基站挂了，直接断网

(2) 一人一半频道（频率共享）： 100MHz 的频段，新旧 DU 各用 50MHz

失败原因：死板

• 刚开始迁移时，旧 DU 那边还有很多用户，需要大带宽
• 新 DU 那边没几个人

一人分一半会导致旧 DU 那边严重拥堵

Atlas 的天才解法：核心机制

既然简单的轮流和分频道都不行，Atlas 决定把发给手机的信息分成两类

第一类：控制指令

图 4 中的阴影方块 - Checkered boxes

• 特点

  • 这是基站发出的“指挥命令”
  • 它数据量小，而且被设计得极度抗干扰（就像拿着大喇叭字正腔圆地喊话）
  • 但是，它一刻都不能停

• Atlas 的做法：空间维度共享（一人用一个天线同时喊）

  • 既然不能停，那就让新旧 DU 在同一时间一起喊
  • 旧 DU 用天线 1 发射，新 DU 用天线 2 发射

• 代价：

  • 一起喊确实会产生噪音（无线电干扰）
  • 但因为控制指令本身极其“皮实”，手机依然能在噪音中听清指令

第二类：用户数据

图 4 中的字母方块 - Lettered boxes

• 特点：

  • 这是用户真正在下的电影、玩的游戏数据
  • 数据量巨大，而且非常娇气，极其怕干扰

• Atlas 的做法：时间维度共享（严格轮流说话）

  • 既然怕干扰，那就绝对不能同时发
  • Atlas 强制安排它们按时间排队（时间共享）
  • 比如，这一毫秒全部用来发旧 DU 的数据，下一毫秒全部用来发新 DU 的数据

如图:

• 不怕干扰的“控制指令”, 走不同天线同时发
• 怕干扰的“用户数据”, 在不同时间段轮流发

落地实现 Algorithm

上面说的机制，具体是怎么落地的呢？

靠的就是图 3 里那个叫 Fronthaul NF 的“智能中间件”

可以把它理解为一个极其聪明的“流量交警”

1. 处理手机上传的数据 (Uplink)：

   • 手机发来的数据，交警直接复印一份，分别扔给新旧两个 DU
   • DU 自己有脑子，会自动忽略掉不属于自己的那部分

2. 处理基站下发的数据 (Downlink)：

   • 交警会拆开数据包查看：
     • 如果是“控制指令”，且是新 DU 发来的，交警会偷偷篡改标签，强行把它塞到“天线 2”的通道里发出去
     • 如果是“用户数据”，交警就看“红绿灯”（调度策略）
       • 轮到谁的时间，就放谁的数据走，没轮到的直接丢弃或暂存

通过这种“欺上瞒下”的巧妙操作，新旧两个 DU 都以为自己在独占整个基站硬件

而用户也能在毫无察觉的情况下，被平滑地过渡到了新的基站系统上