Internet multicast protocol driven IPTV server control method and system

Abstract

The present invention relates to the field of network communication technology and discloses a method and system for controlling an IPTV server driven by an Internet multicast protocol. The method comprises the following steps: first obtaining a multicast data stream and parsing its protocol characteristics; identifying multicast nodes and then slicing the traffic; building a traffic on-demand framework; extracting traffic load data within the framework and marking it in a hierarchical manner; calculating bandwidth allocation values ​​to detect traffic anomalies; determining the congested areas corresponding to the anomalies and marking them with speed limits; calculating a conflict threshold after obtaining data through protocol analysis; identifying redundant parameters based on the threshold; optimizing parameters in combination with preset QoS standards; and finally formulating a multicast control strategy based on the protocol analysis data. The present invention can improve the resource scheduling efficiency of IPTV servers.

Description

Technical Field

[0001] The present invention relates to an Internet multicast protocol-driven IPTV server management and control method and system, belonging to the technical field of network communications. Background Art

[0002] IPTV (Internet Protocol Television) is a technology for transmitting multimedia content over IP networks. It is widely used in live, on-demand, and interactive video services. Its multicast protocols (such as IGMP and PIM) are the core transmission mechanisms of IPTV, reducing network load through one-to-many distribution.

[0003] Current technologies typically employ fixed multicast routing strategies or manually adjust multicast group memberships, lacking real-time awareness of network conditions (such as congestion and node failures) and user needs (such as channel switching frequency). Furthermore, traditional approaches suffer from weak coordination capabilities in cross-domain multicast scenarios, easily leading to data redundancy and packet loss, impacting Quality of Service (QoS). Therefore, an intelligent management and control approach driven by Internet multicast protocols is needed to improve resource scheduling efficiency for IPTV servers. Summary of the Invention

[0004] The present invention provides an Internet multicast protocol-driven IPTV server management and control method and system, the main purpose of which is to improve the resource scheduling efficiency of the IPTV server.

[0005] To achieve the above objectives, the present invention provides an Internet multicast protocol-driven IPTV server management and control method, comprising:

[0006] Obtaining a multicast data stream corresponding to a target IPTV server, performing protocol parsing on the multicast data stream to obtain multicast protocol features, and identifying a multicast node in the multicast data stream based on the multicast protocol features;

[0007] Based on the multicast node, the multicast data stream is traffic sliced ​​to obtain sliced ​​traffic units, and based on the sliced ​​traffic units, a traffic on-demand framework corresponding to the target IPTV server is constructed;

[0008] Extracting traffic load data from the traffic on-demand framework, performing hierarchical marking on the traffic load data to obtain hierarchical load queues, calculating bandwidth allocation values ​​corresponding to the hierarchical load queues, and detecting traffic anomalies in the target IPTV server based on the bandwidth allocation values;

[0009] Determine a congested area corresponding to the traffic anomaly point, mark the congested area with a speed limit, obtain an area control label, perform protocol analysis on the area control label to obtain protocol analysis data, and calculate a conflict threshold corresponding to the protocol analysis data;

[0010] Based on the conflict threshold, redundant parameters in the protocol analysis data are identified, the redundant parameters are managed and optimized with preset QoS standards to obtain management and control optimization parameters, and based on the protocol analysis data, a multicast management and control strategy corresponding to the target IPTV server is formulated.

[0011] Optionally, the identifying a multicast node in the multicast data stream based on the multicast protocol feature includes:

[0012] Parsing the protocol fields in the multicast protocol;

[0013] Based on the protocol field, traverse the node routing table in the preset topology database;

[0014] Extracting the time series communication records of active nodes in the node routing table;

[0015] Filtering candidate recording points in the time series communication record;

[0016] Based on the candidate recording points, a multicast node in the multicast data stream is identified.

[0017] Optionally, the performing traffic slicing on the multicast data stream based on the multicast node to obtain a slicing traffic unit includes:

[0018] Querying a multicast traffic sequence corresponding to the multicast data stream;

[0019] extracting a traffic sequence vector from the multicast traffic sequence;

[0020] Dividing the dynamic fragmentation interval corresponding to the traffic sequence vector;

[0021] Identifying a sharding granularity in the dynamic sharding interval;

[0022] Based on the fragmentation granularity, traffic fragmentation is performed on the multicast data stream to obtain fragmented traffic units.

[0023] Optionally, constructing a traffic on-demand framework corresponding to the target IPTV server based on the fragmented traffic unit includes:

[0024] Analyze the traffic peak and time period distribution in the sharded traffic unit;

[0025] Fitting a flow fluctuation curve corresponding to the flow peak value and the time period distribution;

[0026] Extracting the time period load segment and the buffer zone segment in the flow fluctuation curve;

[0027] Dynamically divide the node resource pool corresponding to the target IPTV server based on the time period load threshold;

[0028] Based on the buffer interval and the node resource pool, a traffic on-demand framework corresponding to the target IPTV server is constructed.

[0029] Optionally, calculating the bandwidth allocation value corresponding to the hierarchical load queue includes:

[0030] The bandwidth allocation value corresponding to the hierarchical load queue is calculated using the following formula:

[0031] ;

[0032] in, Indicates the bandwidth allocation value corresponding to the hierarchical load queue, Indicates the total number of levels corresponding to the hierarchical load queue, Indicates the level index corresponding to the hierarchical load queue, represents the priority weight of the i-th level load, represents the normalized load value of the i-th level load, and Respectively represent the start time and end time of the bandwidth calculation period, represents the cumulative load of the target node in the hierarchical load queue during the bandwidth calculation period, Indicates the maximum load value in the hierarchical load queue. Indicates the minimum load value in the hierarchical load queue.

[0033] Optionally, detecting traffic anomalies in the target IPTV server based on the bandwidth allocation value includes:

[0034] Parsing the bandwidth flow packet corresponding to the bandwidth allocation value;

[0035] Extracting peak-valley fluctuation data corresponding to a transmission unit in the target IPTV server based on the bandwidth traffic packet;

[0036] Determining a dynamic threshold baseline corresponding to the peak-to-valley fluctuation data;

[0037] Analyzing the instantaneous transmission rate of traffic units in the target IPTV server according to the dynamic threshold baseline;

[0038] Based on the instantaneous transmission rate, a traffic abnormality point in the target IPTV server is determined.

[0039] Optionally, the performing speed limit marking on the congested area to obtain an area control label includes:

[0040] Extracting traffic peak data in the congested area;

[0041] According to the traffic peak data, the congestion area is divided into dynamic speed limit levels corresponding to the congestion area;

[0042] Match the protocol speed limit rules corresponding to the dynamic speed limit level;

[0043] Based on the protocol rate limit rule, marking the congestion boundary corresponding to the congested area;

[0044] According to the congestion boundary, the congested area is marked with a speed limit to obtain an area control label.

[0045] Optionally, calculating a conflict threshold corresponding to the protocol analysis data includes:

[0046] The conflict threshold corresponding to the protocol analysis data is calculated using the following formula:

[0047] ;

[0048] in, represents the conflict threshold corresponding to the protocol analysis data, represents the current parameter vector corresponding to the protocol analysis data, represents the reference parameter vector, Indicates the total number of data items corresponding to the protocol analysis data, Indicates the data item index corresponding to the protocol analysis data, Indicates the The conflict-sensitive weights corresponding to the data items are Indicates the load fluctuation coefficient, Indicates the end time of the load analysis period, represents the load change rate at time t, Indicates the average load during the load analysis period. represents the historical conflict factor, Indicates the number of historical conflicts, Indicates the conflict statistics period.

[0049] Optionally, the identifying redundant parameters in the protocol analysis data based on the conflict threshold includes:

[0050] Analyzing a threshold baseline corresponding to the conflict threshold;

[0051] Based on the threshold baseline, conflict marking is performed on the protocol analysis data to obtain a marked data set;

[0052] Filtering redundant nodes in the labeled data set;

[0053] Based on the redundant nodes, redundant parameters in the protocol analysis data are identified.

[0054] In order to solve the above problems, the present invention also provides an IPTV server management and control system driven by an Internet multicast protocol, the system comprising:

[0055] a node identification module configured to obtain a multicast data stream corresponding to a target IPTV server, perform protocol analysis on the multicast data stream to obtain multicast protocol features, and identify multicast nodes in the multicast data stream based on the multicast protocol features;

[0056] A framework construction module is used to perform traffic slicing on the multicast data stream based on the multicast node to obtain slicing traffic units, and to construct a traffic on-demand framework corresponding to the target IPTV server based on the slicing traffic units;

[0057] an anomaly detection module, configured to extract traffic load data from the traffic on-demand framework, perform hierarchical marking on the traffic load data to obtain hierarchical load queues, calculate bandwidth allocation values ​​corresponding to the hierarchical load queues, and detect traffic anomalies in the target IPTV server based on the bandwidth allocation values;

[0058] a threshold calculation module, configured to determine a congested area corresponding to the traffic anomaly point, mark the congested area with a speed limit, obtain an area control label, perform protocol analysis on the area control label, obtain protocol analysis data, and calculate a conflict threshold corresponding to the protocol analysis data;

[0059] A policy formulation module is used to identify redundant parameters in the protocol analysis data based on the conflict threshold, optimize the management and control of the redundant parameters and the preset QoS standards, obtain management and control optimization parameters, and formulate a multicast management and control policy corresponding to the target IPTV server based on the protocol analysis data.

[0060] Compared with the problems described in the background technology, the present invention obtains the multicast data stream corresponding to the target IPTV server, can accurately identify the multicast node through protocol analysis, build a topology structure, provide a data basis for the construction of traffic segmentation and on-demand framework, effectively guarantee the quality of IPTV service and reduce network load. Based on the multicast node, the present invention can split the data stream into segmented traffic units adapted to the processing capabilities of different nodes according to the node location (such as edge router and core server) and load difference, improve transmission efficiency, and ensure the smoothness and stability of IPTV service. Furthermore, by extracting the traffic load data in the traffic on-demand framework, the present invention can accurately grasp the traffic pressure of each node in different time periods, helping operation and maintenance personnel to predict potential network congestion in advance. Reasonable allocation of resources can also be used to mine traffic patterns through historical load data, guide server expansion or upgrade, and improve the overall performance and user experience of IPTV services. Furthermore, the present invention helps analyze the cause of congestion by determining the congested area corresponding to the traffic anomaly point, whether it is insufficient equipment performance, link failure or traffic burst, etc., providing a basis for subsequent optimization; it can also assist in the reasonable planning of network resources, expand or adjust the configuration of congested areas in advance, and improve the overall reliability and stability of the IPTV network. Finally, based on the conflict threshold, the present invention identifies redundant parameters in the protocol analysis data, can accurately locate parameters that have no substantial impact or minimal impact on the conflict risk, avoid invalid configuration interference, simplify protocol rules, and enhance network stability and reliability. Therefore, the Internet multicast protocol-driven IPTV server control method and system provided in the embodiment of the present invention can improve the resource scheduling efficiency of the IPTV server. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 A schematic diagram of a flow chart of an Internet multicast protocol-driven IPTV server management and control method provided in one embodiment of the present invention;

[0062] Figure 2 A schematic diagram of the architecture of a traffic on-demand framework in an Internet multicast protocol-driven IPTV server management and control method provided in one embodiment of the present invention;

[0063] Figure 3 A schematic diagram of modules for implementing the Internet multicast protocol-driven IPTV server management and control system provided in one embodiment of the present invention.

[0064] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0065] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0066] The present invention provides an Internet multicast protocol-driven IPTV server management and control method. The method can be executed by at least one of the following electronic devices, including a server and a terminal, that can be configured to execute the method provided by the present invention. In other words, the method can be executed by software or hardware installed on a terminal or server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster.

[0067] Example 1:

[0068] Reference Figure 1 FIG. 1 is a flow chart of an Internet multicast protocol-driven IPTV server management and control method provided by an embodiment of the present invention. In this embodiment, the Internet multicast protocol-driven IPTV server management and control method includes:

[0069] S1. Acquire a multicast data stream corresponding to a target IPTV server, perform protocol analysis on the multicast data stream to obtain multicast protocol features, and identify multicast nodes in the multicast data stream based on the multicast protocol features.

[0070] By acquiring the multicast data stream corresponding to the target IPTV server, the present invention can accurately identify the multicast nodes and build a topology structure through protocol analysis, providing a data basis for traffic segmentation and on-demand framework construction, effectively ensuring the quality of IPTV services and reducing network load.

[0071] The target IPTV server refers to a specific IPTV service provider device that needs to be managed and controlled. It is usually a server deployed in the operator's computer room or content distribution network (CDN), responsible for receiving, processing and pushing audio and video content through the multicast protocol. For example, a 4K live broadcast server provided by an operator to users in the northern region, which carries the multicast stream sending task of channels such as CCTV-5, is a typical target IPTV. server; the multicast data stream refers to a multimedia data collection transmitted based on the IP multicast protocol (such as IGMP, PIM), which distributes live streams, on-demand content, etc. from the source end to multiple receiving ends in a "one-to-many" manner, which can reduce network bandwidth usage. For example, when a user watches the live broadcast of the Premier League through an IPTV set-top box, the continuous video frames, audio streams and control signaling sent by the server to the multicast group address 239.1.1.1 together constitute the multicast data stream of the channel. Optionally, the multicast data stream corresponding to the target IPTV server can be obtained through a network protocol parsing tool, such as: using Wireshark to capture IGMP protocol messages, parse the multicast group address and port, and then input the multicast address through the VLC player to receive the data stream in real time, thereby obtaining the multicast data stream.

[0072] Furthermore, the present invention obtains multicast protocol characteristics by performing protocol analysis on the multicast data stream, can accurately identify key information such as the multicast group address, membership and routing path in the data stream, quickly build a multicast topology structure, and help realize intelligent management and control of IPTV server multicast transmission and resource optimization configuration.

[0073] The multicast protocol features refer to key parameters and behavioral characteristics parsed from the multicast data stream that reflect the execution status of the multicast protocol (such as IGMP and PIM), including but not limited to the multicast group address (such as 239.0.0.1), the join / leave message type of the member host, the querier election status (IGMPv3), the flood-prune status of the PIM routing protocol, the RP (rendezvous point) address, the multicast tree type (SPT / RPT), and the protocol message interaction delay. For example, IGMP protocol features can reflect changes in the membership of user-subscribed channels, and PIM protocol features can reflect the routing optimization path during cross-domain multicast. Optionally, the protocol parsing of the multicast data stream can be performed using a network protocol analysis tool, such as using Wireshark to capture multicast packets and parse their IP headers, UDP / TCP ports, and payload content to extract the multicast protocol features.

[0074] Furthermore, based on the multicast protocol characteristics, the present invention identifies multicast nodes in the multicast data stream, can quickly locate the positions and roles of topological components such as data sources, routers, and receiving ends, clarify the data transmission path, and assist in discovering abnormal nodes (such as failed routers or illegal receiving ends), facilitating timely optimization of the multicast tree structure and improving the stability and security of IPTV transmission.

[0075] The multicast nodes refer to all network entities involved in multicast data transmission, including data source nodes (IPTV servers), forwarding nodes (multicast routers, layer 3 switches), receiving nodes (user set-top boxes, terminal devices), and querier nodes responsible for protocol control.

[0076] As an embodiment of the present invention, the identifying of multicast nodes in the multicast data stream based on the multicast protocol characteristics includes: parsing the protocol field in the multicast protocol; traversing the node routing table in a preset topology database based on the protocol field; extracting the time series communication records of active nodes in the node routing table; filtering the candidate recording points in the time series communication records; and identifying the multicast nodes in the multicast data stream based on the candidate recording points.

[0077] The protocol field refers to a field containing specific functions in a multicast protocol (such as IGMP, PIM) message, for example, the type field (identifying member join / leave messages) and group address field of IGMP, the message type field (such as Join / Prune messages) and source address field of PIM, which are used to carry the interaction logic and status information between multicast nodes; the preset topology database refers to a pre-stored IPTV network topology database, which contains the physical addresses, logical groupings, connection relationships and protocol configuration information of routers, servers, switches and other devices in the network, and is used to match the multicast protocol features parsed in real time; the node routing table is Refers to the multicast routing entries maintained by each network node (such as a router) recorded in the topology database, which contain information such as the multicast group address, outbound interface list, routing protocol type (such as PIM-SM), and next-hop address, reflecting the forwarding path of multicast data in the node; the active node refers to a node currently participating in multicast data transmission and in normal communication status, distinguished from a dormant, faulty, or non-joined multicast group node through survival messages in the protocol field (such as IGMP general query response) or real-time traffic interaction confirmation; the time-series communication record refers to a log of protocol message interactions between active nodes recorded in chronological order, such as the sending time of IGMP member report and the reception timing of PIM Join messages, which are used to analyze the continuity and behavior patterns of node communication; the candidate recording point refers to key interaction events related to the target multicast data stream screened from the time-series communication record, such as the first join request for a specific multicast group address and the time point of renegotiation of the routing protocol between nodes, which serve as characteristic markers for identifying multicast nodes.

[0078] Furthermore, the parsing of the protocol fields in the multicast protocol can be achieved through a network protocol analysis tool, such as: using the protocol parsing engine of Wireshark to deconstruct the IP header, UDP / TCP message and RTP / RTCP payload layer by layer, and extracting protocol fields such as source address, destination address, port number and timestamp; the traversal of the node routing table in the preset topology database can be achieved through a graph database query language, such as: executing a MATCH path query through the Cypher statement of Neo4j, traversing the next-hop routing entries of all nodes, and thus obtaining a complete node routing table; the extraction of the time series communication records of the active nodes in the node routing table can be achieved through a time series database. Implementation, such as: querying the tx_bytes / rx_bytes counters of the specified node from InfluxDB according to the time range, and aggregating to generate a communication record sequence with a timestamp; filtering the candidate record points in the time series communication record can be implemented by a sliding window algorithm, such as: calculating the 5-minute traffic mean based on the rolling function of Pandas, and retaining the abnormal peak points exceeding the threshold 3σ as candidate record points; identifying the multicast nodes in the multicast data stream can be implemented by a machine learning classifier, such as: using the random forest model of Scikit-learn, classifying and identifying the multicast member nodes according to the node communication frequency, data packet TTL characteristics and IGMP protocol tags.

[0079] S2. Based on the multicast node, the multicast data stream is traffic sliced ​​to obtain sliced ​​traffic units, and based on the sliced ​​traffic units, a traffic on-demand framework corresponding to the target IPTV server is constructed.

[0080] Based on the multicast node, the present invention can split the data stream into fragmented traffic units adapted to the processing capabilities of different nodes according to the node location (such as edge router and core server) and load differences, thereby improving transmission efficiency and ensuring the smoothness and stability of IPTV services.

[0081] Among them, the fragmented traffic unit refers to an independent data unit split from the multicast data stream according to the dynamic fragmentation interval and fragmentation granularity, which can be used as the basic unit of node scheduling. For example, a 30-second live stream is split into 30 fragments at a 1-second granularity. Each fragment contains the video frame, audio stream and multicast control message within that second, which is a fragmented traffic unit and can be independently transmitted and cached between multicast nodes.

[0082] As an embodiment of the present invention, the multicast data stream is traffic sliced ​​based on the multicast node to obtain a sliced ​​traffic unit, including: querying the multicast traffic sequence corresponding to the multicast data stream; extracting the traffic sequence vector in the multicast traffic sequence; dividing the dynamic slice interval corresponding to the traffic sequence vector; identifying the slice granularity in the dynamic slice interval; and based on the slice granularity, performing traffic slice on the multicast data stream to obtain a sliced ​​traffic unit.

[0083] The multicast traffic sequence refers to the orderly arrangement of continuous data streams sent by the target IPTV server through the multicast protocol in the time dimension, including audio and video data, control signaling, etc., forming a traffic set with time sequence characteristics in the transmission order. For example, in the live stream of a sports channel, 50 video frames and corresponding RTP / RTCP control packets sent per second constitute the multicast traffic sequence of the channel in time sequence; the traffic sequence vector refers to the conversion of the multicast traffic sequence into a numerical feature vector, which includes quantitative values ​​of dimensions such as traffic size, packet interval time, data type (such as I frame / P frame), protocol type (IGMP / PIM), etc., and is used to characterize the dynamic characteristics of the traffic. For example, a video stream within 1 second is split into a vector composed of parameters such as "traffic peak 10Mbps, average packet interval 20ms, I frame proportion 10%", which is a Traffic sequence vector; the dynamic sharding interval refers to the traffic segmentation range dynamically divided according to the changing trend of the traffic sequence vector (such as bandwidth fluctuation, data type switching), which is used to adapt to the processing capabilities of different nodes. For example, when it is detected that the live stream switches from the advertising period (low bit rate) to the game scene (high bit rate), the switching point is automatically used as the sharding boundary to form two dynamic sharding intervals before and after; the sharding granularity refers to the granularity of the traffic sharding, which is usually measured in time length (such as 500ms / shard) or data volume (such as 10MB / shard), and needs to be dynamically adjusted in combination with node performance (such as the cache capacity of the edge router). For example, in areas with weak edge node processing capabilities, the sharding granularity is set to 500ms, so that each sharded traffic unit contains approximately 5MB of data, which facilitates rapid node forwarding.

[0084] Furthermore, the querying of the multicast traffic sequence corresponding to the multicast data stream can be implemented through a time series database, such as using the InfluxDB SELECT statement to query the byte_count indicator of the specified multicast group by time range, and aggregating to generate a traffic sequence with a timestamp; the extraction of the traffic sequence vector from the multicast traffic sequence can be implemented through a numerical processing library, such as converting the time series into a two-dimensional vector matrix of [timestamp, traffic value] through the NumPy array function; the division of the dynamic sharding interval corresponding to the traffic sequence vector can be implemented through a clustering algorithm, such as applying the KMeans algorithm of Scikit-learn to automatically divide the high / medium / low load intervals according to the traffic fluctuation characteristics; the identification of the sharding granularity in the dynamic sharding interval can be implemented through a statistical analysis tool, such as using the Pandas describe function to calculate the standard deviation of the traffic in each interval and determining the optimal shard size based on the 3σ principle; the traffic sharding of the multicast data stream can be implemented through a stream processing framework, such as dynamically blocking the data stream according to the identified sharding granularity based on the Apache Flink window operator to generate sharded traffic units of equal length.

[0085] The present invention constructs a traffic on-demand framework corresponding to the target IPTV server based on the fragmented traffic unit. The fragmented unit can be associated with multicast node resources (such as edge server cache) through the framework, thereby achieving local distribution and rapid response, reducing the pressure on the core network, and improving the playback fluency and system concurrent processing capabilities in the on-demand scenario.

[0086] Among them, the traffic on-demand framework refers to an intelligent scheduling system built based on fragmented traffic units, node resource pools and buffering mechanisms, which realizes on-demand allocation and flexible control of multicast streams. For example, when a user requests a live broadcast segment, the framework calls the pre-cached corresponding fragment unit from the node resource pool and quickly pushes it to the terminal through an optimized path, supporting operations such as pause and fast forward.

[0087] As an embodiment of the present invention, the traffic on-demand framework corresponding to the target IPTV server is constructed based on the sliced ​​traffic unit, including: parsing the traffic peak and time period distribution in the sliced ​​traffic unit; fitting the traffic fluctuation curve corresponding to the traffic peak and the time period distribution; extracting the time period load segment and buffer interval segment in the traffic fluctuation curve; dynamically dividing the node resource pool corresponding to the target IPTV server based on the time period load threshold; and constructing the traffic on-demand framework corresponding to the target IPTV server based on the buffer interval segment and the node resource pool.

[0088] Among them, the traffic peak refers to the maximum data transmission rate (such as Mbps) of the fragmented traffic unit in unit time, reflecting the burst load of the multicast stream. For example, the video encoding bit rate at the moment of a goal in a live broadcast of a sports event suddenly increases to 15Mbps, which is the traffic peak of that period; the time period distribution refers to the distribution pattern of traffic peaks and various types of data (such as I frames, audio streams) on the time axis, which is usually counted in units of minutes or seconds. For example, a TV series has an advertisement switch every 10 minutes, and the bit rate of the advertising period is lower and the bit rate of the plot period is higher in the corresponding time period distribution; the traffic fluctuation curve refers to the traffic rate curve that changes with time drawn in the coordinate system by fitting the traffic peak and time period distribution, which intuitively shows the dynamic fluctuations of the data flow. For example, the average bit rate per minute of a 2-hour live stream is connected into a curve, showing a "stable-peak-stable" wave-shaped fluctuation; the time period load segment refers to the flow During the time period when the load in the traffic fluctuation curve exceeds the preset threshold, node resources need to be allocated in a priority manner. For example, when the curve shows that the bit rate is continuously higher than 8Mbps (the threshold is 5Mbps) from 19:00 to 19:30, this period is the time period load segment, and the edge server cache resources need to be increased; the buffer interval refers to the time period in the traffic fluctuation curve when the load is lower than the threshold and there are redundant resources, which can be used for pre-caching or traffic smoothing. For example, during the advertising period, the bit rate drops to 2Mbps (lower than the threshold), and the fragmented traffic units of this period can be pre-cached to the edge node to provide a buffer for subsequent high-load periods; the node resource pool refers to a collection of multicast node resources dynamically divided according to the time period load segment, including edge servers, router caches, bandwidth quotas, etc., which are used to respond to real-time traffic needs. For example, 10 edge servers close to the user are divided into a resource pool, and fragmented transmission of popular channels is given priority during high-load periods.

[0089] Furthermore, the analysis of the traffic peak and time distribution in the sharded traffic unit can be achieved through time series analysis tools, such as: using Pandas's resample and max functions to count the maximum traffic value in each time period, and combining Matplotlib to draw a 24-hour traffic heat map, so as to extract the peak time period and distribution characteristics; the fitting of the traffic peak and the traffic fluctuation curve corresponding to the time period distribution can be achieved through a regression algorithm, such as: applying Scikit-learn's SVR model to perform nonlinear fitting on the peak point to generate a smooth traffic fluctuation trend curve; the extraction of the time period load segment and the buffer zone segment in the traffic fluctuation curve can be achieved through the inflection point The detection algorithm is implemented, such as: identifying the sudden change point of the curve slope based on the Kneedle algorithm, marking the interval above the threshold as the load segment, and the rest as the buffer segment; the dynamic division of the node resource pool corresponding to the target IPTV server can be achieved through the resource scheduling framework, such as: automatically expanding and shrinking the Pod instance according to the load segment requirements through the HPA component of Kubernetes to form an elastic resource pool; the construction of the traffic on-demand framework corresponding to the target IPTV server can be achieved through the streaming media architecture, such as: building an edge node cluster based on the Nginx-RTMP module, configuring a hierarchical caching strategy according to the buffer segment, and finally forming an on-demand framework that supports dynamic resource scheduling.

[0090] Specifically, to further understand the on-demand logic architecture corresponding to the traffic on-demand framework in this application, please refer to Figure 2 The image shown is a diagram of the on-demand logic architecture provided by the present invention. It should be noted that, in the present invention, Figure 2 The architecture diagram presented is only used to illustrate the VOD logical architecture, which starts from CP / SP (content provider / service provider), passes through the national content center, nine distribution centers, provincial nodes and then to the municipal nodes. It involves components such as LVS (load balancer), and Figure 2 The content of building a traffic on-demand framework involves analyzing and processing traffic-related parameters (such as traffic peaks, time period distribution, etc.), and then dividing the node resource pool and building the on-demand framework. The nodes and distribution paths at each level presented in this architecture diagram are the physical or logical architecture foundations on which the sharded traffic units actually distribute, schedule, and allocate resources after the above-mentioned traffic analysis and processing. They provide node layout and transmission path support for the implementation of the traffic on-demand framework, and do not limit the relationship analysis of the traffic on-demand framework in different actual application scenarios.

[0091] S3. Extract traffic load data from the traffic on-demand framework, perform hierarchical marking on the traffic load data to obtain hierarchical load queues, calculate bandwidth allocation values ​​corresponding to the hierarchical load queues, and detect traffic anomalies in the target IPTV server based on the bandwidth allocation values.

[0092] By extracting traffic load data from the traffic on-demand framework, the present invention can accurately grasp the traffic pressure of each node at different time periods, helping operation and maintenance personnel to predict potential network congestion in advance and allocate resources reasonably. It can also mine traffic patterns through historical load data to guide server expansion or upgrade, thereby improving the overall performance and user experience of IPTV services.

[0093] Among them, the traffic load data refers to a data set in the traffic on-demand framework that reflects the data transmission load of network nodes, links, etc. in a specific time period, including traffic rate (such as the amount of data transmitted per second, unit Mbps), number of concurrent connections, bandwidth occupancy rate and other indicators. For example, a specific edge server has an average traffic rate of 8Mbps from 8 to 9 pm, 500 concurrent connections, and a bandwidth occupancy rate of 70%. These values ​​are the traffic load data for this period. Optionally, the extraction of traffic load data from the traffic on-demand framework can be achieved through a streaming media monitoring tool, such as using Nginx's stub_status module to collect indicators such as the number of connections and request rate in real time, combining Telegraf for data collection, and finally outputting load data including QPS and bandwidth utilization.

[0094] Furthermore, the present invention obtains a hierarchical load queue by hierarchically marking the traffic load data, which can clearly distinguish different degrees of traffic pressure, facilitate operation and maintenance personnel to quickly locate high-load nodes and prioritize potential risks. It can also provide an intuitive basis for traffic scheduling strategies, dynamically adjust content distribution paths according to load levels, and ensure stable and smooth IPTV services.

[0095] Among them, the hierarchical load queue refers to a queue formed by arranging network nodes or links in order of levels according to the size or severity of the traffic load data. It is usually divided into multiple levels from light to heavy (or from low to high), such as low load, medium load, and high load. For example, nodes with a bandwidth occupancy rate below 30% are marked as low load levels and placed at the head of the queue, 30%-70% are medium load levels and placed in the middle, and above 70% are high load levels and placed at the end of the queue, thereby forming an ordered queue for easy management and scheduling. Optionally, the hierarchical marking of the traffic load data can be achieved through a clustering algorithm, such as using Scikit-learn's KMeans algorithm to automatically divide the load data into three levels of high / medium / low according to characteristics such as bandwidth occupancy rate and request concurrency to generate a hierarchical load queue.

[0096] Furthermore, the present invention can achieve differentiated allocation of bandwidth resources according to load levels by calculating the bandwidth allocation values ​​corresponding to the hierarchical load queues, dynamically increase bandwidth quotas for high-load nodes to alleviate congestion, avoid resource waste in low-load nodes, and optimize the QoS indicators of IPTV services.

[0097] The bandwidth allocation value refers to the bandwidth quota allocated to network nodes (such as servers and routers) for data transmission, calculated using the above formula based on the relevant parameters of the hierarchical load queue (such as load level and weight). The unit is usually Mbps (megabits per second) to ensure that the node can transmit data normally under the corresponding load conditions and avoid congestion or resource waste.

[0098] As an embodiment of the present invention, the calculating of the bandwidth allocation value corresponding to the hierarchical load queue includes:

[0099] The bandwidth allocation value corresponding to the hierarchical load queue is calculated using the following formula:

[0100] ;

[0101] in, Indicates the bandwidth allocation value corresponding to the hierarchical load queue, Indicates the total number of levels corresponding to the hierarchical load queue, Indicates the level index corresponding to the hierarchical load queue, represents the priority weight of the i-th level load, represents the normalized load value of the i-th level load, and Respectively represent the start time and end time of the bandwidth calculation period, represents the cumulative load of the target node in the hierarchical load queue during the bandwidth calculation period, Indicates the maximum load value in the hierarchical load queue. Indicates the minimum load value in the hierarchical load queue.

[0102] In detail, the priority weight refers to a value used to measure the importance of different levels of load in the hierarchical load queue, and the value range is generally (0,1]. The higher the weight, the higher the priority and more urgent the resource demand of the corresponding level of load. For example, in the IPTV service, the priority weight of the live service load can be set higher than the ordinary video on demand service load to ensure the smoothness of the live broadcast; the normalized load value refers to mapping the actual load of the node (such as bandwidth occupancy, number of concurrent connections, etc.) to a value in the range of [0,1] through a certain calculation method. For example, the load value of a node with a bandwidth occupancy of 80% is normalized to 0.8; the bandwidth calculation period refers to the time interval selected for calculating the node bandwidth allocation value, which is from the start time and end time The time period can be flexibly set according to actual needs, such as hourly or daily statistics, to count the load of the node in this time period and provide a basis for bandwidth allocation; the cumulative load refers to the cumulative value of the load of the target node at each time point (such as bandwidth occupancy rate) during the bandwidth calculation period, which is generally calculated by the time interval [ , ]Internal load variation function over time It is obtained by performing an integral operation, which reflects the total load pressure of the node during the period; the maximum load value refers to the maximum value of the normalized load values ​​corresponding to all levels of load in the hierarchical load queue, which represents the heaviest load in the current load queue and can be used to measure the load difference; the minimum load value refers to the minimum value of the normalized load values ​​corresponding to all levels of load in the hierarchical load queue, which is relative to the maximum load value and is used to reflect the lowest load level in the load queue.

[0103] Furthermore, the present invention detects traffic anomalies in the target IPTV server based on the bandwidth allocation value, can promptly discover situations where actual traffic does not match the allocated bandwidth, quickly locate problems such as congestion caused by a sudden increase in traffic or idle resources caused by a sudden decrease in traffic, effectively identify the source of abnormal traffic, and facilitate the investigation of hidden dangers such as malicious attacks or software failures.

[0104] Among them, the traffic anomaly point refers to the time point or data segment when the instantaneous transmission rate deviates significantly from the dynamic threshold baseline, which may be caused by network attacks, equipment failures or sudden traffic. For example, if the traffic in a period suddenly soars to 25Mbps (exceeding the threshold baseline of 14Mbps), analysis shows that it is caused by a large number of live stream requests from malicious crawlers. This time point is marked as a traffic anomaly point.

[0105] As an embodiment of the present invention, detecting traffic anomalies in the target IPTV server based on the bandwidth allocation value includes: parsing bandwidth traffic packets corresponding to the bandwidth allocation value; extracting peak-valley fluctuation data corresponding to transmission units in the target IPTV server based on the bandwidth traffic packets; determining a dynamic threshold baseline corresponding to the peak-valley fluctuation data; analyzing the instantaneous transmission rate of the traffic units in the target IPTV server based on the dynamic threshold baseline; and determining traffic anomalies in the target IPTV server based on the instantaneous transmission rate.

[0106] The bandwidth traffic packet refers to a collection of network data packets that carry IPTV data streams, including data units such as video frames, audio streams, and control signaling. Its size and transmission frequency directly affect the bandwidth allocation value. For example, if the bandwidth traffic packet for a 4K live channel consists of 25 video GOPs (Groups of Pictures) per second and related RTSP control packets, each GOP is approximately 1.2MB in size. The transmission unit refers to the smallest data unit in the IPTV data stream that can be independently transmitted and scheduled, typically corresponding to an audio or video clip within a specific time window. For example, a transmission unit may contain 1 second of video data (approximately 5-10MB) and a synchronized audio stream, encapsulated as a continuous sequence of data packets via the RTP protocol. The peak-valley fluctuation data refers to the bandwidth usage variation curve of the transmission unit over a time series, reflecting the dynamic fluctuation characteristics of traffic. For example, the bandwidth peak at the moment of a goal in a live sports event can reach 15Mbps, while it drops to 3Mbps during commercial breaks. This alternating high and low fluctuations form peak-valley data. The dynamic threshold baseline refers to an anomaly detection baseline that is adaptively adjusted based on historical traffic data and the current bandwidth allocation value and is dynamically updated as network load changes. For example, the historical traffic mean of a server is 8Mbps and the standard deviation is 2Mbps. The dynamic threshold baseline can be set to the mean plus 3 times the standard deviation (14Mbps). Any value exceeding this value is considered an anomaly. The traffic unit refers to a continuous data stream transmitted at a specific time point or time period, which can be regarded as a collection of transmission units. For example, a traffic unit can contain all video frames and audio packets within 5 seconds, with a total size of approximately 50MB, which is used to evaluate traffic bursts in a short period of time. The instantaneous transmission rate refers to the real-time data transmission speed of the traffic unit at a certain moment, usually in Mbps. For example, if the instantaneous rate of video key frame transmission can reach 20Mbps, while the ordinary P frame transmission rate is about 5Mbps, anomalies can be quickly identified by comparing the instantaneous rate with the threshold baseline.

[0107] Furthermore, the analysis of the bandwidth traffic packets corresponding to the bandwidth allocation value can be implemented by a network protocol analysis tool, such as: using Wireshark to capture TCP / IP data packets, extracting the DSCP field and payload size through the tshark command line tool, and generating a bandwidth traffic packet containing a QoS mark; the extraction of the peak-valley fluctuation data corresponding to the transmission unit in the target IPTV server can be implemented by a time series analysis tool, such as: using Pandas' rolling function to calculate the bandwidth range within a 5-minute sliding window, combining Matplotlib to draw a bandwidth fluctuation curve, and outputting a peak-valley difference sequence; the determination of the dynamic threshold baseline corresponding to the peak-valley fluctuation data can be implemented by a statistical modeling method, such as: applying the Facebook Prophet algorithm to seasonally decompose historical fluctuation data to generate a dynamic baseline threshold containing a confidence interval; the analysis of the instantaneous transmission rate of the traffic unit in the target IPTV server can be implemented by a streaming computing framework, such as: calculating the number of bytes per second in real time based on Apache Flink's window function, and outputting a timestamp-containing instantaneous rate sequence; the determination of traffic anomalies in the target IPTV server can be implemented by an anomaly detection algorithm, such as: using Isolation The Forest model performs unsupervised learning on the rate sequence and marks data points with a deviation exceeding 3σ as traffic anomalies.

[0108] S4. Determine the congested area corresponding to the traffic anomaly point, mark the congested area with a speed limit, obtain an area control label, perform protocol analysis on the area control label to obtain protocol analysis data, and calculate a conflict threshold corresponding to the protocol analysis data.

[0109] By determining the congested area corresponding to the traffic anomaly point, the present invention helps to analyze the cause of congestion, such as insufficient equipment performance, link failure or traffic burst, and provides a basis for subsequent optimization. It can also assist in the rational planning of network resources, expand or adjust the configuration of congested areas in advance, and improve the overall reliability and stability of the IPTV network.

[0110] Among them, the congested area refers to a specific range area in the IPTV network where data transmission is blocked and network performance is degraded due to traffic abnormalities (such as sudden traffic growth, excessive transmission rate), which covers several servers, partial links, or a subnet composed of multiple nodes and their connections. For example, when the instantaneous traffic of an individual edge server far exceeds the processing capacity, a congested area is formed in the range of the surrounding switches and links connected to it, and phenomena such as video freeze and slow loading will occur. Optionally, the determination of the congested area corresponding to the traffic anomaly point can be achieved through a network topology analysis tool, such as: combining the Gephi visualization tool to perform a graph analysis on the connection relationship of the network nodes where the anomaly point is located, and identifying a cluster of high-density connected devices as a congested area.

[0111] Furthermore, the present invention obtains a regional control label by marking the congested area with a speed limit, which can quickly alleviate local network pressure by limiting the transmission rate of abnormal traffic, prevent congestion from spreading to core links, and provide a clear routing avoidance signal for the traffic scheduling system, guiding subsequent data flows to detour to low-load paths, thereby improving overall transmission efficiency.

[0112] The regional control label refers to a metadata tag that carries the speed limit level, boundary range, and protocol rules of the congested area, and is used to notify upstream nodes to adjust traffic scheduling strategies. For example, the label content can be expressed as "[Area ID: EDGE-01, Speed ​​Limit Level: Medium, Boundary Port: GE0 / 1, Protocol Rule: DSCP=AF41, Speed ​​Limit Value: 9Mbps]", so that core routers can identify and bypass the area.

[0113] As an embodiment of the present invention, the speed limit marking of the congested area to obtain the regional control label includes: extracting traffic peak data in the congested area; dividing the dynamic speed limit level corresponding to the congested area according to the traffic peak data; matching the protocol speed limit rules corresponding to the dynamic speed limit level; based on the protocol speed limit rules, marking the congestion boundary corresponding to the congested area; and speed limit marking the congested area according to the congestion boundary to obtain the regional control label.

[0114] The traffic peak data refers to the maximum data transmission rate (such as Mbps) and duration of the congested area during the abnormal period, reflecting the intensity and duration of the traffic burst. For example, if the edge server reaches a peak rate of 22Mbps during the period of 20:00-20:05 (normal threshold 15Mbps), the peak value of this period and the record lasting 5 minutes are the traffic peak data; the dynamic speed limit level refers to the speed limit requirements of the congested area divided into different levels (such as light, medium, and heavy speed limit) according to the degree of deviation between the traffic peak data and the normal threshold. For example, if the peak exceeds the threshold by 30%, it is classified as light speed limit (speed limit to 110% of the threshold), if it exceeds 50%, it is moderate (speed limit to 90% of the threshold), and if it exceeds 80%, it is heavy (speed limit to 70% of the threshold); the protocol speed limit rule refers to the speed limit of the network protocol (such as IP Specific rules for implementing traffic rate limiting based on the DiffServ protocol (such as precedence or DiffServ) or device configuration (such as QoS policies) include rate limit thresholds, priority adjustment, and traffic drop policies. For example, based on the DiffServ protocol, the DSCP marking of non-critical traffic (such as standard-definition video streams) in a congested area can be set to EF, and its rate can be limited to no more than 5 Mbps. The congestion boundary refers to the logical or physical boundary between congested and non-congested areas in the network topology, usually measured in router interfaces, switch ports, or IP network segments. For example, if a congested area consists of three edge servers and the aggregation switch connected to them, the boundary is the uplink port of the aggregation switch, and the rate limit rule applies only to traffic within that port.

[0115] Furthermore, the extraction of traffic peak data in the congested area can be achieved through a time series analysis tool, such as: using the SELECT MAX() query statement of InfluxDB to obtain the historical peak traffic of each node in the congested area, and drawing a peak distribution heat map in combination with Grafana to extract key peak data; the division of the dynamic speed limit level corresponding to the congested area can be achieved through an adaptive clustering algorithm, such as: applying the OPTICS density clustering algorithm to automatically divide the three speed limit level intervals of heavy / medium / light according to the peak data distribution characteristics; the matching of the protocol speed limit rules corresponding to the dynamic speed limit level can be achieved through a rule engine, such as: configuring QoS policies based on the Drools rule engine (such as heavy speed limit TCP 50%, UDP 80%, medium speed limit TCP 30%, etc.) to generate a differentiated protocol speed limit rule set; the marking of the congestion boundary corresponding to the congested area can be achieved through a network topology analysis tool, such as: analyzing the node connectivity through the Cytoscape.js visualization library, identifying the BGP AS number of the border router to divide the logical congestion boundary; the speed limit marking of the congested area can be achieved through an SDN controller, such as: using the Flow of the OpenFlow protocol The Mod message adds a DSCP rate limit mark to the edge switch port to generate a recognizable zone control label.

[0116] The present invention performs protocol analysis on the regional control tags to obtain protocol analysis data, which can deeply interpret the rate limit rules and topology information (such as DiffServ tags and boundary ports) carried by the tags, ensuring the compatibility of rate limit policies between different protocol layers, thereby improving the control efficiency and stability of IPTV networks in complex protocol environments.

[0117] The protocol analysis data refers to the quantitative results of the label structure, rate limit rule parameters, topology location information, and protocol execution status extracted by parsing the protocol fields of the regional control label (such as the DSCP value, QoS policy parameters, and boundary port identifier in the IP header). For example, the following data is parsed from the label "[DSCP=AF41, port=GE0 / 1, rate limit value=9Mbps]": the protocol type is DiffServ, the priority tag AF41 corresponds to the medium rate limit level, the active port is GE0 / 1, and the consistency status of the actual rate limit value with the rule configuration (such as whether there is an error within 5%). This data is used to evaluate the effectiveness of the rate limit policy and protocol compatibility. Optionally, the protocol analysis of the regional control label can be implemented using a network protocol parsing tool, such as using Wireshark to capture data packets carrying DSCP marks and using the TShark command-line tool to extract the QoS field, protocol type, and rate limit policy parameters to generate structured protocol analysis data.

[0118] Furthermore, the present invention can quantify the potential conflict risks in the execution of protocol rules by calculating the conflict threshold corresponding to the protocol analysis data, and quickly identify policy conflict points and issue warnings by setting reasonable thresholds (such as priority mark difference critical values), thereby ensuring the coordinated consistency and execution efficiency of regional control strategies in the IPTV system.

[0119] Among them, the conflict threshold refers to a quantitative indicator used to determine whether there is a conflict risk in the parameter configuration of the protocol analysis data. When the relevant calculated value exceeds the threshold, it means that there is a conflict in the protocol parameter configuration, and further investigation and adjustment are required to ensure normal data transmission and business operation in the network.

[0120] As an embodiment of the present invention, the calculating the conflict threshold corresponding to the protocol analysis data includes:

[0121] The conflict threshold corresponding to the protocol analysis data is calculated using the following formula:

[0122] ;

[0123] in, represents the conflict threshold corresponding to the protocol analysis data, represents the current parameter vector corresponding to the protocol analysis data, represents the reference parameter vector, Indicates the total number of data items corresponding to the protocol analysis data, Indicates the data item index corresponding to the protocol analysis data, Indicates the The conflict-sensitive weights corresponding to the data items are Indicates the load fluctuation coefficient, Indicates the end time of the load analysis period, represents the load change rate at time t, Indicates the average load during the load analysis period. represents the historical conflict factor, Indicates the number of historical conflicts, Indicates the conflict statistics period.

[0124] In detail, the current parameter vector refers to a vector composed of various parameter values ​​currently measured in the protocol analysis data. For example, when analyzing the IPTV network protocol, it may include multiple parameters such as DSCP value, rate limit value, TTL value, etc., in the form of vector P=[ , ,..., ] indicates that it is used to reflect the actual status of the current protocol parameters; the reference parameter vector refers to a pre-set parameter vector that is considered to be normal or standard, which can be determined based on network design specifications, parameter values ​​under historical good operating conditions, etc., in the form of =[ , ,..., ], as a comparison benchmark to measure whether the current parameter vector deviates from the normal range; the conflict sensitivity weight refers to a weight value set for each data item (parameter) in the protocol analysis data, reflecting the sensitivity and influence of the parameter to the occurrence of conflicts, and the value range is generally [0,1]. Parameters with high sensitivity (such as traffic priority and key routing related parameters) have weights closer to 1, and vice versa. The load fluctuation coefficient refers to a dimensionless coefficient, and the value range is usually [0,1], which is used to measure the influence of load fluctuations on the risk of protocol conflicts. The larger the coefficient, the higher the weight of load fluctuations in calculating the conflict threshold, that is, the more likely load fluctuations are to cause changes in the assessment of conflict risks; the load analysis period refers to the time interval selected for calculating load-related indicators (such as load change rate, average load), from the start time to the end time T. This time period can be set according to the actual network monitoring and analysis needs, such as by hour, by day, etc., to count the dynamic changes of network load within the period; the load change rate refers to the load change at a certain moment. The speed of change of network load (such as bandwidth occupancy, data flow rate, etc.) is usually expressed by the change in load per unit time, which is a function that changes with time. , reflects the instantaneous fluctuation characteristics of the network load at that moment; the historical conflict factor refers to the degree of influence of historical conflict situations on the calculation of the current conflict threshold. The larger the factor, the higher the weight of historical conflict situations in calculating the current conflict threshold, that is, the more attention is paid to the effect of the frequency and status of historical conflicts on the current risk assessment; the number of historical conflicts refers to the number of historical conflicts in a certain statistical period in the past (duration The cumulative number of conflicts in the protocol parameter configuration in the network within a certain period of time is a statistical value used to measure the frequency of protocol conflicts in the network within a certain period of time. The conflict statistical period refers to the length of time used to count the number of historical conflicts. Indicates, for example, statistics for the past week ( =7×24×3600 seconds). The duration of one week is the conflict statistics period.

[0125] S5. Based on the conflict threshold, identify redundant parameters in the protocol analysis data, perform management and control optimization on the redundant parameters and preset QoS standards to obtain management and control optimization parameters, and formulate a multicast management and control policy corresponding to the target IPTV server based on the protocol analysis data.

[0126] The present invention identifies redundant parameters in the protocol analysis data based on the conflict threshold, can accurately locate parameters that have no substantial impact or minimal impact on the conflict risk, avoid invalid configuration interference, simplify protocol rules, and enhance network stability and reliability.

[0127] Among them, the redundant parameters refer to parameters in the protocol analysis data that have no actual contribution to the implementation of protocol functions, or that increase complexity and cause conflicts. For example, in some network traffic control protocols, multiple repeated traffic priority parameters are set, and the redundant parts are redundant parameters. Removing them can optimize the protocol configuration and reduce the possibility of conflicts.

[0128] As an embodiment of the present invention, identifying redundant parameters in the protocol analysis data based on the conflict threshold includes: analyzing a threshold baseline corresponding to the conflict threshold; conflict marking the protocol analysis data based on the threshold baseline to obtain a marked data set; screening redundant nodes in the marked data set; and identifying redundant parameters in the protocol analysis data based on the redundant nodes.

[0129] The threshold baseline refers to a reference standard line determined based on historical data, network normal operation indicators, etc., used to measure the rationality of the conflict threshold. It is a quantitative value. For example, the conflict thresholds during normal network operation over the past month are calculated and the average value is taken as the threshold baseline. If the current conflict threshold is much higher than this line, it indicates that there is a risk of parameter conflict. The marked data set refers to a collection of conflict-marked data (such as conflict, potential conflict, and no conflict) after the protocol analysis data is conflict-marked. For example, when analyzing IPTV network protocol data, each parameter group is marked with a corresponding conflict status based on the comparison results with the threshold baseline. These marked parameter groups together constitute the marked data set. The redundant nodes refer to nodes in the marked data set that have no substantial effect on the normal operation of the protocol or that perform duplicate functions, increasing the risk of conflict. For example, in a network routing protocol configuration, if there are two routing configuration nodes with exactly the same functions, one of them may be a redundant node, which not only consumes resources but can also cause conflicts due to configuration differences.

[0130] Furthermore, the analysis of the threshold baseline corresponding to the conflict threshold can be achieved through a statistical modeling method, such as: using the Facebook Prophet time series prediction model to perform seasonal decomposition on historical threshold data to generate a dynamic baseline containing a confidence interval; the conflict marking of the protocol analysis data can be achieved through a rule engine, such as: configuring protocol conflict detection rules (such as TCP / UDP rate mismatch, QoS marking conflict, etc.) based on the Drools rule engine, and outputting a data set with conflict markings; the screening of redundant nodes in the marked data set can be achieved through a graph theory algorithm, such as: applying the PageRank algorithm to calculate the importance score of the network node, and screening out redundant nodes with a connectivity lower than the threshold and no critical business; the identification of redundant parameters in the protocol analysis data can be achieved through a feature selection method, such as: using Scikit-learn's SelectKBest algorithm based on the chi-square test to identify protocol parameters with low contribution to traffic classification.

[0131] The present invention optimizes the management and control of the redundant parameters and the preset QoS standards to obtain the management and control optimization parameters, which can accurately allocate network resources, avoid resource waste due to parameter redundancy, and improve resource utilization; it can also simplify network management, reduce operation and maintenance complexity, quickly locate and solve network performance problems, and enhance network stability.

[0132] The preset QoS standard refers to a series of pre-set indicators and specifications used to measure and ensure network service quality, which covers specific thresholds and requirements for parameters such as bandwidth, latency, jitter, and packet loss rate. For example, for IPTV high-definition video services, the preset QoS standard stipulates that the bandwidth must be no less than 5 Mbps, the latency must be less than 100 ms, and the packet loss rate must be less than 1%. This ensures smooth video playback and clear images, meeting user experience requirements. The control optimization parameters refer to parameters obtained by processing redundant parameters and adjusting and optimizing them according to the preset QoS standard. These parameters can make network protocol configuration more reasonable and efficient, and ensure network service quality. For example, after eliminating redundant flow control parameters, appropriate rate limit parameters can be reset according to the bandwidth requirements in the QoS standard, so as to make network resource allocation more scientific, reduce conflict risks, and improve overall network performance. Optionally, the control optimization of the redundant parameters and the preset QoS standard can be implemented through a parameter optimization framework, such as using the TensorFlow optimizer module to perform gradient descent calculations on the redundant parameters, minimize the parameter dimensions while meeting the minimum bandwidth guarantee condition, and ultimately obtain the control optimization parameters.

[0133] Furthermore, the present invention formulates a multicast control strategy corresponding to the target IPTV server based on the protocol analysis data. By parsing protocol parameters (such as IGMP group address and PIM hello interval), it can accurately match multicast traffic characteristics, dynamically optimize the forwarding tree structure and bandwidth quota, reduce cross-segment forwarding delay, and improve live streaming transmission efficiency.

[0134] The multicast control policy refers to a set of traffic scheduling and resource management rules formulated based on the multicast service characteristics of the target IPTV server through protocol analysis data (such as IGMPv3 membership reports, PIM-SM signaling parameters, and multicast stream bandwidth distribution). Its contents include but are not limited to: multicast group address planning, forwarding tree construction strategy (such as SPT / RPT switching threshold), bandwidth quota allocation (such as the maximum allowed rate for each multicast group), QoS priority marking (such as allocating DSCP=46 for 4K live multicast streams), membership aging time configuration (such as setting the IGMP leave delay to 10 seconds), etc. For example, If the number of multicast group users in the policy exceeds 500, the forwarding tree is automatically switched to the shortest path tree (SPT), and 10Mbps dedicated bandwidth is allocated to the group flow. At the same time, the optimal forwarder is elected through the PIM assertion mechanism to avoid loops and bandwidth waste. This strategy aims to optimize multicast transmission efficiency, ensure service quality, and reduce network resource consumption. Optionally, the formulation of the multicast control policy corresponding to the target IPTV server can be implemented through a policy orchestration framework, such as using the ONAP policy engine to automatically generate rules including bandwidth reservation and multicast tree optimization based on network topology and QoS requirements, and finally obtain the multicast control policy.

[0135] Compared to the problems described in the background art, the Internet multicast protocol-driven IPTV server control method and system provided in the embodiments of the present invention can improve the resource scheduling efficiency of the IPTV server. The Internet multicast protocol-driven IPTV server control method and system provided in the embodiments of the present invention can improve the resource scheduling efficiency of the IPTV server.

[0136] Example 2:

[0137] like Figure 3 FIG. 1 is a functional module diagram of an Internet multicast protocol-driven IPTV server control system according to the present invention.

[0138] The Internet multicast protocol-driven IPTV server management and control system 200 described in the present invention can be installed in an electronic device. Depending on the functionality implemented, the system can include a node identification module 201, a framework construction module 202, an outlier detection module 203, a threshold calculation module 204, and a policy formulation module 205. A module, also referred to as a unit, is a series of computer program segments that can be executed by an electronic device processor and perform a fixed function. These modules are stored in the electronic device's memory.

[0139] In the embodiment of the present invention, the functions of each module / unit are as follows:

[0140] The node identification module 201 is used to obtain a multicast data stream corresponding to a target IPTV server, perform protocol analysis on the multicast data stream to obtain multicast protocol features, and identify multicast nodes in the multicast data stream based on the multicast protocol features;

[0141] The framework construction module 202 is configured to perform traffic slicing on the multicast data stream based on the multicast node to obtain slicing traffic units, and to construct a traffic on-demand framework corresponding to the target IPTV server based on the slicing traffic units;

[0142] The anomaly detection module 203 is configured to extract traffic load data from the traffic on-demand framework, perform hierarchical marking on the traffic load data to obtain hierarchical load queues, calculate bandwidth allocation values ​​corresponding to the hierarchical load queues, and detect traffic anomalies in the target IPTV server based on the bandwidth allocation values;

[0143] The threshold calculation module 204 is used to determine the congested area corresponding to the traffic anomaly point, mark the congested area with a speed limit, obtain an area control label, perform protocol analysis on the area control label to obtain protocol analysis data, and calculate the conflict threshold corresponding to the protocol analysis data;

[0144] The policy formulation module 205 is used to identify redundant parameters in the protocol analysis data based on the conflict threshold, optimize the redundant parameters and the preset QoS standards, obtain the control optimization parameters, and formulate the multicast control policy corresponding to the target IPTV server based on the protocol analysis data.

[0145] In detail, the modules in the Internet multicast protocol driven IPTV server control system 200 in the embodiment of the present invention are used in the same manner as above. Figure 1 The same technical means are used as the Internet multicast protocol driven IPTV server control method described in , and can produce the same technical effects, so they will not be repeated here.

[0146] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0147] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. An IPTV server management and control method driven by an Internet multicast protocol, characterized in that: The method comprises: Obtaining a multicast data stream corresponding to a target IPTV server, performing protocol parsing on the multicast data stream to obtain multicast protocol features, and identifying a multicast node in the multicast data stream based on the multicast protocol features; Based on the multicast node, the multicast data stream is traffic sliced ​​to obtain sliced ​​traffic units, and based on the sliced ​​traffic units, a traffic on-demand framework corresponding to the target IPTV server is constructed; Extracting traffic load data from the traffic on-demand framework, performing hierarchical marking on the traffic load data to obtain hierarchical load queues, and calculating bandwidth allocation values ​​corresponding to the hierarchical load queues, wherein calculating the bandwidth allocation values ​​corresponding to the hierarchical load queues includes: The bandwidth allocation value corresponding to the hierarchical load queue is calculated using the following formula: ； in, Indicates the bandwidth allocation value corresponding to the hierarchical load queue, Indicates the total number of levels corresponding to the hierarchical load queue, Indicates the level index corresponding to the hierarchical load queue, represents the priority weight of the i-th level load, represents the normalized load value of the i-th level load, and Respectively represent the start time and end time of the bandwidth calculation period, represents the cumulative load of the target node in the hierarchical load queue during the bandwidth calculation period, Indicates the maximum load value in the hierarchical load queue. Indicates the minimum load value in the hierarchical load queue, and detects traffic anomalies in the target IPTV server based on the bandwidth allocation value; Determine a congestion area corresponding to the traffic anomaly point, mark the congestion area with a speed limit, obtain an area control label, perform protocol analysis on the area control label to obtain protocol analysis data, and calculate a conflict threshold corresponding to the protocol analysis data, wherein calculating the conflict threshold corresponding to the protocol analysis data includes: The conflict threshold corresponding to the protocol analysis data is calculated using the following formula: ； in, represents the conflict threshold corresponding to the protocol analysis data, represents the current parameter vector corresponding to the protocol analysis data, represents the reference parameter vector, Indicates the total number of data items corresponding to the protocol analysis data, Indicates the data item index corresponding to the protocol analysis data, Indicates the The conflict-sensitive weights corresponding to the data items are Indicates the load fluctuation coefficient, Indicates the end time of the load analysis period, represents the load change rate at time t, Indicates the average load during the load analysis period. represents the historical conflict factor, Indicates the number of historical conflicts, Indicates the conflict statistics period; Based on the conflict threshold, redundant parameters in the protocol analysis data are identified, the redundant parameters are managed and optimized with preset QoS standards to obtain management and control optimization parameters, and based on the protocol analysis data, a multicast management and control strategy corresponding to the target IPTV server is formulated.

2. The method for controlling an IPTV server driven by an Internet multicast protocol as claimed in claim 1, wherein: The identifying the multicast node in the multicast data stream based on the multicast protocol feature includes: Parsing the protocol fields in the multicast protocol; Based on the protocol field, traverse the node routing table in the preset topology database; Extracting the time series communication records of active nodes in the node routing table; Filtering candidate recording points in the time series communication record; Based on the candidate recording points, a multicast node in the multicast data stream is identified.

3. The Internet multicast protocol driven IPTV server management and control method according to claim 1, wherein: The method of performing traffic slicing on the multicast data stream based on the multicast node to obtain a slicing traffic unit includes: Querying a multicast traffic sequence corresponding to the multicast data stream; extracting a traffic sequence vector from the multicast traffic sequence; Dividing the dynamic fragmentation interval corresponding to the traffic sequence vector; Identifying a sharding granularity in the dynamic sharding interval; Based on the fragmentation granularity, traffic fragmentation is performed on the multicast data stream to obtain fragmented traffic units.

4. The method for controlling an IPTV server driven by an Internet multicast protocol as claimed in claim 1, wherein: The method of constructing a traffic on-demand framework corresponding to the target IPTV server based on the fragmented traffic unit includes: Analyze the traffic peak and time period distribution in the sharded traffic unit; Fitting a flow fluctuation curve corresponding to the flow peak value and the time period distribution; Extracting the time period load segment and the buffer zone segment in the flow fluctuation curve; Dynamically divide the node resource pool corresponding to the target IPTV server based on the time period load threshold; Based on the buffer interval and the node resource pool, a traffic on-demand framework corresponding to the target IPTV server is constructed.

5. The method for controlling an IPTV server driven by an Internet multicast protocol according to claim 1, wherein: The detecting, based on the bandwidth allocation value, traffic anomalies in the target IPTV server includes: Parsing the bandwidth flow packet corresponding to the bandwidth allocation value; Extracting peak-valley fluctuation data corresponding to a transmission unit in the target IPTV server based on the bandwidth traffic packet; Determining a dynamic threshold baseline corresponding to the peak-to-valley fluctuation data; Analyzing the instantaneous transmission rate of traffic units in the target IPTV server according to the dynamic threshold baseline; Based on the instantaneous transmission rate, a traffic abnormality point in the target IPTV server is determined.

6. The method for controlling an IPTV server driven by an Internet multicast protocol according to claim 1, wherein: The step of marking the congested area with a speed limit to obtain an area control label includes: Extracting traffic peak data in the congested area; According to the traffic peak data, the congestion area is divided into dynamic speed limit levels corresponding to the congestion area; Match the protocol speed limit rules corresponding to the dynamic speed limit level; Based on the protocol rate limit rule, marking the congestion boundary corresponding to the congested area; According to the congestion boundary, the congested area is marked with a speed limit to obtain an area control label.

7. The method for controlling an IPTV server driven by an Internet multicast protocol according to claim 1, wherein: The identifying redundant parameters in the protocol analysis data based on the conflict threshold comprises: Analyzing a threshold baseline corresponding to the conflict threshold; Based on the threshold baseline, conflict marking is performed on the protocol analysis data to obtain a marked data set; Filtering redundant nodes in the labeled data set; Based on the redundant nodes, redundant parameters in the protocol analysis data are identified.

8. An Internet multicast protocol-driven IPTV server management and control system, applied to the Internet multicast protocol-driven IPTV server management and control method according to claim 1: a node identification module configured to obtain a multicast data stream corresponding to a target IPTV server, perform protocol analysis on the multicast data stream to obtain multicast protocol features, and identify multicast nodes in the multicast data stream based on the multicast protocol features; A framework construction module is used to perform traffic slicing on the multicast data stream based on the multicast node to obtain slicing traffic units, and to construct a traffic on-demand framework corresponding to the target IPTV server based on the slicing traffic units; The outlier detection module is configured to extract traffic load data from the traffic on-demand framework, perform hierarchical marking on the traffic load data to obtain hierarchical load queues, and calculate bandwidth allocation values ​​corresponding to the hierarchical load queues, wherein calculating the bandwidth allocation values ​​corresponding to the hierarchical load queues includes: The bandwidth allocation value corresponding to the hierarchical load queue is calculated using the following formula: ； in, Indicates the bandwidth allocation value corresponding to the hierarchical load queue, Indicates the total number of levels corresponding to the hierarchical load queue, Indicates the level index corresponding to the hierarchical load queue, represents the priority weight of the i-th level load, represents the normalized load value of the i-th level load, and Respectively represent the start time and end time of the bandwidth calculation period, represents the cumulative load of the target node in the hierarchical load queue during the bandwidth calculation period, Indicates the maximum load value in the hierarchical load queue. Indicates the minimum load value in the hierarchical load queue, and detects traffic anomalies in the target IPTV server based on the bandwidth allocation value; A threshold calculation module is configured to determine a congested area corresponding to the traffic anomaly point, mark the congested area with a speed limit, obtain an area control label, perform protocol analysis on the area control label to obtain protocol analysis data, and calculate a conflict threshold corresponding to the protocol analysis data, wherein calculating the conflict threshold corresponding to the protocol analysis data includes: The conflict threshold corresponding to the protocol analysis data is calculated using the following formula: ； in, represents the conflict threshold corresponding to the protocol analysis data, represents the current parameter vector corresponding to the protocol analysis data, represents the reference parameter vector, Indicates the total number of data items corresponding to the protocol analysis data, Indicates the data item index corresponding to the protocol analysis data, Indicates the The conflict-sensitive weights corresponding to the data items are Indicates the load fluctuation coefficient, Indicates the end time of the load analysis period, represents the load change rate at time t, Indicates the average load during the load analysis period. represents the historical conflict factor, Indicates the number of historical conflicts, Indicates the conflict statistics period; A policy formulation module is used to identify redundant parameters in the protocol analysis data based on the conflict threshold, optimize the management and control of the redundant parameters and the preset QoS standards, obtain management and control optimization parameters, and formulate a multicast management and control policy corresponding to the target IPTV server based on the protocol analysis data.

Images