WO2020024303A1

WO2020024303A1 - Data collection method and apparatus

Info

Publication number: WO2020024303A1
Application number: PCT/CN2018/098688
Authority: WO
Inventors: 普云
Original assignee: 华为技术有限公司
Priority date: 2018-08-03
Filing date: 2018-08-03
Publication date: 2020-02-06

Abstract

A data collection method and apparatus, relating to the technical field of communications and used for executing a data collection procedure in a new networking architecture. The method comprises: a second network element receiving a first message sent by a third network element and encapsulated in the format of a first interface protocol (S801), and encapsulating the first message in the format of a second interface protocol to obtain a second message (S802), wherein the first interface protocol is an IPDR protocol, and the second interface protocol comprises a restconf protocol, a netconf protocol, an SNMP and an RPC protocol; the second network element determining, according to the second message, at least one first network element associated with the third network element, and respectively sending the second message to the at least one first network element (S804); the second network element receiving first data sent by the first network element and encapsulated in the format of the second interface protocol (S805), and encapsulating the first data in the format of the first interface protocol to obtain second data (S806); and the second network element determining, according to the second data, the third network element associated with the first network element (S807), and sending the second data to the third network element (S808).

Description

Data acquisition method and device

Technical field

The present application relates to the field of communication technologies, and in particular, to a method and device for data collection.

Background technique

At present, in the CMTS networking architecture, operators can use CMTS equipment to collect data from user-side equipment (such as Cable Modem (CM)), such as the operating status of the CM, and the types of services of different user terminals connected to the CM. In order to facilitate operators to grasp the business conditions of different user terminals, and to analyze the billing, fault location and network operation status according to the business conditions of different user terminals.

Figure 1 shows a traditional CMTS networking architecture. The OLT is deployed in the central office room to manage multiple CMTS devices (only one CMTS is shown as an example in the figure). The CMTS device is deployed in the residential room. Manage multiple CMs. CMs are deployed in users 'homes. Each CM can be connected to multiple customer premise equipment (CPE). For example, CMs can be used to connect users' mobile phones, computers, and cable television. In the networking architecture shown in FIG. 1, the CMTS device collects the data of each CM, uploads the collected CM data to the OLT, and the OLT uploads the CM data to the operator server.

In order to meet higher business requirements, the industry has proposed a new networking architecture. In the new networking architecture, different functions of the CMTS can be separated and deployed in different locations. For example, the downstream CMTS and PHY layer processing can be separated from the CMTS and MAC layer processing and deployed at different locations, or the upstream and downstream CMTS and PHY layer processing can be separated from the CMTS and MAC layer processing and deployed at different locations. Among them, the CMTS processing unit and the CMTS processing unit are connected by optical fibers. This connection method is generally called a remote physical layer (Remote Physical) (R-PHY) architecture.

It can be seen that because the new network architecture has a larger change in network element composition, network element location, and network element functions than the traditional CMTS network architecture, the data collection technology in the traditional CMTS network architecture is no longer available. Applicable to the new networking architecture.

Summary of the invention

The embodiments of the present application provide a data collection method and device, which can execute a data collection process in a new networking architecture.

To achieve the above purpose, the embodiments of the present application adopt the following technical solutions:

According to a first aspect, an embodiment of the present application provides a data collection method. The method includes: a second network element receiving a first message encapsulated in a first interface protocol format sent by a third network element, and encapsulating according to a second interface protocol format. First message, get the second message. After that, the second network element determines at least one first network element associated with the third network element according to the second message, and sends a second message to the at least one first network element, respectively. Receiving first data encapsulated in a second interface protocol format sent by a first network element (the first network element is any one of at least one first network element), and encapsulating the first data in the first interface protocol format A piece of data to obtain second data, and then determine a third network element associated with the first network element according to the second data, and send the second data to the third network element.

Among them, the first interface protocol is the Internet Detailed Record (IPDR) protocol, and the second interface protocol includes a characterization state transfer configuration (restconf) protocol, a network configuration (netconf) protocol, and a simple network management protocol (Simple Network Management Protocol). (SNMP), Remote Procedure Call (RPC) protocol; the second message is used to request data collected by at least one first network element.

In the data collection method provided in the embodiment of the present application, after receiving the first message encapsulated in the first interface protocol format sent by the third network element, the second network element encapsulates the first message according to the second interface protocol format to obtain the second Message, and send a second message to the first network element to obtain first data sent by the first network element. After obtaining the first data, the second network element encapsulates the first data according to the first interface protocol format to obtain the second data, so that the second data can be carried in the transmission channel between the second network element and the third network element, thereby The data collected by the first network element is successfully transmitted to the third network element via the second network element. It can be seen that, in the data collection method of the embodiment of the present application, each segment of the transmission channel can transmit data or messages consistent with the format of the channel, which improves the probability of successfully transmitting data or messages in the channel, thereby improving the success rate of data collection .

In a possible design, before the second network element receives the first message sent by the third network element and encapsulated in the first interface protocol format, the following steps may be performed: the second network element receives the first message sent by the third network element. For the first version negotiation request, the second network element sends a first version negotiation response to the third network element.

The first version negotiation request is used to request to negotiate the first protocol version. The first protocol version is an IPDR protocol version between the second network element and the third network element. The first version negotiation response carries the first protocol version.

It should be noted that the above process uses the third network element to actively initiate a version negotiation request as an example to explain the process of negotiating the IPDR protocol version between the third network element and the second network element. In addition, the second network may also be used by the second network. The element actively initiates an IPDR protocol version negotiation request with the third network element. Specifically, the second network element sends a first version negotiation request to the third network element, and receives a first version negotiation response sent by the third network element.

In a possible design, before the second network element receives the first message sent by the third network element and encapsulated in the first interface protocol format, the following steps may be performed:

The second network element sends a second version negotiation request to the first network element, and receives a second version negotiation response sent by the first network element.

The second version negotiation request is used to request to negotiate a second protocol version. The second protocol version is an IPDR protocol version between the second network element and the first network element. The second version negotiation response carries the second protocol version.

In the above process, the second network element actively initiates an IPDR protocol version negotiation request with the first network element to negotiate the IPDR protocol version with the first network element. In the embodiment of the present application, the first network element may also actively initiate the IPDR protocol version negotiation request. Specifically, the second network element receives the second version negotiation request sent by the first network element, and sends a second version negotiation response to the first network element.

It should be noted that, in a data collection method provided in the embodiment of the present application, a first interface protocol is used when communicating between the second network element and the third network element, and the first interface protocol may be the IPDR protocol, and the second The network element and the first network element use a second interface protocol for communication, and the second interface protocol may be an IPDR protocol. In this scenario, the second network element encapsulates the first message according to the second interface protocol format to obtain the second message, which can be specifically implemented as follows:

If, based on the IPDR protocol version negotiation process, the second network element learns that the first protocol version is different from the second protocol version, the second network element changes the encapsulation format of the first message from the encapsulation format corresponding to the first protocol version to An encapsulation format corresponding to the second protocol version to obtain a second message.

Correspondingly, in a scenario where the first interface protocol and the second interface protocol are both IPDR protocols, the second network element encapsulates the first data according to the format of the first interface protocol to obtain the second data, which can be specifically implemented as:

If the first protocol version is different from the second protocol version, the second network element changes the encapsulation format of the first data from the encapsulation format corresponding to the second protocol version to the encapsulation format corresponding to the first protocol version to obtain the second data.

In another possible design, the first interface protocol used in the communication between the second network element and the third network element is the IPDR protocol, and the second interface used in the communication between the second network element and the first network element The protocol can be any of restconf, netconf, SNMP, and SNMP protocols.

Correspondingly, the second network element encapsulates the first message according to the second interface protocol format to obtain the second message, which can be specifically implemented as follows: The second network element encapsulates the first message's encapsulation format with the encapsulation format corresponding to the first protocol version. The second message is obtained by modifying the encapsulation format corresponding to any protocol other than the IPDR protocol in the second interface protocol.

Correspondingly, the second network element encapsulates the first data according to the first interface protocol format to obtain the second data, which can be specifically implemented as follows: the second network element divides the encapsulation format of the first data from the IPDR protocol by the second interface protocol The encapsulation format corresponding to any other protocol is modified to the encapsulation format corresponding to the first protocol version to obtain the second data.

In a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the following steps may be performed to establish transmission with the third network element. Control Protocol (Transmission Control Protocol) TCP connection:

When the third network element works in the active mode, the second network element receives a TCP connection request sent by the third network element, where the TCP connection request is used to request establishment of a TCP between the third network element and the second network element connection;

Or, in a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the following steps may be performed to establish a connection with the third network element. Transmission Control Protocol (TCP) connection: When the third network element works in a passive mode, the second network element sends a TCP connection request to the third network element.

In a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the second network element performs the following steps to establish a connection with the first network element. TCP connection:

When the second network element works in the active mode, the second network element sends a TCP connection request to the first network element, and the TCP connection request is used to request establishment of a TCP connection between the second network element and the first network element.

Or, in a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the second network element performs the following steps to establish a connection with the first network element. TCP connection between the two network elements: when the second network element works in the passive mode, the second network element receives the TCP connection request sent by the first network element.

In a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the second network element performs the following steps to establish a connection with the third network element. IPDR connection:

When the third network element works in the passive mode, the second network element sends an IPDR connection request to the third network element, and receives the IPDR connection response sent by the third network element. The IPDR connection request is used to request to establish an IPDR connection between the third network element and the second network element.

Or, in a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the second network element performs the following steps to establish a connection with the third network element. IPDR connection between: In the case where the third network element works in the active mode, the second network element receives the IPDR connection request sent by the third network element and sends an IPDR connection response to the third network element.

In a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the second network element performs the following steps to establish a connection with the first network element. IPDR connection: When the second network element works in the passive mode, the second network element receives the IPDR connection request sent by the first network element and sends an IPDR connection response to the third network element. The IPDR connection request is used to request to establish an IPDR connection between the first network element and the second network element.

Or, in a possible design, before the second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, the second network element performs the following steps to establish a connection with the first network element. IPDR connection between the two network elements: When the second network element works in the active mode, the second network element sends an IPDR connection request to the first network element, and receives the IPDR connection response sent by the first network element.

In a possible design, before the second network element receives the first message sent by the third network element and encapsulated in the first interface protocol format, the second network element may further perform the following steps: the second network element receives the third The session query request sent by the network element, and sends a session query response to the third network element. The session query request is used to request to query the session associated with the first network element; the session query response carries the session associated with the first network element.

In a possible design, before the second network element receives the first message sent by the third network element and encapsulated in the first interface protocol format, the second network element may further perform the following steps:

The second network element sends a session query request to the first network element, and receives a session query response sent by the first network element. The session query response carries a session associated with the first network element, and the session query request is used to request to query the first network element. Associated Session.

In a second aspect, an embodiment of the present application provides a data acquisition device. The device is provided with a transceiver and a processor. The transceiver is configured to receive the first message encapsulated in the first interface protocol format sent by the third network element; and the processor is configured to encapsulate the first message received by the transceiver according to the second interface protocol format to obtain the second message. The first interface protocol is the Internet detailed record IPDR protocol. The second interface protocol includes a state transfer configuration restconf protocol, a network configuration netconf protocol, a simple network management protocol SNMP, and a remote procedure call RPC protocol. The processor is also used to The message determines at least one first network element associated with the third network element; the transceiver is further configured to send a second message to the at least one first network element, respectively, and the second message is used to request the data collected by the at least one first network element Data; receiving the first data encapsulated in the second interface protocol format sent by the first network element; the processor is further configured to encapsulate the first data according to the first interface protocol format to obtain the second data, and the first network element is at least one Any one of the first network elements, the first network element; determining the third network element associated with the first network element according to the second data; the transceiver is further configured to send a signal to the third network element Transmitting the second data element.

In a possible design, the transceiver is further configured to receive a first version negotiation request sent by a third network element. The first version negotiation request is used to request to negotiate a first protocol version, and the first protocol version is a second network element. IPDR protocol version with the third network element; sending a first version negotiation response to the third network element, where the first version negotiation response carries the first protocol version.

Or, in a possible design, the transceiver is further configured to send a first version negotiation request to a third network element; and receive a first version negotiation response sent by the third network element.

In a possible design, the transceiver is further configured to send a second version negotiation request to the first network element, the second version negotiation request is used to request to negotiate a second protocol version, and the second protocol version is the second network element and The version of the IPDR protocol between the first network elements; receiving the second version negotiation response sent by the first network element, and the second version negotiation response carrying the second protocol version.

Alternatively, in a possible design, the transceiver is further configured to receive a second version negotiation request sent by the first network element; and send a second version negotiation response to the first network element.

When the second interface protocol is the IPDR protocol, in a possible design, the processor is configured to encapsulate the first message according to the second interface protocol format to obtain the second message, including: if the first protocol version is different from For the second protocol version, the encapsulation format of the first message is modified from the encapsulation format corresponding to the first protocol version to the encapsulation format corresponding to the second protocol version to obtain the second message.

In a possible design, the processor is configured to encapsulate the first data according to the first interface protocol format to obtain the second data, including: if the first protocol version is different from the second protocol version, The encapsulation format is changed from the encapsulation format corresponding to the second protocol version to the encapsulation format corresponding to the first protocol version to obtain the second data.

When the second interface protocol is a non-IPDR protocol, in a possible design, the processor is configured to encapsulate the first message according to the second interface protocol format to obtain a second message, including: encapsulating the first message. The format is changed from the encapsulation format corresponding to the first protocol version to the encapsulation format corresponding to any protocol other than the IPDR protocol in the second interface protocol to obtain a second message.

In a possible design, the processor is configured to encapsulate the first data according to the first interface protocol format to obtain the second data, including: dividing the encapsulation format of the first data from the IPDR protocol by the second interface protocol. The encapsulation format corresponding to any external protocol is modified to the encapsulation format corresponding to the first protocol version to obtain the second data.

In a possible design, the transceiver is further configured to receive a Transmission Control Protocol TCP connection request sent by the third network element when the third network element works in an active mode, and the TCP connection request is used to request establishment of a third TCP connection between the network element and the second network element.

Or, in a possible design, the transceiver is further configured to send a TCP connection request to the third network element when the third network element works in the passive mode.

In a possible design, the transceiver is further configured to send a TCP connection request to the first network element when the second network element works in an active mode, and the TCP connection request is used to request establishment of the second network element and the first network element. TCP connection between network elements.

Or, in a possible design, the transceiver is further configured to receive a TCP connection request sent by the first network element when the second network element works in a passive mode.

In a possible design, the second network element actively initiates an IPDR connection request with the third network element, and the transceiver is further configured to send the third network element to the third network element when the third network element works in the passive mode. Send an IPDR connection request and receive an IPDR connection response sent by the third network element; the IPDR connection request is used to request the establishment of an IPDR connection between the third network element and the second network element.

Or, in a possible design, the second network element passively receives an IPDR connection request initiated by the third network element, and the transceiver is further configured to receive the third network element when the third network element works in an active mode. The IPDR connection request sent; an IPDR connection response is sent to the third network element.

In a possible design, the second network element passively receives the IPDR connection request initiated by the first network element, and the transceiver is further configured to receive the first network element to send the IPDR when the second network element works in the passive mode. A connection request, sending an IPDR connection response to the third network element; the IPDR connection request is used to request the establishment of an IPDR connection between the first network element and the second network element;

Or, in a possible design, the second network element actively initiates an IPDR connection request with the first network element, and the transceiver is further configured to send the first network element to the first network element when the second network element works in an active mode. The network element sends an IPDR connection request; receives the IPDR connection response sent by the first network element.

In a possible design, the transceiver is further configured to receive a session query request sent by a third network element, and send a session query response to the third network element; the session query request is used to request a query about a session associated with the first network element; The session query response carries the session associated with the first network element.

In a possible design, the transceiver is further configured to send a session query request to the first network element and receive a session query response sent by the first network element; the session query request is used to request a query about a session associated with the first network element; The session query response carries the session associated with the first network element.

In a third aspect, an embodiment of the present application provides a data acquisition device, which has a function of implementing the data acquisition method of any one of the first aspects. This function can be realized by hardware, and can also be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

According to a fourth aspect, a data acquisition device is provided, including: a processor and a memory; the memory is configured to store computer execution instructions, and when the data acquisition device is running, the processor executes the computer execution instructions stored in the memory so that The data acquisition device executes the data acquisition method according to any one of the first aspects.

According to a fifth aspect, a data acquisition device is provided, including: a processor; the processor is coupled to the memory and reads instructions in the memory, and then executes the data acquisition method according to any one of the first aspects according to the instructions.

According to a sixth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions that, when run on a computer, enable the computer to execute the data collection method of any one of the first aspects.

According to a seventh aspect, a computer program product containing instructions is provided, which, when run on a computer, enables the computer to execute the data collection method of any one of the above-mentioned first aspects.

According to an eighth aspect, a circuit system is provided. The circuit system includes a processing circuit configured to execute the data acquisition method according to any one of the first aspects.

According to a ninth aspect, a chip is provided. The chip includes a processor, and the processor is coupled to a memory. The memory stores program instructions. The program instructions stored in the memory are executed by the processor to implement the first chip. The data collection method according to any one of the aspects.

The technical effects brought by any one of the design methods in the second aspect to the ninth aspect can refer to the technical effects brought by the different design methods in the first aspect, and are not repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of the architecture of a traditional data acquisition system;

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

FIG. 3 is a schematic structural diagram of a data acquisition system according to an embodiment of the present application; FIG.

4 is a schematic structural diagram of a data acquisition device according to an embodiment of the present application;

FIG. 5 is a flowchart of a data collection preprocessing method according to an embodiment of the present application;

6 is a schematic diagram of a version negotiation message according to an embodiment of the present application;

7 is a flowchart of another data collection and preprocessing method according to an embodiment of the present application;

FIG. 8 is a first method flowchart of a data collection method according to an embodiment of the present application; FIG.

9 is a second method flowchart of a data collection method according to an embodiment of the present application;

FIG. 10 is a schematic structural diagram of a data acquisition device according to an embodiment of the present application.

detailed description

The terms “first” and “second” in the specification of the present application and the drawings are used to distinguish different objects, or to distinguish different processes on the same object, rather than to describe a specific order of the objects. Furthermore, the terms "including" and "having" as well as any variants thereof mentioned in the description of the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that contains a series of steps or units is not limited to the listed steps or units, but optionally also includes other steps or units not listed, or optionally also Include other steps or units inherent to these processes, methods, products, or equipment. It should be noted that, in the embodiments of the present application, words such as "exemplary" or "for example" are used as examples, illustrations or illustrations. Any embodiment or design described as “exemplary” or “for example” in the embodiments of the present application should not be construed as more preferred or more advantageous than other embodiments or designs. Rather, the use of the words "exemplary" or "for example" is intended to present the relevant concept in a concrete manner.

First, the system architecture involved in the embodiment of the present application is as follows:

As shown in Figure 2, the system includes an Internet detailed record server (Internet Protocol Record Server, IPDR Server), a media access control management network element (MAC Manager, also referred to herein as a MAC controller), and a remote media access control. Layer (Remote Media Access Control, R-MAC) entity, R-PHY entity, remote media access control layer and physical layer (Remote Media Access Control and Physical, R-MACPHY) entity, CM, CPE.

The IPDR server is located at the aggregation layer and is used to manage at least one MAC Manager (only one is shown as an example in the figure).

MAC Manager is used to manage at least one remote entity. Generally, the form of the remote entity may be different under different networking architectures. Optionally, in the R-PHY architecture, the MAC layer and PHY layer functions of the CMTS are separated and deployed in different locations. Among them, the PHY layer function of the CMTS is sunk to the user side to form the R-PHY entity (to simplify the description, the R-PHY entity is referred to as R-PHY hereinafter), and the R-PHY entity is responsible for the PHY layer processing. The function of the MAC layer is retained at the central office side, forming an R-MAC entity (for simplicity of description, the R-MAC entity is hereinafter referred to simply as R-MAC), and the R-MAC entity is responsible for MAC layer processing. In this way, the MAC Manager directly manages at least one R-MAC (only one is exemplarily shown in FIG. 2), and the R-MAC manages at least one R-PHY. In the R-MACPHY architecture, the functions of the MAC layer and the PHY layer of the CMTS are sunk to the user side to form the R-MACPHY entity (to simplify the description, the R-MACPHY entity is referred to as R-MACPHY hereinafter), and the R-MACPHY MACPHY is responsible for MAC layer and PHY layer processing. Therefore, in this architecture, at least one R-MACPHY is directly managed by the MAC Manager (only one is exemplarily shown in FIG. 2).

Of course, as the network evolves, different networking architectures may also be generated for each function of the CMTS. The technical solution of the embodiment of the present application is not limited to the R-PHY architecture or R-MACPHY architecture shown in FIG. 2.

The R-PHY or R-MACPHY is located in the access layer and is used to manage at least one CM (the case where each R-MACPHY or R-PHY manages one CM is exemplarily shown in FIG. 2).

The CM is located in the user's home and is used to manage at least one CPE.

CPE, located in the user's home, is used to connect user terminals and provide users with integrated access to services such as home cable broadband, Internet Protocol Television (IPTV), and Voice over Internet Protocol (VOIP). Optionally, the CPE involved in the embodiments of the present application may include various devices having an access function, such as a digital video conversion box (Set Top Box, STB), a home gateway, and the like. The user terminal may be, for example, a cable TV, or a wearable device, a computing device, a personal digital assistant (PDA) computer, a tablet computer, a laptop computer, and a machine type communication, MTC) terminal, user equipment (UE), and so on.

To facilitate understanding, the following mainly uses the R-PHY architecture as an example to describe the data transmission method of the system of FIG. 2. In the downlink transmission (from the IPDR server to the CPE), the downlink data is sent by the IPDR server to the MAC manager, and then sent by the MAC manager to the R-PHY through the R-MAC. The R-PHY demodulates and decodes to obtain the original downlink data. Re-encoding and modulation convert the original downlink data into a coaxial cable signal and send it to each connected CM, and the CM sends the coaxial cable signal to the CPE (such as a set-top box and / or a personal computer).

In the uplink transmission (from the CPE to the IPDR server), the CPE sends the uplink data to the CM, and the CM transmits the data to the R-PHY through a coaxial cable. The R-PHY demodulates and decodes the data, and then encodes and modulates the data. The shaft cable signal is converted into an optical fiber signal, which is then sent to the R-MAC by the R-PHY through the optical fiber. After that, the R-MAC uploads the downlink data to the IPDR server through the MAC Manager.

Optionally, the names of the network elements in FIG. 2 are only examples, and the names of the network elements in the specific implementation may be other names, or the network elements may also be called entities, which is not specifically limited in the embodiment of the present application. All or part of the foregoing network elements may be physical physical network elements or virtualized network elements, which is not limited herein.

In addition, the network architecture and service scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. With the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

As shown in FIG. 3, an embodiment of the present application provides a data acquisition system, which includes a third network element 303, a second network element 302, and a first network element 301.

The first network element 301 is configured to collect data from the CM, and the collected data includes CM operating status, CM-related charging information, spectrum information of uplink and downlink channels of the link where the CM is located, and debugging information of the CM.

The second network element 302 has an Internet Protocol (IP) layer function, and is configured to upload data collected by the first network element 301 to the third network element 303. The second network element 302 and the first network element 301 have a second protocol interface, and the second network element 302 and the third network element 303 have a first protocol interface. The second network element 302 and the first network element 301 use the second interface protocol to encapsulate communication data when communicating, and the second network element 302 and the third network element 303 use the first interface protocol to encapsulate communication data when communicating.

The third network element 303 is configured to receive the collected data sent by the second network element 302 and upload the collected data to an upper network.

The data collection system provided in the embodiment of the present application may be applied to the system shown in FIG. 2 or a system with a similar architecture or a subsequent evolved system. When applied to the system shown in FIG. 2, the first network element 301 described above The corresponding network element or entity may be the R-MAC and / or R-MACPHY in FIG. 2, and the network element or entity corresponding to the above-mentioned second network element 302 may be the MAC manager in FIG. 2, and the above-mentioned third The network element or entity corresponding to the network element 303 may be the IPDR server in FIG. 2.

Optionally, the first network element 301, the second network element 302, and the third network element 303 in FIG. 3 may be implemented by multiple devices, and may also be implemented by one device, for example, different functions in one device may be implemented. Module, which is not specifically limited in the embodiment of the present application. It can be understood that the foregoing function module may be a network element in a hardware device, a software function running on a hardware device, or a virtualization function instantiated on a platform (for example, a cloud platform).

For example, the first network element, the second network element, and the third network element in the embodiment of the present application may be implemented by the communication device in FIG. 4. FIG. 4 is a schematic diagram of a hardware structure of a communication device according to an embodiment of the present application. The communication device 400 includes at least one processor 401, a communication line 402, a memory 403, and at least one communication interface 404.

The processor 401 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more processors for controlling the execution of the program of the solution of the present application. integrated circuit.

The communication line 402 may include a path for transmitting information between the aforementioned components.

The communication interface 404 uses any device such as a transceiver to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc. .

The memory 403 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types that can store information and instructions The dynamic storage device can also be electrically erasable programmable read-only memory (EEPROM-ready-only memory (EEPROM)), compact disc (read-only memory (CD-ROM)) or other optical disk storage, optical disk storage (Including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be used by a computer Any other media accessed, but not limited to this. The memory may exist independently, and is connected to the processor through the communication line 402. The memory can also be integrated with the processor.

The memory 403 is configured to store computer execution instructions for executing the solutions in the embodiments of the present application, and the execution is controlled by the processor 401. The processor 401 is configured to execute computer execution instructions stored in the memory 403, so as to implement the data collection method provided in the following embodiments of the present application. For example, the memory 403 is used to store two tables shown in FIG. 4, namely, the association relationship between the IPDR server and the R-MACPHY, and the IPDR protocol versions supported by the IPDR server and the R-MACPHY, respectively.

Optionally, the computer-executable instructions in the embodiments of the present application may also be referred to as application program codes, which are not specifically limited in the embodiments of the present application.

In a specific implementation, as an embodiment, the processor 401 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 4.

In a specific implementation, as an embodiment, the communication device 400 may include multiple processors, such as the processor 401 and the processor 405. Each of these processors may be a single-CPU processor or a multi-CPU processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

It can be understood that FIG. 4 only shows an exemplary hardware structure diagram of a communication device. In order to implement the technical solution of the embodiment of the present application, the communication device 400 may further include other components. Limitation.

The above-mentioned communication device 400 may be a general-purpose device or a special-purpose device. In a specific implementation, the communication device 400 may be a device having a similar structure as in FIG. 4. The embodiment of the present application does not limit the type of the communication device 400.

The data collection method provided by the embodiment of the present application will be specifically described below with reference to FIGS. 1 to 4.

It should be noted that the names of the messages or the names of the parameters in the messages between the various network elements in the following embodiments of this application are only examples, and other names may also be used in the specific implementation, which are uniformly described here and will not be described below To repeat.

As described above, in the embodiment of the present application, the second network element and the third network element adopt a first interface protocol for communication, and the first interface protocol may be an IPDR protocol. The second network element communicates with the first network element using a second interface protocol, and the second interface protocol may be an IPDR protocol or a non-IPDR protocol. Among them, non-IPDR protocols include restconf protocol, netconf protocol, SNMP protocol, and RPC protocol. Among them, the RPC protocol includes but is not limited to Google Remote Procedure Call (GRPC) GRPC protocol, Apache Thrift and so on.

First, taking the first network element in the data acquisition system shown in FIG. 3 as the R-MACPHY and the second interface protocol as the IPDR protocol as an example, the pre-processing flow of the embodiment of the present application is given. The basis of the data collection method provided in the application examples. As shown in Figure 5, the pre-processing process includes the following steps:

S501. The IPDR server sends a first version negotiation request (Version Request) to the MAC Manager.

Correspondingly, the MAC Manager receives the first version negotiation request sent by the IPDR Server.

The first version negotiation request is used to request to negotiate a first protocol version, and the first protocol version is an IPDR protocol version between the MAC Manager and the IPDR Server.

Exemplarily, the format of the first version negotiation request is shown in FIG. 6 (a):

The fields included in the first version negotiation request message sent by the IPDR Server include a request ID (IDentity, ID) field, which occupies 4 bytes, a request time field, and an IPDR version field of the IPDR Server.

S502. The MAC Manager sends a first version negotiation response to the IPDR Server.

Correspondingly, the IPDR Server receives the first version negotiation response sent by the MAC Manager. The first version negotiation response carries the first protocol version.

Exemplarily, as shown in FIG. 6 (b), the first version negotiation response message sent by the MAC Manager includes the following fields: the transmission type field of the MAC Manager, the IPDR protocol version field of the MAC Manager, and the port number used by the MAC Manager Fields, reserved words, and fields to indicate additional information. Among them, the transmission type is used to indicate the transport layer protocol defined by the TCP / IP protocol.

The above S501 and S502 are the IPDR protocol version negotiation process between the MAC Manager and the IPDR server, and may also be referred to herein as the first protocol version negotiation process. Of course, in the protocol negotiation process, the MAC Manager can also actively initiate the protocol negotiation process, that is, the MAC Manager sends a first version negotiation request to the IPDR Server and receives the first version negotiation response sent by the IPDR Server. The embodiment of the present application does not limit specific devices that actively initiate a protocol negotiation process.

S503. The MAC Manager sends a second version negotiation request to the R-MACPHY.

Correspondingly, the R-MACPHY receives the second version negotiation request sent by the MAC Manager.

The second version negotiation request is used to request to negotiate a second protocol version, and the second protocol version is an IPDR protocol version between the MAC Manager and the R-MACPHY.

S504. The R-MACPHY sends a second version negotiation response to the MAC Manager.

The MAC Manager receives the second version negotiation response sent by the R-MACPHY.

The second version negotiation response carries a second protocol version.

Here, S503 and S504 are processes for negotiating the IPDR protocol version between the R-MACPHY and the MAC Manager, and may also be referred to herein as a second protocol version negotiation process. Similarly, the R-MACPHY can initiate the protocol version negotiation process with the MAC Manager. In addition, the first protocol version negotiation process and the second protocol version negotiation process are performed independently. This means that when the MAC Manager actively initiates the negotiation process in the first protocol version negotiation process, the MAC Manager in the second protocol version negotiation process can actively initiate the negotiation process or passively receive the R-MACPHY version negotiation response.

S505. In the case where the IPDR Server works in the active mode, the IPDR Server sends a TCP connection request to the MAC Manager.

Correspondingly, the MAC Manager receives the TCP connection request sent by the IPDR Server.

Among them, the TCP connection request is used to request to establish a TCP connection between the IPDR Server and the MAC Manager.

It can be understood that a TCP connection between the peers is usually established through a three-way handshake. The schematic process of the three-way handshake is shown in FIG. 5. Through the three-way handshake shown in Figure 5, the TCP connection between the MAC Manager and the IPDR Server was successfully established.

As an alternative to S505, when the IPDR Server works in passive mode, the MAC Manager actively initiates a TCP connection request to the IPDR Server to establish a TCP connection with the IPDR Server.

S506. When the MAC Manager works in the active mode, the MAC Manager sends a TCP connection request to the R-MACPHY.

Correspondingly, the R-MACPHY receives the TCP connection request sent by the MAC Manager.

Among them, the TCP connection request is used to request establishment of a TCP connection between the MAC Manager and the R-MACPHY.

Similarly, when the MAC Manager works in the passive mode, S506 can also be implemented as: R-MACPHY sends a TCP connection request to the MAC Manager to establish a TCP connection with the MAC Manager.

S507. In the case where the IPDR Server works in the active mode, the IPDR Server sends an IPDR connection request to the MAC Manager.

Correspondingly, the MAC Manager receives the IPDR connection request sent by the IPDR Server.

Among them, the IPDR connection request is used to request to establish an IPDR connection between the IPDR server and the MAC manager.

S508. The MAC Manager sends an IPDR connection response to the IPDR Server.

The above S507 and S508 are procedures for establishing an IPDR connection between the MAC Manager and the IPDR Server. Alternatively, when the IPDR Server works in passive mode, the MACDR Manager can actively initiate an IPDR connection request. Specifically, S507 and S508 may be implemented as follows: The MAC Manager sends an IPDR connection request to the IPDR Server, and receives the IPDR connection response sent by the IPDR Server.

S509. When the MAC Manager works in the active mode, the MAC Manager sends an IPDR connection request to the R-MACPHY.

Correspondingly, the R-MACPHY receives the IPDR connection request sent by the MAC Manager.

Among them, the IPDR connection request is used to request the establishment of an IPDR connection between the MAC Manager and the R-MACPHY.

S510. The R-MACPHY sends an IPDR connection response to the MAC Manager.

Correspondingly, the MAC Manager receives the IPDR connection response sent by the R-MACPHY.

Alternatively, S509 and S510 can be implemented as follows: R-MACPHY sends an IPDR connection request to the MAC Manager and receives an IPDR connection response sent by the MAC Manager.

S511. The IPDR server sends a session query request to the MAC Manager.

Correspondingly, the MAC Manager receives the session query request sent by the IPDR Server.

The session query request is used to request to query a session associated with the R-MACPHY.

S512. The MAC Manager sends a session query response to the IPDR Server.

Correspondingly, the IPDR Server receives the session query response sent by the MAC Manager.

The session query response carries a session associated with the R-MACPHY.

Optionally, if the R-MACPHY associated session is stored in the MAC Manager, S512 may be directly executed to feed back the session query response to the IPDR Server. Alternatively, if the R-MACPHY associated session is not stored in the MAC Manager, as shown by the flow in the dashed box in FIG. 5, the MAC Manager sends a session query request to the R-MACPHY (S513) and receives the session query sent by the R-MACPHY A response (S514), and sends the session query response to the IPDR server (S515).

Taking the first network element in the data acquisition system shown in FIG. 3 as an R-MACPHY and the second interface protocol being a non-IPDR protocol as an example, another pre-processing flow of the embodiment of the present application is given, as shown in FIG. The other pre-processing process includes the following steps:

S701. The IPDR server sends a first version negotiation request (Version Request) to the MAC manager.

S702. The MAC manager sends a first version negotiation response (Version Response) to the IPDR server.

Correspondingly, the IPDR Server receives the first version negotiation response sent by the MAC Manager.

S703. In the case where the IPDR Server works in the active mode, the IPDR Server sends a TCP connection request to the MAC Manager.

S704. In a case where the IPDR server works in the active mode, the IPDR server sends an IPDR connection request to the MAC Manager.

S705. The MAC Manager sends an IPDR connection response to the IPDR Server.

Correspondingly, the IPDR server receives the IPDR connection response sent by the MAC Manager.

S706. The IPDR server sends a session query request to the MAC manager.

S707. The MAC Manager sends a session query response to the IPDR Server.

For a detailed description of the process shown in FIG. 7, refer to the description of the process shown in FIG.

The embodiment of the present application provides a data collection method. When the second interface protocol is the IPDR protocol, based on the preprocessing process shown in FIG. 5, and as shown in FIG. 8, the data collection method provided in the embodiment of the present application, It includes the following steps:

S801. The IPDR server sends a first message encapsulated in a first interface protocol format to the MAC manager.

Correspondingly, the MAC Manager receives the first message sent by the IPDR Server.

The first interface protocol is the IPDR protocol.

Optionally, the first message may be an IPDR session control message, and the first message carries an IPDR server identifier and is used to address an R-MACPHY associated with the IPDR server. The IPDR server identification includes but is not limited to the IP address of the IPDR server and the MAC address of the IPDR server identification.

S802. The MAC manager encapsulates the first message according to the second interface protocol format to obtain the second message.

Specifically, based on the process shown in FIG. 5, the MAC Manager learns that the first protocol version is different from the second protocol version after the protocol version negotiation. At this time, S802 can be implemented as follows: The MAC Manager encapsulates the first message from the first The encapsulation format corresponding to the protocol version is changed to the encapsulation format corresponding to the second protocol version to obtain a second message. As described above, the first message carries the IPDR server identifier, and accordingly, the re-encapsulated second message also carries the IPDR server identifier.

For example, in the preprocessing process shown in FIG. 5, the MAC Manager finds that the IPDR protocol version between the MAC Manager and the IPDR Server is IPDR 2.0, and the IPDR protocol version between the MAC Manager and the R-MACPHY is IPDR 1.0. Subsequently, the MAC Manager receives the first message of the IPDR 2.0 version, parses the first message, and repackages the first message according to the format of the IPDR 1.0 to obtain the second message.

S803. The MAC manager determines at least one R-MACPHY associated with the IPDR server according to the second message.

In the embodiment of the present application, the MAC Manager stores the association relationship between the IPDR server and the R-MACPHY. Exemplarily, as shown in FIG. 4, the memory 403 of the MAC Manager stores an association table of the IPDR server ID and the R-MACPHY ID. In this way, the MAC Manager may query the stored association table according to the IPDR server identifier carried in the second message to determine one or more R-MACPHYs to which the IPDR server is associated.

S804. The MAC manager sends a second message to at least one R-MACPHY, respectively.

Accordingly, the R-MACPHY receives the second message from the MAC Manager.

The second message is used to request data collected by at least one R-MACPHY.

S805. The R-MACPHY sends the first data encapsulated in the second interface protocol format to the MAC Manager.

Correspondingly, the MAC Manager receives the first data sent by the R-MACPHY.

Optionally, the first data includes, but is not limited to, the CM operating state, CM-related charging information, spectrum information of uplink and downlink channels of the link where the CM is located, and debugging information of the CM. As a possible implementation manner, the first data carries an R-MACPHY identifier and is used to address an IPDR server associated with the R-MACPHY.

S806. The MAC Manager encapsulates the first data according to the first interface protocol format to obtain the second data.

Specifically, the first protocol version between the MAC Manager and the IPDR server is different from the second protocol version between the MAC Manager and the R-MACPHY. S806 can be implemented as follows: The MAC Manager converts the first data encapsulation format from the second protocol version. The corresponding encapsulation format is modified to the encapsulation format corresponding to the first protocol version to obtain second data, where the second data carries the R-MACPHY identifier.

S807. The MAC manager determines the IPDR server associated with the R-MACPHY according to the second data.

As a possible implementation manner, the MAC Manager queries the association table shown in FIG. 4 according to the R-MACPHY identifier carried in the second data to determine the IPDR Server associated with the R-MACPHY.

S808. The MAC Manager sends the second data to the IPDR Server.

According to the data collection method provided in the embodiment of the present application, after receiving the first message encapsulated in the first interface protocol format sent by the third network element, the second network element repackages the first message according to the second interface protocol format to obtain the first message. Two messages and sending the second message to the first network element to trigger the first network element to send the collected first data to the second network element. After obtaining the first data, the second network element repackages the first data according to the first interface protocol format to obtain the second data, so that the second data can be carried in the transmission channel between the second network element and the third network element, Thus, the data collected by the first network element is successfully transmitted to the third network element via the second network element. It can be seen that, in the data collection method of the embodiment of the present application, each segment of the transmission channel can transmit data or messages consistent with the format of the channel, which improves the probability of successfully transmitting data or messages in the channel, thereby improving the success rate of data collection. .

An embodiment of the present application further provides a data collection method. When the second interface protocol is a non-IPDR protocol, based on the preprocessing process shown in FIG. 7, as shown in FIG. 9, the data collection method includes the following steps: :

S901. The IPDR server sends a first message encapsulated in a first interface protocol format to the MAC Manager.

S902. The MAC Manager encapsulates the first message according to the second interface protocol format to obtain a second message.

Specifically, S902 can be implemented as follows: The MAC Manager changes the encapsulation format of the first message from the encapsulation format corresponding to the first protocol version to the corresponding one of the second interface protocols except the IPDR protocol (that is, non-IPDR protocol). Encapsulated format to get the second message.

For example, the second interface protocol is the GRPC protocol. In the preprocessing process shown in FIG. 7, it is found that the IPDR protocol version between the MAC Manager and the IPDR Server is IPDR 2.0. Subsequently, the MAC Manager receives the first message of the IPDR 2.0 version, parses the first message, and repackages the first message according to the GRPC format to obtain the second message.

S903. The MAC manager determines at least one R-MACPHY associated with the IPDR server according to the second message.

S904. The MAC Manager establishes a connection with the R-MACPHY.

Exemplarily, if the second interface protocol is the GRPC protocol, the MAC Manager establishes a GRPC connection with the R-MACPHY.

Optionally, the MAC Manager can establish a GRPC connection with the R-MACPHY in any of the following two ways:

Method 1: The MAC Manager actively sends a GRPC connection request to the R-MACPHY to establish a GRPC connection.

In this way, R-MACPHY can collect data periodically and upload the collected data to a designated device. If the specified device is not configured, R-MACPHY uploads the collected data to MAC Manager by default. And, in the method 1, if the GRPC connection between the MAC Manager and the R-MACPHY is disconnected, the R-MACPHY no longer pushes the collected data upwards.

Method 2: The MAC Manager receives a GRPC connection request initiated by the R-MACPHY to establish a GRPC connection with the R-MACPHY.

In method 2, if the GRPC connection between the MAC Manager and R-MACPHY is disconnected, R-MACPHY will retry to establish a GRPC connection and upload the collected data to the MAC Manager.

It should be noted that the MAC Manager can also trigger the action of establishing a connection with the R-MACPHY after receiving the first message (ie, S901) from the IPDR Server, or it can be executed after S902 or simultaneously with S902. This embodiment of the present application is not correct. The execution timing of S904 is restricted.

S905. Send second messages to at least one R-MACPHY, respectively.

Accordingly, the R-MACPHY receives the second message from the IPDR server.

S906. The R-MACPHY sends the first data encapsulated in the second interface protocol format to the MAC Manager.

Correspondingly, the MAC Manager receives the first data sent by the R-MACPHY.

S907. The MAC Manager encapsulates the first data according to the first interface protocol format to obtain the second data.

Specifically, S907 can be implemented as follows: The MAC Manager changes the encapsulation format of the first data from the encapsulation format corresponding to any protocol in the second interface protocol except the IPDR protocol to the encapsulation format corresponding to the first protocol version to obtain the second data. For example, if the second interface protocol is the GRPC protocol and the first protocol version is IPDR 2.0, the MAC Manager decapsulates the first data after receiving the first data in the GRPC format, and decapsulates the first data. Re-encapsulate according to the IPDR 2.0 format to obtain the second data.

S908. The MAC manager determines the IPDR server associated with the R-MACPHY according to the second data.

S909. The MAC Manager sends the second data to the IPDR Server.

For a detailed description of the data collection process shown in FIG. 9, refer to the process shown in FIG. 8, and details are not described herein again.

With the above data collection method, data or messages encapsulated in the IPDR protocol format are transmitted between the second network element and the third network element, and data or messages encapsulated in the non-IPDR protocol format are transmitted between the second network element and the third network element, so that The data or message format is adapted to the transmission channel carrying the data or message, and the success rate of data collection is improved.

It should be noted that the first interface protocol in the embodiment of the present application is not limited to the IPDR protocol, and may also be an evolved protocol of the IPDR protocol, or another protocol having the same function as the IPDR protocol. Similarly, the second interface protocol is not limited to the above-listed protocols, but may also be an evolved version of the listed protocols, or other protocols having the same functions as the listed protocols.

It can be understood that, in order to implement the foregoing functions, the network element in the embodiment of the present application includes a hardware structure and / or a software module corresponding to each function. With reference to the units and algorithm steps of each example described in the embodiments disclosed in this application, the embodiments of this application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is performed by hardware or computer software-driven hardware depends on the specific application of the technical solution and design constraints. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the technical solutions of the embodiments of the present application.

In the embodiment of the present application, functional unit division may be performed on the network element according to the foregoing method example. For example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional unit. It should be noted that the division of the units in the embodiments of the present application is schematic, and is only a logical function division. There may be another division manner in actual implementation.

FIG. 10 shows a schematic block diagram of a data acquisition device provided in an embodiment of the present application, and the data acquisition device may be the foregoing second network element. The data acquisition device 1000 may exist in the form of software, or may be a chip that can be used in a device. The data acquisition device 1000 includes a processing unit 1002 and a communication unit 1003.

The processing unit 1002 may be used to support the second network element to perform S802, S803, S806, S807 in FIG. 8, S902, S903, S907, S908, etc. in FIG. 9, and / or other processes for the scheme described herein . The communication unit 1003 is configured to support communication between the second network element and other network elements (for example, the first network element and the third network element described above). For example, the second network element supports S501 to S512 in FIG. 5 and FIG. 7. S701 to S707, S801, S804, S805, and S808 in FIG. 8, S901, S904, S905, S906, and S909 in FIG. 9.

Optionally, the data acquisition device 1000 may further include a storage unit 1001 for storing program codes and data of the data acquisition device 1000. The data may include, but is not limited to, original data or intermediate data.

In a possible manner, the processing unit 1002 may be a controller or the processor 401 or the processor 405 shown in FIG. 4, for example, it may be a central processing unit (CPU), a general-purpose processor, and digital signal processing ( Digital Signal Processing (DSP), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any of them combination. It may implement or execute various exemplary logical blocks, modules, and circuits described in connection with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, and so on. The communication unit 1003 may be a transceiver, a transceiver circuit, or the communication interface 404 shown in FIG. 4 and the like. The storage unit 1001 may be a memory 403 shown in FIG. 4.

A person of ordinary skill in the art may understand that in the foregoing embodiments, all or part may be implemented by software, hardware, firmware, or any combination thereof. When implemented in software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be from a website site, computer, server, or data center Transmission to another website site, computer, server or data center via wired (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, and the like including one or more available medium integration. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a Digital Video Disc (DVD)), or a semiconductor medium (for example, a solid state disk (Solid State Disk, SSD)) )Wait.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the unit is only a logical function division. In actual implementation, there may be another division manner. For example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be electrical or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, which may be located in one place, or may be distributed to multiple network devices (for example, Terminal device). Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each functional unit may exist independently, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware, or in the form of hardware plus software functional units.

Through the description of the above embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general hardware, and of course, also by hardware, but in many cases the former is a better implementation. . Based on such an understanding, the technical solution of this application that is essentially or contributes to the existing technology can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer's floppy disk , A hard disk or an optical disc, etc., includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments of the present application.

The above description is only a specific implementation of the present application, but the scope of protection of the present application is not limited thereto, and changes or replacements within the technical scope disclosed in the present application shall be covered by the protection of the present application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims.

Claims

A data collection method, comprising:

The second network element receives the first message encapsulated in the first interface protocol format sent by the third network element, and encapsulates the first message according to the second interface protocol format to obtain a second message. The first interface protocol is the Internet. Record the IPDR protocol in detail. The second interface protocol includes a state transfer configuration restconf protocol, a network configuration netconf protocol, a simple network management protocol SNMP, and a remote procedure call RPC protocol.

Determining, by the second network element, at least one first network element associated with the third network element according to the second message, and sending a second message to the at least one first network element, the second message, respectively Configured to request data collected by the at least one first network element;

Receiving, by the second network element, first data sent by the first network element and encapsulated in the second interface protocol format, and encapsulating the first data according to the first interface protocol format to obtain second data, where The first network element is any one of the at least one first network element;

The second network element determines the third network element associated with the first network element according to the second data, and sends the second data to the third network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

Receiving, by the second network element, a first version negotiation request sent by the third network element, where the first version negotiation request is used to request to negotiate a first protocol version, and the first protocol version is the second network element An IPDR protocol version with the third network element;

Sending, by the second network element, a first version negotiation response to the third network element, where the first version negotiation response carries a first protocol version;

Alternatively, the second network element sends the first version negotiation request to the third network element;

Receiving, by the second network element, a first version negotiation response sent by the third network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

Sending, by the second network element, a second version negotiation request to the first network element, where the second version negotiation request is used to request to negotiate a second protocol version, and the second protocol version is An IPDR protocol version between the first network elements;

Receiving, by the second network element, a second version negotiation response sent by the first network element, where the second version negotiation response carries a second protocol version;

Or, the second network element receives a second version negotiation request sent by the first network element;

The second network element sends a second version negotiation response to the first network element.
The data collection method according to claim 2 or 3, wherein the second network element encapsulates the first message according to a second interface protocol format to obtain a second message, comprising:

If the first protocol version is different from the second protocol version, the second network element changes the encapsulation format of the first message from the encapsulation format corresponding to the first protocol version to the encapsulation format corresponding to the second protocol version. To get the second message.
The data collection method according to claim 2 or 3, wherein the second network element encapsulates the first data according to the first interface protocol format to obtain second data, comprising:

If the first protocol version is different from the second protocol version, the second network element changes the encapsulation format of the first data from the encapsulation format corresponding to the second protocol version to the encapsulation format corresponding to the first protocol version. To obtain the second data.
The data collection method according to claim 1 or 2, wherein the second network element encapsulates the first message according to a second interface protocol format to obtain a second message, comprising:

Modifying, by the second network element, an encapsulation format of the first message from an encapsulation format corresponding to the first protocol version to an encapsulation format corresponding to any protocol other than the IPDR protocol in the second interface protocol To get the second message.
The data collection method according to claim 1 or 2, wherein the second network element encapsulates the first data according to the first interface protocol format to obtain second data, comprising:

Modifying, by the second network element, the encapsulation format of the first data from an encapsulation format corresponding to any protocol other than the IPDR protocol in the second interface protocol to an encapsulation format corresponding to the first protocol version To obtain the second data.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

When the third network element works in an active mode, the second network element receives a Transmission Control Protocol TCP connection request sent by the third network element, and the TCP connection request is used to request establishment of the third network element. A TCP connection between the network element and the second network element;

Alternatively, when the third network element works in a passive mode, the second network element sends a TCP connection request to the third network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

In a case where the second network element works in an active mode, the second network element sends a TCP connection request to the first network element, and the TCP connection request is used to request establishment of the second network element and all network elements. The TCP connection between the first network elements;

Alternatively, when the second network element works in a passive mode, the second network element receives a TCP connection request sent by the first network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

In a case where the third network element works in a passive mode, the second network element sends an IPDR connection request to the third network element, and the IPDR connection request is used to request establishment of the third network element and all network elements. The IPDR connection between the second network elements;

Receiving, by the second network element, an IPDR connection response sent by the third network element;

Alternatively, when the third network element works in an active mode, the second network element receives an IPDR connection request sent by the third network element;

The second network element sends an IPDR connection response to the third network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

In a case where the second network element works in a passive mode, the second network element receives an IPDR connection request sent by the first network element, and the IPDR connection request is used to request establishment of the first network element and all network elements. The IPDR connection between the second network elements;

Sending, by the second network element, an IPDR connection response to the third network element;

Alternatively, when the second network element works in an active mode, the second network element sends an IPDR connection request to the first network element;

Receiving, by the second network element, an IPDR connection response sent by the first network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

Receiving, by the second network element, a session query request sent by the third network element, where the session query request is used to request to query a session associated with the first network element;

The second network element sends a session query response to the third network element, and the session query response carries a session associated with the first network element.
The data collection method according to claim 1, wherein before the second network element receives a first message encapsulated in a first interface protocol format sent by a third network element, the method further comprises:

Sending, by the second network element, a session query request to the first network element, where the session query request is used to request to query a session associated with the first network element;

The second network element receives a session query response sent by the first network element, and the session query response carries a session associated with the first network element.
A data acquisition device, characterized in that the device is provided with a transceiver and a processor;

The transceiver is configured to receive a first message encapsulated in a first interface protocol format sent by a third network element;

The processor is configured to encapsulate the first message received by the transceiver according to a second interface protocol format to obtain a second message, the first interface protocol is an Internet detailed record IPDR protocol, and the second interface protocol Including characterization state transfer configuration restconf protocol, network configuration netconf protocol, simple network management protocol SNMP, remote procedure call RPC protocol;

The processor is further configured to determine at least one first network element associated with the third network element according to the second message;

The transceiver is further configured to separately send a second message to the at least one first network element, where the second message is used to request data collected by the at least one first network element; and receive the first network element sends The first data encapsulated in the second interface protocol format;

The processor is further configured to encapsulate the first data according to the first interface protocol format to obtain second data, and the first network element is any one of the at least one first network element. Element; determining the third network element associated with the first network element according to the second data;

The transceiver is further configured to send the second data to the third network element.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to receive a first version negotiation request sent by the third network element, where the first version negotiation request is used to request to negotiate a first protocol version, and the first protocol version is the second An IPDR protocol version between the network element and the third network element; sending a first version negotiation response to the third network element, where the first version negotiation response carries the first protocol version;

Alternatively, the transceiver is further configured to send the first version negotiation request to the third network element; and receive the first version negotiation response sent by the third network element.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to send a second version negotiation request to the first network element, where the second version negotiation request is used to request to negotiate a second protocol version, and the second protocol version is the second network An IPDR protocol version between the element and the first network element; receiving a second version negotiation response sent by the first network element, where the second version negotiation response carries a second protocol version;

Alternatively, the transceiver is further configured to receive a second version negotiation request sent by the first network element; and send a second version negotiation response to the first network element.
The data acquisition device according to claim 15 or 16, wherein the processor is configured to encapsulate the first message according to a second interface protocol format to obtain a second message, including: The version is different from the second protocol version, and the encapsulation format of the first message is modified from the encapsulation format corresponding to the first protocol version to the encapsulation format corresponding to the second protocol version to obtain the second message.
The data acquisition device according to claim 15 or 16, wherein the processor is configured to encapsulate the first data according to the first interface protocol format to obtain second data, including: A protocol version is different from a second protocol version, and an encapsulation format of the first data is modified from an encapsulation format corresponding to the second protocol version to an encapsulation format corresponding to the first protocol version to obtain the second data.
The data acquisition device according to claim 14 or 15, wherein the processor is configured to encapsulate the first message according to a second interface protocol format to obtain a second message, including: The encapsulation format of a message is changed from the encapsulation format corresponding to the first protocol version to the encapsulation format corresponding to any protocol other than the IPDR protocol in the second interface protocol to obtain a second message.
The data acquisition device according to claim 14 or 15, wherein the processor is configured to encapsulate the first data according to the first interface protocol format to obtain second data, and includes: The encapsulation format of the first data is changed from an encapsulation format corresponding to any protocol in the second interface protocol except the IPDR protocol to an encapsulation format corresponding to the first protocol version to obtain the second data.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to receive a Transmission Control Protocol TCP connection request sent by the third network element when the third network element works in an active mode, and the TCP connection request is used to request establishment of the TCP connection request. A TCP connection between the third network element and the second network element;

Alternatively, the transceiver is further configured to send a TCP connection request to the third network element when the third network element works in a passive mode.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to send a TCP connection request to the first network element when the second network element works in an active mode, and the TCP connection request is used to request establishment of the second network element A TCP connection with the first network element;

Alternatively, the transceiver is further configured to receive a TCP connection request sent by the first network element when the second network element works in a passive mode.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to: when the third network element works in a passive mode, send an IPDR connection request to the third network element, and receive an IPDR connection response sent by the third network element; the The IPDR connection request is used to request to establish an IPDR connection between the third network element and the second network element;

Alternatively, the transceiver is further configured to receive an IPDR connection request sent by the third network element when the third network element works in an active mode; and send an IPDR connection response to the third network element.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to: when the second network element works in a passive mode, receive an IPDR connection request sent by the first network element, and send an IPDR connection response to the third network element; the IPDR A connection request is used to request to establish an IPDR connection between the first network element and the second network element;

Alternatively, the transceiver is further configured to send an IPDR connection request to the first network element when the second network element works in an active mode; and receive an IPDR connection response sent by the first network element.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to receive a session query request sent by the third network element, and send a session query response to the third network element; the session query request is used to request a query of the first network element association. Session; the session query response carries a session associated with the first network element.
The data acquisition device according to claim 14, wherein:

The transceiver is further configured to send a session query request to the first network element, and receive a session query response sent by the first network element; the session query request is used to request a query of the first network element association. Session; the session query response carries a session associated with the first network element.
A readable storage medium, comprising a program or an instruction, and when the program or the instruction is executed, the data collection method according to any one of claims 1 to 13 is implemented.
A chip, characterized in that the chip includes a processor, the processor is coupled to a memory, the memory stores program instructions, and the program instruction stored in the memory is implemented when the processor executes claim 1 The data collection method according to any one of 13 to 13.