CT车外出体检，检查数据怎么传回医院？不能拉线时的5G多链路聚合

“我们有一台 CT 体检车，要开到外面去做体检，检查数据能不能传回医院？现场没法拉线，只能用 5G。”

这是微恩云咨询入口收到的一个很具体的问题。我们的第一反应不是先回答“能”或“不能”，而是先问了一句：一次检查大概产生多大的数据，一天要做多少人？因为“能不能传”和“多久能传完、能不能稳定传完”，是两个完全不同的问题。

这篇文章把移动 CT 车院外体检的数据回传拆开讲：数据量怎么估、单条 5G 的实际表现、多链路聚合到底聚合了什么，以及落地时需要盯住的几个边界。

一、为什么这些数据必须回传

CT 检查产生的断层影像要进入院内影像系统归档，医生在院内工作站上读片、写报告。这条链路本来是闭环的：检查设备 → 影像系统 → 诊断报告。

移动 CT 车把设备搬到了院外，但这个闭环没有跟着一起搬走。数据如果留在车上，通常只剩两种处理办法：

• 车开回医院再拷贝。报告要等车回院之后才能开始写，当天出报告基本做不到；车在路上的这段时间也不能出车体检。
• 用移动硬盘人工搬运。速度受限于硬盘读写和人工，还存在丢失、损坏、交接不清的风险。

所以对院外体检来说，数据回传不是“锦上添花”，而是决定“当天能不能出报告”的前置条件。

再看现场条件：体检车停在大门外、厂区空地、乡镇卫生院院子里，车位一次一换，驻点时间从半天到几天不等。挖沟布线的成本和时间都不成立。这种场景下，无线接入几乎是唯一可选的方式。

二、先算一笔账：一天要传多少数据

讨论方案之前，先把数据量估出来。因为链路要几条、需要什么能力，完全由这个数字决定。

粗略的估算方式是这样：

• 单次检查：一个部位平扫的原始断层数据加上重建图像，量级通常在 100–300MB 之间，扫描范围和重建层厚不同会有明显浮动；多部位或含薄层重建时更大。
• 日均人次：一辆体检车一天按 30–60 人次计，属于常见区间。
• 合起来：一天的总量大致落在 5–20GB 这个区间。

（具体数值以设备厂商给出的单次数据量和实际体检流程为准，建议用自己的真实数据替换这两个参数。）

再把这个总量换算成时间。假设当天要传 8GB：

• 有效上行 10Mbps（约 1.25MB/s）：约需 110 分钟；
• 有效上行 30Mbps（约 3.75MB/s）：约需 36 分钟；
• 有效上行 90Mbps（约 11.25MB/s）：约需 12 分钟。

注意这里用的是“有效上行”，不是测速软件在理想位置跑出来的峰值。实际可持续的上行往往明显低于峰值，这正是下面要说的。

这笔账的价值在于：它把“能不能传”变成了“要在多长的时间窗口内传完多少数据”。窗口越短、数据越多，对上行能力的要求就越高。

三、单条 5G 到底够不够

5G 的上行能力比 4G 强不少，但它有个特点：波动大。

• 位置与遮挡：车体是金属结构，设备舱和车厢内的信号衰减明显。天线装在车顶还是设备舱内，实测结果可能相差数倍。
• 基站负载：体检通常安排在白天，正好是基站相对繁忙的时段。同一小区下的用户越多，可用上行越低。
• 移动中的切换：车辆行驶过程中会跨基站切换，速率会出现抖动甚至短暂中断。
• 套餐策略：不少大流量套餐在达到一定用量后会限速，而持续性大流量上传最容易触发这类条款。

在这些因素叠加下，单条 5G 的持续上行落到 10–30Mbps 属于常见情况，位置好时可以更高，但不建议把好位置的峰值当作规划依据。

按上一节的账：单条链路意味着 8GB 数据要传 40 分钟以上；如果赶上忙时或位置不佳，一两个小时也不奇怪。更麻烦的是稳定性——传到一半掉速或断开，如果方案不支持断点续传，就得从头再来。

所以结论是：单条 5G 能传，但很难保证“在收工前传完”。这正是我们建议用多链路聚合的原因。

四、多链路聚合到底聚合了什么

“聚合”这个词在市场上的用法比较混乱。先把三种常见能力区分清楚，因为它们解决的问题完全不同：

• 主备切换：同一时间只用一条链路，主链路故障时切换到备用。它提升的是可靠性，不提升总带宽。
• 负载均衡：把不同的连接或会话分配到不同链路上。多人同时传文件会更快，但单个大文件的上传速度通常不变，因为它仍然是一个会话、一条链路。
• 多路径聚合：同一份数据流同时经多条链路传输，接收端重组。单条上传任务也能获得多链路叠加后的速率，这才是回传大文件时真正需要的。

不少标着“聚合”的网关实际上只做到了前两种。判断方法很直接：用单线程上传一个大文件，看速率是否接近多条链路之和。如果只有多线程、多设备并发时才快，那它做的是负载均衡，不是聚合。

真正要落地的聚合方案，一般包含三部分：

1. 多条独立链路。车载机箱内插多个 5G 模块，尽量选择不同运营商的卡。同一区域内不同运营商的覆盖与负载分布不同，放在一起能降低“同时变差”的概率。
2. 上行侧的聚合节点。聚合需要在链路另一端有一个接收并重组数据的服务，通常部署在院内或云端，多条链路汇聚到这里再还原成一条数据流。
3. 回院的安全通道。聚合之后的数据要走加密隧道落到医院内网，再与影像系统对接。不要在公网上直接暴露院内影像服务。

举个量级上的例子：三条有效上行各 30Mbps 的链路，聚合后在理想条件下可接近 90Mbps，同样的 8GB 数据大约 12 分钟传完。但实际叠加效率通常低于理论之和——链路速率不均、时延差异大、丢包都会拖累整体表现，因此最终数字必须以现场实测为准。

五、几个容易被忽略的边界

• 上行不能无限叠加：多条链路的总上限仍受运营商速率策略、基站上行资源和套餐条款约束。加链路能缓解，不能突破。
• 多运营商不等于多物理路径：如果几条链路最终走的是同一片区域的同一批回传资源，遇到区域性拥塞仍可能一起变差。
• 天线与安装位置往往比套餐更决定成败：车顶天线、馈线走线、设备舱的散热与屏蔽，都是实测时最容易暴露问题的环节。
• 不是所有数据都必须实时传：可以分优先级，先把当天诊断需要的图像传回，重建数据等收工后或回院后补传。这一招通常能显著降低对上行能力的要求，非常实用。
• 合规要提前确认：医学影像属于敏感数据，传输过程应加密，落点、访问权限与留存策略需要符合医院的信息安全管理要求。这一项应在方案设计阶段就列入，而不是上线前才补。
• 断点续传能力：院外无线环境难免中断，传了一半的大文件能否续传，直接决定这套方案是“能用”还是“难用”。

六、落地时建议按这个顺序推进

1. 现场实测：把车开到常用的驻点，用不同运营商的卡，在真实时间段测试上行，并记录多个时段的数据。
2. 估算总量：按日均人次与单次数据量算出每天的传输需求。
3. 确定窗口：明确是“收工前必须传完”，还是“可以回院后补传”，这直接决定需要几条链路。
4. 确认聚合方式：让供应商说清楚做的是多路径聚合还是主备/负载均衡，并用单线程大文件实测验证。
5. 打通回院路径：完成隧道落点与影像系统的联调，跑通一次端到端的完整传输。
6. 做一次演练：模拟链路断开、基站切换与上传中断，观察业务是否受影响、能否自动续传。

七、下一步

如果你也在做移动体检、移动影像这类院外业务，可以先把这些信息整理出来：日均检查人次、单次检查的数据量、常用驻点位置与当地运营商覆盖、每天可用于传输的时间窗口、院内影像系统的对接方式。

这些信息越具体，方案越容易定下来——要解决的到底是带宽、稳定性还是合规，往往一看就知道。可以通过微恩云官网的咨询入口把这些情况发给我们，先判断你的场景需要几条链路、聚合该做在哪一端，再谈设备选型与实施。