Optical network communication method and communication apparatus

Abstract

The present application provides an optical network communication method and a communication apparatus. The method is applied to an optical fiber network, the optical fiber network comprises a master device and at least one slave device, and the at least one slave device includes a first slave device. The first message sent by the master device to the first slave device carries first indication information, and the first indication information indicates an operation type of the first message. In this way, a first slave device can quickly make a decision, on the basis of first indication information, on whether to generate a response message of a first message, so that the communication efficiency between a master device and the slave devices is improved, thereby improving the management and control efficiency of the master device on the slave devices.

Description

An optical network communication method and communication device

[0001] This application claims priority to Chinese Patent Application No. 202411569873.4, filed on November 4, 2024, entitled "An Optical Network Communication Method and Communication Device", and Chinese Patent Application No. 202411755222.4, filed on November 29, 2024, entitled "An Optical Network Communication Method and Communication Device", the entire contents of which 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] The current standard does not clearly define the format of WMCI messages, which is not conducive to the master device's efficient management and control of the slave device. Summary of the Invention

[0005] This application provides an optical network communication method and communication device. By defining indication information to indicate the operation type of WMCI messages, it is beneficial to improve the management efficiency of master and slave devices.

[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 Local Area Network Management and Control Interface (WMCI) message, used to manage or control the WLAN function of the first slave device. The first message includes first indication information, which indicates the operation type of the first message.

[0007] In this aspect, the first message sent by the master device to the first slave device carries first indication information, which indicates the operation type of the first message. Therefore, it is beneficial for the first slave device to quickly decide whether to generate a response message for the first message based on the first indication information, thereby improving the communication efficiency between the master device and the slave device, and further improving the master device's control efficiency over the slave device.

[0008] In one possible implementation, the operation type of the first message includes a parameter request type, meaning the first indication information indicates that the operation type of the first message is a parameter request type. This parameter request type indicates that the master device requests the first slave device to send its parameters to the master device. In other words, it requires the first slave device to send its parameters to the master device. It can be understood that a parameter request type message (e.g., the first message) is to request the receiving end (e.g., the first slave device) to report one or more parameters; therefore, the receiving end (e.g., the first slave device) needs to send the parameters requested by the first message to the sending end (e.g., the master device). These parameters can be inherent parameters of the first slave device or parameters already configured for the first slave device by the master device; no limitation is made here.

[0009] In this embodiment, the operation type of the first message sent by the master device to the first slave device is a parameter request type, which prompts the first slave device to reply to the master device with the parameters requested by the master device. This allows the first slave device to quickly obtain the parameters that need to be reported based on the operation type of the received first message, thereby improving the efficiency of the master device obtaining parameters from the first slave device.

[0010] In another possible implementation, the operation type of the first message includes a parameter configuration type, meaning the first indication information indicates that the operation type of the first message is a parameter configuration type. This parameter configuration type indicates that the master device is sending configuration parameters of the first slave device to the first slave device. It can be understood that a message of parameter configuration type (e.g., the first message) is for configuring one or more parameters for the receiving end (e.g., the first slave device).

[0011] In this embodiment, the operation type of the first message sent by the master device to the first slave device is parameter configuration type, so as to enable the first slave device to perform parameter configuration based on the first message, which helps to improve the efficiency of the master device configuring parameters to the first slave device.

[0012] In one possible implementation, the first indication information includes a first value or a second value, wherein the first value is used to indicate that the operation type is a parameter request type, and the second value is used to indicate that the operation type is a parameter configuration type.

[0013] In one possible implementation, the first indication information is located in the message length and processing requirement field of the first message. For example, the first indication information is located in the 7th bit of the first byte of the message length and processing requirement field.

[0014] In another possible implementation, the first indication information is located in the message type identifier field of the first message. For example, the first indication information is located in the 8th bit or the 7th bit of the message type identifier field.

[0015] In one possible implementation, the first message further includes second indication information, which indicates the parameter set corresponding to the first message. This can be understood as the second indication information indicating the parameter set requested by the first message or the parameter set configured by the first message. For example, if the operation type of the first message is a parameter request type, then the parameter set indicated by the second indication information indicates which parameter set the parameters requested by the first message belong to, i.e., which parameter set the master device requests the first slave device to report through the first message to belong to. If the operation type of the first message is a parameter configuration type, then the parameter set indicated by the second indication information indicates which parameter set the parameters configured by the first message belong to, i.e., which parameter set the master device configures for the first slave device through the first message to belong to.

[0016] In this embodiment, the second indication information in the first message indicates which parameter set the parameter requested or configured in the first message belongs to. This helps improve the accuracy and efficiency of the master device obtaining parameters from the first slave device, thereby improving the master device's control efficiency over the slave device.

[0017] In one possible implementation, the second indication information is located in the message type identifier field of the first message.

[0018] In this embodiment, the second indication information is carried in the message type identifier field, which can be understood as classifying WMCI messages according to different sets (or types) of parameters acquired or configured. This enables fine-grained management of WMCI messages and helps improve the efficiency of master devices in controlling slave devices.

[0019] In one possible implementation, the parameter request type is further used to indicate the parameters of the parameter set indicated by the message type identifier field of the request first slave device; the parameter configuration type is further used to indicate the configuration parameters of the parameter set indicated by the message type identifier field of the master device to the first slave device.

[0020] In this embodiment, if the first indication information indicates that the operation type of the first message is a parameter request type, and the second indication information is carried in the message type identifier field, then the parameter request type indicates that the master device requests the first slave device to send parameters of the parameter set (or parameter type) indicated by the message type identifier field to the master device; if the first indication information indicates that the operation type of the first message is a parameter configuration type, and the second indication information is carried in the message type identifier field, then the parameter configuration type indicates that the master device sends configuration parameters of the parameter set (or parameter type) indicated by the message type identifier field to the first slave device.

[0021] In one possible implementation, the message content field of the first message further includes a parameter mask field, which indicates the parameters in the parameter set corresponding to the first message. This can be understood as the parameter mask field indicating which parameters in the request parameter set, or which parameters in the parameter set need to be configured.

[0022] In one possible implementation, the parameter mask field is the first two bytes of the message content field, and the remaining bytes of the message content field are used to carry the content of the parameters.

[0023] In one possible implementation, the parameter set includes any one of the following:

[0024] The parameters can be: device capability parameter set from the device WLAN; or, device operating parameter configuration parameter set from the device WLAN; or, WMCI characteristic parameter set; or, interference matrix parameter set; or, timer configuration parameter set.

[0025] 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.

[0026] 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.

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

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

[0029] 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 Local Area Network Management and Control Interface (WMCI) message, used to manage or control the WLAN function of the first slave device. The first message includes first indication information, used to indicate the operation type of the first message.

[0030] In one possible implementation, the operation type of the first message includes any of the following:

[0031] The parameter request type is used to instruct the master device to request the first slave device to send the parameters of the first slave device to the master device; or the parameter configuration type is used to instruct the master device to send the configuration parameters of the first slave device to the first slave device.

[0032] In one possible implementation, the first indication information includes a first value or a second value, wherein the first value is used to indicate that the operation type is a parameter request type, and the second value is used to indicate that the operation type is a parameter configuration type.

[0033] In one possible implementation, the first indication information is located in the message length and processing requirement field of the first message. For example, the first indication information is located in the 7th bit of the first byte of the message length and processing requirement field.

[0034] In another possible implementation, the first indication information is located in the message type identifier field of the first message. For example, the first indication information is located in the 8th bit or the 7th bit of the message type identifier field.

[0035] In one possible implementation, the first message further includes second indication information, which is used to indicate the parameter set corresponding to the first message.

[0036] In one possible implementation, the second indication information is located in the message type identifier field of the first message.

[0037] In one possible implementation, the parameter request type is further used to indicate the parameters of the parameter set indicated by the message type identifier field of the request first slave device; the parameter configuration type is further used to indicate the configuration parameters of the parameter set indicated by the message type identifier field of the master device to the first slave device.

[0038] In one possible implementation, the message content field of the first message further includes a parameter mask field, which is used to indicate the parameters in the parameter set corresponding to the first message.

[0039] In one possible implementation, the parameter mask field is the first two bytes of the message content field, and the remaining bytes of the message content field are used to carry the content of the parameters.

[0040] In one possible implementation, the parameter set includes any one of the following:

[0041] The parameters can be: device capability parameter set from the device WLAN; or, device operating parameter configuration parameter set from the device WLAN; or, WMCI characteristic parameter set; or, interference matrix parameter set; or, timer configuration parameter set.

[0042] In one possible implementation, the first message is encapsulated in the payload field of a fiber-to-room encapsulation mode (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.

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

[0044] In one possible implementation, the master device is the master fiber-to-room FTTR unit (MFU), and the slave device is the slave FTTR unit (SFU).

[0045] 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.

[0046] Thirdly, 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 sends a second message to the master device. The second message is a Wireless Local Area Network Management and Control Interface (WMCI) message, used to request management or control of the WLAN function of the first slave device. The second message includes third indication information, used to indicate the operation type of the second message.

[0047] In this aspect, the second message sent by the first slave device to the master device carries third indication information, which indicates the operation type of the second message. Therefore, it is beneficial for the master device to quickly decide whether to generate a response message for the second message based on the third indication information, thereby improving the communication efficiency between the master device and the slave device, and further improving the master device's control efficiency over the slave device.

[0048] In one possible implementation, the operation type of the second message includes any of the following:

[0049] The scheduling request type is used to request the master device to send scheduling configuration information to the first slave device; or, the parameter reporting type or alarm type is used for the first slave device to send the parameters of the first slave device or the alarm information of the first slave device to the master device.

[0050] In one possible implementation, the third indication information includes a first value or a second value, wherein the first value is used to indicate that the operation type is a scheduling request type, and the second value is used to indicate that the operation type is a parameter reporting type or an alarm type.

[0051] In one possible implementation, the third indication information is located in the message length and processing requirement field of the first message. For example, the third indication information is located in the 7th bit of the first byte of the message length and processing requirement field.

[0052] In another possible implementation, the third indication information is located in the message type identifier field of the first message. For example, the third indication information is located in the 8th bit or the 7th bit of the message type identifier field.

[0053] In one possible implementation, the second message further includes second indication information, which is used to indicate the parameter set corresponding to the second message.

[0054] In one possible implementation, the second indication information is located in the message type identifier field of the second message.

[0055] In one possible implementation, the scheduling request type is further used to indicate the scheduling configuration information of the parameter set indicated by the message type identifier field sent by the master device to the first slave device; or, the parameter reporting type or alarm type is further used to indicate the parameter or alarm type of the parameter set indicated by the message type identifier field sent by the first slave device to the master device.

[0056] In one possible implementation, the message content field of the second message further includes a parameter mask field, which is used to indicate the parameters in the parameter set corresponding to the second message.

[0057] In one possible implementation, the parameter mask field is the first two bytes of the message content field, and the remaining bytes of the message content field are used to carry the content of the parameters.

[0058] In one possible implementation, the parameter set includes any one of the following:

[0059] The parameters can be: device capability parameter set from the device WLAN; or, device operating parameter configuration parameter set from the device WLAN; or, WMCI characteristic parameter set; or, interference matrix parameter set; or, timer configuration parameter set.

[0060] In one possible implementation, the second message is encapsulated in the payload field of a fiber-to-room encapsulation mode (FEM) frame, and the FEM port identifier in the frame header of the FEM frame is used to indicate that the second message corresponds to the first slave device.

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

[0062] In one possible implementation, the master device is the master fiber-to-room FTTR unit (MFU), and the slave device is the slave FTTR unit (SFU).

[0063] 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.

[0064] Fourthly, 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 receives a second message from the first slave device. The second message is a Wireless Local Area Network Management and Control Interface (WMCI) message, used to request management or control of the WLAN function of the first slave device. The second message includes third indication information, used to indicate the operation type of the second message.

[0065] 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 third aspect, which will not be repeated here.

[0066] Fifthly, this application provides a communication device 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 communication device can be the master device in the optical fiber network, or a functional module or chip within the master device. The communication device includes a transceiver and a processor. The processor is used to generate a first message, and the transceiver is used to send the first message to the first slave device. The first message is a Wireless Local Area Network Management and Control Interface (WMCI) message, used to manage or control the WLAN function of the first slave device, and includes first indication information indicating the operation type of the first message.

[0067] 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.

[0068] Sixthly, this application provides a communication device 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 communication device may be the first slave device in the optical fiber network, or it may be a functional module or chip within the first slave device. The communication device includes a transceiver and a processor. The transceiver is used to receive a first message from the master device, the first message being a Wireless Local Area Network Management and Control Interface (WMCI) message, the first message being used to manage or control the WLAN function of the first slave device, and the first message including first indication information indicating the operation type of the first message.

[0069] 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 second aspect, which will not be repeated here.

[0070] In a seventh aspect, this application provides a communication device 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 communication device may be the first slave device in the optical fiber network, or it may be a functional module or chip within the first slave device. The communication device includes a transceiver and a processor. The processor is used to generate a second message, and the transceiver is used to send the second message. The second message is a Wireless Local Area Network Management and Control Interface (WMCI) message, used to request management or control of the WLAN function of the first slave device. The second message includes third indication information, which indicates the operation type of the second message.

[0071] 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 third aspect, which will not be repeated here.

[0072] Eighthly, this application provides a communication device 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 communication device can be the master device in the optical fiber network, or a functional module or chip within the master device. The communication device includes a transceiver and a processor. The transceiver is used to receive a second message from the first slave device, the second message being a Wireless Local Area Network Management and Control Interface (WMCI) message, the second message being used to request management or control of the WLAN function of the first slave device, and the second message including third indication information, the third indication information being used to indicate the operation type of the second message.

[0073] 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 fourth aspect, which will not be repeated here.

[0074] Ninthly, embodiments of this application provide a communication device, which may 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 further 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 fourth aspect or any embodiment of the fourth 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 fourth aspect or any embodiment of the fourth 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.).

[0075] In a tenth aspect, 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 stores 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 third aspect or any embodiment of the third 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 third aspect or any embodiment of the third 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.).

[0076] Eleventhly, 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.

[0077] In a twelfth aspect, 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.

[0078] In a thirteenth aspect, 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.

[0079] In a fourteenth aspect, embodiments of this application provide an optical fiber network including a master device in the third aspect and any embodiment of the third aspect, and a slave device (e.g., a first slave device) in the fourth aspect and any embodiment of the fourth aspect.

[0080] In a fifteenth aspect, embodiments of this application provide an optical fiber network including a master device in the sixth aspect and any embodiment thereof, and a slave device (e.g., a first slave device) in the fifth aspect and any embodiment thereof. Attached Figure Description

[0081] Figure 1A is an example diagram of the network architecture of an optical fiber network;

[0082] Figure 1B shows another example of a fiber optic network architecture.

[0083] Figure 1C shows an example of an FTTR system;

[0084] Figure 2 is a flowchart of the optical network communication method in this application;

[0085] Figure 3 is another flowchart of the optical network communication method in this application;

[0086] Figure 4 is another flowchart of the optical network communication method in this application;

[0087] Figure 5A is an example diagram of an FEM frame encapsulating WMCI messages;

[0088] Figure 5B is an example diagram of an XFEM frame encapsulating WMCI messages;

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

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

[0091] Figure 6 is a schematic diagram of an embodiment of the communication device in this application;

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

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] The optical network communication method provided in this application is applied to optical fiber networks. Figure 1A is an example diagram of the architecture of a conventional optical fiber network. As shown in Figure 1A, the optical fiber 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 generally connected to the ONU (or ONT) through the ODN. The ODN includes a network composed of one or more optical devices such as optical fibers, optical distribution frames (ODFs), optical splitters (also known as splitters), and combiners. In addition, the aforementioned OLT can be connected to the operator's network through a network-side interface, and the OLT can be connected to the ODN through a dedicated interface, which in turn is connected to the ONU (or ONT) through a dedicated interface. In the downlink direction, the OLT broadcasts the downlink optical signal and distributes the downlink optical signal to each ONU (or ONT) through 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 respective uplink time slot allocated 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 fiber-optic composite cable, etc.

[0098] Figure 1B is a schematic diagram of a fiber optic network provided in this application. As shown in Figure 1B, 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 at least one slave device 02 via optical fiber. For example, the master device 01 is connected to at least one slave device 02 via an optical distribution network. The master device 01 can manage or control specific functions of one or more slave devices 02 based on at least one protocol. For example, the master device 01 can manage or control 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. For example, in a fiber to the room (FTTR) scenario, the master device 01 can be called a main FTTR unit (MFU), FTTR master device, or master gateway, and the slave device 02 can be called a sub FTTR unit (SFU), FTTR slave device, or slave gateway.

[0099] Figure 1C shows an example of an FTTR network location. As shown in Figure 1C, FTTR is a fiber optic network built on top of FTTH / O, providing fiber optic coverage within broadband customer networks (e.g., homes or offices). Fiber optic connections are used between the FTTR master device and the FTTR slave devices in each room. Both the FTTR master and FTTR 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) device. The southbound connection of the FTTR master device's FTTR transceiver unit connects to the FTTR transceiver units of the FTTR slave devices via the indoor fiber distribution network (IFDN), also providing gateway and other network functions. The FTTR transceiver units of the FTTR 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.

[0100] For example, in an FTTR system management architecture, the master device manages or controls the WLAN functions of the slave device by exchanging WMCI messages. However, master devices may have different management needs and characteristics. Furthermore, the current standard does not clearly define the format of WMCI messages, which hinders efficient communication between the master and slave devices.

[0101] This application provides an optical network communication method and communication device. By defining indication information to indicate the operation type of WMCI messages, it is beneficial to improve the management efficiency of master and slave devices.

[0102] The main processes of applying the optical network communication method provided in this application to downlink and uplink communication scenarios will be described below with reference to Figures 2 and 3:

[0103] Figure 2 shows 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 in Figure 2, the optical network communication method includes the following steps:

[0104] 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.

[0105] 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.

[0106] 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 and control). The first message includes first indication information, which indicates the operation type of the first message. It should be noted that the operation type in this embodiment and subsequent embodiments can also be called operation code, control type, control code, action type, or action code, etc., and is not limited here. In this embodiment and subsequent embodiments, the term "operation type" will be used as an example for description.

[0107] In one possible implementation, the operation type of the first message includes a parameter request type, meaning the first indication information indicates that the operation type of the first message is a parameter request type. This parameter request type indicates that the master device requests the first slave device to send its parameters to the master device. In other words, it requires the first slave device to send its parameters to the master device. It can be understood that a parameter request type message (e.g., the first message) is to request the receiving end (e.g., the first slave device) to report one or more parameters; therefore, the receiving end (e.g., the first slave device) needs to send the parameters requested by the first message to the sending end (e.g., the master device). These parameters can be inherent parameters of the first slave device or parameters already configured for the first slave device by the master device; no limitation is made here.

[0108] In another possible implementation, the operation type of the first message includes a parameter configuration type, meaning the first indication information indicates that the operation type of the first message is a parameter configuration type. This parameter configuration type indicates that the master device is sending configuration parameters of the first slave device to the first slave device. It can be understood that a message of parameter configuration type (e.g., the first message) is for configuring one or more parameters for the receiving end (e.g., the first slave device).

[0109] It should also be noted that "Parameter Request Type" and "Parameter Configuration Type" are merely names, and other names can be used to describe the aforementioned two operation types. For example, the aforementioned two operation types can also be called "First Operation Type" and "Second Operation Type," etc., and examples will not be listed here.

[0110] It should be noted that the parameters in the aforementioned two embodiments can be determined by another indication information in the first message. Optionally, the first message also includes second indication information, which is used to indicate the parameter set corresponding to the first message. For example, the parameter set configured by the first message, or the capability parameter set requested by the first message. A parameter set can be understood as a collection of multiple parameters. For example, if the operation type of the first message is a parameter request type, then the parameter set indicated by the second indication information indicates which parameter set the parameters requested by the first message belong to, that is, which parameter set the parameters reported by the first slave device requested by the master device through the first message belong to. If the operation type of the first message is a parameter configuration type, then the parameter set indicated by the second indication information indicates which parameter set the parameters configured by the first message belong to, that is, which parameter set the parameters configured by the master device for the first slave device through the first message belong to.

[0111] It should also be noted that a parameter set generally contains parameters of the same type or with similar functions; therefore, a parameter set can also be understood as a parameter type. The second indication information can also be understood as indicating the parameter type corresponding to the first message. For example, the parameter type configured through the first message, or the parameter type requested through the first message. For instance, if the operation type of the first message is a parameter request type, then the parameter type indicated by the second indication information represents the parameter type requested by the first message, that is, what type of parameter the master device requests the first slave device to report through the first message. If the operation type of the first message is a parameter configuration type, then the parameter type indicated by the second indication information represents the parameter type configured by the first message, that is, what type of parameter the master device configures for the first slave device through the first message.

[0112] Therefore, when the first message contains both first indication information and second indication information, if the first indication information indicates that the operation type of the first message is a parameter request type, then the parameter request type indicates that the master device requests the first slave device to send the parameters of the parameter set (or parameter type) indicated by the second indication information to the master device; if the first indication information indicates that the operation type of the first message is a parameter configuration type, then the parameter configuration type indicates that the master device sends the configuration parameters of the parameter set (or parameter type) indicated by the second indication information to the first slave device.

[0113] Optionally, the first indication information includes a first value or a second value. The first value indicates that the operation type of the first message is a parameter request type; the second value indicates that the operation type of the first message is a parameter configuration type.

[0114] Optionally, the first indication information is represented by at least one newly defined bit in the WMCI message. In one example, the first indication information is a newly defined bit in the WMCI message, i.e., a first value and a second value are two possible values ​​for this newly defined bit. The two values ​​of this bit indicate the parameter request type and the parameter configuration type, respectively. For example, a value of 1 indicates that the operation type of the first message is a parameter request type, and a value of 0 indicates that the operation type of the first message is a parameter configuration type. Another example is that a value of 0 indicates that the operation type of the first message is a parameter request type, and a value of 1 indicates that the operation type of the first message is a parameter configuration type. In another example, the first indication information is two newly defined bits in the WMCI message, i.e., a first value and a second value are two possible values ​​for this newly defined 2 bits. The two values ​​of this bit indicate the parameter request type and the parameter configuration type, respectively. For example, a value of 01 indicates that the operation type of the first message is a parameter request type, and a value of 00 indicates that the operation type of the first message is a parameter configuration type. For example, a value of 11 for the two bits indicates that the operation type of the first message is a parameter request type, and a value of 00 for the two bits indicates that the operation type of the first message is a parameter configuration type. This embodiment does not limit the specific implementation of the first and second values, only ensuring that the first and second values ​​are different. In addition, the first indication information can also be implemented using three bits or even four bits, and examples will not be listed here.

[0115] Specifically, the first instruction information can be carried in the first message in any of the following ways:

[0116] In one possible implementation, the first indication information is located in the message length field of the first message, which indicates the length of the message content carried by the first message. The first indication information is located in one or two bits of the first byte of the message length field. For example, the first indication information is located in bit 7 of the first byte of the message length field, that is, the 7th bit from low to high in the first byte. Another example is that the first indication information is located in bits 7 and 6 of the first byte of the message length field, that is, the 6th and 7th bits from low to high in the first byte.

[0117] Optionally, the message length field may also include processing requirement indication information to indicate the message priority. For example, the processing requirement indication information is located in bit 8 of the first byte of the message length field, i.e., the most significant bit of the first byte. In this case, the message length field may also be referred to as the message length and processing requirement field. For example, the message length and processing requirement field of the first message includes processing requirement indication information and first indication information, wherein the processing requirement indication information is located in bit 8 of the first byte of the message length and processing requirement field, and the first indication information is located in bit 7 of the first byte of the message length and processing requirement field.

[0118] For example, Table 1-1 below is an example of a first message implemented using one bit of the message length and processing requirement fields for the first indication information.

[0119] Table 1-1

[0120] As shown in Table 1-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. The third and fourth bytes are the message length and processing requirement fields, consisting of three fields: message priority, operation type, and message content length. Among them, X (the most significant bit of the third byte): is used to indicate the priority of processing this message. When X=1, it indicates that the message has a high priority; when X=0, it indicates that the message has a low priority. C: is the first indication information introduced above, used to indicate 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 first slave device to send its parameters to the master device; that is, the first slave device is required to send its 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 configuration parameters of the first slave device to the first slave device. LL LLLL LLLL: Indicates the length of the message content, with a value range of 0 to 1023. The remaining 4 bits RRRR are reserved.

[0121] It should be noted that the second indication information can be carried in the message type identifier field of the first message. The second indication information indicates the parameter set or parameter type corresponding to the first message. For example, the lower n bits of the message type identifier field are used to carry the second indication information, where n is an integer greater than 2. For example, n = 5, that is, the first to fifth bits of the first byte of the first message carry the second indication information. Another example is n = 6, that is, the first to sixth bits of the first byte of the first message carry the second indication information.

[0122] It should be noted that including the second indication information in the message type identifier field can be understood as classifying WMCI messages according to the different sets (or types) of parameters acquired or configured. When the first message contains both the first and second indication information, if the first indication information indicates that the operation type of the first message is a parameter request type, and the second indication information is included in the message type identifier field, then the parameter request type indicates that the master device requests the first slave device to send parameters of the parameter set (or parameter type) indicated by the message type identifier field to the master device; if the first indication information indicates that the operation type of the first message is a parameter configuration type, and the second indication information is included in the message type identifier field, then the parameter configuration type indicates that the master device sends configuration parameters of the parameter set (or parameter type) indicated by the message type identifier field to the first slave device. Taking Table 1-1 as an example, in the downlink direction, when C=1, it indicates that the operation type of the message is a parameter request type, which requests the slave device (e.g., the first slave device) to send the output indicated by the message type ID field; when C=0, it indicates that the message is a parameter configuration type message, and the parameter type configured in the message is indicated by the message type ID field.

[0123] In addition, bytes 5 through N are the message content field, used to carry the specific content of the message, which is 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, or which parameters in the parameter set need to be configured. It should be noted that since the parameter mask is 16 bits (i.e., 2 bytes) in size, a parameter set can contain a maximum of 16 parameters, and each message type of parameter set 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. For downlink request messages, the parameter mask represents the parameters that 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. It should be noted that when C=1, indicating that the operation type of the message is a parameter request type, bytes 7 to N are invalid. After receiving the message, the receiving end (e.g., the first slave device) should return the corresponding parameters as instructed. Bytes (N+1) to (N+4) are message integrity check fields, which are 4 bytes in size and used to verify the sender's identity and prevent forged WMCI message attacks. This field follows the cyclic redundancy check (CRC) function.

[0124] For example, Table 1-2 below shows an example of a first message when the first indication information is represented by two bits in the message length and processing requirement fields.

[0125] Table 1-2

[0126] The example shown in Table 1-2 differs from the example in Table 1-1 only in the message length and processing requirement fields. For explanations of the other fields, please refer to the description in Table 1-1 above; they will not be repeated here. The first indication information can be represented by the 6th and 7th bits of the first byte of the message length and processing requirement fields. For example, in the 3rd byte, X: indicates the priority of processing this message. When X=1, it indicates that the message has a high priority; when X=0, it indicates that the message has a low priority. CC: This is the first indication information described above, used to indicate the operation type of this message. In the downlink direction, when CC=11, it indicates that the operation type of this message is a parameter request type, indicating that the master device requests the first slave device to send the parameters of the first slave device to the master device; when CC=00, it indicates that the operation type of this message is a parameter configuration type, indicating that the master device sends the configuration parameters of the first slave device to the first slave device. LL LLLL LLLL: Indicates the length of the message content, with a value range of 0 to 1023. The remaining 3 bits are reserved.

[0127] For example, in the downlink direction, when CC=11, the operation type of the message is identified as a parameter request type, requesting the slave device (e.g., the first slave device) to send the output indicated by the message type ID field; when CC=00, the message is identified as a parameter configuration type message, and the parameter type configured in the message is indicated by the message type ID field.

[0128] It should be understood that the values ​​of bit C in Table 1-1 and bit CC in Table 1-2 are only examples. In practical applications, other values ​​can be used to represent similar functions, and examples will not be listed here.

[0129] In another possible implementation, the first indication information is located in the message type identifier field of the first message. The second indication information can be carried in the message type identifier field of the first message, indicating the parameter set or parameter type corresponding to the first message. For example, if the message type identifier field is 1 byte (8 bits), the lower n bits can be used to carry the second indication information, and the higher m bits can carry the first indication information, where n is an integer greater than 2, m is an integer greater than 0, and m + n ≤ 8. For example, if n = 5 and m = 1, the first to fifth bits from low to high of the first byte of the first message carry the second indication information, and the most significant bit (i.e., the eighth bit from low to high) of the first byte of the first message carries the first indication information. As another example, if n = 5 and m = 2, the first to fifth bits from low to high of the first byte of the first message carry the second indication information, and the seventh and eighth bits from low to high of the first byte of the first message carry the first indication information. For example, if n=6 and m=1, the first 6 bits (from low to high) of the first byte of the first message carry the second indication information, and the most significant bit (the 8th bit from low to high) of the first byte of the first message carries the first indication information. For example, if n=6 and m=2, the first 6 bits (from low to high) of the first byte of the first message carry the second indication information, and the 7th and 8th bits (from low to high) of the first byte of the first message carry the first indication information.

[0130] For example, Tables 1-3 below show an example of a first message when the first indication information is implemented using one bit of the message type identifier.

[0131] Table 1-3

[0132] The example shown in Table 1-3 differs from the example in Table 1-1 only in the message length, processing requirement, and message type identifier fields. For explanations of the remaining fields, please refer to the descriptions in Table 1-1 above; they will not be repeated here. The first five bits (from low to high) of the first byte of the first message carry the second indication information, while the most significant bit (the eighth bit from low to high) of the first byte carries the first indication information. In the downlink direction, when C=1, the operation type of this message is identified as a parameter request type, indicating that the master device requests the first slave device to send its parameters to the master device; when C=0, the operation type of this message is identified as a parameter configuration type, indicating that the master device sends the configuration parameters of the first slave device to the first slave device. In the downlink direction, when C=1, the message indicates a parameter request type operation, requesting the slave device (e.g., the first slave device) to send the output indicated by the second indication information (i.e., bit ZZZZZ); when C=0, the message indicates a parameter configuration type message, with the second indication information (i.e., bit ZZZZZ) indicating the parameter type configured in the message. Furthermore, in the third byte, X: indicates the priority for processing this message. When X=1, it indicates a high priority; when X=0, it indicates a low priority. LL LLLL LLLL: indicates the length of the message content, ranging from 0 to 1023. The remaining 5 bits RRRRR are reserved.

[0133] Optionally, the set of parameters indicated by the second indication information can be any of the following:

[0134] (1) The device capability parameter set of the slave device WLAN, which includes parameters related to the WLAN capabilities of the slave device. For example, Wi-Fi version number, number of Wi-Fi bands, number of supported service set identifiers (SSIDs), supported transmit power level, number of antennas, multiple-in multiple-out (MIMO) capability, etc.

[0135] In one example, the meanings of the various parameters included in the device capability parameter set of the device WLAN are shown in Table 2-1-1 below:

[0136] Table 2-1-1

[0137] For example, parameters related to the WLAN capabilities of a device include WMCI version number, Wi-Fi version number (also known as 802.11 version number), number of frequency bands (i.e., number of Wi-Fi frequency bands), frequency band (i.e., Wi-Fi frequency bands), number of supported service set identifiers (SSIDs), supported transmit power levels, number of antennas, multiple-in multiple-out (MIMO) capability, channel width, and WMCI, etc.

[0138] In one example, the meanings of the various parameters included in the device capability parameter set of the device WLAN are shown in Table 2-1-2 below:

[0139] Table 2-1-2

[0140] It should be noted that the WMCI features listed in sequence 10 of Table 2-1-2 represent the WMCI feature parameters that the device supports or does not support. These WMCI feature parameters include time-domain scheduling, power saving, enhanced distributed channel access (EDCA), roaming, spatial multiplexing, frequency-domain scheduling, and Wi-Fi time synchronization. The meaning of the bitmap is illustrated using the order of the parameters in Table 2-3 below. When the WMCI feature parameter set contains different parameters, or when the order of the parameters in the WMCI feature parameter set differs from the example shown in Table 2-3, the WMCI bitmap listed in sequence 10 of Table 2-1-2 will also be different. For example, if the WMCI characteristic parameter set includes time-domain scheduling, frequency-domain scheduling, cooperative EDCA, roaming, spatial multiplexing, and energy saving in sequence, then the WMCI bit diagram in Table 2-1-2 may include: Bit 0: Whether time-domain scheduling is supported; Bit 1: Whether frequency-domain scheduling is supported; Bit 2: Whether cooperative EDCA is supported; Bit 3: Whether roaming is supported; Bit 4: Whether spatial multiplexing is supported; Bit 5: Whether energy saving is supported. As the parameters included in the WMCI characteristic parameter set change, or the order of the parameters in the WMCI characteristic parameter set changes, there may be other examples of bit diagrams, which will not be listed here.

[0141] (2) The set of operating parameters for the slave device's WLAN, which includes parameters related to the WLAN operating parameter configuration of the slave device. For example, operating mode, SSID, password, beacon type, encryption mode, authentication mode, Wi-Fi Protected Access (WPA) encryption mode, WPA authentication mode, IEEE 11i encryption mode, IEEE 11i authentication mode, frequency band selection, channel, channel width, transmit power level, etc.

[0142] In one example, the meanings of the various parameters included in the device operating parameter set of the device WLAN are shown in Table 2-2-1 below:

[0143] Table 2-2-1

[0144] In another example, the meanings of the various parameters included in the device operating parameter set of the device WLAN are shown in Table 2-2-2 below:

[0145] Table 2-2-2

[0146] (3) WMCI characteristic parameter set, which includes parameters related to WMCI characteristics. For example, time-domain scheduling, energy saving, enhanced distributed channel access (EDCA), roaming, spatial multiplexing, frequency-domain scheduling, Wi-Fi time synchronization, etc.

[0147] For example, the meanings of the various parameters included in the WMCI characteristic parameter set are shown in Table 2-3 below:

[0148] Table 2-3

[0149] (4) Interference matrix parameter set, which includes the relevant parameters of the interference sources in the interference matrix. For example, the parameters of interference source 1, interference source 2, interference source 3, etc.

[0150] (5) Timer configuration parameter set, which includes parameters related to one or more timers. For example, parameters of timer 1, parameters of timer 2, parameters of timer 3, etc.

[0151] For example, the meanings of the various parameters included in the timer configuration parameter set are shown in Table 2-4 below:

[0152] Table 2-4

[0153] It should be noted that the timer configuration parameter set can also include parameters related to other timers, which are used to generate configuration messages related to the timers. These will not be listed here.

[0154] It should be noted that the five parameter sets listed above are merely examples. In practical applications, other parameter sets may exist, and each parameter set may contain other parameters. This embodiment does not limit the specific types of parameter sets or the specific parameters included in a parameter set. Furthermore, the order of parameters within the same parameter set listed above is also merely an example, and this embodiment does not limit the order of different parameters within the same parameter set.

[0155] 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.

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

[0157] In this embodiment, step 202 is an optional step. For example, when the operation type of the first message is parameter configuration type, the first slave device may not send a response message for the first message after configuring the parameters based on the first message.

[0158] In this embodiment, the first message sent by the master device to the first slave device carries first indication information, which indicates the operation type of the first message. Therefore, it is beneficial for the first slave device to quickly decide whether to generate a response message for the first message based on the first indication information, thereby improving the communication efficiency between the master device and the slave device, and further improving the master device's control efficiency over the slave device.

[0159] Figure 3 shows a flowchart of another embodiment of the optical network communication method provided in this application. In this embodiment, the scenario of a first slave device sending a message to a master device is used as an example. Of course, the entity executing the master device's action in this method can also be a device, module, or chip in the master device; the entity executing the first slave device's action in this method can also be a device, module, or chip in the first slave device, and this embodiment does not specifically limit this. For example, as shown in Figure 3, the optical network communication method includes the following steps:

[0160] 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.

[0161] 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.

[0162] The second message is a WMCI message, which includes a third indication message. The third indication message is used to indicate the operation type of the second message.

[0163] In one possible implementation, the operation type of the second message includes a scheduling request type, meaning the third indication information indicates that the operation type of the second message is a scheduling request type. This scheduling request type indicates that the first slave device requests the master device to send parameters for scheduling the first slave device, i.e., requests the master device to send scheduling parameters for the first slave device. It can be understood that a scheduling request type message (e.g., the second message) is to request the receiving end (e.g., the master device) to issue one or more scheduling parameters; therefore, the receiving end (e.g., the master device) needs to send the parameters requested by the second message to the sending end (e.g., the first slave device).

[0164] In another possible implementation, the operation type of the first message includes a parameter reporting type or an alarm type (hereinafter referred to as parameter reporting or alarm type), that is, the third indication information indicates that the operation type of the second message is a parameter reporting type or an alarm type. The parameter reporting type indicates that the first slave device sends parameters of the first slave device (e.g., inherent parameters or configured parameters) to the master device, and the alarm type indicates that the first slave device reports alarm information to the master device. It can be understood that a parameter reporting type message (e.g., the second message) is a message where the sender (e.g., the first slave device) actively reports one or more parameters to the receiver (e.g., the master device). An alarm type message (e.g., the second message) is a message where the sender (e.g., the first slave device) actively reports alarm information to the receiver (e.g., the master device).

[0165] It should also be noted that "scheduling request type" and "parameter reporting or alarm type" are merely names, and other names can also be used to describe the aforementioned two operation types. For example, the aforementioned two operation types can also be called "third operation type" and "fourth operation type," etc., and examples will not be listed here.

[0166] It should be noted that the parameters in the aforementioned two embodiments can be determined by another indication information in the second message. Optionally, the second message also includes second indication information, which is used to indicate the parameter set corresponding to the second message. For example, the capability parameter set reported through the second message, or the alarm type reported through the second message. A parameter set can be understood as a collection of multiple parameters. For example, if the operation type of the second message is a scheduling request type, then the parameter set indicated by the second indication information indicates which parameter set the parameters requested by the second message belong to, that is, which parameter set the parameters sent by the master device through the second message belong to. If the operation type of the second message is a parameter reporting or alarm type, then the parameter set indicated by the second indication information indicates which parameter set the parameters or alarm information reported by the second message belong to, that is, which parameter set the parameters or alarm information reported by the first slave device to the master device through the second message belong to.

[0167] It should also be noted that a parameter set generally contains parameters of the same type or with similar functions; therefore, a parameter set can also be understood as a parameter type. The second indication information can also be understood as indicating the parameter type of the second message. For example, if the operation type of the second message is a scheduling request type, then the parameter type indicated by the second indication information represents the parameter type of the parameter requested by the second message, that is, what type of parameter the first slave device requests the master device to schedule via the second message. If the operation type of the second message is a parameter reporting or alarm type, then the parameter type indicated by the second indication information represents the parameter type of the parameter reported by the second message or the alarm type reported by the second message, that is, what type of parameter the first slave device reports to the master device via the second message or what type of alarm information is reported.

[0168] Therefore, when the second message contains both the third indication information and the second indication information, if the third indication information indicates that the operation type of the second message is a scheduling request type, then the scheduling request type indicates that the first slave device requests the master device to send the parameters of the parameter set (or parameter type) indicated by the second indication information to the first slave device; if the third indication information indicates that the operation type of the second message is a parameter reporting or alarm type, then the parameter reporting or alarm type indicates that the first slave device sends the parameters of the parameter set (or parameter type) indicated by the second indication information to the master device or alarm information.

[0169] Optionally, the third indication information includes a first value or a second value. The first value indicates the scheduling request type; the second value indicates the parameter reporting or alarm type.

[0170] Optionally, the third indication information is represented by at least one newly defined bit in the WMCI message. In one example, the third indication information is a newly defined bit in the WMCI message, i.e., the first value and the second value are two possible values ​​of this newly defined bit. The two values ​​of this bit indicate the scheduling request type and the parameter reporting or alarm type, respectively. For example, a value of 1 indicates that the operation type of the second message is a scheduling request type, and a value of 0 indicates that the operation type of the second message is a parameter reporting or alarm type. Another example: a value of 0 indicates that the operation type of the second message is a scheduling request type, and a value of 1 indicates that the operation type of the second message is a parameter reporting or alarm type. In another example, the third indication information is two newly defined bits in the WMCI message, i.e., the first value and the second value are two possible values ​​of this newly defined 2-bit. The two values ​​of this bit indicate the scheduling request type and the parameter reporting or alarm type, respectively. For example, a value of 01 for the two bits indicates that the operation type of the second message is a scheduling request, and a value of 00 indicates that the operation type of the second message is a parameter reporting or alarm. As another example, a value of 11 for the two bits indicates that the operation type of the second message is a scheduling request, and a value of 00 indicates that the operation type of the second message is a parameter reporting or alarm. This embodiment does not limit the specific implementation of the first and second values, only ensuring that the first and second values ​​are different. Furthermore, the third indication information can also be implemented using three bits or even four bits; examples are not listed here.

[0171] Optionally, the third indication information can be located in the message length field of the second message or in the message type identifier field of the second message. The location of the third indication information in the second message is the same as the location of the first indication information in the first message. For details, please refer to the relevant description of the first indication information in the embodiment corresponding to Figure 2 above, which will not be repeated here.

[0172] For example, Table 3-1 below shows an example of a second message where the third indication information is implemented using one bit from the message length and processing requirement fields.

[0173] Table 3-1

[0174] The second message shown in Table 3-1 contains fields with essentially the same meaning as the first message shown in Table 1-1 above. The difference is that the example in Table 1-1 is a downlink message, where bit 7 of the first byte of the message length and processing requirement fields is the first indication information; while the example in Table 3-1 is an uplink message, where bit 7 of the first byte of the message length and processing requirement fields is the third indication information.

[0175] In the example shown in Table 3-1, C: represents the third indication information described above, used to indicate the operation type of this message. In the uplink direction, when C=1, it indicates that the operation type of this message is a scheduling request type, meaning that the first slave device requests the master device to send parameters for scheduling the first slave device, that is, it requests the master device to send scheduling parameters for the first slave device to the first slave device; when C=0, it indicates that the operation type of this message is a parameter reporting or alarm type, meaning that the first slave device reports the parameters of the first slave device to the master device or reports alarm information.

[0176] Furthermore, the second indication information can be carried in the message type identifier field. The position of the second indication information in the second message is the same as the position of the second indication information in the first message. For details, please refer to the relevant description in the embodiment corresponding to Figure 2 above, which will not be repeated here. If the third indication information indicates that the operation type of the second message is a scheduling request type, and the second indication information is carried in the message type identifier field, then the scheduling request type indicates that the first slave device requests the master device to send the scheduling parameters (e.g., scheduling configuration information, etc.) of the parameter set indicated by the message type identifier field to the first slave device; if the third indication information indicates that the operation type of the second message is a parameter reporting or alarm type, and the second indication information is carried in the message type identifier field, then the parameter reporting or alarm type indicates that the first slave device reports the parameters or alarm type of the parameter set indicated by the message type identifier field to the master device. Taking Table 3-1 as an example, in the uplink direction, when C=1, it indicates that the operation type of the message is a scheduling request type, requesting the master device to send the scheduling configuration indicated by the message type ID field; when C=0, it indicates that the message is a parameter reporting message or an alarm message, and the parameter or alarm type reported by the message type ID field is indicated by the message type ID field.

[0177] For explanations of the other fields in the example shown in Table 3-1, please refer to the relevant descriptions in the example shown in Table 1-1 above; they will not be repeated here.

[0178] It should be noted that the second message also includes a parameter mask field. For example, bytes 5 and 6 of the message content field carry a parameter mask, which is used to indicate the parameters in the parameter set corresponding to the second message. For example, the parameter mask field indicates which parameters in the parameter set need to be scheduled, which parameters in the parameter set need to be reported, or what type of alarm is being reported. For further information on the parameter mask field and the explanation of the parameter set, please refer to the relevant descriptions in the example shown in Table 1-1 above; they will not be repeated here.

[0179] For example, Table 3-2 below shows an example of a second message when the third indication information is implemented using one bit of the message type identifier.

[0180] Table 3-2

[0181] The second message shown in Table 3-2 contains fields with essentially the same meaning as the first message shown in Table 1-3 above. The difference is that the example in Table 1-3 is a downlink message, where the highest bit of the message type identifier field is the first indication information; while the example in Table 3-2 is an uplink message, where the highest bit of the message type identifier field is the third indication information.

[0182] 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 from the master device.

[0183] 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.

[0184] 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.

[0185] In this embodiment, the second message sent by the first slave device to the master device carries third indication information, which indicates the operation type of the second message. Therefore, it is beneficial for the master device to quickly decide whether to generate a response message for the second message based on the third indication information, thereby improving the communication efficiency between the master device and the slave device, and further improving the master device's control efficiency over the slave device.

[0186] It should be noted that the embodiments corresponding to Figure 2 and Figure 3 can be combined.

[0187] In one implementation, the second message can be a response message to the first message. For example, during initialization, the master device needs to obtain the basic capability information of the slave device and complete the configuration of the slave device's basic operating parameters.

[0188] In one example, the master device sends a first message to the first slave device (as shown in Table 4-1 below). This first message includes a first indication indicating that the operation type is a parameter request type (i.e., C=1 in Table 4-1), and a second indication indicating the slave device's WLAN device capability parameter set (i.e., ZZZZZ = SFU WLAN device capability in Table 4-1). The parameter mask field of the first message is used to indicate at least one parameter in the slave device's WLAN device capability parameter set. For example, if the slave device's WLAN device capability parameter set includes WiFi version number, number of Wi-Fi bands, Wi-Fi bands, number of supported SSIDs, supported transmit power level, number of antennas, MIMO capability, etc., then taking the first message requesting the WiFi version number, number of Wi-Fi bands, and Wi-Fi bands as an example, bits 8, 7, and 6 of the 5th byte in Table 4-1 are all 1, and the remaining bits are 0. After receiving the first message, the master device generates a second message (as shown in Table 4-2). This second message includes a third indication indicating that the operation type is parameter reporting (i.e., C = 0 in Table 4-2). The second message also includes a second indication indicating the device capability parameter set of the slave device's WLAN (i.e., ZZZZZ = SFU WLAN device capability in Table 4-2). The parameter mask field of the second message indicates which parameters from the slave device's WLAN device capability parameter set are reported in the second message. The remaining fields of the message content (bytes 7 to N) carry the specific content of the aforementioned parameters. For example, in the example shown in Table 4-2, bits 8, 7, and 6 of byte 5 are all 1, and the remaining bits are 0, indicating that the second message reports the WiFi version number, the number of Wi-Fi bands, and the Wi-Fi bands. In addition, the 7th byte of the second message carries the WiFi version number (e.g., supports 802.11AX; supports 802.11BE;), the 8th byte carries the value of the number of Wi-Fi bands (e.g., 2, i.e., supports 2 bands), and the 9th byte carries the Wi-Fi band information (i.e., supports 2.4G and 5G).

[0189] In the examples shown in Tables 4-1 and 4-2, the first message shown in Table 4-1 has the same sequence number as the second message shown in Table 4-2.

[0190] Table 4-1

[0191] Table 4-2

[0192] It should be noted that after the master device and slave device complete initialization using the aforementioned first and / or second messages, the master device can manage and control the relevant characteristics of WMCI. The management and control process is described below with reference to Figure 4:

[0193] Figure 4 shows a flowchart of another embodiment of the optical network communication method provided in this application. In this embodiment, the signaling interaction between the master device and the 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 in the master device; the entity executing the first slave device's actions in this method can also be a device, module, or chip in the first slave device. This embodiment does not specifically limit this. For example, as shown in Figure 4, the optical network communication method includes the following steps:

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

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

[0196] The third message is a WMCI message, used to manage or control the WLAN function of the first slave device. The third message includes a fourth indication message and a fifth indication message. The fourth indication message indicates the first feature, and the fifth indication message indicates whether the first feature of the first slave device is enabled.

[0197] The first characteristic can be a feature of WLAN functionality. Since WMCI is used to manage the WLAN functionality of slave devices, the first characteristic can also be understood as a feature related to WMCI. For example, the first characteristic can be any one of the following: time-domain scheduling, energy saving, cooperative EDCA, roaming, spatial multiplexing, frequency-domain scheduling, or Wi-Fi time synchronization. It should be noted that with the development of WMCI technology or changes in WLAN application scenarios, the first characteristic may also be other WLAN-related features or other WMCI-related features; this embodiment is not limited to these.

[0198] Optionally, the third message also includes second indication information, which indicates the parameter set of the third message. A parameter set can be understood as a collection of multiple parameters. The fourth indication information indicates one parameter from the parameter set indicated by the second indication information; that is, the first characteristic is the characteristic indicated by one parameter from the parameter set indicated by the second indication information. A parameter set generally contains parameters of the same type or with similar functions; therefore, a parameter set can also be understood as a parameter type. The fourth indication information indicates one parameter from the parameter type indicated by the second indication information; that is, the first characteristic is the characteristic indicated by one parameter from the parameter type indicated by the second indication information.

[0199] Optionally, the parameter set includes a WMCI characteristic parameter set. For example, the parameter set indicated by the second indication information is a WMCI characteristic parameter set, and the first characteristic is a characteristic indicated by a parameter in the WMCI characteristic parameter set, that is, the first characteristic is a characteristic related to WMCI.

[0200] For example, the parameters included in the WMCI characteristic parameter set and the order of the parameters can be as shown in Table 2-3 above.

[0201] In the examples shown in Table 2-3, the time-domain scheduling parameter is used to indicate time-domain scheduling characteristics, the energy-saving parameter is used to indicate energy-saving characteristics, the cooperative EDCA parameter is used to indicate cooperative EDCA characteristics, the roaming parameter is used to indicate roaming characteristics, the spatial multiplexing parameter is used to indicate spatial multiplexing characteristics, the frequency-domain scheduling parameter is used to indicate frequency-domain scheduling characteristics, and the Wi-Fi time synchronization parameter is used to indicate Wi-Fi time synchronization characteristics.

[0202] It should be noted that the various parameters (or characteristics) included in the WMCI characteristic parameter set listed above are merely examples. In practical applications, other parameters (or characteristics) may also be included. Furthermore, the order of the parameters (or characteristics) in the WMCI characteristic parameter set listed above is also merely an example. In practical applications, the parameters (or characteristics) in the WMCI characteristic parameter set may be arranged in other orders. This embodiment does not limit the order of different parameters (or characteristics) in the WMCI characteristic parameter set.

[0203] Specifically, the aforementioned second, fourth, and fifth instruction information can be implemented in the following ways:

[0204] Optionally, the second indication information is carried in the message type identifier field of the third message. For example, the lower n bits of the message type identifier field are used to carry the second indication information, where n is an integer greater than 2. For example, n = 5, meaning the first to fifth bits of the first byte of the third message carry the second indication information. Another example is n = 6, meaning the first to sixth bits of the first byte of the third message carry the second indication information. The following description uses the first to fifth bits as an example for the second indication information. Please refer to the example shown in Table 5-1 below for details.

[0205] Optionally, the third message includes a message content field, a fourth indication information located in the first two bytes of the message content field, and a fifth indication information located in the remaining bytes of the message content field. The first two bytes of the message content field are a parameter mask field, and the fourth indication information is one bit of the parameter mask field. For example, the parameter mask field is used to indicate which parameter in the parameter set indicated by the second indication information has the first characteristic. Please refer to the example shown in Table 5-1 below for details.

[0206] Optionally, the fifth indication information includes a first value and a second value, wherein the first value indicates that the first feature is enabled, and the second value indicates that the first feature is disabled. In one implementation, the fifth indication information can be represented by a newly defined bit in the WMCI message, that is, the first value and the second value are two values ​​of the newly defined bit. The two values ​​of this bit indicate whether the first feature is enabled or disabled, respectively. For example, a value of 1 indicates that the first feature is enabled, and a value of 0 indicates that the first feature is disabled. Please refer to the example shown in Table 5-2 below for details. In another implementation, the fifth indication information can be represented by m newly defined bits in the WMCI message, that is, the first value and the second value are two values ​​of the newly defined m bits, where m is an integer greater than 1. For example, m bits can represent 0 to 2. m The first indicator can take two values: 0 and 1, which indicate whether the first feature is enabled or disabled, respectively. The remaining values ​​are reserved. For example, the fifth indicator information can be represented by one byte (8 bits), where a value of 0 indicates that the first feature is disabled, a value of 1 indicates that the first feature is enabled, and the remaining values ​​(i.e., 2 to 255) are reserved. Please refer to the example shown in Table 5-3 below for details.

[0207] For example, Table 5-1 below is an example of a third message in this embodiment.

[0208] Table 5-1

[0209] As shown in Table 5-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 indication information is carried in the message type identifier field of the third message, used to indicate the parameter set, that is, the parameter set to which the parameters of the first characteristic belong, i.e., which parameter set's parameters determine the first characteristic. In the example shown in Table 5-1, bits 1 to 5 are used to represent the second indication information, i.e., the bits "ZZZZZ". 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. Bytes 3 and 4 are the message length and processing requirement fields. If the third message also includes the first indication information and processing requirement indication information described above, then the message length and processing requirement fields consist of three fields: message priority, operation type, and message content length. For an explanation of this field, please refer to the relevant descriptions in the examples shown in Tables 1-1, 1-2, or 1-3 above; they will not be repeated here. Furthermore, bytes 5 through N are the message content field, used to carry the specific content of the message and are 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 indicated by the second indication information. Since the parameter mask field is 16 bits (i.e., 2 bytes), a parameter set can contain a maximum of 16 parameters, and each message type of parameter set can carry a maximum of 16 parameters. The parameter set indicated by the second indication information contains less than or equal to 16 parameters. The fourth indication information is one bit of the parameter mask field. For example, the fourth indication information is bits S1 through S2. 16One of the bits in the parameter mask is byte S1, and the value of this bit is 1. For example, if the first characteristic is the characteristic of the parameter indicated by bit S1, then the value of bit S1 is 1. In addition, bytes 7 to N are used to carry the parameter content of the parameter indicated by the parameter mask. The parameter content should be filled into the message content in the order indicated by the parameter mask. Here, N is an integer greater than 7. The fifth indication information is located in the parameter content field, and the bytes occupied by the fifth indication information correspond to the bits of the fourth indication information. For the specific correspondence, please refer to the example shown in Table 5-2 below. In addition, bytes (N+1) to (N+4) are the message integrity check field, which is 4 bytes in size and is used to verify the sender's identity and prevent forged WMCI message attacks. This field follows the cyclic redundancy check (CRC) function.

[0210] For ease of understanding, the third message will be described using the parameter set indicated by the second instruction information as the WMCI characteristic parameter set, and the parameters and their order contained in the WMCI characteristic parameter set as shown in Table 2-3 above.

[0211] For example, Table 5-2 below shows an example of a third message when the fifth indication information is implemented using one bit of the parameter content field.

[0212] Table 5-2

[0213] In the example shown in Table 5-2, the second indication information is located in the first to fifth bits of the message type identifier field, indicating the WMCI feature parameter set. In the example of the WMCI feature parameter set shown in Table 2-3, this WMCI feature parameter set contains 7 parameters, corresponding to 7 features. The 7 parameters (or features) are represented by the first 7 bits of the parameter mask field in the message content field, and the first 7 bits of the parameter mask field are mapped according to the parameter order shown in Table 2-3. That is, bit S1 of the 5th byte represents time-domain scheduling, bit S2 of the 5th byte represents energy saving, bit S3 of the 5th byte represents cooperative EDCA, bit S4 of the 5th byte represents roaming, bit S5 of the 5th byte represents spatial multiplexing, bit S6 of the 5th byte represents frequency-domain scheduling, bit S7 of the 5th byte represents Wi-Fi time synchronization, and the remaining bits are reserved. If the parameter content of each parameter occupies one byte, then the first 7 bytes of the parameter content field are mapped according to the parameter order shown in Table 2-3. In other words, byte 7 contains the time-domain scheduling parameter content, byte 8 contains the energy-saving parameter content, byte 9 contains the cooperative EDCA parameter content, byte 10 contains the roaming parameter content, byte 11 contains the spatial multiplexing parameter content, byte 12 contains the frequency-domain scheduling parameter content, byte 13 contains the Wi-Fi time synchronization parameter content, and the remaining bytes are reserved. In this example, the parameter content includes a fifth indication information, used to indicate whether the feature indicated by the parameter is enabled. If the value of the highest bit of the parameter content field is used to represent whether the corresponding feature is enabled, then F... i =1 indicates that the feature of bit Si is enabled, F i=0 indicates that the feature of bit Si is not enabled, where i = 1, 2, 3, 4, 5, 6 or 7. For example, in byte 7, bit F1 = 1 enables time-domain scheduling, and bit F1 = 0 disables time-domain scheduling; in byte 8, bit F2 = 1 enables energy-saving features, and bit F2 = 0 disables energy-saving features; in byte 9, bit F3 = 1 enables cooperative EDCA features, and bit F3 = 0 disables cooperative EDCA features; in byte 10, bit F4 = 1 enables roaming features, and bit F4 = 0 disables roaming features; in byte 11, bit F5 = 1 enables spatial multiplexing features, and bit F5 = 0 disables spatial multiplexing features; in byte 12, bit F6 = 1 enables frequency-domain scheduling features, and bit F6 = 0 disables frequency-domain scheduling features; in byte 13, bit F7 = 1 enables Wi-Fi time synchronization features, and bit F7 = 0 disables Wi-Fi time synchronization features. For example, if the first characteristic indicated by the fourth indication information is the energy-saving characteristic, and the fifth indication information indicates that the energy-saving characteristic is enabled, then in the example shown in Table 5-2, bit S2 of the 5th byte is 1, and the highest bit F2 of the 8th byte is 1. If the first characteristic indicated by the fourth indication information is the cooperative EDCA characteristic, and the fifth indication information indicates that the cooperative EDCA characteristic is not enabled, then in the example shown in Table 5-2, bit S3 of the 5th byte is 1, and the highest bit F3 of the 9th byte is 0.

[0214] For example, Table 5-3 below is an example of a third message when the fifth indication information is implemented using one byte in the parameter content field.

[0215] Table 5-3

[0216] The example shown in Table 5-3 differs from the example shown in Table 5-2 only in the parameter content field; all other fields are the same. For explanations of the remaining fields, please refer to the corresponding descriptions in Table 5-2 above; they will not be repeated here. The difference between the example shown in Table 5-3 and the example shown in Table 5-2 is that the example in Table 5-3 uses a single byte with values ​​of 0 and 1 to represent enabling and disabling the corresponding feature, respectively. The value of this byte is reserved from 2 to 255. For example, in byte 7, byte F1=1 enables time-domain scheduling, and byte F1=0 disables time-domain scheduling; in byte 8, byte F2=1 enables energy-saving features, and byte F2=0 disables energy-saving features; in byte 9, byte F3=1 enables cooperative EDCA features, and byte F3=0 disables cooperative EDCA features; in byte 10, byte F4=1 enables roaming features, and byte F4=0 disables roaming features; in byte 11, byte F5=1 enables spatial multiplexing features, and byte F5=0 disables spatial multiplexing features; in byte 12, byte F6=1 enables frequency-domain scheduling features, and byte F6=0 disables frequency-domain scheduling features; in byte 13, byte F7=1 enables Wi-Fi time synchronization features, and byte F7=0 disables Wi-Fi time synchronization features. For example, if the first characteristic indicated by the fourth indication information is the energy-saving characteristic, and the fifth indication information indicates that the energy-saving characteristic is enabled, then in the example shown in Table 5-2, bit S2 of the 5th byte is 1, and the value of the 8th byte is 1. If the first characteristic indicated by the fourth indication information is the cooperative EDCA characteristic, and the fifth indication information indicates that the cooperative EDCA characteristic is not enabled, then in the example shown in Table 5-2, bit S3 of the 5th byte is 1, and the value of the 9th byte is 0.

[0217] It should be noted that the third message may include multiple fourth and fifth indication messages, with each fourth and fifth indication message corresponding one-to-one. This can be understood as the master device simultaneously indicating whether multiple features are enabled or disabled via the third message. For example, as shown in Table 5-2, if bits S2 and S3 of the parameter mask field in the third message are both 1, the value of byte 8 is 1, and the value of byte 9 is 0, it indicates that the energy-saving feature is enabled, and the collaborative EDCA feature is disabled. As another example, as shown in Table 5-2, if bits S2 and S4 of the parameter mask field in the third message are both 1, the value of byte 8 is 1, and the value of byte 10 is 1, it indicates that the energy-saving feature is enabled, and the roaming feature is enabled. As yet another example, as shown in Table 5-2, if bits S2 and S3 of the parameter mask field in the third message are both 1, the value of byte 8 is 0, and the value of byte 9 is 0, it indicates that the energy-saving feature is disabled, and the collaborative EDCA feature is disabled.

[0218] Step 402: The first slave device configures the first feature based on the third message.

[0219] For example, after receiving the third message, the first slave device can enable or disable the first feature according to the instructions of the fourth and fifth instructions in the received third message. For instance, if the first feature of the first slave device was disabled before receiving the third message, and the third message indicates that the first feature should be enabled, then the first slave device enables the first feature based on the instruction of the third message. Alternatively, if the first feature of the first slave device was enabled before receiving the third message, and the third message indicates that the first feature should be disabled, then the first slave device disables the first feature based on the instruction of the third message; this can also be understood as disabling the first feature based on the instruction of the third message.

[0220] After the first slave device performs an operation on the first feature based on the third message (e.g., enabling or disabling the first feature), the first slave device will also execute step 403.

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

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

[0223] The fourth message is a WMCI message, which is used to manage or control the wireless local area network (WLAN) function of the first slave device. The fourth message includes a fourth indication message and a sixth indication message. The fourth indication message is used to indicate the first feature, and the sixth indication message is used to indicate whether to enable the first feature of the first slave device.

[0224] For an explanation of the fourth instruction information and the first characteristic, please refer to the relevant introduction in step 401 above, which will not be repeated here.

[0225] Optionally, the fourth message may also include second indication information, which is located in the message type identifier field of the fourth message. For an explanation of the second indication information, please refer to the relevant description in step 401 above; it will not be repeated here.

[0226] Optionally, the fourth message includes a message content field, with the fourth indication information located in the first two bytes of the message content field, and the sixth indication information located within the message content field. The sixth indication information includes a first value and a second value. The first value indicates that the first feature is enabled, and the second value indicates that the first feature is disabled. The sixth indication information in this step is similar to the fifth indication information described earlier. The function of the sixth indication information and its position in the message can be found in the description of the fifth indication information above, and will not be repeated here.

[0227] In one possible implementation, if the first slave device enables the first feature according to the fourth and fifth indications in the received third message, then the fourth and sixth indications in the fourth message sent by the first slave device also indicate that the first feature is enabled. If the first slave device does not enable the first feature according to the fourth and fifth indications in the received third message, then the fourth and sixth indications in the fourth message sent by the first slave device also indicate that the first feature is not enabled. In this case, the value of the sixth indication is the same as the value of the fifth indication. It can be understood that the configuration result of the first feature reported by the first slave device through the fourth message is that the configuration has been successfully implemented.

[0228] In another possible implementation, the first slave device may also choose not to enable or disable the first feature according to the instructions of the fourth and fifth indications in the received third message. For example, the fourth and fifth indications in the third message received by the first slave device indicate that the energy-saving feature should be enabled; however, the first slave device may have service transmissions that are not suitable for energy saving, so the first slave device does not enable the energy-saving feature according to the instructions of the third message. In this case, the value of the sixth indication is different from the value of the fifth indication. It can be understood that the configuration result of the first feature reported by the first slave device through the fourth message is a failure to take effect.

[0229] For example, the master device sends a third message to the first slave device (as shown in Table 6-1 below). This third message includes second indication information indicating the WMCI feature parameter set, two fourth indication information indicating power saving features (i.e., the 7th bit from low to high in the 5th byte) and Wi-Fi time synchronization features (i.e., the 2nd bit from low to high in the 5th byte), and two fifth indication information indicating that power saving features are enabled (i.e., the value of the 8th byte is 1) and Wi-Fi time synchronization features are enabled (i.e., the value of the 13th byte is 1). The first slave device attempts to enable power saving features and Wi-Fi time synchronization features according to the instructions of the third message. If the first slave device successfully enables the Wi-Fi time synchronization feature but fails to enable the power saving feature, it sends a fourth message to the master device (as shown in Table 6-2). This fourth message includes a second indication information indicating the WMCI feature parameter set. This fourth message includes two fourth indication information entries, indicating the power saving feature (i.e., the 7th bit from low to high in the 5th byte) and the Wi-Fi time synchronization feature (i.e., the 2nd bit from low to high in the 5th byte). This fourth message also includes two sixth indication information entries, namely the value of the 8th byte and the 13th byte of the parameter content field. A value of 1 for the 8th byte indicates that the power saving feature was not successfully enabled; a value of 1 for the 13th byte indicates that the Wi-Fi time synchronization feature was successfully enabled.

[0230] Table 6-1

[0231] Table 6-2

[0232] In this embodiment, the first slave device is instructed to enable or disable its first characteristic by the fourth and fifth indication information in the third message. This allows the master device to flexibly configure the first characteristic of the first slave device, thereby improving the efficiency of the master device in managing the first slave device.

[0233] 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, third message, fourth 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 the 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. Port ID1 and Port ID2 may correspond to the same physical transceiver port or different physical transceiver ports.

[0234] Furthermore, as shown in Figure 5A, if the master device's rate class 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.

[0235] Furthermore, as shown in Figure 5B, 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 recipient of the WMCI message (i.e., the first message), meaning it 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.

[0236] Furthermore, as shown in Figure 5C, FEM frames are encapsulated in the payload field of data link layer (DLL) frames. As shown in Figure 5D, 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 (i.e., PLOAMd, BIP, Plend) and one variable-size partition: a bandwidth mapping partition (BWmap). A bandwidth mapping (BWmap) is used to indicate the uplink transmission position in the corresponding uplink physical frame (PHY frame) for different slave devices.

[0237] It should be noted that in the example shown in Figure 5C, only the payload of the DLL frame containing 3 FEM frames is taken as an example. In actual applications, the payload of the DLL frame can contain other numbers of FEM frames, which is not limited here. In the example shown in Figure 5D, only the payload of the DLL frame containing 3 XFEM frames is taken as an example. In actual applications, the payload of the DLL frame can contain other numbers of XFEM frames, which is not limited here.

[0238] Furthermore, this application embodiment also provides a communication device 60, as shown in FIG6, which is a structural schematic diagram of a communication device 60 provided in this application embodiment. The specific implementation of the master device and slave device (e.g., the first slave device) in the flowcharts shown in FIG2, FIG3, or FIG4 can be referred to the internal structure of the communication device 60 shown in FIG6. When the communication device 60 is used to implement the function of the master device in the method shown in FIG2, FIG3, or FIG4, the communication device 60 can be a master gateway or an MFU. When the communication device 60 is used to implement the function of the slave device in the method shown in FIG2, FIG3, or FIG4, the communication device 60 can be a slave gateway or an SFU.

[0239] As shown in Figure 6, the communication device 60 may include a processor 601 and a transceiver 602, with the processor 601 and transceiver 602 coupled together. 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.

[0240] 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.

[0241] 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 that executes 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.

[0242] In one implementation, the communication device 60 is used to implement the functions of the master device in the method embodiment corresponding to FIG2. Specifically, the processor 601 is used to generate a first message; the transceiver 602 is used to send the first message to the first slave device. The first message is a Wireless Local Area Network Management and Control Interface (WMCI) message, used to manage or control the WLAN function of the first slave device. The first message includes first indication information, which indicates the operation type of the first message.

[0243] In one possible implementation, the operation type of the first message includes any one of the following: a parameter request type, used to instruct the master device to request the first slave device to send the parameters of the first slave device to the master device; or a parameter configuration type, used to instruct the master device to send the configuration parameters of the first slave device to the first slave device.

[0244] In one possible implementation, the first indication information includes a first value or a second value, wherein the first value is used to indicate that the operation type is a parameter request type, and the second value is used to indicate that the operation type is a parameter configuration type.

[0245] In one possible implementation, the first indication information is located in the message length and processing requirement field of the first message; or, the first indication information is located in the message type identifier field of the first message. For example, the first indication information is located in the 7th bit of the first byte of the message length and processing requirement field.

[0246] In one possible implementation, the first message further includes second indication information, which indicates the parameter set corresponding to the first message. Optionally, the second indication information is located in the message type identifier field of the first message.

[0247] In one possible implementation, the parameter request type is further used to indicate the parameters of the parameter set indicated by the message type identifier field of the request first slave device; the parameter configuration type is further used to indicate the configuration parameters of the parameter set indicated by the message type identifier field of the master device to the first slave device.

[0248] In one possible implementation, the message content field of the first message further includes a parameter mask field, which is used to indicate the parameters in the parameter set corresponding to the first message.

[0249] In one possible implementation, the parameter mask field is the first two bytes of the message content field, and the remaining bytes of the message content field are used to carry the content of the parameters.

[0250] In one possible implementation, the parameter set includes any one of the following:

[0251] The parameters can be: device capability parameter set from the device WLAN; or, device operating parameter configuration parameter set from the device WLAN; or, WMCI characteristic parameter set; or, interference matrix parameter set; or, timer configuration parameter set.

[0252] In one possible implementation, the first message is encapsulated in the payload field of a Fiber to the Room (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. Optionally, the FEM frame is encapsulated in the payload field of a Data Link Layer (DLL) frame.

[0253] In another implementation, the communication device 60 is used to implement the function of the slave device (e.g., the first slave device) in the method embodiment corresponding to FIG2. Specifically, the transceiver 602 is used to receive a first message from the master device. The first message is a Wireless LAN Management and Control Interface (WMCI) message. The first message is used to manage or control the WLAN function of the first slave device. The first message includes first indication information, which indicates the operation type of the first message.

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

[0255] In one implementation, the communication device 60 is used to implement the functions of the master device in the method embodiment corresponding to FIG3. Specifically, the processor 601 is used to generate a second message; the transceiver 602 is used to send the second message to the master device. The second message is a Wireless LAN Management and Control Interface (WMCI) message, which requests management or control of the WLAN function of the first slave device. The second message includes third indication information, which indicates the operation type of the second message.

[0256] In one possible implementation, the operation type of the second message includes any of the following:

[0257] The scheduling request type is used to request the master device to send scheduling configuration information to the first slave device; or, the parameter reporting type or alarm type is used for the first slave device to send the parameters of the first slave device or the alarm information of the first slave device to the master device.

[0258] In one possible implementation, the third indication information includes a first value or a second value, wherein the first value is used to indicate that the operation type is a scheduling request type, and the second value is used to indicate that the operation type is a parameter reporting type or an alarm type.

[0259] In one possible implementation, the third indication information is located in the message length and processing requirement field of the second message; or, the third indication information is located in the message type identifier field of the second message. For example, the third indication information is located in the 7th bit of the first byte of the message length and processing requirement field.

[0260] In one possible implementation, the second message further includes second indication information, which indicates the parameter set corresponding to the second message. Optionally, the second indication information is located in the message type identifier field of the second message.

[0261] In one possible implementation, the scheduling request type is further used to indicate the scheduling configuration information of the parameter set indicated by the message type identifier field sent by the master device to the first slave device; or, the parameter reporting type or alarm type is further used to indicate the parameter or alarm type of the parameter set indicated by the message type identifier field sent by the first slave device to the master device.

[0262] In one possible implementation, the message content field of the second message further includes a parameter mask field, which is used to indicate the parameters in the parameter set corresponding to the second message.

[0263] In another implementation, the communication device 60 is used to implement the function of the slave device (e.g., the first slave device) in the method embodiment corresponding to FIG3. Specifically, the transceiver 602 is used to receive a second message from the first slave device. The second message is a Wireless LAN Management and Control Interface (WMCI) message. The second message is used to request management or control of the wireless LAN (WLAN) function of the first slave device. The second message includes third indication information, which indicates the operation type of the second message.

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

[0265] In one implementation, the communication device 60 is used to implement the functions of the master device in the method embodiment corresponding to FIG4. Specifically, the processor 601 is used to generate a third message; the transceiver 602 is used to send the third message to the first slave device. The third message is a Wireless Local Area Network Management and Control Interface (WMCI) message, used to manage or control the WLAN function of the first slave device. The third message includes fourth and fifth indication information; the fourth indication information indicates a first feature, and the fifth indication information indicates whether the first feature of the first slave device is enabled.

[0266] In one possible implementation, transceiver 602 is further configured to receive a fourth message from the first slave device. The fourth message is a Wireless LAN Management and Control Interface (WMCI) message. The fourth message is used to manage or control the WLAN function of the first slave device. The fourth message includes a fourth indication information and a sixth indication information. The fourth indication information is used to indicate a first feature, and the sixth indication information is used to indicate whether the first feature of the first slave device is enabled.

[0267] In another implementation, the communication device 60 is used to implement the function of the slave device (e.g., the first slave device) in the method embodiment corresponding to FIG4. Specifically, the transceiver 602 is used to receive a third message from the master device. The third message is a Wireless LAN Management and Control Interface (WMCI) message. The third message is used to manage or control the WLAN function of the first slave device. The third message includes a fourth indication information and a fifth indication information. The fourth indication information is used to indicate a first feature, and the fifth indication information is used to indicate whether the first feature of the first slave device is enabled.

[0268] In one possible implementation, processor 601 is used to generate a fourth message, and transceiver 602 is also used to send the fourth message to the master device. The fourth message is a Wireless LAN Management and Control Interface (WMCI) message. The fourth message is used to manage or control the WLAN function of the first slave device. The fourth message includes a fourth indication information and a sixth indication information. The fourth indication information is used to indicate a first feature, and the sixth indication information is used to indicate whether the first feature of the first slave device is enabled.

[0269] Please refer to the relevant descriptions in the embodiments corresponding to Figures 2, 3, or 4 above; they will not be repeated here.

[0270] As shown in Figure 7, 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.

[0271] 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.

[0272] In one possible design, one or more modules as shown in Figure 7 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 specific implementation of these modules. The processors, memory, and transceivers can be implemented individually or integrated into a single unit.

[0273] The communication device 70 is equipped to implement the functions of the slave device (e.g., the first slave 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 slave device (e.g., the first slave device) described in the embodiments of this application. 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. Specifically, please refer to the communication device 60 in the embodiment corresponding to Figure 6 above.

[0274] 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. Specifically, please refer to the communication device 60 in the embodiment corresponding to Figure 6 above.

[0275] 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, methods related to a slave device (e.g., a first slave device) as shown in Figures 2, 3, or 4 are implemented. Another example is methods related to a master device as shown in Figures 2, 3, or 4. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may 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 may 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 media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0276] In addition, this application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the methods associated with a slave device (e.g., a first slave device) as shown in Figures 2, 3, or 4 above.

[0277] In addition, this application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the main device-related methods as shown in FIG2, FIG3 or FIG4 above.

[0278] 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.

[0279] 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, the optical 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 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 also includes a message type identifier field, which is used to indicate the type of message and define the semantics of the message content.

2. An optical network communication method, wherein the optical network includes a master device and at least one slave device, the at least one slave device including a first slave device, characterized in that, include: The master device receives a first message sent by the first slave device. The first message is a Wireless LAN Management and Control Interface (WMCI) message. The first message also includes a message type identifier field, which is used to indicate the type of message and define the semantics of the message content.

3. The method according to claim 1, characterized in that, The message type identifier field indicates that the first message is a set of working parameters. Before the first slave device sends the first message to the master device, the method further includes: The slave device receives a second message from the master device and performs configuration based on the second message.

4. The method according to claim 2, characterized in that, The message type identifier field indicates that the first message is a set of working parameters. Before the master device receives the first message sent by the first slave device, the method further includes: The master device sends a second message to the first slave device, wherein the second message is used to configure the first slave device.

5. The method according to any one of claims 1-4, characterized in that, The message type identifier field indicates that the first message is a set of working parameters, and the set of working parameters includes a channel width field.

6. The method according to any one of claims 1-5, characterized in that, The message type identifier field indicates that the first message is a set of working parameters, and the set of working parameters includes a transmit power level field, wherein the transmit power level field is used to indicate that the transmit power level is any one of 20%, 40%, 60%, 80%, and 100%.

7. The method according to claim 1, characterized in that, The message type identifier field indicates that the first message is a set of capability parameters. Before the first slave device sends the first message to the master device, the method further includes: The first slave device receives a second message sent by the master device, wherein the second message is used to request the first slave device to send the capability parameters of the first slave device to the master device.

8. The method according to claim 2, characterized in that, The message type identifier field indicates that the first message is a set of capability parameters. Before the master device receives the first message sent by the first slave device, the method further includes: The master device sends a second message to the first slave device, wherein the second message is used to request the first slave device to send the capability parameters of the first slave device to the master device.

9. The method according to any one of claims 1-2, 7-8, characterized in that, The message type identifier field indicates that the first message is a capability parameter set, which includes a WMCI feature field. The WMCI feature field is used to indicate whether time-domain scheduling is supported and whether energy saving is supported.

10. The method according to any one of claims 1-2, 7-9, characterized in that, The message type identifier field indicates that the first message is a capability parameter set, and the capability parameter set includes a transmit power field, which indicates whether at least one of the following transmit powers is supported: Transmission power of 0-20%, 20%-40%, 40%-60%, 60%-80%, and 80%-100%.

11. The method according to any one of claims 1-2, 7-10, characterized in that, The message type identifier field indicates that the first message is a capability parameter set, and the capability parameter set includes an 802.11 version number field, which is used to indicate the 802.11 version supported by the slave device.

12. The method according to any one of claims 1-2, 7-11, characterized in that, The message type identifier field indicates that the first message is a capability parameter set, and the capability parameter set includes a WMCI version number field, which is used to indicate the version of WMCI.

13. The method according to any one of claims 1-2, 7-12, characterized in that, The message type identifier field indicates that the first message is a capability parameter set, and the capability parameter set includes a channel width field to indicate whether at least one of the following channel widths is supported: 20MHz channel width, 40MHz channel width, 80MHz channel width, 160MHz channel width, and two non-consecutive 80MHz channel widths.

14. The method according to any one of claims 1-13, characterized in that, The first message also includes a message content field, which includes a parameter mask that indicates the parameters in the parameter set corresponding to the first message.

15. The method according to claim 14, characterized in that, The first two bytes of the message content field are the parameter mask field.

16. The method according to any one of claims 1-15, characterized in that, The first message is encapsulated in an FEM frame, and the FEM port identifier of the FEM frame is used to indicate that the first message corresponds to the first slave device.

17. The method according to any one of claims 1-16, characterized in that, The master device is an MFU, and the slave device is an SFU.

18. The method according to any one of claims 1-17, characterized in that, The optical network is an optical fiber network, and the master device is connected to the at least one slave device via optical fiber.

19. A communication device, characterized in that, include: A processor and a transceiver, the processor being connected to the transceiver, the processor being configured to implement the method as described in any one of claims 1-18.

20. A communication device, characterized in that, Used to implement the method as described in any one of claims 1-18.

21. A chip, characterized in that, Used to implement the method as described in any one of claims 1-18.

Images