Timing accuracy for radio data packets

Abstract

A method for determining timing accuracy of one or more radio data packets (10), the method comprising the steps of generating excitation data (20), the excitation data (20) comprising a radio data packet (10) and a reference time (TRa) for transmitting the radio data packet (10) over the air, storing the excitation data (20) on a test device (1), replaying the excitation data (20) by the test device (1), and determining timing accuracy of one or more radio data packets (10). In order to determine the timing accuracy of the transmission of one or more radio data packets (10) by the device under test (2, 3).

Description

Technical Field

[0001] The present disclosure relates to the timing of one or more radio data packets. In particular, the present disclosure relates to transmitting and / or receiving radio data packets through a fronthaul network. More specifically, the present disclosure relates to testing of radio equipment. Background Art

[0002] In the fronthaul of a radio network, antenna data needs to be transmitted over a longer distance. Therefore, strict throughput latency, jitter, timing and synchronization requirements need to be adhered to. Therefore, transmission via the fronthaul, for example between the radio unit RU and the baseband unit BBU, requires strict synchronization and timing mechanisms, such as the Precision Time Protocol (PTP), to ensure proper transmission and / or reception of data packets.

[0003] To ensure compatible synchronization, the proper operation of the radio equipment of the radio network needs to be verified. To do this, tests of the radio equipment need to be performed. For example, the test set can also act as a PTP master and ensure that the fronthaul messages are replayed to honor the specified timestamps that enable testing of the required timing windows. Summary of the invention

[0004] It is therefore an object of the invention to improve the checking and verification of the transmission and / or reception of radio data packets in the fronthaul with respect to timing.

[0005] This object is achieved by the independent claim. Advantageous embodiments are given in the dependent claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 A diagram of a test system including a test device coupled to a baseband unit and a radio unit is shown.

[0007] Figure 2 A diagram of a test system comprising a test device coupled to a radio unit is shown.

[0008] Figure 3 A diagram showing the timing requirements between the baseband unit and the radio unit.

[0009] Figure 4 A diagram of a radio data packet is shown.

[0010] Figure 5 A diagram of an excitation comprising a radio data packet and a reference time is shown.

[0011] Figure 6 A diagram showing a test setup for replaying and recording fronthaul radio data packets.

[0012] Figure 7A diagram showing the transmission of a radio data packet and a reference pulse is shown.

[0013] Figure 8 A visualization showing the fronthaul of RF symbol transmission and the transmission of radio data packets over acceptable time windows.

[0014] Figures 9 to 15 Exemplary steps according to various embodiments are shown. DETAILED DESCRIPTION

[0015] exist Figure 1 In a test system, the baseband unit BBU performs baseband processing on a specific air interface for wireless communication through one or more radio frequency channels. The radio unit RU performs radio frequency processing to convert the baseband data output from the BBU into a radio frequency signal for radiation from one or more antennas coupled to the RU, and / or to generate baseband data for the BBU from the radio frequency signal received at the RU via one or more antennas. The RU is usually installed near one or more antennas, usually at the top of the tower, and the BBU is usually installed in a more accessible location, usually at the bottom of the tower. However, depending on the situation, the RU and the BBU can be collocated, for example, in a laboratory. The BBU and the RU are usually connected by one or more optical fiber links. The interface between the BBU and the RU is defined by fronthaul communication link standards such as the Common Public Radio Interface (CPRI) or Enhanced Common Public Radio Interface (eCPRI) specification family, the Open Base Station Architecture Active (OBSAI) specification family, and the Open Radio Interface (ORI) specification family.

[0016] Frequency domain fronthaul is a functional split where IFFT / FFT (Inverse Fast Fourier Transform / Fast Fourier Transform) can be moved from the BBU to the RU. Frequency domain samples are sent over the fronthaul instead of time domain samples. The RU will have information about resource allocations for different UEs through the communication channel. The new eCPRI interface specification "eCPRI Specification V1.0 (2017-08-22)" is already available.

[0017] For deployment scenarios in which the radio unit RU (sometimes also denoted as radio remote unit RRU or remote radio head RRH or (evolved) radio equipment €RE) and the baseband unit BBU (sometimes also denoted as (evolved) radio equipment controller (e)REC or distributed unit DU) are separated, the signals received from one or more antennas must be transmitted on the medium connecting the RU with the BBU, since signal combining is usually performed at the BBU. Typically, the interface for the connection between the BBU and the RU is called the fronthaul interface. The signals on the fronthaul can be complex time domain samples, such as specified in the traditional common radio interface CPRI or today's eCPRI. The digitized waveform can be transmitted from the BBU to one or more RUs via the fronthaul via one or more radio aggregation units (RAUs) and vice versa. As shown in the figure, the BBU can be connected to the core network, the core, and possibly to other BBUs (not shown) via one or more backhauls or cross-hauls. One or more radio data packets can therefore be transmitted via the fronthaul, for example between the radio unit and the baseband unit. In this case, the test device can be coupled to the radio unit and / or the baseband unit via the fronthaul, which will be discussed later. Thus, one or more wireless packets may be transmitted from the test device to the RU or BBU, or vice versa.

[0018] User Equipment (UE) signals are power limited and as the path loss varies with the distance to the UE, a large dynamic range is encountered when these signals are represented digitally; it can be assumed that for complex frequency sampling, 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, the propagation of the radio signals needs to be modeled in order to test the functionality of the radio system and its components. Since the capacity of the fronthaul is limited, it is desirable to find ways to optimize and / or monitor the usage of the fronthaul.

[0019] High-speed data services are always the goal of operators and the need of users, especially professionals. The quality of synchronization directly affects the quality of service. In addition, for telecommunication system performance, radio equipment requires good synchronization to achieve proper separation and avoid channel interference.

[0020] The open fronthaul interface linking the ORAN distributed unit (O-DU) corresponding to the baseband unit BBU and the ORAN radio unit (O-RU) includes 3 main planes to ensure a reliable connection between the distributed unit and one or more radio units. The S plane, known as the synchronization plane, plays a role in synchronizing the distributed unit with the radio unit in terms of time, phase and / or frequency synchronization. In addition, the management plane (M plane) is responsible for supporting FCAPS (fault, configuration, accounting, performance, security) of the O-RU. In addition, the control plane (C plane) and the user plane (U plane) cover, for example, data configuration and feature parameters and actual radio data expected to be sent by the user during operation and / or testing.

[0021] In the uplink direction, the O-RU receives a wireless signal through an antenna element. The wireless signal, for example in the form of an RF symbol, is also typically represented as an RF signal, and can then pass through an analog beamforming block not shown and / or an analog-to-digital converter block not shown, whereby the data generated is ready to be converted from the time domain to the frequency domain by a fast Fourier transform (FFT) block not shown. Basic filtering and digital beamforming are then performed to extract the actual data that can be compressed into IQ data. The IQ data can then be provided in the form of one or more radio data packets for transmission via the fronthaul.

[0022] In order to test the functionality of the baseband unit and / or the radio unit, a test device can be used which provides a stimulus to the radio unit and / or the baseband unit, for example in the form of one or more radio data packets. The test device 1 can additionally or alternatively store data transmitted and / or received by the baseband unit and / or the radio unit. Thus, the test device can be used to test and / or monitor and / or analyze the functionality of the baseband unit and / or the radio unit.

[0023] Figure 2 A diagram of a test system comprising a test device is shown, wherein the test device comprises the functionality of a baseband unit, for example the functionality of a simulated baseband unit. Depending on the circumstances, the test device itself may comprise the functionality of a baseband unit, for example, in order to test a radio unit. In order to test the BBU and / or RU, the test device may transmit a stimulus to one or more devices under test via a fronthaul (link). The stimulus typically comprises IQ data to be processed by the device under test.

[0024] Since the IQ data transmitted via the fronthaul is in the frequency domain, the RF symbol duration directly affects the amount of time required for the radio data packet to be transmitted. In other words, all bandwidths, amounts of data compression, and eRE data rates can affect the transmission time. In addition, since the IQ data transmitted via the fronthaul (e.g., using eCPRI) is in the frequency domain, the RF symbol duration directly affects the time required for the data packet to be transmitted. In other words, all bandwidths, amounts of data compression, and radio unit data rates can affect the transmission time within the entire fronthaul.

[0025] like Figure 3 As shown, for example in an eCPRI network, all nodes should be synchronized in different domains: frequency, time and phase domains. In the downlink direction, there are the following timing parameters: T12 is the transmission network delay between port 1 and port 2. T12 can vary in intervals called transmission variations. It is bounded by T12min and T12max. T12min is the minimum delay of the fastest path data required to link two nodes. T12max is the maximum end-to-end one-way delay. Therefore, the user data will adopt a delay T12 such that: T12min <T12<T12max。

[0026] T1a is the timing difference between the transmission of a radio data packet at the output point R1 of the eREC and the transmission of an IQ sample at the antenna Ra of the eRE. The earliest transmission of an IQ sample generated from the transmitted radio data (in one or more radio data packets) is the RF symbol time Tsym at the antenna Ra.

[0027] T2a is the timing difference between receiving a radio data packet at the input point R2 of the eRE and transmitting an IQ sample (as one or more RF symbols) at the antenna Ra. The earliest transmission of an IQ sample at the antenna is the RF symbol time Tsym. If a user data packet arrives outside the receive window (i.e., earlier than T2a max or later than T2a min), the radio data packet may not be used and therefore the IQ samples and RF symbols associated with the radio data packet may not be generated correctly.

[0028] Since consideration of packet timing and required time advance values ​​are of primary concern in making, for example, an ORAN-based fronthaul network work reliably, sufficient timing accuracy is required.

[0029] Figure 4A diagram of radio data packets 11-16 is shown. For example, control plane data (also known as C-plane) is sent separately from user plane data (also known as U-plane). For the downlink case, the C-plane radio data packets 11, 13 are sent before the U-plane radio data packets 12, 14, 15, 16 with a specific time period, which allows the O-RU to process the next received U-plane radio data packet from the same source BBU (e.g. O-DU) and prepare for it. This C-plane data packet 11, 13 is sent again in the next time slot. Depending on the U-plane characteristics and pattern, the C-plane can be an identical copy or can be reconfigured. The C-plane and U-plane radio data packets 11-16 may include data encapsulated using eCPRI or IEEE1914.3 mechanisms. As Figure 4 As shown, the control information and IQ data are preceded by an IP and / or Ethernet header and a C-plane header or a U-plane header, respectively, as shown in the small box at the beginning of data packets 11-16. The IQ data can be in the frequency domain. The control information radio data packet is always sent before the U-plane data packet. Each time slot C-plane data packet precedes the U-plane radio data packet by a specific time period defined by a time management parameter called T cp_adv_dl. This amount of time allows the O-RU to update the beamforming weights linked to the user data in the DL direction. Similarly, the C-plane packets in the UL data stream are used to adapt the processing of the O-RU to the U-plane data arriving at its antenna.

[0030] The U-plane radio data packet is usually divided into two parts. First the scheduling, beamforming command information is defined, followed by the IQ data. The U-plane data can actually exceed the maximum ORAN specified data packet size. In this case, the data is split over multiple radio data packets. Typically, the data is organized into a number of segment types. Data belonging to different segments should be sent separately. Whenever the IQ data does not achieve 1-byte alignment, padding bits are added at the end of the segment.

[0031] Thus, when receiving an RF signal on the RU antenna (uplink direction), the radio unit digitizes the data and encapsulates it into IQ data, for example according to the (e)CPRI protocol. The radio data packet including the IQ data can then be transmitted, for example, via an optical fiber, to the BBU, and possibly backhauled afterwards. Thus, the RF symbol can correspond to one or more IQ samples provided in one or more radio data packets and transmitted, for example, via a fronthaul. In the downlink direction, the baseband unit sends user data to the RU encapsulated according to a fronthaul protocol such as the (e)CPRI protocol. The user data may also be in the form of IQ data and present in one or more radio data packets, for example, transmitted on the fronthaul. The (e)CPRI frame will be unpacked, converted to an analog signal, and then typically transmitted over the air as an RF symbol or RF signal. For example, a CPRI radio frame consists of a 10ms time period. Among them, 256 basic frames (each basic frame is 260ns) constitute a superframe with a period of 66.7μs. The set of 150 superframes takes the shape of a 10ms frame as a radio frame.

[0032] As mentioned above, transmission of one or more radio data packets via fronthaul requires sending packetized control and user plane data from the O-DU to the O-RU in advance so that the radio unit can perform the required data processing and digital-to-analog conversion at a time well ahead of the actual symbol time in the air interface RF antenna. The "advance amount" is configurable, for example, as per the O-RU requirements, and it is important to verify the correct arrival time window in terms of ensuring the correct operation of the fronthaul network and interoperability between the O-DU and the O-RU. The problem in this verification is that the actual RF side symbol time is not visible to the fronthaul, and without such a symbol time reference, the radio data packet arrival time window cannot be reliably established, and it is impossible to say whether a packet arrived too early (exceeding the buffering capacity in the radio unit) or too late (the radio unit did not have enough time to prepare the symbol data for RF transmission).

[0033] Furthermore, the lack of such an RF time reference in the radio test system (modeled or real SoC) complicates the data analysis on the RF interface side in the ADC / DAC interface of the radio unit. As a result, the position of the RF symbols in time is unknown and cannot be reliably verified by means of IQ data analysis.

[0034] Therefore, it is recommended to include a reference time as part of the stimulus to be transmitted to the fronthaul link. Figure 5As shown. The reference time may mark the RF symbol time, i.e., the point in time at which the transmission of an RF symbol of one or more radio data packets begins. Thus, the RF symbol / frame reference is known and / or always synchronized with the radio data packets of the excitation data. A reference signal (e.g., in the form of a pulse) representing the reference time may fork from the excitation data to its own signal path, e.g., prior to the fronthaul transmission. The signal path for the reference signal may be, e.g., a separate cable in an HW-based environment, or a dedicated RF frame pulse signal, e.g., in a model-based environment.

[0035] Similarly, along with the radio data packet capture from the fronthaul, a reference signal can be recorded as part of the data capture. Thus, the timing of both the digital fronthaul domain and the analog RF domain can be combined.

[0036] By recording the precise timing of a reference pulse on the RF side (typically a 1PPS signal in an RF test environment) as part of the data packet capture, a detailed symbol timing analysis can be performed (e.g., by interpolation and / or extrapolation) to establish one or more acceptable arrival time windows for each RF symbol, respectively. Given the required C-plane and U-plane advance values, it can be determined whether the radio data packet carrying the physical resource block (PRB) portion of the symbol falls within or outside of the acceptable time window. By linking the ADC / DAC data to the RF frame, it can be determined how to convert the PRB to time domain data, i.e., whether the RF symbol timing on the RF side is within an acceptable time window.

[0037] Therefore, a reference time, in particular a reference pulse, is generated and included in the stimulus data, for example, for a device under test such as a radio device (e.g., a radio unit). Therefore, the reference time can be part of the stimulus data. The stimulus data (i.e., radio data packets and / or reference time) can be generated according to a radio modeling environment (e.g., modeling one or more radio channels). As mentioned above, the reference time can be recorded, for example by recording a reference pulse, as part of a (time-stamped) radio data packet capture. For example, PCAP is widely used as an Ethernet-based packet capture format, but it does not support the transmission or reception of such auxiliary information. A formatting of stimulus, for example, including radio data packets, is proposed, which allows the definition, injection, time stamping and / or capture of external events, in particular reference times. Preferably, these external events (such as reference times or corresponding reference signals) are not Ethernet or O-RAN data packets and do not occur in the fronthaul, for example, they are not transmitted over a high-speed serial data link.

[0038] The reference time can be used to determine the RF frame or RF symbol boundaries. Based on the expected RF frame or RF symbol boundaries, the timing accuracy of the device under test can be determined. To this end, the actual RF frame or RF symbol boundaries can be determined, comparing the expected RF frame or RF symbol boundaries (determined based on the reference time). For test systems (analog, emulated and post-silicon) where it is not possible to obtain such reference time from the global navigation satellite system and / or where the O-RAN synchronization plane facility (PTPv2) does not yet exist, the ability to generate reference signals for RF frame boundaries may be necessary. Generating such RF symbol / frame reference time into a test system isolated in a timing manner enables synchronization across the entire test system, for example, from the excitation source of the fronthaul to the data sink in the ADC / DAC interface of the radio unit, and vice versa. Using the reference time as part of the excitation data makes it possible to align the radio data packet timing with the RF symbol / frame time (or intentionally misalign it). Optionally, the reference time or other external events can be visualized together with the radio data packets and / or the excitation data. This allows further analysis of the radio data packet timing on the fronthaul and / or the device under test, in particular RF symbol processing in the ADC / DAC of the analog and / or digital RF interface of the radio unit, for example. Using the timestamps of the symbol / frame pulses on the RF side, the RF symbol boundaries can be interpolated and extrapolated from the reference time (or corresponding reference pulse) based on the subcarrier spacing and / or the cyclic prefix length, by, for example, calculating the RF symbol duration for each antenna carrier separately. Having a timing reference pointing to the RF symbol or RF frame boundaries in the RF interface, the RF symbol positions, in particular one or more symbol boundaries, can be reliably interpolated from the reference time (e.g., the corresponding reference pulse), for example, in order to check the time division duplex (TDD) switching pattern and the content of each RF symbol.

[0039] Go to Figure 6 , the reference times may be stored as part of a file, for example in an (adapted) PCAP format. For example, the reference times may be stored in a PCAP file as a separate file or a separate grouping in a format such as PCAP, for example in a memory of the test device, e.g. Figure 6 DDR in. Wherein, the reference time can be marked as TRa, i.e. external event. Therefore, when processing the stimulus data, the reference time is separated before the radio data packet is transmitted via the fronthaul. The reference time can be a 1PPS or 10ms frame pulse signal, which is inserted into the stimulus data based on the radio data packet. The reference time can also be recorded, for example by recording the reference pulse, as part of the fronthaul packet capture. This allows, for example, to calculate and thereby analyze the radio data packets and corresponding arrival time windows at one or both ends of the test system (for example at the BBU or RU) by capturing the radio data packets and the reference pulses by the test device.

[0040] like Figure 6 As shown, the test device may include a transceiver TR, which is connected to a (separate) receiver module RX and / or a transmitter module TX, for example, to form a data path to and / or from a memory (e.g., DDR), respectively. Depending on the specific situation, the transmitter and / or receiver RX, TX may be included in the transceiver TR, for example, or in a data Mux module. The data Mux module may provide bit-level multiplexing in the TX and RX directions. For example, the data Mux function is described in clause 83.5.2 of IEEE Std802.3ba-2010.

[0041] For example, in the uplink, the test set can capture inbound fronthaul protocol frames (i.e., radio data packets including IQ data) into its memory (e.g., DDR4 memory) together with high-speed serial data capture, e.g., from a fiber link, e.g., via an SFP or QSPF interface, such as Figure 6 As shown, the test device 1 is also capable of recording one or more auxiliary timing pulses, such as a reference signal as part of the captured data. The test device can receive the reference signal via a separate data path. One or more reference signals are preferably synchronized with the inbound data so that the reference signal (e.g., in the form of a reference pulse) can be used to record a reference time, thereby marking a time event for analyzing the captured radio data packet. For example, when the reference signal is detected, the reference time can be saved as part of an XGMII data structure encoded by, for example, 8b10b, such as in its spare bits. The spare bits are generated as follows: 8+K information that needs to be stored in order to be able to recover the original 10b conversion word of the 8b10b code leaves a spare bit when the input code word is saved as a 4-bit group to occupy a 40-bit area in the memory (e.g., RAM) of the test device. From the perspective of memory and / or software, 40 bits are convenient numbers because data is usually read one byte (8 bits) at a time. Therefore, 5 bytes correspond to an even number of 40 bits, and no additional operations, such as transfer operations, are required. Therefore, a total of 4 spare bits are left for every 4 protocol data words. These one or more spare bits may be used to record a reference signal (eg, indicating a reference time) or another external event.

[0042] For example, a software application for protocol generation and analysis (such as the software modules described herein) can transmit data, such as one or more radio data packets, via the transceiver TR by writing the data (from a memory, such as DDR) to the TX module. Similarly, the software application can receive data, i.e., data in the form of one or more radio data packets, via the transceiver TR by receiving the data from the RX module. Figure 6As shown, the reference pulse can be received and / or transmitted by a signal multiplexer module (Signal Mux) connected to the RX and / or TX modules. As explained, the reference pulse can be saved as part of a line coded (e.g. 8b10b) data structure. Similarly, the reference pulse is generated when auxiliary data (indicating a reference time) is present in the excitation data to be transmitted.

[0043] Software modules such as protocol generators and / or analyzers may be configured to identify reference signals, for example, based on spare bit positions in the XGMII data. For example, a reference pulse in position spare0 is (automatically) identified as a 1 pulse per second (PPS) boundary in the RF frame or air interface, i.e., reference time T_Ra. The reference time may be used to correlate RF time with fronthaul time and perform fronthaul time window calculations.

[0044] A software module such as a protocol generator and / or analyzer may (pre)generate a protocol RF frame into a memory of the test device (such as a DDR4 memory) as stimulus data to be transmitted to the device under test (DUT). It should be understood that a protocol is an internal protocol for generating, storing and / or transmitting radio data packets within the test device. As part of the generation of the protocol RF frame, e.g. Figure 7 As shown, a general I / O signal (pulse), for example in the form of auxiliary data, may be inserted into the protocol data. The reference signal is time-synchronized with the protocol data and may be used to indicate time events and / or may be used as a trigger for an external device (e.g. a DUT and in particular a radio unit or a baseband unit). Specifically, for fronthaul protocols such as O-RAN, and for example the need to signal a reference time to a radio frequency (RF) analyzer (e.g. a radio unit) in the antenna side of the DUT, the reference signal may be in the form of a pulse and may be generated, for example based on the auxiliary data, to coincide with a pre-calculated RF (sub) frame, RF time slot and / or RF symbol boundary T_Ra=0. As Figure 7 As shown, when the stimulus is transmitted at a desired advance time T=<desired advance>, for example, a reference pulse is transmitted (by the test device). That is, before the reference pulse (i.e., T_Ra frame boundary pulse) is transmitted, a desired number of radio data packets of a particular RF symbol or RF frame have left the test device, because of the advance requirements of the fronthaul and / or the device under test.

[0045] For example, in a protocol processing module such as a transmitter module TX, auxiliary data is extracted from the excitation data, or more specifically, auxiliary data is extracted from the (internal) protocol data. Based on the auxiliary data, a reference pulse can be generated, for example, by a signal multiplexer, a signal Mux. The signal multiplexer can then send a reference pulse 60 to, for example, an (external) connector of a (test device). For example, an SMA (subminiature A-type) connector can be used as a connector. The radio data packet from the excitation data is distributed, for example, via an SFP or QSFP port to control the data multiplexer of the forward transmission. The forward transmission of the radio data packet from the radio data packet of the excitation data can occur via an SFP or QSFP optical fiber module for high-speed serial transmission. The waiting time of these two parallel transmission paths (i.e., for the radio data packet and the reference signal) is balanced, so that the reference pulse and its corresponding radio data packet arrive at their destination (e.g., such as a DUT of a radio unit and / or other RF device) at the same time, assuming that the connection distance between the test device and the device under test is short, so that the forward transmission delay becomes negligible. The proposed method, apparatus and system for generating RF frame reference pulses may be applied, for example, in early system-on-chip (SoC) testing, where more complex and cumbersome mechanisms are generally not available.

[0046] Go to Figure 8 , by recording, e.g. saving, a reference time TRa, past and future RF symbol boundaries, i.e. Tsym, can be interpolated and / or extrapolated. Furthermore, specific time advance values ​​(for control and / or user plane) can be taken into account, which enables determination of a time window for transmission of a radio data packet at a baseband unit, e.g. an O-DU, or a time window for reception at, e.g. a radio unit, e.g. an O-RU, depending on which end of the fronthaul (link) of the radio data packet is captured, i.e. whether the (O-RAN) fronthaul latency (i.e. T12) needs to be taken into account.

[0047] This way, radio data packets with correct timing lie within the acceptable time window, and data packets that are too early or too late fall outside the time window. Timing violations thus become apparent. Furthermore, the positioning of the radio data packets can be visualized, and the user is able to determine whether a radio data packet was received at the beginning, center or end of the time window. With the captured radio data packets, the user can easily see if the delay is due to high link utilization or if there is another problem. Figure 8 In FIG. 1 , an acceptable (transmission) time window of an RF symbol (symbol 0..13) is shown, and the radio data packets of the corresponding RF symbol are overlaid. Thus, the delay of the radio data packet transmission becomes apparent. As explained before, the time window can be generated based on the reference time TRa in the excitation data.

[0048] Fig. 9 Exemplary steps according to a first embodiment are shown. In a first step S1, stimulus data including radio data packets and reference times are generated, for example using a software module for protocol generation and / or analysis. The software module may (pre)generate protocol RF symbols and / or RF frames into a memory (e.g., DDR4 memory) of a test device as stimulus data to be transmitted to a device under test (DUT). To this end, an RF frame may be represented by one or more radio data packets. The radio data packet may include IQ data representing the RF symbol and / or RF frame. The stimulus data may also include a reference time for transmitting the radio data packet (10) over the air.

[0049] In a second step S2, the stimulus data on the test device is stored on the test device. For example, a software module for protocol generation and / or analysis may access a memory on the test device. The software module may be executed using a processor of the test device, or may be executed on a separate device and access the memory of the test device to store the generated stimulus data.

[0050] In a third step S3, the stimulus data are replayed by the test device. To this end, the radio data packets of the stimulus data can be transmitted on the fronthaul (network), and the reference time can be forked and transmitted to the device under test via a separate link. For this purpose, a software module accessing a memory can be used, such as the software module for protocol generation and / or analysis mentioned above. The stimulus data can be replayed once or multiple times, i.e. multiple repetitions.

[0051] In step S4, the timing accuracy may be determined.

[0052] The reference time may be used to compare actual RF symbol times at the antenna to the reference time and thereby determine the timing accuracy of radio data packets on the fronthaul and / or the device under test (eg, radio unit).

[0053] exist Fig.10 middle, Fig.10 Further method steps are shown. In a fifth step S5, reference times may be inserted between radio data packets. Thus, the step of generating excitation data may also include the following steps: in step S6, one or more radio data packets and auxiliary data representing reference times are formatted (inserted with reference times) according to the data format of the protocol. For example, the radio data packets may be generated first and then the reference times may be inserted. In step S2, the excitation data may then be stored as described herein.

[0054] exist Fig.11. In step S5, the reference time is inserted into the stimulus data as described above. In step S7, auxiliary data representing the reference time is inserted temporally synchronously with the radio data packets, preferably with the IQ data of one or more radio data packets. Thus, in step S2, the stimulus data is stored, for example, in a memory of the test device, for example for playback as described herein.

[0055] exist Fig.12 Additional method steps are shown in . In step S8, one or more RF symbol times of one or more radio data packets of the excitation data can be determined based on the reference time T_Ra. For example, based on the reference time stored in the excitation data (represented by the auxiliary data therein), the RF symbol time can be calculated. The RF symbol time can be calculated (and therefore corrected) based on the alpha and beta parameters of the forward transmission. In addition, one or more RF symbols can be extrapolated or interpolated based on the reference time. In step S9, the RF symbol time determined (according to step S8) can be compared with the actual RF symbol time (at the air interface or antenna of the DUT). Therefore, based on the comparison of the RF symbol time (according to step S9), the timing accuracy of the radio data packet can be determined in step S4.

[0056] exist Fig.13 Further method steps are shown in . In step S2, as described above, the stimulus data can be stored. The storing step can include storing the stimulus data in a data file according to the data format of the protocol in step S9. The format can be selected to provide (in addition to the radio data packets and / or IQ data) data entries of the reference time, for example in the form of auxiliary data (indicating the reference time). In step S3, the stimulus data in the protocol format can first be stored in a memory of, for example, a test device. Therefore, the format already includes radio data packets. The radio data packets can be (pre)generated by a software module for generating and storing stimulus data. The stimulus data in the form of one or more radio data packets are ready to be transmitted from the memory. Alternatively, the IQ data can be stored and packaged into radio data packets. In this case, the radio data packets are (only) created from the IQ data when they are transmitted via the fronthaul.

[0057] In step S10, auxiliary data is extracted from the excitation data, e.g. before transmitting one or more radio data packets also included in the excitation data. In step S11, a reference signal is generated based on the auxiliary data. As described above, the auxiliary data is used to generate the reference signal using, e.g., a data and / or signal multiplexer. The reference signal 60 can then be transmitted by the test device, e.g., to the device under test.

[0058] exist Fig.14 . In step S3, the stimulus data may be replayed. Step S3 may include steps S12 and / or S13, or may be followed by steps S12 and / or S13. In step S12, a radio data packet is transmitted by the test device, and in step S13, a reference signal is transmitted by the test device, preferably twice, to the device under test.

[0059] In step S14, Fig.15 As shown, in step S15, the device under test receives a radio data packet as well as a reference signal. In step S16, one or more RF symbols are created based on the IQ data in the radio data packet received by the DUT. The RF symbol time of the device under test can then be compared with the symbol time determined based on the reference signal (representing the reference time). Therefore, in step S17, the time shift, i.e., the time difference, between the reference time and the actual time at which the RF symbol exists at the air interface or antenna can be determined in order to determine, for example, the timing accuracy of the radio data packet transmission and processing performed by the DUT.

Claims

1. A method for determining the timing accuracy of one or more radio data packets (10), the method comprising the following steps: generating excitation data (20), the excitation data (20) comprising the radio data packet (10) and a reference time (T_Ra) for transmitting the radio data packet (10) over the air, The stimulus data (20) are stored on a test device (1) and replayed by the test device (1) in order to determine the timing accuracy of the transmission of the one or more radio data packets (10) by the device under test (2, 3).

2. According to the method described in the preceding claim, the step of generating excitation data (20) further comprises the step of formatting one or more radio data packets (10) and auxiliary data (21) representing a reference time (T_Ra) according to a data format of the protocol (thereby inserting said reference time).

3. The method according to the preceding claim, inserting said auxiliary data (21), said auxiliary data representing said reference time (21) being temporally synchronized with said radio data packet (10), preferably temporally synchronized with IQ data of said one or more radio data packets (10).

4. The method according to the preceding claim, the reference time (TRa) indicating a point in time at which one of the one or more radio data packets (10) is / should be present at the antenna interface (Ra) of the device under test (2, 3).

5. The method according to the preceding claim, the reference time (TRa) indicating an RF frame and / or RF symbol boundary for transmitting at least one of the one or more radio data packets (10) via an antenna interface (Ra) of the device under test (2, 3).

6. The method according to the preceding claim, determining on-the-air radio symbol times, such as RF symbol boundaries, of the one or more radio data packets based on the reference time, and preferably based on the subcarrier spacing and the cyclic prefix.

7. The method according to any of the preceding claims, the step of storing the excitation data (20) further comprising the step of storing the excitation data (20) in a data file according to a data format of a protocol.

8. The method according to any one of the preceding claims, wherein the step of replaying further comprises the following steps: Auxiliary data (21) are extracted from the stimulus data (20), and a reference signal for transmission from the test device (1) to the device under test (2, 3) is generated based on the auxiliary data (21).

9. According to the method according to any of the preceding claims, the radio data packet (10) is transmitted by the test device (1) to the device under test (2, 3), wherein the radio data packet (10) is preferably transmitted via a first communication link, preferably via a fronthaul link, and a reference signal is transmitted via a second communication link.

10. The method according to any of the preceding claims, wherein the radio data packet (10) is received by the device under test (2, 3) from the test device (1), wherein the radio data packet (10) is preferably received via a first communication link, preferably via a fronthaul link, and a reference signal (60) is received via a second communication link.

11. The method according to any of the preceding claims, the device under test (2, 3) converting the one or more radio data packets (10) into RF symbols for transmission over the air via an antenna (Ra).

12. Method according to any of the preceding claims, determining a time shift based on the reference time (T_Ra) and the actual time at which one or more data packets are present at the antenna (Ra) (air) interface.

13. A test device (1) comprising a processor and a memory operable to perform the steps of the method according to any one of the preceding claims.

14. A testing device (1), comprising: A first software module for generating and storing excitation data, the excitation data comprising one or more radio data packets and a reference time; and a memory for storing the stimulus data, the testing device further comprising a second software module for replaying the stimulus data.

15. A system (1, 2, 3) comprising a device under test (2, 3) and a testing device (1) according to any of the preceding claims.

16. A format of excitation data (20), preferably on a non-transitory medium, comprising a radio data packet (10) and a reference time (T_Ra) for transmitting the radio data packet (10) over the air.

Images