Service traffic suppression method, device, equipment, medium and computer program product

Abstract

The invention provides a service traffic suppression method, device and equipment, a medium and a computer program product, and relates to the technical field of intelligent networks. The method comprises the steps that operator identification information of user equipment is acquired, and the operator identification information comprises user identity authentication information and wireless transmission performance data; when it is determined that the operator identification information satisfies a preset condition, whether the user equipment is an Internet of Things card is determined based on a plurality of pre-constructed trusted anchor point pools, and each trusted anchor point pool comprises a group of known network entity identifiers belonging to Internet of Things services; if the user equipment is the Internet of Things card, judging whether the user equipment executes the Internet of Things service or not according to the service data information of the user equipment; and if the user equipment does not execute the Internet of Things service, performing traffic suppression on non-Internet of Things services executed by the user equipment. According to the invention, network resource balance can be realized, and service experience of common users is guaranteed.

Description

Technical Field

[0001] The present disclosure relates to the field of intelligent network technology, and in particular to a method, apparatus, device, medium, and computer program product for suppressing service traffic. Background Art

[0002] The co-build and share model generally refers to a business model in which two or more physical operators collaborate to build and share infrastructure or other resources. As the co-build and share model advances, base stations and core networks across different operators share user traffic in predetermined proportions. To meet the massive connectivity demands, operators are issuing a large number of low-cost, high-connectivity, and low-power IoT cards (e.g., IoT SIM cards and embedded SIM cards). These IoT cards were originally intended for typical large-scale machine-type communication (mMTC) scenarios, such as smart metering, vehicle networks, and wearable devices.

[0003] However, due to their low cost and simple activation procedures, these IoT cards were widely distributed by external operators to ordinary users, replacing traditional mobile phone SIM cards used for regular data internet access. In densely populated areas like universities, industrial parks, and convention centers, the daily average uplink and downlink traffic (DOUs) generated by these unconventional "human IoT cards" surged, significantly crowding out bearer resources on the co-built and shared network that should have been reserved for regular data services. This resulted in a serious imbalance in the resource allocation of the co-built and shared network, deviating from the original resource allocation agreement.

[0004] Among the related technologies, some solutions only implement traffic control on their own IoT cards, which in turn allows a large number of low-cost IoT cards from external operators to occupy more network resources, fails to improve the resource imbalance of the shared network, and even worse, exacerbates unfair competition; other solutions lack fine-grained service-level identification and can only globally shut down stations or limit traffic through the Public Land Mobile Network (PLMN), resulting in a decline in user experience in normal high-traffic services (for example, live streaming, cloud gaming, and 4K video), which is prone to complaints.

[0005] Therefore, relevant technologies are often unable to accurately determine non-conventional "human IoT cards" or business types across operators, and it is difficult to carry out fine-grained management of traffic characteristics of different businesses. It is obviously impossible to achieve network resource balance, let alone guarantee the service quality of IoT businesses and ordinary users of the party. It is difficult to maintain the sustainable allocation of jointly built and shared resources according to the agreed proportion.

[0006] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute prior art known to ordinary technicians in the field. Summary of the Invention

[0007] The present disclosure provides a method, apparatus, device, medium and computer program product for suppressing service traffic, which at least to some extent overcome the problem in related technologies of being unable to improve resource imbalance in a shared network.

[0008] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by practice of the present disclosure.

[0009] According to one aspect of the present disclosure, a service traffic suppression method is provided, comprising: obtaining operator identification information of a user device, wherein the operator identification information includes user identity authentication information and wireless transmission performance data; upon determining that the operator identification information satisfies a preset condition, judging whether the user device is an Internet of Things card based on a plurality of pre-built trusted anchor point pools, wherein each trusted anchor point pool contains a group of network entity identifiers known to belong to Internet of Things services; if the user device is an Internet of Things card, judging whether the user device executes an Internet of Things service based on service data information of the user device; and if the user device does not execute an Internet of Things service, performing traffic suppression on non-Internet of Things services executed by the user device.

[0010] In some embodiments, obtaining the operator identification information of the user equipment includes: obtaining an access signaling message sent by the user equipment; determining a unique identifier corresponding to the user equipment based on the access signaling message, and parsing to obtain a corresponding public land mobile network PLMN identifier as user identity authentication information; and collecting wireless transmission performance data of the user equipment according to a preset period.

[0011] In some embodiments, after obtaining the operator identification information of the user equipment, the method further includes: matching the PLMN identifier corresponding to the user equipment with a pre-built PLMN whitelist; if the match is consistent, determining that the user equipment belongs to the local operator; if the match is inconsistent, determining that the user equipment belongs to an external operator.

[0012] In some embodiments, the wireless transmission performance data includes data throughput and the number of physical resource blocks; after obtaining the operator identification information of the user equipment, the method further includes: comparing the data throughput with a first preset threshold; comparing the number of physical resource blocks with a second preset threshold; if the data throughput is not less than the first preset threshold and the number of physical resource blocks is not less than the second preset threshold, it is determined that the user equipment performs a high-traffic service.

[0013] In some embodiments, the preset condition is that the user equipment belongs to an external operator and the user equipment performs a high-traffic service.

[0014] In some embodiments, based on multiple pre-built trusted anchor point pools, determining whether the user device is an Internet of Things card includes: collecting anchor point information hit by the current session of the user device; judging whether there is an anchor point that meets the preset independent judgment conditions based on the anchor point information; if so, determining that the user device is an Internet of Things card; if not, selecting different categories of anchor points from the anchor point information, matching them with the corresponding trusted anchor point pools respectively, and judging whether the user device is an Internet of Things card.

[0015] In some embodiments, different categories of anchor points are selected from the anchor point information, matched with corresponding trusted anchor point pools respectively, and whether the user device is an Internet of Things card is determined, including: selecting different categories of anchor points from the anchor point information, and obtaining corresponding network entity address information; matching the network entity address information of different categories of anchor points with corresponding trusted anchor point pools respectively to determine whether the user device is an Internet of Things card.

[0016] In some embodiments, based on the business data information of the user device, determining whether the user device performs the Internet of Things business includes: real-time aggregation of all network connections or session instances initiated by the user device; extracting at least one business feature from each network connection or session instance, and matching each business feature with a preset reference library to generate a corresponding single feature confidence; summarizing all single feature confidences to obtain an overall confidence; and determining whether the user device performs the Internet of Things business based on the overall confidence.

[0017] In some embodiments, based on the overall confidence, determining whether the user device executes the Internet of Things service includes: determining whether the overall confidence meets the preset service discrimination conditions; if so, outputting a service tag; matching the service tag with a pre-built service whitelist to determine whether the user device executes the Internet of Things service.

[0018] According to another aspect of the present disclosure, a service traffic suppression device is also provided, including: an operator identification information acquisition module, used to obtain the operator identification information of a user device, wherein the operator identification information includes user identity authentication information and wireless transmission performance data; an Internet of Things card judgment module, used to determine whether the user device is an Internet of Things card based on a plurality of pre-built trusted anchor point pools when it is determined that the operator identification information meets preset conditions, wherein each trusted anchor point pool contains a group of network entity identifiers known to belong to Internet of Things services; an Internet of Things service judgment module, used to determine whether the user device executes Internet of Things services based on the service data information of the user device if the user device is an Internet of Things card; and a service traffic suppression module, used to suppress the traffic of non-Internet of Things services executed by the user device if the user device does not execute Internet of Things services.

[0019] According to another aspect of the present disclosure, an electronic device is also provided, which includes: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute any one of the above-mentioned service traffic suppression methods by executing the executable instructions.

[0020] According to another aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the service traffic suppression method described in any one of the above is implemented.

[0021] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, which implements any of the above-mentioned service traffic suppression methods when executed by a processor.

[0022] The service traffic suppression method, apparatus, device, medium, and computer program product provided in the embodiments of the present disclosure first obtain the user device's identity authentication information and wireless transmission performance data. If both meet preset conditions, the method determines whether the user device is an IoT card based on a pre-established trusted anchor point pool. If so, the method then determines whether the user device is performing IoT services based on the user device's service data information. If not, traffic is suppressed for non-IoT services performed by the user device. The embodiments of the present disclosure can achieve network resource balancing and protect the service experience of ordinary users.

[0023] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification, are used to explain the principles of the present disclosure. Obviously, the drawings described below are only some embodiments of the present disclosure, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0025] Figure 1 A flow chart of a method for suppressing service traffic in an embodiment of the present disclosure is shown;

[0026] Figure 2 A schematic diagram of an anchor signaling path in an embodiment of the present disclosure is shown;

[0027] Figure 3 A method for identifying and suppressing low-cost, high-traffic IoT card services in an embodiment of the present disclosure is shown;

[0028] Figure 4A schematic diagram of a service flow suppression device according to an embodiment of the present disclosure is shown;

[0029] Figure 5 A structural block diagram of an electronic device in an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0030] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0031] In addition, the accompanying drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. Identical reference numerals in the figures denote identical or similar parts, and thus repetitive descriptions thereof will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0032] The specific implementation of the embodiment of the present disclosure is described in detail below with reference to the accompanying drawings.

[0033] Figure 1 A flow chart of a method for suppressing service traffic in an embodiment of the present disclosure is shown as follows: Figure 1 As shown, the method includes the following steps:

[0034] S102: Acquire operator identification information of the user equipment, where the operator identification information includes user identity authentication information and wireless transmission performance data.

[0035] In one embodiment of the present disclosure, the user identity authentication information may be an International Mobile Subscriber Identity (IMSI) or a 5G Globally Unique Temporary Identifier (5G-GUTI). The above identification code or identifier has a certain mapping relationship with the Public Land Mobile Network (PLMN) identifier, and the PLMN ID can be directly parsed through the above identification code or identifier to facilitate further authentication of the user equipment's home operator.

[0036] In one embodiment of the present disclosure, wireless transmission performance data is generally data continuously aggregated according to a fixed sampling window Δt, and may include the Packet Data Convergence Protocol (PDCP) layer cumulative throughput ΣTP_PDCP(Δt) and the actual number of occupied physical resource blocks ΣPRB(Δt).

[0037] It should be noted that the above sampling window can usually be set to 100ms-1s, but it can also be adjusted according to actual conditions, and the embodiments of the present disclosure do not make specific limitations on this.

[0038] In one example of the present disclosure, user identity authentication information and wireless transmission performance data can be matched against corresponding preset conditions. If the user identity authentication information meets the corresponding preset conditions, the user device can be determined to belong to an external operator. If the wireless transmission performance data meets the corresponding preset conditions, the user device can be determined to be performing high-traffic services. When both the user identity authentication information and the wireless transmission performance data meet the corresponding preset conditions, it can be determined whether the user device has an IoT card and whether it can perform IoT services.

[0039] S104: When it is determined that the operator identification information meets the preset conditions, determine whether the user device is an IoT card based on multiple pre-built trusted anchor point pools, where each trusted anchor point pool contains a set of network entity identifiers known to belong to IoT services.

[0040] In one embodiment of the present disclosure, the operator pre-builds and maintains multiple trusted anchor point pools and assigns "independently identifiable priorities" to each anchor point based on business practices. The operator can then determine whether the user device is an IoT card by matching the anchor point of the user device's current session with the anchor points in the corresponding trusted anchor point pool.

[0041] S106: If the user device is an Internet of Things card, determine whether the user device executes the Internet of Things service based on the service data information of the user device.

[0042] In one embodiment of the present disclosure, service data information may be obtained by aggregating network connections or session instances, and may specifically include, but is not limited to, Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) traditional streams, Quick UDP Internet Connection (QUIC) logical substreams, Stream Control Transmission Protocol (SCTP) or Datagram Congestion Control Protocol (DCCP) sessions, and Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) sessions. Service features are extracted from the above service data information, and further determined based on the service features to determine whether the user device is executing IoT services.

[0043] S108: If the user equipment does not execute an IoT service, traffic suppression is performed on non-IoT services executed by the user equipment.

[0044] In one embodiment of the present disclosure, traffic suppression is a management measure taken by operators or network control entities to ensure fair use of the network, compliance, and the achievement of business policy objectives. The core of this measure is to dynamically adjust the traffic rate or quality of service (QoS) for specific users or services, rather than completely blocking their services.

[0045] In one embodiment of the present disclosure, when a user device belongs to an external operator and is equipped with a high-traffic IoT card, if it is determined that the user device is performing a non-IoT service, traffic suppression is performed on the non-IoT service performed by the user device.

[0046] As can be seen from the above, the disclosed embodiment first obtains the user device's identity authentication information and wireless transmission performance data. If both meet preset conditions, the system then determines whether the user device is an IoT card based on a pre-established trusted anchor point pool. If so, it then determines whether the user device is performing IoT services based on the user device's service data information. If not, traffic suppression is applied to non-IoT services performed by the user device. This disclosed embodiment achieves network resource balancing and ensures a secure service experience for ordinary users.

[0047] In one embodiment of the present disclosure, the above S102 includes: obtaining an access signaling message sent by the user equipment; determining a unique identifier corresponding to the user equipment based on the access signaling message, and parsing to obtain a corresponding public land mobile network PLMN identifier as user identity authentication information; and collecting wireless transmission performance data of the user equipment according to a preset period.

[0048] In one embodiment of the present disclosure, a user equipment (UE) initiates a Radio Resource Control (RRC) connection establishment request to a gNB. After the RRC connection is successfully established, the UE can access the core network through the gNB. At this point, the gNB can obtain the IMSI or 5G-GUTI through access signaling and parse the corresponding PLMN ID. Specifically, the PLMN ID consists of the Mobile Country Code (MCC) and the Mobile Network Code (MNC).

[0049] In one embodiment of the present disclosure, the gNB continuously collects radio transmission performance data of the UE according to a fixed sampling window Δt throughout the entire period that the UE maintains an RRC connection. The radio transmission performance data may include the cumulative throughput of the Packet Data Convergence Protocol (PDCP) layer ΣTP_PDCP(Δt) and the number of physical resource blocks actually occupied within the same window ΣPRB(Δt).

[0050] It should be noted that the above sampling window can usually be set to 100ms-1s, but it can also be adjusted according to actual conditions, and the embodiments of the present disclosure do not make specific limitations on this.

[0051] It should be noted that the above-mentioned PLMN ID acquisition process and wireless transmission performance data collection process can be performed in any order or simultaneously, and the embodiments of the present disclosure do not specifically limit this.

[0052] In one embodiment of the present disclosure, after the above S102, the method further includes: matching the PLMN identifier corresponding to the user equipment with a pre-built PLMN whitelist; if the match is consistent, determining that the user equipment belongs to the local operator; if the match is inconsistent, determining that the user equipment belongs to an external operator.

[0053] In one embodiment of the present disclosure, the gNB performs a one-to-many fast match between the PLMN ID and a preconfigured list of authorized PLMNs for the local operator (i.e., a pre-built PLMN whitelist). If the match succeeds, the UE is marked as a "local network user," meaning the UE belongs to the local operator. If the match fails, the UE is marked as an "external operator user," meaning the UE belongs to an external operator, and the flag User_Type_Unicom = 1 is set in the UE context.

[0054] In one embodiment of the present disclosure, the wireless transmission performance data includes data throughput and the number of physical resource blocks; after the above S102, the method further includes: comparing the data throughput with a first preset threshold; comparing the number of physical resource blocks with a second preset threshold; if the data throughput is not less than the first preset threshold and the number of physical resource blocks is not less than the second preset threshold, determining that the user equipment performs a high-traffic service.

[0055] In one embodiment of the present disclosure, the system pre-configures adaptive threshold pairs 〈T_thr, P_thr〉 (i.e., the above-mentioned 〈first preset threshold, second preset threshold〉) for different scenarios, wherein the threshold pairs can be dynamically updated through a network data analysis function (NWDAF) prediction model.

[0056] The above scenarios can specifically include macro stations, indoor distribution systems and micro stations. Specifically, macro stations refer to base stations with a larger coverage area, which are usually used to provide wide-area coverage and are mainly used in areas with low population density, such as rural areas, suburbs and the outer parts of cities; indoor distribution systems are indoor distribution systems, which are specially designed to improve wireless signal coverage inside buildings, mainly to solve signal coverage problems inside large buildings such as large shopping malls, office buildings, hospitals, etc.; micro stations refer to base stations with a smaller coverage area, including microcells, picocells and femtocells. They have a small coverage area but can support more users to access at the same time, and are very suitable for high-density user areas, such as stadiums, airports, railway stations and other crowded places.

[0057] In one embodiment of the present disclosure, when and only when ΣTP_PDCP≥T_thr and ΣPRB≥P_thr are satisfied in any consecutive k windows, the wireless context of the UE is quickly set to HT_Flag=1 and regarded as a "high-traffic session", that is, the UE performs high-traffic services; if in the subsequent m windows (m can be equal to k), ΣTP_PDCP and / or ΣPRB are less than their corresponding thresholds, the flag is cleared, and at this time, HT_Flag=0, that is, the UE performs non-high-traffic services.

[0058] The scheduling module, located within the gNB, manages radio resources and determines how to allocate them to UEs. The scheduling module performs the aforementioned UE radio context setup process. At this point, the scheduling module is primarily responsible for collecting UE data transmission information in real time. Based on a set time window size (Δt) and number (k), it analyzes whether these statistics exceed predefined thresholds (T_thr, P_thr), and performs status updates, adjusting the HT_Flag value.

[0059] It should be noted that the above-mentioned process of determining whether the user equipment belongs to an operator and the process of determining whether the user equipment performs high-traffic services can be performed in any order or simultaneously, and the embodiments of the present disclosure do not make specific limitations on this.

[0060] In one embodiment of the present disclosure, the preset condition is that the user equipment belongs to an external operator and performs a high-traffic service.

[0061] In one embodiment of the present disclosure, only when the user device belongs to an external operator and performs a high-traffic service can it be determined whether the user device has an Internet of Things card. If the user device does not meet any of the above conditions, the determination cannot be continued.

[0062] In one embodiment of the present disclosure, the above S104 includes: collecting anchor point information hit by the current session of the user device; judging whether there is an anchor point that meets the preset independent judgment conditions based on the anchor point information; if so, determining that the user device is an Internet of Things card; if not, selecting different categories of anchor points from the anchor point information, matching them with the corresponding trusted anchor point pools respectively, and judging whether the user device is an Internet of Things card.

[0063] In one embodiment of the present disclosure, different categories of anchor points are selected from the anchor point information, matched with the corresponding trusted anchor point pools respectively, and whether the user device is an Internet of Things card is determined, including: selecting different categories of anchor points from the anchor point information and obtaining corresponding network entity address information; matching the network entity address information of different categories of anchor points with the corresponding trusted anchor point pools respectively to determine whether the user device is an Internet of Things card.

[0064] In one embodiment of the present disclosure, the anchor point generally refers to a network entity identifier that can characterize the user session ownership or service attributes, covering multiple types such as the control plane (such as the access and mobility management function AMF address, the network slice identifier Slice-ID), the user plane (such as the user plane function UPF address, the edge user plane function Edge-UPF address) and the service plane (such as the private network domain name system DNS domain name, the message queue telemetry transmission agent MQTT Broker domain name).

[0065] In one embodiment of the present disclosure, multiple trusted anchor pools are defined and maintained in the configuration management system in advance on the operation side (i.e., the network operator) based on business requirements and network architecture. Anchor types may include, but are not limited to, control plane anchors, user plane anchors, and business plane anchors. Each trusted anchor pool contains a set of identifiers known to belong to IoT services, such as a dedicated UPF address pool, an IoT access and mobility management function IoT-AMF instance address pool, etc. The anchor pool can be hot-updated through the operations support system OSS / business support system BSS or software-defined network SDN controller to adapt to changes such as network expansion and new business launches.

[0066] At the same time, operators can also set "independently identifiable priorities" for certain anchor points. When an anchor point forms a unique correspondence or exclusive match with a record in the pool, it can be directly used as the basis for identifying the IoT card without having to enter the subsequent multi-anchor consistency process.

[0067] In one embodiment of the present disclosure, the system can first collect various anchor point information in the current session of the user device and immediately compare it with the trusted anchor point pool. Specifically, all collected anchor points are traversed. If at least one anchor point is found to meet the "independent judgment priority" and forms a unique correspondence or exclusive hit with its corresponding pool, IoT_Flag = 1 is immediately set to mark the user device as an IoT card. Subsequently, only necessary log retention and compliance verification are performed, and multi-anchor point fusion operations are no longer triggered.

[0068] For example, when a user device initiates a PDU session and the core network session management function (SMF) routes traffic to a dedicated UPF in the trusted pool, the system intercepts the UPF address during the fast matching phase and queries the trusted anchor pool. If the UPF address meets the "independent discrimination priority" requirement, upon finding an exclusive hit, the system immediately sets IoT_Flag to 1 to confirm that the user device is an IoT card, without entering the multi-anchor consistency or fusion evaluation process, thereby achieving low-latency, high-throughput identification.

[0069] If no independently verifiable anchor hit occurs during the quick matching phase, or if multiple anchors contradict each other (for example, the control plane anchor is IoT, but the user plane anchor is not IoT), it is necessary to comprehensively determine the user device type and enter the multi-anchor consistency determination phase. Specifically, based on the input multi-anchor information and the corresponding trusted anchor pool, the system will select at least two types of anchors, compare them with the corresponding trusted pool, and generate a consistency feature vector containing a matching mark to provide input for subsequent fusion evaluation. The matching mark is used to determine whether the anchor is in the respective trusted anchor pool.

[0070] It should be noted that the control plane anchor and the user plane anchor are usually preferred for anchor point selection, but can be adjusted according to actual conditions, and the embodiments of the present disclosure do not make specific limitations on this.

[0071] In one embodiment of the present disclosure, the trusted anchor point pool may include an Internet of Things Access Point Name / Data Network Name (IoT-APN / DNN) name pool, an Internet of Things Access and Mobility Management Function (IoT-AMF) address pool, and an Internet of Things User Plane Function (IoT-UPF) address pool. The IoT-APN / DNN name pool is used to list all access point names or data network names allowed for use in IoT private networks, the IoT-AMF address pool is used to store AMF instances or their virtual IP segments that only carry the IoT control plane, and the IoT-UPF address pool is used to store UPF devices and their address blocks that specifically forward IoT user plane traffic.

[0072] Specifically, Figure 2 A schematic diagram of an anchor signaling path in an embodiment of the present disclosure is shown, including: user equipment UE, 5G base station gNB, AMF, SMF, UPF and external network Internet.

[0073] Among them, the N1 interface is used for signaling interaction between UE and AMF, including registration, authentication, session management, etc.; the Ng interface is used for control plane communication between gNB and AMF, mainly for transmitting control information; the N3 interface is used for user plane communication between gNB and UPF, mainly for transmitting user data; the N2 interface is used for control plane communication between AMF and SMF, mainly for session management and policy control; the N4 interface is used for control plane communication between SMF and UPF, mainly for configuring and managing user plane tunnels; the N6 interface is used for communication between UPF and the Internet, and is responsible for forwarding user data packets to the external network.

[0074] The network channels where APN / DNN, AMF, and UPF are located are as follows: Figure 2 As shown, it includes two links, specifically:

[0075] The first link is used for network plane verification. When the UE is about to establish a new PDU session, it will include the target APN / DNN information in the non-access layer NAS signaling message and send it to the AMF. After receiving the APN / DNN parameters, the AMF immediately performs a two-level matching.

[0076] The first-level match involves the AMF querying the latest local IoT-APN / DNN name pool. If the request field matches the pool, the service request is deemed to be compliant with the IoT private network and Tag_CP_APN is set to 1. If the request field does not match the pool, the service request is deemed to be compliant with the IoT private network and Tag_CP_APN is set to 0.

[0077] Secondary matching includes: For requests with Tag_CP_APN=1, AMF continues to call the AMF-selection rule to select the target AMF instance in the IoT-AMF address pool. If the final routed AMF IP belongs to the IoT-AMF address pool, Tag_CP_AMF=1 is set; if the final routed AMF IP does not belong to the IoT-AMF address pool, Tag_CP_AMF=0 is set.

[0078] If Tag_CP=Tag_CP_APN∧Tag_CP_AMF=1, it means that the access to the Internet of Things is successful, otherwise it is 0.

[0079] The second link is used for user plane verification, matching the UPF IP address of the actual landing point of the PDU session with the IoT-UPF address pool. If the UPF IP address exists in the IoT-UPF address pool, set Tag_UPF to 1; if the UPF IP address does not exist in the IoT-UPF address pool, set Tag_UPF to 0.

[0080] Furthermore, the consistency of the network and user planes must be evaluated and weighted to calculate a comprehensive score (Score) to determine whether the UE uses an IoT card. Specifically, the calculation formula can be Score = w1 × Tag_CP + w2 × Tag_UPF, where w1 + w2 = 1.

[0081] The preset threshold range is T_thr. If Score ≥ T_thr, IoT_Flag = 1 is written in the UE context, indicating that it is an IoT card. If Score < T_thr, IoT_Flag = 0 is written in the UE context, indicating that it is not an IoT card. This disclosed embodiment ensures that a UE is only identified as an IoT card when it meets the consistency requirements of both the control plane and the user plane, improving the accuracy of identification and avoiding the misjudgment that may be caused by single-dimensional judgment.

[0082] It should be noted that the weights can be initialized to w1=0.7 and w2=0.3, where w1 represents the weight of the control plane (APN / DNN matching and AMF matching), and w2 represents the weight of the user plane (UPF matching). It can be adjusted according to actual conditions, and the embodiment of this disclosure does not make specific limitations on this.

[0083] It should be noted that the preset threshold range can be T_thr∈[0.6,0.8]. This range can be dynamically adjusted based on the actual operation of the network to achieve optimal recognition results. The preset threshold range can be updated synchronously with the measured equilibrium point and can be adjusted based on actual conditions. This is not specifically limited in the present embodiment.

[0084] In one embodiment of the present disclosure, when the consistency feature vector is insufficient for direct judgment, the consistency feature vector is input into a fusion evaluation model for comprehensive scoring or probability estimation. The score or probability output by the model is compared with a preset threshold, dynamic threshold, or confidence interval to determine whether the user device is an IoT card. The consistency feature vector includes the matching status and weight of each anchor point.

[0085] It should be noted that the fusion evaluation model is not limited to any specific form, and may include but is not limited to linear or piecewise weighted models, statistical learning models (such as logistic regression, naive Bayes, support vector machines, etc.), integrated learning frameworks (such as random forests, gradient boosting decision trees GBDT / extreme gradient boosting XGBoost, etc.), and deep learning models (including multi-layer perceptrons, convolutional or recursive networks, graph neural networks GNN, or sequence / graph encoding networks of transformer models based on self-attention mechanisms) or any combination thereof. The corresponding fusion evaluation model can be selected according to actual conditions, and the embodiments of the present disclosure do not specifically limit this.

[0086] In one embodiment of the present disclosure, model parameters may be trained offline or dynamically adjusted through reinforcement learning or other online learning mechanisms.

[0087] It should be noted that the embodiments of the present disclosure are not limited by the above-mentioned algorithms, parameters or threshold settings, and any technical solution that can complete the combined evaluation based on the consistent feature vector and output the discrimination result is acceptable.

[0088] In one embodiment of the present disclosure, the above S106 includes: real-time aggregation of all network connections or session instances initiated by the user device; extracting at least one service feature from each network connection or session instance, and matching each service feature with a preset reference library to generate a corresponding single feature confidence; summarizing all single feature confidences to obtain an overall confidence; and judging whether the user device executes the IoT service based on the overall confidence.

[0089] In one embodiment of the present disclosure, whether the user device executes the Internet of Things service is determined based on the overall confidence level. The method further includes: determining whether the overall confidence level meets a preset service discrimination condition; if so, outputting a service tag; and matching the service tag with a pre-built service whitelist to determine whether the user device executes the Internet of Things service.

[0090] In one embodiment of the present disclosure, the system calls the business identification module BIM to determine the business type of network connection / session instances such as TCP / UDP traditional streams, QUIC logical substreams, SCTP or DCCP sessions, TLS / DTLS sessions, etc. The system will select applicable key-value pairs to complete aggregation based on the actual protocol characteristics. Specifically, the system uses the five-tuple {source IP, destination IP, source Port, destination Port, protocol} for TCP / UDP traditional streams, the connection identifier ID (ConnectionID) and stream identifier (StreamID) for QUIC logical substreams, the associated transaction identifier (TransactionID) or StreamID for SCTP or DCCP sessions, and the content identification based on session ID or client hello message ClientHello for TLS / DTLS sessions. At the same time, metadata such as direction, first packet timestamp, length sequence, and whether the end condition is met are maintained in real time.

[0091] After aggregation, BIM extracts at least one business feature from the first K data units of each network connection / session instance. Feature categories include but are not limited to: ① protocol keywords (domain names, paths, instruction codes, etc.); ② private protocol fingerprints (fixed offset codewords, header hashes, etc.); ③ statistical behavior features (length distribution, directional entropy, packet interval, duration, etc.); and ④ deep model embedding features (CNN / Transformer / GNN encoding of payloads or metadata). Each feature is compared with a reference library or model to generate a single feature confidence score conf_i.

[0092] Subsequently, BIM combines each conf_i according to a configurable fusion strategy (linear or piecewise weighting, priority voting, statistical / machine learning models, or deep learning models) to obtain the overall confidence Conf_total, and compares it with a fixed threshold, dynamic threshold, or confidence interval: if the judgment condition is met, the business label final_label is output; otherwise, UNKNOWN is returned. Among them, the keyword table, fingerprint rules, weight parameters, and thresholds can be updated through offline configuration; the model is dynamically optimized using feedback mechanisms (such as manual labeling, anomaly detection, and behavior clustering), and reinforcement learning, incremental learning, and other methods are supported to adjust the fusion strategy. In addition, the dynamic threshold can be automatically adjusted according to changes in the network environment, the weight can be adjusted according to the false positive rate / missed detection rate, and the model can be regularly hot-updated without interrupting service.

[0093] The implementation form of BIM is not restricted. It can use intelligent computing boards or dedicated probes with business identification functions to complete high-speed DPI and metadata collection. It can also be based on software DPI engines, statistics combined with machine learning, pure deep learning inference, or a mixture of the two.

[0094] It should be noted that, based on following the process of “multi-feature extraction → confidence calculation → fusion judgment” and performing service identification on the above-mentioned network connection or session instance, the embodiments of the present disclosure do not specifically limit the technical means adopted.

[0095] In one embodiment of the present disclosure, a service whitelist is first pre-set, for example, some legitimate or known safe service flows that can be identified without in-depth analysis. A bypass probe is then deployed to aggregate packets online into Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) streams according to the five-tuple {source IP, destination IP, source port, destination port, L4 protocol}. The bypass probe is used to capture TCP / UDP packets in the network in real time.

[0096] When a preset termination condition is triggered, the sequence number index, direction, first packet timestamp, length sequence, etc. are maintained for each flow to form basic metadata, and written to the cache after the flow ends. The preset termination condition may include, but is not limited to, any of the following: monitoring that the TCP connection has completed four handshakes, being in a silent state for a preset time period (e.g., 120 seconds), or the number of data packets contained in a flow reaching a preset packet count threshold.

[0097] In one embodiment of the present disclosure, service type determination may be performed in two ways: keyword-based determination and private fingerprint-based determination.

[0098] The keyword-based identification method specifically involves extracting protocol fields that may carry domain names or identifiers at fixed locations within the first K visible packets of each TCP / UDP stream, then searching for matching entries in a pre-set keyword table. For example, the table contains N highly discriminative terms for each app. The number of keyword hits (hit) is counted, and the confidence level (keyword_conf = hit / N, where keyword_conf ∈ [0, 1]) is calculated. The app label and score are then packaged, resulting in the form {"label":"keyword_label","score":keyword_conf}.

[0099] It should be noted that K is set to 3 based on empirical values, and the keyword table is pre-set. The above K and N can be adjusted according to actual conditions, and the embodiments of the present disclosure do not make specific limitations on this.

[0100] The private fingerprint-based identification method specifically involves examining the first K packets of each TCP / UDP stream containing each app's custom protocol header, comparing them against pre-set codeword rules at a pre-set payload offset, and accumulating the weight hit_w for each rule hit. Normalized by the total weight W, the confidence score fingerprint_conf is calculated as (hit_w) / W, where fingerprint_conf∈[0,1]. The app label and score are then packaged together, resulting in the form {"label":"fingerprint_label","score":fingerprint_conf}.

[0101] It should be noted that K is set to 4 based on empirical values, and the load offset and codeword rules are all pre-set. The above K, load offset and codeword rules can be adjusted according to actual conditions, and the embodiments of the present disclosure do not make specific limitations on this.

[0102] It should be noted that the TCP / UDP streams involved in the keyword determination process and the private fingerprint determination process in the embodiment of the present disclosure are the same, and the starting point for obtaining data packets on each TCP / UDP stream is the same.

[0103] In one embodiment of the present disclosure, a voting algorithm is used to determine whether the service type is determined based on keywords or private fingerprints. The results and confidence scores of both the keyword and private fingerprint methods are input into the voting decision maker. The parameters low confidence threshold θ_low and cumulative confidence threshold θ_sum are set. The keyword method is initially prioritized high, while the private fingerprint method is initially prioritized low.

[0104] The decision logic specifically includes the following: if both confidences are lower than θ_low, return UNKNOWN; if the labels are the same and the total confidence is greater than or equal to θ_sum, use that label as the final judgment basis; if the confidences are the same but the labels are different, choose the label corresponding to the keyword with the higher priority; otherwise, choose the label corresponding to the method with the higher confidence as the final judgment basis. The final judgment basis label is recorded as final_label.

[0105] In one embodiment of the present disclosure, for a flow that identifies a specific service and returns UNKNOWN, traffic suppression measures are directly taken for the flow, that is, for a flow whose service type cannot be clearly identified, it will be subject to stricter traffic management or restrictions by default.

[0106] In one embodiment of the present disclosure, the final_label is matched against a pre-built service whitelist. If the match is successful, the label is further mapped to the standard service code Biz_Code defined internally by the operator, and Biz_Allowed is set to 1, indicating that the service is an IoT service. If the match fails, the flow is classified as "other service" or "unknown service," and Biz_Allowed is set to 0, indicating that the service is not an IoT service.

[0107] In one embodiment of the present disclosure, for a specific final_abel, the system first combines multiple dimensions of information, such as user-side attribute flags, service tags, IoT card identifiers, and service codes, to form a Policy_Key. For this generated Policy_Key, the system uses a policy matching engine to search for the corresponding traffic control policy. This policy may include, but is not limited to, bandwidth limiting, rate shaping, scheduling priority adjustment, and other measures. This can be achieved by issuing a set of traffic control parameters for the Policy_Key.

[0108] Specific suppression methods are not limited to a single method and can be selected or combined according to the scenario: First, reduce the bandwidth guarantee by rewriting the minimum guaranteed bandwidth minbr, peak bandwidth pbr, and scheduling priority (such as 5G QoS identifier 5QI, DSCP, queue weight, etc.); second, perform rate shaping based on token bucket, leaky bucket or hierarchical scheduling (such as WFQ, DRR); third, compress PRB quota, slice bandwidth limit or trigger ECN / WRED hierarchical packet loss at the base station gNodeB or UPF; fourth, use statistical or machine learning models to dynamically adjust the above-mentioned rate limit thresholds to achieve closed-loop adaptation. It should be noted that any solution for differentiated suppression of IoT card traffic can be adopted according to actual circumstances, and this disclosure does not specifically limit this.

[0109] In one embodiment of the present disclosure, the previously marked user attribute flags are combined, including but not limited to: User_Type_Unicom=1 (the user device belongs to an external operator), HT_Flag=1 (the user device performs high-traffic services), IoT_Flag=1 (the user device has an Internet of Things card), as well as Biz_Code and Biz_Allowed.

[0110] Using these multiple user attribute flags, a unique traffic control key (Policy_Key = {User_Type_Unicom, HT_Flag, IoT_Flag, Biz_Code}) is formed. For this Policy_Key, a token bucket rate threshold (R_limit) is assigned in the scheduling module, and rate limiting rules are issued in the physical or virtualized flow table. When the actual rate exceeds R_limit, packet loss or marked speed reduction is triggered to lower its priority, ultimately achieving service-level traffic control for high-traffic IoT cards from external operators.

[0111] Figure 3 A method for identifying and suppressing low-cost, high-traffic IoT card services in an embodiment of the present disclosure is shown. Figure 3 As shown, the method includes:

[0112] ① When the UE sends an RRC establishment request to the gNB or after the UE establishes an RRC connection with the gNB, the PLMNID is used to identify whether the UE belongs to a foreign operator.

[0113] ② After the UE establishes an RRC connection with the gNB, it identifies whether the UE is capable of performing high-traffic services based on a preset threshold, that is, whether it has a card capable of performing high-traffic services.

[0114] In one embodiment of the present disclosure, during high-traffic detection, a system employs a combined "k consecutive sampling windows" and "dual thresholds for throughput and PRBs" to simultaneously calculate the PDCP layer's cumulative throughput and resource block occupancy for each sampling window. The HT_Flag is set only when both statistics for k consecutive windows exceed the adaptive thresholds (T_thr, P_thr). This dual-metric, multi-window design effectively avoids misjudgments caused by single peaks or short-term rate jitter. Furthermore, by dynamically updating the thresholds through the NWDAF prediction model, the algorithm maintains stable detection accuracy across a variety of load scenarios, including macro, indoor, and micro base stations. Field validation demonstrates a reduction of approximately 30% in missed detections and 40% in false positives compared to fixed-threshold solutions.

[0115] ③ After determining that the user device belongs to an external operator and is executing a high-traffic business, determine whether the user device has an external operator's high-traffic IoT card based on the external operator's IoT card identification algorithm.

[0116] In one embodiment of the present disclosure, in terms of IoT card identification, an IoT card identification method of hierarchical anchor point discrimination and fusion evaluation is adopted. The system first checks whether the control plane or user plane anchor point (APN / DNN, Slice-ID, AMF_IP, UPF_IP, etc.) of the user device hits the "independently discriminable priority" whitelist; if it hits, IoT_Flag=1 is quickly set. If there is no high-priority anchor point, the system selects at least two types of anchor points (preferably control plane anchor points and user plane anchor points), encodes the hit mark, similarity or confidence into a consistency feature vector, and sends it to the fusion evaluation model (linear weighting, statistics or machine learning or deep learning) to generate a comprehensive score; when the score meets the threshold judgment criterion, the IoT card is confirmed. This hierarchical design provides an extremely fast direct judgment path while retaining the high-precision discrimination capability of multi-anchor fusion.

[0117] For example, when there are no high-priority anchor points, a scoring mechanism based on the consistency of the "APN whitelist, AMF address pool, and UPF address pool" can be used. The system first determines whether the control plane APN / DNN and AMF_IP match the IoT whitelist. It then verifies whether the user plane session landing point, UPF_IP, is located in the dedicated UPF address pool. Finally, a weighted formula is used to calculate a comprehensive score, and the IoT_Flag is confirmed only when the score reaches a threshold. This method simultaneously considers both control and user plane information, overcoming the high misidentification rate of IMSI or APN-only determinations. Verified in live network samples, IoT identification accuracy exceeds 98%, providing fine-grained labeling for subsequent differentiated settlement and resource scheduling.

[0118] ④ After determining that the user device has a high-traffic IoT card from an external operator, determine whether the user device is actually performing non-IoT services based on the service identification algorithm.

[0119] In one embodiment of the present disclosure, service determination is performed on any network connection or session instance (TCP / UDP stream, QUIC substream, TLS session, etc.): Streams are first aggregated by protocol characteristics, and at least one service feature (keyword, private fingerprint, statistical behavior, or deep model embedding) is extracted. Each feature is compared with a reference library / model to generate a confidence score, which is then combined into an overall confidence score (Conf_total) using a configurable fusion strategy (weighted, voting, or machine / deep learning). If Conf_total exceeds a fixed or dynamic threshold, a service label is output; otherwise, UNKNOWN is returned.

[0120] For example, two service identification algorithms, keyword matching and private fingerprint comparison, can be run in parallel in a bypass probe, each outputting a label and confidence level. The voting decision maker sets keyword priority and introduces a cumulative confidence threshold and corresponding decision rules. When the scores of the two algorithms match and are above a low confidence threshold, the label of the preferred method is returned. When the scores disagree, the one with higher confidence is selected; otherwise, UNKNOWN is returned. This dual-algorithm cumulative voting framework not only improves the recognition rate for low-traffic, long-connection services, but also reduces random misjudgments caused by mutual interference, achieving efficient, low-overhead service-level flow control triggering.

[0121] ⑤ After determining that the user device has a high-traffic IoT card from an external operator and that the service actually performed by the user device is non-IoT service, service-level traffic suppression is performed based on the traffic suppression strategy to ensure that network resources are left for legitimate services.

[0122] In one embodiment of the present disclosure, a serially triggered "identify-determine-classify-suppress" process is established. Upon access, the base station analyzes PLMN information and marks non-operator user devices as external users. It then applies a high-traffic detection mechanism to filter out sessions that significantly consume network resources. Within this subset, IoT card identification and service-level classification are performed. Finally, token bucket rate limiting instructions are issued on the gNB side only for target traffic that meets all judgment links. This chained process ensures that each step is preconditioned by the previous judgment result, significantly reducing the probability of accidental damage to ordinary users and legitimate IoT services.

[0123] Based on the same inventive concept, the present disclosure also provides a service traffic suppression device, as described in the following embodiments. Since the principle of solving the problem in the device embodiment is similar to that in the above method embodiment, the implementation of the device embodiment can refer to the implementation of the above method embodiment, and the repeated parts will not be repeated.

[0124] Figure 4 A schematic diagram of a service flow suppression device according to an embodiment of the present disclosure is shown. Figure 4 As shown, the device includes: an operator identification information acquisition module 401, an Internet of Things card judgment module 402, an Internet of Things service judgment module 403 and a service traffic suppression module 404.

[0125] Among them, the operator identification information acquisition module 401 is used to obtain the operator identification information of the user device, wherein the operator identification information includes user identity authentication information and wireless transmission performance data; the Internet of Things card judgment module 402 is used to determine whether the user device is an Internet of Things card based on a plurality of pre-built trusted anchor point pools when it is determined that the operator identification information meets the preset conditions, wherein each trusted anchor point pool contains a group of network entity identifiers known to belong to the Internet of Things service; the Internet of Things service judgment module 403 is used to determine whether the user device is performing the Internet of Things service based on the service data information of the user device if the user device is an Internet of Things card; the service traffic suppression module 404 is used to suppress the traffic of non-Internet of Things services performed by the user device if the user device does not perform the Internet of Things service.

[0126] As can be seen from the above, the disclosed embodiment first obtains the user device's identity authentication information and wireless transmission performance data. If both meet preset conditions, the system then determines whether the user device is an IoT card based on a pre-established trusted anchor point pool. If so, it then determines whether the user device is performing IoT services based on the user device's service data information. If not, traffic suppression is applied to non-IoT services performed by the user device. This disclosed embodiment achieves network resource balancing and ensures a secure service experience for ordinary users.

[0127] In one embodiment of the present disclosure, the above-mentioned operator identification information acquisition module 401 is also used to obtain an access signaling message sent by a user device; determine a unique identifier corresponding to the user device based on the access signaling message, and parse it to obtain a corresponding public land mobile network PLMN identifier as user identity authentication information; and collect wireless transmission performance data of the user device according to a preset period.

[0128] In one embodiment of the present disclosure, the apparatus further includes: a home operator determination module 405, configured to match the PLMN identifier corresponding to the user equipment with a pre-built PLMN whitelist; if the match is consistent, determining that the user equipment belongs to the local operator; if the match is inconsistent, determining that the user equipment belongs to an external operator.

[0129] In one embodiment of the present disclosure, the wireless transmission performance data includes data throughput and the number of physical resource blocks; the device also includes: a high-traffic service judgment module 406, which compares the data throughput with a first preset threshold; compares the number of physical resource blocks with a second preset threshold; if the data throughput is not less than the first preset threshold and the number of physical resource blocks is not less than the second preset threshold, it is determined that the user equipment performs a high-traffic service.

[0130] In one embodiment of the present disclosure, the preset condition is that the user equipment belongs to an external operator and performs a high-traffic service.

[0131] In one embodiment of the present disclosure, the above-mentioned Internet of Things card judgment module 402 is also used to collect anchor point information hit by the current session of the user device; based on the anchor point information, determine whether there is an anchor point that meets the preset independent judgment conditions; if so, determine that the user device is an Internet of Things card; if not, select different categories of anchor points from the anchor point information, match them with the corresponding trusted anchor point pool respectively, and determine whether the user device is an Internet of Things card.

[0132] In one embodiment of the present disclosure, the IoT card determination module 402 is further configured to select different categories of anchor points from the anchor point information and obtain corresponding network entity address information; and match the network entity address information of different categories of anchor points with the corresponding trusted anchor point pools to determine whether the user device is an IoT card.

[0133] In one embodiment of the present disclosure, the IoT service judgment module 403 is further configured to aggregate all network connections or session instances initiated by user devices in real time; extract at least one service feature from each network connection or session instance, and match each service feature with a preset reference library to generate a corresponding single feature confidence; aggregate all single feature confidences to obtain an overall confidence; and determine whether the user device executes the IoT service based on the overall confidence.

[0134] In one embodiment of the present disclosure, the IoT service judgment module 403 is further configured to determine whether the overall confidence level satisfies a preset service discrimination condition; if so, output a service tag; and match the service tag with a pre-built service whitelist to determine whether the user device executes the IoT service.

[0135] Those skilled in the art will appreciate that various aspects of the present disclosure may be implemented as systems, methods, or program products. Therefore, various aspects of the present disclosure may be implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which may be collectively referred to herein as "circuits," "modules," or "systems."

[0136] Refer to the following Figure 5 hereinafter, an electronic device 500 according to this embodiment of the present disclosure is described. Figure 5 The electronic device 500 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0137] like Figure 5As shown, electronic device 500 is implemented as a general-purpose computing device. Components of electronic device 500 may include, but are not limited to, the aforementioned at least one processing unit 510, the aforementioned at least one storage unit 520, and a bus 530 connecting various system components (including storage unit 520 and processing unit 510).

[0138] The storage unit stores a program code, and the program code can be executed by the processing unit 510, so that the processing unit 510 performs the steps described in the "Exemplary Method" section of this specification according to various exemplary embodiments of the present disclosure. For example, the processing unit 510 can perform the following steps of the above method embodiment: obtaining the operator identification information of the user device, wherein the operator identification information includes user identity authentication information and wireless transmission performance data; when it is determined that the operator identification information meets the preset conditions, based on a plurality of pre-built trusted anchor point pools, determining whether the user device is an Internet of Things card, wherein each trusted anchor point pool contains a set of network entity identifiers known to belong to the Internet of Things service; if the user device is an Internet of Things card, then judging whether the user device performs the Internet of Things service based on the service data information of the user device; if the user device does not perform the Internet of Things service, then suppressing the traffic of the non-Internet of Things service performed by the user device.

[0139] The storage unit 520 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 5201 and / or a cache memory unit 5202 , and may further include a read-only memory unit (ROM) 5203 .

[0140] The storage unit 520 may also include a program / utility 5204 having a set (at least one) of program modules 5205, such program modules 5205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0141] Bus 530 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0142] The electronic device 500 can also communicate with one or more external devices 540 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 500, and / or any device that enables the electronic device 500 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). Such communication can occur via an input / output (I / O) interface 550. Furthermore, the electronic device 500 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 560. As shown, the network adapter 560 communicates with other modules of the electronic device 500 via a bus 530. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 500, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0143] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

[0144] Based on the same inventive concept, embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the aforementioned traffic suppression methods. Because the principles underlying the problems solved by this computer-readable storage medium embodiment are similar to those of the aforementioned method embodiment, the implementation of this computer-readable storage medium embodiment can be referenced to the implementation of the aforementioned method embodiment, and any repetitive details will not be repeated.

[0145] More specific examples of computer-readable storage media in the present disclosure may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fibers, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0146] In the present disclosure, a computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0147] Alternatively, the program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.

[0148] In a specific implementation, the program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and the like, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a standalone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0149] Based on the same inventive concept, embodiments of the present disclosure also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implements the traffic suppression method described in any one of the above-mentioned method embodiments. Because the principles for solving the problems described in this computer program product embodiment are similar to those described in the above-mentioned method embodiments, the implementation of this computer program product embodiment can be referenced to the implementation of the above-mentioned method embodiments, and any repetitions will not be repeated.

[0150] It should be noted that although several modules or units of the device for action execution are mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0151] Furthermore, although the steps of the method of the present disclosure are described in a particular order in the accompanying drawings, this does not require or imply that the steps must be performed in this particular order, or that all steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0152] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

[0153] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the appended claims.

Claims

1. A method for suppressing business traffic, characterized in that: include: Obtaining operator identification information of a user device, wherein the operator identification information includes user identity authentication information and wireless transmission performance data; If it is determined that the operator identification information meets the preset conditions, determining whether the user device is an IoT card based on a plurality of pre-established trusted anchor point pools, wherein each trusted anchor point pool contains a set of network entity identifiers known to belong to IoT services; If the user device is an Internet of Things card, determining whether the user device performs an Internet of Things service based on the service data information of the user device; If the user equipment does not perform an Internet of Things service, traffic suppression is performed on the non-Internet of Things service performed by the user equipment.

2. The service flow suppression method according to claim 1, characterized in that: The obtaining of operator identification information of the user equipment includes: Obtaining an access signaling message sent by a user equipment; Determining, according to the access signaling message, a unique identifier corresponding to the user equipment, and parsing to obtain a corresponding public land mobile network (PLMN) identifier as user identity authentication information; Collect wireless transmission performance data of the user equipment according to a preset period.

3. The service flow suppression method according to claim 2, characterized in that: After obtaining the operator identification information of the user equipment, the method further includes: Match the PLMN identifier corresponding to the user equipment with the pre-built PLMN whitelist; If the match is consistent, it is determined that the user equipment belongs to the local operator; If the match is inconsistent, it is determined that the user equipment belongs to an external operator.

4. The service flow suppression method according to claim 1, characterized in that: The wireless transmission performance data includes data throughput and number of physical resource blocks; After obtaining the operator identification information of the user equipment, the method further includes: comparing the data throughput with a first preset threshold; Comparing the number of physical resource blocks with a second preset threshold; If the data throughput is not less than the first preset threshold, and the number of physical resource blocks is not less than the second preset threshold, it is determined that the user equipment performs a high-traffic service.

5. The service flow suppression method according to claim 1, characterized in that: The preset condition is that the user equipment belongs to an external operator and performs a high-traffic service.

6. The service flow suppression method according to claim 1, characterized in that: Determine whether the user device is an IoT card based on multiple pre-built trusted anchor point pools, including: Collect the anchor point information hit by the current session of the user device; Determining, based on the anchor point information, whether there is an anchor point that meets a preset independent judgment condition; If so, it is determined that the user device is an IoT card; If not, different categories of anchor points are selected from the anchor point information, matched with corresponding trusted anchor point pools respectively, and whether the user device is an Internet of Things card is determined.

7. The service flow suppression method according to claim 6, characterized in that: The selecting of different categories of anchor points from the anchor point information, matching them with corresponding trusted anchor point pools respectively, and determining whether the user device is an IoT card includes: Selecting different types of anchor points from the anchor point information and obtaining corresponding network entity address information; The network entity address information of different types of anchor points is matched with the corresponding trusted anchor point pool to determine whether the user device is an IoT card.

8. The service flow suppression method according to claim 1, characterized in that: Determining, based on the service data information of the user equipment, whether the user equipment performs an Internet of Things service, includes: Real-time aggregation of all network connections or session instances initiated by user devices; Extract at least one service feature from each network connection or session instance, match each service feature with a preset reference library, and generate a corresponding single feature confidence score; Summarize all single feature confidences to get the overall confidence; Determine whether the user equipment performs an Internet of Things service based on the overall confidence level.

9. The service flow suppression method according to claim 8, characterized in that: Determining, based on the overall confidence level, whether the user equipment performs an Internet of Things service includes: Determine whether the overall confidence level meets the preset business judgment conditions; If yes, then output the business label; The service tag is matched with a pre-built service whitelist to determine whether the user device executes the Internet of Things service.

10. A service flow suppression device, characterized in that: include: An operator identification information acquisition module is used to obtain operator identification information of a user device, wherein the operator identification information includes user identity authentication information and wireless transmission performance data; An IoT card determination module is configured to determine whether the user device is an IoT card based on a plurality of pre-established trusted anchor point pools upon determining that the operator identification information satisfies a preset condition, wherein each trusted anchor point pool contains a set of network entity identifiers known to belong to IoT services; An Internet of Things service judgment module, configured to, if the user device is an Internet of Things card, judge whether the user device executes an Internet of Things service based on the service data information of the user device; The service traffic suppression module is used to suppress the traffic of non-Internet of Things services executed by the user equipment if the user equipment does not execute the Internet of Things service.

11. An electronic device, characterized in that: include: processor; as well as a memory for storing executable instructions of the processor; The processor is configured to execute the service flow suppression method according to any one of claims 1 to 9 by executing the executable instructions.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the service flow suppression method according to any one of claims 1 to 9 is implemented.

13. A computer program product comprising: A computer program or instruction, characterized in that when the computer program or instruction is executed by a processor, it implements the service traffic suppression method according to any one of claims 1 to 9.

Images