简介一份面向Com-Way通信全网融合仿真系统使用者的PDF操作指南适合学员、授课教师、安装维护经理和市场销售人员阅读旨在帮助用户掌握设备安装与后台配置的核心操作。文档从主界面操作讲起系统说明机房、楼顶、铁塔三类场景中的3D仿真安装流程包括增加机柜、设备、单板、配线架接口连线、设备上电以及GPS、RRU部署和天线调整等关键环节并同步介绍教学资源、考试系统和个人中心模块方便教学培训与实际项目练习。资源为单个PDF文件大小约5.95MB目录结构完整图文对照清晰既可作课程实训教材也可作售前演示与售后维护的速查手册。已有590人浏览学习对于需要快速上手该仿真平台的人员而言是一份直接可查的操作参考。1. 把 Com-Way 当成一套能跑通的通信实验环境而不是一个 PPT 产品第一次打开 Com-Way 通信全网融合仿真实验系统的人很容易被界面上一堆拓扑节点、链路标签和参数面板劝退——看起来像网管软件用起来又像协议模拟器定位模糊。但如果你把它放到「通信全网融合」这个语境里看它的真实角色就清晰了一个把核心网、接入网、传输网、业务网统一放进同一张仿真拓扑、用同一条事件总线驱动信令和业务流的实验平台。换句话说你不需要同时部署 open5GS 模拟核心网、用 ns-3 仿无线侧、再拿 Wireshark 去看协议交互Com-Way 把这些环节收拢到一个操作界面上重点解决的是「全网业务端到端打通」这件事。这篇内容面向两类人一类是刚拿到系统、连拓扑都拖不出来的初学者另一类是已经跑过几个实验、但卡在参数调优和异常定位上的工程师。前者需要一份能照抄的操作路径后者需要知道每个参数背后对应真实网络中哪个实体。下文所有步骤都基于 Com-Way 常见版本的操作逻辑具体菜单名称在不同版本里可能略有差异但层级关系和配置思路是通用的。建议你边读边开系统跟着最小实验先跑通一次再回头看参数细节。能从一张空画布走到业务通你对这套系统的理解就超过大多数只看过演示的人。2. Com-Way 的仿真骨架全网融合到底融的是什么2.1 从网元类型看融合边界接入、承载、核心、业务四层一次建模Com-Way 里新建实验的第一步是选网元库。很多初学者直接拖「基站」「交换机」「服务器」这些图标拖完发现连不上因为没搞清楚这个系统里网元是按什么粒度建模的。Com-Way 的网元粒度不是「一台设备」而是「一个功能域」。常见的主类型分组如下分组典型网元对应真实网络实体可配置的关键项接入域eNB/gNB、AP、OLT、ONU无线基站、WLAN、光纤接入覆盖半径、带宽、用户数、切换门限承载域交换机、路由器、PTN、OTN城域/骨干传输设备队列策略、链路速率、时延抖动核心域MME、SGW/PGW、HSS、IMS-CSCFLTE/5G 核心网控制面与用户面信令超时、重传次数、注册周期业务域应用服务器、数据库、PBX语音、视频、消息类业务平台服务端口、编解码类型、码率这个分组的价值在于它强迫你按「端到端视图」搭建实验而不是像协议仿真器那样只关心某一段。比如你只研究 LTE 附着流程传统做法是单独拉 eNB、MME、HSS 三个节点但在 Com-Way 里你会在同一张拓扑上同时放业务服务器和传输节点因为系统默认所有节点共享一套时钟和事件调度任何一段链路的拥塞都会真实反映到上层业务指标上——这正是「全融合」的含义不同技术域在同一个仿真内核里互相影响而不是各跑各的再拼接结果。注意一点Com-Way 的网元图标可以在画布上重叠或紧贴放置而不会自动报错新手很容易把所有节点堆在一起导致后续链路建立时选了错误的端口。我习惯的做法是先把画布按网格对齐顶部工具栏的「对齐排列」再按接入-承载-核心-业务从左到右布局这样后面排查链路状态时能一眼看出数据流方向。2.2 事件调度机制为什么业务通了信令却可能在排队Com-Way 的仿真内核采用离散事件驱动不是实时模拟。这意味着你看到拓扑上链路通、节点在线不代表所有消息都按时到达。系统内部维护一个全局事件队列每个消息信令或用户面数据都会被打上时间戳压入队列仿真时钟按事件先后推进。这个设计的好处是结果可复现、可回溯坏处是如果你把事件调度参数设得过于激进比如事件批处理量过大高优先级信令可能被大量业务数据挤压出现「业务通、信令慢」的假象。在实验属性面板里有两个参数直接决定这个行为事件扫描间隔默认 1ms每次从队列取出事件的最小时间片。设得越小时序越精确但仿真速度下降。调优建议室内小规模实验保持默认跑多小区切换这类大批量事件场景时先调到 5ms 跑通逻辑再回 1ms 出正式数据速度能差出 5 倍以上。最大批处理数默认 1000一个时间片内最多处理的事件数。如果某个时刻事件数超过这个值超出部分进入下一个时间片。这个参数很容易被忽略但它直接决定高并发场景下是否丢事件。当你发现某个 UE 的信令交互突然中断、而链路状态显示正常时先看批处理数是不是被业务流量打满了。所以你在做实验时不要把「网络通」直接等同于「实验成功」。Com-Way 里有独立的「事件监视器」可以按网元和消息类型过滤查看事件时序。我每次跑完核心网注册类实验都会先过滤 MME 收到和发出的事件确认 Attach Request/Response 在时间轴上成对出现再去看业务层指标——这一步能过滤掉至少一半的假性失败。另外如果你需要和其他工具比如真实的 Wireshark 抓包文件做比对可以在全局设置里打开「事件导出」把仿真过程导出为标准 PCAP 格式。导出的 PCAP 里每个分组的源目 IP 和端口与拓扑配置一致方便你复用现成的协议分析经验不需要重新学一套抓包语法。3. 从零跑通一个全网业务最小实验的可抄作业路径3.1 拓扑搭建的最小操作链节点、链路、接口三段式配置下面这套操作基于「用户通过 LTE 接入访问内部业务服务器」的典型场景覆盖接入、承载、核心、业务四层是你能遇到的最简单但仍算「全网」的实验。先新建实验命名建议带日期和场景比如attach_voice_20250101避免后面多个实验分不清参数。第一步从左侧网元库拖入以下节点1 个 eNB接入域1 台交换机承载域1 套「LTE 核心网组合网元」——如果你用的版本里没有组合网元就分别拖 MME、SGW、PGW、HSS 四个独立节点1 台应用服务器业务域第二步建立链路。Com-Way 里链路不是简单拉一条线而是先选中源节点端口、再选目标节点端口。双击源节点打开端口面板选中一个空闲端口后单击目标节点系统会弹出链路参数窗口。这里最关键的参数是「链路类型」默认是 Ethernet但 eNB 到交换机之间建议改为「IP over Ethernet」并指定 VLAN ID——如果不指定后续配置业务路由时会因为二层广播域过大而出现 ARP 风暴虽然不是致命错误但会让实验日志刷屏影响排查。第三步配置每个节点的必填参数。双击节点打开配置面板常见必填项如下eNB小区标识PLMN Cell ID、频点、覆盖半径。PLMN 用默认值即可Cell ID 必须唯一否则 UE 无法选择这个小区。MME关联 HSS 地址、本机名称。地址可以直接从拓扑上选不用手输 IP这是一个容易踩坑的点——手输 IP 时如果和端口绑定的网段不一致后面 SCTP 链路会一直处于 down 状态。SGW/PGW配置 PDN 类型IPv4、APN 名称。APN 必须和 UE 侧请求的 APN 一致否则附着会被拒绝。应用服务器监听端口比如 8080、服务类型HTTP/FTP/语音任意选一个实验目的不同。配置完成后先做连通性预检菜单「工具」-「连通性检测」系统会给所有已建链路打一个状态标记。绿色代表物理层和链路层已通黄色代表链路通了但配置不完整最常见的是 IP 没配或端口未启用红色代表链路失败。大多数拓扑搭完都是黄绿混合不用慌继续往下配。3.2 UE 与业务配置用终端脚本把业务数据注入仿真拓扑和链路配好后还要至少添加一个 UE。UE 在网元库的「终端」分组下有的版本叫「用户设备」。拖入 UE 后需要把它通过无线链路关联到 eNB——选中 UE选择「接入」操作再点 eNB这时系统会自动建立无线承载。注意与有线链路不同无线接入不需要指定端口但需要选择「初始接入理由」常见两个选项附着 PDN 连接请求最常用覆盖注册和建立默认承载的完整过程仅小区选择只测试无线侧接入不涉及核心网适合先单独验证无线配置如果想快速验证全网是否打通可以直接导入预置的 UE 脚本。在 UE 配置面板的「业务脚本」页签里选择系统自带的data_udp_test脚本模板它会在自动附着成功后向配置的目标服务器地址发送 100 条 UDP 数据包每条间隔 1 秒。这个脚本的好处是它内部包含了等待附着完成的逻辑不需要你手动去控制时序。导入后脚本面板长这样# Com-Way UE 业务脚本简化示例 import comway_ue as ue def on_attached(ue_ctx): server_ip ue_ctx.config[server_ip] server_port int(ue_ctx.config[server_port]) payload ue_ctx.config[payload] count int(ue_ctx.config[packet_count]) for i in range(count): ue_ctx.send_udp(server_ip, server_port, payload) ue_ctx.sleep(1)这段脚本是示例性质理解重点在两点on_attached是系统提供的回调接口附着成功后被触发send_udp会阻塞执行直到报文真正下发到无线承载返回值里带有一个tick字段表示该报文在仿真时钟上的发送时间戳。你可以把它打印出来用于后续确认端到端时延。实际使用中脚本面板可直接写不用引入额外依赖写好保存后点「运行」UE 会自动开始接入流程。脚本里ue_ctx.config是从 UE 配置面板读取的键值对所以我在配置面板里把服务端口和报文长度都抽出来放这儿而不是写死在脚本里——这样如果想比较不同报文长度对时延的影响只需要改配置面板不用改脚本逻辑。3.3 跑通后最先盯的三个实验指标点击「开始仿真」系统进入运行状态。对于这个最小实验你先把「运行速度」调到 10 倍速仿真时间推进约 10 秒后暂停查看三个位置第一UE 状态面板。正常情况下 UE 状态会从「空闲」变为「已附着」并显示分配的 IP 地址。如果长时间停在「发起附着」优先检查 HSS 里 UE 的 IMSI 是否和 UE 节点一致——预置模板通常一致但自己添加 UE 时很容易因为复制节点导致 IMSI 重复。第二MME 状态面板里的「信令负荷」曲线。这个曲线表示 MME 单位时间处理的事件数。正常附着过程会出现一个短脉冲然后归零。如果曲线持续有值且伴随错误事件计数上升多半是 HSS 响应超时这时去看「消息追踪」窗口对比 HSS 是否收到了来自 MME 的请求。第三业务统计视图里 UDP 报文的收发计数。发送与接收计数相等代表全网业务打通。如果发送大于接收说明丢包接着要看丢包发生在哪一段——Com-Way 支持在链路上右键选择「查看报文统计」每个方向都会显示通过该链路的报文总数逐段对比就能定位丢在接入侧还是核心侧。这个最小实验做完你已经覆盖了「搭建-配置-运行-观察」的完整闭环。接下来所有的复杂实验——多小区切换、拥塞控制、业务优先级调度——都是在这个骨架上增加节点和策略底层逻辑不变。4. 需要动手改的参数从默认到可用再到最优4.1 链路与队列参数时延抖动主要靠这两项调跑通最小实验后再复杂的场景本质上都是在这四层结构上加节点、加链路。但真正让实验结果从「能通」变「可信」的是参数调整。初学者容易陷入一个误区追求参数极值比如把带宽设成 100Gbps、时延设成 0结果实验永远不丢包、不排队看起来完美但没有任何参考价值。仿真实验的意义在于逼近真实约束所以下面几个参数才是你该花时间调的。首先是链路速率。Com-Way 默认新建链路速率按网元类型自动匹配eNB 到交换机的无线侧常见是 100Mbps交换机到核心网侧常见是 1Gbps。这个默认值在大多数实验里够用但如果你要模拟拥塞就需要手动把某一跳降低。比如你把 eNB 到交换机的链路改成 5Mbps 而业务速率是 10Mbps队列就会开始缓存——这正是你想要的拥塞效果。其次是时延和抖动。双击链路在弹出的属性窗口里会看到「传播时延」和「抖动范围」两项。真实网络中这两项由物理距离和节点处理能力决定仿真里如果不设置默认按 0 处理。具体建议如下场景传播时延设置抖动范围说明本地有线实验1-2ms0ms模拟同机房设备互联城域范围5-10ms1ms模拟同一城市不同区广域互联20-50ms2-5ms模拟跨省或跨运营商卫星链路250ms10ms特殊场景可观察长时延对 TCP 的影响最后是队列长度。链路属性里的「队列深度」默认按带宽时延积自动计算一般不用改。但如果你的拓扑里同时跑多个业务而且发现某个业务出现周期性丢包我建议往小了调——比如设成默认值的 50%目的是提前触发拥塞以便观察 QoS 调度策略是否按预期工作。永远不要让队列无限长否则丢包率始终是 0拥塞控制的实验结果就没有区分度了。4.2 信令超时与重传参数别让仿真的「耐性」掩盖真实问题核心网网元的信令参数是另一个值得细调的地方。Com-Way 里 MME、HSS 这些核心网元都带有一组「定时器」配置映射到真实 3GPP 协议里的 T 系列定时器。常用几个如下T3410UE 发起 Attach Request 后等待 MME 响应的时间默认 15 秒范围 5-30 秒。这个值设得太短仿真时钟较慢时可能导致 UE 误判 MME 无响应而重发设得太长又会拖慢故障场景的仿真速度。我的建议是快速验证用 5 秒正式实验用 15 秒。T3413或对应版本里的 TAU 定时器周期性位置更新间隔默认 30 分钟。如果你想在单次仿真里观察多次 TAU 流程可以把仿真加速倍数拉高或者在参数里临时改短到 2 分钟——但注意改短只是为观察流程实验结论里不能把这个短值当成真实网络场景数据。SCTP 重传次数与重传超时如果核心网内部网元之间用 SCTP 承载信令常见于 MME 与 HSS 之间重传超时默认 1 秒、最大重传 5 次。模拟信令面故障时我把重传次数改成 2同时把超时改成 500ms——这样故障导致信令失败的仿真时长缩短能更快看到结果。调这些参数之前先想清楚实验目的。如果你测的是「网络正常时业务能通」这些定时器全部保持默认如果你测的是「MME 故障时 UE 是否能及时重选」那就把 T3410 缩短同时在仿真中途用「故障注入」功能手动关闭 MME 节点。用仿真工具最大的优势是你可以反复调整定时器观察不同行为这在真实网络上几乎不可能安全地做。4.3 业务模型参数区分「简单排包」和「真实业务特征」Com-Way 的业务节点不只是收发数据包它还支持配置业务模型。在应用服务器的「业务配置」里你可以选择加载固定速率模型或随机模型。默认是固定速率每秒发固定数量的包。但真实网络里的业务是突发的所以我建议至少做两个版本的实验模型 A固定速率 5Mbps用于验证全网基本连通性模型 B模拟 HTTP 业务请求间隔满足泊松分布、页面大小满足重尾分布用于观察缓存和时延波动切换模型时注意「流数量」这个参数。如果你把流数量设成 1即使走随机模型也只会有一条连接在跑拥塞现象不明显通常设成 10 条以上让流量在队列中交织排队效应才会在时延指标上体现出来。另外业务流的方向不要只配下行。很多实验只让服务器向 UE 发数据忽略了 UE 上行。在真实网络中上行和下行经过的链路与调度策略不同特别是无线侧所以你应该在业务配置里同时勾选上行和下行两个方向然后对比两个方向的平均时延——经常能发现下行拥塞而上行正常这对应真实网络中下行带宽抢占的场景对于理解 QoS 调度非常有帮助。5. 故障注入与验证让实验结果可信的进阶操作5.1 用断链和节点失效验证业务容错能力跑通了正常场景下一步应该练习故障注入。Com-Way 的「故障注入」模块在工具栏的扳手图标下支持链路中断、节点宕机、链路劣化增加丢包和时延三类操作。最常见的实验是链路中断后观察业务恢复时间。操作路径仿真运行中右键点一条链路选「故障注入」-「物理链路中断」中断时长设 10 秒然后开始仿真。系统会在第 10 秒切断链路并在你设定的恢复时刻自动恢复。此时你需要在业务统计视图里记录「业务中断时间」——从第一个丢包到第一个成功重传的报文之间的仿真时间差。这个数值就是该拓扑下业务的恢复时间。关键细节断链前最好先让业务稳定运行几秒不要一开始仿真就注入故障。比如你先让 UDP 业务跑 5 秒确认收发计数同步增长再断链否则你无法区分业务中断是链路故障导致的还是初始建立阶段本身就没成功。建议每一步都记录当前仿真实机时间方便后续对齐事件。链路劣化实验更有意思。不要直接断链而是把链路丢包率设为 5%、时延加大 10ms观察 TCP 业务的吞吐变化。你会发现 TCP 吞吐下降远不止 5%——因为丢包触发拥塞窗口减半重传进一步加剧时延整体吞吐可能降到原来的 60%。这个结果用来解释「丢包对 TCP 性能的非线性影响」非常直观也是面试时可以讲的实打实数据。5.2 事件序列表定位「业务通但指标异常」的通用排错法故障注入后如果业务没有恢复或者恢复了但指标不对靠肉眼看拓扑是不够的。Com-Way 的「事件回放」功能会把每次仿真运行的所有事件记录到时间轴上包括每个报文从源节点发送、到达中间节点、到达目的节点的三个事件点。回放时顶部有一个时间游标拖动游标可以逐事件推进每条事件记录显示所属网元、消息类型、源目地址、当前时间戳。排错顺序我一般这样走先按「消息类型」过滤掉业务数据报文只看信令事件找到第一个失败或被丢弃的信令双击展开它的完整路径在路径上确认它停在哪一跳——停在源节点多半是本机配置问题停在中间节点去看该节点接口状态停在目的节点但没响应则多半是目的节点处理能力或协议栈异常这个方法百试百灵比逐个网元翻日志快得多。有一次我遇到 UE 附着成功但业务不通的诡异问题用事件回放看到 MME 后的一条 GTP-U 报文在 SGW 处被丢弃检查发现 SGW 的隧道表没建立——因为之前手动改过 S GW 的 APN 配置和 PGW 上配置不一致。这种问题看节点日志很难定位事件回放几乎是一步到位。5.3 用批处理脚本跑参数扫描调优结果的唯一靠谱验证方式「最优参数」到底哪个最优不能靠感觉要靠对比。Com-Way 支持命令行批处理启动可以用脚本跑多组参数的对比实验。核心命令如下# 批处理参数扫描简化示例 # 参数占位符假设系统支持按实际版本文法调整 comway-cli run experiment_15s.yaml --output ./result_fast --queue_depth 50 comway-cli run experiment_15s.yaml --output ./result_slow --queue_depth 100实验配置文件用 YAML 描述关键字段包括拓扑文件路径、仿真时长、业务脚本、需要采集的指标和输出目录。跑完后对比输出目录里的summary.json不同版本字段名可能不同重点看三个字段avg_latency_ms、packet_loss_percent、throughput_mbps。多组数据放在一起折线图对比最优参数一目了然而不是拍脑袋。这种批处理方式也适合给团队做回归验证修改底层协议栈后把以前跑过的 topo 全部重新跑一遍对比历史指标任何退化都会在 summary 中暴露细节。实验要可信就要用自动化方式让结论可以复现。6. 把 Com-Way 的仿真数据导出成可复现实验结论的三种做法仿真实验做完最终要沉淀成别人能看懂、能复核的结论。Com-Way 提供了三种导出方式对应不同使用场景建议按需组合使用。第一种是场景快照导出。菜单栏「场景」-「导出快照」会把当前拓扑、网元配置、链路参数全部打包成一个.cwscn文件具体后缀以版本为准。别人拿到这个文件后直接打开就能复现你的完整实验环境不需要手动补配任何参数。这个做法尤其适合做技术支持排查你本地复现不了对方的问题就让对方把场景快照发过来问题定位效率提升明显。导出快照前先确认所有节点名称没有中文和空格——有些版本的跨平台兼容性对文件名比较敏感中文名可能在后续复核或转场景时乱码。第二种是报告导出。在结果分析面板点「生成报告」系统会把当前实验的拓扑截图、关键参数表、统计图表、事件列表汇总成一个 HTML 文件。默认生成的报告包含所有统计项会比较冗长建议在「报告模板」里取消勾选节点级明细只保留你关注的三四个指标图这样报告可读性高很多分享给同事或用在做实验记录都更合适。报告里的图表是真数据渲染的不是示意所以项目汇报时可以直接用但记得在图题下方加一行仿真时钟范围免得被追问时间尺度时答不上来。第三种是原始指标导出到 CSV适合还需要二次数据分析的情况。在「统计结果」面板选择需要导出的指标支持多选点「导出数据」得到一个标准 CSV 文件。我在做队列长度与时延关系这类观察实验时通常导出全部指标然后写一个小脚本算 95 分位时延——Com-Way 默认只展示平均值和中位数但真实网络优化中 95 分位或 99 分位时延比平均值更有参考价值。示例脚本思路如下import pandas as pd df pd.read_csv(latency_data.csv) p95 df.groupby(queue_depth)[end_to_end_delay_ms].quantile(0.95) print(p95)脚本里先用groupby按队列深度分组再对每组算 95 分位值。这样做可以把不同参数下的尾部时延差异暴露出来而只看平均值的话几个长尾点会被大量正常数据稀释掉结论就容易偏乐观。最后提一个容易被忽略的实践无论用哪种导出方式每次实验跑完立刻做好文件命名。只写experiment1这种名字三天后回来你自己都不知道跑的是什么参数。我自己的习惯是命名带关键参数摘要delay_q50_latency2ms_trace1.csv或者snapshot_congestion_queue100_20250101.cwscn文件名本身就是这次实验的可读索引。这样积累一段时间后回看你能从文件命名里直接还原整个实验矩阵不依靠记忆。本文还有配套的精品资源点击获取