Patent Description:
In a distributed converged cable access platform (D-CCAP) scenario, an Internet protocol detail record (IPDR) may provide a statistics collecting and reporting mechanism and statistics information that are defined in a data over cable service interface specification (DOCSIS) standard.

As copper access evolves to optical access, as a typical solution of a multiple system operator (MSO), a hybrid networking scenario of a passive optical network (PON) and a D-CCAP has been widely applied. According to a definition of the IPDR, a CMTS device may send collected CM data to an IPDR server. However, a statistics collecting and reporting manner of ONT data lacks a uniform standard.

<CIT> relates to method and system for transporting DOCSIS communication signals over a passive optical network. <CIT> relates to data over cable service interface specification (DOCSIS) over passive optical network (PON).

"<NPL>, relates to operational support system interface in converged cable access platform.

Embodiments of this application provide a data transmission method and a related device, to reduce power consumption of a management server configured to manage ONT data.

In view of this, a first aspect of this application provides a data transmission method, including:
an OLT obtains a data template; then the OLT may obtain corresponding ONT data based on one or more data types defined in the data template; and then the OLT encodes the ONT data according to an XDR format and sends encoded ONT data to a management server; and the management server stores and manages the ONT data.

In this implementation, the OLT collects the corresponding ONT data based on the data template, and encodes and reports the ONT data according to the uniform XDR format. This application defines a unified statistics collecting and reporting manner of ONT data and uses standardly-defined ONT data, to help the management server store and manage the ONT data.

The management server is specifically an IPDR server. According to a definition of the DOCSIS standard, the IPDR server may be configured to store CM data collected by a CMTS device in a D-CCAP scenario. Therefore, in a hybrid networking scenario of a PON and a D-CCAP, the IPDR server is also configured to store ONT data collected by an OLT. In this way, a management server dedicated to storing and managing ONT data does not need to be configured. This reduces network deployment costs.

Optionally, in some possible implementations, the OLT may further receive cable modem (CM) data sent by a cable modem termination system (CMTS) device, and then the OLT encodes the CM data according to the XDR format, and sends encoded CM data to the IPDR server.

In this implementation, in the hybrid networking scenario of the PON and the D-CCAP, the CM data is also reported to the IPDR server by using the OLT. Therefore, the IPDR server may store and manage the ONT data and the CM data. In addition, an XDR encoding manner is used for both the ONT data and the CM data. This improves scalability of this solution.

Optionally, in some possible implementations, the OLT receives CM data sent by a CMTS device, where the CM data is encoded by the CMTS device according to XDR. Therefore, the OLT directly forwards the CM data to the IPDR server without encoding the CM data.

In this implementation, alternatively, the CMTS device may perform XDR encoding on CM data. This improves flexibility of this solution.

Optionally, in some possible implementations, the data template includes at least two of a media access control (MAC) address of an ONT, an online status of the ONT, last registration time of the ONT, an identifier of an ONT service flow, a traffic template of the ONT service flow, a direction of the ONT service flow, a quantity of forwarded bytes of the ONT service flow, a quantity of forwarded packets of the ONT service flow, and a quantity of discarded packets of the ONT service flow. It may be understood that, in addition to the foregoing listed ONT data types in the data template, in an actual application, the data template may further include another ONT data type. This is not specifically limited herein.

In this implementation, the OLT collects the ONT data based on the data template. Because the data template includes a plurality of ONT data types, the OLT may collect the plurality of types of ONT data at one time and jointly report the plurality of types of ONT data to the management server. Therefore, the management server does not need to send one query request to the OLT for each type of ONT data, thereby reducing power consumption of the management server.

In this aspect, that an OLT obtains a data template includes:
the OLT receives the data template sent by the management server.

Thus, the OLT obtains the data template, that is, the OLT receives the data template sent by the management server. The management server centrally delivers the data template to the OLT, thereby improving practicality of this solution.

A second aspect of this application provides an OLT, including:.

The management server is an IPDR server.

Optionally, in some possible implementations, the second obtaining unit is further configured to:.

Optionally, in some possible implementations, the data template includes at least two of a MAC address of the ONT, an online status of the ONT, last registration time of the ONT, an identifier of an ONT service flow, a traffic template of the ONT service flow, a direction of the ONT service flow, a quantity of forwarded bytes of the ONT service flow, a quantity of forwarded packets of the ONT service flow, and a quantity of discarded packets of the ONT service flow.

In this aspect, the first obtaining unit is specifically configured to:
receive the data template sent by the management server.

A third aspect of this application provides an OLT, including:.

A fourth aspect of the implementations of this application provides a computer program product including instructions. When the computer program product runs on a computer, the computer is enabled to perform the processes in the data transmission method according to the first aspect.

It can be learned from the foregoing technical solutions that, the implementations of this application have the following advantages:.

In the implementations of this application, the OLT obtains the data template; then the OLT may obtain the corresponding ONT data based on one or more data types defined in the data template; and then the OLT encodes the ONT data according to the XDR format and sends the encoded ONT data to the management server; and the management server stores and manages the ONT data. According to the foregoing description, the OLT collects the corresponding ONT data based on the data template, and encodes and reports the ONT data according to the uniform XDR format. This application defines a unified statistics collecting and reporting manner of ONT data and uses standardly-defined ONT data, to help the management server store and manage the ONT data.

Current broadband access technologies are mainly categorized into copper access technologies (for example, various DSL technologies) and optical access technologies. The copper access technology may include various digital subscriber line (DSL) technologies. An access network implemented by using the optical access technology is referred to as an optical access network (OAN).

A passive optical network (PON) is an implementation technology of the optical access network, and the PON is an optical access technology of point-to-multipoint transmission.

This application mainly provides an ONT data collection process applied to a PON scenario or a hybrid networking scenario of a PON and a D-CCAP. The following separately describes the data transmission method in the implementations of this application with reference to the two scenarios.

<FIG> is a diagram of a system architecture applied to the PON scenario according to an implementation of this application.

An optical line terminal (OLT) (<NUM>) is configured to provide a network side interface for an OAN. The OLT (<NUM>) is connected to an upper-layer management server (<NUM>), and is connected to one or more optical distribution networks (ODN) (<NUM>) at a lower layer.

The ODN (<NUM>) includes an optical splitter (<NUM>) configured to split optical power, a feeder fiber connected between the optical splitter (<NUM>) and the OLT (<NUM>), and distribution fibers connected between the optical splitter (<NUM>) and optical network terminals (optical network terminal, ONT) (<NUM>). During downlink data transmission, the ODN (<NUM>) transmits downlink data of the OLT (<NUM>) to the ONTs (<NUM>) by using the optical splitter (<NUM>). Likewise, during uplink data transmission, the ODN (<NUM>) converges uplink data of the ONTs (<NUM>) and then transmits converged uplink data to the OLT (<NUM>). The ONT (<NUM>) provides a user side interface for the OAN, and is also connected to the ODN (<NUM>).

It should be noted that the management server (<NUM>) in this implementation of this application is dedicated to storing and managing ONT data. The management server (<NUM>) may be a network management device that performs a network management task such as network planning or network monitoring. Specifically, the ONTs (<NUM>) may report ONT data to the OLT (<NUM>) by using the ODN (<NUM>); the OLT (<NUM>) encodes the collected ONT data in a uniform format and then sends encoded ONT data to the management server (<NUM>); and the management server (<NUM>) stores and manages the ONT data.

For ease of understanding, the following describes a specific process in the implementations of this application in detail. Refer to <FIG>. An implementation of the data transmission method in this application includes the following steps.

According to the claimed invention, the OLT receives the data template sent by a management server. The data templateindicates at least two data types associated with an ONT. It should be noted that the OLT may alternatively obtain the data template in another manner, for example, by preconfiguring the data template. This is not specifically limited herein. For the ONT data types in the data template, refer to Table <NUM>.

It can be seen from Table <NUM> that, the data template includes at least two of the media access control (MAC) address of the ONT, the online status of the ONT, the last registration time of the ONT, the identifier of the ONT service flow, the traffic template of the ONT service flow, the direction of the ONT service flow, the quantity of forwarded bytes of the ONT service flow, the quantity of forwarded packets of the ONT service flow, and the quantity of discarded packets of the ONT service flow. The data template may further include some information associated with the OLT, such as the OLT device name and the OLT start time.

It should be noted that the data template listed in Table <NUM> does not include all ONT data types in this application. For details, refer to a definition of a CM data type in a current DOCSIS. That is, the ONT in the data template in this application corresponds to a CM in the DOCSIS standard. In addition to the ONT data types, the data template further includes other items corresponding to the ONT data types (for example, a character data type, a data length, and an XDR object that correspond to each type of ONT data). For details, refer to an IPDR data collection template defined in the DOCSIS. That is, parameters such as the character data type and the data length that correspond to the ONT data in the data template defined in this application is consistent with parameters such as a character data type and a data length that correspond to CM data in the IPDR data collection template defined in the DOCSIS.

The OLT obtains ONT data based on the data template.

In this implementation, one OLT may manage a plurality of ONTs. The OLT broadcasts a message to all the managed ONTs to request the ONTs to report ONT data, and then the ONTs send ONT data of the ONTs to the OLT by using a time division multiple access (TDMA) technology. Specifically, the OLT fills, based on the data template, ONT data corresponding to each data type.

The OLT sends the ONT data to the management server.

In this implementation, after collecting the ONT data, the OLT encodes the ONT data in a uniform format, and then send encoded ONT data to the management server; and the management server stores and manages the ONT data. Specifically, an encoding manner is external data representation (XDR). The OLT may jointly package ONT data filled in the data template and send packaged ONT data to the management server. Certainly, the OLT may alternatively send the ONT data to the management server in batches based on different requirements. This is not specifically limited herein.

Optionally, the OLT may establish a connection to the management server in a plurality of manners, for example, in an active mode or a passive mode. This is not specifically limited herein. The active mode means that the OLT actively initiates a connection request to the management server; and the management server listens to a status of a port connected to the OLT, and after receiving the request, the management server makes a response and establishes a connection. The passive mode means that the management server actively initiates a connection request to the OLT; and the OLT listens to a status of a port connected to the management server, and after receiving the request, the OLT makes a response and establishes a connection.

Optionally, the OLT may send the ONT data to the management server in a plurality of manners, for example, may periodically report the ONT data to the management server or report the ONT data to the management server at one time. This is not specifically limited herein. The periodic reporting means that a statistics collecting period is configured for the OLT. When the statistics collecting period starts, the OLT may send a session start message to the management server, to identify start of data reporting of the statistics collecting period, and then the OLT sends collected ONT data to the management server. When the statistics collecting period ends, the OLT sends a session end message to the management server, to identify end of the data reporting of the statistics collecting period. It may be understood that the statistics collecting period may be delivered by the management server to the OLT, or may be locally configured in the OLT. This is not specifically limited herein. The one-time reporting means that the management server initiates a statistics collecting session, and then the OLT sends collected ONT data to the management server according to an indication of the statistics collecting session. The statistics collecting session may be a logical connection between the OLT and the management server, for completing data transmission and recording. There may be a plurality of statistics collecting sessions between the OLT and the management server, and different statistics collecting sessions are distinguished from each other by using session identifiers.

It should be noted that after receiving the ONT data sent by the OLT, the management server may locally store the ONT data, and forward the ONT data to an MSO background running system. The MSO background running system (such as an OSS or a BSS) may analyze the ONT data to meet a related requirement of an operator, such as charging.

In this implementation of this application, the OLT obtains the data template; then the OLT may obtain the corresponding ONT data based on one or more data types defined in the data template; and then the OLT encodes the ONT data according to an XDR format and sends the encoded ONT data to the management server; and the management server stores and manages the ONT data. According to the foregoing description, the OLT collects the corresponding ONT data based on the data template, and encodes and reports the ONT data according to the uniform XDR format. This application defines a unified statistics collecting and reporting manner of ONT data and uses standardly-defined ONT data, to help the management server store and manage the ONT data.

Second scenario: Hybrid networking scenario of a PON and a D-CCAP.

The foregoing mainly describes the process in which the OLT sends the ONT data to the management server in the PON scenario. It may be understood that, as copper access evolves to optical access, as a typical solution of an MSO, the hybrid networking scenario of the PON and the D-CCAP has been widely applied.

<FIG> is a diagram of a system architecture applied to a hybrid networking scenario of a PON and a D-CCAP according to an implementation of this application.

The hybrid networking scenario of the PON and the D-CCAP may include a CM (<NUM>), a CMTS device (<NUM>), an ONT (<NUM>), an OLT (<NUM>), an IPDR server (<NUM>), and a management server (<NUM>). The CMTS device (<NUM>) is configured to: collect CM data from the CM (<NUM>), and encode the CM data and then send encoded CM data to the OLT (<NUM>), and the OLT (<NUM>) sends the encoded CM data to the IPDR server (<NUM>). The OLT (<NUM>) may collect ONT data from the ONT (<NUM>), and encode the ONT data and then send encoded ONT data to the management server (<NUM>). It can be learned that the IPDR server (<NUM>) and the management server (<NUM>) are respectively configured to manage the CM data and the ONT data.

In addition, in the hybrid networking scenario of the PON and the D-CCAP, the management server (<NUM>) may be specifically the IPDR server (<NUM>), that is, the IPDR server is further configured to manage the ONT data in addition to the CM data. The management server (<NUM>) and the IPDR server (<NUM>) are no longer separated, so that network deployment costs can be reduced to a specific extent.

Therefore, the following mainly describes an implementation in which the management server (<NUM>) is specifically the IPDR server (<NUM>) in the hybrid networking scenario of the PON and the D-CCAP.

Refer to <FIG>. Another implementation of the data transmission method in this application includes the following steps.

The OLT sends the ONT data to an IPDR server.

In this implementation, steps <NUM> to <NUM> are similar to steps <NUM> to <NUM> in the implementation shown in <FIG>. However, in the implementation shown in <FIG>, the management server interacts with the OLT, and in the implementation shown in <FIG>, the IPDR server interacts with the OLT.

In this implementation, the CMTS device may collect the CM data in a manner defined in a DOCSIS standard. For example, the CMTS device may receive a data template that is about the CM data and that is sent by the IPDR server, and then the CMTS device collects the corresponding CM data based on the data template.

The CMTS device sends the CM data to the OLT.

In this implementation, it can be learned from the network structure shown in <FIG> that the CMTS device is a cascaded device of the OLT, that is, data of the CMTS device needs to be reported by using the OLT. Therefore, the CMTS device needs to first send the collected CM data to the OLT. Specifically, the CMTS device may encode the CM data in a uniform format, and send encoded CM data to the OLT. An encoding manner may be XDR. It may be understood that the CM data and the ONT data are encoded in a same encoding manner.

It should be noted that, in the hybrid networking scenario of the PON and the D-CCAP, the CMTS device and the OLT may be devices independent of each other, or may be aggregated as an optical-copper integrated access device, that is, the CMTS device and the OLT device are externally virtualized as an independent access device to interact with the IPDR server. This is not specifically limited herein.

The OLT sends the CM data to the IPDR server.

In this implementation, the OLT may forward the received CM data to the IPDR server. It may be understood that, if the CMTS device does not encode the CM data in step <NUM>, the OLT may alternatively encode the CM data after receiving the CM data. This is not specifically limited herein.

It should be noted that there is no fixed time sequence relationship between steps <NUM> to <NUM> and steps <NUM> to <NUM>. Steps <NUM> to <NUM> may be first performed, steps <NUM> to <NUM> may be first performed, or steps <NUM> to <NUM> and steps <NUM> to <NUM> may be simultaneously performed. This is not specifically limited herein. In addition, the OLT may jointly package the CM data and the ONT data and send packaged data to the IPDR server, or may separately package the CM data and the ONT data and send packaged CM data and packaged ONT data to the IPDR server. This is not specifically limited herein.

In this implementation of this application, in the hybrid networking scenario of the PON and the D-CCAP, as a management server, the IPDR server may store and manage the CM data collected by the CMTS device, and may further store and manage the ONT data collected by the OLT. The management server and the IPDR server are no longer separated. This reduces network deployment costs.

The data transmission method in the implementations of this application is described above, and the OLT in the implementations of this application is described below.

Refer to <FIG>. An implementation of the OLT in the implementations of this application includes:.

The management server includes an IPDR server.

Optionally, the second obtaining unit <NUM> is further configured to:
receive CM data sent by a CMTS device.

The encoding unit <NUM> is further configured to:
encode the CM data according to the XDR.

The sending unit <NUM> is further configured to:
send encoded CM data to the IPDR server.

Optionally, the second obtaining unit <NUM> is further configured to:
receive CM data sent by a CMTS device, where the CM data is encoded by the CMTS device according to the XDR.

The sending unit <NUM> is further configured to:
send the encoded CM data to the IPDR server.

Optionally, the data template includes at least two of a MAC address of the ONT, an online status of the ONT, last registration time of the ONT, an identifier of an ONT service flow, a traffic template of the ONT service flow, a direction of the ONT service flow, a quantity of forwarded bytes of the ONT service flow, a quantity of forwarded packets of the ONT service flow, and a quantity of discarded packets of the ONT service flow.

The first obtaining unit <NUM> is specifically configured to:
receive the data template sent by the management server.

In this implementation of this application, the first obtaining unit <NUM> obtains the data template; then the second obtaining unit <NUM> obtains the ONT data based on the data template; then the encoding unit <NUM> encodes the ONT data according to an XDR format; and the sending unit <NUM> sends the encoded ONT data to the management server. According to the foregoing description, the OLT collects the corresponding ONT data based on the data template, and encodes and reports the ONT data according to the uniform XDR format. This application defines a unified statistics collecting and reporting manner of ONT data and uses standardly-defined ONT data, to help the management server store and manage the ONT data.

The foregoing describes the OLT in the implementations of this application from a perspective of a modular functional entity. The following describes the OLT in the implementations of this application from a perspective of hardware processing.

<FIG> is a schematic diagram of a hardware structure of an OLT (<NUM>) according to this application. As shown in <FIG>, the OLT (<NUM>) mainly includes the following parts: a processor <NUM>, a memory <NUM>, a communications apparatus <NUM>, and a power management module <NUM>.

The power management module <NUM> is configured to provide a stable current for the OLT (<NUM>).

The communications apparatus <NUM> may be used by the OLT (<NUM>) to communicate with another communications device, such as a network side device, another optical line terminal, or a client device. Specifically, in this application, the network side device is a management server. A first PON interface and a second PON interface are configured in the communications apparatus <NUM>. The first PON interface is used by the OLT (<NUM>) to perform optical communication with an upper-layer device (another upper-layer optical line terminal), and the second PON interface is used by the OLT (<NUM>) to perform optical communication with a client device. Both the first PON interface and the second PON interface are ports used for connection by using a PON (passive optical network) technology. The first PON interface may include at least one of the following: an Ethernet PON (EPON) interface, a gigabit PON (GPON) interface, a <NUM> gigabit Ethernet PON (<NUM>-EPON) interface, or a future PON interface with a higher operating rate. The second PON interface may include at least one of the following: a GPON interface, an EPON interface, a symmetric <NUM>-GPON interface, an asymmetric <NUM>-GPON interface, a <NUM>-EPON interface, or a future PON interface with a higher operating rate.

In this application, the first PON interface and the second PON interface may be PON interfaces of different types, or may be PON interfaces of a same type. The following describes functions of the modules in the OLT (<NUM>).

Optionally, the first PON interface and the second PON interface may be PON interfaces of different types. The processor <NUM> is configured to perform protocol conversion processing on an optical signal that is received through the first PON interface or the second PON interface, so that a processed optical signal is applicable to the second PON interface or the first PON interface. Two conversion manners are described below.

In a first manner, protocol conversion is directly performed on the optical signal. In an optional implementation, during downlink data transmission, the processor <NUM> is configured to: parse, by using a protocol corresponding to the first PON interface, a first optical signal received by the first PON interface, and encapsulate a parsed first optical signal by using a protocol corresponding to the second PON interface, to complete protocol conversion of the first optical signal; and during uplink data transmission, the processor <NUM> is configured to: parse, by using the protocol corresponding to the second PON interface, a second optical signal received by the second PON interface, and encapsulate a parsed second optical signal by using the protocol corresponding to the first PON interface, to complete protocol conversion of the second optical signal.

In a second manner, after the optical signal is converted into an electrical signal, protocol conversion is performed on the electrical signal. In an optional implementation, the OLT (<NUM>) may further include an optical module <NUM>, a first PON MAC chip <NUM>, and a second PON MAC chip <NUM>. The first PON MAC chip <NUM> uses a protocol corresponding to the first PON interface, and the second PON MAC chip <NUM> uses a protocol corresponding to the second PON interface.

During downlink data transmission, the processor <NUM> is specifically configured to: indicate the optical module <NUM> to convert a first optical signal received through the first PON interface into a first electrical signal, indicate the first PON MAC chip <NUM> to perform protocol deframing on the first electrical signal, indicate the second PON MAC chip <NUM> to perform protocol framing on a first electrical signal obtained after the protocol deframing, and indicate the optical module <NUM> to perform electrical-to-optical conversion on a first electrical signal obtained after the protocol framing, to obtain a processed first optical signal. In this way, protocol conversion of the first optical signal is completed.

During uplink data transmission, the processor <NUM> is specifically configured to: indicate the optical module <NUM> to convert a second optical signal received through the second PON interface into a second electrical signal, indicate the second PON MAC chip <NUM> to perform protocol deframing on the second electrical signal, indicate the first PON MAC chip <NUM> to perform protocol framing on a second electrical signal obtained after the protocol deframing, and indicate the optical module <NUM> to perform electrical-to-optical conversion on a second electrical signal obtained after the protocol framing, to obtain a processed second optical signal. In this way, protocol conversion of the second optical signal is completed.

(<NUM>) The first PON interface and the second PON interface are PON interfaces of a same type.

When the first PON interface and the second PON interface are of a same type, the optical line terminal may perform processing such as denoising and signal enhancement on a received signal by using the processor, to improve signal transmission reliability.

Optionally, an Ethernet interface may be further configured for the communications apparatus <NUM>. The Ethernet interface is an interface used for communication over an Ethernet protocol, and may be used by the OLT (<NUM>) to communicate with an upper-layer network side device (a switch, a router, or the like).

The memory <NUM> is coupled to the processor <NUM>, and is configured to store various software programs and/or a plurality of sets of instructions. Specifically, the memory <NUM> may include a high-speed random access memory, and may also include a nonvolatile memory, for example, one or more magnetic disk storage devices, flash memory devices, or other nonvolatile solid-state storage devices. The memory <NUM> may store an operating system (briefly referred to as a system in the following), for example, an embedded operating system such as ANDROID, IOS, WINDOWS, or LINUX. The memory <NUM> may further store a network communications program. The network communications program may be used to communicate with one or more optical line terminations, one or more customer-premises equipments, or one or more network side devices.

The processor <NUM> may be configured to read and execute computer-readable instructions, to complete a management function of the OLT (<NUM>); parse, control, or process a packet received by the OLT (<NUM>); and the like. Specifically, the processor <NUM> may be configured to invoke the program stored in the memory <NUM>, and execute instructions included in the program. The instructions may be used to implement a signal transmission function of the OLT (<NUM>) in a PON communications network.

It may be understood that the OLT (<NUM>) may further include an upstream board, a backplane that provides a physical connection for units, a clock, a fan, a fan control module, and the like.

It should be noted that the OLT (<NUM>) shown in <FIG> is merely an implementation of this application. In an actual application, the OLT (<NUM>) may alternatively include more or fewer components. This is not limited herein.

It should be noted that, based on the OLT hardware structure shown in <FIG>, the OLT may be configured to perform all or some of the actions performed by the OLT in the implementations shown in <FIG> and <FIG>.

It may be clearly understood by persons skilled in the art that, for the purpose of convenient and brief description, for detailed working processes of the foregoing system, apparatus, and unit, refer to corresponding processes in the foregoing method implementations.

In the several implementations provided in this application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus implementation is merely an example. For example, division into units is merely logical function division and may be other division in an actual implementation. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the implementations.

In addition, functional units in the implementations of this application may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units may be integrated into one unit.

When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer readable storage medium. Based on such an understanding, the technical solutions of this application essentially, or the part contributing to the conventional technology, or all or some of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or some of the steps of the methods described in the implementations of this application. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc.

Claim 1:
A data transmission method, comprising:
obtaining (<NUM>), by an optical line terminal, OLT, a data template;
obtaining (<NUM>), by the OLT, ONT data based on the data template;
encoding, by the OLT, the ONT data according to an external data representation, XDR, format; and
sending (<NUM>), by the OLT, encoded ONT data to a management server, wherein the management server is an Internet protocol detail record, IPDR server;
wherein the obtaining, by an OLT, a data template comprises receiving, by the OLT, the data template sent by the management server, wherein the data template comprises at least two data types associated with an ONT, and further comprises an XDR object corresponding to each data type associated with the ONT such that one or more parameters, including a character data type and a data length that correspond to the ONT data in the data template are consistent with one or more parameters including a character data type and a data length that correspond to CM data in an IPDR data collection template defined in data over cable service interface specification, DOCSIS.