Method for dynamic allocation of audio transmission bandwidth and related devices

Abstract

The embodiment of the application discloses a kind of audio transmission bandwidth dynamic allocation method and related device, method is applied to the center gateway of transmission control platform, transmission control platform includes center gateway, and the multiple edge gateways connected by center gateway, multiple edge gateways are connected with multiple internet-of-things equipment;Method includes: obtaining the real-time bandwidth data of multiple edge gateways and the service priority of multiple internet-of-things equipment;In response to bandwidth adjustment trigger condition, determine the gateway to be adjusted;From the multiple internet-of-things equipment connected to the gateway to be adjusted, determine target internet-of-things equipment, determine target gateway for target internet-of-things equipment;Control target internet-of-things equipment switches from the gateway to be adjusted to target gateway, to reduce the bandwidth load of the gateway to be adjusted.Such, by center gateway dynamic optimization bandwidth allocation, solved the problem such as lag, disconnected in audio transmission process, avoid bandwidth resource waste, guarantee the stability of two-way audio transmission.

Description

Technical Field

[0001] This application relates to the field of audio transmission technology, specifically to a method and related apparatus for dynamically allocating audio transmission bandwidth. Background Technology

[0002] With the rapid development of IoT technology, traditional IoT devices such as speakers and smart panels are playing an increasingly important role in two-way audio transmission applications. These devices typically need to use edge gateways to interact with the cloud or other devices to support various business scenarios such as voice calls, audio broadcasting, and emergency communications.

[0003] However, existing IoT edge gateway technologies still have many shortcomings in supporting bidirectional audio transmission for traditional IoT devices: First, in scenarios with concurrent transmission of multiple devices, existing solutions are prone to bandwidth contention and data conflicts, leading to a decline in audio transmission quality; second, uneven load distribution on edge gateways can directly cause audio stuttering and disconnection when a gateway is overloaded, resulting in audio stream interruptions and impacting user experience; third, existing solutions lack an effective bandwidth priority scheduling mechanism, failing to allocate bandwidth differently based on business importance and historical stability, thus failing to guarantee transmission quality and stability in emergency business scenarios; furthermore, in low-concurrency scenarios, existing solutions waste bandwidth resources and fail to achieve dynamic optimization of resource configuration; finally, traditional solutions are difficult to adapt to the hardware characteristics and performance limitations of IoT devices, either requiring significant hardware modifications or failing to meet the stable transmission requirements of high concurrency and low latency (≤100ms), severely limiting the application expansion of traditional IoT devices in bidirectional audio interaction scenarios. Summary of the Invention

[0004] In view of this, this application provides a method and related apparatus for dynamic allocation of audio transmission bandwidth, which aims to build a linkage architecture between a central gateway and an edge gateway, with the central gateway dynamically optimizing the bandwidth allocation strategy to ensure that each audio transmission occupies a stable bandwidth, thereby achieving efficient and stable audio data transmission, avoiding bandwidth waste, and ensuring the stability of bidirectional audio transmission.

[0005] In a first aspect, embodiments of this application provide a method for dynamically allocating audio transmission bandwidth, applied to a central gateway of a transmission control platform. The transmission control platform includes the central gateway and multiple edge gateways connected to the central gateway. The multiple edge gateways are respectively communicatively connected to multiple IoT devices, and the multiple IoT devices support bidirectional audio transmission. The method includes: The system obtains real-time bandwidth data of the multiple edge gateways and service priorities of the multiple IoT devices. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priorities are bandwidth configuration priorities pre-configured by the central gateway to reflect different audio service scenarios. In response to a bandwidth adjustment trigger condition, a gateway to be adjusted is determined. The bandwidth adjustment trigger condition refers to the real-time bandwidth data being greater than a preset bandwidth threshold, or the receipt of an audio transmission access request from a high-priority IoT device. The gateway to be adjusted refers to the edge gateway among the multiple edge gateways whose bandwidth utilization exceeds the preset bandwidth threshold. A target IoT device is determined from the plurality of IoT devices connected to the gateway to be adjusted, and a target gateway is determined for the target IoT device. The target IoT device is an IoT device that represents a low service priority, and the target gateway is a gateway among the plurality of edge gateways that meets the bandwidth load conditions. Control the target IoT device to switch from the gateway to be adjusted to the target gateway, so as to reduce the bandwidth load of the gateway to be adjusted.

[0006] In one possible embodiment, determining the target gateway for the target IoT device includes: evaluating the load status and historical audio transmission stability of other gateways using a weighted round-robin algorithm to obtain an evaluation score, wherein the other gateways refer to gateway devices other than the gateway to be adjusted among the plurality of edge gateways, and the load status is a representation of the remaining bandwidth of the gateway; and determining the gateway with the higher evaluation score as the target gateway based on the evaluation score.

[0007] In one possible embodiment, the step of evaluating the load status and historical audio transmission stability of other gateways using a weighted round-robin algorithm to obtain an evaluation score includes: determining the load status based on the real-time bandwidth data of the other gateways and the total bandwidth configured for the other gateways; obtaining the average packet loss rate and the number of disconnections of the other gateways within a preset time period, and determining the packet loss rate score of the other gateways based on the average packet loss rate and a packet loss rate threshold, wherein the packet loss rate threshold is a preset maximum allowable packet loss rate; and determining the number of disconnections score of the other gateways based on the number of disconnections and a disconnection number threshold, wherein the disconnection number threshold is a preset maximum allowable number of disconnections; determining a stability score for evaluating the historical audio transmission stability based on the packet loss rate score and the number of disconnections score; configuring a first weighting coefficient for the load status, configuring a second weighting coefficient for the stability score, and determining the evaluation score based on the load status and the first weighting coefficient, and the stability score and the second weighting coefficient, wherein the sum of the first weighting coefficient and the second weighting coefficient is 1.

[0008] In one possible embodiment, controlling the target IoT device to switch from the gateway to be adjusted to the target gateway includes: pre-establishing an audio transmission channel for the target IoT device at the target gateway; controlling the target IoT device to suspend data forwarding on the original audio transmission path and controlling the gateway to be adjusted to temporarily freeze the network mapping relationship corresponding to the target IoT device; synchronizing the communication status of the target IoT device to the target gateway through the audio transmission channel, the communication status including the network mapping relationship and the audio session status; controlling the gateway to be adjusted to cache the cached audio data generated by the target IoT device during the switch and forwarding the cached audio data to the target gateway so that the target gateway can splice the data stream; receiving a switch success message sent by the target gateway to confirm that the target IoT device and the target gateway have established and connected an audio transmission link.

[0009] In one possible embodiment, forwarding the cached audio data to the target gateway includes: creating a temporary link between the gateway to be adjusted and the target gateway; sending a caching instruction to the target gateway, the caching instruction instructing the target gateway to enable cache reception; and pushing the cached audio data to the target gateway through the temporary link.

[0010] In one possible embodiment, the operation of splicing the data stream by the target gateway includes the following steps: receiving the cached audio data of the gateway to be adjusted and the real-time audio data of the target IoT device; sorting the cached audio data and the real-time audio data according to the timestamps carried by them in ascending order to obtain an audio data packet sequence; traversing the audio data packet sequence, if there are two adjacent data packets in the audio data packet sequence whose timestamp difference is less than a judgment threshold, then removing one of the two adjacent data packets to obtain a valid audio data packet sequence, wherein the judgment threshold is a time threshold used to determine whether two data packets belong to the same audio frame; and determining whether there are two adjacent data packets in the valid audio data packet sequence whose timestamp difference is greater than a certain threshold. The audio frame duration is the sum of the audio frame duration and the timestamp deviation threshold. The audio frame duration is a fixed attribute of the cached audio data and the real-time audio data. The timestamp deviation threshold refers to the maximum time threshold allowed between two data packets. If no such threshold exists, the valid audio data packet sequence is used as the target audio data stream for output. If a target number of silent frames is found, the target number of silent frames is determined based on the timestamp difference between two adjacent data packets, the audio frame duration, and the timestamp deviation threshold. The duration of the silent frames is consistent with the duration of the audio frames. The target number of silent frames is inserted into the two adjacent data packets until the timestamp difference between any two adjacent data packets in the valid audio data packet sequence is less than the sum of the audio frame duration and the timestamp deviation threshold.

[0011] In one possible embodiment, the method further includes: when a transmission request from a high-priority IoT device is received, and the dedicated bandwidth cannot meet the bandwidth resources required by the transmission request, temporarily using the redundant bandwidth of a low-priority IoT device, and releasing the redundant bandwidth after the high-priority IoT device finishes transmission, wherein the redundant bandwidth refers to configured but unused bandwidth resources; in response to low concurrency conditions, reducing the preset bandwidth threshold of the plurality of edge gateways, wherein the low concurrency conditions refer to the number of IoT devices connected to the plurality of edge gateways being lower than the preset concurrency threshold; and reclaiming the redundant bandwidth of the plurality of edge gateways.

[0012] Secondly, embodiments of this application provide an audio transmission bandwidth dynamic allocation device applied to the central gateway of a transmission control platform. The transmission control platform includes the central gateway and multiple edge gateways connected to the central gateway. Each edge gateway is communicatively connected to multiple IoT devices, and the multiple IoT devices support bidirectional audio transmission. The device includes an acquisition unit, a response unit, a determination unit, and a control unit. The acquisition unit is used to acquire real-time bandwidth data of the multiple edge gateways and the service priorities of the multiple IoT devices. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priorities are pre-configured by the central gateway to reflect bandwidth configuration priorities for different audio service scenarios. The response unit is used to respond to... Based on the bandwidth adjustment trigger condition, a gateway to be adjusted is determined. The bandwidth adjustment trigger condition refers to the real-time bandwidth data exceeding a preset bandwidth threshold or the receipt of an audio transmission access request from a high-priority IoT device. The gateway to be adjusted refers to an edge gateway among the plurality of edge gateways whose bandwidth utilization exceeds the preset bandwidth threshold. The determining unit is used to determine a target IoT device from the plurality of IoT devices connected to the gateway to be adjusted, and to determine a target gateway for the target IoT device. The target IoT device is an IoT device representing a low-priority service, and the target gateway is a gateway among the plurality of edge gateways that meets the bandwidth load condition. The control unit is used to control the target IoT device to switch from the gateway to be adjusted to the target gateway to reduce the bandwidth load of the gateway to be adjusted.

[0013] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, the memory being used to store one or more programs and configured to be executed by the processor, the programs including instructions for performing the steps in the first aspect of embodiments of this application.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the first aspect of embodiments of this application.

[0015] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the first aspect of embodiments of this application. The computer program product may be a software installation package.

[0016] As can be seen, the audio transmission bandwidth dynamic allocation method and related apparatus provided in this application are applied to the central gateway of a transmission control platform. The transmission control platform includes a central gateway and multiple edge gateways connected to the central gateway. Each edge gateway is communicatively connected to multiple IoT devices, and bidirectional audio transmission is supported between the IoT devices. The method includes: acquiring real-time bandwidth data from the multiple edge gateways and the service priorities of the multiple IoT devices. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priorities are pre-configured by the central gateway to reflect bandwidth configuration priorities for different audio service scenarios. The method responds to bandwidth adjustment triggers. The process involves several steps: First, determining the gateway to be adjusted. The bandwidth adjustment trigger condition is when real-time bandwidth data exceeds a preset bandwidth threshold or when an audio transmission access request is received from a high-priority IoT device. The gateway to be adjusted refers to the edge gateway among multiple edge gateways whose bandwidth utilization exceeds the preset bandwidth threshold. Then, a target IoT device is determined from the multiple IoT devices connected to the gateway to be adjusted. A target IoT device is then assigned a target gateway, representing a low-priority IoT device. The target gateway is the gateway among multiple edge gateways that meets the bandwidth load condition. Finally, the target IoT device is switched from the gateway to be adjusted to the target gateway to reduce the bandwidth load on the gateway to be adjusted. This constructs a core architecture of central gateway and edge gateways. By dynamically optimizing bandwidth allocation through the central gateway, problems such as stuttering and disconnections during audio transmission are solved, bandwidth resource waste is avoided, and the stability of bidirectional audio transmission is ensured. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1This is a schematic diagram of a transmission control platform provided in an embodiment of this application; Figure 2 This is a topology diagram of a transmission control platform provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a method for dynamically allocating audio transmission bandwidth according to an embodiment of this application; Figure 4 This is a schematic diagram illustrating an application scenario where a target IoT device connects to a target gateway, as provided in an embodiment of this application. Figure 5 This is a schematic diagram of a target gateway splicing data streams according to an embodiment of this application; Figure 6 This is a functional unit block diagram of an audio transmission bandwidth dynamic allocation device provided in an embodiment of this application; Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0020] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but in some embodiments includes steps or units not listed, or in some embodiments includes other steps or units inherent to these processes, methods, products, or apparatuses.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] In the embodiments of this application, "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the following three situations: A exists alone; A and B exist simultaneously; B exists alone. Among them, A and B can be singular or plural.

[0023] In this embodiment, the symbol " / " can indicate that the preceding and following objects are in an "or" relationship. Alternatively, the symbol " / " can also represent a division sign, i.e., performing a division operation. For example, A / B can mean A divided by B.

[0024] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0025] In the embodiments of this application, "equal to" can be used with "greater than" and is applicable to technical solutions used when "greater than" is used; it can also be used with "less than" and is applicable to technical solutions used when "less than" is used. When "equal to" is used with "greater than", it is not used with "less than"; when "equal to" is used with "less than", it is not used with "greater than".

[0026] The following describes the relevant content, concepts, meanings, technical issues, technical solutions, and beneficial effects involved in the embodiments of this application.

[0027] With the rapid development of IoT technology, traditional IoT devices such as speakers and smart panels are playing an increasingly important role in two-way audio transmission applications. These devices typically need to use edge gateways to interact with the cloud or other devices to support various business scenarios such as voice calls, audio broadcasting, and emergency communications.

[0028] However, existing IoT edge gateway technologies still have many shortcomings in supporting bidirectional audio transmission for traditional IoT devices: First, in scenarios with multiple devices transmitting concurrently, existing solutions are prone to bandwidth contention and data conflicts, leading to a decline in audio transmission quality. Second, uneven load distribution on edge gateways can cause stuttering and disconnections during audio transmission when a gateway is overloaded, severely impacting user experience. Third, existing solutions lack an effective bandwidth priority scheduling mechanism, failing to allocate bandwidth differently based on business importance, especially in emergency scenarios where transmission quality cannot be guaranteed. Furthermore, in low-concurrency scenarios, existing solutions waste bandwidth resources and fail to achieve dynamic optimization of resource allocation. Finally, traditional solutions are difficult to adapt to the hardware characteristics and performance limitations of IoT devices, either requiring significant hardware modifications or failing to meet the stable transmission requirements of high concurrency and low latency (≤100ms), severely limiting the application expansion of traditional IoT devices in bidirectional audio interaction scenarios.

[0029] To address the aforementioned issues, this application provides a method and related apparatus for dynamically allocating audio transmission bandwidth. By constructing a linkage architecture between a central gateway and edge gateways, the central gateway dynamically optimizes the bandwidth allocation strategy to ensure that each audio transmission channel occupies a stable bandwidth, thereby achieving efficient and stable audio data transmission, avoiding bandwidth resource waste, and ensuring the stability of bidirectional audio transmission.

[0030] First, the method in this embodiment is applied to the central gateway of the transmission control platform. The following is in conjunction with... Figure 1 The method for dynamically allocating audio transmission bandwidth in the embodiments of this application will be described. Figure 1 This is a system schematic diagram of a transmission control platform provided in an embodiment of this application, such as... Figure 1 As shown, the transmission control platform 10 includes a central gateway 110 and an edge gateway 120 that is communicatively connected to the central gateway 110; wherein, each edge gateway is communicatively connected to an IoT device 130. It should be understood that the number of IoT devices 130 is not limited here. There can be one, or each edge gateway can be communicatively connected to multiple IoT devices 130. Bidirectional audio transmission is supported between IoT devices.

[0031] The central gateway 110 is the control node of the entire transmission control platform 10. It is deployed at the core physical location of the local area network to ensure the stability and low latency of the communication links with each edge gateway 120. The central gateway 110 is equipped with a high-performance embedded processor and an industrial-grade network processing chip, and integrates wired or wireless communication modules such as Ethernet and Wi-Fi.

[0032] Edge gateways 120 serve as regional access nodes for the transmission control platform 10. Multiple edge gateways are deployed in a distributed manner based on the physical area division of the local area network. Each edge gateway 120 covers a designated physical area, such as an office area, meeting room, or floor zone. This effectively avoids signal attenuation and concentrated bandwidth load caused by an excessively large coverage area of ​​a single gateway, enabling regionalized distributed access for IoT devices 130. Edge gateways 120 establish a stable bidirectional communication link with the central gateway 110 via wired Ethernet or Wi-Fi, ensuring low-latency transmission of scheduling commands and core data. They also establish bidirectional communication links with IoT devices 130 within their respective areas using an adapted wireless communication protocol, meeting the uplink acquisition and downlink distribution needs of the IoT devices 130's audio data.

[0033] The IoT device 130 is a traditional IoT device with two-way audio interaction capability, which can be connected to the transmission control platform 10. Its specific types include, but are not limited to, smart speakers, smart voice panels, IoT voice terminals, smart conference speakers, smart central control devices with audio interaction functions, etc., all of which are deployed in the signal coverage area of ​​each edge gateway 120.

[0034] Specifically, the transmission control platform 10 in this application embodiment is built on a local area network and adopts the IP network communication protocol as a whole. It realizes the identification of each device, the establishment of transmission links and the effective transmission of audio data through IP address mapping technology. The central gateway 110 assigns a unique IP address within the local area network to all edge gateways 120 and IoT devices 130 in the platform, and assigns a dedicated network port number to each audio transmission link to realize accurate identification and management of devices and links.

[0035] First, the central gateway 110 acquires real-time bandwidth data from multiple edge gateways 120 and service priorities from multiple IoT devices 130. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priorities are pre-configured by the central gateway to reflect the bandwidth configuration priorities for different audio service scenarios. Second, in response to bandwidth adjustment triggering conditions, the central gateway 110 determines the gateway to be adjusted. The bandwidth adjustment triggering conditions are that the real-time bandwidth data is greater than a preset bandwidth threshold, or that an audio transmission access request is received from an IoT device with high service priority. The gateway to be adjusted refers to the edge gateway among the multiple edge gateways 120 whose bandwidth utilization exceeds the preset bandwidth threshold. Then, the central gateway 110 determines the target IoT device from the multiple IoT devices 130 connected to the gateway to be adjusted, and determines the target gateway for the target IoT device. The target IoT device is an IoT device representing low service priority, and the target gateway is the gateway among the multiple edge gateways 120 that meets the bandwidth load conditions. Finally, the central gateway 110 controls the target IoT device to switch from the gateway to be adjusted to the target gateway to reduce the bandwidth load of the gateway to be adjusted.

[0036] Specifically, please refer to Figure 2 , Figure 2 This is a topology diagram of a transmission control platform provided in an embodiment of this application, such as... Figure 2 As shown, the transmission control platform 10 uses a star topology with a central gateway 110 and edge gateways 120. The central gateway 110 is responsible for overall management, while the edge gateways 120 are responsible for regional coverage. The edge gateways 120 are deployed in different physical areas within the local area network, and their signal radiation range covers IoT devices 130 within a certain surrounding area. The central gateway 110 establishes a stable connection with all edge gateways 120 via wired (Ethernet) or wireless (WiFi) connections, forming a regional access and centralized scheduling architecture. Figure 2 The star topology shown enables regional distribution of bandwidth load, avoiding overload on a single node. At the same time, the centralized scheduling capability of the central gateway ensures low latency and stability for high-concurrency bidirectional IP audio transmission, improving the efficiency of platform bandwidth scheduling and the reliability of audio transmission.

[0037] The following is combined Figure 3 This application describes the method for dynamically allocating audio transmission bandwidth. Figure 3 This is a flowchart illustrating a method for dynamically allocating audio transmission bandwidth according to an embodiment of this application. Figure 3 The method flow shown is applied to, for example, Figure 1 The central gateway 110 shown includes the following steps: Step S310: Obtain real-time bandwidth data from multiple edge gateways and service priorities from multiple IoT devices.

[0038] Among them, real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and service priority is the bandwidth configuration priority pre-configured by the central gateway to reflect different audio service scenarios.

[0039] Among them, real-time bandwidth data refers to the current bandwidth usage status data of each edge gateway, which includes at least the actual bandwidth occupied by all IoT devices under the gateway when transmitting audio. It is a quantitative data reflecting the bandwidth load of the edge gateway. Service priority is a hierarchical parameter pre-configured by the central gateway according to the importance of the audio service scenario. It is used to reflect the bandwidth configuration priority of different audio service scenarios. Specifically, emergency calls, conference communication, and ordinary chat correspond to the first, second, and third priority levels, respectively.

[0040] Step S320: In response to the bandwidth adjustment trigger condition, determine the gateway to be adjusted.

[0041] The bandwidth adjustment trigger conditions refer to real-time bandwidth data exceeding a preset bandwidth threshold, or receiving an audio transmission access request from a high-priority IoT device. The gateway to be adjusted refers to the edge gateway among multiple edge gateways whose bandwidth utilization exceeds a preset bandwidth threshold. Specifically, for example, simultaneous transmission by 10 IoT devices in a single area causing the corresponding edge gateway's utilization to reach 92%, or the central gateway receiving a high-priority access request.

[0042] Specifically, when the real-time bandwidth utilization of any edge gateway exceeds the preset bandwidth threshold, it indicates that the gateway lacks sufficient bandwidth to support existing audio transmission services, potentially leading to audio stuttering and disconnections. Conversely, when an audio transmission access request is received from a high-priority IoT device, it signifies that the platform has added core audio service requirements, necessitating the reservation or allocation of bandwidth resources. If either of these scenarios is met, the bandwidth adjustment process is triggered. The central gateway compares the real-time bandwidth data of the edge gateways with the preset bandwidth threshold to identify all edge gateways with excessive bandwidth utilization.

[0043] Step S330: Determine the target IoT device from the multiple IoT devices connected to the gateway to be adjusted, and determine the target gateway for the target IoT device.

[0044] Among them, the target IoT device is an IoT device representing a low-priority service, and the target gateway is the gateway among multiple edge gateways that meets the bandwidth load conditions. The bandwidth utilization of the target gateway is within a preset threshold range, has remaining bandwidth resources, and can handle the audio transmission services of the target IoT device.

[0045] After identifying the gateway to be adjusted, the central gateway prioritizes selecting low-priority IoT devices from its subordinate IoT devices as target IoT devices to avoid affecting the normal transmission of high-priority audio services due to traffic splitting operations. At the same time, the central gateway checks the bandwidth load status of all other edge gateways in the platform except the gateway to be adjusted, and selects edge gateways with sufficient remaining bandwidth resources as target gateways.

[0046] Specifically, in one possible embodiment, determining the target gateway for the target IoT device includes: evaluating the load status and historical audio transmission stability of other gateways using a weighted round-robin algorithm to obtain an evaluation score, where other gateways refer to gateway devices other than the gateway to be adjusted among multiple edge gateways, and load status is a representation of the remaining bandwidth of the gateway; and determining the gateway with the higher evaluation score as the target gateway based on the evaluation score.

[0047] The weighted round-robin algorithm assigns weights to different evaluation dimensions and performs a comprehensive quantitative evaluation of gateways that meet the evaluation criteria, outputting a comprehensive evaluation score for each gateway to filter target gateways. The load status represents the quantitative status of the remaining bandwidth of each other gateway, which is the core dimension reflecting whether the gateway has the bandwidth carrying capacity. The higher the remaining bandwidth percentage, the lower the bandwidth load pressure of the gateway and the stronger its ability to undertake new audio transmission services. The historical audio transmission stability represents the stable operation of other gateways in the past audio transmission process, which is the core dimension reflecting whether the gateway can guarantee the audio transmission quality. The better the stability, the lower the probability of audio stuttering or disconnection after the gateway undertakes the target IoT device.

[0048] The evaluation score directly reflects the comprehensive ability of other gateways to handle the audio transmission services of the target IoT device. The gateway with the highest score has the best overall performance in terms of remaining bandwidth ratio and historical audio transmission stability. It has sufficient remaining bandwidth resources to handle the audio transmission of the target IoT device, effectively sharing the bandwidth load of the gateway to be adjusted, and ensuring the audio transmission quality of the target IoT device after migration, avoiding audio stuttering, disconnection and other failures due to the stability of the gateway itself. If there are multiple gateways with the same highest evaluation score, the central gateway can select one as the target gateway randomly or in a fixed order according to the preset round-robin rules.

[0049] As can be seen, in this embodiment, a weighted round-robin algorithm is used to evaluate the load status and historical audio transmission stability of other gateways, obtaining an evaluation score. Based on this score, the gateway with the highest evaluation score is selected as the target gateway. This avoids the problem of unreasonable gateway selection caused by subjective judgment, achieves objectivity in selecting target gateways, allows for more reasonable allocation of bandwidth resources, and further improves the overall bandwidth load balancing of the transmission control platform.

[0050] In other possible embodiments, before determining the target gateway for the target IoT device, the method further includes allocating logically independent transmission links to each device group, wherein the device group is a collective term for the edge gateway and the corresponding connected IoT device.

[0051] The central gateway first assigns a globally unique device group identifier to each device group. This identifier is associated with the device group's service attributes, access area, and other information, serving as the device group's identity. Next, it retrieves reserved network port resources within the transmission control platform and matches each device group with a unique network port number. This port number and device group identifier form a unique, one-to-one combination, which serves as the exclusive identifier for each device group's logical transmission link. Based on this unique combination of device group identifier and port number, the central gateway uses port multiplexing technology to virtualize and divide the physical transmission links, constructing an independent logical transmission link for each device group. These links are isolated from each other at the data transmission layer. Two-way audio data from the same device group can only be acquired uplink and distributed downlink within its dedicated logical link, without crossing links.

[0052] In addition, if a new high-priority device group initiates an audio transmission access request, the central gateway will immediately assign a unique device group identifier and a dedicated port number to it according to the above rules, and build an independent logical transmission link to ensure the transmission independence of the newly accessed device group.

[0053] Step S340: Control the target IoT device to switch from the gateway to be adjusted to the target gateway in order to reduce the bandwidth load of the gateway to be adjusted.

[0054] The central gateway, acting as the command hub of the transmission control platform, issues link switching commands to the target IoT device, the gateway to be adjusted, and the target gateway after identifying the target IoT device and the target gateway. This controls the target IoT device to gradually disconnect its audio transmission link from the gateway to be adjusted, while simultaneously establishing an audio transmission link with the target gateway, thus achieving the overall migration of the target IoT device's audio transmission services. Because the gateway to be adjusted reduces the audio transmission bandwidth usage of its subordinate target IoT devices, its overall bandwidth utilization will decrease until it falls back to within the preset bandwidth threshold range, achieving the core objective of reducing the bandwidth load on the gateway to be adjusted.

[0055] As can be seen, in this embodiment, firstly, real-time bandwidth data of multiple edge gateways and service priorities of multiple IoT devices are obtained. Secondly, in response to the bandwidth adjustment trigger condition, the gateway to be adjusted is determined. Then, the target IoT device is determined from the multiple IoT devices connected to the gateway to be adjusted, and a target gateway is determined for the target IoT device. Finally, the target IoT device is controlled to switch from the gateway to be adjusted to the target gateway to reduce the bandwidth load of the gateway to be adjusted. In this way, timely response to bandwidth adjustment is achieved, effectively avoiding audio transmission failures caused by bandwidth overload of edge gateways, which is conducive to balancing the bandwidth load of each edge gateway, improving the overall bandwidth resource utilization, and ensuring the transmission quality and stability of core audio services.

[0056] In one possible embodiment, a weighted round-robin algorithm is used to evaluate the load status and historical audio transmission stability of other gateways to obtain an evaluation score. This includes: determining the load status based on the real-time bandwidth data of other gateways and the total bandwidth configured for other gateways; obtaining the average packet loss rate and number of disconnections of other gateways within a preset time period, and determining the packet loss rate score of other gateways based on the average packet loss rate and a packet loss rate threshold, where the packet loss rate threshold is a preset maximum allowable packet loss rate; determining the number of disconnections score of other gateways based on the number of disconnections and a disconnection number threshold, where the disconnection number threshold is a preset maximum allowable number of disconnections; determining a stability score for evaluating the historical audio transmission stability based on the packet loss rate score and the number of disconnections score; configuring a first weighting coefficient for the load status and a second weighting coefficient for the stability score; and determining the evaluation score based on the load status, the first weighting coefficient, the stability score, and the second weighting coefficient, where the sum of the first weighting coefficient and the second weighting coefficient is 1.

[0057] Specifically, obtain other gateways g within a preset time period. i Average packet loss rate P loss,i and the number of disconnections C disconnect,i ; Based on the average packet loss rate P loss,i and packet loss rate threshold P max For example, 5%, determine the packet loss rate score S of other gateways. loss,i The following formula can be used to obtain: ; According to the above formula, the packet loss rate S loss,i Normalize the score (0-1); And, based on the number of disconnections C disconnect,i and the threshold C for the number of disconnections max For example, 3 times / minute, determine the score S for the number of disconnections from other gateways. disconnect,i The following formula yields: ; Based on the above formula, the number of disconnections C disconnect,i Normalize the score (0-1); Then, a stability score H is determined to evaluate the stability of historical audio transmission. i The following formula yields: ; Specifically, α and β are the weighting coefficients assigned to the packet loss rate score and the number of disconnections score, respectively, and can be adjusted according to actual needs. According to the above formula, a perfect score of 1 point corresponds to no historical disconnections, 0.2 points are deducted for each disconnection, and 0.1 points are deducted for every 1% of the packet loss rate, etc.

[0058] R calculated according to the above formulai H i Determine the evaluation score W i Please refer to the following formula: ; Among them, w R For load state R i The first weighting coefficient configured, R i This indicates the load status of other gateways, with a value ranging from 0% to 100%, calculated using the following formula: B used,i B represents the real-time bandwidth data of other gateways. total,i This indicates the total bandwidth configured for other gateways, w H For stability score H i The second weighting coefficient is configured.

[0059] Finally, confirm whether the remaining bandwidth percentage meets the minimum requirement, such as R. i ≥30%, if not satisfied, exclude directly, only retain those that satisfy R. i ≥R min The gateway, where R min The minimum remaining bandwidth threshold is set, for example, 30%. From the filtered set of gateways, the weighted score W is selected. i The highest gateway is used as the target gateway g target If multiple candidates have the same highest score, other factors, such as having the smallest gateway ID, can be considered for selection. Specifically, let the first weighting coefficient w be... R The second weighting coefficient is 0.8. H A weighted score of 0.2 indicates that edge gateway A has sufficient remaining bandwidth and no historical disconnection records, resulting in a weighted score of 0.85. Edge gateway B, on the other hand, does not meet the remaining bandwidth requirements, resulting in a weighted score of 0.6. Therefore, the central gateway ultimately selects edge gateway A as the target gateway. It should be understood that the above weighting coefficients are adjusted according to actual needs and are not limited to specific values.

[0060] As can be seen, in this embodiment, the historical audio transmission stability is evaluated by two indicators: average packet loss rate and number of disconnections, and then converted into a quantitative score. This achieves a comprehensive and multi-dimensional assessment of the gateway's transmission stability, avoiding evaluation bias caused by a single indicator and better meeting the actual needs of audio transmission. At the same time, the weighted round-robin algorithm is adapted to different high-concurrency audio transmission scenarios. The weights can be adjusted according to the different bandwidth or stability requirements of the scenario, improving the algorithm's scenario adaptability.

[0061] In one possible embodiment, controlling the target IoT device to switch from the gateway to be adjusted to the target gateway includes: pre-establishing an audio transmission channel for the target IoT device at the target gateway; controlling the target IoT device to suspend data forwarding on the original audio transmission path and controlling the gateway to be adjusted to temporarily freeze the network mapping relationship corresponding to the target IoT device; synchronizing the communication status of the target IoT device to the target gateway through the audio transmission channel, the communication status including the network mapping relationship and the audio session status; controlling the gateway to be adjusted to cache the cached audio data generated by the target IoT device during the switchover and forwarding the cached audio data to the target gateway so that the target gateway can splice the data stream; receiving a switchover success message sent by the target gateway to confirm that the target IoT device and the target gateway have established and connected an audio transmission link.

[0062] The audio transmission channel is a logical communication link for bidirectional IP audio data transmission, including a dedicated network port, audio transmission protocol, and data parsing rules. After identifying the target IoT device and the target gateway, the central gateway immediately sends a channel pre-construction instruction to the target gateway. The instruction includes key parameters such as the unique identifier of the target IoT device, the audio transmission bitrate, encoding format, and dedicated port allocation rules. Upon receiving the instruction, the target gateway allocates an unused network port to the target IoT device based on the parameters, configures the communication protocol and data parsing rules adapted for bidirectional audio transmission, completes the construction of the audio transmission channel, and reports the channel pre-construction completion status information back to the central gateway. At this point, the target gateway has the link conditions for audio data transmission with the target IoT device.

[0063] After receiving feedback that the target gateway channel has been pre-built, the central gateway simultaneously issues instructions to the target IoT device and the gateway to be adjusted: on the one hand, the target IoT device is instructed to immediately suspend sending and receiving audio data to and from the original audio transmission path, retaining only the basic functions of audio acquisition and playback, and continuing to generate audio data but not forwarding it for the time being; on the other hand, the gateway to be adjusted is instructed to perform a temporary freeze operation on the network mapping relationship corresponding to the target IoT device. After the freeze, the gateway to be adjusted will no longer forward any data to the target IoT device based on the mapping relationship.

[0064] Among them, the network mapping relationship refers to the correspondence between the device identifier of the target IoT device and the local area network IP address and network port recorded in the gateway to be adjusted; the audio session status refers to the real-time session information of the target IoT device's current audio transmission, including audio session identifier, encoding format, transmission bitrate, audio data timing stamp rules, and the transmission progress of the current session.

[0065] After synchronizing the communication status of the target IoT device, the central gateway sends a data caching and forwarding instruction to the gateway to be adjusted. Upon receiving the instruction, the gateway to be adjusted activates its local audio data caching module, caching all audio data generated and uploaded to the gateway by the target IoT device during the handover period in chronological order of generation, forming cached audio data. Subsequently, the gateway to be adjusted forwards all the cached audio data to the target gateway according to the preset forwarding rules. The target gateway receives this data and temporarily stores it. After confirming that the target IoT device and the target gateway have established an audio transmission link, the data stream splicing operation is performed.

[0066] Specifically, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating an application scenario where a target IoT device connects to a target gateway, as provided in an embodiment of this application. Figure 4 As shown, the target gateway 401 first establishes an audio transmission channel with the target IoT device 402. Then, during the cache switching process of the gateway to be adjusted 403, the cached audio data generated by the target IoT device is forwarded to the target gateway 401 through the communication link between the target gateway 401 and the gateway to be adjusted 403, so that the target gateway 401 can perform the splicing data stream operation.

[0067] As can be seen, in this embodiment, by pausing the original data forwarding and temporarily freezing the network mapping relationship, the data flow isolation between the target IoT device and the gateway to be adjusted is achieved, avoiding data corruption and duplication during the switching process, ensuring orderly switching, and enabling the target gateway to achieve seamless connection of the transmission link configuration for the audio transmission needs of the matching device, ensuring the continuity of the audio session, while avoiding audio data loss during the switching process and ensuring smooth audio playback.

[0068] In other possible embodiments, after confirming that the target IoT device and the target gateway have established and connected an audio transmission link, the method further includes: waiting for a preset time period and then sending a resource release instruction to the gateway to be adjusted. The resource release instruction instructs the gateway to be adjusted to delete the corresponding port of the target IoT device and release the audio transmission bandwidth resources occupied by the target IoT device.

[0069] For example, the central gateway waits 100ms to ensure there is no residual data transmission before issuing a resource release command to the gateway to be adjusted. The gateway to be adjusted deletes the original mapped port 40001 of terminal T1, releasing the occupied bandwidth resources, approximately 64kbps. Its bandwidth utilization rate drops from 90% to 80%, completing the seamless switching process.

[0070] In one possible embodiment, forwarding cached audio data to a target gateway includes: creating a temporary link between the gateway to be adjusted and the target gateway; sending a caching instruction to the target gateway, the caching instruction instructing the target gateway to enable cache reception; and pushing the cached audio data to the target gateway through the temporary link.

[0071] For example, the central gateway sends a pre-construction instruction to the target gateway. This instruction includes the device identifier of terminal T1, the original mapped port (192.168.1.10:40001), and the device group identifier (Group005). The target gateway detects that no resources are occupied within the port segment, allocates a dedicated UDP port 50001, creates a temporary mapping relationship between terminal T1 and port 50001, and reports the completion of channel pre-construction to the central gateway. Subsequently, the central gateway updates the global association table of "device identifier, edge gateway IP, and mapped port," updating the record for terminal T1 from "SN001-192.168.1.10-40001" to "SN001-192.168.1.11-50001," while freezing the original mapping relationship without deleting it. Then, a status synchronization instruction is sent to terminal T1 and the gateway to be adjusted. Terminal T1 switches its audio acquisition buffer to the pending transmission queue, and the gateway to be adjusted suspends forwarding T1's audio data to the original channel, retaining only the receiving link.

[0072] Next, the gateway to be adjusted initiates a caching mechanism, temporarily storing the two frames of audio data generated by terminal T1 during the handover period (approximately 20ms) in a local buffer. The central gateway synchronously instructs the target gateway to enable receive caching. The gateway to be adjusted pushes the cached data to the target gateway via a temporary link. The target gateway sorts the data by timestamp and then concatenates it with the subsequently received real-time audio data.

[0073] Please refer to the following: Figure 5 , Figure 5 This is a schematic diagram illustrating a process for splicing data streams at a target gateway, as provided in an embodiment of this application. Figure 5 The steps shown are as follows: S501 receives the cached audio data of the gateway to be adjusted and the real-time audio data of the target IoT device.

[0074] The set of cached audio data packets pushed from the gateway to be adjusted is C={cj|j=1,2,…,m}, where each cached audio data packet cj includes: timestamp tj, audio frame sequence number sj, and audio frame data payload dj. The set of real-time audio data packets directly received from the target IoT device is R={rk|k=1,2,…,n}, where each real-time audio data packet set rk includes: timestamp tk, audio frame sequence number sk, and audio frame data payload dk.

[0075] S502 sorts the audio data packets according to the timestamps carried by the cached audio data and the real-time audio data in ascending order of timestamps to obtain the audio data packet sequence.

[0076] All data packets are sorted in ascending order of their timestamps to obtain an ordered sequence P = [p1, p2, ..., pm+n], where p corresponds to the original data packet and satisfies t p1 ≤t p2 ≤ ≤t pm+n .

[0077] S503, traverse the audio data packet sequence. If the timestamp difference between two adjacent data packets in the audio data packet sequence is less than the judgment threshold, then remove one of the two adjacent data packets to obtain a valid audio data packet sequence.

[0078] If the timestamp difference between two adjacent packets is less than the timestamp comparison threshold, they are considered to correspond to the same audio frame. At this time, according to a preset strategy, such as retaining packets that arrive later or retaining packets with a lower packet loss rate, one of them is removed to obtain a valid audio data packet sequence.

[0079] S504, determine whether there are two adjacent data packets in the valid audio data packet sequence whose timestamp difference is greater than the sum of the audio frame duration and the timestamp deviation threshold; if not, proceed to step S505; if so, proceed to step S506.

[0080] The audio frame duration is a fixed attribute of both cached and real-time audio data, while the timestamp deviation threshold refers to the maximum allowed time interval between two data packets. The specific judgment formula is as follows: | -t prev -T frame |≤Δt max ; Among them, the timestamp of the previous frame t prev for The timestamp deviation threshold is Δt. max For example, 5ms is used to determine whether adjacent frames are continuous; the audio frame has a fixed duration of T. frame .

[0081] S505 outputs the valid audio data packet sequence as the target audio data stream.

[0082] That is, if If so, then time is considered continuous, and directly... Add to the output queue and update t. prev = .

[0083] S506 determines the target number of silent frames based on the timestamp difference between two adjacent data packets, the duration of the audio frame, and the timestamp deviation threshold.

[0084] The duration of the silent frame is the same as the duration of the audio frame. The above steps are as follows: if Δt > T frame +Δt max This indicates that frame drops have occurred. In this case, a silent frame can be inserted. The rule for inserting a silent frame is as follows: [The text abruptly ends here, likely due to an incomplete sentence or a formatting error.] prev +T frame A silent frame is generated at the specified location. This step is repeated until the frame is time-aligned with the next frame. Specifically, the target number L of silent frames to be inserted is shown in the following formula: ; For each inserted silent frame, output and update t. prev =t prev +T frame , until | t prev T frame |≤Δt max Until then. For example, if T frame =20ms, Δt max =5ms, Δt=70ms, then the calculation yields: L= (70 20 5) / 20 +1= 45 / 20 +1=2+1=3, This indicates that three silent frames need to be inserted, with timestamps t and t respectively. prev +20, t prev +40, t prev +60, the 4th frame should be the current packet, timestamp 70ms.

[0085] S507, insert the target number of silent frames into two adjacent data packets until the timestamp difference between any two adjacent data packets in the valid audio data packet sequence is less than the sum of the audio frame duration and the timestamp deviation threshold.

[0086] As can be seen, in this embodiment, by arranging the integrated data packets in ascending order of timestamps, the problem of timing discrepancies between cached and real-time data is resolved, ensuring the timing consistency of the audio data stream. By removing redundant data packets with timestamp differences less than a threshold, deduplication optimization of the audio data is achieved, avoiding repetition and stuttering issues during audio playback after splicing, thus improving the effectiveness of the audio data stream. By quantitatively calculating and inserting the target number of silent frames, gap filling between broken frames is achieved, effectively controlling audio experience loss during switching and improving the continuity and smoothness of audio transmission after switching the target IoT device gateway.

[0087] In one possible embodiment, the method further includes: when a transmission request from a high-priority IoT device is received and the dedicated bandwidth cannot meet the bandwidth resources required for the transmission request, temporarily calling the redundant bandwidth of a low-priority IoT device, and releasing the redundant bandwidth after the high-priority IoT device finishes transmission, where redundant bandwidth refers to configured but unused bandwidth resources; in response to low concurrency conditions, reducing the preset bandwidth threshold of multiple edge gateways, where low concurrency conditions refer to the number of IoT devices connected to multiple edge gateways being lower than the preset concurrency threshold; and reclaiming the redundant bandwidth of multiple edge gateways.

[0088] Dedicated bandwidth refers to the bandwidth resources reserved by the central gateway for high-priority IoT devices, specifically for their audio transmission, ensuring the transmission quality of high-priority services. Redundant bandwidth refers to the portion of bandwidth resources configured for low-priority IoT devices that has been configured but not actually used; this portion of resources is idle and can be temporarily allocated. The central gateway monitors the transmission status of high-priority IoT devices in real time. When it detects that a device has ended its audio transmission, it immediately releases the temporary occupation of the redundant bandwidth for the low-priority IoT device, restoring the bandwidth to its original allocation.

[0089] The central gateway continuously monitors the number of IoT devices actually connected to each edge gateway in real time, calculates the total number of connected devices, and compares it with a preset concurrency threshold. When the total number is lower than the preset concurrency threshold, it is determined that the low concurrency condition is met. After the platform determines that it has entered the low concurrency condition, it checks the bandwidth usage status of all edge gateways, filters out all redundant bandwidth configured for IoT devices in each gateway but not occupied, including redundant bandwidth of low-priority IoT devices and idle part of dedicated bandwidth of high-priority IoT devices, and uniformly reclaims it. This part of the resources is included in the global bandwidth resource pool and no longer belongs to a certain edge gateway or a certain type of IoT device. It is then uniformly scheduled and managed by the central gateway.

[0090] As can be seen, in this embodiment, by temporarily calling low-priority redundant bandwidth when the dedicated bandwidth of high-priority services is insufficient, the bandwidth guarantee for high-priority audio transmission is achieved, solving the bandwidth gap problem of sudden service transmission, and without affecting the normal transmission of low-priority services. By reducing the preset bandwidth threshold of edge gateways under low concurrency conditions, the platform can still maintain fine-grained bandwidth load management under low service volume, achieving bandwidth load balancing of each edge gateway in low concurrency scenarios, and recovering redundant bandwidth of edge gateways and incorporating it into the global resource pool, thus realizing global scheduling and efficient utilization of bandwidth resources.

[0091] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0092] and Figure 3 The implementation is consistent with the previous one; please refer to [link / reference]. Figure 6 , Figure 6 This is a functional unit block diagram of an audio transmission bandwidth dynamic allocation device provided in an embodiment of this application. The audio transmission bandwidth dynamic allocation device 600 is applied to, for example... Figure 1 The central gateway 110 shown includes an audio transmission bandwidth dynamic allocation device 600 comprising: an acquisition unit 610, a response unit 620, a determination unit 630, and a control unit 640. The acquisition unit 610 acquires real-time bandwidth data from multiple edge gateways and service priorities from multiple IoT devices. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priorities are pre-configured by the central gateway to reflect bandwidth configuration priorities for different audio service scenarios. The response unit 620 determines the gateway to be adjusted in response to a bandwidth adjustment trigger condition, where the bandwidth adjustment trigger condition refers to the real-time bandwidth... If the data exceeds a preset bandwidth threshold, or if an audio transmission access request is received from an IoT device with high service priority, the gateway to be adjusted refers to an edge gateway among multiple edge gateways whose bandwidth utilization exceeds a preset bandwidth threshold; the determining unit 630 is used to determine the target IoT device from among the multiple IoT devices connected to the gateway to be adjusted, and to determine the target gateway for the target IoT device. The target IoT device is an IoT device representing low service priority, and the target gateway is a gateway among multiple edge gateways that meets the bandwidth load condition; the control unit 640 is used to control the target IoT device to switch from the gateway to be adjusted to the target gateway, so as to reduce the bandwidth load of the gateway to be adjusted.

[0093] In one possible embodiment, in determining the target gateway for the target IoT device, the determining unit 630 is specifically used to: evaluate the load status and historical audio transmission stability of other gateways through a weighted round-robin algorithm to obtain an evaluation score, wherein other gateways refer to gateway devices other than the gateway to be adjusted among multiple edge gateways, and the load status is a representation of the remaining bandwidth of the gateway; and determine the gateway with the higher evaluation score as the target gateway based on the evaluation score.

[0094] In one possible embodiment, in evaluating the load status and historical audio transmission stability of other gateways using a weighted round-robin algorithm to obtain an evaluation score, the determining unit 630 is specifically configured to: determine the load status based on the real-time bandwidth data of other gateways and the total bandwidth configured for other gateways; obtain the average packet loss rate and number of disconnections of other gateways within a preset time period, and determine the packet loss rate score of other gateways based on the average packet loss rate and a packet loss rate threshold, wherein the packet loss rate threshold is a preset maximum allowable packet loss rate; and determine the number of disconnections score of other gateways based on the number of disconnections and a number of disconnections threshold, wherein the number of disconnections threshold is a preset maximum allowable number of disconnections; determine a stability score for evaluating the historical audio transmission stability based on the packet loss rate score and the number of disconnections score; configure a first weighting coefficient for the load status, configure a second weighting coefficient for the stability score, and determine the evaluation score based on the load status, the first weighting coefficient, the stability score, and the second weighting coefficient, wherein the sum of the first weighting coefficient and the second weighting coefficient is 1.

[0095] In one possible embodiment, in controlling the target IoT device to switch from the gateway to be adjusted to the target gateway, the control unit 640 is specifically configured to: pre-establish an audio transmission channel for the target IoT device at the target gateway; control the target IoT device to suspend data forwarding of the original audio transmission path and control the gateway to be adjusted to temporarily freeze the network mapping relationship corresponding to the target IoT device; synchronize the communication status of the target IoT device to the target gateway through the audio transmission channel, the communication status including the network mapping relationship and the audio session status; control the gateway to be adjusted to cache the cached audio data generated by the target IoT device during the switching period and forward the cached audio data to the target gateway so that the target gateway can splice the data stream; receive a switching success message sent by the target gateway to confirm that the target IoT device and the target gateway have established and connected an audio transmission link.

[0096] In one possible embodiment, in forwarding cached audio data to the target gateway, the control unit 640 is specifically configured to: create a temporary link between the gateway to be adjusted and the target gateway; send a caching instruction to the target gateway, the caching instruction instructing the target gateway to enable cache reception; and push the cached audio data to the target gateway via the temporary link.

[0097] In one possible embodiment, regarding the operation of splicing data streams at the target gateway, the control unit 640 is specifically configured to: receive cached audio data from the gateway to be adjusted and real-time audio data from the target IoT device; sort the cached audio data and real-time audio data according to the timestamps carried by them in ascending order to obtain an audio data packet sequence; traverse the audio data packet sequence, and if there are two adjacent data packets in the audio data packet sequence whose timestamp difference is less than a judgment threshold, then remove one of the two adjacent data packets to obtain a valid audio data packet sequence. The judgment threshold is a time threshold used to determine whether two data packets belong to the same audio frame; determine whether there are two adjacent data packets in the valid audio data packet sequence. If the timestamp difference between the data packets is greater than the sum of the audio frame duration and the timestamp deviation threshold, and the audio frame duration is a fixed attribute of both cached and real-time audio data, and the timestamp deviation threshold is the maximum allowed time between two data packets, then if no such threshold exists, the valid audio data packet sequence is used as the target audio data stream for output. If a target number of silent frames is found, the target number of silent frames is determined based on the timestamp difference between two adjacent data packets, the audio frame duration, and the timestamp deviation threshold. The duration of the silent frames is the same as the audio frame duration. The target number of silent frames is inserted into two adjacent data packets until the timestamp difference between any two adjacent data packets in the valid audio data packet sequence is less than the sum of the audio frame duration and the timestamp deviation threshold.

[0098] In one possible embodiment, the audio transmission bandwidth dynamic allocation device 600 is further configured to: temporarily call the redundant bandwidth of the low-priority IoT device when a transmission request from a high-priority IoT device is received and the dedicated bandwidth cannot meet the bandwidth resources required for the transmission request; and release the redundant bandwidth after the high-priority IoT device finishes transmission, where redundant bandwidth refers to configured but unused bandwidth resources; reduce the preset bandwidth threshold of multiple edge gateways in response to low concurrency conditions, where low concurrency conditions refer to the number of IoT devices connected to multiple edge gateways being lower than the preset concurrency threshold; and reclaim the redundant bandwidth of multiple edge gateways.

[0099] It is understood that since the method embodiments and the device embodiments are different presentations of the same technical concept, the content of the method embodiment section in this application should be adapted to the device embodiment section in a synchronous manner, and will not be repeated here.

[0100] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. For example... Figure 7As shown, electronic device 700 may include one or more components: a processor 701 and a memory 702 coupled to the processor 701, wherein the memory 702 may store one or more computer programs, which may be configured to implement the methods described in the examples above when executed by one or more processors 701. Electronic device 700 may be as follows: Figure 1 The central gateway 110 is shown.

[0101] Processor 701 may include one or more processing cores. Processor 701 connects to various parts within the electronic device 700 using various interfaces and lines, and performs various functions and processes data of the electronic device 700 by running or executing instructions, programs, code sets, or instruction sets stored in memory 702, and by calling data stored in memory 702. Optionally, processor 701 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 701 may integrate one or more of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. It is understood that the aforementioned modem may also not be integrated into processor 701, but may be implemented separately through a communication chip.

[0102] The memory 702 may include random access memory (RAM) or read-only memory (ROM). The memory 702 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 702 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method examples described above. The data storage area may also store data created during the use of the electronic device 700.

[0103] It is understood that the electronic device 700 may include more or fewer structural elements than those shown in the above block diagram, such as a power module, physical buttons, WiFi (Wireless Fidelity) module, speaker, Bluetooth module, sensor, etc., without limitation.

[0104] This application also provides a computer storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements some or all of the steps of any of the methods described in the above method embodiments.

[0105] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0106] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0107] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and there may be other division methods in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0108] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0109] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can be physically comprised separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0110] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute partial steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes: a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, volatile memory, or non-volatile memory. The 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. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM), etc., which are various media capable of storing program code.

[0111] While the present invention has been disclosed above, it is not limited thereto. Any person skilled in the art can easily conceive of variations or substitutions without departing from the spirit and scope of the present invention, and various modifications and alterations can be made, including combinations of the different functions and implementation steps described above, as well as software and hardware implementation methods, all of which are within the protection scope of the present invention.

Claims

1. A method for dynamically allocating audio transmission bandwidth, characterized in that, A central gateway is applied to a transmission control platform, wherein the transmission control platform includes the central gateway and multiple edge gateways connected to the central gateway, the multiple edge gateways being communicatively connected to multiple IoT devices, and the multiple IoT devices supporting bidirectional audio transmission; the method includes: The system obtains real-time bandwidth data of the multiple edge gateways and service priorities of the multiple IoT devices. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priorities are bandwidth configuration priorities pre-configured by the central gateway to reflect different audio service scenarios. In response to a bandwidth adjustment trigger condition, a gateway to be adjusted is determined. The bandwidth adjustment trigger condition refers to the real-time bandwidth data being greater than a preset bandwidth threshold, or the receipt of an audio transmission access request from a high-priority IoT device. The gateway to be adjusted refers to the edge gateway among the multiple edge gateways whose bandwidth utilization exceeds the preset bandwidth threshold. A target IoT device is determined from the plurality of IoT devices connected to the gateway to be adjusted, and a target gateway is determined for the target IoT device. The target IoT device is an IoT device that represents a low service priority, and the target gateway is a gateway among the plurality of edge gateways that meets the bandwidth load conditions. Control the target IoT device to switch from the gateway to be adjusted to the target gateway, so as to reduce the bandwidth load of the gateway to be adjusted; When a transmission request is received from a high-priority IoT device, and the dedicated bandwidth cannot meet the bandwidth resources required by the transmission request, the redundant bandwidth of a low-priority IoT device is temporarily used. After the high-priority IoT device finishes transmission, the redundant bandwidth is released. The redundant bandwidth refers to configured but unused bandwidth resources. In response to low concurrency conditions, the preset bandwidth threshold of the multiple edge gateways is reduced. The low concurrency condition means that the number of IoT devices connected to the multiple edge gateways is lower than the preset concurrency threshold. The redundant bandwidth of the multiple edge gateways is also reclaimed.

2. The method according to claim 1, characterized in that, Determining the target gateway for the target IoT device includes: The load status and historical audio transmission stability of other gateways are evaluated using a weighted round-robin algorithm to obtain an evaluation score. The other gateways refer to the gateway devices other than the gateway to be adjusted among the multiple edge gateways. The load status is a representation of the remaining bandwidth of the gateway. Based on the evaluation score, the gateway with the higher evaluation score is selected as the target gateway.

3. The method according to claim 2, characterized in that, The weighted round-robin algorithm is used to evaluate the load status and historical audio transmission stability of other gateways, resulting in an evaluation score, including: The load status is determined based on the real-time bandwidth data of the other gateways and the total bandwidth configured for the other gateways; The system obtains the average packet loss rate and the number of disconnections of the other gateways within a preset time period. Based on the average packet loss rate and the packet loss rate threshold, it determines the packet loss rate score of the other gateways, where the packet loss rate threshold is a preset maximum allowable packet loss rate. It also determines the number of disconnections score of the other gateways based on the number of disconnections and the number of disconnections threshold, where the number of disconnections threshold is a preset maximum allowable number of disconnections. Finally, based on the packet loss rate score and the number of disconnections score, it determines a stability score used to evaluate the stability of the historical audio transmission. A first weighting coefficient is configured for the load state, a second weighting coefficient is configured for the stability score, and the evaluation score is determined based on the load state and the first weighting coefficient, the stability score and the second weighting coefficient, wherein the sum of the first weighting coefficient and the second weighting coefficient is 1.

4. The method according to claim 2 or 3, characterized in that, The control of the target IoT device to switch from the gateway to be adjusted to the target gateway includes: An audio transmission channel for the target IoT device is pre-established at the target gateway. Control the target IoT device to pause data forwarding along the original audio transmission path, and control the gateway to be adjusted to temporarily freeze the network mapping relationship corresponding to the target IoT device; The communication status of the target IoT device is synchronized to the target gateway through the audio transmission channel, and the communication status includes network mapping relationship and audio session status. The gateway to be adjusted is controlled to cache the cached audio data generated by the target IoT device during the handover, and forward the cached audio data to the target gateway so that the target gateway splices the data stream; The system receives a successful handover message from the target gateway, confirming that the target IoT device and the target gateway have established and connected an audio transmission link.

5. The method according to claim 4, characterized in that, Forwarding the cached audio data to the target gateway includes: Create a temporary link between the gateway to be adjusted and the target gateway; Send a caching instruction to the target gateway, the caching instruction instructing the target gateway to enable cache reception; The cached audio data is pushed to the target gateway via the temporary link.

6. The method according to claim 5, characterized in that, The operation of splicing data streams at the target gateway includes the following steps: Receive the cached audio data of the gateway to be adjusted and the real-time audio data of the target IoT device; Based on the timestamps carried by the cached audio data and the real-time audio data, the data packets are sorted in ascending order of timestamps to obtain an audio data packet sequence. Traverse the audio data packet sequence. If the timestamp difference between two adjacent data packets in the audio data packet sequence is less than the judgment threshold, then remove one of the two adjacent data packets to obtain a valid audio data packet sequence. The judgment threshold is a time threshold used to determine whether two data packets belong to the same audio frame. Determine whether there are two adjacent data packets in the valid audio data packet sequence whose timestamp difference is greater than the sum of the audio frame duration and the timestamp deviation threshold. The audio frame duration is a fixed attribute of the cached audio data and the real-time audio data. The timestamp deviation threshold refers to the maximum time threshold allowed between two data packets. If it does not exist, the valid audio data packet sequence will be used as the target audio data stream and output. If they exist, the target number of silent frames is determined based on the timestamp difference between the two adjacent data packets, the duration of the audio frame, and the timestamp deviation threshold. The duration of the silent frame is the same as the duration of the audio frame. The target number of silent frames are inserted into the two adjacent data packets until the timestamp difference between any two adjacent data packets in the effective audio data packet sequence is less than the sum of the audio frame duration and the timestamp deviation threshold.

7. An audio transmission bandwidth dynamic allocation device, characterized in that, A central gateway is applied to a transmission control platform, wherein the transmission control platform includes the central gateway and multiple edge gateways connected to the central gateway, the multiple edge gateways being communicatively connected to multiple IoT devices, and the multiple IoT devices supporting bidirectional audio transmission; the device includes: an acquisition unit, a response unit, a determination unit, and a control unit, the audio transmission bandwidth dynamic allocation device being used to execute the audio transmission bandwidth dynamic allocation method as described in any one of claims 1-6; wherein... The acquisition unit is used to acquire the real-time bandwidth data of the multiple edge gateways and the service priority of the multiple IoT devices. The real-time bandwidth data includes at least the bandwidth occupied by audio transmission, and the service priority is a bandwidth configuration priority pre-configured by the central gateway to reflect different audio service scenarios. The response unit is used to determine the gateway to be adjusted in response to the bandwidth adjustment trigger condition. The bandwidth adjustment trigger condition refers to the real-time bandwidth data being greater than the preset bandwidth threshold or receiving an audio transmission access request from an IoT device with high service priority. The gateway to be adjusted refers to the edge gateway among the multiple edge gateways whose bandwidth utilization exceeds the preset bandwidth threshold. The determining unit is used to determine a target IoT device from the plurality of IoT devices connected to the gateway to be adjusted, and to determine a target gateway for the target IoT device. The target IoT device is an IoT device that represents a low service priority, and the target gateway is a gateway among the plurality of edge gateways that meets the bandwidth load conditions. The control unit is used to control the target IoT device to switch from the gateway to be adjusted to the target gateway, so as to reduce the bandwidth load of the gateway to be adjusted.

8. An electronic device, characterized in that, It includes a processor and a memory, the memory being used to store one or more programs and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, A computer program for storing electronic data interchange is provided, wherein the computer program causes a computer to perform the method as described in any one of claims 1-6.

Images