Dynamic bandwidth management method and device of slave equipment, electronic equipment and storage medium

Abstract

The invention provides a dynamic bandwidth management method and device for slave equipment, electronic equipment and a storage medium, and the method comprises the steps: obtaining the service flow state information of the slave equipment in a current communication period, and enabling the service flow state information to be used for quantifying the data receiving and transmitting demands of the slave equipment; dynamically determining a bandwidth management mode adaptive to the current data receiving and transmitting demand based on the service flow state information; and controlling the communication behavior of the slave device according to the determined bandwidth management mode, and performing iterative execution based on the updated service flow state information after the end of a communication period. According to the method and the device, the slave device can intelligently apply, maintain or release the bandwidth based on the real-time service flow state of the slave device, so that the bandwidth utilization efficiency is remarkably improved, the real-time performance of data transmission is ensured, and the overall performance and the connection stability in a multi-connection scene are enhanced.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of wireless communication, and in particular, to a dynamic bandwidth management method and device of a slave device, an electronic device, and a storage medium. BACKGROUND

[0002] In a classic Bluetooth communication system, an Asynchronous Connectionless Link (ACL) adopts a master-slave architecture for data transmission. Under this architecture, the slave device is a passive communication end, and its data transmission completely depends on the polling scheduling mechanism of the master device, that is, the slave device can only respond and transmit data when the master device initiates a query.

[0003] The above-mentioned communication mode of “master device query-slave device response” causes obvious limitations of the slave device in the initiative and real-time of data transmission, which is specifically reflected in the following aspects: 1. When the slave device has no data transmission requirement, it is still passively occupied with system bandwidth resources, especially in the multi-slave device networking scenario. The static bandwidth allocation mechanism causes intensified resource competition, and the overall bandwidth utilization efficiency is low.

[0004] 2. Poor transmission real-time: the slave device cannot actively apply for bandwidth. When there is a burst data transmission requirement (such as sensor data collection, streaming buffer data), it must wait for the next master device polling window, and the polling timing cannot be predicted, which easily causes transmission delay and affects the service real-time. SUMMARY

[0005] The embodiments of the present disclosure at least provide a dynamic bandwidth management method and device of a slave device, an electronic device, and a storage medium to solve the above technical problems.

[0006] In a first aspect, the embodiments of the present disclosure provide a dynamic bandwidth management method of a slave device, comprising: obtaining service traffic state information of the slave device in a current communication period, the service traffic state information being used to quantify data transceiving requirements of the slave device; dynamically determining a bandwidth management mode suitable for the current data transceiving requirements based on the service traffic state information; controlling communication behaviors of the slave device according to the determined bandwidth management mode, and iteratively executing based on updated service traffic state information after the end of a communication period.

[0007] In a possible implementation, in the case that the service traffic state information includes a received traffic statistical value, the obtaining of the service traffic state information of the slave device in the current communication period comprises: determining types of each data packet received in the current communication period; counting a number of valid service data packets received in a current communication period; excluding a handshake data packet received in the current communication period for link maintenance from the counting of the valid service data packets, and determining the received traffic statistical value.

[0008] In a possible implementation, the determining the received traffic statistical value comprises: accumulating a count value by 1 for each valid service data packet correctly received; wherein the count value is provided with a preset upper limit value, and the accumulation is stopped when the count value reaches the preset upper limit value.

[0009] In a possible implementation, the method further comprises: outputting the counted number of valid service data packets as the received traffic statistical value at the end of the current communication period; resetting the count value for counting to restart counting in a next communication period.

[0010] In a possible implementation, the method further comprises: regarding a service data packet with a check error or an incomplete handshake data packet received as one receiving event and counting it.

[0011] In a possible implementation, when the service traffic state information comprises a sending traffic statistical value, the obtaining service traffic state information of the slave device in a current communication period comprises: obtaining a real-time length of a sending data queue of the slave device; determining the sending traffic statistical value based on the real-time length.

[0012] In a possible implementation, the method further comprises: the determination of the sending traffic statistical value is performed before each communication window starts and / or is performed when the sending data queue changes, to ensure that the sending traffic statistical value is consistent with the real-time state of the queue.

[0013] In a possible implementation, the method further comprises: when a data packet sending failure event is detected, triggering a switching application to a high-bandwidth management mode based on the currently obtained sending traffic statistical value.

[0014] In a possible implementation, the bandwidth management mode comprises a service traffic mode for guaranteeing service data transmission and a heartbeat mode for maintaining basic signaling interaction of connection.

[0015] In a possible implementation, the dynamic determination of the bandwidth management mode adaptive to the current data transceiving requirement comprises: determining to enter or maintain the traffic mode when the traffic status information indicates that there is valid traffic requirement; determining to switch to the heartbeat mode when the traffic status information indicates that there is no valid traffic requirement or the requirement is below a preset threshold.

[0016] In a possible implementation, the preset threshold is a preconfigured parameter for controlling the sensitivity of switching from the traffic mode to the heartbeat mode. wherein a smaller threshold parameter is configured for a scenario requiring quick release of bandwidth, and a larger threshold parameter is configured for a scenario requiring delayed release of bandwidth for predicting data retransmission.

[0017] In a possible implementation, the method further comprises: when the conditions for entering the traffic mode and the heartbeat mode are both met, determining to enter the traffic mode preferentially.

[0018] In a possible implementation, when the slave device is simultaneously connected to at least two master devices asynchronously and each connection is executed independently, the dynamic determination of the bandwidth management mode adaptive to the current data transceiving requirement comprises: for a first connection carrying high-traffic traffic, determining and maintaining the traffic mode; and for a second connection carrying low-traffic or no traffic data, determining and maintaining the heartbeat mode.

[0019] In a possible implementation, the high-traffic traffic is traffic requiring high real-time and continuous transmission; and the control of the communication behavior of the slave device according to the determined bandwidth management mode comprises: in the traffic mode, dynamically allocating a communication bandwidth window matching the current traffic status information for the first connection, so that transmission data packets for traffic can all fall within the allocated communication window.

[0020] In a possible implementation, the low-traffic or no traffic data includes only exchanging link maintenance handshake packets; and the control of the communication behavior of the slave device according to the determined bandwidth management mode comprises: in the heartbeat mode, allocating low-bandwidth resources for the second connection only for maintaining basic handshake timing.

[0021] In a second aspect, the disclosure also provides a dynamic bandwidth management apparatus of a slave device, comprising: The acquisition module is configured to acquire traffic state information of the slave device in a current communication period, the traffic state information being used to quantify data transceiving demand of the slave device. The determination module is configured to dynamically determine a bandwidth management mode suitable for the current data transceiving demand based on the traffic state information. The control module is configured to control communication behavior of the slave device according to the determined bandwidth management mode, and iteratively perform based on updated traffic state information after a communication period ends.

[0022] In a third aspect, the present disclosure further provides an electronic device, comprising a processor, a memory and a bus, the memory storing machine readable instructions executable by the processor, the processor and the memory communicating through the bus when the electronic device is running, and the machine readable instructions being executed by the processor to perform the dynamic bandwidth management method of the slave device according to any one of the first aspect and various embodiments thereof.

[0023] In a fourth aspect, the present disclosure further provides a computer readable storage medium, the computer readable storage medium storing a computer program, the computer program being executed by the processor to perform the dynamic bandwidth management method of the slave device according to any one of the first aspect and various embodiments thereof.

[0024] The dynamic bandwidth management method, device, electronic device and storage medium of the slave device described above first acquire traffic state information of the slave device in a current communication period, then dynamically determine a bandwidth management mode suitable for the current data transceiving demand based on the traffic state information, and finally control communication behavior of the slave device according to the determined bandwidth management mode, and iteratively perform based on updated traffic state information after a communication period ends, so that the slave device can intelligently apply, maintain or release bandwidth based on real-time traffic state of the slave device, thereby significantly improving bandwidth utilization efficiency, guaranteeing real-time data transmission, and enhancing overall performance and connection stability in a multi-connection scenario.

[0025] Other advantages of the present disclosure will be described in more detail in conjunction with the following description and drawings.

[0026] It should be understood that the above description is only a summary of the technical solutions of the present disclosure, so as to enable a general understanding of the technical means of the present disclosure, and then implement the content of the description. In order to make the above-mentioned purposes, features and advantages of the present disclosure more obvious and easy to understand, the following preferred embodiments are specifically described in detail below, and the accompanying drawings are described as follows. BRIEF DESCRIPTION OF DRAWINGS

[0027] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. The accompanying drawings are incorporated in and constitute a part of this specification. These drawings illustrate embodiments conforming to this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure. It should be understood that the drawings only illustrate certain embodiments of this disclosure and should not be considered as a limitation on the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. Furthermore, the same reference numerals denote the same components throughout the drawings. In the drawings: Figure 1 A flowchart of a dynamic bandwidth management method for a slave device provided by an embodiment of this disclosure is shown; Figure 2 A schematic diagram illustrating the module working principle of the dynamic bandwidth management method for slave devices provided in an embodiment of this disclosure is shown. Figure 3 The flowchart illustrates the workflow of the Rx_Traffic functional module in the dynamic bandwidth management method for slave devices provided in this embodiment of the present disclosure. Figure 4 The flowchart illustrates the workflow of the Tx_Traffic functional module in the dynamic bandwidth management method for slave devices provided in this embodiment of the disclosure. Figure 5 The diagram illustrates a scenario application of the Rx_Traffic functional module in the dynamic bandwidth management method for slave devices provided in this embodiment of the present disclosure. Figure 6 The diagram illustrates a scenario application of the Tx_Traffic functional module in the dynamic bandwidth management method for slave devices provided in this embodiment of the present disclosure. Figure 7 The following are application test diagrams showing a method for managing the dynamic bandwidth of a slave device that does not employ the embodiments provided in this disclosure. Figure 8 The following diagram shows an application test of the dynamic bandwidth management method for slave devices provided in the embodiments of this disclosure. Figure 9 A schematic diagram of a dynamic bandwidth management device for a slave device provided in an embodiment of this disclosure is shown; Figure 10 A schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0028] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0029] In the description of embodiments disclosed herein, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of the disclosed features, figures, steps, behaviors, components, portions or combinations thereof in this specification, and do not exclude the possibility of the presence of one or more other features, figures, steps, behaviors, components, portions or combinations thereof.

[0030] Unless otherwise stated, " / " means "or". For example, A / B can mean A or B. In this article, "and / or" is merely a way of describing the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A alone, A and B at the same time, and B alone.

[0031] The terms "first," "second," etc., are used only for ease of description to distinguish identical or similar technical features and should not be construed as indicating or implying the relative importance or number of these technical features. Therefore, a feature defined by "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, the term "multiple" means two or more.

[0032] Research has revealed that in the asynchronous connectionless link (ACL) of the classic Bluetooth communication system, the slave device, as a passive communication end, is directly affected by the master-slave architecture and transmission mechanism, which directly impacts its communication efficiency and bandwidth resource utilization efficiency. Specifically, in the master-slave communication architecture, the slave device follows the "master device query - slave device response" communication mechanism and can only send and receive data when the master device starts polling.

[0033] When a slave device has an immediate data transmission requirement (such as burst data collection from sensors or temporary buffered data from streaming media devices), if it is not in the communication window polled by the master device, it must wait for the next round of master device queries before it can transmit. The slave device cannot predict the timing of the master device's query and may miss the communication opportunity. Conversely, when there is no data to be transmitted between the master and slave devices, the bandwidth resources maintained by the slave device are ineffective, especially in multi-slave device networking scenarios.

[0034] This passive bandwidth allocation model intensifies resource competition and further reduces overall bandwidth utilization.

[0035] To at least partially address one or more of the aforementioned problems and other potential issues, this disclosure provides at least one dynamic bandwidth management scheme for slave devices. Its core objective is to enable slave devices to intelligently request, maintain, or release bandwidth based on their real-time service traffic status, thereby significantly improving bandwidth utilization efficiency, ensuring the real-time nature of data transmission, and enhancing overall performance and connection stability in multi-connection scenarios.

[0036] To clearly illustrate the embodiments of this disclosure, some core parameters that may appear in subsequent embodiments will be introduced first.

[0037] Table 1

[0038] Table 2

[0039] To facilitate understanding of this embodiment, a detailed description of the dynamic bandwidth management method for a slave device disclosed in this disclosure is provided first. The executing entity of the dynamic bandwidth management method for a slave device provided in this disclosure is generally an electronic device with a certain computing capability. This electronic device may include, for example, a terminal device, a server, or other processing devices. The terminal device may be a user equipment (UE), a mobile device, a user terminal, a personal digital assistant (PDA), a handheld device, a computing device, an in-vehicle device, etc. Considering that this disclosure embodiment is mainly applicable to classic Bluetooth communication systems, the other processing devices mentioned here are, for example, a BR / EDR controller.

[0040] In some possible implementations, the dynamic bandwidth management method for the slave device can be implemented by the processor calling computer-readable instructions stored in memory.

[0041] See Figure 1 The diagram illustrates a flowchart of a dynamic bandwidth management method for a slave device provided in an embodiment of this disclosure, the method comprising the following steps S101-S103: S101: Obtain the service traffic status information of the slave device in the current communication cycle. The service traffic status information is used to quantify the data transmission and reception requirements of the slave device. S102: Based on service traffic status information, dynamically determine the bandwidth management mode that adapts to the current data transmission and reception requirements; S103: Control the communication behavior of the slave device according to the determined bandwidth management mode, and perform iterative execution based on the updated service traffic status information after a communication cycle ends.

[0042] To facilitate understanding of the dynamic bandwidth management method for slave devices provided in this disclosure, the application scenarios of this method will be briefly introduced first. This disclosure can be widely applied to various classic Bluetooth (BR / EDR) slave devices, such as in the fields of consumer electronics and smart audio, sports and health and wearable devices, industrial IoT and sensor networks, and automotive infotainment and peripheral devices. Considering the widespread application of True Wireless Stereo (TWS) earphones in the consumer electronics and smart audio field, TWS earphones will be used as examples in the following sections.

[0043] Considering the various problems that may arise from the "master device query - slave device response" approach in practical applications, this disclosure provides a dynamic bandwidth management mechanism for slave devices based on traffic status, and establishes a closed-loop management framework of "perception-decision-execution-optimization" based on this mechanism. By continuously sensing its own traffic status, the slave device can proactively and dynamically adjust its bandwidth strategy, breaking away from the passive state of relying entirely on master device polling, and laying the architectural foundation for achieving efficient bandwidth utilization and real-time transmission.

[0044] refer to Figure 2 The closed-loop management architecture shown executes the following steps iteratively by the device according to the communication cycle: Step 1: Through the service traffic update module, collect real-time status information of received traffic generated within the current communication cycle (e.g., through...). Figure 3 The Rx_Traffic function module performs the traffic reception process and sends traffic status information (such as via...). Figure 4 The Tx_Traffic function module executes the traffic sending process.

[0045] In the specific process of collecting traffic status, it is possible to determine whether the transmitted traffic statistics (Tx_Traffic) or received traffic statistics (Rx_Traffic) is 0. Once it is determined that Tx_Traffic=0 or Rx_Traffic=0, the system scheduling module can prepare for the next action by obtaining the two parameters HeartBeat_Window and HeartBeat_Interval in the heartbeat mode. If it is determined that Tx_Traffic and Rx_Traffic are not 0, the system scheduling module can prepare for the next action by obtaining the two parameters Traffic_Interval and Traffic_Window in the service traffic mode.

[0046] Step two: Based on the status information updated in the previous steps, the system scheduling module evaluates and determines the appropriate communication interval and bandwidth window parameters to meet the current needs, and accordingly initiates the communication window for the corresponding bandwidth management mode (service traffic mode or heartbeat mode). During the window's operation, traffic status information is continuously updated.

[0047] Step three: After the current communication window ends, the system recalculates and updates the communication interval and bandwidth window parameters for the next cycle based on the latest collected service traffic status information within the window, thereby enabling dynamic application, maintenance, or release of bandwidth resources. The process then returns to step one to enter the next management cycle.

[0048] This embodiment of the disclosure takes the receiving direction as an example. When the service traffic status information includes received traffic statistics, the received traffic statistics can be obtained through the following steps: Step 1: Determine the type of each data packet received in the current communication cycle; Step 2: Count the number of valid service data packets received within the current communication cycle; Step 3: Exclude handshake data packets received during the current communication cycle that are used for link maintenance from the statistics of valid service data packets, and determine the received traffic statistics value.

[0049] In one possible implementation, the received traffic statistics are determined through the following steps: For each valid service data packet correctly received, the count value is incremented by 1; the count value has a preset upper limit, and the incrementing stops when the count value reaches the preset upper limit.

[0050] In another possible implementation, at the end of the current communication cycle, the number of valid service data packets obtained is output as the received traffic statistics value; the count value used for statistics is reset so that the statistics can start again in the next communication cycle.

[0051] In another possible implementation, a received business data packet with a checksum error or an incomplete handshake data packet is still treated as a reception event and counted.

[0052] refer to Figure 3 This disclosure, in conjunction with the Rx_Traffic functional module, specifically illustrates the detailed implementation of the traffic reception process. Within the communication window, for each data packet reception event reported by the physical layer, this module executes: Parse the received data packets. If it is an ACL Data packet carrying valid application data, then it will be entered into the counter for accumulation; if it is a Poll packet or Null packet used for link status query and maintenance, then the current processing will end directly without traffic accumulation, ensuring that the handshake packet does not affect the judgment of service traffic.

[0053] Valid ACL Data packets increment the internal receive counter Rx_Traffic by 1. This counter Rx_Traffic has a preset upper limit value Traffic_MAX (configurable according to different business scenarios). When Rx_Traffic reaches Traffic_MAX, the increment stops to prevent it from growing indefinitely.

[0054] For ACL data packets that fail Cyclic Redundancy Check (CRC) or poll packets that are incomplete in length, although they cannot be processed as valid data, this module still treats them as a "receive event". This design is to prevent the system from misjudging the link as having no traffic due to valid packets being incorrect because of transient link quality problems, thus ensuring that the system can still respond promptly even in harsh environments.

[0055] At the end of the current communication window, the final value of the counter Rx_Traffic is output to the service traffic update module as the received traffic statistics (Rx_Traffic) for this window. Then, Rx_Traffic is immediately reset to 0. This "statistics-output-reset" process is a key error-proofing mechanism in this embodiment, effectively avoiding counter overflow and duplicate data counting across communication windows, ensuring the statistical independence of each cycle.

[0056] This embodiment of the disclosure takes the sending direction as an example. When the service traffic status information includes sending traffic statistics, the sending traffic statistics can be obtained through the following steps: Get the real-time length of the data transmission queue from the device; The transmission traffic statistics are determined based on the real-time length.

[0057] In one possible implementation, the determination of the transmission traffic statistics is performed before the start of each communication window and / or when the transmission data queue changes, to ensure that the transmission traffic statistics are consistent with the real-time status of the queue.

[0058] In another possible implementation, when a packet transmission failure event is detected, a request to switch to high bandwidth management mode is triggered based on the currently acquired transmission traffic statistics.

[0059] refer to Figure 4 This disclosure, in conjunction with the Tx_Traffic functional module, specifically illustrates the detailed implementation of the traffic transmission process.

[0060] Unlike the Rx_Traffic module, the Tx_Traffic module does not maintain an accumulator counter. Instead, it directly queries the current length L of the send buffer queue (TX FIFO) to achieve send statistics. This length L directly represents the number of data packets to be sent.

[0061] The query action is triggered at the following times: first, periodic state sampling is performed before each communication window begins; second, event-triggered state updates are performed whenever a data packet is enqueued or dequeued, causing a change in the sending queue length. This ensures that the sending traffic statistics (Tx_Traffic) always remains consistent with the queue status L, and its value is also limited by the preset upper limit TRAFFIC_MAX.

[0062] When the query finds that the sending queue is empty, the sending traffic statistics value is cleared to zero (Tx_Traffic = 0) to explicitly indicate that there is no sending demand.

[0063] When the link layer reports a packet transmission failure (e.g., no ACK received), this module does not modify the current Tx_Traffic value (which still reflects the actual queue length). Instead, it immediately generates a "bandwidth upgrade request" flag and submits it along with the current Tx_Traffic value to the decision module. The decision module can then assess that even if the current queue is not long, a poor link may require more bandwidth to ensure retransmission, potentially triggering a switch to a different service traffic mode earlier, securing an earlier retransmission opportunity, and improving data timeliness.

[0064] Based on the traffic status information obtained above, mode decisions can be made. The bandwidth management modes here mainly include the service traffic mode for ensuring the transmission of service data and the heartbeat mode for maintaining basic signaling interaction of the connection.

[0065] For details on the process of dynamically determining the bandwidth management mode that adapts to the current data transmission and reception requirements, please refer to the following steps: Step 1: When the business traffic status information indicates that there is a valid business demand, determine whether to enter or maintain the business traffic mode; Step 2: When the business traffic status information indicates that there is no valid business demand or the demand is lower than the preset threshold, confirm the switch to heartbeat mode.

[0066] In one possible implementation, the preset threshold is a pre-configured parameter used to control the sensitivity of switching from business traffic mode to heartbeat mode; wherein, configuring a smaller threshold parameter is suitable for scenarios that require rapid release of bandwidth; configuring a larger threshold parameter is suitable for scenarios that require delayed release of bandwidth to predict data continuation.

[0067] In one possible implementation, when the conditions for entering both the business traffic mode and the heartbeat mode are met simultaneously, the business traffic mode is prioritized.

[0068] In this embodiment of the disclosure, it can be implemented based on a decision module.

[0069] First, the system defines two bandwidth management modes: service traffic mode (high bandwidth, used for data transmission) and heartbeat mode (low bandwidth, used only for maintaining the connection).

[0070] The decision-making logic is as follows: The system compares the received traffic statistics (Rx_Traffic) and / or transmitted traffic statistics (Tx_Traffic) with a configurable traffic recovery threshold parameter TRAFFIC_DEF.

[0071] Entering / Maintaining Traffic Flow Mode: When Rx_Traffic or Tx_Traffic is greater than TRAFFIC_DEF, it indicates that there is a valid traffic demand. The decision is made to enter or maintain traffic flow mode and request a larger communication window.

[0072] Switch to heartbeat mode: When both Rx_Traffic and Tx_Traffic drop to TRAFFIC_DEF or below, it indicates that the business demand is very low or non-existent. The decision is to switch to heartbeat mode to free up bandwidth.

[0073] like Figure 5 The following is a scenario application diagram of Rx_Traffic: Example 1: If valid data (ACL Data) is received at the end of the business traffic communication window, the system will continue to maintain and request the business traffic mode (corresponding to the traffic window) to maintain high bandwidth transmission; Example 2: If a heartbeat handshake packet (Poll packet) is received when the business traffic communication window ends, the request heartbeat mode (corresponding to HeartBeat window) is switched. Example 3: During the operation of the service traffic communication window, if the service traffic has fallen below the TRAFFIC_DEF threshold, the system will release bandwidth in advance; Example 4: If handshake failures occur in multiple consecutive heartbeat mode communication windows, the system will request a service traffic mode to increase bandwidth, improve link stability, and prevent disconnection due to timeout.

[0074] like Figure 6 The following is a scenario application diagram of Tx_Traffic: Example 5: The business traffic communication window is about to close. If the system detects that there are data packets (ACL Data) to be sent, it will continue to request the business traffic mode (corresponding to the Traffic window). Example 6: When the business traffic communication window is about to end, if the system detects that there are no data packets to send, it will actively switch and request heartbeat mode (corresponding to HeartBeat window). Example 7: Within the business traffic communication window, if the system completes data transmission ahead of schedule and assesses that there is surplus bandwidth, it will release the excess bandwidth and request heartbeat mode (corresponding to the HeartBeat window).

[0075] In practical applications, such as sensor terminal scenarios where data bursts are frequent and intervals are long, TRAFFIC_DEF can be configured to a small value (e.g., 1). This allows the traffic statistics to quickly drop below the threshold after a data burst, enabling the system to rapidly release bandwidth and return to heartbeat mode, achieving optimal power consumption. Conversely, in streaming media terminal scenarios where data is continuous and stable, TRAFFIC_DEF can be configured to a larger value. This ensures that even if there are brief data intervals due to network buffering, the traffic statistics may still exceed the threshold. The system will maintain the service traffic mode for a period (delayed release), anticipating that the data stream will continue, thus avoiding the overhead of frequent mode switching and ensuring the continuity and low latency of audio and video streams.

[0076] Priority rule: When it is determined that the business traffic mode needs to be entered based on Rx_Traffic, but the heartbeat mode can be entered based on Tx_Traffic (or vice versa), the decision module will prioritize the execution of the business traffic mode to ensure that data transmission can be given priority when there is a business need in either direction.

[0077] When a slave device maintains asynchronous connections with at least two master devices simultaneously, and each connection is executed independently, the dynamic bandwidth management method provided in this disclosure can dynamically determine a bandwidth management mode adapted to the current data transmission and reception requirements in the following manner: For the first connection carrying high-traffic services, determine and maintain the service traffic pattern; for the second connection carrying low-traffic services or no service data, determine and maintain the heartbeat pattern.

[0078] In one possible implementation, the high-traffic service is one that requires high real-time performance and continuous transmission; the communication behavior of the slave device is controlled in the following way: In service traffic mode, a communication bandwidth window that matches the current service traffic status information is dynamically allocated to the first connection, so that all data packets transmitted for the service can fall within the allocated communication window.

[0079] In another possible implementation, low traffic or no service data includes states where only link maintenance handshake packets need to be exchanged; the communication behavior of the slave device is controlled in the following ways: In heartbeat mode, low-bandwidth resources are allocated to the second connection only to maintain basic handshake timing.

[0080] This disclosure combines the embodiments with Figure 7 and Figure 8 The actual test comparison illustrates the outstanding effect of this dynamic bandwidth management method in multi-connection scenarios.

[0081] Suppose a Bluetooth slave device (such as TWS earphones) maintains an ACL connection with both a mobile phone (master device 1, playing music) and a computer (master device 2, in synchronization mode only).

[0082] like Figure 7 As shown, it employs static and equal bandwidth allocation. As a result, audio data packets (1-1, 1-2, 1-3) on Link 1 (streaming media service) fail to be received in time due to insufficient allocated fixed windows or timing mismatches, causing music stuttering. Simultaneously, Link 2 (heartbeat-only service) only transmits Poll packets (2-1, 2-2, 2-3) within its allocated time slot, resulting in significant bandwidth wastage.

[0083] like Figure 8 As shown, it adopts the dynamic management scheme provided in this embodiment. For link 1 carrying high-traffic streaming media services, the slave device dynamically decides and stably maintains the service traffic mode based on its consistently high Rx_Traffic / Rx_Traffic, successfully applying for sufficient and continuous communication windows. Streaming media data packets can be received in a timely manner within their dedicated window, completely eliminating lag and effectively ensuring the high real-time performance and transmission continuity of streaming media services.

[0084] For Link 2, which only needs to maintain a connection, the slave device dynamically decides and stably maintains heartbeat mode based on its extremely low traffic status (mainly receiving Poll packets). It allocates very little, periodic bandwidth resources to complete the basic handshake and only uses them to maintain the basic heartbeat handshake sequence, thereby greatly avoiding competition for service bandwidth with Link 1 and minimizing resource waste.

[0085] As can be seen, through the dynamic bandwidth management scheme provided in this embodiment, the system realizes differentiated dynamic bandwidth management between connections, intelligently allocates resources to high-demand services, and compresses the resource consumption of low-demand services, thereby systematically solving the bandwidth competition and mismatch problem under multiple connections, and significantly improving system efficiency and user experience.

[0086] In the description of this specification, references to terms such as "some possible implementations," "some implementations," "example," "specific example," or "some examples" indicate that a specific feature, structure, material, or characteristic described in connection with that implementation or example is included in at least one implementation or example of this disclosure, and the aforementioned terms do not necessarily refer to the same implementation or example. Furthermore, the described specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more implementations or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different implementations or examples described in this specification, as well as the features of different implementations or examples.

[0087] Regarding the method flowcharts of embodiments of this disclosure, certain operations are described as different steps performed in a certain order. Such flowcharts are illustrative and not restrictive. Some steps described herein may be grouped together and performed in a single operation, or some steps may be divided into multiple sub-steps, and some steps may be performed in an order different from that shown herein. The various steps shown in the flowcharts may be implemented in any way by any circuit structure and / or tangible mechanism (e.g., software running on a computer device, hardware (e.g., logic functions implemented by a processor or chip), and / or any combination thereof).

[0088] Those skilled in the art will understand that in the methods described in the above specific embodiments, the order in which the steps are written does not imply a strict execution order, and the specific execution order of each step should be determined by its function and possible internal logic.

[0089] Based on the same inventive concept, this disclosure also provides a dynamic bandwidth management device corresponding to the dynamic bandwidth management method for slave devices. Since the principle of the device in this disclosure for solving the problem is similar to the dynamic bandwidth management method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0090] Reference Figure 9 The diagram shown is a schematic of a dynamic bandwidth management device provided in an embodiment of this disclosure. The device includes: an acquisition module 201, a determination module 202, and a control module 203; wherein, The acquisition module 201 is used to acquire the service traffic status information of the slave device in the current communication cycle. The service traffic status information is used to quantify the data transmission and reception needs of the slave device. The determination module 202 is used to dynamically determine the bandwidth management mode that is adapted to the current data transmission and reception requirements based on the service traffic status information. The control module 203 is used to control the communication behavior of the slave device according to the determined bandwidth management mode, and to perform iterative execution based on the updated service traffic status information after a communication cycle ends.

[0091] The aforementioned dynamic bandwidth management device for slave devices first acquires the service traffic status information of the slave devices during the current communication cycle. Then, based on the service traffic status information, it dynamically determines the bandwidth management mode that adapts to the current data transmission and reception requirements. Finally, it controls the communication behavior of the slave devices according to the determined bandwidth management mode. After a communication cycle ends, it iteratively executes the operation based on the updated service traffic status information. This enables the slave devices to intelligently apply for, maintain, or release bandwidth based on their own real-time service traffic status, thereby significantly improving bandwidth utilization efficiency, ensuring the real-time performance of data transmission, and enhancing overall performance and connection stability in multi-connection scenarios.

[0092] In one possible implementation, when the service traffic status information includes received traffic statistics, the acquisition module 201 is specifically configured to acquire the service traffic status information of the slave device in the current communication cycle according to the following steps: Determine the type of each data packet received within the current communication cycle; Count the number of valid service data packets received within the current communication cycle; Handshake packets received during the current communication cycle for link maintenance are excluded from the statistics of valid service packets to determine the received traffic statistics.

[0093] In one possible implementation, the acquisition module 201 is specifically configured to determine the received traffic statistics value according to the following steps: For each valid service data packet correctly received, the counter value is incremented by 1; The count value has a preset upper limit. When the count value reaches the preset upper limit, the accumulation stops.

[0094] In one possible implementation, the acquisition module 201 is further configured to: At the end of the current communication cycle, the number of valid service data packets obtained is output as the received traffic statistics value; the count value used for statistics is reset so that the statistics can start again in the next communication cycle.

[0095] In one possible implementation, the acquisition module 201 is further configured to: For received business data packets with verification errors or incomplete handshake data packets, they are still treated as a reception event and counted.

[0096] In one possible implementation, when the service traffic status information includes transmission traffic statistics, the acquisition module 201 is specifically configured to acquire the service traffic status information of the slave device in the current communication cycle according to the following steps: Get the real-time length of the data transmission queue from the device; The transmission traffic statistics are determined based on the real-time length.

[0097] In one possible implementation, the acquisition module 201 is further configured to: The determination of transmission traffic statistics is performed before the start of each communication window and / or when the transmission data queue changes, to ensure that the transmission traffic statistics are consistent with the real-time status of the queue.

[0098] In one possible implementation, the acquisition module 201 is further configured to: When a packet transmission failure event is detected, a request to switch to high-bandwidth management mode is triggered based on the currently acquired transmission traffic statistics.

[0099] In one possible implementation, the bandwidth management modes include a service traffic mode for ensuring service data transmission and a heartbeat mode for maintaining basic signaling interactions for the connection.

[0100] In one possible implementation, the determining module 202 is configured to dynamically determine a bandwidth management mode adapted to the current data transmission and reception requirements according to the following steps: When the business traffic status information indicates that there is a valid business demand, determine whether to enter or maintain the business traffic mode. When the business traffic status information indicates that there is no valid business demand or the demand is lower than the preset threshold, the system will switch to heartbeat mode.

[0101] In one possible implementation, the preset threshold is a pre-configured parameter used to control the sensitivity of switching from business traffic mode to heartbeat mode; Configuring a smaller threshold parameter is suitable for scenarios that require rapid bandwidth release; configuring a larger threshold parameter is suitable for scenarios that require delayed bandwidth release to predict data continuation.

[0102] In one possible implementation, the determining module 202 is further configured to: When the conditions for entering both business traffic mode and heartbeat mode are met simultaneously, the business traffic mode will be selected first.

[0103] In one possible implementation, when a slave device maintains asynchronous connections with at least two master devices simultaneously, and each connection is executed independently, the determining module 202 is used to dynamically determine a bandwidth management mode adapted to the current data transmission and reception requirements according to the following steps: For the first connection carrying high-traffic services, determine and maintain the service traffic pattern; for the second connection carrying low-traffic services or no service data, determine and maintain the heartbeat pattern.

[0104] In one possible implementation, the high-traffic service is one that requires high real-time performance and continuous transmission; the control module 203 is configured to control the communication behavior of the slave device according to the determined bandwidth management mode, following the steps described below: In service traffic mode, a communication bandwidth window that matches the current service traffic status information is dynamically allocated to the first connection, so that all data packets transmitted for the service can fall within the allocated communication window.

[0105] In one possible implementation, low traffic or no service data includes a state where only link maintenance handshake packets need to be exchanged; the determining module 202 is configured to control the communication behavior of the slave device according to the determined bandwidth management mode in the following steps: In heartbeat mode, low-bandwidth resources are allocated to the second connection only to maintain basic handshake timing.

[0106] It should be noted that the apparatus in this embodiment can implement the various processes of the aforementioned method and achieve the same effects and functions, which will not be elaborated here.

[0107] This disclosure also provides an electronic device, such as... Figure 10 The diagram shown is a schematic representation of an electronic device structure provided in this embodiment of the present disclosure, including: a processor 301, a memory 302, and a bus 303. The memory 302 stores machine-readable instructions executable by the processor 301 (e.g., ...). Figure 9 The device includes modules 201 for acquiring data, 202 for determining data, and 203 for controlling data to execute corresponding instructions. When the electronic device is running, the processor 301 and memory 302 communicate via bus 303. When a machine-readable instruction is executed by the processor 301, the following processing is performed: Obtain the service traffic status information of the slave device within the current communication cycle. The service traffic status information is used to quantify the data transmission and reception requirements of the slave device. Based on business traffic status information, dynamically determine the bandwidth management mode that adapts to the current data transmission and reception requirements; The communication behavior of the slave device is controlled according to the determined bandwidth management mode, and iterative execution is performed based on the updated service traffic status information after a communication cycle ends.

[0108] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the dynamic bandwidth management method for a slave device described in the above method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0109] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of the dynamic bandwidth management method for slave devices described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0110] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0111] The various embodiments in this disclosure are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments. In particular, the description of the apparatus, device, and computer-readable storage medium embodiments is simplified because they are basically similar to the method embodiments, and the relevant parts can be referred to the description of the method embodiments.

[0112] The apparatus, device, and computer-readable storage medium provided in this disclosure correspond one-to-one with the method. Therefore, the apparatus, device, and computer-readable storage medium also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the apparatus, device, and computer-readable storage medium will not be repeated here.

[0113] Those skilled in the art will understand that embodiments of this disclosure can be implemented as methods and apparatus (devices or systems), or as computer-readable storage media. Therefore, this disclosure can be implemented entirely in hardware, entirely in software, or in a combination of software and hardware. Furthermore, this disclosure can be implemented as a computer-readable storage medium on one or more computer-readable storage media containing computer-usable program code (including, but not limited to, disk storage, read-only optical disc storage (CD-ROM), optical storage, etc.).

[0114] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices or systems), and computer-readable storage media according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0115] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article including instruction means, wherein the instruction means implement the functions specified in one or more flowcharts and / or one or more blocks in a block diagram.

[0116] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0117] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0118] Memory can include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0119] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory, read-only memory, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. Furthermore, although the operations of the methods of this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally, certain steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple sub-steps.

[0120] While the spirit and principles of this disclosure have been described above with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method for dynamic bandwidth management of a device, characterized in that, include: The service traffic status information of the slave device in the current communication cycle is obtained, and the service traffic status information is used to quantify the data transmission and reception requirements of the slave device. Based on the aforementioned service traffic status information, a bandwidth management mode adapted to the current data transmission and reception requirements is dynamically determined; The communication behavior of the slave device is controlled according to the determined bandwidth management mode, and iterative execution is performed based on the updated service traffic status information after a communication cycle ends.

2. The method according to claim 1, characterized in that, When the service traffic status information includes received traffic statistics, obtaining the service traffic status information of the slave device within the current communication cycle includes: Determine the type of each data packet received within the current communication cycle; Count the number of valid service data packets received within the current communication cycle; Handshake packets received during the current communication cycle for link maintenance are excluded from the statistics of the valid service packets to determine the received traffic statistics.

3. The method according to claim 2, characterized in that, Determining the received traffic statistics includes: For each valid service data packet correctly received, the counter value is incremented by 1; The count value has a preset upper limit value, and the accumulation stops when the count value reaches the preset upper limit value.

4. The method according to claim 3, characterized in that, The method further includes: At the end of the current communication cycle, the number of valid service data packets obtained by statistics will be output as the received traffic statistics value; The count value used for statistics is reset so that statistics can restart in the next communication cycle.

5. The method according to any one of claims 2 to 4, characterized in that, The method further includes: For received business data packets with verification errors or incomplete handshake data packets, they are still treated as a reception event and counted.

6. The method according to claim 2, characterized in that, When the service traffic status information includes transmission traffic statistics, obtaining the service traffic status information of the slave device within the current communication cycle includes: Obtain the real-time length of the data transmission queue of the slave device; The transmission traffic statistics are determined based on the real-time length.

7. The method according to claim 6, characterized in that, The method further includes: The determination of the transmission traffic statistics is performed before the start of each communication window, and / or when the transmission data queue changes, to ensure that the transmission traffic statistics are consistent with the real-time status of the queue.

8. The method according to claim 6 or 7, characterized in that, The method further includes: When a packet transmission failure event is detected, a request to switch to high bandwidth management mode is triggered based on the currently acquired transmission traffic statistics.

9. The method according to claim 1, characterized in that, The bandwidth management modes include a service traffic mode for ensuring service data transmission and a heartbeat mode for maintaining basic signaling interactions for the connection.

10. The method according to claim 9, characterized in that, The dynamic determination of the bandwidth management mode adapted to the current data transmission and reception requirements includes: When the service traffic status information indicates that there is a valid service demand, determine whether to enter or maintain the service traffic mode; When the service traffic status information indicates that there is no valid service demand or the demand is lower than a preset threshold, it is determined to switch to the heartbeat mode.

11. The method according to claim 10, characterized in that, The preset threshold is a pre-configured parameter used to control the sensitivity of switching from the service traffic mode to the heartbeat mode; The smaller threshold parameter is suitable for scenarios that require rapid bandwidth release; the larger threshold parameter is suitable for scenarios that require delayed bandwidth release to predict data continuation.

12. The method according to claim 10, characterized in that, The method further includes: When the conditions for entering the service traffic mode and the heartbeat mode are met simultaneously, the service traffic mode is selected first.

13. The method according to claim 9, characterized in that, When the slave device maintains asynchronous connections with at least two master devices simultaneously, and each connection is executed independently, the dynamic determination of the bandwidth management mode adapted to the current data transmission and reception requirements includes: For the first connection carrying high-traffic services, determine and maintain the service traffic pattern; for the second connection carrying low-traffic or no service data, determine and maintain the heartbeat pattern.

14. The method according to claim 13, characterized in that, The high-traffic service is one that requires high real-time performance and continuous transmission; controlling the communication behavior of the slave device according to the determined bandwidth management mode includes: In the service traffic mode, a communication bandwidth window that matches the current service traffic status information is dynamically allocated to the first connection, so that all data packets transmitted for the service can fall within the allocated communication window.

15. The method according to claim 13, characterized in that, The low traffic or no service data includes a state where only link maintenance handshake packets need to be exchanged; controlling the communication behavior of the slave device according to the determined bandwidth management mode includes: In the heartbeat mode, low-bandwidth resources are allocated to the second connection only to maintain basic handshake timing.

16. A dynamic bandwidth management device for a slave device, characterized in that, include: The acquisition module is used to acquire the service traffic status information of the slave device in the current communication cycle. The service traffic status information is used to quantify the data transmission and reception requirements of the slave device. The determination module is used to dynamically determine the bandwidth management mode that is adapted to the current data transmission and reception requirements based on the service traffic status information. The control module is used to control the communication behavior of the slave device according to the determined bandwidth management mode, and to perform iterative execution based on the updated service traffic status information after a communication cycle ends.

17. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the dynamic bandwidth management method of the slave device as described in any one of claims 1 to 15 is performed.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the dynamic bandwidth management method for a slave device as described in any one of claims 1 to 15.

Images