Reference signaling configuration method and system

Abstract

Provided in the embodiments of the present disclosure are a reference signaling configuration method and system, which are applied to a main fiber-to-the-room (FTTR) unit (MFU). The method comprises: sending reference signaling to a first sub-FTTR unit (SFU), wherein the reference signaling carries a mobile basic service set (MBSS) field, and the first SFU is associated with a station (STA); or, sending reference signaling to a second SFU, wherein the reference signaling carries a block acknowledgement (BA) information field or each link information field of a multi-link operation (MLO), and the second SFU is not associated with the STA. By means of the present disclosure, the problem in the related art of a roaming scheme for all-optical-network networking amounting to STA re-association and thus causing considerable latency and service delays is solved.

Description

Reference signaling configuration methods and systems

[0001] Cross-reference to related applications

[0002] This disclosure is based on and claims priority to Chinese patent application CN202510205359.0, filed on February 24, 2025, entitled “Configuration Method and System for Reference Signaling”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of communications, and more specifically, to a method and system for configuring reference signaling. Background Technology

[0004] The primary roaming method in current Fiber to the Room (FTTR) networks is based on the 802.11kV protocol. 802.11k is mainly used to help wireless terminals understand their surrounding wireless environment. When the main gateway determines that a wireless terminal needs to roam, for terminals supporting 802.11k capability, it can use 802.11k to request the wireless terminal to measure the signal quality of each sub-gateway, thus assisting the main gateway in better selecting roaming candidates. 802.11V is used to guide wireless terminals during roaming, including frequency band guidance between single devices (2.4GHz and 5GHz) and guidance between multiple devices. After obtaining the signal strength of the wireless terminal through 802.11k, it is then guided to a suitable sub-gateway via 802.11V. In this roaming scheme, each roaming is equivalent to re-association, resulting in significant latency and service delays. Summary of the Invention

[0005] This disclosure provides a method and system for configuring reference signaling to at least address the issue in related technologies where all-optical network networking and roaming schemes, which are equivalent to re-associating stations (STAs), result in significant latency and service delays.

[0006] According to one embodiment of this disclosure, a method for configuring reference signaling is provided, applied to a Main FTTR Unit (MFU), comprising: sending reference signaling to a first Sub FTTR Unit (SFU), wherein the reference signaling carries a Mobile Basic Service Set (MBSS) field, and the first SFU is associated with a Station (STA); or, sending reference signaling to a second SFU, wherein the reference signaling carries a Block Acknowledgment (BA) information field or a Multi-Link Operation (MLO) link information field, and the second SFU is not associated with a STA.

[0007] According to another embodiment of this disclosure, a reference signaling configuration system is provided, including a main fiber-to-remote node (MFU), a first fiber-to-remote node (FTTR) device (SFU), a second SFU, and a site (STA). The MFU is configured to send reference signaling to the first SFU, wherein the reference signaling carries a Mobile Basic Service Set (MBSS) field, and the first SFU is associated with the site STA; or, to send reference signaling to the second SFU, wherein the reference signaling carries a Block Acknowledgment (BA) information field or a Multi-Link Operation (MLO) link information field, and the second SFU is not associated with the STA. The first SFU is configured to receive the reference signaling and instruct the STA to switch between the Basic Service Set (BSS) and the MBSS according to the reference signaling. The second SFU is configured to receive the reference signaling and perform BA information synchronization, or BA information synchronization and TID-to-link mapping of MLO links according to the reference signaling. The STA is configured to switch between the BSS and MBSS of the first SFU, or switch the MBSS between the first SFU and the second SFU.

[0008] According to yet another embodiment of this disclosure, a computer-readable storage medium is also provided, in which a computer program is stored, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0009] According to yet another embodiment of this disclosure, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0010] According to yet another embodiment of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments. Attached Figure Description

[0011] Figure 1 is a communication network architecture diagram for fast roaming according to an embodiment of the present disclosure;

[0012] Figure 2 is a flowchart of a method for configuring reference signaling according to an embodiment of the present disclosure;

[0013] Figure 3 is a schematic diagram of an 802.11V message format according to an embodiment of the present disclosure;

[0014] Figure 4 shows an intentional representation of the neighbor report element field format according to an embodiment of this disclosure;

[0015] Figure 5 shows a schematic diagram of the BSSID information field format according to an embodiment of the present disclosure;

[0016] Figure 6 is a structural block diagram of a configuration system for reference signaling according to an embodiment of the present disclosure;

[0017] Figure 7 is a schematic diagram of a roaming scene where a STA switches from a BSS to an MBSS according to an embodiment of the present disclosure;

[0018] Figure 8 is a schematic diagram of STA switching back to BSS without roaming after a predetermined time according to an embodiment of the present disclosure;

[0019] Figure 9 is a schematic diagram of MBSS switching BA information synchronization according to an embodiment of the present disclosure;

[0020] Figure 10 is a schematic diagram of MLO STA roaming according to an embodiment of the present disclosure. Detailed Implementation

[0021] The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings and examples.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0023] FTTR all-optical networking is an advanced network architecture designed to provide a high-performance, high-reliability, and high-security network solution by directly connecting to each room or end-user equipment via optical fiber, suitable for various high-bandwidth application scenarios. Figure 1 is a communication network architecture diagram for fast roaming according to an embodiment of this disclosure, as shown in Figure 1.

[0024] A management channel for control information can exist between the Main FTTR Unit (MFU) and the Sub FTTR Unit (SFU). Both the MFU and SFU have control message transceiver units for real-time information collection, reporting, and decision dissemination between devices. The MFU has an MFU Controller Entity (MCE) (also known as an MFU control management module) for collecting real-time status information from each SFU, making decisions, and initiating synchronized decisions with each SFU. The SFU has an SFU Controller Entity (SCE) (also known as an SFU control management module) for converting and adapting wireless module (such as WLAN) data and configuring decision information.

[0025] Ethernet (Ethernet interface) is a wired network connection, typically used to connect FTTR devices (MFU, SFU) to other network devices or the Internet. A Wi-Fi AP (Access Point) provides Wi-Fi network access to a STA (Wireless Terminal). A Wi-Fi STA represents a terminal device connected to a Wi-Fi network, such as a personal computer, smartphone, or tablet. The application is the software running on the STA; it can be any software that requires a network connection, such as a web browser, email client, or video conferencing software.

[0026] The WLAN Management and Control Interface (WMCI) is an interface technology used for managing and controlling Wireless Local Area Networks (WLANs). It provides a standardized mechanism that enables efficient communication and operation between network devices and management systems, facilitating orderly coordination of the WLAN air interface within an FTTR network, seamless roaming handover, and maximizing air interface performance.

[0027] This embodiment provides a method for configuring reference signaling operating on the above-described network architecture. Figure 2 is a flowchart of the method for configuring reference signaling according to an embodiment of this disclosure. This method can be applied to the laying of the main optical fiber to the remote node device MFU. As shown in Figure 2, the process includes the following steps:

[0028] Step S202: Send a reference signaling message to the first FTTR device (SFU) that is laid from the optical fiber to the remote node. The reference signaling message carries the Mobile Basic Service Set (MBSS) field and the first SFU is associated with the site (STA).

[0029] For example, an MFU can control the STA to switch between BSS and MBSS by sending a reference signaling carrying the MBSS field to the first SFU associated with the STA (also known as the Client).

[0030] In one exemplary embodiment, step S202 includes:

[0031] In response to the detection that the STA has moved to a predetermined range, it is determined that the STA is about to roam, wherein the STA is associated with the basic service set (BSS) of the first SFU;

[0032] Send an MBSS creation request message to the first SFU so that the first SFU can create an MBSS based on the MBSS creation request message;

[0033] Receive the MBSS creation success response message returned by the first SFU based on the MBSS creation request message;

[0034] A reference signaling message is sent to the first SFU so that the first SFU can instruct the STA to switch to MBSS according to the reference signaling message. The reference signaling message is a client boot request message carrying the MBSS field, which is used to indicate that the STA's roaming destination BSS is MBSS.

[0035] It should be noted that an MBSS enable request message can also be used, so that the first SFU can create an MBSS based on the MBSS enable request message. That is, in all embodiments of this disclosure, it is not limited to creating an MBSS, but can also be enabling an MBSS.

[0036] For example, a STA is associated with the BSS of the first SFU. The STA may move. When the MFU detects that the STA has moved to a predetermined range, the MFU can determine that the STA is about to roam. The MFU needs to send an MBSS creation request message to the first SFU, instructing the first SFU to create the MBSS. After the first SFU successfully creates the MBSS, it will report an MBSS creation success response message to the MFU. The MFU then redirects the STA, which is already associated with the BSS of the first SFU, to the MBSS of the first SFU. The reference signaling sent by the MFU to the first SFU carries the MBSS field, marking the STA's roaming destination BSS as the MBSS.

[0037] In one exemplary embodiment, step S202 includes:

[0038] In response to the detection that the STA has been in a non-roaming state for more than a predetermined period of time, it is determined that the STA needs to switch back to the BSS, wherein the STA is associated with the MBSS of the first SFU;

[0039] A reference signaling message is sent to the first SFU so that the first SFU can instruct the STA to switch to the BSS according to the reference signaling message. The reference signaling message is a client boot request message carrying the MBSS field. The MBSS field is used to indicate that the STA's roaming destination BSS is the BSS.

[0040] For example, a STA is associated with the MBSS of the first SFU. The STA may operate normally after being associated with the MBSS of the first SFU. When the MFU detects that the STA has been in a non-roaming state for a predetermined period of time, in order to release the MBSS resources in a timely manner, it determines that the STA needs to switch back to the BSS. The MFU needs to send a reference signaling to the first SFU. This reference signaling carries the MBSS field, marking the STA's roaming destination BSS as the BSS.

[0041] In one exemplary embodiment, after step S202, the method includes: receiving a response message returned by the first SFU based on reference signaling.

[0042] In an exemplary embodiment, in response to the MBSS field indicating that the roaming destination BSS of the STA is MBSS, receiving a response message returned by the first SFU based on reference signaling includes:

[0043] Receive the client boot response message returned by the first SFU based on the Basic Service Set Transition Management (BTM) response message. The BTM response message is returned by the STA to the first SFU based on the BTM request message sent by the first SFU. The BTM request message is sent by the first SFU to the STA based on the client boot request message. The BTM request message carries the MBSS field.

[0044] For example, after the MFU sends a reference signaling message to the first SFU, the first SFU sends a BTM request message to the STA based on the reference signaling message. This BTM request message carries an MBSS field, which also marks the STA's roaming destination BSS as MBSS. The STA can return a BTM response message to the first SFU based on the BTM request message. After receiving the BTM response message, the first SFU can return a client bootstrapping response message to the MFU based on the BTM response message. The STA then switches to the first SFU's MBSS and associates with the first SFU's MBSS.

[0045] In an exemplary embodiment, in response to the MBSS field indicating that the roaming destination BSS of the STA is a BSS, receiving a response message returned by the first SFU based on reference signaling includes:

[0046] Receive the client boot response message returned by the first SFU based on the BTM response message, wherein the BTM response message is returned by the STA to the first SFU based on the BTM request message sent by the first SFU, the BTM request message is sent by the first SFU to the STA based on the client boot request message, and the BTM request message carries the MBSS field.

[0047] Send an MBSS destruction request message to the first SFU so that the first SFU can destroy the MBSS according to the MBSS destruction request message;

[0048] Receive the destruction success response message returned by the first SFU based on the MBSS destruction request message.

[0049] For example, after the MFU sends a reference signaling message to the first SFU, the first SFU sends a BTM request message to the STA based on the reference signaling message. This BTM request message carries an MBSS field, marking the STA's roaming destination BSS as the BSS. The STA can return a BTM response message to the first SFU based on the BTM request message. Upon receiving the BTM response message, the first SFU can return a client bootstrapping response message to the MFU based on the BTM response message. The STA then switches to the first SFU's BSS and associates with it.

[0050] It should be noted that it could also be an MBSS close request message, so that the first SFU closes the MBSS according to the MBSS close request message. That is, in all embodiments of this disclosure, it is not limited to destroying the MBSS, but can also be closing the MBSS.

[0051] For example, the client boot response message may include the first SFU reporting the 11v boot result to the MFU. If the 11v boot result indicates STA handover failure, the process ends. If the 11v boot result indicates STA handover success, the MFU needs to send an MBSS destruction request message to the first SFU, instructing the first SFU to destroy the MBSS. After the first SFU successfully destroys the MBSS, it reports a destruction success response message to the MFU. The STA can then interact with the second SFU on the BSS.

[0052] For example, the client bootstrap request message is shown in Table 1.

[0053] Table 1

[0054] BSSID: Basic Service Set Identifier, a 6-byte MAC address used to uniquely identify an access point for a wireless network. In roaming scenarios, it represents the MAC address of the source BSS currently associated with the STA.

[0055] Request Mode: This is a 1-byte field. Bit 7 indicates the type of request mode, while Bit 6 in some roaming protocols indicates Disassociation Imminent, meaning the STA may soon leave the current BSS. Bit 5 is defined as the "Abridged" bit, which in the 802.11v protocol is typically used to indicate whether the roaming opportunity window has been shortened or simplified.

[0056] Steering Opportunity Window: A 2-byte field that defines the time window during which the STA can roam to the target BSS. The size and position of this window can be adjusted by the MFU based on network conditions and the STA's movement pattern.

[0057] Disassociation Timer: A 2-byte field that indicates when the association of a STA on the current BSS will end. This helps the STA prepare in advance for roaming to the next BSS.

[0058] STA list Num: Number of STAs in the list, a 1-byte field indicating the number of STA MAC addresses in subsequent messages, i.e. how many STAs need to be directed to roam.

[0059] STA MAC: The MAC address of the STA is a 6-byte field used to identify the STA that needs to roam. Each STA has its own unique MAC address, and this field is used to identify the corresponding STA in the message.

[0060] BSSID list Num: Number of BSSIDs in the list, a 1-byte field indicating how many target BSSs can be used as roaming options for STAs.

[0061] Target BSSID: The destination BSSID is a 6-byte field used to identify the MAC address of the destination BSS to which the STA will roam.

[0062] Opclass: Operation class, a 1-byte field that defines the operation class of the radio frequency band used by the target BSS, so that the STA can quickly identify and access the correct frequency band.

[0063] Channel: A 1-byte field that specifies the radio channel used by the destination BSS. This helps the STA select the correct channel while roaming and avoid channel conflicts.

[0064] MBSS: The MBSS field is a 1-byte field used to indicate whether the destination BSS is an MBSS. For example, a bit value of 1 (or other predetermined value) indicates that the target BSS is an MBSS, while a bit value of 0 (or other predetermined value) indicates that the target BSS is a BSS. This field was introduced to more clearly instruct the STA to perform a specific type of roaming (mobile BSS roaming or normal BSS roaming), thereby enabling a fast and seamless roaming process.

[0065] In one exemplary embodiment, the MBSS field is located in a reserved field of the BSSID information field, the BSSID information field is located in the neighbor report element field, the neighbor report element field is located in the BSS conversion candidate list entry field, and the BSS conversion candidate list entry field is located in the BTM request message.

[0066] For example, FIG3 is an embodiment of the 802.11V message format according to an embodiment of the present disclosure. The message format is shown in FIG3. The BTM request message uses the 802.11V message format.

[0067] Category: 1 byte, which describes the message category and is used to identify which functional category in the 802.11 series the message belongs to.

[0068] WIM Action: 1 byte, which can describe whether the message belongs to WIM (Wireless Interworking) action and is used to enable interoperability between different wireless networks.

[0069] Dialog Token: 1 byte, which describes messages used to identify and track bidirectional communication sequences between multiple entities in a network.

[0070] Request Mode: 1 byte, which can describe the operation mode used to indicate the request message, such as whether to request the STA to roam, or whether to immediately associate before roaming.

[0071] Disassociation Timer: 2 bytes, which describes the time at which an STA will be forced to disassociate from the current BSS if it fails to complete its roaming before the timer expires.

[0072] Validity Interval content: 1 byte, which can be used to describe how long an operation request in a message is valid.

[0073] BSS Termination Duration: 0 or 12 bytes, an optional field that, if present, describes the duration for which the BSS will terminate, used for subsequent operations of the STA plan.

[0074] Session Information URL: Variable bytes, optional field, provides a URL address containing session information. The STA can obtain further network service information through this URL.

[0075] BSS Transition Candidate List Entries: Variable bytes, optional field, containing information about one or more candidate BSSs, used by the STA to select the best roaming target.

[0076] Figure 4 illustrates the intent of the Neighbor Report Elements field format according to an embodiment of this disclosure. BSS Transition Candidate List: This is the list of candidate roaming APs, containing the Neighbor Report Elements field for each BSS.

[0077] Element ID: 1 byte, used to identify the type of the element, namely the Neighbor Report element.

[0078] Length: 1 byte, representing the length of the current element, which helps the receiver to correctly parse the element content.

[0079] BSSID: 6 bytes, representing the MAC address of the nearest BSS. BSSID is the address used to uniquely identify each access point in a wireless LAN.

[0080] BSSID Information: 4 bytes, containing additional information about the BSSID, such as reachability, security, and aggregation information. In this disclosure, Bit 14 is reserved in the BSSID Information as the Mobile BSS field, used to mark whether the destination BSS is an MBSS (Mobile BSS), with 1 indicating an MBSS and 0 indicating a regular BSS.

[0081] Operating Class: 1 byte, indicating the operating class used by the neighboring BSS, which helps to determine the frequency band and frequency point.

[0082] Channel: 1 byte, identifies the wireless channel being used by the neighboring BSS. STAs need to select the correct channel based on this information when roaming.

[0083] PHY Type: 1 byte, indicating the physical layer type used by the neighboring BSS, such as 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, etc.

[0084] Optional Subelements: Variable length, containing a series of optional subelements to provide more detailed BSS information, such as signal strength, channel utilization, supported rate sets, etc.

[0085] Figure 5 illustrates the BSSID information field format according to an embodiment of this disclosure. As shown in Figure 5, the neighbor report element field includes a BSSID information field, BSSID Information. Bit 14 of the reserved field in the BSSID information is defined as MBSS, indicating whether the attribute of this destination BSS is MBSS; for example, 1 represents MBSS and 0 represents BSS.

[0086] AP Reachability Bit Position: B0 Bit Count: 2, indicating the reachability status between the STA and the AP corresponding to the BSSID in the report. Two bits can be used to indicate different reachability levels, such as whether direct communication or communication via a relay node is possible.

[0087] Security bit position: B1 bit number: 1, indicating whether the BSS corresponding to the BSSID has enabled security mechanisms, such as whether encryption is supported.

[0088] Key Scope bit position: B2 bit number: 1, indicates the range of keys used by the BSS corresponding to the BSSID, and helps the STA understand whether additional key information is needed.

[0089] Capabilities bit position: B3 Number of bits: 6, provides the capability set of the AP corresponding to the BSSID, such as supported service types, data rates, etc.

[0090] Mobility Domain (B4) bit position: 1, identifies the mobility domain where the BSSID is located. A mobility domain is a logical concept used to represent a group of BSSs that can roam without being noticed.

[0091] High Throughput bit position: B9 Number of bits: 1, indicating whether the BSS corresponding to the BSSID supports high throughput mode, such as 802.11n or later versions of the WLAN standard.

[0092] Very High Throughput (Very High Throughput Support) Bit Position: B10 Number of Bits: 1, indicating whether higher throughput standards such as 802.11ac or 802.11ax are supported.

[0093] FTM (Fine Timing Measurement) bit position: B11 bit number: 1, indicates whether the fine timing measurement function is supported. This was introduced in the 802.11mc standard to improve position accuracy and roaming performance.

[0094] Reserved field bit position: B12 to B31, number of bits: 18, indicates whether the attribute of this BSS is MBSS, for example 1 indicates MBSS, 0 indicates BSS.

[0095] Step S204, or send reference signaling to the second SFU, wherein the reference signaling carries a block acknowledgment (BA) information field or a multi-link operation (MLO) link information field, and the second SFU is not associated with the STA.

[0096] For example, the MFU can send reference signaling carrying BA information fields or MLO link information fields to a second SFU that is not associated with the STA, which can achieve zero awareness of BA and zero awareness of MLO STA handover, and reduce network packet loss rate.

[0097] In one exemplary embodiment, step S204 includes:

[0098] Obtain the first network status information, and determine the STA that needs to roam to the second SFU based on the first network status information;

[0099] Send a wireless terminal information acquisition request message to the first SFU, wherein the STA is associated with the MBSS of the first SFU;

[0100] Receive the wireless terminal information response message returned by the first SFU based on the wireless terminal information acquisition request message, wherein the wireless terminal information response message carries the BA information field;

[0101] A reference signaling message is sent to the second SFU so that the second SFU can create an MBSS based on the reference signaling message and synchronize BA information. The reference signaling message is an MBSS creation request message carrying the BA information field.

[0102] In one exemplary embodiment, the first network state information includes at least one of the following: non-associated STA measurement results, STA historical data, and the number of MBSS available to the SFU.

[0103] For example, the STA is associated with the MBSS of the first SFU. The MFU can obtain the first network status information from the first SFU and the second SFU by sending a request message. Based on the first network status information, it determines that the STA needs to roam to the second SFU. It sends a wireless terminal information acquisition request message to the first SFU. After obtaining the wireless terminal information, it sends a reference signaling (an MBSS creation request message carrying the BA information field) to the second SFU to instruct the second SFU to create an MBSS for the STA.

[0104] In one exemplary embodiment, the BA information field includes at least one of the following: a valid traffic identifier (TID) field and an aggregation information field. The STA security information includes at least one of the following: key length, associated negotiated key, PN sequence number in encryption mode, integrity multicast key length, integrity multicast key, integrity multicast PN sequence number, SN context, and message sequence number.

[0105] For example, the wireless terminal information response message is shown in Table 2.

[0106] Table 2

[0107] STA's MAC (6 bytes): The media access control address associated with the STA, used to uniquely identify each wireless device in the network.

[0108] Key length (2 bytes): Indicates the length of the key, which is typically used to encrypt and decrypt data to ensure the security of wireless communication.

[0109] PTK Pairwise Transient Key (32 bytes): This is a pairwise transient key generated between the site and the BSS after association negotiation, used to protect data transmission between the site and the network in encrypted mode.

[0110] TX PN (Transmission Sequence Control, 8 bytes): This is the PN sequence number in encrypted mode, which helps to identify and confirm the transmission status of data packets, ensuring the correct order and integrity of the data.

[0111] IGTK Integrity Multicast Key Length (2 bytes): The length of the integrity multicast temporary key, which is used to protect the integrity and security of multicast data.

[0112] IGTK (Integrity Group Temporal Key, 32 bytes): Integrity multicast key, ensuring the security and integrity of multicast data packets during transmission.

[0113] Integrity Sequence Number (IPN, 8 bytes): The integrity multicast PN sequence number is used for the sequence number of packets in integrity multicast to ensure the correct order and integrity of multicast data packets.

[0114] SN Context (32 bytes, expandable): Sequence number context information, context information related to aggregation, such as transmission window, data block size, etc., which is extremely important for maintaining the aggregation communication state after roaming handover.

[0115] IPID (Integrity Package ID, 32 bytes): Message sequence number, used to identify a specific integrity multicast data packet, which helps the receiver to correctly reassemble the data.

[0116] Valid TIDs (TIDValid, 16 bytes, may need to be expanded if subsequent protocols expand the number of TIDs): This field indicates which TIDs (Traffic IDs) need to be aggregated in the uplink or downlink. 1 indicates that aggregation is required, and 0 indicates that it is not. This helps network devices understand the aggregation requirements of STAs.

[0117] Aggregation information (1250 bytes, may need to be expanded if the protocol changes in the future): It contains the aggregation parameters of all TIDs, such as the size of the aggregated data block, the aggregation time interval, etc. This is crucial for quickly restoring the aggregation communication state and ensuring that the STA can seamlessly continue aggregation communication after roaming.

[0118] For example, the MBSS creation request message is shown in Table 3.

[0119] Table 3

[0120] Radio Frequency ID (6 bytes): The MAC address corresponding to the radio frequency of the SFU, used to specify a specific radio frequency for MBSS creation in a multi-radio environment.

[0121] BSSID (6 bytes): Sets the BSSID (Basic Service Set Identifier) ​​corresponding to this SFU. The BSSID is used to uniquely identify a wireless access point or network in the network.

[0122] SSID name length (2 bytes): The length of the SSID (Service Set Identifier) ​​name corresponding to the SFU. The SSID is the wireless network name that users can see and is used to distinguish different wireless networks.

[0123] SSID Name (50 bytes): The SSID name corresponding to the SFU. This is the recognizable name of the wireless network, which helps the STA identify the target network.

[0124] Password length (2 bytes): The length of the password for the BSSID corresponding to the SFU, used to determine the size of the subsequent password field.

[0125] Password (64 bytes): The password for the BSSID corresponding to the SFU. This password is used for encryption and authentication to ensure network security.

[0126] STA's MAC (6 bytes): The MAC address of the STA to be associated with MBSS, used to uniquely identify the STA in the network.

[0127] Key length (2 bytes): The length of the key, used to indicate the size of subsequent key fields.

[0128] PTK (Pairwise Transient Key, 32 bytes): The key after association negotiation. This key is generated when a secure association is established between the MFU and STA and is used for data encryption.

[0129] TX PN (Transmission Package Number, 8 bytes): The PN sequence number in encrypted mode. In encrypted mode, it is used to identify the sequence number of the data packets sent by the STA, ensuring the order and integrity of the data packets.

[0130] IGTK length (2 bytes): Integrity multicast key length, used to indicate the size of subsequent IGTK fields.

[0131] IGTK (Integrity Group Temporal Key, 32 bytes): Integrity multicast key, which is a key used in multicast communication to protect the integrity and security of multicast data.

[0132] IPN (Integrity Package Number, 8 bytes): Integrity multicast PN sequence number, used in multicast communication to identify and track the sequence number of integrity multicast data packets in order to maintain the order of communication.

[0133] SN Context (32 bytes, expandable): Sequence number context information, aggregation-related context information, such as transmission window, data block size, etc., used to maintain the aggregation communication state after roaming handover.

[0134] IPID (Integrity Package ID, 32 bytes): Message sequence number, used to identify a specific integrity multicast data packet in multicast communication, which helps the receiver to correctly reassemble the data.

[0135] Valid TID TIDValid (16 bytes, may need to be extended if subsequent protocols expand the number of TIDs): Indicates which TIDs (Traffic IDs) need to establish aggregation in the uplink or downlink. 1 indicates that aggregation is required and 0 indicates that aggregation is not required. It is used to quickly resume aggregation communication after roaming.

[0136] Aggregation information (1250 bytes, may need to be expanded if the protocol changes in the future): contains aggregation parameters for all TIDs, such as the size of the aggregated data block, the aggregation time interval, etc. This is crucial for quickly restoring the aggregation communication state after roaming handover, ensuring that the STA can seamlessly connect and restore aggregation communication after roaming.

[0137] In one exemplary embodiment, after step S204, the following is included:

[0138] Receive the MBSS creation success response message returned by the second SFU based on the reference signaling;

[0139] Send an MBSS destruction request message to the first SFU so that the first SFU can destroy the MBSS of the first SFU according to the MBSS destruction request message;

[0140] Receive the destruction success response message returned by the first SFU based on the MBSS destruction request message;

[0141] Receive STA change information sent by the second SFU.

[0142] For example, after sending a reference signaling message to the second SFU, the second SFU can establish an MBSS, return an MBSS creation success response message to the MFU, and create a virtual STA to obtain and synchronize STA information. The MFU sends an MBSS destruction request message to the first SFU, instructing the first SFU to destroy the MBSS, receives a destruction success response message returned by the first SFU based on the MBSS destruction request message, and receives STA change information sent by the second SFU.

[0143] In one exemplary embodiment, step S204 includes:

[0144] Send an MLO capability acquisition request message to the first SFU, wherein the STA associates with the MBSS of the first SFU via MLO;

[0145] Receive the MLO capability response message returned by the first SFU based on the MLO capability acquisition request message;

[0146] Obtain the second network status information, and determine the STA's need to roam to the second SFU based on the second network status information;

[0147] Send a request message to the first SFU to obtain MLO link information;

[0148] Receive the MLO link information response message returned by the first SFU based on the MLO link information acquisition request message;

[0149] A reference signaling message is sent to the second SFU so that the second SFU can create an MBSS based on the reference signaling message and perform BA information synchronization and TID-to-link mapping for each link of MLO. The reference signaling message is an MBSS creation request message that carries the MLO link information field.

[0150] In one exemplary embodiment, the second network status information includes at least one of the following: STA signal strength, STA historical data, and the number of MBSS that the SFU can use in MLO mode.

[0151] For example, the STA is associated with the MBSS (MLO) of the first SFU via MLO. The MFU can send an MLO capability acquisition request message to the first SFU and receive an MLO capability response message to determine whether the STA, the first SFU, and the second SFU support MLO. The MFU can obtain second network status information from the first SFU and the second SFU by sending request messages, and determine whether the STA needs to roam to the second SFU (the second SFU supports MLO) based on the second network status information.

[0152] The MFU sends an MLO link information retrieval request message to the first SFU and receives an MLO link information response message from the first SFU based on the MLO link information retrieval request message. The MFU can obtain the current MLO link information according to the Multi-Link Distributor (MLD) Media Access Control (MAC). The MFU sends a reference signaling message to the second SFU, instructing the second SFU to establish various MBSS (MLO) links in each frequency band. The MLO link information obtained from the first SFU is sent to the second SFU. Then, the second SFU needs to synchronize BA information and perform TID-to-link mapping for each MLO link.

[0153] For example, the MLO link information may include unicast message information, multicast message information, and BA information. Unicast message information includes the same PTK and PN information shared by all links. Multicast message information includes the GTK, IGTK, and IPN information for each link.

[0154] In one exemplary embodiment, after step S204, the following is included:

[0155] Receive the MBSS creation success response message returned by the second SFU based on the reference signaling;

[0156] Send an MBSS destruction request message to the first SFU so that the first SFU can destroy the MBSS of the first SFU according to the MBSS destruction request message;

[0157] Receive the destruction success response message returned by the first SFU based on the MBSS destruction request message;

[0158] Receive STA change information sent by the second SFU.

[0159] For example, after the second SFU completes the synchronization of MLO information across all links, the second SFU returns an MBSS creation success response message to the MFU. The MFU sends an MBSS destruction request message to the first SFU, instructing the first SFU to destroy the MBSS on each link. The first SFU then reports a destruction success response message to the MFU. The STA can then interact with the second SFU.

[0160] In an exemplary embodiment, the fields carried in the MLO link information acquisition request message include at least one of the following: STA Multilink Distributor Media Access Control (MLD) MAC, BSSID;

[0161] The MLO response message for each link includes at least one of the following fields: STA's MLD MAC, main link key length, main link pairwise temporary key PTK, main link transmission message sequence number TX PN, main link sequence number SN context, main link message sequence number IID, main link valid TID, main link aggregation information, number of auxiliary APs, integrity multicast key IGTK length, IGTK, integrity multicast PN sequence number IPN;

[0162] The MBSS creation request message carries at least one of the following fields: SSID name length, SSID name, password length, password, STA's MLD MAC, main link key length, main link PTK, main link TX PN, main link SN context, main link IPID, main link valid TID, main link aggregation information, number of auxiliary APs, radio ID, BSSID, IGTK length, IGTK, IPN.

[0163] In one exemplary embodiment, the MBSS destruction request message carries fields including at least one of the following: the STA's MLD MAC, the STA to be associated with, the number of affiliated APs, and the BSSID;

[0164] MBSS creation success response message or destruction success response message includes at least one of the following: number of affiliated APs, RF ID, BSSID, success identifier.

[0165] For example, the MLO link information acquisition request messages are shown in Table 4.

[0166] Table 4

[0167] STA's MLD MAC: 6 bytes in length. The MLD MAC (Multi-Link Device MAC Address) is the identifier of the STA when using MLO mode; it is used to distinguish and locate a specific STA. The MFU uses this field to specify which STA's MLO link information it wants to obtain.

[0168] BSSID: 6 bytes in length. BSSID is the Basic Service Set Identifier, used to uniquely identify a wireless network. Here, BSSID refers to the BSSID of the primary link currently associated with the STA, and can also be used to identify the network or SFU currently primarily connected to by the STA.

[0169] For example, the MLO link information response messages are shown in Table 5.

[0170] Table 5

[0171] STA's MLD MAC: This 6-byte MLD MAC address uniquely identifies the STA in an MLO environment. The MLD MAC is the primary identifier used by the STA to communicate with network devices when connected to multiple APs in MLO mode.

[0172] Link Key Length: 2 bytes in length, indicating the length of the key used in the main link. The key is a critical security element used for encrypting and decrypting data in wireless communication, and its length directly affects the security strength of the communication.

[0173] Main Link PTK: 32 bytes in length. This is the Pairwise Transient Key (the key negotiated under the main link) on the main link, used to protect the privacy and integrity of wireless communication between the STA and AP. The PTK is a key generated when the STA and AP establish an association, ensuring the security of transmitted data.

[0174] Main link TX PN: 8 bytes in length, the PN sequence number in encrypted mode under the main link, used for message sequence number management in encrypted mode, to ensure that data packets are transmitted in order and to prevent replay attacks, especially in MLO scenarios where data synchronization and integrity need to be guaranteed.

[0175] The SN (Sequence Number) context of the main link is 32 bytes long (expandable). The SN context contains context information related to the packet sequence number and is crucial for packet aggregation and deaggregation operations. It helps maintain the correct order and integrity of data transmission, which is the key to achieving efficient data transmission in MLO operations.

[0176] Main link IPID: 32 bytes in length. IPID (Integrity Packet ID) is the sequence number of a packet under the main link. It is used for integrity protection to ensure the integrity and security of wireless communication. In MLO mode, it is necessary to track and manage the packet integrity of all links.

[0177] Main link valid TID TIDValid: The length is 16 bytes (it may need to be extended if the number of TIDs is expanded in subsequent protocols). This field is used to indicate which TIDs (transmission identifiers) on the main link need to be aggregated in uplink or downlink transmission. 1 indicates that aggregation is required and 0 indicates that it is not required. This is crucial for optimizing data transmission efficiency and managing link aggregation strategies.

[0178] Main link aggregation information: The length is 1250 bytes (subsequent protocol changes may require expansion). This field contains aggregation parameters for all TIDs, such as the number of aggregations and aggregation thresholds. It is an important component for achieving efficient data transmission, especially in high-throughput network environments.

[0179] Num_AffiliatedAP: This is a 1-byte number of APs associated with the STA, i.e., the number of APs the STA is simultaneously connected to in MLO mode. It is key information for evaluating the MLO status of the STA in the current network.

[0180] IGTK Length: The length is 2 bytes. IGTK is the length of the Integrity Group Temporal Key, which is used for the encryption and decryption of multicast data packets to ensure the privacy and integrity of multicast communication.

[0181] IGTK: 32 bytes in length. This is the integrity multicast key, used to protect the security of multicast communication. IGTK is used in the main link to encrypt multicast packets and maintain the security of multi-point communication in the network.

[0182] IPN: The length is 8 bytes. The integrity multicast PN sequence number is a field used in the main link for verifying the transmission order and integrity of multicast packets, ensuring the correct transmission and processing of multicast data.

[0183] For example, the MBSS creation request message is shown in Table 6.

[0184] Table 6

[0185] SSID name length: The length is 2 bytes, which is used to specify the length of the SSID (Service Set Identifier) ​​name of the MBSS to be created. The SSID is the name of the wireless network and is used to distinguish different wireless networks.

[0186] SSID Name: 50 bytes in length. This is the SSID name of the MBSS, which identifies the specific service set under which the MBSS will be created.

[0187] Password length: 2 bytes in length, indicating the password length of the BSSID corresponding to the SFU. The password is used to encrypt wireless data and for authentication.

[0188] Password: 64 bytes in length. This is the password for the BSSID corresponding to the SFU, used to encrypt wireless communication and ensure network security.

[0189] STA's MLD MAC: This is a 6-byte long MLD (Multi-Link Device) MAC address for the STA (Station), used to uniquely identify the STA's device information in an MLO (Multi-Link Operation) environment.

[0190] Main link key length: 2 bytes in length, representing the length of the main link key. The key is used to encrypt and decrypt wireless communication to ensure the security of data transmission.

[0191] Main link PTK: 32 bytes in length. This is the key negotiated under the main link. It is generated when the association is established between the STA and AP (Access Point) and is used to protect the privacy and integrity of wireless communication.

[0192] Main link TX PN: 8 bytes in length, the PN sequence number in the encrypted mode under the main link, used to ensure that data packets are transmitted in order and to prevent replay attacks.

[0193] The SN context of the main link: 32 bytes in length (expandable). This is sequence number context information related to packet aggregation and deaggregation operations, used to maintain the correct order and integrity of data transmission.

[0194] Main link IPID: 32 bytes in length. This is the Integrity Packet ID (serial number under the main link), used for integrity protection to ensure the integrity and security of wireless communication.

[0195] Main link TIDValid: The length is 16 bytes (it may need to be extended if the number of TIDs is expanded in subsequent protocols). This field indicates which TIDs (Transmission Identifiers) need to be aggregated in the uplink or downlink transmission of the main link, which is crucial for optimizing data transmission efficiency in MLO environments.

[0196] Main link aggregation information: The length is 1250 bytes (subsequent protocol changes may require expansion), which contains aggregation parameters for all TIDs, such as the number of aggregations and aggregation thresholds. It is key information for achieving efficient data transmission.

[0197] Num_AffiliatedAP: This is a 1-byte number of APs associated with the STA, i.e., the number of APs that the STA can connect to simultaneously in MLO mode. It is of great value for managing STA roaming in a multi-link environment.

[0198] RF ID: 6 bytes in length. This is the identifier of the RF interface on the SFU (Sub FTTR Unit, from FTTR device), indicating on which RF the MBSS will be created.

[0199] BSSID: 6 bytes in length, this is the Basic Service Set Identifier, used to identify the target wireless network created by MBSS.

[0200] IGTK Length: The length is 2 bytes. This is the length of the Integrity Group Temporal Key, used for the security protection of multicast data.

[0201] IGTK: 32 bytes in length. This is the integrity multicast key, used to encrypt and decrypt multicast data packets in the MBSS environment, protecting the privacy and integrity of multicast communication.

[0202] IPN: 8 bytes in length. This is the Integrity Package Number (IPN), used to manage the transmission order and integrity verification of multicast data packets, ensuring the correct transmission of multicast data.

[0203] For example, the MBSS destruction request message is shown in Table 7.

[0204] Table 7

[0205] STA's MLD MAC: This 6-byte MAC address is the MLD (Multi-Link Device) MAC address of the STA (Station). The MLD MAC uniquely identifies the STA in the MLO environment, enabling devices in the network to recognize and manage the multi-link connection status of the STA.

[0206] Deassociate STA: This is a 1-byte boolean field indicating whether the STA needs to be deassociated. When set to 1, the association between the STA and MBSS will be terminated when the MBSS is destroyed; when set to 0, the association between the STA and MBSS will remain, and only the resources of the MBSS will be released.

[0207] Num_AffiliatedAP: This field, with a length of 1 byte, represents the number of APs (Access Points) associated with the STA. In MLO scenarios, a STA can be associated with multiple APs simultaneously. This field indicates how many APs the STA is currently associated with, helping the SFU understand the multi-link status of the STA in the current network environment.

[0208] BSSID: 6 bytes in length, short for Basic Service Set Identifier, used to identify the network identifier of an MBSS. In an MBSS destruction request, the BSSID is used to explicitly indicate which MBSS needs to be destroyed, because multiple MBSSs may exist in a network, and the BSSID ensures that the target MBSS is correctly located.

[0209] For example, MBSS creates a successful response message or destroys a successful response message as shown in Table 8.

[0210] Table 8

[0211] Num_AffiliatedAP: This field, with a length of 1 byte, indicates the number of APs (Access Points) associated with a STA (Station). In an MLO (Multi-Link Operation) environment, a STA may be associated with multiple APs simultaneously; this field provides information about the STA's current association status.

[0212] RF ID: 6 bytes in length, identifying the MAC address of the RF interface on the SFU. During the creation or destruction of an MBSS (Mobile Basic Service Set), this field is used to explicitly specify which specific RF interface the operation is targeting. This is especially important for multi-RF devices, ensuring the accuracy of the operation.

[0213] BSSID: 6 bytes in length, short for Basic Service Set Identifier, used to identify the network identifier of the MBSS. In the MBSS creation or destruction confirmation message, the BSSID is used to verify that the operation is performed on the correct MBSS.

[0214] Success or Failure: This is a 1-byte Boolean field indicating the result of the MBSS creation or destruction operation. A value of 1 indicates successful completion; a value of 0 indicates failure. This field is crucial for the MFU to determine the operation status and make subsequent network management decisions.

[0215] In one exemplary embodiment, the method includes: in response to the existence of a Wireless Local Area Network Management and Control Interface (WMCI) management channel between the MFU and a first SFU or a second SFU, loading reference signaling into WMCI information; and sending the WMCI information to the first SFU or the second SFU.

[0216] For example, in an FTTR all-optical network environment, there may be a WMCI management channel between the MFU and SFU. This low-latency channel, which enables WLAN control and other functions between the MFU transceiver unit and the SFU transceiver unit, carries WMCI messages to ensure that the message latency between the MFU and SFU is at the microsecond level. This embodiment of the disclosure uses a WMCI channel as an example, where reference signaling can be loaded with WMCI information, instantiating the various WMCI messages required in the above embodiments.

[0217] In one exemplary embodiment, the fields carried by the WMCI information include at least one of the following: WMCI information type ID, WMCI information length, and WMCI information content; the WMCI information content field carries reference signaling.

[0218] For example, the WMCI message for a wireless terminal information acquisition request is shown in Table 9.

[0219] Table 9

[0220] Message type ID: This field is 1 byte long and contains the value 0x33. It identifies the type of message, specifically a WMCI message requesting information from a wireless terminal. The WMCI (WLAN Management and Control Interface) message type ID is a fixed component of the message format, used to help the receiver quickly identify the nature of the message and its processing logic.

[0221] Message Length: 2 bytes in length, variable content, representing the length of the WMCI message. This field is crucial for the receiver to parse the message structure, providing information about the size of the message body to ensure the message is processed correctly.

[0222] Message content: This part is the message payload, containing detailed information about the STA (Station). The content includes:

[0223] STA's MAC address: This is a 6-byte field used to uniquely identify the STA device. It is an essential field in wireless terminal information requests and is used to specify the STA making the information request.

[0224] BSSID: 6 bytes in length. This is the Basic Service Set Identifier, used to identify the BSS (Basic Service Set) currently associated with the STA. Through the BSSID, the receiver can understand the network environment in which the STA is currently located.

[0225] For example, the WMCI messages in the wireless terminal information response are shown in Table 10.

[0226] Table 10

[0227] Message type ID: This 1-byte field, with a value of 0x34, identifies the message type, specifically the WMCI message reported by the wireless terminal. The message type ID is crucial in communication protocols because it helps the receiving device identify the nature of the message and how to process it.

[0228] Message Length: 2 bytes in length, variable content, representing the length of the WMCI message. This field ensures the receiver can correctly read and parse all the message content, avoiding data truncation or parsing errors.

[0229] Message content: This part is the message payload, containing detailed information about the STA (Station), including:

[0230] STA MAC Address: This 6-byte MAC address is the MAC address of the associated STA and is used to uniquely identify the STA device. In a wireless network, the MAC address is crucial information for device identification, used for tracking and managing STAs.

[0231] Key length: This 2-byte key describes the length of the encryption key. In secure communication, the key length directly affects the security strength of the encryption algorithm.

[0232] PTK: 32 bytes in length. This is the negotiated key used in the 802.11 security protocol to protect wireless communication between the STA and AP (Access Point). PTK is established between the STA and AP via a four-way handshake protocol and is used for encrypting and decrypting data.

[0233] TX PN: This is an 8-byte sequence number used in encrypted mode for message sequence number tracking. In the 802.11 security protocol, TX PN is used to prevent replay attacks and ensure the order and integrity of wireless communication.

[0234] IGTK Length: The length is 2 bytes. IGTK is the length of the Integrity Group Temporal Key, which is used to protect the security of multicast communication and ensure the integrity and privacy of multicast data.

[0235] IGTK: 32 bytes in length, this is the integrity multicast key itself, used to encrypt and decrypt multicast packets, ensuring the privacy and integrity of multicast data.

[0236] IPN: 8 bytes in length. It is short for Integrity Package Number (PN) and is used to manage the transmission order and integrity verification of multicast data packets.

[0237] SN Context: 32 bytes long (expandable). This is Sequence Number context information used for operations related to packet sequence numbers, especially during data aggregation and deaggregation, where it helps maintain the order and integrity of data transmission.

[0238] IPID: 32 bytes in length. This is the Integrity Packet ID, used to implement data integrity protection and ensure the integrity and security of wireless communication.

[0239] Valid TID (TIDValid): 16 bytes in length (may be extended if subsequent protocols expand the number of TIDs), used to indicate which TIDs (transmission identifiers) need to be aggregated in uplink or downlink transmissions. Each bit in TIDValid corresponds to one TID; setting it to 1 indicates that an aggregation needs to be established, and setting it to 0 indicates that it does not.

[0240] Aggregation information: 1250 bytes in length (may be expanded if the protocol changes later), containing aggregation parameters for all TIDs, such as aggregation threshold, aggregation window, etc., used to optimize data transmission efficiency and manage link aggregation strategies.

[0241] For example, the WMCI message for an MBSS creation request is shown in Table 11.

[0242] Table 11

[0243] Message type ID: This 1-byte field, with a value of 0x35, defines the message type and explicitly indicates that this is a WMCI message for an MBSS creation request. The message type ID is crucial for message identification and proper processing.

[0244] Message Length: 2 bytes in length, variable content, representing the length of the WMCI message. This field helps SFU correctly parse the message structure and avoid data parsing errors.

[0245] Message content: This part contains the main content of the message, including detailed configuration information required to create MBSS.

[0246] RF ID: 6 bytes in length. This is the MAC address of the RF interface on the SFU, used to specify on which RF the MBSS will be created.

[0247] BSSID: 6 bytes in length, this is the Basic Service Set Identifier, used to identify the created MBSS network.

[0248] SSID name length: The length is 2 bytes, which is used to specify the length of the SSID (Service Set Identifier) ​​name. The SSID name is used to distinguish different wireless networks.

[0249] SSID name: 50 bytes in length, giving the SSID name corresponding to the SFU, which is the network identifier when creating MBSS.

[0250] Password length: 2 bytes, indicating the password length of the BSSID corresponding to the SFU.

[0251] Password: 64 bytes in length. This is the password for the BSSID corresponding to the SFU, used to protect network security.

[0252] STA's MAC: This is a 6-byte long MAC address of the STA to be associated with, used to identify which STA the MBSS creation request needs to be sent to.

[0253] Key Length: The key is 2 bytes long and describes the length of the key used to encrypt and decrypt wireless communications.

[0254] PTK: 32 bytes in length. This is the Pairwise Transient Key, used to protect the wireless communication between the STA and AP (Access Point).

[0255] TX PN: 8 bytes in length. This is short for Transmit Packet Number (PN sequence number in encrypted mode), used for message sequence numbers in encrypted mode.

[0256] IGTK Length: The length is 2 bytes. IGTK is the length of the Integrity Group Temporal Key, which is used to protect the security of multicast data.

[0257] IGTK: 32 bytes in length, this is the integrity multicast key used to encrypt and decrypt multicast packets.

[0258] IPN: 8 bytes in length. It is short for Integrity Package Number (IPN), used to manage the sequence number of multicast messages.

[0259] SN Context: 32 bytes in length (expandable), this is Sequence Number context information used for operations related to packet sequence numbers.

[0260] IPID: 32 bytes in length, this is the Integrity Packet ID (sequence number), used for integrity protection.

[0261] TID Valid: 16 bytes in length (may be extended if subsequent protocols expand the number of TIDs), used to indicate which TIDs (Transmission Identifiers) need to be aggregated in uplink or downlink transmissions.

[0262] Aggregation information: 1250 bytes in length (may be expanded if the protocol changes), containing aggregation parameters for all TIDs, such as aggregation quantity and aggregation threshold, used to optimize data transmission efficiency.

[0263] Num_AffiliatedAP: 1 byte in length, representing the number of APs associated with the STA, i.e. the number of APs associated with the STA in an MLO (Multi-Link Operation) environment.

[0264] For example, the WMCI message for an MBSS destruction request is shown in Table 12.

[0265] Table 12

[0266] Message type ID: Length: 1 byte, Content value: 0x36. This field defines the message type, indicating that the current message is a WMCI message for MBSS destruction request, helping the receiver quickly identify the nature of the message.

[0267] Message Length: 2 bytes, variable content, representing the total length of the entire WMCI message, helping the receiver to correctly parse the message structure and ensuring complete message reception.

[0268] The message content can include the following subfields:

[0269] STA MAC: This field is 6 bytes long and contains the STA's MAC address. It is used to explicitly identify which STA's MBSS needs to be destroyed.

[0270] BSSID: 6 bytes in length, it identifies the BSSID (Basic Service Set Identifier) ​​of the MBSS associated with the STA. The receiver can determine which specific MBSS network needs to be destroyed using the BSSID.

[0271] Deassociate STA: This is a 1-byte boolean field indicating whether to deassociate STAs during MBSS destruction. A value of 1 indicates deassociating STAs, while a value of 0 indicates retaining the association status of STAs and only destroying MBSSs.

[0272] For example, the WMCI messages for MBSS creation / destruction responses are shown in Table 13.

[0273] Table 13

[0274] Message type ID: Length: 1 byte, Content value: 0x37. This field defines the message type, indicating that the current message is a WMCI message created and confirmed by MBSS. It helps the receiver quickly identify the message nature and prepare to receive and process the correct message type.

[0275] Message Length: Length: 2 bytes, variable content, representing the total length of the entire WMCI message, helping the receiver to correctly parse the message structure and ensuring complete message reception and accurate parsing.

[0276] Message content: This part is the message payload, containing detailed information confirming the successful MBSS creation operation.

[0277] RF ID: 6 bytes in length, containing the MAC address of the RF interface on the SFU. This field specifies the exact RF interface used to create the MBSS, ensuring accurate network management for multiple RF devices.

[0278] BSSID: 6 bytes in length, containing the BSSID (Basic Service Set Identifier) ​​of the created MBSS. The MFU can verify that the MBSS was created for the correct network identifier using the BSSID.

[0279] Success or Failure: This is a 1-byte Boolean field indicating the result of the MBSS creation operation. A value of 1 indicates successful creation, and a value of 0 indicates failure. This field is crucial for network management, ensuring that the MFU can obtain timely feedback on the MBSS creation status for subsequent network control and optimization.

[0280] Through the above steps, the problems of significant latency and service delay in all-optical network networking and roaming schemes, which are equivalent to STA re-association, are solved. The goal is to reduce latency and service delay, control STA switching between BSS and MBSS, and achieve zero-awareness switching of BA and MLO STA.

[0281] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solutions of this disclosure, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this disclosure.

[0282] This embodiment also provides a configuration system for reference signaling, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0283] Figure 6 is a structural block diagram of a configuration system for reference signaling according to an embodiment of the present disclosure. As shown in Figure 6, the system 60 includes a main fiber-to-remote node (MFU) 62, a first secondary fiber-to-remote node (FTTR) 64, a second SFU 66, and a site STA 68.

[0284] MFU 62 is configured to send reference signaling to the first SFU, wherein the reference signaling carries a Mobile Basic Service Set (MBSS) field, and the first SFU is associated with the STA; or, to send reference signaling to the second SFU, wherein the reference signaling carries a Block Acknowledgment (BA) information field or a Multi-Link Operation (MLO) link information field, and the second SFU is not associated with the STA.

[0285] The first SFU 64 is configured to receive reference signaling; the STA is instructed by the reference signaling to switch between the Basic Service Set (BSS) and MBSS.

[0286] The second SFU 66 is configured to receive reference signaling; to synchronize BA information based on the reference signaling, or to synchronize BA information and perform TID-to-link mapping for each link of MLO;

[0287] STA 68 is configured to switch between the BSS and MBSS of the first SFU, or to switch the MBSS between the first SFU and the second SFU.

[0288] In an exemplary embodiment, the MFU is configured to detect that the STA has moved to a predetermined range and determine that the STA is about to roam; send an MBSS creation request message to the first SFU; receive an MBSS creation success response message returned by the first SFU based on the MBSS creation request message; send reference signaling to the first SFU, wherein the reference signaling is a client boot request message carrying an MBSS field, the MBSS field being used to indicate that the STA's roaming destination BSS is MBSS; and receive a client boot response message returned by the first SFU based on the client boot request message.

[0289] The first SFU is configured to receive MBSS creation request messages; create an MBSS based on the MBSS creation request message; return an MBSS creation success response message to the MFU based on the MBSS creation request message; receive reference signaling; send a Basic Service Set Switching Management (BTM) request message to the STA based on the reference signaling, wherein the BTM request message carries an MBSS field; receive a BTM response message returned by the STA based on the BTM request message; and return a client boot response message to the MFU based on the BTM response message.

[0290] STA is configured to be associated with the BSS of the first SFU; receive BTM request messages sent by the first SFU; return BTM response messages to the first SFU based on the BTM request messages; switch to the MBSS of the first SFU according to the BTM request messages, and associate with the MBSS of the first SFU.

[0291] In an exemplary embodiment, the MFU is configured to detect that the STA has been in a non-roaming state for a predetermined period of time, determine that the STA needs to switch back to the BSS; send reference signaling to the first SFU, wherein the reference signaling is a client bootstrapping request message carrying an MBSS field, the MBSS field being used to indicate that the STA's roaming destination BSS is the BSS; receive a client bootstrapping response message returned by the first SFU; send an MBSS destruction request message to the first SFU; and receive a destruction success response message returned by the first SFU based on the MBSS destruction request message.

[0292] The first SFU is configured to receive reference signaling; send a BTM request message to the STA based on the reference signaling, wherein the BTM request message carries an MBSS field; receive a BTM response message returned by the STA based on the BTM request message; return a client boot response message to the MFU based on the BTM response message; receive an MBSS destruction request message; destroy the MBSS according to the MBSS destruction request message; and return a destruction success response message to the MFU based on the MBSS destruction request message.

[0293] STA is configured to be associated with the MBSS of the first SFU; receive BTM request messages sent by the first SFU; return BTM response messages to the first SFU based on the BTM request messages; switch to the BSS of the first SFU according to the BTM request messages, and associate with the BSS of the first SFU.

[0294] In an exemplary embodiment, the MFU is configured to: acquire first network status information; determine, based on the first network status information, that the STA needs to roam to the second SFU; send a wireless terminal information acquisition request message to the first SFU; receive a wireless terminal information response message returned by the first SFU based on the wireless terminal information acquisition request message, wherein the wireless terminal information response message carries a BA information field; send reference signaling to the second SFU, wherein the reference signaling is an MBSS creation request message carrying a BA information field; receive an MBSS creation success response message returned by the second SFU based on the reference signaling; send an MBSS destruction request message to the first SFU; receive a destruction success response message returned by the first SFU based on the MBSS destruction request message; and receive STA change information sent by the second SFU.

[0295] The first SFU is configured to receive wireless terminal information acquisition request messages; return wireless terminal information response messages to the MFU based on the wireless terminal information acquisition request messages; receive MBSS destruction request messages; destroy the MBSS of the first SFU according to the MBSS destruction request messages; return destruction success response messages to the MFU based on the MBSS destruction request messages; and receive STA change information sent by the second SFU.

[0296] The second SFU is configured to receive reference signaling; create an MBSS based on the reference signaling and synchronize BA information; create a virtual STA based on the STA to obtain and synchronize STA information; return an MBSS creation success response message to the MFU based on the reference signaling; and send STA change information to both the MFU and the first SFU.

[0297] STA is set to be associated with the MBSS of the first SFU; when switching to the MBSS of the second SFU, it is associated with the MBSS of the second SFU.

[0298] In an exemplary embodiment, the MFU is configured to: send an MLO capability acquisition request message to a first SFU; receive an MLO capability response message returned by the first SFU based on the MLO capability acquisition request message; acquire second network status information and determine, based on the second network status information, that the STA needs to roam to the second SFU; send an MLO link information acquisition request message to the first SFU; receive an MLO link information response message returned by the first SFU based on the MLO link information acquisition request message; send reference signaling to the second SFU, wherein the reference signaling is an MBSS creation request message carrying MLO link information fields; receive an MBSS creation success response message returned by the second SFU based on the reference signaling; send an MBSS destruction request message to the first SFU; receive a destruction success response message returned by the first SFU based on the MBSS destruction request message; and receive STA change information sent by the second SFU.

[0299] The first SFU is configured to receive MLO capability acquisition request messages; return MLO capability response messages to the MFU based on the MLO capability acquisition request messages; receive MLO link information acquisition request messages; return MLO link information response messages to the MFU based on the MLO link information acquisition request messages; receive MBSS destruction request messages; destroy the MBSS of the first SFU according to the MBSS destruction request messages; return a destruction success response message to the MFU based on the MBSS destruction request messages; and receive STA change information sent by the second SFU.

[0300] The second SFU is configured to receive reference signaling; create MBSS based on the reference signaling, and perform BA information synchronization and TID-to-link mapping for each link of MLO; return an MBSS creation success response message to the MFU based on the reference signaling; and send STA change information to the MFU and the first SFU respectively.

[0301] STA is set to associate with the MBSS of the first SFU via MLO; when switching to the MBSS of the second SFU, it is associated with the MBSS of the second SFU via MLO.

[0302] In an exemplary embodiment, the MFU is configured to, in response to the existence of a Wireless Local Area Network Management and Control Interface (WMCI) management channel between the MFU and the first SFU or the second SFU, load reference signaling into WMCI information and send the WMCI information to the first SFU or the second SFU.

[0303] The above embodiments solve the problem of significant latency and service delay in all-optical network networking and roaming schemes, which are equivalent to STA re-association. The solutions reduce latency and service delay, control STA switching between BSS and MBSS, and achieve zero-awareness switching of BA and MLO STA.

[0304] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0305] Example 1

[0306] This embodiment is an example of a roaming scene where a STA switches from a BSS to an MBSS. Figure 7 is a schematic diagram of a roaming scene where a STA switches from a BSS to an MBSS according to an embodiment of this disclosure. As shown in Figure 7, it includes:

[0307] 1) STA is associated with the BSS of the first SFU.

[0308] 2) When the MFU detects that the STA has moved to the predetermined range and determines that the STA is about to roam, the MFU needs to send an MBSS creation request message to the first SFU to instruct the first SFU to create an MBSS.

[0309] 3) After the first SFU successfully creates the MBSS, it sends an MBSS creation success response message to the MFU.

[0310] 4) In order for the MFU to redirect the STA of the BSS already associated with the first SFU to the MBSS of the first SFU, the MFU needs to add the MBSS field to the reference signaling sent to the first SFU to mark the destination BSS of this STA as MBSS (i.e., the client guidance request message carrying the MBSS field, for example, the MBSS field bit is 1). At the same time, in the BTM request message sent by the first SFU to the STA based on the reference signaling, the MBSS bit is added to the reserved field in the BSSID Information (i.e., the BTM request message carrying the MBSS field, for example, the MBSS field bit is 1), which also marks whether the destination BSS of this STA is MBSS.

[0311] 5) The STA receives the BTM request message sent by the first SFU, returns a BTM response message to the first SFU, switches to the MBSS of the first SFU according to the BTM request message, and associates with the MBSS of the first SFU.

[0312] 6) The first SFU receives the BTM response message and returns a client boot response message to the MFU. The MFU receives the client boot response message returned by the first SFU based on the client boot request message.

[0313] Example 2

[0314] This embodiment illustrates an example of STA switching back to BSS without roaming after a predetermined duration. Figure 8 is a schematic diagram of STA switching back to BSS without roaming after a predetermined duration according to an embodiment of this disclosure. As shown in Figure 8, it includes:

[0315] 1) After the STA is associated with the MBSS of the first SFU, it will run normal business operations.

[0316] 2) When the MFU detects that the STA has been in a non-roaming state for more than the predetermined time, in order to release MBSS resources in a timely manner, it needs to switch the STA back to the BSS. The MFU adds the MBSS field to the reference signaling sent to the SFU to mark the destination BSS of this STA roaming as the BSS (i.e., the client boot request message with the MBSS field, for example, the MBSS field bit is 0). At the same time, in the BTM request message sent by the first SFU to the STA, the MBSS bit is added to the reserved field in the BSSID Information, which also marks the destination BSS of this roaming as the BSS (i.e., the BTM request message with the MBSS field, for example, the MBSS field bit is 0).

[0317] 3) The first SFU reports the 11v boot result (i.e., the client boot response message) to the MFU. If the 11v boot switch fails, the process ends. If the boot is successful, the MFU needs to send an MBSS destruction request message to the first SFU, instructing the first SFU to destroy the MBSS.

[0318] 4) After the first SFU successfully destroys the MBSS, it sends a successful destruction response message to the MFU.

[0319] 5) STA can then interact with the first SFU on the BSS of the first SFU.

[0320] Example 3

[0321] This embodiment is an example of MBSS switching BA information synchronization. Figure 9 is a schematic diagram of MBSS switching BA information synchronization according to an embodiment of this disclosure. As shown in Figure 9, it includes:

[0322] 1) STA is associated with MBSS of the first SFU.

[0323] 2) The MFU sends request messages to the first SFU and the second SFU to obtain the first network status information. The first SFU and the second SFU can return response messages to the MFU based on the content of the request messages, to return information such as the measurement results of unrelated STAs, historical data of STAs, and the number of MBSSs available to each SFU. The MFU can select an appropriate SFU to send an MBSS creation request message to instruct that SFU to create an MBSS for the STA based on the measurement results of unrelated STAs in each SFU, historical data of STAs, and the number of MBSSs available to each SFU.

[0324] 3) If the MFU decides that the STA should roam to the second SFU, the MFU sends a wireless terminal information acquisition request message to the first SFU and receives a wireless terminal information response message returned by the first SFU to obtain the STA's security information and BA information.

[0325] 4) The MFU sends a reference signaling instruction to the second SFU to establish an MBSS for the STA (i.e., an MBSS creation request message carrying the BA information field). The second SFU creates the MBSS according to the reference signaling, synchronizes the BA information, creates a virtual STA based on the STA, obtains and synchronizes the STA information, and returns an MBSS creation success response message to the MFU.

[0326] 5) The MFU sends an MBSS shutdown message, instructing the first SFU to shut down the MBSS.

[0327] 6) The MFU receives the MBSS creation success response message returned by the second SFU, sends an MBSS destruction request message to the first SFU, and receives the destruction success response message returned by the first SFU.

[0328] 7) The second SFU sends STA change information to both the MFU and the first SFU. The STA can then interact with the second SFU on the MBSS of the second SFU.

[0329] Example 4

[0330] This embodiment is an example of MLO STA roaming. Figure 10 is a schematic diagram of MLO STA roaming according to an embodiment of this disclosure. As shown in Figure 10, it includes:

[0331] 1) STA is associated with MBSS (MLO) of the first SFU in the MLO manner.

[0332] 2) The MFU sends an MLO capability acquisition request message to the first SFU and receives an MLO capability response message returned by the first SFU based on the MLO capability acquisition request message, so as to know whether the STA, the first SFU, and the second SFU support MLO.

[0333] 3) The MFU sends request messages to the first and second SFUs to obtain the second network status information. The first and second SFUs can return response messages to the MFU based on the content of the request messages, providing information such as the STA signal strength, STA historical data, and the number of MBSS (MLO) available to each SFU. If the MFU determines that the STA should roam to the second SFU (which supports MLO) based on the STA signal strength, STA historical data, and the number of MBSS (MLO) available to each SFU, the MFU sends an MLO link information retrieval request message to the first SFU and receives a MLO link information response message returned by the first SFU based on the MLO link information retrieval request message. The MFU then obtains the current MLO link information (unicast message information, multicast message information, BA information, etc.) based on the MLD MAC.

[0334] 4) The MFU sends a reference signaling message (i.e., an MBSS creation request message carrying the link information fields of the MLO, also known as an MBSS(MLO) creation request message) to the second SFU, instructing the second SFU to establish the various links of the MBSS(MLO) in each frequency band. The second SFU creates the MBSS according to the reference signaling message and performs synchronization of the aforementioned MLO link information, such as BA information, and TID-to-link mapping of the MLO links.

[0335] 5) After completing the above information synchronization on the second SFU, return an MBSS creation success response message to the MFU.

[0336] 6) Send an MBSS destruction request message to the first SFU, instructing the first SFU to destroy the MBSS on each link. The first SFU then sends a destruction success response message to the MFU.

[0337] 7) The second SFU sends STA change information to both the MFU and the first SFU, and the STA can then interact with the second SFU.

[0338] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0339] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0340] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0341] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0342] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0343] It is obvious to those skilled in the art that the modules or steps of this disclosure described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this disclosure is not limited to any particular combination of hardware and software.

[0344] The above are merely preferred embodiments of this disclosure and are not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for configuring reference signaling, applied to the laying of a main optical fiber to a remote node device (MFU), comprising: Send a reference signaling message to the first FTTR (Fiber to the Remote Node) device (SFU), wherein the reference signaling message carries a Mobile Basic Services Set (MBSS) field, and the first SFU is associated with a site (STA); or, A reference signaling is sent to the second SFU, wherein the reference signaling carries a Block Acknowledgment (BA) information field or a Multi-Link Operation (MLO) link information field, and the second SFU is not associated with the STA.

2. The method according to claim 1, wherein, Sending reference signaling to the first SFU includes: In response to detecting that the STA has moved to a predetermined range, it is determined that the STA is about to roam, wherein the STA is associated with the basic service set (BSS) of the first SFU; Send an MBSS creation request message to the first SFU so that the first SFU can create an MBSS based on the MBSS creation request message; Receive the MBSS creation success response message returned by the first SFU based on the MBSS creation request message; The reference signaling is sent to the first SFU so that the first SFU instructs the STA to switch to MBSS according to the reference signaling, wherein the reference signaling is a client boot request message carrying an MBSS field, and the MBSS field is used to indicate that the STA's roaming destination BSS is MBSS.

3. The method according to claim 1, wherein, Sending reference signaling to the first SFU includes: In response to detecting that the STA has been in a non-roaming state for more than a predetermined period of time, it is determined that the STA needs to switch back to the BSS, wherein the STA is associated with the MBSS of the first SFU; The reference signaling is sent to the first SFU so that the first SFU instructs the STA to switch to the BSS according to the reference signaling, wherein the reference signaling is a client boot request message carrying an MBSS field, and the MBSS field is used to indicate that the STA's roaming destination BSS is the BSS.

4. The method according to claim 2 or 3, wherein, After sending the reference signaling to the first SFU, the following is included: Receive the response message returned by the first SFU based on the reference signaling.

5. The method according to claim 4, wherein, In response to the MBSS field indicating that the roaming destination BSS of the STA is MBSS, receiving the response message returned by the first SFU based on the reference signaling includes: The system receives a client boot response message returned by the first SFU based on the Basic Service Set Switching Management (BTM) response message. The BTM response message is returned by the STA to the first SFU based on the BTM request message sent by the first SFU. The BTM request message is sent by the first SFU to the STA based on the client boot request message. The BTM request message carries the MBSS field.

6. The method according to claim 4, wherein, In response to the MBSS field indicating that the roaming destination BSS of the STA is a BSS, receiving the response message returned by the first SFU based on the reference signaling includes: Receive a client boot response message returned by the first SFU based on a BTM response message, wherein the BTM response message is returned by the STA to the first SFU based on a BTM request message sent by the first SFU, the BTM request message is sent by the first SFU to the STA based on the client boot request message, and the BTM request message carries the MBSS field. Send an MBSS destruction request message to the first SFU so that the first SFU can destroy the MBSS according to the MBSS destruction request message; Receive the destruction success response message returned by the first SFU based on the MBSS destruction request message.

7. The method according to claim 1, wherein, Sending reference signaling to the second SFU includes: Obtain first network status information, and determine based on the first network status information that the STA needs to roam to the second SFU; Send a wireless terminal information acquisition request message to the first SFU, wherein the STA is associated with the MBSS of the first SFU; Receive the wireless terminal information response message returned by the first SFU based on the wireless terminal information acquisition request message, wherein the wireless terminal information response message carries a BA information field; The reference signaling is sent to the second SFU so that the second SFU can create an MBSS based on the reference signaling and synchronize BA information, wherein the reference signaling is an MBSS creation request message carrying a BA information field.

8. The method according to claim 7, wherein, After sending the reference signaling to the second SFU, the following is included: Receive the MBSS creation success response message returned by the second SFU based on the reference signaling; Send an MBSS destruction request message to the first SFU so that the first SFU destroys the MBSS of the first SFU according to the MBSS destruction request message; Receive the destruction success response message returned by the first SFU based on the MBSS destruction request message; Receive STA change information sent by the second SFU.

9. The method according to claim 1, wherein, Sending reference signaling to the second SFU includes: Send an MLO capability acquisition request message to the first SFU, wherein the STA is associated with the MBSS of the first SFU via MLO; Receive the MLO capability response message returned by the first SFU based on the MLO capability acquisition request message; Obtain second network status information, and determine based on the second network status information that the STA needs to roam to the second SFU; Send an MLO link information retrieval request message to the first SFU; Receive the MLO link information response message returned by the first SFU based on the MLO link information acquisition request message; The reference signaling is sent to the second SFU so that the second SFU can create an MBSS based on the reference signaling and perform BA information synchronization and TID-to-link mapping of each link of MLO. The reference signaling is an MBSS creation request message carrying MLO link information fields.

10. The method according to claim 9, wherein, After sending the reference signaling to the second SFU, the following is included: Receive the MBSS creation success response message returned by the second SFU based on the reference signaling; Send an MBSS destruction request message to the first SFU so that the first SFU destroys the MBSS of the first SFU according to the MBSS destruction request message; Receive the destruction success response message returned by the first SFU based on the MBSS destruction request message; Receive STA change information sent by the second SFU.

11. The method according to claim 1, wherein, The method includes: In response to the existence of a Wireless Local Area Network Management and Control Interface (WMCI) management channel between the MFU and the first SFU or the second SFU, the reference signaling is loaded into WMCI information; Send the WMCI information to the first SFU or the second SFU.

12. The method according to claim 5, wherein, The MBSS field is located in the reserved field of the BSSID information field, the BSSID information field is located in the neighbor report element field, the neighbor report element field is located in the BSS conversion candidate list entry field, and the BSS conversion candidate list entry field is located in the BTM request message.

13. The method according to claim 7, wherein, The BA information fields include at least one of the following: Valid Traffic Identifier (TID) field and Aggregation Information field; the first network status information includes at least one of the following: non-associated STA measurement results, STA historical data, and the number of MBSS available to the SFU.

14. The method according to claim 9, wherein, The second network status information includes at least one of the following: STA signal strength, STA historical data, and the number of MBSS that the SFU can use in MLO mode; The MLO link information acquisition request message carries at least one of the following fields: STA Multi-Link Distributor Media Access Control (MLD) MAC, BSSID; The fields in the response message for each link information of the MLO include at least one of the following: MLD MAC of the STA, length of the main link key, PTK of the main link pairwise temporary key, sequence number TX PN of the main link transmission message, SN context of the main link sequence number, IID of the message under the main link, valid TID of the main link, aggregation information of the main link, number of auxiliary APs, length of the integrity multicast key IGTK, IGTK, and sequence number IPN of the integrity multicast PN; The MBSS creation request message carries at least one of the following fields: SSID name length, SSID name, password length, password, STA's MLD MAC, main link key length, main link PTK, main link TX PN, main link SN context, main link IPID, main link valid TID, main link aggregation information, number of auxiliary APs, radio frequency ID, BSSID, IGTK length, IGTK, IPN.

15. The method according to claim 10, wherein, The MBSS destruction request message carries at least one of the following fields: STA's MLD MAC, STA to be associated with, number of affiliated APs, and BSSID; The MBSS creation success response message or the destruction success response message includes at least one of the following: number of affiliated APs, radio frequency ID, BSSID, and success identifier.

16. The method according to claim 11, wherein, The fields carried by the WMCI information include at least one of the following: WMCI information type ID, WMCI information length, and WMCI information content; the WMCI information content field carries the reference signaling.

17. A configuration system for reference signaling, comprising a main fiber-to-remote node (MFU), a first secondary fiber-to-remote node (SFU), a second SFU, and a site (STA). The MFU is configured to send reference signaling to the first SFU, wherein... The reference signaling carries a Mobile Basic Service Set (MBSS) field, and the first SFU is associated with a station (STA); or, a reference signaling is sent to the second SFU, wherein the reference signaling carries a Block Acknowledgment (BA) information field or a Multi-Link Operation (MLO) link information field, and the second SFU is not associated with the STA; The first SFU is configured to receive the reference signaling and instruct the STA to switch between the Basic Service Set (BSS) and the MBSS according to the reference signaling. The second SFU is configured to receive the reference signaling; and to synchronize BA information according to the reference signaling, or to synchronize BA information and perform TID-to-link mapping for each link of MLO; The STA is configured to switch between the BSS and MBSS of the first SFU, or to switch the MBSS between the first SFU and the second SFU.

18. The system according to claim 17, wherein, The MFU is configured to detect that the STA has moved to a predetermined range, determine that the STA is about to roam, and send an MBSS creation request message to the first SFU. Receive an MBSS creation success response message returned by the first SFU based on the MBSS creation request message; send the reference signaling to the first SFU, wherein the reference signaling is a client bootstrapping request message carrying an MBSS field, the MBSS field being used to indicate that the roaming destination BSS of the STA is an MBSS; receive a client bootstrapping response message returned by the first SFU based on the client bootstrapping request message; The first SFU is configured to: receive the MBSS creation request message; create an MBSS based on the MBSS creation request message; return an MBSS creation success response message to the MFU based on the MBSS creation request message; receive the reference signaling; send a Basic Service Set Switching Management (BTM) request message to the STA based on the reference signaling, wherein the BTM request message carries an MBSS field; receive a BTM response message returned by the STA based on the BTM request message; and return a client bootstrapping response message to the MFU based on the BTM response message. The STA is configured to be associated with the BSS of the first SFU; receive the BTM request message sent by the first SFU; return the BTM response message to the first SFU based on the BTM request message; and switch to the MBSS of the first SFU according to the BTM request message, and be associated with the MBSS of the first SFU.

19. The system according to claim 17, wherein, The MFU is configured to detect that the STA has been in a non-roaming state for a predetermined period of time, determine that the STA needs to switch back to the BSS; send the reference signaling to the first SFU, wherein the reference signaling is a client bootstrapping request message carrying an MBSS field, the MBSS field being used to indicate that the STA's roaming destination BSS is the BSS; receive a client bootstrapping response message returned by the first SFU; send an MBSS destruction request message to the first SFU; and receive a destruction success response message returned by the first SFU based on the MBSS destruction request message. The first SFU is configured to: receive the reference signaling; send a BTM request message to the STA based on the reference signaling, wherein the BTM request message carries an MBSS field; receive a BTM response message returned by the STA based on the BTM request message; return a client bootstrapping response message to the MFU based on the BTM response message; receive the MBSS destruction request message; destroy the MBSS according to the MBSS destruction request message; and return a destruction success response message to the MFU based on the MBSS destruction request message. The STA is configured to be associated with the MBSS of the first SFU; receive the BTM request message sent by the first SFU; return the BTM response message to the first SFU based on the BTM request message; switch to the BSS of the first SFU according to the BTM request message, and associate with the BSS of the first SFU.

20. The system according to claim 17, wherein, The MFU is configured to: acquire first network status information; determine, based on the first network status information, that the STA needs to roam to the second SFU; send a wireless terminal information acquisition request message to the first SFU; receive a wireless terminal information response message returned by the first SFU based on the wireless terminal information acquisition request message, wherein the wireless terminal information response message carries a BA information field; send the reference signaling to the second SFU, wherein the reference signaling is an MBSS creation request message carrying a BA information field; receive an MBSS creation success response message returned by the second SFU based on the reference signaling; send an MBSS destruction request message to the first SFU; receive a destruction success response message returned by the first SFU based on the MBSS destruction request message; and receive STA change information sent by the second SFU. The first SFU is configured to receive the wireless terminal information acquisition request message; return the wireless terminal information response message to the MFU based on the wireless terminal information acquisition request message; receive the MBSS destruction request message; destroy the MBSS of the first SFU according to the MBSS destruction request message; return the destruction success response message to the MFU based on the MBSS destruction request message; and receive the STA change information sent by the second SFU. The second SFU is configured to receive the reference signaling; create an MBSS based on the reference signaling and synchronize BA information; create a virtual STA based on the STA to obtain and synchronize STA information; return an MBSS creation success response message to the MFU based on the reference signaling; and send the STA change information to the MFU and the first SFU respectively. The STA is configured to be associated with the MBSS of the first SFU; when switching to the MBSS of the second SFU, it is associated with the MBSS of the second SFU.

21. The system according to claim 17, wherein, The MFU is configured to: send an MLO capability acquisition request message to the first SFU; receive an MLO capability response message returned by the first SFU based on the MLO capability acquisition request message; acquire second network status information and determine, based on the second network status information, that the STA needs to roam to the second SFU; send an MLO link information acquisition request message to the first SFU; receive an MLO link information response message returned by the first SFU based on the MLO link information acquisition request message; send the reference signaling to the second SFU, wherein the reference signaling is an MBSS creation request message carrying MLO link information fields; receive an MBSS creation success response message returned by the second SFU based on the reference signaling; send an MBSS destruction request message to the first SFU; receive a destruction success response message returned by the first SFU based on the MBSS destruction request message; and receive STA change information sent by the second SFU. The first SFU is configured to: receive the MLO capability acquisition request message; return an MLO capability response message to the MFU based on the MLO capability acquisition request message; receive the MLO link information acquisition request message; return an MLO link information response message to the MFU based on the MLO link information acquisition request message; receive an MBSS destruction request message; destroy the MBSS of the first SFU according to the MBSS destruction request message; return a destruction success response message to the MFU based on the MBSS destruction request message; and receive the STA change information sent by the second SFU. The second SFU is configured to receive the reference signaling; create an MBSS based on the reference signaling, and perform BA information synchronization and TID-to-link mapping for each link of the MLO; return an MBSS creation success response message to the MFU based on the reference signaling; and send the STA change information to the MFU and the first SFU respectively. The STA is configured to be associated with the MBSS of the first SFU via MLO; when switching to the MBSS of the second SFU, it is associated with the MBSS of the second SFU via MLO.

22. The system according to claim 17, wherein, The MFU is configured to, in response to the existence of a Wireless Local Area Network Management and Control Interface (WMCI) management channel between the MFU and the first SFU or the second SFU, load the reference signaling into WMCI information and send the WMCI information to the first SFU or the second SFU.

23. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 16.

24. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the steps of the method according to any one of claims 1 to 16.

25. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1 to 16.

Images