A method of optical network communication and a communication device

Abstract

The application provides an optical network communication method and a communication device. The method is applied to an optical fiber network, and the optical fiber network comprises a master device and at least one slave device, and the at least one slave device comprises a first slave device. The master device sends a first message to the first slave device, and the first message comprises first indication information. The first indication information is used to indicate that a parameter is carried in a TLV format. The first indication information is added in a conventional WMCI message, so that the parameter transmission between the master device and the slave device can adopt the TLV format. When the master device and the slave device need to transmit an extended parameter (i.e. a parameter type not defined in the current standard or a parameter size not defined in the current standard), the master device and the slave device can determine that the extended parameter is transmitted in the TLV format through the first indication information. Therefore, the problem that the parameter extension is limited due to the conventional fixed format is overcome, and the flexibility of the parameter extension is improved.

Description

[0001] This application is a divisional application. The original application has the application number 202510231432.1 and the original application date is February 27, 2025. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of optical communication, and more particularly to an optical network communication method and communication device. Background Technology

[0003] Fiber to the room (FTTR) refers to a technology that uses optical fiber instead of network cables to provide fiber optic media access to a room via optical network equipment (e.g., an optical network terminal, ONT). In this FTTR scenario, the fiber optic network includes a master device and one or more slave devices (also called sub-devices). A management channel can be established between the master and slave devices, allowing the master device to send management or control-related messages to the slave devices, thereby enabling the master device to manage or control some functions of the slave devices. For example, the master and slave devices can establish a WMCI management channel based on the Wireless Local Area Network Management and Control Interface (WMCI) protocol, allowing the master and slave devices to exchange WMCI messages, thus enabling the management or control of the wireless local area network (WLAN) functions.

[0004] In the current standard, master and slave devices communicate using WMCI messages with a fixed format, each carrying a maximum of 16 parameters. Expanding the parameter range requires defining a new message format, thus limiting scalability. Furthermore, extending the length of already defined parameters can lead to system compatibility issues. Therefore, the current standard's WMCI message format offers limited flexibility, hindering support for future flexible message expansion. Summary of the Invention

[0005] This application provides an optical network communication method and communication device. In the current fixed message format, a type length value (TLV) format is introduced, that is, the TLV format is used to carry parameters, so as to achieve compatibility with the current fixed message format while supporting flexible message expansion in the future.

[0006] In a first aspect, this application provides an optical network communication method applied to an optical fiber network, which includes a master device and at least one slave device, the at least one slave device including a first slave device. The optical network communication method provided in this aspect can be executed by the master device in the optical fiber network, or by a portion of a functional module or chip within the master device. Taking execution by the master device as an example, the master device sends a first message to the first slave device. The first message is a Wireless LAN Management and Control Interface (WMCI) message, and the first message includes first indication information, which indicates that parameters are carried in Type Length Value (TLV) format.

[0007] In this embodiment, a first indication message is added to the traditional WMCI message to enable parameter transmission between the master and slave devices using TLV format parameters. When the master and slave devices need to transmit extended parameters (e.g., parameter types or sizes not defined in the current standard), they can determine to transmit the extended parameters in TLV format through the first indication message. Therefore, this overcomes the problem of limited parameter extension caused by the traditional fixed format and improves the flexibility of parameter extension.

[0008] In one possible implementation, the first indication information indicates that the first message or its response message carries parameters in TLV format. In one implementation, the first message is a parameter configuration type message, meaning it carries parameters that the master device needs to send to the first slave device. In this case, the first indication information indicates that the parameters carried in the first message are in TLV format. In another implementation, the first message is a parameter request type message, meaning it is used by the master device to request or instruct the first slave device to report parameters. The first message may not carry any parameter content. In this case, the first indication information indicates that the parameters requested by the first message from the first slave device are transmitted in TLV format. In other words, the response message of the first message sent by the first slave device to the master device carries parameters in TLV format.

[0009] In one possible implementation, before the master device sends the first message to the first slave device, the method further includes: the master device receiving a second message from the first slave device, wherein the first message is a response message to the second message, and the second message includes first indication information. For example, the second message is a scheduling request type, indicating that the first slave device requests the master device to send parameters for scheduling the slave device, that is, requests the master device to send scheduling parameters for the slave device to the first slave device. If the first message is a parameter configuration type message, after receiving the second message, the master device sends the first message to the first slave device to configure parameters for the first slave device.

[0010] In one possible implementation, after the master device sends a first message to the first slave device, the method further includes: the master device receiving a third message from the first slave device, the third message being a response message to the first message, and the third message including first indication information.

[0011] In one possible implementation, the first indication information is located in the message content field; or, the first indication information is located in the message type identifier field; or, the first indication information is located in the message length and processing requirement fields. For example, the first message includes the first indication information, which is located in one of the message content field, the message type identifier field, or the message length field (i.e., the message length and processing requirement fields) of the first message.

[0012] In this embodiment, the first indication information is carried in an existing field of the traditional WMCI message, which helps to improve system compatibility.

[0013] In one possible implementation, the message content field includes a parameter mask field, and the first indication information is located in the parameter mask field.

[0014] Optionally, the first indication information is located in one bit of the parameter mask field.

[0015] For example, the first indication information is located in the 16th bit of the parameter mask field. For example, setting the 16th bit of the parameter mask field to 1 indicates the first indication information.

[0016] In this embodiment, the last bit (e.g., bit 16) of the parameter mask field in a traditional WMCI message is used to indicate whether the current WMCI message carries parameters in TLV format, instead of defining the last bit of the parameter mask field as a parameter indicator. If the WMCI message carries parameters in TLV format, after carrying the fixed parameters in the message content field, the extended parameters (i.e., TLV parameters) will be carried in TLV format. Carrying the extended parameters in TLV format in the message content field is compatible with the traditional method of carrying fixed parameters, which not only solves the problem of transmitting extended parameters but also makes the transmission method of extended parameters compatible with that of fixed parameters. This improves the flexibility of parameter extension and enhances system compatibility. In addition, a WMCI message can carry at least one extended parameter in addition to 15 fixed parameters, thereby increasing the parameter capacity that a WMCI message can carry. When transmitting the same amount of data, fewer WMCI messages can be used to complete the data transmission compared to traditional WMCI messages, improving data transmission efficiency and saving signaling overhead.

[0017] In another possible implementation, the first indication information is at least one value of the message type identifier field. For example, the first indication information is a newly defined value of the message type identifier field.

[0018] In this embodiment, a new value is added to the message type identifier field to indicate that parameters are carried in TLV format. The values ​​of the message type identifier field already defined in the current standard continue the function of the current standard, which can also be understood as implicitly indicating that parameters are not carried in TLV format. Therefore, by carrying the first indication information in the message type identifier field, the message format is changed less and the system compatibility is high.

[0019] Optionally, the message type identifier field may be at least one byte in size, and the first indication information may be at least one byte in size. For example, the message type identifier field may be 2 bytes in size, and the first indication information may be 2 bytes in size.

[0020] In this embodiment, the message type identifier field, which is 1 byte in size in traditional WMCI messages, is expanded to 2 bytes, increasing the maximum number of message types that the system can define. Since a message type can carry at least one parameter and at most 16 parameters, this is beneficial for increasing the variety of parameters that the system can transmit, and thus for increasing the range of parameter expansion.

[0021] Optionally, the message content field of the first message includes a parameter mask field, where each bit of the parameter mask field is set to 0.

[0022] Optionally, the first two bytes of the message content field of the first message are used to carry parameters in TLV format. In other words, the portion of the traditional WMCI message used to carry the parameter mask is replaced with the portion carrying the parameters in TLV format. This can also be understood as removing the parameter mask field from the message content field.

[0023] In this embodiment, the parameter mask field in traditional WMCI messages is discarded, increasing the space for carrying parameters in TLV format. Specifically, the first two bytes of the message content field of the first message can be used to carry parameters in TLV format. This increases the payload of the first message for carrying TLV parameters, thereby improving the efficiency of parameter carrying in the message.

[0024] In another possible implementation, the first indication information is at least one of the 3rd to 6th bits in the message length and processing requirement fields.

[0025] This implementation method can be applied to scenarios requiring low latency and high-efficiency processing. While ensuring system compatibility, it does not affect the transmission of fixed parameters in traditional technologies.

[0026] Optionally, the first two bytes of the message content field of the first message are used to carry parameters in TLV format.

[0027] In one possible implementation, the type field of the TLV format is 2 bytes in size, the length field of the TLV format is 1 byte in size, and the value field of the TLV format is at least one byte in size.

[0028] In one possible implementation, before the master device sends the first message to the first slave device, the method further includes: the master device obtaining version information of the first slave device, the version information being used to indicate the version type of WMCI messages supported by the first slave device, the version information including a first version type, the first version type indicating that the first slave device supports communication using WMCI messages of the first version type, the WMCI messages of the first version type using TLV format to transmit parameters; the master device sending configuration information to the first slave device, the configuration information including the first version type.

[0029] In this implementation, before the parameter configuration process, the master device needs to negotiate the capabilities of the slave device during initialization. During initialization, the master device can obtain the WMCI versions supported by the slave device and define a common message format for negotiation. If a new version is defined in the future, a specific WMCI version code can be used. If both the master and slave devices support it, the new version can be applied. This improves system compatibility.

[0030] In one possible implementation, the first message is encapsulated in the payload field of an FTTR Encapsulation Method (FEM) frame, and the FEM port identifier in the frame header of the FEM frame is used to indicate that the first message corresponds to a first slave device.

[0031] In this embodiment, the FEM port ID in the FEM frame header is assigned by the master device. This FEM port ID not only indicates that the first message is a WMCI message, but also indicates the sender and receiver of the WMCI message (i.e., the first message), that is, it indicates that the WMCI message (i.e., the first message) corresponds to the first slave device and not other slave devices. Therefore, the FEM port ID can be used to distinguish WMCI messages from other control messages in the FTTR system, which is beneficial to improving the control efficiency of WLAN functions.

[0032] In one possible implementation, the FEM frame is encapsulated in the payload field of a data link layer (DLL) frame.

[0033] In one possible implementation, the master device is a main FTTR unit (MFU), and the slave device is a sub FTTR unit (SFU).

[0034] Secondly, this application provides an optical network communication method applied to an optical fiber network, which includes a master device and at least one slave device, the at least one slave device including a first slave device. The optical network communication method provided in this aspect can be executed by the first slave device in the optical fiber network, or by a portion of a functional module or chip within the first slave device. Taking execution by the first slave device as an example, the first slave device receives a first message from the master device. The first message is a Wireless LAN Management and Control Interface (WMCI) message, which includes first indication information indicating that parameters are carried in Type Length Value (TLV) format.

[0035] In one possible implementation, before the first slave device receives the first message from the master device, the method further includes:

[0036] The first slave device sends a second message to the master device. The first message is a response message to the second message, and the second message includes the first instruction information.

[0037] In one possible implementation, after the first slave device receives the first message from the master device, the method further includes:

[0038] The first slave device sends a third message to the master device. The third message is a response to the first message and includes the first instruction information.

[0039] In one possible implementation, before the first slave device receives the first message from the master device, the method further includes:

[0040] The first slave device sends its version information to the master device. The version information is used to indicate the version type of WMCI messages supported by the first slave device. The version information includes the first version type, which indicates that the first slave device supports communication using WMCI messages of the first version type. The WMCI messages of the first version type use TLV format to transmit parameters.

[0041] The first slave device receives configuration information from the master device, including the first version type.

[0042] It should be noted that there are many other specific implementation methods in this application, and you can refer to the specific implementation methods and their beneficial effects in the first aspect, which will not be repeated here.

[0043] Thirdly, this application provides an optical network communication method applied to an optical fiber network, the optical fiber network including a master device and at least one slave device, the at least one slave device including a first slave device. The optical network communication method provided in this aspect can be executed by the first slave device in the optical fiber network, or by a portion of a functional module or chip in the first slave device. Taking execution by the master device as an example, the master device receives a first message from the first slave device, the first message being a Wireless LAN Management and Control Interface (WMCI) message, the first message including first indication information, the first indication information indicating that parameters are carried in Type Length Value (TLV) format.

[0044] In one possible implementation, before the master device receives the first message from the first slave device, the method further includes:

[0045] The master device sends a second message to the first slave device. The first message is a response message to the second message, and the second message includes the first indication information.

[0046] In one possible implementation, after the master device receives the first message from the first slave device, the method further includes:

[0047] The master device sends a third message to the first slave device. The third message is a response to the first message and includes the first indication information.

[0048] It should be noted that there are many other specific implementation methods in this application, and you can refer to the specific implementation methods and their beneficial effects in the first aspect, which will not be repeated here.

[0049] Fourthly, this application provides an optical network communication method applied to an optical fiber network, the optical fiber network including a master device and at least one slave device, the at least one slave device including a first slave device. The optical network communication method provided in this aspect can be executed by the first slave device in the optical fiber network, or by a portion of a functional module or chip in the first slave device. Taking execution by the first slave device as an example, the first slave device sends a first message to the master device. The first message is a Wireless LAN Management and Control Interface (WMCI) message, the first message including first indication information, the first indication information indicating that parameters are carried in Type Length Value (TLV) format.

[0050] In one possible implementation, before the first slave device sends the first message to the master device, the method further includes:

[0051] The first slave device receives a second message from the master device, the first message being a response message to the second message, and the second message including first indication information.

[0052] In one possible implementation, after the first slave device sends a first message to the master device, the method further includes:

[0053] The first slave device receives a third message from the master device. The third message is a response to the first message and includes the first instruction information.

[0054] It should be noted that there are many other specific implementation methods in this application, and you can refer to the specific implementation methods and their beneficial effects in the first aspect, which will not be repeated here.

[0055] Fifthly, embodiments of this application provide a communication device, which can be a main device as described in the foregoing embodiments, or a chip within the main device. The communication device may include a processing module and a transceiver module. When the communication device is a main device, the processing module may be a processor, and the transceiver module may be a transceiver. The main device may also include a storage module, which may be a memory. The storage module stores instructions, and the processing module executes the instructions stored in the storage module to cause the main device to perform the method of the first aspect or any embodiment of the first aspect; or, to perform the method of the third aspect or any embodiment of the third aspect. When the communication device is a chip within the main device, the processing module may be a processor, and the transceiver module may be an input / output interface, pin, or circuit, etc. The processing module executes the instructions stored in the storage module to cause the main device to perform the method of the first aspect or any embodiment of the first aspect; or, to perform the method of the third aspect or any embodiment of the third aspect. The storage module may be a storage module within the chip (e.g., a register, cache, etc.), or a storage module located outside the chip within the main device (e.g., a read-only memory, random access memory, etc.).

[0056] Sixthly, embodiments of this application provide a communication device, which may be a slave device (e.g., a first slave device) as described in the foregoing embodiments, or a chip within the slave device (e.g., the first slave device). The communication device may include a processing module and a transceiver module. When the communication device is a slave device (e.g., the first slave device), the processing module may be a processor, and the transceiver module may be a transceiver. Optionally, the slave device (e.g., the first slave device) may further include a storage module, which may be a memory; the storage module is used to store instructions, and the processing module executes the instructions stored in the storage module to cause the slave device (e.g., the first slave device) to perform the method of the second aspect or any embodiment of the second aspect; or, to perform the method of the fourth aspect or any embodiment of the fourth aspect. When the communication device is a chip within a slave device (e.g., a first slave device), the processing module can be a processor, and the transceiver module can be an input / output interface, pin, or circuit, etc. The processing module executes instructions stored in the storage module to cause the slave device (e.g., the first slave device) to perform the method of the second aspect or any embodiment of the second aspect; or, to perform the method of the fourth aspect or any embodiment of the fourth aspect. The storage module can be a storage module within the chip (e.g., a register, cache, etc.), or it can be a storage module located outside the chip within the slave device (e.g., the first slave device) (e.g., a read-only memory, random access memory, etc.).

[0057] In a seventh aspect, this application provides a communication device, which may be an integrated circuit chip. The integrated circuit chip includes a processor. The processor is coupled to a memory for storing programs or instructions that, when executed by the processor, cause the communication device to perform the methods described in any of the various embodiments of the foregoing aspects, as well as the foregoing aspects themselves.

[0058] Eighthly, embodiments of this application provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform the methods described in any of the various embodiments of the foregoing aspects.

[0059] Ninthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the methods described in any of the various embodiments of the foregoing aspects.

[0060] In a tenth aspect, embodiments of this application provide an optical fiber network including a master device that performs the methods described in the first aspect and any embodiment of the first aspect, and a slave device (e.g., a first slave device) that performs the methods described in the second aspect and any embodiment of the second aspect. Attached Figure Description

[0061] Figure 1A An example diagram of the network architecture of a fiber optic network;

[0062] Figure 1B Another example diagram of the network architecture of a fiber optic network;

[0063] Figure 1C Here is an example diagram of an FTTR system;

[0064] Figure 2 This is a flowchart illustrating the optical network communication method in this application;

[0065] Figure 3 This is another flowchart illustrating the optical network communication method in this application;

[0066] Figure 4 This is another flowchart illustrating the optical network communication method in this application;

[0067] Figure 5A An example diagram of an FEM frame encapsulating WMCI messages;

[0068] Figure 5B An example diagram of an XFEM frame encapsulating a WMCI message;

[0069] Figure 5C An example diagram of a DLL frame that encapsulates an FEM frame;

[0070] Figure 5D An example diagram of a DLL frame that encapsulates an XFEM frame;

[0071] Figure 6 This is a schematic diagram of one embodiment of the communication device in this application;

[0072] Figure 7 This is a schematic diagram of another embodiment of the communication device in this application. Detailed Implementation

[0073] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0074] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0075] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such terms are interchangeable where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0076] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0077] The optical network communication method provided in this application is applied to optical fiber networks. Figure 1A This is an example diagram of the architecture of a fiber optic network in traditional technology. (Example:) Figure 1AAs shown, this fiber optic network includes an optical line terminal (OLT), an optical distribution network (ODN), and optical network units (ONUs) (or optical network terminals (ONTs)). The OLT and ONUs are connected and communicate via optical fibers. The OLT is typically connected to the ONU (or ONT) through the ODN. The ODN comprises a network of one or more optical devices, such as optical fibers, optical distribution frames (ODFs), optical splitters (also known as splitters), and combiners. Furthermore, the aforementioned OLT can connect to the operator's network through a network-side interface, and it can also connect to the ODN through a dedicated interface. The ODN, in turn, connects to the ONUs (or ONTs) through a dedicated interface. In the downlink direction, the OLT broadcasts downlink optical signals, which are then distributed to each ONU (or ONT) via the ODN. In the uplink direction, a time division multiple access (TDMA) method is used, with each ONU (or ONT) transmitting uplink optical signals in its assigned uplink time slot by the OLT. It should be noted that this application does not limit the specific type of optical fiber. The optical fiber described in this application can be a single optical fiber, loose-tube optical fiber, optical cable, or optoelectronic composite cable, etc.

[0078] Figure 1B A schematic diagram of the optical fiber network provided in this application. Figure 1BAs shown, the fiber optic network provided in this application includes a master device 01 and at least one slave device 02, with the master device 01 connected to the at least one slave device 02 via optical fiber. For example, the master device 01 is connected to the at least one slave device 02 via an optical distribution network. The master device 01 is capable of managing or controlling specific functions of one or more slave devices 02 based on at least one protocol. For example, the master device 01 is capable of managing or controlling the wireless local area network (WLAN) function of one or more slave devices 02 based on the WMCI protocol. It can be understood that the master device 01 and / or the slave device 02 have WLAN functionality; it can also be understood that the master device 01 and / or the slave device 02 have wireless fidelity (WiFi) functionality. Exemplarily, in a fiber to the room (FTTR) scenario, the master device 01 can be referred to as a main FTTR unit (MFU), FTTR master device, or main gateway, and the slave device 02 can be referred to as a sub FTTR unit (SFU), FTTR slave device, or slave gateway.

[0079] Figure 1C This is an example diagram showing the network locations for FTTR. Figure 1C As shown, FTTR is a network that provides fiber optic coverage within a broadband customer network (e.g., a home or office) based on fiber to the home / office (FTTH / O). Fiber optic connections are used between the FTTR master device and the FTTR slave devices in each room. Both the FTTR master and slave devices can connect to user terminals via wireless or wired interfaces, or via adapters such as set-top boxes. Specifically, the northbound connection of the FTTR master device acts as an access network terminal, connecting to the access node (AN). The southbound connection of the FTTR master device's FTTR transceiver unit connects to the FTTR transceiver units of the slave devices via the indoor fiber distribution network (IFDN), also providing gateway and other network functions. The FTTR transceiver units of the slave devices connect to the TTTP transceiver unit of the FTTR master device via the indoor fiber distribution network, providing terminal access via wireless or wired interfaces. Indoor optical distribution networks are point-to-multipoint fiber optic infrastructures that can be completely passive, typically consisting of interconnected optical cables and passive devices such as optical splitters. They can also provide remote power supply functionality for FTTR slave devices by using hybrid optical-electrical cables and hybrid optical-electrical splitters.

[0080] For example, in the FTTR system management architecture, the master and slave devices communicate using WMCI messages with a fixed format, each message carrying a maximum of 16 parameters. If more parameters are needed, a new message format must be defined, thus limiting scalability. Furthermore, extending the length of already defined parameters may lead to system compatibility issues. Therefore, the current standard-defined WMCI message format has limited flexibility, hindering support for future flexible message expansion.

[0081] In response, this application provides an optical network communication method and communication device, which introduces a type length value (TLV) format into the current fixed message format, that is, uses the TLV format to carry parameters, so as to achieve compatibility with the current fixed message format while supporting flexible message expansion in the future.

[0082] The following will combine Figure 2 and Figure 3 The main processes of applying the optical network communication method provided in this application to downlink and uplink communication scenarios are described below:

[0083] like Figure 2 The diagram shown is a flowchart of an embodiment of the optical network communication method provided in this application. This embodiment uses a scenario where a master device sends a message to a first slave device as an example. Of course, the entity executing the master device's action in this method can also be a device, module, or chip within the master device; similarly, the entity executing the first slave device's action in this method can also be a device, module, or chip within the first slave device. This embodiment does not specifically limit this. For example, as shown... Figure 2 As shown, the optical network communication method includes the following steps:

[0084] Step 201: The master device sends a first message to the first slave device; correspondingly, the first slave device receives the first message from the master device.

[0085] For example, the master device sends a first message to the first slave device via an optical fiber or composite cable; correspondingly, the first slave device receives the first message from the master device via an optical fiber or composite cable.

[0086] The first message is a WMCI message used to manage or control the WLAN function of the first slave device (hereinafter referred to as management). The first message includes first indication information, which indicates that parameters should be carried in TLV format. Since the first indication information is carried within the first message, it indicates that the first message should carry parameters in TLV format, or that the response message to the first message should carry parameters in TLV format. In one implementation, the first message is a parameter configuration type message, meaning it carries parameters that the master device needs to send to the first slave device. In this case, the first indication information indicates that the parameters carried in the first message should be in TLV format; it can also be understood as the first indication information indicating that the first message carries parameters in TLV format. In another implementation, the first message is a parameter request type message. That is, the first message is used by the master device to request or instruct the first slave device to report parameters. The first message may not carry any parameter content. In this case, the first indication information indicates that the parameters requested by the first message from the first slave device should be transmitted in TLV format. That is, the response message of the first message sent by the first slave device to the master device carries parameters in TLV format. Alternatively, it can be understood that the response message of the first message sent by the first slave device to the master device carries parameters in TLV format. The following text mainly uses a parameter configuration type message as an example. In examples without explicit explanation, it is assumed that the first message carries parameters (e.g., a parameter configuration type message).

[0087] It should be noted that "the first message carries parameters in TLV format" means that at least one parameter in the first message is in TLV format. That is, "the first message carries parameters in TLV format" can mean that some parameters in the first message are in TLV format, or that all parameters in the first message are in TLV format; this embodiment is not limited. Similarly, "the first message carries parameters in TLV format" means that the first message carries at least one parameter in TLV format. That is, "the first message carries parameters in TLV format" can mean that the first message carries both TLV format parameters and parameters in traditional format, or that the first message carries only parameters in TLV format. Furthermore, "the first message does not carry parameters in TLV format" means that no parameters in the first message are in TLV format. For example, all parameters carried in the first message are in traditional format. Similarly, "the first message does not carry parameters in TLV format" indicates that the first message carries no parameters or only parameters in traditional format.

[0088] It's important to note that TLV format is a binary data encoding format widely used in communication protocols, data storage, and transmission (e.g., financial transactions, the Internet of Things, abstract syntax notation one (ASN.1)). The core idea of ​​TLV format is to describe data using three fields: Type (T), Length (L), and Value (L). For example, a TLV unit includes a Type field, a Length field, and a Value field. The Type field identifies the data type, meaning, or tag (e.g., integer, string, nested structure), which is used to determine the format and purpose of the subsequent Value field. The Type field is typically of fixed length to ensure the receiver can accurately interpret the data. For example, the Type field is 1 to 4 bytes long. The Length field indicates the byte length of the Value field, allowing the receiver to accurately determine how much data to read. The Length field is generally 1 to 4 bytes long, depending on the maximum length of the Value field. The Value field contains the actual data content, which can be numbers, strings, binary sequences, etc. The length and format of the Value field are determined by the Type and Length fields.

[0089] It should also be noted that the traditional format refers to the parameter-carrying format defined by the current standard (e.g., WMCI). Because in traditional technologies, there are fixed rules regarding which type of WMCI message each parameter is carried in and which bit in the parameter mask field of the WMCI message corresponds to that parameter, the traditional format can also be called a fixed format.

[0090] In this embodiment, parameters transmitted using a traditional format (i.e., a fixed format) are referred to as fixed parameters. Furthermore, parameters that cannot be transmitted using a traditional format are referred to as extended parameters (abbreviated as extended parameters). For example, extended parameters can be parameters of a type not defined in the current standard, or parameters of a size not defined in the current standard; this embodiment does not impose such limitations.

[0091] Optionally, the format of the parameters carried in the first message and its response message is generally the same. For example, both the first message and its response message carry parameters in TLV format. Alternatively, both the first message and its response message carry parameters in a conventional format (e.g., the fixed-format WMCI message parameter carrying format in conventional technology). Optionally, when the first message includes first indication information, the parameters in TLV format can be carried in the message content field of the first message or in the message content field of the response message. For example, the first message includes at least one parameter in TLV format, or the response message of the first message includes at least one parameter in TLV format.

[0092] Therefore, by adding a first indication message to the traditional WMCI message, parameter transmission between the master and slave devices can utilize TLV format parameters. When the master and slave devices need to transmit extended parameters (i.e., parameter types or sizes not defined in the current standard), they can determine to transmit the extended parameters in TLV format through the first indication message. This overcomes the limitation on parameter extension caused by the traditional fixed format and improves the flexibility of parameter extension.

[0093] Furthermore, to further improve the compatibility of the WMCI message format provided in this application with traditional WMCI message formats, the aforementioned first indication information can be carried in existing fields of traditional WMCI messages. For example, Table 1 below shows an example of a WMCI message format in the conventional art.

[0094] Table 1

[0095]

[0096] As shown in Table 1, the first byte is the message type identifier field (also called the message type ID field), used to indicate the message type and define the semantics of the message content. The second byte is the sequence number (SeqNo) field, containing a sequence number counter used to ensure the robustness of the WMCI message delivery channel. In the downlink direction, the sequence number field is filled with the value of the corresponding master device's sequence number counter. The master device maintains a separate sequence number counter for each slave device's unicast and broadcast WMCI message stream. Each sequence number counter rolls from 255 to 1, and the value 0 is not used in the downlink. In the uplink direction, when an uplink WMCI message is a response to a downlink WMCI message, the value of the SeqNo field is equal to the value of the SeqNo field in the downlink WMCI message. If the WMCI message is initiated by the slave device, then SeqNo = 0 is used. The third and fourth bytes are the message length and processing requirement fields, consisting of three fields: message priority (i.e., message processing requirement), operation type, and message content length. X (the most significant bit of the 3rd byte): Indicates the priority of processing this message. When X=1, the message has a high priority; when X=0, the message has a low priority. C: Indicates the operation type of this message. In the downlink direction, when C=1, the operation type of this message is a parameter request type, indicating that the master device requests the slave device to send the slave device's parameters to the master device; when C=0, the operation type of this message is a parameter configuration type, indicating that the master device sends the slave device's configuration parameters to the slave device. In the uplink direction, when C=1, the operation type of this message is a scheduling request type, indicating that the slave device requests the master device to send the parameters used to schedule the slave device; when C=0, the operation type of this message is a parameter reporting or alarm type, indicating that the slave device reports the slave device's parameters or reports alarm information to the master device. LL LLLL LLLL: Indicates the length of the message content, with a value range of 0 to 1023. The remaining four bits (RRRR) are reserved. Furthermore, bytes 5 through N are the message content field, carrying the specific content of the message and related to the specific message. Bytes 5 and 6 are used to carry the parameter mask (called the parameter mask field), which indicates the parameters in the parameter set corresponding to the first message. For example, the parameter mask field indicates which parameters in the parameter set need to be requested, which parameters in the parameter set need to be configured, or which parameters in the parameter set need to be reported.As shown in Table 2-1, the parameter mask is 16 bits (2 bytes) in size, so a parameter set can contain a maximum of 16 parameters, and each message type can carry a maximum of 16 parameters. Furthermore, bytes 7 through N are used to carry the parameter content of the parameters indicated by the parameter mask. The parameter content should be filled into the message content in the order indicated by the parameter mask, as shown in Table 2-1. For downlink request messages, the parameter mask represents the parameters the master device wants to obtain. For uplink messages, the parameter mask represents the parameters reported and replied to. Here, N is an integer greater than 7. Bytes (N+1) through (N+4) are message integrity check fields, 4 bytes in size, used to verify the sender's identity and prevent forged WMCI message attacks. This field follows the cyclic redundancy check (CRC) function.

[0097] Table 2-1

[0098]

[0099] It should be noted that the mapping relationship between parameters and bits in Table 2-1 is only one example. The specific mapping method can also be based on the order of the parameters from the least significant bit to the most significant bit. For example, the mapping method shown in Table 2-2 below.

[0100] Table 2-2

[0101]

[0102] In the subsequent evolution of the standard, the parameter mask field may use other methods to map parameters and bits, and this embodiment is not limited to this. In this embodiment and subsequent embodiments, only the example shown in Table 2-1 is used as an example for introduction.

[0103] In this embodiment, the first indication information can be carried in any one of the aforementioned message content field, message type ID field, or message length and processing requirement field. These will be described in detail below:

[0104] In one implementation, the first indication information is located in the message content field of the first message.

[0105] Optionally, the message content field includes a parameter mask field, with the first indication information located within the parameter mask field. Since the parameter mask field is typically located within the first two bytes of the message content field, the first indication information is also located within the first two bytes of the message content field.

[0106] Optionally, the first indication information is located in one bit of the parameter mask field. For example, the first indication information is located in the least significant bit of the second byte (i.e., byte 6) of the parameter mask field (e.g., the bit corresponding to parameter 16 in the example shown in Table 2-1, or the bit corresponding to parameter 9 in the example shown in Table 2-2, also referred to as the 16th bit of the parameter mask field). Another example is that the first indication information is located in the most significant bit of the second byte (i.e., byte 6) of the parameter mask field (e.g., the bit corresponding to parameter 9 in the example shown in Table 2-1, or the bit corresponding to parameter 16 in the example shown in Table 2-2, also referred to as the 9th bit of the parameter mask field). Yet another example is that the first indication information is located in the most significant bit of the first byte (i.e., byte 5) of the parameter mask field (e.g., the bit corresponding to parameter 1 in the example shown in Table 2-1, or the bit corresponding to parameter 8 in the example shown in Table 2-2, also referred to as the 1st bit of the parameter mask field).

[0107] For ease of explanation, the following description will use the example of the first indication information being located in the least significant bit (i.e., the 16th bit) of the second byte (i.e., byte 6) of the parameter mask field. For example, the parameter mask carrying the first indication information provided in the embodiments of this application can be as shown in Table 3 below.

[0108] Table 3

[0109]

[0110] In the example shown in Table 3, the 16th bit is 1, indicating the first indication information. Furthermore, the remaining bits of the parameter mask field (e.g., bits 1-15) can retain their traditional functions. For example, a bit of bits 1-15 being 1 indicates that the first message carries the parameter indicated by that bit, carried in the first message according to the format defined in the current standard; a bit of bits 1-15 being 0 indicates that the first message does not carry the parameter indicated by that bit. For example, in the example shown in Table 3, if bit 8 of the 5th byte is 1, it indicates that the message carries or requests parameter 1; if bit 8 of the 5th byte is 0, it indicates that the message does not carry or request parameter 1. It should be noted that the parameters corresponding to bits 1-15 are parameters defined in the current standard, and the 16th bit indicates that the parameter carried in TLV format is an extended parameter. Therefore, the first message can carry a maximum of 15 fixed parameters and can carry one or more extended parameters. Furthermore, the first message can also carry only extended parameters or only fixed parameters. The following will illustrate this with specific examples:

[0111] In one example, the first message carries fixed parameters and extended parameters, where the fixed parameters are mapped using a conventional format, and the extended parameters are carried in TLV format. If the first message carries two fixed parameters (e.g., parameter 1 and parameter 3) and two extended parameters (e.g., extended parameter 1 and extended parameter 2), then the first indication information indicates that the first message carries parameters in TLV format, for example, the 16th bit of the parameter mask is set to 1. If parameter 1 is 2 bytes in size, parameter 3 is 4 bytes in size, extended parameter 1 is 2 bytes in size, and extended parameter 2 is 4 bytes in size, then the first message can be as shown in Table 4-1 below.

[0112] Table 4-1

[0113]

[0114] It should be noted that in Table 4-1 and the examples of TLV format parameters thereafter, the size of the T field is 2 bytes and the size of the L field is 1 byte. In practical applications, the size of the T field can be other values ​​(e.g., 1 byte) and the size of the L field can also be other values ​​(e.g., 2 bytes). This embodiment will not list examples of each.

[0115] In this example, the last bit (e.g., bit 16) of the parameter mask field in a traditional WMCI message is used to indicate whether the current WMCI message carries parameters in TLV format, instead of defining the last bit of the parameter mask field as a parameter indicator. If the WMCI message carries parameters in TLV format, the message content field will carry extended parameters (i.e., TLV parameters) in TLV format after carrying the fixed parameters. In this example, the extended parameters are carried in TLV format in the message content field, while maintaining compatibility with the traditional method of carrying fixed parameters. This not only solves the problem of transmitting extended parameters but also ensures compatibility between the transmission methods of extended and fixed parameters. This improves the flexibility of parameter extension and enhances system compatibility. Furthermore, in addition to carrying 15 fixed parameters, a WMCI message can also carry at least one extended parameter, thereby increasing the parameter capacity of a single WMCI message. When transmitting the same amount of data, fewer WMCI messages can be used to complete the data transmission compared to traditional WMCI messages, improving data transmission efficiency and saving signaling overhead.

[0116] In another example, the first message carries only extended parameters, not fixed parameters, and the extended parameters are carried in TLV format. If the first message carries two extended parameters (e.g., extended parameter 1 and extended parameter 2), the first indication information indicates that the first message carries parameters in TLV format, for example, the 16th bit of the parameter mask is set to 1. If the size of extended parameter 1 is 2 bytes and the size of extended parameter 2 is 4 bytes, then the first message can be as shown in Table 4-2 below.

[0117] Table 4-2

[0118]

[0119] In this example, bit 16 of the parameter mask field is set to 1, and the other bits are set to 0, indicating that the message only carries parameters in TLV format, and the parameter content is filled according to the TLV definition. This example can be applied to scenarios that require flexible parameter expansion, or scenarios that require carrying a large number of combined parameters. It helps overcome the limitations of traditional WMCI message formats on transmitting extended parameters and improves the flexibility of parameter expansion.

[0120] Optionally, if the first message does not carry parameters in TLV format, the 16th bit of the parameter mask field is set to 0, indicating that the first message does not carry parameters in TLV format. For example, the first message includes second indication information, which is represented by the 16th bit of the parameter mask field being set to 0, indicating that no parameters in TLV format are carried.

[0121] For example, the first message carries only fixed parameters, which are mapped using a traditional format. If the first message carries two fixed parameters (e.g., parameter 1 and parameter 3), the 16th bit of the parameter mask is set to 0. If parameter 1 is 2 bytes in size and parameter 3 is 4 bytes in size, the first message can be as shown in Table 4-3 below.

[0122] Table 4-3

[0123]

[0124] In this example, when only fixed parameters need to be transmitted, bit 16 of the parameter mask field in the WMCI message is set to 0, and the other bits are set based on the fixed parameters to be carried. A message can carry a maximum of 15 fixed parameters. The padding method for fixed parameters follows the existing definitions in the current standard. This example can be applied to scenarios requiring low latency and high-efficiency processing. While ensuring system compatibility, it does not affect the transmission of fixed parameters in traditional technologies.

[0125] Optionally, if the first message is a parameter request message and includes first indication information, then the first message is used by the master device to request the first slave device to report at least one parameter in TLV format. Furthermore, the response message of the first message is a parameter reporting message, used by the first slave device to report at least one parameter in TLV format to the master device. The response message of the first message also includes the first indication information. In this case, to clarify which TLV the master device requests the first slave device to report, the message content field of the first message needs to carry information related to that TLV. In one implementation, the first message includes the value of the T field of the first TLV. Optionally, the first message also includes the value of the L field of the first TLV.

[0126] For example, the first message is used by the master device to request fixed parameters and extended parameters from the first slave device, and the response message of the first message is used by the first slave device to send the fixed parameters and extended parameters to the master device. If the first message requests two fixed parameters (e.g., parameter 1 and parameter 3) and two extended parameters (e.g., extended parameter 1 and extended parameter 2), where parameter 1 is 2 bytes in size, parameter 3 is 4 bytes in size, extended parameter 1 is 2 bytes in size, and extended parameter 2 is 4 bytes in size, then the first message can be as shown in Table 4-4 below, and the response message of the first message can be as shown in Table 4-5 below.

[0127] Table 4-4

[0128]

[0129] In the example shown in Table 4-4, by carrying first indication information to instruct the master device to request the first slave device to report parameters in TLV format, and by carrying an empty TLV in the message content field (e.g., T field is filled but L and V fields are not filled, or T and L fields are filled but V field is not filled), the first slave device is indicated which TLV to report. This facilitates the first slave device to quickly and accurately fill the TLV, thereby improving the efficiency and accuracy of the first slave device reporting TLV parameters.

[0130] It should be noted that an empty V value (e.g., V1 or V2 being empty) means the V field is set to a value that the receiving end (e.g., the first slave device) does not process (e.g., a preset value, a conventional value, or an arbitrary value). After receiving the V field value, the first slave device does not process it but instead fills the V field with the content of the parameters to be reported. The specific type of the parameters to be reported is indicated by the T field of this TLV. Furthermore, the message content field may carry a TLV terminator to indicate the end of the TLV carried in this field. Optionally, the TLV terminator can be a specific type of TLV. The receiving end only reads the TLV terminator and does not need to read the subsequent bits in the message content field.

[0131] Table 4-5

[0132]

[0133]

[0134] In another implementation, the first indication information is located in the message type ID field of the first message. In this embodiment, the first indication information is represented by the value of the message type ID field. If the value of the first indication information is a second value, then the message type ID field of the first message indicates that the message type of the first message is a TLV message type, and the message of the TLV message type carries parameters in TLV format, or the message of the TLV message type carries parameters in TLV format; if the message type ID field of the first message is not a second value, then the message type of the first message is a normal message type, and the message of the normal message type does not carry parameters in TLV format, that is, it carries parameters in the traditional format.

[0135] Optionally, the size of the message type identifier field of the first message is at least one byte, and the size of the first indication information is at least one byte. For example, if the size of the message type identifier field of the first message is 2 bytes, then the size of the first indication information is 2 bytes; if the size of the message type identifier field of the first message is 1 byte, then the size of the first indication information is 1 byte.

[0136] In one example, taking binary as an example, if the message type identifier field is 1 byte, and 1 byte can have a maximum of 256 values ​​(i.e., 0 to 255), then a value not defined by the standard can be selected from 0 to 255 to indicate that the parameter is carried in TLV format, while other standard-defined values ​​follow the traditional definition, implicitly indicating that the parameter is not carried in TLV format. For example, if the standard has defined the meaning of each value from 0 to 254, but has not defined the meaning of the value 255, then the value 255 can be used to represent the first indication information, that is, to carry the parameter in TLV format, while the values ​​from 0 to 254 follow the definition in the standard, that is, to implicitly indicate that the parameter is not carried in TLV format.

[0137] In another example, taking binary as an example, if the message type identifier field is 2 bytes, and 2 bytes can have a maximum of 32768 values ​​(i.e., 0 to 32767), then a value not defined in the standard can be selected from 0 to 32767 to indicate that the parameter is carried in TLV format. For example, if the standard has defined the meaning of each value from 0 to 32750, but not the meaning of values ​​from 32751 to 32767, then any value from 32751 to 32767 (e.g., 32751) can be selected to represent the first indication information, that is, to carry the parameter in TLV format. The values ​​from 0 to 32750 follow the definition in the standard, that is, implicitly indicating that the parameter is not carried in TLV format. This embodiment does not limit the specific values ​​of the second value and non-second values, only ensuring that the second value is a value not defined in the standard. In addition, the first indication information can also be implemented using three bytes or even four bytes, and examples are not listed here.

[0138] Optionally, the second value can be any value from a set of second values. Any value in the set of second values ​​indicates that the first message should carry parameters in TLV format. For example, the set of second values ​​includes second value #1, second value #2, and second value #3. All three values ​​indicate that parameters should be carried in TLV format, but the content of the parameters carried in TLV format differs. For example, second value #1, second value #2, and second value #3 correspond to three different TLV message types. By setting multiple second values, parameters that need to be transmitted in TLV format can be divided into multiple different TLV messages, which helps to reduce the payload size of a single TLV message and improve data transmission efficiency and reliability.

[0139] In this embodiment, the existing field values ​​of WMCI messages in traditional technology implicitly indicate that parameters are not carried in TLV format. Furthermore, a new value is added to this field to indicate that parameters are carried in TLV format. The message format change is minor, resulting in high system compatibility.

[0140] For ease of explanation, the following text will use the example of the message type identifier field of the first message being 1 byte in size.

[0141] It is important to note that in traditional technologies, the parameter mask field in the message content field is related to the message type identifier field. For example, the message type identifier field indicates the message type of the WMCI message and also indicates the parameter set corresponding to that WMCI message, i.e., which parameter set the parameters carried by the WMCI message belong to. The parameter mask field of the WMCI message can only indicate the parameters in that parameter set. Therefore, a single WMCI message cannot carry parameters from two different parameter sets; according to traditional parameter carrying methods, two WMCI messages are required. Thus, if the first message includes the first indication information, then the first message only carries extended parameters and not fixed parameters; if the first message does not include the first indication information, then the first message is a traditional message type, and the first message only carries fixed parameters and not extended parameters. The following will illustrate this with specific examples:

[0142] In one example, since the first message includes first indication information and carries only extended parameters without fixed parameters, each bit of the parameter mask field in the message content field of the first message is set to 0, indicating that no fixed parameters are carried. For example, if the first message carries two extended parameters (e.g., extended parameter 1 and extended parameter 2), the message type identifier field uses the second value, indicating that the first message carries parameters in TLV format. If extended parameter 1 is 2 bytes in size and extended parameter 2 is 4 bytes in size, the first message can be as shown in Table 5-1 below.

[0143] Table 5-1

[0144]

[0145] In this example, since the current standard does not define a message with a value of 255, that is, it does not define a message with a message type identifier field value of 255, the newly defined message with a value of 255 is a TLV message (i.e. a message that carries parameters in TLV format). The message in the example shown in Table 5-1 only carries parameters in TLV format (e.g., extended parameters), and the traditional fixed parameters are transmitted using the traditional message format.

[0146] Optionally, when every bit in the parameter mask field is 0 (as shown in Table 5-1), the parameter mask field in the message content field of the first message has a smaller effect, and therefore can be discarded. That is, the first two bytes of the message content field of the first message can be used to carry parameters in TLV format. This increases the payload of the first message for carrying TLV parameters, thereby improving the efficiency of parameter carrying. For example, if the first message discards the parameter mask field and carries two extended parameters in TLV format (e.g., extended parameter 1 (2 bytes) and extended parameter 2 (4 bytes)), then the first message can be as shown in Table 5-2 below.

[0147] Table 5-2

[0148]

[0149] In this example, the parameter mask field in traditional WMCI messages is discarded, increasing the space for carrying parameters in TLV format. Specifically, the first two bytes of the message content field in the first message can be used to carry TLV format parameters. This increases the payload of the first message for carrying TLV parameters, thereby improving the efficiency of parameter carrying in the message.

[0150] It should be noted that Tables 5-1 and 5-2 use a 1-byte message type identifier field as an example. As the number of message types the system needs to support increases, the message type identifier field can be expanded to 2 bytes. A 2-byte message type identifier field can support up to 65,536 message types.

[0151] For example, if the message type identifier field is 2 bytes, the first message does not discard the parameter mask field, and the first message carries two extended parameters in TLV format (for example, extended parameter 1 (size 2 bytes) and extended parameter 2 (size 4 bytes)), then the first message can be as shown in Table 5-3 below.

[0152] Table 5-3

[0153]

[0154] In this example, the message type identifier field, which is 1 byte in size in the traditional WMCI message, is expanded to 2 bytes, which increases the maximum number of message types that the system can define and helps to expand the range of parameter expansion.

[0155] In another implementation, the first indication information is located in the message length and processing requirement field of the first message. In some scenarios, the message length and processing requirement field is also simply referred to as the message length field.

[0156] Optionally, as shown in the example in Table 1 above, the first indication information may be located in the first byte of the message length and processing requirement field (i.e., byte 3 of the first message). Optionally, the first indication information may be located in the 3rd to 6th bits (i.e., bits 3 to 6) of the 3rd byte of the first message from low to high. Optionally, the first indication information may be represented by at least one of the aforementioned 3rd to 6th bits from low to high.

[0157] In one type of example, the first indication information is represented by one of the aforementioned bits 3 through 6 from low to high. For example, as shown in Table 6-1 below, the first indication information is represented by bit 6 in the message length and processing requirement field. As another example, the first indication information is represented by bit 3 in the message length and processing requirement field. Furthermore, the first indication information may also be represented by bit 4 or bit 5; detailed message formats are not listed here.

[0158] Table 6-1

[0159]

[0160]

[0161] In one type of example, the first indication information is represented by two bits from the 3rd to 6th bits (from low to high). For example, as shown in Table 6-2 below, the first indication information is represented by bits 6 and 5 in the message length and processing requirement fields. As another example, the first indication information is represented by bits 3 and 4 in the message length and processing requirement fields. Furthermore, the first indication information may also be represented by bits 4 and 5; detailed message formats are not listed here.

[0162] Table 6-2

[0163]

[0164] For ease of explanation, the following text will use bit 6 from the message length and processing requirement fields as an example for the first indication information.

[0165] Furthermore, since the first indication information is carried in the message length and processing requirement fields, but not in the parameter mask field, the parameter mask field of the first message can retain the functionality of the current standard. For example, the parameter mask field is used to indicate the types of parameters not carried in TLV format (i.e., the types of fixed parameters). The first message can carry a maximum of 16 fixed parameters and can carry one or more extended parameters. Additionally, the first message can also carry only extended parameters, or only fixed parameters. Specific examples are provided below:

[0166] In one example, the first message carries fixed parameters and extended parameters, where the fixed parameters are mapped using a conventional format, and the extended parameters are carried in TLV format. If the first message carries two fixed parameters (e.g., parameter 1 and parameter 3) and two extended parameters (e.g., extended parameter 1 and extended parameter 2), then the first indication information indicates that the first message carries parameters in TLV format, i.e., bit Y (bit 6 of the 3rd byte) is set to 1. If parameter 1 is 2 bytes in size, parameter 3 is 4 bytes in size, extended parameter 1 is 2 bytes in size, and extended parameter 2 is 4 bytes in size, then the first message can be as shown in Table 6-3 below.

[0167] Table 6-3

[0168]

[0169]

[0170] In this example, reserved bits (e.g., bit 6) in the message content length and processing requirement field of a traditional WMCI message are used to indicate whether the current WMCI message carries parameters in TLV format. If the WMCI message carries parameters in TLV format, after carrying the fixed parameters in the message content field, the extended parameters (i.e., TLV parameters) will be carried in TLV format. In this example, the extended parameters are carried in TLV format in the message content field, while maintaining compatibility with the traditional method of carrying fixed parameters. This not only solves the problem of transmitting extended parameters but also ensures compatibility between the transmission methods of extended parameters and fixed parameters. This improves the flexibility of parameter extension and enhances system compatibility. Furthermore, in addition to carrying 16 fixed parameters, a WMCI message can also carry at least one extended parameter, thereby increasing the parameter capacity of a single WMCI message. When transmitting the same amount of data, fewer WMCI messages can be used to complete the data transmission compared to traditional WMCI messages, improving data transmission efficiency and saving signaling overhead.

[0171] In another example, the first message carries only extended parameters and no fixed parameters; the extended parameters are carried in TLV format. If the first message carries two extended parameters (e.g., extended parameter 1 and extended parameter 2), the first indication information indicates that the first message carries parameters in TLV format, i.e., bit Y (bit 6 of the 3rd byte) is set to 1. If the size of extended parameter 1 is 2 bytes and the size of extended parameter 2 is 4 bytes, then the first message can be as shown in Table 6-4 below.

[0172] Table 6-4

[0173]

[0174] In this example, bit Y is set to 1, and all bits in the parameter mask field are set to 0, indicating that the message only carries parameters in TLV format, and the parameter content is filled according to the TLV definition. This example can be applied to scenarios that require flexible parameter expansion, or scenarios that require carrying a large number of combined parameters. It helps overcome the limitations of traditional WMCI message formats on transmitting extended parameters and improves the flexibility of parameter expansion.

[0175] Optionally, when every bit in the parameter mask field is 0 (as shown in Table 6-4), the parameter mask field in the message content field of the first message has less effect, and therefore can be discarded. That is, the first two bytes of the message content field of the first message can be used to carry parameters in TLV format. This increases the payload of the first message for carrying TLV parameters, thereby improving the efficiency of parameter carrying. For example, if the first message discards the parameter mask field and carries two extended parameters in TLV format (e.g., extended parameter 1 (2 bytes) and extended parameter 2 (4 bytes)), then the first message can be as shown in Table 6-5 below.

[0176] Table 6-5

[0177]

[0178]

[0179] In this example, the parameter mask field in traditional WMCI messages is discarded, increasing the space for carrying parameters in TLV format. Specifically, the first two bytes of the message content field in the first message can be used to carry TLV format parameters. This increases the payload of the first message for carrying TLV parameters, thereby improving the efficiency of parameter carrying in the message.

[0180] Optionally, if the first message does not carry parameters in TLV format, then bit Y (bit 6 of the 3rd byte) is set to 0, indicating that the first message does not carry parameters in TLV format. For example, the first message includes second indication information, which is represented by bit Y (bit 6 of the 3rd byte) being set to 0, indicating that no parameters in TLV format are carried.

[0181] For example, the first message carries only fixed parameters, which are mapped using a traditional format. If the first message carries two fixed parameters (e.g., parameter 1, parameter 3, and parameter 16), then bit Y (bit 6 of the 3rd byte) is 0. If parameter 1 is 2 bytes in size, parameter 3 is 4 bytes in size, and parameter 16 is 6 bytes in size, then the first message can be as shown in Table 6-6 below.

[0182] Table 6-6

[0183]

[0184] In this example, when only fixed parameters need to be transmitted, bit Y is set to 0, and the bits in the parameter mask field are set based on the fixed parameters to be carried. A message can carry a maximum of 16 fixed parameters. The padding method for fixed parameters follows the existing definitions in current standards. This example can be applied to scenarios requiring low latency and efficient processing. While ensuring system compatibility, it does not affect the transmission of fixed parameters in traditional technologies.

[0185] Step 202: The first slave device sends a response message of the first message to the master device; correspondingly, the master device receives the response message from the first slave device.

[0186] For example, the master device sends a first message to the first slave device via an optical fiber or composite cable; correspondingly, the first slave device receives the first message from the master device via an optical fiber or composite cable.

[0187] The response message to the first message includes a first indication message, which indicates that the parameters are carried in TLV format. For example, the first indication message indicates that the response message to the first message carries the parameters in TLV format.

[0188] In this embodiment, step 202 is an optional step. For example, when the operation type of the first message is parameter configuration type, after the first slave device performs parameter configuration based on the first message, it can send a response message of the first message to indicate whether the parameter configuration was successful.

[0189] In this embodiment, the first message sent by the master device to the first slave device carries first indication information, which indicates that the first message uses TLV format to carry parameters. When the master device and the slave device need to transmit extended parameters (i.e., parameter types or sizes not defined in the current standard), the master device and the slave device can negotiate and determine to transmit the extended parameters using TLV format through the first indication information. Therefore, the problem of limited parameter extension caused by the traditional fixed format is overcome, and the flexibility of parameter extension is improved. Since TLV has the characteristics of high flexibility, good scalability, and efficient parsing, the TLV format is introduced into WMCI messages so that WMCI messages can also obtain the characteristics of good scalability and efficient parsing. This is beneficial to improving the flexibility, scalability, and self-descriptiveness of WMCI messages (e.g., the first message).

[0190] like Figure 3The diagram shown is a flowchart of another embodiment of the optical network communication method provided in this application. In this embodiment, a scenario where a first slave device sends a message to a master device is used as an example. Of course, the entity executing the master device's actions in this method can also be a device, module, or chip within the master device; similarly, the entity executing the first slave device's actions in this method can also be a device, module, or chip within the first slave device. This embodiment does not specifically limit this. For example, as shown... Figure 3 As shown, the optical network communication method includes the following steps:

[0191] Step 301: The first slave device sends a second message to the master device; correspondingly, the master device receives the second message from the first slave device.

[0192] For example, the first slave device sends a second message to the master device via an optical fiber or composite cable; correspondingly, the master device receives the second message from the first slave device via an optical fiber or composite cable.

[0193] The second message is a WMCI message, which includes first indication information indicating that parameters should be carried in TLV format. Since the first indication information is carried within the second message, it instructs the second message to carry parameters in TLV format, or it instructs the response message requiring the second message to carry parameters in TLV format. In one implementation, the second message is a parameter reporting or alarm type message, meaning it carries parameters sent from the first slave device to the master device. In this case, the first indication information instructs the parameters carried in the second message to be in TLV format, or it can be understood as the first indication information instructing the second message to carry parameters in TLV format. In another implementation, the second message is a scheduling request type message, meaning it is used by the first slave device to request the master device to send scheduling configuration information. The second message may not carry any parameters. In this case, the first indication information instructs the second message to request the parameters sent by the master device to be transmitted in TLV format, meaning the response message sent by the master device to the first slave device carries parameters in TLV format, or it can be understood as the response message sent by the master device to the first slave device carrying parameters in TLV format. The following text mainly uses the example of a message whose second message is a parameter reporting type. In examples without explicit explanation, the second message is assumed to be a message carrying parameters (e.g., a message of parameter reporting type).

[0194] Optionally, the format of the parameters carried in the second message and the response message of the second message are generally the same. For example, both the second message and the response message of the second message use the TLV format to carry parameters. Or, for another example, both the second message and the response message of the second message use a traditional format (e.g., the fixed format of WMCI messages in conventional technology) to carry parameters.

[0195] For an introduction to the first instruction information, please refer to the preceding text. Figure 2 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0196] Furthermore, the way the first instruction information is carried in the second message is the same as the way the first instruction information is carried in the first message; please refer to the preceding text for details. Figure 2 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0197] Step 302: The master device sends a response message of the second message to the first slave device; correspondingly, the first slave device receives the response message of the second message from the master device.

[0198] For example, if the operation type of the second message indicates that the master device needs to respond to the second message, then after receiving the second message, the master device can generate a response message for the second message based on the indication in the second message, and send the response message for the second message to the first slave device.

[0199] The response message to the second message includes a first indication message, which indicates that the parameters are carried in TLV format. For example, the first indication message indicates that the response message to the second message carries the parameters in TLV format.

[0200] In this embodiment, step 302 is an optional step. For example, when the operation type of the second message sent by the first slave device to the master device is an alarm type, the master device may not return a response message.

[0201] In this embodiment, the second message sent by the first slave device to the master device carries first indication information, which indicates that the second message uses TLV format to carry parameters. When the master and slave devices need to transmit extended parameters (i.e., parameter types or sizes not defined in the current standard), they can negotiate and determine to transmit the extended parameters using TLV format through the first indication information. Therefore, this overcomes the problem of limited parameter extension caused by traditional fixed formats and improves the flexibility of parameter extension. Since TLV has the characteristics of high flexibility, good scalability, and efficient parsing, the introduction of the TLV format into WMCI messages enables WMCI messages to also achieve good scalability and efficient parsing. This is beneficial for improving the flexibility, scalability, and self-descriptiveness of WMCI messages (e.g., the second message).

[0202] It should be noted that, Figure 2 Corresponding embodiments and Figure 3 Corresponding implementation examples can be combined.

[0203] In one implementation, the first message may be a response message to the second message. For example, the master device receives a second message from the slave device, where the first message is a response message to the second message, and the second message includes first indication information.

[0204] In another implementation, the third message is a response message to the first message. For example, the master device receives a third message from the slave device, which is a response message to the first message and includes first indication information.

[0205] In addition, during initialization, the master device needs to acquire the basic capability information of the slave device and configure its basic operating parameters. The master and slave devices can negotiate and determine the version of WMCI messages for subsequent communication during the initialization process; for example, whether to use a version of WMCI messages that supports the TLV format. The following will combine... Figure 4 The process is described below:

[0206] like Figure 4 The diagram shown is a flowchart of another embodiment of the optical network communication method provided in this application. In this embodiment, signaling interaction between a master device and a first slave device is used as an example for explanation. Of course, the entity executing the master device's actions in this method can also be a device, module, or chip within the master device; similarly, the entity executing the first slave device's actions in this method can also be a device, module, or chip within the first slave device. This embodiment does not specifically limit this. For example, as shown... Figure 4 As shown, the optical network communication method includes the following steps:

[0207] Step 401: The master device obtains the version information of the first slave device.

[0208] The version information is used to indicate the version type of WMCI messages supported by the first slave device.

[0209] In one implementation, the first slave device proactively reports the version types of WMCI messages supported by the first slave device to the master device. For example, the first slave device sends a capability reporting message to the master device, which includes the version information of the first slave device.

[0210] In another implementation, the master device requests the first slave device to report the version type of WMCI messages supported by the first slave device. For example, the master device sends a request message to the first slave device requesting the first slave device to report version information; in response to the request message, the first slave device sends a response message to the master device, which includes the version information of the first slave device.

[0211] Optionally, the version information includes the first version type, which indicates that the first slave device supports communication using WMCI messages of the first version type, and the WMCI messages of the first version type use TLV format to transmit parameters.

[0212] Step 402: The master device sends configuration information to the first slave device.

[0213] The configuration information includes the first version type, and the WMCI messages of the first version type use TLV format to transmit parameters.

[0214] For example, when both the master device and the first slave device support the first version type, the master device sends configuration information containing the first version type to the first slave device.

[0215] In this embodiment, before the parameter configuration process, the master device needs to negotiate the capabilities of the slave device during initialization. During initialization, the master device can obtain the WMCI versions supported by the slave device and define a common message format for negotiation. If a new version is defined in the future, a specific WMCI version code can be used. If both the master and slave devices support it, the new version can be applied. This improves system compatibility.

[0216] It should also be noted that the master device and slave device exchange the messages described above (e.g., first message, second message, response message to the first message, response message to the second message, etc.) through the WMCI management channel. Taking the first message as an example, the other messages are similar. The master device sends the first message to the first slave device through the WMCI management channel; correspondingly, the first slave device receives the first message from the master device through the WMCI management channel. Here, the management channel refers to the logical channel established between the master device and the slave device for transmitting messages. The WMCI management channel is a logical channel established between the master device and the first slave device for transmitting WMCI messages. Generally, different management channels correspond to different logical port identifiers (port IDs). Different logical port identifiers may correspond to the same physical transceiver port, or they may correspond to different physical transceiver ports; this is not limited here. For example, the first management channel corresponds to the master device's Port ID1 and the first slave device's Port ID1, while other management channels correspond to the master device's Port ID2 and the first slave device's Port ID2. Here, Port ID1 and Port ID2 may correspond to the same physical transceiver port, or they may correspond to different physical transceiver ports.

[0217] In addition, such as Figure 5AAs shown, if the master device's rate level is 2.5G, the first message is encapsulated in the payload field of an FTTR Encapsulation Method (FEM) frame. The FEM port ID in the FEM frame header is assigned by the master device. This FEM port ID not only indicates that the first message is a WMCI message, but also indicates the sender and receiver of the WMCI message (i.e., the first message), that is, it indicates that the WMCI message (i.e., the first message) corresponds to the first slave device and not other slave devices. Therefore, the FEM port ID can be used to distinguish WMCI messages from other control messages in the FTTR system (e.g., FMCI messages or OMCI messages). It should be noted that when the master device's rate class is 2.5G, the downlink rate of the master device is 2.48832 Gbit / s; the uplink rate of the master device can be 1.24416 Gbit / s, or 2.48832 Gbit / s, and can support both simultaneously. The slave device's downlink rate is 2.48832 Gbit / s, and its uplink rate is 1.24416 Gbit / s or 2.48832 Gbit / s. It should also be noted that the payload length L of the FEM frame is equal to the length L of the WMCI message, where L is a positive integer.

[0218] In addition, such as Figure 5BAs shown, if the master device's rate class is 10G, the first message is encapsulated in the payload field of a 10G-FTTR Encapsulation Method (XFEM) frame. The XFEM port ID in the XFEM frame header is assigned by the master device. This XFEM port ID not only indicates that the first message is a WMCI message, but also indicates the sender and receiver of the WMCI message (i.e., the first message), that is, it indicates that the WMCI message (i.e., the first message) corresponds to the first slave device and not other slave devices. Therefore, the XFEM port ID can be used to distinguish WMCI messages from other control messages in the FTTR system. It should be noted that when the master device's rate class is 10G, the downlink rate of the master device is 9.95328 Gbit / s; the uplink rate of the master device can be 9.95328 Gbit / s, 2.48832 Gbit / s, or both simultaneously. The slave device's downlink rate is 9.95328 Gbit / s, and its uplink rate is either 9.95328 Gbit / s or 2.48832 Gbit / s. It should also be noted that the payload length P of the XFEM frame is an integer multiple of 4 bytes, but the length of the WMCI message may not be an integer multiple of 4 bytes. Therefore, the XFEM payload may need to include 0 to 3 bytes of padding fields while carrying the WMCI message.

[0219] In addition, such as Figure 5C As shown, the FEM frame is encapsulated in the payload field of the data link layer (DLL) frame. For example... Figure 5D As shown, XFEM frames are encapsulated in the payload field of DLL frames. A DLL frame consists of a DLL frame header and a DLL frame payload. The DLL payload is formed on the transmitting side and processed by the service adaptation sublayer on the receiving side. The DLL frame header consists of three fixed-size partitions (PLOAMd, BIP, Plend) and one variable-size partition: a bandwidth mapping partition (BWmap). The bandwidth mapping (BWmap) indicates the uplink transmission position in the corresponding uplink physical frame (PHY frame) for different slave devices.

[0220] It should be noted that, in Figure 5C The example shown only illustrates that the payload of the DLL frame contains three FEM frames. In practical applications, the payload of the DLL frame can contain other numbers of FEM frames; this is not limited here. Figure 5D In the example shown, the payload of the DLL frame contains 3 XFEM frames. In actual applications, the payload of the DLL frame can contain other numbers of XFEM frames, which is not limited here.

[0221] Furthermore, embodiments of this application also provide a communication device 60, such as... Figure 6 As shown, Figure 6 This is a schematic diagram of the structure of a communication device 60 provided in an embodiment of this application. Figure 2 , Figure 3 or Figure 4 The specific implementation of the master device and slave device (e.g., the first slave device) in the flowchart shown can be found in [reference]. Figure 6 The internal structure of the communication device 60 shown. When the communication device 60 is used to implement... Figure 2 , Figure 3 or Figure 4 When the communication device 60 is used to implement the function of the master device in the method shown, it can be a master gateway or an MFU. Figure 2 , Figure 3 or Figure 4 When the method shown uses the slave device function, the communication device 60 can be a slave gateway or SFU.

[0222] like Figure 6 As shown, the communication device 60 may include a processor 601 and a transceiver 602, with the processor 601 coupled to the transceiver 602. The processor 601 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 601 may refer to a single processor or may include multiple processors; no specific limitation is made here.

[0223] The aforementioned transceiver 602 can also be referred to as a transceiver unit, transceiver, transceiver device, etc. Optionally, the device in the transceiver unit that performs the receiving function can be regarded as the receiving unit, and the device in the transceiver unit that performs the transmitting function can be regarded as the transmitting unit. That is, the transceiver unit includes a receiving unit and a transmitting unit. The receiving unit can also be referred to as a receiver, input port, receiving circuit, etc., and the transmitting unit can be referred to as a transmitter, transmitter, or transmitting circuit, etc.

[0224] Optionally, the communication device 60 further includes a memory 603. The processor 601 is coupled to the memory 603. The memory 603 is primarily used to store software programs and data. The memory 603 can exist independently, connected to the processor 601. Optionally, the memory 603 can be integrated with the processor 601, for example, integrated within one or more chips. The memory 603 can store program code executing the technical solutions of the embodiments of this application, and its execution is controlled by the processor 601. The various types of computer program code being executed can also be considered as drivers for the processor 601. The memory 603 can include volatile memory, such as random-access memory (RAM); the memory can also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); the memory 603 can also include combinations of the above types of memory. Memory 603 can refer to a single memory or may include multiple memories. For example, memory 603 is used to store various types of data.

[0225] In one implementation, the communication device 60 is used to implement Figure 2 The corresponding method embodiment describes the function of the master device. Specifically, the processor 601 is used to generate a first message, which is a Wireless LAN Management and Control Interface (WMCI) message. The first message includes first indication information, which indicates that parameters are carried in Type Length Value (TLV) format. The transceiver 602 is used to send the first message to the first slave device.

[0226] In one possible implementation, transceiver 602 is further configured to receive a response message to a first message from a first slave device, the response message including first indication information.

[0227] In one possible implementation, the first indication information indicates that the first message or the response message to the first message carries parameters in TLV format.

[0228] In one possible implementation, the first indication information is located in the message content field; or, the first indication information is located in the message type identifier field; or, the first indication information is located in the message length and processing requirement fields. For example, the first message includes the first indication information, which is located in one of the message content field, the message type identifier field, or the message length field (i.e., the message length and processing requirement fields) of the first message.

[0229] In one possible implementation, the message content field includes a parameter mask field, and the first indication information is located in the parameter mask field.

[0230] Optionally, the first indication information is a bit in the parameter mask field. For example, the first indication information is the 16th bit of the parameter mask field.

[0231] In another possible implementation, the message type identifier field is set to the first indication information.

[0232] Optionally, the message type identifier field may be at least one byte in size, and the first indication information may be at least one byte in size. For example, the message type identifier field may be 2 bytes in size, and the first indication information may be 2 bytes in size.

[0233] Optionally, the message content field of the first message includes a parameter mask field, where each bit of the parameter mask field is set to 0.

[0234] Optionally, the first two bytes of the message content field of the first message are used to carry parameters in TLV format.

[0235] In another possible implementation, the first indication information is at least one of the 3rd to 6th bits in the message length and processing requirement fields.

[0236] Optionally, the first two bytes of the message content field of the first message are used to carry parameters in TLV format.

[0237] In one possible implementation, the type field of the TLV format is 2 bytes in size, the length field of the TLV format is 1 byte in size, and the value field of the TLV format is at least one byte in size.

[0238] In another implementation, the communication device 60 is used to implement Figure 2 This corresponds to the function of the slave device (e.g., the first slave device) in the corresponding method embodiment. Specifically, the transceiver 602 is used to receive a first message, which is a Wireless LAN Management and Control Interface (WMCI) message. The first message includes first indication information, which indicates that parameters are carried in Type Length Value (TLV) format.

[0239] In one possible implementation, transceiver 602 is also used to send a response message to the first message.

[0240] For other implementation methods, please refer to the relevant introduction on the main device side above, which will not be repeated here.

[0241] In one implementation, the communication device 60 is used to implement Figure 3This corresponds to the function of the master device in the method embodiment. Specifically, transceiver 602 is used to receive a second message, which is a Wireless LAN Management and Control Interface (WMCI) message. The second message includes first indication information, which indicates that parameters are carried in Type Length Value (TLV) format.

[0242] In another implementation, the communication device 60 is used to implement Figure 3 This corresponds to the function of the slave device (e.g., the first slave device) in the corresponding method embodiment. Specifically, the processor 601 is used to generate a second message, which is a Wireless LAN Management and Control Interface (WMCI) message. The second message includes first indication information, which indicates that parameters are carried in Type Length Value (TLV) format. The transceiver 602 is used to transmit the second message.

[0243] For other implementation methods, please refer to the relevant introduction on the main device side above, which will not be repeated here.

[0244] In one implementation, the communication device 60 is used to implement Figure 4 The corresponding method embodiment describes the function of the master device. Specifically, transceiver 602 is used to obtain version information of the first slave device. The version information indicates the version type of WMCI messages supported by the first slave device. The version information includes a first version type, which indicates that the first slave device supports communication using WMCI messages of the first version type. The WMCI messages of the first version type use TLV format to transmit parameters. Processor 601 is used to determine configuration information based on the version information of the first slave device. Transceiver 602 is also used to send configuration information to the first slave device. The configuration information includes the first version type.

[0245] In another implementation, the communication device 60 is used to implement Figure 4 This corresponds to the function of the slave device (e.g., the first slave device) in the corresponding method embodiment. Specifically, transceiver 602 is used to send version information of the first slave device. The version information is used to indicate the version type of WMCI messages supported by the first slave device. The version information includes a first version type, which indicates that the first slave device supports communication using WMCI messages of the first version type. The WMCI messages of the first version type use TLV format to transmit parameters. Transceiver 602 is also used to receive configuration information, which includes the first version type.

[0246] Please refer to the preceding text for details. Figure 2 , Figure 3 or Figure 4 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0247] like Figure 7As shown, this application also provides a communication device 70. The communication device 70 can be a slave device (e.g., a first slave device) or a master device, or a component (e.g., an integrated circuit, a chip, etc.) of a slave device (e.g., a first slave device) or a master device. The communication device 70 can also be other communication modules used to implement the methods in the method embodiments of this application.

[0248] The communication device 70 may include a processing module 701 (or processing unit). Optionally, it may also include an interface module 702 (or transceiver unit or transceiver module) and a storage module 703 (or storage unit). The interface module 702 is used to enable communication with other devices. The interface module 702 may be, for example, a transceiver module or an input / output module.

[0249] In one possible design, such as Figure 7 One or more modules may be implemented by one or more processors, or by one or more processors and memory; or by one or more processors and transceivers; or by one or more processors, memory, and transceivers. This application does not limit the implementation in this way. The processors, memory, and transceivers can be configured individually or integrated into one unit.

[0250] The communication device 70 is equipped to implement the functions of a slave device (e.g., a first slave device) as described in the embodiments of this application. For example, the communication device 70 includes modules, units, or means corresponding to the steps described in the embodiments of this application for executing steps involving the slave device (e.g., the first slave device). These functions, units, or means can be implemented in software, hardware, or a combination of both. Further details can be found in the corresponding descriptions in the foregoing method embodiments. Please refer to the preceding text for specific details. Figure 6 The corresponding embodiment is the communication device 60.

[0251] Alternatively, the communication device 70 may have the functions of the main device described in the embodiments of this application. For example, the communication device 70 includes modules, units, or means corresponding to the steps involved in the main device described in the embodiments of this application. These functions, units, or means can be implemented by software, hardware, or hardware executing corresponding software, or a combination of software and hardware. Further details can be found in the corresponding descriptions in the foregoing method embodiments. Please refer to the preceding text for specific details. Figure 6 The corresponding embodiment is the communication device 60.

[0252] Furthermore, this application provides a computer program product comprising one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. For example, implementing the aforementioned... Figure 2 , Figure 3 or Figure 4 Methods related to the slave device (e.g., the first slave device). For example, implementing the methods described above. Figure 2 , Figure 3 or Figure 4 The method relates to the main device in the process. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0253] Furthermore, this application also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform the aforementioned functions. Figure 2 , Figure 3 or Figure 4 Methods related to slave devices (e.g., the first slave device).

[0254] Furthermore, this application also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform the aforementioned functions. Figure 2 , Figure 3 or Figure 4 Methods related to the master device in the process.

[0255] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0256] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An optical network communication method applied to an optical fiber network, the optical fiber network comprising a master device and at least one slave device, the at least one slave device comprising a first slave device, characterized in that, include: The first communication device sends a first message to the second communication device. The first message is a Wireless Local Area Network Management and Control Interface (WMCI) message. The first message includes a first field and a parameter mask field. The value of the first field indicates whether the first message carries a parameter in TLV format. The first field is located in the message length field of the first message. Each bit of the parameter mask field corresponds to a fixed parameter. The value of one bit of the parameter mask field is used to indicate whether the first message carries the fixed parameter corresponding to the bit. Wherein, the first communication device is the master device and the second communication device is the first slave device; or, the first communication device is the first slave device and the second communication device is the master device.

2. The method according to claim 1, characterized in that, The method further includes: The first communication device receives a second message from the second communication device, the second message including the first field.

3. The method according to claim 1 or 2, characterized in that, The first field is the 6th bit from the least significant bit of the message length field.

4. The method according to claim 1 or 2, characterized in that, When the value of the first field is 0, the first message does not carry parameters in TLV format; when the value of the first field is 1, the first message carries parameters in TLV format.

5. The method according to claim 1, characterized in that, The parameter mask field consists of two bytes.

6. The method according to claim 5, characterized in that, At least one bit of the parameter mask field is set to 1, the first field is set to 0, and the first message carries at least one fixed parameter but does not carry parameters in TLV format.

7. The method according to claim 5, characterized in that, At least one bit of the parameter mask field is set to 1, the first field is set to 1, the first message carries at least one fixed parameter, and also carries at least one parameter in TLV format.

8. The method according to claim 5, characterized in that, All bits of the parameter mask field are 0, the first field is 1, the first message does not carry fixed parameters, but carries at least one parameter in TLV format.

9. The method according to claim 1, characterized in that, The first message is encapsulated in an FEM frame, and the FEM port identifier in the frame header of the FEM frame is used to indicate that the first message corresponds to the first slave device.

10. The method according to claim 9, characterized in that, The FEM frame is encapsulated in a data link layer DLL frame.

11. The method according to claim 1 or 2, characterized in that, The master device is an MFU, and the slave device is an SFU.

12. A communication device, characterized in that, include: Processor and memory; wherein the memory stores computer programs; The processor invokes the computer program to cause the communication device to perform the method of the master device as described in any one of claims 1 to 11.

13. A communication device, characterized in that, include: Processor and memory; wherein the memory stores computer programs; The processor invokes the computer program to cause the communication device to perform the slave device method as described in any one of claims 1 to 11.

14. A communication system, characterized in that, include: The communication device as claimed in claim 12, and the communication device as claimed in claim 13.

15. A chip, characterized in that, The chip is used to perform the method as described in any one of claims 1 to 11.

16. A computer-readable storage medium, characterized in that, The computer program is stored thereon and can be executed by a processor to cause the computer to perform the method as described in any one of claims 1 to 11.

17. A computer program product, characterized in that, It includes computer program instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 11.

Images