Roaming method and device

Abstract

A roaming method and device, relating to the technical field of communications, and used for providing a processing flow between master and slave optical network units. The method comprises: an MFU determines a target SFU for a station on the basis of roaming decision information; the MFU sends a roaming start instruction message to the target SFU, wherein the roaming start instruction message is used for instructing to start roaming processing for the station.

Description

A roaming method and device

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411563236.6, filed with the State Intellectual Property Office of the People's Republic of China on November 4, 2024, entitled "A Roaming Method and Apparatus", the entire contents of which are incorporated herein by reference; this application claims priority to Chinese Patent Application No. 202411761234.8, filed with the State Intellectual Property Office of the People's Republic of China on November 29, 2024, entitled "A Roaming Method and Apparatus", the entire contents of which are incorporated herein by reference; this application claims priority to Chinese Patent Application No. 202510039268.4, filed with the State Intellectual Property Office of the People's Republic of China on January 9, 2025, entitled "A Roaming Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a roaming method and apparatus. Background Technology

[0004] When a terminal moves within an FTTR network and the channel quality deteriorates with its currently associated access point, it needs to roam to an access point with better channel quality to ensure service continuity. Currently, the processing flow between master and slave optical network units in an FTTR network has not been discussed. Summary of the Invention

[0005] This application provides a roaming method and apparatus for providing a master-slave optical network unit processing flow.

[0006] In a first aspect, an embodiment of this application provides a roaming method, comprising:

[0007] The main optical network unit (MFU) acquires roaming decision information from the system units (SFUs) in the network;

[0008] The MFU determines the target SFU for the site based on the roaming decision information;

[0009] The MFU sends a roaming start indication message to the target SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

[0010] In one possible implementation scenario, the source access point can be an MFU. In another possible implementation scenario, the source access point can be a source SFU.

[0011] In one possible design, the roaming start indication message is carried in a Wi-Fi management control interface message.

[0012] In one possible design, the roaming initiation process includes initiating a roaming switching state machine.

[0013] In one possible design, the roaming start indication message includes the identifier of the site.

[0014] In one possible design, the method further includes:

[0015] The MFU receives a roaming start confirmation message from the target SFU, which indicates that the target SFU has successfully completed roaming initiation for the site.

[0016] In one possible design, the method further includes:

[0017] The MFU receives a roaming start failure message from the target SFU, the roaming start failure message indicating that the target SFU failed to initiate roaming for the site;

[0018] The MFU removes roaming-related information for the site.

[0019] In one possible design, the method further includes:

[0020] The MFU sends a roaming start indication message to the source SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

[0021] In one possible design, the method further includes:

[0022] The MFU receives a roaming start confirmation message from the source SFU, which indicates that the source SFU has successfully completed roaming initiation for the site.

[0023] In one possible design, the method further includes:

[0024] The MFU receives a roaming start failure message from the source SFU, the roaming start failure message indicating that the source SFU failed to initiate roaming for the site;

[0025] The MFU removes roaming-related information for the site.

[0026] In one possible design, the method further includes:

[0027] The MFU sends a roaming anomaly handling message to the source SFU and the target SFU. The roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site.

[0028] In one possible design, the method further includes:

[0029] The MFU receives a roaming exception handling completion message from the source SFU; and / or,

[0030] The MFU receives the roaming exception handling completion message from the target SFU.

[0031] In one possible design, the roaming decision information includes one or more of the following: signal strength with the station, load information, or channel condition information.

[0032] On the other hand, embodiments of this application also provide a roaming method, which mainly includes:

[0033] The main optical network unit (MFU) acquires roaming decision information from at least one sub-unit (SFU) in the network;

[0034] The MFU determines the target access point for the site currently accessing the source SFU based on the roaming decision information, and the target access point is the MFU.

[0035] The MFU sends a roaming start indication message to the source SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

[0036] The roaming method provided by this invention can roam a site from the current source SFU to the target access point, i.e., MFU, so that the site can access the network at the MFU and continue its current services.

[0037] In one possible design, the MFU obtains the roaming decision information of the SFU from the roaming decision information collection and reporting messages sent by the SFU in the network.

[0038] In addition, the MFU can also obtain its own roaming decision information.

[0039] In one possible design, the roaming start indication message is carried in a Wi-Fi management control interface message.

[0040] In one possible design, after the MFU determines that the MFU is the target access point of the site based on roaming decision information, the MFU initiates roaming processing for the site.

[0041] In one possible design, the roaming initiation process includes initiating a roaming switching state machine.

[0042] In one possible design, the roaming start indication message includes the identifier of the site, facilitating the target SFU to initiate roaming processing for that site.

[0043] In one possible design, the roaming method further includes: the MFU receiving a roaming start confirmation message from the source SFU, the roaming start confirmation message indicating that the source SFU has successfully completed roaming initiation for the site. The MFU can initiate subsequent roaming procedures based on the roaming start confirmation message, such as performing roaming preprocessing.

[0044] In one possible design, roaming preprocessing includes aggregated transfers between the analog and STA.

[0045] In one possible design, roaming preprocessing includes creating users for STAs.

[0046] In one possible design, the roaming method also includes:

[0047] The MFU receives a roaming start failure message from the source SFU, which indicates that the source SFU failed to initiate roaming for the site, and the MFU clears the roaming-related information for the site.

[0048] In one possible design, the roaming method also includes:

[0049] The MFU sends a roaming exception handling message to the source SFU, the roaming exception handling message being used to instruct the clearing of roaming-related information for the site.

[0050] In one possible design, the roaming method also includes:

[0051] The MFU receives a roaming exception handling completion message from the source SFU; and / or,

[0052] The MFU receives the roaming exception handling completion message from the target SFU.

[0053] In one possible design, the roaming decision information acquired by the MFU includes one or more of the following: signal strength with the site, load information, or channel condition information.

[0054] Secondly, embodiments of this application provide a roaming method, including:

[0055] The Sub-Optical Network Unit (SFU) receives a roaming start indication message from the Main Optical Network Unit (MFU), which is used to indicate that roaming processing should be initiated for the site; the SFU is either the source SFU currently accessed by the site or the target SFU determined by the MFU for roaming of the site.

[0056] The SFU initiates roaming processing for the site.

[0057] In one possible design, the roaming start indication message is carried in a Wi-Fi management control interface message.

[0058] In one possible design, the roaming initiation process includes initiating a roaming switching state machine.

[0059] In one possible design, the roaming start indication message includes the identifier of the site.

[0060] In one possible design, the method further includes:

[0061] The SFU sends the roaming start confirmation message to the MFU, the roaming start confirmation message indicating that the SFU has successfully completed the roaming initiation for the site.

[0062] In one possible design, the method further includes:

[0063] The SFU sends a roaming start failure message to the MFU, the roaming start failure message indicating that the SFU failed to initiate roaming for the site.

[0064] In one possible design, the method further includes:

[0065] The SFU receives a roaming error handling message from the MFU, the roaming error handling message being used to instruct the clearing of roaming-related information for the site;

[0066] The SFU clears roaming-related information for the site.

[0067] In one possible design, the method further includes:

[0068] The SFU sends a roaming exception handling completion message to the MFU.

[0069] In one possible design, the method further includes:

[0070] The SFU sends roaming decision information to the MFU.

[0071] In one possible design, the roaming decision information includes one or more of the following: signal strength with the station, load information, or channel condition information.

[0072] Thirdly, embodiments of this application provide a roaming device that implements the functions described in the first aspect and the optional methods of the first aspect. The device includes at least one module for implementing the methods provided in the first aspect and the optional methods of the first aspect. In one possible design, applied to a main optical network unit (MFU), it includes:

[0073] The receiving module is used to acquire roaming decision information of SFUs in the network;

[0074] The processing module is used to determine the target SFU for the site based on the roaming decision information;

[0075] The sending module is used to send a roaming start indication message to the target SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

[0076] In one possible design, the roaming start indication message is carried in a Wi-Fi management control interface message.

[0077] In one possible design, the roaming initiation process includes initiating a roaming switching state machine.

[0078] In one possible design, the roaming start indication message includes the identifier of the site.

[0079] In one possible design, the receiving module is further configured to:

[0080] Receive a roaming start confirmation message from the target SFU, the roaming start confirmation message indicating that the target SFU has successfully completed roaming initiation for the site.

[0081] In one possible design, the receiving module is further configured to receive a roaming start failure message from the target SFU, the roaming start failure message indicating that the target SFU's roaming initiation for the site has failed;

[0082] The processing module is also used to clear roaming-related information for the site.

[0083] In one possible design, the sending module is further configured to send a roaming start indication message to the source SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

[0084] In one possible design, the receiving module is further configured to receive a roaming start confirmation message from the source SFU, the roaming start confirmation message indicating that the source SFU has successfully completed roaming initiation for the site.

[0085] In one possible design, the receiving module is further configured to receive a roaming start failure message from the source SFU, the roaming start failure message indicating that the source SFU failed to initiate roaming for the site;

[0086] The processing module is also used to clear roaming-related information for the site.

[0087] In one possible design, the sending module is further configured to send roaming exception handling messages to the source SFU and the target SFU, the roaming exception handling messages being used to instruct the clearing of roaming-related information for the site.

[0088] In one possible design, the receiving module is further configured to receive a roaming exception handling completion message from the source SFU; and / or, receive the roaming exception handling completion message from the target SFU.

[0089] In one possible design, the roaming decision information includes one or more of the following: signal strength with the station, load information, or channel condition information.

[0090] Fourthly, embodiments of this application provide a roaming device that implements the functions of the second aspect and optional methods described above. The device includes at least one module for implementing the methods provided by the second aspect and optional methods. In one possible design, applied to a sub-optical network unit (SFU), it includes:

[0091] The receiving module is used to receive a roaming start indication message from the main optical network unit (MFU), the roaming start indication message being used to instruct the initiation of roaming processing for the site; the SFU is either the source SFU currently accessed by the site or the target SFU determined by the MFU for roaming of the site.

[0092] The processing module is used to initiate roaming processing for the site.

[0093] In one possible design, the roaming start indication message is carried in a Wi-Fi management control interface message.

[0094] In one possible design, the roaming initiation process includes initiating a roaming switching state machine.

[0095] In one possible design, the roaming start indication message includes the identifier of the site.

[0096] In one possible design, the device further includes:

[0097] The SFU sends the roaming start confirmation message to the MFU, the roaming start confirmation message indicating that the SFU has successfully completed the roaming initiation for the site.

[0098] In one possible design, the device further includes:

[0099] The SFU sends a roaming start failure message to the MFU, the roaming start failure message indicating that the SFU failed to initiate roaming for the site.

[0100] In one possible design, the device further includes:

[0101] The SFU receives a roaming error handling message from the MFU, the roaming error handling message being used to instruct the clearing of roaming-related information for the site;

[0102] The SFU clears roaming-related information for the site.

[0103] In one possible design, the device further includes:

[0104] The SFU sends a roaming exception handling completion message to the MFU.

[0105] In one possible design, the device further includes:

[0106] The SFU sends roaming decision information to the MFU.

[0107] In one possible design, the roaming decision information includes one or more of the following: signal strength with the station, load information, or channel condition information.

[0108] Fifthly, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is used to execute program instructions in the memory to implement the method provided in any of the above aspects, and the communication interface is used to communicate with the SFU.

[0109] In a sixth aspect, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is used to execute program instructions in the memory to implement the methods provided in the second aspect and the optional methods of the second aspect, and the communication interface is used to communicate with an MFU.

[0110] In a seventh aspect, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in the MFU) to perform the method provided in either aspect.

[0111] Eighthly, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in the SFU) to perform the method provided in the second aspect or any alternative method of the second aspect.

[0112] Ninthly, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the MFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the MFU to perform the method provided in the first aspect or any alternative method of the first aspect.

[0113] In a tenth aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the SFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the SFU to perform the method provided in the second aspect or any alternative method of the second aspect described above.

[0114] Eleventhly, embodiments of this application provide a communication system including a source SFU, a target SFU, and an MFU. The MFU is used to perform the method described in the first aspect or any design of the first aspect. The source SFU or the target SFU is used to perform the method described in the second aspect or any design of the second aspect.

[0115] In a twelfth aspect, embodiments of this application provide a roaming method, including:

[0116] The main optical network unit (MFU) sends a roaming preprocessing message to the target SFU, the roaming preprocessing message being used to instruct the target SFU to initiate roaming preparation for the site;

[0117] The MFU receives a roaming preprocessing feedback message from the target SFU, the roaming preprocessing feedback message being used to indicate whether roaming preparation for the site was successful.

[0118] In one possible design, the roaming preprocessing message is carried in a Wi-Fi management control interface message.

[0119] In one possible design, the roaming preprocessing message includes the identifier of the site.

[0120] In one possible design, the roaming preprocessing message includes aggregation parameters used to establish an aggregation between the target SFU and the site.

[0121] In one possible design, the roaming preprocessing message includes aggregation parameters and association parameters. The aggregation parameters are used to establish an aggregation between the target SFU and the site, and the association parameters are used to establish an association between the target SFU and the site.

[0122] In one possible design, the association parameters include: the association request frame of the site and / or the key negotiated by the site with the source SFU for communication.

[0123] In one possible design, the aggregation parameters include: the size of the aggregation window and / or the aggregation strategy.

[0124] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has successfully completed roaming preparation for the site.

[0125] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has failed to roam for the site;

[0126] The method further includes:

[0127] The MFU removes roaming-related information for the site.

[0128] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has failed to roam for the site;

[0129] The method further includes:

[0130] The MFU sends a roaming anomaly handling message to the target SFU, the roaming anomaly handling message being used to instruct the clearing of roaming-related information for the site.

[0131] In one possible design, the method further includes: the MFU receiving the roaming exception handling completion message from the target SFU.

[0132] In one possible design, the method further includes:

[0133] The MFU sends the roaming exception handling message to the source SFU, where the source SFU is the SFU currently connected to the site.

[0134] In one possible design, the method further includes:

[0135] The MFU receives a roaming exception handling completion message from the source SFU.

[0136] In a thirteenth aspect, embodiments of this application provide a roaming method, including:

[0137] The target sub-optical network unit (SFU) receives a roaming preprocessing message from the main optical network unit (MFU), which instructs the target SFU to initiate roaming preparation for the site.

[0138] The target SFU sends a roaming preprocessing feedback message to the MFU, the roaming preprocessing feedback message being used to indicate whether the roaming preparation for the site was successful.

[0139] In one possible design, the roaming preprocessing message is carried in a Wi-Fi management control interface message.

[0140] In one possible design, the roaming preprocessing message includes the identifier of the site.

[0141] In one possible design, the roaming preprocessing message includes aggregation parameters used to establish an aggregation between the target SFU and the site.

[0142] In one possible design, the roaming preprocessing message includes aggregation parameters and association parameters. The aggregation parameters are used to establish an aggregation between the target SFU and the site, and the association parameters are used to establish an association between the target SFU and the site.

[0143] In one possible design, the association parameters include: the association request frame of the site and / or the key negotiated by the site with the source SFU for communication.

[0144] In one possible design, the aggregation parameters include: the size of the aggregation window and / or the aggregation strategy.

[0145] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has successfully completed roaming preparation for the site.

[0146] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has failed to roam for the site;

[0147] The method further includes:

[0148] Receive a roaming exception handling message from the MFU, the roaming exception handling message being used to instruct the clearing of roaming-related information for the site;

[0149] Clear roaming-related information for the site.

[0150] In one possible design, the method further includes:

[0151] Send a roaming exception handling completion message to the MFU.

[0152] In a fourteenth aspect, embodiments of this application provide a roaming method, including:

[0153] When the source optical network unit (SFU) has initiated roaming processing for the site, a roaming anomaly handling message is received from the main optical network unit (MFU). The roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site. The source SFU is the SFU currently accessed by the site.

[0154] Clear roaming-related information for the site.

[0155] In one possible design, the method further includes:

[0156] The source SFU sends a roaming exception handling completion message to the MFU.

[0157] In a fifteenth aspect, embodiments of this application provide a roaming device having the functionality to implement the twelfth aspect and its optional methods described above. The device includes at least one module for implementing the methods provided by the twelfth aspect and its optional methods. One possible design includes: applied to a main optical network unit (MFU), comprising:

[0158] The sending module is used to send a roaming preprocessing message to the target SFU, the roaming preprocessing message being used to instruct the target SFU to initiate roaming preparation for the site;

[0159] A receiving module is configured to receive a roaming preprocessing feedback message from the target SFU, the roaming preprocessing feedback message being used to indicate whether roaming preparation for the site was successful.

[0160] In one possible design, the roaming preprocessing message is carried in a Wi-Fi management control interface message.

[0161] In one possible design, the roaming preprocessing message includes the identifier of the site.

[0162] In one possible design, the roaming preprocessing message includes aggregation parameters used to establish an aggregation between the target SFU and the site.

[0163] In one possible design, the roaming preprocessing message includes aggregation parameters and association parameters. The aggregation parameters are used to establish an aggregation between the target SFU and the site, and the association parameters are used to establish an association between the target SFU and the site.

[0164] In one possible design, the association parameters include: the association request frame of the site and / or the key negotiated by the site with the source SFU for communication.

[0165] In one possible design, the aggregation parameters include: the size of the aggregation window and / or the aggregation strategy.

[0166] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has successfully completed roaming preparation for the site.

[0167] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has failed to roam for the site;

[0168] The device further includes:

[0169] A processing module is used to clear roaming-related information for the site.

[0170] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has failed to roam for the site;

[0171] The sending module is used to send a roaming exception handling message to the target SFU, the roaming exception handling message being used to instruct the clearing of roaming-related information for the site.

[0172] In one possible design, the receiving module is further configured to receive the roaming exception handling completion message from the target SFU.

[0173] In one possible design, the sending module is further configured to send the roaming exception handling message to the source SFU, where the source SFU is the SFU currently connected to by the site.

[0174] In one possible design, the receiving module is further configured to:

[0175] Receive a roaming exception handling completion message from the source SFU.

[0176] In a sixteenth aspect, embodiments of this application provide a roaming device having the functionality to implement the thirteenth aspect and its optional methods. The device includes at least one module for implementing the methods provided by the thirteenth aspect and its optional methods.

[0177] In one possible design, the application to the target sub-optical network unit (SFU) includes:

[0178] The receiving module is used to receive a roaming preprocessing message from the main optical network unit (MFU), wherein the roaming preprocessing message is used to instruct the target SFU to initiate roaming preparation for the site;

[0179] The sending module is used to send a roaming preprocessing feedback message to the MFU, the roaming preprocessing feedback message being used to indicate whether the roaming preparation for the site is successful.

[0180] In one possible design, the roaming preprocessing message is carried in a Wi-Fi management and control interface message.

[0181] In one possible design, the roaming preprocessing message includes the identifier of the site.

[0182] In one possible design, the roaming preprocessing message includes aggregation parameters used to establish an aggregation between the target SFU and the site.

[0183] In one possible design, the roaming preprocessing message includes aggregation parameters and association parameters. The aggregation parameters are used to establish an aggregation between the target SFU and the site, and the association parameters are used to establish an association between the target SFU and the site.

[0184] In one possible design, the association parameters include: the association request frame of the site and / or the key negotiated by the site with the source SFU for communication.

[0185] In one possible design, the aggregation parameters include: the size of the aggregation window and / or the aggregation strategy.

[0186] In one possible design, the roaming preprocessing feedback message indicates that the target SFU has successfully completed roaming preparation for the site.

[0187] In one possible design, the roaming preprocessing feedback message indicates that the target SFU's roaming preparation for the site has failed;

[0188] The receiving module is further configured to receive a roaming exception handling message from the MFU, the roaming exception handling message being used to instruct the clearing of roaming-related information for the site;

[0189] Also includes:

[0190] A processing module is used to clear roaming-related information for the site.

[0191] In one possible design, the sending module is used to send a roaming exception handling completion message to the MFU.

[0192] In a seventeenth aspect, embodiments of this application provide a roaming device that has the functionality to implement the first aspect and the optional methods described above. The device includes at least one module for implementing the methods provided by the first aspect and the optional methods described above.

[0193] In one possible design, a receiving module is included, which is used to receive a roaming anomaly handling message from a main optical network unit (MFU) when the source sub-optical network unit (SFU) has initiated roaming processing for the site. The roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site, and the source SFU is the SFU currently accessed by the site.

[0194] A processing module is used to clear roaming-related information for the site.

[0195] In one possible design, the device further includes:

[0196] The sending module is used to send a roaming exception handling completion message to the MFU.

[0197] In an eighteenth aspect, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is configured to execute program instructions in the memory to implement the methods provided in the twelfth aspect and the optional mode of the twelfth aspect, and the communication interface is configured to communicate with an SFU.

[0198] In a nineteenth aspect, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is configured to execute program instructions in the memory to implement the methods provided in the thirteenth aspect and the optional methods of the thirteenth aspect, or to implement the methods provided in the fourteenth aspect and the optional methods of the fourteenth aspect, and the communication interface is configured to communicate with an MFU.

[0199] In a twentieth aspect, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in the MFU) to perform the method provided by the twelfth aspect or any alternative method of the twelfth aspect; or, the program instruction is read by a processor to cause the processor (in the SFU) to perform the method provided by the thirteenth aspect and any alternative method of the thirteenth aspect, or to perform the method provided by the fourteenth aspect and any alternative method of the fourteenth aspect.

[0200] In a twentieth aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the MFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the MFU to perform the method provided in the twelfth aspect or any alternative method of the twelfth aspect described above.

[0201] In a twentieth aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the SFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the SFU to perform the methods provided by the thirteenth aspect and its optional embodiments, or to perform the methods provided by the fourteenth aspect and its optional embodiments.

[0202] In a twentieth aspect, embodiments of this application provide a communication system including a source SFU, a target SFU, and an MFU. The MFU is used to perform the method described in aspect 12 or any design of aspect 12. The target SFU is used to perform the method described in aspect 13 or any design of aspect 13. The source SFU is used to perform the method described in aspect 14 or any design of aspect 14.

[0203] In a twentieth aspect, embodiments of this application provide a roaming method, including:

[0204] During site roaming, the main optical network unit (MFU) sends a service shutdown instruction message to the source SFU. The service shutdown message is used to instruct the source SFU to shut down service interaction with the site.

[0205] The MFU receives a service shutdown feedback message from the source SFU, which indicates whether the service interaction with the site has been successfully shut down.

[0206] In one possible design, the service shutdown message is carried in a Wi-Fi management control interface message.

[0207] In one possible design, the service shutdown instruction message includes the site's identifier.

[0208] In one possible design, the service shutdown instruction message is also used to instruct the source SFU to report context information about the service interaction with the site.

[0209] In one possible design, the service shutdown feedback message indicates that the source SFU has successfully shut down service interaction with the site.

[0210] In one possible design, the service shutdown feedback message includes context information about the service interaction between the source SFU and the site.

[0211] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN) context, message sequence number, or site OMI status information.

[0212] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0213] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0214] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0215] The method further includes:

[0216] The MFU sends a first roaming exception handling message to the source SFU, the first roaming exception handling message being used to instruct the restoration of the configuration prior to the start of roaming for the site.

[0217] In one possible design, the method further includes:

[0218] The MFU sends the second roaming exception handling message to the target SFU. The second roaming exception handling message is used to instruct the deletion of roaming-related information of the site. The target SFU is the target SFU determined by the site roaming handover.

[0219] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0220] The method further includes:

[0221] The MFU sends a third roaming anomaly handling message to the source SFU, the third roaming anomaly handling message being used to instruct the site to be removed from the network.

[0222] In one possible design, the method further includes:

[0223] The MFU sends the third roaming exception handling message to the target SFU, where the target SFU is the target SFU determined by the site roaming handover.

[0224] In a twentieth aspect, embodiments of this application provide a roaming method, including:

[0225] During site roaming, the source sub-optical network unit (SFU) receives a service shutdown instruction message from the main optical network unit (MFU). The service shutdown message is used to instruct the source SFU to shut down service interaction with the site.

[0226] The source SFU sends a service shutdown feedback message to the MFU, which indicates whether the source SFU has successfully shut down service interaction with the site.

[0227] In one possible design, the service shutdown instruction message is carried in a Wi-Fi management control interface message.

[0228] In one possible design, the service shutdown instruction message includes the site's identifier.

[0229] In one possible design, the service shutdown instruction message is also used to instruct the source SFU to report context information about the service interaction with the site.

[0230] In one possible design, the service shutdown feedback message indicates that the source SFU has successfully shut down service interaction with the site.

[0231] In one possible design, the service shutdown feedback message includes context information about the service interaction between the source SFU and the site.

[0232] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0233] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0234] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0235] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0236] The method further includes:

[0237] The source SFU receives a first roaming error handling message from the MFU, the first roaming error handling message being used to instruct the source SFU to restore the configuration before roaming was initiated for the site;

[0238] The source SFU restores the configuration prior to the start of roaming for the site.

[0239] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0240] The method further includes:

[0241] The source SFU receives a third roaming anomaly handling message from the MFU, the third roaming anomaly handling message being used to instruct the source SFU to remove the site from the network;

[0242] The source SFU removes the site from the network.

[0243] In one possible design, the method further includes:

[0244] The source SFU sends a roaming exception handling completion message to the MFU.

[0245] In one possible design, the method further includes:

[0246] The source SFU or MFU can also delete the aggregated session that has been established locally with the STA.

[0247] In a twentieth aspect, embodiments of this application provide a roaming method, including:

[0248] When the target sub-optical network unit (SFU) has initiated roaming processing for the site, a second roaming anomaly handling message is received from the main optical network unit (MFU). The second roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site. The source SFU is the SFU currently accessed by the site.

[0249] Remove roaming-related information for the site or remove the site from the network.

[0250] In one possible design, the method further includes:

[0251] The target SFU sends a roaming exception handling completion message to the MFU.

[0252] In a twentieth aspect, embodiments of this application provide a roaming device having the functionality to implement the twenty-fourth aspect and the optional methods of the twenty-fourth aspect. The device includes at least one module for implementing the methods provided by the twenty-fourth aspect and the optional methods of the twenty-fourth aspect. One possible design includes: a sending module, configured to send a service shutdown indication message to a source SFU during roaming at a site, the service shutdown message instructing the source SFU to shut down service interaction with the site;

[0253] The receiving module is used to receive a service shutdown feedback message from the source SFU, the service shutdown feedback message being used to indicate whether the service interaction with the site has been successfully shut down.

[0254] In one possible design, the service shutdown message is carried in a Wi-Fi management control interface message.

[0255] In one possible design, the service shutdown instruction message includes the site's identifier.

[0256] In one possible design, the service shutdown instruction message is also used to instruct the source SFU to report context information about the service interaction with the site.

[0257] In one possible design, the service shutdown feedback message indicates that the source SFU has successfully shut down service interaction with the site.

[0258] In one possible design, the service shutdown feedback message includes context information about the service interaction between the source SFU and the site.

[0259] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0260] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0261] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0262] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0263] The sending module is further configured to send a first roaming exception handling message to the source SFU, the first roaming exception handling message being used to instruct the restoration of the configuration prior to the start of roaming for the site.

[0264] In one possible design, the sending module is further configured to send the second roaming exception handling message to the target SFU, the second roaming exception handling message being used to instruct the deletion of roaming-related information of the site, the target SFU being the target SFU determined by the site roaming handover.

[0265] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0266] The sending module is further configured to send a third roaming exception handling message to the source SFU, the third roaming exception handling message being used to instruct the site to be removed from the network.

[0267] In one possible design, the sending module is further configured to send the third roaming exception handling message to the target SFU, wherein the target SFU is the target SFU determined by the site roaming handover.

[0268] In a twentieth aspect, embodiments of this application provide a roaming device having the functionality to implement the twenty-fifth aspect and the optional methods of the twenty-fifth aspect. The device includes at least one module for implementing the methods provided by the twenty-fifth aspect and the optional methods of the twenty-fifth aspect. In one possible design, applied to a source sub-optical network unit (SFU), it includes:

[0269] The receiving module is used to receive a service shutdown indication message from the main optical network unit (MFU) during the roaming process of the site. The service shutdown message is used to instruct the source SFU to shut down service interaction with the site.

[0270] The sending module is used to send a service shutdown feedback message to the MFU, the service shutdown feedback message being used to indicate whether the source SFU has successfully shut down service interaction with the site.

[0271] In one possible design, the service shutdown instruction message is carried in a Wi-Fi management control interface message.

[0272] In one possible design, the service shutdown instruction message includes the site's identifier.

[0273] In one possible design, the service shutdown instruction message is also used to instruct the source SFU to report context information about the service interaction with the site.

[0274] In one possible design, the service shutdown feedback message indicates that the source SFU has successfully shut down service interaction with the site.

[0275] In one possible design, the service shutdown feedback message includes context information about the service interaction between the source SFU and the site.

[0276] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0277] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0278] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0279] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0280] The receiving module is further configured to receive a first roaming exception handling message from the MFU, the first roaming exception handling message being used to instruct the source SFU to restore the configuration before the site roaming was initiated;

[0281] Also includes:

[0282] The processing module is used to restore the configuration prior to the start of roaming for the site.

[0283] In one possible design, the service shutdown feedback message indicates that the source SFU has failed to shut down the service interaction with the site;

[0284] The receiving module is also configured to receive a third roaming exception handling message from the MFU, the third roaming exception handling message being used to instruct the source SFU to remove the site from the network;

[0285] Also includes:

[0286] A processing module for removing the site from the network.

[0287] In one possible design, the sending module is also used to send a roaming exception handling completion message to the MFU.

[0288] In a twentieth aspect, embodiments of this application provide a roaming device having the functionality to implement the twenty-sixth aspect and the optional methods of the twenty-sixth aspect described above. The device includes at least one module for implementing the methods provided by the twenty-sixth aspect and the optional methods of the twenty-sixth aspect.

[0289] In one possible design, the application to the target sub-optical network unit (SFU) includes:

[0290] The receiving module is configured to receive a second roaming anomaly handling message from the main optical network unit (MFU) when the target sub-optical network unit (SFU) has initiated roaming processing for the site. The second roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site, and the source SFU is the SFU currently accessed by the site.

[0291] A processing module is used to clear roaming-related information for the site.

[0292] In one possible design, the device further includes:

[0293] The sending module is used to send a roaming exception handling completion message to the MFU.

[0294] In a thirtieth aspect, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is configured to execute program instructions in the memory to implement the methods provided in the twenty-fourth aspect and the optional manner of the twenty-fourth aspect, and the communication interface is configured to communicate with an SFU.

[0295] In a thirty-first aspect, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is configured to execute program instructions in the memory to implement the methods provided by the twenty-fifth aspect and the optional methods of the twenty-fifth aspect, or to implement the methods provided by the fourteenth aspect and the optional methods of the fourteenth aspect, and the communication interface is configured to communicate with an MFU.

[0296] In a thirty-second aspect, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in an MFU) to perform the method provided in the twenty-fourth aspect or any alternative method of the twenty-fourth aspect.

[0297] In a thirty-third aspect, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in a SFU) to perform the method provided by the twenty-fifth aspect and the optional method of the twenty-fifth aspect, or to perform the method provided by the twenty-sixth aspect and the optional method of the twenty-sixth aspect.

[0298] In a thirty-fourth aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the MFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the MFU to perform the method provided in either the twenty-fourth aspect or any alternative method of the twenty-fourth aspect.

[0299] In a thirty-fifth aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the SFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the SFU to perform the methods provided by the twenty-fifth aspect and the optional methods of the twenty-fifth aspect, or to perform the methods provided by the twenty-sixth aspect and the optional methods of the twenty-sixth aspect.

[0300] In a thirty-sixth aspect, embodiments of this application provide a communication system including a source SFU, a target SFU, and an MFU. The MFU is used to perform the method described in or according to any design of the twenty-fourth aspect. The source SFU is used to perform the method described in or according to any design of the twenty-fifth aspect. The target SFU is used to perform the method described in or according to any design of the twenty-sixth aspect.

[0301] In a thirty-seventh aspect, embodiments of this application provide a roaming method, including:

[0302] During site roaming, the main optical network unit (MFU) sends a service activation instruction message to the target SFU. The service activation instruction message is used to instruct the target SFU to activate service interaction with the site.

[0303] The MFU receives a service activation feedback message from the target SFU, which indicates whether service interaction with the site has been successfully activated.

[0304] In one possible design, the service activation indication message is carried in a Wi-Fi management and control interface message.

[0305] In one possible design, the service activation instruction message includes the site's identifier.

[0306] In one possible design, the service activation indication message includes context information about the service interaction between the source SFU and the site.

[0307] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0308] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0309] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0310] In one possible design, the service activation feedback message indicates that the target SFU has successfully initiated service interaction with the site.

[0311] In one possible design, the service activation feedback message indicates that the service interaction between the target SFU and the site has failed.

[0312] The method further includes:

[0313] The MFU sends a first roaming exception handling message to the target SFU, the first roaming exception handling message being used to instruct the restoration of the configuration prior to the start of roaming for the site.

[0314] In one possible design, the method further includes:

[0315] The MFU receives the roaming exception handling completion message sent by the target SFU.

[0316] In one possible design, the method further includes:

[0317] The MFU sends the first roaming exception handling message to the source SFU.

[0318] In one possible design, the method further includes:

[0319] The MFU receives a roaming exception handling completion message sent by the source SFU.

[0320] In one possible design, the method further includes:

[0321] The MFU clears the roaming-related information of the site.

[0322] In one possible design, the service activation feedback message indicates that the service interaction between the target SFU and the site has failed.

[0323] The method further includes:

[0324] The MFU sends a third roaming anomaly handling message to the target SFU, the third roaming anomaly handling message being used to instruct the site to be removed from the network.

[0325] In one possible design, the method further includes:

[0326] The MFU sends the third roaming exception handling message to the source SFU, where the source SFU is the target SFU determined by the site roaming handover.

[0327] In a thirty-eighth aspect, embodiments of this application provide a roaming method, including:

[0328] During the roaming process at the site, the target sub-optical network unit (SFU) receives a service activation instruction message from the main optical network unit (MFU). The service activation instruction message is used to instruct the target SFU to activate service interaction with the site.

[0329] The target SFU sends a service activation feedback message to the MFU, which indicates whether the source SFU has successfully activated service interaction with the site.

[0330] In one possible design, the service activation indication message is carried in a Wi-Fi management and control interface message.

[0331] In one possible design, the service activation instruction message includes the site's identifier.

[0332] In one possible design, the service activation indication message includes context information about the service interaction between the source SFU and the site.

[0333] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0334] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0335] In one possible design, the context information includes the site OMI status information; the method further includes:

[0336] The target SFU interacts with the site based on the transmit / receive parameters indicated by the site's OMI status information.

[0337] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0338] In one possible design, the context information includes the site OMI status information, and the method further includes:

[0339] When the target SFU determines that the source SFU has entered the energy-saving mode according to the energy-saving mode of the SFU, it performs service interaction with the site according to the transmit and receive parameters indicated by the site OMI status information.

[0340] When the target SFU determines that the source SFU has entered the energy-saving mode based on the energy-saving mode of the SFU, it negotiates the operating mode (OM) with the site.

[0341] In one possible design, the context information includes the site OMI status information, and the method further includes:

[0342] When the target SFU determines that the energy-saving mode of the source SFU supports the current traffic volume of the target SFU, it performs service interaction with the site based on the transmit / receive parameters indicated by the site OMI status information; or,

[0343] When the target SFU determines that the energy-saving mode of the source SFU does not support the current traffic volume of the target SFU, it negotiates the Operation Mode (OM) with the site.

[0344] In one possible design, the method further includes:

[0345] Send a downlink message to the STA according to the message sequence number, or

[0346] The aggregate message is sent to the STA according to the SN context, or...

[0347] The channel bandwidth and number of streams are determined based on the site's OMI status information. This design synchronizes the site's energy-saving status to the roaming SFU by synchronizing the OMI status with the target SFU, maintaining consistency in the STA's energy-saving status and improving roaming performance.

[0348] In one possible design, the service activation feedback message indicates that the target SFU has successfully initiated service interaction with the site.

[0349] In one possible design, after receiving the service activation instruction message, the target SFU establishes an aggregation session with the STA based on the service traffic.

[0350] In one possible design, the method further includes:

[0351] The target SFU sends downlink service messages to the site.

[0352] In one possible design, the service shutdown feedback message indicates that the target SFU failed to enable service interaction with the site.

[0353] The method further includes:

[0354] The target SFU receives a first roaming exception handling message from the MFU, the first roaming exception handling message being used to indicate the restoration of the configuration before the site roaming was initiated;

[0355] The target SFU restores the configuration prior to the start of roaming for the site.

[0356] In one possible design, the method further includes:

[0357] The target SFU sends a roaming exception handling completion message to the MFU.

[0358] In one possible design, the service activation feedback message indicates that the service interaction between the target SFU and the site has failed.

[0359] The method further includes:

[0360] The target SFU receives a third roaming anomaly handling message from the MFU, the third roaming anomaly handling message being used to instruct the target SFU to remove the site from the network;

[0361] The target SFU removes the site from the network.

[0362] In a thirty-ninth aspect, embodiments of this application provide a roaming method, including:

[0363] When the source optical network unit (SFU) has initiated roaming processing for a site, a first roaming anomaly handling message is received from the main optical network unit (MFU). The first roaming anomaly handling message is used to indicate the restoration of the configuration before the roaming for the site was initiated. The target SFU is the target SFU for the site roaming handover.

[0364] Restore the configuration for the site prior to roaming initiation and remove the site from the network.

[0365] In one possible design, the method further includes:

[0366] The source SFU sends a roaming exception handling completion message to the MFU.

[0367] In a fortieth aspect, embodiments of this application provide a roaming device having the functionality to implement the thirty-seventh aspect and the optional methods of the thirty-seventh aspect. The device includes at least one module for implementing the methods provided by the thirty-seventh aspect and the optional methods of the thirty-seventh aspect. In one possible design, applied to a main optical network unit (MFU), it includes:

[0368] The sending module is used to send a service activation instruction message to the target SFU during the roaming process of the site. The service activation instruction message is used to instruct the target SFU to activate service interaction with the site.

[0369] The receiving module is used to receive a service activation feedback message from the target SFU, the service activation feedback message being used to indicate whether service interaction with the site has been successfully activated.

[0370] In one possible design, the service activation indication message is carried in a Wi-Fi management and control interface message.

[0371] In one possible design, the service activation instruction message includes the site's identifier.

[0372] In one possible design, the service activation indication message includes context information about the service interaction between the source SFU and the site.

[0373] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0374] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0375] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0376] In one possible design, the service activation feedback message indicates that the target SFU has successfully initiated service interaction with the site.

[0377] In one possible design, the service activation feedback message indicates that the service interaction between the target SFU and the site has failed.

[0378] The sending module is further configured to send a first roaming exception handling message to the target SFU, the first roaming exception handling message being used to instruct the restoration of the configuration prior to the start of roaming for the site.

[0379] In one possible design, the receiving module is also configured to receive a roaming exception handling completion message sent by the target SFU.

[0380] In one possible design, the sending module is further configured to send the first roaming exception handling message to the source SFU.

[0381] In one possible design, the receiving module is also used to receive a roaming exception handling completion message sent by the source SFU.

[0382] In one possible design, the device further includes:

[0383] The processing module is used to clear roaming-related information of the site.

[0384] In the forty-first aspect, embodiments of this application provide a roaming device having the functionality to implement the thirty-eighth aspect and the optional methods of the thirty-eighth aspect described above. The device includes at least one module for implementing the methods provided by the thirty-eighth aspect and the optional methods of the thirty-eighth aspect. In one possible design, applied to a target sub-optical network unit (SFU), it includes:

[0385] The receiving module is used to receive a service activation indication message from the main optical network unit (MFU) during the roaming process of the site. The service activation indication message is used to instruct the target SFU to activate service interaction with the site.

[0386] The sending module is used to send a service activation feedback message to the MFU, the service activation feedback message being used to indicate whether the source SFU has successfully activated service interaction with the site.

[0387] In one possible design, the service activation indication message is carried in a Wi-Fi management and control interface message.

[0388] In one possible design, the service activation instruction message includes the site's identifier.

[0389] In one possible design, the service activation indication message includes context information about the service interaction between the source SFU and the site.

[0390] In one possible design, the context information includes one or more of the following: unicast packet sequence number (PN), sequence number (SN), context, message sequence number, or site operation mode indicator (OMI) status information.

[0391] In one possible design, the site OMI status information includes one or more of the following: received spatial stream count, channel bandwidth, uplink multi-user transmission disabled, transmitted spatial-time stream count, extended distance single-user transmission disabled, recommendation to re-perform downlink multi-user multiple-input multiple-output transmission channel probing, and uplink data multi-user transmission disabled.

[0392] In one possible design, the context information includes the site OMI status information; a communication module is used to perform service interaction with the site according to the transmit / receive parameters indicated by the site OMI status information, and the communication module includes the receiving module and the sending module.

[0393] Specifically, the sending module is further configured to send data to the site according to the sending parameters indicated by the site OMI status information. The receiving module is further configured to receive data from the site according to the receiving parameters indicated by the site OMI status information.

[0394] In one possible design, the context information also includes the energy-saving mode of the source SFU.

[0395] In one possible design, the context information includes the site OMI status information, and the communication module is used to determine, based on the SFU's power-saving mode, when the source SFU enters power-saving mode, to perform service interaction with the site according to the transmit / receive parameters indicated by the site OMI status information; or...

[0396] When the source SFU enters the energy-saving mode according to the energy-saving mode of the SFU, it negotiates the operating mode (OM) with the site.

[0397] In one possible design, the context information includes the site OMI status information. The communication module, when determining that the source SFU's power-saving mode supports the target SFU's current traffic volume, interacts with the site based on the transmit / receive parameters indicated by the site OMI status information; or...

[0398] When it is determined that the energy-saving mode of the source SFU does not support the current traffic volume of the target SFU, an Operation Mode (OM) negotiation is conducted with the site.

[0399] In one possible design, the sending module is used for:

[0400] Send a downlink message to the STA according to the message sequence number, or

[0401] The aggregate message is sent to the STA according to the SN context, or...

[0402] The channel bandwidth and number of streams are determined based on the site's OMI status information. This design synchronizes the site's energy-saving status to the roaming SFU by synchronizing the OMI status with the target SFU, maintaining consistency in the STA's energy-saving status and improving roaming performance.

[0403] In one possible design, the service activation feedback message indicates that the target SFU has successfully initiated service interaction with the site.

[0404] In one possible design, the sending module is also used to send downlink service messages to the station.

[0405] In one possible design, the service shutdown feedback message indicates that the target SFU failed to enable service interaction with the site.

[0406] The receiving module is further configured to receive a first roaming exception handling message from the MFU, the first roaming exception handling message being used to indicate the restoration of the configuration before the site roaming was initiated;

[0407] Also includes:

[0408] The processing module is used to restore the configuration prior to the start of roaming for the site.

[0409] In one possible design, the sending module is also used to send a roaming exception handling completion message to the MFU.

[0410] In a forty-second aspect, embodiments of this application provide a roaming device having the functionality to implement the thirty-ninth aspect and the optional methods thereof. The device includes at least one module for implementing the methods provided by the thirty-ninth aspect and the optional methods thereof.

[0411] One possible design applied to the source-sub-optical network unit (SFU) includes:

[0412] The receiving module is configured to receive a first roaming error handling message from the main optical network unit (MFU) when the source sub-optical network unit (SFU) has initiated roaming processing for the site. The first roaming error handling message is used to indicate the restoration of the configuration before the roaming for the site was initiated.

[0413] The processing module restores the configuration for the site before roaming was initiated.

[0414] In one possible design, the device further includes:

[0415] The sending module is also used to send a roaming exception handling completion message to the MFU.

[0416] In a forty-third aspect, this application provides a roaming device, the roaming device including a processor, a memory, and a communication interface; the processor is configured to execute program instructions in the memory to implement the methods provided in the thirty-seventh aspect and the optional manner of the thirty-seventh aspect, and the communication interface is configured to communicate with an SFU.

[0417] In a forty-fourth aspect, this application provides a roaming device, the roaming device including a processor, a memory and a communication interface; the processor is configured to execute program instructions in the memory to implement the methods provided in the thirty-eighth aspect and the optional mode of the thirty-eighth aspect above, or to implement the methods provided in the thirty-ninth aspect and the optional mode of the thirty-ninth aspect above, and the communication interface is configured to communicate with an MFU.

[0418] In a forty-fifth aspect, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in an MFU) to perform the method provided in either the thirty-seventh aspect or any alternative method of the thirty-seventh aspect.

[0419] In a forty-sixth aspect, this application provides a computer-readable storage medium storing at least one program instruction that is read by a processor to cause the processor (in a SFU) to perform the method provided by the thirty-eighth aspect and the optional method of the thirty-eighth aspect, or to perform the method provided by the thirty-ninth aspect and the optional method of the thirty-ninth aspect.

[0420] In a forty-seventh aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the MFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the MFU to perform the method provided in the thirty-seventh aspect or any alternative method of the thirty-seventh aspect.

[0421] In a forty-eighth aspect, this application provides a computer program product including program instructions stored in a computer-readable storage medium. The processor of the SFU reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the SFU to perform the methods provided by the thirty-eighth aspect and its optional embodiments, or to perform the methods provided by the thirty-ninth aspect and its optional embodiments.

[0422] In a forty-ninth aspect, embodiments of this application provide a communication system including a source SFU, a target SFU, and an MFU. The MFU is used to perform the method described in or according to any design of the thirty-seventh aspect. The source SFU is used to perform the method described in or according to any design of the thirty-eighth aspect. The target SFU is used to perform the method described in or according to any design of the thirty-ninth aspect.

[0423] In some embodiments, the MFU, source SFU, and target SFU have the same Basic Service Set Identifier (BSSID). The MFU, source SFU, and target SFU also have the same Service Set Identifier (SSID).

[0424] Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description

[0425] Figure 1A is a schematic diagram of an FTTR system architecture provided in an embodiment of this application;

[0426] Figure 1B is a schematic diagram of an FTTR system architecture provided in an embodiment of this application;

[0427] Figure 1C is a schematic flowchart provided in an embodiment of this application;

[0428] Figure 2A is a schematic flowchart of the roaming method provided in an embodiment of this application;

[0429] Figure 2B is a schematic flowchart of another roaming method provided in an embodiment of this application;

[0430] Figure 2C is a schematic flowchart of another roaming method provided in an embodiment of this application;

[0431] Figure 3A is a schematic flowchart of a roaming method under abnormal state 1 provided in an embodiment of this application;

[0432] Figure 3B is a schematic flowchart of a roaming method under abnormal state 1 provided in an embodiment of this application;

[0433] Figure 4A is a schematic flowchart of a roaming method under abnormal state 1 provided in an embodiment of this application;

[0434] Figure 4B is a schematic flowchart of a roaming method under abnormal state 1 provided in an embodiment of this application;

[0435] Figure 5 is a schematic flowchart of a roaming method under abnormal state 2 provided in the embodiment of this application;

[0436] Figure 6 is a schematic flowchart of a roaming method under abnormal state 2 provided in the embodiment of this application;

[0437] Figure 7 is a schematic flowchart of a roaming method under abnormal state 3 provided in the embodiment of this application;

[0438] Figure 8 is a schematic flowchart of a roaming method under abnormal state 3 provided in the embodiment of this application;

[0439] Figure 9 is a schematic flowchart of a roaming method under abnormal state 4 provided in the embodiment of this application;

[0440] Figure 10 is a schematic flowchart of a roaming method under abnormal state 4 provided in an embodiment of this application;

[0441] Figure 11 is a schematic diagram of the roaming device structure provided in an embodiment of this application;

[0442] Figure 12 is a schematic diagram of the device structure provided in the embodiment of this application. Detailed Implementation

[0443] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0444] In the description of this application, unless otherwise stated, "multiple" refers to two or more. Additionally, " / " indicates that the related objects are in an "or" relationship; for example, A / B can represent A or B. "And / or" in this application merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. It should also be noted that, unless specifically stated, the specific description of some technical features in one embodiment can also be used to explain the corresponding technical features mentioned in other embodiments.

[0445] The importance of seamless Wi-Fi roaming lies in its ability to provide users with a continuous and uninterrupted wireless network connection, ensuring stable and reliable network connectivity in homes, offices, and public places. From a user experience perspective, seamless Wi-Fi roaming avoids network interruptions. Imagine how frustrating it would be to suddenly lose your internet connection while enjoying a smooth online video or conducting an important online meeting, forcing you to move to another room or area. Seamless Wi-Fi roaming technology intelligently senses user movement and signal strength changes, automatically switching to the optimal access point to avoid such interruptions and allow users to enjoy a consistently stable network connection.

[0446] This application provides a roaming method for seamless roaming of sites, enhancing user experience. A site can be any site using a wireless network, such as a mobile phone, tablet, computer, or smart home appliance—any terminal requiring network access. A site can also be referred to as a terminal, user equipment, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device, etc., and is not specifically limited in this application. The device type of the terminal equipment 111 can be a cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, in-vehicle device, wearable device, and user equipment in 5G or future networks, etc.

[0447] This application's embodiments can be applied to Fiber To The Room (FTTR) system scenarios. An FTTR system includes a master fiber unit (MFU) and a sub-fiber unit (SFU). The MFU and SFU are connected via optical fiber. Access points include both the MFU and SFU, which can be optical network terminals (ONTs) or optical network units (ONUs). The Chinese term for MFU can also be FTTR master device, and the English term for SFU can also be FTTR slave device or FTTR sub-device, and the English term for SFU is sub-FTTR unit. The MFU can also be called a main gateway, and the SFU can also be called a sub-gateway.

[0448] When an FTTR system is deployed, the MFU and SFU are configured to belong to the same subnet. Configuration can be manual or automatic. Alternatively, the MFU and SFU are configured with the same Basic Service Set Identifier (BSSID). BSSID is an important term in Wireless Local Area Networks (WLANs) used to identify a specific Wi-Fi network. For example, as shown in Figure 1A, an FTTR system is deployed in the same subnet, including MFU, SFU1, SFU2, and SFU3. The MFU is connected to SFU1, SFU2, and SFU3 via fiber optic cables. In some possible implementation scenarios, the MFU can be connected to SFU1, SFU2, and SFU3 via optical splitters, as shown in Figure 1A.

[0449] In one possible application scenario, the roaming handover process may include the following steps, as shown in Figures 1B and 1C: initialization, virtual initialization, information synchronization, and link switching. Figure 1B illustrates this with an example of a STA initially going online at SFU1, followed by a link switch to SFU2. As shown in Figure 1B, the WMCI-based collaborative roaming scheme mainly involves four aspects: roaming configuration information synchronization, network information synchronization, terminal online processing, and terminal roaming processing.

[0450] During the initialization process: The STA goes live by executing the scanning process, authentication process, association process, and four-way handshake process. During the initialization process, the SMF and SFU receive the STA's initialization information, and the corresponding SFU responds to the STA's request messages.

[0451] In the virtual initialization process: After the STA comes online, the MFU sends some key information about the STA to each SFU, enabling each SFU to create a virtual user for the STA. This allows the STA to virtually come online on other SFUs, meaning it retains relevant communication information with the STA but does not currently provide services to the STA. Key information may include one or more of the following: authentication request frame, AID, association request frame, or secret key (Pairwise Transient Key, abbreviated as PTK). A Pairwise Transient Key (PTK) and a Group Transient Key (GTK) are also included.

[0452] In the information synchronization process: the source SFU synchronizes the context information of the STA to the target SFU to achieve fast roaming decision-making and seamless roaming.

[0453] Link switching: After the roaming decision and context information synchronization are completed, the STA switches from the source SFU to the target SFU.

[0454] The roaming process provided in this application embodiment is a switch from a source access point to a target access point. In one implementation scenario, the source access point can be an MFU (Multi-Functional Unit), and the target access point is a target SFU (Single-Functional Unit). In another implementation scenario, the source access point can be a source SFU, and the target access point is a target SFU. The target access point can also be called the destination access point, and the target SFU can also be called the destination SFU. The following description uses roaming from a source SFU to a target SFU as an example; other implementation scenarios can be referred to accordingly, and will not be described in detail.

[0455] The following is an exemplary description of the format of the roaming handover indication and reporting message involved in the embodiments of this application. See Tables 0-1 and 1-1.

[0456] Each roaming handover indication and reporting message has different parameters, which can be indicated by a mask. The roaming handover messages include sequence numbers 2-5 and 7-8; the roaming handover completion status reporting messages include sequence numbers 2-8; the roaming handover exception handling messages include sequence numbers 2-5 and 7-8; and the roaming handover exception handling status reporting messages include sequence numbers 2-6. Table 1-1 is only an example; the message types or message states corresponding to different values ​​can be configured according to requirements, and this application embodiment does not limit this.

[0457] Table 0-1

[0458] Table 1-1

[0459] The following describes the roaming method flow in the embodiments of this application, as shown in Figure 2A.

[0460] S201, the source SFU detects a roaming trigger event of the STA and sends the roaming trigger event of the STA to the MFU.

[0461] Roaming trigger events can include the STA's signal strength falling below the roaming threshold.

[0462] The source SFU periodically determines the signal strength of the STA. For example, the source SFU periodically sends beacon frames to the STA. Upon receiving the beacon frame, the STA sends a reply signal to the source SFU. The source SFU determines the received signal strength indication (RSSI) of this reply signal, which is the signal strength. The source SFU compares this signal strength with a roaming threshold. If the signal strength is determined to be below the roaming threshold, the source SFU reports the trigger event to the MFU. For example, as the STA moves away from the source SFU, the signal gradually weakens until it falls below the roaming threshold. If the signal strength is determined to be at least as high as the roaming threshold, the source SFU continues to monitor the STA's signal strength. In one possible implementation, the roaming threshold can be manually configured or intelligently configured. The roaming threshold can also be configured by the MFU to the source SFU.

[0463] Optionally, the roaming threshold can be different in different deployment scenarios. For example, a first roaming threshold can be configured in scenarios with dense access point coverage, and a second roaming threshold can be configured in scenarios with sparse access point coverage, with the first roaming threshold being larger than the second. In dense coverage scenarios, because the distance between access points is small, setting the roaming threshold too low would result in roaming occurring even after a short distance, leading to frequent roaming. To conserve roaming management resources, the roaming threshold is configured higher. Conversely, in sparse coverage scenarios, because the distance between access points is large, a greater distance is required to enter the coverage area of ​​an access point with stronger signal strength. Therefore, the roaming threshold is configured lower.

[0464] In one possible implementation, the source SFU can carry the triggering event in a Wi-Fi Management and Control Interface (WMCI) message.

[0465] WMCI is the interface between the MFU and SFU for implementing WLAN control and other functions. The WMCI management channel is a low-latency channel in the FTTR network that enables WLAN control and other functions between the MFU and SFU. It carries WMCI messages via a unique FEM port-ID. The WMCI management channel is also called the Wi-Fi Management and Control Channel (WMCC). WMCI messages are encapsulated in FEM frames and used to manage and control the WLAN functions of the SFU. The FTTR transceiver can identify the destination of the WMCI message using the FEM port ID in the FEM frame.

[0466] See Table 1-2 for the WMCI message encapsulation format.

[0467] Table 1-2

[0468] The message type is an 8-bit field that indicates the type of message and defines the semantics of the message content. When the MFU receives an upstream message with a message type ID indicating that it is unsupported, the MFU ignores the message. When the SFU receives a message with a reserved or unsupported message type ID, it ignores the message.

[0469] The sequence number is an 8-bit field containing a sequence number counter to ensure the robustness of the WMCI message channel. In the downlink direction, the sequence number field is populated with the corresponding MFU sequence number counter value. The MFU maintains a separate sequence number counter for each SFU unicast and broadcast WMCI message stream. Each sequence number counter rolls from 255 to 1. A value of 0 is not used in the downlink direction. In the uplink direction, when an uplink WMCI message is a response to a downlink message, the value of the sequence number field is equal to the value of the sequence number field in the downlink message. If the WMCI message is initiated by the SFU, sequence number = 0 is used.

[0470] Message length and priority are 2-byte fields, representing the number of bytes in the message content and the message processing requirements. X (the most significant bit of the third byte): Indicates the priority of processing this message. When X=1, the message has high priority; X=0 indicates low priority. LL LLLL LLLL: This field represents the length of the message content. The value range is 0 to 1023. O: Indicates the operation type of the current message. In the downlink direction, when O=1, it indicates that the operation type of this message is a parameter request, requesting the SFU to send the output indicated by the Message type ID field; when O=0, it indicates that the message is a parameter configuration message, with the Message type ID field indicating the parameter type configured in this message. In the uplink direction, when O=1, it indicates that the operation type of this message is a scheduling request, requesting the MFU to send the scheduling configuration indicated by the Message type ID field; when O=0, it indicates that the message is a parameter reporting message, with the Message type ID field indicating the parameter type configured in this message.

[0471] The format of the message content field is related to the specific message. The message content includes two parts: the message mask and the parameter content.

[0472] The message mask consists of a 16-bit mask, as shown in Table 1-3.

[0473] Table 1-3

[0474] Each message type can carry 16 parameters. Please refer to the message definition for a detailed explanation of the parameter sequence.

[0475] The message content should be filled in according to the order indicated by the parameter mask. For downlink request messages, the parameter mask represents the parameters that the MFU wants to obtain. For uplink messages, the parameter mask represents the parameters reported and replied to.

[0476] Message verification can employ Cyclic Redundancy Check (CRC). The message verification field, also known as the CRC field, is used to verify whether the message has been corrupted during transmission; its value is generated by the CRC algorithm.

[0477] The messages involved in Table 0-1 or 1-1 can be carried within WMCI messages, such as in the content fields of the WMCI message. In some embodiments, the WMCI message includes the identifier of the access point (such as AP ID or AP index). In one approach, the access point identifier (such as AP ID or AP index) is carried in the message header of the WMCI message. In another approach, the access point identifier (such as AP ID or AP index) is carried in the content fields of the WMCI message, such as in the messages involved in Table 0-1 or 1-1, that is, an AP ID field can be added to Table 0-1 or 1-1.

[0478] For example, the source SFU can carry the triggering event in the message content field of the WMCI message.

[0479] S202, the MFU sends a roaming decision information collection request to multiple SFUs within the network. The roaming decision information collection request instructs the SFUs to collect roaming decision information and report it to the MFU.

[0480] In one possible example, multiple SFUs within a network can include all SFUs within the network. In another possible embodiment, SFUs in the network can be configured into groups; for example, several adjacent SFUs may belong to the same group. Of course, other grouping methods are also applicable to this application, and this application does not limit them. Multiple SFUs within a network can be SFUs within a certain group; for example, the group containing the multiple SFUs may include the source SFU.

[0481] The roaming decision information collection request can also be referred to as roaming decision information collection. This application does not limit the naming method.

[0482] For example, the MFU can carry roaming decision information reporting requests in a WMCI message, such as in the message content field of the WMCI message.

[0483] Furthermore, multiple SFUs respectively perform roaming decision information collection. Roaming decision information may include one or more of the following: RSSI, load information, or channel condition information. Roaming decision information may also be called roaming auxiliary decision information, or may use other names, which are not limited in this embodiment.

[0484] It can be understood that load information represents the busyness of the Wi-Fi channel of the SFU. Higher load indicates a busier Wi-Fi channel and lower communication performance; lower load indicates a less busy Wi-Fi channel and higher communication performance. For example, load information can be the number of sites connected to the SFU. For example, load information can include the number of sites connected to the SFU and the site type. Different site types correspond to different load weights. The correspondence between site type and load weight can be preset. For example, the load weight for the mobile phone site type is 1; the load weight for the VR device site type is 2; and the load weight for the smart refrigerator site type is 0.2. Therefore, the MFU can determine the load of the SFU based on the SFU's load information. For example, when the load information is the number of sites, more sites indicate a larger SFU load. For example, when the load information includes the number of sites and the site type, the number of sites of the same type can be multiplied by the load weight corresponding to that type to obtain the weighted load. Then, the weighted loads of each site type are added together, and the sum can be used to represent the SFU load.

[0485] Channel condition information may include signal to interference plus noise ratio (SINR) and / or packet loss rate.

[0486] As an example, the roaming decision information collection message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 1-4 for example.

[0487] Table 1-4

[0488] The Payload field can carry the parameters that the SFU needs to report. In some possible implementation scenarios, default or protocol-defined parameters can be used for reporting. In this case, it is not necessary to indicate the parameters that the SFU needs to report. In this case, a set sequence can be added to Payload and PayloadLen, such as all zeros, or these two fields can be omitted.

[0489] S203, multiple SFUs send roaming decision information to the MFU respectively.

[0490] For example, each SFU sends a roaming decision information collection and reporting message to the MFU. For instance, the roaming decision information collection and reporting message sent by the target SFU carries the roaming decision information collected by the target SFU. The roaming decision information collection and reporting message can be called a roaming decision information reporting message, or other naming conventions can be used; this application embodiment does not limit this.

[0491] S204, based on roaming decision information, the MFU selects the target SFU to be handed over (or accessed). The source SFU can be called the source SFU, and the target SFU can be called the target SFU or destination SFU. An aggregation session has been established between SFU1 and STA.

[0492] In one possible example, the roaming decision information sent by the SFU to the MFU includes the RSSI of the Wi-Fi signal received by the SFU from the STA. Specifically, the SFU can measure the RSSI of the Wi-Fi signal it receives from the STA. It can be understood that RSSI reflects the communication performance of the channel or link; the higher the RSSI, the higher the communication performance. The MFU can select the SFU with the highest RSSI among multiple SFUs as the target SFU.

[0493] In another possible example, the roaming decision information sent by the SFU to the MFU includes the load information of the SFU. The MFU can select the SFU with the lowest load among multiple SFUs as the target SFU.

[0494] In another possible example, the roaming decision information sent by the SFU to the MFU includes the SFU's channel condition information. Specifically, the SFU can measure the channel conditions for its communication with the STA to obtain channel condition information. The MFU can select the SFU with the best channel conditions among multiple SFUs as the target SFU. For example, it can select the SFU with the highest SINR as the target SFU, or the SFU with the lowest packet loss rate as the target SFU, or the SFU with the highest SINR among SFUs with packet loss rates below a certain threshold as the second SFU, or SINR and packet loss rate can be weighted differently, and the SFU with the largest weighted value can be selected as the target SFU.

[0495] In another possible example, the roaming decision information sent by the SFU to the MFU includes the SFU's load information and RSSI. For instance, the SFU can select the SFU with an RSSI greater than a certain threshold and the lowest current load as the target SFU. Alternatively, the MFU can weight the RSSIs of multiple SFUs with their load values ​​and determine the SFU with the highest weighted value as the target SFU.

[0496] In another possible example, the roaming decision information sent by the SFU to the MFU includes RSSI, load information, and channel condition information. The MFU can select the target SFU by using a weighted calculation method. For example, RSSI, load, SINR (and / or packet loss rate) each correspond to different weights, and the target SFU is determined by calculating the weights.

[0497] It should be understood that there are other combinations of the above roaming decision information. Therefore, the MFU can select the optimal SFU as the target SFU based on different combinations, which will not be listed here.

[0498] In some possible implementations, after selecting the target SFU, the MFU initiates the roaming process. Initiating the roaming process can involve starting a state machine. The state machine describes the states of the roaming handover. For example, the roaming handover states include: the roaming processing state and the roaming reporting state.

[0499] As an example, the roaming decision information collection and reporting message may include fields numbered 2-8 in Table 1-1, as shown in Table 1-5 for example.

[0500] Table 1-5

[0501] Table 1-6

[0502] The unit of load is bps, and the value range can be 1 to 2^40bps, where 2^40bps is approximately equal to 1Tbps.

[0503] The Payload field can carry the parameters that the SFU needs to report. In some possible implementation scenarios, default or protocol-defined parameters can be used for reporting. In this case, it is not necessary to indicate the parameters that the SFU needs to report. In this case, a set sequence can be added to Payload and PayloadLen, such as all zeros, or these two fields can be omitted.

[0504] The load field mentioned above can be the total uplink or downlink traffic on the SFU, for example, in bytes per second.

[0505] In addition to the RSSI and load information parameters mentioned above, a third parameter can be included, namely the channel occupancy parameter. This parameter occupies 1 byte and is used to represent the occupancy rate (percentage unit) of the transmit and receive channels on the SFU.

[0506] In addition to the three parameters mentioned above—RSSI, load information, and channel occupancy rate—a fourth parameter can be included: the number of packets buffered. This parameter occupies 4 bytes and is used to represent the number of packets buffered on the SFU (in bytes or bits).

[0507] Among them, the SFU can report the values ​​of some (e.g., one) of the four fields mentioned above: RSSI, load information, channel occupancy rate, and number of buffered packets. It can also report the values ​​of all parameters.

[0508] If the SFU successfully completes the roaming decision information collection, it can reply with a roaming decision information reporting confirmation message, i.e., Status = 0 for sequence number 6. Otherwise, it replies with a roaming decision information reporting failure message, i.e., Status = 1.

[0509] S205, the MFU sends a roaming start instruction message to both the source SFU and the target SFU.

[0510] In some embodiments, after the MFU selects the target SFU, it caches the downlink packets of the site and stops sending downlink packets to the source SFU, thereby initiating roaming processing, i.e., executing S205.

[0511] The roaming start indication message may also be called the roaming start message or other names, and this application embodiment does not limit this.

[0512] After receiving the roaming start indication message, the source SFU and the target SFU respectively start roaming, such as starting their own roaming switching state machine.

[0513] As an example, the roaming start indication message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 2.

[0514] Table 2

[0515] In Table 2, Payload and PayloadLen can have specified sequences added, such as all zeros, or these two fields can be excluded.

[0516] S206, the source SFU sends a roaming start confirmation message to the MFU. For example, after the source SFU completes its own roaming handover state machine startup, it sends a roaming start confirmation message to the MFU.

[0517] The roaming start confirmation message can also be named in other ways, such as roaming start successful message. This application embodiment does not limit this.

[0518] If the source SFU fails to initiate roaming processing, it will send a roaming start failure message to the MFU. Roaming start confirmation messages and roaming start failure messages can be collectively referred to as roaming start feedback messages. The roaming start feedback message indicates whether roaming initiation was successful. If it indicates success, it can be called a roaming start confirmation message; if it indicates failure, it can be called a roaming start failure message. The circumstances surrounding roaming initiation failure will be described in detail later and will not be repeated here.

[0519] As an example, the roaming start confirmation message may include fields numbered 2-8 in Table 1-1, as shown in Table 3.

[0520] Table 3

[0521] In Table 3, Payload and PayloadLen can have specified sequences added, such as all zeros, or these two fields can be excluded.

[0522] In Table 3, Status = 0 corresponds to the roaming start confirmation message.

[0523] S207, the target SFU sends a roaming start confirmation message to the MFU. For example, after the target SFU completes its own roaming handover state machine startup, it sends a roaming start confirmation message to the MFU.

[0524] In step S208, after receiving roaming start confirmation messages from both the source SFU and the target SFU, the MFU sends a roaming preprocessing instruction to the target SFU. The roaming preprocessing instruction instructs the target SFU to complete preparations before roaming handover. The roaming preprocessing instruction message instructs the target SFU to perform roaming preparations for the STA.

[0525] Roaming preprocessing instructions, also known as roaming preprocessing messages, or other names are not limited to in this application.

[0526] When the target SFU receives the roaming preprocessing instruction message, it performs roaming preprocessing for the STA, or in other words, performs roaming preparation for the STA, and generates preprocessing information.

[0527] In one possible example, the preparation work involves simulating aggregation.

[0528] It should be noted that, to improve air interface transmission efficiency, aggregated transmission is performed between the access point (AP) and the STA. First, an aggregated session is established between the AP and the STA. Then, aggregated transmission occurs between the AP and the STA. For example, after receiving an aggregated frame from the STA, the AP can respond using a block acknowledge (BA) frame.

[0529] Simulated aggregation can be understood as the aggregation transmission between the simulation and the STA.

[0530] For example, the roaming preprocessing instruction includes parameters used to simulate aggregation. These could be aggregation parameters used to implement aggregated transmission with the STA, or aggregated frames. These parameters, or roaming preprocessing context information, can also be used to simulate aggregation.

[0531] As an example, the aggregation parameters are shown in Table 4-1 or Table 4-2. Table 4-1 or Table 4-2 can be applied to aggregation scenarios. The parameters in the table below can be partially or fully included as needed.

[0532] Table 4-1

[0533] Table 4-2

[0534] In one possible implementation, the Key field may also include an encryption mode.

[0535] In some possible implementations, the aggregated information may also include the content of at least one field from Table 4-3 below. The parameters in the table below may carry some or all of the information as needed.

[0536] Table 4-3

[0537] Here, dialog token is the session token. GCR group address element is the retransmittable multicast group address element. Multi-band indicates multiple frequency bands. TCLAS represents traffic classification. ADDBA (Add Block Acknowledgment) extension is the add block acknowledgment extension.

[0538] The ADDBA response frame format specified in the protocol has a total of 0 to 7 Tids. Among them, the optional parameters have not appeared in real-world scenarios. The three elements GCR Group address, Multi-band, and TCLAS are shown in Table 4-3.

[0539] In some possible implementations, the aggregation information may include downlink aggregation parameters + ADDBA response frames. For example, the frame format of downlink aggregation parameters + ADDBA response is shown in Table 4-4. The parameters in the table below may be carried in part or in full as needed.

[0540] Table 4-4

[0541] Among them, A-MSDU (Aggregate MAC Service Data Unit) is the aggregated MAC service data unit.

[0542] In another possible example, the preparation work includes: creating users for STA and simulating aggregation.

[0543] For example, the roaming preprocessing instruction includes one or more of the following communication information: the STA's AID, an authentication request frame from the STA, an association (or reassociation) request frame from the STA, or a key used for communication between the STA and the source SFU. Further, the target SFU creates a user for the STA based on the communication information in the roaming preprocessing instruction. The target SFU also performs simulated aggregation.

[0544] In one possible implementation scenario, the destination SFU has already established an association with the user. In this case, the parameters passed in the roaming preprocessing are aggregation parameters, and the destination SFU establishes an aggregation with the STA through the aggregation parameters passed by the MFU. For example, the roaming preprocessing instruction message carries the aggregation parameters of the aggregation session received from the source SFU.

[0545] In another possible implementation scenario, if the destination SFU has not yet established an association with the user, the parameters passed by the roaming preprocessing are association parameters and aggregation information. The destination SFU establishes an association and aggregation relationship with the terminal through the association and aggregation information passed by the MFU.

[0546] The association parameters include the site's association request frame and / or the key negotiated between the site and the source SFU for communication. The association parameters may also include the site's authentication request frame.

[0547] In some possible implementation scenarios, the creation of users for the STA by the target SFU can be completed during the STA go-live phase.

[0548] As an example, the roaming preprocessing instruction message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 5.

[0549] Table 5

[0550] S209, the target SFU sends a roaming preprocessing completion message to the MFU. For example, after completing the above preparations, the target SFU sends a roaming preprocessing completion message to the MFU. The MFU then receives the roaming preprocessing completion message from the target SFU.

[0551] In the event of a roaming preprocessing failure, the target SFU will send a roaming preprocessing failure message to the MFU. Roaming preprocessing completion messages and roaming preprocessing failure messages can be collectively referred to as roaming preprocessing feedback messages. The roaming preprocessing feedback message indicates whether roaming preprocessing was successful. If it indicates success, it can be called a roaming preprocessing completion message; if it indicates failure, it can be called a roaming preprocessing failure message. The circumstances surrounding roaming preprocessing failure will be described in detail later and will not be repeated here.

[0552] As an example, roaming preprocessing feedback messages may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 6.

[0553] Table 6

[0554] In Table 6, Payload and PayloadLen can have specified sequences added, such as all zeros, or these two fields can be excluded.

[0555] In Table 6, Status = 0 corresponds to a roaming preprocessing completion (or confirmation) message. Status = 1-255 corresponds to a roaming preprocessing failure message.

[0556] S210, the MFU sends a service shutdown indication message to the source SFU. This service shutdown indication message can also be called a service shutdown indication message, or any other name; this embodiment does not limit its usage. The service shutdown indication message is used to instruct the source SFU to shut down service interaction with the STA.

[0557] In addition, after receiving a service shutdown instruction message, the source SFU can also delete the local aggregation session (or aggregation for short) that has been established with the STA. The source SFU can also send an aggregation deletion message to the STA, which instructs the STA to delete the established aggregation session (or aggregation for short). After the source SFU deletes the STA's aggregation, it shuts down the STA's service.

[0558] As an example, a service shutdown instruction message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 7-1 or Table 7-2.

[0559] Table 7-1

[0560] The Payload field can carry the parameters that the SFU needs to report. In some possible implementation scenarios, default or protocol-defined parameters can be used for reporting. In this case, it is not necessary to indicate the parameters that the SFU needs to report. In this case, a set sequence can be added to Payload and PayloadLen, such as all zeros, or these two fields can be omitted.

[0561] Table 7-2

[0562] S211, the source SFU sends a service shutdown completion message to the MFU.

[0563] In the event of a service shutdown failure, the source SFU will send a service shutdown failure message to the MFU. Service shutdown completion messages and service shutdown failure messages can be collectively referred to as service shutdown feedback messages. The service shutdown feedback message indicates whether the service shutdown was successful. If it indicates success, it can be called a service shutdown completion message; if it indicates failure, it can be called a service shutdown failure message. The circumstances of service shutdown failure will be described in detail later and will not be repeated here.

[0564] As an example, the service closure completion message may include fields numbered 2-8 in Table 1-1, as shown in Table 8.

[0565] Table 8

[0566] In Table 8, Status = 0 corresponds to a service closure completion (or confirmation) message. Status = 1-255 corresponds to a service closure failure message.

[0567] After the source SFU successfully shuts down the service, it retrieves the parameters that need to be synchronized. The service shutdown completion message includes these parameters. These parameters include context information about the service interaction between the source SFU and the STA, such as the sequence numbers of the aggregate frames to be transmitted between the source SFU and the STA, and the sequence numbers of each data packet in the block acknowledgment. For example, the context information that needs to be synchronized may include one or more of the following: PN number, SN context, IPID, or site OMI status information. The site OMI status information may include one or more of the following: receiver number of spatial streams (Rx NSS), channel width (CW), uplink multi-user transmission disabled (UL MU disable), transmit number of spatial streams and time streams (Tx NSTS), extended range single user transmission disabled (ER SU disable), recommendation to resound downlink multi-user multiple-input multiple-output transmission (DL MU-MIMO resound recommendation), and uplink data multi-user transmission disabled (UL MU Data disable).

[0568] As an example, the parameters (context information) that need to be synchronized can be found in Table 9-1.

[0569] Table 9-1

[0570] The information in sequence number 4 is optional. In some implementation scenarios, the key does not need to be updated, and the context information may include the fields in sequences 1-3.

[0571] In addition, Table 9-1 may include a hibernation status field, which contains the hibernation status of the STA (hibernating or not hibernating).

[0572] Here, "key replay" indicates key reloading, and "rep replay counter" is a counter in the Extended Authentication Protocol over LAN (EAPOL) frame. The "Key replay counter__used" indicates the number of EAPOL-Key messages sent by the access point; this field increments by 1 for each EAPOL-Key message sent to prevent replay attacks. At the start of key negotiation, this field is 0 in the EAPOL-Key message sent by the AP. When the client receives the EAPOL-Key message, it records this value locally. When the client receives another EAPOL-Key message from the AP, this field must be greater than the locally recorded value; otherwise, the message is discarded and retransmitted. When the AP receives a message from the client, this field must match the value stored locally; otherwise, it waits for retransmission until a valid Key replay counter is received. If the maximum number of retransmissions is reached, the AP will delete the client.

[0573] As another example, the parameters (context information) that need to be synchronized can be found in Table 9-2. Some or all of the parameters in the table below can be carried as needed.

[0574] Table 9-2

[0575] Channel bandwidth indicates the channel bandwidth of the Physical Layer Protocol Data Units (PPDUs) that the OM initiator supports transmitting or receiving (bandwidth is indicated uniformly for both transmission and reception). Received space-time stream count indicates the number of space-time streams of received PPDUs supported by the OM initiator; this value is less than or equal to its maximum supported space-time stream count. In other words, the received space-time stream count is a limitation when the initiator acts as the receiver of data transmission, and it also limits the number of space-time streams of data transmitted by the sender on the other side; it cannot exceed the capacity of this received space-time stream count limit. Transmitted space-time stream count indicates the number of space-time streams of transmitted PPDUs supported by the OM initiator.

[0576] In other words, the number of space-time streams sent is a limitation imposed on the initiating end when it acts as the sender in the data transmission process. During data transmission, it cannot exceed the capacity limit set by the number of space-time streams sent.

[0577] As another example, the parameters (context information) that need to be synchronized can be found in Table 9-3. Some or all of the parameters in the table below can be carried as needed.

[0578] Table 9-3

[0579] The core concept of Spatial Multiplexing Power Save (SM Power Save) lies in controlling antenna usage strategies. In scenarios requiring energy conservation, the STA can adjust the number of operating antennas, such as switching from dual-stream to single-stream, or completely shutting down some antennas to reduce the energy consumption of wireless transmission. However, since the 802.11 protocol focuses more on the interaction between the STA and the AP, the requirements for uplink transmission and downlink reception are different.

[0580] During uplink transmission, the STA can independently decide how many antennas to use and indicate the number of spatial streams via peamble. Downlink reception can be negotiated with the AP to avoid the station being unable to receive data due to the AP sending multiple streams. Therefore, the station can inform the AP of the status of its own antennas in advance to coordinate reception behavior.

[0581] SMPS enabled: In a WIFI network, before enabling SM Power Save, you can check the AP's beacon frame, such as the HT Capability field, to determine whether the network supports SMPS. Once the network supports it, the site will negotiate the working mode with the AP through the action frame.

[0582] SM Power Save has two operating modes: static mode and dynamic mode. Static mode is a simple on / off mode. Once enabled, the site will default to SM power saving mode, using single-stream reception by default. Full antenna operation will only resume when this mode is explicitly disabled. Static mode is similar to 802.11 OMI technology, but the functional scenarios and parameter settings differ.

[0583] Dynamic SM Power Save is more flexible. By default, the site maintains single-stream reception. When the AP needs multi-stream transmission, it triggers this via Request To Send / Clear To Send (RTS / CTS), temporarily activating all antennas to receive multi-stream data. During this process, the RTS and CTS may not require multi-stream transmission but rather single-stream acknowledgment, as the protocol does not explicitly require it. In dynamic mode, after receiving an RTS, the site triggers multi-stream reception via a single-stream RTS frame and acknowledges it with a single-stream CTS. After receiving data, the site provides feedback via a single-stream ACK, and then reverts to single-stream reception. This dynamic mode switching ensures high energy efficiency while maintaining data transmission accuracy.

[0584] Specifically, the site status information in Tables 9-2 or 9-3 above may include the operating mode indication (OMI). The OMI status of the STA is used by the destination SFU to determine the bandwidth of the STA and the number of spatial flows of the STA.

[0585] The STA OMI status parameter can be 2 bytes long, and its values ​​can be:

[0586] Bit0~Bit2 Rx NSS (represents the number of receiving spatial streams);

[0587] Bit3 to Bit5 represent the channel width (representing the channel bandwidth). The specific values ​​for the channel bandwidth can be:

[0588] 0:20MHZ 1:40MHZ 2:80MHZ 3:160MHZ 4:80+80MHZ 5:320MHZ

[0589] Bit6 UL MU Disable, uplink multi-user (MU) is off;

[0590] Bit7~Bit9 Tx NSTS, Number of transmitting spatial streams;

[0591] Bit10 ER-SU Disable, Extended Range Single User (ER-SU) is disabled;

[0592] Bit11 DL MU-MIMO Resound Recommendation (Downlink Multi-User Multiple-Input Multiple-Output Resound Recommendation);

[0593] Specific values ​​can be: 0, not recommended; 1, instructing the SFU to re-probe the channel or increase the channel probing frequency.

[0594] Bit12 UL MU Data Disable: Uplink multi-user data is disabled, and uplink multi-user data cannot coexist with other STAs.

[0595] The specific values ​​can be: 0, off; 1, on.

[0596] The aggregation status indicates that the aggregation session between the source SFU and STA has been successfully deleted.

[0597] In step S212, the MFU sends a service activation instruction message to the target SFU. This message can also be simply called the service activation message. It instructs the target SFU to initiate service interaction with the STA. The service activation instruction includes configuration parameters, such as context information, that need to be synchronized.

[0598] The service activation instruction message, also known simply as the service activation message, may be used under other names, but this application embodiment does not specifically limit it.

[0599] Since the source SFU sent a delete aggregation message to the STA in step S210, the STA has deleted the aggregation session. To restart the aggregation session and improve service transmission efficiency, the target SFU, upon receiving the service activation instruction message, can establish an aggregation session with the STA based on service traffic. For example, the target SFU sends an Add Block ACK (ADDBA) request frame to the STA to request the establishment of an aggregation session (hereinafter referred to as aggregation). Subsequently, the STA can send an ADDBA response frame to the target SFU. The target SFU and STA can establish a downlink aggregation session by exchanging ADDBA request and response frames. Then, the target SFU can send an aggregation service frame (hereinafter referred to as an aggregation frame) to the STA, which includes service traffic. Correspondingly, the STA can send an Add Block ACK (ADDBA) request frame to the target SFU to request the establishment of an aggregation session. Subsequently, the target SFU can send an ADDBA response frame to the STA. The target SFU and STA can establish an uplink aggregation session by exchanging ADDBA request and response frames. Subsequently, the STA can send an uplink aggregation service frame (referred to as an aggregation frame) to the target SFU, which includes service traffic.

[0600] In another possible scenario, instead of sending a delete aggregation message to the STA after receiving a service shutdown instruction message, the target SFU sends the delete aggregation message to the STA after receiving a service startup instruction message. The STA then deletes the previous aggregation session based on this message. After the previous aggregation session is deleted, the target SFU can begin establishing an aggregation session with the STA, the specific establishment process of which is described above and will not be repeated here.

[0601] In addition, the value of the session token field in the ADDBA request frame is the same as the value of the session token field in the ADDBA response frame, indicating that the ADDBA response frame is a response to the ADDBA request frame.

[0602] Furthermore, aggregation sessions can be established between the target SFU and STA at the TID level. For example, under each TID, the target SFU and STA can establish corresponding uplink aggregation sessions and / or downlink aggregation sessions. For different TIDs, different uplink aggregation sessions and / or downlink aggregation sessions can be established between the target SFU and STA.

[0603] As an example, the service activation instruction message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 10.

[0604] Table 10

[0605] In another possible scenario, after receiving the service activation instruction message, the target SFU can send a Block Acknowledgment (BA) request to the STA to request the STA to adjust the Start Sequence Number (SSN) in the BA frame. The BA request can carry the new SSN to facilitate the adjustment of the SSN in the BA frame.

[0606] S213, the target SFU receives the service activation instruction message and sends a service activation completion message to the MFU. After receiving the service activation instruction, the target SFU starts service interaction with the STA according to the parameters to be synchronized, and sends a service activation completion message to the MFU.

[0607] If the target SFU fails to initiate the service, it will send a service initiation failure message to the MFU. Service initiation success messages and service initiation failure messages can be collectively referred to as service initiation feedback messages. The service initiation feedback message indicates whether the service initiation was successful. If it indicates success, it can be called a service initiation success message; if it indicates failure, it can be called a service initiation failure message. The circumstances of service initiation failure will be described in detail later and will not be repeated here.

[0608] As an example, the service closure completion message may include fields numbered 2-8 in Table 1-1, as shown in Table 11.

[0609] Table 11

[0610] In Table 11, Status = 0 corresponds to a service activation completion (or confirmation) message. Status = 1-255 corresponds to a service activation failure message.

[0611] In some possible implementations, the context information and aggregation parameters can also be sent to the target SFU in a single message. For example, in a service activation message.

[0612] In some embodiments, roaming ends after the MFU receives a service activation completion message from the target SFU. In other embodiments, the MFU can also send cached downlink packets to the target SFU, allowing the target SFU to interact with the site based on context information. For example, the target SFU can send cached downlink packets to the site based on packet sequence numbers, or send aggregation packets to the STA based on the SN context, and determine the channel bandwidth and number of streams based on the terminal OMI status information.

[0613] It should be noted that the names of the above messages can also be other names, such as first message, second message, etc., and this application embodiment does not limit this.

[0614] In one possible implementation, the context information includes site OMI status information. After receiving the new site OMI status, the target SFU can send and receive data with the site (or perform business interactions) according to the send and receive parameters indicated by the site OMI status information. Alternatively, it can also negotiate send and receive parameters with the site using OM.

[0615] The 802.11ax standard incorporates the Operation Mode Invocation (OM) method, where the initiating and responding ends negotiate the operating mode. This reduces power consumption by decreasing the channel bandwidth and the number of supported space-time streams during normal operation. When a large volume of traffic requires transmission, the channel bandwidth and number of space-time streams are restored. Reducing the number of space-time streams or channel bandwidth can be understood as entering an energy-saving mode or state. The initiating end can be a site, and the responding end can be an access point (AP), or vice versa.

[0616] In one possible implementation scenario, if the initiating point is a site (i.e., the site enters power-saving mode before roaming), the source SFU can synchronize the site's OMI status information to the target SFU via the MFU. That is, the OMI status information is included in the aforementioned context information. The target SFU can then interact with the site using the transmit / receive parameters indicated by the OMI status information (e.g., determining channel bandwidth and stream count).

[0617] In another possible implementation scenario, the initiating end is the AP, i.e., the source AP, such as the source SFU (i.e., the scenario where the source SFU switches to the target SFU). In this case, the context information can also include the energy-saving mode of the source SFU. As another example, if the source AP is the MFU, i.e., the scenario where the MFU switches to the target SFU, the context information can also include the energy-saving mode of the MFU.

[0618] In one possible approach, when the target SFU determines that the source SFU (or MFU) has entered the energy-saving mode based on the energy-saving mode of the source SFU (or MFU), it performs service interaction with the site based on the transmit / receive parameters indicated by the site OMI status information.

[0619] In another possible implementation, when the target SFU determines that the source SFU (or MFU) has entered the energy-saving mode based on the energy-saving mode of the source SFU (or MFU), it negotiates the operating mode (OM) with the site.

[0620] In another possible implementation, when the target SFU determines that the energy-saving mode of the source SFU (or MFU) supports the current traffic volume of the target SFU, it performs service interaction with the site according to the transmit / receive parameters indicated by the site's OMI status information. When the target SFU determines that the energy-saving mode of the source SFU (or MFU) does not support the current traffic volume of the target SFU, it negotiates the Operation Mode (OM) with the site.

[0621] As shown in Figure 2B, which is a schematic flowchart of another roaming method provided in an embodiment of this application, in this embodiment, the STA is currently connected to the SFU, which provides services to the STA. This SFU can be called the source SFU. The source SFU can be the one actually associated with the STA.

[0622] The roaming method provided in this embodiment includes the following steps:

[0623] S101, the source SFU detects a roaming trigger event of the STA and sends the roaming trigger event of the STA to the MFU.

[0624] S102, the MFU sends a roaming decision information collection request to the source SFU.

[0625] S103, the source SFU sends roaming decision information to the MFU.

[0626] The implementation process of steps S101-S103 can be referred to steps S201-203 above, and will not be repeated here.

[0627] S104, MFU determines the target access point for roaming based on roaming decision information.

[0628] In this embodiment, the MFU selects itself as the target access point of the STA based on roaming decision information.

[0629] In one possible example, the roaming decision information sent by the SFU to the MFU includes the RSSI of the Wi-Fi signal received by the SFU from the STA. Specifically, the SFU can measure the Wi-Fi signal transmitted by the STA to obtain the RSSI. The MFU can also detect the RSSI of the STA. The RSSI reflects the communication performance of the channel or link; the higher the RSSI, the higher the communication performance. The MFU can select itself as the target access point based on the RSSI returned by the SFU and the RSSI it detects.

[0630] In another possible example, the roaming decision information sent by the SFU to the MFU includes the load information of the SFU. The MFU can select the access point (MFU) with the lowest load as the target access point based on the load of the SFU and its own load.

[0631] In another possible example, the roaming decision information sent by the SFU to the MFU includes the SFU's channel condition information. Specifically, the SFU can measure the channel conditions through which it communicates with the STA to obtain channel condition information. The MFU can select the device with the best channel conditions among multiple SFUs and its own as the target access point. For example, it can select the device with the highest SINR, or the device with the lowest packet loss rate, or the device with the highest SINR among devices with packet loss rates below a certain threshold, or SINR and packet loss rate can each have different weights, and the MFU can weight SINR with the reciprocal of the packet loss rate and select the device with the largest weighted value as the target access point.

[0632] In another possible example, the roaming decision information sent by the SFU to the MFU includes the SFU's load information and RSSI. The MFU can collect its own load information and RSSI. For example, the MFU can select the device with an RSSI greater than a certain threshold and the lowest current load as the target access point. Alternatively, the MFU can weight the RSSIs of multiple SFUs with their load values ​​and determine the device with the highest weighted value as the target access point.

[0633] In another possible example, the roaming decision information sent by the SFU to the MFU includes RSSI, load information, and channel condition information. The MFU can use a weighted calculation method to select the target access point. For example, RSSI, load, SINR (and / or packet loss rate) each correspond to different weights, and the target access point is determined by calculating the weights.

[0634] It should be understood that there are other combinations of the above roaming decision information, so the MFU can select the optimal device as the target access point based on different combinations, which will not be listed here.

[0635] In some possible implementations, after selecting the target access point (MFU), the MFU initiates the roaming process. Initiating the roaming process may involve starting a handover state machine. The handover state machine describes the states of the roaming handover. For example, the roaming handover states include: the roaming processing state and the roaming reporting state.

[0636] The roaming decision information collection and reporting message sent by the SFU to the MFU may include fields numbered 2-8 in Table 1-1, with a specific format as shown in Table 12 below. Additionally, the roaming decision information collection and reporting message may also be called a roaming decision reporting message, or use other names; this embodiment does not limit the specific name used.

[0637] Table 12

[0638] Table 13

[0639] The Payload field in Table 12 can carry the parameters reported by the SFU. In some possible implementation scenarios, default or protocol-defined parameters can be used for reporting. In this case, it is not necessary to instruct the SFU on the parameters to be reported. In this case, a set sequence can be added to Payload and PayloadLen, such as all zeros, or these two fields can be excluded.

[0640] S105, the MFU sends a roaming start instruction message to the source SFU.

[0641] The roaming start indication message may also be called the roaming start message or other names, and this application embodiment does not limit this.

[0642] After making a roaming decision, the MFU can initiate the roaming handover state machine. The source SFU can also initiate the roaming handover state machine after receiving the roaming start indication message.

[0643] The roaming start indication message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 14 below.

[0644] Table 14

[0645] In Table 14, the Payload and PayloadLen fields can have specified sequences added, such as all zeros, or these two fields can be excluded. Additionally, the payload field can carry parameters including the roaming decision information in Table 13, roaming preprocessing context information (aggregation parameters) as shown in Table 4-1 or Table 4-2, and roaming feedback context information (parameters to be synchronized) as shown in Table 9-1, Table 9-2, or Table 9-3.

[0646] S106, the source SFU sends a roaming start confirmation message to the MFU.

[0647] For example, after the source SFU completes its roaming handover state machine startup, it sends a roaming start confirmation message to the MFU.

[0648] The roaming start confirmation message can also be named in other ways, such as roaming start successful message. This application embodiment does not limit this.

[0649] If the source SFU fails to initiate roaming processing, it can send a roaming start failure message to the MFU. Roaming start confirmation messages and roaming start failure messages can be collectively referred to as roaming start feedback messages. The roaming start feedback message indicates whether roaming initiation was successful. If it indicates success, it can be called a roaming start confirmation message; if it indicates failure, it can be called a roaming start failure message. The circumstances surrounding roaming initiation failure will be described in detail later and will not be repeated here.

[0650] As an example, the roaming start indication message may include fields numbered 2-8 in Table 1-1, as shown in Table 15 below.

[0651] Table 15

[0652] In Table 15, Payload and PayloadLen can have specified sequences added, such as all zeros, or these two fields can be excluded.

[0653] In Table 15, Status = 0, which corresponds to the roaming start confirmation message.

[0654] S107, after receiving the roaming start confirmation message from the source SFU, the MFU performs roaming preprocessing. The purpose of roaming preprocessing is to complete the preparations before roaming handover.

[0655] MFU can perform roaming preprocessing for STA, or roaming preparation for STA, generating preprocessing information.

[0656] In one possible example, roaming preprocessing includes: simulated aggregation.

[0657] To improve air interface transmission efficiency, aggregated transmission can be performed between the access point (MFU / SFU) and the STA. First, an aggregated session is established between the access point and the STA. Then, aggregated transmission occurs between the AP (MFU / SFU) and the STA. For example, after receiving an aggregated frame from the STA, the AP can respond using a Block Acknowledgment (BA) frame.

[0658] Simulated aggregation can be understood as the aggregated transmission between the simulation and the STA.

[0659] As an example, the aggregation parameters are shown in Table 4-1 or Table 4-2 above, and will not be repeated here.

[0660] In another possible example, roaming preprocessing includes: creating users for STAs, and simulating aggregation.

[0661] The MFU can create a user for the STA after receiving a roaming start confirmation message from the source SFU, based on the STA's AID, an authentication request frame from the STA, an association (or reassociation) request frame from the STA, or a key used for communication between the STA and the source SFU. The MFU can also receive the STA's authentication request frame, association request frame, and key used for communication between the STA and the source SFU from the source SFU when the STA comes online.

[0662] In another possible implementation scenario, when the STA comes online, the MFU receives the STA's authentication request frame, association request frame, and the key used for communication between the STA and the source SFU. The MFU then creates a user for the STA based on this information.

[0663] In one possible implementation scenario, if the MFU has already established a connection with the STA, the MFU establishes an aggregation with the STA based on the aggregation parameters. The aggregation parameters in the MFU come from the source SFU. When the STA comes online on the source SFU, the source SFU can pass the aggregation parameters to the MFU.

[0664] S108, the MFU sends a service shutdown instruction message to the source SFU.

[0665] After the MFU completes preprocessing, it sends a service shutdown instruction message to the source SFU.

[0666] The service shutdown instruction message can also be called a service shutdown instruction message, or other names may be used; this application embodiment does not limit the specific name. The service shutdown instruction message is used to instruct the source SFU to shut down the service interaction between it and the STA.

[0667] As an example, a service shutdown instruction message may include fields numbered 2-5 and 7-8 in Table 1-1, as shown in Table 16-1.

[0668] Table 16-1

[0669] The Payload field can carry the parameters that the SFU needs to report. In some possible implementation scenarios, default or protocol-defined parameters can be used for reporting. In this case, it is not necessary to indicate the parameters that the SFU needs to report. In this case, a set sequence can be added to Payload and PayloadLen, such as all zeros, or these two fields can be omitted.

[0670] Table 16-2

[0671] In another possible scenario, after receiving the service shutdown instruction message, the source SFU can also delete the existing aggregation session (or aggregation for short) between itself and the STA. The source SFU can also send an aggregation deletion message to the STA, instructing it to delete the established aggregation session (or aggregation for short). After the source SFU deletes the STA's aggregation, it shuts down the STA's service.

[0672] S109, the source SFU sends a service shutdown completion message to the MFU.

[0673] In the event of a service shutdown failure, the source SFU will send a service shutdown failure message to the MFU. Service shutdown completion messages and service shutdown failure messages can be collectively referred to as service shutdown feedback messages. The service shutdown feedback message indicates whether the service shutdown was successful. If it indicates success, it can be called a service shutdown completion message; if it indicates failure, it can be called a service shutdown failure message. The circumstances of service shutdown failure will be described in detail later and will not be repeated here.

[0674] As an example, the service closure completion message can be found in Table 8, and will not be repeated here.

[0675] After the source SFU successfully shuts down the service, it obtains the parameters that need to be synchronized (which can be called the parameters to be synchronized) and sends these parameters to the MFU through a service shutdown completion message. The service shutdown completion message includes the parameters that need to be synchronized.

[0676] The parameters that need to be synchronized may include context information of service interactions between the source SFU and STA, such as the aggregate frames to be transmitted between the source SFU and STA and the sequence numbers of data packets in the block acknowledgment (BA).

[0677] As an example, the parameters (or context information) that need to be synchronized can be found in Table 9-1, Table 9-2, or Table 9-3, and will not be repeated here.

[0678] S110, MFU enables services to STA based on synchronization parameters.

[0679] The MFU establishes a communication link with the STA, sends and replies to messages to the STA, and receives messages from the STA.

[0680] In one possible implementation, the parameters (context information) that need to be synchronized include site OMI status information. After receiving the site OMI status information, the MFU can send and receive data with the site (or perform business interactions) according to the send and receive parameters indicated by the site OMI status information. Alternatively, it can also negotiate send and receive parameters with the site using OM.

[0681] The 802.11ax standard incorporates the Operation Mode Invocation (OM) method, where the initiating and responding ends negotiate the operating mode. This reduces power consumption by decreasing the channel bandwidth and the number of supported space-time streams during normal operation. When a large volume of traffic requires transmission, the channel bandwidth and number of space-time streams are restored. Reducing the number of space-time streams or channel bandwidth can be understood as entering an energy-saving mode or state. The initiating end can be a site, and the responding end can be an access point (AP), or vice versa.

[0682] In one possible implementation scenario, if the initiating point is a site (i.e., the site enters power-saving mode before roaming), the source SFU can synchronize the site's OMI status information to the MFU. That is, the OMI status information is included in the aforementioned context information. The MFU can then interact with the site based on the send / receive parameters indicated by the OMI status information.

[0683] In another possible implementation scenario, the initiator is the AP, i.e., the source AP, such as the source SFU (i.e., the scenario where the source SFU switches to the MFU). In this case, the context information can also include the energy-saving mode of the source SFU.

[0684] In one possible approach, when the MFU determines that the source SFU has entered the power-saving mode based on the power-saving mode of the source SFU, it performs service interaction with the site based on the transmit / receive parameters indicated by the site OMI status information (e.g., determining channel bandwidth and stream count).

[0685] In another possible implementation, when the MFU determines that the source SFU has entered the energy-saving mode based on the energy-saving mode of the source SFU, it negotiates the operating mode (OM) with the site.

[0686] In another possible implementation, when the MFU determines that the energy-saving mode of the source SFU supports the current traffic volume of the MFU, it performs service interaction with the site based on the transmit / receive parameters indicated by the site OMI status information. When the MFU determines that the energy-saving mode of the source SFU does not support the current traffic volume of the MFU, it negotiates the Operation Mode (OM) with the site.

[0687] In another possible scenario, since the source SFU sent a delete aggregation message to the STA in step S108, the STA has already deleted the aggregation session. To restart the aggregation session, the MFU, after receiving the service shutdown completion message, can establish an aggregation session with the STA based on the service traffic. For example, the process of the MFU establishing an aggregation session with the STA can refer to the process of the target SFU establishing a joint session with the STA in the above embodiment, and will not be repeated here.

[0688] In another possible scenario, instead of the target SFU sending a delete aggregation message to the STA after receiving the service shutdown instruction message, the MFU sends the delete aggregation message to the STA after receiving the aforementioned service shutdown completion message. The STA then deletes the previous aggregation session based on this message. After the previous aggregation session is deleted, the MFU can begin establishing an aggregation session with the STA, the specific establishment process of which is described above and will not be repeated here.

[0689] It should be noted that the names of the above messages can also be other names, such as first message, second message, etc., and this application embodiment does not limit this.

[0690] As shown in Figure 2C, Figure 2C is a schematic flowchart of another roaming method provided in an embodiment of this application. In this embodiment, the STA is currently connected to the MFU, and the MFU provides services to the STA. The roaming method provided in this embodiment includes the following steps:

[0691] S001, MFU detected a roaming trigger event in STA.

[0692] Roaming trigger events can include the STA's signal strength falling below the roaming threshold.

[0693] The specific implementation of the MFU detecting the roaming trigger event can be referred to in step S201 above, where the SFU detects the roaming trigger event.

[0694] S002, the MFU sends a roaming decision information collection request to multiple SFUs within the network.

[0695] S003, multiple SFUs send roaming decision information to the MFU respectively.

[0696] S004, MFU determines the target access point for roaming based on roaming decision information.

[0697] The implementation process of steps S002-S004 can be referred to steps S202-204 above, and will not be repeated here.

[0698] S005, after the MFU makes a roaming decision and determines the target access point for the STA roaming, it starts its own roaming handover state machine and enters the roaming processing state.

[0699] S006, the MFU sends a roaming start instruction message to the target SFU.

[0700] The roaming start indication message may also be called the roaming start message or other names, and this application embodiment does not limit this.

[0701] After receiving the roaming start instruction message, the target SFU can initiate roaming, such as by starting its own roaming switching state machine.

[0702] The roaming start indication message can be found in Table 2 above, and will not be repeated here.

[0703] S007, the target SFU sends a roaming start confirmation message to the MFU.

[0704] For example, after the target SFU completes its roaming handover state machine startup, it sends a roaming start confirmation message to the MFU.

[0705] S008, after receiving the roaming start confirmation message from the target SFU, the MFU sends a roaming preprocessing instruction to the target SFU.

[0706] The roaming preprocessing instruction is used to instruct the target SFU to complete the preparations before roaming handover. The roaming preprocessing instruction message is used to instruct the target SFU to perform roaming preparations for the STA.

[0707] Roaming preprocessing instructions, also known as roaming preprocessing messages, or other names are not limited to in this application.

[0708] S009, the target SFU performs roaming preprocessing.

[0709] When the target SFU receives the roaming preprocessing instruction message, it performs roaming preprocessing for the STA, or in other words, performs roaming preparation for the STA, and generates preprocessing information.

[0710] In one possible example, roaming preprocessing includes: simulated aggregation.

[0711] To improve air interface transmission efficiency, aggregated transmission is performed between the access point (MFU / SFU) and the STA. First, an aggregated session is established between the access point and the STA. Then, aggregated transmission occurs between the AP (MFU / SFU) and the STA. For example, after receiving an aggregated frame from the STA, the AP can respond using a Block Acknowledgment (BA) frame.

[0712] Simulated aggregation can be understood as the aggregated transmission between the simulation and the STA.

[0713] For example, the roaming preprocessing instruction sent by the MFU includes parameters used to simulate aggregation. These could be aggregation parameters used to implement aggregated transmission with the STA, or aggregated frames.

[0714] As an example, the aggregation parameters are shown in Table 4-1 or 4-2 above.

[0715] In another possible example, roaming preprocessing includes: creating users for STAs, and simulating aggregation.

[0716] For example, the roaming preprocessing instruction received by the target SFU includes one or more of the following: the STA's AID, an authentication request frame from the STA, an association request frame from the STA, or a key used for communication between the STA and the MFU. Further, the target SFU creates a user for the STA based on the information in the roaming preprocessing instruction. The target SFU also performs simulated aggregation.

[0717] In one possible implementation scenario, the target SFU has already established an association with the user. In this case, the parameters passed in the roaming preprocessing instruction are aggregation parameters, and the target SFU establishes an aggregation with the STA through the aggregation parameters passed by the MFU.

[0718] In another possible implementation scenario, if the target SFU has not yet established an association with the user, the parameters passed in the roaming preprocessing instruction are association parameters and aggregation information. The target SFU establishes an association and aggregation relationship with the terminal through the association and aggregation information passed by the MFU.

[0719] The association parameters include the site's association request frame and / or the key negotiated between the site and the source SFU for communication. The association parameters may also include the site's authentication request frame.

[0720] In some possible implementation scenarios, the target SFU can create users for the STA during the STA's online phase on the FTTR network.

[0721] As an example, the format of the roaming preprocessing message (i.e., the roaming preprocessing instruction mentioned above) can be found in Table 5 above, and will not be repeated here.

[0722] S010, the target SFU sends a roaming preprocessing complete message to the MFU.

[0723] The implementation process of step S010 can be referred to step S209 above, and will not be repeated here.

[0724] S011, MFU shuts down STA's services.

[0725] The MFU stops sending messages to the STA (closing the communication link with the STA) and shuts down the STA's services. After the MFU successfully shuts down the services, it retrieves the parameters that need to be synchronized. These parameters include the context information of the service interaction between the MFU and the STA, such as the sequence numbers of the aggregate frames to be transmitted between the MFU and the STA, and the sequence numbers of each data packet in the block acknowledgment.

[0726] As an example, the parameters that need to be synchronized can be found in Table 9-1, Table 9-2, or Table 9-3 above, and will not be repeated here.

[0727] In another possible scenario, the MFU can also delete the existing aggregation session (or aggregation for short) between the local machine and the STA. The MFU can also send an aggregation deletion message to the STA, instructing it to delete the established aggregation session (or aggregation for short). After the MFU deletes the STA's aggregation, the STA's services are shut down.

[0728] S012, the MFU sends a service activation instruction message to the target SFU.

[0729] The service activation instruction message, also known simply as the service activation message, is used to instruct the target SFU to initiate service interaction with the STA. The service activation instruction can include the parameters that need to be synchronized, such as context information.

[0730] The service activation instruction message, also known simply as the service activation message, may be used under other names, but this application embodiment does not specifically limit it.

[0731] As an example, the format of the service activation instruction message can be found in Table 10 above, and will not be repeated here.

[0732] S013, the target SFU receives the service activation instruction message and activates the service with the STA.

[0733] After receiving the service activation instruction message, the target SFU starts service interaction with the STA according to the parameters to be synchronized, such as sending messages to the STA based on context information such as unicast PN number, SN context, message sequence number or site OMI status information.

[0734] In one possible implementation, the context information includes site OMI status information. After receiving the site OMI status information, the target SFU can send and receive data with the site (or perform business interactions) according to the send and receive parameters indicated by the site OMI status information. Alternatively, it can also negotiate send and receive parameters with the site using OM.

[0735] The 802.11ax standard incorporates the Operation Mode Invocation (OM) method, where the initiating and responding ends negotiate the operating mode. This reduces power consumption by decreasing the channel bandwidth and the number of supported space-time streams during normal operation. When a large volume of traffic requires transmission, the channel bandwidth and number of space-time streams are restored. Reducing the number of space-time streams or channel bandwidth can be understood as entering an energy-saving mode or state. The initiating end can be a site, and the responding end can be an access point (AP), or vice versa.

[0736] In one possible implementation scenario, if the initiating point is a site (i.e., the site enters power-saving mode before roaming), the MFU can synchronize the site's OMI status information to the target SFU. That is, the OMI status information is included in the aforementioned context information. The target SFU can then interact with the site using the transmit / receive parameters indicated by the OMI status information (e.g., determining channel bandwidth and stream count).

[0737] In another possible implementation scenario, the initiator is the AP, i.e., the source AP, i.e., the MFU. In this case, the context information can also include the power-saving mode of the MFU.

[0738] In one possible approach, when the target SFU determines that the MFU has entered the energy-saving mode based on the MFU's energy-saving mode, it performs service interaction with the site according to the transmit / receive parameters indicated by the site's OMI status information.

[0739] In another possible implementation, when the target SFU determines that the MFU has entered the energy-saving mode based on the energy-saving mode of the MFU, it negotiates the operating mode (OM) with the site.

[0740] In another possible implementation, when the target SFU determines that the MFU's energy-saving mode supports the target SFU's current traffic volume, it performs service interaction with the site based on the transmit / receive parameters indicated by the site's OMI status information. When the target SFU determines that the MFU's energy-saving mode does not support the target SFU's current traffic volume, it negotiates the Operation Mode (OM) with the site.

[0741] In another possible scenario, since the MFU sent a delete aggregation message to the STA in step S011, the STA has already deleted the aggregation session. To restart the aggregation session, the target SFU, upon receiving the service activation instruction message, can establish an aggregation session with the STA based on the service traffic. The specific establishment process is described in the above embodiment and will not be repeated here.

[0742] In another possible scenario, instead of sending a delete aggregation message to the STA, the MFU sends the delete aggregation message to the STA only after receiving the service activation instruction message. The STA then deletes the previous aggregation session based on this message. After the previous aggregation session is deleted, the target SFU can begin establishing an aggregation session with the STA, the specific establishment process of which is as described above and will not be repeated here.

[0743] In another possible scenario, after receiving the service activation instruction message, the target SFU can send a Block Acknowledgment (BA) request to the STA to request the STA to adjust the Start Sequence Number (SSN) in the BA frame. The BA request can carry the new SSN to facilitate the adjustment of the SSN in the BA frame.

[0744] S014, the target SFU sends a service activation completion message to the MFU.

[0745] Once the service is started, the target SFU sends a service start completion message to the MFU.

[0746] If the target SFU fails to initiate the service, it can send a service initiation failure message to the MFU. Service initiation success messages and service initiation failure messages can be collectively referred to as service initiation feedback messages. The service initiation feedback message indicates whether the service initiation was successful. If it indicates success, it can be called a service initiation success message; if it indicates failure, it can be called a service initiation failure message. The circumstances of service initiation failure will be described in detail later and will not be repeated here.

[0747] As an example, the format of the service activation completion message can be found in Table 11 above.

[0748] In some possible implementations, the context information and aggregation parameters can also be sent to the target SFU in a single message. For example, the MFU sends the message to the target SFU in the service activation message in step S012.

[0749] After the MFU receives the service activation completion message from the target SFU, the roaming ends.

[0750] It should be noted that the names of the above messages can also be other names, such as first message, second message, etc., and this application embodiment does not limit this.

[0751] In some possible implementation scenarios, roaming anomalies may occur during the above roaming process. The following describes how to handle roaming anomalies.

[0752] Abnormal state 1: Exception that roaming failed to start.

[0753] Method 1:

[0754] Referring to Figures 3A and 3B, a schematic flowchart of a roaming method provided in an embodiment of this application is shown. When the MFU determines that the source SFU or the target SFU has failed to initiate roaming, it clears the roaming information of the STA. Figures 3A and 3B describe an exception handling method for roaming initiation failure.

[0755] In S301, the MFU sends a roaming start indication message to both the source SFU and the target SFU. See S205 for further details.

[0756] In one possible example, after receiving the roaming start indication message, the source SFU initiates roaming, for example, by starting its own roaming switching state machine. However, if roaming initiation fails, S302a is executed.

[0757] In another possible example, after receiving the roaming start indication message, the target SFU initiates roaming, for example, by starting its own roaming switching state machine. However, if roaming initiation fails, S302b is executed.

[0758] Referring to Figure 3A, in step S302a, the source SFU sends a roaming start failure indication message (which can be simply referred to as a roaming start failure message or other names) to the MFU. For example, a software vulnerability (bug) or hardware failure in the source SFU can cause roaming to fail to start.

[0759] Referring to Figure 3B, in step S302b, the target SFU sends a roaming start failure indication message to the MFU. For example, a software vulnerability (bug) or hardware failure in the target SFU can cause roaming initiation to fail.

[0760] For example, the format of the roam start failure indication message can be seen in Table 3. Roam Process Status = 1, and Status ≠ 0. In some implementation scenarios, Roam Status is a value between 1 and 255, used to indicate the error identification code. Different values ​​indicate different reasons for failure.

[0761] The SFU that fails to initiate roaming can be either the source SFU or the target SFU. Figure 3A shows an example of the source SFU, and Figure 3B shows an example of the target SFU. In some possible scenarios, both the source SFU and the target SFU may fail to initiate roaming simultaneously.

[0762] S303, the MFU clears the roaming information of the STA, or in other words, clears the preparation information made for the STA's roaming, or the MFU clears the current roaming for the STA and waits for the next roaming trigger. Clearing roaming information can be achieved, for example, by disabling the state machine switching.

[0763] The above solution addresses the issue of roaming initiation failure by promptly clearing roaming-related information. The MFU then stops executing the roaming process, reducing instruction overhead, minimizing storage resource waste, and preventing the stored information from impacting subsequent roaming operations.

[0764] In some possible implementations, if the MFU determines that the source SFU has failed to initiate roaming when it sends a roaming start indication message to the source SFU for a certain period of time or when the number of retransmissions reaches a certain number of times, then it executes S303.

[0765] In other possible implementations, if the MFU determines that the target SFU has failed to initiate roaming when the time threshold for sending the roaming start indication message to the target SFU has been reached or the number of retransmissions has reached the number threshold, then S303 is executed.

[0766] Method 2:

[0767] Referring to Figures 4A and 4B, a schematic diagram of another roaming method provided in an embodiment of this application is shown.

[0768] S401, see S301, will not be repeated here.

[0769] In one possible example, after receiving the roaming start indication message, the source SFU initiates roaming, for example, by starting its own roaming switching state machine. However, if roaming initiation fails, S402a is executed.

[0770] In another possible example, after receiving the roaming start indication message, the target SFU initiates roaming, for example, by starting its own roaming switching state machine. However, if roaming initiation fails, S402b is executed.

[0771] Referring to Figure 4A, in S402a, the source SFU sends a roaming start failure indication message to the MFU.

[0772] Referring to Figure 4B, in S402b, the target SFU sends a roaming start failure indication message to the MFU.

[0773] The SFU that fails to initiate roaming can be either the source SFU or the target SFU. Figure 4A shows an example of the source SFU, and Figure 4B shows an example of the target SFU. In some possible scenarios, both the source SFU and the target SFU may fail to initiate roaming simultaneously. In such cases, both the source SFU and the target SFU will send a roaming start failure indication to the MFU.

[0774] S403, MFU clears the roaming information of the STA.

[0775] S404, the MFU sends a roaming exception handling message to the source SFU. The roaming exception handling message indicates that the roaming information should be cleared.

[0776] In the exception handling scenario at the start of roaming, the roaming exception handling message can also be called the roaming start exception handling message, or other names can be used. This application embodiment does not specifically limit this.

[0777] S405, the MFU sends a roaming exception handling message to the target SFU.

[0778] S406, the source SFU sends a roaming exception handling completion message to the MFU.

[0779] In the roaming start exception handling scenario, the roaming exception handling completion message can also be called the roaming start exception handling completion message, or other names can be used. This application embodiment does not specifically limit this.

[0780] When the source SFU receives a roaming exception handling message, it deletes the roaming information of the STA, such as deleting the started switching state machine, and then sends a roaming exception handling completion message to the MFU.

[0781] S407, the target SFU sends a roaming exception handling completion message to the MFU.

[0782] When the target SFU receives a roaming exception handling message, it deletes the roaming information of the STA, such as deleting the started switching state machine, and then sends a roaming exception handling completion message to the MFU.

[0783] The above solution addresses the issue of roaming initiation failure by promptly clearing roaming-related information. Neither the MFU nor the SFU will continue executing the roaming process, reducing instruction overhead and minimizing storage resource waste. It also prevents stored information from impacting subsequent roaming operations.

[0784] In some possible implementations, if the MFU determines that the source SFU has failed to initiate roaming when it sends a roaming start indication message to the source SFU for a certain period of time or when the number of retransmissions reaches a certain number of times, then it executes S404-S405.

[0785] In other possible implementations, if the MFU determines that the target SFU has failed to initiate roaming when the time threshold for sending the roaming start indication message to the target SFU has been reached or the number of retransmissions has reached the number threshold, then S404-S405 are executed.

[0786] Abnormal Status 2: Exception of roaming preprocessing failure.

[0787] Method 1:

[0788] Referring to Figure 5, it is a schematic flowchart of a roaming method provided in an embodiment of this application.

[0789] In S501, the MFU sends a roaming preprocessing message to the target SFU. See S208 for details.

[0790] After receiving the roaming preprocessing message, the target SFU completes pre-handover preparations. These preparations may include simulating aggregation. Optionally, the preparations may also include creating users for the STA.

[0791] S502, the target SFU sends a roaming preprocessing failure indication message to the MFU. Upon receiving the roaming preprocessing failure indication message, the MFU determines that the target SFU's roaming preprocessing has failed. For example, a software vulnerability (bug) or hardware failure in the target SFU can both lead to roaming preprocessing failure.

[0792] For example, the format of the roaming preprocessing failure indication message can be seen in Table 6. Roam Notify Status = 2, and Roam Status ≠ 0. In some implementation scenarios, Roam Status is a value between 1 and 255, used to indicate the error identification code. Different values ​​indicate different reasons for failure.

[0793] S503, MFU clears the roaming information of the STA, or in other words, clears the preparation information made for the STA's roaming. Clearing roaming information can, for example, disable the switching state machine.

[0794] In some possible implementations, if the MFU determines that the roaming preprocessing of the target SFU has failed when the time threshold for sending the roaming preprocessing instruction message to the target SFU is reached or the number of retransmissions reaches the number threshold, then S503 is executed.

[0795] Method 2:

[0796] Referring to Figure 6, this is a schematic diagram of another roaming method provided in an embodiment of this application.

[0797] S601, see S501, will not be repeated here.

[0798] S602, the target SFU sends a roaming preprocessing failure indication to the MFU. Upon receiving the roaming preprocessing failure indication message, the MFU determines that the target SFU's roaming preprocessing has failed. For example, a software vulnerability (bug) or hardware failure in the target SFU can both lead to roaming preprocessing failure.

[0799] Optionally, in step S603, the MFU clears the roaming information of the STA.

[0800] S604, the MFU sends a roaming exception handling message to the target SFU. The roaming exception handling message instructs the deletion of roaming-related information for that site.

[0801] S605, the MFU sends a roaming exception handling message to the source SFU. The roaming exception handling message instructs the removal of roaming-related information for that site.

[0802] In the exception handling scenario of this roaming preprocessing, the roaming exception handling message can also be called the roaming preprocessing exception handling message, or other names can be used. This application embodiment does not specifically limit this.

[0803] S606, the target SFU sends a roaming exception handling completion message to the MFU.

[0804] S607, the source SFU sends a roaming exception handling completion message to the MFU.

[0805] In the exception handling scenario of this roaming preprocessing, the roaming exception handling completion message can also be called the roaming preprocessing exception handling completion message, or other names can be used. This application embodiment does not specifically limit this.

[0806] When the target SFU receives a roaming exception handling message, it deletes the roaming information and preprocessing information of the STA. For example, deleting the STA's roaming information includes deleting the initiated switching state machine. It also deletes preprocessing information, including deleting simulated aggregation information and user information for created STAs. Then, it sends a roaming exception handling complete message to the MFU.

[0807] When the source SFU receives a roaming exception handling message, it clears the roaming message, such as by deleting the started switching state machine.

[0808] In some possible implementations, if the MFU sends a roaming preprocessing instruction message to the target SFU for a certain period of time or a certain number of retransmissions, and does not receive a roaming preprocessing completion message from the target SFU (or does not receive a reply message from the target SFU), it determines that the roaming preprocessing of the target SFU has failed, and then executes S604-S605.

[0809] Abnormal Status 3: Service shutdown failure exception.

[0810] Method 1:

[0811] Referring to Figure 7, it is a schematic flowchart of a roaming method provided in an embodiment of this application.

[0812] In S701, the MFU sends a service shutdown instruction message to the source SFU. See S209 for details.

[0813] S702, the source SFU sends a service shutdown failure indication message to the MFU. Upon receiving the service shutdown failure indication message, the MFU determines that the service shutdown of the source SFU has failed.

[0814] For example, if the source SFU has a software vulnerability (bug) or a hardware failure, the service shutdown may fail.

[0815] For example, the format of the roaming preprocessing failure indication message can be seen in Table 6. Roam Notify Status = 3, and Roam Status ≠ 0. In some implementation scenarios, Roam Status is a value between 1 and 255, used to indicate the error identification code. Different values ​​indicate different reasons for failure.

[0816] S703, the MFU sends a roaming exception handling message a1 to the source SFU. The roaming exception handling message a1 instructs the source SFU to restore the configuration prior to roaming initiation for the site.

[0817] S704, the MFU sends a roaming exception handling message a2 to the target SFU. The roaming exception handling message a2 instructs the target SFU to delete roaming-related information for the STA.

[0818] Optionally, MFU removes roaming-related information from a site.

[0819] In the abnormal handling scenario of service shutdown, the roaming abnormal handling message can also be called the service shutdown abnormal handling message, or other names can be used. This application embodiment does not make specific limitations on this.

[0820] S705, the source SFU sends a roaming exception handling completion message to the MFU. Upon receiving the roaming exception handling message a1, the source SFU restores the STA to its pre-roaming configuration. After completion, it sends back a roaming exception handling completion message.

[0821] S706, the target SFU sends a roaming exception handling completion message to the MFU. Upon receiving the roaming exception handling message a2, the target SFU deletes the roaming-related information for the STA, and then sends back a roaming exception handling completion message.

[0822] In the abnormal handling scenario of service shutdown, the roaming abnormal handling completion message can also be called the service shutdown abnormal handling completion message, or other names can be used. This application embodiment does not make specific limitations on this.

[0823] In some possible implementations, the MFU can restore the configuration of the site before roaming was initiated, such as deleting the site's roaming-related information.

[0824] In some possible implementations, if the MFU determines that the source SFU service shutdown has failed when the time threshold for sending the service shutdown indication message to the source SFU has been reached or the number of retransmissions has reached the number of times threshold, and no service shutdown completion message (or no reply message from the source SFU) has been received, then S703-S704 are executed.

[0825] Method 2:

[0826] Referring to Figure 8, it is a schematic flowchart of a roaming method provided in an embodiment of this application.

[0827] In S801, the MFU sends a service shutdown instruction message to the source SFU. See S209 for details.

[0828] S802, the source SFU sends a service shutdown failure indication message to the MFU. Upon receiving the service shutdown failure indication message, the MFU determines that the service shutdown of the source SFU has failed. For example, a software vulnerability (bug) or hardware failure in the source SFU may cause service shutdown failure.

[0829] For example, the format of the roaming preprocessing failure indication message can be seen in Table 6. Roam Notify Status = 3, and Roam Status ≠ 0. In some implementation scenarios, Roam Status is a value between 1 and 255, used to indicate the error identification code. Different values ​​indicate different reasons for failure.

[0830] S803, the MFU sends a roaming anomaly handling message b1 to the source SFU. Roaming anomaly handling message b1 indicates that the site should be removed from the network.

[0831] S804, the MFU sends a roaming anomaly handling message b2 to the target SFU. Roaming anomaly handling message b2 indicates that the site should be removed from the network.

[0832] In the abnormal handling scenario of service shutdown, the roaming abnormal handling message can also be called the service shutdown abnormal handling message, or other names can be used. This application embodiment does not make specific limitations on this.

[0833] Optionally, the MFU removes the site from the network.

[0834] S805, the source SFU sends a roaming exception handling completion message to the MFU. Upon receiving the roaming exception handling message b1, the source SFU removes the site from the network and then sends back a roaming exception handling completion message.

[0835] S806, the target SFU sends a roaming exception handling completion message to the MFU. Upon receiving the roaming exception handling message b2, the target SFU removes the site from the network and then sends back a roaming exception handling completion message.

[0836] In the abnormal handling scenario of service shutdown, the roaming abnormal handling completion message can also be called the service shutdown abnormal handling completion message, or other names can be used. This application embodiment does not make specific limitations on this.

[0837] In some possible implementations, if the MFU determines that the source SFU service shutdown has failed when the time threshold for sending the service shutdown indication message to the source SFU has been reached or the number of retransmissions has reached the number of times it has been retransmitted has been reached, and no service shutdown completion message has been received from the source SFU (or no reply message has been received from the source SFU), then S803-S804 are executed.

[0838] Abnormal Status 4: Service startup failure.

[0839] Method 1:

[0840] Referring to Figure 9, it is a schematic flowchart of a roaming method provided in an embodiment of this application.

[0841] In S901, the MFU sends a service activation instruction to the target SFU. See S211 for details, which will not be repeated here.

[0842] S902, the target SFU sends a service activation failure indication to the MFU. Upon receiving the service activation failure indication message, the MFU determines that the service activation of the target SFU has failed. For example, a software vulnerability (bug) or hardware failure in the target SFU may cause service activation failure.

[0843] Optionally, if the MFU receives a service activation failure indication, the MFU will delete the roaming-related information for the site or restore the configuration prior to roaming activation for that STA.

[0844] S903, the MFU sends a roaming exception handling message c1 to the target SFU. The roaming exception handling message c1 indicates that the configuration prior to the start of roaming for this STA should be restored.

[0845] S904, the MFU sends a roaming exception handling message c1 to the source SFU. The roaming exception handling message c2 indicates that the configuration prior to the start of roaming for this STA should be restored.

[0846] In the scenario of handling exceptions during service activation, the roaming exception handling message can also be called the service activation exception handling message, or other names can be used. This application embodiment does not specifically limit this.

[0847] S905, the target SFU sends a roaming exception handling completion message to the MFU. Upon receiving the roaming exception handling message c1, the target SFU restores the configuration prior to roaming initiation for that STA, and then sends back a roaming exception handling completion message.

[0848] S906, the source SFU sends a roaming exception handling completion message to the MFU. Upon receiving the roaming exception handling message c2, the source SFU restores the configuration prior to roaming initiation for that STA, and then sends back a roaming exception handling completion message.

[0849] In the scenario of handling exceptions during the service activation, the roaming exception handling completion message can also be called the service activation exception handling completion message, or other names can be used. This application embodiment does not specifically limit this.

[0850] In some possible implementations, if the MFU sends a service activation instruction message to the target SFU for a certain period of time or a certain number of retransmissions, and does not receive a service activation completion message from the target SFU (or does not receive a reply message from the target SFU), it determines that the service activation of the target SFU has failed, and then executes S903-S904.

[0851] Method 2:

[0852] Referring to Figure 10, it is a schematic flowchart of a roaming method provided in an embodiment of this application.

[0853] In S1001, the MFU sends a service activation instruction to the target SFU. See S211 for details, which will not be repeated here.

[0854] S1002, the target SFU sends a service activation failure indication to the MFU.

[0855] S1003, the MFU sends a roaming anomaly handling message d1 to the target SFU. Roaming anomaly handling message d1 instructs the STA to be removed from the network. The target SFU deletes the relevant information of the STA.

[0856] S1004, the MFU sends a roaming anomaly handling message d1 to the source SFU. Roaming anomaly handling message d1 instructs the STA to be removed from the network. The source SFU deletes the relevant information of the STA.

[0857] S1005, the target SFU sends a roaming exception handling completion message to the MFU.

[0858] S1006, the source SFU sends a roaming exception handling completion message to the MFU. The MFU records the failure error code of the STA.

[0859] In some possible implementations, if the MFU sends a service activation instruction message to the target SFU for a certain period of time or a certain number of retransmissions, and does not receive a service activation completion message from the target SFU (or does not receive a reply message from the target SFU), it determines that the service activation of the target SFU has failed, and then executes S1003-S1004.

[0860] As an example, the roaming exception handling messages involved in the above roaming exception handling process can reuse the format of the roaming handover indication message. See Table 17-1 for example.

[0861] Table 17-1

[0862] As an example, the roaming exception handling completion message involved in the above roaming exception handling process can reuse the format of the roaming switchover feedback indication message. See Table 18-1 for example.

[0863] Table 18-1

[0864] In some possible implementation scenarios, load-related fields in some roaming exception handling messages and roaming exception handling completion messages can be empty.

[0865] As another example, the roaming exception handling messages involved in the above roaming exception handling process may include fields 2-5 and 7-8 in Table 1-1. See Table 19-1.

[0866] Table 19-1

[0867] Among them, Roam Process Status = 1 corresponds to the roaming start exception handling message. Roam Process Status = 2 corresponds to the roaming preprocessing exception handling message. Roam Process Status = 3 corresponds to the service shutdown exception handling message. Roam Process Status = 4 corresponds to the service startup exception handling message.

[0868] As another example, the roaming exception handling messages involved in the above roaming exception handling process may include fields 2-5 and 7-8 in Table 1-1. See Table 20-1.

[0869] Table 20-1

[0870] Specifically, Roam Process Status = 1 and Status = 0 corresponds to the completion (or confirmation or success) of roam start exception handling. Roam Process Status = 2 and Status = 0 corresponds to the completion (or confirmation or success) of roam preprocessing exception handling. Roam Process Status = 3 and Status = 0 corresponds to the completion (or confirmation or success) of service closure exception handling. Roam Process Status = 4 and Status = 0 corresponds to the completion (or confirmation or success) of service startup exception handling.

[0871] In this application, all parameters in the tables above, except for Table 1-2, can be carried in the message content field of the WMCI message in Table 1-2 as optional or required fields for transmission.

[0872] Figure 11 is a structural diagram of the roaming device provided in an embodiment of this application. This device can be implemented as part or all of a device through software, hardware, or a combination of both, and is applied to an MFU or SFU. The device provided in this embodiment can implement some of the processes described in the above-described method of this embodiment. The device includes: a sending module 1101 and a receiving module 1102. Optionally, it also includes a processing module (not shown in Figure 11).

[0873] In one possible implementation scenario, the device is applied to an MFU. The various modules described above work together to implement the method flow executed by the MFU in any of the embodiments corresponding to Figures 2A-10.

[0874] In one possible embodiment, the receiving module 1102 is used to obtain roaming decision information of SFUs in the network;

[0875] The processing module is used to determine the target SFU for the site based on the roaming decision information;

[0876] The sending module 1101 is used to send a roaming start indication message to the target SFU, the roaming start indication message being used to indicate that roaming processing is initiated for the site.

[0877] In another possible embodiment,

[0878] Sending module 1101 is used to send a roaming preprocessing message to the target SFU, the roaming preprocessing message being used to instruct the target SFU to initiate roaming preparation for the site;

[0879] The receiving module 1102 is used to receive a roaming preprocessing feedback message from the target SFU, the roaming preprocessing feedback message being used to indicate whether the roaming preparation for the site is successful.

[0880] In another possible embodiment,

[0881] The sending module 1101 is used to send a service shutdown instruction message to the source SFU during the roaming process of the site. The service shutdown message is used to instruct the source SFU to shut down the service interaction with the site.

[0882] The receiving module 1102 is used to receive a service shutdown feedback message from the source SFU, the service shutdown feedback message being used to indicate whether the service interaction with the site has been successfully shut down.

[0883] In another possible embodiment,

[0884] The sending module 1101 is used to send a service activation indication message to the target SFU during the roaming process of the site. The service activation indication message is used to instruct the target SFU to activate service interaction with the site.

[0885] The receiving module 1102 is used to receive a service activation feedback message from the target SFU, the service activation feedback message being used to indicate whether the service interaction with the site has been successfully activated.

[0886] In another possible implementation scenario, the device is applied to the source SFU. The various modules described above work together to implement the method flow executed by the source SFU in any of the embodiments corresponding to Figures 2A-10.

[0887] In one possible implementation:

[0888] The receiving module 1102 is configured to receive a roaming start indication message from the main optical network unit (MFU), wherein the roaming start indication message is used to indicate that roaming processing is initiated for the site; the SFU is either the source SFU currently accessed by the site or the target SFU determined by the MFU for roaming of the site.

[0889] The processing module is used to initiate roaming processing for the site.

[0890] In another possible embodiment,

[0891] The receiving module 1102 is configured to receive a roaming anomaly handling message from the main optical network unit (MFU) when the source sub-optical network unit (SFU) has initiated roaming processing for the site. The roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site. The source SFU is the SFU currently accessed by the site.

[0892] A processing module is used to clear roaming-related information for the site.

[0893] In another possible embodiment,

[0894] The receiving module 1102 is used to receive a service shutdown indication message from the main optical network unit (MFU) during the roaming process of the site. The service shutdown message is used to instruct the source SFU to shut down service interaction with the site.

[0895] The sending module 1101 is used to send a service shutdown feedback message to the MFU, the service shutdown feedback message being used to indicate whether the source SFU has successfully shut down the service interaction with the site.

[0896] In another possible embodiment,

[0897] The receiving module 1102 is configured to receive a first roaming error handling message from the main optical network unit (MFU) when the source sub-optical network unit (SFU) has initiated roaming processing for the site. The first roaming error handling message is used to indicate the restoration of the configuration before the roaming for the site was initiated. The target SFU is the target SFU for the site roaming handover.

[0898] Processing module 1101 restores the configuration for the site before roaming was initiated.

[0899] In another possible implementation scenario, the device is applied to the target SFU. The various modules described above work together to implement the method flow executed by the target SFU in any of the embodiments corresponding to Figures 2A-10.

[0900] In one possible implementation:

[0901] The receiving module 1102 is configured to receive a roaming start indication message from the main optical network unit (MFU), wherein the roaming start indication message is used to indicate that roaming processing is initiated for the site; the SFU is either the source SFU currently accessed by the site or the target SFU determined by the MFU for roaming of the site.

[0902] The processing module is used to initiate roaming processing for the site.

[0903] In another possible embodiment, the receiving module 1102 is configured to receive a roaming preprocessing message from the main optical network unit (MFU), the roaming preprocessing message being used to instruct the target SFU to initiate roaming preparation for the site;

[0904] The sending module 1101 is used to send a roaming preprocessing feedback message to the MFU, the roaming preprocessing feedback message being used to indicate whether the roaming preparation for the site is successful.

[0905] In another possible embodiment,

[0906] The receiving module 1102 is configured to receive a second roaming anomaly handling message from the main optical network unit (MFU) when the target sub-optical network unit (SFU) has initiated roaming processing for the site. The second roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site. The source SFU is the SFU currently accessed by the site.

[0907] A processing module is used to clear roaming-related information for the site.

[0908] In another possible embodiment,

[0909] The receiving module 1102 is used to receive a service activation indication message from the main optical network unit (MFU) during the roaming process of the site. The service activation indication message is used to instruct the target SFU to activate service interaction with the site.

[0910] The sending module 1101 is used to send a service activation feedback message to the MFU, the service activation feedback message being used to indicate whether the source SFU has successfully activated service interaction with the site.

[0911] For a detailed description of the roaming process of the roaming device shown in Figure 11, please refer to the descriptions in the previous embodiments; they will not be repeated here.

[0912] This application also provides a device 100. As shown in FIG12, device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other via the bus 102. Device 100 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in device 100.

[0913] Bus 102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 12, but this does not imply that there is only one bus or one type of bus. Bus 104 can include pathways for transmitting information between various components of device 100 (e.g., memory 106, processor 104, communication interface 108).

[0914] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0915] The memory 106 may include volatile memory, such as random access memory (RAM). The memory 106 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0916] The memory 106 stores executable program code, which the processor 104 executes to implement the roaming method. That is, the memory 106 stores program instructions for executing the roaming management method.

[0917] The communication interface 108 uses an optical module to enable communication between the device 100 and other devices or communication networks.

[0918] In one possible embodiment, processor 104 executes executable program code in memory 106 to implement the method flow executed by the source SFU in any of the embodiments corresponding to FIG2A-FIG10.

[0919] In another possible embodiment, processor 104 executes executable program code in memory 106 to implement the method flow executed by the target SFU in any of the embodiments corresponding to FIG2A-FIG10.

[0920] In another possible implementation, processor 104 executes executable program code in memory 106 to implement the method flow executed by MFU in any of the embodiments corresponding to Figures 2A-10.

[0921] This application also provides a computer program product, which includes program instructions stored in a computer-readable storage medium. A processor reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the processor to execute the MFU execution flow in Figures 2A-10, or the source SFU execution flow in Figures 2A-10, or the target SFU execution flow in Figures 2A-10.

[0922] One embodiment of this application provides a communication system including the aforementioned MFU, a source SFU, and a target SFU. Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the communication system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0923] One embodiment of this application provides a computer-readable medium for storing a computer program that includes instructions for executing method steps of the MFU in the method embodiments corresponding to FIG2A-FIG10, or instructions for executing method steps of the source SFU in the method embodiments corresponding to FIG2A-FIG10, or instructions for executing method steps of the target SFU in the method embodiments corresponding to FIG2A-FIG10.

[0924] Those skilled in the art will recognize that the method steps and units described in the embodiments disclosed in this application can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the steps and components of each embodiment have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0925] In the embodiments provided in this application, it should be understood that the disclosed system architecture, apparatus, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, or may be electrical, mechanical, or other forms of connection.

[0926] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0927] Furthermore, the modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or in software.

[0928] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0929] In this application, the terms "first" and "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first" and "second," nor does it limit the quantity or execution order. It should also be understood that although the following description uses the terms "first" and "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the scope of the various examples, a first access point can be referred to as a second access point, and similarly, a second access point can be referred to as a first access point. Both a first access point and a second access point can be access points, and in some cases, they can be separate and distinct access points.

[0930] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and such modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A roaming method, characterized in that, include: The main optical network unit (MFU) acquires roaming decision information from the system units (SFUs) in the network; The MFU determines the target SFU for the site based on the roaming decision information; The MFU sends a roaming start indication message to the target SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

2. The method as described in claim 1, characterized in that, The roaming start indication message is carried in the Wi-Fi management and control interface message.

3. The method as described in claim 1 or 2, characterized in that, The roaming initiation process includes initiating a roaming switching state machine.

4. The method according to any one of claims 1-3, characterized in that, The roaming start indication message includes the identifier of the site.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: The MFU receives a roaming start confirmation message from the target SFU, which indicates that the target SFU has successfully completed roaming initiation for the site.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: The MFU receives a roaming start failure message from the target SFU, the roaming start failure message indicating that the target SFU failed to initiate roaming for the site; The MFU removes roaming-related information for the site.

7. The method according to any one of claims 1-4, characterized in that, The method further includes: The MFU sends a roaming start indication message to the source SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

8. The method as described in claim 7, characterized in that, The method further includes: The MFU receives a roaming start confirmation message from the source SFU, which indicates that the source SFU has successfully completed roaming initiation for the site.

9. The method as described in claim 7, characterized in that, The method further includes: The MFU receives a roaming start failure message from the source SFU, the roaming start failure message indicating that the source SFU failed to initiate roaming for the site; The MFU removes roaming-related information for the site.

10. The method as described in claim 6 or 9, characterized in that, The method further includes: The MFU sends a roaming anomaly handling message to the source SFU and the target SFU. The roaming anomaly handling message is used to instruct the clearing of roaming-related information for the site.

11. The method as described in claim 10, characterized in that, The method further includes: The MFU receives a roaming exception handling completion message from the source SFU; and / or, The MFU receives the roaming exception handling completion message from the target SFU.

12. The method according to any one of claims 1-11, characterized in that, The roaming decision information includes one or more of the following: signal strength, load information, or channel condition information between the roaming station and the station.

13. A roaming method, characterized in that, include: The Sub-Optical Network Unit (SFU) receives a roaming start indication message from the Main Optical Network Unit (MFU). The roaming start indication message is used to indicate that roaming processing should be initiated for the site. The SFU is either the source SFU currently accessed by the site or the target SFU determined by the MFU for roaming of the site. The SFU initiates roaming processing for the site.

14. The method as described in claim 13, characterized in that, The roaming start indication message is carried in the Wi-Fi management and control interface message.

15. The method as described in claim 13 or 14, characterized in that, The roaming initiation process includes initiating a roaming switching state machine.

16. The method according to any one of claims 13-15, characterized in that, The roaming start indication message includes the identifier of the site.

17. The method according to any one of claims 13-16, characterized in that, The method further includes: The SFU sends the roaming start confirmation message to the MFU, the roaming start confirmation message indicating that the SFU has successfully completed the roaming initiation for the site.

18. The method according to any one of claims 13-16, characterized in that, The method further includes: The SFU sends a roaming start failure message to the MFU, the roaming start failure message indicating that the SFU failed to initiate roaming for the site.

19. The method as described in claim 18, characterized in that, The method further includes: The SFU receives a roaming exception handling message from the MFU, the roaming exception handling message being used to instruct the clearing of roaming-related information for the site; The SFU clears roaming-related information for the site.

20. The method as described in claim 19, characterized in that, The method further includes: The SFU sends a roaming exception handling completion message to the MFU.

21. The method according to any one of claims 13-20, characterized in that, The method further includes: The SFU sends roaming decision information to the MFU.

22. The method as described in claim 21, characterized in that, The roaming decision information includes one or more of the following: signal strength, load information, or channel condition information between the roaming station and the station.

23. A roaming device, characterized in that, Applied to the main optical network unit (MFU), including: The receiving module is used to acquire roaming decision information of SFUs in the network; The processing module is used to determine the target SFU for the site based on the roaming decision information; The sending module is used to send a roaming start indication message to the target SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

24. The apparatus as claimed in claim 23, characterized in that, The roaming start indication message is carried in the Wi-Fi management and control interface message.

25. The apparatus as claimed in claim 23 or 24, characterized in that, The roaming initiation process includes initiating a roaming switching state machine.

26. The apparatus according to any one of claims 23-25, characterized in that, The roaming start indication message includes the identifier of the site.

27. The apparatus according to any one of claims 23-26, characterized in that, The receiving module is further configured to: Receive a roaming start confirmation message from the target SFU, the roaming start confirmation message indicating that the target SFU has successfully completed roaming initiation for the site.

28. The apparatus according to any one of claims 23-26, characterized in that, The receiving module is further configured to receive a roaming start failure message from the target SFU, the roaming start failure message indicating that the target SFU failed to initiate roaming for the site; The processing module is also used to clear roaming-related information for the site.

29. The apparatus according to any one of claims 23-26, characterized in that, The sending module is also configured to send a roaming start indication message to the source SFU, the roaming start indication message being used to instruct the initiation of roaming processing for the site.

30. The apparatus as claimed in claim 29, characterized in that, The receiving module is further configured to receive a roaming start confirmation message from the source SFU, the roaming start confirmation message indicating that the source SFU has successfully completed the roaming initiation for the site.

31. The apparatus as claimed in claim 29, characterized in that, The receiving module is further configured to receive a roaming start failure message from the source SFU, the roaming start failure message indicating that the source SFU failed to initiate roaming for the site; The processing module is also used to clear roaming-related information for the site.

32. The apparatus as claimed in claim 29 or 31, characterized in that, The sending module is also used to send roaming exception handling messages to the source SFU and the target SFU, the roaming exception handling messages being used to instruct the clearing of roaming-related information for the site.

33. The apparatus as claimed in claim 32, characterized in that, The receiving module is further configured to receive a roaming exception handling completion message from the source SFU; and / or, receive the roaming exception handling completion message from the target SFU.

34. The apparatus according to any one of claims 23-33, characterized in that, The roaming decision information includes one or more of the following: signal strength, load information, or channel condition information between the roaming station and the station.

35. A roaming device, characterized in that, Applications to Sub-Optical Network Units (SFUs) include: The receiving module is used to receive a roaming start indication message from the main optical network unit (MFU), the roaming start indication message being used to indicate the initiation of roaming processing for the site; the SFU is either the source SFU currently accessed by the site or the target SFU determined by the MFU for roaming of the site. The processing module is used to initiate roaming processing for the site.

36. The apparatus as claimed in claim 35, characterized in that, The roaming start indication message is carried in the Wi-Fi management and control interface message.

37. The apparatus as claimed in claim 35 or 36, characterized in that, The roaming initiation process includes initiating a roaming switching state machine.

38. The apparatus according to any one of claims 35-37, characterized in that, The roaming start indication message includes the identifier of the site.

39. The apparatus according to any one of claims 35-38, characterized in that, The device further includes: The SFU sends the roaming start confirmation message to the MFU, the roaming start confirmation message indicating that the SFU has successfully completed the roaming initiation for the site.

40. The apparatus according to any one of claims 35-38, characterized in that, The device further includes: The SFU sends a roaming start failure message to the MFU, the roaming start failure message indicating that the SFU failed to initiate roaming for the site.

41. The apparatus as claimed in claim 40, characterized in that, The device further includes: The SFU receives a roaming exception handling message from the MFU, the roaming exception handling message being used to instruct the clearing of roaming-related information for the site; The SFU clears roaming-related information for the site.

42. The apparatus as claimed in claim 41, characterized in that, The device further includes: The SFU sends a roaming exception handling completion message to the MFU.

43. The apparatus according to any one of claims 35-42, characterized in that, The device further includes: The SFU sends roaming decision information to the MFU.

44. The apparatus as claimed in claim 43, characterized in that, The roaming decision information includes one or more of the following: signal strength, load information, or channel condition information between the roaming station and the station.

45. A roaming device, characterized in that, The roaming device includes a processor, a memory, and a communication interface; The processor is configured to execute program instructions in the memory to perform the processing functions in the roaming method as described in any one of claims 1 to 12; The communication interface is used to communicate with the Sub-Optical Network Unit (SFU).

46. ​​A roaming device, characterized in that, The roaming device includes a processor, a memory, and a communication interface; The processor is configured to execute program instructions in the memory to perform the processing functions in the roaming method as described in any one of claims 13 to 22; The communication interface is used to communicate with the main optical network unit (MFU).

47. A computer storage medium, characterized in that, The computer storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method of any one of claims 1-12, or cause the electronic device to perform the method of any one of claims 13-22.

48. A computer program product, characterized in that, When the program code contained in the computer program product is executed by a processor in an electronic device, the electronic device performs the method according to any one of claims 1-12, or performs the method according to any one of claims 13-22.

Images