Method and system for protocol processing

Abstract

The invention relates to a method for protocol processing comprising a main program code (MC) comprising instructions for processing different protocol elements (MAC SA, MAC DA) of a data packet stream (S1) of a transmission protocol (TP), the main program code (MC) comprising one or more code sections, the method comprising the following steps: assigning a latency requirement and / or a bandwidth requirement to one or more of the code sections of the main program code (MC), compiling each of the code sections into a respective object code according to the assigned latency and / or bandwidth requirement, and executing each of the object codes by different processors (P1, P11, P12, P13, P2).

Description

TECHNICAL FIELD

[0001] The present disclosure relates to program code compilation, network communication and improved processor architecture for data packet flow processing. BACKGROUND

[0002] There are many communication interfaces and communication protocols, especially in modern telecommunication systems. New technologies are being designed and old systems are further developed, so there are many generations of products on the market. Communication protocols are also constantly evolving and, as a result, several protocol versions are applied at the same time. For example, it has been proposed to use Ethernet for 5G fronthaul to transport Common Public Radio Interface (CPRI) traffic between Radio Equipment (RE) and Radio Equipment Control (REC), see http: / / www.cpri.info / downloads / eCPRI_Presentation_for_CPRI_Server_2018_01_03.pdf.

[0003] The advantages of using Ethernet transport are threefold: 1) low cost of equipment, 2) use of shared infrastructure with statistical multiplexing, and 3) ease of Operation, Administration and Maintenance (OAM). However, there are several challenges: in future mobile networks, ultra-high bit rate requirements from bandwidth radio streams added for multiple antenna transmission, and low latency and jitter to meet delay requirements and joint processing needs. eCPRI does not constrain the use of network layer specific and data link layer specific protocols to form a network. Therefore, any type of (transport) network can be used for eCPRI as long as the eCPRI requirements are met.

[0004] In the case of radio equipment test equipment, such as described in European patent application publication EP 3637826 A1, the test equipment should support as many required protocol(s) as possible, e.g. eCPRI. However, the possible configurations are extensive. Furthermore, different manufacturers’ implementations can differ and thus cause further protocol variations.

[0005] The extensive parameterization options and resulting huge parameter space and possible FPGA and / or ASIC implementations mean that product development to market takes a long time. Furthermore, in the case of FPGA circuits, it can be difficult to implement new features when the FPGA is highly utilized, i.e. there is no downtime of FPGA usage. In addition to this, testing and verifying FPGA specific and / or ASIC specific implementations also takes time.

[0006] Currently, Mentor Graphics' test equipment X-STEP specifically utilizes a parametrized software and FPGA circuit solution for protocol handling. Therein, the software runs on an application processor or host processor and the required runtime processing is performed by FPGA circuits, i.e. in hardware. The challenge of this architecture has become the runtime data processing and the reactive bidirectional communication between the software on the application processor and the data processing on the FPGA circuits. By limiting the functionality supported by the product using FPGAs, the increasing FPGA requirements could be reduced. However, this also limits the number of solutions that can be offered to customers.

[0007] A solution could be the use of ever larger FPGA / ASIC chips. However, a challenge arises, as it is no longer sensible to choose larger chips. Larger chips also increase the costs for product development, production and testing. Furthermore, larger chips also create new challenges with respect to power and heat problems.

[0008] Developing a solution based on processor-driven software is faster compared to hardware-based FPGA / ASIC functionality. However, pure software solutions have historically been slower and less accurate compared to hardware-based circuit solutions. Figure 1 A common approach is shown in a block diagram that utilizes a dedicated hardware implementation for protocol handling and a software application that handles the payload. In this approach, all payloads are sent via a memory that serves as a single send interface between hardware-based processing and software-based processing. Unfortunately, the accurate timing information related to the payload is lost with this approach.

[0009] An alternative solution would be to perform all processing directly in hardware, but as discussed, this increases the requirements on the FPGA / ASIC circuits. In this case, all processing related to the send protocol is done by the FPGA. Management messages are driven to the application processor as in the previous implementation example. For example, framing and deframing of the payload, and corresponding real-time data control messages (when enabled) can be handled in hardware. The remaining user data service can be handled by software. SUMMARY

[0010] Accordingly, it is an object to improve protocol handling, in particular the handling of data packets of a data packet stream. Furthermore, it is an object to improve the utilization of one or more processors for protocol handling. It is also an object to improve data transmission, in particular the transmission of radio data, by connecting one or more radio stations, e.g. one or more remote radio units (RRUs), to a centralized baseband unit (BBU) and / or to a packet-based transmission network of a device under test.

[0011] This object is achieved by the following aspects.

[0012] According to a first aspect, a method of protocol processing comprising a main program code is presented. The main program code comprises instructions for processing different protocol elements of a data packet stream of a transport protocol. The main program code comprises one or more code segments. The method comprises the step of assigning a latency requirement and / or a bandwidth requirement to one or more of the code segments of the main program code. The method further comprises the step of compiling each of the code segments into a respective target code for execution by a different processor according to the assigned latency and / or bandwidth requirement.

[0013] According to a second aspect, an apparatus is presented. The apparatus is operative to perform the method steps of the first aspect.

[0014] According to a third aspect, a main program code is presented. The main program code comprises instructions for processing different protocol elements of a data packet stream of a transport protocol. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 A block diagram of a method for protocol processing is shown.

[0016] Figure 2 A block diagram of an improved method for protocol processing is shown.

[0017] Figure 3 A block diagram of an improved method for protocol processing with further details is shown.

[0018] Figure 4 Latency and data rate requirements are illustrated.

[0019] Figure 5 A block diagram of a protocol source code is shown, which is divided into code segments and the code segments are compiled into target codes for execution by different processors.

[0020] Figure 6 Processing of different protocol parts by different processors is shown.

[0021] Figure 7 Distribution of target codes to different processors is illustrated.

[0022] Figure 8 An illustration of a radio communication system is shown.

[0023] Figure 9 An illustration of a fronthaul data transmission between a baseband unit and a remote radio head is shown.

[0024] Figure 10 An illustration of a system for testing a radio device is shown.

[0025] Figure 11 The processing of different data packet streams representing antenna carriers is shown.

[0026] Figure 12 Further details of packet stream processing performed by different processors are shown.

[0027] Figure 13 Further details of the processing of multiple sub-streams are shown.

[0028] Figure 14 The protocol stack of the eCPRI protocol is shown.

[0029] Figure 15 An example of eCPRI protocol processing performed by different processors is shown. Detailed Implementation

[0030] Figure 1 A block diagram is shown illustrating a method utilizing a dedicated hardware implementation for protocol processing (i.e., on a first processor P1, in this case, an FPGA or ASIC) and a software application for processing the payload (on a second processor P2, in this case, a CPU). In this method, all payloads are transmitted via a memory M, which serves as a single transmission interface between the hardware-based processing and the software-based processing. As already mentioned, accurate timing information associated with the payload is lost with this method. Figure 1 The first processor P1 in the system uses a transport protocol to receive the data packet stream S1. The transport protocol can be an ISO / OSI Layer 2 (i.e., data link layer) and / or Layer 3 (i.e., network layer) protocol. Therefore, the transport protocol can be Ethernet or eCPRI, or it can include both Ethernet and encapsulated eCPRI (Ethernet Radio, RoE). Ethernet Radio IEEE 1904.3 is an open and free standardization work specifying the transport protocol and encapsulation format for transmitting time-sensitive wireless (cellular) radio-related application streams between two endpoints via an Ethernet-based transport network. For example, in the case of radio equipment, software applications such as network throughput testing need to be performed, where frame loss analysis and / or latency analysis are performed.

[0031] like Figure 1 As can be seen, the first processor P1 (in this case, an FPGA or ASIC) can handle all protocol elements, such as Ethernet frame elements like preambles, MAC destinations, MAC sources, and / or frame inspection sequences in the case of the Ethernet protocol. The physical layer transceiver circuitry (PHY) can also be implemented in the first processor P1 and is required to be connected to the physical medium.

[0032] The PHY connects the link layer device (often referred to as MAC, as an abbreviation for Media Access Control) to the physical medium such as fiber or copper cable. The PHY usually does not handle MAC addressing.

[0033] The second processor P2 (in this case a CPU) can be responsible for payload processing. In Figure 1 In embodiments of the application, the protocol processing is thus performed by the first processor only.

[0034] Increasing data traffic demands impose very stringent timing requirements on both accuracy (stability of time synchronization) and network latency. Allowing the network to support very stringent demands imposes sub- picosecond level requirements on the transport network. Latency of the whole network is almost as critical as timing and becomes even more important in 5G networks as devices impose stringent latency requirements on the network. In addition, bandwidth requirements are high, e.g. for CPRI, and current link rates are limited in the sense that they cannot be scaled up. Bandwidth is not the only limiting aspect, in fact, there can be very stringent latency constraints that do not permit long distance transmission of data. Bandwidth between the application processor P2 and the FPGA P1 can be low. This can be a disadvantage, especially in certain radio equipment test scenarios where a test model for sending IQ data to a remote radio head and subsequently receiving IQ data response at high data rates is required.

[0035] Figure 2 A block diagram showing an improved method for protocol processing is shown. Therein, the protocol processing is split between the first processor P1 and the second processor P2. The data packet stream S1 can be received by the first processor P1, in Figure 1In case of an implementation of the first processor P1 comprising a physical layer transceiver circuit PHY, data packets of e.g. Ethernet frames are received via a serial port (e.g. a high speed transceiver) and can subsequently be converted into a plurality of parallel data packet sub-streams. The conversion can be performed by a serial-to-parallel converter and a parallel-to-serial converter in the opposite direction, which can be implemented in the first processor P1 (e.g. the FPGA). The conversion can be performed by a multiplexer (MUX) comprising a circuitry for converting parallel data into serial data and vice versa. The multiplexer can also be responsible for the exact timing for switching the data packets onto the respective sub-stream SUB1, SUB2, SUBn and / or the data packet stream S1 of the transmission protocol. Thus, after the serial-to-parallel conversion of the received data packet stream S1, there can be a plurality of sub-streams SUB1, SUB2, SUBn. Subsequently, the protocol elements of each sub-stream SUB1, SUB2, SUBn are processed by the first processor P1 and the second processor P2. The second processor P2 can still handle the processing of the received payload. For example, a first set of protocol elements can be processed by the first processor P1 in hardware and a second set of protocol elements can be processed by the second processor P2 by software. For example, the preamble, the MAC DA and / or the CRC can be processed by the first processor P1, while the MAC SA can be processed by the second processor P2. The cyclic redundancy check (CRC) is an error detection code. Furthermore, it is possible that the second processor P2 processes the MAC DA and / or the MAC SA, wherein the MAC DA is the MAC destination address and the MAC SA is the MAC source address. Of course, other distributions of the processing of the protocol elements between the first processor in hardware and the second processor by software are possible, as will be described later. For all sub-streams SUB1, SUB2, SUBn, the processing of the same type of protocol elements can be performed by the same processor. However, it can be the case that for different sub-streams SUB1, SUB2, SUBn, the same protocol elements are handled by different processors, as will also be described later. It should also be understood that more than two processors P1, P2 can be used for the protocol processing in hardware or by software, e.g. a first processor handles a first set of protocol elements, a second processor handles a second set of protocol elements and a third processor handles a third set of protocol elements, etc. As shown in Fig. 9, each sub-stream can have a respective processing path comprising a sub-processing module of the first and / or second processor, wherein the sub-processing module is used for processing individual protocol elements of the transmission protocol. Furthermore, the sub-processing module of the first or second processor can be used for processing a plurality of protocol elements. Figure 2

[0036] Now turning to Figure 3 ​, further details of the improved method for protocol processing are shown. As indicated, a plurality of processors can be used to process the protocol elements and the payload of the received data packet stream. For example, a high-speed transceiver for receiving and / or transmitting data packets in serial form can be implemented in a first processor P1 (e.g. FPGA) as well as a serial-to-parallel converter MUX. Furthermore, the first processor P1 can be used to process the first set of protocol elements of the first and second sub-stream SUB1, SUB2.

[0037] The sub-streams SUB1, SUB2 can be created by multiplexing the original data packet stream S1 in parallel form and thus creating parallel processing paths along which the sub-streams SUB1, SUB2 are processed, see Figure 2 For simplicity, Figure 3 Two sub-streams SUB1, SUB2, an upstream and a downstream sub-stream are shown in

[0038] A data packet is the basic unit of communication over a transport network. Packets are also called datagrams, segments, cells, or frames, depending on the protocol used to send the data. When data must be sent, the data is broken into similar data structures, called packets, before transmission, which are reassembled into the original data chunk once they reach their destination. The structure of a packet depends on which type of packet it is and on the protocol. Normally, a data packet has protocol elements: a header and a payload. The header holds overhead information about the packet, the service, and other transmission-related data. The payload, which represents the batch of packets (all of the above being considered overhead), and is actually the data being carried.

[0039] Now, the data packets of the received data packet stream S1 can comprise data packets related to different purposes. For example, eCPRI messages can be mapped onto the transport network layer payload. In this case, multiple eCPRI messages can be concatenated and can be encapsulated in Ethernet frames. An example is shown in eCPRI Specification V1.0 (2017-08-22) 3.2.3.4 « Mapping Instances ». For example, the eCPRI messages can belong to different antenna carriers. Thus, messages belonging to a first antenna carrier can be assigned to the first sub-stream SUB1, while messages belonging to a second antenna carrier can be assigned to the second sub-stream SUB2, etc.

[0040] In general, there can be multiple sub-streams, each of which is processed according to a respective processing path. The first processing path SUB1 along which the first sub-stream SUB1 is processed can comprise one or more sub-processing modules P11, P12, P13 of the first processor P1 and one or more sub-processing modules P21, P22 of the second processor P2. The second processing path along which the second sub-stream SUB1 is processed can comprise one or more sub-processing modules P11, P12, P13 of the first processor P1 and one or more sub-processing modules P21, P22 of the second processor P2. The first and second processors can be a system on chip, SoC. The SoC can have more than one core or sub-processing module.

[0041] Thus, the protocol processing of the different sub-streams SUB1, SUB2 is divided into parallel segments based on, e.g., data source or message type. The message type can be, e.g., the type as shown in eCPRI Specification V1.0 (2017-08-22) 3.3.4 Message Types.

[0042] Each parallel processing comprises the exact timing requirements of when traffic should be on the processing path. The timing of the data packets on the processing path can be performed by a multiplexer, which can be configured according to, e.g., timing information received from an application processor, e.g., the second processor P2. The number of parallel sub-processing modules and thus parallel processing paths can vary and depends on the data volume, available bandwidth and / or required latency.

[0043] Further details of the arrangement of one or more sub-processing modules for processing a data stream are described in US Patent Application Publication No. 2018 / 0013608 Al. Further, as shown in Figure 3 A GPU or other processor for accelerating the protocol processing can be provided.

[0044] Each sub-stream and corresponding processing path can comprise its own memory M1, M2, M3, M4 or can share a memory with one or more other sub-streams or processing paths. Further, a global memory 1 and / or a global memory 2 can be provided, which can be accessed by multiple or all sub-streams or processing paths and / or processors P1, P2.

[0045] The sub-processing modules can be communicatively coupled between the first processor P1 and the second processor P2 using different buses, such as PCIe, and in another aspect, between AXI4 (memory mapped) and / or AXI4 stream, or another protocol for on-chip communication, as applicable, between the sub-processing modules of the first processor P1. AXI (Advanced eXtensible Interface) is a parallel high-performance, synchronous, high-frequency, multi-master, multi-slave communication interface, mainly designed for on-chip communication.

[0046] As Figure 3 indicated, a graphical user interface, GUI, can be provided, e.g. on a host workstation, by means of which a user can control and / or configure the processing of protocol elements. For example, the user can control the creation, update and distribution of object code to be executed by one or more of the respective processors P1, P2 and / or sub-processing modules P11, P12, P13, P21, P22.

[0047] In case of eCPRI, the second processor P2, i.e. the application processor, can be used for payload and other non-time-critical processing. For example, the second processor can be used for configuring and / or storing radio channel models and / or for creating stimulus data for transmission to the DUT over the transport network, e.g. based on one or more radio channel models. Further, the second processor P2 can be used for configuring the sub-processing modules and / or for configuring the timing of the multiplexer MUX. Protocol processing is spread over different sub-processing modules, depending on its time-criticality, i.e. delay requirement(s) and / or bandwidth requirement(s). For example, 5G NR symbols can be stored in the global memory 1 and the data transmission to the DUT, e.g. one or more antennas, can be processed by the first processor P1 in hardware, i.e. sub-processing modules P11, P12, P13, e.g. sub-processing modules of the FPGA of the SoC shown.

[0048] In many transport protocols, some (protocol processing) operations do not require a fast response to newly arrived data packets or generally traffic - therefore, this high latency task can thus be done by a general purpose processor and / or by software program code executed by the processor P2. Further, in these cases, the amount of data to be processed (during runtime) typically drops. In particular, one or more tasks for processing one or more protocol elements can thus be offloaded (by software) to the second processor P2. At the other extreme are fast and continuous protocol functions that have to be implemented in hardware, e.g. by FPGA switching. Further, in assigning processing tasks to the respective processors, the amount of data to be processed is typically of importance. For example, in case of low response time requirements, packets are generated by the first processor, e.g. FPGA, and only non-critical protocol elements, such as control plane management, are then generated on the second processor P2, e.g. a general purpose processor, e.g. CPU.

[0049] In Figure 4In the middle, different processing requirements and the distribution of the corresponding processing tasks on the available processors and sub-processing modules are shown. Depending on the requirements, parts of the processing are transferred to the first processor P1 (e.g. FPGA) or one or more second processors P2. In case of low latency and high data rate or bandwidth requirements, the processing is assigned to the first processor P1 and its sub-processing modules P11, P12, P13. In case of more relaxed requirements with respect to latency of the protocol processing, the processing tasks can be assigned to the second processor P2.

[0050] Turning to Figure 5 , the protocol processing can be designed and written into the main program code MC, e.g. in C / C++ or other high-level languages that make use of multi-tasking. The main program code MC can be divided before or during compile time. Figure 5 The block diagram of Fig. 2 shows how one main program code MC for protocol processing code can be divided into separate object codes, which are executed by different processors P1, P2 or processing sub-modules P11, P12, P13 of the respective processors P1, P2.

[0051] Protocol processing is involved in any exchange of information. Protocols typically contain packets. These packets have to be created by the sender and reassembled at the receiver while ensuring compliance with the protocol specification. Therefore, when designing the processor architecture and creating the program code, the protocol processing and efficiently implementing the protocol processing functionality is important.

[0052] The main program code MC can comprise instructions for processing different protocol elements of the data packets of the data packet stream. The protocol elements can correspond to control and / or signaling data required for the payload data to reach its destination. The protocol elements can correspond to protocol overhead. It can thus be required that the protocol elements reliably issue the payload of the data over the transmission network. The protocol elements can correspond to elements of an Ethernet frame. For example, the protocol elements can comprise a preamble, a start-of-frame delimiter, a MAC destination address, a MAC source address, an 802.1Q tag, an Ethernet type (Ethernet II) or length (IEEE 802.3), a frame check sequence (e.g. 32-bit CRC) and / or an inter-packet gap. The protocol elements can comprise or exclude the payload data. The protocol elements can correspond to eCPRI common headers. For example, the protocol elements can comprise an eCPRI protocol revision C (indicating concatenation), an eCPRI message type and / or an eCPRI payload size. The protocol elements can thus comprise or exclude the payload of the eCPRI packet.

[0053] The main program code MC can comprise one or more code segments. Thus, the main program code MC can be monolithic or modular, as the case can be. Each code segment can comprise one or more instructions for processing one or more protocol elements of a data packet stream of a transport protocol. The transport protocol can correspond to an ISO OSI layer 2 protocol, i.e. a data link layer protocol, such as Ethernet. The transport protocol can correspond to an ISO OSI layer 4 protocol, i.e. a transport layer protocol, such as UDP. The transport protocol can be a combination of a data link layer protocol and a transport layer protocol, such as eCPRI. The transport protocol can be an ISO / OSI layer 2, i.e. data link layer, and / or layer 3, i.e. network layer, protocol. The transport protocol can thus be Ethernet or eCPRI, or can comprise both Ethernet and encapsulated eCPRI (Ethernet Radio, RoE). The transport protocol can thus be or can comprise Ethernet Radio RoE.

[0054] The main program code MC and / or the code segments can be in the form of source code, preferably C or C++. The code segments can be compiled, which compilation can or can not include synthesis, to produce corresponding object code. To this end, a first code segment can be compiled, e.g. by a compiler C1, C2, C3, C4, in order to obtain a first object code, wherein a second code segment can be compiled by another one of the compilers C1, C2, C3, C4, to obtain a second object code.

[0055] The first code segment can be compiled by, e.g., synthesizing the first code segment by a compiler C1 and / or C2. Thereby, the code segment can be translated into RTL code, e.g. using HDL, and can then become a design implementation of underlying hardware, i.e. the first processor and / or the sub-processing modules P11, P12, P13, e.g. a SoC comprising a reconfigurable FPGA.

[0056] The second code segment can be compiled, e.g. by a compiler C3 or C4, into bytecode. Bytecode is a binary representation of program code, an intermediate representation between source code and machine code. Bytecode is typically more "portable" than machine code, meaning that bytecode tends to reduce the code's dependence on a limited set of hardware and / or operating system environments. At the same time, bytecode is also typically more efficient than source code, because it can usually be translated into machine code (also known as "native language") much faster than source code can be translated into machine code during runtime. Bytecode can also be "compiled" into native language for execution, or can be executed on a virtual machine that "interprets" the bytecode at runtime. Different segments of bytecode used in a single program can be handled in different ways. For example, some segments can be compiled, while others are interpreted.

[0057] The delay requirement and / or the bandwidth requirement can be assigned to the main program code or to one or more code segments. The assignment can comprise a flag, a comment and / or one or more parameter settings in a separate file. In case of a flag, a priority can be assigned to the code segment. For example, the flag can indicate one of a plurality of (e.g. two) priorities for executing the code segment. The priorities specify a high or low delay requirement for the respective code segment. The comment can specify how the respective code segment is to be compiled. This has the effect of changing the behavior of the compiler. Thus, by means of the comment, it is specified how the compiler (or other translator) is to handle the inputted main program code or code segment. Thus, by means of the comment, only a local section is affected, i.e. the code segment of the main program code can be affected. In the separate file, parameters of the respective code segment can be set, for example by a user. The parameter settings can reflect the delay requirement and / or the bandwidth requirement of the respective code segment, for example as shown in Figure 4 Fig. 1, wherein the delay and data rate requirements are illustrated. The user can assign these requirements to the main program code and / or one or more code segments of the main program code, for example using the graphical user interface GUI described above. Furthermore, via control messages, for example using the GUI, the user can change the distribution and execution of the main program code, for example at runtime of the main program code or one or more code segments thereof.

[0058] Now, based on the assigned requirements, the code segments can be compiled. For example, based on the requirements, different object codes can be created. To this end, the compiler CI, C2, C3, C4 or compiler functionality can be selected based on the requirements assigned to the respective code segments. For example, the object code for the first processor (e.g. FPGA) and the first sub-processing module PI 1 can be compiled or synthesized using the first compiler CI, e.g. Mentor Graphics Catapult-C for C-synthesis and / or Xilinx VITIS. The object code for the second sub-processing module P12 (e.g. stream processor, vector processor or core, such as Microblaze or ACAP) can be compiled using a hardware-specific gcc compiler, e.g. the Xilinx VITIS toolchain (including gcc compiler for MicroBlaze or ACAP). The third sub-processing module P13 can be an arch64 (64-bit ARM core) for which a standard gcc compiler C3 can be used. In this case, a bare-metal gcc compiler or a real-time specific operating system gcc compiler can be used. For the sub-processing modules of the second processor P2, e.g. in a standard Linux / Windows environment, gcc can again be used as a compiler C4, e.g. the Microsoft Visual Studio compiler. Thus, different object codes for the respective processor or its sub-modules can be obtained. These object codes can then be distributed to the processors for execution. The user can configure which part of the protocol processing is compiled / synthesized to which hardware element, i.e. processor. The communication between the different object codes running on different processors can be enabled by a runtime environment. The runtime environment can allow the communication and, to this end, establishes a connection between the object codes on the different processors or sub-processing modules. This runtime environment can comprise one or more protocols and / or buses that allow the communication therebetween, e.g. PCIe and / or AXI as mentioned above.

[0059] The design and programming of the object code can be performed using a high-level synthesis tool. The high-level synthesis tool can be used by the user to develop one or more register transfer level (RTL) programs. Each register transfer level program comprises a definition and description of one or more operations to be performed by the object code. Each register transfer level program can be written using a high-level programming language such as ANSI C++. For example, the Intel HLS compiler is a high-level synthesis (HLS) tool that takes untimed C++ code as input and generates production-quality register transfer level (RTL) code, which in this case is optimized for FPGA.

[0060] The main program code MC can thus be compiled to be executed in hardware and by software, depending on the specific requirements set for the code sections of the main program code MC.

[0061] Turning now to Figure 6 Further details are shown with respect to the processing of different protocol elements or parts by different processors P1, P2 and their respective sub-processing modules P11, P12, P13. The system can comprise multiple processors P1, P2 with different processing capabilities. For example, as described in Figure 5 the created object code can be distributed to the respective processors P1, P2. For example, a first processor P1, which can be a system on a chip SOC, can comprise multiple sub-processing modules P11, P12, P13. A first sub-processing module P11 can be used to execute a first object code, and a second sub-processing module P12 can be used to execute a second object code. In this case, the first sub-processing module P11 and the second sub-processing module P12 can be different parts of an FPGA, for example one or more different logic blocks. The first processor P1 can comprise a further sub-processing module P13 separate from the FPGA. The first processor P1 can thus comprise a third sub-processing module P13 in the form of a co-processor for executing a third object code. A second processor P2 can execute a fourth object code. Of course, the second processor P2 can also comprise multiple sub-processing modules for processing respective object codes.

[0062] The data packet stream can be received by the first processor, for example via the transmission line 1-4, and the first set of protocol elements can be processed according to the instructions of the first object code, and the second set of protocol elements can be processed according to the instructions of the second object code. The first processor can also process a third set of protocol elements according to the instructions of the third object code. The second processor can process a fourth set of protocol elements according to the instructions of the fourth object code. The communication between the processors and their sub-processing modules can be enabled by buses connecting, for example, the first processor with the second processor and / or the first, second and third sub-processing modules, as the case can be.

[0063] As shown in Figure 6 the memory modules DDR4 can be communicatively coupled to the respective processors P1, P2, and to the sub-processing modules P11, P12, P13.

[0064] Figure 7Fig. illustrates the distribution of target code to different processors P1, P2 and sub-processing modules P11, P12, P13. Depending on the requirement(s) assigned to the respective code segment, the target code can be created and distributed to the processor P1, P2 having the required processing power. The distribution can be performed, for example, when one or more target codes need to be updated. Once the updated target code(s) is compiled, for example, during the runtime of the target code on the respective processor P1, P2 or sub-processing module(s), the target code(s) can be updated.

[0065] Figure 8 A diagram of a radio communication system is shown. In particular, the proposed method and system enable proper timing advance and compensate for delay variations of packets from different network stations, such as BBU, RRH and / or UE. Furthermore, radio data, for example associated with a beam ID, is extracted from the received packets in the proper symbol period and can be forwarded for further processing, for example to a beamforming function.

[0066] In Figure 8 A radio communication system is illustrated in Fig.. The traditional monolithic base transceiver station (BTS) architecture is increasingly being replaced by a distributed BTS architecture in which the functions of a BTS are split into two physically separate units, a baseband unit (BBU) and a remote radio head (RRH). The BBU performs baseband processing for a particular air interface that is being used for wireless communication over one or more radio frequency channels. The RRH performs radio frequency processing to convert baseband data output from the BBU into radio frequency signals for radiation from one or more antennas coupled to the RRH, and / or to produce baseband data for the BBU from radio frequency signals received at the RRH via one or more antennas. The RRH can typically be installed close to the one or more antennas, often at the top of a tower, and the BBU can typically be installed in a more easily accessible location, often at the bottom of the tower. However, the RRH and BBU can be collocated, for example in a lab, as appropriate. The BBU and RRH can typically be connected by one or more fiber optic links. The interface between the BBU and RRH is defined by a fronthaul communication link standard, such as the Common Public Radio Interface (CPRI) family of specifications, the Open Base Station Architecture Initiative (OBSAI) family of specifications, and the Open Radio Interface (ORI) family of specifications.

[0067] In the 5G architecture, a new frequency domain fronthaul interface will be specified. The frequency domain fronthaul is a functional split where the IFFT / FFT (Inverse Fast Fourier Transform / Fast Fourier Transform) can move from the BBU to the RRH. Frequency domain samples instead of time domain samples are emitted over the fronthaul. The RRH will have information about the resource allocation for different UEs over the communication channel. The new eCPRI interface specification "eCPRI Specification V1.0 (2017-08-22)" is already available.

[0068] For deployment scenarios where the Remote Radio Head RRH (sometimes also denoted as Radio Remote Unit RRU) and the Base Band Unit BBU (sometimes also denoted as Radio Equipment Controller REC) are separated, the signals received from one or more antennas have to be transmitted over a medium connecting the RRH with the BBU, since normally the signal combination is done at the BBU. In general, the interface used for the connection between the BBU and the RRH is called fronthaul. The signals over the fronthaul can be complex time domain samples, such as specified in the legacy Common Public Radio Interface CPRI. The digitized waveforms can be transmitted over the fronthaul from the BBU to the RRH and from the RRH to the BBU via one or more Radio Aggregation Units (RAU).

[0069] The signals of the user equipment UE are power limited and due to the path loss varying with the distance to the UE, when these signals are digitally represented, a large dynamic range is encountered, which can assume that for complex frequency samples a large number of bits will be required and in case of MIMO (Multiple Input Multiple Output) / diversity layers, the required fronthaul capacity will be multiplied by the number of antennas. Furthermore, it is desirable to model this propagation of the radio signals in order to test the functionality of the radio system and its components. Due to the limited capacity over the fronthaul, it is desirable to find a way to optimize the use of the fronthaul. As illustrated, the BBU can be connected to the core network Core via one or more backhaul or crosshaul connections and possibly to other BBUs (not shown).

[0070] In Figure 9 different protocols are used for the fronthaul data transmission. As mentioned above, the different protocols employed have different bandwidth capacities. Thus, for example, between the RRH and the BBU, the CPRI streaming supports up to 10.1 Gbps, while the CPRI v7.0 supports 25 Gbps and the eCPRI supports up to 25 Gbps (per single line).

[0071] I / Q data (i.e. in-phase and quadrature component data) is the digitized air interface data. The sampling rate in 5G is 122.88 MHz. Thus, especially in case of multiple radio channels, a large amount of data needs to be transmitted via the fronthaul. It should be understood that I / Q data transmission can occur in uplink and downlink direction for each radio channel.

[0072] In Figure 10 , a test environment for testing radio equipment is illustrated. SIEMENS is developing an innovative test system for ASIC and FPGA verification and validation in the field of simulation, hardware emulation, field programmable gate array (FPGA) prototyping and real-time (post-silicon, manufacturing) environments. This test system can comprise one or more test equipment 10 which can be used in a wide variety of high-tech fields ranging from cellular base stations to the automotive industry. For example, a radio equipment test system or test equipment 10, e.g. from the X-STEP product line, allows to stimulate and trace all digital interfaces in a modem radio equipment such as a radio equipment control (REC) and / or a radio equipment (RE) module (also referred to as baseband unit BBU and remote radio head RRH, respectively). The digital interface protocols supported by such test equipment can include JESD204B, CPRI, OBSAI RP3 and 10G Ethernet. The test equipment 10 can also include register transfer level (RTL) simulation and hardware emulation and can also be applicable for FPGA prototyping, real-time post-silicon board debugging and final product testing. The test equipment 10 can cover every phase in the radio base station product development cycle, ranging from first RTL simulation all the way to post-production. The same test can be reused in every phase of the product development cycle of the device under test DUT. Furthermore, due to a parameterized test case building block architecture, it is facilitated to port test cases from one project to another.

[0073] As Figure 10The illustrated, the test equipment 10 is arranged between a BBU and a RRH and is communicatively coupled to the BBU and the RRH via respective fronthaul connections. However, other test setups including the test equipment 10 have become known. For example, in the international application PCT / US2019 / 055623 and the European application EP 18200162, different test systems and arrangements are disclosed, respectively. In there, the test equipment 10 is able to be coupled to a BBU only or a RRH only. For this, the simulation or emulation of one or more UEs can be performed by the test equipment 10. Alternatively, the test equipment 10 is able to be coupled to a RRH. For this, the BBU can be simulated or emulated by the test equipment 10. In this case, one or more devices connected to the test equipment 10 can be considered as devices under test, DUT, as the digital signal processing and, generally speaking, the functionality of those devices is tested whether they work according to specified requirements. The channel model is a (test) model of the behavior of one or more radio signals transmitted over an air interface. The channel model enables testing of radio devices in a laboratory environment or even in the field. For example, the test equipment 10 can be tested using a channel model, which performs the processing of radio frequency signals, e.g. in the form of I / Q data, according to one or more channel models. All connections (e.g. between base station and / or test apparatus and / or UE) can be made from coaxial cables.

[0074] As mentioned before, radio base station systems rely on various types of digital IC designs in the form of FPGA or ASIC chips. The development and verification of these IC designs requires a practical counterpart interface to the external digital RF interface of the chip. Especially in the case of pre-silicon testing, the simulated or emulated DUT can only process data at a lower speed than the test equipment. Therefore, the transmission rate of the test equipment is required to be reduced. To cope with the transceiver limitations of the DUT, an external opto-electrical conversion and buffering unit can be designed to connect the test equipment to a slow running prototype, e.g. for early verification of the fronthaul interface in the pre-silicon phase. However, no matter how big the buffer is, if the transmitting side, i.e. the test equipment, is not slowed down according to the slowdown factor of the prototype, they will eventually overflow. Besides implementing the external converter / buffering unit itself, a flow control on the test equipment side is required.

[0075] To cope with the ever increasing amount of data to be transmitted and processed, especially in the case of beamforming, an improved design of the processing architecture is required, especially for the test equipment 10. Another test scenario can be found in the CPRI 2.0 specification chapter 3.2.4.6 “Message Type #5: One-way delay measurement”, where exact timing information of the packet transmission over the transport network is required.

[0076] To meet these requirements, a method and system for processing one or more data streams is proposed, like Figure 11As shown. Here, the system settings are similar to Figure 3 The system setup is as follows: The data packet stream S1 between the test device 10 and the DUT is divided into multiple sub-streams, each corresponding to an antenna carrier AxC1...AxCn. Sub-streams SUB1, SUB2, and SUBn can then be processed in parallel, for example, according to corresponding processing paths. For example, the eCPRI protocol can be divided into sub-streams for each antenna carrier AxC1...AxCn. The processing of protocol elements is performed by the corresponding processor and the sub-processing modules of the corresponding processing paths. The first sub-stream SUB1 can be processed along a processing path including sub-processing modules P11a, P21a, P13a, and P2a. The second sub-stream SUB2 can be processed along a processing path including sub-processing modules P11b, P21b, P13b, and P2b. The nth sub-stream SUBn can be processed along a processing path including sub-processing modules P11n, P21n, P13n, and P2n (e.g., logic blocks of an FPGA or coprocessor). In this context, sub-processing modules P11a, P11b, and P11n can be part of sub-processing module P11, which processes one or more protocol elements (i.e., the first set of protocol elements). The same protocol elements should be processed by sub-processing module P11, which processes all sub-streams. The same applies to the second sub-processing module P12, which can include additional sub-processing modules P12a, P12b, and P12n for processing the same protocol elements of all sub-streams SUB1, SUB2, and SUBn—however, the protocol elements processed by sub-processing module P12 are different from those processed by sub-processing module P11. The same applies to the sub-processing module P13 of the first processor. Finally, the second processor is also used to process different packet streams through its corresponding sub-processing modules P2a, P2b, and P2n. It should be understood that the processor and its corresponding sub-processing units are integrated into the (radio equipment) test apparatus as described above.

[0077] The CPRI standard defines the AxC (antenna carrier) for transmitting and receiving digital I / Q data; see CPRI specification V4.0 (2008-06-30). The AxC is a container for I / Q samples. The antenna carrier (AxC) corresponds to IQ data, which reflects the sampled and digitized radio signal of a carrier at a separate antenna element. For testing purposes, IQ data can be generated or reproduced by test equipment. That is, IQ data is used as excitation for the DUT and stored on the test equipment; see [link to relevant documentation]. Figure 10 The response from the DUT is then received by the test equipment and can be analyzed, displayed, and / or stored.

[0078] In case of eCPRI, the application CPU (i.e. the second processor P2) comprises control, payload and other non runtime control. Generally depending on the required latency and bandwidth and / or time accuracy, the runtime protocol processing is spread over different processing stages, i.e. processors P1, P2. For example, as shown in Figure 3 all 5G NR symbols can be stored in a global memory and the individual antenna data is generated on the FPGA circuit running at runtime. In many protocols, some operations do not require a fast response to the traffic, which can be done by software based processing. Also, in these cases, the data volume usually drops. At the other extreme are fast and continuous protocol functions that have to be implemented in hardware (e.g. FPGA switching). Also, the data volume and thus the available bandwidth is often important for the processing requirement(s).

[0079] It is an object to provide a test equipment, such as the X-STEP product family, with a better support of protocols, e.g. stateful protocols, also called bidirectional protocols. It is a further object to provide a faster and more flexible way to develop protocol support for a test equipment. It is a further object to reduce the overall demand for FPGA / ASIC circuitry. These together allow a more cost efficient implementation and a better protocol support for testing.

[0080] The processing of the protocol elements is divided into parallel and / or sequential (sub) processing modules. Thereby, different protocol elements can be processed in different processing stages (i.e. on different hardware elements) according to different requirements and / or the processing can be split into software based and hardware based processing. Depending on the latency requirements or bandwidth requirements of the data packet stream, different parallel sub streams can be processed in different ways. Also, each stream can be reconfigured during runtime, e.g. by updating the respective processors and / or sub processing modules.

[0081] The test equipment can mimic a baseband unit and / or a radio unit in a test setup. In the antenna interface of a remote unit, the test equipment can mimic a JESD204B / C ADC / DAC device, issuing antenna stimuli to a radio unit or capturing antenna data from a radio unit for e.g. radio performance analysis. The test equipment can operate on the physical and data link layer (i.e. OSI layer 1 and OSI layer 2) and provide bit accuracy visibility of the stimulated and captured data with physical as well as framing error injection and detection capabilities. The test equipment can provide access to all channels of the interface protocol, e.g. file based, allowing control and management of the payload and individual antenna carriers to be generated and post processed by an algorithm model.

[0082] Figure 12Further details of the packet stream by different processors are shown. After creation of the sub-streams, the protocol elements of the sub-streams can be processed by different processors in hardware or by software. The upstream or downstream packet stream is encoded or decoded by the transceiver, respectively, e.g. as shown in the previous figures. Decoding can comprise translating electrical signals from a serial bus, such as a transport network, into a bit sequence. In the present example, a first processor P1 1 is used for processing the preamble, and in case of a current inter-packet gap, preferably by a sub-processing module P1 1. The first processor can be used for processing the Ethernet type (eType) CRC and the encapsulated eCPRI common header, preferably by a second sub-processing module P1 2. It is to be understood that the processing of the first and second protocol elements can be performed by the first and second sub-processing modules of the first processor P1. A third sub-processing module P1 3 of the first processor P1 can be used for processing the MAC destination address MAC DA, while a second processor P2 can be used for processing the MAC source address MAC SA. The sequence of processors and / or sub-processing modules can form a processing path. The payload in the packets of the respective sub-stream can be written to or received from a (global) memory, see Figure 3 . The creation of the sub-streams is performed by a multiplexer MUX which switches the packets belonging to the respective sub-stream onto the sub-stream and the processing path. As indicated by AxC1, AxC2,... in Figure 12 , for the other sub-streams created, the processing of the respective sub-streams can be performed in parallel.

[0083] Figure 13 Further details of the parallel processors of the multiple sub-streams are shown. Herein, timing offsets between the parallel sub-streams corresponding to the antenna carriers AxC1, AxC2, AxC3 are shown. As mentioned, timing offsets between the packets can be necessary to perform tests, e.g. such as the one-way delay measurement described in the eCPRI 2.0 specification chapter 3.2.4.6 “Message Type #5: One-way Delay Measurement”. As already mentioned, the sub-streams can correspond to different antenna carriers. However, another division of the packet stream into multiple sub-streams can be performed instead. The respective offset or timing information can be controlled by an application processor, e.g. as shown in Figure 3 and Figure 12The second processor P2 is shown. This timing information is used by the multiplexer to switch the data packets and protocol elements onto the respective sub-streams. The timing information can be related to the time these data packets arrive at the multiplexer MUX and / or can relate to the transmission over the antenna. This is particularly important when using beamforming, because, unlike MIMO where different spatial streams are emitted on each antenna, beamforming emits the same stream on multiple antennas with a judicious timing offset that increases the range. The phase of each data stream is sent by all antennas at different times, i.e. with different phase offsets, which are calculated so that these different signals constructively interfere at a specific point in space, i.e. the location of the receiver, thereby enhancing the signal strength at that location.

[0084] Figure 14 The protocol stack of the eCPRI protocol is shown. Different protocol layers can require high or low latency or high or low bandwidth, as Figure 14 illustrated on the right. The higher the protocol layer, the higher the latency that can be required and the smaller the bandwidth that is required. The lower the protocol layer, the lower the latency that can be required and the higher the bandwidth that is required. These requirements can be reflected when writing and distributing the instructions for protocol processing in the main program code. As Figure 14 depicted by the shaded areas in, the protocol processing instructions can be written in the program code, which can be divided into code segments (with different requirements for the processing of protocol elements) and compiled into object code, which can then be distributed to different processors depending on the assigned requirements. For example, as Figure 14 shown, the Ethernet physical layer (PHY) Ethernet MAC and security functions can be processed by the first processor P1 or a corresponding one or more sub-processing modules in hardware, as appropriate. The UDP, TCP, SCTP layers can be processed by a second processor or sub-processing module in hardware or by software, depending on the specific requirements of the implementation. This can be a co-processor of the first processor, a sub-processing module of the first processor or a separate processor. The eCRI services such as user data, real-time control and other eCRI services and the eCPRI protocol layers can be processed by a further third processor P3. It will be appreciated that the allocation of latency requirements and / or bandwidth requirements to the code segments of the main program code can depend on the specific application. In one case, the second processor can be responsible for processing the UDP protocol layers, while in another implementation where UDP requires higher bandwidth or lower latency, the first processor can be used to process these protocol layers.

[0085] Operation, administration and maintenance (OAM) functionality is critical for operating the network, fault isolation, service and path awareness. Ethernet also provides a rich set of OAM capabilities for layer 2 packet networking and transport applications. Depending on the case, a first processor P1 is used for handling the Ethernet PHY layer, while a third processor is used for handling the higher level OAM protocol layers.

[0086] The synchronization and C&M (control and management) plane is not covered by the eCPRI protocol and therefore relies on existing methods such as PTP or SyncE. Similarly, the processing of the protocol layers can be distributed among the first, second and third processors.

[0087] Figure 15 An embodiment of the (eCPRI) protocol processing by different processors P1, P2 of a test device, e.g. emulating a distributed unit DU, is shown. Here, a detailed view of the processing of different protocol elements is provided. The data packet stream can be received or transmitted based on the processing of the protocol elements of the transport protocol as shown. For this, a high-speed serial transceiver can be employed. The data packets of the data packet stream can then be switched onto the respective sub-streams SUB1, SUB2, SUB3 or vice versa, the sub-streams can be combined to form a data packet stream which is transmitted to e.g. a DUT, in this case a radio unit RU. Now, the first processor P1, here an FPGA, can be used to (in hardware) process the physical layer PHY of each data stream in the respective processing path, which is indicated by the arrows in Figure 15 In a second sub-processing module P12, Ethernet MAC (DA) address processing can be performed (in hardware) for one or more of the sub-streams SUB1, SUB2. However, the second sub-processing module P12 can not perform any processing at all for the third sub-stream SUB3. It is to be understood that multiple first processing modules P11, P12 can be provided which perform processing (in hardware) for the respective sub-streams.

[0088] For the first sub-stream SUB1, the second processor P2 can (by software) process the Ethernet MAC (SA) address and can also be used to process the antenna data, i.e. the payload data, e.g. for the purpose of analytics as described before. In the second sub-stream SUB2, the second processor P2 can process the synchronization plane data, e.g. (by a sub-processing module of the processor P2). In the third sub-stream SUB3, the second processor P2 can be used to process the eCPRI management plane and the MAC address. Thus, depending on the latency requirements, the data processing is shared among the multiple processors P1, P2 and / or their respective sub-processing modules, in which the processing can be done by the first processor in hardware or by the second processor in software.

[0089] The DUT itself is capable of transmitting and / or receiving data packet streams. To this end, the DUT itself can comprise one or more processors, e.g. for sampling and digitizing IQ data. In case of a radio unit, the processing of protocol elements of the transmission protocol, such as MAC DA and MAC SA, can be done completely in hardware, as shown.

Claims

1. A computer-implemented method for protocol processing including main program code, said main program code including instructions for processing different protocol elements of a data packet stream (S1) of a transport protocol, wherein, The data packets in the data packet stream have a header and a payload, and the header retains overhead information about packets, services, and other transmission-related data. The protocol elements correspond to the overhead information. The main program code includes multiple code segments. The method includes the following steps: Assign latency and / or bandwidth requirements to the code segment of the main program code; and Each code segment in the code segment is compiled into corresponding object code according to the allocated latency and / or bandwidth requirements, so that each object code in the object code is executed in hardware and by software by different processors according to the specific requirements set of the code segment of the main program code, wherein the processors have different processing capabilities, a first processor (P1) processes a first type of protocol element according to a first object code, and a second processor (P2) processes a second type of protocol element according to a second object code, wherein the first type and the second type of protocol element are different. The target code is distributed across the appropriate processors for execution.

2. The method according to claim 1, further comprising the following step: The main program code is divided into multiple code segments.

3. The method according to claim 1 or 2, further comprising the following step: The first and second sub-streams of the data packet stream are processed according to the first target code executed by the first processor; as well as The first sub-stream and the second sub-stream are processed according to the second target code executed by the second processor (P2); as well as The first sub-stream and the second sub-stream are processed according to the third object code executed by the third processor (P3).

4. The method according to claim 1 or 2, further comprising the following step: The first code segment of the main program code is compiled by a first compiler (C1); The second code segment of the main program code is compiled by a second compiler (C2); as well as The third code segment of the main program code is compiled by a third compiler (C3).

5. The method according to claim 1 or 2, in, The protocol element requires the payload of data to be reliably transmitted over the transport network, and / or the protocol element corresponds to an element of an Ethernet frame, and / or The protocol elements include a preamble, start-of-frame delimiter, MAC destination address, MAC source address, 802.1Q tag, Ethernet type or length, frame check sequence, and / or inter-packet gap.

6. The method according to claim 1 or 2, further comprising the following step: The data packets of the data packet stream (S1) are divided into a first sub-stream and a second sub-stream.

7. The method according to claim 3, further comprising the following step: The first sub-stream is processed according to a first processing path, the first processing path including one or more sub-processing modules of the first processor (P1) and one or more sub-processing modules of the second processor (P2).

8. The method according to claim 7, further comprising the following step: The first protocol element of the data packets of the first sub-stream is processed by the sub-processing module of the first processor (P1) in the processing path; as well as The second protocol element of the data packets of the first sub-stream is processed by the sub-processing module of the second processor (P2) in the processing path.

9. The method according to claim 8, further comprising the following step: The second sub-stream is processed according to a second processing path, the second processing path including one or more sub-processing modules of the first processor (P1) and one or more sub-processing modules of the second processor (P2).

10. The method according to claim 1 or 2, further comprising the step of: The first protocol element of the data packets of the second sub-stream is processed by the first sub-processing module of the first processor in the second processing path; as well as The second protocol element of the data packets of the second sub-stream is processed by the second sub-processing module of the second processor (P2) in the second processing path.

11. The method according to claim 1 or 2, wherein, The step of dividing the data packet stream (S1) includes: The data packet stream is received serially (S1); and The data packet stream is transformed in parallel (S1); and The first substream and the second substream are multiplexed in parallel onto the first processing path and the second processing path.

12. The method according to claim 1 or 2, wherein, The step of dividing the data packet stream (S1) includes: Assign data packets associated with the first antenna carrier (AxC1) to the first substream; and Data packets associated with the second antenna carrier (AxC2) are assigned to the second substream.

13. The method according to claim 1 or 2, further comprising the following step: The first and second sub-streams of the data packet stream (S1) are processed by the third processor (P3).

14. The method according to claim 1 or 2, wherein, The first sub-processing module of the first processor (P1) performs low-level line coding and real-time functions. The second sub-processing module of the first processor (P1) performs data stream operations, and The second processor (P2) performs control functions.

15. The method according to claim 14, wherein, The first sub-processing module is an FPGA.

16. The method of claim 14, wherein, The second sub-processing module is a soft microprocessor.

17. The method of claim 14, wherein, The second processor is a CPU.

18. The method according to claim 1 or 2, wherein, The sub-processing modules of the first processor, the second processor, and the third processor share the local memory (M1, M2, M3, M4) of the first processor, the second processor, and the third processor. The first processor, the second processor, and optionally the third processor share a global memory (GM1, GM2) for storing 5G NR symbols.

19. An apparatus operable to perform the steps of the method according to any one of claims 1 to 18.

20. The apparatus according to claim 19, wherein, The device is a testing equipment.

Images