一、先说说这场赛事为什么通信不好搞9 月 13 日哈尔滨银行 2026 哈尔滨马拉松鸣枪开赛。世界田联精英标牌、中国田协 A 类认证全马半马各 1.5 万人总共 3 万人四枪分批发令。起点音乐公园全马终点太阳岛太阳石广场半马终点世纪大道市政府广场赛道贴着松花江两岸走。赛事本身不多说重点说通信。这场保障拿到手先看清楚三个硬骨头。赛道长地形杂。全马 42 公里多跨松花江。沿江开阔地、高层楼群、跨江桥、隧道口四种地形轮着来。开阔地信号好但人散楼群里多径衰落明显桥上江面反射导致信号飘隧道口直接弱覆盖。传统专网要全线布基站42 公里的工期和成本一次性赛事扛不住纯公网对讲人一多基站就拥塞稳定性说不准。并发峰值猛还不均匀。开赛前半小时起点挤了近 3 万人同一区域几百台终端同时呼叫、上报位置、触发告警公网基站负载瞬间拉满。赛道中段人拉散了单点并发不高但要求 42 公里不断线。终点又聚一次医疗、安保、裁判、后勤全在那交汇。两头高、中间长这种流量曲线对系统弹性要求不低。部门多群组不能混。公安、医疗、志愿者、后勤、裁判、环卫、媒体七个岗位。全塞一个群组里闲聊能把紧急指令淹了。必须各聊各的指挥中心能跨组听、能插播、能全组广播。出事的时候也不能光靠喊得能看到人在哪、一键告警能联动。这三条摆清楚方案选型就有方向了。本次保障选用 LONPTT 公专融合调度方案由黑龙江单工科技负责现场实施和值守。下面按时间线说怎么做的。二、赛前一周42 公里走下来信号数据是踩出来的通信保障的活七成在赛前。开赛前一周团队沿着赛道全程走了一遍每 500 米一个采样点拿测试终端记三大运营商的 RSRP、SINR 和下行速率。踩完按地形分类数据如下表格地形类型采样点数RSRP 均值 (dBm)SINR 均值 (dB)弱覆盖点占比沿江开阔带38-7818.22.6%城市楼宇区22-929.718.2%跨江桥梁4-8512.40%隧道出入口3-1015.366.7%楼群区和隧道口是重灾区最终标了 7 个盲区点位。这 7 个点的处理办法很直接公网为主旁边架便携专网中继补盲单台覆盖半径大概 300 米够把盲区填上。7 台设备半天布完。除了信号还得摸清人。找组委会要了保障人员清单按岗位统计终端数量和部署位置表格岗位终端数量部署方式通信群组总指挥部8固定值守指挥组跨组权限公安安保120起点 / 赛道 / 终点分散安保组医疗急救45沿途医疗站 流动救护车医疗组赛道志愿者200每公里约 5 人巡检组按赛段分 3 个子组后勤补给30各补给站后勤组裁判25起终点 计时点裁判组环卫40沿途分段环卫组总共 468 台终端。这个数字是后面压测并发规模的依据。三、方案怎么搭一张图说清楚的事用文字描述系统架构不复杂分三层。最上层是指挥调度平台。部署在云端双链路接入 —— 主链路用固定宽带备用链路走 4G 网卡主断了备自动切。平台管所有终端的注册、群组、权限、位置、告警调度大屏实时显示终端位置热力图和在线状态。中间层是通信链路。公网为主终端通过运营商 4G/5G 接入平台7 个盲区点位架便携专网中继终端进入盲区后自动从公网切到专网中继出了盲区再切回去切换过程用户基本无感知。最下层是终端。468 台手持终端按岗位预配置群组和权限开机即用。普通终端只能在本群组呼叫指挥组终端能跨组监听和广播。分组用的是 “1N” 两级结构。1 个指挥组在顶层7 个业务组在下层 —— 安保、医疗、巡检、后勤、裁判、环卫、媒体巡检组再按赛段拆 3 个子组。指挥组能听任何组、能插播、能全组广播普通组之间互不干扰。位置上报做了分级。平时 30 秒报一次省电、省平台负载触发一键告警或者进了电子围栏自动改成 2 秒一次指挥中心能盯着人走。一键告警的流程是这样的终端按报警键平台 1 秒内弹告警窗显示谁报的、哪个组的、在哪、周边 500 米有哪些人在线。调度员直接点周边终端的名字就能呼叫不用翻通讯录。传统电话调度从发现到调人大概一分半这套流程压到了 15 秒左右。四、赛前三天压测和故障演练数据不过关不上场方案定了不代表能跑得测。开赛前三天做了两轮压测加一轮故障演练。第一轮并发承载测试。468 台终端全上线堆在起点 200 米 ×300 米的区域里模拟开赛高峰。半小时内每台终端平均每 2 分钟呼一次每次 30 秒位置 30 秒一报。测出来的数据468 台全部稳定在线没掉线峰值同时呼叫 37 路系统上限 64 路余量够语音端到端时延均值 380msP95 是 520ms行业一般 800ms 以内算可接受丢包率均值 0.3%峰值 0.8%2% 以内可接受位置上报成功率 99.7%第二轮盲区切换测试。7 个盲区点位挨个走一遍测终端从公网切专网中继的表现。7 个点全成功切换时语音断平均 1.2 秒最长 2.1 秒人感知是卡了一下不是掉线。故障演练主链路断了怎么办。人为把指挥平台的主宽带拔了看 4G 备用链路多久能接上。2.8 秒切完平台恢复。当时正在进行的 3 路呼叫1 路断了一下自动重连另外 2 路没感觉。双链路冗余这关算过了。测完没问题终端统一充电、预填群组、查按键按岗位分装。赛前一天发设备顺便做操作培训。用设备的人大多是公安、医护、志愿者不是搞通信的所以培训只讲三件事怎么开关机、怎么切群组、报警键在哪。讲多了记不住。五、比赛当天6 小时值守数据和一次真实应急5:30 到起点最后查一遍设备和链路。6 点平台上线终端陆续开机7 点前 468 台全部接入。7:30 第一枪比赛开始。跑了 6 小时核心数据终端在线率 99.1%少数没电的备用电池顶上安保组呼叫量最大全天约 1200 次医疗组约 350 次一键告警触发 7 次全是选手身体不适3 分钟内都完成了就近医疗调度通信链路重大故障 0 次盲区终端掉线 2 次5 秒内自动重连说一次真实的应急处置。32 公里处一名选手身体不舒服旁边志愿者按了一键告警。指挥中心弹窗看到位置直接呼了 1.2 公里外的流动救护车同时通知该赛段医疗站准备接应。从报警到救护车到现场4 分 12 秒。选手后来没大事但这个响应速度是平时电话调度做不到的。值守是两个人轮班一个盯平台看链路和在线率一个在现场跑终端故障和换备件。整场比赛主链路没断过备用链路没派上用场 —— 这是好事。六、复盘哪些做对了哪些下次改公专融合这个选型对一次性赛事是划算的。全线专网布站42 公里的成本和工期不现实纯公网在人堆里稳定性说不准。公网为主、便携中继补盲7 台设备半天布完投入比全线专网低一个数量级效果也够用。这个思路以后同类活动可以直接复用。群组数量有个甜区。这次 7 个业务组加 1 个指挥组468 台终端用下来刚好。组太多超过 10 个指挥中心跨组调度忙不过来组太少五六个以内组里语音打架。这个规模下71 是比较舒服的配置。位置上报分级是对的。平时 30 秒、告警时 2 秒平台负载和终端续航都扛得住。如果全程 2 秒上报平台负载翻 15 倍终端续航少 40%完全没必要。下次要改的地方。一是跨江桥段的时延P95 虽然 520ms但偶尔飘到 700ms 以上下次在桥上多加一台中继应该能压下来。二是终端电量高呼叫量的岗位安保组有人到后半程电量紧张下次直接给这些岗位配充电宝别等没电了换电池。三是培训可以再精简现场还是有人找不到报警键以后把报警键贴个红标比讲十分钟管用。七、写在最后这场保障做下来最大的感受是通信保障这活做得好的时候没人注意到你因为一切都顺出问题的时候所有人都找你。所以核心目标就一个 —— 别出事。从赛前 42 公里踩点到 468 台终端压测再到比赛当天 6 小时值守整套流程跑通了。数据摆在这该改的地方也列出来了。国内城市马拉松、文旅集会这类活动越来越多临时大型活动的通信保障需求只会增不会减。公专融合这个路子部署快、成本可控、稳定性有保障适合这类场景。希望这篇复盘里的实测数据和踩过的坑对同行有用。素材来源新华网、央广网 2026 哈尔滨马拉松公开赛事报道通信保障数据来自现场实施记录。