一种对EOC局端设备进行性能测试的方法与流程

本发明涉及三网融合EOC(Ethernet Over Cable，基带传输)接入技术领域，具体涉及一种对EOC局端设备进行性能测试的方法。

背景技术：

EOC系统是由局端CBAT(Cable Bandwidth Access Terminal，同轴电缆带宽接入终端)、用户终端CNU(Cable Network Unit，同轴电缆网络单元)和CDN(Cable Distribution Network，同轴电缆分配网络)组成的同轴双向传输系统，用于在有线电视传输线路上同时承载以太网和有线电视业务。

EOC局端CBAT又由主处理器和若干CLT(Cable Line Terminal，同轴电缆线路终端)组成，CLT和CNU之间通过MME报文进行通信，主处理器也通过MME报文实现对CLT和CNU的配置、维护和管理，主要功能包括CLT上下线、CNU上下线、读取CNU的HFID(Human Friendly Identifier，用于识别CNU设备类型的字段)、CNU的UNI(User Network Interface，用户-网络接口)的配置和状态查询、重启CNU和CNU软件升级等。

EOC局端CBAT对CNU进行管理会耗费一定的CPU和内存资源，随着CNU个数的规模增长，无论是CLT还是主处理器，都会带来极大的性能处理要求，EOC局端CBAT能否满足要求必须通过测试进行验证，因此涉及到复杂测试环境的搭建问题。实际测试环境下，想要测试EOC局端CBAT的最大接入能力，必须准备多个CLT和足够多的CNU用于测试，导致测试环境的搭建和维护都具有一定的难度。

有鉴于此，急需提供一种能够降低EOC局端CBAT接入能力测试难度的方法。

技术实现要素：

本发明所要解决的技术问题是降低EOC局端CBAT接入能力的测试难度。

为了解决上述技术问题，本发明所采用的技术方案是提供一种对EOC局端设备进行性能测试的方法，包括以下步骤：

通过仿真软件仿真预设数目的CLT，并在预设数目CLT下分别配置预设数目CNU的MAC地址和HFID；

EOC局端主处理器向仿真软件依次获取各个CLT的MAC地址、各个CLT下挂的各个CNU的MAC地址以及各个CNU的HFID，仿真软件依次回应界面上各个CLT的MAC地址、各个CNU的MAC地址以及各个CNU的HFID；

EOC局端主处理器根据获取到的不同HFID，向仿真的各个CNU下发不同的配置报文，仿真软件解析各个CNU的配置报文，显示配置信息并回应配置结果。

在上述技术方案中，

通过所述仿真软件在预设数目CLT下分别配置预设数目CNU的MAC地址和HFID，单个或批量增加所述CNU，所述CNU单个或批量上线；或

通过所述仿真软件删除预设数目CLT下预设数目CNU的MAC地址和HFID，单个或批量删除所述CNU，所述CNU单个或批量下线。

在上述技术方案中，所述仿真软件接收所述EOC局端主处理器发送的MME请求报文，解析报文内容，如果是查询消息，则将相应的信息以MME回应报文的格式回应所述EOC局端主处理器；如果是配置消息，则将相应配置解析为寄存器的值下发到CNU，并将配置结果回应给所述EOC局端主处理器。

在上述技术方案中，所述EOC局端主处理器通过向所述仿真软件发送目的MAC地址为00:B0:52:00:00:01、类型为0xA010的MME请求报文，查询所述CLT的MAC地址。

在上述技术方案中，所述EOC局端主处理器通过周期性地向所述仿真软件发送类型为0xA038的MME请求报文，获取所述CLT下挂的CNU的MAC地址。

在上述技术方案中，所述EOC局端主处理器通过向所述仿真软件发送类型为0xA024的MME请求报文，读取所述CNU的PIB文件，并根据偏移量提取所述CNU的HFID。

在上述技术方案中，所述EOC局端主处理器通过向所述仿真软件发送类型为0xA0B0的MME请求报文，对所述CNU的交换芯片的端口使能、VLAN信息、端口限速、双工模式和风暴抑制进行写配置，写配置操作包括创建写会话、写配置到内存以及将内存配置写Flash。

在上述技术方案中，在DHCP认证模式下，通过所述仿真软件仿真所述CNU的UNI下挂的UE，进行批量的DHCP认证，并将动态获取的IP地址显示出来。

本发明通过仿真软件不仅能仿真CNU还能仿真各个CLT，可完成EOC局端挂接大批量CNU的仿真测试，极大的简化了测试环境，从而大大降低了EOC局端接入能力测试的复杂度和测试难度，缩短了测试周期，提高了测试效率以及降低了测试成本。

附图说明

图1为本发明中一种对EOC局端设备进行性能测试的方法流程图；

图2为本发明中测试拓扑图；

图3为本发明中EOC局端主处理器的基本处理流程图；

图4为本发明中仿真软件的基本处理流程图。

具体实施方式

在通信设备的系统测试中，EOC局端主处理器的承载能力是一项重要的性能指标，在EOC系统工程应用中，如何在实验室环境下，用有限的CNU测试大规模工程应用条件下EOC局端CBAT对CNU的承载能力，一直是困扰业界的难题。本方案创新性地提出采用仿真CNU的设计，在测试环境匮乏的情况下，仅用仿真软件就可以仿真高达几十甚至几百个CNU，该设计完全可以满足测试需求，可以极大的简化测试环境，从而大大降低了EOC局端CBAT接入能力测试的复杂度，提高了测试效率，缩短了测试周期，并降低了测试成本，对于促进行业的发展有着重要的参考价值。

下面结合说明书附图和具体实施方式对本发明做出详细的说明。

本发明实施例提供了一种对EOC局端设备进行性能测试的方法，如图1所示，包括以下步骤：

S1、通过仿真软件仿真预设数目的CLT,并在预设数目CLT下分别配置预设数目CNU的MAC地址和HFID。

本方案将复杂性能测试环境简化到一根网线和一台电脑就可以测试EOC局端挂接能力，测试拓扑十分简单，具体测试拓扑如图2所示。

可以选择仿真单个或者多个CLT，仿真单个CLT时，CLT的MAC地址为连接EOC局端CBAT的电脑网卡的MAC地址；仿真多个CLT时，各CLT的MAC地址依次为连接EOC局端CBAT的电脑网卡的MAC地址、电脑网卡的MAC地址+1、电脑网卡的MAC地址+2等，依次类推。

通过仿真软件可在各个CLT下分别配置CNU的MAC地址和HFID，可以单个或批量增加CNU，增加CNU即认为CNU上线；或者，通过仿真软件删除CLT下CNU的MAC地址和HFID，单个或批量删除CNU，删除CNU即认为CNU下线。

S2、EOC局端主处理器向仿真软件查询各个CLT的MAC地址，仿真软件根据界面的配置，回应各个CLT的MAC地址。

S3、EOC局端主处理器获取到各个CLT的MAC地址后，向仿真软件查询各个CLT下挂的各个CNU的MAC地址，仿真软件根据界面的配置，回应各个CLT下挂的各个CNU的MAC地址。

S4、EOC局端主处理器获取到各个CNU的MAC地址后，向仿真软件查询各个CNU的HFID，仿真软件根据界面的配置，回应各个CNU的HFID。

S5、EOC局端主处理器根据获取到的不同HFID，向仿真的各个CNU的交换芯片下发不同的配置报文，仿真软件解析各个CNU的配置报文，显示配置信息并回应配置结果。

上述仿真软件是基于Windows平台的一款EOC终端仿真软件，主要用于接收EOC局端发送的MME请求报文，解析报文内容，并回应MME请求报文，EOC局端主处理器与CLT和CNU之间的所有通信均采用MME报文。仿真软件接收到EOC局端主处理器发送的MME请求报文，解析报文内容，如果是查询消息，则将相应的信息以MME回应报文的格式回应EOC局端主处理器；如果是配置消息，则将相应配置解析为寄存器的值下发到CNU，并将配置结果回应给EOC局端主处理器。

仿真软件的核心是仿真CNU的操作，接收EOC局端主处理器发送的MME报文，解析MME报文并回应EOC局端主处理器，在界面配置几十甚至上百个CNU，能够很容易地测试出EOC局端下可以同时在线或正常运行的CNU最大数量，得出EOC局端设备对CNU个数的最大支持能力。同时，也可以在界面上单个或批量增加或删除CNU，以仿真CNU单个或批量上下线时EOC局端CBAT的处理情况，以及查询CNU获取到的配置是否正确。

另外，通过仿真软件仿真CLT和CNU只是其一部分功能，更可以在DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)认证模式下，通过仿真软件仿真CNU的UNI(User Networks Interface，用户网络侧接口)下挂的UE(User Equipment，用户设备)，进行批量的DHCP认证，并将动态获取的IP地址显示出来。

如图3所示，EOC局端主处理器的基本处理流程包括以下步骤：

S10、查询CLT的MAC地址。

S11、判断是否接收到MME回应报文，如果是，转S12；否则，转S10。

S12、查询CLT下挂的CNU的MAC地址。

S13、判断MME回应报文中是否包含CNU，如果是，转S14；否则，转S12。

S14、判断是否有新CNU上线，如果是，转S15；否则，转S12。

S15、查询CNU的HFID。

S16、根据获取到的不同HFID对仿真的各个CNU的交换芯片下发不同配置报文。

如图4所示，仿真软件的基本处理流程包括以下步骤：

S20、选择电脑网卡及确定仿真CLT的预设数目。

S21、接收到查询各个CLT的MAC地址的MME请求报文。

S22、回应连接EOC局端CBAT的电脑网卡的MAC地址。

S23、接收到查询各个CLT下挂CNU的MAC地址的MME请求报文。

S24、判断界面是否配置有CNU，如果是，转S25；否则，转S23。

S25、回应界面配置的各个CNU的MAC地址。

S26、接收到查询各个CNU的HFID的MME请求报文。

S27、回应各个CNU配置的HFID。

S28、接收到配置各个CNU的交换芯片的MME请求报文。

S29、解析各个CNU的交换芯片的配置报文，显示配置信息并回应配置结果。

1.1MME请求报文的标准格式如表1所示。

表1：请求MME报文的标准格式。

在表1中，字段ODA、OSA、VLAN和MTYPE共同组成以太网包头，字段MMV、MMTYPE和OUI共同组成MME包头，因此，MME报文的标准格式为：以太网包头+MME包头+MME数据段。

1.2查询CLT的MAC地址。

EOC局端CBAT由一个主处理器和若干个CLT组成，主处理器是整个EOC局端的核心，掌握和处理整个EOC局端的运行状态。在对CLT和CNU进行管理时，首先查询是否存在CLT，在目的MAC地址未知的情况下，EOC局端主处理器通过发送目的MAC地址为00:B0:52:00:00:01的MME请求报文查询CLT的MAC地址，若存在CLT，则CLT自动回应MME请求报文，EOC局端主处理器获取CLT的MAC地址等信息。

查询CLT的MAC地址的MME请求报文类型为0xA010，该MME请求报文只包含以太网包头和MME包头，不包含MME数据段，所以只需将MMTYPE填为0xA010即可。

查询CLT的MAC地址的MME回应报文类型为0xA011，MME数据段的格式如表2所示。

表2：查询CLT的MAC地址的MME回应报文类型为0xA011时，MME数据段的格式。

在表2中，MME回应报文0xA011的源MAC地址为CLT的MAC地址，字段NVMTYPE、NVMPAGE、NVMBLOCK和NVMSIZE一般只关注NVMSIZE，即flash的大小。

1.3查询CLT下挂的CNU的MAC地址。

若CLT下挂接了CNU，则CLT和CNU直接通过内部的MME报文通信，从CLT上能学到下挂的各个CNU的MAC地址等信息，EOC局端主处理器只需周期性地向CLT发送MME请求报文即可获得该CLT下的CNU的MAC地址，EOC局端主处理器通过比较本次和上一次获取到的CNU的MAC地址，即可获知是否有CNU上下线。

查询CLT下CNU的MAC地址的MME请求报文类型为0xA038，该MME请求报文只包含以太网包头和MME包头，不包含MME数据段，所以只需将MMTYPE填为0xA038即可。

查询CLT下CNU的MAC地址的MME回应报文类型为0xA039，MME数据段的格式如表3所示。

表3：查询CLT下CNU的MAC地址的MME回应报文类型为0xA039时，MME数据段的格式。

在表3中字段NWINFO的详细内容如表4所示。

表4：字段NWINFO的详细内容。

上述类型为0xA039的MME回应报文中，字段CCO_MACADDR填写CLT的MAC地址，该CLT下各CNU的MAC地址填写在字段DA[0]和字段DA[L-1]中。

1.4查询CNU的HFID。

CNU的HFID中标识了CNU的类型和厂家等信息，EOC局端的主处理器在获知有新CNU上线的消息后，需要获取新CNU的HFID，根据获取的HFID对不同CNU下发相应的配置报文。CNU的HFID保存在PIB(Parameter Information Block，参数信息块)文件中，要想获取HFID需先读取CNU的PIB文件，PIB为二进制文件，根据偏移量即可提取HFID信息。

获取CNU的HFID的MME请求报文类型为0xA024，MME数据段的格式如表5所示。

表5：获取CNU的HFID的MME请求报文类型为0xA024时，MME数据段的格式。

在表5中字段MODULEID需填写0x02(PIB)，即读取CNU的PIB文件。

获取CNU的HFID的MME回应报文类型为0xA025，MME数据段的格式如表6所示。

表6：获取CNU的HFID的MME回应报文类型为0xA025时，MME数据段的格式。

在表6中字段MSTATUS回应获取CNU的HFID成功及失败原因，字段MODULEID填写0x02(PIB)，即读取CNU的PIB文件，字段DATA按要求填写PIB文件中的各个参数。

1.5配置CNU。

ECO局端对CNU的配置主要是对CNU的交换芯片的配置，包括交换芯片的端口的使能、VLAN信息、端口限速、双工模式和风暴抑制等参数，且这些参数必须能保存配置。

写配置操作包括创建写会话(Start Write Session)、写配置到内存(Write)及将内存配置写Flash(Commit)，这三种MME请求报文的类型均为0xA0B0，MME回应报文类型均为0xA0B1。

MME请求报文(0xA0B0)的通用包格式如表7所示。

表7：MME请求报文的通用包格式。

MME回应报文(0xA0B1)的通用包格式如表8所示。

表8：MME回应报文的通用包格式。

1.5.1创建写会话(Start Write Session)。

Start Write Session请求报文的字段MOD_OP_DATA如表9所示。

表9：Start Write Session请求报文的字段MOD_OP_DATA内容。

在表9中，字段MOD_OP填0x10(Start Write Session)，字段MODULE_SUB_ID填要写的BLOCK区域的ID。

Start Write Session回应报文的格式如表10所示。

表10：Start Write Session回应报文的格式。

在表10中，字段MOD_OP填0x10(Start Write Session)，字段MOD_STATUS填返回码。

1.5.2写配置到内存(Write)。

Write请求报文的字段MOD_OP_DATA如表11所示。

表11：Write请求报文的字段MOD_OP_DATA内容。

在表11中，字段MOD_OP填0x11(Write Module to Memory)，字段MODULE_SUB_ID填要写的BLOCK区域的ID，字段DATA填写配置参数信息。

Write回应报文的格式如表12所示。

表12：Write回应报文的格式。

在表12中，字段MOD_OP填0x11(Write Module to Memory)，字段MODULE_SUB_ID填要写的BLOCK区域的ID。

1.5.3将内存配置写Flash(Commit)。

Commit请求报文的MOD_OP_DATA字段如表13所示。

表13：Commit请求报文的MOD_OP_DATA字段内容。

在表13中，字段MOD_OP填0x12(Commit Module from Memory to NVM)，MOD_OP_DATA_LEN填要写flash的配置参数的长度。

Commit回应报文的格式如表14所示。

表14：Commit回应报文的格式。

在表14中，字段MOD_OP填0x12(Commit Module from Memory to NVM)，字段MOD_OP_DATA_LEN填要写flash的配置参数的长度，字段COMMIT_CODE填返回码。

本发明不局限于上述最佳实施方式，任何人在本发明的启示下作出的结构变化，凡是与本发明具有相同或相近的技术方案，均落入本发明的保护范围之内。