Transmission of radio data packets

Abstract

A method of transmitting one or more radio data packets (40) by a first test device (11, 12, 13), the method comprising the steps of: obtaining, preferably repeatedly, by the first test device (11, 12, 13), a reference timestamp from a reference clock (RT), wherein the reference clock (RT) provides a reference time in a test system (1) comprising the first test device (11, 12, 13), wherein the reference timestamp indicates the reference time, transmitting, by the first test device (1), the one or more radio data packets, preferably sequentially, in accordance with a predetermined start time in the test system (1) on a communication interface (QSFP) for coupling the first test device (11, 12, 13) with a device under test, DUT (10).

Description

[0001] 202404911

[0002] 1

[0003] Description

[0004] Title of the Invention

[0005] Transmission of radio data packets

[0006] Technical Field

[0007] The present disclosure relates to the transmission of one or more radio data packets. In particular, the disclosure relates to the timed transmission and / or reception of the radio data packets, preferably over a fronthaul network. More particularly, the disclosure relates to testing of radio equipment.

[0008] Background Art

[0009] In a fronthaul of a radio network the antenna data needs to be carried over longer distances. Therefore, strict throughput latency, jitter, timing, and synchronization requirements need to be respected. Hence, the transmission in particular over the fronthaul requires a strict synchronization and timing mechanism, like Precision Time Protocol, PTP, e.g., between the radio unit, Rll, and the distributed unit, DU, to ensure appropriate transmission and / or reception of data packets.

[0010] To ensure compliant synchronization, the proper functioning of radio equipment of a radio network needs to be verified. To that end, testing of the radio equipment needs to be performed. For example, a test device can also act as a PTP master and ensure that fronthaul messages are replayed honoring specified timestamps enabling testing of required timing windows.

[0011] From international patent application WO 2024 / 003596 a method for determining timing accuracy of one or more radio data packets has become known. Therein, stimulus data comprising a reference time for transmission of the radio data packets over the air is generated.

[0012] Summary of Invention

[0013] In the field of (testing) radio access networks and the corresponding radio equipment it is necessary to synchronize the device under test and the test equipment to the same air interface timing phase, i.e. to the RF frame boundaries. To that end, trigger signals are used that must be transmitted to the device under test via some sort of copper cabling, typically via SubMiniature version A, SMA, connectors or cables. Trigger pulses and / or copper cables are not optimal for remote-controlled test automation facilities due to their relatively short reach, re-cabling difficulty, and latency. In addition, copper-based I / O signals pose challenges to the test setup in terms of signal rise / fall times, trigger pulse duration and detection, registering and reacting to 202404911

[0014] 2 the pulse, and I / O voltage compatibility. Furthermore, designs under test need to be modified to support such input / output signaling in the pre- or post-silicon design phase of a System-On-a- Chip, SoC. It is thus desired to get rid of copper-cabling while still maintaining triggering support.

[0015] According to a first aspect a method of transmitting one or more radio data packets by a first test device is proposed.

[0016] According to a second aspect a computer program, preferably on a non-transitory medium, that comprises program code that when carried out performs the method according to the first aspect is proposed.

[0017] According to a third aspect a first and / or a second test device, preferably comprising a processor and a memory, operative to perform the method in accordance with the first aspect is proposed.

[0018] According to a fourth aspect a test system comprising a device under test and further comprising a first test device, an additional first test device and / or a second test device according to the second and third aspect is proposed.

[0019] Description of Embodiments

[0020] Independent of the grammatical term usage, individuals with male, female or other gender identities are included within the term.

[0021] Brief Description of the Drawings

[0022] Fig. 1 shows an illustration of a test system with sync-pulse-based synchronization

[0023] Fig. 2 shows an illustration of a test system with a timestamp-based synchronization

[0024] Fig. 3 shows an illustration of a test device.

[0025] Fig. 4 shows an illustration of a plurality of radio data packets.

[0026] Fig. 5 shows the protocol stacks of different communication planes in a fronthaul network.

[0027] Fig. 6 shows a synchronization mechanism.

[0028] Fig. 7 shows a test sequence with a plurality of transmission and / or reception events

[0029] Description of Examples 202404911

[0030] 3

[0031] As shown in Figure 1 it is possible to make use of trigger signals and timing references via, e.g., copper-based, wires 2 across a test system 1. The (originally red) lines connecting the test device(s) 11, 12, 13 and / or the device under test 10 in Figure 3 indicate, e.g., copper-based, cabling that is subject to the limitations mentioned herein.

[0032] RF switches, not shown, may be used to re-route trigger signal connections for different test system setups. An RF switch is a device to route high frequency signals through transmission paths. RF (radio frequency) switches are used extensively in test systems for signal routing between test devices and devices under test, DUT. Latencies may be compensated in the test devices, as accurately as possible without knowing the actual cabling length. A DUT such as a System-On-a-Chip, SoC, in the bring-up phase may be tweaked to receive and / or emit timing reference pulses. In addition, test devices 11 , 12, 13 or other test equipment, e.g., said RF switch, may also support emission or reception trigger signals via corresponding inputs and outputs, respectively.

[0033] In the field of radio networks and the necessary radio equipment, the communication interface between a distributed unit, DU, and a radio unit, RU, is known as the fronthaul interface. The fronthaul interface, one of the most demanding system interfaces, is very latency-sensitive. As a communication protocol CPRI or eCPRI (5G only) may be used for communication over the fronthaul and / or fronthaul interface. For example, in the Open RAN fronthaul architecture the O- DU and O-RU elements are defined as the O-RU being the Open RAN Distributed Unit, O-DU, which is a logical node hosting RLC / MAC / High-PHY layers according to a functional split, and the O-RU is defined as the Open RAN Radio Unit, O-RU, being a logical node hosting a Low- PHY layer and RF processing according to the functional split.

[0034] Hence, as can be seen in Figure 1 a stimulus comprising one or more radio data packets is transmitted / received over a fronthaul (link) and / or the respective fronthaul interfaces between the test device(s) and / or the DUT. The fronthaul is indicated as Protocol A in Figure 1. Furthermore, it is possible to connect one or more test devices 11, 12 to an interface of the DUT, such as the digital frontend in case of a radio unit, using another protocol, e.g. such as JESD 204B / C, indicated by Protocol B in Figure 1. On the other hand, the trigger signals and / or timing references are transmitted separately via, e.g., copper-based, wires across the test system 1 connecting the one or more test device 11 , 12, 13 with each other and / or the DUT 10. As shown in Figure 1 time sync pulses are issued once per second (1PPS) for (frame) synchronization between the DUT 10 and the one or more test devices 11 , 12, 13. The one or 202404911

[0035] 4 more test devices and / or the DUT then may start their local clocks at the next 1PPS event. However, this implementation suffers from the drawbacks mentioned herein.

[0036] Now turning to Figure 2, instead of trigger signal, for example such as sync pulses over a copper wire, e.g., time synchronization pulses (1 PPS for frame synchronization), it is proposed to use a “future timestamp” -based approach for the test of the DUT 10 and / or in the test sequence definition. Hitherto, a synchronization in the test system 1 is performed. Thereby the test system 1 comprising the one or more test devices 10, 11 , 12 and / or the DUT 10 forms a time domain. The synchronization may be performed over a communication network 20, also denoted as (PTPv2 over) control LAN in Figure 2, connecting the one or more test devices 11,

[0037] 12 ,13 and / or the DUT 10. Hence, the one or more test device 11 ,12, 13 and / or the DUT 10 are network stations in a network 20 of the test system 1. As apparent, the synchronization in the test system 1 as well as the transmission of the stimulus or the respective one or more radio data packets takes place over the fronthaul and / or the respective (fronthaul) communication protocol, preferably over the C / U and / or S plane of the fronthaul protocol, as the case may be. As already mentioned, stimulus transmission may also take place over another protocol, e.g., Protocol B, which may be as also already mentioned a communication protocol such as JESD 204B / C.

[0038] When starting a test or test sequence, a test controller 15, e.g., on one of the test devices 11 , 12, 13 or a computer communicatively coupled to the test system 1, indicated by <OR> in Figure 2, may define a future time, i.e. a predetermined start time or event time, for one or more events relating to the test sequence, e.g., for starting the test, for example by transmitting one or more radio data packets. Other events may comprise idle times, capture / reception times or the like. The test controller 15 may then configure one or more times of those (future) events into participating test equipment, e.g., said one or more test devices 11, 12, 13 and / or the device under test 10. For example, the test controller 15 can configure test device 11 to start transmission at the next full minute (HH: MM: 00.000.000) and test device 12 to start 10 milliseconds later (HH:MM:00.010.000). Before, this would have required complex trigger conditions, e.g., with 1 PPS and frame sync trigger signals wired across the test system.

[0039] Thus, a synchronized time domain in the test environment comprising the test device(s) 11 , 12,

[0040] 13 and / or the device under test 10 is introduced. By way of a time-synchronization protocol, such as, e.g., PTP, PTPv2, or SyncE, in the test system 1 and / or the communication network (local area network), or another time-synchronization mechanism, such as, e.g., GPS, the one or more test devices 11 , 12, 13 and / or the DUT 10 can be synchronized, or made aware of an 202404911

[0041] 5 exact and / or common time. Hence, the synchronization and / or common time can be used to determine the phase of the one or more RF frames, i.e. the one or more radio data packets. The DUT 10 and / or the one or more test devices 11 , 12, 13 thus can synchronize their respective local time or local clock LT10, LT 11 , LT12, LT13, e.g., based on a time-synchronization protocol, preferably to a reference time or global time, or reference clock, RT. For example, in case of O-RAN WG4 Fronthaul, the Protocol A in the Figure 2 may carry synchronization information on the S-Plane. For example, e.g., in the absence of such synchronization capabilities in the DUT, the time reference would only be required by the DUT 10, and not by surrounding test devices 11, 12, 13. By substituting triggers signals, i.e. pulses, by time-based future events, e.g., in said test sequence, the need for copper I / O signal lines between the one or more test devices and / or the DUT can be eliminated.

[0042] This approach has several advantages. First, it simplifies the setup of connections in the test system 1 for connecting the one or more test devices 11, 12, 13 to each other and / or the DUT 10. Consequently, when there’s no need for copper cabling, the one or more test devices 11, 12, 13, e.g. using fiber-optic media for communication, i.e. reception and / or transmission, can be located far or further away from the DUT 10. This enables remote-controlled test system operation and / or control. Furthermore, the test system 1, in particular communication lines for transmission and / or reception, can be reconfigured, e.g., by (remotely) controlling one or more fiber-optical switches of the test system 1. That is to say, no rewiring is necessary.

[0043] Furthermore, latency may be compensated when transmitting the one or more radio data packets. That is, when all test devices are (automatically) synchronized, e.g., based on a common time reference RT, there is no need to account for cabling and / or buffer latencies in the trigger signals. As described herein, said latency may be considered when transmitting the one or more radio data packets, e.g. by starting the transmission in advance, e.g., in order for the one or more radio data packets to arrive at the DUT 10 precisely in time. That is the one or more radio data packets representing RF frames arrive at the desired time at the DUT 10, e.g., the DUT’s digital frontend and / or fronthaul interface. To that end, a transmission or timing advance may be applied by the test device. In that case the one or more data packets will be transmitted by the test device 11 , 12, and / or 13 in order to arrive at the DUT 10, i.e., its one or more interfaces, at the predetermined time.

[0044] Furthermore, test sequences become more predictable, easier to debug, and easier to report afterwards, when all events are based on commonly agreed-upon time or timestamps rather 202404911

[0045] 6 than trigger pulses. Test logs from all test equipment 11 , 12, 13 and / or the DUT 10 may use the same time base and / or may thus show events according to their time of occurrence.

[0046] The use of different test devices 11, 12, 13 for a first protocol A, e.g., a fronthaul protocol such as (e)CPRI, and a second protocol B, such as JESD 204B / C, becomes easier and / or more accurate in terms of synchronization, since a first test device 13, such as a master tester, or a test controller (a computer in the local area network), defines timestamp-based trigger events in advance to one or more test devics 11 , 12 or other participating test equipment and / or the DUT 10 in the test system 1.

[0047] Finally, it becomes possible to stack multiple test devices 11 , 12, e.g., to increase the number of links / lanes that can be driven to / from the DUT. This also is achieved through the time-based trigger events, such as transmission and / or capture start.

[0048] A test or test sequences may comprise one or more events occurring on such future timestamps, i.e. one or more predetermined event times, inter alia said predetermined start time. Due to the test system 1, i.e. the one or more test device 11, 12, 13 and / or the DUT 10, being synchronized it is possible to define one more points in time at which one or more events shall occur. Such an event may be a start time (for the test sequence), an idle time (of the fronthaul (medium) or other communication link or protocol), an antenna activation time, a capture start, beginning or ending time, or the like.

[0049] Hence, as the case may be, events and event times programed into the participating devices 10, 11 , 12, 13 may comprise and / or be related to the transmission and / or reception of the one or more radio data packets, e.g., of said stimulus. Alternatively or additionally, the one or more events and the event times may relate to the execution of functions on the one or more test devices 11, 12, 13 and / or the device under test 10.

[0050] An exemplary test device is shown in Figure 3. The device 11, 12, 13 may comprise, as shown in Figure 3, a transceiver TR which is connected to a (independent) receiver module RX and / or transmitter module TX, e.g., forming a data path to and / or from the memory, e.g., DDR, respectively. DDR is mentioned herein as a subtype of Synchronous Dynamic Random Access Memory, SDRAM. Thus, the memory may be implemented as a DDR - dual data rate (operates on rising and falling data strobe edges) or SDR - single data rate (rising edge only). As the case may be, the transmitter and / or receiver TX, RX may be included in the transceiver TR, e.g., as well as the Data Mux module. The Data Mux module may provide bit-level multiplexing in both 202404911

[0051] 7 the TX and RX directions. The Data Mux function is for example described in clause 83.5.2 of IEEE Std 802.3ba-2010.

[0052] For example, e.g., in the uplink, a test device 11, 12, 13 may capture inbound fronthaul protocol frames, i.e. , radio data packets comprising IQ data, into its memory, such as a DDR4 memory. Along with the high-speed serial data capture, e.g., from a fiber-optic link for example through SFP or QSPF interfaces. A software application, such as a software module, e.g., for protocol generation and / or analysis, may transmit data, e.g., said one or more radio data packets, through the transceiver TR by writing data (from the memory, e.g., DDR), to the TX module. Similarly, the software application may receive data, i.e., in the form of one or more radio data packets, through the transceiver TR by receiving data from the RX module. The software application, such as the protocol generator and / or analyzer may (pre-)generate protocol RF frames, e.g., in the form of said one or more radio data packets, and store them into a memory, such as a DDR4 memory, of the test device as stimulus data to be transmitted to the device under test (DUT). It is to be understood that the protocol may be an internal protocol that is used for radio data packets to be generated, stored and / or transmitted within the test device. The stimulus may then be packetized and / or transmitted by one or more data packets over a communication interface, such as the fronthaul (interface). The test device may also be capable of packetizing the stimulus in the form of one or more radio data packets according to another communication protocol, such as JESD 204 B / C.

[0053] Specifically, for fronthaul protocols, such as O-RAN, there is a need to signal a reference time, e.g., from one test device to another test device, e.g., from a playback device to a radio frequency (RF) analyzer and / or the DUT, e.g., a radio unit. This reference time needs to coincide with the pre-calculated RF (sub)frame, RF slot and / or RF symbol boundary T_Ra=0, to have comparable signals, i.e. in order to compare the actual response of the DUT with the desired output.

[0054] The radio data packets from the stimulus data passes through the data multiplexer that controls the transmission, e.g., via the SFP or QSFP port assignments. The transmission of the radio data packets of the radio data packets from the stimulus data may occur via an SFP or a QSFP fiber-optic module for high-speed serial transmission. Said one or more SFP or QSFP ports may thus serve as a communication interface for coupling the first test device with a device under test, DUT. As mentioned, either a fronthaul protocol or another digital communication protocol may be used. For example, if the stimulus is to be transmitted to a DUT in the downlink the stimulus may be encapsulated according to a fronthaul protocol. When stimulus is transmitted in 202404911

[0055] 8 the uplink to the DUT the stimulus may be encapsulated according to communication protocol, such as JESD 204 B / C, capable to be received by the DUT via its digital frontend, DFT.

[0056] The medium over which one or more radio data packets are transmitted may be a fiber-optic cable or a copper cable. Hence at a predetermined time such as said start time or event time in the test system, one or more radio data packets may be transmitted on the medium coupling the first test device with a device under test and / or with another test device - as the case may be. In general, an event may be triggered in the test system in accordance with a predetermined event time.

[0057] Preferably, the one or more radio data packets are transmitted, e.g., by the first test device, in the test system such that the one or more radio data packets are received by a device under test, DUT, at the predetermined start time. The (transmission) medium can be a very long, and the intention is to make sure that the DUT actually receives the packets at the right time, not just that they are somewhere ”on their way” towards the DUT. This may be achieved by advancing the transmission, e.g., according to an advance time, of the one or more radio data packets such that they are received at the DUT at the predetermined start time.

[0058] In any case, the transmission of the one or more radio data packets may be triggered such that the one or more radio data packets are present on the medium between the first test device and the device under test, DUT, in accordance with or at the predetermined start time.

[0059] Figure 4 shows an illustration of stimulus 40 in the form of radio data packets 41-46. Stimulus and response are interactions with a device under test, DUT. The one or more radio data packets may form the stimulus or may be part of the stimulus. For example, the control plane data, also referred to as C plane, is sent separately from the user plane data, also referred to as U plane. For the downlink case, C plane radio data packets 41, 43 are sent before the U plane radio data packets 42, 44, 45, 46 with a specific period of time that allows the O-RU to process and be ready for the next received U plane radio data packet, coming from the same source BBU, e.g., an O-DU. This C plane data packet 41 , 43 is sent again in the next slot. Depending on U plane characteristics and patterns, the C plane can be either the same copy or can be reconfigured. The C plane and the U plane radio data packets 41-46 may comprise data encapsulated using eCPRI or IEEE1914.3 mechanism. As shown in Figure 4 the control information and the IQ data are preceded by IP and / or Ethernet header and a C plane header or a U Plane header, respectively, illustrated by the small boxes at the beginning of the data packets 41-46. The IQ data may be in the frequency domain. The control information radio data 202404911

[0060] 9 packets are sent always before the II plane data packets. Every slot C plane data packet precedes II plane radio data packet by a certain period of time defined by time management parameters known as T cp_adv_dl. This amount of time allows O-RU to update beamforming weights linked to the user data in a DL direction -exemplifying the strict latency requirements of the radio data packet transmission. Similarly, the C plane packet, in UL data flow, is used to adapt the processing of the O-RU for the II plane data coming to its antenna.

[0061] The II plane radio data packets are usually separated into two parts. The first defines the scheduling, beamforming commands information followed by the IQ data. The II plane data can actually exceed the maximum ORAN specified data packet size. In such cases, the data is split over multiple radio data packets. Typically, data is organized in many section types. Data that belongs to different sections should be sent separately. Whenever the IQ data are not achieving 1 byte alignment, stuffing bits are added at the end of a section.

[0062] Hence, during operation, when receiving an RF signal in the Rll antenna (uplink direction), the radio unit will digitize data and wrap it up into the IQ data, e.g., according to (e)CPRI protocol. During a test it is possible to connect to the digital frontend of the Rll, and transmit IQ data directly to the DFT of the Rll, e.g., using a communication protocol such as JESD 204 B / C. The radio data packets comprising the IQ data may then be transmitted through, e.g., an optical fiber, reaching the BBU, and possible a backhaul afterwards. In the test case, the radio data packets may be transmitted to a test device, e.g., to be analyzed in order to determine correct functioning of the DUT, e.g., such as said Rll. Hence, an RF symbol may correspond to one or more IQ samples that are provided in one or more radio data packets and, e.g., transmitted via the fronthaul. In the downlink direction, the baseband unit sends user data to Rll enveloped according to a fronthaul protocol, such as (e)CPRI protocol. In the test case this may be done by a test device. The user data may also be in the form of IQ data and present in the one or more radio data packets, e.g., transmitted over the fronthaul. In the test case, the (packetized) stimulus is transmitted to the DUT over the fronthaul. The (e)CPRI frames will be unpacked, converted to analog signals and then transmitted over the air as RF symbols or RF signals in general. In the test case, it is possible to obtain the stimulus processed by the DUT via its digital frontend, i.e. before being converted into RF signals by the RU. For example, a CPRI radio frame consists of a 10ms time period. Therein, 256 basic frames, each basic frame if of 260ns, constructs one hyper frame of period 66.7ps. A collection of 150 hyper frame takes a shape of 10 ms frame which is the radio frame. 202404911

[0063] 10

[0064] As mentioned, transmission of one or more radio data packets via the fronthaul (or similarly for another communication protocol such as JESD 204B / C) requires packetized Control- and Userplane data to be sent from O-DU to O-RU in advance, so that the radio unit can perform required data processing and digital-to-analog conversion well in time before the actual symbol time in the air interface, RF antenna. This amount of “advance” is configurable, e.g., per O-RU requirements and the verification of correct arrival time windows is of essence in ensuring correct operation of the fronthaul network and the interoperability between O-DU and O-RU. The problem in this verification is that the actual RF-side symbol time is not visible to the fronthaul, and without such symbol time reference, radio data packet arrival time windows cannot be reliably established, and it is impossible to say if packets arrived too early (exceeding the buffering capabilities in radio unit) or too late (radio unit does not have enough time to prepare the symbol data for RF transmission).

[0065] Furthermore, the lack of such an RF time reference in a radio test system (given by a modeled or real SoC) complicates data analysis in the RF interface side, in the ADC / DAC interface of a radio unit. Hence, RF symbols time-wise locations are not known and cannot be reliably verified by the means of IQ data analysis.

[0066] Figure 5 shows the protocol stacks of a C / U-Plane, an S-Plane and an M-Plane respectively. For example, the Open Fronthaul protocol includes the Control User Synchronization (CUS) plane and the Management (M) plane over Low Layer Split interfaces. Open RAN defines these interface planes as shown in Figure 5. Therein, the control plane refers to real-time control between O-DU and O-RU, not including the IQ sample data (which is part of the User Plane). User Plane refers to IQ sample data transferred between O-DU and O-RU. The Management Plane refers to non-real-time management operations between the O-DU and the O-RU. The Synchronization Plane refers to traffic between the O-RU or O-DU to a synchronization controller, for example an IEEE-1588 Grand Master. Regarding the test system it is proposed to couple the one or more test devices and / or the DUT to such a reference clock, e.g., in the form of a synchronization controller, for example said PTPv2, i.e. IEEE-1588, Grand Master or other clock.

[0067] The IEEE 1588 standard describes a hierarchical master-slave architecture for clock distribution comprising of one or more network segments and / or one or more clocks. An ordinary clock is a device with a single network connection that is either the source of or the destination for a synchronization reference, i.e. reference time. A source is called a leader, a.k.a. master, and a destination is called a follower, a.k.a. slave. A boundary clock has multiple 202404911

[0068] 11 network connections and synchronizes one network segment to another. A single, synchronization leader may be selected for each network segment. The root timing reference is called the grandmaster. A test system, which may comprise an implementation of a PTP architecture, may thus comprise one or more local clocks, i.e. ordinary clocks in terms of PTP, preferably on a single-segment network with no boundary clocks. In the test system a grandmaster may be selected and all other local clocks may thus need to synchronize to it.

[0069] The IEEE 1588-2008 protocol, i.e. PTPv2, introduces a clock, i.e. a reference clock, associated with network equipment used to convey PTP messages. One or more timestamps may be comprised in the one or more messages exchanges between the network equipment. In the case of a test system the network equipment may be the one or more test devices and / or the DUT. The timestamps in the one or more messages may be corrected for time spent traversing the network equipment. Thus, a synchronization protocol provides clock synchronization and / or may improve distribution accuracy by compensating for delivery variability across the network, in particular of the test system.

[0070] It should be understood that the radio data packets are transmitted, e.g., from a memory of a test device, to a device under test and / or via a device under test to another or the same test device over a digital communication protocol, such as a fronthaul communication protocol and / or JESD 204 B / C. For example, in the downlink direction, i.e. traffic in the direction from O- Dll to O-RU, frequency-domain IQ payload (typically obtained as part of a 3GPP DL test models) may be present in the test device. This IQ payload is packetized into one or more radio data packets, i.e. O-RAN Il-Plane downlink message(s). Optionally the IQ payload in the one or more radio data packets may be compressed. The one or more radio data packets may be sent over the communication link, e.g. fronthaul using a fronthaul protocol, with required advance time T1a. The one or more radio data packets are then received and processed by a receiver such as an O-RU, and decompressed if compression was activated. The IQ samples in the one or more radio data packets are then converted from the frequency domain into time-domain IQ samples, e.g. by way of an i FFT, for example with cyclic prefix addition. These IQ samples are then placed into JESD204 B / C frame structure as converter samples for one or more DA converters (digital to -analog converters) that feed one or more transmission antenna(s) Tx.

[0071] In the uplink direction, i.e. in the direction from the O-RU to O-DU, the time-domain IQ payload (typically 3GPP UL FRCs received from over-the-air or conducted RF cabling), the IQ payload the is created by digitizing the incoming RF signals by one or more AD converters (analog-to- digital converters) in the antenna interface (typically by a System-On-a-Chip, SoC, of the O-RU) 202404911

[0072] 12 and mapped into JESD / JESD204C frame structure. These IQ samples are extracted by the O- RU’s SoC from the JESD204C frame structure as converter samples of one or more antenna(s) Rx. The IQ samples may then additionally be processed by 0-Rll. The IQ sample in the time domain may then be converted into frequency-domain IQ samples, e.g. by way of an FFT, for example including cyclic prefix removal. The IQ samples are the packetized into one or more radio data packets, e.g. in the form of one or more O-RAN Il-Plane uplink message(s). Again, the IQ samples in the radio data packets may be compressed (optional). The one or more radio data packets are then sent via the fronthaul. Hence, the transmission of the radio data packets may be subject to a processing latency Ta3. For the sake of conciseness reference is made to Figure 3 of International Patent Application PCT / IB2022 / 056043 illustrating timing requirements between a base-band unit and a radio unit.

[0073] It should be understood that for a transmission and / or for a reception of the radio data packets one or more test devices may be used. That is, the one or more radio data packets are transmitted from the test device to the DUT and / or received by the test device from the DUT. As the case may be the DUT may be a radio unit and / or a distributed unit. The radio data packets may be transmitted over the medium connecting the one or more test devices with the device(s) under test.

[0074] Figure 6 shows a synchronization mechanism. One or more time synchronization mechanisms may be used in the test system, e.g., in a network of the test system. The test system and / or the network comprising said one or more test devices and / or said DUT. The most common standards are Network Time Protocol, NTP, and Precision Time Protocol, PTP. PTP is a network-based time synchronization standard that is designed for distributing precise time and frequency from a clock source over packet-based networks. PTP is capable of synchronizing multiple clocks to better than 100 nanoseconds on a network specifically designed for IEEE- 1588. There are different types of clocks defined in PTP: Grand Master Clock (GMC): the reference time source derived from an accurate clock such as a GNSS driven clock (i.e. GPS, GLONASS, GALILEO). Boundary Clock (BC): A network device that acts as slave to its master and as master to its slaves. Ordinary Clock (OC): A clock that operates either as a Master or a Slave. In the case of a slave, the end point whose clock is been synced (normally a host / server). Master Clock (MC): A clock that operates as a Master and derives its timing capabilities from the clock chain up to the GMC. It typically serves as a port on a BC connected to a host running as a slave. Transparent Clock (TC): A device that calculates the residence time of the PTP event message and updates the correction field of the event message before forwarding the message. 202404911

[0075] 13

[0076] Any one of said clocks, in particular said ordinary clock or local clock may provide the reference time to the one or more test device and / or DUT of the test system. Preferably the grandmaster, or grandmaster clock, which for example has a time source, such as a GPS, may serve as the reference clock. Boundary Clock (BC) acts as a secondary clock at the port that connects to the primary and distributes time to all other downstream devices. The secondary port synchronizes the time from the upstream PTP device. Transparent Clock, TC, forwards the PTP message after updating the residence time of a PTP event message. This reference clock, for example said master clock, provides synchronization messages that the one or more test devices and / or DUT, e.g., acting as slaves to the master clock, use to correct their local clocks, for example as described in Figure 2, where the local time or local clock LT10, LT 11 , LT12, LT13 is synchronized to the reference time or reference clock RT. Hitherto, one or more reference timestamps captured and / or transmitted by the reference clock are used, e.g., by the one or more test devices and / or the DUT, for example of said test system. These timestamps may be used to determine the network latency and / or to synchronize the one or more test device and / or the DUT, e.g. acting as slaves, to the reference clock, e.g. said master clock. There is a sync message transmitted, e.g., typically every two seconds from the reference clock, e.g., said master clock, and a delay request message from the slave less frequently, e.g., about one request per minute. Four timestamps are captured between the master and the respective slave clock. The timestamps are required for the slave offset calculation. The timestamps are commonly referred to as t1, t2, t3, and t4, and the synchronization steps are shown in Figure 6. The first timestamp is t1. It is the precise time of the sync message from the Master. This timestamp is sent in the follow-up message since the time of t1 was sampled when the sync message was transmitted on the Ethernet port. The second timestamp is t2. It is the precise time of the sync message as it is received at the Slave. The Master-Slave difference can be calculated once t1 and t2 are available at the Slave. In order to determine the time difference between master to slave a third timestamp is t3 is transmitted. It is the precise time of the delay request message from the slave. The fourth timestamp is t4, which is the precise time of the delay request message when received at the Master. The Slave to Master difference can be calculated once t3 and t4 are available at the Slave. The one-way delay can be calculated once the Master to Slave and Slave to Master difference is available at the Slave: One-way delay = (Master to Slave difference + Slave to Master difference) 12. The offset may be used to correct the Slave clock: Offset = Master to Slave difference - One-way delay or Offset = ((t2 - 11) - (t4 - 13)) 12.

[0077] The Grandmaster clock can provide precise (nanosecond resolution). A Grandmaster clock may incorporate a local reference oscillator serving as reference clock. This oscillator may be used 202404911

[0078] 14 as the reference clock used for the precise timestamping of the incoming delay request and(or outgoing sync packets. Similarly, the one or more test device and / or DUT may comprise an oscillator serving as local clocks respectively.

[0079] Thus, a local clock in the first test device or one or more test devices and / or in the DUT, e.g. of the test system, may be updated based on the at least one reference timestamp. Furthermore, the transmission of the one or more radio data packets, by the first test device, may be initiated and / or triggered in accordance with or at the predetermined start time, wherein the start time is determined in accordance with the local clock of the first test device or one or more of the test devices and / or the DUT. In general, any event of the test or test sequence may be determined, e.g., be initiated and / or triggered, in accordance with or at a predetermined event time.

[0080] Finally, the transmission and / or reception in particular of the one or more radio data packets, e.g. of said test stimulus, may be performed in accordance with or at a predetermined start time. In general, an event, e.g., in the test sequence, may be triggered based on a predetermined event (start) time. Said predetermined start time, or event time in general, may be configured and / or stored in the one or more test devices and / or the DUT, e.g., of said test system.

[0081] Hence, in an embodiment, a reference timestamp, e.g., from a reference clock, may be obtained, preferably repeatedly, by an additional first test device for transmitting one or more radio data packets. The reference clock provides the reference time in the test system comprising the first test device and the additional first test device. For example the test device may be said test device 11 of Figure 2 and the additional test device may said test device 12 of Figure 2, or vice versa. The reference timestamp may indicate the reference time. The reference timestamp may be used for synchronizing the first test device and the additional first test device and / or the DUT in a time domain of the test system. Furthermore, one or more radio data packets may be transmitted, by the additional first test device, in accordance with or at a predetermined start time, preferably the same start time as the first test device, in the test system on a communication interface for coupling the additional first test device with the device under test, DUT. Said transmission may also be such that the one or more radio data packets are received by the device under test, DUT, at the predetermined start time.

[0082] Furthermore, a reference timestamp from the reference clock, may be obtaining, preferably repeatedly, by a second test device, e.g., said test device 12 of Figure 2, for analyzing and / or recording the radio data packets processed by the device under test, DUT. The reference clock provides the reference time in the test system comprising the second test device, wherein the 202404911

[0083] 15 reference timestamp indicates the reference time, and preferably thereby synchronizing the first test device and the second test device in a time domain of the test system. Still Further one or more radio data packets processed by the DUT may be received by the second test device. Furthermore, the reference time may be applied, by the test device, to the one or more data packets processed by the DUT, e.g. for analyzing the correct functioning of the DUT.

[0084] In an embodiment, an arrival time may be associated, by the second test device, with the one or more radio data packets processed by the DUT in accordance with the reference time.

[0085] Preferably the one or more radio data packets processed by the DUT may be stored in the second test device.

[0086] In an embodiment, the one or more radio data packets are transmitted from the first test device to the DUT using a first communication protocol, such as JESD204(A), JESD204(B) or JESD204(C), also denoted as JESD 204B / C or simply JESD herein. The one or more radio data packets may be processed by the DUT and / or transmitted from the DUT to the second test device using a second communication protocol, preferably a fronthaul protocol, such as O-RAN fronthaul protocol. The DUT preferably converts the one or more radio data packets received in accordance with the first communication protocol into the second communication protocol.

[0087] Still further, one or more transmission times, e.g. the predetermined start time, of the one or more radio data packets transmitted by the first test device, may be compared with one or more reception times of the one or more radio data packets processed by the DUT, wherein the one or more transmission times and / or the one or more reception times are determined in accordance with the reference time.

[0088] As already mentioned, the predetermined start time may be set, e.g., by a test controller, in the first test device, the additional first test device and / or the second test device.

[0089] In general, one or more event, such as transmission events and / or reception events, such as start, end and / or duration of an idle time; and / or start, end, and / or duration of transmission; start, end and / or duration of reception, i.e. capture, relating to the transmission and / or reception, respectively, of the one or more radio data packets, e.g., on a C-plane, a U-plane, an S-plane, and / or an M-plane, may be set in the first test device, the additional first test device and / or the second test device. That is, the first test device, the additional first test device and / or the second test device may be programmed or configured accordingly, e.g. by said test controller. 202404911

[0090] 16

[0091] Figure 7 shows a timeline of a test or test sequences 70 performed by one or more test devices 11, 12, 13. The test or test sequence may comprise one or more of the following events: idle, initialization, transmission and / or capture; and corresponding start and end times. The one or more test devices 11, 12, 13 may be synchronized among each other and / or with respect to a reference clock, e.g. as described herein. Here, a plurality of (synchronized) test devices 11 , 12, and 13 are shown. The test devices 11, 12, 13 are physically separated. The test devices can be made to work together through future timestamps T 1 and T2, also referred to as predetermined start or event times. Thus, in this embodiment a plurality of start times or event times T1, T2, in general, may be used. In particular, a timing advance for test device 12 before a predetermined time T2 may be used that implies that the stimulus or radio data packets held by test device 12 requires a certain advance regarding a predetermined time T2 (which can be configured / assumed as a frame boundary) to arrive on time at the device under test, e.g. in order to coincide with the reception of the radio data packets, also denoted as frame-based test vectors in Figure 7, transmitted by the test device 11. The values of the timing advance can be determined for each test device individually. The timing advance can be determined based on (known and / or required) timing parameters of the network of the test system, specifically such as the latency values T12, T2a, Ta3, T34 of O-RAN WG4 CUS.

[0092] Hence, it is inter alia proposed to set one or more predetermined start or event times, e.g., by one or more respective timestamps (in the future). These one or more timestamps may have different types of events associated with them, e.g., a frame boundary, a capture start as mentioned herein. The test device, or any other test equipment, thus can associate a start time or other event time to those one or more timestamps. In addition, the one or more test devices may take into account one or more advance values and in fact start the transmission and / or initiate an event before the communicated timestamp, for example start or event time T minus the timing advance, for example as shown in Fig 7.

Claims

20240491117Patent claims1 . A method of transmitting one or more radio data packets (40) by a first test device (11 , 12, 13), the method comprising the steps of: obtaining, preferably repeatedly, by the first test device (11 , 12, 13), a reference timestamp from a reference clock (RT), wherein the reference clock (RT) provides a reference time in a test system (1) comprising the first test device (11 , 12, 13), wherein the reference timestamp indicates the reference time, transmitting, by the first test device (1), the one or more radio data packets, preferably sequentially, in accordance with a predetermined start time in the test system (1) on a communication interface (QSFP) for coupling the first test device (11 , 12, 13) with a device under test, DUT (10).

2. The method according to the preceding claim, further comprising: transmitting, by the first test device (11 , 12, 13), the one or more radio data packets (40) at a predetermined start time (T1 , T2) in the test system (1) on a medium coupling the first test device (11 , 12, 13) with a device under test (10).

3. The method according to any one of the preceding claims, further comprising: transmitting, by the first test device (11 , 12, 13), the one or more radio data packets (40) such that the one or more radio data packets (40) are received by the device under test, DUT (10), at the predetermined start time (T 1 , T2).

4. The method according to any one of the preceding claims, further comprising triggering the transmission of the one or more radio data packets (40) such that the one or more radio data packets (40) are present on the medium between the first test device (11 , 12, 13) and the device under test, DUT (10), in accordance with or at the predetermined start time (T 1 , T2).

5. The method according to any one of the preceding claims, further comprising updating a local clock (LT11 , LT12, LT13) in the first test device (11 , 12, 13) based on the at least one reference timestamp, and / or initiating / triggering the transmission of the one or more radio data packets (40), by the first test device (11 , 12, 13), at the predetermined start time (T1 , T2), wherein the start time (T1 , T2) is determined in accordance with the local clock (LT11 , LT12, LT13) of the first test device (11 , 12,202404911186. The method according to any one of the preceding claims, further comprising obtaining, preferably repeatedly, by an additional first test device (12) for transmitting one or more radio data packets, a reference timestamp from the reference clock (RT), wherein the reference clock (RT) provides the reference time in the test system (1) comprising the first test device (11) and the additional first test device (12), wherein the reference timestamp indicates the reference time, and preferably thereby synchronizing the first test device (11) and the additional first test device (12) in a time domain of the test system (1), transmitting, by the additional first test device (12), the one or more radio data packets (40) at a predetermined start time (T1, T2), preferably the same start time as the first test device (11), in the test system (1) on a communication interface for coupling the additional first test device (11) with the device under test, DUT (10).

7. The method according to any one of the preceding claims, further comprising obtaining, preferably repeatedly, by a second test device (13) for analyzing and / or recording the radio data packets (40) processed by the device under test, DUT (10), a reference timestamp from the reference clock (RT), wherein the reference clock (RT) provides the reference time in the test system (1) comprising the second test device (13), wherein the reference timestamp indicates the reference time (RT), and preferably thereby synchronizing the first test device (11) and the second test device (13) in a time domain of the test system, receiving, by the second test device (13), one or more radio data packets (40) processed by the DUT (10), and applying, by the second test device (13), the reference time to the one or more data packets ()40 processed by the DUT (10).

8. The method according to any one of the preceding claims, further comprising associating, by the second test device (13), an arrival time with the one or more radio data packets (40) processed by the DUT (10) in accordance with the reference time, and preferably storing the one or more radio data packets (40) processed by the DUT (10) in the second test device (13).

9. The method according to any one of the preceding claims, further comprising wherein the one or more radio data packets (40) are transmitted from the first test device to the DUT (10) using a first communication protocol, such as JESD204(B) or (C), and wherein the one or more radio data packets (40) processed by the DUT (10) are transmitted from the DUT (10) to the second test device (13) using a second communication protocol, preferably a fronthaul protocol, such as O-RAN fronthaul protocol, and wherein preferably the20240491119DUT (10) converts the one or more radio data packets (40) received in accordance with the first communication protocol into the second communication protocol.

10. The method according to any one of the preceding claims, further comprising comparing one or more transmission times, e.g. the start time, of the one or more radio data packets (40) transmitted by the first test device, with one or more reception times of the one or more radio data packets (40) processed by the DUT, wherein the one or more transmission times and the one or more reception times are determined in accordance with the reference time.

11. The method according to any one of the preceding claims, further comprising setting, by a test controller (15), the predetermined start time in the first test device (11), the additional first test device (12) and / or the second test device (13).

12. The method according to any one of the preceding claims, further comprising setting, by a test controller (15), one or more transmission events and / or reception events, such as start, end and / or duration of an idle time; and / or start, end, and / or duration of transmission; start, end and / or duration of reception, i.e. capture, relating to the transmission and / or reception, respectively, of the one or more radio data packets (40), e.g., on a C-plane, a U-plane, an S- plane, and / or an M-plane, in the first test device (11), the additional first test device (12) and / or the second test device (13).

13. A computer program, preferably on a non-transitory medium, that comprises program code that when carried out performs the method steps according to any one of the preceding claims.

14. A first test device (11 , 12), preferably comprising a processor and a memory, operative to perform the method steps in accordance with any one of the preceding claims.

15. A second test device (13) operative to perform the method steps in accordance with any one of the preceding claims.

16. A test system (1) comprising a device under test and further comprising the first test device (11), the additional first test device (12) and / or the second test device (13) according to any one of the preceding claims.

Images