luobangwang
/
meeting_summury
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

first commit

main
Bifang 2026-07-20 15:43:27 +08:00
commit df1f667933
20 changed files with 1698 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
.env.example 100644
View File

@ -0,0 +1,14 @@
# Copy to .env and set values for your OpenAI-compatible service.
MEETING_SUMMARY_ENDPOINT=http://localhost:11434/v1
MEETING_SUMMARY_MODEL=qwen3:4b
MEETING_SUMMARY_API_KEY=
# Set to 20600 to produce approximately 20000-token transcript chunks,
# matching Meetily's two 300-token prompt reserves.
MEETING_SUMMARY_CONTEXT_TOKENS=20600
# Maximum tokens generated in each model response.
MEETING_SUMMARY_MAX_TOKENS=1024
# Sampling temperature sent to the model.
MEETING_SUMMARY_TEMPERATURE=1.0
# Number of transcript chunks summarized at the same time.
MEETING_SUMMARY_MAX_CONCURRENT_CHUNKS=1

9
.gitignore vendored 100644
View File

@ -0,0 +1,9 @@
.env
__pycache__/
*.py[cod]
.pytest_cache/
dist/
build/
*.egg-info/
.vscode/
.agent/

82
README.md 100644
View File

@ -0,0 +1,82 @@
# Meeting Summary Lab
这是从 Meetily 提取出的纯 Python 长会议总结测试项目。输入是**已经得到的会议文字稿**；不含 ASR、音频、数据库、录音或界面。
它严格复现原项目的核心路线：
```text
完整文字稿
-> 估算 token 数
-> 超过阈值则按窗口切块（相邻块重叠 100 tokens）
-> 每个块提取关键点、决策、行动项、人员
-> 一次性合并各块摘要
-> 按 Markdown 模板生成最终会议纪要
```
默认采用与原项目一致的粗略估算：`字符数 * 0.35`。块切分优先在句末（`. `）或空格处断开。
## 安装
项目依赖 PyYAML，用于加载可编辑的 YAML 提示词配置。可直接用源码运行：
```powershell
cd meeting-summary-lab
$env:PYTHONPATH = "src"
python -m meeting_summary_lab chunk --input .\examples\meeting.txt --context-tokens 4096
python -m meeting_summary_lab summarize --input .\examples\meeting.txt --fake --output .\report.md
```
也可以安装为本地命令：
```powershell
python -m pip install -e .
meeting-summary-lab summarize --input .\examples\meeting.txt --fake
```
## 可独立测试的功能单元
| 单元 | 命令 / API | 用途 |
| --- | --- | --- |
| Token 估算 | `rough_token_count(text)` | 验证触发分块的阈值 |
| 切块 | `chunk_text(text, size, overlap)` 或 `chunk` | 验证块尺寸、重叠与边界 |
| 单块摘要 | `SummarizationPipeline.summarize_chunk()` | 验证 map prompt |
| 摘要合并 | `combine_chunk_summaries()` | 验证 reduce prompt |
| 模板报告 | `render_final_report()` | 验证 Markdown 模板化 |
| 全链路 | `summarize` | 验证单次/分块两种路径 |
## 调整提示词
默认中文提示词位于 `prompt/zh/base.yaml`。其中 `system` 管理各阶段系统提示词，`prompts` 管理 map、reduce 和最终报告的用户提示词模板，`templates.final_output` 管理默认 Markdown 结构。修改 YAML 后，下次启动程序即可生效，无需改动 Python 代码。
## 使用真实本地模型（Ollama）
先启动 Ollama 并准备模型，例如：
```powershell
ollama pull qwen3:4b
$env:PYTHONPATH = "src"
python -m meeting_summary_lab summarize `
--input .\examples\meeting.txt `
--endpoint http://localhost:11434/v1 `
--model qwen3:4b `
--context-tokens 8192 `
--output .\report.md
```
客户端使用 OpenAI 兼容的 `/chat/completions` 协议，因此也可以指向 vLLM、LM Studio 或企业内部兼容网关。`--api-key` 是可选的；默认从 `OPENAI_API_KEY` 读取。
## 离线全流程测试
加入 `--fake` 可使用确定性测试模型：它不会调用任何网络，而是记录每一步 prompt 并生成可检查的占位结果。这适合验证切块、调用次数和模板结构；不代表真实模型质量。
```powershell
$env:PYTHONPATH = "src"
python -m unittest discover -s tests -v
python -m meeting_summary_lab summarize --input .\examples\meeting.txt --fake --context-tokens 500
```
## 与 Meetily 原实现一致的限制
这是**单层 Map-Reduce**：块摘要会在一次请求中统一合并，随后再执行一次模板化请求。极端长会议可能使“摘要合并”或“最终模板化”仍超出上下文；该项目刻意保留这一行为，方便复现和测试。若你要消除该限制，可在 `combine_chunk_summaries()` 外再套递归分组归并。

51
examples/H20测试结果.md 100644
View File

@ -0,0 +1,51 @@
# 会议纪要
## 1. 会议概览
本次会议围绕网络性能优化、资源数字化管控与运维成本压降展开，依次听取了辽宁公司接入网微秒级时延测量方案、湖南公司家宽光网融合维护实践、蔡一峰管道资源规划与管控课题、广东公司VC OTN网络DNI改造与自动逃生技术、亚冬会传输保障体系、天津公司光缆租赁成本压降方案及重庆公司传输端口资源优化等汇报。会议旨在分享现网创新实践，明确后续改造方向、待办任务、风险管控措施及跨专业协同机制。
## 2. 主要讨论点
- **辽宁公司（接入网时延测量）：** 提出基于T-WAP协议的微秒级时延采集方案，解决传统Ping测试（毫秒级）无法准确测量0.0点几毫秒短接入网链路、导致地市一级时延圈缺失接入网数据的问题。采用T-WAP LAN轻量化架构，在OLT与上联Base间部署，基于UDP数据包测量双向时延、抖动和丢包率。朝阳试点完成286台华为5800 OLT部署，实现572条链路实时采集。发现OTN环网长短路径时延差异（短边约0.3毫秒，长边达2.1毫秒），将高时延OLT上联路由改至SPN承载，时延压降最高达10%。整合端到端时延数据，支持高价值/敏感业务调度至低时延链路。
- **湖南公司（家宽光网融合维护）：** 推进家宽线路维护融入综合代维，实现职责、流程、管理、优改“四个融合”。维护界面以二级/一级分光器为界。建立四级故障分级管控体系（多PON口/主干、单PON口、配线段、单用户投诉），采用聚类算法与直派机制（如1分钟内同OLT下2个以上PON口中断直派综合代维），设置30分钟延迟派单规避冗余工单。建立区县/模块维度效能画像与排名打分机制，综合解决率、及时率和合格率进行考核。
- **蔡一峰（管道资源规划与管控）：** 针对海量杆资源缺乏路段管理功能的问题，购买道路红线及路段信息，匹配资源数据构建数字城市模型。从管廊覆盖、建设、使用维度设定权重评分，识别利用率超100%路段进行优化。提出废弃光缆拆除、头路段光缆收敛、路由优化等策略，以南京路路段为例将利用率从113%降至86%。强调加强资金管控储备、新增光接入光纤网比例考核及管道预警管控。
- **广东公司（VC OTN网络改造）：** 汇报省内VC OTN网络DNI改造情况。针对现有SNCP保护存在单点故障、同路由、带宽不足及核心节点槽位紧张等问题，引入DNI保护能力，将环相切改为环相交实现节点保护。联合华为开发割接专用工具，实现可视化脚本执行与无损调整（先倒备→改交叉→再倒回）。诊断出四大问题并制定四套优化方案，珠海/佛山方案涉及跨市链路升至100G及节点直连改造。
- **亚冬会保障/传输工作台：** 构建以传输工作台为核心的保障体系，涵盖基站与传输链路关联、故障分级管控（红橙黄蓝四级）、同流分析等。采用1:1:2保护版本及光开关设备实现应急逃生，利用SPN L3能力验证跨线区、跨地市、跨厂家逃生。保障期间完成2693个基站穿透排查，整改31个同路由问题，验证成功率达100%。
- **天津公司（光缆租赁成本压降）：** 针对重点区域光缆租赁成本高、路由不透明问题，提出单芯双向光模块改造方案。以滨海生态城为例，通过隐蔽改造、分布式OLT部署及智能网管监控，总量压降313芯公里（压降比例41.7%），2025年预计节约成本320万元。
- **重庆公司（传输网络利用率提升）：** 针对千兆FTTR发展下现网端口利用率低问题，采取低效端口置换、插纤板整合腾退等措施。以单端口承载用户数为坐标画像，开发跨厂家端口割接工具实现批量割接。按机房维度统筹整合空闲端口，省公司计划部统一调配回收板卡，节约投资30%。
## 3. 决策事项
- **辽宁公司：** T-WAP协议部署成功补齐地市一级时延圈数据，具备全网推广价值；确定优先利用既有SPN或裸纤资源对高时延链路进行改造压降。
- **湖南公司：** 家宽光网故障分级定位与线上化调度机制有效运行，确定分阶段（指标提升期、全面整改期、稳定达标期）推进维护指标提升策略，并实施多维度效能画像与考核排名；连续三个月内部曲线代维指标未达标执行退出机制；今年将成本费用整治合同范围下沉，保证整治范围与维护界面统一，光缆层面整治统筹为一张网。
- **蔡一峰：** 加强资金管控储备（隧道、大桥等战略资源）；加强新增光接入光纤网比例考核（小新数定于20根及以上）；实施路网分级管理与管道预警管控（莫控不串放、红色预警不串放）；加强基站搬迁管控防闭环。
- **广东公司：** 基础业务验证及各类故障场景下网管状态符合预期；DNI配置具备抗多点老化及单节点故障能力，普适性强；业务安全性本质提升，链路带宽增长10倍（升至100G）；割接工具将单条业务割接时间缩短至3分钟，单窗口业务数翻5~6倍，现网验证无损。
- **亚冬会保障：** 跨线区/跨地市逃生原理通用，可实现4/5G业务保底；四级基站蓝色告警暂不做处理仅关注；冰雪大世界景区同路由问题已全部完成整改。
- **天津/重庆公司：** 创新应以解决问题为导向；重庆公司低效端口置换与插纤板整合腾退方案显著提升资源使用效率，节约投资30%。
## 4. 待办事项
- **辽宁公司：** 推进T-WAP全网部署，继续与中兴、烽火OLT厂商开展现网联合测试，目标完成全量OLT上联链路部署与采集。（责任人：未明确；时间：未明确）
- **辽宁公司：** 分析全量OLT上联链路时延，结合现有或规划传输资源，对高时延链路开展优化压降。（责任人：未明确；时间：未明确）
- **辽宁公司：** 整合接入网及上层网络时延数据，联合上层网络调度高价值用户及敏感业务至低时延链路。（责任人：未明确；时间：未明确）
- **湖南公司：** 按指标提升期、全面整改期、稳定达标期三阶段稳步提升故障处理及时率与服务指标。（责任人：未明确；时间：每小半年推进一阶段）
- **广东公司：** 今年底前完成重要专线的DNI改造（非全量）；24年3月至今年底完成重要专线部分改造。（责任人：未明确；时间：今年底前/24年3月至今年底）
- **广东公司：** 新增业务通过自控作业台开发适配实现DNI能力；存量业务改造倾向使用厂家工具；推进中兴OTN能力开发，存量业务工具开发预计今年底完成。（责任人：未明确；时间：今年底前）
- **广东公司：** 施工公司根据珠海/佛山改造方案指导，向当地规划部门提报本地网具体建设项目。（责任人：施工公司；时间：未明确）
- **亚冬会保障：** 今年底前实现基站大面积保障、4M IP城联网重要电路及重要集客专线等保障场景的大部分功能。（责任人：项目部/相关团队；时间：今年底前）
- **重庆公司：** 群资中心梳理低效端口置换清单并跟踪置换情况。（责任人：群资中心；时间：未明确）
- **重庆公司：** 计划部对未切实执行置换的分公司停止后续插纤板资源审批，并统一调配回收的腾退板卡。（责任人：计划部；时间：未明确）
- **重庆公司：** 资管系统常态化监控现网空闲端口。（责任人：资管系统/相关部门；时间：常态化）
- **其他：** 若算法稳定性测试通过，争取下周一由亚星团队安装系统设备，需配合远程支持。（责任人：亚星团队/配合方；时间：下周一）
## 5. 关键信息
- **辽宁公司：** 传统Ping测试精度为毫秒级；朝阳试点部署286台华为5800 OLT，采集572条链路；高时延链路差值大于1.5毫秒；端到端路径最优6.5毫秒，最差10.6毫秒。风险：中兴OLT未获入网证，烽火预计7月支持；OTN改造资源与投资受限；端到端时延受流量调控影响存在不确定性。
- **湖南公司：** 故障判断规则：1分钟内同OLT下2个以上PON口中断直派；3个以上用户1分钟内不在线判定配线故障；30分钟延迟派单。成效：无效沟通与频繁上门率下降近1/4；月均故障量约3.6万笔，重复故障占约八成。风险：交接初期资料不清、跨专业考核不完善易致推诿；OLT下行“黑线段”缺乏无源器件告警数据定位能力弱；助力网项目与传统光纤项目整治界面交叉。
- **蔡一峰：** 管道占比34%，购买性占比88%；市政道路覆盖率72%，轨道交通96%，市区覆盖率91%；48000个已建管道，30000个管道段配置较高（占比62.5%）；资金管道利用率2.5%。风险：管道利用率普遍偏低，前期储备少，废弃光缆未拆除及路由不合理导致堵塞。
- **广东公司：** 倒换时间在15毫秒以下；链路升级至100G（带宽增长10倍）；割接时间从15~10分钟缩短至3分钟。风险：全量改造费用未定；改造工具强烈依赖厂家内部资源分析与脚本生成，暂无法自研；现网存在单节点故障、同路由、带宽不足及核心节点槽位紧张风险。
- **亚冬会保障：** 保护版本1:1:2，需至少3条路由；逃生模块速率10G/50G/100G；光缆距离限制不超过85公里；华为设备双断切换存在约10秒周期性问题。风险：100G/85m光模块对接时中兴/烽火FEC配置默认差异需底层修改；华为与中兴对接存在正序/反序差异；跨专业告警匹配困难。
- **天津公司：** 单芯双向光模块改造压降总量313芯公里（比例41.7%）；50GE单芯双向光模块单价较传统高约200元；2025年预计节约成本320万元；当前租赁单价约150元/芯公里/月。风险：重点区域运营商话语权弱，新租赁路由不透明、距离不可控。
- **重庆公司：** 单插纤板接入千兆用户数提升至7.7户；节约投资30%；腾退670块板卡。风险：现网插纤板/端口资源闲置低效使用。
- **待确认事项：** 中兴OLT入网证获取时间及烽火7月支持的具体版本/能力范围；原文“152 10实验圈”指标定义及“助力网”项目准确名称；天津租赁成本递增比例（原文“10~5%”疑似识别错误）；重庆汇报中“插机胖/胖口”等疑似“插纤板/端口”的ASR错误；天津生态城案例中“313新公里”及多项金额数值单位待确认；华为双断切换10秒问题是否已升级解决；亚冬会保障起止时间及涉及基站准确数量（原文2633/2693冲突）。
## 6. AI 建议
- **设备兼容与标准化管控：** 针对中兴、烽火OLT T-WAP协议支持进度不一及光模块FEC/正反序配置差异，建议建立跨厂家设备对接兼容性测试清单，提前制定底层配置修改规范与现网割接应急预案，避免多厂商混用场景下业务中断。
- **改造成本分摊与工具自主化：** 广东VC OTN全量改造费用未定且割接工具强依赖厂家，建议分批次优先对高价值专线及单点风险链路实施DNI改造，同时加快自研或联合开发标准化无损割接脚本，降低对单一厂商底层资源的绑定风险。
- **资源数据治理与界面统一：** 针对湖南“助力网”项目界面交叉、重庆端口闲置及天津租赁路由不透明问题，建议建立统一的资源台账动态更新机制，明确整治与维护界面划分，将低效/闲置资源纳入常态化考核与自动预警系统，提升资产周转率与考核公平性。
- **跨专业告警协同机制：** 针对无线与传输设备种类多、综资采集滞后导致告警匹配困难，建议推动综资系统数据实时同步，完善基站IP/MAC与传输链路的自动关联模型，缩短故障定界与跨部门协同处理时长，降低重复故障率。

254
examples/meeting.txt 100644
View File

@ -0,0 +1,254 @@
# 文件会议 07-13 11:30 会议转录
- 会议时间：2026-07-13 11:30:52
- 主持人：中移物联管理员
- 导出时间：2026-07-13 14:42:12
## 转录正文
- [00:00:00 - 00:00:02] 说话人1: 下午好，我是来自辽宁公司的刘。
- [00:00:02 - 00:00:07] 说话人2: 你你还做的是写的啥？是的，你解释里面也写的啥？是的。
- [00:00:08 - 00:01:03] 说话人1: 测量方案研究与实践，也是近几年吧，随着这个，串联网络提出的这个，152 10实验圈呢，这个概念和要求，各省各兄弟省应该都做了很多关于干线方面的这个实验优化的工作，但是对于接入网这块呢，可能之前做的比较少，然后我们也我这块分享了一下我们省做的这一些工作，一是项目背景，传统的这个拼测试的方案，因为这个测试实验精度的问题呢，无法准确采集这个胖网络的接入的这个实验，导致在这个地市一级实验分析中缺失接入网的这个实验数据的情况，无法准确呈现一级实验圈的这个数据，所以这个提出了基于，T WAP这个协议测量胖网络实验的方案的这个解决方式。
- [00:01:04 - 00:01:59] 说话人1: 之前用的比较多的，就是测量这个ORT上联至base这段链路的这个，时间测试的方法，可能用探针用的比较多，然后在ORT下面挂一个探针做拼测试，但是这个拼测试的这个，时间的这个精度一般都是毫秒级的，在像我们接入网的这部分链路可能有一些，距离比较短，可能是0.0点几毫秒，通过这个拼的这个方法，就无法准确的这个测量，然后呢，在这个地市的一级时间圈当中呢，可分解为这个小区，我们这些小区到这个曲线呢，中心，然后是这个曲线到市中心这两部分，然后曲线到曲线中心到市中心呢，我们可以结合，比如说base到那个PC，就CMNET网络这部分时间数据，可以计算出这个曲线到市中心的这部分时间。
- [00:02:00 - 00:02:58] 说话人1: 但是从这个小区到这个区县中心的这部分接入网的实验区域，目前在这个实验地图中还是缺失的，所以也就是无法精确的分析到这个网络接入这个路的这个实验包的，或者是有这个实验问题呢这部分详细的这原因。基于以上呢，通过这个基于T-WAP这个实现，通过链路微秒级别的这个实验采集，解决跨网络链路实验无法准确采集的问题，为接入网实验分析业务多层方案实验分析提供数据支撑。我们这个先简单介绍一下这个T-WAP协议吧，它是用于IP链路性能测试的技术，然后在接入网使用呢就是通过在OLT与被试之间部署，该协议实现OLT这个上联链路的实验数据的准确采集。
- [00:02:59 - 00:03:55] 说话人1: T-WAP它是一种这个使用的是这个UDP数据包作为探测作为测量探针统计网络的双向时延抖动和这个丢包率的情况在现网中用的比较多的是这个T-WAP T-WAP LAN这个协议它是这个轻量化的这个架构简化了性能建立的测量会话的控制协议实现对网络任意位置的双向IP性能测量这个实际在现网的部署呢这个测量机制是在OLT与上联Base之间部署这个T-WAP LAN协议然后Base是作为这个Sender然后OLT测作为这个Responder然后通过Sender周期的发送这个测试报文在测试报文中携带这个时间戳。
- [00:03:56 - 00:04:47] 说话人1: 基于相邻的两个包文的时间戳来计算这个链路的性能。它这个计算呢，实验的方式还是很简单的，就是通过这个接收的这个时间戳减去这个发送的时间戳，再减去这个中间转发的这个间隔的这段时间，就得出了这个链路的整体的这个实验的这个数据。然后在胖网络中部署呢，嗯也是就是结合这个现网呢各个设备厂家的这个情况，我们进行了一个了解，然后在那就设备支持的情况呢，因为我们现网RT设备有三个厂家，然后华为的5800的设备是支持这个TWP这个协议的，我们是也是在华为的这个。
- [00:04:48 - 00:05:38] 说话人1: 因为我们现网base也是华为的，所以就是基于华为的OLT和base，做了这个现网的部署，然后其他两个中兴和烽火的这个OLT的设备目前的这个版本还是中兴是说反馈的是已经发布了，但还没有这个获得入网证，然后烽火我们了解到是说七月份支持，所以这两个厂家目前现网还不具备这个能力，所以这个现网呢我们目前做的测试就是在华为OLT上联到这个华为base这部分链路部署这个TWP协议，实现这个性能数据的这部分采集。然后在宽网络中的这个部署方案，第一个第一步就是这个网络规划，因为部署这个测试任务需要。
- [00:05:39 - 00:06:31] 说话人1: IP地址，然后我们在现网是立就了这个电视的主播业务的这个维拉，还有接口以及IP地址规划，直接在这个OLT上联这个双机base间新增了两对互联IP，解决了这个IP地址的这个现网立就的这个情况。然后第二点就是做数据配置，在base上需要配置这个ty5000 sender的这个测试任务，在OLT上配置responder这个测试任务。目前呢，这base测我们还是通过这个跨专业沟通base测需要这个手工去配置，然后在OLT测呢，因为这个OLT的这个数量也是比较大，我们已经这个实现了这个脚本的这个自动生成和自动配置。然后第三步就是这个数据的实验数据的这个采集。
- [00:06:32 - 00:06:42] 说话人1: 在这个工作台通过 telemetry采集这个base和rt之间的tflab的这个任务，来获取各条链路的。
- [00:06:43 - 00:06:45] 说话人3: 全刘邦总统的这个声光数据。
- [00:06:49 - 00:07:38] 说话人1: 第三点介绍一下项目的效果，我们在那个辽宁的朝阳市开展了项目的试点，已经完成了，286台华为5800型号RT的T-WAP协议部署，实现了572条链路实验性能数据的实时采集，并且预警这个链路的时差，可以先看一下这个上联链路实验的这个呈现，在工作台上呢可以针对这个每条T上联的链路，可以呈现出，链路的时延丢包抖动等性能数据，在这个网管中呢基于这个T-WAP的这个，性能链路的性能测试采集任务，在链路时差的情况下呢会生成。
- [00:07:38 - 00:08:25] 说话人1: 并开发工单，实现这个接入网链路的性能监控，就是部署了这个任务呢，就可以代替我们，之前可能用的比较多的探针来播测，还是出这个丢包，时差的报警，这个可以直接从设备侧，通过这个厂家网管就可以显示出来这个，电路的时差的这个报警。然后就是曲线级的这个时延数据的呈现，然后根据曲线内全量的OLT上联链路的时延，可以计算出曲线内这个网络的平均时延情况，呈现各个曲线的时延的数据的同时呢，也支撑这个曲线公司开展，网络时延优化的工作。
- [00:08:25 - 00:09:18] 说话人1: 在我们线网呢，根据非是上联链路，来计算这个线曲线到市中心的这个平均时间，然后根据这个OLT上联链路计算出这个曲线的平均时间，两部分数据结合起来呈现出这个地市一级四圈的整体这个时间情况。然后下面举了一个我们这个朝阳市的各区线内的这个，以市道线以及曲线内的时间情况。可以看到，我们提出的这个一毫秒这个一级四圈，在这个朝阳市的这个网络里，特别是这个曲线内，朝阳线这个点它，就曲线内部的这个平均时间已经超过了这个一毫秒，这主要原因还是这个。
- [00:09:18 - 00:10:10] 说话人1: 跟这个曲线呢，传输的网络呀，还有这个整体的这个地区结构也有一定关系。然后针对这个高时延的链路呢，我们也开展了这个，接入网的结构性的这个问题的挖掘。我们对这个朝阳市这个全量的OLT上联链路的，进行了这个分析，存在七台OLT上联链路，差值大于一毫1.5毫秒的情况。然后选取了两台接入，进行了深入的分析，上联链路的传输光中承载情况。然后造成这个时延高差值较大的原因主要是长路径的存在。然后一下就是举例说明一下。然后左侧这个图呢可以看到，这个曲线的倍数。
- [00:10:15 - 00:11:03] 说话人1: 然后这个ORT呢，它也是通过这个线箱的OTN这个OTN环来承载的，它这个短边和这个长边，就是这个OTN环可能有这个问题，短边的时延就是非常小，才0.3毫秒左右，通过这个长边承载的这部分，然后这条链路呢，时延就达到了2.1毫秒，所以这还是跟这整个区域内的这个长中频网络这个网，有一定的关系，然后右侧这个头呢也是大概是相同的情况吧，然后主要还是传承载，那个线箱的OTN环的这个。
- [00:11:04 - 00:11:51] 说话人1: 我们的长短路径承载导致的时延差距过大存在高时延的那个链路情况。然后我们也选取了现网中一台具备传输资源的这个一台上联时延较高的OLT设备进行了这个改造，将该OLT设备上联链路由OTN网络改就是这个SPN网络承载，然后链路时延最多压降10%。就是这个区域正好还有既有OTN网络也有它的SPN混合网，通过将OLT的上联链路从OTN改至SPN，这个时延达到了一定的这个优化。然后这个现江的OTN这部分。
- [00:11:53 - 00:12:52] 说话人1: 优化起来还是怎么说也是对这个资源要求，包括投资要求也是比较高。所以这部分链路，我们暂时还是选取已有资源网，包括SP或者裸线来进行这个时延的压量网络的改造。有了这，OT就是接入网的这个时延的数据，然后就，我们也做了一个，时延数据的整合吧，可以呈现出这个业务端到端的这个时延的情况。就是对省内的这个1~2级线圈的各级各层级的链路时延数据进行了整合，呈现业务在省内端到端各个方向，路径时延的情况，体现网络针对业务提供，差时延差异化服务的这个能力。选取了一个，朝阳市的小区。
- [00:12:52 - 00:13:49] 说话人1: 模拟在用户访问，我们省会沈阳市CMNET省网下的这个资源业务，通过逻辑拓扑呈现业务，流经的设备及实验链路，在网络无调无流量调控的情况下，各个用户及业务会首先移动到各个链路上，端到端的这个实验是无法确定的。这个小区到ORT这部分实验呢，主要基于这个我们这个胖猫到用户家里的这个，光猫的这个，就是网管里面的这个测距，这部分数据来转换过来的。从ORT往上呢，ORT到BASE之间是刚才通过TLOG这个数据，测试任务得到的这个实验数据，然后BASE往上呢，就是基于CMNET网络，它部署的这个。
- [00:13:50 - 00:14:47] 说话人1: T沃把这个测试任务，拿到这个整个现在他网络的这实验数据。他就是他，其实他就支持，这他就是通过IP，就是IP网络的这个测试任务。就是ORT之前这块，嗯怎么说呢，在现网没有部署，但是在这个CMNet网络里面，前两年已经部署了这个T沃这个采集任务，已经有了这个类型。对他只要升级网络，基本上升级那个软件版本，就可以支持这个实验的采集。然后可以看一下，通过对该小区访问端，省网端到端网络，链路实验的这个整合分析，该小区共存在四个不同的实验路径。我们可以看一下最优的是。
- [00:14:48 - 00:15:43] 说话人1: 6.5毫秒，然后最差的这个路径呢有1010.6毫秒，后续呢可以调整这个高价值用户，以及对这个业务时延比较敏感的这部分业务，到这个调度到低时延链路上承载，然后体现出我们这个网络的差异化的这个服务能力。然后项目总结及下一步的这个工作计划，然后基于T-WAP协议在接入网中的部署应用实现了，跨网络链路的微秒级的时延采集，补齐了地市一级时延圈数据，发掘接入网高时延ORT上连接路等结构问题，呈现业务级省内端到端多方向路径时延情况，提升曲线网络支撑能力。后续呢我们计划从以下三方面继续。
- [00:15:44 - 00:15:59] 说话人1: 工作，一是推进这个全网部署，继续与这个中兴和烽火的这个RT厂商，对这个他们RT设备的支持情况来开展在线网开展联合的测试和任务。
- [00:16:00 - 00:16:02] 说话人3: 全。
- [00:16:02 - 00:17:00] 说话人1: 目标是将我们这个全量的OT设备的上联链路，全部署了这个TWP协议，完成全量的OT上联链路的这个采集。第二个，第二项工作呢是这个接入网这个问题的挖掘和优化。对全量的OT上联链路时间开展分析，挖掘时间异常偏高的链路。然后结合现有的或者是后续可能建设的这个传输本地网的设备及光缆资源，对时间较高的链路开展优化和时间压降。三是这个网络差异化的这个呈现，对这个实验数据的整合。通过工作台呢，将接入网上层网络的实验数据进行整合，制作呈现业务，各种途径的这个各个路径的实验情况。然后根据各类用户和业务的重要程度，联合上层网络。
- [00:17:01 - 00:17:10] 说话人1: 调度高价值用户，以及业务是这个低时延链路去承担。以上是我分享的内容，谢谢大家。
- [00:17:21 - 00:17:32] 说话人4: 各位领导同事大家下午好，我是那个湖南公司的杨毅，然后我今天跟大家讲的这个就是，基于分级机制的这个加工方法。
- [00:17:32 - 00:17:34] 说话人3: 我清晰。
- [00:17:36 - 00:17:41] 说话人4: 整体呢分为四个部分，第一个呢是24年的时候。
- [00:17:42 - 00:17:44] 说话人3: 24年初的时候，我们省内基于。
- [00:17:44 - 00:18:28] 说话人4: 这个综合代维的这个整个维护活动，和我们实际维护的这样一个需要，也是整体去考虑的这个加级的业务支撑保障能力和客户提升感知的这样一个方面的工作，有序或者有计划的去推进的这样一个光了一张网的这样一个融合工作，就是相当于通过一张光网的这个四个融合方面的一些工作，按照这个融合的管理的基本原则，将加级客户部分的这个线路维护的部分，整体融合到了我们这个综合代维的这个部分，综合代维的这个包年服务的整体项目的一个管理和维护当中。这个地方总体呢也是分为三个部分，第一个就是职责界面的一个调整，就是把原有的加级的队伍的这个线路维护。
- [00:18:30 - 00:18:55] 说话人4: 统一发挥了这个综合代维去维护，做到了综合代维的融合一张网络网的这个运维管理。第二块呢，就是我们在这个流程方面与现有的这个综合代维加几个代维的这个运维机制去做了匹配，包括我们现有的胖网的胖口的故障、配线故障和层故障、带故障，实现了这个像，实现了这个分代维单位的这个。
- [00:18:57 - 00:18:58] 说话人3: 包括这种投诉状态的。
- [00:18:59 - 00:19:29] 说话人4: 综合代维和加急代维的这种互派互转的这种模式，实现了这个故障工单的一个闭环的一个流转。第三方面呢，就是在管理上面，整体在代维管理合同，包括我们的相应的一些考核细则当中明确了这个考核依据，同时呢，也量化了一个对代维单位综合代维的这个故障处理的时长及服务等方面一些量化的质量考核要求。总体上呢，我们是来维护融合、流程融合、管理融合和优改融。
- [00:19:30 - 00:19:33] 说话人3: 分阶段去推进这样一个。
- [00:19:38 - 00:20:36] 说话人4: 整体我们的这个推进方案呢，从四个融合方面来看，就是基于这个高效交接和屏幕过渡提质增效的这样一个总体原则，分为几个阶段去有序的去推进，这样一个线路运维和综合代维活的这样一个工作，在保障这个网络质量屏幕过渡的同时，有序的去提升这个技术运维的这个故障和故障指标。第一块呢维护工作融合这块呢，整体就是将原有的家庭代维的这块的一些维护资料维护指标，这个地方分为两个部分，维护资料这块其实是以整个甲方用户的一个一级或二级中间箱或者几个单位的网点和标准的这样一个资源点为基础这样一个资源交接，包括一些材料物资这方面。第二个方面可能是更重要的一点，就是关于维护界面，将综合代维的整体的维护界面下沉到了这个二级封装器，也就是说以靠近用户最近的二级或一级封装器为界。
- [00:20:37 - 00:21:26] 说话人4: 这个分光器上行的，有一个线缆部分，由综合代维整体负责；下行部分，其实这个地方的下行部分，大概率也基本上只有皮线部分了，就是由架构装备这块整体去负责。第二块呢，就是这个流程调度机制整块，就是像我刚前面介绍的，就是把整个这个，线上化的一些故障工单的派单机制，派单流程，通过这种工单直派的方式，直接首派到我们的这个综合代维，或者说对于这种投诉类工单，或者说我们就会，去这种12086和490的单用户投诉，用去首派这种铁通维护，也就是加方维护这块，然后通过这种后续的一些故障判断，然后计算去做这个一个线上化的工单。
- [00:21:27 - 00:22:15] 说话人4: 的这样一个形式。第三块呢，就是这个考核管理融合这块。整体呢，在现有的我们省内的综合代维管理考核的管理办法和实施细则当中，对这一块呢，也是大步无从。一些相应的这种考核及时率的指标，和时长的指标，投诉，困难处理的一些指标，这个纳入到了这个综合代维的一些合同和考核管理实施细则。第四块呢，就是优改融合这块呢，整体上。因为现行的我们的这个成本费用整治这块，整体分为传输网一块和数据网一块整治这一块，在整体上这1块2个相对来说还是比较吻合的。然后我们整体。
- [00:22:16 - 00:23:10] 说话人4: 过程当中呢，也发现这个故障，流程过程当中也存在或多或少一些典型问题，包括维护当中遇到的一些，嗯综合代维和加特代维在交接初期的一些资料不清，职责不职责也不明，然后包括一些相互之间的一些沟通协调机制也不顺畅的这样1.1些很多典型问题，还有也包括我们现有的这种ORT下行的这个，黑线段的这种光缆故障的定位的能力也不强，然后包括一些跨专业考核，管理不完善的这样问题。在第一个方面就是这个故障响应不及时这块，整体上来说我们现有的原有的这个故障信息的流转，包括这个处理效率比较低，因为加特装维和这个代维之间，他们是没有线上化的这样一个调度的这样一个流转的这样一个机制和流程，更多的方式都是通过一种。
- [00:23:10 - 00:23:59] 说话人4: 线下电话沟通的这种方式，导致这个故障的处理效率呢时间长，效率低。第二块呢，就是这个工单信息也不够完善，工单信息里面包含的这个关键信息也不足，也不能够去帮助这个故障的这个快速定位和这个，现场人员的及时找到这个故障位置。第二块呢，就是这个OT下行的这个故障定位，黑线段因为一分二分我们都是无线器件，在这一段的这个整体的这个告警定位，尤其是定位这段黑线段故障的时候，整体我们是缺少一些必要的一些告警数据，或者说定位手段。然后第二块呢，也是整体就黑线段的这个关联性也是较低的，导致我们的告警信息和我们的这个资源信息的关联性是比较低的，导致这个这块也就是。
- [00:24:00 - 00:24:59] 说话人4: 定位能力也不太也是比较弱的。第三块呢就是考核这块，然后原有的综合代维和加刻代维这块，因为或多或少相互之间的一些维护职责的一些关系，他们之间，也存在一些工单的这个沟通，包括这种故障超时之后导致的这种投诉处理不及时的这种相互之间的，一些沟通掰扯的一些问题。第二点呢就是我们在人，就像刚前面提到的融合过程当中存在的一个，按整治成本费用整治的助力网项目和我们的传统光纤项目，它其实整体上是，这个小区光纤也是，大概率是以一级封装器为界的，在一级封装器的二级封装器阶段的配线光缆的，光缆层面的这个整治，又是在助力网的这个项目整治活动里面，去执行的，所以就会导致这两个者，我们存在一个维护界面和我们的项目整治。
- [00:24:59 - 00:25:53] 说话人4: 自动界面会存在一定的交叉，导致项目管理有一个多头管理和隐患整治不及时的问题，并且这个地方也会存在因为跨专业沟通，他们的隐患整治这种进度，包括这种及时性得不到这种明确保障。在这一块呢，就是我们的这个省内的这种跨网或者说配建网后的这个月均故障，我们在3.60003.60000笔的样子，大概有这一段的故障量占了八成左右。第二块呢，就是因为同一个网段的这个光网段的这个整治，助力网整治和传输网整治的这个项目推进的这个进度不是统一的，所以它这块因为整治精度不一的话，也容易造成这个段路的重复故障，这个比例也是偏高的。然后基于。
- [00:25:53 - 00:26:42] 说话人4: 基于融合过程当中，这样的一些问题呢，我们为了去提升这样一张光网络的融合程度，提升这个维护质量效呢，然后呢我们整总体呢将这个加宽光网络的故障分为四个层级，就是分层分级的这个采用这种分层分级的这种故障定位的方法呢，来构建一个整套的这个加宽光网络的故障管控体系。这一块呢，大家也可以看到我们的组我们在主网拓扑上面，把它整体分为四个故障层级，第一个层级呢是包括我们的多胖口这一段的多宽多发在这个主服务区的这种主干光缆这块，单胖口的故障就是从一层往下走的，走到二层位置的这种单胖口，第三个呢就配件端从小数光交到用户分接箱里面，到楼栋的分箱里面，第四个呢就是单用户投诉的，就是配件端的。
- [00:26:43 - 00:27:42] 说话人4: 它分了四个层级的这样一个，故障定位的这样一个投诉管理的一个体系。然后呢，将整体的体系通过不同的判断规则，包括这种故障发生的位置的这样一个定位，故障发生位置这样一个和我们的判断规则去做了一个这样一个分析匹配。包括我们举个，典型例子，多判口的这种故障来说，我们在一分钟内如果同一个OLT下面的两个或两个以上的判口去中报上报这样一个中断类告警，我们。在一定的根据一定的判断规则，我们就判断这个主干光缆中断故障。这种工单的话，根据这个判断机制，我们就会直接直派工号代维。建建立工单去直派工号代维去处理线路式故障，也就加宽装维。它就没有，不会受理到建立，因为主干光缆中断导致了末端的用户投诉的这种告警。建建立工单。总体呢也分了这个四个层级，包括我们的多判口单报和黑线。
- [00:27:43 - 00:28:33] 说话人4: 主传派，在这一块呢，就，配线故障的工单，我们前期，也是因为前期的这样一个定位能力呢，我们，通过也是通过不断的这个优化算法和这个优化这个，工单的这个调度流程，然后保证的这个工单派发的呢更加可以高效。然后这一块我们其实可以看一下右边这个典型的这个组网模型当中。对于这个聚类算法的我们的一个典型的应用场景呢，就是对于这种，右边的这种标准化的组网场景下面，当用户，多个三个以上的我们的，定义的一个判断逻辑去，当三个，以上的用户应用户在一分钟内，都不在线的情况下，系统自动判定它为一个配线的故障，也就是说对应于我们右边这种场景的情况下，如果三个用户同时中断。
- [00:28:34 - 00:29:33] 说话人4: 定义我们就根据这个故障的这个定位判断逻辑去判断它是属于这一段分支段的非线性光缆故障，这是属于一个典型的故障。如果还有一个非典型场景，就是由于多个二级分光器采用在同一个光缆上面多加串联这种方式，当出现的多个用户分布在多个二级分光器上面的时候，这个就去做了一个聚类分析定位它在多个二级分光器在同一个光缆上面，然后呢，就通过这个告警工单的这个信息，把这个离这个OLT最近的这个分光器故障分光器的这个地址给它带出来，定位的这个光缆段的故障段落呢，就是这个分光器最离OLT最近的分光器和OLT之间的这个光缆段故障。然后这一块呢，同时呢我们还在另外两个方面，第一个就是针对我们现在可能存在的一些电干扰这种。
- [00:29:35 - 00:29:38] 说话人3: 做了一个规则的排除，包括讲 O U。
- [00:29:39 - 00:30:22] 说话人4: 体电告点了之后会上报一个DGI，就是这个设备掉电这样一个告警。系统中关联的这个，FIO上面真有这个闹死，但是没有DGI的时候，才会判定故障。这种情况下我们就避免了停误派单。第二种就是设置了一个延迟派单的情况。因为实际维护操作当中可能存在这种现场这种，FIO的重启，光缆接的这种过程，会也会去触发这个告警派单的规则。但是我们设置了一个三30min的延迟派单，去规避这样一个冗余派单的这样一个情况。在整体我们在去年六月份之后，整体上线呢，我们现有的这种故障率的下降。
- [00:30:25 - 00:30:59] 说话人4: 整个的这种配线段故障定位的时间呢，也是缩短到了分钟级。另外，整体这个无效沟通，包括这种代维人员频繁上门的这种情况，上门确认的这种情况也减少了接近1/4。第二块呢，就是我们投诉转派这块。末端加宽用户，单个用户投诉或者触发的这种投诉工单，由于这个加宽专维去现场核实了之后，他会把这个现场核实的情况通过工单进行流转到中国代维去，相当于。
- [00:30:59 - 00:31:00] 说话人3: 一个做到一个。
- [00:31:00 - 00:31:18] 说话人4: 终端的正向派单，相当于他在现场判断了这个位置，不是由于末端缺陷或者说故障器或者说加用户体验这样一个情况导致的，而是由于上端二分以上的光缆故障的造成的这个用户投诉，他会在现场去发现测试的点位的一些。
- [00:31:18 - 00:31:21] 说话人3: 成功率、精准度信息，后测试结果。
- [00:31:21 - 00:31:33] 说话人4: 通过这种工单复建的形式，上传到这个工单系统里面，然后流转到我们大伟工地。通过大伟在受理了这样一张工单之后，然后再去现场去定位，做这样一个。
- [00:31:36 - 00:31:40] 说话人3: 桥梁故障处理，这个呢也是。
- [00:31:40 - 00:31:45] 说话人4: 目前是可以通过，然后因为投诉工单。
- [00:31:45 - 00:31:46] 说话人3: 说说。
- [00:31:46 - 00:32:30] 说话人4: 责任制的时候，他接到工单之后，他做了第一步分析判断之后，他会把这个工单同步向外转派的坐标范围，加快这个光缆故障的这个处理，此外也提供了一定的相应的一些测试信息、位置信息，便于这个位置光缆位置的这个直接定位。在这一块呢，整体的这个投诉工单的这个处理效率呢，目前也是得到了一些显著的提升。这一块呢也是，这一块主要是有一个，在电子化转派当中，我们这个光缆故障转派的这个专用入口，光为人员去发转派工单的时候，是我们对他做了一项限制条件，是一定需要去上传一些相应的一些测试佐证照片，避免这种无效转派或者说。
- [00:32:31 - 00:32:33] 说话人3: 恶意转派的这种情况。
- [00:32:35 - 00:33:24] 说话人4: 另外一方面呢，就是在整个运维管理体系上面，从两个方面：一块就是这个运维指标上面。我们按照这个分阶段做，分阶段提升的这样一个策略，然后也是去稳步提升这样一个处理能力和各个预防面。第一个阶段呢，叫指标提升期，第二个阶段呢，再全面整改期，第三个阶段呢，叫稳定达标期。也就是从去年初开始，我们分三个阶段，差不多是每小半年一个阶段的一个时间节点。在就是为了去提升这个加班故障工单的这样一个快的处理的一些及时率。第二个方面呢，是整体对曲线维度的这个综合带维，去对它进行了一个整体的这个处理效能的一个画像。然后我们相当于从多维度。
- [00:33:24 - 00:33:44] 说话人4: 我们解决率、及时率和合格率这方面进行一个综合，再去对这个加工装维的这个各项能力指标去做一个综合分析判断，去给所有的这个按曲线维度和模块维度进行一个曲线的排名打分，然后对于这种曲线维度和模块维度。
- [00:33:45 - 00:33:47] 说话人3: 两个维度方面，都对他们。
- [00:33:47 - 00:34:39] 说话人4: 进行了一些相应的这种指标考核，包括一些竞争性管理。按照我们的这个竞争管理机制，就是连续三个月内部的这种，曲线代维指标是按要求要执行这个退出机制和竞争性要求的这个原则要，就相当于在所属区域的这个代维服务，移交给其他的代维单位去负责。最后一块内容呢是优改，就是整体交通网络的优化，整体一体化。然后这一块呢整体来说是分为成本费用和资本费用开支。在成本费用这块，我们按照刚前面介绍的其实处理网和，传输优化整治，在一定的程度上它的整治界面和它的这个维护界面是一步交叉的。所以在整在这个工作上面，整体上我们省内。
- [00:34:40 - 00:34:53] 说话人4: 在今年开始，相当于把这个成本费用整治这一块的这个整治合同范围进一步的下沉，保证这个整治范围和我们的这个维护界面保持了统一，就是。
- [00:34:53 - 00:34:54] 说话人3: 二分以上的。
- [00:34:54 - 00:34:55] 说话人4: 整体的这个。
- [00:34:56 - 00:34:58] 说话人3: 光缆层面的这个。
- [00:34:58 - 00:35:26] 说话人4: 整治，统筹为一张网，统筹为光缆网的一体化整治项目。就相当于加克装维，整体只负责在分二级风光网下一部分的这个皮线侧的整治项目。这样就做到了这个整体的光缆层面的这个整治，由一个合同项目去支出，一个项目合同一个合同项目去管理。其实呢，这个合同项目管理的这个便捷性，同时也。
- [00:35:27 - 00:35:30] 说话人3: 统筹去做这个光华网银行的这个整治工作。
- [00:35:31 - 00:35:47] 说话人4: 第二块呢，就是这个今年，整体集团公司也在推这个资本费用项目，成本费用下资本费用开支这块的倾斜。在省内呢，我们负责去考虑的这样一个，有线网络一体化优化升级的这样一个项目，通过这个。
- [00:35:47 - 00:36:06] 说话人2: 雅兴那个人，他在问：“他说，我们那个设备准备好了没得？”设备的。就是两台摄像机，还有两个ET机。ET机想去那边。摄像机在那边。摄像机还没有去拿，就不晓得。因为有个5095，晚上的效果不一定好。
- [00:36:06 - 00:36:09] 说话人4: 这个经过了一化的。
- [00:36:09 - 00:36:19] 说话人2: 没有讲的4101的那个，这用得起就行了。我其实我觉得有一个，都是因为有他有一台，他那个照的范围应该是那个大一点那个。
- [00:36:19 - 00:36:22] 说话人3: 吃饭能早点，我们就去接。
- [00:36:22 - 00:36:25] 说话人2: 如果你这台你如果不用的话，你换上也行。
- [00:36:25 - 00:36:27] 说话人4: 这个有码器，但是。
- [00:36:27 - 00:36:55] 说话人2: 效果比自己那个课里面那个好一些。它那个好一点就是不是那种，它晚上我们之前对比过，它那个存储占地面积比较小，但是它这个效果好，效果不好，效果好一些。那个真的占地要大一点，但是它效果好一些。对它的意思，这个都好一些。那它用那种。那我看，拿得到噻，应该还是，设备应该还是拿得到噻。拿得到，再那边有两一台也拿得到。
- [00:36:55 - 00:36:56] 说话人3: 那是哪的呢？
- [00:36:57 - 00:37:05] 说话人4: 这块呢，经过去年从24年到目前为止，四个步骤的推进，通过一个分层分级的这样一个故障调度机制。
- [00:37:06 - 00:37:07] 说话人2: 我我好像。
- [00:37:07 - 00:37:15] 说话人3: 是嘛？同样和那个烧烤，你的状态，心情，你的状态，很健康。
- [00:37:16 - 00:37:17] 说话人4: 出一句是裂痕，失常了。
- [00:37:18 - 00:37:24] 说话人3: 主题声，然后当前呢，我们已经看，也就是我们是在一个。
- [00:37:25 - 00:37:39] 说话人4: 像前面的这个第三三个阶段当中的第一保持期。后续呢，我们在这个工作当中呢，也是会继续加速，继续去深入到。
- [00:37:40 - 00:37:42] 说话人3: 各个方面呢，把它这个整体的进行。
- [00:37:44 - 00:37:49] 说话人4: 这个效能进一步做提升，更好的统筹做好这个一张光网网。
- [00:38:06 - 00:38:46] 说话人3: 各位专家，那个小鹏，我是蔡一峰，是听书人。下面我觉得汇报的是蔡总是一个，能够结合研究一个课题。然后汇报呢，是会三个部分，是非常，这是一个内容，有项目主题。那么我们先做呢，就是说了，通行的规划是，交通的一个不可再生的一个战略资源，也是阐述了，如何使用或者管控资源，关乎于运营商的一个长期的运营，包括少拓展。前期的一个什么，包括我们的前台业务，国家方案，包括公交的一些预覆盖和建设。导致我们的市政管道中的一些，管道之间瓶颈和低限。
- [00:38:46 - 00:39:18] 说话人2: 江苏那边他跟一汽机，他都相当于说用的差不多了，他准备都再把算法多考一下稳定性。如果可以的话，他都想德州魔也挂起。那我们就争取到时候周下周一嘛。如果你那边都差不多了的话，我都喊那个亚星他们周一都可以把个系统设备给他装起。到时候都配合一下，车需要看他需要他们配合嘛，可能远程支持还是能够。不行。还是一台没两台嘛。两台噻。一台估计有个钱了。要。
- [00:39:20 - 00:40:18] 说话人3: 这个弯曲要素的部分点，包括这个优化部分，说在管区内，这个优化项目，优化好的这个路段，运行周期的优化，包括优化什么？那么维护难也是体现在管理难、检修难。比如说在这个共建共享的一些这个管道里面，这个那个管控穿我穿你的，这个运营商的权益得到保障。那么另外一方面呢，就是虽然说这个指挥系统呢，也是掌握了这个530000段，这个海量的这个杆资源的这个设备，但是呢，缺乏这个路段的管理功能，难以是直观有效的去支撑我们的网络规划，难以去匹配这个标准，难以从全局层面去遏制和控制穿网化的合理性，包括这个有效性。比如说我们现在高一级里面说，这个位置处的管控配置多少，比如说主干道的管控配置多少，有没有开截流。那么我们现在就是我们哪些管道是。
- [00:40:19 - 00:41:18] 说话人3: 一道是主干道路，我们有些管道又如何优先控制？控制。所以项目呢就是立足于城市主干，第一个是主干是通过购买这个地图厂商的一个地块，做道路红线，还有路段级别的道路信息。结合这些特征，做出一个数据，对路进行一个综合分析，然后形成这个符合线网，符合数字，整个户外分布特点的一个城市效果。快速直观，能够全面的去反映这个道路特点。第二关呢是建立这个数字管理模型，去探索这个哪些可能问题，哪些可能需要优化的问题，形成一个示范，这个反映这个，还有一些这个优化方案，或者是模拟。我们的研究内容第一项呢就是建模和数据分析。我们从这个从厂商这边买，从这个地图厂商买这个，上去上海市6.50000条这个道路信息。我们对这个1490000条这个资源数据。
- [00:41:19 - 00:42:18] 说话人3: 包括这个网点资源，包括这个公交箱，40000点这个人机点杆基础设施，还有这个广告带，还有这个辐射带，也包括空间资源。也是就是设定一些这个范围，包括匹配这个一个消遣方法，包括匹配这个道路两侧的一些方法，把这些资源呢，都进行到这个道路这个范畴影视。这个其实也是为一些初期规划进行了一些很便捷的一些参考，比如说这个版图，或者说是或者道路，这些通行的又像的一些那个能力，也是能够方便去进行导出。那么项目成果一呢，就是我们从这个四维度，一个是管廊的一个情况，一个是我们覆盖情况，管廊建设情况，和管道使用情况。我们分区域分属地分区公司分中央维修区，分我产线的一个分布，就是构建出大概百分之多少分布在哪里。道路的覆盖率包括这个联通的。
- [00:42:19 - 00:43:10] 说话人3: 这个管道建设情况，我们包括了那些市政管道，也包括了就是那些，汇集点，和应急点的重建管道。使用情况呢方面，我们是六个利用率。那么第一个子场景呢是这个房屋情况。我们通过这个这张图，是也是大家可以看到，就是我们这些管道可能是占比是34%，购买性是达到了可能是占比88%。这两个呢是上海公司里面管道的百分之，主要比较大的一个比重。那么在万科市区里面，大概就是购买性去管建呢，可能是占50%，占八成。资金的话只有比例只有3%。这个说是能够体现出我们这个市区和，郊区和城区管道，也是我建议这个管道的一些。
- [00:43:11 - 00:43:57] 说话人3: 你说几场，首先最广一点，以管线为主，管线可能比较少。那么第二个场景呢是一个，我们的覆盖情况。那么就是说这个市政道路情况题目说不像是快递方面的这个，道路管道。那个覆盖率呢是72%，那个轨道交通呢是96%。那么在市区里面呢是覆盖率呢，基本上覆盖率比较高，在91%。所以呢通过这种这个清单式的话也可以对这个，哪些路段没有覆盖管道，哪些路段是管道，或提供一些这个清单作为决策的一个依据。我们也是设定一些规则，包括这个。
- [00:44:00 - 00:44:49] 说话人3: 表示覆盖率。第三个指标呢，是一个条件的情况。我们对这个路段是一个，节点进行分析，比如说打上这个标签。比如说我们这个这下图两张图呢，是我们是计划的交通简说，对不对？一些主干道路，次干道路，对不对？一些小路，支路，包括一些符合一些要求的一些，包括延伸一些道路一些要求一些标准。我们就是可以把这个一条路段，从道路级别和站点类型，来来这个识别它的一个接受的标准，然后去匹配现状是否满足。我们第四块指标呢，是数据情况。
- [00:44:50 - 00:45:48] 说话人3: 对这个线网很大，建立这个模块和这个图层。我们来说跟你就说，比如说以大红穿网四个光缆为红色预警，六个是橙色预警，八根大的红色预警。目前的那个系统会是的，只要一点点的话是50左右，这个是符合目前的现状。那么比如说我们搞一个案例，就跟案例，比如说我们从知识图谱上筛选了很多的点，黑一点点，它能够很快速的定位到这个黑一点点附近。这个一公里范围内的一个路段的网格情况。比如说这个盘库，从这个铁路盘库到这个铁路盘库，一般道路需要配置2~3口，但是一般道路。但同时呢又请示为这个，那就是贯穿汇聚点的处理的延伸的交叉路，不需要配置的话，它呢配置标准的是六。它呢目前这个路段规划的网格是20段，每一个网格50个。
- [00:45:48 - 00:46:46] 说话人3: 利用率呢是那么的101，其中呢超过100%的这个路段，所以呢就是可以把它作为地面清单数据进行加排。我整个项目的第二项也是我们是就是管道和井盖的分析。然后通过这个井盖来看，刚才说的是我们的信息管道和井盖，确认我今天把它进行一个整体真实这个关系吧，全周期的一个分析。我对这个管道进行分析呢，我们这个主要是认识到就是说自建的管道有井盖比较少，主要是在主城区。城区里面主要有信息管道。但是反映出的情况就是这个交叉情况非常严重，就是利用率或者说直接说现场摆放，可能交叉的路段非常多。那再对这个运行的管道段进行一个复理性分析。
- [00:46:47 - 00:47:46] 说话人3: 比如说这个管道里面的管道的经营利用率，它普遍还是比较低的。比如说资金管道里面是有的是2.5%，清洗管道有的是30%。比如说小型输送管，它的利用率可能也是25%、88、30%。这些都是因为有点空间的，包括它的接入管道网的比例也不算高，就50%，跟全网相当。我们在这个4.80000这个已经管道里面，有30000个管道段，它配置有点高，占比有62.5%。所以就是这个从上述的一些体现出来，一个就是前期储备的一个保护数比较少。第二个就是包括那些所谓的小型输送管，还是比较多的，包括整体利用率比较低。这也是会后续的这个是主控优化方向。那我们采取的通风爆发和这个一些反馈影响这个管道堵塞的因子进行了一个总结。我们主要是通过一个是使用管道，一个是无价值长距离小型输送。那这体现出来就说。
- [00:47:46 - 00:47:47] 说话人4: 这样子就不好，或者说，比如说。
- [00:47:48 - 00:48:37] 说话人3: 其中关键退湖，或者说是，这个就是真的几个专线，低一些废弃的光缆，还没有进行拆除，还是在我们国庆剪断。第二个是这个光缆路不合理，包括，跨区我们以这个匝道七段的原来那些，跨区的接入光缆为主等等。第二个就是这个接入光缆，主要把它堵在道路上。第三个就是，由于这个匝道拥塞，造成了有些光缆的迂回。比如说，我们导航从A到B可能有几两公里，但这个光缆在市里面可能路四公里，进行绕路的。又比如说这个匝道搬迁，规划方案不合理，没有在就近的途径进行剪断进行终结，造成这个光缆路不合理。我们小青说呢，这个主要是，体现在这个投入站的光缆会收敛。什么意思呢？就是比如说，这个小区的建设可能是一个更好。
- [00:48:37 - 00:49:33] 说话人3: 没有，如果前期没有传输合理规划的话，那么小金属上来的光缆，存在这个路由比较长，然后这个利用率比较低的一种情况。就比如说这个一级光交建完之后，二级光交没有，其实已经建设了。那么早期的一些这个专线的光缆可能直接会接到一级光交，那这也是没有经过梳理的。就比如说这个复兴大院的这个光缆利用率肯定比较高，但是呢它通过我们拨通设备之后呢，它的路由可以进行缩短，通过经营的需求。那么管道的话是包括这个管道，这种权益，包括这个管道建设不足，包括这个路，一些断头管道，包括长距离的一些道路两侧没有沟通。那我们综合上述一些这个管道因素，因此，从这个能力维度、建设维度和使用维度，我们分了这么一些指标，进行一些权重评分来评估每条道路的一个这个计划度。
- [00:49:35 - 00:50:25] 说话人3: 这个情况包括一些覆盖率，整个情况包括一些使用的利用率，和使用情况呢，就是覆盖这个八个这个光缆的一个情况的意思。刚才说了一些，主要是一些这个，高价值、低价值，或者说市场区的这个光缆的一个情况。直接举了一些例子，可以把那个每个路段里面的一个瓶颈，或者说是不足之处，就举一个例子。同时对每条道路线的一个档案，每月去跑一次这个，有一个道路每个每条道路的一些情况。不是，就是在系统里面做固定档案。这些数据都一个几个月跑一次，流量比较大。按照这个路段，比如说我们全国有六六60000公里的路段，一个路段去跑一遍，把它的资源关。
- [00:50:26 - 00:51:25] 说话人3: 之后的话，那资源利用率，你的方案能进行优化。像我从国外呢，就是一些这个优化场景和这个策略的描述。那我们也是列举了一些一个优化场景，给给我们大家去交流。一个就是废弃光缆拆除。我们拆除光缆呢，我们在测试里面是掌握了很多，就是断路光缆。比如说这个，比如说一些末端基站退服，包括末端的一些这个专线的停闭。一般我们光缆的话，只就直接简单带门口，没有进行系统的回收。所以在系统里面会有很多这个长距离的一些断路光缆。我们建议呢，就是截断或者是回收，或者是这个拉到这个上海站预留。那我们可能上海那个每个离站近站，由于烧楼，远站的话可能有些的协调费。所以避免二次进站的话，可以做一些预留。第二个场景呢，就是头路段的光缆收敛。比如说我们有一个站A，A到B，B到C，A到D。
- [00:51:25 - 00:52:24] 说话人3: 都有光缆，那我们可能是放一个A到接头包，再从这个接头包去割接到B到C到底。A到接头包这一段呢，可能光缆这一段就可以进行一些这个腾挪。那么场景三呢是这个光缆路由的优化，我们是分有四个小场景。第一个呢就是以这个传统的基站到基站的光缆，那么这种情况呢就是它的费用比较低，然后它的光缆可能因为夜晚一些是SDH或者是早期的音频链路，所以随着这个老旧设备拆除的时候呢，也会很多一部分迁新，做了一些业务的调整，然后光缆就主动的一个拆除。第二款是这个承载一主要承载这个加班业务为主的一些一个接入光缆，达到OT这种光缆，我们可以去挑选一些这个利用率低的或者是跨区的长距离的进行一个换模调整，有光的一个缩短。第三个是一些几个专线为主的一些一个末端的光缆，大多之内二级光纤点。
- [00:52:24 - 00:53:14] 说话人3: 那这样的话也可以去提升二级分二级光交的一个利用率，也可以去缩短这个业务接入距离。那么第四个是一些这个C源拉远的一些这个方案，可以也是可以做一些C源去接入光交网，去缩短这个业务接入距离。那么这里结合一个案例分析呢，我们可能去年做了一个地铁搬迁，在这个人民广场就在我们在市中心的最中心附近。那么搬迁时候呢就发现就是主干道路上一些，次干路上的一些道路比较紧张。并且这个地方是没法加牌，只能在市区里面。那么对于这个南京路上一个路段进行分析呢，这个该路段为主干道路，应该配置8~15的限流使用。其实我们的就是购买是，孔数是储备到位的，但车辆方案确实比较多。
- [00:53:15 - 00:54:03] 说话人3: 利用率是113%，达到黄山预警。那么就是线网的这个百号已经需要做优化了，已经没法再去外去购买或者或解释。那么50个光缆中的小金光缆占比呢在60%，那接入光交网比例也是40%，是跟大五相当。那主要结论就是50个光缆里面有12根价值光缆，可以通过对应方式进行优化。那第一种是无业务的直接拆除一个，可调整业务畅通拆除的，是有四条。通过各级调度，10光交网可以拆除原光缆也是有两条。那么因此我们通过这个优化方式一、二、三之后呢，就是也是结合这个基站搬迁，搞重建的时候把这个路段上面，举个例子就是把这个路段上面的可能22组，这个利用率有113降低到86%。
- [00:54:05 - 00:55:02] 说话人3: 通过以上的一些这个研究我们，基于现网我们还是给出了一些这个思考和建议。第一块就是加强这个资金管控的一些储备，包括这个对于隧道大桥一些长期宝贵战略资源的一些储备。第二块就是建议是加强对于这个新增光接入光纤网比例，比如说是小新数，我们这个小新数主要定于20根及以上，这个距离超长距离的占比的考核。第三块就是这个对于这个分对于这个路网分成分级进行管理，比如说对于这个一干土干呢就是这种大型的这种光缆，它的路由呢尽量是要沿主干道去进行规划和设计。而且这些功能呢也是可以通过这个路段管理功能呢也是可以规划到这个系统，在设计模块里面去。那么后面几块呢一个是这个这光纤共享的一些权益的使用，包括这个后面还有一个叫汇聚点数光纤。那这块也是我们站公司。
- [00:55:03 - 00:55:55] 说话人3: 也是做了那个2323年的试点，就是说我们可能在一些比较长期自由的这种汇聚点的延伸段，延伸到两旁边两个路口各设立一个智能公交箱，这个智能公交箱就是替代这个街头包的一个作用，我们可能市区里面的人井打开，因为街头包里面的数量比较多，然后它的预留盘留会大量是占据这个维护空间，所以呢我们这个智能公交箱呢，进行一个收敛作用的时候，能够比较有效的去提升这个汇聚点门口那一段管道上的一个资源储备和利用率。后面是一些这个比如说这个管道预警的一些使用管控，比如说这个我们电信上海电信，它还是对这个资源管控，做了一些这个原则，比如说是莫控不串放光缆原则，红色预警这个不串放光缆原则。
- [00:55:56 - 00:56:35] 说话人3: 它还是加强了这个什么储备，因为你这里的预警如果不解决，你放了人光缆，毕竟是绕路的。最后一点就是加强这个基站搬迁的一个管控。在这个搬迁的情况呢，一定要对这个方案进行一个合理的审核，杜绝这个来回串扰的情况，防止闭环。项目呢总结呢就是一个就是形成了这个路段和这个资源模型的一个算法和模型，并且对这个转换进行初步验证和实现，呈现了这一个外的一个呈现。第二个是。
- [00:56:36 - 00:57:28] 说话人3: 网络安全的模型，对问题点进行分类和问题的剖析，形成这个策略和模型和case的论证。我就汇报完了。大家下午好，其他领导，这边，我广东公司呢是代表，这个叫做什么，我我是我个人吧，也是我个人代表我们负责这个政企专线维护的同事。简单的对这个广东省内的VCP的一个DNA改造的一个情况，做一个情况的一个介绍吧。这个题目呢其实是关于网络安全方面的。
- [00:57:28 - 00:58:19] 说话人3: 一项内容，我们的这里面涉及的网络呢，可能是广东省特有的一些情况，然后可能跟别的省份的情况可能不一定完全相同，所以里面提的一些情况也是想仅供大家参考的。接下来我就简单的把这个情况先给大家介绍一下，我们网络的现状。第一个就是全省，从全省的这个结构来讲呢，我们是以广州为中心做了一张VCOTN的一个新型的网络，大概是在2019年就开始做建设，然后呢，基本上这个设备厂家都是大主要是以华为主的，初期上的时候都是以华为主，后续陆续有0星的上了一些中兴和烽火，总体结构的话就是以广州为核心。
- [00:58:20 - 00:59:11] 说话人3: 然后广州这个核心的话其实分了六个站点，核心站点，然后是站街是用一个mesh化的主网，然后其中有三个站点呢是长途的节点，然后是对各个地市去对开一些vc的链路去做业务的转接的，就跨市的那个，链路呢就在这三个节点去开通，因为当初vc建设的时候呢，计划部门可能这个就是属于一种尝试性的这种态度去考虑嘛，所以这些vc的跨市的部分其实都是跟本地的vc设备是共用的，就没有单独建干建的vc的这样的系统，所以的话后续会引出一系列问题我待会提到，总体来讲呢省内的这个结构就是跨省这段是这样的一个情况。
- [00:59:12 - 01:00:09] 说话人3: 然后本地的话呢，结构也是比较相对比较清晰吧，也是分干线出口的节点，然后多层，第一层是干线出口的节点，然后第二层是重要汇聚，第三层是普通汇聚。在此这三层的这个基础上，可能就有CP的设备通过双规单规或者是其他方式吧接入到这个VC的这个网络上面去。这个结构上面来看呢，我们核心层的话都是用口字型的结构，然后相邻节点呢是采用灰光连接。底层是基本上会用波分承载，而且路由上面主网上已经是要求做口字型要做分离的，有条件的话都会做WARP或WMP保护吧。然后重要汇聚对之间呢，它原则上是不做汇聚对之间的那个互连量。
- [01:00:09 - 01:01:00] 说话人3: 目的也是会让这个主网会更加的清晰。普通汇聚这一层的话呢，基本上是用V型的结构跟上级的那个中央汇去做一个连接。总体的那个主网的带宽呢，也是以10G的带宽为主。这样的一个情况可能就是我们最初建网的时候就按照这样的一个进度去做。这样的规划。曲线的那部分我们原则上不搭，其实搭也可以，就就是让结构清晰一点。实际上没有搭，对对，实际上没有搭。然后这样的初期建设这个网络呢，其实当时可能也是一个尝试吧。所以它在这个主网上面其实还是有一些。
- [01:01:01 - 01:01:52] 说话人3: 安全上的一些不足主要就体现在两点吧，两部分。第一个呢就是我们一个跨市的一个业务为，不市内的一个业务为例吧，它是配的是普通SNCP的那个保护。这种业务的话，它端到端都在一个室内，是吧？用普通SNCP保护这种方式的话，其实在整个室内的话，它就是一个主备就是一个冲突域吧。然后如果主备之间的跨度越长的话呢，双断的可能性就越大。然后通常来讲，只要有一次触断，第二处再断的话，往往就会造成这个业务中断了。这是这个室内业务用普通SNCP是存在一个不足。还有一种情况呢，就是跨市的时候，我们往就会用分段SNCP。
- [01:01:53 - 01:02:47] 说话人3: 就是室内CP一到出口之间呢可能是做一段，然后对端四也是做一段，就多段的这SSCP。但是这种SSCP的保护呢，它其实问题就在于出口的时候都是集中在一个节点吧，就跟下面这张图里面，可以看到CP一它都左边的CP一都要经过N一六再出市到对端B四，这样的话这个N一六这个网元如果出问题的话呢，很可能就这条这专线直接就断掉了。所以的话，在这种结构下的话，虽然专线它分段保护了冲突，就是这种双段的冲突域会缩小，但是其实对于单点节点的这个隐患来讲，它它还是扛不住。所以的话对应的话，这个分段保护其实也是有它的。
- [01:02:47 - 01:03:44] 说话人3: 一样，有有它的不足。结合的这两个现有的保护方式都不够完美这样的一个现状吧，我们就也是去想看有没有合适的技术可以借鉴的，可以协助我们把这个保护能力进一步提升。参考了SH网络里面的DNI的这个保护能力呢，我们也想有没有可能把这个能力引入到OTN里面去。其实DNI这个东西是在SH时代已经早就有了，它本质上其实就是两个跨环的系统吧，做一些双节点的互联。这个互联的方式可以是四节点，也可以是两个节点，标准的话其实四节点，但是我们日常应用的时候可能通常只有两个节点，就做成两个环相交这样的一个结构。其实刚才回顾刚那个图。
- [01:03:46 - 01:04:40] 说话人3: 我们其实分段为SSCP就是两个环相切嘛，现在话其实要扛单节点，无非就是要把节点增加嘛，所以就是用双节点去做相切这样的一个结拓扑结构，去在结构上面先把这个安全的问题先给满足了，SH其实那个时代的话为什么我们一直都没太部署这个DNI，是因为这个DNI其实就是要做很多的业务交叉，去实现分段的多点的选收的这样的一一些业务的保护的，但是呢这个SH时代大家都知道可能还是国外厂家为主的一个时代嘛，所以都是要人工去做配置的，人工或者是效率都不太高，所以普及性也不是很高吧这个DNI，但是OTN这个时代呢，说说实话是以国内厂家为主。
- [01:04:40 - 01:05:27] 说话人3: 所以我们也是把这个想法和现有我们现网VC的厂家华为做了一些沟通吧，然后就依托它的S一的一些功能或它后台的一些平台吧，开发了一些做配交自动化配交叉的一些工具，然后把DNI引入保护的设涉及到的一些交叉配置这方面的一些能力补足了，接下来我们也可以也会再详细的稍微介绍一下这部分的情况，引入DNI保护的话其实理论上是可以做节点级的保护的，这一点从理论上我们已经有这样的一个设想，然后接下来其实简单的来看其实还是我们刚才讲的，就是。
- [01:05:28 - 01:06:22] 说话人3: 无非就是把环相切变成环相交，然后它的核心就是从环相切的话就是东西向同一节点东西向做SSCP交叉，变成是环相交的DNA保护队之间做SSCP的交叉。其实原理应该还是比较简单的，只是说通过交叉的冗余去实现节点的那个交叉的保护的一个选择。代价无非就是把交叉的容量消耗多一点吧，这个在OTN的这个时代来讲其实也不是问题，因为现在单个OTN节点的交叉的带宽容量也很大。所以的话我们就往这个方向去继续去尝试吧。对应的话呢我们在广州。
- [01:06:23 - 01:07:14] 说话人3: T网的VC的OTN的环境里面的去选呢，两个主网的环境去尝试，就手工去配一些交叉，实现这个DNI的这样的一个保护，配的交叉业务包括US、EU、O和CLAN的这种业务，然后在这个配上去之后去模拟，链路的多点故障，还有节点的故障，然后看我们的这个网络的实际上配置能不能下发，还有那个倒换的能力是不是能够符合预期，然后模拟故障的这个情况也是包括模拟单处故障三单纤双纤，三纤还有红联的故障以及单节点的故障的这几种故障场景，其实从这个场景来看的话我们。
- [01:07:15 - 01:08:12] 说话人3: 很明显看得到，就就场景一的这个结构其实就是左侧的是一个CPE，然后双上联到一个DNI保护队，这个DNI保护队就是配了一些保护交叉或者是多重保护交叉这样的一对设备。场景二是，所有末端都配了这样的一个的DNI保护队，两个的区别其实就是它是一对和两对DNI的一个主网的这样的一个差别。这两种场景会比较适合适配吧，本地网目前的那个专线开通的这个情况，所以我们就选了这两个场景。然后这两个场景的话，我们的线网做手工交叉做的那个导换验证，还有保护验证的话呢，总共是做了一些下面的结果是这样下面这样的一个情况。首先是基础的业务验证方面的话呢。
- [01:08:12 - 01:09:07] 说话人3: 无论是CPE到CPE，还是CPE到CO，还有CO到CO，这几种场景下的业务创建，还有单纤故障、双纤、三纤，还有红点、单节点故障呢，在网管上面看到的状态都是符合预期的，状态都正常的。然后从倒换的性能来看，我们是专门以CPE到CPE的U/S的业务做一个验证的，端到端因为要画表嘛。还是做了一个CPE到CPE的业务，是100兆的这样的一个数据，这个上面其实是，倒换时间也是在15毫秒以下的，时间也是符合要求的。我们可以看到就是，我们从单纤故障、双纤故障还有三纤故障，这三种场景是可能，这三种场景下其实，我们的通过横连这个。
- [01:09:07 - 01:10:00] 说话人3: 途径是可以构筑出一条业务的这样子可通达的路由的，然后横联的情况下还有单节点的故障下，其实它也可以继续就是业务也可以继续通过剩余的一条冗余路由去实现单道端的连通。结果的话，我们从现网的测试的效果来看的话，无论是我们测的100兆，这上面显示100兆数据，还有两兆、10兆、20兆等等，还有UoClam1000兆的这种带宽下，其实它都具备了这样的一个抗多点老化，还抗多点保护和抗单节点故障的这样的一个能力。也就是说这个配置其实跟业务的类型关系不大，然后跟业务的速率关系也不大。
- [01:10:00 - 01:10:49] 说话人3: 就是一个比较普适性的一种保护的一种能力。根据这个这样的一个结果的话，我们其实就继续下一步的一个设想，对我们现网的一个VCO天的主网情况做一个总体性的一个诊断。其实除了DNI这种需求之外，我们由于建网比较早嘛，可能而且前期的投入也不大，所以的话，除了这个单节点这个还有链路过长有设备同时中断的风险之外呢，其实我们还有一些那个出入局同路由，或者是短时延误路径的原因，导致这个业务配置会有小段同路由这样的。
- [01:10:50 - 01:11:31] 说话人3: 风险，然后还有带宽上的不足，特别是网深，可能实际带宽开几个客户可能就满了，这种情况可能会比较普遍。所以带宽也会成为我们现在这个这张网目前存在的这张网的一个不足之处。另外的话呢，还有就是我们新型主网这个结构下呢，广州有两个核心的节点，支撑了西帮村这两个点的那个潮位的利用率非常高。然后本地和干线都会占用这个网元上面的潮位，所以的话业务量一上来可能用不了多久，这个网元的潮位想再扩就很难。
- [01:11:32 - 01:12:19] 说话人3: 所以总体诊断出来的话呢，就是会有四个毛病吧，只能说我们这个这张网现存是四个毛病。然后对应的话，我们定了一个总体的优化方案。首先就针对四个方案四个毛病吧，开了四个方子吧。第一个就是通过D N H去保护来解决单网元故障和多点中断迁移的风险。第二的话呢，对于同路由的问题呢，我们还是在本地侧增一些O R P和电路加干线侧吧，加一些S S P的保护，解决同路由的一些风险，就尽可能去避免。第三呢，就是把我们跨市和省市内上联到。
- [01:12:19 - 01:13:11] 说话人3: 那个链路呢，是做一个100100G的链路的升级，解决我们实际链路带宽偏小的这样一个问题。另外第四点就是做分列网元，就是在广州把本地和干线的这种业务把它，带网元分开了。新增一对的这个DNI的这个网元呢，是用于跨市业务调度的，这样本地和业务就彻底分离，会会缓解我们这些资源不足的这个矛盾嘛。然后策略上的话呢，在这个新的这个主网方案下面的话，我们跨市内的业务呢会在普通汇聚和中央汇聚配DNI，然后跨市的话呢会在普通汇聚、中央汇聚骨干接入。
- [01:13:13 - 01:14:03] 说话人3: 我们的分裂的那对核心节点吧，也配D N I，波分系统的O R P的话，因为本地网会有一些图纸上的限制吧，所以的话，第四的这个是不太可能配S N C P了。但是目前的话，按照广东省内的这个安全的一些整治的一些要求，汇聚以上都是要做O R P保护。所以的话，目前第四的这个层面呢，在外线上面主要是做O R P保护去那个提供。然后省干的部分的话，S N C P的这个保护呢，我们是做单边，这个也是一个折中吧，就是口字形双上联的这个链路，如果双边的话，可能投资还是。
- [01:14:04 - 01:14:53] 说话人3: 所以跟规划部门妥协的一个结果就是做单边，就只要有一边能够保证，SSBP其实就等于是三路游了嘛，三路游的话这个保险系数虽然没有四路游高嘛，但总体来讲还是能够接受的。所以的话在省干的话我们做了跨市那个是配单边的SSBP，当然每个省份如果这个资源充足或者这个条件比较好，也可以配双边，这个完全没问题。然后对应的话我们这样开完这四个方子，其实是这11系列的策略之后呢，总体我们的效果会主要就是两个，第一个就是业务安全性肯定会得到一个本质的提升吧，因为抗单点多点还有突发的风险这些。
- [01:14:54 - 01:15:46] 说话人3: 都提升了，另外的话，这容量也得到了增加，因为实际到100是有10倍的一个链路的带宽的增长，总体能够满足今后可能比较长一段时间的一个业务需求。对应的话，我们会靠到线网，可能对第四做一个主网上的一个指导，比如珠海公司，它的主网就很单纯，它的可能初始就是一对群光大厦和南屏二期楼这样的一个节点，然后对接上去也是两个节点，这样的话，它就直接在这个，现有的这个网络比较简单的结构上，我们就按我们前面开的那个方式，把它室内的设备的D N I横连的这个电路线路上去，这个横连电路是个100G的。
- [01:15:47 - 01:16:46] 说话人3: 然后跨世界物也升到100级，原来的10级就不用了，或者是先保留等，后续是不用，先暂时保留，等100级上线之后就会可以撤掉，然后就做一个简单的一个联连接吧。其实整体来讲，它它的这个改造的这个难度也不大，就是室内加一对口100级的，然后跨世加一对的，这样的话就可以实现我们那个这个目标的一个结构了。然后这个是比较常规的一个方案，我们是可以跟施工司去做一个指导性的一个要求，然后施工司可以据此去跟当地的规划部门去提一些具体落在本地网一些项目上面的一些建设那个项目去。然后另外一个就是佛山的这个结构其实跟珠海有一点点差。
- [01:16:47 - 01:17:45] 说话人3: 它就是在一对山水通信中心和这个德胜这个枢纽，这个中间它是通过一个业务节点，一个OTN节点去穿通的。我们改造的时候其实就是要把这个穿通节点给去掉，我们让两个出口的节点直接就穿通。其他的情况其实跟珠海那个模式也是类似的，也是一样，就是这个横联这个，我们之间做了一个100G横联采用那个，辉光纤的辉光或者是波分电路型的。然后100G的这样的一个数据，它是也是配，辉光的这个SNCP的这种电。然后输出，总体就是把B四的这一场输出的一些方案给，施工师做一个参考吧。然后接下来的话，从主网的这个结构已经明确之后呢。
- [01:17:45 - 01:18:33] 说话人3: 可能我们就要解决前面提到的这个交叉这个问题怎么办？这个交叉这个改造的话，其实就是DNA保护的一个核心内容之一吧。其实就是要增加各种的双方选中的交叉点嘛，然后形成多点之间的SCP保护。然后这种保护配置其实，需要如果人工配的话，需要人工人脑比较清晰。然后还要去找一些空闲的时期去算，会这样的话对应的话，可能人工参与的这个成分比较高吧。然后一个是时间要求高，对人的要求也高。然后呢，它是通常都是要先删掉原来的业务，然后再创建那个DNA业务。可以，对于我们VCOT来讲呢，因为它承载的都是专线嘛。
- [01:18:36 - 01:19:24] 说话人3: 要征服。所以总体来讲呢，人工去做交叉，还有这个断业务式的这种方式呢，会导致我们的绩效的更低。所以的话，我们就联合华为对针对这种的改造存量业务的改造吧，做一个做了一个专门的一个工具。这个工具的话呢，就可以完全把上面提到的两个问题给克服掉了。根据我们的这个目标的话呢，其实这个人工配置交叉改为，依赖这个割接专用工具去配交叉的话呢，它的时间可以缩短到从原来15~10min，可以缩短到三分钟一条。然后每管能割的业务数可以翻5~6倍。按三个小时上。
- [01:19:25 - 01:20:12] 说话人3: 所以整体来讲，对我们对存量业务的改造，还有这个安全性或者可靠性来讲，它它都有一个比较大的提升。而且客户呢，他对我们的这个改造可以是无感知的，因为我们通过工具，实现了一个无损的，一个调整。就是通过改造过程中做一些业务倒换，先倒背，再改交，数据的交叉，然后再倒，这样的方式来回的做一些连串性的动作，会实现这个业务的存量调整。所以整体来讲，这个改造的这个效率问题，也可以通过工具去实现。当然我们讲的可能比较简单，但实际上后面。
- [01:20:13 - 01:20:59] 说话人3: 实现的话，其实还是比较多内容的。我们这部分我们跟华为也磨合了比较久，然后也是依赖依靠华为的这个研发的人员、主管的研发，还有设备工具的研发去做这个专门的工具。现在目前也是做基本上做出来了，也能适配现网的一些场景。我们有在试，所以这下面就是我们讲的，就是这个工具大概是今年四月份才做出来，然后我们做出来实验室验证完之后就放到现网去做一个验证了，就看这个工具在现网用起来的效果。然后也是适配各种的业务类型吧，还有验证它在执行。
- [01:21:01 - 01:21:52] 说话人3: 正向改造，和意外倒回这样的一个能力，是不是符合我们的预期？正常来讲，我们现在对这个工具，因为这里面我没有展示这个工具的能力。其实它的工具其实是，可以说一个可视化的一个界面，就是执行一个脚本。其实脚本是通过华为的一个平台去生成的。这个平台生成脚本是，先采先往网上的数据，然后去分析，它的一些空闲失线情况，然后生成一些脚本。然后你可能要告诉他要做哪一条SNCB的业务，要增补DNI，他就会分析那个空闲的失线，然后输出一个脚本。然后这个脚本是导到一个外挂的NCE的一个工具吧，去去下这个脚本。这个脚本主要是一个。
- [01:21:52 - 01:22:46] 说话人3: T I港是改造的一个可视化的一个呈现，它可以看到每一条业务它执行的过程，就改交叉的这个过程，改到哪一步完成了，然后哪一步要往回退，要实现这样的一个能力。这个工具最终的话其实是花了大概差不多大半年吧，然后前台后台验证和那个才弄出来的。主要的这个功能需求方面，我们其实也是结合我们日常的一些习惯嘛，就是还必须要打回的能力嘛，能去做一些自动化的分析，就不需要人工介入去找时间这样的一些去弄。然后这个工具的话，我们放在现网中，那这个网络呢去验证也是分了几个场景1234，这里面可能不会有一点点小。
- [01:22:47 - 01:23:39] 说话人3: 场景一其实就是，改造前后其实那个CPE上联的那对汇聚网元呢，都是就是必要配DNI的这个网元。然后场景二呢是，这个改造前是，改造前后都是新的一对重要的汇聚，然后CPE呢是没有直接连到中那个DNI的那个网。场景三呢是，改造前经过的重要汇聚已经换掉了是新的一对重要汇聚，就是新的DNI保护的那对重要汇聚跟原来的业务是完全是没关系的。然后场景四呢是，改造的这个是经过那个不同的DNI的那个重要汇聚网元，但是。
- [01:23:40 - 01:24:35] 说话人3: 普通汇聚呢，是原来的普通汇聚。这个也是跟广州公司去沟通吧，可能这个场景可能在本地，四个场景在本地会比较常见，所以我们也是用了这四个场景去做验证。我后面会提，因为目前我们其实是跟华为在做的，因为网络的情况我就说了，其实就是我们大部分是华为的，所以我们现在还是以华为探索性的吧，先把华为的先做出来看效果。回退测，对，测试倒回我们也测，就临时终止，然后让它自行回退，或者是直接执行完了再回退都可以。而且它这个执行呢是按业务来的，就假设我这个网联上面有100条业务，我可能跟客户约了是做今晚只做10条，然后这10条我就当晚只做这10条的脚本下去。
- [01:24:35 - 01:25:27] 说话人3: 然后下到一半，比如说做到第一条就出问题了，直接就回退了，然后面可以暂停，这样的，可以做到这样的一个效果。目前这是跟我们自己的维护习惯比较相似。对。然后这个改造验证的结果，我们简单拿场景四去做一个演示，这就是SC上面的一个截图。这个结果其实原来就是主端这样的一个主备方案，实现是主用备用是虚线的这一条路由。然后改造后它其实就是在中间的这个4519645197这两个，加了一个横联。其实看上去它没有太大变化，就多了个横联。但是其实的话，就是在哎两个横联的这个网元之间加了若干的交叉连接，去做SSCP的一些防护传输。然后网管上面看出来，其实就是。
- [01:25:30 - 01:26:19] 说话人3: 然后改造的这个时间，确实是耗时也是达到我们的预期的，然后呢业务也是没有中断，我们是通过话表去做一个验证，无损的这个效果还是比较确定。我们现网客户没有感知，不过我们其实是试验的时候，我们是拿仪表去测，对，拿表去测呢，就没有真正拿在我们的业务去试。现在的话我们在网业务我们也做了一个改造，这个改造确实是无损的，这个就是我们就是验收的时候跟科委协商，因为验收的时候发现他有个物流的问题，就是本地网它广州到揭阳这条专线吧，在揭阳这个地方呢，它放了两个不同层级的部分，一个是一级部分，一个二级部分。
- [01:26:20 - 01:27:09] 说话人3: 它就不可避免可能有些部分全部是同源了，然后发现了这个问题之后呢，但是业务客户其实已经上了，所以说客户已经上了，但是没办法，我们就尝试用这个D N I去改造，直接把它改过来，顺便测一下这个无损的效果。其实也跟客户打个招呼，然后客户这边也同意我们去做。做完之后其实我们原来的那个故障点就是上下这两个点一段，就是故障到CP这段就全断了嘛。然后改造完之后它的那个路由就可以这样绕下面，这个把就是绕这个上下这个点这样过去，把故障两个光缆段其实都绕开。这样的话其实测的话，这条两A的专线其实也是可以的。客户那边给我们其实他都没有反应，改完之后他都没有反。
- [01:27:11 - 01:28:02] 说话人3: 就是这个效果来看，还是在实际的这个效果来看，还是可以的。其他的话，我们是做了一个计划，就是对这个线网改造案例，我们一步来。就到了线网改造，确实这个也试过了。然后面的话，我们总体我们其实有个这个计划的。这个计划其实简单回顾一下，03年开始做一个验证嘛，然后中间会涉及到跟规划还有本地工程的一个扩容交互吧。就是扩容链路还有那些端口资源提供出来做主网的这个规划。所以总体我们到还有分列我们觉得建设是一体的。所以大概是而且中间我们自己的主网的预备情况已经历了大半年。中间华为厂家去做那个工具的开发。
- [01:28:02 - 01:28:57] 说话人3: 还有线网的一些磨合试用吧，也也花费了比较长的时间，所以我们真的是在今年四月份才开始去做这个实际存量改造的这个验证。然后呢，后续的话，我们暂时计划是在今年底把重要的专线的B N I改造做了。其实也只是做重要的专线的部分，也不全量，因为全量的量还是一个是比较大，第二的话呢，这部分可能改造还涉及到一些费用，这方面还没定。所以我们只会对一些重要的专线去做一个考虑。然后这里面反正就从24/03到今年目前那个情况吧，大概会接近两年的时间，会把这个重要专线这部分的这个改造做完，从无到有吧。反正这整个过程，可能回顾一下觉得还是做出来还是有点价值，自己感觉。就是反正摸按摸吧，也是跟厂家也和。
- [01:28:57 - 01:29:57] 说话人3: 然后自己也会提前想法这样去做。然后对应的话，这个改造的话，它有一些要求吧，比如说链路，还有规划主网上面的一些要求，可能内部要先协商好。另外它网管版本也要适配。然后R2~3这个可能大部分省份可能已经开始在升嘛。然后设备版本的VC设备呢，要R二一以上。然后改造的这个工具呢，现在其实应该开发出来了。正常来讲，如果各个省公司可能比较强，应该也是能用的。但是这个产区不在广东。就是它这个其实是比较强烈依赖于厂家内部的一些资源分析，是脚本这个东西暂时我们自己是没有办法去自研去实现。因为可能跟底层捆绑的比较多。但是这个工具确实现在也支持各种类型的一些无线改造。我们可能自己去做的话，主要在工作台，就是下面工作目标里面。
- [01:29:57 - 01:30:44] 说话人3: 预计工作台，我们把新增的那部分通过D N I的这个工具的能力去在新增业务我们自己去做。存量的业务因为还是改起来会比较复杂，所以还而且可靠性也可能相对没那么高了。所以我们存量的那部分可能以就会倾向于用厂家的工具去做，新增的部分就通过我们自控作业台的那个开发去适配了。无非是多笔交叉，可能新增的这个业务做断了应该会有点大，做错的可能也还好。所以的话，我们会在新增的部分考虑自己的平台去做一个能力的一个实现。另外的话呢，在厂家方面，也因为这位那个专家提到的，我们在也在推中心的O T N这部分做一个。
- [01:30:45 - 01:31:33] 说话人3: 能力的一个开发，中兴目前反馈的话就是，EOS的版本已经具备了，设备和网管都已经有，但是EOS的话还在做一个研发，上面的一些准备吧，预预计是今年底。但是这部分呢，它也只是做DNA的一些功能，对于这个存量业务工具开发，可能还在第二阶段没那么快，这个可能还得再等吧，因为广东的这个，量主要是华为嘛，所以中兴这边我们放在第二步，烽火那一块的这个，因为就这个量更少，所以我们现在还没考虑，或者哪位省公司可能有哪些省公司可能有这个条件呢，我觉得可以尝试一下，行。然后这个整个过程大概是这样的一个情况，然后我这边的分享。
- [01:31:45 - 01:32:43] 说话人5: 各位领导，那专家大家下午好，辽宁公司也给力。今天主要是跟大家那个，分享和交流，这是市道县路由自动管控的一个实践，和SPN三跨或者是跨县区、跨地市、跨厂家的能力的一个实践的一个交流。主要分了四部分，一个是背景，一个是原始传统的那个本地逃生的一个思考，还有一个是高铁的一个逃生的一个实践，还有SPN那个三跨能力的那个验证和实践。这个背景就是去年八月，19号的2012，我们那个葫芦岛建昌，因为是那个台风导致，建昌市道县的多条路由，因为三条路由，市道县是全部中断，然后造成了我们整个建昌县的一个三个乡镇的一个通行受阻，然后建昌地区就90%以上的那个车站都得掉。
- [01:32:44 - 01:33:32] 说话人5: 然后在这种三段的情况下，然后我们就来思考一下，就是我们怎么在这个OTN和SP这个网络，然后能不能够进行自动逃生的这么一个想法一个探讨。这个呢，就是在传统情况下的OTN的一个流程的一个思路，就是比如说我试道线环的一个逃生，试道线，全组的情况下，一般呢我通过第三路，通过第四路，然后我在通过跨线区的这两个跨乡镇的这两个，或者是在利用我这一个跨省或者跨市的这个干线资源的这一个逃生。这个场景一就比如说我试道线拓扑方案全段，但是我第三路有第三我第四路。
- [01:33:33 - 01:34:31] 说话人5: 每段的情况下，我就可以人工到现场，然后把我的那个实到线的观览通过第三路由第四路，跟人到现场去给讲明。然后场景二呢，就是比如说我实到线观览就全阻断，我的三速路由也全阻断，是吧？然后我的传统的方案就是看跨线区有没有这个逃生的观览逃生观览，然后人到现场到这个，这辆车的这A二这个局，然后跳先跳到咱们的B一这个局，然后B一这个局中有空线信号，再回到这个核心局一，然后回到核心局二，这样一个传统的逃生。如果是距离太远的话呢，我可以带着咱们的放大版，到到现场去，到这个B B这个B局B一局的现场，然后把那放大版插上，然后借助咱们那个光放大，然后咱们造成，这也是一种一一种思路。如果前期没有前期不足的情况下，我们可以临时把这个B一到核心局这个这条缆给它断开。
- [01:34:31 - 01:35:27] 说话人5: 利用它的立救千斤，是吧？咱们也可以从这儿逃过去，上来回来，回回他这边的。这是咱们传统的一个一一个逃生的这么一个思路。这是长这是场景二。场景三的话，就是我这两个线区之间没有那个可用的逃生光缆，但是我这两个，东区下面有普通的咱们那个现场环境，这有逃生光缆。我也可以，在紧急情况下，受到线圈组的情况下，紧急来进行人为的现场逃生。就是人到这，就是咱们的抢夺人员到这A二这个局，然后借用他这个光缆，这光缆的扣眼千斤，然后再转入到咱们这个A一到B一的这个逃生光缆上来，然后回到B局，从这儿再上来，就像红色的这个线。然后可能有的地区上，然后是距离比较远，咱们可以携带着咱们会带着咱们放大板，是吧？到现场去查在哪看哪。
- [01:35:27 - 01:36:24] 说话人5: 电源设备，咱们给他接上，然后让套用套上。如果说是没有空压潜芯了，也可以在紧急情况下，比如说咱们没有空压潜芯了，我们断开，让这边的环有一半可活，然后让咱们借用它的空压潜芯上来，给它俩再回到咱们这里。就是这样的一个现场的一个人为的，到现场的这么紧急的一个逃生的这么一个思路。然后这个场景二也是，世道线所有光缆全阻的情况下，然后呢我这个跨线区还有线区之间就是没有可逃生的光缆，然后呢我可以借用我干线的这个，还有光缆资源还有干线这个资源来完成，然后我这个世道线的这个光缆的一个逃生。就是我A线区正好是它当地，有我们的干线的那个资源，然后通过干，A线区和干线光的光缆，然后再通过我干线的这个空压潜芯，然后再迂回到我这个核心。
- [01:36:25 - 01:37:19] 说话人5: 然后中间距离可能远，然后咱们就得写那张，看哪个站，找一个比较合适的这么一个站吧，把那个咱们放大板都给拆了，然后作为一个临时的这么一个现场抢修的这么一个思路。但是所有的上述的事情都是得让咱们人到现场去，而且还得那个熟悉咱们的机房，熟悉咱们的设备，还得对咱们的天线，还得要了解。所以说这就是一个，我们就在探讨有没有一个什么可以自动实现的，对吧？就是我们试到现在OTN光缆全都是什么，通过自动的一个思路来实现的一个。下面就是咱们一个，就讲咱们有一个自动误差系统那种一个实验，然后我们也是做了一下验证，应该是还是可行，因为在后边是能有。然后这个就说的是那什么。
- [01:37:20 - 01:38:14] 说话人5: 前面是引入那个，欧沙西，就是欧梯上自动公交车的这个，嗯一个场景。就是比如说这个是盘锦大娃，是本地油田，他到盘锦，就从这边来，是到盘锦是吧？他10号线全阻了。他对只能逃生呢，只能通过盘锦到营口，这个这营口也是我们二二干设备，通过这二干设备。然后大娃来了，到营口直接就回到这个，进入二干的这个四杆，直接就回到这个盘锦市了。就是这事儿是盘锦大娃的这个套装。然后鞍山这个也是，鞍山的这个套装，他也是正常，就是鞍山本地泰安那个是吧？本地油田，他10号线到我鞍山综合楼，对吧？这10号线断了，他也可以通过鞍山本地油田。就是就会让我干线的盘锦综合楼，然后是回到营口辽河，然后是回到鞍山海城。
- [01:38:16 - 01:39:10] 说话人5: 这样的一个通过这个岸那个逃生呢，它也是需要人为的到现场，然后那个去进行跳纤呐，然后去查板子呀。然后这两个有个共同点，不管是攀井捞蛙还是我这个安神泰安，它都是经过了我这个引口调和的这么一个点，然后去通过这个引口调和这个，我就引入了我们这个自动关节差的这么一个设备，然后也怎么样一个技术，来实现无论是我攀井捞蛙还是我安神泰安发生摄像头线冲突的情况下，我能不需要人为到现场，通过我这个摄像机自动来逃生，然后自动通过二干来迂回来，然后来实现我这个摄像头线上全部导下的这么一个网络的这么一个自动逃生。再就是SPS逃生。
- [01:39:11 - 01:40:01] 说话人5: 因为是上次虎岛这个发生了这个市道线中断之后吧，我们也在思考，S SP呢本来它就有这个L三的这个能力，为什么S就是为什么不能通过这个我这个能力来实现我在当我市道线关缆全阻的情况下，我业务能够正常逃生。无论是我SP是承载在OTN下，还是说我是关缆指导的小车上，都需要来通过这个SP的这个本身的技术能力，然后来进行这个逃生。然后当时我们就想到了一个，就是通过SP这个市道线全阻之后，我们是不是可以做这个跨线区的逃生？如果跨线区逃生，如果比如说线区到市内是吧，比较远，我是不是可以进线区跟其他地市的线区就是相邻，我是不是可以通过这个跨地市来进行。
- [01:40:02 - 01:40:30] 说话人5: 如果说，跨地市之后呢，而且这个地市呢，比如我本地市是华为的，我另一个地市呢，是中兴的，我可不可以通过跨厂家这个进行这个来实现跑通？这就是我们还在，思考和实验点的那个，一个什么，我们叫做了一个这个神话吧，我们叫神话的这么一个跑通测试，而且是，效果是达到了我们的预期。这个呢就是，我们现象还是就是我们统县区内，我们。
- [01:40:30 - 01:40:32] 说话人5: 有个光缆中断的。
- [01:40:32 - 01:40:35] 说话人6: 我想到了，我我天呐，他说。
- [01:40:35 - 01:40:41] 说话人5: 我讲的是什么？没有，能自动套声。就是那个，这个就是通过什么？以前咱们。
- [01:40:41 - 01:40:45] 说话人6: 是吧？我也没参加，我忘了。
- [01:40:45 - 01:41:44] 说话人5: 接入环，咱们换了一个路，就是每个汇聚环换了一个路。然后我们省现在就是把一个SPN下面，所有的换到了一个路上。然后通过这个，无论是，然后把这两个线区之间，光缆可能再给它连上，就相当于迈上铁路了。通过它SRB组实现了这个网络的这个SPN的这个多机、多场、远、多级的计算过程上的一个自动逃生那种一个便捷。这个就是咱们刚才说的那个高铁自动逃生能力的一个验证，主要是这个。这个是是，因为咱们南盘锦，就是刚才咱们块儿干说的这个，就是南盘锦大巴到盘锦三号桥，它有四条线，有有两条路，它是一个方向，主备是吧？主备方向。然后呢，鞍山综合楼到台安，它也是有两方主备。然后第三路友呢是通过我们干线的是另一个方向。正常的话，我们盘锦的大巴，它不管是。
- [01:41:45 - 01:42:34] 说话人5: 两条路有三条路，它那个就是全是比如说全是由西往东走。但是我们这个应急路有，因为它是从西往东走，绕开了我们这个，不管是三路、五路或几路这个风险的跨河，是吧？我绕开我的河，我通过二干的这个，通过我另一条，比如说我通过五号营口，再绕回到这个盘锦。彻底的，我这个应急范围就是咱们市道线的地方，我两个就全部避开。就是刚才咱们照片里边，也就是这个，比如说我从盘锦到完到市内市道线，它是这个方向，对吧？我市道线去全走了之后。然后但是我有一条应急的干线，一条是从一路方向过来的，它是净是从西往东。那时候我逃生命令是从东往西，然后通过干线过来，然后通过干线又。
- [01:42:35 - 01:43:34] 说话人5: 草能回到我们，看见那个。然后说的就是这个。然后我们采用的是，主要是采用的是O R的皮。最早大家都是1:1的，然后我们采用了O R的皮，1:1:2的版本，就是主倒背，然后背在段背在倒背，就是就相当于是主用段了，我倒背，然后背回用了，再倒到背，就已经挺够了。咱们最早的不知道O R的皮，O R的皮不都是1:1的那种吗？就是一发一手，就是我一个主用一个备用嘛。现在我们就是现在能就是咱们奥杀系列，如奥杀系列的，如这个，就得是我正常是不是一个工作两个备用。我主用段的时候，我先倒一背在段的时候，我倒2:1。可以定制，也可以大家有的也有两两套板卡，就是两套板卡也可以融合在一起。你说我正好备有一个一主一背嘛，或者备用来了再接到一个板卡上。不对，那厂家也参考过。就是我们这个是单独的板卡，就是它。对，都是那个光学和独立的都。
- [01:43:36 - 01:43:37] 说话人3: 我是三毛的。
- [01:43:37 - 01:44:35] 说话人5: 三八的，就是光迅和中裕的，我看光迅和中裕的都有做。然后有了，我们已经验证了。对。对对，就叫做多层保护，但是吧，多层那个保护吧，不是说还是这个方向的，只不过是咱们应急的一个方向。对呀，就是正常受到天降都得有三条护栏，就是我们省得要对这受到天降必须有三条护栏。但是你这三条护栏吧，其实也是一个方向，以水过人，也是可能这个河这么走是吧？也是可能三条路就跨这个河。所以说我们这个应急是不怕河了，绕到其他地势上去绕过去，通过干线自己。这就是一个这样，就是提供了一个应急路，就是跟主备路由不同方向的一个应急路，来实现咱们说应急的逃生嘛。然后就前提就是这块放了个1:2的，也可以是咱们以前的1:1:1的，就是我有两块板子，主用进来是吧？然后出去了，然后备用进来，再进另一块板，然后再出去。
- [01:44:35 - 01:45:29] 说话人5: 实际上还是原理上其实这么原理，就实现了咱们的这么一个。对这要长很多嘛，刚才老师长很多嘛。然后这个，这就引入到刚才的我们这个欧卡西的这个设备，就放在这儿。欧卡西设备里面，它也是，咱们这个二干手，二干那个机房里边，可能也有中型的库，每家都有。拿两块放大板，第三个一是一发一收两个方向嘛，要插在咱们设备上，插在那咱们那个光旁光方向上。作为它的咱们东西，它叫这两块板，这是咱们的放大板，就插在咱们的光网线上。插上之后，然后咱们这会儿还有一个欧卡西的设备，就是，两轴的这么一个设备，它是可上管的，可现场配置的，它是通过光开关的。就比如说咱们这个盘点大妈的这个，这雪山上接在这儿。
- [01:45:29 - 01:46:22] 说话人5: 通过可以网管可以配，就是我配到这个，我这边有一个放大板嘛，我配到这儿来。这个都是事先接好的，就是这个了。我放大板，这些线都是事先接好的。它是通过咱们那个一个网管那个可以对它的进行，然后光开关配配。就是我这一口背后这个二口，我可以配到10口来。然后我这个，那个是安装方向的，我这五口也可以配到10口来。当当我这断的时候，对吧？我这光我这边光就过来了，过来之后，它它这边，它这个光进来之后，它发现，我收到光了，然后我就光开关打开。我这个，这就是这样嘛，就是我的光进来之后，然后他发现我收到光了，然后他那个光开关打开，然后这光从这进来经过我的放大板，放大了嘛。放大之后，然后出来，因为它事先配置好的，然后从这走出去，到这，到我的这方向，直到终点。
- [01:46:22 - 01:47:15] 说话人5: 方向就上，它就是这么一个东西。但是你得有光缆能到这儿。主要是你对，主要是你有光缆能到这儿。你看我们边上有营口做的这做的实验的，因为我们泰安也能对都能到营口，就是它的光缆，通过都能爬到我这个营口看一下的。然后我就通过这个通过只能到我这个地方来，然后我就可以进入到我这个自动观察设备里。然后我就可以。对对，至少得有第三条路由就是。底跟原来咱们世豪线全同一路由得必须得是能分开。对。然后就是通过这么一个几个点来实现的。就是因为去年我们那个建塘嘛，世豪线全断了嘛，然后也是抢修嘛。刚才那个谁，济南的超导也配合这种也说了我们建塘那个事儿嘛。
- [01:47:16 - 01:48:03] 说话人5: 但是呢，你人没到现场嘛，对吧？你人到现场去到机房里跳线，对吧？你们这不就有时候散乱，然后转路了，到机房很时间很长。然后我们就探讨，能不能通过就是这种自动的这种方式来实现这个。其实就是比方，如果说大家说，如果说有第三步有的话，我们举点比较少的话，可能不需要这个观察器，对吧？因为我就我觉得一条路，我直接我这块直接，那我放大板，直接我就把它去做。这只要有一个这个bar的皮，这个要有这个。如果这个就相当于是我为啥你观察器，就是我多个本地的站点，要进入我这个，然后进入这个机房的时候，才能通选择。如果是只是一个方向的，不需要选择的话，就不需要这个。
- [01:48:07 - 01:48:54] 说话人5: 这个就是基本就是这么一个设备。对对，做完成过。因为咱们这个方大板嘛，就是咱们那个，一个方大板一个铲子，咱们这个比如说这铲子华为的方大板是吧？一个铲子华为的，光盘是吧？对吧？然后它就是，这个是咱们什么的嘛，就是专用的嘛。就把它的咱们方大板，一发一声，方大板一发一声，给接在我这边后边洗这个设备，就已经接在这后边洗设备。就是这方大板其实就咱就说咱这儿方大板其实就已经接在这上。它是个，这个后边设备是一个，多多接口。这玩意儿就现就用用22二点15。这个什么嘛，这个方大板，咱们知道吧？我一个发方向，一个收方向，对吧？在当时咱。
- [01:48:55 - 01:49:34] 说话人5: 。对通过刷机。对对，就是我通过，就是它也是有网管的嘛，它是有网管的，可以事先配上，就是我这个，比如说给他，我盘起这个方向，你来了，进来之后，然后我不得，进了之后，然后我让它到底放大板，对吧？进去放大板，那放大板出来，那出来这不正常不得啥吗？不得这个。在内部，在咱们在内部可以做光开关，然后我可以走这个方向嘛。对，去下一个方向。对对，我这机外壳可以配多少个方向？内部可以。三高。
- [01:49:34 - 01:49:45] 说话人2: 错了，身高给你道歉，应该叫身高也好。你说开会么？没有，我就说一个，不测他，对你我直接用语音在播，随便在看。
- [01:49:45 - 01:50:42] 说话人5: 的使劲。感觉到我过来之后，光开关儿不，就他这样说，平时他妈都是得配好的。他说：“你这个自动调节都配好的。”然后我们光就过来了，过来之后呢，我这个自动交叉光我们就把它打开了之后，然后他就开始按照咱们内部事先设好的这个方向，他就出去了。他他就是经过了这个放大板，就把这光一放。我不感觉啥，这不是暗杀方向的，不是这暗杀方向就来了吗？对。对，这他有多口，有暗杀来了之后也在这，他也是事先配好的，到这啥，出来之后就这。对。我们测试的是这天津那个大牙印牌，你知道吗？就边从这到。模式不是，它是那不真的是。对，是有两油的，那么一个小盒子。对，就是个黄开关儿。不是，就跟R的P，这都三八呢。
- [01:50:43 - 01:51:39] 说话人5: 对，两优小盒子就是，他说有的都有30个光纤口，对吧？就是我把各个的都插。不是内部的。它就是。对，就像我交换机，只不过是光交换机，光的对。对，物理上。但是他通过网管上可以配置我这个口，我这一口的光往哪走。对，因为你想实现自动的话，你就得。对。有网管了，可以网管。有网管。就我们，你可以通过M的信号把这网管拉到咱们省端上来，你也可以在现场，都可以。然后下边这个就是，刚才说的那个三跨的，这个场景就是咱们主线区的，就是我这个线区内我的那个我汇聚、双断呢，或者说我接入环双断呢。我我们省就是把原来的不是，每个汇聚环下边和接入环双断呢，我我们省就是把原来的不是，每个汇聚环下边和接入环双断呢。
- [01:51:40 - 01:52:32] 说话人5: 现在我们把整个五个都是下边，换了一个用。然后就是根据你的观览情况，就是我这两个汇聚之间有光缆，对吧？光缆距离呢，它说还比较近，然后还能搭得上，对吧？接触之间的或者是能够搭上。就是一两点之间能搭上，就能保证我这个双端的情况下，我可以通过那个什么S R B E是吧？或者是先S R B，然后套成之后，然后再什么，我们把S R T B组组，就是S R T B组组，全部S R T隧道全部变成通路，然后把全部的功能全部打开。就是在我任意两点终端的情况下，然后都可以自动合成。这个只是那个图像区的情况下。然后下面这个就说是我那个视道线，还是说或者回头又说到我们视道线。比如说这就是我们那个建长对吧？视道线全组的。
- [01:52:32 - 01:53:24] 说话人5: 赤道线全阻也是两场景，一般的这个，管控的全阻，一般是管控路全阻。因为管控和咱们那个上行吧，应该都是同缆，或者是都是通过OT或者PT上来。只不过是赤道线断了之后，然后咱们的管控也断了。然后我们就是做了两次逃生，第一次就是我们国防队之间，就两个县区国防队之间。然后我们找那个再找条光缆，然后给它连上。然后普通飞机之间，然后找光缆连上。然后前提就是光缆距离吧，然后这个要就是不能大于8810公里，因为我们用的是百G的这个模块来实现逃生。然后就是，如果是超过百G的话，就光缆直达可能光缆二层，性能就性能不够。然后就连上。然后我们测试的时候就比如说我连管控我带那个上行全断了。
- [01:53:24 - 01:54:24] 说话人5: 我的业务，然后通过这个，首先是通过这种最低第一个命令一，然后我觉得从什么，就是如果不断的打路容跨区的，到时候这个L二的，然后几颗业务，或者说到时候那个什么业务，但是咱4~5G的业务，那只能是模拟，4~5G业务什么的。前提是在这儿打个玩，就是在我们黑龙江这边，找了一个板卡，有两个碰线板卡，就是咱们说百G的也行，因为我们都是做这百G的，就两个百G板卡，然后现场咱们先打个玩，然后咱们呢就是咱们这要保的这个线区的S P S P对之间的找S P来打玩，这目的是啥呢？就是通过这个L二这个U M，这不你看咱们去打玩这个其实单播数据，一个是N M，一个是L二N M，这边是上面也是是L三的L三L二，也就是通过这逃生路径来模拟出一条。
- [01:54:24 - 01:54:28] 说话人5: 其实我跟朋友现在不是，怎么说是这么说话了，但是。
- [01:54:28 - 01:54:40] 说话人2: 天天是这个像特别要有文化，可以来做。你可以自己，特别是年龄的外国去。你你的录音拿出来，已经在回忆。那不得两个。好，轻松了。
- [01:54:40 - 01:55:38] 说话人5: 他两个项目了。因为I L R I的业务来模拟这条光缆，它就像用的。就是原理，不管是跨线区域、跨地市，或者是跨厂家的，原理都是这种原理。就是我通过业务，然后模拟出一条新的光缆，只不过是这条新的光缆是我，是是，就是绕我来的，绕的。正常的话，我10号线直达的，断了之后，或者通过一条，不管是L R I业务，还是在干什么业务，做的很。模拟出一条新的光缆，然后导致我上游的，都是从这儿过来。然后这就是，我们的这个跨线区的人们一个自动逃生的一个思路。然后也就是说，对流量上的，然后有要求，就是看一看流量，就是你选择多大的这块。如果说你想只想保多不保质嘛，就是我发生的10号线光缆全部是中央，我我线区线上全美的情况下，我只保我的通话，我别的通话只是能。
- [01:55:39 - 01:56:31] 说话人5: 通话就行。然后咱们也可以选择，我这块我们省都做的验证成功率百斤。如果说我没有百斤的话，我可能有10G的，或者说也可以。知道普通话你是。首先，我我就是在那个上行，比如说我正常的我们省，比如说其他省上行流量，那说100%分之20，这边是20%，对吧？然后合起来，是，那说就40%，百斤的40%G的。如果说你说我这10G可能就，质量就不行了。咱们可以用50G的，可能百斤。在它的同时，就是这么，划线区域就是这么一个百斤一个数。它这个也是，就是我不仅是那个射道线双断的时候，它优先是走那个，等我那个，买这个时来优先走第一，我一段的时候，然后我再走二。然后比如说咱们有条件的话，我可以，比如说我在普通接路上，在50G在两。
- [01:56:33 - 01:57:26] 说话人5: 只要是光缆情况有具备，就是到时候这样都行，光缆都两个够。只要是你两个线局之间有光缆都可以。咱们就可以做这种什么线光缆勘测，这样都可以。那通过这种线局来进行投射，那就是这种。一个投射的这么一个思路。那我们省也是，做了好多线局的，那个朝阳那个卡，就是卡索，连元卡索呀，丹东的，还有辽阳灯塔工厂里，我们省这个做了，已经具备了地方。投射的，我们又做了验证的，我们也是。其实就是每个地市我们每台嘛，我们都会验证一遍，它是没问题的。回过头来，这就是。跨地市，就刚才咱们说的这是，我这个片区吧，因为我练了一下，你对我本事的练了一下，就非常。
- [01:57:27 - 01:58:11] 说话人5: 跨式的线群，它俩。在这个情况下，就是我市道线光缆去传输的情况呢，我可不可以通过立线的，带我来逃走。也是这两样，但是都是中心的，也可以。那就是也是，但是只是这个短路，也就是也是这么连上，进行这个短路。然后刚才那个干线区呢，它是那个L三的，在我自己一个网管内部，这是因为跨网管的嘛，它是网管，这个有网管的，另外那个都是有网管的。屋里，都是一样，只不过是这也是，那我给我打了个弯儿，我在这个在这边也是打了个弯儿。也是打了个弯儿，这个就弯儿，也是打个弯儿，也就是相当于我你一条光缆，就是我市道线光缆全部，我你一条光缆。
- [01:58:13 - 01:59:13] 说话人5: 再到这儿，也是新生成一条路，适合先关了。适合先关了，也是，就是跨越区域跨二干。这个就是，因为这是两地市嘛，两地市互通的情况下，这都是北京的网。那怎么从A地市回到B地市？就通过二干子，就提供了一个北京的。然后他们这块儿对互联互通，然后这块儿互联互通。然后通过，然后这边也是，就是通过这个，我A地市，我做点L二业务到这儿，然后我我B地市做点L二到这儿。然后通过二个，它都全程互通。然后就可以实现我们这个系统。我是适合先关两全程的情况下，然后至少保证我4~5级业务。就是4~5级业务，然后能通过这个，通过咱们这个投成业务，然后来后面来保证我就是在抢眼和抢眼的时候，我我还有业务，还在。我是管不掉了，对吧？
- [01:59:13 - 02:00:05] 说话人5: 管控掉了的话，那咱们有几颗业务是吧？跨跨区域的、跨域的或者跨区域的业务，那几颗业务不保。那如果管控没掉那些，那几颗业务也能通过S I P P重构功能，那也能重构。都是这么样的一个场景。这个测试的时候，应该是有点那个跨城。这是跨城市的，我这华为一个什么一个华为，当时是测试的，就是我上一段的话，第一路的时候没问题，当我第一路再段的时候，111111，第二路的时候，完了，结果那个路断续续。那华为给你解释，他那个频率是，他那意思，他说他是九周期，但是每周七是10s。
- [02:00:06 - 02:01:03] 说话人5: 它是整个周期，发现整个它，在这去完保之后，它才水，才才能走到那个第二，走到这个。我们说，后期呢，应该是有专门的，他们都知道是把这个升级就能解决，最后解决这个问题呢。这个也是我们省的也是，在那个，在铁岭拍人和沈阳康宁，这个是我华为的，然后鞍山T C和这个北方电视中心的，然后是湖岛联想和锦州，这个是有个峰，S P的，这三家每家都会都做的这个时间演练的。这个基本上是就是，没有问题，那4~5G的只能说是升级，然后掉的话也没有。那其实，在我们掉的，对他们那个，所以那个，差不多了，还有那种发现区的这种，因为它掉的之后，没法重播，没法那个导致他们那个，那机壳的也会，那化学。
- [02:01:11 - 02:02:02] 说话人5: 没有视频是没问题。这是这个，快递室的。最后这个就是咱们这个，他俩一样的这个。跟刚才快递室那个是，嗯是的。快递室，你比一下，唯一的区别，这就是这个，华为的这个东西或者这周星的这个。两个SP的这个一个厂家。那是也是的，比如说线群，只跟这个华为的线群，只跟这个周星的线群，他俩近，往往这样同它同，也是可以的。那原理放在那是一样，也是。我把两个SP都连接了，或者什么的，我把个后羿只连接了，或者我接入了，或者我接入个后羿连接了，都可以。都可以的，长什么来，距离也都可以。那都是也是什么？距离，也不超过85m。而且这个测验证的在测试的过程里面，发现了一些问题。主要就是咱们那个。
- [02:02:03 - 02:02:52] 说话人5: 100G的那个八G的这个光块儿，没有这个没有同款。至少你看我们在测试的过程中兴和烽火。中兴的它那个80几G，就是85，100G85的光块儿，它就默认它的F V X。烽火的默认是不起。因为它是，我们不带潮了吗？每每家都有F V X的，就起也不行。后来这是怎么点的？后来这个烽火这个在底层上把它F V X，我们就起这个起。在那个，等到上面去，然后把它起。然后期我们就替代了，烽火那个把它，是吧？它不是，往哪几边儿？或者说这个，咱们中兴的，我们把这个F V X，我确定怎么用的是八，用的是85，反正可能就40，是吧？我们把这个F V X，我用，把这个。
- [02:02:54 - 02:03:47] 说话人5: 然后还有就是，华为和中央对接的事，也都在这85m光杆儿块儿。那也是就是对不起来的。就是让华为的这个，他两家把一个微信功能打开之后吧，在这华为呢有一个叫什么，哎什么杆儿块儿，一个正序一个反序。然后咱说一个中央是正序，华为是反序。然后呢，也是华为在底层，给他改了一下这个步配序。就是现在就是这个测试，就就是在这85m光杆儿的街道。是是有一些连接。那这也是找的是什么？找什么国家？然后把这些东西，然后看，同一个那个界面，然后打开什么，我可以跟着你自己家自己对接的时候吧。你都可以，但是比如说你用微信什么对接的时候，你光晚上我有一个功能，你知道，我这个啥？微信，是不是开启，是不是关闭，对吧？然后我这个正序反序，是不是把这个。
- [02:03:49 - 02:04:38] 说话人5: 就是重要的一个测试点，这么一个，因为这个时间，这个也是在，沈阳是华为的，那大连是是，大连是宁都区的，然后这个是锦州是凤凰的，然后天津是华为的，然后天津是东兴的，然后北京是凤凰的，就是每一个场景我们念着我们，就是绝对就是在，不管是你这上游，不管是你上游全段走，只能是不扔的，然后手机用，那是不断的，而且在路面也有点点点，也是的，像就是我手机断的时候，故障维修吧，就是你看我们上游，几乎故障维修是不完善的，再说我们本地是放什么的，咱不说故障维修，我我告诉你，今天车尾，我讲讲。
- [02:04:39 - 02:04:49] 说话人5: 这个他们说的，我说对了，我的，会帮我就。
- [02:05:00 - 02:05:51] 说话人3: 各位领导同志大家好，我是黑龙江俄罗斯的王月凡。下面我就今年我们亚冬会保障的一些说我们的经验跟大家做个分享。亚冬会保障是2月17日到14号在黑龙江哈尔滨举行。有34个国家和地区和1200名运动员报名参赛。也是说参赛的国家是亚冬会历史之最。比赛项目主要是六个大项，11分项和64个小项。共有13个场馆。其中哈尔滨有五个场馆承办的是冰上赛，冰上比赛。亚冰赛区有八个场地承办的是雪上项目比赛。我们规划的规划了169个重点保障场景。是共涉及2633个基站。的信号拓扑，高景，性能的一些呈现。
- [02:05:51 - 02:06:41] 说话人3: 广场景还包括含开冰制和比赛场馆，两站一场就是飞机场和火车站，冰雪旅游相关像冰雪大世界，重点的景区，重要的道路包括像火炬传递的这个道路。这次呢我们面对主要是以下有五个问题，第一个问题的是保障的场景比较多，车站、道路、比赛场馆一共是21个场景，保证的这个点有100多处，第二个是基站和传输链路无法自动关联，无线基站这个跨专业是目前是我们在做这个之前的是属于割裂开，无线和传输分别看各自的报警和定位，这个资源方面没有进行关联，影响了这个报警定位的。
- [02:06:41 - 02:07:41] 说话人3: 准确性，第二个是，原始的告警拍的量比较大，不易分辨出故障的根因，影响故障定位的和处理。第四个是告警和链路匹配的比较困难，由于这个传输和，传输这个设备比较设备的种类，比较多，然后和综资的链路采集呢有一定的滞后性，导致的这个告警与链路的主因关联性存在一些匹配的困难。再一个就是跨专业的告警匹配，无线网和传输网之间的各种信息没有，集成，就是无法判断是无线出故障的还是传输故障影响。那么基于下面五个问题呢，我们，先下面给大家介绍一下这个我们针对于这五个问题的一些重点的保障方案。整体呢是以传输工作台为核心，构建呢以拓扑自呈现和故障自定位为目标的这个管理模式，实现对关键节点的实时监控和故障预警。
- [02:07:41 - 02:08:33] 说话人3: 范围呢主要是，比赛场馆和相关的景区和重要道路。搭建的体系主要分为下面五个方面，一个就是基站与传输链的关联。我们通过，基站的信息和北向MPC的信息，实现了网元端口以及整体链路的，这个主备路径的自动关联。这是全面基于北向MPC数据的，把公司抛开了。同时也是同时也实现了二层与三层的这个关联映射。第二个是基站监控与管理，是我们拉管了2693个基站，进行全面的监控和管理。对接故障中心，把无线和传输到底都拿过来，将二者与上面的这个链路进行了融合，直观的呈现这个，各个那个各两个专业之间的告警。
- [02:08:34 - 02:09:23] 说话人3: 同时我们还制定了这个132个重要保障这个场景，进行了保障场景的分组，针对于不同场景不同基站，都能呈现这个多端的拓扑告警和性能的这个监控。第四个我们建立了故障等级的划分，按照红橙黄蓝四影响的严重程度和影响范围，我们将基站故障划分成了四级，这样的话有便于我们更快的找到所关注的传输原因导致的这个故障。最后一个第五点是智能化监控与预警，通过这个传输控制台呢实现了对通信网络多端拓扑性能告警的智能化监控，可实时监控这个网络的状态，有问题呢及时通知。
- [02:09:24 - 02:10:19] 说话人3: 那个历史公司进行处理。这个是我们的整体的这个工作架构，涉及了这么几个系统，主要是无线公台资源中心，就是总资，还有故障中心，从还有厂家的O M C表数据，将这四个数据呢，包括传输链路中进行捏合，实现了我上面所说的这些步骤。下面一给大家一一介绍一下。第一个是基站与传输链路的关联。我们通过基无线公台给过来的基站的IP微辣，还有基站的名称，去匹配北向数据中的信息。通过IP微辣，将无线的基站的信息与传输链路的信息进行匹配，同时，关联了四G五G的整个P T S P的链路。然后在公台中呢，我们通过北向的数据，按照集团之前下发的电视春节的这个。
- [02:10:19 - 02:11:10] 说话人3: 规则，把它的传输链路进行呈现，这样的话就实现了传输到无线的端到端呈现。同时，在对于PTN链路我们也实现了二层三层的自动关联。第二个是告警监控。这个去年其实分享过，就是我们是基于这个告警的压缩规压缩收敛的规则，进，来做这个这次压缩的保障的。主主要是什么？主要是通过传输端环内线外线资源机房资源，还有这个业务的关系模型。我们将故障传输的故障分为了以下几大类，八大类会13个小类。主要是主要体现为动网故障、电源故障、温度热线故障、硬件故障、单线中断、光缆中断和托管故障、网元异常这个故障。将这个我们之前做的。
- [02:11:10 - 02:12:08] 说话人3: 故障收敛的规则呢，对应到这次的保障中，通过基站的告警关联链路，在关联我们传输故障，涉及到这些收敛的告警，把这个端到端的这个告警和关联上。下一个是我们建立了不同的，众保组可以根据我们不同的区域、景区和业务需求进行详细的划分，比如说我像图里说的我们要做进行一个场景建设，我们先建设一个哈尔滨火车站这么一个场景，将火车站所关联的基站全部导入这个，全部关联到这个场景里，以此设置多个这个众保组，最后众保组里面的信息去关联所有的基站，进行一个分组化的管理。下一个是我们进行，红色关轮的分级管控，由于保障的场景和硬件非常多，我们无法直观的体现看到我们需要及时处理的。
- [02:12:08 - 02:13:02] 说话人3: 这些故障是哪些基站的，或者是哪些场景的？比如说像在开幕式期间，我们可能重点关注开幕式场馆，在非开幕式期间呢，我们可能重点关注一些基站，或者那个飞场和火车站，还有一些别的场馆。那么我们就是需要进行一个道路划分。我们是这样划分的：像红色呢属于有重大风险的，它是什么样的呢？是基站关联的传输链路上双链路有传输报警，基站侧有报警，这个我们定为红色是最紧急处理的。第二个是橙色的，橙色说明有较大风险，基站关联的传输链路上有单链的报警，基站侧也有报警，这个我们选为橙色。黄色是基站关联的链路上单链有传输报警，基站侧没有报警，这个是选为黄色。最后是最低风险，只有基站侧报警，传输是没有。
- [02:13:04 - 02:13:53] 说话人3: 就不需要处理。下面我们还结合了之前在集团的资源网络里做的同流分析，我们将同流分析的这个功能集成到了这个我们这次保障中，实现了主保基站关联传输链路的主备路由同流筛查，并可以跟踪处理基站逻辑同流，提升这个稳定性。主要是在逻辑上分为主备链路设备板卡端口的同流。大家可以看这张图，我们可以看到它可以直观的体现这个基站里我是有哪些设备同流，有哪些同板卡，因为它有哪些同端口，它有包括它是在主用和备用的这个同流上。还有这个。
- [02:13:53 - 02:14:47] 说话人3: 关注一下这个误码差距，因为在保证期间呢，我们发现，这个误报的这个告警产生的频率其实是非常高的，我们就将巡检中的这个端口误码信息和基站的信息进行关联，因为我们知道了所有的这个基站所经过的所有的端口，那么对端口的误码的巡检情况进行一个呈现，那么就可以查到当前这个基站所经过的这些链路的这个端口主备路径是否有这个误码的存在，这样也便于我们快速的处理这个故障。下面呢是几个案例，我们当像大家可以看那个例一，左边这个呢，我们其实就是发现了，两个红色的可以看到，这两个红色是上了一天是老端口报警，然后中间这蓝色上了一个网元托管报警，这里这块。
- [02:14:47 - 02:15:45] 说话人3: 我们把这个主要的这个告警呈现在这儿，这条是我们衍生的告警，就说明其实是由于这个，托管导致的这个两根的故障。那我们去这个水上乐园这个点去看一下，后续我们发现这个其实是由于停电原因导致的这个故障。还有这个，像这个我们是只有基站侧有告警，我们可以看到，这边呈现的全都是基站侧的告警，这是一个四级的基站。那么这个在这边呈现的也是蓝色，那我们这个可能我们就只需要关注就行，不需要暂时不做处理。还有我们对于这个在网络保障期间业务有不合理也进行了这个整改。大家可以看到左边这个是冰雪大世界景区的这么一个四级基站，四级站可以发现它的主干路径基本全程都坐在了一条路径上，那这个风险其实是很大的。那我们发现了这个之后呢，就通知地市公司去调整这个。
- [02:15:46 - 02:16:37] 说话人3: 发现它其实是有路由的，是配置的问题。然后它通过这个路由的调整，将主边连主备链路其实就是分开了，然后就完成了这么一个同路由的整改。这个其这个保最后我们说一下这个保证成效。保证成效其实我们也是基于去年的这个故障压缩故障收敛故障排单这么一个经验吧。然后把这个进行了整合，实现了这个保障场景。我们在分组的跨专业关联故障工单收敛，分区管控和关键的关键故障呈现这个方面，获得了一定的经验。保障了亚运会期间呢没有因为传输故障导致的这个基站的中断。基于这个经验，我们其实今年也在。
- [02:16:38 - 02:17:28] 说话人3: 其他场景的这个保障，包括基站大面积，base，大站的保障，还有，大概是一个四M带的IP城联网，一些重要电路的保障，还有一些重要集客的专线。把这些场景其实我们都在今年都已经开始做了，今年底应该可以把一些东西大部分都实现。我们现在项目部设置了132个重要保障场景，完成了2693个基站与传输链路的穿透。完成这些基站的同路排查工作，共一共发现同路问题31个，全部都完成整改。在保障期间呢，一共发生了80起传输单边故障，直属人员第一时间发现并处理，平均故障处理时长均在一小时以内。这就是我的分享，谢谢。
- [02:17:40 - 02:18:33] 说话人8: 领导各位同事，上午好，我是来自天津的刘立新，今天呢我给大家这个汇报的这个题目呢，是这个单芯双线光模块，然后这个天津的这个光缆租赁成本，困境的一个解决。先说一下咱这个我们这个课题的这个背景，因为这个早晨我们这个第一节课然后我这边，咱们今天讲一些就是稍微简单一点的东西，然后我这个非常简单大伙儿可能一听就明白了，然后呢但是呢这个对天津来说呢可能帮助还是很大的，因为呢就是咱们首先说一下这个两个背景，第一个背景呢是天津这边的这个因为地理位置的一个比较特殊，然后既为这个首都门户又是非常口岸，目前呢各个区域的就是这种重建的开发区，还有高新区这种。
- [02:18:34 - 02:19:26] 说话人8: 就是这种东西比较多，然后这些呢区域呢现在都是自主管理，在针对运营商这个基础设施建设上管理非常的严格，就是许多地方呢都是这个统筹管理甚至是自己这个建设自己经营，然后不许运营商架设这个基础设施，所以呢就是我们如果要是想做覆盖或者是开业务，就是清呢就是需要交这管理费，然后呢许多地儿呢就都是需要租赁或者购置这个资产，然后第二个困境呢是这个虽然呢现在基因为经过这么多年的这个包括管局的协调，包括各个运营商基就是集中一体的跟这个是就是这个商户呢去这个沟通，现在这个大部分这个重点区域的这。
- [02:19:27 - 02:20:18] 说话人8: 租赁的这个价格，基本上是已经固定的。但是呢，现在先新租赁呢，有时候面临一个这样一个问题，因为呢，先新租赁这个资源都掌握在业主手里。通常呢，业主是不公开这个工那个，就是这个具体路由的。然后运营商想租光纤呢，它就是都是业主帮忙给挑好的。然后这个具体距离呢，就是一个测试，用ODF打一下，看看具体距离是多少。其实就是业主想怎么挑他就怎么挑。然后这个距离呢，是我们那个运营商那边没法掌控的。所以呢，然后这个就是无可奈何被人宰割。第三个呢，是运营商的话语权不足。就是三家运营商呢多次就是联合起来向有关部门反映这类的问题，然后相关部门。
- [02:20:19 - 02:21:12] 说话人8: 面进行一些个就是统筹和这个调节，但是呢这个收效甚微。然后因为这统计区域呢，通常呢这个就是都是财政自主，他们对这盈利的这方面呢还是关注的很严格的。所以呢造成了现在的这个情况就是收入现金量从逐年的递增，然后租赁的成本呢，使这个分这个公司呢也是不堪重负了。然后大家可以看这个数据，基本上是每年都是以这个10~5%的这个比例，然后再提升的。然后面临着这个问题呢，这个还有一个隐形的一个第二个背景，就是天津本地呢，我们这边一般都不太使用这个单行双向的模块。通常这环路呢都是双人双向的，因为就是。
- [02:21:12 - 02:22:01] 说话人8: 一般的情况下就没有这个谐音这个量不足的这个忧虑，所以呢，这个通常这么多年呢都是习惯性的也就忽略了这个产品。然后呢，就是在我们这个经过多年经过很长时间的调研呢，突然想到了就是在租赁的这个场景，如果使用这个单芯双向光模块进行改造，会不会有一些意外的效果。然后这个时那个，就是由这个想法呢就确定了这个方案。先说一下这单芯双向光模块，因为这个东西就是咱们许多省市已经都用的，然后确实没什么可说的。然后简单的原理就是这个也是这波分复用的原理，然后包括这复协调的技术，近端串扰的一些抑制，然后包括呢它一个。
- [02:22:02 - 02:22:49] 说话人8: 双波长复用的这个路径，包括这个低成本方案，波长自适应校准，对称的这个传输架构，还有它这个现在产业链的一个矩阵的一个，整体的一个规模化和成熟化。所以现这个这些东西呢，所以呢，对我们来说这些东西其实它并不重要，因为它对整个方案其实没有什么效果。并不是我们并不是追求它这些个特殊的这些个，就是这个产品特性，我们追求的是什么？追求的是这个原来两芯的组联，通过使用这个单双线光模块，我直接可以对半砍。这个是，对我们最大的这个优势吧。然后再说一下这个方案的这个核心优势。
- [02:22:50 - 02:23:50] 说话人8: 一个说明，首先呢是改造便捷，无需更改跳纤，只需在A端的两端机房进行改造，不会惊动业主，也不会造成不必要的纠纷，因为呢这个业主对这个限行量的这个租赁，他是非常敏感的，如果我们贸然的比如说动它的光交箱，动它的那个承端，这些个对业主来说呢，他是非常敏感的，都会那个就是对这个运营商呢进行这个阻拦，但是呢我们这个改造呢通常只是呢，就是我只在两端，轻轻的就把这个一个限行我就拔了，就是这么简单的一个改造，对业主来说呢他感知不够，所以呢这就有第二个优势，就是这个优化比较隐蔽，然后因为这个业主呢，更改跳纤，有效的避免这个业主恶意的加强跳纤路由，然后变相的提高租金。
- [02:23:51 - 02:24:45] 说话人8: 而且呢，改造完成之后，在利用空间建设是保留记录，以证据，借此在谈判过程中处于优势地位。第三个呢，就是效果显著，就是直接可以压降至原有租赁量的一半，起效非常快。这个我跟大家解释一下，就是如果要是我们在就是大张旗鼓的去做这个先行改造，因为前期我们有过这一类的方案的一个探索，包括就是把整个这个租赁区域，划划成一个网格，然后进行这个综合右区的改造，或者是进行这个机房的这个调整位置，这些呢，业主这方面的，一个是拒不配合，这个是首先最大的困难，第二个是即使配合了，之后期的这个光纤跳纤的时候，还是有业主掌握这话语权，他呢就会就是比如说就是说提出了什么。
- [02:24:45 - 02:24:47] 说话人3: 因为我某个人光感坏了。
- [02:24:47 - 02:24:48] 说话人8: 我现在需要重新规划。
- [02:24:48 - 02:24:51] 说话人2: 我的臭老大哥会议。
- [02:24:51 - 02:24:55] 说话人8: 这歌我是不用了，这歌光拿你不能用了，我给你。
- [02:24:55 - 02:24:56] 说话人2: 唱好一点。
- [02:24:56 - 02:24:59] 说话人8: 然后呢，再结果出来之后呢。
- [02:24:59 - 02:25:03] 说话人2: 每次都是，我就把上一次的来改的呀。
- [02:25:03 - 02:25:05] 说话人8: 最后，整个合同的这个价格。
- [02:25:05 - 02:25:06] 说话人2: ก็ประมาณว่ามันคืออะไรไง
- [02:25:06 - 02:25:08] 说话人6: 那一篇还没有消息。
- [02:25:08 - 02:25:11] 说话人2: 下期又来了，想个点子又来了。
- [02:25:11 - 02:25:19] 说话人8: 全部的都浪费了，还有几条。所以呢，一种就是这种，写有点亏，我感觉。油霸非常隐蔽，而且不会惊动业主的这种方案。
- [02:25:20 - 02:25:22] 说话人6: 我还以为你又想了个新的点。
- [02:25:22 - 02:25:33] 说话人2: 我想得到，他之前那个，可能我把去年的每个段位拿来写，但是那个确实太差了写不出来，就把这个全一票的改了。
- [02:25:33 - 02:25:54] 说话人8: 给大家介绍一个本地的一个投资更改的一个案例，这个呢是天津这个滨海地区的生态城的视角。整个生态城区域呢现在都是统筹的由业主方开发商统一建设的基础工业的光缆。然后呢这从24年呢陆续我方以这个设备检修。
- [02:25:55 - 02:25:56] 说话人3: 情感实时改造。
- [02:25:56 - 02:26:49] 说话人8: 全部完成后呢，进入其他合作，开始跟业主谈判，然后签订定价协议，后开始最终完成了这个合同的改签压降成本。第二部分呢是，也采用了一些包括分布式OLT的部署，在以当今双向光模块改造的手段以外，如这个加个场景，我方希望业主将光纤这个线路终端OLT下旋置社区计划，减少主干光纤的长度，并且承担了就是机房的这个包括电费之类的，相对于一些其他的一些交换，相那个总的来说呢实现了这个成本压降。然后为了保证后期稳定，加强那个智能网管中心的集成，然后通过FBN那个控制器实施那个光模块的功率、码率的这个监控，动态调整发射功率。
- [02:26:51 - 02:27:44] 说话人8: 距离的一个需求，提升网络稳定性，完成这个设备。最终的成果呢是生态城整体区域的，总量呢，在2024年、2025年的那个开端吧，实现了313新那个新公里的压降比例为41.7%，全年的压降成本节约了16.340000元。这个是我们对这个方案的一个量化的一个对比吧。单晶双向光模块这个需要单独立项采购，替换产品用于，替换这个产品可以立那个立项的这个工程的立究，因为这个都是其实都是好的光模块，它就是双向的。我们就会拿出来放到别处，对比那个单价呢，以50GE的光模块为例呢，单晶双向光模块与。
- [02:27:45 - 02:28:30] 说话人8: 传统光模块单价约高200元，截止2025年合计增加成本不到400000元。然后加上2025年二季度合计替换单晶双向光模块321对，代维人员按照网格票前费用，然后进行那个付费，合计花费了7.20000元。截止2025年改造量面度，可节约成本3200000元。2025年有望实现租赁量与这个租赁成本的这个双压降势。随着这个项目推进的节奏，每况愈下。就是现在这就是这个生态城这边大约是150元，新公里每月。然后这个313公里呢，因为是就是在这一年中，随着时间。
- [02:28:31 - 02:29:26] 说话人8: 越来越多的这种不是一次性就改造了压降300，130公里，然后最后我们测算统一这个包括，对，300，300，就是从第一年比如说从一月份开始，10节，然后慢加，最后统1+1块，大约是就是压降的。然后这个全年成本呢，所以就是，它并不是说就是150乘以313再乘12怎么算出来的，它就是这个合同随着改造，因为还有合同谈判，还有合同签订这个时间就是通过这个延续吧，加一块算，就是130，三大约是这么有钱，然后到2015年，这个313就是整天计算，这个数会更大一些。行，然后那个就是这个案例呢，我们感觉跟我们这个想法可能有异曲同工。
- [02:29:26 - 02:29:49] 说话人8: 知道，但就是咱们比较熟悉的有一个是牙膏厂商的那个扩大牙膏那个口径的这个案例。因为呢，所以呢，就是我们天津这边呢有一个这个观点的一个输出吧。然后就是我们觉得这个创新呢，以解决问题为导向，不要盲目追求高大上，有时解决办法就在身边，却不被看到。好，谢谢大家。
- [02:30:00 - 02:30:22] 说话人9: 尊敬的集团公司领导，各位专家，是重庆公司全业务支撑中心陈友红。下面将向大家汇报重庆公司在传输利用率方面开展的工作。对于传输网络利用率提升，主要有两个方面，我的理解主要。
- [02:30:23 - 02:30:25] 说话人3: 一个是网络资源，不要。
- [02:30:25 - 02:31:20] 说话人9: 这样会造成既费钱买又费电。另一方面是网络资源的高效利用，例如业务量小又没有高带宽、高价值业务的地方，那就没有必要使用插机胖胖。这就是我们常说的“杀鸡焉用宰牛刀”。重庆公司在网络运维中就遇到了这样的情况，下面将从背景、采取措施和下一步计划三方面进行描述。为支撑千兆FTTR业务的规模发展，重庆公司已实现了千兆平台的全覆盖。随着插机胖的大量投放，现网存在着资源利用率低、使用效益低的问题。这样的问题主要体现在：虽然千兆业务的规模发展，但是单实际胖口，像下网的插千兆用户数很中。二是在业务批量迁移之后，空闲胖口占比高，还有0带宽率。
- [02:31:20 - 02:32:17] 说话人9: 端口占比高，那么究其原因呢主要有四个方面，一个是叉机胖端口的低效使用，叉机胖端口空闲多，然后业务迁移之后机胖板空闲，还有高价值高贷款业务迁走后留下了大量的无贷款并轨胖口。总结起来就是资源闲置低效使用，那相应的政策呢也就呼之欲出了，重庆公司通过低效端口置换，叉机胖板的整合腾退，空闲机胖板的腾退，无贷款利用率胖口的清理，充分利用现有的机胖板资源，杜绝叉机胖板的资源浪费，减少了叉机胖板的投放，取得了显著的效果。首先呢是低效端口置换，通过低价值区域，且叉机胖板的有效使用场景，胖口协同开展端口业务置换提升资源利用效率，主要通过三个步骤进行实施。
- [02:32:17 - 02:32:19] 说话人5: 一个是红点型。
- [02:32:19 - 02:32:22] 说话人2: 这朋友，我把他抛弃了。
- [02:32:22 - 02:33:21] 说话人9: 用户数作为衡量叉接泵网口是否有效率的判断条件，结合单端口承载千兆用户数，作为辅助坐标，为各分公司叉接泵网部署和业务发展进行了画像。对于我们就是现在就对于那种处于第三象限的那种部署又不精准、效益又差的分公司，就会要求他们开展低效端口置换。所谓的低效端口置换呢，是将低效使用的叉接泵端口与达到迁移标准的机泵口进行业务置换，充分利用现网机泵网络资源来承载轻量级业务。为了保障此项工作顺利进行，群资中心和计划部各司其职。群资中心梳理清单，跟踪置换情况，计划部则对未切实执行置换的分公司停止后续叉接泵网资源的审批。通过双方密切合作，确保分公司各接需求时。
- [02:33:21 - 02:33:41] 说话人9: 各街需求是优先使用低效装头板承载业务。为支撑分公司高效的割接，重庆公司开发了跨厂家的磅口割接工具。该工具有三个特点：一个是跨厂家的快速割接磅口，快速割接。第二个是同可以同时割接多个。
- [02:33:42 - 02:33:46] 说话人3: 还有能够记录各界的完成情况。
- [02:33:47 - 02:34:17] 说话人9: 各项失败端口的复退。第三个是资源数据的自动修改，它可以修改那个各接完后可以修改那个光路的信息，自动的进行修改。措施二是插接泵板的整合复退，可以机房维度统计分析，对整个机房内的插接泵板端口资源进行统一的那个筹划，将未用完的插接泵口整合到一块板上。邮分公司将库检出来的。
- [02:34:17 - 02:34:23] 说话人3: 回收，比如省公司计划部统一调配的用户，后续业务的发展。
- [02:34:23 - 02:35:11] 说话人9: 截至目前呢，我们腾退了670户，也节约了大量的投资。通过差低效端口的置换和差机旁网的整合腾退，网络资源使用效率得到了提升。单胖单差机旁网接入千兆用户数，提升至7.7户，可能也不是很高，但是对诚信公司来讲的话，已经是一个很大的提升了。还有是实际胖网有空闲频率也显著下降。节约投资的话是节去了30%，就是我们这个是计划部这边，做到了节约投资节用了30%。从13~9是没有空闲机旁网的回收，资管系统建立了支撑手段，常态化的去监控现网空闲胖网。

91
examples/天数测试结果-30分钟.md 100644
View File

@ -0,0 +1,91 @@
# 会议纪要
## 1. 会议概览
- **会议时间**：2026-07-13 11:30:52
- **主持人**：中移物联管理员
- **会议背景**：针对多个省份及区域传输网络接入、维护、安全保护及资源规划进行总结与部署，涵盖辽宁、湖南、上海、广东、黑龙江、天津、重庆等公司情况。
## 2. 主要讨论点
- **辽宁公司**：
- **接入网 T-WAP 协议测量方案**：传统拼测试方案精度为毫秒级，无法准确采集距离短（0.0 点几毫秒）的接入网链路数据。现网 RT 设备支持情况：华为 5800 设备支持 T-WAP 协议；中兴设备已发布但尚未获得入网证；烽火设备预计七月份支持。
- **现网部署**：网络规划在 OLT 上联双基基站间新增两对互联 IP。Base 侧配置 Sender 测试任务（手工配置），OLT 侧配置 Responder 测试任务（脚本自动生成自动配置）。数据采集通过 telemetry 采集 Base 和 RT 之间的 T-WAP 任务。
- **试点效果**：辽宁朝阳市试点，已完成 286 台华为 5800 型号 RT 的 T-WAP 协议部署，实现 572 条链路实验性能数据实时采集。
- **问题分析与优化**：发现 7 台 OLT 上联链路差值大于一毫秒 1.5 毫秒。发现长路径导致高时延（如 OTN 环短边 0.3 毫秒，长边 2.1 毫秒）。优化措施：将 OLT 上联链路由 OTN 改至 SPN 网络承载，链路时延最多压降 10%。
- **自动化逃生实践**：去年八月，19 号的 2012（台风导致葫芦岛建昌市道县多条路由中断）。通过跨线区、地市、跨厂家逃生，验证了 SPN 三跨或跨县区、跨地市、跨厂家能力。技术为自动交叉设备（光开关），1:1:2 版本（主倒备、备段倒备），85m 光块（中兴/烽火/华为），4-5G 业务模拟。
- **湖南公司**：
- **一张光网分级维护机制**：2024 年初推进综合代维与加急代维融合，含职责、流程、管理、优改四方面融合。
- **维护工作融合**：维护资料以一级或二级中间箱/网点为标准资源点交接；维护界面综合代维界面下沉至二级封装器；流程调度线上化故障工单直派综合代维，投诉类工单（12086/490）首派铁通维护。
- **效果与数据**：配线段故障定位时间缩短至分钟级；无效沟通及上门确认情况减少接近 1/4。省内跨网或配建网后月均故障在 3.60003.60000 笔的样子，故障量占八成左右。
- **问题与隐患**：故障响应不及时（线下电话沟通为主）；工单信息不足，故障定位困难（黑线段光缆故障定位能力不强）；考核管理存在沟通问题；整治项目进度不一导致段路重复故障比例偏高。
- **下一步计划**：继续加速深入，提升效能，统筹做好一张光网。
- **上海/道路资源**：
- **道路资源与管道规划**：针对交通资源管控，结合地图厂商地块、道路红线及路段信息，构建符合线网的城市资源效果。上海市 650000 条道路信息，1490000 条资源数据（网点、机点、杆基础设施等）。
- **覆盖率**：市政道路 72%，轨道交通 96%，市区基本覆盖率 91%。
- **利用率分析**：50000 个管道段（利用率 101%），其中超过 100% 的路段作为地面清单数据进行加排。部分管道利用率低（如资金管道 2.5%，小型输送管 25%-88%）。
- **案例**：南京路地铁搬迁路段，利用率由 113% 降低到 86%。
- **优化场景**：废弃光缆拆除；头路段光缆收敛；光缆路由优化（基站到基站、接入光缆、专线、C 源拉远）。
- **建议**：加强资金管控储备（隧道、大桥长期宝贵战略资源）；加强新增光接入光纤网比例考核（小新数 20 根及以上）；路网分级管理（一干、土干沿主干道规划）；加强基站搬迁管控，合理审核方案。
- **待确认信息**：全国路段资源情况，六六 60000 公里的路段数据。
- **广东公司**：
- **VCP/OTN 网络安全与 DNI 保护**：以广州为中心建设 VCOTN 新型网络（2019 年开始），核心站点 6 个，Mesh 化主网。设备厂家以华为为主，后续有中兴、烽火。
- **问题**：跨市业务配普通 SNCP 保护，主备跨度长，双断风险大；跨市分段 SNCP 保护，节点隐患（如 N16 网元出问题导致专线断掉）。
- **解决方案**：引入 SH 网络 DNI（双节点互联）保护能力至 OTN。依托华为平台开发自动配交叉工具，实现节点级保护（环相交结构）。业务包括 US、EU、O 和 CLAN。
- **验证结果**：故障模拟包括单纤、双纤、三纤、红联、单节点故障。倒换时间 15 毫秒以下，符合预期。业务创建及状态符合预期，正常。
- **待确认信息**：设备准备情况（两台摄像机、两个 ET 机），5095 晚上效果不一定好，一台估计有个钱了。
- **广州网络**：
- **现状与优化**：现存四个毛病：单节点故障、链路过长/设备中断风险、出入局同路由/短时延误路径导致的小段同路由、带宽不足（特别是网深）、本地/干线占用网元潮位高（广州两个核心节点支撑西帮村点）。
- **优化方案**：1. 通过 DNI 保护解决单网元故障和多点中断迁移风险；2. 本地侧增 ORP、电路加干线侧加 SSP 保护解决同路由风险；3. 跨市和省市内上联链路做 100G 链路升级；4. 分列网元（广州），新增一对 DNI 网元用于跨市业务调度，缓解资源矛盾。跨市业务在普通汇聚和中央汇聚配 DNI，跨市在普通汇聚、中央汇聚骨干接入。第四层面（分裂的网元）外线做 ORP 保护，省干部分做单边 SSCP 保护（因投资原因妥协）。
- **决策**：确定了总体优化方案（四个方案对应四个毛病），业务安全性及容量得到提升（容量增加 10 倍）。
- **黑龙江亚冬会保障**：
- **时间**：2 月 17 日到 14 号。
- **规模**：34 个国家和地区，1200 名运动员，13 个场馆，169 个重点保障场景，2633 个基站。
- **问题**：基站/传输链路无法自动关联、告警量大、告警链路匹配困难、跨专业告警匹配困难。
- **方案**：传输工作台为核心，拓扑自呈现、故障自定位。基站与传输链路自动关联（PTN 链路二层三层）。
- **成效**：无因为传输故障导致的基站中断。
- **天津光纤租赁**：
- **困境**：地理位置特殊，重建开发区/高新区自主管理，不允许多运营商架设基础设施。租赁价格固定，业主不公开具体路由，需租赁/购置资产，需测试距离（ODF 打一下）。
- **风险**：业主掌握路由控制权，配合度低，存在恶意加强跳纤路由风险。
- **珠海/佛山公司**：
- **主网结构**：珠海公司主网结构单纯（一对群光大厦和南屏二期楼），横连电路 100G，跨市物升到 100G。佛山公司结构跟珠海有差异（山水通信中心和德胜枢纽中间有 OTN 节点穿通），改造去掉穿越节点。
- **工具应用**：
- **交叉改造工具**：联合华为开发专门工具，针对存量业务改造。人工配置交叉时间 15~10min，工具配置时间缩短到三分钟一条，每管能割的业务数翻 5~6 倍。工具功能：可视化界面，执行脚本，通过华为平台生成脚本，分析空闲失线情况，适配 NCE 工具。工具开发时间：大半年；现网验证：今年四月份开始做实际存量改造验证。工具适用性：新增业务通过自控作业台开发适配，存量业务用厂家工具（依赖华为内部资源分析）。版本要求：网管版本 R2~3，设备版本 VC 设备 R21 以上。
- **重庆公司**：
- **传输网络利用率提升**：千兆 FTTR 规模发展，现网存在资源利用率低、使用效益低问题（端口占比高、0 带宽、无贷款并轨胖口）。
- **决策**：开展低效端口置换及插接泵板整合腾退，节约投资 30%。
## 3. 决策事项
- **辽宁公司**：推进全网部署，与中兴和烽火厂商联合开展在线网测试；接入网问题挖掘和优化，分析全量 OT 上联链路时间，压降高时延链路；网络差异化呈现，整合接入网上层网络实验数据，调度高价值用户及业务至低时延链路。
- **湖南公司**：继续加速深入，提升效能，统筹做好一张光网。
- **上海/道路资源**：加强资金管控储备（隧道、大桥长期宝贵战略资源）；加强新增光接入光纤网比例考核（小新数 20 根及以上）；路网分级管理（一干、土干沿主干道规划）；加强基站搬迁管控，合理审核方案。
- **广东/广州/珠海/佛山**：确定了总体优化方案（四个方案对应四个毛病），业务安全性及容量得到提升（容量增加 10 倍）；跨市业务在普通汇聚和中央汇聚配 DNI；第四层面（分裂的网元）外线做 ORP 保护，省干部分做单边 SSCP 保护；存量业务改造依赖厂家工具（华为），新增业务通过自控作业台开发适配；今年底把重要的专线的 B N I 改造做了（不全量），24/03 到今年目前接近两年的时间完成重要专线改造。
- **黑龙江**：今年底把一些东西大部分实现（4M 带 IP 城联网、重要集客专线等）。
- **天津**：采用单芯双向光模块改造方案，直接压降至原有租赁量的一半。
- **重庆**：低效端口置换及插接泵板整合腾退，节约投资 30%。
## 4. 待办事项
- **施工司**：根据方案跟当地规划部门提具体项目。
- **珠海公司/佛山公司**：按前面开的方式改造室内设备 DNI 横连电路。
- **工具现网验证**：分了 1234 场景验证，测试倒回。
- **黑龙江**：今年底把一些东西大部分实现（4M 带 IP 城联网、重要集客专线等）。
- **天津公司**：解决光缆租赁成本困境，与业主沟通。
- **厂家**：解决华为/中兴/烽火 85m 光块 FVX 功能对接问题（正序/反序）。
- **群资中心**：梳理清单，跟踪置换情况。
- **计划部**：对未切实执行置换的分公司停止后续叉接泵网资源的审批。
- **开发工作**：开发跨厂家的磅口割接工具（跨厂家快速割接、同时割接多个、记录完成情况、资源数据自动修改）。
- **资管系统**：建立了支撑手段，常态化监控现网空闲胖网。
- **天津案例部门**：群资中心、计划部、业主（开发商）。
- **责任人**：
- 施工司（跟当地规划部门提具体项目）。
- 黑龙江俄罗斯的王月凡（亚冬会保障经验）。
- 天津公司（光纤租赁成本问题）。
- 厂家（华为（脚本生成、工具）、中兴（EOS 版本）、烽火（底层配置））。
## 5. 关键信息
- **辽宁 T-WAP**：286 台华为 5800 型号 RT，572 条链路实验性能数据，7 台 OLT 上联链路差值大于一毫秒 1.5 毫秒，OTN 环短边 0.3 毫秒，长边 2.1 毫秒，压降高时延链路最多 10%。光缆 8810 公里，85m 光块。
- **湖南维护**：配线段故障定位时间缩短至分钟级，无效沟通及上门确认情况减少接近 1/4。省内跨网或配建网后月均故障在 3.60003.60000 笔的样子，故障量占八成左右。
- **上海道路资源**：650000 条道路信息，1490000 条资源数据，市政道路覆盖率 72%，轨道交通 96%，市区基本覆盖率 91%。50000 个管道段（利用率 101%）。资金管道利用率 2.5%，小型输送管 25%-88%。南京路地铁搬迁路段利用率由 113% 降低到 86%。全国路段资源情况，六六 60000 公里的路段数据。
- **广东 VCP/OTN**：核心站点 6 个，Mesh 化主网。倒换时间 15 毫秒以下。5095 晚上效果不一定好。
- **广州网络优化**：容量增加 10 倍。100G 链路升级。网管版本 R2~3，设备版本 VC 设备 R21 以上。
- **黑龙江亚冬会**：2 月 17 日到 14 号。34 个国家和地区，1200 名运动员，13 个场馆，169 个重点保障场景，2633 个基站，132 个重要保障场景，80 起传输单边故障，31 个同路问题。告警分级：红橙黄蓝四级。
- **工具效率**：人工配置交叉时间 15~10min，工具配置时间缩短到三分钟一条，每管能割的业务数翻 5~6 倍。工具开发时间：大半年。
- **天津光纤租赁**：租赁价格 150 元（新公里每月）。每年以 10~5% 的比例提升。改造距离 313 公里。压降比例 41.7%。压降成本 16.340000 元。合计增加成本不到 400000 元。光模块单价差异约 200 元。2025 年二季度合计替换单晶双向光模块 321 对。代维人员费用 7.20000 元。预计节约成本 320000

116
examples/文件会议 07-13 11_30-Transcript-summary.md 100644
View File

@ -0,0 +1,116 @@
# 项目会议纪要
## 1. 会议概览
本次会议汇总了多个关键网络优化与保障项目的进展情况，包括：基于T-WAP协议的接入网时延测量、综合代维与家庭代维融合、城市主干管道资源管理、广东省VCOTN网络安全改造（含DNI改造与工具开发）、辽宁市道县路由自动管控、亚冬会保障工作、天津光缆租赁成本优化以及重庆公司传输网络资源利用率提升。会议重点讨论了技术方案的验证结果、成本压降成效及后续部署计划。
## 2. 项目进展与推进事项
### 基于T-WAP协议的接入网时延测量研究与实践
- **目标与范围**：通过T-WAP协议实现链路微秒级时延采集，解决传统Ping测试精度不足（毫秒级）及接入网（胖网络）时延数据缺失问题，支撑“小区到区县中心”的时延分析。
- **当前阶段/已完成进展**：
- **技术实现**：采用UDP数据包作为探测探针，在OLT（Responder）与上联Base（Sender）间部署T-WAP LAN协议。
- **部署步骤**：已完成网络规划（新增互联IP）、数据配置（Base侧手工配置，OLT侧脚本自动配置）及数据采集（通过Workbench利用Telemetry技术）。
- **试点成效（辽宁朝阳市）**：已完成286台华为5800型号OLT部署，实现572条链路时延、丢包、抖动数据的实时采集，并可支撑区县公司开展时延优化。
- **端到端整合**：实现省内1~2级时延圈数据整合（小区到OLT + OLT到Base + Base到CMNET）。
- **关键讨论与方案**：针对朝阳市部分区县平均时延超1ms的问题，通过将OTN承载链路改为SPN承载，链路时延最多压降10%。
### 综合代维与家庭代维融合项目
- **目标与范围**：通过维护、流程、管理、优改四个方面的融合，将家庭代维（加急）线路维护工作纳入综合代维包年服务，实现运维一体化。
- **当前阶段/已完成进展**：
- **职责与流程**：职责界面已调整，实现综合代维与家庭代维的互派互转及故障工单闭环。
- **管理与考核**：明确了考核依据，实施“指标提升期 $\rightarrow$ 全面整改期 $\rightarrow$ 稳定达标期”三个阶段，通过解决率、及时率、合格率进行效能画像，并建立连续三个月不达标的退出机制。
- **故障管控**：采用分层分级定位方法（多PON口、单PON口、配线端、单用户），并引入误报规避机制（关联DGI告警、30分钟延迟派单）。
- **成效**：配线段故障定位缩短至分钟级，无效沟通及频繁上门减少接近1/4。
### 城市主干管道资源管理与优化项目
- **目标与范围**：通过购买地图数据建立数字管理模型，实现城市管道资源的快速、直观、全面反映，支撑规划与优化。
- **当前阶段/已完成进展**：
- **数据规模**：整合6.5万条道路信息及149万条资源数据（网点、分箱、杆、广告带等）。
- **覆盖指标**：市政道路管道覆盖率72%，轨道交通96%，市区91%。
- **建模功能**：涵盖管廊、覆盖、使用情况、条件匹配及数据预警（如光缆数量超标预警）。
- **关键讨论与方案**：针对南京路利用率达113%（黄色预警）的情况，通过拆除无业务光缆、调整路径等方式，计划将利用率降至86%。
### 广东省VCOTN网络安全改造项目（含VCO/VCOT主网优化及DNI改造）
- **目标与范围**：借鉴SH网络DNI能力，通过“环相交”结构提升OTN网络节点级保护能力，解决单节点故障及链路过长导致的业务中断风险。
- **当前阶段/已完成进展**：
- **验证结果**：CPE双上联至DNI保护对的验证显示，100M业务倒换时间在15ms以下，符合预期；在单点/多点故障下业务仍能连通。
- **工具开发**：与华为联合开发“无损”调整工具，将人工配置时间从15-30分钟/条缩短至3分钟/条，支持业务倒换实现无损切换。
- **实施案例**：已在珠海（100G DNI横连）及佛山（出口节点直接穿通）开展改造。
- **已确认决策**：
- **总体优化方案**：采用DNH保护、ORP/SNCP组合、100G升级及“分列网元”四项措施。
- **配置策略**：汇聚以上均需做ORP保护；省干部分采用“单边SNCP”折中方案以平衡成本。
### 辽宁市道县路由自动管控实践
- **目标与范围**：解决台风等极端天气下市道县路由中断导致的车站掉线问题，实现业务向干线资源的自动迂回逃生。
- **当前阶段/已完成进展**：
- **方案实现**：引入O-X设备（自动交叉设备/光开关）配合ORP 1:1:2保护模式。
- **验证效果**：完成“三跨”（跨线区、跨地市、跨厂家）能力验证，通过SR-TE隧道实现自动合成通路。
### 亚冬会保障项目
- **目标与范围**：保障2月17日至24日期间，涉及13个场馆、2633个基站及169个重点保障场景的通信需求。
- **当前阶段/已完成进展**：
- **体系建设**：建立以“传输工作台”为核心的保障体系，实现基站与传输链路的关联映射（基于北向MPC数据）。
- **保障成效**：完成132个场景组及2693个基站穿透；保障期间发生80起传输单边故障，平均处理时长在1小时以内；亚冬会期间未发生因传输故障导致的基站中断。
### 天津光缆租赁成本优化项目（含单芯双向光模块改造）
- **目标与范围**：针对租赁成本逐年递增（10%~15%）及业主掌控路由的困境，通过使用单芯双向光模块，将原有两芯组联减半，压降租赁量与成本。
- **当前阶段/已完成进展**：
- **改造优势**：实现A端机房改造，无需更改跳纤，具备隐蔽性，避免业主感知变化。
- **试点成效（滨海生态城）**：2024年至2025年初，实现313新/公里 (待确认) 压降，压降比例为41.7%。
- **投资回报**：2025年二季度累计替换321对模块；预计截止2025年改造量可节约成本3,200,000元。
### 重庆公司传输网络资源利用率提升
- **目标与范围**：解决千兆FTTR业务规模发展中，因“插机胖”（待确认）大量投放导致的资源利用率低、空闲端口占比高的问题。
- **当前阶段/已完成进展**：
- **实施措施**：开展低效端口置换（针对第三象限分公司）、插机胖板整合与腾退、开发跨厂家“磅口”（待确认）割接工具。
- **成效数据**：已腾退670户；单插机胖网接入千兆用户数提升至7.7户；实现节约投资30%。
## 3. 行动项
| 任务 | 责任人 | 协同方 | 截止时间 | 状态/依赖 |
| :--- | :--- | :--- | :--- | :--- |
| 推进全网T-WAP协议部署，实现全量OLT上联链路采集 | 待确认 | 中兴、烽火 | 待确认 | 持续进行 |
| 挖掘高时延链路并结合现有/后续资源开展优化 | 待确认 | 待确认 | 待确认 | 计划中 |
| 完成重要专线的DNI改造（非全量） | 待确认 | 待确认 | 2024年底 | 计划中 |
| 中兴存量业务工具研发 | 待确认 | 中兴 | 2024年底 | 计划中 |
| 针对低效使用端口开展置换 | 待确认 | 分公司 | 待确认 | 执行中 |
| 开展插机胖板的整合与腾退 | 待确认 | 分公司、省计划部 | 待确认 | 执行中 |
## 4. 跨项目事项
*（暂无明确跨项目事项）*
## 5. 风险、阻塞与待确认事项
### 基于T-WAP协议的接入网时延测量研究与实践
- **设备能力风险**：中兴设备虽发布功能但尚未获得入网证；烽火预计7月份支持。
### 综合代维与家庭代维融合项目
- **沟通与效率风险**：交接初期存在资料不清、职责不明、沟通不畅问题；故障处理过度依赖线下电话。
- **技术阻塞**：OLT下行“黑线段”（分光器后光缆段）故障定位能力弱，缺少告警数据。
- **管理冲突**：助力网项目（成本费用整治）与传统光纤项目在维护界面存在交叉，导致多头管理。
### 广东省VCOTN网络安全改造项目
- **安全隐患**：市内业务采用普通SNCP，冲突域大，存在双断风险；跨市业务出口节点集中，存在单点故障风险。
- **工具依赖**：华为工具依赖厂家内部资源分析，暂无法自研。
### 辽宁市道县路由自动管控实践
- **兼容性风险**：烽火、中兴、华为在85G/100G模块的FX/FVX配置及正序/反序上存在差异，需底层适配。
- **性能限制**：逃生链路光缆距离受限于100G模块性能，不能超过81-85公里。
### 天津光缆租赁成本优化项目
- **管理风险**：业主（开发商）可能因感知变化而恶意加强跳纤路由或要求重新规划，增加成本。
### 重庆公司传输网络资源利用率提升
- **术语待确认**：涉及“插机胖”、“磅口”等表述，需确认准确名称。
### 其他待确认事项
- **项目归属待确认**：关于“两台摄像机、两个ET机、5095设备效果”的内容，疑似非项目汇报相关的现场杂谈。
- **数据待确认**：
- 天津滨海生态城压降量：“313新/公里”及“300,130公里”表述不一。
- 天津滨海生态城成本节约额：“16.340000元”。
## 6. 关键信息
- **重要时间节点**：2024年初（融合项目启动）、2024年4月（VCOTN工具验证）、2024年8月19日（辽宁路由中断事件）、2024年底（VCOTN改造目标）、2025年二季度（天津模块替换）、2月17-24日（亚冬会）。
- **关键数字**：286台（华为5800 OLT）、149万条（资源数据）、72%（市政道路覆盖率）、15ms（VCOTN倒换时间）、313公里（天津压降量）、30%（重庆投资节约）。
- **关键厂商**：华为、中兴、烽火。
- **关键设备/协议**：T-WAP协议、OLT、Base、DNI、ORP、SNCP、O-X设备。

254
examples/文件会议 07-13 11_30-Transcript.md 100644
View File

@ -0,0 +1,254 @@
# 文件会议 07-13 11:30 会议转录
- 会议时间：2026-07-13 11:30:52
- 主持人：中移物联管理员
- 导出时间：2026-07-13 14:42:12
## 转录正文
- [00:00:00 - 00:00:02] 说话人1: 下午好，我是来自辽宁公司的刘。
- [00:00:02 - 00:00:07] 说话人2: 你你还做的是写的啥？是的，你解释里面也写的啥？是的。
- [00:00:08 - 00:01:03] 说话人1: 测量方案研究与实践，也是近几年吧，随着这个，串联网络提出的这个，152 10实验圈呢，这个概念和要求，各省各兄弟省应该都做了很多关于干线方面的这个实验优化的工作，但是对于接入网这块呢，可能之前做的比较少，然后我们也我这块分享了一下我们省做的这一些工作，一是项目背景，传统的这个拼测试的方案，因为这个测试实验精度的问题呢，无法准确采集这个胖网络的接入的这个实验，导致在这个地市一级实验分析中缺失接入网的这个实验数据的情况，无法准确呈现一级实验圈的这个数据，所以这个提出了基于，T WAP这个协议测量胖网络实验的方案的这个解决方式。
- [00:01:04 - 00:01:59] 说话人1: 之前用的比较多的，就是测量这个ORT上联至base这段链路的这个，时间测试的方法，可能用探针用的比较多，然后在ORT下面挂一个探针做拼测试，但是这个拼测试的这个，时间的这个精度一般都是毫秒级的，在像我们接入网的这部分链路可能有一些，距离比较短，可能是0.0点几毫秒，通过这个拼的这个方法，就无法准确的这个测量，然后呢，在这个地市的一级时间圈当中呢，可分解为这个小区，我们这些小区到这个曲线呢，中心，然后是这个曲线到市中心这两部分，然后曲线到曲线中心到市中心呢，我们可以结合，比如说base到那个PC，就CMNET网络这部分时间数据，可以计算出这个曲线到市中心的这部分时间。
- [00:02:00 - 00:02:58] 说话人1: 但是从这个小区到这个区县中心的这部分接入网的实验区域，目前在这个实验地图中还是缺失的，所以也就是无法精确的分析到这个网络接入这个路的这个实验包的，或者是有这个实验问题呢这部分详细的这原因。基于以上呢，通过这个基于T-WAP这个实现，通过链路微秒级别的这个实验采集，解决跨网络链路实验无法准确采集的问题，为接入网实验分析业务多层方案实验分析提供数据支撑。我们这个先简单介绍一下这个T-WAP协议吧，它是用于IP链路性能测试的技术，然后在接入网使用呢就是通过在OLT与被试之间部署，该协议实现OLT这个上联链路的实验数据的准确采集。
- [00:02:59 - 00:03:55] 说话人1: T-WAP它是一种这个使用的是这个UDP数据包作为探测作为测量探针统计网络的双向时延抖动和这个丢包率的情况在现网中用的比较多的是这个T-WAP T-WAP LAN这个协议它是这个轻量化的这个架构简化了性能建立的测量会话的控制协议实现对网络任意位置的双向IP性能测量这个实际在现网的部署呢这个测量机制是在OLT与上联Base之间部署这个T-WAP LAN协议然后Base是作为这个Sender然后OLT测作为这个Responder然后通过Sender周期的发送这个测试报文在测试报文中携带这个时间戳。
- [00:03:56 - 00:04:47] 说话人1: 基于相邻的两个包文的时间戳来计算这个链路的性能。它这个计算呢，实验的方式还是很简单的，就是通过这个接收的这个时间戳减去这个发送的时间戳，再减去这个中间转发的这个间隔的这段时间，就得出了这个链路的整体的这个实验的这个数据。然后在胖网络中部署呢，嗯也是就是结合这个现网呢各个设备厂家的这个情况，我们进行了一个了解，然后在那就设备支持的情况呢，因为我们现网RT设备有三个厂家，然后华为的5800的设备是支持这个TWP这个协议的，我们是也是在华为的这个。
- [00:04:48 - 00:05:38] 说话人1: 因为我们现网base也是华为的，所以就是基于华为的OLT和base，做了这个现网的部署，然后其他两个中兴和烽火的这个OLT的设备目前的这个版本还是中兴是说反馈的是已经发布了，但还没有这个获得入网证，然后烽火我们了解到是说七月份支持，所以这两个厂家目前现网还不具备这个能力，所以这个现网呢我们目前做的测试就是在华为OLT上联到这个华为base这部分链路部署这个TWP协议，实现这个性能数据的这部分采集。然后在宽网络中的这个部署方案，第一个第一步就是这个网络规划，因为部署这个测试任务需要。
- [00:05:39 - 00:06:31] 说话人1: IP地址，然后我们在现网是立就了这个电视的主播业务的这个维拉，还有接口以及IP地址规划，直接在这个OLT上联这个双机base间新增了两对互联IP，解决了这个IP地址的这个现网立就的这个情况。然后第二点就是做数据配置，在base上需要配置这个ty5000 sender的这个测试任务，在OLT上配置responder这个测试任务。目前呢，这base测我们还是通过这个跨专业沟通base测需要这个手工去配置，然后在OLT测呢，因为这个OLT的这个数量也是比较大，我们已经这个实现了这个脚本的这个自动生成和自动配置。然后第三步就是这个数据的实验数据的这个采集。
- [00:06:32 - 00:06:42] 说话人1: 在这个工作台通过 telemetry采集这个base和rt之间的tflab的这个任务，来获取各条链路的。
- [00:06:43 - 00:06:45] 说话人3: 全刘邦总统的这个声光数据。
- [00:06:49 - 00:07:38] 说话人1: 第三点介绍一下项目的效果，我们在那个辽宁的朝阳市开展了项目的试点，已经完成了，286台华为5800型号RT的T-WAP协议部署，实现了572条链路实验性能数据的实时采集，并且预警这个链路的时差，可以先看一下这个上联链路实验的这个呈现，在工作台上呢可以针对这个每条T上联的链路，可以呈现出，链路的时延丢包抖动等性能数据，在这个网管中呢基于这个T-WAP的这个，性能链路的性能测试采集任务，在链路时差的情况下呢会生成。
- [00:07:38 - 00:08:25] 说话人1: 并开发工单，实现这个接入网链路的性能监控，就是部署了这个任务呢，就可以代替我们，之前可能用的比较多的探针来播测，还是出这个丢包，时差的报警，这个可以直接从设备侧，通过这个厂家网管就可以显示出来这个，电路的时差的这个报警。然后就是曲线级的这个时延数据的呈现，然后根据曲线内全量的OLT上联链路的时延，可以计算出曲线内这个网络的平均时延情况，呈现各个曲线的时延的数据的同时呢，也支撑这个曲线公司开展，网络时延优化的工作。
- [00:08:25 - 00:09:18] 说话人1: 在我们线网呢，根据非是上联链路，来计算这个线曲线到市中心的这个平均时间，然后根据这个OLT上联链路计算出这个曲线的平均时间，两部分数据结合起来呈现出这个地市一级四圈的整体这个时间情况。然后下面举了一个我们这个朝阳市的各区线内的这个，以市道线以及曲线内的时间情况。可以看到，我们提出的这个一毫秒这个一级四圈，在这个朝阳市的这个网络里，特别是这个曲线内，朝阳线这个点它，就曲线内部的这个平均时间已经超过了这个一毫秒，这主要原因还是这个。
- [00:09:18 - 00:10:10] 说话人1: 跟这个曲线呢，传输的网络呀，还有这个整体的这个地区结构也有一定关系。然后针对这个高时延的链路呢，我们也开展了这个，接入网的结构性的这个问题的挖掘。我们对这个朝阳市这个全量的OLT上联链路的，进行了这个分析，存在七台OLT上联链路，差值大于一毫1.5毫秒的情况。然后选取了两台接入，进行了深入的分析，上联链路的传输光中承载情况。然后造成这个时延高差值较大的原因主要是长路径的存在。然后一下就是举例说明一下。然后左侧这个图呢可以看到，这个曲线的倍数。
- [00:10:15 - 00:11:03] 说话人1: 然后这个ORT呢，它也是通过这个线箱的OTN这个OTN环来承载的，它这个短边和这个长边，就是这个OTN环可能有这个问题，短边的时延就是非常小，才0.3毫秒左右，通过这个长边承载的这部分，然后这条链路呢，时延就达到了2.1毫秒，所以这还是跟这整个区域内的这个长中频网络这个网，有一定的关系，然后右侧这个头呢也是大概是相同的情况吧，然后主要还是传承载，那个线箱的OTN环的这个。
- [00:11:04 - 00:11:51] 说话人1: 我们的长短路径承载导致的时延差距过大存在高时延的那个链路情况。然后我们也选取了现网中一台具备传输资源的这个一台上联时延较高的OLT设备进行了这个改造，将该OLT设备上联链路由OTN网络改就是这个SPN网络承载，然后链路时延最多压降10%。就是这个区域正好还有既有OTN网络也有它的SPN混合网，通过将OLT的上联链路从OTN改至SPN，这个时延达到了一定的这个优化。然后这个现江的OTN这部分。
- [00:11:53 - 00:12:52] 说话人1: 优化起来还是怎么说也是对这个资源要求，包括投资要求也是比较高。所以这部分链路，我们暂时还是选取已有资源网，包括SP或者裸线来进行这个时延的压量网络的改造。有了这，OT就是接入网的这个时延的数据，然后就，我们也做了一个，时延数据的整合吧，可以呈现出这个业务端到端的这个时延的情况。就是对省内的这个1~2级线圈的各级各层级的链路时延数据进行了整合，呈现业务在省内端到端各个方向，路径时延的情况，体现网络针对业务提供，差时延差异化服务的这个能力。选取了一个，朝阳市的小区。
- [00:12:52 - 00:13:49] 说话人1: 模拟在用户访问，我们省会沈阳市CMNET省网下的这个资源业务，通过逻辑拓扑呈现业务，流经的设备及实验链路，在网络无调无流量调控的情况下，各个用户及业务会首先移动到各个链路上，端到端的这个实验是无法确定的。这个小区到ORT这部分实验呢，主要基于这个我们这个胖猫到用户家里的这个，光猫的这个，就是网管里面的这个测距，这部分数据来转换过来的。从ORT往上呢，ORT到BASE之间是刚才通过TLOG这个数据，测试任务得到的这个实验数据，然后BASE往上呢，就是基于CMNET网络，它部署的这个。
- [00:13:50 - 00:14:47] 说话人1: T沃把这个测试任务，拿到这个整个现在他网络的这实验数据。他就是他，其实他就支持，这他就是通过IP，就是IP网络的这个测试任务。就是ORT之前这块，嗯怎么说呢，在现网没有部署，但是在这个CMNet网络里面，前两年已经部署了这个T沃这个采集任务，已经有了这个类型。对他只要升级网络，基本上升级那个软件版本，就可以支持这个实验的采集。然后可以看一下，通过对该小区访问端，省网端到端网络，链路实验的这个整合分析，该小区共存在四个不同的实验路径。我们可以看一下最优的是。
- [00:14:48 - 00:15:43] 说话人1: 6.5毫秒，然后最差的这个路径呢有1010.6毫秒，后续呢可以调整这个高价值用户，以及对这个业务时延比较敏感的这部分业务，到这个调度到低时延链路上承载，然后体现出我们这个网络的差异化的这个服务能力。然后项目总结及下一步的这个工作计划，然后基于T-WAP协议在接入网中的部署应用实现了，跨网络链路的微秒级的时延采集，补齐了地市一级时延圈数据，发掘接入网高时延ORT上连接路等结构问题，呈现业务级省内端到端多方向路径时延情况，提升曲线网络支撑能力。后续呢我们计划从以下三方面继续。
- [00:15:44 - 00:15:59] 说话人1: 工作，一是推进这个全网部署，继续与这个中兴和烽火的这个RT厂商，对这个他们RT设备的支持情况来开展在线网开展联合的测试和任务。
- [00:16:00 - 00:16:02] 说话人3: 全。
- [00:16:02 - 00:17:00] 说话人1: 目标是将我们这个全量的OT设备的上联链路，全部署了这个TWP协议，完成全量的OT上联链路的这个采集。第二个，第二项工作呢是这个接入网这个问题的挖掘和优化。对全量的OT上联链路时间开展分析，挖掘时间异常偏高的链路。然后结合现有的或者是后续可能建设的这个传输本地网的设备及光缆资源，对时间较高的链路开展优化和时间压降。三是这个网络差异化的这个呈现，对这个实验数据的整合。通过工作台呢，将接入网上层网络的实验数据进行整合，制作呈现业务，各种途径的这个各个路径的实验情况。然后根据各类用户和业务的重要程度，联合上层网络。
- [00:17:01 - 00:17:10] 说话人1: 调度高价值用户，以及业务是这个低时延链路去承担。以上是我分享的内容，谢谢大家。
- [00:17:21 - 00:17:32] 说话人4: 各位领导同事大家下午好，我是那个湖南公司的杨毅，然后我今天跟大家讲的这个就是，基于分级机制的这个加工方法。
- [00:17:32 - 00:17:34] 说话人3: 我清晰。
- [00:17:36 - 00:17:41] 说话人4: 整体呢分为四个部分，第一个呢是24年的时候。
- [00:17:42 - 00:17:44] 说话人3: 24年初的时候，我们省内基于。
- [00:17:44 - 00:18:28] 说话人4: 这个综合代维的这个整个维护活动，和我们实际维护的这样一个需要，也是整体去考虑的这个加级的业务支撑保障能力和客户提升感知的这样一个方面的工作，有序或者有计划的去推进的这样一个光了一张网的这样一个融合工作，就是相当于通过一张光网的这个四个融合方面的一些工作，按照这个融合的管理的基本原则，将加级客户部分的这个线路维护的部分，整体融合到了我们这个综合代维的这个部分，综合代维的这个包年服务的整体项目的一个管理和维护当中。这个地方总体呢也是分为三个部分，第一个就是职责界面的一个调整，就是把原有的加级的队伍的这个线路维护。
- [00:18:30 - 00:18:55] 说话人4: 统一发挥了这个综合代维去维护，做到了综合代维的融合一张网络网的这个运维管理。第二块呢，就是我们在这个流程方面与现有的这个综合代维加几个代维的这个运维机制去做了匹配，包括我们现有的胖网的胖口的故障、配线故障和层故障、带故障，实现了这个像，实现了这个分代维单位的这个。
- [00:18:57 - 00:18:58] 说话人3: 包括这种投诉状态的。
- [00:18:59 - 00:19:29] 说话人4: 综合代维和加急代维的这种互派互转的这种模式，实现了这个故障工单的一个闭环的一个流转。第三方面呢，就是在管理上面，整体在代维管理合同，包括我们的相应的一些考核细则当中明确了这个考核依据，同时呢，也量化了一个对代维单位综合代维的这个故障处理的时长及服务等方面一些量化的质量考核要求。总体上呢，我们是来维护融合、流程融合、管理融合和优改融。
- [00:19:30 - 00:19:33] 说话人3: 分阶段去推进这样一个。
- [00:19:38 - 00:20:36] 说话人4: 整体我们的这个推进方案呢，从四个融合方面来看，就是基于这个高效交接和屏幕过渡提质增效的这样一个总体原则，分为几个阶段去有序的去推进，这样一个线路运维和综合代维活的这样一个工作，在保障这个网络质量屏幕过渡的同时，有序的去提升这个技术运维的这个故障和故障指标。第一块呢维护工作融合这块呢，整体就是将原有的家庭代维的这块的一些维护资料维护指标，这个地方分为两个部分，维护资料这块其实是以整个甲方用户的一个一级或二级中间箱或者几个单位的网点和标准的这样一个资源点为基础这样一个资源交接，包括一些材料物资这方面。第二个方面可能是更重要的一点，就是关于维护界面，将综合代维的整体的维护界面下沉到了这个二级封装器，也就是说以靠近用户最近的二级或一级封装器为界。
- [00:20:37 - 00:21:26] 说话人4: 这个分光器上行的，有一个线缆部分，由综合代维整体负责；下行部分，其实这个地方的下行部分，大概率也基本上只有皮线部分了，就是由架构装备这块整体去负责。第二块呢，就是这个流程调度机制整块，就是像我刚前面介绍的，就是把整个这个，线上化的一些故障工单的派单机制，派单流程，通过这种工单直派的方式，直接首派到我们的这个综合代维，或者说对于这种投诉类工单，或者说我们就会，去这种12086和490的单用户投诉，用去首派这种铁通维护，也就是加方维护这块，然后通过这种后续的一些故障判断，然后计算去做这个一个线上化的工单。
- [00:21:27 - 00:22:15] 说话人4: 的这样一个形式。第三块呢，就是这个考核管理融合这块。整体呢，在现有的我们省内的综合代维管理考核的管理办法和实施细则当中，对这一块呢，也是大步无从。一些相应的这种考核及时率的指标，和时长的指标，投诉，困难处理的一些指标，这个纳入到了这个综合代维的一些合同和考核管理实施细则。第四块呢，就是优改融合这块呢，整体上。因为现行的我们的这个成本费用整治这块，整体分为传输网一块和数据网一块整治这一块，在整体上这1块2个相对来说还是比较吻合的。然后我们整体。
- [00:22:16 - 00:23:10] 说话人4: 过程当中呢，也发现这个故障，流程过程当中也存在或多或少一些典型问题，包括维护当中遇到的一些，嗯综合代维和加特代维在交接初期的一些资料不清，职责不职责也不明，然后包括一些相互之间的一些沟通协调机制也不顺畅的这样1.1些很多典型问题，还有也包括我们现有的这种ORT下行的这个，黑线段的这种光缆故障的定位的能力也不强，然后包括一些跨专业考核，管理不完善的这样问题。在第一个方面就是这个故障响应不及时这块，整体上来说我们现有的原有的这个故障信息的流转，包括这个处理效率比较低，因为加特装维和这个代维之间，他们是没有线上化的这样一个调度的这样一个流转的这样一个机制和流程，更多的方式都是通过一种。
- [00:23:10 - 00:23:59] 说话人4: 线下电话沟通的这种方式，导致这个故障的处理效率呢时间长，效率低。第二块呢，就是这个工单信息也不够完善，工单信息里面包含的这个关键信息也不足，也不能够去帮助这个故障的这个快速定位和这个，现场人员的及时找到这个故障位置。第二块呢，就是这个OT下行的这个故障定位，黑线段因为一分二分我们都是无线器件，在这一段的这个整体的这个告警定位，尤其是定位这段黑线段故障的时候，整体我们是缺少一些必要的一些告警数据，或者说定位手段。然后第二块呢，也是整体就黑线段的这个关联性也是较低的，导致我们的告警信息和我们的这个资源信息的关联性是比较低的，导致这个这块也就是。
- [00:24:00 - 00:24:59] 说话人4: 定位能力也不太也是比较弱的。第三块呢就是考核这块，然后原有的综合代维和加刻代维这块，因为或多或少相互之间的一些维护职责的一些关系，他们之间，也存在一些工单的这个沟通，包括这种故障超时之后导致的这种投诉处理不及时的这种相互之间的，一些沟通掰扯的一些问题。第二点呢就是我们在人，就像刚前面提到的融合过程当中存在的一个，按整治成本费用整治的助力网项目和我们的传统光纤项目，它其实整体上是，这个小区光纤也是，大概率是以一级封装器为界的，在一级封装器的二级封装器阶段的配线光缆的，光缆层面的这个整治，又是在助力网的这个项目整治活动里面，去执行的，所以就会导致这两个者，我们存在一个维护界面和我们的项目整治。
- [00:24:59 - 00:25:53] 说话人4: 自动界面会存在一定的交叉，导致项目管理有一个多头管理和隐患整治不及时的问题，并且这个地方也会存在因为跨专业沟通，他们的隐患整治这种进度，包括这种及时性得不到这种明确保障。在这一块呢，就是我们的这个省内的这种跨网或者说配建网后的这个月均故障，我们在3.60003.60000笔的样子，大概有这一段的故障量占了八成左右。第二块呢，就是因为同一个网段的这个光网段的这个整治，助力网整治和传输网整治的这个项目推进的这个进度不是统一的，所以它这块因为整治精度不一的话，也容易造成这个段路的重复故障，这个比例也是偏高的。然后基于。
- [00:25:53 - 00:26:42] 说话人4: 基于融合过程当中，这样的一些问题呢，我们为了去提升这样一张光网络的融合程度，提升这个维护质量效呢，然后呢我们整总体呢将这个加宽光网络的故障分为四个层级，就是分层分级的这个采用这种分层分级的这种故障定位的方法呢，来构建一个整套的这个加宽光网络的故障管控体系。这一块呢，大家也可以看到我们的组我们在主网拓扑上面，把它整体分为四个故障层级，第一个层级呢是包括我们的多胖口这一段的多宽多发在这个主服务区的这种主干光缆这块，单胖口的故障就是从一层往下走的，走到二层位置的这种单胖口，第三个呢就配件端从小数光交到用户分接箱里面，到楼栋的分箱里面，第四个呢就是单用户投诉的，就是配件端的。
- [00:26:43 - 00:27:42] 说话人4: 它分了四个层级的这样一个，故障定位的这样一个投诉管理的一个体系。然后呢，将整体的体系通过不同的判断规则，包括这种故障发生的位置的这样一个定位，故障发生位置这样一个和我们的判断规则去做了一个这样一个分析匹配。包括我们举个，典型例子，多判口的这种故障来说，我们在一分钟内如果同一个OLT下面的两个或两个以上的判口去中报上报这样一个中断类告警，我们。在一定的根据一定的判断规则，我们就判断这个主干光缆中断故障。这种工单的话，根据这个判断机制，我们就会直接直派工号代维。建建立工单去直派工号代维去处理线路式故障，也就加宽装维。它就没有，不会受理到建立，因为主干光缆中断导致了末端的用户投诉的这种告警。建建立工单。总体呢也分了这个四个层级，包括我们的多判口单报和黑线。
- [00:27:43 - 00:28:33] 说话人4: 主传派，在这一块呢，就，配线故障的工单，我们前期，也是因为前期的这样一个定位能力呢，我们，通过也是通过不断的这个优化算法和这个优化这个，工单的这个调度流程，然后保证的这个工单派发的呢更加可以高效。然后这一块我们其实可以看一下右边这个典型的这个组网模型当中。对于这个聚类算法的我们的一个典型的应用场景呢，就是对于这种，右边的这种标准化的组网场景下面，当用户，多个三个以上的我们的，定义的一个判断逻辑去，当三个，以上的用户应用户在一分钟内，都不在线的情况下，系统自动判定它为一个配线的故障，也就是说对应于我们右边这种场景的情况下，如果三个用户同时中断。
- [00:28:34 - 00:29:33] 说话人4: 定义我们就根据这个故障的这个定位判断逻辑去判断它是属于这一段分支段的非线性光缆故障，这是属于一个典型的故障。如果还有一个非典型场景，就是由于多个二级分光器采用在同一个光缆上面多加串联这种方式，当出现的多个用户分布在多个二级分光器上面的时候，这个就去做了一个聚类分析定位它在多个二级分光器在同一个光缆上面，然后呢，就通过这个告警工单的这个信息，把这个离这个OLT最近的这个分光器故障分光器的这个地址给它带出来，定位的这个光缆段的故障段落呢，就是这个分光器最离OLT最近的分光器和OLT之间的这个光缆段故障。然后这一块呢，同时呢我们还在另外两个方面，第一个就是针对我们现在可能存在的一些电干扰这种。
- [00:29:35 - 00:29:38] 说话人3: 做了一个规则的排除，包括讲 O U。
- [00:29:39 - 00:30:22] 说话人4: 体电告点了之后会上报一个DGI，就是这个设备掉电这样一个告警。系统中关联的这个，FIO上面真有这个闹死，但是没有DGI的时候，才会判定故障。这种情况下我们就避免了停误派单。第二种就是设置了一个延迟派单的情况。因为实际维护操作当中可能存在这种现场这种，FIO的重启，光缆接的这种过程，会也会去触发这个告警派单的规则。但是我们设置了一个三30min的延迟派单，去规避这样一个冗余派单的这样一个情况。在整体我们在去年六月份之后，整体上线呢，我们现有的这种故障率的下降。
- [00:30:25 - 00:30:59] 说话人4: 整个的这种配线段故障定位的时间呢，也是缩短到了分钟级。另外，整体这个无效沟通，包括这种代维人员频繁上门的这种情况，上门确认的这种情况也减少了接近1/4。第二块呢，就是我们投诉转派这块。末端加宽用户，单个用户投诉或者触发的这种投诉工单，由于这个加宽专维去现场核实了之后，他会把这个现场核实的情况通过工单进行流转到中国代维去，相当于。
- [00:30:59 - 00:31:00] 说话人3: 一个做到一个。
- [00:31:00 - 00:31:18] 说话人4: 终端的正向派单，相当于他在现场判断了这个位置，不是由于末端缺陷或者说故障器或者说加用户体验这样一个情况导致的，而是由于上端二分以上的光缆故障的造成的这个用户投诉，他会在现场去发现测试的点位的一些。
- [00:31:18 - 00:31:21] 说话人3: 成功率、精准度信息，后测试结果。
- [00:31:21 - 00:31:33] 说话人4: 通过这种工单复建的形式，上传到这个工单系统里面，然后流转到我们大伟工地。通过大伟在受理了这样一张工单之后，然后再去现场去定位，做这样一个。
- [00:31:36 - 00:31:40] 说话人3: 桥梁故障处理，这个呢也是。
- [00:31:40 - 00:31:45] 说话人4: 目前是可以通过，然后因为投诉工单。
- [00:31:45 - 00:31:46] 说话人3: 说说。
- [00:31:46 - 00:32:30] 说话人4: 责任制的时候，他接到工单之后，他做了第一步分析判断之后，他会把这个工单同步向外转派的坐标范围，加快这个光缆故障的这个处理，此外也提供了一定的相应的一些测试信息、位置信息，便于这个位置光缆位置的这个直接定位。在这一块呢，整体的这个投诉工单的这个处理效率呢，目前也是得到了一些显著的提升。这一块呢也是，这一块主要是有一个，在电子化转派当中，我们这个光缆故障转派的这个专用入口，光为人员去发转派工单的时候，是我们对他做了一项限制条件，是一定需要去上传一些相应的一些测试佐证照片，避免这种无效转派或者说。
- [00:32:31 - 00:32:33] 说话人3: 恶意转派的这种情况。
- [00:32:35 - 00:33:24] 说话人4: 另外一方面呢，就是在整个运维管理体系上面，从两个方面：一块就是这个运维指标上面。我们按照这个分阶段做，分阶段提升的这样一个策略，然后也是去稳步提升这样一个处理能力和各个预防面。第一个阶段呢，叫指标提升期，第二个阶段呢，再全面整改期，第三个阶段呢，叫稳定达标期。也就是从去年初开始，我们分三个阶段，差不多是每小半年一个阶段的一个时间节点。在就是为了去提升这个加班故障工单的这样一个快的处理的一些及时率。第二个方面呢，是整体对曲线维度的这个综合带维，去对它进行了一个整体的这个处理效能的一个画像。然后我们相当于从多维度。
- [00:33:24 - 00:33:44] 说话人4: 我们解决率、及时率和合格率这方面进行一个综合，再去对这个加工装维的这个各项能力指标去做一个综合分析判断，去给所有的这个按曲线维度和模块维度进行一个曲线的排名打分，然后对于这种曲线维度和模块维度。
- [00:33:45 - 00:33:47] 说话人3: 两个维度方面，都对他们。
- [00:33:47 - 00:34:39] 说话人4: 进行了一些相应的这种指标考核，包括一些竞争性管理。按照我们的这个竞争管理机制，就是连续三个月内部的这种，曲线代维指标是按要求要执行这个退出机制和竞争性要求的这个原则要，就相当于在所属区域的这个代维服务，移交给其他的代维单位去负责。最后一块内容呢是优改，就是整体交通网络的优化，整体一体化。然后这一块呢整体来说是分为成本费用和资本费用开支。在成本费用这块，我们按照刚前面介绍的其实处理网和，传输优化整治，在一定的程度上它的整治界面和它的这个维护界面是一步交叉的。所以在整在这个工作上面，整体上我们省内。
- [00:34:40 - 00:34:53] 说话人4: 在今年开始，相当于把这个成本费用整治这一块的这个整治合同范围进一步的下沉，保证这个整治范围和我们的这个维护界面保持了统一，就是。
- [00:34:53 - 00:34:54] 说话人3: 二分以上的。
- [00:34:54 - 00:34:55] 说话人4: 整体的这个。
- [00:34:56 - 00:34:58] 说话人3: 光缆层面的这个。
- [00:34:58 - 00:35:26] 说话人4: 整治，统筹为一张网，统筹为光缆网的一体化整治项目。就相当于加克装维，整体只负责在分二级风光网下一部分的这个皮线侧的整治项目。这样就做到了这个整体的光缆层面的这个整治，由一个合同项目去支出，一个项目合同一个合同项目去管理。其实呢，这个合同项目管理的这个便捷性，同时也。
- [00:35:27 - 00:35:30] 说话人3: 统筹去做这个光华网银行的这个整治工作。
- [00:35:31 - 00:35:47] 说话人4: 第二块呢，就是这个今年，整体集团公司也在推这个资本费用项目，成本费用下资本费用开支这块的倾斜。在省内呢，我们负责去考虑的这样一个，有线网络一体化优化升级的这样一个项目，通过这个。
- [00:35:47 - 00:36:06] 说话人2: 雅兴那个人，他在问：“他说，我们那个设备准备好了没得？”设备的。就是两台摄像机，还有两个ET机。ET机想去那边。摄像机在那边。摄像机还没有去拿，就不晓得。因为有个5095，晚上的效果不一定好。
- [00:36:06 - 00:36:09] 说话人4: 这个经过了一化的。
- [00:36:09 - 00:36:19] 说话人2: 没有讲的4101的那个，这用得起就行了。我其实我觉得有一个，都是因为有他有一台，他那个照的范围应该是那个大一点那个。
- [00:36:19 - 00:36:22] 说话人3: 吃饭能早点，我们就去接。
- [00:36:22 - 00:36:25] 说话人2: 如果你这台你如果不用的话，你换上也行。
- [00:36:25 - 00:36:27] 说话人4: 这个有码器，但是。
- [00:36:27 - 00:36:55] 说话人2: 效果比自己那个课里面那个好一些。它那个好一点就是不是那种，它晚上我们之前对比过，它那个存储占地面积比较小，但是它这个效果好，效果不好，效果好一些。那个真的占地要大一点，但是它效果好一些。对它的意思，这个都好一些。那它用那种。那我看，拿得到噻，应该还是，设备应该还是拿得到噻。拿得到，再那边有两一台也拿得到。
- [00:36:55 - 00:36:56] 说话人3: 那是哪的呢？
- [00:36:57 - 00:37:05] 说话人4: 这块呢，经过去年从24年到目前为止，四个步骤的推进，通过一个分层分级的这样一个故障调度机制。
- [00:37:06 - 00:37:07] 说话人2: 我我好像。
- [00:37:07 - 00:37:15] 说话人3: 是嘛？同样和那个烧烤，你的状态，心情，你的状态，很健康。
- [00:37:16 - 00:37:17] 说话人4: 出一句是裂痕，失常了。
- [00:37:18 - 00:37:24] 说话人3: 主题声，然后当前呢，我们已经看，也就是我们是在一个。
- [00:37:25 - 00:37:39] 说话人4: 像前面的这个第三三个阶段当中的第一保持期。后续呢，我们在这个工作当中呢，也是会继续加速，继续去深入到。
- [00:37:40 - 00:37:42] 说话人3: 各个方面呢，把它这个整体的进行。
- [00:37:44 - 00:37:49] 说话人4: 这个效能进一步做提升，更好的统筹做好这个一张光网网。
- [00:38:06 - 00:38:46] 说话人3: 各位专家，那个小鹏，我是蔡一峰，是听书人。下面我觉得汇报的是蔡总是一个，能够结合研究一个课题。然后汇报呢，是会三个部分，是非常，这是一个内容，有项目主题。那么我们先做呢，就是说了，通行的规划是，交通的一个不可再生的一个战略资源，也是阐述了，如何使用或者管控资源，关乎于运营商的一个长期的运营，包括少拓展。前期的一个什么，包括我们的前台业务，国家方案，包括公交的一些预覆盖和建设。导致我们的市政管道中的一些，管道之间瓶颈和低限。
- [00:38:46 - 00:39:18] 说话人2: 江苏那边他跟一汽机，他都相当于说用的差不多了，他准备都再把算法多考一下稳定性。如果可以的话，他都想德州魔也挂起。那我们就争取到时候周下周一嘛。如果你那边都差不多了的话，我都喊那个亚星他们周一都可以把个系统设备给他装起。到时候都配合一下，车需要看他需要他们配合嘛，可能远程支持还是能够。不行。还是一台没两台嘛。两台噻。一台估计有个钱了。要。
- [00:39:20 - 00:40:18] 说话人3: 这个弯曲要素的部分点，包括这个优化部分，说在管区内，这个优化项目，优化好的这个路段，运行周期的优化，包括优化什么？那么维护难也是体现在管理难、检修难。比如说在这个共建共享的一些这个管道里面，这个那个管控穿我穿你的，这个运营商的权益得到保障。那么另外一方面呢，就是虽然说这个指挥系统呢，也是掌握了这个530000段，这个海量的这个杆资源的这个设备，但是呢，缺乏这个路段的管理功能，难以是直观有效的去支撑我们的网络规划，难以去匹配这个标准，难以从全局层面去遏制和控制穿网化的合理性，包括这个有效性。比如说我们现在高一级里面说，这个位置处的管控配置多少，比如说主干道的管控配置多少，有没有开截流。那么我们现在就是我们哪些管道是。
- [00:40:19 - 00:41:18] 说话人3: 一道是主干道路，我们有些管道又如何优先控制？控制。所以项目呢就是立足于城市主干，第一个是主干是通过购买这个地图厂商的一个地块，做道路红线，还有路段级别的道路信息。结合这些特征，做出一个数据，对路进行一个综合分析，然后形成这个符合线网，符合数字，整个户外分布特点的一个城市效果。快速直观，能够全面的去反映这个道路特点。第二关呢是建立这个数字管理模型，去探索这个哪些可能问题，哪些可能需要优化的问题，形成一个示范，这个反映这个，还有一些这个优化方案，或者是模拟。我们的研究内容第一项呢就是建模和数据分析。我们从这个从厂商这边买，从这个地图厂商买这个，上去上海市6.50000条这个道路信息。我们对这个1490000条这个资源数据。
- [00:41:19 - 00:42:18] 说话人3: 包括这个网点资源，包括这个公交箱，40000点这个人机点杆基础设施，还有这个广告带，还有这个辐射带，也包括空间资源。也是就是设定一些这个范围，包括匹配这个一个消遣方法，包括匹配这个道路两侧的一些方法，把这些资源呢，都进行到这个道路这个范畴影视。这个其实也是为一些初期规划进行了一些很便捷的一些参考，比如说这个版图，或者说是或者道路，这些通行的又像的一些那个能力，也是能够方便去进行导出。那么项目成果一呢，就是我们从这个四维度，一个是管廊的一个情况，一个是我们覆盖情况，管廊建设情况，和管道使用情况。我们分区域分属地分区公司分中央维修区，分我产线的一个分布，就是构建出大概百分之多少分布在哪里。道路的覆盖率包括这个联通的。
- [00:42:19 - 00:43:10] 说话人3: 这个管道建设情况，我们包括了那些市政管道，也包括了就是那些，汇集点，和应急点的重建管道。使用情况呢方面，我们是六个利用率。那么第一个子场景呢是这个房屋情况。我们通过这个这张图，是也是大家可以看到，就是我们这些管道可能是占比是34%，购买性是达到了可能是占比88%。这两个呢是上海公司里面管道的百分之，主要比较大的一个比重。那么在万科市区里面，大概就是购买性去管建呢，可能是占50%，占八成。资金的话只有比例只有3%。这个说是能够体现出我们这个市区和，郊区和城区管道，也是我建议这个管道的一些。
- [00:43:11 - 00:43:57] 说话人3: 你说几场，首先最广一点，以管线为主，管线可能比较少。那么第二个场景呢是一个，我们的覆盖情况。那么就是说这个市政道路情况题目说不像是快递方面的这个，道路管道。那个覆盖率呢是72%，那个轨道交通呢是96%。那么在市区里面呢是覆盖率呢，基本上覆盖率比较高，在91%。所以呢通过这种这个清单式的话也可以对这个，哪些路段没有覆盖管道，哪些路段是管道，或提供一些这个清单作为决策的一个依据。我们也是设定一些规则，包括这个。
- [00:44:00 - 00:44:49] 说话人3: 表示覆盖率。第三个指标呢，是一个条件的情况。我们对这个路段是一个，节点进行分析，比如说打上这个标签。比如说我们这个这下图两张图呢，是我们是计划的交通简说，对不对？一些主干道路，次干道路，对不对？一些小路，支路，包括一些符合一些要求的一些，包括延伸一些道路一些要求一些标准。我们就是可以把这个一条路段，从道路级别和站点类型，来来这个识别它的一个接受的标准，然后去匹配现状是否满足。我们第四块指标呢，是数据情况。
- [00:44:50 - 00:45:48] 说话人3: 对这个线网很大，建立这个模块和这个图层。我们来说跟你就说，比如说以大红穿网四个光缆为红色预警，六个是橙色预警，八根大的红色预警。目前的那个系统会是的，只要一点点的话是50左右，这个是符合目前的现状。那么比如说我们搞一个案例，就跟案例，比如说我们从知识图谱上筛选了很多的点，黑一点点，它能够很快速的定位到这个黑一点点附近。这个一公里范围内的一个路段的网格情况。比如说这个盘库，从这个铁路盘库到这个铁路盘库，一般道路需要配置2~3口，但是一般道路。但同时呢又请示为这个，那就是贯穿汇聚点的处理的延伸的交叉路，不需要配置的话，它呢配置标准的是六。它呢目前这个路段规划的网格是20段，每一个网格50个。
- [00:45:48 - 00:46:46] 说话人3: 利用率呢是那么的101，其中呢超过100%的这个路段，所以呢就是可以把它作为地面清单数据进行加排。我整个项目的第二项也是我们是就是管道和井盖的分析。然后通过这个井盖来看，刚才说的是我们的信息管道和井盖，确认我今天把它进行一个整体真实这个关系吧，全周期的一个分析。我对这个管道进行分析呢，我们这个主要是认识到就是说自建的管道有井盖比较少，主要是在主城区。城区里面主要有信息管道。但是反映出的情况就是这个交叉情况非常严重，就是利用率或者说直接说现场摆放，可能交叉的路段非常多。那再对这个运行的管道段进行一个复理性分析。
- [00:46:47 - 00:47:46] 说话人3: 比如说这个管道里面的管道的经营利用率，它普遍还是比较低的。比如说资金管道里面是有的是2.5%，清洗管道有的是30%。比如说小型输送管，它的利用率可能也是25%、88、30%。这些都是因为有点空间的，包括它的接入管道网的比例也不算高，就50%，跟全网相当。我们在这个4.80000这个已经管道里面，有30000个管道段，它配置有点高，占比有62.5%。所以就是这个从上述的一些体现出来，一个就是前期储备的一个保护数比较少。第二个就是包括那些所谓的小型输送管，还是比较多的，包括整体利用率比较低。这也是会后续的这个是主控优化方向。那我们采取的通风爆发和这个一些反馈影响这个管道堵塞的因子进行了一个总结。我们主要是通过一个是使用管道，一个是无价值长距离小型输送。那这体现出来就说。
- [00:47:46 - 00:47:47] 说话人4: 这样子就不好，或者说，比如说。
- [00:47:48 - 00:48:37] 说话人3: 其中关键退湖，或者说是，这个就是真的几个专线，低一些废弃的光缆，还没有进行拆除，还是在我们国庆剪断。第二个是这个光缆路不合理，包括，跨区我们以这个匝道七段的原来那些，跨区的接入光缆为主等等。第二个就是这个接入光缆，主要把它堵在道路上。第三个就是，由于这个匝道拥塞，造成了有些光缆的迂回。比如说，我们导航从A到B可能有几两公里，但这个光缆在市里面可能路四公里，进行绕路的。又比如说这个匝道搬迁，规划方案不合理，没有在就近的途径进行剪断进行终结，造成这个光缆路不合理。我们小青说呢，这个主要是，体现在这个投入站的光缆会收敛。什么意思呢？就是比如说，这个小区的建设可能是一个更好。
- [00:48:37 - 00:49:33] 说话人3: 没有，如果前期没有传输合理规划的话，那么小金属上来的光缆，存在这个路由比较长，然后这个利用率比较低的一种情况。就比如说这个一级光交建完之后，二级光交没有，其实已经建设了。那么早期的一些这个专线的光缆可能直接会接到一级光交，那这也是没有经过梳理的。就比如说这个复兴大院的这个光缆利用率肯定比较高，但是呢它通过我们拨通设备之后呢，它的路由可以进行缩短，通过经营的需求。那么管道的话是包括这个管道，这种权益，包括这个管道建设不足，包括这个路，一些断头管道，包括长距离的一些道路两侧没有沟通。那我们综合上述一些这个管道因素，因此，从这个能力维度、建设维度和使用维度，我们分了这么一些指标，进行一些权重评分来评估每条道路的一个这个计划度。
- [00:49:35 - 00:50:25] 说话人3: 这个情况包括一些覆盖率，整个情况包括一些使用的利用率，和使用情况呢，就是覆盖这个八个这个光缆的一个情况的意思。刚才说了一些，主要是一些这个，高价值、低价值，或者说市场区的这个光缆的一个情况。直接举了一些例子，可以把那个每个路段里面的一个瓶颈，或者说是不足之处，就举一个例子。同时对每条道路线的一个档案，每月去跑一次这个，有一个道路每个每条道路的一些情况。不是，就是在系统里面做固定档案。这些数据都一个几个月跑一次，流量比较大。按照这个路段，比如说我们全国有六六60000公里的路段，一个路段去跑一遍，把它的资源关。
- [00:50:26 - 00:51:25] 说话人3: 之后的话，那资源利用率，你的方案能进行优化。像我从国外呢，就是一些这个优化场景和这个策略的描述。那我们也是列举了一些一个优化场景，给给我们大家去交流。一个就是废弃光缆拆除。我们拆除光缆呢，我们在测试里面是掌握了很多，就是断路光缆。比如说这个，比如说一些末端基站退服，包括末端的一些这个专线的停闭。一般我们光缆的话，只就直接简单带门口，没有进行系统的回收。所以在系统里面会有很多这个长距离的一些断路光缆。我们建议呢，就是截断或者是回收，或者是这个拉到这个上海站预留。那我们可能上海那个每个离站近站，由于烧楼，远站的话可能有些的协调费。所以避免二次进站的话，可以做一些预留。第二个场景呢，就是头路段的光缆收敛。比如说我们有一个站A，A到B，B到C，A到D。
- [00:51:25 - 00:52:24] 说话人3: 都有光缆，那我们可能是放一个A到接头包，再从这个接头包去割接到B到C到底。A到接头包这一段呢，可能光缆这一段就可以进行一些这个腾挪。那么场景三呢是这个光缆路由的优化，我们是分有四个小场景。第一个呢就是以这个传统的基站到基站的光缆，那么这种情况呢就是它的费用比较低，然后它的光缆可能因为夜晚一些是SDH或者是早期的音频链路，所以随着这个老旧设备拆除的时候呢，也会很多一部分迁新，做了一些业务的调整，然后光缆就主动的一个拆除。第二款是这个承载一主要承载这个加班业务为主的一些一个接入光缆，达到OT这种光缆，我们可以去挑选一些这个利用率低的或者是跨区的长距离的进行一个换模调整，有光的一个缩短。第三个是一些几个专线为主的一些一个末端的光缆，大多之内二级光纤点。
- [00:52:24 - 00:53:14] 说话人3: 那这样的话也可以去提升二级分二级光交的一个利用率，也可以去缩短这个业务接入距离。那么第四个是一些这个C源拉远的一些这个方案，可以也是可以做一些C源去接入光交网，去缩短这个业务接入距离。那么这里结合一个案例分析呢，我们可能去年做了一个地铁搬迁，在这个人民广场就在我们在市中心的最中心附近。那么搬迁时候呢就发现就是主干道路上一些，次干路上的一些道路比较紧张。并且这个地方是没法加牌，只能在市区里面。那么对于这个南京路上一个路段进行分析呢，这个该路段为主干道路，应该配置8~15的限流使用。其实我们的就是购买是，孔数是储备到位的，但车辆方案确实比较多。
- [00:53:15 - 00:54:03] 说话人3: 利用率是113%，达到黄山预警。那么就是线网的这个百号已经需要做优化了，已经没法再去外去购买或者或解释。那么50个光缆中的小金光缆占比呢在60%，那接入光交网比例也是40%，是跟大五相当。那主要结论就是50个光缆里面有12根价值光缆，可以通过对应方式进行优化。那第一种是无业务的直接拆除一个，可调整业务畅通拆除的，是有四条。通过各级调度，10光交网可以拆除原光缆也是有两条。那么因此我们通过这个优化方式一、二、三之后呢，就是也是结合这个基站搬迁，搞重建的时候把这个路段上面，举个例子就是把这个路段上面的可能22组，这个利用率有113降低到86%。
- [00:54:05 - 00:55:02] 说话人3: 通过以上的一些这个研究我们，基于现网我们还是给出了一些这个思考和建议。第一块就是加强这个资金管控的一些储备，包括这个对于隧道大桥一些长期宝贵战略资源的一些储备。第二块就是建议是加强对于这个新增光接入光纤网比例，比如说是小新数，我们这个小新数主要定于20根及以上，这个距离超长距离的占比的考核。第三块就是这个对于这个分对于这个路网分成分级进行管理，比如说对于这个一干土干呢就是这种大型的这种光缆，它的路由呢尽量是要沿主干道去进行规划和设计。而且这些功能呢也是可以通过这个路段管理功能呢也是可以规划到这个系统，在设计模块里面去。那么后面几块呢一个是这个这光纤共享的一些权益的使用，包括这个后面还有一个叫汇聚点数光纤。那这块也是我们站公司。
- [00:55:03 - 00:55:55] 说话人3: 也是做了那个2323年的试点，就是说我们可能在一些比较长期自由的这种汇聚点的延伸段，延伸到两旁边两个路口各设立一个智能公交箱，这个智能公交箱就是替代这个街头包的一个作用，我们可能市区里面的人井打开，因为街头包里面的数量比较多，然后它的预留盘留会大量是占据这个维护空间，所以呢我们这个智能公交箱呢，进行一个收敛作用的时候，能够比较有效的去提升这个汇聚点门口那一段管道上的一个资源储备和利用率。后面是一些这个比如说这个管道预警的一些使用管控，比如说这个我们电信上海电信，它还是对这个资源管控，做了一些这个原则，比如说是莫控不串放光缆原则，红色预警这个不串放光缆原则。
- [00:55:56 - 00:56:35] 说话人3: 它还是加强了这个什么储备，因为你这里的预警如果不解决，你放了人光缆，毕竟是绕路的。最后一点就是加强这个基站搬迁的一个管控。在这个搬迁的情况呢，一定要对这个方案进行一个合理的审核，杜绝这个来回串扰的情况，防止闭环。项目呢总结呢就是一个就是形成了这个路段和这个资源模型的一个算法和模型，并且对这个转换进行初步验证和实现，呈现了这一个外的一个呈现。第二个是。
- [00:56:36 - 00:57:28] 说话人3: 网络安全的模型，对问题点进行分类和问题的剖析，形成这个策略和模型和case的论证。我就汇报完了。大家下午好，其他领导，这边，我广东公司呢是代表，这个叫做什么，我我是我个人吧，也是我个人代表我们负责这个政企专线维护的同事。简单的对这个广东省内的VCP的一个DNA改造的一个情况，做一个情况的一个介绍吧。这个题目呢其实是关于网络安全方面的。
- [00:57:28 - 00:58:19] 说话人3: 一项内容，我们的这里面涉及的网络呢，可能是广东省特有的一些情况，然后可能跟别的省份的情况可能不一定完全相同，所以里面提的一些情况也是想仅供大家参考的。接下来我就简单的把这个情况先给大家介绍一下，我们网络的现状。第一个就是全省，从全省的这个结构来讲呢，我们是以广州为中心做了一张VCOTN的一个新型的网络，大概是在2019年就开始做建设，然后呢，基本上这个设备厂家都是大主要是以华为主的，初期上的时候都是以华为主，后续陆续有0星的上了一些中兴和烽火，总体结构的话就是以广州为核心。
- [00:58:20 - 00:59:11] 说话人3: 然后广州这个核心的话其实分了六个站点，核心站点，然后是站街是用一个mesh化的主网，然后其中有三个站点呢是长途的节点，然后是对各个地市去对开一些vc的链路去做业务的转接的，就跨市的那个，链路呢就在这三个节点去开通，因为当初vc建设的时候呢，计划部门可能这个就是属于一种尝试性的这种态度去考虑嘛，所以这些vc的跨市的部分其实都是跟本地的vc设备是共用的，就没有单独建干建的vc的这样的系统，所以的话后续会引出一系列问题我待会提到，总体来讲呢省内的这个结构就是跨省这段是这样的一个情况。
- [00:59:12 - 01:00:09] 说话人3: 然后本地的话呢，结构也是比较相对比较清晰吧，也是分干线出口的节点，然后多层，第一层是干线出口的节点，然后第二层是重要汇聚，第三层是普通汇聚。在此这三层的这个基础上，可能就有CP的设备通过双规单规或者是其他方式吧接入到这个VC的这个网络上面去。这个结构上面来看呢，我们核心层的话都是用口字型的结构，然后相邻节点呢是采用灰光连接。底层是基本上会用波分承载，而且路由上面主网上已经是要求做口字型要做分离的，有条件的话都会做WARP或WMP保护吧。然后重要汇聚对之间呢，它原则上是不做汇聚对之间的那个互连量。
- [01:00:09 - 01:01:00] 说话人3: 目的也是会让这个主网会更加的清晰。普通汇聚这一层的话呢，基本上是用V型的结构跟上级的那个中央汇去做一个连接。总体的那个主网的带宽呢，也是以10G的带宽为主。这样的一个情况可能就是我们最初建网的时候就按照这样的一个进度去做。这样的规划。曲线的那部分我们原则上不搭，其实搭也可以，就就是让结构清晰一点。实际上没有搭，对对，实际上没有搭。然后这样的初期建设这个网络呢，其实当时可能也是一个尝试吧。所以它在这个主网上面其实还是有一些。
- [01:01:01 - 01:01:52] 说话人3: 安全上的一些不足主要就体现在两点吧，两部分。第一个呢就是我们一个跨市的一个业务为，不市内的一个业务为例吧，它是配的是普通SNCP的那个保护。这种业务的话，它端到端都在一个室内，是吧？用普通SNCP保护这种方式的话，其实在整个室内的话，它就是一个主备就是一个冲突域吧。然后如果主备之间的跨度越长的话呢，双断的可能性就越大。然后通常来讲，只要有一次触断，第二处再断的话，往往就会造成这个业务中断了。这是这个室内业务用普通SNCP是存在一个不足。还有一种情况呢，就是跨市的时候，我们往就会用分段SNCP。
- [01:01:53 - 01:02:47] 说话人3: 就是室内CP一到出口之间呢可能是做一段，然后对端四也是做一段，就多段的这SSCP。但是这种SSCP的保护呢，它其实问题就在于出口的时候都是集中在一个节点吧，就跟下面这张图里面，可以看到CP一它都左边的CP一都要经过N一六再出市到对端B四，这样的话这个N一六这个网元如果出问题的话呢，很可能就这条这专线直接就断掉了。所以的话，在这种结构下的话，虽然专线它分段保护了冲突，就是这种双段的冲突域会缩小，但是其实对于单点节点的这个隐患来讲，它它还是扛不住。所以的话对应的话，这个分段保护其实也是有它的。
- [01:02:47 - 01:03:44] 说话人3: 一样，有有它的不足。结合的这两个现有的保护方式都不够完美这样的一个现状吧，我们就也是去想看有没有合适的技术可以借鉴的，可以协助我们把这个保护能力进一步提升。参考了SH网络里面的DNI的这个保护能力呢，我们也想有没有可能把这个能力引入到OTN里面去。其实DNI这个东西是在SH时代已经早就有了，它本质上其实就是两个跨环的系统吧，做一些双节点的互联。这个互联的方式可以是四节点，也可以是两个节点，标准的话其实四节点，但是我们日常应用的时候可能通常只有两个节点，就做成两个环相交这样的一个结构。其实刚才回顾刚那个图。
- [01:03:46 - 01:04:40] 说话人3: 我们其实分段为SSCP就是两个环相切嘛，现在话其实要扛单节点，无非就是要把节点增加嘛，所以就是用双节点去做相切这样的一个结拓扑结构，去在结构上面先把这个安全的问题先给满足了，SH其实那个时代的话为什么我们一直都没太部署这个DNI，是因为这个DNI其实就是要做很多的业务交叉，去实现分段的多点的选收的这样的一一些业务的保护的，但是呢这个SH时代大家都知道可能还是国外厂家为主的一个时代嘛，所以都是要人工去做配置的，人工或者是效率都不太高，所以普及性也不是很高吧这个DNI，但是OTN这个时代呢，说说实话是以国内厂家为主。
- [01:04:40 - 01:05:27] 说话人3: 所以我们也是把这个想法和现有我们现网VC的厂家华为做了一些沟通吧，然后就依托它的S一的一些功能或它后台的一些平台吧，开发了一些做配交自动化配交叉的一些工具，然后把DNI引入保护的设涉及到的一些交叉配置这方面的一些能力补足了，接下来我们也可以也会再详细的稍微介绍一下这部分的情况，引入DNI保护的话其实理论上是可以做节点级的保护的，这一点从理论上我们已经有这样的一个设想，然后接下来其实简单的来看其实还是我们刚才讲的，就是。
- [01:05:28 - 01:06:22] 说话人3: 无非就是把环相切变成环相交，然后它的核心就是从环相切的话就是东西向同一节点东西向做SSCP交叉，变成是环相交的DNA保护队之间做SSCP的交叉。其实原理应该还是比较简单的，只是说通过交叉的冗余去实现节点的那个交叉的保护的一个选择。代价无非就是把交叉的容量消耗多一点吧，这个在OTN的这个时代来讲其实也不是问题，因为现在单个OTN节点的交叉的带宽容量也很大。所以的话我们就往这个方向去继续去尝试吧。对应的话呢我们在广州。
- [01:06:23 - 01:07:14] 说话人3: T网的VC的OTN的环境里面的去选呢，两个主网的环境去尝试，就手工去配一些交叉，实现这个DNI的这样的一个保护，配的交叉业务包括US、EU、O和CLAN的这种业务，然后在这个配上去之后去模拟，链路的多点故障，还有节点的故障，然后看我们的这个网络的实际上配置能不能下发，还有那个倒换的能力是不是能够符合预期，然后模拟故障的这个情况也是包括模拟单处故障三单纤双纤，三纤还有红联的故障以及单节点的故障的这几种故障场景，其实从这个场景来看的话我们。
- [01:07:15 - 01:08:12] 说话人3: 很明显看得到，就就场景一的这个结构其实就是左侧的是一个CPE，然后双上联到一个DNI保护队，这个DNI保护队就是配了一些保护交叉或者是多重保护交叉这样的一对设备。场景二是，所有末端都配了这样的一个的DNI保护队，两个的区别其实就是它是一对和两对DNI的一个主网的这样的一个差别。这两种场景会比较适合适配吧，本地网目前的那个专线开通的这个情况，所以我们就选了这两个场景。然后这两个场景的话，我们的线网做手工交叉做的那个导换验证，还有保护验证的话呢，总共是做了一些下面的结果是这样下面这样的一个情况。首先是基础的业务验证方面的话呢。
- [01:08:12 - 01:09:07] 说话人3: 无论是CPE到CPE，还是CPE到CO，还有CO到CO，这几种场景下的业务创建，还有单纤故障、双纤、三纤，还有红点、单节点故障呢，在网管上面看到的状态都是符合预期的，状态都正常的。然后从倒换的性能来看，我们是专门以CPE到CPE的U/S的业务做一个验证的，端到端因为要画表嘛。还是做了一个CPE到CPE的业务，是100兆的这样的一个数据，这个上面其实是，倒换时间也是在15毫秒以下的，时间也是符合要求的。我们可以看到就是，我们从单纤故障、双纤故障还有三纤故障，这三种场景是可能，这三种场景下其实，我们的通过横连这个。
- [01:09:07 - 01:10:00] 说话人3: 途径是可以构筑出一条业务的这样子可通达的路由的，然后横联的情况下还有单节点的故障下，其实它也可以继续就是业务也可以继续通过剩余的一条冗余路由去实现单道端的连通。结果的话，我们从现网的测试的效果来看的话，无论是我们测的100兆，这上面显示100兆数据，还有两兆、10兆、20兆等等，还有UoClam1000兆的这种带宽下，其实它都具备了这样的一个抗多点老化，还抗多点保护和抗单节点故障的这样的一个能力。也就是说这个配置其实跟业务的类型关系不大，然后跟业务的速率关系也不大。
- [01:10:00 - 01:10:49] 说话人3: 就是一个比较普适性的一种保护的一种能力。根据这个这样的一个结果的话，我们其实就继续下一步的一个设想，对我们现网的一个VCO天的主网情况做一个总体性的一个诊断。其实除了DNI这种需求之外，我们由于建网比较早嘛，可能而且前期的投入也不大，所以的话，除了这个单节点这个还有链路过长有设备同时中断的风险之外呢，其实我们还有一些那个出入局同路由，或者是短时延误路径的原因，导致这个业务配置会有小段同路由这样的。
- [01:10:50 - 01:11:31] 说话人3: 风险，然后还有带宽上的不足，特别是网深，可能实际带宽开几个客户可能就满了，这种情况可能会比较普遍。所以带宽也会成为我们现在这个这张网目前存在的这张网的一个不足之处。另外的话呢，还有就是我们新型主网这个结构下呢，广州有两个核心的节点，支撑了西帮村这两个点的那个潮位的利用率非常高。然后本地和干线都会占用这个网元上面的潮位，所以的话业务量一上来可能用不了多久，这个网元的潮位想再扩就很难。
- [01:11:32 - 01:12:19] 说话人3: 所以总体诊断出来的话呢，就是会有四个毛病吧，只能说我们这个这张网现存是四个毛病。然后对应的话，我们定了一个总体的优化方案。首先就针对四个方案四个毛病吧，开了四个方子吧。第一个就是通过D N H去保护来解决单网元故障和多点中断迁移的风险。第二的话呢，对于同路由的问题呢，我们还是在本地侧增一些O R P和电路加干线侧吧，加一些S S P的保护，解决同路由的一些风险，就尽可能去避免。第三呢，就是把我们跨市和省市内上联到。
- [01:12:19 - 01:13:11] 说话人3: 那个链路呢，是做一个100100G的链路的升级，解决我们实际链路带宽偏小的这样一个问题。另外第四点就是做分列网元，就是在广州把本地和干线的这种业务把它，带网元分开了。新增一对的这个DNI的这个网元呢，是用于跨市业务调度的，这样本地和业务就彻底分离，会会缓解我们这些资源不足的这个矛盾嘛。然后策略上的话呢，在这个新的这个主网方案下面的话，我们跨市内的业务呢会在普通汇聚和中央汇聚配DNI，然后跨市的话呢会在普通汇聚、中央汇聚骨干接入。
- [01:13:13 - 01:14:03] 说话人3: 我们的分裂的那对核心节点吧，也配D N I，波分系统的O R P的话，因为本地网会有一些图纸上的限制吧，所以的话，第四的这个是不太可能配S N C P了。但是目前的话，按照广东省内的这个安全的一些整治的一些要求，汇聚以上都是要做O R P保护。所以的话，目前第四的这个层面呢，在外线上面主要是做O R P保护去那个提供。然后省干的部分的话，S N C P的这个保护呢，我们是做单边，这个也是一个折中吧，就是口字形双上联的这个链路，如果双边的话，可能投资还是。
- [01:14:04 - 01:14:53] 说话人3: 所以跟规划部门妥协的一个结果就是做单边，就只要有一边能够保证，SSBP其实就等于是三路游了嘛，三路游的话这个保险系数虽然没有四路游高嘛，但总体来讲还是能够接受的。所以的话在省干的话我们做了跨市那个是配单边的SSBP，当然每个省份如果这个资源充足或者这个条件比较好，也可以配双边，这个完全没问题。然后对应的话我们这样开完这四个方子，其实是这11系列的策略之后呢，总体我们的效果会主要就是两个，第一个就是业务安全性肯定会得到一个本质的提升吧，因为抗单点多点还有突发的风险这些。
- [01:14:54 - 01:15:46] 说话人3: 都提升了，另外的话，这容量也得到了增加，因为实际到100是有10倍的一个链路的带宽的增长，总体能够满足今后可能比较长一段时间的一个业务需求。对应的话，我们会靠到线网，可能对第四做一个主网上的一个指导，比如珠海公司，它的主网就很单纯，它的可能初始就是一对群光大厦和南屏二期楼这样的一个节点，然后对接上去也是两个节点，这样的话，它就直接在这个，现有的这个网络比较简单的结构上，我们就按我们前面开的那个方式，把它室内的设备的D N I横连的这个电路线路上去，这个横连电路是个100G的。
- [01:15:47 - 01:16:46] 说话人3: 然后跨世界物也升到100级，原来的10级就不用了，或者是先保留等，后续是不用，先暂时保留，等100级上线之后就会可以撤掉，然后就做一个简单的一个联连接吧。其实整体来讲，它它的这个改造的这个难度也不大，就是室内加一对口100级的，然后跨世加一对的，这样的话就可以实现我们那个这个目标的一个结构了。然后这个是比较常规的一个方案，我们是可以跟施工司去做一个指导性的一个要求，然后施工司可以据此去跟当地的规划部门去提一些具体落在本地网一些项目上面的一些建设那个项目去。然后另外一个就是佛山的这个结构其实跟珠海有一点点差。
- [01:16:47 - 01:17:45] 说话人3: 它就是在一对山水通信中心和这个德胜这个枢纽，这个中间它是通过一个业务节点，一个OTN节点去穿通的。我们改造的时候其实就是要把这个穿通节点给去掉，我们让两个出口的节点直接就穿通。其他的情况其实跟珠海那个模式也是类似的，也是一样，就是这个横联这个，我们之间做了一个100G横联采用那个，辉光纤的辉光或者是波分电路型的。然后100G的这样的一个数据，它是也是配，辉光的这个SNCP的这种电。然后输出，总体就是把B四的这一场输出的一些方案给，施工师做一个参考吧。然后接下来的话，从主网的这个结构已经明确之后呢。
- [01:17:45 - 01:18:33] 说话人3: 可能我们就要解决前面提到的这个交叉这个问题怎么办？这个交叉这个改造的话，其实就是DNA保护的一个核心内容之一吧。其实就是要增加各种的双方选中的交叉点嘛，然后形成多点之间的SCP保护。然后这种保护配置其实，需要如果人工配的话，需要人工人脑比较清晰。然后还要去找一些空闲的时期去算，会这样的话对应的话，可能人工参与的这个成分比较高吧。然后一个是时间要求高，对人的要求也高。然后呢，它是通常都是要先删掉原来的业务，然后再创建那个DNA业务。可以，对于我们VCOT来讲呢，因为它承载的都是专线嘛。
- [01:18:36 - 01:19:24] 说话人3: 要征服。所以总体来讲呢，人工去做交叉，还有这个断业务式的这种方式呢，会导致我们的绩效的更低。所以的话，我们就联合华为对针对这种的改造存量业务的改造吧，做一个做了一个专门的一个工具。这个工具的话呢，就可以完全把上面提到的两个问题给克服掉了。根据我们的这个目标的话呢，其实这个人工配置交叉改为，依赖这个割接专用工具去配交叉的话呢，它的时间可以缩短到从原来15~10min，可以缩短到三分钟一条。然后每管能割的业务数可以翻5~6倍。按三个小时上。
- [01:19:25 - 01:20:12] 说话人3: 所以整体来讲，对我们对存量业务的改造，还有这个安全性或者可靠性来讲，它它都有一个比较大的提升。而且客户呢，他对我们的这个改造可以是无感知的，因为我们通过工具，实现了一个无损的，一个调整。就是通过改造过程中做一些业务倒换，先倒背，再改交，数据的交叉，然后再倒，这样的方式来回的做一些连串性的动作，会实现这个业务的存量调整。所以整体来讲，这个改造的这个效率问题，也可以通过工具去实现。当然我们讲的可能比较简单，但实际上后面。
- [01:20:13 - 01:20:59] 说话人3: 实现的话，其实还是比较多内容的。我们这部分我们跟华为也磨合了比较久，然后也是依赖依靠华为的这个研发的人员、主管的研发，还有设备工具的研发去做这个专门的工具。现在目前也是做基本上做出来了，也能适配现网的一些场景。我们有在试，所以这下面就是我们讲的，就是这个工具大概是今年四月份才做出来，然后我们做出来实验室验证完之后就放到现网去做一个验证了，就看这个工具在现网用起来的效果。然后也是适配各种的业务类型吧，还有验证它在执行。
- [01:21:01 - 01:21:52] 说话人3: 正向改造，和意外倒回这样的一个能力，是不是符合我们的预期？正常来讲，我们现在对这个工具，因为这里面我没有展示这个工具的能力。其实它的工具其实是，可以说一个可视化的一个界面，就是执行一个脚本。其实脚本是通过华为的一个平台去生成的。这个平台生成脚本是，先采先往网上的数据，然后去分析，它的一些空闲失线情况，然后生成一些脚本。然后你可能要告诉他要做哪一条SNCB的业务，要增补DNI，他就会分析那个空闲的失线，然后输出一个脚本。然后这个脚本是导到一个外挂的NCE的一个工具吧，去去下这个脚本。这个脚本主要是一个。
- [01:21:52 - 01:22:46] 说话人3: T I港是改造的一个可视化的一个呈现，它可以看到每一条业务它执行的过程，就改交叉的这个过程，改到哪一步完成了，然后哪一步要往回退，要实现这样的一个能力。这个工具最终的话其实是花了大概差不多大半年吧，然后前台后台验证和那个才弄出来的。主要的这个功能需求方面，我们其实也是结合我们日常的一些习惯嘛，就是还必须要打回的能力嘛，能去做一些自动化的分析，就不需要人工介入去找时间这样的一些去弄。然后这个工具的话，我们放在现网中，那这个网络呢去验证也是分了几个场景1234，这里面可能不会有一点点小。
- [01:22:47 - 01:23:39] 说话人3: 场景一其实就是，改造前后其实那个CPE上联的那对汇聚网元呢，都是就是必要配DNI的这个网元。然后场景二呢是，这个改造前是，改造前后都是新的一对重要的汇聚，然后CPE呢是没有直接连到中那个DNI的那个网。场景三呢是，改造前经过的重要汇聚已经换掉了是新的一对重要汇聚，就是新的DNI保护的那对重要汇聚跟原来的业务是完全是没关系的。然后场景四呢是，改造的这个是经过那个不同的DNI的那个重要汇聚网元，但是。
- [01:23:40 - 01:24:35] 说话人3: 普通汇聚呢，是原来的普通汇聚。这个也是跟广州公司去沟通吧，可能这个场景可能在本地，四个场景在本地会比较常见，所以我们也是用了这四个场景去做验证。我后面会提，因为目前我们其实是跟华为在做的，因为网络的情况我就说了，其实就是我们大部分是华为的，所以我们现在还是以华为探索性的吧，先把华为的先做出来看效果。回退测，对，测试倒回我们也测，就临时终止，然后让它自行回退，或者是直接执行完了再回退都可以。而且它这个执行呢是按业务来的，就假设我这个网联上面有100条业务，我可能跟客户约了是做今晚只做10条，然后这10条我就当晚只做这10条的脚本下去。
- [01:24:35 - 01:25:27] 说话人3: 然后下到一半，比如说做到第一条就出问题了，直接就回退了，然后面可以暂停，这样的，可以做到这样的一个效果。目前这是跟我们自己的维护习惯比较相似。对。然后这个改造验证的结果，我们简单拿场景四去做一个演示，这就是SC上面的一个截图。这个结果其实原来就是主端这样的一个主备方案，实现是主用备用是虚线的这一条路由。然后改造后它其实就是在中间的这个4519645197这两个，加了一个横联。其实看上去它没有太大变化，就多了个横联。但是其实的话，就是在哎两个横联的这个网元之间加了若干的交叉连接，去做SSCP的一些防护传输。然后网管上面看出来，其实就是。
- [01:25:30 - 01:26:19] 说话人3: 然后改造的这个时间，确实是耗时也是达到我们的预期的，然后呢业务也是没有中断，我们是通过话表去做一个验证，无损的这个效果还是比较确定。我们现网客户没有感知，不过我们其实是试验的时候，我们是拿仪表去测，对，拿表去测呢，就没有真正拿在我们的业务去试。现在的话我们在网业务我们也做了一个改造，这个改造确实是无损的，这个就是我们就是验收的时候跟科委协商，因为验收的时候发现他有个物流的问题，就是本地网它广州到揭阳这条专线吧，在揭阳这个地方呢，它放了两个不同层级的部分，一个是一级部分，一个二级部分。
- [01:26:20 - 01:27:09] 说话人3: 它就不可避免可能有些部分全部是同源了，然后发现了这个问题之后呢，但是业务客户其实已经上了，所以说客户已经上了，但是没办法，我们就尝试用这个D N I去改造，直接把它改过来，顺便测一下这个无损的效果。其实也跟客户打个招呼，然后客户这边也同意我们去做。做完之后其实我们原来的那个故障点就是上下这两个点一段，就是故障到CP这段就全断了嘛。然后改造完之后它的那个路由就可以这样绕下面，这个把就是绕这个上下这个点这样过去，把故障两个光缆段其实都绕开。这样的话其实测的话，这条两A的专线其实也是可以的。客户那边给我们其实他都没有反应，改完之后他都没有反。
- [01:27:11 - 01:28:02] 说话人3: 就是这个效果来看，还是在实际的这个效果来看，还是可以的。其他的话，我们是做了一个计划，就是对这个线网改造案例，我们一步来。就到了线网改造，确实这个也试过了。然后面的话，我们总体我们其实有个这个计划的。这个计划其实简单回顾一下，03年开始做一个验证嘛，然后中间会涉及到跟规划还有本地工程的一个扩容交互吧。就是扩容链路还有那些端口资源提供出来做主网的这个规划。所以总体我们到还有分列我们觉得建设是一体的。所以大概是而且中间我们自己的主网的预备情况已经历了大半年。中间华为厂家去做那个工具的开发。
- [01:28:02 - 01:28:57] 说话人3: 还有线网的一些磨合试用吧，也也花费了比较长的时间，所以我们真的是在今年四月份才开始去做这个实际存量改造的这个验证。然后呢，后续的话，我们暂时计划是在今年底把重要的专线的B N I改造做了。其实也只是做重要的专线的部分，也不全量，因为全量的量还是一个是比较大，第二的话呢，这部分可能改造还涉及到一些费用，这方面还没定。所以我们只会对一些重要的专线去做一个考虑。然后这里面反正就从24/03到今年目前那个情况吧，大概会接近两年的时间，会把这个重要专线这部分的这个改造做完，从无到有吧。反正这整个过程，可能回顾一下觉得还是做出来还是有点价值，自己感觉。就是反正摸按摸吧，也是跟厂家也和。
- [01:28:57 - 01:29:57] 说话人3: 然后自己也会提前想法这样去做。然后对应的话，这个改造的话，它有一些要求吧，比如说链路，还有规划主网上面的一些要求，可能内部要先协商好。另外它网管版本也要适配。然后R2~3这个可能大部分省份可能已经开始在升嘛。然后设备版本的VC设备呢，要R二一以上。然后改造的这个工具呢，现在其实应该开发出来了。正常来讲，如果各个省公司可能比较强，应该也是能用的。但是这个产区不在广东。就是它这个其实是比较强烈依赖于厂家内部的一些资源分析，是脚本这个东西暂时我们自己是没有办法去自研去实现。因为可能跟底层捆绑的比较多。但是这个工具确实现在也支持各种类型的一些无线改造。我们可能自己去做的话，主要在工作台，就是下面工作目标里面。
- [01:29:57 - 01:30:44] 说话人3: 预计工作台，我们把新增的那部分通过D N I的这个工具的能力去在新增业务我们自己去做。存量的业务因为还是改起来会比较复杂，所以还而且可靠性也可能相对没那么高了。所以我们存量的那部分可能以就会倾向于用厂家的工具去做，新增的部分就通过我们自控作业台的那个开发去适配了。无非是多笔交叉，可能新增的这个业务做断了应该会有点大，做错的可能也还好。所以的话，我们会在新增的部分考虑自己的平台去做一个能力的一个实现。另外的话呢，在厂家方面，也因为这位那个专家提到的，我们在也在推中心的O T N这部分做一个。
- [01:30:45 - 01:31:33] 说话人3: 能力的一个开发，中兴目前反馈的话就是，EOS的版本已经具备了，设备和网管都已经有，但是EOS的话还在做一个研发，上面的一些准备吧，预预计是今年底。但是这部分呢，它也只是做DNA的一些功能，对于这个存量业务工具开发，可能还在第二阶段没那么快，这个可能还得再等吧，因为广东的这个，量主要是华为嘛，所以中兴这边我们放在第二步，烽火那一块的这个，因为就这个量更少，所以我们现在还没考虑，或者哪位省公司可能有哪些省公司可能有这个条件呢，我觉得可以尝试一下，行。然后这个整个过程大概是这样的一个情况，然后我这边的分享。
- [01:31:45 - 01:32:43] 说话人5: 各位领导，那专家大家下午好，辽宁公司也给力。今天主要是跟大家那个，分享和交流，这是市道县路由自动管控的一个实践，和SPN三跨或者是跨县区、跨地市、跨厂家的能力的一个实践的一个交流。主要分了四部分，一个是背景，一个是原始传统的那个本地逃生的一个思考，还有一个是高铁的一个逃生的一个实践，还有SPN那个三跨能力的那个验证和实践。这个背景就是去年八月，19号的2012，我们那个葫芦岛建昌，因为是那个台风导致，建昌市道县的多条路由，因为三条路由，市道县是全部中断，然后造成了我们整个建昌县的一个三个乡镇的一个通行受阻，然后建昌地区就90%以上的那个车站都得掉。
- [01:32:44 - 01:33:32] 说话人5: 然后在这种三段的情况下，然后我们就来思考一下，就是我们怎么在这个OTN和SP这个网络，然后能不能够进行自动逃生的这么一个想法一个探讨。这个呢，就是在传统情况下的OTN的一个流程的一个思路，就是比如说我试道线环的一个逃生，试道线，全组的情况下，一般呢我通过第三路，通过第四路，然后我在通过跨线区的这两个跨乡镇的这两个，或者是在利用我这一个跨省或者跨市的这个干线资源的这一个逃生。这个场景一就比如说我试道线拓扑方案全段，但是我第三路有第三我第四路。
- [01:33:33 - 01:34:31] 说话人5: 每段的情况下，我就可以人工到现场，然后把我的那个实到线的观览通过第三路由第四路，跟人到现场去给讲明。然后场景二呢，就是比如说我实到线观览就全阻断，我的三速路由也全阻断，是吧？然后我的传统的方案就是看跨线区有没有这个逃生的观览逃生观览，然后人到现场到这个，这辆车的这A二这个局，然后跳先跳到咱们的B一这个局，然后B一这个局中有空线信号，再回到这个核心局一，然后回到核心局二，这样一个传统的逃生。如果是距离太远的话呢，我可以带着咱们的放大版，到到现场去，到这个B B这个B局B一局的现场，然后把那放大版插上，然后借助咱们那个光放大，然后咱们造成，这也是一种一一种思路。如果前期没有前期不足的情况下，我们可以临时把这个B一到核心局这个这条缆给它断开。
- [01:34:31 - 01:35:27] 说话人5: 利用它的立救千斤，是吧？咱们也可以从这儿逃过去，上来回来，回回他这边的。这是咱们传统的一个一一个逃生的这么一个思路。这是长这是场景二。场景三的话，就是我这两个线区之间没有那个可用的逃生光缆，但是我这两个，东区下面有普通的咱们那个现场环境，这有逃生光缆。我也可以，在紧急情况下，受到线圈组的情况下，紧急来进行人为的现场逃生。就是人到这，就是咱们的抢夺人员到这A二这个局，然后借用他这个光缆，这光缆的扣眼千斤，然后再转入到咱们这个A一到B一的这个逃生光缆上来，然后回到B局，从这儿再上来，就像红色的这个线。然后可能有的地区上，然后是距离比较远，咱们可以携带着咱们会带着咱们放大板，是吧？到现场去查在哪看哪。
- [01:35:27 - 01:36:24] 说话人5: 电源设备，咱们给他接上，然后让套用套上。如果说是没有空压潜芯了，也可以在紧急情况下，比如说咱们没有空压潜芯了，我们断开，让这边的环有一半可活，然后让咱们借用它的空压潜芯上来，给它俩再回到咱们这里。就是这样的一个现场的一个人为的，到现场的这么紧急的一个逃生的这么一个思路。然后这个场景二也是，世道线所有光缆全阻的情况下，然后呢我这个跨线区还有线区之间就是没有可逃生的光缆，然后呢我可以借用我干线的这个，还有光缆资源还有干线这个资源来完成，然后我这个世道线的这个光缆的一个逃生。就是我A线区正好是它当地，有我们的干线的那个资源，然后通过干，A线区和干线光的光缆，然后再通过我干线的这个空压潜芯，然后再迂回到我这个核心。
- [01:36:25 - 01:37:19] 说话人5: 然后中间距离可能远，然后咱们就得写那张，看哪个站，找一个比较合适的这么一个站吧，把那个咱们放大板都给拆了，然后作为一个临时的这么一个现场抢修的这么一个思路。但是所有的上述的事情都是得让咱们人到现场去，而且还得那个熟悉咱们的机房，熟悉咱们的设备，还得对咱们的天线，还得要了解。所以说这就是一个，我们就在探讨有没有一个什么可以自动实现的，对吧？就是我们试到现在OTN光缆全都是什么，通过自动的一个思路来实现的一个。下面就是咱们一个，就讲咱们有一个自动误差系统那种一个实验，然后我们也是做了一下验证，应该是还是可行，因为在后边是能有。然后这个就说的是那什么。
- [01:37:20 - 01:38:14] 说话人5: 前面是引入那个，欧沙西，就是欧梯上自动公交车的这个，嗯一个场景。就是比如说这个是盘锦大娃，是本地油田，他到盘锦，就从这边来，是到盘锦是吧？他10号线全阻了。他对只能逃生呢，只能通过盘锦到营口，这个这营口也是我们二二干设备，通过这二干设备。然后大娃来了，到营口直接就回到这个，进入二干的这个四杆，直接就回到这个盘锦市了。就是这事儿是盘锦大娃的这个套装。然后鞍山这个也是，鞍山的这个套装，他也是正常，就是鞍山本地泰安那个是吧？本地油田，他10号线到我鞍山综合楼，对吧？这10号线断了，他也可以通过鞍山本地油田。就是就会让我干线的盘锦综合楼，然后是回到营口辽河，然后是回到鞍山海城。
- [01:38:16 - 01:39:10] 说话人5: 这样的一个通过这个岸那个逃生呢，它也是需要人为的到现场，然后那个去进行跳纤呐，然后去查板子呀。然后这两个有个共同点，不管是攀井捞蛙还是我这个安神泰安，它都是经过了我这个引口调和的这么一个点，然后去通过这个引口调和这个，我就引入了我们这个自动关节差的这么一个设备，然后也怎么样一个技术，来实现无论是我攀井捞蛙还是我安神泰安发生摄像头线冲突的情况下，我能不需要人为到现场，通过我这个摄像机自动来逃生，然后自动通过二干来迂回来，然后来实现我这个摄像头线上全部导下的这么一个网络的这么一个自动逃生。再就是SPS逃生。
- [01:39:11 - 01:40:01] 说话人5: 因为是上次虎岛这个发生了这个市道线中断之后吧，我们也在思考，S SP呢本来它就有这个L三的这个能力，为什么S就是为什么不能通过这个我这个能力来实现我在当我市道线关缆全阻的情况下，我业务能够正常逃生。无论是我SP是承载在OTN下，还是说我是关缆指导的小车上，都需要来通过这个SP的这个本身的技术能力，然后来进行这个逃生。然后当时我们就想到了一个，就是通过SP这个市道线全阻之后，我们是不是可以做这个跨线区的逃生？如果跨线区逃生，如果比如说线区到市内是吧，比较远，我是不是可以进线区跟其他地市的线区就是相邻，我是不是可以通过这个跨地市来进行。
- [01:40:02 - 01:40:30] 说话人5: 如果说，跨地市之后呢，而且这个地市呢，比如我本地市是华为的，我另一个地市呢，是中兴的，我可不可以通过跨厂家这个进行这个来实现跑通？这就是我们还在，思考和实验点的那个，一个什么，我们叫做了一个这个神话吧，我们叫神话的这么一个跑通测试，而且是，效果是达到了我们的预期。这个呢就是，我们现象还是就是我们统县区内，我们。
- [01:40:30 - 01:40:32] 说话人5: 有个光缆中断的。
- [01:40:32 - 01:40:35] 说话人6: 我想到了，我我天呐，他说。
- [01:40:35 - 01:40:41] 说话人5: 我讲的是什么？没有，能自动套声。就是那个，这个就是通过什么？以前咱们。
- [01:40:41 - 01:40:45] 说话人6: 是吧？我也没参加，我忘了。
- [01:40:45 - 01:41:44] 说话人5: 接入环，咱们换了一个路，就是每个汇聚环换了一个路。然后我们省现在就是把一个SPN下面，所有的换到了一个路上。然后通过这个，无论是，然后把这两个线区之间，光缆可能再给它连上，就相当于迈上铁路了。通过它SRB组实现了这个网络的这个SPN的这个多机、多场、远、多级的计算过程上的一个自动逃生那种一个便捷。这个就是咱们刚才说的那个高铁自动逃生能力的一个验证，主要是这个。这个是是，因为咱们南盘锦，就是刚才咱们块儿干说的这个，就是南盘锦大巴到盘锦三号桥，它有四条线，有有两条路，它是一个方向，主备是吧？主备方向。然后呢，鞍山综合楼到台安，它也是有两方主备。然后第三路友呢是通过我们干线的是另一个方向。正常的话，我们盘锦的大巴，它不管是。
- [01:41:45 - 01:42:34] 说话人5: 两条路有三条路，它那个就是全是比如说全是由西往东走。但是我们这个应急路有，因为它是从西往东走，绕开了我们这个，不管是三路、五路或几路这个风险的跨河，是吧？我绕开我的河，我通过二干的这个，通过我另一条，比如说我通过五号营口，再绕回到这个盘锦。彻底的，我这个应急范围就是咱们市道线的地方，我两个就全部避开。就是刚才咱们照片里边，也就是这个，比如说我从盘锦到完到市内市道线，它是这个方向，对吧？我市道线去全走了之后。然后但是我有一条应急的干线，一条是从一路方向过来的，它是净是从西往东。那时候我逃生命令是从东往西，然后通过干线过来，然后通过干线又。
- [01:42:35 - 01:43:34] 说话人5: 草能回到我们，看见那个。然后说的就是这个。然后我们采用的是，主要是采用的是O R的皮。最早大家都是1:1的，然后我们采用了O R的皮，1:1:2的版本，就是主倒背，然后背在段背在倒背，就是就相当于是主用段了，我倒背，然后背回用了，再倒到背，就已经挺够了。咱们最早的不知道O R的皮，O R的皮不都是1:1的那种吗？就是一发一手，就是我一个主用一个备用嘛。现在我们就是现在能就是咱们奥杀系列，如奥杀系列的，如这个，就得是我正常是不是一个工作两个备用。我主用段的时候，我先倒一背在段的时候，我倒2:1。可以定制，也可以大家有的也有两两套板卡，就是两套板卡也可以融合在一起。你说我正好备有一个一主一背嘛，或者备用来了再接到一个板卡上。不对，那厂家也参考过。就是我们这个是单独的板卡，就是它。对，都是那个光学和独立的都。
- [01:43:36 - 01:43:37] 说话人3: 我是三毛的。
- [01:43:37 - 01:44:35] 说话人5: 三八的，就是光迅和中裕的，我看光迅和中裕的都有做。然后有了，我们已经验证了。对。对对，就叫做多层保护，但是吧，多层那个保护吧，不是说还是这个方向的，只不过是咱们应急的一个方向。对呀，就是正常受到天降都得有三条护栏，就是我们省得要对这受到天降必须有三条护栏。但是你这三条护栏吧，其实也是一个方向，以水过人，也是可能这个河这么走是吧？也是可能三条路就跨这个河。所以说我们这个应急是不怕河了，绕到其他地势上去绕过去，通过干线自己。这就是一个这样，就是提供了一个应急路，就是跟主备路由不同方向的一个应急路，来实现咱们说应急的逃生嘛。然后就前提就是这块放了个1:2的，也可以是咱们以前的1:1:1的，就是我有两块板子，主用进来是吧？然后出去了，然后备用进来，再进另一块板，然后再出去。
- [01:44:35 - 01:45:29] 说话人5: 实际上还是原理上其实这么原理，就实现了咱们的这么一个。对这要长很多嘛，刚才老师长很多嘛。然后这个，这就引入到刚才的我们这个欧卡西的这个设备，就放在这儿。欧卡西设备里面，它也是，咱们这个二干手，二干那个机房里边，可能也有中型的库，每家都有。拿两块放大板，第三个一是一发一收两个方向嘛，要插在咱们设备上，插在那咱们那个光旁光方向上。作为它的咱们东西，它叫这两块板，这是咱们的放大板，就插在咱们的光网线上。插上之后，然后咱们这会儿还有一个欧卡西的设备，就是，两轴的这么一个设备，它是可上管的，可现场配置的，它是通过光开关的。就比如说咱们这个盘点大妈的这个，这雪山上接在这儿。
- [01:45:29 - 01:46:22] 说话人5: 通过可以网管可以配，就是我配到这个，我这边有一个放大板嘛，我配到这儿来。这个都是事先接好的，就是这个了。我放大板，这些线都是事先接好的。它是通过咱们那个一个网管那个可以对它的进行，然后光开关配配。就是我这一口背后这个二口，我可以配到10口来。然后我这个，那个是安装方向的，我这五口也可以配到10口来。当当我这断的时候，对吧？我这光我这边光就过来了，过来之后，它它这边，它这个光进来之后，它发现，我收到光了，然后我就光开关打开。我这个，这就是这样嘛，就是我的光进来之后，然后他发现我收到光了，然后他那个光开关打开，然后这光从这进来经过我的放大板，放大了嘛。放大之后，然后出来，因为它事先配置好的，然后从这走出去，到这，到我的这方向，直到终点。
- [01:46:22 - 01:47:15] 说话人5: 方向就上，它就是这么一个东西。但是你得有光缆能到这儿。主要是你对，主要是你有光缆能到这儿。你看我们边上有营口做的这做的实验的，因为我们泰安也能对都能到营口，就是它的光缆，通过都能爬到我这个营口看一下的。然后我就通过这个通过只能到我这个地方来，然后我就可以进入到我这个自动观察设备里。然后我就可以。对对，至少得有第三条路由就是。底跟原来咱们世豪线全同一路由得必须得是能分开。对。然后就是通过这么一个几个点来实现的。就是因为去年我们那个建塘嘛，世豪线全断了嘛，然后也是抢修嘛。刚才那个谁，济南的超导也配合这种也说了我们建塘那个事儿嘛。
- [01:47:16 - 01:48:03] 说话人5: 但是呢，你人没到现场嘛，对吧？你人到现场去到机房里跳线，对吧？你们这不就有时候散乱，然后转路了，到机房很时间很长。然后我们就探讨，能不能通过就是这种自动的这种方式来实现这个。其实就是比方，如果说大家说，如果说有第三步有的话，我们举点比较少的话，可能不需要这个观察器，对吧？因为我就我觉得一条路，我直接我这块直接，那我放大板，直接我就把它去做。这只要有一个这个bar的皮，这个要有这个。如果这个就相当于是我为啥你观察器，就是我多个本地的站点，要进入我这个，然后进入这个机房的时候，才能通选择。如果是只是一个方向的，不需要选择的话，就不需要这个。
- [01:48:07 - 01:48:54] 说话人5: 这个就是基本就是这么一个设备。对对，做完成过。因为咱们这个方大板嘛，就是咱们那个，一个方大板一个铲子，咱们这个比如说这铲子华为的方大板是吧？一个铲子华为的，光盘是吧？对吧？然后它就是，这个是咱们什么的嘛，就是专用的嘛。就把它的咱们方大板，一发一声，方大板一发一声，给接在我这边后边洗这个设备，就已经接在这后边洗设备。就是这方大板其实就咱就说咱这儿方大板其实就已经接在这上。它是个，这个后边设备是一个，多多接口。这玩意儿就现就用用22二点15。这个什么嘛，这个方大板，咱们知道吧？我一个发方向，一个收方向，对吧？在当时咱。
- [01:48:55 - 01:49:34] 说话人5: 。对通过刷机。对对，就是我通过，就是它也是有网管的嘛，它是有网管的，可以事先配上，就是我这个，比如说给他，我盘起这个方向，你来了，进来之后，然后我不得，进了之后，然后我让它到底放大板，对吧？进去放大板，那放大板出来，那出来这不正常不得啥吗？不得这个。在内部，在咱们在内部可以做光开关，然后我可以走这个方向嘛。对，去下一个方向。对对，我这机外壳可以配多少个方向？内部可以。三高。
- [01:49:34 - 01:49:45] 说话人2: 错了，身高给你道歉，应该叫身高也好。你说开会么？没有，我就说一个，不测他，对你我直接用语音在播，随便在看。
- [01:49:45 - 01:50:42] 说话人5: 的使劲。感觉到我过来之后，光开关儿不，就他这样说，平时他妈都是得配好的。他说：“你这个自动调节都配好的。”然后我们光就过来了，过来之后呢，我这个自动交叉光我们就把它打开了之后，然后他就开始按照咱们内部事先设好的这个方向，他就出去了。他他就是经过了这个放大板，就把这光一放。我不感觉啥，这不是暗杀方向的，不是这暗杀方向就来了吗？对。对，这他有多口，有暗杀来了之后也在这，他也是事先配好的，到这啥，出来之后就这。对。我们测试的是这天津那个大牙印牌，你知道吗？就边从这到。模式不是，它是那不真的是。对，是有两油的，那么一个小盒子。对，就是个黄开关儿。不是，就跟R的P，这都三八呢。
- [01:50:43 - 01:51:39] 说话人5: 对，两优小盒子就是，他说有的都有30个光纤口，对吧？就是我把各个的都插。不是内部的。它就是。对，就像我交换机，只不过是光交换机，光的对。对，物理上。但是他通过网管上可以配置我这个口，我这一口的光往哪走。对，因为你想实现自动的话，你就得。对。有网管了，可以网管。有网管。就我们，你可以通过M的信号把这网管拉到咱们省端上来，你也可以在现场，都可以。然后下边这个就是，刚才说的那个三跨的，这个场景就是咱们主线区的，就是我这个线区内我的那个我汇聚、双断呢，或者说我接入环双断呢。我我们省就是把原来的不是，每个汇聚环下边和接入环双断呢，我我们省就是把原来的不是，每个汇聚环下边和接入环双断呢。
- [01:51:40 - 01:52:32] 说话人5: 现在我们把整个五个都是下边，换了一个用。然后就是根据你的观览情况，就是我这两个汇聚之间有光缆，对吧？光缆距离呢，它说还比较近，然后还能搭得上，对吧？接触之间的或者是能够搭上。就是一两点之间能搭上，就能保证我这个双端的情况下，我可以通过那个什么S R B E是吧？或者是先S R B，然后套成之后，然后再什么，我们把S R T B组组，就是S R T B组组，全部S R T隧道全部变成通路，然后把全部的功能全部打开。就是在我任意两点终端的情况下，然后都可以自动合成。这个只是那个图像区的情况下。然后下面这个就说是我那个视道线，还是说或者回头又说到我们视道线。比如说这就是我们那个建长对吧？视道线全组的。
- [01:52:32 - 01:53:24] 说话人5: 赤道线全阻也是两场景，一般的这个，管控的全阻，一般是管控路全阻。因为管控和咱们那个上行吧，应该都是同缆，或者是都是通过OT或者PT上来。只不过是赤道线断了之后，然后咱们的管控也断了。然后我们就是做了两次逃生，第一次就是我们国防队之间，就两个县区国防队之间。然后我们找那个再找条光缆，然后给它连上。然后普通飞机之间，然后找光缆连上。然后前提就是光缆距离吧，然后这个要就是不能大于8810公里，因为我们用的是百G的这个模块来实现逃生。然后就是，如果是超过百G的话，就光缆直达可能光缆二层，性能就性能不够。然后就连上。然后我们测试的时候就比如说我连管控我带那个上行全断了。
- [01:53:24 - 01:54:24] 说话人5: 我的业务，然后通过这个，首先是通过这种最低第一个命令一，然后我觉得从什么，就是如果不断的打路容跨区的，到时候这个L二的，然后几颗业务，或者说到时候那个什么业务，但是咱4~5G的业务，那只能是模拟，4~5G业务什么的。前提是在这儿打个玩，就是在我们黑龙江这边，找了一个板卡，有两个碰线板卡，就是咱们说百G的也行，因为我们都是做这百G的，就两个百G板卡，然后现场咱们先打个玩，然后咱们呢就是咱们这要保的这个线区的S P S P对之间的找S P来打玩，这目的是啥呢？就是通过这个L二这个U M，这不你看咱们去打玩这个其实单播数据，一个是N M，一个是L二N M，这边是上面也是是L三的L三L二，也就是通过这逃生路径来模拟出一条。
- [01:54:24 - 01:54:28] 说话人5: 其实我跟朋友现在不是，怎么说是这么说话了，但是。
- [01:54:28 - 01:54:40] 说话人2: 天天是这个像特别要有文化，可以来做。你可以自己，特别是年龄的外国去。你你的录音拿出来，已经在回忆。那不得两个。好，轻松了。
- [01:54:40 - 01:55:38] 说话人5: 他两个项目了。因为I L R I的业务来模拟这条光缆，它就像用的。就是原理，不管是跨线区域、跨地市，或者是跨厂家的，原理都是这种原理。就是我通过业务，然后模拟出一条新的光缆，只不过是这条新的光缆是我，是是，就是绕我来的，绕的。正常的话，我10号线直达的，断了之后，或者通过一条，不管是L R I业务，还是在干什么业务，做的很。模拟出一条新的光缆，然后导致我上游的，都是从这儿过来。然后这就是，我们的这个跨线区的人们一个自动逃生的一个思路。然后也就是说，对流量上的，然后有要求，就是看一看流量，就是你选择多大的这块。如果说你想只想保多不保质嘛，就是我发生的10号线光缆全部是中央，我我线区线上全美的情况下，我只保我的通话，我别的通话只是能。
- [01:55:39 - 01:56:31] 说话人5: 通话就行。然后咱们也可以选择，我这块我们省都做的验证成功率百斤。如果说我没有百斤的话，我可能有10G的，或者说也可以。知道普通话你是。首先，我我就是在那个上行，比如说我正常的我们省，比如说其他省上行流量，那说100%分之20，这边是20%，对吧？然后合起来，是，那说就40%，百斤的40%G的。如果说你说我这10G可能就，质量就不行了。咱们可以用50G的，可能百斤。在它的同时，就是这么，划线区域就是这么一个百斤一个数。它这个也是，就是我不仅是那个射道线双断的时候，它优先是走那个，等我那个，买这个时来优先走第一，我一段的时候，然后我再走二。然后比如说咱们有条件的话，我可以，比如说我在普通接路上，在50G在两。
- [01:56:33 - 01:57:26] 说话人5: 只要是光缆情况有具备，就是到时候这样都行，光缆都两个够。只要是你两个线局之间有光缆都可以。咱们就可以做这种什么线光缆勘测，这样都可以。那通过这种线局来进行投射，那就是这种。一个投射的这么一个思路。那我们省也是，做了好多线局的，那个朝阳那个卡，就是卡索，连元卡索呀，丹东的，还有辽阳灯塔工厂里，我们省这个做了，已经具备了地方。投射的，我们又做了验证的，我们也是。其实就是每个地市我们每台嘛，我们都会验证一遍，它是没问题的。回过头来，这就是。跨地市，就刚才咱们说的这是，我这个片区吧，因为我练了一下，你对我本事的练了一下，就非常。
- [01:57:27 - 01:58:11] 说话人5: 跨式的线群，它俩。在这个情况下，就是我市道线光缆去传输的情况呢，我可不可以通过立线的，带我来逃走。也是这两样，但是都是中心的，也可以。那就是也是，但是只是这个短路，也就是也是这么连上，进行这个短路。然后刚才那个干线区呢，它是那个L三的，在我自己一个网管内部，这是因为跨网管的嘛，它是网管，这个有网管的，另外那个都是有网管的。屋里，都是一样，只不过是这也是，那我给我打了个弯儿，我在这个在这边也是打了个弯儿。也是打了个弯儿，这个就弯儿，也是打个弯儿，也就是相当于我你一条光缆，就是我市道线光缆全部，我你一条光缆。
- [01:58:13 - 01:59:13] 说话人5: 再到这儿，也是新生成一条路，适合先关了。适合先关了，也是，就是跨越区域跨二干。这个就是，因为这是两地市嘛，两地市互通的情况下，这都是北京的网。那怎么从A地市回到B地市？就通过二干子，就提供了一个北京的。然后他们这块儿对互联互通，然后这块儿互联互通。然后通过，然后这边也是，就是通过这个，我A地市，我做点L二业务到这儿，然后我我B地市做点L二到这儿。然后通过二个，它都全程互通。然后就可以实现我们这个系统。我是适合先关两全程的情况下，然后至少保证我4~5级业务。就是4~5级业务，然后能通过这个，通过咱们这个投成业务，然后来后面来保证我就是在抢眼和抢眼的时候，我我还有业务，还在。我是管不掉了，对吧？
- [01:59:13 - 02:00:05] 说话人5: 管控掉了的话，那咱们有几颗业务是吧？跨跨区域的、跨域的或者跨区域的业务，那几颗业务不保。那如果管控没掉那些，那几颗业务也能通过S I P P重构功能，那也能重构。都是这么样的一个场景。这个测试的时候，应该是有点那个跨城。这是跨城市的，我这华为一个什么一个华为，当时是测试的，就是我上一段的话，第一路的时候没问题，当我第一路再段的时候，111111，第二路的时候，完了，结果那个路断续续。那华为给你解释，他那个频率是，他那意思，他说他是九周期，但是每周七是10s。
- [02:00:06 - 02:01:03] 说话人5: 它是整个周期，发现整个它，在这去完保之后，它才水，才才能走到那个第二，走到这个。我们说，后期呢，应该是有专门的，他们都知道是把这个升级就能解决，最后解决这个问题呢。这个也是我们省的也是，在那个，在铁岭拍人和沈阳康宁，这个是我华为的，然后鞍山T C和这个北方电视中心的，然后是湖岛联想和锦州，这个是有个峰，S P的，这三家每家都会都做的这个时间演练的。这个基本上是就是，没有问题，那4~5G的只能说是升级，然后掉的话也没有。那其实，在我们掉的，对他们那个，所以那个，差不多了，还有那种发现区的这种，因为它掉的之后，没法重播，没法那个导致他们那个，那机壳的也会，那化学。
- [02:01:11 - 02:02:02] 说话人5: 没有视频是没问题。这是这个，快递室的。最后这个就是咱们这个，他俩一样的这个。跟刚才快递室那个是，嗯是的。快递室，你比一下，唯一的区别，这就是这个，华为的这个东西或者这周星的这个。两个SP的这个一个厂家。那是也是的，比如说线群，只跟这个华为的线群，只跟这个周星的线群，他俩近，往往这样同它同，也是可以的。那原理放在那是一样，也是。我把两个SP都连接了，或者什么的，我把个后羿只连接了，或者我接入了，或者我接入个后羿连接了，都可以。都可以的，长什么来，距离也都可以。那都是也是什么？距离，也不超过85m。而且这个测验证的在测试的过程里面，发现了一些问题。主要就是咱们那个。
- [02:02:03 - 02:02:52] 说话人5: 100G的那个八G的这个光块儿，没有这个没有同款。至少你看我们在测试的过程中兴和烽火。中兴的它那个80几G，就是85，100G85的光块儿，它就默认它的F V X。烽火的默认是不起。因为它是，我们不带潮了吗？每每家都有F V X的，就起也不行。后来这是怎么点的？后来这个烽火这个在底层上把它F V X，我们就起这个起。在那个，等到上面去，然后把它起。然后期我们就替代了，烽火那个把它，是吧？它不是，往哪几边儿？或者说这个，咱们中兴的，我们把这个F V X，我确定怎么用的是八，用的是85，反正可能就40，是吧？我们把这个F V X，我用，把这个。
- [02:02:54 - 02:03:47] 说话人5: 然后还有就是，华为和中央对接的事，也都在这85m光杆儿块儿。那也是就是对不起来的。就是让华为的这个，他两家把一个微信功能打开之后吧，在这华为呢有一个叫什么，哎什么杆儿块儿，一个正序一个反序。然后咱说一个中央是正序，华为是反序。然后呢，也是华为在底层，给他改了一下这个步配序。就是现在就是这个测试，就就是在这85m光杆儿的街道。是是有一些连接。那这也是找的是什么？找什么国家？然后把这些东西，然后看，同一个那个界面，然后打开什么，我可以跟着你自己家自己对接的时候吧。你都可以，但是比如说你用微信什么对接的时候，你光晚上我有一个功能，你知道，我这个啥？微信，是不是开启，是不是关闭，对吧？然后我这个正序反序，是不是把这个。
- [02:03:49 - 02:04:38] 说话人5: 就是重要的一个测试点，这么一个，因为这个时间，这个也是在，沈阳是华为的，那大连是是，大连是宁都区的，然后这个是锦州是凤凰的，然后天津是华为的，然后天津是东兴的，然后北京是凤凰的，就是每一个场景我们念着我们，就是绝对就是在，不管是你这上游，不管是你上游全段走，只能是不扔的，然后手机用，那是不断的，而且在路面也有点点点，也是的，像就是我手机断的时候，故障维修吧，就是你看我们上游，几乎故障维修是不完善的，再说我们本地是放什么的，咱不说故障维修，我我告诉你，今天车尾，我讲讲。
- [02:04:39 - 02:04:49] 说话人5: 这个他们说的，我说对了，我的，会帮我就。
- [02:05:00 - 02:05:51] 说话人3: 各位领导同志大家好，我是黑龙江俄罗斯的王月凡。下面我就今年我们亚冬会保障的一些说我们的经验跟大家做个分享。亚冬会保障是2月17日到14号在黑龙江哈尔滨举行。有34个国家和地区和1200名运动员报名参赛。也是说参赛的国家是亚冬会历史之最。比赛项目主要是六个大项，11分项和64个小项。共有13个场馆。其中哈尔滨有五个场馆承办的是冰上赛，冰上比赛。亚冰赛区有八个场地承办的是雪上项目比赛。我们规划的规划了169个重点保障场景。是共涉及2633个基站。的信号拓扑，高景，性能的一些呈现。
- [02:05:51 - 02:06:41] 说话人3: 广场景还包括含开冰制和比赛场馆，两站一场就是飞机场和火车站，冰雪旅游相关像冰雪大世界，重点的景区，重要的道路包括像火炬传递的这个道路。这次呢我们面对主要是以下有五个问题，第一个问题的是保障的场景比较多，车站、道路、比赛场馆一共是21个场景，保证的这个点有100多处，第二个是基站和传输链路无法自动关联，无线基站这个跨专业是目前是我们在做这个之前的是属于割裂开，无线和传输分别看各自的报警和定位，这个资源方面没有进行关联，影响了这个报警定位的。
- [02:06:41 - 02:07:41] 说话人3: 准确性，第二个是，原始的告警拍的量比较大，不易分辨出故障的根因，影响故障定位的和处理。第四个是告警和链路匹配的比较困难，由于这个传输和，传输这个设备比较设备的种类，比较多，然后和综资的链路采集呢有一定的滞后性，导致的这个告警与链路的主因关联性存在一些匹配的困难。再一个就是跨专业的告警匹配，无线网和传输网之间的各种信息没有，集成，就是无法判断是无线出故障的还是传输故障影响。那么基于下面五个问题呢，我们，先下面给大家介绍一下这个我们针对于这五个问题的一些重点的保障方案。整体呢是以传输工作台为核心，构建呢以拓扑自呈现和故障自定位为目标的这个管理模式，实现对关键节点的实时监控和故障预警。
- [02:07:41 - 02:08:33] 说话人3: 范围呢主要是，比赛场馆和相关的景区和重要道路。搭建的体系主要分为下面五个方面，一个就是基站与传输链的关联。我们通过，基站的信息和北向MPC的信息，实现了网元端口以及整体链路的，这个主备路径的自动关联。这是全面基于北向MPC数据的，把公司抛开了。同时也是同时也实现了二层与三层的这个关联映射。第二个是基站监控与管理，是我们拉管了2693个基站，进行全面的监控和管理。对接故障中心，把无线和传输到底都拿过来，将二者与上面的这个链路进行了融合，直观的呈现这个，各个那个各两个专业之间的告警。
- [02:08:34 - 02:09:23] 说话人3: 同时我们还制定了这个132个重要保障这个场景，进行了保障场景的分组，针对于不同场景不同基站，都能呈现这个多端的拓扑告警和性能的这个监控。第四个我们建立了故障等级的划分，按照红橙黄蓝四影响的严重程度和影响范围，我们将基站故障划分成了四级，这样的话有便于我们更快的找到所关注的传输原因导致的这个故障。最后一个第五点是智能化监控与预警，通过这个传输控制台呢实现了对通信网络多端拓扑性能告警的智能化监控，可实时监控这个网络的状态，有问题呢及时通知。
- [02:09:24 - 02:10:19] 说话人3: 那个历史公司进行处理。这个是我们的整体的这个工作架构，涉及了这么几个系统，主要是无线公台资源中心，就是总资，还有故障中心，从还有厂家的O M C表数据，将这四个数据呢，包括传输链路中进行捏合，实现了我上面所说的这些步骤。下面一给大家一一介绍一下。第一个是基站与传输链路的关联。我们通过基无线公台给过来的基站的IP微辣，还有基站的名称，去匹配北向数据中的信息。通过IP微辣，将无线的基站的信息与传输链路的信息进行匹配，同时，关联了四G五G的整个P T S P的链路。然后在公台中呢，我们通过北向的数据，按照集团之前下发的电视春节的这个。
- [02:10:19 - 02:11:10] 说话人3: 规则，把它的传输链路进行呈现，这样的话就实现了传输到无线的端到端呈现。同时，在对于PTN链路我们也实现了二层三层的自动关联。第二个是告警监控。这个去年其实分享过，就是我们是基于这个告警的压缩规压缩收敛的规则，进，来做这个这次压缩的保障的。主主要是什么？主要是通过传输端环内线外线资源机房资源，还有这个业务的关系模型。我们将故障传输的故障分为了以下几大类，八大类会13个小类。主要是主要体现为动网故障、电源故障、温度热线故障、硬件故障、单线中断、光缆中断和托管故障、网元异常这个故障。将这个我们之前做的。
- [02:11:10 - 02:12:08] 说话人3: 故障收敛的规则呢，对应到这次的保障中，通过基站的告警关联链路，在关联我们传输故障，涉及到这些收敛的告警，把这个端到端的这个告警和关联上。下一个是我们建立了不同的，众保组可以根据我们不同的区域、景区和业务需求进行详细的划分，比如说我像图里说的我们要做进行一个场景建设，我们先建设一个哈尔滨火车站这么一个场景，将火车站所关联的基站全部导入这个，全部关联到这个场景里，以此设置多个这个众保组，最后众保组里面的信息去关联所有的基站，进行一个分组化的管理。下一个是我们进行，红色关轮的分级管控，由于保障的场景和硬件非常多，我们无法直观的体现看到我们需要及时处理的。
- [02:12:08 - 02:13:02] 说话人3: 这些故障是哪些基站的，或者是哪些场景的？比如说像在开幕式期间，我们可能重点关注开幕式场馆，在非开幕式期间呢，我们可能重点关注一些基站，或者那个飞场和火车站，还有一些别的场馆。那么我们就是需要进行一个道路划分。我们是这样划分的：像红色呢属于有重大风险的，它是什么样的呢？是基站关联的传输链路上双链路有传输报警，基站侧有报警，这个我们定为红色是最紧急处理的。第二个是橙色的，橙色说明有较大风险，基站关联的传输链路上有单链的报警，基站侧也有报警，这个我们选为橙色。黄色是基站关联的链路上单链有传输报警，基站侧没有报警，这个是选为黄色。最后是最低风险，只有基站侧报警，传输是没有。
- [02:13:04 - 02:13:53] 说话人3: 就不需要处理。下面我们还结合了之前在集团的资源网络里做的同流分析，我们将同流分析的这个功能集成到了这个我们这次保障中，实现了主保基站关联传输链路的主备路由同流筛查，并可以跟踪处理基站逻辑同流，提升这个稳定性。主要是在逻辑上分为主备链路设备板卡端口的同流。大家可以看这张图，我们可以看到它可以直观的体现这个基站里我是有哪些设备同流，有哪些同板卡，因为它有哪些同端口，它有包括它是在主用和备用的这个同流上。还有这个。
- [02:13:53 - 02:14:47] 说话人3: 关注一下这个误码差距，因为在保证期间呢，我们发现，这个误报的这个告警产生的频率其实是非常高的，我们就将巡检中的这个端口误码信息和基站的信息进行关联，因为我们知道了所有的这个基站所经过的所有的端口，那么对端口的误码的巡检情况进行一个呈现，那么就可以查到当前这个基站所经过的这些链路的这个端口主备路径是否有这个误码的存在，这样也便于我们快速的处理这个故障。下面呢是几个案例，我们当像大家可以看那个例一，左边这个呢，我们其实就是发现了，两个红色的可以看到，这两个红色是上了一天是老端口报警，然后中间这蓝色上了一个网元托管报警，这里这块。
- [02:14:47 - 02:15:45] 说话人3: 我们把这个主要的这个告警呈现在这儿，这条是我们衍生的告警，就说明其实是由于这个，托管导致的这个两根的故障。那我们去这个水上乐园这个点去看一下，后续我们发现这个其实是由于停电原因导致的这个故障。还有这个，像这个我们是只有基站侧有告警，我们可以看到，这边呈现的全都是基站侧的告警，这是一个四级的基站。那么这个在这边呈现的也是蓝色，那我们这个可能我们就只需要关注就行，不需要暂时不做处理。还有我们对于这个在网络保障期间业务有不合理也进行了这个整改。大家可以看到左边这个是冰雪大世界景区的这么一个四级基站，四级站可以发现它的主干路径基本全程都坐在了一条路径上，那这个风险其实是很大的。那我们发现了这个之后呢，就通知地市公司去调整这个。
- [02:15:46 - 02:16:37] 说话人3: 发现它其实是有路由的，是配置的问题。然后它通过这个路由的调整，将主边连主备链路其实就是分开了，然后就完成了这么一个同路由的整改。这个其这个保最后我们说一下这个保证成效。保证成效其实我们也是基于去年的这个故障压缩故障收敛故障排单这么一个经验吧。然后把这个进行了整合，实现了这个保障场景。我们在分组的跨专业关联故障工单收敛，分区管控和关键的关键故障呈现这个方面，获得了一定的经验。保障了亚运会期间呢没有因为传输故障导致的这个基站的中断。基于这个经验，我们其实今年也在。
- [02:16:38 - 02:17:28] 说话人3: 其他场景的这个保障，包括基站大面积，base，大站的保障，还有，大概是一个四M带的IP城联网，一些重要电路的保障，还有一些重要集客的专线。把这些场景其实我们都在今年都已经开始做了，今年底应该可以把一些东西大部分都实现。我们现在项目部设置了132个重要保障场景，完成了2693个基站与传输链路的穿透。完成这些基站的同路排查工作，共一共发现同路问题31个，全部都完成整改。在保障期间呢，一共发生了80起传输单边故障，直属人员第一时间发现并处理，平均故障处理时长均在一小时以内。这就是我的分享，谢谢。
- [02:17:40 - 02:18:33] 说话人8: 领导各位同事，上午好，我是来自天津的刘立新，今天呢我给大家这个汇报的这个题目呢，是这个单芯双线光模块，然后这个天津的这个光缆租赁成本，困境的一个解决。先说一下咱这个我们这个课题的这个背景，因为这个早晨我们这个第一节课然后我这边，咱们今天讲一些就是稍微简单一点的东西，然后我这个非常简单大伙儿可能一听就明白了，然后呢但是呢这个对天津来说呢可能帮助还是很大的，因为呢就是咱们首先说一下这个两个背景，第一个背景呢是天津这边的这个因为地理位置的一个比较特殊，然后既为这个首都门户又是非常口岸，目前呢各个区域的就是这种重建的开发区，还有高新区这种。
- [02:18:34 - 02:19:26] 说话人8: 就是这种东西比较多，然后这些呢区域呢现在都是自主管理，在针对运营商这个基础设施建设上管理非常的严格，就是许多地方呢都是这个统筹管理甚至是自己这个建设自己经营，然后不许运营商架设这个基础设施，所以呢就是我们如果要是想做覆盖或者是开业务，就是清呢就是需要交这管理费，然后呢许多地儿呢就都是需要租赁或者购置这个资产，然后第二个困境呢是这个虽然呢现在基因为经过这么多年的这个包括管局的协调，包括各个运营商基就是集中一体的跟这个是就是这个商户呢去这个沟通，现在这个大部分这个重点区域的这。
- [02:19:27 - 02:20:18] 说话人8: 租赁的这个价格，基本上是已经固定的。但是呢，现在先新租赁呢，有时候面临一个这样一个问题，因为呢，先新租赁这个资源都掌握在业主手里。通常呢，业主是不公开这个工那个，就是这个具体路由的。然后运营商想租光纤呢，它就是都是业主帮忙给挑好的。然后这个具体距离呢，就是一个测试，用ODF打一下，看看具体距离是多少。其实就是业主想怎么挑他就怎么挑。然后这个距离呢，是我们那个运营商那边没法掌控的。所以呢，然后这个就是无可奈何被人宰割。第三个呢，是运营商的话语权不足。就是三家运营商呢多次就是联合起来向有关部门反映这类的问题，然后相关部门。
- [02:20:19 - 02:21:12] 说话人8: 面进行一些个就是统筹和这个调节，但是呢这个收效甚微。然后因为这统计区域呢，通常呢这个就是都是财政自主，他们对这盈利的这方面呢还是关注的很严格的。所以呢造成了现在的这个情况就是收入现金量从逐年的递增，然后租赁的成本呢，使这个分这个公司呢也是不堪重负了。然后大家可以看这个数据，基本上是每年都是以这个10~5%的这个比例，然后再提升的。然后面临着这个问题呢，这个还有一个隐形的一个第二个背景，就是天津本地呢，我们这边一般都不太使用这个单行双向的模块。通常这环路呢都是双人双向的，因为就是。
- [02:21:12 - 02:22:01] 说话人8: 一般的情况下就没有这个谐音这个量不足的这个忧虑，所以呢，这个通常这么多年呢都是习惯性的也就忽略了这个产品。然后呢，就是在我们这个经过多年经过很长时间的调研呢，突然想到了就是在租赁的这个场景，如果使用这个单芯双向光模块进行改造，会不会有一些意外的效果。然后这个时那个，就是由这个想法呢就确定了这个方案。先说一下这单芯双向光模块，因为这个东西就是咱们许多省市已经都用的，然后确实没什么可说的。然后简单的原理就是这个也是这波分复用的原理，然后包括这复协调的技术，近端串扰的一些抑制，然后包括呢它一个。
- [02:22:02 - 02:22:49] 说话人8: 双波长复用的这个路径，包括这个低成本方案，波长自适应校准，对称的这个传输架构，还有它这个现在产业链的一个矩阵的一个，整体的一个规模化和成熟化。所以现这个这些东西呢，所以呢，对我们来说这些东西其实它并不重要，因为它对整个方案其实没有什么效果。并不是我们并不是追求它这些个特殊的这些个，就是这个产品特性，我们追求的是什么？追求的是这个原来两芯的组联，通过使用这个单双线光模块，我直接可以对半砍。这个是，对我们最大的这个优势吧。然后再说一下这个方案的这个核心优势。
- [02:22:50 - 02:23:50] 说话人8: 一个说明，首先呢是改造便捷，无需更改跳纤，只需在A端的两端机房进行改造，不会惊动业主，也不会造成不必要的纠纷，因为呢这个业主对这个限行量的这个租赁，他是非常敏感的，如果我们贸然的比如说动它的光交箱，动它的那个承端，这些个对业主来说呢，他是非常敏感的，都会那个就是对这个运营商呢进行这个阻拦，但是呢我们这个改造呢通常只是呢，就是我只在两端，轻轻的就把这个一个限行我就拔了，就是这么简单的一个改造，对业主来说呢他感知不够，所以呢这就有第二个优势，就是这个优化比较隐蔽，然后因为这个业主呢，更改跳纤，有效的避免这个业主恶意的加强跳纤路由，然后变相的提高租金。
- [02:23:51 - 02:24:45] 说话人8: 而且呢，改造完成之后，在利用空间建设是保留记录，以证据，借此在谈判过程中处于优势地位。第三个呢，就是效果显著，就是直接可以压降至原有租赁量的一半，起效非常快。这个我跟大家解释一下，就是如果要是我们在就是大张旗鼓的去做这个先行改造，因为前期我们有过这一类的方案的一个探索，包括就是把整个这个租赁区域，划划成一个网格，然后进行这个综合右区的改造，或者是进行这个机房的这个调整位置，这些呢，业主这方面的，一个是拒不配合，这个是首先最大的困难，第二个是即使配合了，之后期的这个光纤跳纤的时候，还是有业主掌握这话语权，他呢就会就是比如说就是说提出了什么。
- [02:24:45 - 02:24:47] 说话人3: 因为我某个人光感坏了。
- [02:24:47 - 02:24:48] 说话人8: 我现在需要重新规划。
- [02:24:48 - 02:24:51] 说话人2: 我的臭老大哥会议。
- [02:24:51 - 02:24:55] 说话人8: 这歌我是不用了，这歌光拿你不能用了，我给你。
- [02:24:55 - 02:24:56] 说话人2: 唱好一点。
- [02:24:56 - 02:24:59] 说话人8: 然后呢，再结果出来之后呢。
- [02:24:59 - 02:25:03] 说话人2: 每次都是，我就把上一次的来改的呀。
- [02:25:03 - 02:25:05] 说话人8: 最后，整个合同的这个价格。
- [02:25:05 - 02:25:06] 说话人2: ก็ประมาณว่ามันคืออะไรไง
- [02:25:06 - 02:25:08] 说话人6: 那一篇还没有消息。
- [02:25:08 - 02:25:11] 说话人2: 下期又来了，想个点子又来了。
- [02:25:11 - 02:25:19] 说话人8: 全部的都浪费了，还有几条。所以呢，一种就是这种，写有点亏，我感觉。油霸非常隐蔽，而且不会惊动业主的这种方案。
- [02:25:20 - 02:25:22] 说话人6: 我还以为你又想了个新的点。
- [02:25:22 - 02:25:33] 说话人2: 我想得到，他之前那个，可能我把去年的每个段位拿来写，但是那个确实太差了写不出来，就把这个全一票的改了。
- [02:25:33 - 02:25:54] 说话人8: 给大家介绍一个本地的一个投资更改的一个案例，这个呢是天津这个滨海地区的生态城的视角。整个生态城区域呢现在都是统筹的由业主方开发商统一建设的基础工业的光缆。然后呢这从24年呢陆续我方以这个设备检修。
- [02:25:55 - 02:25:56] 说话人3: 情感实时改造。
- [02:25:56 - 02:26:49] 说话人8: 全部完成后呢，进入其他合作，开始跟业主谈判，然后签订定价协议，后开始最终完成了这个合同的改签压降成本。第二部分呢是，也采用了一些包括分布式OLT的部署，在以当今双向光模块改造的手段以外，如这个加个场景，我方希望业主将光纤这个线路终端OLT下旋置社区计划，减少主干光纤的长度，并且承担了就是机房的这个包括电费之类的，相对于一些其他的一些交换，相那个总的来说呢实现了这个成本压降。然后为了保证后期稳定，加强那个智能网管中心的集成，然后通过FBN那个控制器实施那个光模块的功率、码率的这个监控，动态调整发射功率。
- [02:26:51 - 02:27:44] 说话人8: 距离的一个需求，提升网络稳定性，完成这个设备。最终的成果呢是生态城整体区域的，总量呢，在2024年、2025年的那个开端吧，实现了313新那个新公里的压降比例为41.7%，全年的压降成本节约了16.340000元。这个是我们对这个方案的一个量化的一个对比吧。单晶双向光模块这个需要单独立项采购，替换产品用于，替换这个产品可以立那个立项的这个工程的立究，因为这个都是其实都是好的光模块，它就是双向的。我们就会拿出来放到别处，对比那个单价呢，以50GE的光模块为例呢，单晶双向光模块与。
- [02:27:45 - 02:28:30] 说话人8: 传统光模块单价约高200元，截止2025年合计增加成本不到400000元。然后加上2025年二季度合计替换单晶双向光模块321对，代维人员按照网格票前费用，然后进行那个付费，合计花费了7.20000元。截止2025年改造量面度，可节约成本3200000元。2025年有望实现租赁量与这个租赁成本的这个双压降势。随着这个项目推进的节奏，每况愈下。就是现在这就是这个生态城这边大约是150元，新公里每月。然后这个313公里呢，因为是就是在这一年中，随着时间。
- [02:28:31 - 02:29:26] 说话人8: 越来越多的这种不是一次性就改造了压降300，130公里，然后最后我们测算统一这个包括，对，300，300，就是从第一年比如说从一月份开始，10节，然后慢加，最后统1+1块，大约是就是压降的。然后这个全年成本呢，所以就是，它并不是说就是150乘以313再乘12怎么算出来的，它就是这个合同随着改造，因为还有合同谈判，还有合同签订这个时间就是通过这个延续吧，加一块算，就是130，三大约是这么有钱，然后到2015年，这个313就是整天计算，这个数会更大一些。行，然后那个就是这个案例呢，我们感觉跟我们这个想法可能有异曲同工。
- [02:29:26 - 02:29:49] 说话人8: 知道，但就是咱们比较熟悉的有一个是牙膏厂商的那个扩大牙膏那个口径的这个案例。因为呢，所以呢，就是我们天津这边呢有一个这个观点的一个输出吧。然后就是我们觉得这个创新呢，以解决问题为导向，不要盲目追求高大上，有时解决办法就在身边，却不被看到。好，谢谢大家。
- [02:30:00 - 02:30:22] 说话人9: 尊敬的集团公司领导，各位专家，是重庆公司全业务支撑中心陈友红。下面将向大家汇报重庆公司在传输利用率方面开展的工作。对于传输网络利用率提升，主要有两个方面，我的理解主要。
- [02:30:23 - 02:30:25] 说话人3: 一个是网络资源，不要。
- [02:30:25 - 02:31:20] 说话人9: 这样会造成既费钱买又费电。另一方面是网络资源的高效利用，例如业务量小又没有高带宽、高价值业务的地方，那就没有必要使用插机胖胖。这就是我们常说的“杀鸡焉用宰牛刀”。重庆公司在网络运维中就遇到了这样的情况，下面将从背景、采取措施和下一步计划三方面进行描述。为支撑千兆FTTR业务的规模发展，重庆公司已实现了千兆平台的全覆盖。随着插机胖的大量投放，现网存在着资源利用率低、使用效益低的问题。这样的问题主要体现在：虽然千兆业务的规模发展，但是单实际胖口，像下网的插千兆用户数很中。二是在业务批量迁移之后，空闲胖口占比高，还有0带宽率。
- [02:31:20 - 02:32:17] 说话人9: 端口占比高，那么究其原因呢主要有四个方面，一个是叉机胖端口的低效使用，叉机胖端口空闲多，然后业务迁移之后机胖板空闲，还有高价值高贷款业务迁走后留下了大量的无贷款并轨胖口。总结起来就是资源闲置低效使用，那相应的政策呢也就呼之欲出了，重庆公司通过低效端口置换，叉机胖板的整合腾退，空闲机胖板的腾退，无贷款利用率胖口的清理，充分利用现有的机胖板资源，杜绝叉机胖板的资源浪费，减少了叉机胖板的投放，取得了显著的效果。首先呢是低效端口置换，通过低价值区域，且叉机胖板的有效使用场景，胖口协同开展端口业务置换提升资源利用效率，主要通过三个步骤进行实施。
- [02:32:17 - 02:32:19] 说话人5: 一个是红点型。
- [02:32:19 - 02:32:22] 说话人2: 这朋友，我把他抛弃了。
- [02:32:22 - 02:33:21] 说话人9: 用户数作为衡量叉接泵网口是否有效率的判断条件，结合单端口承载千兆用户数，作为辅助坐标，为各分公司叉接泵网部署和业务发展进行了画像。对于我们就是现在就对于那种处于第三象限的那种部署又不精准、效益又差的分公司，就会要求他们开展低效端口置换。所谓的低效端口置换呢，是将低效使用的叉接泵端口与达到迁移标准的机泵口进行业务置换，充分利用现网机泵网络资源来承载轻量级业务。为了保障此项工作顺利进行，群资中心和计划部各司其职。群资中心梳理清单，跟踪置换情况，计划部则对未切实执行置换的分公司停止后续叉接泵网资源的审批。通过双方密切合作，确保分公司各接需求时。
- [02:33:21 - 02:33:41] 说话人9: 各街需求是优先使用低效装头板承载业务。为支撑分公司高效的割接，重庆公司开发了跨厂家的磅口割接工具。该工具有三个特点：一个是跨厂家的快速割接磅口，快速割接。第二个是同可以同时割接多个。
- [02:33:42 - 02:33:46] 说话人3: 还有能够记录各界的完成情况。
- [02:33:47 - 02:34:17] 说话人9: 各项失败端口的复退。第三个是资源数据的自动修改，它可以修改那个各接完后可以修改那个光路的信息，自动的进行修改。措施二是插接泵板的整合复退，可以机房维度统计分析，对整个机房内的插接泵板端口资源进行统一的那个筹划，将未用完的插接泵口整合到一块板上。邮分公司将库检出来的。
- [02:34:17 - 02:34:23] 说话人3: 回收，比如省公司计划部统一调配的用户，后续业务的发展。
- [02:34:23 - 02:35:11] 说话人9: 截至目前呢，我们腾退了670户，也节约了大量的投资。通过差低效端口的置换和差机旁网的整合腾退，网络资源使用效率得到了提升。单胖单差机旁网接入千兆用户数，提升至7.7户，可能也不是很高，但是对诚信公司来讲的话，已经是一个很大的提升了。还有是实际胖网有空闲频率也显著下降。节约投资的话是节去了30%，就是我们这个是计划部这边，做到了节约投资节用了30%。从13~9是没有空闲机旁网的回收，资管系统建立了支撑手段，常态化的去监控现网空闲胖网。

25
prompt/en/base.yaml 100644
View File

@ -0,0 +1,25 @@
system: |
You are a practical work assistant. When executing specific tasks, you must follow the workflow of “plan first, confirm, then execute.” Before execution, the agent must first explain to the user:
1. The task objective;
2. The intended scope of access or processing;
3. The key steps expected to be performed;
4. Possible risks, costs, or side effects;
5. The execution boundaries that require the user’s explicit confirmation.
Your responsibility is to understand the goal, use tools when needed, decompose work into tasks when helpful, load relevant skills before acting in unfamiliar domains, and assist the user in completing the work.
Rules:
- Script files generated during the task must be cleaned up after the task is completed.
- If the task scope is unclear, the agent must first ask the user to confirm the scope instead of expanding it on its own. If it is unable to determine whether an operation is safe, it should default to pausing and requesting confirmation.
- After the user confirms, the agent may only execute within the confirmed scope. If, during execution, it becomes necessary to expand the scope, increase the number of requests, access new sources, or change the strategy, the agent must request confirmation from the user again.
- If a problem cannot be solved after multiple attempts, the agent may continue a deeper discussion with the user.
- Use `list_skills` and `load_skill` when a reusable workflow would help.
- Use `dispatch_task` when the request contains multiple interdependent steps.
- Prefer reading the workspace before writing.
- For operating system, hardware, environment, process, dependency, and runtime inspections, use `execute_shell`.
- If no existing tool directly solves the task, use `run_python` to write and run a small helper script instead of giving up.
- `read_file` is only for reading files inside the workspace.
- Keep tool arguments precise and concise.
- If enough information is available, take action directly instead of asking questions.
- If the requirements, environment state, or expected behavior are materially unclear, ask the user before making risky assumptions.
- If the Python virtual environment, interpreter, or required dependencies appear to be missing or unclear, ask the user how they would like to proceed instead of deciding the setup yourself.

85
prompt/zh/base.yaml 100644
View File

@ -0,0 +1,85 @@
system:
chunk_prompt: |
你是项目会议转录信息提取专家。你的任务不是总结，而是从当前会议原文分块中“高召回、保真地提取可用于最终项目纪要的原始有效信息”。
核心原则：宁可多保留，不要漏掉有效信息；宁可保留原文细节，不要过度概括。
提取范围：
1. 只处理当前分块中的内容，不参考其他分块，不补充外部背景。
2. 以“项目”为信息归属单位。识别原文明确提到的项目名称、项目别名、产品/系统/客户交付物；对每条有效信息尽量标记其项目归属。未明确归属时标记“项目归属待确认”，不要自行猜测。
3. 凡是可能影响项目推进或最终项目纪要的信息都应保留，包括但不限于：项目背景、业务目标、范围与边界、交付物、当前阶段、已完成进展、里程碑、计划、方案、原因、依据、问题、风险、困难、依赖、资源、预算、争议、决策倾向、已形成结论、行动项、责任人、协同方、时间要求、关键数字、比例、金额、日期、系统名称、设备型号、部门名称、地名、专有名词、案例、对比关系、前后因果关系、待确认事项。
4. 对同一事项的不同表述、补充说明、限定条件、例子、数字和口径差异，只要包含新增信息，都要保留，不要因为看起来重复就删除。
5. 对发言人的观点、判断、担忧、建议、要求、承诺、计划和未解决问题，应尽量保留原始语义和上下文关系。
表达要求：
1. 按原文出现顺序提取，不重新设计最终报告结构，不跨段大幅重组；每条可用“项目：…｜类别：…”作为前缀，类别优先使用背景/目标/范围/进展/里程碑/决策/行动项/风险与依赖/待确认。
2. 可以清理寒暄、语气词、明显重复口水话和无信息转场；但一句话中只要包含有效事实，就必须保留有效事实部分。
3. 不要为了简洁而压缩掉数字、限定条件、原因、例子、对象范围、前提条件和不确定表述。
4. 不要把多个具体事实合并成一句笼统概括；如果原文有多个具体点，应分条保留。
5. 不要写正式会议纪要，不要输出会议概览、决策事项、AI 建议、总结评价等最终成稿内容。
6. 不要替发言人补全未明确表达的结论，不要推断责任人、时间、状态或因果关系。
7. 对听不清、疑似 ASR 错误、冲突或未确认内容，应保留原文可辨识信息，并标记“待确认”。
输出要求：
1. 输出 Markdown 中间材料，使用短标题和项目符号。
2. 每条尽量包含完整上下文，避免只写关键词。
3. 如果本分块信息很多，可以输出较长内容；不要主动压缩成简短摘要。
combine_prompt: |
你是项目管理会议总结专家。你的任务是将会议主要内容按照模板规则整理成面向项目推进的标准文档，帮助读者快速判断每个项目的目标、进展、决策、下一步和风险。
整理规则：
1. 仅使用原文或用户提供材料中的事实，不编造、不推导、不补全未经确认的信息。
2. 数字、比例、金额、日期、时间节点、责任人、部门名称和专有名词必须原样保留。
3. 可清理明显无意义的口水话、重复表达和语气词；可修正明显 ASR 错误，但不得修改关键事实。
4. 原文存在不确定、冲突、听不清或待确认表述时，如实保留并标记为待确认。
5. 先识别会议涉及的项目，再按项目组织内容：同一项目的背景、目标、范围、进展、决策、行动项、风险和依赖必须聚合在同一项目小节，不能按发言顺序打散。
6. 若涉及多个项目，为每个有明确事实的项目建立独立小节；无法归属到某个项目但影响整体推进的内容，归入“跨项目事项”。不要因为模板而虚构项目或填充空小节。
7. 每个项目优先突出可执行信息：当前状态或阶段、已完成与未完成事项、明确决策、下一步行动、责任人、截止时间、阻塞项及外部依赖。原文没有的信息标记“待确认”，不要补写。
8. 不输出推理过程、内部规则、无关解释或与任务无关的内容。
prompts:
chunk_user: |
这是分块阶段，目标是“保真提取中间材料”，不是生成会议纪要，也不是做最终总结。
<transcript_chunk>
{chunk}
</transcript_chunk>
combine_user: |
这是最终合并阶段。以下内容是同一会议按时间顺序提取的主要内容，和最终输出模板。请将时间顺序的材料重新聚合为项目视图，而不是按发言或时间线逐条罗列。
模板：
<template>
{template_markdown}
</template>
主要内容：
<summaries>
{summaries}
</summaries>
templates:
final_output: |
# 项目会议纪要
## 1. 会议概览
- 简要说明会议目的、涉及项目和整体背景。
## 2. 项目进展与推进事项
- 按项目名称建立三级标题；若项目名称未明确，使用“项目归属待确认”，不要自行命名。
- 每个项目按需记录：目标与范围、当前阶段/已完成进展、里程碑与计划、关键讨论与方案、已确认决策。
- 不要为了套模板重复信息；原文未涉及的字段可省略。
## 3. 行动项
- 按项目列出后续任务，格式为“任务｜责任人｜协同方｜截止时间｜状态/依赖”。
- 原文未明确责任人、时间、状态或依赖时，如实标记待确认。
## 4. 跨项目事项
- 记录影响多个项目或无法明确归属项目的资源协调、共性决策、共享依赖和整体计划；没有则省略本节。
## 5. 风险、阻塞与待确认事项
- 按项目归类记录问题、风险、阻塞点、冲突信息和待确认事项，并说明影响、所需决策或依赖（仅限原文明确内容）。
## 6. 关键信息
- 汇总重要时间节点、数字、系统/设备、部门、项目名称及其他关键专有名词；避免重复前文已清晰列出的内容。

3
prompt_loader.py 100644
View File

@ -0,0 +1,3 @@
from meeting_summary_lab.prompt_loader import PROMPT_ROOT, load_prompt
__all__ = ["PROMPT_ROOT", "load_prompt"]

16
pyproject.toml 100644
View File

@ -0,0 +1,16 @@
[build-system]
requires = ["setuptools>=68"]
build-backend = "setuptools.build_meta"
[project]
name = "meeting-summary-lab"
version = "0.1.0"
description = "Standalone long-meeting summarization pipeline extracted from Meetily"
requires-python = ">=3.10"
dependencies = ["PyYAML>=6.0"]
[project.scripts]
meeting-summary-lab = "meeting_summary_lab.cli:main"
[tool.setuptools.packages.find]
where = ["src"]

5
src/meeting_summary_lab/__init__.py 100644
View File

@ -0,0 +1,5 @@
"""Standalone, testable long-meeting summarization pipeline."""
from .pipeline import SummarizationPipeline, chunk_text, rough_token_count
__all__ = ["SummarizationPipeline", "chunk_text", "rough_token_count"]

3
src/meeting_summary_lab/__main__.py 100644
View File

@ -0,0 +1,3 @@
from .cli import main
main()

135
src/meeting_summary_lab/cli.py 100644
View File

@ -0,0 +1,135 @@
from __future__ import annotations
import argparse
import os
import sys
from pathlib import Path
from .llm import FakeLLM, OpenAICompatibleLLM
from .pipeline import SummarizationPipeline, chunk_text, rough_token_count
def load_local_env(path: Path = Path(".env")) -> None:
"""加载本地 key=value 配置，且不覆盖外部已注入的环境变量。"""
if not path.is_file():
return
for line in path.read_text(encoding="utf-8-sig").splitlines():
line = line.strip()
if not line or line.startswith("#") or "=" not in line:
continue
key, value = line.split("=", 1)
key = key.strip()
if not os.environ.get(key):
os.environ[key] = value.strip()
def build_parser() -> argparse.ArgumentParser:
"""构建命令行：chunk 仅检查切分，summarize 执行完整流水线。"""
parser = argparse.ArgumentParser(description="Standalone long-meeting summary pipeline")
subparsers = parser.add_subparsers(dest="command", required=True)
chunk = subparsers.add_parser("chunk", help="Inspect context-window chunks without any LLM call")
chunk.add_argument("--input", type=Path, required=True)
chunk.add_argument(
"--context-tokens",
type=int,
default=int(os.environ.get("MEETING_SUMMARY_CONTEXT_TOKENS", "4000")),
)
chunk.add_argument("--overlap-tokens", type=int, default=100)
summarize = subparsers.add_parser("summarize", help="Run the full map-reduce-template pipeline")
summarize.add_argument("--input", type=Path, required=True)
summarize.add_argument("--output", type=Path)
summarize.add_argument(
"--context-tokens",
type=int,
default=int(os.environ.get("MEETING_SUMMARY_CONTEXT_TOKENS", "4000")),
)
summarize.add_argument(
"--endpoint",
default=os.environ.get("MEETING_SUMMARY_ENDPOINT", "http://localhost:11434/v1"),
)
summarize.add_argument(
"--model", default=os.environ.get("MEETING_SUMMARY_MODEL", "qwen3:4b")
)
summarize.add_argument(
"--api-key",
default=os.environ.get(
"MEETING_SUMMARY_API_KEY", os.environ.get("OPENAI_API_KEY", "")
),
)
summarize.add_argument(
"--max-tokens",
type=int,
default=1024,
help="Maximum completion tokens per LLM call (default: 1024)",
)
summarize.add_argument(
"--temperature",
type=float,
default=float(os.environ.get("MEETING_SUMMARY_TEMPERATURE", "1.0")),
help="Sampling temperature for each LLM call (default: 1.0)",
)
summarize.add_argument(
"--request-timeout",
type=int,
default=300,
help="Per-request timeout in seconds (default: 300)",
)
summarize.add_argument("--fake", action="store_true", help="Run offline with deterministic fake LLM")
return parser
def main() -> None:
load_local_env()
args = build_parser().parse_args()
transcript = args.input.read_text(encoding="utf-8")
if args.command == "chunk":
# 仅输出切分预览，方便在真实模型调用前检查窗口大小和重叠效果。
threshold = max(1, args.context_tokens - 300)
chunks = chunk_text(transcript, max(1, threshold - 300), args.overlap_tokens)
print(f"estimated_tokens={rough_token_count(transcript)} chunks={len(chunks)}")
for index, chunk in enumerate(chunks, start=1):
print(f"\n--- chunk {index}: estimated_tokens={rough_token_count(chunk)} ---\n{chunk}")
return
threshold = max(1, args.context_tokens - 300)
estimated_chunks = (
1
if rough_token_count(transcript) < threshold
else len(chunk_text(transcript, max(1, threshold - 300), 100))
)
print(
f"Plan: estimated_tokens={rough_token_count(transcript)}, "
f"context_tokens={args.context_tokens}, estimated_chunks={estimated_chunks}",
file=sys.stderr,
)
llm = (
FakeLLM()
if args.fake
else OpenAICompatibleLLM(
args.endpoint,
args.model,
args.api_key,
timeout_seconds=args.request_timeout,
max_tokens=args.max_tokens,
temperature=args.temperature,
)
)
result = SummarizationPipeline(
llm=llm,
context_tokens=args.context_tokens,
completion_reserve_tokens=args.max_tokens,
# 进度输出到 stderr，避免与最终 Markdown 正文混在同一输出流。
progress_callback=lambda message: print(message, file=sys.stderr, flush=True),
).summarize(transcript)
if args.output:
args.output.write_text(result.markdown, encoding="utf-8")
print(f"Wrote {args.output} ({result.chunk_count} chunk(s), multilevel={result.used_multilevel_strategy})")
else:
print(result.markdown)

115
src/meeting_summary_lab/llm.py 100644
View File

@ -0,0 +1,115 @@
"""Small LLM boundary: a real OpenAI-compatible client and an offline fake."""
from __future__ import annotations
import json
import urllib.error
import urllib.request
from dataclasses import dataclass, field
from typing import Callable, Protocol
class LLM(Protocol):
def complete(self, *, system_prompt: str, user_prompt: str) -> str: ...
@dataclass
class OpenAICompatibleLLM:
"""OpenAI Chat Completions 兼容接口的轻量客户端，支持普通和 SSE 流式响应。"""
endpoint: str
model: str
api_key: str = ""
timeout_seconds: int = 300
max_tokens: int | None = 1024
temperature: float = 1.0
on_token: Callable[[str], None] | None = None
on_reasoning: Callable[[str], None] | None = None
stream: bool = False
def complete(self, *, system_prompt: str, user_prompt: str) -> str:
"""发送单次补全请求，并统一转换网络、超时和协议异常。"""
url = f"{self.endpoint.rstrip('/')}/chat/completions"
payload: dict[str, object] = {
"model": self.model,
"messages": [
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_prompt},
],
}
if self.max_tokens is not None:
payload["max_tokens"] = self.max_tokens
payload["temperature"] = self.temperature
# 注册任一回调即自动启用流式请求，便于调用方边生成边展示内容。
if self.stream or self.on_token or self.on_reasoning:
payload["stream"] = True
request = urllib.request.Request(
url,
data=json.dumps(payload).encode("utf-8"),
method="POST",
headers={"Content-Type": "application/json", "Authorization": f"Bearer {self.api_key}"},
)
try:
with urllib.request.urlopen(request, timeout=self.timeout_seconds) as response:
if self.stream or self.on_token or self.on_reasoning:
return self._read_stream(response)
response_payload = json.load(response)
except TimeoutError as exc:
raise RuntimeError(f"LLM request timed out after {self.timeout_seconds}s: {url}") from exc
except urllib.error.HTTPError as exc:
raise RuntimeError(f"LLM HTTP {exc.code}: {exc.read().decode('utf-8', errors='replace')}") from exc
except urllib.error.URLError as exc:
raise RuntimeError(f"Cannot reach LLM endpoint {url}: {exc.reason}") from exc
try:
return response_payload["choices"][0]["message"]["content"].strip()
except (KeyError, IndexError, TypeError) as exc:
raise RuntimeError(f"Unexpected OpenAI-compatible response: {response_payload}") from exc
def _read_stream(self, response: object) -> str:
"""解析 OpenAI 兼容服务返回的 SSE data 行并拼接最终正文。"""
parts: list[str] = []
for raw_line in response: # type: ignore[union-attr]
line = raw_line.decode("utf-8").strip()
if not line.startswith("data:"):
continue
data = line[5:].strip()
if data == "[DONE]":
break
try:
delta = json.loads(data)["choices"][0].get("delta", {})
except (KeyError, IndexError, TypeError, json.JSONDecodeError) as exc:
raise RuntimeError(f"Unexpected streaming response chunk: {data}") from exc
reasoning = delta.get("reasoning_content") or delta.get("reasoning", "")
if reasoning and self.on_reasoning:
self.on_reasoning(reasoning)
token = delta.get("content", "")
if token:
# 同时保留完整返回值，并将增量交给上层的实时展示回调。
parts.append(token)
if self.on_token:
self.on_token(token)
return "".join(parts).strip()
@dataclass
class FakeLLM:
"""Offline LLM replacement for deterministic pipeline tests."""
calls: list[tuple[str, str]] = field(default_factory=list)
def complete(self, *, system_prompt: str, user_prompt: str) -> str:
self.calls.append((system_prompt, user_prompt))
if "<transcript_chunk>" in user_prompt:
body = user_prompt.split("<transcript_chunk>", 1)[1].split("</transcript_chunk>", 1)[0]
return f"[chunk summary] {body.strip()[:120]}"
if "<summaries>" in user_prompt:
body = user_prompt.split("<summaries>", 1)[1].split("</summaries>", 1)[0]
return f"[combined summary]\n{body.strip()}"
return "# 测试会议纪要\n\n## 会议摘要\n离线测试模型已完成模板化步骤。"

266
src/meeting_summary_lab/pipeline.py 100644
View File

@ -0,0 +1,266 @@
"""Long-transcript meeting summarization pipeline."""
from __future__ import annotations
import math
import shutil
from concurrent.futures import FIRST_COMPLETED, Future, ThreadPoolExecutor, wait
from dataclasses import dataclass
from functools import lru_cache
from pathlib import Path
from typing import Any, Callable, Iterable
if __package__:
from .prompt_loader import load_prompt
from .llm import LLM
else:
from prompt_loader import load_prompt
from llm import LLM
@lru_cache(maxsize=2)
def _prompt_config(language: str = "zh") -> dict[str, Any]:
"""加载并校验提示词配置；缓存中英文配置，避免每次模型调用重复读 YAML。"""
config = load_prompt("base", language)
system = config.get("system")
if isinstance(system, str):
if not system.strip():
raise ValueError("Prompt config value must be a non-empty string: system")
elif isinstance(system, dict):
for name in ("chunk_prompt", "combine_prompt"):
value = system.get(name)
if not isinstance(value, str) or not value.strip():
raise ValueError(f"Prompt config value must be a non-empty string: system.{name}")
else:
raise ValueError("Prompt config section must be a string or object: system")
for section in ("prompts", "templates"):
if not isinstance(config.get(section), dict):
raise ValueError(f"Prompt config section must be an object: {section}")
return config
def _system_prompt(name: str) -> str:
system = _prompt_config()["system"]
if isinstance(system, str):
return system
value = system.get(name)
if not isinstance(value, str) or not value.strip():
raise ValueError(f"Prompt config value must be a non-empty string: system.{name}")
return value
def _prompt_value(section: str, name: str) -> str:
value = _prompt_config()[section].get(name)
if not isinstance(value, str) or not value.strip():
raise ValueError(f"Prompt config value must be a non-empty string: {section}.{name}")
return value
def _render_prompt(name: str, **values: str) -> str:
return _prompt_value("prompts", name).format(**values)
CHUNK_SYSTEM_PROMPT = _system_prompt("chunk_prompt")
COMBINE_SYSTEM_PROMPT = _system_prompt("combine_prompt")
FINAL_OUTPUT_TEMPLATE = _prompt_value("templates", "final_output")
def build_chunk_prompt(chunk: str) -> str:
return _render_prompt("chunk_user", chunk=chunk)
def build_combine_prompt(summaries: Iterable[str], template_markdown: str) -> str:
return _render_prompt(
"combine_user",
summaries="\n---\n".join(summaries),
template_markdown=template_markdown,
)
def rough_token_count(text: str) -> int:
"""按中文约 1 字符/token、其他字符约 0.35 token 粗估上下文占用。
此估算只用于决定是否分块和计算窗口大小，不能替代模型官方 tokenizer。
"""
cjk_chars = sum(
1
for char in text
if "\u3400" <= char <= "\u4dbf"
or "\u4e00" <= char <= "\u9fff"
or "\uf900" <= char <= "\ufaff"
)
return math.ceil(cjk_chars + (len(text) - cjk_chars) * 0.35)
def chunk_text(text: str, chunk_size_tokens: int, overlap_tokens: int = 100) -> list[str]:
"""将长文本切成带重叠区的上下文窗口，优先在句末或空白处断开。
重叠区让跨分块的上下文能同时出现在相邻请求中，降低行动项、时间等
信息恰好被切断而遗漏的概率。
"""
if not text or chunk_size_tokens <= 0:
return []
estimated_tokens = rough_token_count(text)
chars_per_token = len(text) / max(estimated_tokens, 1)
chunk_size_chars = math.ceil(chunk_size_tokens * chars_per_token)
overlap_chars = math.ceil(overlap_tokens * chars_per_token)
if len(text) <= chunk_size_chars:
return [text]
chunks: list[str] = []
start = 0
delimiters = ((". ", 2), ("。", 1), ("！", 1), ("？", 1))
while start < len(text):
target_end = min(start + chunk_size_chars, len(text))
end = target_end
if target_end < len(text):
sentence_end_positions = [
index + length
for delimiter, length in delimiters
if (index := text.find(delimiter, target_end)) >= 0
]
if sentence_end_positions:
end = min(sentence_end_positions)
else:
end = next(
(index + 1 for index in range(target_end, len(text)) if text[index].isspace()),
len(text),
)
chunks.append(text[start:end])
if end >= len(text):
break
start = max(start + 1, end - overlap_chars)
return chunks
@dataclass
class SummaryResult:
"""一次汇总的最终 Markdown 及供调用方展示/复用的元数据。"""
markdown: str
chunk_count: int
used_multilevel_strategy: bool
intermediate_summary: str
@dataclass
class SummarizationPipeline:
"""长会议纪要的两阶段 Map-Reduce 流水线。
短文本直接进入最终整合；长文本先并发提炼各分块，再将中间材料按
原始顺序合并为项目视图的会议纪要。
"""
llm: LLM
context_tokens: int = 4000
prompt_reserve_tokens: int = 300
completion_reserve_tokens: int = 1024
overlap_tokens: int = 100
template_markdown: str = FINAL_OUTPUT_TEMPLATE
progress_callback: Callable[[str], None] | None = None
max_concurrent_chunks: int = 2
intermediate_directory: Path | None = None
final_markdown_path: Path | None = None
@property
def chunk_threshold(self) -> int:
return max(1, self.context_tokens - self.prompt_reserve_tokens)
def summarize_chunk(self, chunk: str) -> str:
return self.llm.complete(system_prompt=CHUNK_SYSTEM_PROMPT, user_prompt=build_chunk_prompt(chunk))
def combine_chunk_summaries(self, summaries: list[str]) -> str:
return self.llm.complete(
system_prompt=COMBINE_SYSTEM_PROMPT,
user_prompt=build_combine_prompt(summaries, self.template_markdown),
).strip()
def summarize(self, transcript: str) -> SummaryResult:
if not transcript.strip():
raise ValueError("Transcript must not be empty")
if rough_token_count(transcript) < self.chunk_threshold:
summaries = [transcript]
chunk_count = 1
multi_level = False
else:
# Map 阶段：每个上下文窗口独立提炼，避免单次请求超过模型上下文。
chunks = chunk_text(
transcript,
max(1, self.chunk_threshold - self.prompt_reserve_tokens),
self.overlap_tokens,
)
summaries = self._summarize_chunks_concurrently(chunks)
chunk_count = len(summaries)
multi_level = True
self._notify("Generating final Markdown report")
# 如果启用中间文件，则从磁盘重新读取，保证最终合并使用已落盘的结果。
summaries_for_final = self._read_intermediate_chunks() if self.intermediate_directory else summaries
# Reduce 阶段：将所有分块材料重组为一份结构化项目会议纪要。
markdown = self.combine_chunk_summaries(summaries_for_final)
if self.final_markdown_path:
self.final_markdown_path.parent.mkdir(parents=True, exist_ok=True)
self.final_markdown_path.write_text(markdown, encoding="utf-8")
self._cleanup_intermediate_directory()
return SummaryResult(
markdown=markdown,
chunk_count=chunk_count,
used_multilevel_strategy=multi_level,
intermediate_summary="\n---\n".join(summaries),
)
def _summarize_chunks_concurrently(self, chunks: list[str]) -> list[str]:
"""以受限并发处理分块，并按原始索引返回结果而非完成先后顺序。"""
if not chunks:
raise RuntimeError("No transcript chunks were created")
results: list[str | None] = [None] * len(chunks)
next_index = 0
workers = max(1, min(self.max_concurrent_chunks, len(chunks)))
with ThreadPoolExecutor(max_workers=workers, thread_name_prefix="meeting-chunk") as executor:
pending: dict[Future[str], int] = {}
def submit_next() -> None:
nonlocal next_index
index = next_index
next_index += 1
self._notify(f"Summarizing chunk {index + 1}/{len(chunks)}")
pending[executor.submit(self.summarize_chunk, chunks[index])] = index
for _ in range(workers):
submit_next()
while pending:
completed, _ = wait(pending, return_when=FIRST_COMPLETED)
for future in completed:
index = pending.pop(future)
# future.result() 会在此处传播模型请求异常，避免产出不完整纪要。
results[index] = future.result()
self._write_intermediate_chunk(index, results[index])
self._notify(f"Completed chunk {index + 1}/{len(chunks)}")
if next_index < len(chunks):
submit_next()
return [result for result in results if result is not None]
def _write_intermediate_chunk(self, index: int, result: str | None) -> None:
if not self.intermediate_directory or result is None:
return
self.intermediate_directory.mkdir(parents=True, exist_ok=True)
# 固定宽度序号使按文件名排序时仍与原始分块顺序一致。
path = self.intermediate_directory / f"{index + 1:04d}.md"
path.write_text(result, encoding="utf-8")
def _read_intermediate_chunks(self) -> list[str]:
if not self.intermediate_directory:
return []
paths = sorted(self.intermediate_directory.glob("*.md"))
if not paths:
raise RuntimeError(f"No intermediate chunk files found: {self.intermediate_directory}")
return [path.read_text(encoding="utf-8") for path in paths]
def _cleanup_intermediate_directory(self) -> None:
if self.intermediate_directory and self.intermediate_directory.exists():
shutil.rmtree(self.intermediate_directory)
def _notify(self, message: str) -> None:
"""向 CLI 或测试脚本报告阶段进度；未配置回调时静默执行。"""
if self.progress_callback:
self.progress_callback(message)

22
src/meeting_summary_lab/prompt_loader.py 100644
View File

@ -0,0 +1,22 @@
from __future__ import annotations
from pathlib import Path
from typing import Any
import yaml
# src/meeting_summary_lab/prompt_loader.py -> 项目根目录/prompt
PROMPT_ROOT = Path(__file__).resolve().parents[2] / "prompt"
def load_prompt(agent_name: str, language: str = "zh") -> dict[str, Any]:
"""加载指定语言和名称的 YAML 提示词配置。"""
lang = "zh" if language.lower().startswith("zh") else "en"
path = PROMPT_ROOT / lang / f"{agent_name}.yaml"
if not path.exists():
raise FileNotFoundError(f"Prompt file not found: {path}")
with path.open("r", encoding="utf-8") as file:
data = yaml.safe_load(file) or {}
if not isinstance(data, dict):
raise ValueError(f"Prompt file must contain a YAML object: {path}")
return data

99
tests/run_real_model_stream.py 100644
View File

@ -0,0 +1,99 @@
"""手动运行真实模型；按配置并发提取并生成最终会议纪要。
运行：
D:/miniconda3/envs/wavdownlode/python.exe tests/run_real_model_stream.py
"""
from __future__ import annotations
import os
import sys
from time import perf_counter
from pathlib import Path
PROJECT_ROOT = Path(__file__).resolve().parents[1]
sys.path.insert(0, str(PROJECT_ROOT / "src"))
from meeting_summary_lab.cli import load_local_env
from meeting_summary_lab.llm import OpenAICompatibleLLM
from meeting_summary_lab.pipeline import SummarizationPipeline, chunk_text, rough_token_count
load_local_env(PROJECT_ROOT / ".env")
# ===== 可直接修改的测试配置 =====
INPUT_PATH = PROJECT_ROOT / "examples" / "文件会议 07-13 11_30-Transcript.md"
OUTPUT_PATH = INPUT_PATH.with_name(f"{INPUT_PATH.stem}-summary.md")
INTERMEDIATE_DIRECTORY = INPUT_PATH.with_name(f"{INPUT_PATH.stem}-chunks")
MAX_CONCURRENT_CHUNKS = int(os.environ.get("MEETING_SUMMARY_MAX_CONCURRENT_CHUNKS", "1"))
CONTEXT_TOKENS = int(os.environ.get("MEETING_SUMMARY_CONTEXT_TOKENS", "10240"))
MAX_TOKENS = int(os.environ.get("MEETING_SUMMARY_MAX_TOKENS", "1024"))
TEMPERATURE = float(os.environ.get("MEETING_SUMMARY_TEMPERATURE", "1.0"))
REQUEST_TIMEOUT_SECONDS = 300
ENDPOINT = os.environ.get("MEETING_SUMMARY_ENDPOINT", "")
MODEL = os.environ.get("MEETING_SUMMARY_MODEL", "")
API_KEY = os.environ.get("MEETING_SUMMARY_API_KEY", os.environ.get("OPENAI_API_KEY", ""))
# ================================
def main() -> None:
started_at = perf_counter()
try:
if not INPUT_PATH.is_file():
raise FileNotFoundError(f"Input transcript not found: {INPUT_PATH}")
if not ENDPOINT or not MODEL:
raise ValueError("Set MEETING_SUMMARY_ENDPOINT and MEETING_SUMMARY_MODEL in .env")
transcript = INPUT_PATH.read_text(encoding="utf-8")
print(f"Input: {INPUT_PATH}")
print(f"Endpoint: {ENDPOINT}; model: {MODEL}")
estimated_tokens = rough_token_count(transcript)
chunk_threshold = max(1, CONTEXT_TOKENS - 300)
chunk_count = 1 if estimated_tokens < chunk_threshold else len(
chunk_text(transcript, max(1, chunk_threshold - 300), 100)
)
print(f"Characters: {len(transcript)}; estimated tokens: {estimated_tokens}")
print(f"Chunks: {chunk_count}; concurrent chunk requests: {MAX_CONCURRENT_CHUNKS}; temperature: {TEMPERATURE}")
print("Starting concurrent chunk extraction...")
llm = OpenAICompatibleLLM(
endpoint=ENDPOINT,
model=MODEL,
api_key=API_KEY,
timeout_seconds=REQUEST_TIMEOUT_SECONDS,
max_tokens=MAX_TOKENS,
temperature=TEMPERATURE,
stream=True,
)
def report_progress(message: str) -> None:
elapsed = perf_counter() - started_at
print(f"[{elapsed:7.1f}s] {message}", flush=True)
pipeline = SummarizationPipeline(
llm=llm,
context_tokens=CONTEXT_TOKENS,
max_concurrent_chunks=MAX_CONCURRENT_CHUNKS,
intermediate_directory=INTERMEDIATE_DIRECTORY,
final_markdown_path=OUTPUT_PATH,
progress_callback=report_progress,
)
result = pipeline.summarize(transcript)
print("\n--- completed ---")
print(f"Chunks: {result.chunk_count}; multilevel: {result.used_multilevel_strategy}")
print(f"Saved: {OUTPUT_PATH}")
finally:
elapsed = perf_counter() - started_at
print(f"Runtime: {elapsed:.2f}s")
if __name__ == "__main__":
main()

53
tests/test_pipeline.py 100644
View File

@ -0,0 +1,53 @@
import unittest
from meeting_summary_lab.llm import FakeLLM
from meeting_summary_lab.pipeline import SummarizationPipeline, build_combine_prompt, chunk_text, rough_token_count
from prompt_loader import load_prompt
class PipelineTests(unittest.TestCase):
def test_rough_token_count_matches_source_formula(self):
self.assertEqual(rough_token_count("a" * 10), 4)
def test_chunking_has_multiple_overlapping_windows(self):
chunks = chunk_text("word " * 500, chunk_size_tokens=50, overlap_tokens=10)
self.assertGreater(len(chunks), 1)
self.assertTrue(chunks[0].strip())
def test_chunking_keeps_unpunctuated_windows_intact(self):
chunks = chunk_text("中" * 200, chunk_size_tokens=50, overlap_tokens=10)
self.assertEqual(len(chunks[0]), 50)
self.assertTrue(all(len(chunk) > 1 for chunk in chunks))
def test_short_text_runs_one_final_combine_call(self):
llm = FakeLLM()
result = SummarizationPipeline(llm=llm, context_tokens=1000).summarize("A short meeting transcript.")
self.assertFalse(result.used_multilevel_strategy)
self.assertEqual(result.chunk_count, 1)
self.assertEqual(len(llm.calls), 1)
def test_long_text_maps_then_generates_final_report(self):
llm = FakeLLM()
result = SummarizationPipeline(llm=llm, context_tokens=1000).summarize("Alice decided to ship next week. " * 200)
self.assertTrue(result.used_multilevel_strategy)
self.assertEqual(len(llm.calls), result.chunk_count + 1)
self.assertTrue(result.markdown.startswith("[combined summary]"))
def test_combine_prompt_contains_template_and_summaries(self):
prompt = build_combine_prompt(["会议摘要"], "# 自定义模板")
self.assertIn("# 自定义模板", prompt)
self.assertIn("会议摘要", prompt)
self.assertIn("模板", prompt)
def test_yaml_prompt_config_has_three_prompt_blocks(self):
prompt = load_prompt("base")
self.assertEqual(set(prompt["system"]), {"chunk_prompt", "combine_prompt"})
self.assertEqual(set(prompt["prompts"]), {"chunk_user", "combine_user"})
if __name__ == "__main__":
unittest.main()