简介《中国联通宽带网络核心网BNC技术白皮书》由中国联通于2024年7月发布联合华为、中兴、新华三及诺基亚贝尔等厂商共同编写面向电信运营商、网络架构师和宽带技术研究人员系统阐述固定宽带网络向BNC架构演进的背景、愿景与实施路径。资源为PDF格式共1个文件压缩包大小1.84MB便于阅读留存已有455人学习下载。白皮书详细分析了宽带业务新机遇与新挑战指出现有固定网络架构存在的问题并提出BNC总体架构设计涵盖管理面、控制面、用户转发面及智能算力底座。同时重点解读转控分离、服务化架构、信令化业务控制、用户永远在线、内生网元智能等关键技术。读者可从中快速掌握联通BNC技术体系的核心思路为网络重构、业务一体化运营及技术选型提供权威参考。1. 宽带网络核心网BNC是什么先搞清这份白皮书要解决谁的难题宽带用户晚上8点刷4K视频卡顿、游戏间歇跳延迟装维师傅排查一圈OLT光功率正常、光猫收光正常最后把问题落在一台已经扛了三年的BRAS上——CPU常年高位会话表接近打满。这类问题不是某一台设备坏了而是宽带网络核心网里的控制逻辑长期绑定在转发设备上带宽一提速控制面先顶不住。BNC宽带网络核心网是联通在宽带网络架构演进里提出的一个方向把散落在BRAS/OLT上的用户会话、地址管理、策略控制收拢成一张独立的网络转发资源池化、策略统一下发、用户状态全局可见。这篇笔记面向想搞清BNC是什么、怎么实施、坑在哪的从业者按一线落地视角把方向拆透。2. 为什么BNC被提出来现网瓶颈不在带宽在控制面2.1 宽带提速后最先扛不住的往往不是转发是“会话管理”近几年的宽带提速从百兆到千兆运营商光模块、OLT、ONT都跟着换唯独BRAS常常被保留。原因很简单BRAS承担的事情太多——终结PPPoE会话、分配IP地址、执行QoS队列、复制组播流、配合AAA做认证。转发本来可以靠硬件流水线扛住但会话管理是状态型任务每来一个新用户上线都要建表、认证、分配地址这些步骤会消耗CPU。当单台BRAS承载的在线用户达到几万晚高峰再加一批新装用户上线CPU使用率就可能冲到85%以上。这时候再谈“扩带宽”瓶颈不在端口速率而在控制面的处理能力。扩容的传统做法是换更大的BRAS整机或者插板卡。主流厂商的现网BRAS一般都有对应的扩容板卡但问题在于扩容一次要规划板卡、割接窗口、回退方案工程周期按月算。更尴尬的是忙时资源紧张只在晚上8点到11点其他时段设备大量闲置。为了峰值换整机等于为了一个月几百小时的高峰买了一台常年吃灰的柜子。这是BNC要解决的第一类问题控制能力不能靠堆硬件解决应该收拢成可伸缩的资源。第二类问题是地址池。传统宽带网里地址池按BRAS划分每台BRAS管自己的一个或多个网段地址利用率完全靠人工估算。有的区域新用户增长快地址池提前耗尽另一台BRAS的地址池却还剩一半没人用。到了IPv6双栈阶段逐台BRAS配置前缀、逐台下发路由配置量翻倍出错率也随之上升。第三类问题是策略。现网里对游戏、视频、办公的差异化保障基本靠静态模板模板绑定在BRAS端口上一旦用户换了接入位置或流量行为变化策略不会跟着走。这三类问题有一个共同点都不是带宽不够而是“控制逻辑放错了地方”。2.2 转控分离BNC立身的技术内核把控制和转发分开在移动核心网里已经是成熟做法宽带接入网却一直在沿用转控一体的BRAS。这里的核心差异在于状态归谁管。传统BRAS里一个用户的上线状态、IP地址、QoS策略都存在这台设备本地设备挂了会话全丢用户只能重新拨号。转到BNC模式后控制面负责会话建立、地址分配、策略计算用户面只负责按规则转发流量。用户面可以做成资源池多台用户面设备共享一个控制面。一旦状态从每台设备本地挪到控制面有两个直接收益。第一转发资源可以按忙时闲时伸缩晚高峰给BNC用户面池临时加一台转发设备凌晨再下线不影响控制面。第二会话可以在用户面之间迁移一台用户面设备检修时在线用户不感知或少感知切换。这种能力的本质是把宽带从“设备级高可用”提升到“网络级高可用”。我用一张对照表说明传统BRAS与BNC模式在部署和运维上的差别对比维度传统 BRAS 模式BNC 模式设备职责控制与转发绑在一台设备控制面集中、用户面池化扩容方式更换整机或加插板卡停机割接用户面资源池水平扩展增量加载会话状态保存在本机断网即丢集中式保存支持跨用户面迁移业务策略CLI逐台下发各自独立控制面统一下发全网一致故障影响面单台BRAS故障影响其全部用户单台用户面故障会话可迁移至他台地址池管理按BRAS静态划分利用率低控制面统一管理动态分配这张表是理解BNC价值的关键。做网络规划时先别急着看设备参数先想清楚状态和策略归谁管很多选型问题会自然化解。2.3 “核心网”三个字的分量从单点设备转向一张网络BNC为什么叫“核心网”而不是“智能BRAS”或者“云化BRAS”因为它的前身就是业界常说的转控分离BRAS但BNC强调的是网络视角。在传统语境里BRAS是接入网的边界设备在BNC语境里控制面成为一个独立的网络功能用户面是池化的转发资源两者之间用标准协议通信对外表现为一张完整的宽带核心网。这和移动核心网的概念一致核心网负责用户状态和业务控制接入网负责信号和流量承载。理解这一层才能明白为什么这份白皮书值得关注。它不是在介绍一款新设备而是在重新划分宽带网络的功能边界。哪些能力必须留在网络边缘哪些能力上收到核心侧是BNC方案里反复出现的取舍。边缘保留低时延的本地转发和组播复制核心承担全局的会话和策略管理——这是BNC架构里一条清晰的主线。下一章按这条主线拆解控制面、用户面、策略与边缘四个业务面的分工。3. BNC白皮书里的四大分工控制、转发、策略、边缘怎么划界3.1 控制面集中化从“一箱设备”到“一组服务”BNC里最先集中的是控制面。用户的PPPoE拨号、DHCP请求到达用户面后被封装成会话信令转发给控制面处理。控制面完成认证、授权、地址分配后把转发规则下发到用户面用户面按规则执行。这个流程的好处是用户上线动作不再依赖某台具体BRAS的CPU而是由控制面集群统一承接。控制面的容量参数是规划重点。常见做法是建一个控制面集群按并发会话数、每秒新建会话数和状态同步时延三个维度评估。并发会话数决定集群规模每秒新建会话数决定忙时用户集中上线是否丢包状态同步时延决定故障倒换时用户感知。我一般会用一张参数表对上线的需求做测算参数项说明建议取值/测算方式并发会话数全网在线用户总数按峰值在线用户×1.3余量每秒新建会话数忙时上线速率取一周中最高15分钟均值×2状态同步时延控制面与用户面状态对齐时延建议不超过200ms会话建立完成时延用户体验到的拨号耗时目标控制在1s以内这里的核心原则是新建会话的峰值余量一定要给足。宽带用户有非常明显的“晚高峰上线风暴”晚上7点到9点大量用户下班回家开机新建会话速率比白天高出一个量级。如果按日均值配控制面必然在晚高峰出现拨号失败。这也是为什么BNC控制面适合做成集群而不是单机——集群可以在风暴到来前弹性扩展。3.2 用户面池化把转发资源做成“可流动的水”用户面是真正干活的转发平面。在BNC架构里用户面设备可以在一个区域内多台组池控制面根据用户面负载、带宽占用和用户位置把业务分配到合适的转发设备上。用户面之间保持会话状态同步这样即使某台用户面故障正在观看视频或进行语音通话的用户也能在秒级切换到另一台业务不中断。用户面规划主要看转发时延、并发会话承载和会话迁移能力。转发时延关系到业务体验普通网页浏览可以接受10ms级时延在线游戏和视频会议对时延和抖动的要求更高。并发会话承载是用户面的基本指标但比容量更重要的是会话迁移能力当用户面的承载超过阈值时系统能把一部分会话平滑迁移到空闲设备而不是直接拒绝新用户。对于IPTV这类组播业务用户面要保留组播复制能力但复制点不能随便上收。常见的做法是让组播复制留在OLT或智能网关侧用户面只按控制面下发的组播策略放行和复制。这个边界如果划错直播流量会在核心网里重复复制多份白白占用大量带宽。组播在边缘、单播在核心是BNC用户面规划里一条很重要的经验。3.3 智能调度从静态QoS到按应用动态保障传统BRAS的QoS策略是静态的按接入端口配置上行下行带宽再按优先级简单分类。视频、游戏、办公流量混在一起忙时互相抢占体验好坏只能靠“碰运气”。BNC把调度策略收到控制面后可以基于应用识别DPI结果做动态调度用户面按策略执行队列调度。一张典型的调度参数表长这样参数项场景取值说明队列数量48条按业务分类游戏、视频、语音、普通上网游戏队列带宽权重高低带宽占用、低时延丢包敏感视频队列带宽权重中高按码率预留带宽可容忍一定丢包语音队列时延目标50ms以内对抖动敏感普通上网队列带宽剩余带宽共享不设硬性上限但动态限速这个方案的实质是把“一刀切”的限速变成“按应用画像分别保障”。对运营商来说这既是体验提升工具也是差异化经营工具——热门的云游戏、高码率视频会议可以单独做服务等级保障。对从业者来说调度策略的落地难点在DPI识别的准确率和队列参数调优这两块都需要现网数据反馈迭代。BNC白皮书如果落到实操应该会建议先从固定的、可识别的场景如视频、会议软件做起不要一开始就做全网全应用识别那样调参周期会拉得很长。3.4 边缘协同OLT、智能网关与BNC的划界标准BNC不是把边缘功能全收走。接入侧保留大量本地处理才能保证低时延和低成本。一个典型的划界清单功能归属理由PPPoE/DHCP终结BNC控制面会话状态全局统一组播复制OLT或智能网关避免核心重复流量本地分流智能网关/OLT内网互访不回核心应用识别与调度策略BNC控制面统一计算用户面执行策略全局一致地址分配BNC控制面全局地址池利用率这条划界逻辑在现网实施时会遇到很多争议特别是“本地分流做到什么程度”。做深了运营商可能失去对一部分流量的可视性做浅了核心网压力大。我的建议是先从流量可视性出发本地分流只做明确的内网互访场景其他流量先回BNC等流量模型跑顺再逐步下放。4. BNC实施路径从现网到核心网化的三步走与四条必看参数4.1 第一步流量画像与容量模型先把账算清楚BNC不是采购完设备就能上线前期最容易被忽略的是流量画像。我见过的失败案例里相当一部分是因为没有摸清现网会话模型就开干。正确做法是先选一个样本城域网部署流量采集连续观测一到两周重点统计在线用户数峰值、新建会话速率峰值、PPPoE与DHCP用户占比、平均在线时长和流量流向。这组数据用于回答几个问题BNC控制面集群要配多大的并发能力用户面池需要多少转发资源地址池集中后会不会与现网路由冲突把这些数据填入容量测算表再乘以1.3的余量系数才能作为采购依据。画完流量画像后还要在仿真环境里验证模型。常见做法是用现网的会话特征生成模拟流量跑一遍BNC控制面和用户面观察目标参数是否达标。这一步不需要真实用户流量但能暴露配置层面的明显问题成本远低于割接后返工。4.2 第二步单一BRAS域试点控制面和用户面一起切容量模型跑通后找一个现网BRAS域做试点。试点目标不是“验证设备能不能用”而是“验证转控分离后业务表现与现网一致”。操作上把试点BRAS的PPPoE会话终结能力切换到BNC控制面流量转发切换到BNC用户面原BRAS保留作为回退路径。割接窗口选在凌晨业务低峰按用户比例灰度切换先切5%再切20%最后全量。试点期的必看参数有四条上线成功率、掉线率、时延和组播频道切换时延。上线成功率要维持在与原BRAS相同的水平掉线率不高于原BRAS端到端时延设置阈值并持续观察波动组播频道切换时延则直接反映组播划界是否正确。如果组播切换时延明显变大大概率是组播复制点上收过多需要把复制点下放回OLT。试点持续一到两周每天晚上8点到11点的数据是重点因为这是现网压力最大的时段。如果在最忙时段数据正常说明模型成立如果忙时出现丢包或上线变慢回头检查控制面的新建会话余量这个瓶颈往往在扩容时被低估。4.3 第三步灰度迁移与双轨共存给回退留够窗口试点验证通过后进入规模推广。不建议一次性全网切换更可靠的做法是按OLT域逐步迁移每个OLT域切换后观察48小时确认在线率、时延指标不劣化后再迁移下一批。BNC与现网BRAS会并存一段时间并存期间两套系统采用不同的地址池和路由策略必须保证地址不冲突、路由不打架。迁移参数表参数项建议取值说明单批迁移用户占比不超过总用户10%控制故障爆炸半径观察窗口48小时覆盖两个忙时周期回退触发条件上线成功率低于99%或时延劣化超20%立即回退到原BRAS地址池切换逐OLT执行先通路由再放地址避免路由黑洞这里有一条经验迁移顺序按“业务类型”而不是“区域”更稳妥。先迁移普通宽带用户再迁移IPTV用户最后迁移政企客户。政企客户对感知和SLA要求高留到后面既能利用前面积累的经验又避免测试期就把最挑剔的客户暴露在风险里。4.4 值不值得做的账算完扩容账再看运维账BNC的价值最终要落到账面上。从扩容成本看传统BRAS在千兆普及后每2到3年可能就需要一次整机替换单台替换的采购和工程成本不小BNC模式下转发资源池可以增量扩展控制面集中后单板利用率更高长期看扩容成本下降。从运维成本看传统BRAS逐台配置策略的模式需要大量人工BNC控制面统一下发后配置工作量整体下降业务开通时间缩短。从业务收益看BNC的动态调度能力带来服务等级差异化的可能——游戏的时延专项保障、视频的带宽保障可以独立售卖。这一项不是固定收益却是运营商愿意投入BNC的原因之一。对从业者来说算账时不要只看设备成本把人力成本和业务开通时延也算进去账才算完整。5. 避坑指南BNC部署中五个常见误判5.1 误把BNC当成“换一台更大的BRAS”现象试点时只把原BRAS替换成转控分离设备控制面没有集中用户面也没有池化业务割接后唯一的区别是设备品牌变了资本开支没省、用户体验没提升。 原因沿用旧架构思维做新方案。BNC的收益来自控制面集中和用户面池化如果只是换设备仍然是一台控制转发绑定的BRAS只能算设备换代不能算架构演进。 解决试点方案里必须明确控制面集中的范围和用户面池化的数量。控制面至少覆盖一个区域的全部BRAS域用户面至少由两台设备组池才能体现BNC的扩展性和故障倒换能力。5.2 组播复制点全部上收核心直播全部卡顿现象IPTV直播频道切换时延从1秒涨到3秒忙时核心网出口流量翻倍OLT却空着大量带宽。 原因组播复制是边缘特性复制点上收到BNC用户面后同一路直播流要在核心网复制多份再分发到不同OLT浪费核心带宽也增加了切换路径长度。 解决组播复制坚持留在OLT或网关侧。BNC只负责下发组播成员关系和允许复制的策略不承担逐用户复制。这个边界在方案评审阶段就要固定下来避免实施时为了“统一管理”把组播也收走。5.3 控制面集中后认证通道容量没有同步扩容现象试点割接后白天正常晚高峰出现大量用户拨号失败或认证超时但控制面设备CPU并不高。 原因控制面集中后整个区域的用户上线请求都汇聚到同一处与AAA服务器的认证通道成为瓶颈。传统BRAS模式下认证流量分散在多台设备集中后单点流量骤然增大。 解决为BNC控制面单独规划认证通道集群按试点区域忙时上线速率的2倍配置并发能力同时对该通道做容量监控拨号失败率超过阈值时以RADIUS重试次数为排查入口。5.4 地址池全局集中后出现IPv6前缀冲突和路由黑洞现象双栈用户从一台用户面迁移到另一台后IPv6流量不通ping测试丢包严重在线用户无故掉线。 原因地址池从逐设备管理改为全局管理后地址与用户面的绑定关系没有同步到路由层部分前缀不被新所在用户面宣告形成黑洞。 解决在迁移设计中强制地址池与路由联动。用户面承接新会话前先完成路由前缀宣告用户面撤下前先停止宣告再迁移会话。地址租约时间与路由老化时间保持同量级可显著降低冲突概率。5.5 只测新终端和新套餐漏掉老光猫和长尾协议现象测试阶段一切正常全量切换后部分老光猫频繁掉线个别品牌路由器反复重拨工单量在切换后一周不降反升。 原因BNC控制面对新旧拨号流程的兼容性不一致测试只覆盖了近年主流光猫和新固件没有覆盖仍在网运行的老旧终端和长尾拨号协议。 解决测试矩阵必须纳入在网终端存量清单抽测2到3年前的光猫型号和几种市场占有率高的路由器。控制面参数上保留兼容老式PPPoE拨号的重传计时器模式不要为了追求新协议的效率而牺牲老终端兼容性。这条避坑记录来自我自己的习惯上线前先翻存量终端台账再定测试名单。6. 验证BNC效果的一个技巧把“换网”当“换大脑”做多维回归6.1 用拨测矩阵代替单点验证重点盯95分位和上线成功率BNC上线后的验证不能只看平均时延平均时延好看不代表体验好。更实际的验证方法是把常见业务场景做成一套拨测矩阵每个场景盯对应的关键指标场景拨测项关键指标观察窗口网页浏览首包时延、打开成功率95分位首包时延2s每天20:00-22:004K视频起播时延、卡顿比卡顿比0.5%全天在线游戏往返时延、抖动抖动5ms晚间忙时视频会议双向时延、丢包率丢包率0.1%会议集中时段老光猫拨号拨号成功率、掉线次数成功率≥99.5%切换后持续一周这套矩阵的要点是三个一是每个业务场景要有独立的阈值不用同一把尺子量所有业务二是看95分位而不是平均值平均值会把偶发劣化掩盖掉三是上线成功率单独盯它反映的是控制面健康度比时延更早暴露问题。我还有一个习惯对每条拨测结果保留原始报文供回放。上线初期在一块用户面出口做流量镜像保留两周左右的样本窗口期过了再关闭。这样如果用户投诉某个时段体验差可以直接从镜像回放对应时段的报文特征确认是新架构的参数问题还是外部网络问题。6.2 一个给自己留“后悔药”的收尾建议回到最初的问题BNC值不值得做。我的结论是如果现网已经面临BRAS扩容压力、或者有差异化业务经营诉求BNC方向值得投入。它的实施不是一次设备替换而是把宽带网络从“设备思维”切换到“网络思维”。投入周期在数月到一年量级期间最花时间的不是设备调测而是流量画像和灰度迁移的窗口。把每次切换都当成一次“换大脑”的手术术前缜密、术后观察回报会体现在后期每一个扩容和维护动作里。这套做法里我最看重的是灰度回退预案。不要相信“切过去就一定会成功”永远保留一套回退到原BRAS的路径。希望这份整理能帮到你让BNC这个方向从概念变成一张可执行的路线图。本文还有配套的精品资源点击获取