A high-performance RTP voice acceleration acquisition method and system based on FPGA implementation

Abstract

This application relates to the field of network voice acquisition technology, and discloses a high-performance RTP voice acceleration acquisition method and system based on FPGA implementation. The method includes receiving raw IP packets and parsing them to obtain a set of key packet information containing five-tuple information, service type identifiers, and policy matching results; filtering out matching RTP voice packets and extracting the five-tuple information; and accessing the flow table in the first DDR4 memory through a multi-BANK interleaved parallel read / write engine to complete the query. When a flow table entry is empty, a table is created for the five-tuple flow, and a storage token corresponding to the second DDR4 storage address is requested. When a flow table entry matches, the timestamp is updated and the storage address is determined. Then, the RTP payload is extracted, written to the corresponding space, and counted. When the count reaches a threshold, an RTP voice compression frame is assembled and output. If the flow duration times out, the storage token is revoked; if the flow table entry times out, the flow table entry is revoked. This invention improves the rate of RTP voice acquisition and storage resource utilization, adapts to high-volume voice acquisition scenarios, and reduces server processing load.

Description

Technical Field

[0001] This application relates to the field of network voice acquisition technology, specifically a high-performance RTP voice acceleration acquisition method and system based on FPGA implementation. Background Technology

[0002] In the field of voice service monitoring of traditional 2G / 3G networks, advanced 4G / 5G networks, and NGN softswitches in fixed-line networks of telecom operators, a common approach is to use an Ethernet network card paired with an X86 server to collect voice media streams based on the Real-time Transport Protocol (RTP). This approach uses the network card to send all received packets to the X86 server memory in the DPDK manner, where the CPU directly completes all processing.

[0003] RTP voice messages are small messages of 100-200 bytes. However, the CPU of a general-purpose x86 server processes messages of different sizes at a basically consistent rate. When faced with large RTP voice streams of 100G or more, the CPU processing performance drops sharply, the single-machine processing capacity is limited, it is difficult to achieve synchronous collection of all voice calls across the entire network, and the system coverage is insufficient.

[0004] Meanwhile, the existing data acquisition scheme lacks a targeted traffic filtering and compression mechanism, requiring all packets to be transmitted completely to the server. This not only wastes the transmission bandwidth between the data acquisition network card and the x86 server, but also significantly increases the CPU's processing load, further reducing the overall system processing efficiency.

[0005] In addition, the traditional solution has an unreasonable resource allocation between flow table management and voice data storage. The flow table storage capacity and the voice compression frame buffer capacity are far apart, which easily leads to low storage resource utilization. It cannot support the stable collection of tens of millions of concurrent RTP streams and cannot meet the collection needs of large-scale voice services of telecom operators. Summary of the Invention

[0006] The purpose of this application is to provide a high-performance RTP voice acceleration acquisition method and system based on FPGA to solve the problems mentioned in the background art.

[0007] According to the first aspect of this application, a high-performance RTP voice acceleration acquisition method based on FPGA is provided, comprising the following steps:

[0008] Receive raw IP packets and parse them to obtain a set of key information about the packets, including five-tuple information, service type identifier, and policy matching results;

[0009] If the service type is identified as an RTP voice message and the policy matching result is a match, then extract the quintuple information from the message key information set;

[0010] The flow table is queried based on the quintuple information. The flow table is stored in the first DDR4 memory and accessed through a multi-BANK interleaved parallel read / write engine.

[0011] If the flow table entry corresponding to the five-tuple information is found to be empty, a flow table entry is created for the current five-tuple flow, and a storage token is requested. The identifier of the storage token is written into the flow table entry. The storage token corresponds to a continuous storage address in the second DDR4 memory.

[0012] If the flow table entry is found to be non-empty and the 5-tuple information in the flow table entry is consistent with the 5-tuple information of the current packet, then the timestamp information in the flow table entry is updated, and the storage address is determined according to the storage token identifier in the flow table entry.

[0013] Extract the RTP payload from the RTP voice message, write the RTP payload into the second DDR4 storage space corresponding to the storage address, and update the number of RTP payloads written to the current 5-tuple stream.

[0014] When the number of written RTP payloads reaches a preset threshold N, N RTP payloads are read from the second DDR4 storage space, assembled into an RTP voice compression frame and output, where N>1;

[0015] The flow duration and the arrival time of the last RTP packet in the flow table entry are obtained. If the flow duration exceeds a preset time threshold, the corresponding storage token is revoked; if the flow table entry times out, the flow table entry is revoked.

[0016] Preferably, the multi-BANK interleaved parallel read / write engine includes multiple independent read / write engines, each corresponding to a BANK of the first DDR4 memory; a hash value is generated based on the quintuple information, and the hash value is modulo the number of BANKs to determine the BANK number to be accessed.

[0017] Preferably, the storage token is allocated from the idle token pool; when the storage token is reclaimed, the storage token is marked as idle and returned to the idle token pool; the identifier of the storage token is pre-associated with the starting address and length of the second DDR4 storage space.

[0018] Preferably, when creating a flow table entry for the current 5-tuple flow, the Media Access Control (MAC) header, Internet Protocol (IP) header, User Datagram Protocol (UDP) header, and Adaptive Multi-Rate (AMR) header of the first message of the current 5-tuple flow are also written to the starting address of the second DDR4 storage space corresponding to the storage token.

[0019] Preferably, updating the timestamp information in the flow table entry includes: writing the RTP timestamp, sequence number, and collection timestamp of the current packet into the flow table entry, and calculating the flow duration based on the collection timestamp of the first packet and the collection timestamp of the current packet.

[0020] Preferably, the RTP payload is sequentially written to the second DDR4 storage space as AMR Chip units; for each AMR Chip unit written, the number of RTP payloads written to the current quintuple stream increases by 1, and the number is cleared to zero after assembling the RTP voice compression frame.

[0021] Preferably, the assembly format of the RTP voice compression frame is: MAC header, IP header, UDP header, AMR header and N sequentially arranged AMR chips, where N>1; the AMR header contains the cyclic redundancy check (CRC32) values ​​of the stream quintuples to which the N AMR chips belong.

[0022] Preferably, it further includes at least one of the following operations:

[0023] Discard Real-Time Transmission Control Protocol (RTCP) packets;

[0024] Identify silent feature fields in the RTP payload and discard the corresponding RTP voice packets;

[0025] Identify RTP media streams that are transmitted only in one direction, assemble them into a form similar to RTP voice compressed frames, and then follow the same processing procedure.

[0026] After trimming the MAC header, IP header, and UDP header from the RTP voice message, only the AMR Chip is written to the second DDR4 storage space.

[0027] Preferably, when storing the RTP voice message in the local cache, a Block Random Access Memory (BRAM) is used to store the complete data of the RTP voice message, and a First-In-First-Out (FIFO) queue is used to store the address and length information of the complete data in the BlockRAM.

[0028] A second aspect of this application also provides a high-performance RTP voice acceleration acquisition system based on FPGA, comprising:

[0029] The message parsing module is used to receive raw IP packets and parse them to obtain a set of key message information containing five-tuple information, service type identifier, and policy matching results.

[0030] The flow table management module is used to extract five-tuple information from the key information set of the packet if the service type is identified as an RTP voice packet and the policy matching result is a hit.

[0031] A multi-BANK interleaved parallel read / write module is used to query the flow table based on the five-tuple information. The flow table is stored in the first DDR4 memory and accesses the first DDR4 memory through the multi-BANK interleaved parallel read / write engine.

[0032] The token management module is used to create a flow table entry for the current five-tuple flow if the flow table entry corresponding to the five-tuple information is empty, and to apply for a storage token, and write the identifier of the storage token into the flow table entry. The storage token corresponds to a continuous storage address in the second DDR4 memory.

[0033] The storage address determination module is used to update the timestamp information in the flow table entry and determine the storage address based on the storage token identifier in the flow table entry if the flow table entry is not empty and the five-tuple information in the flow table entry is consistent with the five-tuple information of the current packet.

[0034] The RTP payload quantity update module is used to extract the RTP payload from the RTP voice packet, write the RTP payload into the second DDR4 storage space corresponding to the storage address, and update the number of RTP payloads written to the current five-tuple stream.

[0035] The RTP voice compression frame assembly and output module is used to read N RTP payloads from the second DDR4 storage space, assemble them into RTP voice compression frames and output them when the number of written RTP payloads reaches a preset threshold N, where N>1.

[0036] The storage token reclamation module is used to obtain the flow duration and the arrival time of the last RTP packet of the flow in the flow table entry. If the flow duration exceeds a preset time threshold, the corresponding storage token is reclaimed; if the flow table entry times out, the flow table entry is reclaimed.

[0037] This application achieves high-performance RTP voice acceleration acquisition through a multi-bank interleaved parallel read / write engine, recyclable storage token management, combined BlockRAM and FIFO storage, and various traffic offloading operations. The processing performance of a single FPGA accelerator card can reach 40 to 100 Gbps, compared to the traditional pure software acquisition solution where a single 36C processor's processing performance is no more than 8 Gbps. The overall processing performance of a single x86 server is improved by 5 to 8 times, requiring only one server to acquire 40 Gbps of traffic, significantly reducing the number of servers deployed. Simultaneously, this method supports the creation of over 2 million flow tables per second and tens of millions of concurrent flow tables, capable of meeting the acquisition needs of telecom operators' nationwide voice call volume. Through traffic offloading and compressed frame assembly, the transmission bandwidth between the acquisition network card and the x86 server is reduced by more than 80%, greatly alleviating the server's CPU load. All processing steps are implemented by FPGA hardware logic, with the overall system processing latency controlled at the microsecond level, meeting the real-time acquisition requirements of voice services. In addition, this method supports multiple RTP voice coding formats such as G.711, AMR-NB, AMR-WB, and EVS, and can be deployed on 2G, 3G, 4G, 5G and fixed-line networks. It has good compatibility and portability, and the structured message encapsulation format also simplifies the subsequent processing of the x86 server software. Attached Figure Description

[0038] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0039] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0040] Figure 1 A schematic diagram of a high-performance RTP voice acceleration acquisition method based on FPGA provided in this application embodiment;

[0041] Figure 2 This is a schematic diagram of the query flow table process provided in an embodiment of this application;

[0042] Figure 3 A schematic diagram of the processing flow when the flow table entry is empty, provided in an embodiment of this application;

[0043] Figure 4 A schematic diagram of a high-performance RTP voice acceleration acquisition system based on FPGA provided in this application embodiment;

[0044] Figure 5 This is a schematic diagram of the AMR frame structure provided in an embodiment of this application;

[0045] Figure 6 This is a schematic diagram of the Head frame format provided in an embodiment of this application. Detailed Implementation

[0046] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] It should be noted that all user information (including but not limited to user device information, user personal information, object information corresponding to device usage data, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, device usage data, etc.) involved in all embodiments of this application are information and data authorized by the user or fully authorized by all parties.

[0048] This implementation method is applicable to voice service acquisition scenarios in traditional 2G and 3G networks, advanced 4G / 5G networks, and NGN softswitches of fixed-line networks for telecom operators. It can realize synchronous monitoring and acquisition of all voice calls across the entire network, adapt to the high-volume real-time transmission protocol RTP media stream processing requirements of 100G and above ports, and can complete voice authentication and individual identification on the x86 server side by combining artificial intelligence voiceprint recognition algorithms. This method can be implemented based on Xilinx's ZYNQ Ultrascale+ series field-programmable gate array (FPGA). This chip includes a processing system (PS) part with a CPU-like central processing unit and a programmable logic (PL) part with a traditional FPGA structure. The PL part accesses the double data rate DDR4 space of the PS part through the advanced extensible interface AXI bus. The external DDR4 of the PS part is divided into Region 0 and Region 1, where Region 0 is the space required for the PS CPU to run, and Region 1 is an idle and reusable space. The first DDR4 memory is an external DDR4 independent of the PS part, and the second DDR4 memory is the idle space of Region 1 of the PS part. RTP voice, which is voice data transmitted based on the Real-time Transport Protocol (RTP), is the core form of carrying voice media streams in multimedia communications such as VoIP and voice calls, and is also the main transmission form of voice services in the 2G / 3G / 4G / 5G and fixed-line networks of telecom operators.

[0049] For example, this method is completed collaboratively by a message receiving module, a message parsing module, a message storage and forwarding module, an RTP (Real-Time Transport Protocol) voice flow table management module, an RTP voice storage token management module, an RTP voice compression management module, a message caching module, and a reporting processing module. Each module is implemented by the PL part of the FPGA hardware logic, without software participation in the processing, ensuring the line-speed execution capability of the entire acquisition process.

[0050] The implementation process of the high-performance RTP voice acceleration acquisition method based on FPGA described in this application will be described in detail below with reference to specific embodiments. It should be noted that this embodiment is only used to explain this application and is not intended to limit the scope of protection of this application. Conventional adjustments or substitutions of each step by those skilled in the art without departing from the concept of this application should be included in the protection scope of this application.

[0051] like Figure 1 As shown in the figure, this application discloses a schematic diagram of a high-performance RTP voice acceleration acquisition method based on FPGA, including the following method steps:

[0052] S1 receives the original IP packet and parses it to obtain a set of key information about the packet, including the five-tuple information, the service type identifier, and the policy matching result.

[0053] S2, if the service type is identified as an RTP voice message and the policy matching result is a hit, then extract the quintuple information from the message key information set;

[0054] S3, query the flow table according to the five-tuple information. The flow table is stored in the first DDR4 memory. Access the first DDR4 memory through the multi-BANK interleaved parallel read / write engine.

[0055] S4. If the flow table entry corresponding to the five-tuple information is found to be empty, then a flow table entry is created for the current five-tuple flow, and a storage token is requested. The identifier of the storage token is written into the flow table entry. The storage token corresponds to a continuous storage address in the second DDR4 memory.

[0056] S5. If the flow table entry is found to be non-empty and the 5-tuple information in the flow table entry is consistent with the 5-tuple information of the current packet, then update the timestamp information in the flow table entry and determine the storage address based on the storage token identifier in the flow table entry.

[0057] S6, extract the RTP payload from the RTP voice message, write the RTP payload into the second DDR4 storage space corresponding to the storage address, and update the number of RTP payloads written to the current five-tuple stream.

[0058] S7, when the number of written RTP payloads reaches a preset threshold N, read N RTP payloads from the second DDR4 storage space, assemble them into an RTP voice compression frame and output it, where N>1;

[0059] S8, obtain the flow duration and the arrival time of the last RTP packet in the flow table entry. If the flow duration exceeds a preset time threshold, reclaim the corresponding storage token; if the flow table entry times out, reclaim the flow table entry.

[0060] In some embodiments, for step S1, the original IP packet is received and parsed to obtain the packet's key information set. The packet receiving module receives Ethernet packets from the physical line, and after basic physical layer processing such as serial-to-parallel conversion, clock synchronization, and frame synchronization, removes redundant physical layer information to generate an original IP packet conforming to the Internet Protocol (IP) specification. This original IP packet is transmitted to the packet parsing module. This process is a routine data conversion in hardware logic, which only needs to ensure the integrity of the packet and the real-time transmission. Optionally, the processing performance of the packet receiving module can be configured to support 100Gbps line-speed reception to avoid packet loss.

[0061] After receiving the raw IP packet, the message parsing module performs multi-layer protocol parsing, timestamp marking, and policy matching, ultimately generating a key message information set containing five-tuple information, service type identifier, and policy matching results. Specific implementation includes:

[0062] Upon receiving the original IP packet, a timestamp is added to the packet and written to the source MAC address (smac) field in the Media Access Control (MAC) frame header of the original IP packet. The timestamp's precision is configured at the microsecond (µs) level. Its parameter is defined as the actual time the packet is received by the physical line, and its value range is within the effective timing range of the high-precision clock module inside the FPGA chip. The parameter value is generated in real-time by a clock signal provided by the high-precision crystal oscillator inside the chip, and the update mechanism is once every microsecond to ensure the timestamp's accuracy. For example, the timestamp is stored in 32-bit binary format, generated in real-time by the high-precision clock module inside the FPGA, and updated once every microsecond to ensure accuracy. It is directly written to the reserved space in the source MAC address field. This operation is completed within a single clock cycle without additional processing delay.

[0063] After completing the timestamp marking, the message parsing module performs protocol parsing from Layer 2 to the application layer on the original IP message. It sequentially extracts key information from the Layer 2 MAC header, Layer 3 IP header, Layer 4 TCP or UDP header, and Application Layer Session Initiation Protocol (SIP) and Real-time Transmission Control Protocol (RTP) header. At the same time, it identifies the service type of the message and generates a service type identifier. The service type identifier is divided into four categories: SIP signaling message, RTP voice message, RTCP media control flow message, and other messages. It is represented by 2 bits of binary data, with different values ​​corresponding to different service types.

[0064] The 5-tuple information is extracted from the Layer 3 IP header and the Layer 4 TCP / UDP header. It is a combination of the source IP address, destination IP address, source port number, destination port number, and transport layer protocol number, serving as a unique identifier for the network data stream. The 5-tuple information is stored in binary format, with the storage length determined by the IP address type; for IPv6 addresses, the storage width is longer. The parsed 5-tuple information, service type identifier, and collection timestamp together form the initial packet information set. This process is implemented by a parallel hardware logic parsing circuit, with each protocol parsing unit working simultaneously, completing the parsing and information extraction of the entire packet frame in a single clock cycle.

[0065] The message parsing module has a built-in policy matching unit. This unit contains a 5-tuple mask and a valid data stream template. The 5-tuple mask is binary data with the same length as each field of the 5-tuple information. It is configured to the policy matching unit by the x86 server via the PCIe bus. In the mask, a bit of 1 indicates that the corresponding bit participates in the matching, and a bit of 0 indicates that the bit is ignored. The policy matching unit first performs a bitwise AND operation between the 5-tuple information in the initial message information set and the 5-tuple mask. The operation formula is as follows:

[0066]

[0067] In the formula, This is the intermediate value after the bitwise AND operation. The binary data of the quintuple information. The binary data of the quintuple mask. This is the bitwise AND operator. It will match the middle value. The policy matching unit compares the data flow templates with the valid data flow templates. If they match, a successful policy matching result is generated; otherwise, a failed policy matching result is generated. The policy matching result is represented by a single bit of binary data, where 0 indicates a failed match and 1 indicates a successful match. The policy matching unit integrates the policy matching results into the initial message information set, ultimately generating a message key information set containing five-tuple information, service type identifier, and policy matching result. For example, the number of valid data flow templates can be configured to 1024, all configured and updated by the x86 server via the PCIe bus, with the update mechanism being on-demand updates.

[0068] In some embodiments, for step S2, the service type and policy matching result are determined and the five-tuple information is extracted. The message parsing module transmits the generated message key information set along with the original RTP voice message to the message store-and-forward module. The message store-and-forward module first reads the service type identifier and policy matching result from the message key information set and filters the message: if the service type identifier is a non-RTP voice message, or the policy matching result is a miss, the message is transmitted to the message cache module for further processing; if the service type identifier is an RTP voice message and the policy matching result is a hit, the five-tuple information is extracted from the message key information set, and the five-tuple information is transmitted to the RTP voice flow table management module.

[0069] Optionally, during this process, the message storage and forwarding module stores the RTP voice messages in a local cache. The local cache adopts a combined storage structure of Block RAM and First-In-First-Out (FIFO). The Block RAM is used to store the complete data of the RTP voice message, and the FIFO is used to store the storage address and data length information of the complete data in the Block RAM. For example, the storage capacity of the Block RAM can be configured to 1Mb, and the buffer depth of the FIFO can be configured to 1024 frames, ensuring no loss of RTP voice messages under high traffic. At the same time, the FIFO's first-in-first-out characteristic enables ordered reading of messages. This storage method solves the technical problems of high message storage latency and low addressing efficiency in traditional pure software acquisition solutions. Its principle is to use the large capacity and high read / write speed of Block RAM to achieve fast storage of message data, and to use FIFO to achieve efficient management of storage addresses, ensuring low-latency storage and fast reading of RTP voice messages under 100Gbps high traffic.

[0070] In some embodiments, for step S3, the flow table is queried based on the 5-tuple information. After receiving the 5-tuple information, the RTP voice flow table management module queries the flow table based on the 5-tuple information. The flow table is stored in the first DDR4 memory, which is an external DDR4 memory independent of the FPGA PS part. The flow table entries contain 5-tuple information, storage token identifier, timestamp information, flow duration, flow status identifier, etc. The access to the flow table is implemented through a multi-BANK interleaved parallel read and write engine.

[0071] Please see Figure 2 , Figure 2 This is a schematic diagram of the flow table query process provided in an embodiment of this application. In S201, a multi-BANK interleaved parallel read / write engine is configured. The multi-BANK interleaved parallel read / write engine includes multiple independent read / write engines, each corresponding to a BANK memory bank of the first DDR4 memory. Each read / write engine consists of a DDR4 physical layer interface, a command address controller, a data path, and arbitration logic, employing standard DDR4 burst read / write operations. The burst length can be configured to 8 or 16. For example, the first DDR4 memory can be configured with 8 BANKs, corresponding to 8 independent read / write engines. The maximum processing performance of each read / write engine can be configured to 5.625 MPPS per million packets per second. When the 8 engines work in parallel, the overall read / write performance of the flow table can reach 45 MPPS, meeting the flow table read / write requirements at 100 Gbps line speed. Each read / write engine is independent of the others and can perform read / write operations on different flow table entries simultaneously. By using hash modulo operation, access requests from different flows are evenly distributed to different banks, avoiding the processing bottleneck of a single engine. At the same time, load balancing between banks is achieved through an interleaving scheduling algorithm, ensuring that the storage resources of the first DDR4 memory are fully utilized.

[0072] In S202, the hash value of the 5-tuple information is generated. The RTP voice flow table management module has a built-in hardware hash operation unit. After receiving the 5-tuple information, this unit performs a hash operation on it to generate a fixed-length hash value, which serves as the initial access address for the flow table. For example, the hardware hash operation unit uses a Cyclic Redundancy Check (CRC) 32 algorithm. The binary data of the 5-tuple information is used as the algorithm input to generate a 32-bit hash value. The hash value ranges from 0 to 2^32-1. The hash operation is completed within a single clock cycle, ensuring high-speed flow table addressing. The hash value parameter is defined as a unique identifier for the 5-tuple information, and its value range is determined by the hash algorithm used. The parameter value is generated in real time by the hardware hash operation unit.

[0073] In S203, the BANK number is determined and the flow table is looked up. After obtaining the hash value, the BANK number to be accessed is determined by modulo operation. The calculation formula is as follows:

[0074]

[0075] In the formula, The BANK number to be accessed. The hash value generated for the quintuple information. This represents the number of banks in the first DDR4 memory. This is the modulo operator. After determining the BANK number, the corresponding read / write engine is activated. This engine performs precise flow table entry addressing within the corresponding BANK based on the hash value. For example, the engine takes the hash value modulo the total number of flow table entries in the current BANK to obtain the array index, and then reads the flow table entry content from the storage address corresponding to that index. Flow table entries for each BANK are stored contiguously in a static array, with the starting address and number of entries configured during initialization. The content of the addressed flow table entry is read and transmitted to the judgment unit of the RTP voice flow table management module to complete the flow table query operation.

[0076] The design of the multi-BANK interleaved parallel read / write engine solves the technical problems of low CPU processing flow table read / write speed and inability to adapt to 100Gbps high traffic in traditional pure software acquisition solutions. Its principle is to improve the overall read / write performance of the flow table by working in parallel with multiple independent read / write engines, and to achieve uniform mapping from hash value to BANK number by using modulo operation to ensure balanced distribution of read / write requests for each BANK. This enables the creation of more than 2 million flow tables per second and supports tens of millions of concurrent flow tables, meeting the acquisition needs of telecom operators for full network and full volume of voice calls.

[0077] For step S4, if the flow table entry is empty, a flow table entry is created and a storage token is requested. The judgment unit of the RTP voice flow table management module judges the content of the received flow table entry. If the content of the flow table entry corresponding to the five-tuple information is empty, it is determined that the current RTP voice packet is the first packet of the corresponding five-tuple flow. At this time, a flow table entry needs to be created for the current five-tuple flow, and a storage token needs to be requested from the RTP voice storage token management module.

[0078] Please see Figure 3 , Figure 3 This is a schematic diagram of the processing flow when the flow table entry is empty, as provided in this embodiment of the application. In S301, a new flow table entry is created. The RTP voice flow table management module generates a new flow table entry based on the message key information set of the first message of the current five-tuple flow. The new flow table entry includes the current five-tuple information, the first message's acquisition timestamp, the RTP timestamp, the sequence number, the flow status identifier initialized to "establishing," the flow duration initialized to 0, and a reserved space for writing the storage token identifier. The new flow table entry is written to the corresponding empty entry address in the first DDR4 memory according to the preset flow table entry format. The write operation is completed by the corresponding read / write engine to ensure the real-time performance and accuracy of the write.

[0079] In S302, a storage token request is made. The RTP voice flow table management module sends a storage token request to the RTP voice storage token management module. This request contains the 5-tuple information of the current 5-tuple flow and the storage address of the new flow table entry. The storage token is a unique identifier for a contiguous block of memory in the second DDR4 memory. The second DDR4 memory is the idle space of Region 1 in the FPGAPS section. For example, its storage capacity can be configured to 2GB. The number of storage tokens is equal to the number of RTP voice compression frames that can be cached in the second DDR4 memory. The identifier of the storage token is pre-associated with the starting address and storage length of the second DDR4 memory space. This association is stored in the token management table of the RTP voice storage token management module and is pre-configured by the x86 server.

[0080] In S303, storage token allocation occurs. Upon receiving a storage token request, the RTP voice storage token management module allocates a new storage token for the current 5-tuple stream from the idle token pool. The idle token pool is the area within the storage token management module that stores all idle storage tokens. Token allocation follows a first-in, first-out (FIFO) principle to ensure orderly allocation. After allocation, the storage token management module sends the token's identifier back to the RTP voice stream table management module and updates the token's status from idle to occupied. If the idle token pool is empty, allocation is suspended, and the current first packet is either discarded or sent to the x86 server. The choice of action is configured by the x86 server via the PCIe bus, and a resource exhaustion alarm is sent to the x86 server.

[0081] In S304, the storage token identifier is written. After receiving the storage token identifier, the RTP voice flow table management module writes it to the reserved location of the newly created flow table entry, and simultaneously updates the flow status identifier in the flow table entry from "under construction" to "normal," completing the entire flow table entry creation process. At this point, the storage address corresponding to the first packet of the current 5-tuple flow is determined.

[0082] The storage token management addresses the technical issue of the mismatch between the capacity of the 5-tuple flow table and the RTP voice compression frame buffer. The principle is to bind the flow table entries to the contiguous storage addresses of the second DDR4 memory using storage tokens. Storage resources are allocated only to the 5-tuple flows that need to be collected, and the storage tokens can be recycled. This improves the resource utilization of the second DDR4 memory and ensures that storage resources can still be used efficiently even when the flow table entry capacity is much larger than the compressed frame buffer capacity, thus meeting the collection needs of large-scale concurrent flows.

[0083] In some embodiments, for step S5, when the flow table entry is not empty and matches, the flow table entry is updated and the storage address is determined. If the judgment unit of the RTP voice flow table management module finds that the content of the flow table entry is not empty, it further compares the five-tuple information in the flow table entry with the five-tuple information of the current RTP voice packet: if the two are inconsistent, it is determined to be a hash collision. At this time, the RTP voice flow table management module uses linear probing or chaining to sequentially search for subsequent free entries in the current BANK; if a free entry is found, a flow table entry is created for the flow according to step four; if there is no free entry in the current BANK, the current packet is marked as another key packet and transmitted to the packet caching module, and a hash collision alarm message is generated and reported to the X86 server.

[0084] If the two match, the current RTP voice message is determined to be a subsequent message of the corresponding 5-tuple stream. At this time, the timestamp information in the flow table entry needs to be updated, and the storage address needs to be determined according to the storage token identifier in the flow table entry.

[0085] Specifically, the RTP voice flow table management module writes the RTP timestamp, sequence number, and acquisition timestamp of the current packet into the flow table entry, overwriting the original corresponding information in the flow table entry to ensure that the flow table entry stores the latest timestamp information of the five-tuple flow. Simultaneously, the module calculates the flow duration based on the acquisition timestamp of the first packet in the flow table entry and the acquisition timestamp of the current packet. The calculation formula is as follows:

[0086]

[0087] In the formula, For the duration of the flow, This is the timestamp of the current message collection. The timestamp of the first packet is used for acquisition. The stream duration parameter is in microseconds, with the same precision as the acquisition timestamp. The value ranges from 0 to a preset time threshold. The update mechanism is to update it once every time a subsequent packet is received. The calculated stream duration is written into the stream table entry, overwriting the original value.

[0088] The RTP voice flow table management module reads the storage token identifier from the flow table entry. This identifier is a unique identifier of the storage token requested by the current 5-tuple flow when the flow table entry is created, and is pre-associated with a contiguous storage address of the second DDR4 memory.

[0089] The RTP voice flow table management module transmits the read storage token identifier to the RTP voice storage token management module. The storage token management module queries the continuous storage address of the second DDR4 memory corresponding to the storage token identifier according to the association in the token management table, including the starting address and storage length, and feeds back the storage address to the RTP voice flow table management module. The flow table management module then transmits the storage address to the packet store-and-forward module.

[0090] In some embodiments, for step S6, the RTP payload is extracted and written to the second DDR4 storage space. After receiving the storage address, the message store-and-forward module extracts the RTP payload from the locally cached RTP voice messages. The RTP payload is the voice data carried in the RTP voice messages and is the core content of voice acquisition. The extraction process is implemented by the address positioning and data reading circuit of the hardware logic. According to the load start position field in the RTP header, the starting address of the RTP payload is located, and all data from that address to the end of the message is read, which is the RTP payload to be extracted. This operation is completed in a single clock cycle without additional processing delay.

[0091] The extracted RTP payload is used as an Adaptive Multi-Rate (AMR) Chip unit and written sequentially to the second DDR4 memory space corresponding to the specified storage address. If the current packet is the first packet of a 5-tuple stream, before writing the RTP payload, the MAC header, IP header, UDP header, and AMR header of the first packet are first written to the starting address of the second DDR4 memory space corresponding to that storage address, and then the RTP payload is written as an AMR Chip unit to subsequent addresses. If the current packet is a subsequent packet of a 5-tuple stream, the RTP payload is directly written as an AMR Chip unit to the free address of the second DDR4 memory space in sequence. The AMR Chip unit is the RTP payload in the RTP voice packet. It is the data unit for the FPGA to split, store, merge, and compress the RTP voice packet, and it is also the basic module for forming the RTP voice compression frame (AMR frame).

[0092] In some embodiments, for step S7, when a preset threshold is reached, an RTP voice compression frame is assembled and output. The RTP voice compression management module reads in real time the number of RTP payloads written to the current five-tuple stream and compares it with a preset threshold N. The preset threshold N is a configurable parameter configured by the x86 server through the PCIE bus, with a value range of 1 to 100. The specific value is determined according to the operator's voice acquisition requirements and network bandwidth conditions.

[0093] If the number of RTP payloads already written is less than a preset threshold N, then continue receiving and storing subsequent AMR Chip units; if the number of RTP payloads already written reaches the preset threshold N, then trigger the assembly operation of RTP voice compression frames, specifically including:

[0094] The RTP voice compression management module reads Q AMR Chip units from the second DDR4 memory in the order of writing according to the storage address. The read operation is implemented through the AXI bus, which can adopt the AXI4 Stream protocol and support high-speed parallel data transmission, where Q>1.

[0095] The CRC32 checksum calculation module performs a CRC32 operation on the Q read AMR Chip units to generate a CRC32 checksum. This checksum is used to verify the integrity of the subsequently assembled RTP voice compression frame. The calculation formula is as follows:

[0096]

[0097] In the formula, This is the CRC32 checksum. to This refers to the binary data of Q AMR chip units read sequentially. For data splicing symbols.

[0098] The RTP voice compression management module assembles RTP voice compression frames according to a preset format. The assembly format includes a MAC header, IP header, UDP header, AMR header, and Q sequentially arranged AMR chip units. The AMR header contains a reserved field, a pkt_cnt field, and a crc_id field. The reserved field is set to 0. The pkt_cnt field represents the number of AMR chip units in the compressed frame. The crc_id field is the calculated CRC32 checksum. The AMR header has a 128-bit width, and the position and length of each field are preset. Figure 5 The diagram shown is a schematic representation of the AMR frame structure provided in an embodiment of this application. Figure 6 The diagram shown is a schematic diagram of the Head frame format provided in an embodiment of this application.

[0099] The assembled RTP voice compression frame is transmitted to the reporting processing module. Simultaneously, the RTP voice compression management module resets the counter for the number of RTP payloads already written to the current 5-tuple stream, preparing for storage of subsequent new AMR Chip units. If the current 5-tuple stream still has subsequent RTP voice packets, new AMR Chip units are written sequentially, and the count is recalculated.

[0100] Optionally, during implementation, at least one traffic offloading operation can be performed. The traffic offloading operation is performed synchronously with the storage of the AMR Chip unit. Before storage, the RTP voice packets are filtered, specifically including: discarding RTCP media control flow packets without any storage or processing; identifying silent feature fields in the RTP payload, and discarding the corresponding RTP voice packets without generating AMR Chip units if silent features are detected; identifying RTP media streams that are transmitted only in one direction, such as ringback tone services, and assembling them into a form similar to RTP voice compressed frames, with the subsequent processing flow being the same; for RTP voice packets that are not the first packet, trimming the MAC header, IP header, and UDP header from the RTP voice packet, and writing only the RTP payload as an AMR Chip unit into the second DDR4 storage space; for the first packet, writing the MAC header, IP header, UDP header, and AMR header completely into the starting address of the second DDR4 storage space.

[0101] Traffic offloading solves the technical problems of high transmission bandwidth and heavy CPU load in traditional pure software acquisition solutions. The principle is to pre-cut invalid data and redundant headers through hardware logic, thereby reducing the amount of data that needs to be stored and transmitted, significantly reducing the transmission bandwidth between the acquisition network card and the x86 server, and alleviating the CPU processing load of the server.

[0102] In some embodiments, the storage token is revoked after the flow duration expires. The RTP voice flow table management module reads the flow duration in the flow table entry in real time and compares it with a preset time threshold. The preset time threshold is a configurable parameter configured by the x86 server via the PCIe bus. For example, it can be configured to 30s. The threshold is determined according to the voice service collection requirements of the operator, and the value range is from 1s to 60s.

[0103] The flow table entry is reclaimed after the flow stop time expires. The RTP voice flow table management module reads the arrival time of the last RTP packet in the flow table entry in real time, determines the length of the flow stop time, and compares it with a preset time threshold. The preset time threshold is a configurable parameter, configured by the x86 server through the PCIe bus. For example, it can be configured to 30 seconds.

[0104] If the duration of the flow does not exceed the preset time threshold, the current state of the flow table entry and storage token is maintained, and the five-tuple flow is continued to be collected and processed. If the duration of the flow exceeds the preset time threshold, it is determined that the collection time of the five-tuple flow has expired, and the five-tuple flow continues to occupy the original flow table space, but the corresponding storage token is reclaimed. When the five-tuple flow stops exceeding the set time threshold, that is, the flow table entry stops updating the duration, and the flow table space originally occupied by the flow table entry is reclaimed.

[0105] Specifically, when the duration of a stream exceeds a preset time threshold, the RTP voice stream management module updates the stream status identifier of the stream entry to "timeout" and sends a storage token revocation request to the RTP voice storage token management module. This request includes the identifier of the storage token to be revoked. Upon receiving the revocation request, the RTP voice storage token management module updates the status of the corresponding storage token from "occupied" to "free" based on the storage token identifier and adds the storage token to the free token pool, completing the storage token revocation. This storage token can then be used by subsequent new five-tuple streams, achieving cyclic reuse of the storage token. Simultaneously, the storage token management module clears the data in the second DDR4 memory space corresponding to the storage token, releasing the storage space to prepare for subsequent new AMR Chip unit storage.

[0106] When it is determined that the five-tuple flow has stopped for more than a set time threshold, the RTP voice flow table management module clears the five-tuple information, storage token identifier, timestamp information, etc. in the flow table entry, completes the reclamation and emptying of the flow table entry, and releases the first DDR4 memory space occupied by the flow table entry. This space can be used to create flow table entries for subsequent new five-tuple flows. If the flow duration has not exceeded the preset time threshold when the flow table entry is reclaimed, that is, the corresponding storage token is still occupied, then the corresponding storage token is reclaimed.

[0107] The revocation mechanism of flow table entries and storage tokens ensures that the storage resources of the first DDR4 memory and the second DDR4 memory can be recycled, avoiding resource waste. It solves the technical problems of excessive storage resource consumption and inability to support large-scale concurrent streams in traditional pure software acquisition solutions. It improves the utilization rate of storage resources to over 90% and meets the long-term acquisition needs of telecom operators for full network and full volume of voice calls.

[0108] In some embodiments, the system also includes caching and reporting of non-RTP voice packets and critical packets. Packets identified as non-RTP voice packets or whose policy matching result is a miss, as well as RTP voice packets marked as other critical packets in the event of a hash collision, are all transmitted to the packet caching module. The packet caching module uses a FIFO caching structure to cache these packets. For example, the FIFO caching depth can be configured to 1024 frames to ensure ordered storage of packets. During the caching process, the integrity of the packets is checked. If the check passes, the packets are stored; if the check fails, the packets are discarded and an alarm message is sent to the x86 server.

[0109] The message caching module transmits the cached messages to the reporting processing module. Simultaneously, the reporting processing module receives RTP voice compression frames transmitted by the RTP voice compression management module. The two types of data are mixed according to a preset priority to form a unified reporting data stream. For example, the priority of the RTP voice compression frames is configured to be higher than other messages to ensure real-time reporting of the voice media stream. The mixed reporting data stream is transmitted to the x86 server via the PCIe high-speed bus. The PCIe bus uses the PCIe v3.1 protocol, and the transmission bandwidth can be configured to 100Gbps to ensure high-speed transmission of the reporting data.

[0110] After receiving the reported data stream, the x86 server decompresses the RTP voice compression frame to restore the original RTP voice data. It then processes the voice data using an artificial intelligence voiceprint recognition algorithm to extract voiceprint information for each call. Combined with behavior and number analysis, it achieves identity verification and individual identification.

[0111] This method achieves high-performance RTP voice acceleration acquisition through a multi-bank interleaved parallel read / write engine, recyclable storage token management, combined BlockRAM and FIFO storage, and various traffic offloading operations. A single FPGA accelerator card can achieve processing performance of 40 to 100 Gbps, compared to the traditional pure software acquisition solution where a single 36C processor's processing performance is no more than 8 Gbps. The overall processing performance of a single x86 server is improved by 5 to 8 times, requiring only one server to acquire 40 Gbps of traffic, significantly reducing the number of servers deployed. Simultaneously, this method supports the creation of over 2 million flow tables per second and tens of millions of concurrent flow tables, capable of meeting the acquisition needs of telecom operators' nationwide voice call volume. Through traffic offloading and compressed frame assembly, the transmission bandwidth between the acquisition network card and the x86 server is reduced by more than 80%, greatly alleviating the server's CPU load. All processing steps are implemented by FPGA hardware logic, with the overall system processing latency controlled at the microsecond level, meeting the real-time acquisition requirements of voice services. In addition, this method supports multiple RTP voice coding formats such as G.711, AMR-NB, AMR-WB, and EVS, and can be deployed on 2G, 3G, 4G, 5G and fixed-line networks. It has good compatibility and portability, and the structured message encapsulation format also simplifies the subsequent processing of the x86 server software.

[0112] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0113] Please see Figure 4 , Figure 4 This application provides a block diagram of a high-performance RTP voice acceleration acquisition system based on FPGA implementation. The system specifically includes:

[0114] The message parsing module 401 is used to receive the original IP message and parse it to obtain a set of key message information containing five-tuple information, service type identifier and policy matching result;

[0115] The flow table management module 402 is used to extract five-tuple information from the key information set of the message if the service type is identified as an RTP voice message and the policy matching result is a hit.

[0116] The multi-BANK interleaved parallel read / write module 403 is used to query the flow table according to the five-tuple information. The flow table is stored in the first DDR4 memory and accesses the first DDR4 memory through the multi-BANK interleaved parallel read / write engine.

[0117] The token management module 404 is used to create a flow table entry for the current five-tuple flow if the flow table entry corresponding to the five-tuple information is empty, and to apply for a storage token, and to write the identifier of the storage token into the flow table entry. The storage token corresponds to a continuous storage address in the second DDR4 memory.

[0118] The storage address determination module 405 is used to update the timestamp information in the flow table entry and determine the storage address based on the storage token identifier in the flow table entry if the flow table entry is not empty and the five-tuple information in the flow table entry is consistent with the five-tuple information of the current packet.

[0119] RTP payload quantity update module 406 is used to extract RTP payload from the RTP voice packet, write the RTP payload into the second DDR4 storage space corresponding to the storage address, and update the number of RTP payloads written to the current five-tuple stream.

[0120] The RTP voice compression frame assembly and output module 407 is used to read N RTP payloads from the second DDR4 storage space, assemble them into RTP voice compression frames and output them when the number of written RTP payloads reaches a preset threshold N, where N>1.

[0121] The storage token reclamation module 408 is used to obtain the flow duration and the arrival time of the last RTP packet of the flow in the flow table entry. If the flow duration exceeds a preset time threshold, the corresponding storage token is reclaimed; if the flow table entry times out, the flow table entry is reclaimed.

[0122] It should be noted that the working process of each module in the high-performance RTP voice acceleration acquisition system based on FPGA described in this embodiment can refer to the working process of the high-performance RTP voice acceleration acquisition method based on FPGA described in the above embodiment, and the technical effect achieved is the same as that of the high-performance RTP voice acceleration acquisition method based on FPGA described in the above embodiment, so it will not be repeated here.

[0123] The above description represents the preferred embodiments of the present invention. It should be noted that, for those skilled in the art, various improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A high-performance RTP voice acceleration collection method based on FPGA implementation, characterized in that, Includes the following steps: Receive raw IP packets and parse them to obtain a set of key information about the packets, including five-tuple information, service type identifier, and policy matching results; If the service type is identified as an RTP voice message and the policy matching result is a match, then extract the quintuple information from the message key information set; The flow table is queried based on the quintuple information. The flow table is stored in the first DDR4 memory and accessed through a multi-BANK interleaved parallel read / write engine. If the flow table entry corresponding to the five-tuple information is found to be empty, a flow table entry is created for the current five-tuple flow, and a storage token is requested. The identifier of the storage token is written into the flow table entry. The storage token corresponds to a continuous storage address in the second DDR4 memory. If the flow table entry is found to be non-empty and the 5-tuple information in the flow table entry is consistent with the 5-tuple information of the current packet, then the timestamp information in the flow table entry is updated, and the storage address is determined according to the storage token identifier in the flow table entry. Extract the RTP payload from the RTP voice message, write the RTP payload into the second DDR4 storage space corresponding to the storage address, and update the number of RTP payloads written to the current 5-tuple stream. When the number of written RTP payloads reaches a preset threshold N, N RTP payloads are read from the second DDR4 storage space, assembled into an RTP voice compression frame and output, where N>1; The flow duration and the arrival time of the last RTP packet in the flow table entry are obtained. If the flow duration exceeds a preset time threshold, the corresponding storage token is revoked; if the flow table entry times out, the flow table entry is revoked.

2. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, The multi-BANK interleaved parallel read / write engine includes multiple independent read / write engines, each corresponding to a BANK of the first DDR4 memory; a hash value is generated based on the quintuple information, and the hash value is modulo the number of BANKs to determine the BANK number to be accessed.

3. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, The storage token is allocated from the free token pool; when the storage token is reclaimed, it is marked as free and returned to the free token pool; the identifier of the storage token is pre-associated with the starting address and length of the second DDR4 storage space.

4. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, When creating a flow table entry for the current 5-tuple flow, the Media Access Control (MAC) header, Internet Protocol (IP) header, User Datagram Protocol (UDP) header, and Adaptive Multi-Rate (AMR) header of the first message of the current 5-tuple flow are also written to the starting address of the second DDR4 storage space corresponding to the storage token.

5. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, Updating the timestamp information in the flow table entry includes: writing the RTP timestamp, sequence number, and collection timestamp of the current packet into the flow table entry, and calculating the flow duration based on the collection timestamp of the first packet and the collection timestamp of the current packet.

6. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, The RTP payload is sequentially written to the second DDR4 storage space as an AMR Chip unit; for each AMR Chip unit written, the number of RTP payloads written to the current quintuple stream increases by 1, and the number is cleared to zero after assembling the RTP voice compression frame.

7. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, The assembly format of the RTP voice compression frame is: MAC header, IP header, UDP header, AMR header and N sequentially arranged AMR chips, where N>1; the AMR header contains the CRC32 value of the stream quintuple to which the N AMR chips belong.

8. The high-performance RTP voice accelerated collection method based on FPGA implementation of claim 1, wherein, It also includes at least one of the following operations: Discard Real-Time Transmission Control Protocol (RTCP) packets; Identify silent feature fields in the RTP payload and discard the corresponding RTP voice packets; Identify RTP media streams that are transmitted only in one direction and assemble them into a form similar to RTP voice compressed frames; After trimming the MAC header, IP header, and UDP header from the RTP voice message, only the AMR Chip is written to the second DDR4 storage space.

9. The high-performance RTP voice acceleration acquisition method based on FPGA implementation according to claim 1, characterized in that, When storing the RTP voice message in the local cache, a Block Random Access Memory (BRAM) is used to store the complete data of the RTP voice message, and a First-In-First-Out (FIFO) queue is used to store the address and length information of the complete data in the Block RAM.

10. A high-performance RTP voice acceleration acquisition system based on FPGA implementation, characterized in that, include: The message parsing module is used to receive raw IP packets and parse them to obtain a set of key message information containing five-tuple information, service type identifier, and policy matching results. The flow table management module is used to extract five-tuple information from the key information set of the packet if the service type is identified as an RTP voice packet and the policy matching result is a hit. A multi-BANK interleaved parallel read / write module is used to query the flow table based on the five-tuple information. The flow table is stored in the first DDR4 memory and accesses the first DDR4 memory through the multi-BANK interleaved parallel read / write engine. The token management module is used to create a flow table entry for the current five-tuple flow if the flow table entry corresponding to the five-tuple information is empty, and to apply for a storage token, and write the identifier of the storage token into the flow table entry. The storage token corresponds to a continuous storage address in the second DDR4 memory. The storage address determination module is used to update the timestamp information in the flow table entry and determine the storage address based on the storage token identifier in the flow table entry if the flow table entry is not empty and the five-tuple information in the flow table entry is consistent with the five-tuple information of the current packet. The RTP payload quantity update module is used to extract the RTP payload from the RTP voice packet, write the RTP payload into the second DDR4 storage space corresponding to the storage address, and update the number of RTP payloads written to the current five-tuple stream. The RTP voice compression frame assembly and output module is used to read N RTP payloads from the second DDR4 storage space, assemble them into RTP voice compression frames and output them when the number of written RTP payloads reaches a preset threshold N, where N>1. The storage token reclamation module is used to obtain the flow duration and the arrival time of the last RTP packet of the flow in the flow table entry. If the flow duration exceeds a preset time threshold, the corresponding storage token is reclaimed; if the flow table entry times out, the flow table entry is reclaimed.

Images