Method for changing data frame length, electronic device, and storage medium

Abstract

The application discloses a method for changing data frame length, an electronic device and a storage medium, and belongs to the technical field of communication. The method comprises the following steps: when it is determined that the length of a data frame is changed from a first length to a second length, a controller sends a first command to a receiving end, the first command is used for instructing the receiving end to determine the length of the received data frame according to a frame length overhead in the data frame, the frame length overhead is included in the data frame and is used for instructing the length of the data frame; when it is determined that the receiving end successfully executes the first command, the controller sends a second command to a sending end, the second command carries a numerical value used for instructing the second length, and the second command is used for instructing the length of the data frame sent by the sending end to be changed to the second length; and when it is determined that the sending end successfully executes the second command, the controller sends a third command to the receiving end, the third command carries the numerical value of the second length and is used for instructing the receiving end to determine the length of the received data frame according to the second length.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and specifically relates to a method for changing the length of a data frame, an electronic device, and a storage medium. Background Technology

[0002] In an Optical Transport Network (OTN), low-speed services are typically configured in an Optical Service Unit (OSU). The frame fixing time of an OSU data frame is related to its rate and length. Since frame fixing must be completed within a certain time, when the OSU data frame rate is very low, the length of the OSU data frame must be short enough to meet the frame fixing time requirement. For high-speed OSUs, a shorter frame length means a very short frame fixing time, but the frame fixing time only needs to meet 3 milliseconds. Too short a frame fixing time has no additional benefits other than wasting bandwidth. Therefore, OSU data frames with at least two frame lengths are required: shorter frame lengths are used when the OSU rate is low, and longer frame lengths are used when the OSU rate is high.

[0003] To support two frame lengths, there are two implementation schemes. Scheme 1 involves the controller setting the frame length for both the transmitter and receiver. Scheme 2 involves the controller only setting the frame length for the transmitter, with the frame length information stored in the frame length overhead. The receiver identifies the frame length based on the frame length overhead. Since there are only two frame lengths, the receiver can initially frame the data using one length. If frame fixing fails, it can try the other length, and so on. If the transmitter sends one of the two frame lengths, the receiver will always be able to fix the frame. After successful frame fixing, the receiver can determine the frame length based on the frame length overhead, thus ensuring that the accurate frame header position is always identified. The OSU packet loading service needs to support lossless bandwidth adjustment, which requires support for lossless frame length switching, meaning that changing the frame length should not cause errors in overhead or payload. Analyzing the two schemes above, Scheme 1 is reliable, meaning that bit errors introduced during OSU transmission cannot cause frame length identification errors. However, it cannot support lossless frame length switching because the frame length change command sent by the controller is too slow and has a delay, making it impossible to guarantee that the sending and receiving ends receive the switching command simultaneously. Furthermore, the delay generated during frame transmission is uncertain. Scheme 2 supports lossless frame length switching, but if bit errors occur during OSU transmission and cause errors in frame length overhead, frame length identification errors will occur, severely impacting services within the OSU. Additionally, the receiving end needs to repeatedly switch between the two frame lengths during frame fixing, which further prolongs the frame fixing time for lower-speed OSUs.

[0004] Currently, there is no good solution that allows the OSU to support two different frame lengths while addressing the shortcomings of the above solutions. Therefore, there is an urgent need for a method to change the data frame length so that even with bit errors, frame length identification will not be incorrect in most cases, and the overhead and payload of the data frame will remain unaffected when changing the data frame length. Summary of the Invention

[0005] This application provides a method, electronic device, and storage medium for changing the length of a data frame, which can prevent frame length identification errors in most cases even with bit errors, while ensuring that the overhead and payload of the data frame remain unaffected when changing the data frame length.

[0006] In a first aspect, embodiments of this application provide a method for changing the length of a data frame. The method includes: when a controller determines that the length of a data frame will be changed from a first length to a second length, sending a first command to a receiving end, wherein the first command instructs the receiving end to determine the length of the received data frame based on a frame length overhead in the data frame, the data frame including the frame length overhead indicating the length of the data frame; a sending end transmitting the data frame; and a receiving end receiving the data frame transmitted by the sending end. If the controller determines that the receiving end has successfully executed the first command, sending a second command to the sending end, wherein the second command carries a value indicating the second length, and the second command instructs the sending end to change the length of the data frame to the second length. If the controller determines that the sending end has successfully executed the second command, sending a third command to the receiving end, wherein the third command carries a value indicating the second length, and the third command instructs the receiving end to determine the length of the received data frame based on the second length.

[0007] In a second aspect, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0008] Thirdly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] In this embodiment, when the controller determines that the length of the data frame needs to be changed from a first length to a second length, it sends a first command to the receiving end. The first command instructs the receiving end to determine the length of the received data frame based on the frame length overhead in the data frame. The data frame includes frame length overhead, which indicates the length of the data frame. The sending end sends the data frame, and the receiving end receives the data frame sent by the sending end. If the controller determines that the receiving end has successfully executed the first command, it sends a second command to the sending end. The second command carries a value indicating the second length and instructs the sending end to change the length of the data frame to the second length. If the controller determines that the sending end has successfully executed the second command, it sends a third command to the receiving end. The third command carries a value indicating the second length and instructs the receiving end to determine the length of the received data frame based on the second length. This approach ensures that frame length identification will not be incorrect in most cases, even with bit errors, and that the overhead and payload of the data frame remain intact when changing the data frame length. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a method for changing the length of a data frame according to an embodiment of this application;

[0011] Figure 2 This is a schematic diagram of the structure of a system for changing the length of a data frame provided in an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] The method, electronic device, and storage medium for changing the data frame length provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0016] Figure 1 An embodiment of this application illustrates a method for changing the length of a data frame, the method comprising the following steps:

[0017] Step 102: When the controller determines that the length of the data frame will be changed from the first length to the second length, it sends a first command to the receiving end.

[0018] In this step, the administrator can issue commands to the controller. Upon receiving a user's command to change the data frame length, the controller determines that the data frame length needs to be changed from a first length to a second length. It then sends a first command to the receiving end, instructing it to determine the length of the received data frame based on the frame length overhead. The data frame includes frame length overhead, which indicates the data frame length. The receiving end receives data frames sent by the sending end, and the sending end sends data frames. After receiving the first command, the receiving end sets its data frame identification method to determine the data frame length through the frame length overhead, and then defines the data frame based on its length.

[0019] As an example, a data frame consists of B rows of data blocks. Each data block contains a fixed number of bits, and each row contains C data blocks, meaning the data frame comprises B*C data blocks. Of the B*C data blocks in the data frame, the first N blocks are fixed overhead, and the last B*CN blocks are fixed payload. Within the fixed overhead of the data frame, there is a frame length overhead, which indicates the length of the data frame. The length of the data frame is B*C, and the unit of length is data blocks; that is, the length of the data frame is B*C data blocks. If a data block contains D bits, then the length of the data frame is B*C*D bits. The content of the frame length overhead may be B*C or B*C*D.

[0020] In a data frame, the frame length overhead is always present. When the receiving end receives the first command, it can identify the frame length overhead and determine the length of the data frame through the frame length overhead, and then frame the data frame.

[0021] In this way, when the length of the data frame sent by the sending end changes from the first length to the second length, the receiving end can identify the frame length overhead of the data frame and determine the second length of the data frame based on the frame length overhead. Then, it can fix the frame of the received data frame. This allows the sending end and the receiving end to change the frame length at the same time, ensuring that the data frame can be correctly identified during the data frame length switching process, thereby achieving lossless switching of data frame length.

[0022] Step 104: If the controller determines that the receiving end has successfully executed the first command, it sends a second command to the sending end.

[0023] Specifically, upon confirming that the receiving end has successfully executed the first command, it can send a second command to the sending end. This second command carries a value indicating a second length, instructing the sending end to change the length of the data frame to the second length. That is, after receiving the second command, the sending end can change the length of the transmitted data frame from the first length to the second length according to the second command. Since the frame length overhead in the data frame is always present, when the frame length of the data frame is changed to the second length, the corresponding frame length overhead also corresponds to the second length. It should be understood that after receiving the second command, the sending end does not necessarily need to immediately change the length of the transmitted data frame to the second length. It can send a preset number of data frames and then generate data frames according to the second length in the second command. This preset number can be set in advance and is not specifically limited here. As an example, suppose the first length of the data frame sent by the sender is L1. The controller sends a second command to the sender, which includes a value L2 to indicate the second length. After receiving the second command, the sender can change the length of the data frame to be sent from the first length L1 to the second length L2, and then send a data frame with a frame length of L2.

[0024] After confirming that the receiving end of the data frame has been configured to determine the length of the data frame using the frame length overhead in the received data frame, the second command is then sent to the sending end. In this way, if the frame length of the data frame sent by the sending end changes, the receiving end can reframe the data frame according to the frame length overhead. This allows both the sending and receiving ends to change the frame length simultaneously, ensuring lossless switching of the data frame length.

[0025] Step 106: If the controller determines that the sending end has successfully executed the second command, it sends a third command to the receiving end.

[0026] In this step, if the controller determines that the sending end has successfully executed the second command, it indicates that the sending end has changed the transmitted data frame from the first length to the second length. The controller can then send a third command to the receiving end. This third command carries the value of the second length and instructs the receiving end to determine the length of the received data frame based on the second length, and then frame the data frame using the second length. Since the length of the received data frame has changed from the first length to the second length, after receiving the third command, the receiving end no longer needs to determine the length of the received data frame based on the frame length overhead. It can determine the length of the received data frame based on the second length in the third command and then perform the frame framing operation. This avoids incorrect identification of the data frame length due to errors in the frame length overhead content.

[0027] As an example, suppose the third command carries a value L2 of the second length. If the controller determines that the sending end has successfully executed the second command, it can send the third command to the receiving end. After receiving the third command, the receiving end no longer determines the length of the data frame based on the frame length overhead in the received data frame. Instead, it determines the length of the received data frame based on the second length L2 and then frames the received data frame.

[0028] In this embodiment, when the controller determines that the length of a data frame needs to be changed from a first length to a second length, it sends a first command to the receiving end. The first command instructs the receiving end to determine the length of the received data frame based on the frame length overhead in the data frame. The data frame includes frame length overhead, which indicates the length of the data frame. The receiving end receives the data frame sent by the sending end, and the sending end sends the data frame. If the controller determines that the receiving end has successfully executed the first command, it sends a second command to the sending end. The second command carries a value indicating the second length and instructs the sending end to change the length of the data frame to the second length. If the controller determines that the sending end has successfully executed the second command, it sends a third command to the receiving end. The third command carries a value indicating the second length and instructs the receiving end to determine the length of the received data frame based on the second length. The controller sends the second command to the sending end only after confirming that the sending end has configured framing based on the frame length overhead in the received data frame. Thus, when the frame length of the data frame sent by the sending end changes, the receiving end can simultaneously change the frame length, ensuring lossless switching of the data frame length.

[0029] Furthermore, if the sending end successfully executes the second command, then the third command is sent to the receiving end. Since the length of the data frame received by the receiving end has changed from the first length to the second length, the receiving end no longer needs to determine the length of the received data frame based on the frame length overhead in the received data frame after receiving the third command. The receiving end can determine the length of the received data frame based on the second length in the third command, and then perform framing operations on the received data frame. This avoids incorrect identification of the data frame length due to errors in the frame length overhead content, and ensures that the overhead and payload of the data frame are lossless when changing the data frame length.

[0030] In one implementation, the data frame further includes frame length overhead, the content of which is used to determine the length of the data frame in which the frame length overhead is located. The sending end writes the length of the data frame into the frame length overhead according to the length of the currently transmitted data frame. The data frame also includes frame positioning overhead, the content of which is fixed bit information. The sending end writes the fixed bit information into the frame positioning overhead. The receiving end determines the expected frame positioning overhead position of the data frame according to the length of the data frame and the content of the frame positioning overhead.

[0031] Specifically, the data frame also includes a frame length overhead. The content of the frame length overhead determines the length of the data frame to which the frame length overhead is located. Regardless of whether the sending end receives the second command, it needs to write the length of the data frame into the frame length overhead. When the sending end receives the second command, it also needs to modify the content of the frame length overhead according to the second length. During the data frame generation process, the sending end can write a frame positioning overhead into the frame positioning overhead. The frame positioning overhead is usually located at the beginning of the data frame, and its content can be fixed bit information. After the receiving end receives the data frame, it can search for and identify the fixed bit information in the data frame. If the fixed bit information is identified, the frame positioning overhead of the data frame can be determined. Furthermore, the receiving end can frame the data frame based on the frame length overhead or the predetermined data frame length, and can determine the expected frame positioning overhead position of the next received data frame based on the data frame length and the frame positioning overhead content. Thus, after receiving the next data frame, the frame positioning overhead can be found based on the expected frame positioning overhead position.

[0032] In one implementation, the receiving end determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead, including:

[0033] When the receiving end does not find the fixed bit information at the expected frame positioning overhead position, it searches for the expected frame positioning overhead position again based on the fixed bit information and the length of the data frame. When the receiving end finds the fixed bit information at the expected frame positioning overhead position, it uses the expected frame positioning overhead position as the new frame positioning overhead position by shifting the expected frame positioning overhead position backward by the length of the data frame. When the receiving end finds the fixed bit information at the expected frame positioning overhead position, all overhead content of the data frame is valid. When the receiving end does not find the fixed bit information at the expected frame positioning overhead position, all overhead content of the data frame is invalid.

[0034] Specifically, after receiving a data frame, the receiving end can search for fixed bit information at the expected frame positioning overhead position. If the receiving end does not find the fixed bit information at the expected frame positioning overhead position, it can continue to identify and search for the fixed bit information. After finding the fixed bit information, the position of the fixed bit information is moved backward by the length of the data frame as the expected frame positioning overhead position. Subsequently, it continues to search for the presence of fixed bit information at the expected frame positioning overhead position. Moving backward means moving towards the direction of the unreceived data frame. The length of the data frame can be determined either by the frame length overhead in the data frame or by a fixed value in the received command.

[0035] When the receiving end can find the fixed bit information at the expected frame positioning overhead position, it can determine the expected frame positioning overhead position as the frame positioning overhead position of the current data frame, and move the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. The length of the data frame can be determined either by the frame length overhead in the data frame or by a fixed value in the received command.

[0036] In this way, if the fixed bit information is not found at the expected frame positioning overhead position, the search for fixed bit information can continue. Upon finding the fixed bit information, the position of the fixed bit information is shifted forward by the length of the data frame containing it to obtain the expected frame positioning overhead position. The search continues at this expected frame positioning overhead position. When the fixed bit information is found at the expected frame positioning overhead position, this position is determined as the frame positioning overhead position of the current data frame. The new expected frame positioning overhead position is then shifted forward by the length of the data frame. The search continues at this new expected frame positioning overhead position. This process ensures that the receiving end can correctly identify the accurate position of the data frame's overhead and payload based on the fixed bit information and the data frame length.

[0037] Furthermore, when the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of all overhead in the data frame containing the fixed bit information is valid, meaning all overhead content of the data frame can be used normally. Conversely, if the receiving end does not find the fixed bit information at the expected frame positioning overhead position, indicating an error in the data frame search, the content of all overhead in the data frame currently containing the expected frame positioning overhead position is invalid, meaning all overhead in the current data frame cannot be used.

[0038] In one implementation, the step of re-locating the desired frame positioning overhead position based on the fixed bit information and the length of the data frame includes:

[0039] The receiving end searches for the fixed bit information among all received bits until it finds the fixed bit information; after finding the fixed bit information, the position of the fixed bit information is shifted backward by the length of the data frame as the expected frame positioning overhead position.

[0040] Specifically, the data frames received by the receiver are actually presented in bit form. The receiver can only consider the expected frame positioning overhead position to be the location of the frame positioning overhead if it finds fixed bit information at the expected frame positioning overhead position. Initially, any position can be used as the expected frame positioning overhead position. If fixed bit information is found at the expected frame positioning overhead position, the expected frame positioning overhead position is considered to be the location of the frame positioning overhead, and the expected frame positioning overhead position is shifted forward by the length of the data frame to become the new expected frame positioning overhead position. If fixed bit information cannot be found at the expected frame positioning overhead position, the search continues bit by bit forward until the fixed bit information position is found, and the found fixed bit information position is shifted forward by the length of the data frame to become the new expected frame positioning overhead position. This process is repeated.

[0041] To prevent bit errors from affecting the search for fixed bit information, it can be required that the expected frame positioning overhead position is considered the location of the frame positioning overhead only after the fixed bit information has been found multiple times consecutively. This expected frame positioning overhead position is maintained as the location of the frame positioning overhead until the fixed bit information cannot be found at the expected frame positioning overhead position multiple times consecutively. If, when the expected frame positioning overhead position is considered the location of the frame positioning overhead, the fixed bit information cannot be found at the expected frame positioning overhead position multiple times consecutively, then the frame positioning overhead position is considered unfindable until the fixed bit information is found at the expected frame positioning overhead position multiple times consecutively.

[0042] In one implementation, after sending the first command to the receiving end, the method further includes:

[0043] When the first command does not carry the value indicating the second length and the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is valid. The receiving end uses the content of the frame length overhead as the length of the data frame and moves the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. When the first command does not carry the value indicating the second length and the receiving end does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid. The receiving end uses the content from the last time the frame length overhead was valid as the length of the data frame and re-finds the expected frame positioning overhead position based on the fixed bit information and the length of the data frame.

[0044] Specifically, after the controller sends the first command to the receiver, if the first command does not carry a value indicating the second length and the receiver finds fixed bit information at the expected frame positioning overhead position, then the content of the frame length overhead of the data frame at the current expected frame positioning overhead position is valid. The length of the corresponding data frame can be determined through this frame length overhead content. Furthermore, this frame length overhead content can be used as the length of the data frame to determine the new expected frame positioning overhead position. The length of the data frame shifted backward from the current expected frame positioning overhead position is used as the new expected frame positioning overhead position. This backward shift is in the direction of unreceived data frames. In this way, after receiving the next data frame, the above operation can continue to be performed to check whether the new expected frame positioning overhead position contains fixed bit information, thereby determining whether the frame positioning overhead of the new data frame is at the new expected frame positioning overhead position.

[0045] If the first command does not carry a value indicating the second length and the receiver does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead of the current data frame is invalid. The receiver can use the content when the frame length overhead was valid last time as the length of the data frame. The receiver searches for the fixed bit information again among all the received bits. After finding the fixed bit information, it can use the content when the frame length overhead was valid last time as the length of the data frame. The fixed bit information is moved backward from the position of the content when the frame length overhead was valid last time as the new expected frame positioning overhead position. In this way, the above operation can continue to be performed to check whether the fixed bit information exists at the new expected frame positioning overhead position, thereby determining whether the frame positioning overhead of the new data frame is at the new expected frame positioning overhead position.

[0046] In one implementation, when the first command carries the value used to indicate the second length and the receiving end finds the fixed bit information at the desired frame positioning overhead position, the content of the frame length overhead is valid, and the receiving end uses the content of the frame length overhead as the length of the data frame, and moves the desired frame positioning overhead position backward by the length of the data frame as the new desired frame positioning overhead position.

[0047] When the first command carries the value used to indicate the second length and the receiving end does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid. The receiving end uses the second length as the length of the data frame and searches for the expected frame positioning overhead position again based on the fixed bit information and the length of the data frame.

[0048] Specifically, after the controller sends the first command to the receiver, if the first command carries a value indicating the second length and the receiver finds fixed bit information at the expected frame positioning overhead position, then the content of the frame length overhead of the data frame at the current expected frame positioning overhead position becomes valid. The length of the corresponding data frame can be determined through this frame length overhead content. Furthermore, this frame length overhead content can be used as the length of the data frame to determine the new expected frame positioning overhead position. The length of the data frame shifted backward from the current expected frame positioning overhead position is then used as the new expected frame positioning overhead position. This backward shift is in the direction of unreceived data frames. In this way, after receiving the next data frame, the above operation can continue to be performed to check whether the fixed bit information exists at the new expected frame positioning overhead position, thereby determining whether the frame positioning overhead of the new data frame is at the new expected frame positioning overhead position.

[0049] If the first command carries a value indicating the second length and the receiver does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead of the current data frame is invalid. The receiver can use the second length as the length of the data frame. The receiver searches for the fixed bit information again in the received bits. After finding the fixed bit information, the receiver can use the second length as the length of the data frame. The receiver moves the second length backward from the position of the fixed bit information as the new expected frame positioning overhead position. The receiver continues to perform the above operation and checks whether the fixed bit information exists at the new expected frame positioning overhead position, thereby determining whether the frame positioning overhead of the new data frame is at the new expected frame positioning overhead position.

[0050] In one implementation, the second command carries a numerical value indicating the second length, and after sending the second command to the sending end, it further includes:

[0051] The sending end writes the value of the second length into the frame length overhead and uses the second length as the length of the data frame.

[0052] Specifically, the second command sent by the controller carries a value for a second length. After the controller sends the second command to the sending end, the sending end can write the value of the second length into the frame length overhead of the data frame during the data frame generation process, and use the second length as the length of the generated data frame. In this way, after the receiving end receives the first command, and then the sending end receives the second command, it changes the length of the generated data frame to the second length. This allows the sending end and the receiving end to change the frame length simultaneously, ensuring that the data frame can be correctly identified during the data frame length switching process, thereby achieving lossless switching of the data frame length.

[0053] In one implementation, after sending the third command to the receiving end, the method further includes:

[0054] The receiving end uses the second length as the length of the data frame, and determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead position.

[0055] Specifically, after the controller sends the third command to the receiver, since the third command carries the value of the second length, the receiver uses the second length as the length of all received data frames. Based on the length of the data frame and the fixed bit information, the receiver determines the expected frame positioning overhead position of the data frame and checks whether the fixed bit information exists at the expected frame positioning overhead position, thereby determining whether the frame positioning overhead of the data frame is at the expected frame positioning overhead position.

[0056] In one implementation, the method further includes:

[0057] When the receiving end receives the first command, it returns a response message indicating that the first command was successfully executed; when the sending end receives the second command, it returns a response message indicating that the second command was successfully executed; when the receiving end receives the third command, it returns a response message indicating that the third command was successfully executed.

[0058] Specifically, upon receiving the first command, the receiving end can return a confirmation message to the controller indicating successful execution of the first command. Upon receiving the second command, the sending end can return a confirmation message to the controller indicating successful execution of the second command. Upon receiving the third command, the receiving end can return a confirmation message to the controller indicating successful execution of the third command.

[0059] In this way, the controller can determine whether the receiver has successfully executed the first or third command based on whether it receives a response message from the receiver, and it can also determine whether the sender has successfully executed the second command based on whether it receives a response message from the sender.

[0060] In one implementation, after sending the first command to the receiving end, the method further includes:

[0061] The controller waits until it receives a response indicating that the first command was executed successfully, then determines that the receiving end has successfully executed the first command, or waits until a preset time has elapsed without receiving a response indicating that the first command was executed successfully. If the controller fails to receive a response indicating that the first command was executed successfully within the preset time after sending the first command a preset number of times, then determines that the receiving end has failed to execute the first command. After sending the second command to the sending end, the method further includes: the controller waits until it receives a response indicating that the second command was executed successfully, then determines that the sending end has executed the second command successfully, or waits until the preset time has elapsed without receiving a response indicating that the second command was executed successfully. If the controller sends the second command a preset number of times and does not receive a response indicating successful execution of the second command within a preset time period after each sending of the second command, the controller determines that the sending end has failed to execute the second command. After sending the third command to the receiving end, the method further includes: if the controller waits until it receives a response indicating successful execution of the third command, it determines that the receiving end has successfully executed the third command, or waits until the preset time period expires without receiving a response indicating successful execution of the third command. If the controller sends the third command a preset number of times and does not receive a response indicating successful execution of the third command within a preset time period after each sending of the third command, the controller determines that the receiving end has failed to execute the third command.

[0062] Specifically, after sending the first command to the receiving end, the controller can wait until it receives a response indicating that the first command was executed successfully. At this point, it can determine that the receiving end has successfully executed the first command. Alternatively, if it waits until a preset time has elapsed without receiving a response indicating that the first command was executed successfully, it can resend the first command to the receiving end. If the controller fails to receive a response indicating that the first command was executed successfully within a preset time after each sending of the first command, it can determine that the receiving end has failed to execute the first command. In this way, the controller can determine whether the receiving end has successfully executed the first command by checking whether it has received a response indicating that the first command was executed successfully. The preset time and preset number of times can be set according to actual needs and are not specifically limited here.

[0063] After sending the second command to the sending end, the controller can wait until it receives a response indicating successful execution of the second command. It can then determine if the sending end has successfully executed the second command, or wait until a preset time has elapsed without receiving a response indicating successful execution. In this case, it resends the second command to the sending end. If the controller sends the second command a preset number of times and does not receive a response indicating successful execution within a preset time after each transmission, it determines that the sending end has failed to execute the second command. In this way, the controller can determine whether the sending end has successfully executed the second command based on whether it has received a response indicating successful execution.

[0064] After sending a third command to the receiving end, the controller can wait until it receives a successful response, at which point it can determine that the receiving end has successfully executed the third command. Alternatively, if no successful response is received after a preset time, the controller can resend the third command to the receiving end. If the controller sends a preset number of third commands and does not receive a successful response within a preset time after each command transmission, it can determine that the receiving end has failed to execute the third command. Thus, the controller can determine whether the receiving end has successfully executed the third command based on whether it has received a successful response from the receiving end.

[0065] In one implementation, after sending the third command to the receiving end, the method further includes:

[0066] After determining that the receiving end successfully executes the third command, the controller determines that changing the length of the data frame from the first length to the second length is successful; after determining that the receiving end fails to execute the first command, the sending end fails to execute the second command, or the receiving end fails to execute the third command, the controller determines that changing the length of the data frame from the first length to the second length is unsuccessful.

[0067] Specifically, after the controller determines that the receiving end has successfully executed the third command, it can determine that the sending end has sent a data frame with a second length. The receiving end can also use the second length as the length of the received data frame and then frame the received data frame. In this way, it can be determined that the length of the data frame has been successfully changed from the first length to the second length.

[0068] Furthermore, the controller can determine that changing the length of the data frame from the first length to the second length has failed once it determines that the receiving end has failed to execute the first command, the sending end has failed to execute the second command, or the receiving end has failed to execute the third command.

[0069] It should be noted that the method for changing the data frame length provided in this application embodiment can be executed by a device for changing the data frame length, or by a control module within that device for executing the method for changing the data frame length. This application embodiment uses an example of a device for changing the data frame length executing the method for changing the data frame length to illustrate the device for changing the data frame length provided in this application embodiment.

[0070] Figure 2 This is a schematic diagram of the structure of a system for changing the length of a data frame according to an embodiment of this application. Figure 2 As shown, the system 200 for changing the data frame length includes: a controller 210, a receiver 220, and a transmitter 230.

[0071] When controller 210 determines that the length of a data frame needs to be changed from a first length to a second length, it sends a first command to receiver 220. The first command instructs receiver 220 to determine the length of the received data frame based on the frame length overhead in the data frame, where the frame length overhead indicates the length of the data frame. Receiver 220 sends the data frame, and receiver 220 receives the data frame sent by sender 230. If controller 210 determines that receiver 220 has successfully executed the first command, it sends a second command to sender 230. The second command carries a value indicating the second length and instructs sender 230 to change the length of the data frame sent by sender 230 to the second length. If controller 210 determines that sender 230 has successfully executed the second command, it sends a third command to receiver 220. The third command carries a value indicating the second length and instructs receiver 220 to determine the length of the received data frame based on the second length.

[0072] In one implementation, the data frame further includes frame length overhead, the content of which is used to determine the length of the data frame in which the frame length overhead is located. The sending end 230 writes the length of the data frame into the frame length overhead according to the length of the currently transmitted data frame. The data frame also includes frame positioning overhead, the content of which is fixed bit information. The sending end 230 writes the fixed bit information into the frame positioning overhead. The receiving end 220 determines the expected frame positioning overhead position of the data frame according to the length of the data frame and the content of the frame positioning overhead.

[0073] In one implementation, when the receiving end 220 does not find the fixed bit information at the expected frame positioning overhead position, it searches for the expected frame positioning overhead position again based on the fixed bit information and the length of the data frame. When the receiving end 220 finds the fixed bit information at the expected frame positioning overhead position, it uses the expected frame positioning overhead position as the new frame positioning overhead position by shifting the expected frame positioning overhead position backward by the length of the data frame. When the receiving end 220 finds the fixed bit information at the expected frame positioning overhead position, all overhead content of the data frame is valid. When the receiving end 220 does not find the fixed bit information at the expected frame positioning overhead position, all overhead content of the data frame is invalid.

[0074] In one implementation, the receiver 220 searches for the fixed bit information among all received bits until it finds the fixed bit information; after finding the fixed bit information, the position of the fixed bit information is shifted backward by the length of the data frame as the desired frame positioning overhead position.

[0075] In one implementation, when the first command does not carry the value indicating the second length and the receiver 220 finds the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is valid. The receiver 220 uses the content of the frame length overhead as the length of the data frame and moves the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. When the first command does not carry the value indicating the second length and the receiver 220 does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid. The receiver 220 uses the content from the previous valid frame length overhead position as the length of the data frame and re-finds the expected frame positioning overhead position based on the fixed bit information and the length of the data frame.

[0076] In one implementation, when the first command carries the value indicating the second length and the receiver 220 finds the fixed bit information at the desired frame positioning overhead position, the content of the frame length overhead is valid. The receiver 220 uses the content of the frame length overhead as the length of the data frame and moves the desired frame positioning overhead position backward by the length of the data frame as the new desired frame positioning overhead position. When the first command carries the value indicating the second length and the receiver 220 does not find the fixed bit information at the desired frame positioning overhead position, the content of the frame length overhead is invalid. The receiver 220 uses the second length as the length of the data frame and re-searches for the desired frame positioning overhead position based on the fixed bit information and the length of the data frame.

[0077] In one implementation, the transmitting end 230 writes the value of the second length into the frame length overhead and uses the second length as the length of the data frame.

[0078] In one implementation, the receiving end 220 uses the second length as the length of the data frame, and determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead position.

[0079] In one implementation, when the receiving end 220 receives the first command, it returns a response message indicating that the first command was successfully executed; when the sending end 230 receives the second command, it returns a response message indicating that the second command was successfully executed; and when the receiving end 220 receives the third command, it returns a response message indicating that the third command was successfully executed.

[0080] In one implementation, the controller 210 waits until it receives a response indicating that the first command was executed successfully, then determines that the receiving end 220 executed the first command successfully, or waits until a preset time has elapsed without receiving a response indicating that the first command was executed successfully. If the controller 210 fails to receive a response indicating that the first command was executed successfully after sending the first command a preset number of times and within the preset time after each sending of the first command, it determines that the receiving end 220 failed to execute the first command. The controller 210 waits until it receives a response indicating that the second command was executed successfully, then determines that the sending end 230 executed the second command successfully, or waits until the preset time has elapsed without receiving a response indicating that the second command was executed successfully. If the controller 210 sends the second command the preset number of times and does not receive a response indicating successful execution of the second command within the preset time after each sending of the second command, it determines that the sending end 230 has failed to execute the second command. If the controller 210 waits until it receives a response indicating successful execution of the third command, it determines that the receiving end 220 has successfully executed the third command, or waits until the preset time has elapsed without receiving a response indicating successful execution of the third command. If the controller 210 sends the third command the preset number of times and does not receive a response indicating successful execution of the third command within the preset time after each sending of the third command, it determines that the receiving end 220 has failed to execute the third command.

[0081] In one implementation, after determining that the receiving end 220 has successfully executed the third command, the controller 210 determines that changing the length of the data frame from the first length to the second length has been successful; after determining that the receiving end 220 has failed to execute the first command, that the sending end 230 has failed to execute the second command, or that the receiving end 220 has failed to execute the third command, the controller 210 determines that changing the length of the data frame from the first length to the second length has failed.

[0082] The system for changing the data frame length provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0083] Optionally, such as Figure 3As shown, this application embodiment also provides an electronic device 300, including a processor 301 and a memory 302. The memory 302 stores a program or instructions that can run on the processor 301. When the program or instructions are executed by the processor 301, the following is implemented: when the controller determines that the length of a data frame will be changed from a first length to a second length, it sends a first command to the receiving end. The first command instructs the receiving end to determine the length of the received data frame based on the frame length overhead in the data frame. The data frame includes the frame length overhead, which indicates the length of the data frame. The sending end transmits the data frame. The receiving end is used to receive the data frame sent by the sending end; if the controller determines that the receiving end has successfully executed the first command, it sends a second command to the sending end, wherein the second command carries a value indicating the second length, and the second command is used to instruct the length of the data frame sent by the sending end to be changed to the second length; if the controller determines that the sending end has successfully executed the second command, it sends a third command to the receiving end, wherein the third command carries a value of the second length, and the third command is used to instruct the receiving end to determine the length of the received data frame according to the second length.

[0084] In one implementation, the data frame further includes frame length overhead, the content of which is used to determine the length of the data frame in which the frame length overhead is located. The sending end writes the length of the data frame into the frame length overhead according to the length of the currently transmitted data frame. The data frame also includes frame positioning overhead, the content of which is fixed bit information. The sending end writes the fixed bit information into the frame positioning overhead. The receiving end determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead, and determines whether the frame positioning overhead of the data frame is at the expected frame positioning overhead position.

[0085] In one implementation, when the receiving end does not find the fixed bit information at the expected frame positioning overhead position, it re-searches for the expected frame positioning overhead position based on the fixed bit information and the length of the data frame. When the receiving end finds the fixed bit information at the expected frame positioning overhead position, it uses the expected frame positioning overhead position as the new frame positioning overhead position by shifting the expected frame positioning overhead position backward by the length of the data frame. When the receiving end finds the fixed bit information at the expected frame positioning overhead position, all overhead content of the data frame is valid. When the receiving end does not find the fixed bit information at the expected frame positioning overhead position, all overhead content of the data frame is invalid.

[0086] In one implementation, the data frame further includes a frame length overhead, the contents of which are used to determine the length of the data frame containing the frame length overhead. The sending end writes the length of the data frame into the frame length overhead according to the length of the currently transmitted data frame. The receiving end searches for the fixed bit information in all received bits until it is found. After finding the fixed bit information, the position of the fixed bit information is shifted backward by the length of the data frame as the desired frame positioning overhead position.

[0087] In one implementation, after sending a first command to the receiving end, if the first command does not carry the value indicating the second length and the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is valid. The receiving end uses the content of the frame length overhead as the length of the data frame and moves the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. If the first command does not carry the value indicating the second length and the receiving end does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid. The receiving end uses the content from the previous valid frame length overhead position as the length of the data frame and re-finds the expected frame positioning overhead position based on the fixed bit information and the length of the data frame.

[0088] In one implementation, after sending a first command to the receiving end, if the first command carries the value indicating the second length and the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is valid, and the receiving end uses the content of the frame length overhead as the length of the data frame, shifting the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position; if the first command carries the value indicating the second length and the receiving end does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid, and the receiving end uses the second length as the length of the data frame, re-finding the expected frame positioning overhead position based on the fixed bit information and the length of the data frame.

[0089] In one implementation, the second command carries a value indicating the second length. After sending the second command to the sending end, the sending end writes the value of the second length into the frame length overhead and uses the second length as the length of the data frame.

[0090] In one implementation, after sending the third command to the receiving end, the receiving end uses the second length as the length of the data frame, and determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead position.

[0091] In one implementation, when the receiving end receives the first command, it returns a response message indicating that the first command was successfully executed; when the sending end receives the second command, it returns a response message indicating that the second command was successfully executed; and when the receiving end receives the third command, it returns a response message indicating that the third command was successfully executed.

[0092] In one implementation, after sending the first command to the receiving end, the controller waits until it receives a response indicating that the first command was executed successfully, then determines that the receiving end has successfully executed the first command, or waits until a preset time has elapsed without receiving a response indicating that the first command was executed successfully. If the controller sends the first command a preset number of times and does not receive a response indicating that the first command was executed successfully within the preset time after each sending of the first command, it determines that the receiving end has failed to execute the first command. The controller waits until it receives a response indicating that the second command was executed successfully, then determines that the sending end has successfully executed the second command, or waits until the preset time has elapsed without receiving a response indicating that the second command was executed successfully. If the controller sends the second command a preset number of times and does not receive a successful response message for the second command within the preset time period after each sending of the second command, it determines that the sending end has failed to execute the second command; if the controller waits until it receives a successful response message for the third command, it determines that the receiving end has successfully executed the third command, or waits until the preset time period expires without receiving a successful response message for the third command; if the controller sends the third command a preset number of times and does not receive a successful response message for the third command within the preset time period after each sending of the third command, it determines that the receiving end has failed to execute the third command.

[0093] In one implementation, after sending a third command to the receiving end, the controller determines that changing the length of the data frame from the first length to the second length is successful after determining that the receiving end has successfully executed the third command; if the controller determines that the receiving end has failed to execute the first command, the sending end has failed to execute the second command, or the receiving end has failed to execute the third command, the controller determines that changing the length of the data frame from the first length to the second length is unsuccessful.

[0094] The specific execution steps can be found in the various steps of the above-described method embodiment for changing the data frame length, and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0095] It should be noted that the electronic devices in the embodiments of this application include: servers, terminals, or other devices besides terminals.

[0096] The above electronic device structure does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or arrange them differently. For example, an input unit may include a Graphics Processing Unit (GPU) and a microphone, and a display unit may use a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar display panels. User input units include at least one of a touch panel and other input devices. A touch panel is also called a touchscreen. Other input devices may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be elaborated further here.

[0097] Memory can be used to store software programs and various data. Memory can primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area can store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, memory can include volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0098] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly handles operations related to the operating system, user interface, and applications, while the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor.

[0099] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described method embodiments for changing the length of a data frame and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0100] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as ROM, RAM, magnetic disk, or optical disk.

[0101] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

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

[0103] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for changing the length of a data frame, characterized in that, include: When the controller determines that the length of the data frame should be changed from a first length to a second length, it sends a first command to the receiving end. The first command is used to instruct the receiving end to determine the length of the received data frame based on the frame length overhead in the data frame. The data frame includes the frame length overhead, which is used to indicate the length of the data frame. The sending end is used to send the data frame, and the receiving end is used to receive the data frame sent by the sending end. If the controller determines that the receiving end has successfully executed the first command, it sends a second command to the sending end, wherein the second command carries a value indicating the second length, and the second command is used to indicate that the length of the data frame sent by the sending end is changed to the second length; If the controller determines that the sending end has successfully executed the second command, it sends a third command to the receiving end, wherein the third command carries the value of the second length and is used to instruct the receiving end to determine the length of the received data frame based on the second length.

2. The method according to claim 1, characterized in that, The data frame also includes frame length overhead, the contents of which are used to determine the length of the data frame in which the frame length overhead is located. The sending end writes the length of the data frame into the frame length overhead according to the length of the data frame currently being sent. The data frame also includes frame positioning overhead, the content of which is fixed bit information. The transmitting end writes the fixed bit information into the frame positioning overhead, and the receiving end determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead.

3. The method according to claim 2, characterized in that, The receiving end determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead, including: When the receiving end fails to find the fixed bit information at the expected frame positioning overhead position, it then searches for the expected frame positioning overhead position again based on the fixed bit information and the length of the data frame. When the receiving end finds the fixed bit information at the expected frame positioning overhead position, it takes the expected frame positioning overhead position as the frame positioning overhead position and moves the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. When the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of all overhead of the data frame is valid content; When the receiving end fails to find the fixed bit information at the expected frame location overhead position, the content of all overhead of the data frame is invalid.

4. The method according to claim 3, characterized in that, The step of relocating the desired frame positioning overhead position based on the fixed bit information and the length of the data frame includes: The receiving end searches for the fixed bit information among all the received bits until it finds the fixed bit information. After finding the fixed bit information, the position of the fixed bit information is shifted backward by the length of the data frame as the desired frame positioning overhead position.

5. The method according to claim 4, characterized in that, After sending the first command to the receiving end, the process also includes: When the first command does not carry the value used to indicate the second length and the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is valid. The receiving end uses the content of the frame length overhead as the length of the data frame and moves the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. When the first command does not carry the value used to indicate the second length and the receiving end does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid. The receiving end uses the content when the frame length overhead was valid last time as the length of the data frame, and re-searches for the expected frame positioning overhead position based on the fixed bit information and the length of the data frame.

6. The method according to claim 4, characterized in that, After sending the first command to the receiving end, the process also includes: When the first command carries the value used to indicate the second length and the receiving end finds the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is valid. The receiving end uses the content of the frame length overhead as the length of the data frame and moves the expected frame positioning overhead position backward by the length of the data frame as the new expected frame positioning overhead position. When the first command carries the value used to indicate the second length and the receiving end does not find the fixed bit information at the expected frame positioning overhead position, the content of the frame length overhead is invalid. The receiving end uses the second length as the length of the data frame and searches for the expected frame positioning overhead position again based on the fixed bit information and the length of the data frame.

7. The method of claim 2, wherein the second command carries a numerical value indicating the second length, and after sending the second command to the sending end, further comprises: The sending end writes the value of the second length into the frame length overhead and uses the second length as the length of the data frame.

8. The method according to claim 4, characterized in that, After sending the third command to the receiving end, the method further includes: The receiving end uses the second length as the length of the data frame, and determines the expected frame positioning overhead position of the data frame based on the length of the data frame and the content of the frame positioning overhead position.

9. The method according to claim 1, characterized in that, The method further includes: Upon receiving the first command, the receiving end returns a response message indicating that the first command was successfully executed. Upon receiving the second command, the sending end returns a response message indicating that the second command was successfully executed. Upon receiving the third command, the receiving end returns a response indicating that the third command was successfully executed.

10. The method according to claim 9, characterized in that, After the controller sends the first command to the receiving end, the method further includes: The controller waits until it receives a response message indicating that the first command was executed successfully, then determines that the receiving end has successfully executed the first command, or waits until a preset time has elapsed without receiving a response message indicating that the first command was executed successfully. If the controller fails to receive a response indicating that the first command was executed successfully within the preset time period after each sending of the first command, it determines that the receiving end has failed to execute the first command. After sending the second command to the sending end, the method further includes: The controller waits until it receives a response indicating that the second command was successfully executed, then determines that the sending end has successfully executed the second command, or waits until the preset time has elapsed without receiving a response indicating that the second command was successfully executed. If the controller sends the second command the preset number of times and does not receive a response message indicating that the second command was executed successfully within the preset time after each sending of the second command, it determines that the sending end has failed to execute the second command. After sending the third command to the receiving end, the method further includes: The controller waits until it receives a response indicating that the third command was successfully executed, then determines that the receiving end has successfully executed the third command, or waits until the preset time has elapsed without receiving a response indicating that the third command was successfully executed. If the controller sends the third command a preset number of times and does not receive a response indicating that the third command was successfully executed within a preset time after each sending of the third command, it determines that the receiving end has failed to execute the third command.

11. The method according to claim 10, characterized in that, After sending the third command to the receiving end, the process also includes: After the controller determines that the receiving end has successfully executed the third command, it determines that the length of the data frame has been successfully changed from the first length to the second length. After determining that the receiving end fails to execute the first command, the sending end fails to execute the second command, or the receiving end fails to execute the third command, the controller determines that changing the length of the data frame from the first length to the second length has failed.

12. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method for changing the length of a data frame as described in any one of claims 1-11.

13. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method for changing the length of a data frame as described in any one of claims 1-11.

Images