CN117319166A

CN117319166A - Access network equipment management method and computer equipment

Info

Publication number: CN117319166A
Application number: CN202311230795.0A
Authority: CN
Inventors: 张利利; 杨海槟; 唐子坚
Original assignee: Shenzhen Sidit Technology Co ltd
Current assignee: Shenzhen Sidit Technology Co ltd
Priority date: 2023-09-21
Filing date: 2023-09-21
Publication date: 2023-12-29

Abstract

The present invention relates to the field of communications technologies, and in particular, to an access network device management method and a computer device. In the access network equipment management method, the access network equipment can subscribe a push-down management theme to the message middleware, and the NMS sends a push-down management message to the message middleware on the push-down management theme, so that the message middleware pushes the push-down management message to the access network equipment subscribed to the push-down management theme, the communication between the NMS and the access network equipment is realized, and the NMS manages the access network equipment. The management scheme realizes decoupling of the access network equipment and the NMS, so that the deployment positions of the NMS and the access network equipment are not bound, the NMS and the access network equipment can be deployed in different networks, the NMS is not limited to managing equipment in a certain local area network, a plurality of access network equipment in different networks can be managed at the same time, the decoupling of the access network equipment and the NMS on deployment is realized, and the management scene of the NMS to the access network equipment is enriched.

Description

Access network equipment management method and computer equipment

Technical Field

The present invention relates to the field of communications technologies, and in particular, to an access network device management method and a computer device.

Background

In the related art, management of access network devices is generally implemented based on a C/S (Client/Server) architecture: the network management system is installed on the management terminal, the managed access network equipment is in communication connection with the network management system and performs management communication based on adopting SNMP (Simple Network Management Protocol ), for example, the access network equipment receives command messages sent by the network management system based on the SNMP, responds to the command messages based on the SNMP, and the access network equipment actively reports equipment data to the network management system based on the SNMP.

In the above management scheme, because of the limitation of SNMP, the management terminal for installing the network management system and the managed access network device are required to be located in the same local area network, which results in tight coupling between the network management system and the access network device, and severely limits the management scenario of the access network device for the network management system.

Disclosure of Invention

In order to solve the problem that a network management system in the related art is limited in management scene of access network equipment, the application provides an access network equipment management method and computer equipment.

In a first aspect, the present application provides an access network device management method, where the access network device management method includes:

Subscribing a plurality of push-down management topics to a message middleware, wherein the message middleware is deployed in a wide area network;

receiving a push-down management message pushed by the message middleware on the push-down management topic, the push-down management message being sent by an NMS (Network Management System ) to the message middleware on the push-down management topic;

processing the push-down management message to accept management of the NMS.

By adopting the technical scheme, the access network equipment can subscribe the push-down management theme to the message middleware, and the NMS sends the push-down management message to the message middleware on the push-down management theme, so that the message middleware pushes the push-down management message to the access network equipment subscribed to the push-down management theme, the communication between the NMS and the access network equipment is realized, and the NMS manages the access network equipment. The management scheme realizes message transfer between the access network equipment and the NMS based on a message subscription/push mechanism, and realizes decoupling of the access network equipment and the NMS on a communication link, thereby being convenient for expansion of the access network equipment; moreover, because the message middleware is deployed on the wide area network, the access network equipment and the NMS only need to be in communication connection with the message middleware respectively, so that the deployment positions of the NMS and the access network equipment are not bound any more, the NMS can be deployed in different networks with the access network equipment, the NMS is not limited to managing equipment in a certain local area network, a plurality of access network equipment in different networks can be managed at the same time, decoupling of the access network equipment and the NMS in deployment is realized, and management scenes of the NMS to the access network equipment are enriched.

Optionally, the message middleware is an MQTT (Message Queuing Telemetry Transport, message queue telemetry transport protocol) Broker (middleware), and the access network device management method further includes:

generating a push-up management message;

determining a push-up management theme to which the push-up management message belongs according to a preset theme determination rule;

and sending the push management message to the message middleware on the push management topic so that the message middleware pushes the push management message to the NMS subscribed to the push management topic.

By adopting the technical scheme, based on the subscription of the NMS to the push-up management subject on the message middleware, after the access network equipment sends the push-up management message to the message middleware on the corresponding push-up management subject, the message middleware can push the push-up management message to the NMS, so that the message transmission from the access network equipment to the NMS is realized. Meanwhile, as the MQTT Broker is adopted as the message middleware, the NMS and the access network equipment can communicate with the message middleware by adopting the MQTT protocol, the development cost of the message middleware is reduced, and the popularization and the application of the access network equipment management scheme are facilitated.

Optionally, the push-down management topic is a command topic, and the push-down management message is a command message; the push-up management theme comprises at least one of a data reporting theme and a command reply theme, and the push-up management message comprises at least one of a data reporting message corresponding to the data reporting theme and a command response message corresponding to the command reply theme.

Optionally, the command theme and the data reporting theme each include a plurality of limiting fields, where the limiting fields include at least one of a device type limiting field and a domain limiting field, the device type limiting field is used to limit a device type of an access network device, and the domain limiting field is used to limit a domain to which the access network device belongs.

By adopting the technical scheme, the limiting field of the command theme and the data reporting theme can comprise at least one of a device type limiting field and a domain limiting field, so that the NMS can issue command information according to at least one of the type of the access network device and the domain to which the access network device belongs, and/or after the access network device performs data reporting through the data reporting information, data statistics is performed on at least one of the type of the access network device and the domain to which the access network device belongs, thereby realizing the type and domain division management of the access network device.

Optionally, before subscribing to the plurality of push management topics from the message middleware, the method further includes:

logging in the message middleware by adopting a registration account, subscribing the push-down authentication theme to the message middleware;

sending authentication information to the message middleware on a push-up authentication topic;

receiving access indication information pushed by the message middleware on the push-down authentication theme, wherein the access indication information is sent to the message middleware by adopting the push-down authentication theme after the authentication of the authentication information is passed by the NMS;

and re-logging in the message middleware according to the access account number and the access password carried in the access indication message.

By adopting the technical scheme, the access terminal device logs in the message middleware through the registration account in the initial stage, and after the authentication of the NMS is passed, the access network device can log in the message middleware again according to the access account number and the access password which are redistributed by the NMS for the access terminal device and receive the management of the NMS. By the method, only legal access network equipment can log in the message middleware for a long time and is managed, and the security of the NMS is improved.

Optionally, the access indication information further includes a subscription indication, and subscribing the message middleware to a plurality of push-down management topics includes:

Subscribing the push management topic indicated by the NMS to the message middleware according to the subscription indication.

By adopting the technical scheme, after the authentication of the access network equipment is passed, the NMS can indicate the theme to be subscribed by the access network equipment to the access network equipment by using the subscription indication in the access indication information, so that the appropriate push-down management theme of the subscription range of the access network equipment can be ensured, the situation that the access network equipment receives excessive and useless push-down management messages due to the too wide push-down management theme range of the subscription, the processing resources of the access network equipment are wasted, or part of useful push-down management messages are missed due to the too narrow push-down management theme range of the subscription, and the effective management of the access network equipment by the NMS is influenced.

Optionally, before the step of sending authentication information to the message middleware on the push-up authentication theme, the method further includes:

transmitting first authentication information to the message middleware on the push-up authentication theme, wherein the first authentication information comprises a unique identifier of the device and first part of data of an authentication key, the authentication key is determined based on the unique identifier, and the first part of data is obtained by dividing the authentication key;

After the verification of the first part of data by the NMS is successful, second authentication information sent on the push-down authentication subject by the message middleware is received, wherein the second authentication information comprises second part of data of the authentication key and a random code, and the second part of data is obtained by dividing the authentication key;

authenticating the second portion of data based on the authentication key;

and after the verification of the second part of data is successful, combining the random code with the unique identifier to obtain combined information, and carrying out encryption processing on the combined information to obtain the authentication information.

By adopting the technical scheme, the NMS can also authenticate the access network equipment based on the first authentication information, and the access network equipment can authenticate the NMS based on the second authentication information, so that bidirectional verification is realized between the NMS and the access network equipment, illegal equipment access can be prevented, access to an illegal management system by the access network equipment can be prevented, and the security of access network equipment management is improved.

In a second aspect, the present application provides an access network device management method, where the access network device management method includes:

A communication connection with message middleware, the message middleware deployed in a wide area network;

generating a push-down management message, and determining a push-down management subject to which the push-down management message belongs according to a preset subject determination rule; and sending the push-down management message to the message middleware on the push-down management theme so that the message middleware pushes the push-down management message to the access network equipment subscribed to the push-down management theme to manage the access network equipment.

Optionally, the access network device management method further includes:

subscribing a plurality of push-up management topics to the message middleware;

receiving a push-up management message pushed by the message middleware on the push-up management theme, wherein the push-up management message is sent to the message middleware by the access network equipment on the push-up management theme;

and processing the push-up management message.

By adopting the technical scheme, the NMS can subscribe the push-up management subject on the message middleware, and after the access network equipment sends the push-up management message to the message middleware on the corresponding push-up management subject, the message middleware can push the push-up management message to the NMS, so that the message transmission from the access network equipment to the NMS is realized. Meanwhile, as the MQTT Broker is adopted as the message middleware, the NMS and the access network equipment can communicate with the message middleware by adopting the MQTT protocol, the development cost of the message middleware is reduced, and the popularization and the application of the access network equipment management scheme are facilitated.

Optionally, the push-down management topic is a command topic, the push-down management message is a command message, and the generating the push-down management message includes:

Receiving a management instruction sent by a web browser;

and generating command information according to the management instruction, wherein the command information comprises a session identifier, a command reply theme indication, an operation object indication and an operation parameter indication.

Optionally, the push-up management topic includes a command reply topic, the push-up management message includes a command response message, and receiving the push-up management message pushed by the message middleware on the push-up management topic includes:

receiving the command response message pushed by the message middleware on the command reply theme, wherein the command response message comprises a session identifier and a response code;

inquiring a userkey (user key) corresponding to the command response message from a redis (remote dictionary service) server;

and transmitting the command response message to the Web browser according to the userkey.

Optionally, the push-up management topic includes a data reporting topic, the push-up management message includes a data reporting message, and receiving the push-up management message pushed by the message middleware on the push-up management topic includes:

receiving the data reporting message pushed by the message middleware on the data reporting theme, wherein the data reporting message comprises reporting data;

And processing the reported data.

In a third aspect, the present application provides a computer device comprising a processor, a memory and a communication bus for implementing a communication connection between the processor and the memory, the memory having stored therein at least one of a first computer program and a second computer program, the first computer program being executable by the processor for implementing the access network device management method of any of the preceding first aspects; the second computer program is executable by the processor to implement the access network device management method of any of the preceding second aspects.

In a fourth aspect, the present application further provides a computer readable storage medium, which adopts the following technical scheme:

a computer readable storage medium storing at least one of a first computer program and a second computer program, the first computer program being executable by a processor to implement the access network device management method of any one of the preceding first aspects; the second computer program is executable by the processor to implement the access network device management method of any of the preceding second aspects.

By adopting the technical scheme, a carrier of a computer program of an access network equipment management method is provided.

In summary, the present application includes at least the following beneficial technical effects: the decoupling between the access network equipment and the NMS is realized, so that the NMS is not limited to be deployed in a local area network where the access network equipment is located, and is not limited to only manage the access network equipment in one local area network, the NMS can manage the access network equipment which is in different networks with the NMS, and a plurality of access network equipment in different local area networks are managed, so that the access network equipment management scene is greatly enriched.

Drawings

Fig. 1 is a schematic diagram of access network device management in the related art according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a management system according to an embodiment of the present application;

fig. 3 is a schematic interaction flow diagram of an access network device management method according to an embodiment of the present application;

fig. 4 is a schematic diagram of another interaction flow of the method for managing access network devices according to an embodiment of the present application;

FIG. 5 is another schematic diagram of a management system according to an embodiment of the present application;

FIG. 6 is yet another schematic diagram of a management system provided in an embodiment of the present application;

Fig. 7 is a schematic diagram of an interaction flow for transmitting command messages and command response messages between an access network device and an NMS according to one embodiment of the present application;

fig. 8 is a schematic diagram of an interaction flow for transmitting a data report message between an access network device and an NMS according to an embodiment of the present application;

fig. 9 is a schematic diagram of an interaction flow of an authentication registration phase in an access network device management scheme according to an embodiment of the present application;

fig. 10 is a schematic diagram of a hardware structure of a computer device according to an embodiment of the present application.

Reference numerals illustrate:

10-EMS (Element Management System, network element management system); 11-EMS server side; a 12-EMS client; 2-a management system; 20-an access network device; 30-NMS; 40-message middleware; 50-a computer device; 51-a processor; 52-a memory; 53-communication bus.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

An access network refers to a network of all devices between a backbone network and a user terminal, which is typically hundreds of meters to several kilometers in length, and is thus visually referred to as the "last kilometer". Depending on the transmission medium, access networks can be divided into two main categories, wired access networks and wireless access networks. Radio access networks are classified into two types, namely a fixed radio access network and a mobile radio access network, and wired access networks are classified into two types, namely a copper wire access network and an optical fiber access network. The optical fiber access network is a high-speed and high-bandwidth communication technology in the communication field, uses an optical fiber as a transmission medium to convert signals into optical signals for transmission, and the application fields of the optical fiber access network comprise a home broadband, an enterprise network, a campus network, an urban broadband and the like. The optical fiber access network has the following characteristics and advantages:

1. The high speed and the high bandwidth can provide a rapid and stable network connection speed, and support more users to access the network simultaneously;

2. the optical fiber is used for transmitting data, so that the communication quality is higher, and the network is more stable;

3. the security is higher, and the data transmitted by the optical fiber cannot be intercepted or disturbed;

4. communication cost is reduced;

5. multimedia is supported.

The access network device refers to a local side device in an access network, such as a fiber optic access network device, and in this embodiment, the access network device includes, but is not limited to, a router, a switch, a fiber optic transceiver, a fiber optic modem, and the like.

To facilitate the management of access network devices by users, corresponding management software, such as EMS, is typically developed by the manufacturer of the access network device and then provided to the user side for installation. Referring to fig. 1, an EMS10 adopts a C/S architecture, where the EMS10 includes an EMS server 11 and an EMS client 12, both of which are installed on a management terminal of a user, the EMS server 11 is communicatively connected to an access network device 20, and the EMS client 12 is simultaneously in communication with the EMS server 11, so that an administrator can manage the access network device 20 through the EMS client 12 running on the management terminal, for example, issue a configuration to the access network device 20, instruct the access network device 20 to restart, inquire about a state of the access network device 20, and the like.

In the management scheme of the access network device 20 based on the EMS10, SNMP communication is adopted between the EMS server 11 and the access network device 20, and SNMP is a protocol for managing network devices, through which an administrator can obtain information such as an operation state of the device, a processor and memory use condition, a network bandwidth utilization rate, and the like, and perform configuration management and fault removal on the device. SNMP has the advantages of simplicity, ease of use, wide application range, etc., but it also has obvious drawbacks: SNMP can only be used in a Local Area Network (LAN) and cannot support communication across networks, so if the EMS10 is to manage the access network device 20, the EMS10 can only be deployed in the LAN where the access network device 20 is located, which severely limits a management scenario of the access network device 20 on the user side, for example, a manager cannot remotely manage the access network device 20, and at the same time, the manager cannot manage the access network device 20 in a different LAN through the same EMS 10.

In order to solve the technical problem existing in the management scheme of the access network device 20, the present embodiment first provides a management system 2 based on the MQTT protocol, please refer to fig. 2: the management system 2 comprises an NMS30, message middleware 40 and several managed access network devices 20.NMS30 is communicatively coupled to access network device 20 with message middleware 40, respectively. Since the message middleware 40 is deployed in the wide area network, and the NMS30 and the access network device 20 only need to communicate with the message middleware 40 respectively, the deployment of the NMS30 and the access network device 20 is no longer associated and bound, and the NMS30 and the access network device 20 are no longer limited to the same local area network.

In some examples of this embodiment, NMS30 and access network device 20 communicate with message middleware 40 using MQTT protocol, respectively, message middleware 40 being MQTT Broker. The MQTT protocol is a "lightweight" communication protocol based on subscription/push (TCP/IP) mode, which builds on TCP/IP (Transmission Control Protocol/Internet Protocol ). The MQTT has the greatest advantages that the MQTT can provide real-time reliable message service for remote connection equipment with few codes and limited bandwidth, and is used as an instant communication protocol with low cost and low bandwidth occupation, so that the MQTT has wider application in the aspects of Internet of things, intelligent home, small equipment, mobile application, industrial automation and the like, and particularly in the fields with low bandwidth and unreliable network environment. The main characteristics of the MQTT protocol include: 1. lightweight class: the method has the characteristics of low cost and small message, and can realize efficient communication under limited capacity;

2. the reliability is as follows: support multiple QoS (Quality of Service ) classes, session awareness and persistent connections, ensuring reliable delivery of messages even under high latency or connection instability conditions;

3. Secure communication: TLS (Transport Layer Security ) and SSL (Secure Socket Layer, secure sockets layer) encryption functions are provided on the one hand, and authentication and authorization mechanisms are also provided by user name/password credentials or client certificates to protect access to the network and its resources on the other hand;

4. two-way communication: the publish/subscribe mode provides a seamless two-way communication between devices without directly coupling the devices together. The integration of new equipment is simplified, and meanwhile, the system is ensured to be easy to expand;

5. continuous, stateful session: the ability to maintain a state session between the MQTT client and the MQTT Broker is provided, which allows the system to keep track of subscribed and undelivered messages even after a disconnect. The MQTT client can also specify a keep-alive interval when establishing the connection that will cause the MQTT Broker to periodically check the connection status. If the connection is broken, the MQTT Broker stores the undelivered messages (determined by QoS level) and attempts to deliver them when the MQTT client reconnects. This feature ensures reliability of the communication and reduces the risk of data loss due to intermittent connections.

However, it will be appreciated by those skilled in the art that in other examples of the present embodiment, the communication between the message middleware 40 and the access network device 20 and the NMS30 may be implemented by other communication methods, such as a newly developed new protocol.

Communication between access network device 20 and NMS30 is effected based on a subscription/push mechanism of message middleware 40, so that access network device 20 and NMS30 need to subscribe to message middleware 40 for one or several topics after being communicatively connected to message middleware 40. The topic (topic) is the basis for the message middleware 40 to implement message passing between the access network device 20 and the NMS30, and the topic of a message allows the message middleware 40 to determine how to push the message and determine the range of recipients of the message. For any one client (including NMS30, access network device 20), a push for a subject message will not be received until the message middleware 40 is subscribed to the corresponding subject. The subject is therefore a bridge or pathway for communication between the NMS30 and the access network device 20.

It will be appreciated that in the management system 2, a part of the messages are sent to the NMS30 by the access network device 20, and another part of the messages are sent to the access network device 20 by the NMS30, in order to distinguish between these two types of messages, in this embodiment, the messages are distinguished by "push down" and "push up" according to the difference of the transmission directions of the messages, where the push down message is a message pushed toward the access network device 20, that is, a message that the receiving end is the access network device 20; the push-up message is a message pushed toward the NMS30, i.e. a message that the receiving end is the NMS 30. Correspondingly, the theme used for realizing the transmission of the push-down message is a push-down theme, and the theme used for realizing the transmission of the push-up message is a push-up theme.

In addition, according to the difference of the acting phases of the topics, the NMS30 in this embodiment also divides the messages involved in the formally managing phase of the access network device 20 into "management messages", the topics corresponding to the management messages are "management topics", and the topics playing other roles in other phases are not management topics, for example, the topics involved in the registration and authentication phases can be divided into "authentication topics", and the messages transmitted by the authentication topics are authentication messages.

From the foregoing description, it should be understood by those skilled in the art that "push down management topic" is a topic of pushing a message sent by the NMS30 in the management phase to the access network device 20 side, where the pushed message is a push down management message; the "push-up management topic" refers to a topic of pushing a message sent by the access network device 20 in the management stage to the NMS30 side, where the pushed message is a push-up management message; similarly, "push-up authentication topic" refers to a topic that pushes a message sent by the access network device 20 in the authentication phase to the NMS30 side, where the message pushed by the push-up authentication topic belongs to the push-up authentication message; "push-down authentication topic" is a topic that pushes a message sent by the NMS30 in the registration authentication phase to the access network device 20 side, where the pushed message belongs to the push-down authentication message.

It will be appreciated that both the push-down topic and the push-up topic, or the management topic and the authentication topic, are broad classes of topics, and under such broad classes of topics, multiple refinement topics may also be included, and in general, in order to ensure that only push-down management messages related to themselves are received, no unwanted push-down management messages unrelated to themselves are received, the push-down management topic subscribed to by the client towards the message middleware 40 is a refinement topic therein, rather than the push-down management topic being the entire broad class of topics. The topic may be refined by defining fields, each defining field embodying an attribute feature of the message: for example, a restriction field may be used to characterize the type of access network device 20 to which the message corresponds, a restriction field may be used to characterize the domain to which the access network device 20 to which the message corresponds belongs, and so on. The push-down management subject subscribed to by the client in this embodiment includes a plurality of limited fields. Taking the MQTT protocol as an example, it supports adding limited fields with "/", and realizes the increase of theme hierarchy, thus realizing the refinement of the theme, for example, assuming that one theme includes N hierarchies, its basic format is "limited field 1/limited field 2/limited field 3/…/limited field N", the MQTT Broker starts matching from the leftmost limited field when matching the theme of the message to be pushed with the theme subscribed by each MQTT client. Meanwhile, the MQTT protocol also supports wildcards, and when one limiting field is the wildcard, the matching of the definition field and the wildcard is considered successful no matter what the content of the limiting field corresponding to the wildcard is. Typically, at least one of "#" and "#" may be selected as the wildcard, where "#" may be used to match one hierarchy, and "#" may match multiple hierarchies.

In some examples of this embodiment, the management system 2 supports three basic topics, namely a Report Topic (Report Topic), a command Topic (Operation Topic) and a Response Topic (Response Topic), where the data Report Topic is used for the access network device 20 to actively Report data to the NMS30 and is used for transferring a data Report message; the command theme is used for the NMS30 to issue commands to the access network device 20 for delivering command messages; the command reply topic is used by the access network device 20 to respond to commands from the NMS30 for delivering command response messages.

For the three basic topics described above, the present embodiment provides a corresponding topic format:

(1) Format definition of data reporting theme:

report/<application>/<device_type>/<dt-type>/<region>/<source-id>/<session-id>

wherein the "report" limit field indicates that the basic topic category is the data reporting topic.

An "application" restriction field, an application identification, indicating the software program that manages access network device 20 is the actual point of receipt of the subject message, such as in some examples the restriction field may be filled with an "NMS" indicating that the message is transmitted to NMS 30; or in some examples the defined field may also be filled with an identification of the microservices in NMS30, indicating that the message is transmitted to a particular microservice in NMS 30.

The "dt-type" defines a field, data type indication, e.g., alert information (trap), performance statistics (performance), registration to management software (register).

The "region" defines a field that indicates the domain to which access network device 20 belongs, e.g., in some examples the domain to which access network device 20 belongs may be determined based on its regional routing information.

A "source-ID" limit field, the source ID indicates, for example, a unique identifier of the access network device 20, such as at least one of a MAC (Media Access Control Address ) and a SN (serial number) of the access network device 20, which may be filled in the limit field, for the access network device 20 that sends the data report message.

The session-id defines a field, a session identifier, ensures uniqueness, and can adopt UUID (Universally Unique Identifier, universal unique identification code) for preventing repeated processing of the message, message coverage and idempotent processing of a service system.

(2) Format definition of command theme:

opt/<application>/<device_type>/<opt-type>/<region>/<destination-id>/<session-id>

wherein, the "opt" defines a field indicating that the basic subject class is a command subject or a command reply subject.

The "device_type" defines a field, a device type indication, for indicating a device type of the access network device 20, such as a router type, a switch type, etc.

An "opt-type" limit field, a command type indication, for indicating the type of command, for example, the command includes an add command, a delete command, a set command, a get command, a reboot command, an upgrade command, an auth command, a reconnect command, and the like.

The "destination-id" defines a field, the target recipient of the message, which may be the access network device 20, or the NMS30, or a microservice in the NMS 30.

(3) Format definition of command reply topic:

opt/<application>/res/<session-id>

wherein, the 'res' limit field adopts a fixed value to express that the message is a command response message for replying the command message;

the "session-id" defines a field, session identifier, in which the value of the session-id in the command response message is consistent with the value of the session-id in its corresponding command message.

It can be understood that the topic classification of the push topic and the push topic is two different classification dimensions from the topic classification of the data report topic, the command topic and the command reply topic. From the topic to the message transmission direction, the command topic belongs to the push topic, and the data reporting topic and the command reply topic belong to the push topic.

The following describes the message body (Payload) of the message corresponding to the three basic topics:

(1) The message body of the data report message comprises the client identification and the data content.

For example, in the case where the message middleware 40 is an MQTT Broker, the pseudocode of one data report message is as follows: {

The # must be filled, the client id (client id) of the access network device 20 when connected to the MQTT Broker as an MQTT client, typically the unique id of the access network device 20

"clientld":"xxxxxxx",

Data content sent by # access network device to NMS

In the message body of the data report message, the data report message sent by the access network device 20 contains the data with the MAC address of "AA: BB: CC: DD: EE: FF", the serial number of "AF2101-160160001", and the software version of "V1.0.0_230724".

(2) The message body of the command message comprises a client identifier, a session identifier, a command reply theme indication, an operation object indication and an operation parameter indication.

For example, in the case where the message middleware 40 is an MQTT Broker, the pseudocode of one command message is as follows:

{

# must be filled, in which case the NMS may be filled with "NMS" as the MQTT client connected to the MQTT Broker "

"clientld":"nms",

# must fill, when the current message requires the processor to provide the processing result after processing is completed, specify the result topic

# session-id: session-id in the same topic

"topic":"opt/nms/res/session-id",

# must be filled in to indicate the number of the operation module, which is hexadecimal 4-byte string

"object":"0x01020000",

# must fill in, NMS issues parameters to device

In the message body of the command message, "attribute" is an operation parameter indication, and "object" is an operation object indication, in order for the NMS30 to indicate an operation object to the access network device 20, an operation object indication table may be set in the NMS30 and the access network device 20, a mapping relationship between each operation object and the operation object indication is stored in the operation object indication table, according to the operation object indication table, the NMS30 may determine what the operation object indication corresponding to the operation object to be indicated is, and after receiving the command message, the access network device 20 may also determine what the operation object indication corresponding to the operation object indication is in the command message. In table 1, a router is taken as an example of the access network device 20, and a corresponding operation object instruction table is shown:

TABLE 1

(3) The message body of the command response message contains the client identification, the session identifier, the response code, and can also contain data content.

{

The # must be filled, the clientId of the access network device 20 when connected to the MQTT Broker as an MQTT client is typically the unique identity of the access network device 20

"cliented": unique identification of device ",

"must fill

"sessionId":"sessionId",

# must be filled in that when the device provides the message publisher with the processing result, the message body should contain this item

In the message body of the command response message, the "code" refers to response codes, each of which describes a response situation to a command message, in order for the access network device 20 to report the response situation to the NMS30, a response code indication table may be set in the NMS30 and the access network device 20, and a mapping relationship between each response code and the return value, and between the response code descriptions is stored in the response code indication table, as shown in table 2. The access network device 20 may determine the corresponding response code according to the return value obtained when processing the command message by itself and combine with the response code indicator table and carry the response code in the command response message, and send the response code to the NMS30 through the MQTT Broker, and after receiving the command response message, the NMS30 may query the response code indicator table according to the response code therein, so as to determine the processing result of the access network device 20 on the corresponding command message.

TABLE 2

It should be appreciated that the description of the mandatory and optional padding in the pseudocode of the above-described messages is for the application MQTT protocol scenario, so the mandatory and optional padding may be different from the description above if the message middleware 40 communicates with the access network device 20, NMS30 not based on the MQTT protocol.

Based on the foregoing description of the management system 2 and the topics and messages, an access network device management method is provided below, and please refer to an interactive flow chart of the access network device management method shown in fig. 3:

s302: the access network device and the NMS are respectively connected with the message middleware in a communication way.

The access network device 20 and the NMS30 are respectively connected to the message middleware 40 and are in communication connection with the message middleware 40. For example, the access network device 20 is connected to an MQTT Broker and the NMS30 is also connected to the MQTT Broker.

S304: the access network device subscribes to a number of push-down management topics from the message middleware.

To ensure that messages from NMS30 can be received, access network device 20, in this embodiment, after connecting to message middleware 40, subscribes to message middleware 40 to a number of push management topics. It will be appreciated that the number of push management topics subscribed to by access network device 20 includes refined command topics.

In some examples of this embodiment, access network device 20 may determine from preset topic determination rules which topics it needs to subscribe to when it is under the management of NMS30 and complete the subscription to message middleware 40. In still other examples, access network device 20 may obtain, from NMS30 side, the topics that it needs to subscribe to during the management phase through message middleware 40 during the registration authentication phase, i.e., access network device 20 may push down the subscriptions of the management topics according to the direction of NMS 30.

S306: the NMS generates a push-down management message and determines the push-down management subject to which the push-down management message belongs according to a preset subject determination rule.

When a management message, such as a command message, needs to be sent to the access network device 20, the NMS30 generates a push-down management message, i.e., a command message, and then determines the push-down management topic to which the generated command message belongs according to a preset topic determination rule.

In order to ensure that the NMS30 and the access network device 20 can perform management communication normally, or to ensure that the message sender performs management message sending on a management topic subscribed by the message receiver, it is ensured that the message receiver subscribes in advance to a management topic adopted by the message sender to send a management message, and in some examples of this embodiment, the NMS30 and the access network device 20 may agree in advance to use the same preset topic determination rule. The agreement between the two may be implemented by a developer setting up the access network device 20, NMS30, e.g. by presetting the preset theme determination rules in the access network device 20 during the production phase of the access network device 20, and by presetting the preset theme determination rules in the NMS30 during the development or upgrade phase of the NMS 30. In other examples of this embodiment, the synchronization of the preset theme determination rule with the access network device 20 during the authentication registration phase by the NMS30 may also be implemented, for example, the preset theme determination rule may be generated by the NMS30 under the direction of an administrator or generated by the NMS30 according to a negotiation with the access network device 20, and then the NMS30 transmits the generated preset theme determination rule to the access network device 20. The access network device 20 may determine, according to a preset topic determination rule, which push-down management topics to subscribe to by itself in the management stage, and determine, according to the preset topic determination rule, a push-up management topic corresponding to the push-up management message when the push-up management message needs to be sent to the NMS 30.

S308: the NMS sends a push management message to the message middleware on the push management topic.

After determining the corresponding push-down management topic of the push-down management message according to the preset topic determination rule, the NMS30 may send the push-down management message to the message middleware 40 on the corresponding push-down management topic, so that the message middleware 40 performs message push to the corresponding access network device 20 according to the push-down management topic to which the message middleware belongs after receiving the push-down management message.

S310: the access network device receives a push-down management message pushed by the message middleware on a push-down management theme.

Because access network device 20 has previously subscribed to message middleware 40 for the corresponding push management topic, when message middleware 40 receives a push management message from NMS30, it sends the push management message to access network device 20.

S312: the access network device processes the push-down management message to accept management of the NMS.

Access network device 20 may consume the push-down management message from message middleware 40, i.e., receive the push-down management message from message middleware 40, and parse the push-down management message, e.g., perform an action indicated by NMS30 in the push-down management message.

Having described the procedure for transmitting push-down management messages between NMS30 and access network device 20 in the above example, the procedure for transmitting push-up management messages between access network device 20 and NMS30 is described below in connection with fig. 4:

s402: the access network device and the NMS are respectively connected with the message middleware in a communication way.

It is clear that before the access network device 20 sends a message to the NMS30 via the message middleware 40, it must be ensured that both the access network device 20, the NMS30 have established a connection with the message middleware 40, i.e. that both the access network device 20, the NMS30 are in a state of being communicatively connected to the message middleware 40, but this does not require that both the access network device 20, the NMS30 have re-established a connection with the message middleware 40, respectively, before each message transmission.

S404: the NMS subscribes to a number of push management topics with the message middleware.

To ensure that messages from access network device 20 can be received, NMS30, in this embodiment, after connecting to message middleware 40, subscribes to message middleware 40 to a number of push management topics. The push management topics to which the NMS30 subscribes may include at least one of data reporting topics and command reply topics, and typically, the NMS30 subscribes to the message middleware 40 for refinement of several data reporting topics and refinement of several command reply topics. In the case where only one NMS30 is provided in the management system 2, the NMS30 may directly subscribe to two general classes of topics, namely, a data report topic and a command reply topic, and after all, all the data report messages and command response messages sent by the access network device 20 are sent to the NMS 30.

In some examples of this embodiment, NMS30 may determine from preset topic determination rules which topics it needs to subscribe to when managing access network device 20 and complete the subscription to message middleware 40.

S406: the access network equipment generates a push-up management message and determines the push-up management subject to which the push-up management message belongs according to a preset subject determination rule.

When the NMS30 needs to send a push-up management message to the access network device 20, it generates a push-up management message, such as a data report message or a command response message, and then determines, according to a preset topic determination rule, the push-up management topic to which the generated push-up management message belongs.

S408: the access network device sends a push-up management message to the message middleware on the push-up management topic.

After determining the push-up management topic to which the push-up management message belongs, the access network device 20 may send the push-up management message to the message middleware 40 on the corresponding push-up management topic, so that the message middleware 40 performs message push to the NMS30 according to the push-up management topic to which the push-up management message belongs after receiving the push-up management message.

S410: the NMS receives push-up management messages pushed by the message middleware over push-up management topics.

Because NMS30 has subscribed to the message middleware 40 in advance for the corresponding push management topic, when message middleware 40 receives a push management message from access network device 20, it sends the push management message to NMS 30.

S412: the NMS processes the push-up management message to manage the access network device.

NMS30 may consume the push-up management message from message middleware 40, i.e., receive the push-up management message from message middleware 40, and parse the push-up management message.

It will be understood by those skilled in the art that the two processes of transmitting the push-down management message between the NMS30 and the access network device 20 and transmitting the push-up management message between the access network device 20 and the NMS30 are not strictly sequential, and the push-down management message may be transmitted first, the push-up management message may be transmitted first, or the push-up management message and the push-down management message may be transmitted simultaneously.

The following description of the management system 2 and the access network device management method is continued by taking the MQTT Broker as the message middleware 40:

please refer to a schematic diagram of a management system 2 shown in fig. 5:

the device set includes a plurality of access network devices 20, e.g., device a, device B, device C … …, and these access network devices 20 may be different types of devices, e.g., routers, switches, etc.

MQTT Broker there are a number of models, e.g., EMQX1, EMQX2 … EMQX N may be selected for MQTT Broker type according to specifications, budget, etc., and in some examples, MQTT broadcasters of free version of EMQX may be selected for installation, deployment, and use.

The NMS30 may include a plurality of micro services therein, each of which may be used to independently manage a portion of the access network devices 20, e.g., micro service a is used to manage access network devices 20 with domain identification "1" and micro service b is used to manage access network devices 20 … … with domain identification "2"; or micro service a is used for access network device 20 of which device type is a router, micro service b is used for managing access network device 20 … … of which device type is a switch, in some other examples, each micro service is responsible for part of the management traffic of access network device 20, for example micro service a is used for implementing configuration management of all access network devices 20, micro service b is used for implementing monitoring management of performance of access network device 20, and micro service c is used for implementing monitoring management of status of access network device 20.

The MQTT Broker may conduct the transfer of messages between the access network device 20 and the NMS30 on a topic basis.

In some examples, to alleviate the processing pressure of the MQTT Broker, to reduce the requirements on the processing performance of the MQTT Broker, a message queue, rock MQ, may be further provided in the message middleware 40 for message caching, as shown in fig. 6, so that the MQTT Broker may extract a message from the rock MQ and consume the message based on its processing capability.

In the present embodiment, since the deployment of the NMS30 is not limited by the deployment location of the access network device 20, the NMS30 may be deployed in a different network from the access network device 20, and the NMS30 may manage the access network devices 20 within a plurality of local area networks at the same time. In this case, only one NMS30 may be set for management of access network devices 20 of different clients, and the NMS30 may be operated and maintained by a device provider, for example, the device provider deploys the NMS30 on a server, the NMS30 connects all access network devices 20 provided by the device provider through message middleware 40, such as MQTT Broker, for each user using the devices provided by the device provider, the device provider may assign account numbers to them, and let the user log into the NMS30 through the assigned account numbers to manage the access network devices 20 owned by the user.

In some examples of this embodiment, the user may log in to the NMS30 through a Web browser, so that the user side does not need to install a client of the NMS30, and the user may log in to the NMS30 through any Web browser at any time and any place, and implement management on his own access network device 20, which enriches the management scenario of the access network device 20 and facilitates the user; meanwhile, since the NMS30 is operated and maintained by the device provider side, the upgrade of the NMS30 and the access network device 20 does not need user processing, which reduces the capability threshold of the user and is beneficial to improving the market competitiveness of the access network device 20.

In the following description of the process in which the NMS30 sends a command message and a command response message to the access network device 20, it should be understood that the access network device 20 should subscribe to a corresponding command topic before the NMS30 transmits the command message to the access network device 20, and the NMS30 needs to subscribe to the corresponding command reply topic in advance. See fig. 7 below:

s702: the Web browser sends a management request to the NMS.

The management request may be an HTTP (Hypertext Transfer Protocol ) request, which includes a request header and a request body, wherein the request header includes a token and a session identifier, and the request body includes data, which may be generated according to an instruction issued by a user.

NMS30 may receive management requests from a Web browser through a Restful (REST (Representational State Transfer, representational state transfer) architectural style) interface.

S704: the NMS processes the management request, encapsulates the management request into a command message, and determines a push-down management subject to which the command message belongs.

In some examples of this embodiment, the NMS generated command message may be a JSON (JavaScript Object Notation, JS object profile) string. As to the format of the command message, since it has been described in more detail above, specific details of the generation of the command message by the NMS30 according to the management request will not be described here. Those skilled in the art will appreciate that the command message generated by the NMS30 need not necessarily be generated in response to a Web browser-side management request, but may be generated in response to its own management requirements.

In addition, the NMS30 may determine, according to a preset theme determination rule, a push-down management theme to which the command message belongs, and in this embodiment, the command message belongs to the command theme, which may be "opt/NMS/device_type/set/region/device-id/session-id".

S706: the NMS sends command information to the MQTT Broker through the determined push-down management theme.

In some examples NMS30 may employ a process of Send Message To Rocket (send message to a token message queue) to send command messages to the token MQ. And the MQTT Broker extracts the command message from the rock MQ according to the processing process to process.

S708: the MQTT Broker pushes the command message on the corresponding push-down management topic.

S710: the access network device processes the command message.

After receiving the command message, the access network device 20 analyzes and executes the corresponding command, and if the command message indicates the access network device 20 to perform configuration, the access network device 20 can perform configuration according to configuration information carried in the command message; if the command message indicates that the access network device 20 reports its current resource occupancy, it may perform resource occupancy collection and then generate resource occupancy reporting information to respond to the NMS 30.

S712: the access network device generates a command response message and determines the push-up management subject to which the command message belongs.

After parsing the command message, the access network device 20 needs to feed back its own response to the command message to the NMS30, so the access network device 20 may encapsulate the response result to the command message into a command response message. The specific data content carried in the command response message is related to the command message, for example, if the command message contains configuration information, the command response message carries a configuration result of the access network device 20; if the command message contains a query instruction, the command response message carries the query result of the access network device 20. For the format of the command response message, please refer to the foregoing description, and the description is omitted herein.

The access network device 20 may determine the corresponding topic for the command response message, e.g., the topic corresponding to the command response message may be "opt/nms/res/session-id".

S714: and the access network equipment sends a command response message to the MQTT Broker through the determined push-up management theme.

The access network device 20 may first send a command response message to the rock MQ, causing the MQTT Broker to consume the command response message from the rock MQ. In some examples, the access network device 20 may also send the command response message directly to the MQTT Broker.

S716: the MQTT Broker pushes the command response message on the corresponding push-up management topic.

S718: the NMS processes the command response message.

After the NMS30 receives the command response message pushed by the MQTT Broker, the command response message may be parsed, for example, the NMS30 may obtain a session identifier from a theme corresponding to the command response message, and in addition, the NMS30 may query a userkey corresponding to the command response message from the redis server.

S720: the NMS feeds back the management result to the Web browser.

The NMS30 may transfer the message body of the command response message to the Web browser according to the queried userkey, for example, the NMS30 invokes the feign (declarative, templated HTTP client developed by Netflix) to transfer the message body to the Web browser, and a Web Socket protocol may be used between the NMS30 and the Web browser.

In the following description of the process in which the access network device 20 sends a data reporting message to the NMS30, it should be understood that the NMS30 needs to subscribe to the corresponding data reporting topic in advance before the access network device 20 transmits the data reporting message to the NMS 30. See fig. 8 below:

s802: the access network equipment generates a data reporting message and determines a push-up management theme corresponding to the data reporting message.

The data report message generated by the access network device 20 may be at least one of an alarm message, a performance acquisition message, and a registration online message, where in some examples, the data report message is an alarm message, and the corresponding refined data report topic may be "report/nms/+/trap/#"; in some examples, the data reporting message is a performance acquisition message, and the corresponding refined data reporting topic may be "report/nms/+/performance/#"; in other examples, the data report message is a registration online message, and the corresponding refined data report topic may be "report/nms/+/register/#".

S804: and the access network equipment sends a data reporting message to the MQTT Broker through the determined push-up management theme.

The access network device 20 may first send the data report message to the router MQ, so that the MQTT Broker consumes the data report message from the router MQ. In some examples, the access network device 20 may also send the data report message directly to the MQTT Broker.

S806: and the MQTT Broker pushes the data reporting message on the corresponding push-up management theme.

S808: the NMS processes the data report message.

After the NMS30 receives the data report message through subscription, it firstly analyzes the message, and then processes the message according to the service logic, if the message needs to be displayed on the Web page in time, it can use the Web Socket or other modes to push the message body of the data report message to the Web browser. Of course, if the Web page does not need to be displayed, the message body does not need to be transferred to the Web browser.

S810: the NMS transmits the message body of the data report message to the more Web browser.

NMS30 may invoke the feign to pass the message body of the data report message to the Web browser, and Web Socket protocol communication may be employed between NMS30 and the Web browser.

It should be appreciated by those skilled in the art that, in order to prevent the management system 2 from being attacked and tampered, the present embodiment provides a registration scheme capable of improving the communication security of the access network device 20 and the NMS30, where the registration scheme may enable the NMS30 to authenticate the access network device 20 when the access network device 20 registers, and in some examples may enable the access network device 20 to authenticate the NMS30, and only after authentication is passed, the access network device 20 accesses the NMS30 through the MQTT Broker:

the access network device 20 and the NMS30 are connected to the MQTT Broker in the roles of MQTT clients, so they need to use corresponding accounts to log in the MQTT Broker, in some examples of this embodiment, the access network device 20 and the NMS30 may store account information of the MQTT client in advance, for example, a developer writes account information including an access account number and an access password in the access network device 20 and the NMS30 in advance, and in this case, the access network device 20 may log in the MQTT Broker directly with the pre-stored account information after being powered on and the NMS30 is started. In other examples of this embodiment the account information of the NMS30 may be obtained in a preconfigured manner, whereas the account information of the access network device 20 is assigned by the NMS 30. For example, in some examples, the access network device 20 may first access the MQTT Broker using a registration account after power-up, accept authentication by the NMS30 through the MQTT Broker, after authentication is passed, the access network device 20 may receive long-term account information assigned to it by the NMS30, and then it may log onto the MQTT Broker using the long-term account information, and accept management by the NMS 30. Since the registered account is only a temporary account, if the access network device 20 fails to authenticate with the NMS30, it can only disconnect from the MQTT Broker and can no longer communicate with the NMS30 and be managed.

The following describes the procedure for the access network device 20, NMS30 to communicate with the MQTT Broker, respectively, in connection with fig. 9:

s902: the access network device adopts a registration account to log in the MQTT Broker, and pushes down an authentication theme to the MQTT Broker subscription; the NMS logs in the MQTT Broker and pushes up authentication topics to the MQTT Broker subscription.

In some examples of this embodiment, the access network device 20 may use a temporary account to log into the MQTT Broker after power-up, e.g., to allow the access network device 20 to communicate with the NMS30 before formally accessing the NMS30 and accepting management from the NMS30, in some examples, the MQTT Broker may assign a registration account to the access network device 20 that is used temporarily during the authentication registration phase. After the access network device 20 is powered up, it logs in to the MQTT Broker using the access account number and the access password in the registration account, and subscribes to the MQTT Broker to push down the authentication topic, for example, the push down authentication topic of its subscription may be "opt/nms/device_type/auth/clientId". In one example, the access network device 20 may access the MQTT Broker as follows: the access network device 20 sends a connection request to the MQTT Broker, the MQTT Broker sends a CONNACK (acknowledge connection request) response to the access network device 20, then the access network device 20 sends a registration account number and a registration password to the MQTT Broker, the MQTT Broker verifies the correctness of the registration account number and the registration password, if correct, sends an AUTH (authentication) response, and otherwise sends a DISCONNECT response.

Correspondingly, after the NMS30 is started, it is also required to access the MQTT Broker as an MQTT client, and the NMS30 may push up the authentication topic to the MQTT Broker subscription in order to receive the message sent by the access network device 20 in the registration authentication phase. In some examples, the push-up authentication topic subscribed to by the NMS30 to the MQTT Broker is a data topic, which may be "report/NMS/device_type/register", for example. In one example, the NMS30 may access the MQTT Broker as follows: the NMS30 sends a connection request to the MQTT Broker, the MQTT Broker sends a CONNACK response to the NMS30, then the NMS30 sends a user name and a password to the MQTT Broker, the MQTT Broker verifies the correctness of the user name and the password, if the user name and the password are correct, an AUTH response is sent, and otherwise, a DICONNECT response is sent.

It will be appreciated that the procedure by which the NMS30 and the access network device 20 access the MQTT Broker is not strictly timing constrained, but typically the procedure by which the NMS30 accesses the MQTT Broker is earlier than the procedure by which the access network device 20 accesses the MQTT Broker.

S904: the access network device sends first authentication information to the NMS through the MQTT Broker on the push-up authentication theme.

The first authentication information includes a unique identifier of the access network device 20 (may be a MAC of the access network device 20, or an SN of the access network device 20, or a combination of both), and first part data of the authentication key.

The authentication key is determined based on the unique identification, for example, the access network device 20 may obtain an authentication key (SecretKey) by performing calculation processing on its own MAC by using a preset algorithm. The access network device 20 then splits the authentication key, for example, by dividing the authentication key into two parts, one of which is the first part of data and the other of which is the second part of data. Assuming that the authentication key has 32 bytes, in some examples, access network device 20 may have the first 16 bytes of data as the first portion of data, i.e., pressetkey, and the last 16 bytes of data as the second portion of data, i.e., postSecretKey; or, combining the data of even bytes to form a first part of data, and combining the data of odd bytes to form a second part of data; in still other examples, the two portions of data from which access network device 20 splits the authentication key may differ in number of bytes, e.g., the first 5 bytes as the first portion of data and the last 27 bytes as the second portion of data. It will be appreciated by those skilled in the art that the manner in which the access network device 20 generates the authentication key and splits the authentication key to obtain the first portion of data and the second portion of data is not limited to the examples described above.

In some examples, the pseudocode of the first authentication information is as follows:

in some examples, the push-up data topic determined by the access network device 20 for the first authentication information is "report/NMS/device_type/register", and the MQTT Broker may push on the topic "report/NMS/device_type/register" after receiving the first authentication information, so that the NMS30 subscribed to the topic receives the first authentication information.

S906: the NMS verifies the first authentication information.

The NMS30 may calculate the MAC carried in the first authentication information by using the same algorithm as the access network device 20 to obtain an authentication key, and in addition, the NMS30 splits the authentication key by using the same splitting rule as the access network device 20 to obtain the first part of data and the second part of data. Then, the NMS30 verifies the first part of data carried in the first authentication information by using the first part of data obtained by splitting itself, if the first part of data obtained by splitting itself of the NMS30 is consistent with the first part of data carried in the first authentication information, the first authentication information passes the verification, otherwise, the verification of the first authentication information fails. For example, the NMS30 performs calculation processing on the MAC in the first authentication information to obtain a SecretKey, then segments the SecretKey to obtain preSecretKey, NMS, compares the pressetkey obtained by processing with the pressetkey carried in the first authentication information to determine whether the pressetkey and the pressetkey are consistent, if so, the verification is successful, otherwise, the verification is failed.

S908: after the verification of the first authentication information is passed, the NMS sends second authentication information to the access network equipment through the MQTT Broker.

If the NMS30 verifies the first authentication information, it may send, to the access network device 20, through MQTT Broker, second authentication information containing a second part of data of the authentication key, for example, postsecret key, and in addition, the second authentication information may further include a random code (random code) generated by the NMS30 for the access network device 20.

In some examples, the pseudocode of the second authentication information is as follows:

in some examples, the NMS30 determines for the second authentication information that the push-up data topic is "opt/NMS/device_type/auth/clientId", and after the MQTT Broker receives the second authentication information, the push-up data topic may be performed on the topic "opt/NMS/device_type/auth/clientId", so that the access network device 20 subscribed to the topic receives the second authentication information.

S910: the access network equipment authenticates the second authentication information.

After receiving the second authentication information, the access network device 20 may extract the second part of the authentication key from the second part of the authentication key, then compare the extracted second part of the authentication key with the second part of the data determined before the access network device 20 itself, if the second part of the authentication information obtained by splitting the access network device 20 itself is consistent with the second part of the data carried in the second authentication information, the second authentication information passes verification, otherwise, the verification of the second authentication information fails. For example, the access network device 20 compares the postSecretKey obtained by processing with the postSecretKey carried in the second authentication information to determine whether the postSecretKey and the postSecretKey are consistent, if so, the authentication is successful, and if not, the authentication is failed.

If the authentication fails, the access network device 20 may disconnect from the MQTT Broker and no attempt is made to connect to the NMS30 via the MQTT Broker.

S912: after the second authentication information is verified, the access network device sends authentication information to the NMS through the MQTT Broker.

After the access network device 20 passes the authentication of the second authentication information, it may generate authentication information, which may be used by the NMS30 to further authenticate the access network device 20. In some examples, the access network device 20 may combine the random code extracted from the second authentication information with its own unique identifier to obtain combined data, and then encrypt the combined data to obtain authentication data (authData), and send the authentication data to the NMS30 through the MQTT Broker, where the authentication data is carried in the authentication information.

In some examples, the pseudo code of the authentication information is as follows:

in some examples, the push-up data topic determined by the access network device 20 for authentication information is "opt/NMS/res/session-id", and after the MQTT Broker receives the authentication information, the message push may be performed on the topic of "opt/NMS/res/session-id", so that the NMS30 subscribed to the topic receives the authentication information.

S914: the NMS authenticates the authentication information.

After receiving the authentication information, the NMS30 parses the authentication information to obtain authentication data, and then the NMS30 decrypts the authentication information and splits the decrypted combined data to obtain unique identification information and a random code of the access network device 20. In the process of generating the second authentication information, the NMS30 may store the random code in association with the unique identifier of the access network device 20 after allocating the random code to the access network device 20, for example, form a random code table, where the unique identifier of the access network device 20 corresponds to the random code allocated to the NMS30 one by one, so when the NMS30 authenticates the authentication information, it may search the corresponding random code in the random code table according to the unique identifier extracted from the combination data, and then compare the found random code with the random code in the combination data, so as to determine whether the random code sent by the access network device 20 through the authentication information is allocated to the access network device itself, if yes, the authentication of the authentication information is passed, or else the authentication fails.

S916: after the authentication of the authentication information is passed, the NMS sends an equipment information acquisition instruction to the access network equipment through an MQTT Broker.

If the NMS30 passes the authentication of the authentication information, it may send information indicating that the authentication passes to the access network device 20 through the MQTT Broker, otherwise, may send information indicating that the authentication fails to pass to the access network device 20 through the MQTT Broker.

In some examples of the present embodiment, in order to facilitate subsequent management of the access network device 20 by the NMS30, the NMS30 may acquire device information of the access network device 20 in the event that authentication information of the access network device 20 is authenticated, to generate ACL (access control list) information in a database from the device information, so in these examples, the NMS30 may send a device information acquisition indication to the access network device 20 if authentication of the authentication information is passed. In one example, the pseudocode of the device information acquisition indication is as follows:

the push-down authentication subject to which the device information acquisition indication belongs may be "opt/NMS/device_type/get/clientId", so that the NMS30 may send the device information acquisition indication to the MQTT Broker on the subject of opt/NMS/device_type/get/clientId for the MQTT Broker to push the device information acquisition indication to the access network device 20.

In some examples, if authentication of authentication information for access network device 20 fails, NMS30 may send an authentication failure notification to access network device 20, e.g., the corresponding pseudocode for the authentication failure notification may be as follows:

The NMS30 may send an authentication failure notification to the access network device 20 through the MQTT Broker on the push-down authentication topic of "opt/NMS/device_type/auth/clientId".

S918: the access network device sends device information to the NMS through the MQTT Broker.

If the access network device 20 receives a message characterizing an authentication failure, such as an authentication failure notification, it may disconnect from the MQTT Broker. If it receives a device information acquisition indication, it may generate and send device information to the NMS 30.

In some examples, the pseudocode for the device information is as follows:

the access network device 20 may send device information to the NMS30 using the push-up authentication topic of "opt/NMS/res/session-id".

S920: the NMS generates access indication information according to the device information.

After receiving the device information through the MQTT Broker, the NMS30 may generate ACL information according to the device information, and store the ACL information in the database. In some examples, the database storing ACL information is accessible to the NMS30 in conjunction with the MQTT Broker. The device information obtained by NMS30 includes the device type of access network device 20. In some examples of this embodiment, the device information may also include the MAC, status, alarm port (trapPort), etc. of the access network device 20.

It will be appreciated by those skilled in the art that, in some examples, the access network device 20 may also carry its own device information in the authentication information when sending the authentication information to the NMS30, so that when the NMS30 passes the authentication of the authentication information, the access network device 20 is not instructed to report the device information, and the ACL information may be generated directly based on the device information carried in the authentication information.

The NMS30 may also generate access indication information based on the device information, where in some examples the access indication information includes a subscription indication indicating a push-down management topic to which the access network device 20 needs to subscribe. In other examples, the access indication information includes long-term account information for the access network device 20 to re-access the MQTT Broker, where the long-term account information includes an access account number and an access password. In still other examples, the access indication information includes both subscription indication and long-term account information, e.g., in one example, the pseudocode of the access indication information is as follows:

s922: the NMS sends access indication information to the access network equipment through the MQTT Broker.

After the NMS30 generates the access indication information, a corresponding push-down authentication theme, for example, "opt/NMS/device_type/reconnect/clientId", may be determined for the access indication information, and then the access indication information is sent to the MQTT Broker through the theme, so that the MQTT Broker pushes the access indication information to the access network device 20.

S924: and the access network equipment re-accesses the MQTT Broker according to the access indication information.

After receiving the access indication information, the access network device 20 may re-access the MQTT Broker according to the long-term account information, subscribe a plurality of push-down management topics to the MQTT Broker, and if the access indication information includes a subscription indication, the access network device 20 may directly subscribe the topics to the MQTT Broker according to the subscription indication.

It should be understood by those skilled in the art that the above example is only one implementation of the access network device 20 accessing the MQTT Broker and accessing the NMS30 through the MQTT Broker, and is not the only way, for example, in some examples, the long-term account information of the access network device 20 accessing the MQTT Broker may be preset in the device before the device leaves the factory, so that the access network device 20 does not need to obtain the long-term account information from the NMS30 side. As another example, in some examples, the authentication and authorization process between NMS30 and access network device 20 may be simpler or more complex.

The present embodiment further provides a computer device 50, please refer to the hardware structure schematic diagram of the computer device 50 shown in fig. 10:

the computer device 50 comprises a processor 51, a memory 52 and a communication bus 53, wherein the processor 51 and the memory 52 are in communication connection via the communication bus 53. The memory 52 may be used to store instructions, programs, code sets or instruction sets, data, among others. The memory 52 may include a storage program area that may store instructions for implementing an operating system, instructions for at least one function, and a storage data area that may store data.

In some examples of this embodiment, the computer device 50 may be the access network device 20 in any of the foregoing examples, where a first computer program is stored in a storage program area, and the first computer program may be executed by the processor 51, so as to implement a flow on the access network device 20 side in the access network device management method provided in the foregoing embodiment; the storage data area may store data and the like related to the access network device 20 in the access network device management provided in the above embodiment. In other examples of this embodiment, the computer device 50 may be a server, and the storage program area of the memory 52 stores a second computer program, which is executable by the processor 51 to implement the flow on the NMS30 side in the access network device management method provided in the foregoing embodiment; the data storage area may store data and the like related to the NMS30 side in the access network device management method provided in the above embodiment.

Processor 51 may include one or more processing cores. The processor 51 performs various functions of the present application and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 52, calling data stored in the memory 52. The processor 51 may be at least one of an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a digital signal processor (Digital Signal Processor, DSP), a digital signal processing device (Digital Signal Processing Device, DSPD), a programmable logic device (Programmable Logic Device, PLD), a field programmable gate array (Field Programmable Gate Array, FPGA), a central processing unit (Central Processing Unit, CPU), a controller, a microcontroller, and a microprocessor. It will be appreciated that the electronic device for implementing the functions of the processor 51 may be other for different apparatuses, and the embodiments of the present application are not specifically limited.

Embodiments of the present application provide a computer-readable storage medium, for example, comprising: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes. The computer readable storage medium stores at least one of a first computer program and a second computer program that can be loaded and executed by the processor 51, where the first computer program is executable by the processor 51 to implement a procedure on the access network device 20 side in any of the access network device management methods of the foregoing embodiments; the second computer program is executable by the processor 51 to implement a procedure on the NMS30 side in any of the access network device management methods of the previous embodiments.

The foregoing embodiments are only used for describing the technical solution of the present application in detail, but the descriptions of the foregoing embodiments are only used for helping to understand the method and the core idea of the present application, and should not be construed as limiting the present application. Variations or alternatives that are readily contemplated by those skilled in the art within the scope of the present disclosure are intended to be encompassed within the scope of the present disclosure.

Claims

1. An access network device management method, characterized in that the access network device management method comprises:

receiving a push-down management message pushed by the message middleware on the push-down management theme, wherein the push-down management message is sent to the message middleware on the push-down management theme by a Network Management System (NMS);

processing the push-down management message to accept management of the NMS.

2. The access network device management method of claim 1, wherein the message middleware is a message queue telemetry transport protocol middleware MQTT Broker, the access network device management method further comprising:

generating a push-up management message;

3. The access network device management method of claim 2, wherein the push-down management topic is a command topic and the push-down management message is a command message; the push-up management theme comprises at least one of a data reporting theme and a command reply theme, and the push-up management message comprises at least one of a data reporting message corresponding to the data reporting theme and a command response message corresponding to the command reply theme.

4. The access network device management method of claim 3, wherein the command theme and the data reporting theme each include a plurality of limiting fields, and the plurality of limiting fields include at least one of a device type limiting field and a domain limiting field, the device type limiting field is used for limiting a device type of an access network device, and the domain limiting field is used for limiting a domain to which the access network device belongs.

5. The method for managing access network devices according to any one of claims 1 to 4, wherein before subscribing to a number of push management topics from the message middleware, the method further comprises:

receiving access indication information pushed by the message middleware on the push-down authentication theme, wherein the access indication information is sent to the message middleware by adopting the push-down authentication theme after the authentication information is verified by the NMS;

6. The method for managing access network equipment according to claim 5, wherein the access indication information further includes a subscription indication, and the subscribing to the message middleware for a number of push-down management topics includes:

7. The access network device management method of claim 5, wherein before sending authentication information to the message middleware on a push-up authentication topic, further comprising:

Authenticating the second portion of data based on the authentication key;

8. An access network device management method, characterized in that the access network device management method comprises:

generating a push-down management message, and determining a push-down management subject to which the push-down management message belongs according to a preset subject determination rule;

and sending the push-down management message to the message middleware on the push-down management theme so that the message middleware pushes the push-down management message to the access network equipment subscribed to the push-down management theme to manage the access network equipment.

9. The access network device management method of claim 8, wherein the message middleware is an MQTT Broker, the access network device management method further comprising:

subscribing a plurality of push-up management topics to the message middleware;

And processing the push-up management message.

10. A computer device comprising a processor, a memory and a communication bus for enabling a communication connection between the processor and the memory, the memory having stored therein at least one of a first computer program and a second computer program, the first computer program being executable by the processor for implementing the access network device management method of any of claims 1 to 7; the second computer program being executable by the processor to implement the access network device management method of claim 8 or 9.