简介这份中国电信PON EMS北向接口技术规范综合信息查询接口分册是一份面向PON网络管理系统与OSS/服务保障类系统开发、集成及运维人员的PDF技术文档主要用于规范设备信息查询、业务配置查询、资源变化通知和资源数据全量导出等接口的功能、参数、协议及技术要求也是电信OSS系统标准化对接和日常排障的重要参考。压缩包内共1个文件类型为PDF包体大小252KB文档目录清晰、内容完整可直接下载查阅。目前已有81人学习浏览。规范详细覆盖OLT与ONU设备查询、机框信息查询等具体接口给出了查询接口的调用方式、数据格式和响应机制并涉及接口位置、接口功能定义以及协议安全、性能指标与错误处理等要求。遵循该规范可帮助实现PON网络设备的自动化监控、故障诊断与业务优化提升运维效率并降低系统集成成本适合电信网络运维、OSS开发及设备厂商技术人员学习参考。1. 这份 PON EMS 北向接口规范管的是资源系统和网管之间的那点事做资源管理系统对接的人多半都经历过这种时刻上面要你把 PON 网络的 OLT、ONU、端口、VLAN 全部同步到资源库里你问网管厂家要接口文档对方甩过来一本几十页的 PDF就是这份《中国电信 PON EMS 北向接口功能及技术规范综合信息查询接口分册》。说白了它把OSS 系统怎么从 PON EMS 查设备、查业务、收变化通知、批量拿数据这件事从接口编号到报文格式全部固定下来了。以前靠人肉导表、翻网管界面点鼠标的日子靠它可以改成正经的北向接口自动同步。适合做服务保障系统、资源管理系统、自动激活系统开发的工程师也适合刚接手 PON 网管北向对接、想快速搞清楚 I5 接口有几类功能的人。2. 综合信息查询接口全景四类能力、十几个接口编号先看懂再动手2.1 为什么把综合信息查询切成四个能力块这份规范里的 I5 接口不是简单的一两个查询命令而是按用途拆成了四块设备信息查询、业务配置查询、资源变化通知、资源数据全量导出。这样切分是有道理的——物理资源OLT、ONU、机框、板卡和业务配置语音、组播、DSL、LAN、VLAN本来就是两类数据前者管网络里有什么后者管业务上配了什么。而资源变化通知解决的是增量问题设备增删、板卡插拔不能总靠全量刷得让 EMS 主动推给你资源数据全量导出则解决存量初始化问题新系统上线第一天总得先把全网数据一次性捞过来。从整个 PON 网络 IT 支撑架构来看I5 只是 PON EMS 和上层系统之间的一个方向。同一张图上还有 ITMS、软交换、综合告警各自对应的接口但只有 I5 是面向资源和服务保障场景的查询通道。所以这份规范里看不到告警上报、看不到性能统计它就是把查询这一件事做透。理解了这个定位后面看接口清单就不会晕。2.2 设备信息查询OLT、ONU、机框、板卡四个接口设备信息查询是最基础的一块对应四个接口接口编号接口名称查什么PON.RESPHY.I5.001查询 OLT 设备信息全网或单个 OLT 的名称、IP、类型、软件版本、CPU/内存利用率、温度PON.RESPHY.I5.002查询 ONU 设备信息OLT 下所有或单个 ONU 的认证方式、MAC、LOID、软件版本PON.RESPHY.I5.003查询机框信息全网机框或单个 OLT/MXU 的机框类型PON.RESPHY.I5.004查询板卡信息全网板卡或单个设备板卡的类型、业务类型、端口数目、软硬件版本这里有个关键设计ONU 查询分了三种模式。模式一给你 OLT ID返回这个 OLT 下所有 ONU模式二给 ONU 的 IP 地址适合查具备 IP 的 SFU/HGU模式三最麻烦ONU 不具备 IP 时要组合传 OLT ID、OLT PON 口、ONU 标识类型ONU_NAME、MAC、LOID、ONU_NUMBER 四选一和具体标识值。为什么这么设计因为无 IP 的 ONU 在网络上没有独立地址只能用挂在哪个 OLT 的哪个 PON 口 一个唯一标识来定位。对接资源系统时老工程师最容易在模式三上翻车后面避坑章节细说。2.3 业务配置查询语音、组播、DSL、LAN、VLAN 七个接口业务配置查询这块有七个接口覆盖了 PON 接入网上最常见的业务类型接口编号接口名称关键返回字段PON.RESSRV.I5.001查询媒体网关信息MGID、语音协议类型H.248/SIP、语音 VLAN、主备软交换 IPPON.RESSRV.I5.002查询语音端口信息ONU 端口号、电话号码、H.248 终端标识、SIP 用户名密码、传真模式PON.RESSRV.I5.003查询组播业务信息组播用户的业务信息、组播频道相关配置PON.RESSRV.I5.004查询 DSL 端口信息DSL 端口配置、速率模板等PON.RESSRV.I5.005查询 LAN 端口信息LAN 端口状态与配置PON.RESSRV.I5.006查询端口 VLAN 信息端口上的 VLAN 划分PON.RESSRV.I5.007查询 VLAN 接口VLAN 三层接口配置做语音业务自动开通的系统重点看 001 和 002做 IPTV 工单的重点看 003 组播做资源清查的005、006、007 一个都跑不掉。这里要提醒的是查询媒体网关信息时同样区分 ONU 有无 IP无 IP 的 ONU 照样要走模式三的组合参数。规范把这种参数设计从头贯彻到尾对接时最好封装一个统一的设备定位参数结构别每个接口单独传参。2.4 资源变化通知注册、取消、查询、通知四个接口资源变化通知解决的是EMS 侧设备变了OSS 怎么及时知道的问题。它不是一个接口而是一组PON.RESCHG.I5.001 注册资源变化通知PON.RESCHG.I5.002 取消资源变化通知PON.RESCHG.I5.003 查询资源变化通知PON.RESCHG.I5.004 资源变化通知上报前三个是 OSS 主动调用 EMS最后一个是 EMS 主动推给 OSS。流程是OSS 先调用 001 注册告诉 EMS我要收哪些变化EMS 在 OLT、MXU 的设备、机框、板卡发生增删变化时调用 004 把变化推给 OSS。不做资源增量同步的系统这块可以跳过但如果你负责资源管理系统这块直接决定你的资源库能不能跟上现网变化。有一点要在设计阶段就确认004 通知是 EMS 主动连你还是你轮询 003 去拉不同厂家的实现不一样规范的接口定义只规定了命令字和数据内容传输方向在 6.1 接口位置那节有图但实际部署时防火墙策略得按厂家的通知通道来开。这个坑在第五节细讲。2.5 资源数据全量导出把全网数据一次性倒文件PON.RESDUMP.I5.001 资源数据全量导出是给新系统初始化用的。它和前面的查询接口思路完全不同查询是一个一个取导出是 EMS 把全网设备信息和业务配置一次性生成到文件里OSS 再通过 FTP 把文件取走自己解析、比较、更新。配套的 PON.RESDUMP.I5.002 是导出结果通知告诉 OSS文件准备好了可以去拿了。这带来一个异步模型你发导出命令EMS 生成文件生成完通知你你再去 FTP 拿。文件格式、命名规则、FTP 账号规范里定义了整体要求但具体细节厂家会有差异。第一次对接时我建议先导一个小范围如果厂家支持按 OLT 过滤确认文件结构和内容样例再跑全网导出不然全网数据跑到一半发现格式不对返工成本很高。3. 接口协议约定从 LOGIN 到错误码一个请求报文怎么才算合法3.1 底层通讯与会话控制登录、退出、握手三件套协议部分最先要搞定的不是查询报文而是会话。规范 8.3 节规定了三个基础命令LOGIN 登录 PON EMS、LOGOUT 退出、SHAKEHAND 握手。登录成功后OSS 和 EMS 之间才建立有效会话后续查询命令都在这个会话里跑。常见实现是 TCP 长连接 XML 报文端口和具体报文字段由厂家在规范基础上细化。我一般会这么组织登录请求?xml version1.0 encodingUTF-8? message head commandLOGIN/command seq1/seq /head body param nameuserName valueoss_user/ param namepassword value******/ /body /message逻辑说明head 里的 command 标识命令类型seq 是序列号用来把响应和请求对上body 里放参数。登录成功与否看响应里的错误码。要注意的是用户名密码的加密方式规范层面不会细到每个厂家都一致多数是明文或简单加密对接时要跟厂家确认有没有额外的安全要求。握手命令 SHAKEHAND 的作用是保活。有些厂家会要求 OSS 每隔一段时间发一次握手避免服务端把连接空闲回收有的则是 EMS 主动发。这个机制直接关系到长连接稳定性建议连接建立后先观察日志确认双方握手频率再设置客户端的空闲超时否则半夜批量任务很容易翻车。3.2 消息格式请求、确认、响应三段式规范把交互过程拆成了三段OSS 发输入命令消息EMS 先回一个确认消息Acknowledgement处理完再回正式的响应消息。确认消息不等于查询结果它只是告诉发送方命令我收到了正在处理。输入命令消息里要有命令编码、序列号、参数。确认消息一般带原序列号和一个处理状态。响应消息里才是真正的业务数据。这个三段式设计很容易被忽略有的开发只看第一次返回发现是确认消息就当空数据结果解析不到业务字段。正确的做法是先匹配 seq然后区分消息类型确认消息只做状态登记业务数据要等响应消息。3.3 资源变化通知的报文格式资源变化通知PON.RESCHG.I5.004是 EMS 主动发给 OSS 的报文结构里除了命令字、序列号核心是变化类型新增/删除和资源对象标识。比如设备新增通知至少要带 OLT ID、机框/板卡/ONU 的标识让资源系统知道该往哪个节点挂。这类通知的格式和查询响应不一样解析逻辑要单独写不能复用查询响应解析器。3.4 返回错误码0 是成功非 0 就要查表规范明确返回参数里 0 表示成功其他值表示失败失败原因对应错误码定义。但具体的错误码表和数值规范正文里没有逐个展开厂家实现时会有自己的枚举。对接前一定要做两件事一是找厂家要完整的错误码清单二是把错误码打日志留现场别只存一个失败。我踩过最长的一个坑是错误码定义拿到晚了生产上返回一个码手册上没有最后发现是厂家的内部错误码没映射。所以代码里最好留一个未知错误码分支把原始码值、原始响应全文记下来方便找厂家定位。4. 对接开发实战OLT/ONU 查询请求怎么组装、参数怎么传4.1 先理顺调用前置条件动手写代码前先确认三件事网络通不通TCP 端口可达、账号能不能登录LOGIN 正常返回成功、会话保活配没配握手。很多问题不是查询报文写错了是会话层先挂了。我习惯写一个最小化的会话测试登录、握手、查询一个已知 OLT、退出四步走一遍全通了再开始封装业务接口。4.2 查询 OLT 设备信息最简请求的组装PON.RESPHY.I5.001 的输入参数只有 OLT ID而且可选——不传就是查全网 OLT传了就是查单个。这个参数可以是 IP 地址也可以是设备名称。查询时报文长这样?xml version1.0 encodingUTF-8? message head commandPON.RESPHY.I5.001/command seq1001/seq sessionIdxxxx/sessionId /head body param nameOLT_ID value10.24.8.101/ /body /message逻辑说明sessionId 是登录后分配的会话标识有些厂家要求带有些不要求OLT_ID 传了就是查单个 OLT不传就查全网。响应里会带设备名称、设备 IP、设备类型、软件版本、内存利用率、CPU 利用率、温度这些字段。参数说明OLT_ID 建议统一用管理 IP不要混用名称因为名称在不同网管里可能有空格或特殊字符容易在报文拼接时出错。查全网时注意数据量OLT 数量大的省网一次返回可能几十上百条客户端要做好分页或流式读取的准备别等超时。4.3 查询 ONU 设备信息三种模式怎么选查询 ONU 的 PON.RESPHY.I5.002 比查 OLT 复杂三种模式对应三种传参组合模式适用场景必传参数模式一查 OLT 下所有 ONUOLT ID模式二查单个有 IP 的 ONUONU IP 地址模式三查单个无 IP 的 ONUOLT ID OLT PON 口 ONU 标识类型 ONU 标识模式三的 XML 请求要注意 PON 口的格式是机架-框-槽号-端口比如 1-1-2-5。ONU 标识类型四选一传 ONU_NAME、MAC、LOID、ONU_NUMBER 都行但标识值必须和类型匹配传 MAC 类型就得给 MAC 格式的值传 LOID 类型就得给 LOID 字符串。?xml version1.0 encodingUTF-8? message head commandPON.RESPHY.I5.002/command seq1002/seq /head body param nameOLT_ID value10.24.8.101/ param nameOLT_PON_PORT value1-1-2-5/ param nameONU_ID_TYPE valueONU_NAME/ param nameONU_ID valueFTTH-HGU-000102/ /body /message逻辑说明这个报文走的是模式三用哪台 OLT 的哪个 PON 口 什么类型的标识 具体标识值唯一定位一台无 IP ONU。查询成功后返回 OLT ID、PON 端口号、ONU 授权号、ONU 名称、类型、IP 地址、MAC、认证方式、LOID、软件版本。参数说明OLT_ID 和 OLT_PON_PORT 必须能对应上PON 口在 EMS 里的表示可能是机架-框-槽号-端口也可能是框/槽/口的分段字段拼接前先找厂家要一个实际样例。ONU_ID_TYPE 的取值一定要用规范里给的枚举值不能自己造缩写。4.4 解析响应的常见做法响应消息本质是一段带业务字段的 XML解析时把命令字、错误码、业务字段分开处理。我一般用 Python 加 lxml 来解伪代码给你参考from lxml import etree def parse_ems_response(xml_text): root etree.fromstring(xml_text.encode(utf-8)) # 先取命令字和错误码 command root.xpath(/message/head/command/text())[0] err_code root.xpath(/message/head/errorCode/text())[0] if err_code ! 0: raise RuntimeError(fEMS返回错误: {err_code}) # 业务字段集中在一个列表里每条ONU/OLT记录是固定结构 records [] for node in root.iter(record): item {} for field in node: item[field.tag] field.text records.append(item) return command, records逻辑说明解析先分两层head 看状态body 里迭代业务记录。规范里的返回参数组织方式是字段名: 值厂家实现成 XML 时一般会包一层 record 节点字段名可能就是规范里的英文名也可能是厂家映射后的名称第一版对接时先 dump 一条原始响应确认标签名再写解析器。参数说明解析器一定要容忍未知字段不要用 strict 模式因为厂家后续升级可能增加返回字段强校验会把小改动变成大故障。5. 对接避坑记录五个实测翻车场景5.1 现象ONU 怎么都查不到响应一直报失败原因是模式三参数不齐。我曾经只传了 OLT ID 和 ONU 名称没传 OLT PON 口EMS 根本定位不到这台 ONU。因为同一台 OLT 下ONU 名称可能重复而且不同 PON 口下的 ONU 编号体系独立不传 PON 口设备侧无法确定是哪一根光纤下的 ONU。解决把模式三的四项参数凑齐ONU 标识类型和标识值一定要配套MAC 模式就传标准 MAC 格式LOID 模式就传字符串别混。5.2 现象注册了资源变化通知一条通知都收不到原因是 EMS 主动通知的通道没打通或者根本没先注册。有一次我在防火墙上只开了 OSS 到 EMS 的 10000 号端口但 EMS 推送通知需要从 EMS 主动连 OSS 的监听端口反方向没放行通知当然进不来。解决先确认 PON.RESCHG.I5.001 注册返回成功再确认 EMS 侧配置了 OSS 的接收地址和端口最后在 OSS 端起一个临时 TCP 监听手动增删一块板卡看 EMS 有没有发 PON.RESCHG.I5.004。别急着怀疑报文先抓包看有没有数据进来。5.3 现象中文乱码解析出来的设备描述全是锟斤拷原因是 XML 编码不统一。EMS 返回的报文如果是 GBK而你用 UTF-8 解析中文字段必乱。解决请求里显式声明 UTF-8响应解析时先检测编码不要默认 UTF-8。我后来养成的习惯是解析前先看原始字节流的前几个字节确认 BOM 或声明再决定解码方式这个从第一天就写进解析器能省掉后期大量抽查。5.4 现象全量导出命令发出去了FTP 上等半小时文件还是空的原因是全量导出是异步的导出命令只是触发 EMS 生成文件生成完了靠 PON.RESDUMP.I5.002 通知 OSS你再去 FTP 拿。如果只发命令就立刻去 FTP 轮询大概率拿到的是临时文件或者空文件。解决把流程改成发导出命令 → 监听导出完成通知 → 收到通知后再连 FTP 取文件同时设置超时重试。还有一个血泪经验FTP 一定要用被动模式很多厂家的 FTP 服务在主动模式下会卡在数据连接上。5.5 现象半夜批量查询大面积失败早上看日志全是登录超时原因是会话被服务端回收了但客户端还以为是长连接。规范里有 SHAKEHAND 握手命令就是用来保活的没做定时握手的客户端空闲超过厂家的会话超时阈值后再发查询就是无效会话。解决在客户端里加一个定时任务按厂家要求的间隔发 SHAKEHAND间隔取厂家阈值的一半比较稳。另外批量任务开始前加一个会话有效性检查失效就重新 LOGIN别让一批任务全挂在死会话上。6. 资源全量导出后的核对技巧文件拿到了怎么证明数据是对的全量导出接完真正考验人的不是导出命令而是怎么证明导出文件是对的。我的做法是三步走。文件行数核对把规则文件行数和 EMS 界面上的设备总数对照但别只比总数要按 OLT 分组比因为总数能对上、某个 OLT 下整棵子树丢了的情况很常见。关键字段抽样导出的 XML 或 CSV 里每个 OLT 抽一两台 ONU把设备名称、MAC、LOID、PON 口、认证方式拿到 EMS 界面上人工比对一遍抽样二十条左右覆盖不同厂家、不同型号比全量验证划算得多。导出再导出比对隔一小时导第二次把两个文件的哈希值或行数比较如果差异巨大说明导出过程不稳定或者 EMS 侧有大量资源变动这时候要先查变化再谈数据一致。还有一个小技巧是解析文件时做主键唯一性检查。规则里给字段专门设计一个业务键导出文件里应该唯一如果出现重复大概率是 EMS 侧数据本身有问题或者导出时没做去重这种脏数据进了资源库后面工单会全部错乱。我最初做 PON 资源同步时自以为导出完了就完事结果第一个省的数据导完资源树上一片乱挂查了一个星期才发现是导出文件里 ONU 标识和 PON 口不匹配解析时又没做唯一性校验脏数据直接入库。从那以后我每次接全量导出都强制把行数核对、抽样比对、二次导出这三步走一遍确认全绿才允许入库。这套方法不挑厂家、不挑协议版本希望你也能省掉我当年踩过的那些坑顺利把接口跑透。本文还有配套的精品资源点击获取