Message transmission method and device, equipment and storage medium

Abstract

The invention discloses a message transmission method and device, equipment and a storage medium, and relates to the technical field of wireless communication, and the method comprises the steps: monitoring an air interface resource occupancy rate of a communication link between plug-and-play equipment and Internet of Things equipment; receiving a plurality of existence declaration messages sent by the plug-and-play equipment; and when the air interface resource occupancy rate is higher than a preset proportion threshold value, discarding a part of the existence declaration message, and forwarding a part of the existence declaration message which is not discarded to the Internet of Things equipment. According to the method and the device, the number of existence declaration messages received by the Internet of Things equipment is actively reduced when air interface resources are insufficient, so that ICMP unreachable messages generated due to error response are reduced, the transmission quantity of redundant messages on a communication link is effectively reduced, the problem of channel congestion caused by the fact that a large number of ICMP messages occupy the air interface resources is directly relieved, and the service life of the Internet of Things equipment is prolonged. The availability and the stability of a wireless network are improved, and the normal communication capability of the Internet of Things equipment under limited air interface resources is ensured.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a message transmission method, apparatus, device and storage medium. Background Technology

[0002] In wireless networks with a large number of IoT (Internet of Things) devices, air interface resources in the 2G band are particularly scarce because most IoT devices only support 2G networks. After devices supporting screen mirroring, such as TVs, TV boxes, and projectors, connect to the network, these devices periodically send multicast SSDP NOTIFY messages to declare their presence in order to support the UPnP (Universal Plug and Play) protocol. However, some IoT devices do not support the SSDP (Simple Service Discovery Protocol) protocol and will misinterpret the SSDP NOTIFY message as an access to their own UDP (User Datagram Protocol) port 1900. Since the IoT device does not support this service, it will send a unicast ICMP (Internet Control Message Protocol) unreachable message to the TV or other devices, and will fill in the ICMP message with the SSDP NOTIFY message verbatim.

[0003] At this time, because some UPnP-enabled devices such as TVs send SSDP NOTIFY messages frequently, when a large number of IoT devices that do not support the SSDP protocol are on the same wireless network, each IoT device will reply with an ICMP unreachable message for every SSDP NOTIFY message it receives. Given the already congested 2G channels, the frequent ICMP unreachable messages sent by IoT devices can easily lead to excessively high overall occupancy of 2G air interface resources, resulting in the 2G channel becoming essentially unusable and terminals being unable to connect. Summary of the Invention

[0004] The main objective of this application is to provide a message transmission method, apparatus, device, and storage medium, which aims to solve the technical problem of easy channel congestion in router wireless networks joined by IoT devices and UPnP devices.

[0005] To achieve the above objectives, this application proposes a message transmission method, the message transmission method comprising: Monitor the air interface resource utilization rate of communication links between plug-and-play devices and IoT devices; Receive multiple presence declaration messages sent by the plug-and-play device; If the air interface resource occupancy rate is higher than a preset threshold, some of the existence declaration messages in each existence declaration message will be discarded, and the remaining existence declaration messages in each existence declaration message will be forwarded to the IoT device.

[0006] In one embodiment, the step of receiving a plurality of presence declaration messages sent by the plug-and-play device includes: Receive data traffic transmitted by the plug-and-play device; The message characteristics of the existing declaration message are compared with the traffic characteristics of the data traffic; If the message characteristics match the traffic characteristics, the data traffic is determined to be the presence declaration message.

[0007] In one embodiment, the message characteristics include the calibration destination address of the presence declaration message, calibration method attribute, calibration notification subtype field, and calibration device identifier. The step of comparing the message characteristics of the presence declaration message with the traffic characteristics of the data traffic includes: Extract the traffic characteristics of the data traffic, wherein the traffic characteristics include destination address, method attribute, notification subtype field and device identifier; The destination address is compared with the calibrated destination address, the method attribute is compared with the calibrated method attribute, the notification subtype field is compared with the calibrated notification subtype field, and the device identifier is compared with the calibrated device identifier. If the destination address matches the calibration destination address, the method attribute matches the calibration method attribute, the notification subtype field matches the calibration notification subtype field, and the device identifier matches the calibration device identifier, then the message feature matches the traffic feature.

[0008] In one embodiment, the step of discarding a portion of the existence declaration messages in each of the existence declaration messages includes: Extract the cache control field of each of the stated existence declaration messages, and determine the rated transmission frequency based on the maximum effective duration corresponding to each of the stated cache control fields; Some of the existence declaration messages in each of the existence declaration messages are discarded, so that the remaining existence declaration messages in each of the existence declaration messages are forwarded to the IoT device at the rated transmission frequency.

[0009] In one embodiment, the step of determining the rated transmission frequency based on the maximum effective duration corresponding to each of the buffer control fields includes: For any cache control field, determine the maximum valid duration corresponding to the maximum valid time subfield in the cache control field; After traversing each of the cache control fields, determine the smallest maximum valid duration among the maximum valid durations. The control period is determined based on the ratio of the minimum maximum effective duration to a preset coefficient, and the rated transmission frequency is determined based on the control period and the preset message control quantity.

[0010] In one embodiment, before the step of determining the control period based on the ratio of the minimum maximum effective duration to a preset coefficient, the method further includes: A preset coefficient is determined based on the air interface resource occupancy rate, wherein the air interface resource occupancy rate is positively correlated with the preset coefficient.

[0011] In one embodiment, the message transmission method further includes: Monitor the channel interference level and terminal association failure rate of the communication link; The air interface status of the communication link is assessed based on the air interface resource occupancy rate, the channel interference level, and the terminal association failure rate. If the air interface status meets the preset congestion status, the step of discarding some of the existence declaration messages in each existence declaration message and subsequent steps are executed.

[0012] Furthermore, to achieve the above objectives, this application also proposes a message transmission apparatus, the message transmission apparatus comprising: The monitoring module is used to monitor the air interface resource utilization of the communication link between plug-and-play devices and IoT devices; The receiving module is used to receive multiple presence declaration messages sent by the plug-and-play device; The forwarding module is used to discard a portion of the existence declaration messages in each existence declaration message when the air interface resource occupancy rate is higher than a preset ratio threshold, and to forward the remaining existence declaration messages in each existence declaration message to the Internet of Things device.

[0013] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the message transmission method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the message transmission method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application monitors the air interface resource occupancy rate of the communication link and selectively discards multiple existence declaration messages continuously sent by plug-and-play devices when the occupancy rate exceeds a preset threshold. Only the messages that are not discarded are forwarded to the IoT devices. This proactively reduces the number of existence declaration messages received by IoT devices when air interface resources are scarce, thereby reducing ICMP unreachable messages caused by erroneous responses from IoT devices. This effectively reduces the amount of redundant messages transmitted on the communication link, directly alleviates the channel congestion problem caused by a large number of ICMP messages occupying air interface resources, improves the availability and stability of the wireless network, and ensures the normal communication capability of IoT devices under limited air interface resources. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the message transmission method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the message transmission method of this application; Figure 3 A simplified flowchart illustrating the message transmission method provided in Embodiment 2 of this application; Figure 4 This is another simplified flowchart illustrating the message transmission method provided in Embodiment 2 of this application; Figure 5 This is a schematic diagram of the module structure of the message transmission device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the message transmission method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: monitoring the air interface resource occupancy rate of the communication link between the plug-and-play device and the IoT device; receiving multiple presence declaration messages sent by the plug-and-play device; when the air interface resource occupancy rate is higher than a preset ratio threshold, discarding some of the presence declaration messages in each presence declaration message, and forwarding the remaining presence declaration messages in each presence declaration message to the IoT device.

[0023] Because some UPnP-enabled devices, such as TVs, send SSDP NOTIFY messages frequently, when a large number of IoT devices that do not support the SSDP protocol are on the same wireless network, each IoT device that receives an SSDP NOTIFY message will reply with an ICMP unreachable message. Given the already congested 2G channels, the frequent ICMP unreachable messages sent by IoT devices can easily lead to excessively high overall occupancy of 2G air interface resources, resulting in the 2G channel becoming essentially unusable and terminals being unable to connect.

[0024] This application provides a solution that monitors the air interface resource occupancy rate of the communication link and selectively discards multiple existence declaration messages continuously sent by plug-and-play devices when the occupancy rate exceeds a preset threshold. Only the messages that are not discarded are forwarded to the IoT device. This proactively reduces the number of existence declaration messages received by the IoT device when air interface resources are scarce, thereby reducing ICMP unreachable messages caused by erroneous responses from the IoT device. This effectively reduces the amount of redundant messages transmitted on the communication link, directly alleviates the channel congestion problem caused by a large number of ICMP messages occupying air interface resources, improves the availability and stability of the wireless network, and ensures the normal communication capability of IoT devices under limited air interface resources.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, router, etc., or an electronic device or message transmission system capable of performing the above functions. The following description uses a message transmission system as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a message transmission method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the message transmission method of this application.

[0027] In this embodiment, the message transmission method includes steps S10 to S30: Step S10: Monitor the air interface resource utilization rate of the communication link between the plug-and-play device and the IoT device; It should be noted that plug-and-play devices refer to network devices that support the UPnP protocol and can actively discover services, such as smart TVs, TV boxes, or projectors. These devices periodically send specific multicast messages to the network, such as SSDP NOTIFY messages, which are also known as presence declaration messages, to declare their presence and available services in the network.

[0028] IoT devices are IoT terminal devices that are connected to the same wireless network but may or may not support or be fully compatible with the SSDP protocol, such as smart sensors, sockets, or lamps. These devices may generate erroneous response traffic when processing unexpected protocol messages. For example, they may misidentify SSDP NOTIFY messages as accesses to their own UDP port 1900. If the IoT device does not support this service, it will send a unicast ICMP unreachable message to plug-and-play devices such as TVs and fill the ICMP message with the SSDP NOTIFY message verbatim, resulting in an excessively high overall air interface resource utilization.

[0029] Air interface resource occupancy rate is a quantitative indicator of the busyness of the physical layer transmission medium in a wireless communication link. Specifically, it can be, but is not limited to, the percentage of time used for actual data transmission to the total available time within a specific time period. The level of this value directly reflects the channel congestion situation.

[0030] Step S20: Receive multiple presence declaration messages sent by the plug-and-play device; It should be noted that existence declaration messages refer to multicast messages periodically sent by plug-and-play devices to declare their network reachability and service information. Specifically, they can be, but are not limited to, messages with the METHOD of the SSDP protocol set to "NOTIFY" and a destination address and port set to a specific multicast address (such as 239.255.255.250:1900).

[0031] Step S30: If the air interface resource occupancy rate is higher than a preset ratio threshold, discard some of the existence declaration messages in each existence declaration message, and forward the remaining existence declaration messages in each existence declaration message to the IoT device.

[0032] Understandably, some IoT devices may respond with a large number of ICMP unreachable messages due to mistakenly receiving continuous presence declaration messages from plug-and-play devices, thereby excessively consuming wireless channel resources. Therefore, this embodiment addresses this by discarding a portion of the received presence declaration messages when the air interface resource occupancy rate of the communication link exceeds a preset threshold, and forwarding only the remaining portion to the IoT device. This reduces the number of times the IoT device triggers ICMP response messages from the source, avoiding problems such as the entire wireless network channel becoming unavailable and terminals being unable to associate due to massive ICMP invalid response messages congesting the air interface. This achieves the effect of significantly reducing air interface load and restoring and maintaining stable wireless network communication capabilities while ensuring the basic service discovery function of plug-and-play devices.

[0033] For example, in a wireless router, the air interface resource utilization of the 2G band communication link between the connected smart TV and multiple IoT terminals is monitored in real time through its wireless driver. When the router continuously receives UDP packets destined for multicast address 239.255.255.250:1900 from the smart TV's wireless interface, it identifies them as presence declaration packets. Once the current air interface resource utilization exceeds a preset 70% threshold, the router initiates a discarding mechanism, for example, randomly discarding subsequent received such packets with a fixed probability of 50%, while forwarding the remaining packets that are not discarded to all IoT devices in the network through its LAN interface, thereby reducing the air interface load.

[0034] This embodiment provides a message transmission method that monitors the air interface resource occupancy rate of the communication link. When the occupancy rate exceeds a preset threshold, it selectively discards multiple existence declaration messages continuously sent by the plug-and-play device, forwarding only the remaining messages to the IoT device. This proactively reduces the number of existence declaration messages received by the IoT device when air interface resources are scarce, thereby reducing ICMP unreachable messages caused by erroneous responses from the IoT device. This effectively reduces the amount of redundant messages transmitted on the communication link, directly alleviating the channel congestion problem caused by a large number of ICMP messages occupying air interface resources, improving the availability and stability of the wireless network, and ensuring the normal communication capability of IoT devices under limited air interface resources.

[0035] In one feasible implementation, step S20 may include steps S21 to S23: Step S21: Receive the data traffic transmitted by the plug-and-play device; It should be noted that data traffic refers to the raw set of network data continuously sent from the network interface of plug-and-play devices and transmitted through the communication link. This data may include, but is not limited to, all unfiltered network packets flowing through the monitoring point. These packets may exist in the form of bit streams or data packet sequences, and may cover mixed data with different protocols, different destination addresses and different service functions. It is the basic input stream for subsequent packet identification and processing.

[0036] Step S22: Compare the message characteristics of the declared message with the traffic characteristics of the data traffic; It should be noted that message features are a set of static criterion attributes predefined and configured based on relevant protocol specifications. These features describe the key condition templates that a message must meet to be considered valid, including but not limited to elements such as the destination address, method attribute, and notification subtype field specified by the protocol. These features serve as identification benchmarks for matching and filtering during data processing, ensuring accurate identification of message types that require restrictions.

[0037] Traffic characteristics are the actual attribute information dynamically extracted from received data traffic through real-time parsing technology. These characteristics reflect the real-time content and structural details of each packet or data stream, such as the specific destination address, method attribute, and notification subtype field values ​​parsed from the packet header. In this embodiment, traffic characteristics serve as the actual basis for comparing real-time data with packet characteristics. The comparison results determine whether the data traffic contains a presence declaration packet, thereby triggering subsequent air interface resource occupancy judgment and processing mechanisms.

[0038] Step S23: If the message characteristics match the traffic characteristics, the data traffic is determined to be the presence declaration message.

[0039] Understandably, in order to effectively perform the drop operation, it is first necessary to accurately and reliably identify the presence declaration messages that need to be restricted from the mixed data stream sent by the plug-and-play device. If the identification is inaccurate or missing, it cannot be ensured that the restriction measures only apply to the target message, which may lead to the wrong restriction of other normal business traffic or the omission of the target message, thus failing to achieve the expected goal of optimizing air interface resources, or even causing network function abnormalities.

[0040] Therefore, this implementation does not immediately discard or forward data traffic received from the plug-and-play device. Instead, it first compares the predefined presence declaration message characteristics with the traffic characteristics extracted in real time from the data traffic. Only after the comparison matches and the current data traffic is confirmed to be a genuine presence declaration message is the subsequent air interface resource occupancy rate judgment and selective discarding process triggered. This establishes a pre-emptive accurate identification and confirmation mechanism, avoiding two major technical problems that may arise from the inability to distinguish message types: first, mistakenly discarding other important service messages as presence declaration messages, leading to damage to core functions such as screen projection or network service interruption; second, failing to accurately identify all target messages, causing some presence declaration messages to escape restrictions and continue to trigger ICMP responses from IoT devices, thus failing to fundamentally solve the air interface congestion problem. Therefore, by adding a precise filtering and confirmation step for message types, the high targeting and accuracy of subsequent frequency limiting actions are ensured, thereby effectively alleviating air interface congestion while ensuring the seamless passage of other normal network service traffic, improving the reliability, intelligence, and practicality of the entire solution.

[0041] For example, a feature recognition module is deployed in the router. When the router receives raw data traffic (represented as a series of UDP packets) continuously sent from plug-and-play devices such as smart TVs from its local area network interface, the module first performs deep parsing on each received packet to extract the actual traffic characteristics of the packet, including but not limited to the destination address, transport layer protocol type, destination port number, and key field values ​​in the application layer protocol header. At the same time, the module pre-configures message features for defining "existence declaration messages". These features are configured as one or more rules, such as the rule content being "destination address equals 239.255.255.250 and destination port equals 1900 and protocol type is UDP". Subsequently, the module compares the real-time extracted traffic features with the preset packet features item by item: if the traffic features of a certain data packet match all the rules in the packet features, the module determines that the data packet is a declared packet and immediately triggers the subsequent process, that is, reads the current air interface resource utilization rate value provided by the wireless network card driver and compares it with the preset ratio threshold (such as 70%); if the match fails, the data packet is determined to be other types of packets and is not affected by the subsequent frequency limiting mechanism, and is forwarded according to the normal process.

[0042] In specific implementation, the message characteristics include the calibration destination address, calibration method attribute, calibration notification subtype field, and calibration device identifier of the existence declaration message. Step S22 may include steps S221 to S223: Step S221: Extract the traffic characteristics of the data traffic, wherein the traffic characteristics include destination address, method attribute, notification subtype field and device identifier; It should be noted that the destination address is the target network location information carried in the network layer and transport layer headers of each packet parsed from the received data traffic. Specifically, it is a combination of the target IP address and port number, used to identify the network terminal or multicast group to which the packet is intended to be delivered. The destination address is a pre-set and stored standard value for defining the network layer target address that must be matched by the declared packet. Specifically, it is fixed to the multicast address and port number specified in the SSDP protocol specification, namely 239.255.255.250:1900, as one of the necessary conditions for identifying such packets.

[0043] Method attributes are the command or operation type defined in the application layer protocol for each message parsed from the received data traffic. Specifically, they are represented by the METHOD field value in the start line of the SSDP message, such as "NOTIFY," which declares the protocol action performed by the message. Identifying method attributes are pre-defined and stored standard values ​​for application layer protocol methods that must match the message's liveness declaration. Specifically, they are fixed to the SSDP protocol's method string "NOTIFY," used to declare liveness, and serve as one of the necessary conditions for identifying such messages.

[0044] The Notification Sub-Type (NTS) field refers to the specific status declaration field, or NTS, included in the SSDP header of each packet parsed from the received data traffic. Its content, such as "ssdp:alive," conveys the service liveness status information corresponding to the packet. The Identifier Notification Sub-Type field is a pre-defined and stored standard value used to define the SSDP header status field that must match the presence declaration packet. Specifically, it is fixed to the NTS field value "ssdp:alive," indicating device liveness, and serves as one of the necessary conditions for identifying this type of packet.

[0045] Device identifier refers to the string information in each packet parsed from received data traffic that uniquely identifies the sending source device. Specifically, it manifests as a universally unique identifier contained in fields such as SERVER, USER-AGENT, or USN in the SSDP packet header, used to distinguish different Plug and Play device instances. The identifiable device identifier, on the other hand, is a pre-defined and stored standard format for defining the device identifier that must be carried in existence declaration packets. Specifically, it can be, but is not limited to, a string template conforming to the UUID format, used to match the field content identifying the sending device in the packet, serving as the basis for identifying a specific Plug and Play device.

[0046] Step S222: Compare the destination address with the calibrated destination address, the method attribute with the calibrated method attribute, the notification subtype field with the calibrated notification subtype field, and the device identifier with the calibrated device identifier; Step S223: If the destination address matches the calibrated destination address, the method attribute matches the calibrated method attribute, the notification subtype field matches the calibrated notification subtype field, and the device identifier matches the calibrated device identifier, then determine that the message feature matches the traffic feature.

[0047] Understandably, if strict matching of all features is required, messages with reasonable variations in protocol implementation may be missed; if the comparison rules are unclear, other irrelevant messages may be misclassified as target messages due to insufficient identification criteria. Both of these situations would compromise the accuracy and robustness of the frequency limiting mechanism.

[0048] Therefore, this implementation plan clearly defines the specific feature dimensions for comparison, namely the four key protocol fields of destination address, method attribute, notification subtype field and device identifier, and compares them with the preset calibration values ​​respectively. Meanwhile, the judgment logic is set to consider a successful overall match as a consistent feature comparison. This constructs a multi-dimensional, high-coverage, and fault-tolerant accurate identification rule, which can effectively avoid two problems that may be caused by unclear or unreasonable identification rules: First, it avoids the problem of missed detection caused by demanding that all details of the message perfectly conform to a rigid template, ensuring that the message can still be correctly identified even if there are legitimate changes to non-core features such as device identifiers. Second, by specifying multiple core protocol features as the judgment criteria, it significantly improves the distinguishability from other irrelevant messages (such as different protocol messages sent to the same port), reduces the risk of false alarms, and prevents normal business traffic from being erroneously blocked. This greatly improves the accuracy and recall rate of presence declaration message identification, ensuring the accuracy of subsequent frequency limiting actions. It effectively curbs the target message traffic and fully guarantees the normal compatibility of network protocols and the seamless passage of business messages.

[0049] For example, in the router's feature identification module, a pre-set set of identification features is configured, where the identification destination address is fixed as "239.255.255.250:1900", the identification method attribute is fixed as "NOTIFY", the identification notification subtype field is fixed as "ssdp:alive", and the identification device identifier is configured as a wildcard pattern, such as "uuid:30845dd6-665e-4c0f-6156-57fd34a9d273". When a data packet is received, the module extracts its traffic features: the destination address is "239.255.255.250:1900", the method attribute is "NOTIFY", the notification subtype field is "ssdp:alive", and the device identifier is "uuid:30845dd6-665e-4c0f-6156-57fd34a9d273". A comparison is then performed: the destination address, method attribute, and notification subtype fields all match the calibration values ​​exactly (indicating that the current data packet is identified as an existence declaration packet), and the device identifier matches the calibration device identifier (indicating that the sending device of the current data packet is the specified plug-and-play device that requires rate limiting). The system then determines that the packet is an existence declaration packet and triggers subsequent processing. This implementation emphasizes strict matching of core protocol fields, while also identifying different plug-and-play devices and executing the rate limiting mechanism for the corresponding plug-and-play device.

[0050] In one feasible implementation, the step of discarding a portion of the existence declaration messages in each of the existence declaration messages in step S30 may include steps S31-S32: Step S31: Extract the cache control field of each of the existence declaration messages, and determine the rated transmission frequency according to the maximum effective duration corresponding to each of the cache control fields; It should be noted that the cache control field is a specific field in the application layer header of the presence declaration message in the SSDP protocol format, usually named "CACHE-CONTROL". It carries instruction parameters for controlling the duration for which the receiving device caches the information declared in the message. The maximum valid duration is a specific numerical parameter parsed from the cache control field, typically consisting of a "max-age" indicator followed by the number of seconds (e.g., "max-age=66"). This value defines the maximum length of time the sending device recommends that the receiver consider the service announcement message valid.

[0051] The rated transmission frequency is the upper limit of the allowed message forwarding rate calculated based on the maximum effective duration. This frequency is a control parameter used to limit the number of presence declaration messages that can be passed and forwarded to IoT devices within a specific time period, thereby ensuring that the message flow is throttled without exceeding the update frequency allowed by the protocol semantics.

[0052] Step S32: Discard a portion of the existence declaration messages in each of the existence declaration messages, so that the remaining existence declaration messages in each of the existence declaration messages are forwarded to the IoT device at the rated transmission frequency.

[0053] Understandably, while the discarding mechanism reduces the number of packets, using a fixed or arbitrary discarding frequency could disrupt the protocol-based service discovery logic between plug-and-play devices and other legitimate control points in the network. Specifically, in the SSDP protocol, devices declare their services through presence declaration messages, and the caching control field carried in the message explicitly defines the validity period of this declaration information. If the forwarding frequency of this message is too low, causing the receiver to fail to receive an updated presence declaration message before the information expires, it will cause abnormal service interruption, affecting the normal discovery and use of core functions such as screen mirroring of plug-and-play devices.

[0054] Therefore, before discarding some existence declaration messages, this implementation method further extracts the cache control field of each message and parses its corresponding maximum effective duration. Then, based on these durations, it dynamically calculates the rated transmission frequency allowed by the protocol. Finally, it performs the discard operation based on this rated frequency, ensuring that the message rate ultimately forwarded to the IoT device will not be lower than the minimum update frequency necessary to maintain the continuity of protocol service discovery. This prevents the IoT device from being unable to update the service declaration information it perceives within its maximum effective duration due to excessive restrictions on message forwarding, which could lead to protocol compatibility issues such as services being incorrectly judged as offline and the screen projection discovery function failing. Thus, the frequency limiting strategy is linked to the SSDP protocol's own cache control mechanism. While achieving the core goal of reducing redundant air interface traffic, it ensures the normal semantics and functional integrity of the SSDP protocol, so that air interface optimization measures do not sacrifice the availability of basic network services. This achieves coordinated optimization of network transmission efficiency and service function reliability.

[0055] For example, several algorithms can be used to discard some messages with presence claims: First, a counter algorithm, which sets a fixed control period (e.g., calculated based on the minimum maximum effective duration) and resets the message counter at the beginning of the period. The counter increments by one for each forwarded message. When the counter value reaches a preset upper limit (e.g., 40 messages) within the period, all subsequent messages are discarded until the end of the current period. This method forcibly limits the forwarding rate to the average rated frequency within the period. Second, a token bucket algorithm, which maintains a virtual token bucket with limited capacity and adds tokens to the bucket at a constant rate (i.e., the rated sending frequency). Each received message requires obtaining and consuming one token from the bucket before it can be forwarded. If there are no available tokens in the bucket, the message is discarded. This algorithm ensures that the long-term average rate does not exceed the limit while allowing messages to pass through. Forwarding in bursts (not exceeding the bucket capacity) offers greater flexibility; thirdly, the sliding window algorithm maintains a fixed-length window (e.g., 10 seconds) that slides over time and continuously counts the number of packets forwarded within that window. When a new packet arrives, it checks if its number within the sliding window exceeds a predetermined threshold. If not, it forwards the packet and updates the window statistics; otherwise, it discards it. This algorithm can smooth instantaneous traffic more precisely and avoid bursts at periodic boundaries; fourthly, the leaky bucket algorithm sets up a queue with a fixed capacity as the "leaky bucket." All arriving packets first enter this queue, and the "leaky bucket" retrieves and forwards packets from the head of the queue at a constant predetermined rate (e.g., 2 packets per second). If the queue is full when a new packet arrives, it is discarded directly. This algorithm can shape any irregular input traffic into a constant-rate output stream. These algorithms all achieve the same core goal through different mechanisms: based on the calculated predetermined transmission frequency, by actively discarding some packets, they ensure that the packet stream ultimately forwarded to IoT devices is limited to a preset rate range. It is understood that this implementation does not impose specific limitations on the specific message discarding algorithm used.

[0056] In specific implementation, the step of determining the rated transmission frequency based on the maximum effective duration corresponding to each of the buffer control fields in step S31 may include steps S311 to S313: Step S311: For any cache control field, determine the maximum valid duration corresponding to the maximum valid time subfield in the cache control field; It should be noted that the maximum valid time subfield is a specific parameter item that exists within the cache control field and is used to carry a specific duration value. Its name is usually "max-age", followed by a value connected by an equal sign. For example, "50" in "max-age=50" is the value of this subfield. This value, in seconds, clearly defines the validity period of the service information.

[0057] Step S312: After traversing each of the cache control fields, determine the smallest maximum valid duration among the maximum valid durations. It should be noted that the minimum maximum effective duration refers to the minimum value determined by comparing the maximum effective duration values ​​corresponding to all cache control fields in multiple existence declaration messages from the same plug-and-play device. This duration represents the shortest update cycle required for the various service information declared by the device and is a key benchmark for calculating the rated transmission frequency.

[0058] Step S313: Determine the control period based on the ratio of the minimum maximum effective duration to the preset coefficient, and determine the rated transmission frequency based on the control period and the preset message control quantity.

[0059] It should be noted that the control period is a specific time interval obtained by dividing the minimum maximum effective duration determined above by a preset coefficient. This period, as a dynamically calculated time window, is the basic time unit for subsequent message quantity control. Its length is directly related to the fastest service update frequency allowed by the protocol, ensuring the synchronization of the restriction policy and the protocol semantics.

[0060] Understandably, since the same plug-and-play device may declare multiple services simultaneously, the maximum validity duration in its different existence declaration messages may vary. Simply calculating frequency limit parameters based on the duration of a single message or any arbitrary duration may result in a mismatch between the set control period or frequency and the fastest update service required by the device. Specifically, if the control period is at a moderate level (corresponding to calculation based on a larger maximum validity duration), the declaration information for services requiring more frequent updates may not be updated in time before it expires, causing service discovery anomalies; conversely, if the control period is too short (corresponding to calculation based on a smaller maximum validity duration), the limitation may be insufficient and unable to adequately alleviate air interface congestion.

[0061] Therefore, this implementation process explicitly parses the maximum valid time subfield from the cache control field of each packet to obtain the maximum valid duration of each packet. Then, through traversal comparison, it determines the minimum maximum valid duration among all currently valid packets. This duration represents the most stringent update cycle required for all active services of the device. Finally, the control cycle is dynamically determined based on the ratio of this minimum maximum valid duration to a preset coefficient. This cycle, combined with a preset number of packets, sets the final rated transmission frequency. By introducing a dynamic parameter calculation mechanism based on the minimum maximum valid duration, the final determined control cycle and rated transmission frequency can strictly adapt to the actual, most stringent service update requirements of the plug-and-play device. This minimizes the number of packet forwards to optimize air interface resources while fundamentally ensuring the discoverability and protocol compatibility of all services provided by the device, achieving a fine balance between network resource optimization and service functionality completeness.

[0062] For example, the system continuously receives all SSDP NOTIFY messages sent by the smart TV and parses the "CACHE-CONTROL" field in the application layer header of each message one by one. It extracts the value corresponding to the maximum valid time subfield "max-age", such as "max-age=66", "max-age=50", etc. These values ​​represent the maximum valid duration for each message. Simultaneously, the system maintains a dynamic list for the device, recording and updating the maximum valid duration of all active messages. By iterating and comparing, the system determines that the minimum maximum valid duration in the current list is 66 seconds. Then, based on a pre-configured coefficient (e.g., 3), the control period is calculated as the minimum maximum valid duration divided by this coefficient, i.e., 66 / 3 = 22 seconds. At the same time, the system calls the preset message control quantity, such as 40, to determine that the rated transmission frequency is a maximum of 40 existence declaration messages allowed to be forwarded every 22 seconds. Finally, based on this frequency, monitoring is performed using a counter within each 22-second cycle: the counter is reset to zero at the beginning of the cycle; each time a smart TV presence declaration message is received, if the current count value is less than 40, the message is forwarded and the counter is incremented; if the count value has reached 40, subsequent messages are discarded until the end of the current cycle and the counter is reset, thus achieving precise frequency limiting while strictly adhering to protocol update requirements.

[0063] Before step S313, step S301 may also be included: Step S301: Determine a preset coefficient based on the air interface resource occupancy rate, wherein the air interface resource occupancy rate is positively correlated with the preset coefficient.

[0064] Understandably, the preset coefficient used to calculate the control period is a fixed value, but the air interface resource occupancy of a wireless network changes dynamically. When the air interface is highly congested, a more aggressive (i.e., shorter) control period may be needed to more forcefully restrict packet forwarding, thereby quickly alleviating congestion; conversely, when the air interface is relatively idle, overly aggressive restrictions may lead to unnecessary delays in service discovery updates, impacting user experience. Using a fixed preset coefficient cannot adapt to such dynamically changing network conditions, resulting in a restriction strategy that is either insufficient during congestion or excessive during idle periods.

[0065] This solution monitors air interface resource occupancy in real time before calculating the control cycle based on the minimum maximum effective duration. It dynamically determines the preset coefficient based on this occupancy rate, ensuring a positive correlation between the two: the higher the air interface resource occupancy rate, the larger the preset coefficient. For example, a mapping relationship can be pre-configured: when the air interface resource occupancy rate is below 75%, the preset coefficient is 2; when the occupancy rate is between 75% and 85%, the preset coefficient is 3; and when the occupancy rate is above 85%, the preset coefficient is 5. Subsequently, this dynamically determined coefficient is used to divide the minimum maximum effective duration, thus obtaining an adaptive control cycle. This effectively avoids the key problems caused by using a fixed preset coefficient that cannot respond to real-time network status changes: firstly, it avoids situations where the air interface is severely congested, resulting in an excessively long calculated control cycle and insufficient restriction due to a too small coefficient, thus failing to effectively reduce the air interface load in a timely manner; secondly, it avoids situations where the air interface is idle, resulting in an excessively short calculated control cycle and overly strict restrictions due to a too large coefficient, thus unnecessarily increasing service discovery latency and causing excessive interference to normal services.

[0066] In this implementation, the core parameter of the frequency limiting strategy, namely the control period, is linked to the real-time network load, namely the air interface resource utilization rate. This allows the limiting intensity to be flexibly adjusted according to the degree of network congestion. Thus, when air interface resources are scarce, redundant traffic can be suppressed more decisively to quickly restore network health, while when air interface resources are abundant, the limiting can be relaxed to prioritize the quality and real-time performance of the service discovery function. This realizes the dynamic and intelligent optimization strategy for network resources, and improves the environmental adaptability and overall efficiency of the entire system.

[0067] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The message transmission method may further include steps S01 to S03: Step S01: Monitor the channel interference level and terminal association failure rate of the communication link; It should be noted that channel interference level refers to a quantitative assessment indicator of the strength of signal interference caused by other wireless devices on the same or adjacent frequencies, non-Wi-Fi interference sources, etc. in the electromagnetic environment in which the wireless communication link is located. It can usually be reflected by measuring parameters such as signal-to-noise ratio, bit error rate, or noise energy in a specific frequency band.

[0068] Terminal association failure rate is the percentage of connection requests that a wireless access point (such as a router) fails to establish an association or authentication for within a specific time period, out of the total number of requests. This metric directly reflects the stability and availability of the wireless network access layer.

[0069] Step S02: Evaluate the air interface status of the communication link based on the air interface resource occupancy rate, the channel interference level, and the terminal association failure rate; It should be noted that the air interface status is a comprehensive assessment conclusion. This data is based on the fusion analysis of monitoring data from multiple dimensions such as air interface resource utilization, channel interference level, and terminal association failure rate. It is used to characterize the overall operational health status and congestion level of the wireless communication link and serves as the basis for decision-making on whether to trigger traffic restriction policies.

[0070] Step S03: If the air interface status meets the preset congestion status, execute the step of discarding some of the existence declaration messages in each existence declaration message and subsequent steps.

[0071] Understandably, wireless network performance degradation and channel congestion can be caused by a variety of complex factors, such as high co-channel interference and frequent terminal access failures. Air interface resource occupancy only reflects the time-based busyness of the channel and cannot fully distinguish the root cause of congestion. Relying solely on this single indicator may lead to erroneous triggering of restrictions (false positives) when high air interface occupancy is caused by non-SSDP packet overload, or failure to trigger restrictions in a timely manner (missed positives) when network quality is severely degraded due to interference or access failures and the air interface occupancy has not reached the threshold. This results in insufficient effectiveness and accuracy of the restriction mechanism.

[0072] Therefore, the technical solution proposed in this embodiment monitors the air interface resource occupancy rate while simultaneously monitoring the channel interference level (reflecting physical layer quality) and the terminal association failure rate (reflecting access layer stability). It then comprehensively evaluates the air interface status of the communication link based on these three dimensions. Subsequent packet dropping and forwarding operations are only executed when the air interface status meets the preset congestion criteria. This constructs a multi-dimensional, comprehensive air interface health assessment and triggering decision mechanism. Firstly, it avoids misjudging normal high occupancy caused by other high-priority services or brief bursts of traffic as a congestion state requiring restriction, thus preventing unnecessary restrictions on SSDP packets and protecting normal service discovery functions. Secondly, it avoids situations where the network is actually unavailable due to severe interference or abnormal terminal access, but the air interface occupancy rate may not be high, yet the restriction mechanism fails to activate. This ensures that the system can intervene promptly to alleviate secondary problems caused by SSDP packets in a wider range of network anomalies.

[0073] This embodiment significantly improves the intelligence, accuracy, and robustness of the limiting mechanism's trigger conditions by introducing multi-dimensional network state awareness and comprehensive evaluation. This enables it to more accurately identify network congestion scenarios that are truly caused or exacerbated by SSDP packets and provide protection in more comprehensive network anomaly situations. As a result, while optimizing air interface resource utilization, it minimizes unnecessary interference with normal network services and enhances the adaptability and reliability of the entire solution.

[0074] For example, the router's monitoring module runs three monitoring threads in parallel: the first thread reads the current air interface resource occupancy rate of the 2G channel from the wireless network card driver; the second thread scans the radio frequency signal and calculates a comprehensive evaluation value of the non-target Wi-Fi signal strength and background noise as the channel interference level; the third thread counts the total number of association requests received and the number of failures received by the access point logic within one minute, and calculates the real-time terminal association failure rate. This monitoring data is sent to a fusion decision engine, which has preset comprehensive criteria for congestion status, such as "if the air interface resource occupancy rate > 70% and (channel interference level > high threshold or terminal association failure rate > 15%)". Assume the current monitoring values ​​are: air interface resource occupancy rate 75%, channel interference level is "medium" (not exceeding the threshold), and terminal association failure rate is 20%. The decision engine judges according to the criteria. Since both the air interface resource occupancy rate (75% > 70%) and the terminal association failure rate (20% > 15%) meet the preset criteria, the current air interface status is determined to be congested. The determination result will serve as a global enable signal, triggering the subsequent frequency limiting process: the message identification module will start working, identify SSDP NOTIFY messages from plug-and-play devices, and the frequency limiting module will selectively discard and forward them according to the dynamically calculated rated transmission frequency; conversely, if the assessment does not meet the congestion condition, even if the air interface resource occupancy rate is high, the restriction on the presence of declared messages will not be initiated, thus ensuring the accuracy and comprehensiveness of the triggering conditions.

[0075] In another example, the air interface status of the communication link can be assessed by assigning different weights to air interface resource occupancy, channel interference level, and terminal association failure rate, and then calculating a comprehensive network user index to determine whether the current state is congested. This embodiment does not specifically limit the method for assessing the air interface status of the communication link.

[0076] For example, to help understand the implementation flow of the message transmission method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart of a message transmission method is provided, specifically: When a router receives a packet, it first determines whether the "SSDP restriction mechanism" is enabled, which is triggered based on the air interface resource utilization monitoring results. If the mechanism is not enabled, the packet is forwarded directly. If the mechanism is enabled, two layers of fine filtering are performed sequentially: First, it checks whether the data traffic is a presence declaration packet. If so, it further compares whether the traffic characteristics match the characteristics of a predefined packet, including comparisons using multiple dimensions such as destination address, method attribute, notification subtype field, and device identifier. For packets that match the characteristics, it finally checks whether their transmission frequency exceeds the rated frequency, which is the rated transmission frequency calculated based on the cache control field and the minimum maximum effective duration. Only packets whose frequency does not exceed the limit are forwarded; those that do are discarded, thus fully implementing the core operation of selective discarding and forwarding.

[0077] Further, please refer to Figure 4 This demonstrates the entire process of dynamically enabling and disabling the "SSDP limiting mechanism" and calculating key parameters: The process is periodically triggered by a timer. First, it monitors the air interface resource occupancy rate and determines whether it exceeds a preset threshold. Based on the comparison result, it decides to enable or disable the limiting mechanism. When the mechanism is enabled, it immediately identifies declared packets based on four specific packet characteristics (such as destination address, method attribute, specific header fields, and device identifier), i.e., extracting traffic characteristics and comparing them with packet characteristics. Then, it records the minimum maximum valid duration in the buffer control field. Finally, based on the minimum maximum valid duration, it calculates the allowed rated transmission frequency for the packet using algorithms such as counters / token buckets.

[0078] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the message transmission method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0079] This application also provides a message transmission device; please refer to... Figure 5 The message transmission device includes: Monitoring module 10 is used to monitor the air interface resource utilization rate of the communication link between plug-and-play devices and IoT devices; The receiving module 20 is used to receive multiple presence declaration messages sent by the plug-and-play device; The forwarding module 30 is used to discard a portion of the existence declaration messages in each existence declaration message and forward the remaining existence declaration messages to the Internet of Things device when the air interface resource occupancy rate is higher than a preset ratio threshold.

[0080] Optionally, the receiving module 20 is further configured to: Receive data traffic transmitted by the plug-and-play device; The message characteristics of the existing declaration message are compared with the traffic characteristics of the data traffic; If the message characteristics match the traffic characteristics, the data traffic is determined to be the presence declaration message.

[0081] Optionally, the message characteristics include the calibration destination address of the existence declaration message, calibration method attribute, calibration notification subtype field, and calibration device identifier. The receiving module 20 is further configured to: Extract the traffic characteristics of the data traffic, wherein the traffic characteristics include destination address, method attribute, notification subtype field and device identifier; The destination address is compared with the calibrated destination address, the method attribute is compared with the calibrated method attribute, the notification subtype field is compared with the calibrated notification subtype field, and the device identifier is compared with the calibrated device identifier. If the destination address matches the calibration destination address, the method attribute matches the calibration method attribute, the notification subtype field matches the calibration notification subtype field, and the device identifier matches the calibration device identifier, then the message feature matches the traffic feature.

[0082] Optionally, the forwarding module 30 is further configured to: Extract the cache control field of each of the stated existence declaration messages, and determine the rated transmission frequency based on the maximum effective duration corresponding to each of the stated cache control fields; Some of the existence declaration messages in each of the existence declaration messages are discarded, so that the remaining existence declaration messages in each of the existence declaration messages are forwarded to the IoT device at the rated transmission frequency.

[0083] Optionally, the forwarding module 30 is further configured to: The step of determining the rated transmission frequency based on the maximum effective duration corresponding to each of the buffer control fields includes: For any cache control field, determine the maximum valid duration corresponding to the maximum valid time subfield in the cache control field; After traversing each of the cache control fields, determine the smallest maximum valid duration among the maximum valid durations. The control period is determined based on the ratio of the minimum maximum effective duration to a preset coefficient, and the rated transmission frequency is determined based on the control period and the preset message control quantity.

[0084] Optionally, the forwarding module 30 is further configured to: A preset coefficient is determined based on the air interface resource occupancy rate, wherein the air interface resource occupancy rate is positively correlated with the preset coefficient.

[0085] Optionally, the monitoring module 10 is further configured to: Monitor the channel interference level and terminal association failure rate of the communication link; The air interface status of the communication link is assessed based on the air interface resource occupancy rate, the channel interference level, and the terminal association failure rate. If the air interface status meets the preset congestion status, the step of discarding some of the existence declaration messages in each existence declaration message and subsequent steps are executed.

[0086] The message transmission apparatus provided in this application, employing the message transmission method in the above embodiments, can solve the technical problem of channel congestion in router wireless networks joined by IoT devices and UPnP devices. Compared with the prior art, the beneficial effects of the message transmission apparatus provided in this application are the same as those of the message transmission method provided in the above embodiments, and other technical features in the message transmission apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0087] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the message transmission method in Embodiment 1 above.

[0088] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0089] like Figure 6As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0090] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0091] The electronic device provided in this application, employing the message transmission method described in the above embodiments, can solve the technical problem of channel congestion in router wireless networks joined by IoT devices and UPnP devices. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the message transmission method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0092] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0093] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0094] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the message transmission method in the above embodiments.

[0095] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0096] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0097] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an electronic device, cause the electronic device to: monitor the air interface resource occupancy rate of the communication link between the plug-and-play device and the IoT device; receive multiple presence declaration messages sent by the plug-and-play device; and, if the air interface resource occupancy rate is higher than a preset ratio threshold, discard some of the presence declaration messages and forward the remaining presence declaration messages to the IoT device.

[0098] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0100] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0101] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described message transmission method. This addresses the technical problem of channel congestion in router wireless networks joined by IoT devices and UPnP devices. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the message transmission method provided in the above embodiments, and will not be elaborated upon here.

[0102] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method of transmitting a packet, characterized by, The message transmission method comprises: monitoring an air interface resource occupation rate of a communication link between a plug and play device and an Internet of Things device; receiving a plurality of presence declaration messages sent by the plug and play device; in a case where the air interface resource occupation rate is higher than a preset proportion threshold, discarding part of the presence declaration messages, and forwarding the presence declaration messages that are not discarded to the Internet of Things device.

2. The packet transmission method of claim 1, wherein, The step of receiving a plurality of presence declaration messages sent by the plug and play device comprises: receiving data traffic transmitted by the plug and play device; comparing a message feature of the presence declaration message with a traffic feature of the data traffic; in a case where the message feature and the traffic feature are consistent, determining that the data traffic is the presence declaration message.

3. The packet transmission method of claim 2, wherein, The message feature comprises a designated destination address, a designated method attribute, a designated notification sub-type field and a designated device identifier of the presence declaration message, and the step of comparing the message feature of the presence declaration message with the traffic feature of the data traffic comprises: extracting a traffic feature of the data traffic, wherein the traffic feature comprises a destination address, a method attribute, a notification sub-type field and a device identifier; comparing the destination address with the designated destination address, the method attribute with the designated method attribute, the notification sub-type field with the designated notification sub-type field, and the device identifier with the designated device identifier; in a case where the destination address, the method attribute, the notification sub-type field and the device identifier are consistent, determining that the message feature and the traffic feature are consistent.

4. The packet transmission method of claim 1, wherein, The step of discarding part of the presence declaration messages comprises: extracting a cache control field of each of the presence declaration messages, and determining a rated sending frequency according to a maximum valid time length corresponding to each of the cache control fields; discarding part of the presence declaration messages, so that the presence declaration messages that are not discarded are forwarded to the Internet of Things device at the rated sending frequency.

5. The message transmission method of claim 4, wherein, The step of determining the rated sending frequency according to the maximum valid time length corresponding to each of the cache control fields comprises: for any one of the cache control fields, determining a maximum valid time length corresponding to a maximum valid time subfield in the cache control field; after traversing each of the cache control fields, determining a minimum maximum valid time length from among the maximum valid time lengths; determining a control period according to a ratio of the minimum maximum valid time length to a preset coefficient, and determining the rated sending frequency according to the control period and a preset message control quantity.

6. The packet transmission method of claim 5, wherein, Before the step of determining the control period according to the ratio of the minimum maximum valid time length to the preset coefficient, the method further comprises: determining the preset coefficient according to the air interface resource occupation rate, wherein the air interface resource occupation rate and the preset coefficient are positively correlated.

7. The packet transmission method of claim 1, wherein, The message transmission method further comprises: monitoring a channel interference level and a terminal association failure rate of the communication link; evaluating an air interface status of the communication link according to the air interface resource occupation rate, the channel interference level and the terminal association failure rate; in a case where the air interface status meets a preset congestion state, performing the step of discarding part of the presence declaration packets in each of the presence declaration packets and subsequent steps.

8. A packet transmission apparatus characterized by comprising: The packet transmission device comprises: a monitoring module configured to monitor an air interface resource occupation rate of a communication link between a plug-and-play device and an Internet of Things device; a receiving module configured to receive a plurality of presence declaration packets sent by the plug-and-play device; a forwarding module configured to discard part of the presence declaration packets in each of the presence declaration packets in a case where the air interface resource occupation rate is higher than a preset proportion threshold, and forward part of the presence declaration packets in each of the presence declaration packets that are not discarded to the Internet of Things device.

9. An electronic device, comprising: The device comprises a memory, a processor and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the packet transmission method according to any one of claims 1 to 7.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the packet transmission method according to any one of claims 1 to 7.

Images