Timing accuracy for one or more radio data packets

Abstract

A method for determining timing accuracy of one or more radio data packets (10), the method comprising the steps of: recording, by a test apparatus (1), a reference time (TRa) for one or more radio data packets (10) received at an antenna interface (Ra) of a first radio device (2); generating, by the test apparatus (1), a time window based on a reference time, for example based on a predetermined time delay of the first radio device (2) and / or a fronthaul transmission; and transmitting, by the first radio device (2), one or more data packets (10) to a second radio device (3); recording, by the test apparatus (1), a time of arrival of one or more radio data packets (10) received by the second radio device (3); and comparing, by the test device (1), the time of arrival with the time window in order to determine the timing accuracy of the one or more radio data packets (10).

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 the transmission and / or reception of radio data packets via a fronthaul network. More particularly, the present disclosure relates to the testing of radio equipment. Background Art

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

[0003] To ensure compatible frame 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 device can also act as a PTP master and ensure that O-RAN messages are played according to the specified timestamps and the required timing windows for the test are achieved. Summary of the invention

[0004] Therefore, it is an object to improve the checking and verification of the transmission and / or reception of data packets via 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 radio communication system is shown.

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

[0008] Figure 3 A diagram of a test system comprising a test device is shown, wherein the test device comprises the functionality of a baseband unit.

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

[0010] Figure 5 A diagram showing the synchronization between the baseband unit eREC and the radio unit eRE is shown.

[0011] Figure 6 A visualization of data packet transmission via fronthaul is shown.

[0012] Figure 7 A diagram showing acceptable time windows and data packets for a first time slot is shown.

[0013] Figure 8 A diagram showing the acceptable time window and data packets for the second time slot is shown.

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

[0015] exist Figure 1 , a radio communication system is shown. The traditional monolithic base transceiver station (BTS) architecture is increasingly being replaced by a distributed BTS architecture in which the functionality of the BTS is divided into two physically separate units - a baseband unit (BBU) and a radio unit RU. The BBU performs baseband processing on a specific air interface used for wireless communication over one or more radio frequency channels. The RU 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 RU, and / or to generate baseband data for the BBU from radio frequency signals received at the RU via one or more antennas. The RU is typically installed near one or more antennas, usually at the top of a tower, and the BBU is typically installed in a more accessible location, usually at the bottom of the tower. However, depending on the circumstances, the RU and the BBU may be co-located, such as in a laboratory. The BBU and the RU are typically 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) family of specifications, the Open Base Station Architecture Initiative (OBSAI) family of specifications, and the Open Radio Interface (ORI) family of specifications.

[0016] In the 5G architecture, a new frequency domain fronthaul interface will be specified. 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 instead of time domain samples are sent via fronthaul. The RU will have information about resource allocations for different UEs over 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 a radio remote unit RRU or a remote radio head RRH) and the baseband unit BBU (sometimes also denoted as a radio equipment controller REC or a distributed unit DU) are separated, the signals received from one or more antennas must be transmitted through the medium connecting the RU to the BBU, since signal combination is usually done at the BBU. Typically, the interface used for the connection between the BBU and the RU is called the fronthaul interface. The signal passed through the fronthaul can be a complex time domain sample, such as specified in the traditional common public radio interface CPRI or today's eCPRI. The digitized waveform can be passed from the BBU to one or more RUs through 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 Core via one or more backhaul or cross-haul (English: cross-haul) connections, and may be connected to other BBUs (not shown). One or more radio data packets can therefore be transmitted, for example, between the radio unit and the baseband unit via the fronthaul. Depending on the situation, the test device can be coupled to the radio unit and / or the baseband unit via the fronthaul, as will be discussed later. Thus, one or more radio packets may be transmitted from the test set to the RU or BBU, or vice versa.

[0018] The signals of the user equipment (UE) are power limited and since 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 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 radio signals in order to test the functionality of the radio system and its components. Since the capacity on the fronthaul is limited, it is desirable to find ways to optimize and / or monitor the fronthaul usage.

[0019] High-speed data services have always been the goal of operators and the demand of users, especially professionals. The quality of synchronization directly affects the quality of service. In addition, for telecommunication system performance, radio equipment needs 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 with respect to time, phase and / or frequency synchronization. In addition, the management plane (M plane) is responsible for supporting FCAPS (fault, configuration, billing, performance, security) for the O-RU. In addition, the control plane (C plane) and the user plane (U plane) cover data configuration and feature parameters and actual radio data expected to be sent by the user, for example during operation and / or testing.

[0021] In the uplink direction, the O-RU receives a wireless signal through an antenna element. The wireless signal (e.g., in the form of RF symbols, also denoted as RF signals) may then pass through an analog beamforming block not shown and / or an analog-to-digital converter block not shown, whereupon the resulting data is ready to be converted from the time domain to the frequency domain by a Fast Fourier Transform (FFT) block not shown. Afterwards, basic filtering and digital beamforming are performed to extract actual data that may be compressed into IQ data. The IQ data may then be provided in the form of one or more radio data packets to be transmitted via the fronthaul.

[0022] Figure 2 A diagram of a test system comprising a test device coupled to a baseband unit and a radio unit is shown. In order to test the functionality of the baseband unit and / or the radio unit, a test device can be used that provides an excitation (e.g. in the form of one or more radio data packets) to the radio unit and / or the baseband unit. 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. For synchronization purposes, the test device can include or be coupled to a clock that provides a reference time for the test device, the baseband unit and / or the radio unit.

[0023] Figure 3 A diagram of a test system comprising a test device is shown, wherein the test device comprises the functionality of a baseband unit. Depending on the circumstances, for example for testing a radio unit, the test device itself may comprise the functionality of the baseband unit. Likewise, the test device may comprise or be coupled to a clock which provides a reference time for synchronization of transmission and / or reception of radio data packets between the baseband unit and the radio unit.

[0024] It should be understood that neither the core network nor the UE need to be present in the test system.

[0025] 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, C-plane radio data packets 11, 13 are sent before U-plane radio data packets 12, 14, 15 and 16 with a specific time period, which allows the O-RU to process and prepare for the next received U-plane radio data packet from the same source O-DU. The C-plane data packets 11, 13 are sent again in the next time slot. Depending on the U-plane characteristics and mode, 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 the data packet 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 certain time period, which is 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 going to its antenna.

[0026] The U-plane radio data packet is usually divided into two parts. The first part defines the scheduling, beamforming command information before the IQ data. The U-plane data can actually exceed the maximum ORAN specified data packet size. In this case, the data is split into multiple radio data packets. Typically, the data is organized into many 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.

[0027] Thus, when receiving an RF signal at the RU antenna (uplink direction), the radio unit digitizes the data and wraps it into an (e)CPRI protocol (IQ data), which travels, for example, over optical fiber before reaching the BBU and backhaul. Thus, an RF symbol may include one or more IQ samples provided in one or more radio data packets and transmitted, for example, via fronthaul. In the downlink direction, the baseband unit sends user data to the RU encapsulated in 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 transmitted, for example, via fronthaul. The (e)CPRI frame is unpacked, converted to an analog signal, and then transmitted over the air as an RF signal or symbol.

[0028] For example, a CPRI radio frame consists of a 10 ms period, wherein if each basic frame is 260 ns, 256 basic frames constitute a superframe with a period of 66.7 μs. A set of 150 superframes adopts the shape of a 10 ms frame as a radio frame.

[0029] like Figure 5 As shown, for example, in an eCPRI network, all nodes should be synchronized in different domains of frequency, time and phase domains. Timing synchronization is required so that all nodes are aligned with the same common time reference called the master clock GM. The nodes can be radio units and baseband units as described above. In this embodiment, the radio unit and the baseband unit are referred to as eRE and eREC, respectively. Both eRE and eREC should meet the requirements related to the timing accuracy of the fronthaul network, such as set by 3GPP. In fact, compared with the eRE, which requires high-quality frequency synchronization, the eREC is relaxed. However, the eREC must send data to the eRE at the right time so that there is enough time to process the data and transmit the data over the air interface, as well as buffering due to network delay variations.

[0030] As mentioned above, the synchronization plane handles the data flow and timing information used for synchronization in the fronthaul (network). To this end, a master (GM) clock can be located in the fronthaul network (outside the base station) or inside one of the eCPRI nodes (most likely in the eREC). The GM clock acts as a reference clock for the PTP-based network to synchronize all nodes in it.

[0031] Typically, eREC and eRE are connected in an eCPRI-based network. Reference points for timing management are always associated with the input and output ports of each node. Timing parameters are common to all fronthaul technologies. T12 represents the time delay caused by the medium or optical fiber linking the output of the eREC and eRE. T2a is the time delay for the eRE to process the data and transfer it through the antenna Ra. The Ta3 delay is used to process data from the antenna and transmitted to port R3. T34 is the transmission network delay of the user data packet between the Rx output of the eRE and the input of the eREC. Finally, T1a is the total time delay for user data starting from the eREC input port 1 until the IQ data is transmitted through the eRE antenna. The same applies to Ta4, but in the opposite direction where the data flow goes from the antenna end to the R4 eREC input port.

[0032] After the two eCPRI nodes are synchronized, DL and UL data transmission begins. Due to the different transmission methods in eCPRI, some amount of time is always required to transfer data packets from the eREC and eRE. Since the IQ data transmitted over eCPRI is in the frequency domain, the RF symbol duration directly affects the amount of time required for radio data packet transmission. In other words, all bandwidths, data compression amounts, and eRE data rates may affect the transmission time. In addition, since the IQ data transmitted over the fronthaul (e.g., using eCPRI) is in the frequency domain, the RF symbol duration directly affects the amount of time required for packet transmission. In other words, all bandwidths, data compression amounts, and eRE data rates may affect the transmission time over the fronthaul.

[0033] In the downlink direction, there are the following timing parameters: T12, 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 for the fastest path data can take to link two nodes. T12max is the maximum end-to-end one-way delay. Therefore, user data will adopt a delay T12 such that: T12min<T12<T12max.

[0034] exist Figure 6 , a visualization of a radio data packet transmission via fronthaul is shown. The visualization comprises a (C-plane and U-plane) radio data packet transmission window and the radio data packets themselves as transmitted via fronthaul (in the C-plane and U-plane).

[0035] For example, in the downlink, once one or more data packets arrive at the RU where they should be processed, T2a is the timing difference between receiving a user packet from the radio unit Tx input port R2 to transmitting the IQ samples at the antenna port Ra. To compensate for different T12 values, the radio unit is able to buffer the data, which means that the T2a timing value changes depending on which path the data packet takes to arrive at port R2. T2a min is the minimum timing for the radio unit to process a data packet.

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

[0037] 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 transmission of the earliest IQ sample at the antenna is the RF symbol time Tsym. If a user data packet arrives outside this reception window (i.e., earlier than T2a max or later than T2a min), the radio data packet may not be used, and as a result, the IQ samples and RF symbols associated with the radio data packet may not be generated correctly.

[0038] By looking at the timestamp of a data packet, it is difficult to determine when a packet should be captured, or what is an acceptable time window for a packet relative to the associated symbol time Tsym on the air interface. As mentioned above, Tsym can therefore be given as the time when the air interface transmission of a symbol starts, or in the case of an uplink, as the time when the reception of a symbol starts via the air interface.

[0039] Since adherence to packet timing and required time advance values ​​is the biggest concern in making O-RAN based fronthaul networks work reliably, sufficient timing accuracy is required. It may also be necessary to provide effective visualization to the test engineers in order to identify the possibilities for identifying the causes of transmission errors or delays.

[0040] For timing analysis, for example, when one or more data packets are captured, a reference time (i.e., TRa) is saved or timestamped. A timestamp may be applied to one or more radio data packets. The reference time TRa may be a 1 Hz (1PPS) pulse from a clock, such as a GPS receiver or a master clock in a test system as described above. The symbol time Tsym may then be derived from the reference time TRa. For example, by considering one or more system parameters, such as α and β values ​​according to 9.7.2, 2019.03.11 of ORA-WG4.CUS.0-v01.00, the symbol time Tsym may be derived from TRa. For example, the system frame number may be calculated based on GPS seconds. The system frame number or radio frame number and the start of the system frame or radio frame may thereby be determined.

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

[0042] Therefore, one or more radio data packets can be segmented and, for example, visualized on an RF time slot basis (i.e., time slot by time slot) on a horizontal time axis. That is, one or more radio data packets captured during a time period, such as several hundred radio frames (each radio frame having a duration of 10ms), can be determined and / or visualized as a time window ("deck"), wherein each time window ("card") includes an RF time slot, and / or corresponds to an acceptable time window, such as for each symbol of, for example, 14 or 12 RF symbols for an RF time slot, such as for a normal or extended cyclic prefix. Each (control and user plane) radio data packet is aligned with an acceptable (received) time window by adding a required time advance value to its timestamp (e.g., a reference time or a symbol time derived from a reference time), as described above. In this way, the radio data packets of the correct timing can be transformed within the acceptable time window, and the data packets that are too early or too late fall outside the time window. Thus, the timing violation becomes obvious. In addition, the positioning of the radio data packets is visualized, and the user can determine whether the radio data packet is received at the beginning, center or end of the time window. By visualizing all radio data packets captured in the same view, the user can easily see whether the delay is due to high link utilization or there is another problem. The RF time slot segmentation of the "deck" type allows a quick scan of the entire captured data packet. For example, using the described visualization of a specific view can be centered on the RF time slot and by using input commands, such as up / down arrows or a mouse wheel, the user can view the time window of the previous or next RF time slot and visually compare the time windows. It can also support zooming in to individual symbols to allow a more detailed display of RF symbol timing and error amplitude.

[0043] Figure 8 A diagram showing the acceptable time window and the radio data packets for the first time slot is shown. Figure 8 , the acceptable (receive) time window for each RF symbol in the first time slot (time slot 0) and its RF symbols (symbols 0, ..., 13) is shown as a light blue / grey / green box vertically spanning multiple antenna carriers. The antenna carriers are extended to the downlink (DL) and uplink (UL) directions, where (control plane and / or user plane) radio data packets are folded onto the same timeline. The size of the bars on the time axis reflects the size of the actual radio data packet (and also shows whether the end of the radio data packet falls outside the (acceptable) time window, not just the beginning of the radio data packet). RF symbols can be colored and / or marked according to their purpose, downlink, uplink or protection period. From this, it can be intuitively seen whether the radio data packet arrives at a completely wrong RF symbol time.

[0044] Go to Fig. 9 , showing an illustration of the acceptable time window and data packets for the second time slot. For example, by using an input command such as the down arrow key or a mouse scroll down, the visualization can be moved from one RF time slot to another, such as to the next time slot, i.e., time slot 1. This time slot shows the "too late" radio data packets for symbols 4, ..., 6. For those radio data packets, the time violation is highlighted, for example, using red. In the "deck" view, the entire RF time slot can be marked accordingly, for example, colored in red, as well as the RF frame / RF subframe if the RF subframe is collapsed and RF time slot 1 is hidden from view.

[0045] This view is positioned identically to the previously seen RF slot (i.e., slot 0), allowing a direct comparison of the RF symbol timing and corresponding radio data packets between the two slots. If the zoom level was changed previously, the same level can be maintained throughout the different RF slots unless the user decides to change the zoom level again to view the complete RF slot, individual symbols, or something in between. The "deck" arrangement allows multiple RF slots to be "open" at the same time, and automatically resizes (collapses the slot farthest from the slot of interest) when the graphical user interface window / widget runs out of space. RF subframes and / or RF frames can also be displayed so that the user can quickly navigate to the next 10ms frame or 1ms subframe without having to scroll through each and every RF slot to get there. RF stands for Radio Frequency so that the corresponding RF characters of a symbol, slot, and / or (sub)frame are recognized and not mistaken for a fronthaul protocol frame (e.g., (e)CPRI).

[0046] Existing solutions based on commercial network interfaces or network cards do not allow the recording of auxiliary signals, i.e., the air interface time reference, i.e., the reference time TRa. Therefore, it has been impossible to perform detailed symbol time calculations without PTP slaves and corresponding timestamps. It is advantageous to display the timing information inherent in the characteristics of transmitting digital antenna samples (i.e., as radio data packets including IQ data) on packet-based interfaces such as fronthaul (link and / or protocol). The "deck" method improves the availability of test equipment and / or test systems. Another benefit is the efficient segmentation of the radio data packet timeline into RF time slots on the time window. In addition, as part of the capture, auxiliary signals (such as air interface time reference (TRa)) are saved and visualized with radio data packets. For each RF symbol, the visualization of the acceptable arrival time window based on the RF symbol can be interpolated / extrapolated from the reference time TRa alone. The transformation of the visualized radio data packet according to the time advance value allows the visualization diagram to be brought to the same time domain (and avoids confusion between (e.g., O-RAN) fronthaul and RF time domains). In addition, radio data packet start and / or end timestamps may be taken into account in the visualization, for example, to show the actual data packet duration on a timeline and / or highlight where, for example, the end of the last radio data packet of an RF symbol (of an application / transfer segment) may fall outside an acceptable time window. Highlighting timing violations by using exclamation points and / or vivid colors (or any other necessary means) can help gain the user's attention and guide the user to the error(s) and allow a direct and easy transition to the next / previous error. Visualization of the timing multiplexing of different radio data packet streams from different antennas; this shows how data packet scheduling works and whether the uplink and / or downlink is running reliably or on the edge. In addition, visualization of RF symbol allocation for downlink (DL), uplink (UL) and guard period (GP) is implemented in LTE and 5G NR schemes based on time division duplex (TDD).

[0047] Fig. 9Exemplary steps according to a first embodiment are shown. In a first step S1, a reference time TRa is recorded for one or more radio data packets received at an antenna interface of a first radio device. In a second step S2, a time window is generated by a test device based on the reference time, for example based on a predetermined time delay of the first radio device and / or a fronthaul transmission. In a third step S3, one or more data packets are transmitted by the first radio device to the second radio device. In a fourth step S4, an arrival time of the one or more radio data packets received by the second radio device is recorded by the test device. In a fifth step S5, the arrival time is compared with the time window by the test device in order to determine the timing accuracy of the one or more radio data packets.

[0048] Fig.10 Further exemplary steps are shown. In step S6, a reference time is generated based on a reference clock. The first radio device and the second device and preferably the test device are synchronized with respect to the reference clock. In step S7, for each RF (sub) frame boundary received at the antenna interface (Ra), the reference time at the antenna interface (Ra) is recorded. In addition, for each RF symbol in the RF (sub) frame, a time window can be generated based on the reference time. In step S8, a time window is generated for each RF symbol in a plurality of RF symbols, wherein a radio data packet corresponds to an RF symbol of an RF time slot and / or an RF (sub) frame, and wherein the RF symbol is represented as IQ data.

[0049] Fig.11 Further exemplary steps are shown. In step S9, a time window is associated with each radio data packet of the plurality of radio data packets. In step S10, the corresponding time window and the associated radio data packet are simultaneously displayed, for example on a display screen. In step S11, it is indicated whether the associated radio data packet at least partially exceeds its corresponding time window.

[0050] Fig.12 A further step S12 is shown, in which the radio data packets received at the antenna interface and / or at the second radio device are arranged consecutively in chronological order and a time window of at least one RF time slot and the associated radio data packets are simultaneously displayed in the first view.

[0051] Fig.13 Further exemplary steps are shown, wherein in step S13 a first view comprising a time window of a first RF time slot and radio data packets and a second view comprising a time window of a second time slot and radio data packets are displayed and preferably switched between the first view and the second view based on a first user input.

[0052] Fig.14Further exemplary steps are shown, wherein in step S14 a first view comprising a time window of a first RF time slot and radio data packets and a second view comprising at least one RF (sub)frame are preferably displayed in chronological order and switching between the first view and the second view is preferably performed based on a second user input, and wherein in the second view it is indicated whether one of the associated radio data packets of the (sub)frame at least partially exceeds its corresponding time window.

[0053] Fig.15 Further exemplary steps are shown. In step S15, one or more data packets are transmitted by the first radio device to a second radio device, the second radio device being communicatively coupled to the first radio device via a fronthaul communication link and / or using a fronthaul communication protocol. In step S16, the arrival time of the radio data packets is transformed according to the time delay of the first radio device and / or the time delay of the fronthaul transmission.

[0054] Additional embodiments include:

[0055] Preferably, for each RF symbol in an RF time slot, an RF subframe and / or an RF frame, an RF symbol boundary Tsym is determined based on a reference time, and / or for one or more radio data packets representing RF symbols in, for example, an RF frame, an RF subframe or an RF time slot, a time window W0, ..., W13 is generated based on the RF symbol boundary.

[0056] Additional embodiments include:

[0057] Time windows W0, ..., W13 are generated for one or more radio data packets 10, wherein the radio data packets 10 correspond to one or more RF symbols of an RF time slot and / or RF (sub)frame, and wherein the RF symbols are represented as IQ data in the radio data packets.

[0058] Additional embodiments include:

[0059] associating a time window W0, ..., W13 with each radio data packet of the plurality of radio data packets 10, and / or

[0060] For example, the corresponding time windows W0, ..., W13 and the associated radio data packets are displayed simultaneously on a display screen, and / or

[0061] Indicates whether the associated radio data packet at least partially exceeds its respective time window W0, ..., W13.

Claims

1. A method for determining the timing accuracy of one or more radio data packets (10), the method comprising the following steps: A reference time (TRa) is recorded by a test device (1) for one or more radio data packets (10) received via an antenna interface (Ra) of a first radio device (2), generating a time window by the test device (1) based on the reference time, for example based on a predetermined time delay of the first radio device (2) and / or a fronthaul transmission, and transmitting one or more data packets (10) by the first radio device (2) to a second radio device (3), recording, by the test device (1), the arrival time of the one or more radio data packets (10) received by the second radio device (3), and The arrival time is compared with the time window by the test device (1) in order to determine the timing accuracy of the one or more radio data packets (10).

2. The method according to the preceding claim further comprises the following steps: The reference time is generated based on a reference clock (4), wherein the first radio device (2) and the second device (3) and preferably the test arrangement (1) are synchronized with respect to the reference clock (4).

3. The method according to any one of the preceding claims, further comprising the steps of: Preferably, for each RF symbol in an RF time slot, RF subframe and / or RF frame, an RF symbol boundary (Tsym) is determined based on the reference time, and For the one or more radio data packets representing the RF symbols, for example in the RF frame, the RF subframe or the RF time slot, the time windows (W0, ..., W13) are generated based on the RF symbol boundaries.

4. The method according to the preceding claim further comprises the following steps: A time window (W0, ..., W13) is generated (S8) for the one or more radio data packets (10), wherein the radio data packet (10) corresponds to one or more RF symbols of an RF time slot and / or an RF (sub)frame, and wherein the RF symbols are represented as IQ data in the radio data packet.

5. The method according to the preceding claim further comprises the following steps: associating a time window (W0, ..., W13) with each radio data packet of a plurality of radio data packets (10), and For example, on a display screen, the corresponding time windows (W0, ..., W13) and the associated radio data packets are simultaneously displayed, and Indicating whether said associated radio data packet at least partially exceeds a respective time window (W0, ..., W13) of said associated radio data packet.

6. The method according to the preceding claim, further comprising the steps of: arranging the radio data packets received at the antenna interface (Ra) and / or at the second radio device (3) successively in chronological order (S12), and The time windows (W0, ..., W13) of at least one RF time slot and the associated radio data packets (10) are simultaneously displayed in a first view.

7. The method according to the preceding claim further comprises the following steps: The first view comprising the time window (W0, ..., W13) of the first RF time slot and the radio data packets and the second view comprising the time window (V0, ..., V13) of the second time slot and the radio data packets are displayed (S13), and the first view and the second view are preferably switched between based on a first user input.

8. The method according to the preceding claim further comprises the following steps: displaying (S14) a first view comprising said time windows (W0, ..., W13) of said first RF time slots and said radio data packets and a second view comprising at least one RF (sub)frame, preferably in chronological order, and switching between said first view and said second view, preferably based on a second user input, And, in said second view, it is indicated whether one of said associated radio data packets of a (sub)frame at least partially exceeds said corresponding time window (W0, ..., W13) of said one radio data packet.

9. The method according to the preceding claim, further comprising the steps of: The one or more data packets are transmitted by the first radio device (2) to a second radio device (3), the second radio device (3) being communicatively coupled to the first radio device (2) via a fronthaul communication link.

10. The method according to the preceding claim, further comprising the steps of: The arrival time (T12) of the radio data packet is shifted depending on a time delay of the first radio device (2) and / or of the fronthaul transmission.

11. Method of use of the method according to any of the preceding claims for testing, verifying and / or validating a radio device (2, 3) under test.

12. A test system, preferably comprising a test device (1), operable to perform the steps of the method according to any of the preceding claims 1-11.

13. A computer program (product) comprising program code, which, when executed, performs the steps of the method according to any one of the preceding claims 1-11.

Images