EP4702783A1

EP4702783A1 - A network entity for synchronization over a packet-based fronthaul network

Info

Publication number: EP4702783A1
Application number: EP23935552.2A
Authority: EP
Inventors: Igor Almeida; Eduardo Lins De Medeiros
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-04-24
Filing date: 2023-04-24
Publication date: 2026-03-04
Also published as: WO2024225939A1

Abstract

A method for synchronizing one or more baseband network entity with one or more radio network entity across a packet-based fronthaul network carrying Time-Division Duplex, TDD, radio transmissions is provided. The method comprise obtaining a time misalignment between a synchronization data-packet stream and a TDD radio 5 transmission data-packet stream traversing the packet-based fronthaul network. Also, the method comprise adjusting the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data- packet stream using the determined time misalignment. Further, the method comprise shifting the departure time of one or more synchronization data-packets in the 10 synchronization data-packet stream to one or more time periods in which no data-packet in the TDD radio transmission data-packet stream is scheduled for transmission. A network entity is also provided, as well as, computer programs and carriers.

Description

A NETWORK ENTITY FOR SYNCHRONIZATION OVER A PACKET-BASED FRONTHAUL NETWORK TECHNICAL FIELD Embodiments herein relate to synchronization over a packet-based fronthaul network. In particular, embodiments herein relate to a network entity and method therein for synchronizing one or more baseband network entity with one or more radio network entity across a packet-based fronthaul network carrying Time-Division Duplex, TDD, radio transmissions. Further, the embodiments herein also relate to a computer program and a carrier. BACKGROUND In today’s wireless communications networks a number of different technologies are used, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/Enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible technologies for wireless communication. A wireless communications network commonly comprises radio base stations providing radio coverage over at least one respective geographical area forming a cell. This is commonly referred to as a Radio Access Network, RAN. The RAN is in turn connected to the core network in the wireless communications network via a so-called backhaul network. Wireless devices, User Equipments (UEs), mobile stations, and/or wireless terminals, are served in the cells by the respective radio base station and are communicating with respective radio base station in the RAN over an air/radio interface. Commonly, the wireless devices transmit data over the air/radio interface to the radio base stations in uplink, UL, transmissions and the radio base stations transmit data over the air/radio interface to the wireless devices in downlink, DL, transmissions. Another different type of RAN comprise centralized baseband processing units and standalone remote radio units, such as, e.g. Remote Radio Heads, RRHs, or indoor radio dot units in a Radio Dot System, RDS. In some cases, the remote radio units may be installed at remote cell sites that may be located up to tens of kilometres away from its baseband processing unit. This type of RAN is commonly referred to as Centralized RAN (C-RAN). The intermediate links connecting baseband processing units and radio units are referred to as fronthaul network, and may comprise optical communications links and intermediate network switching nodes (such as, routers or switches). A fronthaul network typically has rather strict latency requirements, such as, typically below 100 µs total latency including propagation delay and any delay in the intermediate network switching nodes. For 2G/3G/4G wireless communications network, the fronthaul network has typically been implemented using the Common Public Radio Interface, CPRI. CPRI uses time division multiplexing and has built-in synchronization capabilities. A packet-based fronthaul network specification, eCPRI, has been developed to improve scalability for 4G/5G fronthaul networks. This specification suggest IEEE 1588- 2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, a Precision Time Protocol, PTP, for synchronization of remote radio units. Using this protocol avoids the need for costly Global Navigation Satellite System, GNSS, receivers in every remote radio unit, which otherwise is a requirement. This also has further advantages since GNSS receivers does not work well for indoor remote radio units. This PTP protocol, or other similar packet-based synchronization protocols, may be used to synchronize fronthaul network units across a fronthaul network. These protocols rely on exchanging timestamped messages and tracking the deviation between a master/leader clock in a master/leader unit and a slave/follower clock in a slave/follower unit. In an end-to-end measurement mode, the clock adjustment value in PTP may be derived from timestamps exchanged using these packet-based synchronization messages e.g.: - Sync-message. Transmitted from master/leader unit to slave/follower unit. Multiple Sync-messages may be transmitted prior to a Delay request message. - Follow-up-message. Transmitted from master/leader unit to slave/follower unit. This is an optional message that depends on the hardware timestamping capabilities of the master/leader unit. - Delay request message. Transmitted from slave/follower unit to master/leader unit. - Delay response message. Transmitted from master/leader unit to slave/follower unit. A PTP exchange is concluded when the slave/follower unit has access to four timestamps ( ^^_^, ^^_ଶ, ^^_ଷ, ^^_ସ). After a Sync-message is delivered, the slave/follower unit will have ^^_^ and ^^_ଶ. It should here be noted that ^^_^ may be comprised in the Sync-message or in the Follow-up message, while ^^_ଶ may be registered by the slave/follower unit when the Sync-message is received. ^^_ଷ is registered when the Delay request-message departs the slave/follower unit and ^^_ସ is registered by the master/leader unit on receipt of the Delay request-message. The Delay response-message carries ^^_ସ back to the slave/follower unit. One of the main drawbacks in using this type of protocol is Packet Delay Variation, PDV. PDV occurs because the time to traverse the fronthaul network and the network switching nodes therein may vary between the PTP packets. The PDV in a fronthaul network may be dependent on a number of factors, such as, for example, the load in the fronthaul network, the number of hops between the baseband processing unit and the radio unit (e.g. because of the store-and-forward nature of the intermediary network switching nodes in the fronthaul network), and availability of specific network features, such as, packet pre-emption. The PDV may also introduce noise in the timing estimates in the fronthaul network, and thus also affect the synchronization accuracy in the fronthaul network. One example of a measurement of the synchronization accuracy is the Timing Alignment Error, TAE, between radio units. The TAE depends on the type of services supported by the fronthaul network. The most advanced services, such as, e.g. spatial multiplexing or transmit diversity, may require a TAE below ± 65 ns, while less advanced services, such as, e.g. LTE Time Division Duplexing, LTE-TDD, may work with a TAE below ± 1.5 µs. However, positioning features, such as, e.g. Observed Time Difference of Arrival, OTDOA, may introduce even stricter requirement on the TAE. One approach to mitigate PDV, and to ensure a suitable performance in the synchronization plane, is to only have PTP-aware network switching nodes in the fronthaul network. PTP-aware network switching nodes may in this case implement a PTP Transparent Clock or a Boundary Clock. However, this significantly increases the costs in the fronthaul network, in particular, for indoor radio communication networks. Another approach to mitigate PDV is to use so-called controlled packet departure. In controlled packet departure, the gap between Sync packets and other traffic is managed in such a way that the Sync packets are not heavily affected by queuing effects, and may be implemented using functionality, such as, e.g. source back- off and pause frames in Ethernet. However, the effectiveness of such solutions depends of the support of these features by the underlying hardware. A major problem is that a large part of the “side traffic” in packet-based fronthaul networks might carry radio content having very strict latency requirements. In such cases, it might not be possible to pause and buffer frames since this may violate the latency requirement, which means that data packets would have to be dropped. Also, backpressure on the source might not be feasible either since the data traffic is real-time data generated by the baseband processing function. Furthermore, if data packets are very frequent, there might not be enough gap for the data packet to go through the fronthaul network unimpeded. A further approach to mitigate PDV is to use Time-Sensitive Networking, TSN, features, such as, e.g. packet pre-emption and scheduled traffic. This, however, adds a lot of support requirements from the network equipment, and will also increase the cost of the fronthaul network. It should also be noted that many TSN features require a high level of synchronization as a pre-condition. A further approach to mitigate PDV and improve performance is to use packet selection at the receiving fronthaul network unit, i.e. the slave/follower unit at the other end of the fronthaul network. This means that a slave/follower unit may, from a set of observations, select and use the observations that has minimum delay (or more frequent delay value), e.g. as calculated over a finite observation window of N observations. In other words, selecting and utilizing only the synchronization data-packets having the smallest delay or most frequent delay value. However, this packet selection implies discarding a high number of synchronization data-packets, which necessitates a large observation window or resulting in a large variance when small observation window is used. Hence, there is a need to improve synchronization over a packet-based fronthaul network. SUMMARY It is an object of the present disclosure to mitigate, alleviate or eliminate one or more of the above-identified deficiencies and disadvantages in the prior art to improve synchronization over a packet-based fronthaul network. According to a first aspect of embodiments herein, the object is achieved by a method performed by a network entity for synchronizing one or more baseband network units with one or more radio network units across a packet-based fronthaul network carrying Time-Division Duplex, TDD, radio transmissions. The network entity obtains a time misalignment between a synchronization data-packet stream and a TDD radio transmission data-packet stream traversing the packet-based fronthaul network. The network entity also adjusts the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data- packet stream using the determined time misalignment. Further, the network entity shifts the departure time of one or more synchronization data-packets in the synchronization data-packet stream to one or more time periods in which no data-packet in the TDD radio transmission data-packet stream is scheduled for transmission. According to a second aspect of embodiments herein, the object is achieved by a network entity for synchronizing one or more baseband network units with one or more radio network units across a packet-based fronthaul network carrying Time-Division Duplex, TDD, radio transmissions. The network entity is configured to obtain a time misalignment between a synchronization data-packet stream and a TDD radio transmission data-packet stream traversing the packet-based fronthaul network. The network entity is also configured to adjust the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data-packet stream using the determined time misalignment. Further, the network entity is configured to shift the departure time of one or more synchronization data-packets in the synchronization data-packet stream to one or more time periods in which no data-packet in the TDD radio transmission data-packet stream is scheduled for transmission. According to a third aspect of the embodiments herein, a computer program is also provided configured to perform the method described above. Further, according to a fourth aspect of the embodiments herein, carriers are also provided configured to carry the computer program configured for performing the method described above. By obtaining the misalignment metric, adjusting the synchronization data-packet stream such that it is aligned with the TDD radio transmission data-packet stream and shifting the departure time of one or more synchronization data-packets, the network entity is able to arrange more transmissions of synchronization data-packets that are less impacted by queuing delays, for example, by delaying or advancing them to avoid intervals with high probability of contention. Hence, the network entity is able to reduce the delay variance for time offset estimations in the fronthaul network and improve performance of the synchronization data-packet stream, e.g. improved synchronization data-packet frequency, time and phase tracking performance of a synchronization data- packet stream, etc. Hence, synchronization over the packet-based fronthaul network is improved. BRIEF DESCRIPTION OF THE DRAWINGS Features and advantages of the embodiments will become readily apparent to those skilled in the art by the following detailed description of exemplary embodiments thereof with reference to the accompanying drawings, wherein: Fig.1 is a schematic block diagram of a network architecture for a packet-based fronthaul network, Fig.2 is another schematic block diagram of a network architecture for a packet- based fronthaul network, Fig.3 is a timing diagram of a packet-based fronthaul network carrying TDD data traffic, Fig.4 is another timing diagram of a packet-based fronthaul network carrying TDD data traffic, Fig.5 is a flowchart depicting embodiments of a method, Fig.6 are schematic diagrams depicting delays in a packet-based fronthaul network, Fig.7 is a schematic illustration of signalling according to some embodiments, Fig.8 is another schematic illustration of signalling according to some embodiments, Fig.9 is a further schematic illustration of signalling according to some embodiments, Fig.10 is a diagram depicting transmission times of synchronization data-packets in a synchronization data-packet stream according to some embodiments versus transmission times of synchronization data-packets in the original synchronization data-packet stream, Fig.11 is a histogram depicting positions within the TDD window for synchronization data-packets according to some embodiments versus positions within the TDD window for synchronization data-packets in the original synchronization data-packet stream, Fig.12 is a histogram depicting an interval spread of a synchronization data- packet stream according to some embodiments versus the interval period of the original synchronization data-packet stream, Fig.13 is a block diagram depicting embodiments of a network entity. DETAILED DESCRIPTION The figures are schematic and simplified for clarity, and they merely show details which are essential to the understanding of the embodiments presented herein, while other details have been left out. Throughout, the same reference numerals are used for identical or corresponding parts or steps. Figs.1-2 illustrates examples of simplified network architectures for a packet- based fronthaul network 100 in a Radio Access Network, RAN. The topology of the network architecture for the packet-based fronthaul network 100 in Fig.1 may be referred to as a tree-like structure, while the topology of the network architecture for the packet- based fronthaul network 100 in Fig.2 may be referred to as a dumbbell-like structure. The packet-based fronthaul network 100 in Figs.1-2 may be any packet-based fronthaul network capable of carrying Time-Division Duplex, TDD, radio transmissions, i.e. this means that the packet-based fronthaul network fulfils the delay requirements for serving certain Radio Access Technologies, RATs, configured with TDD radio transmissions. Also, the packet-based fronthaul network 100 in Fig.1-2 may be implemented in a TDD- based RAN, such as, e.g. a NR or a LTE-TDD RAN, etc. Further, the packet-based fronthaul network 100 in Figs.1-2 may comprise one or more baseband processing units, ^^ ^^ _^^, ^^ ^^ _^^, … , ^^ ^^ _^^. The baseband processing units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may be connected to one or more remote radio units, ^^ ^^ _^^, ^^ ^^ _^^, … , ^^ ^^ _^^, via a number of intermediate fronthaul network switching nodes 101, 201. Here, k and m may be any integers depending on suitable deployment in the packet-based fronthaul network 100. The baseband processing units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, the remote radio units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, and the number of intermediate fronthaul network switching nodes 101, 201 may be configured to communicate with each other over optical communications links in the packet-based fronthaul network 100. For the purpose of describing the advantages of the embodiments described herein, it should be noted that there are no direct communication links described between any of the one or more of the remote radio units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, and their corresponding baseband processing unit, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Conventionally, in such packet-based fronthaul networks, the intermediate fronthaul network switching nodes 101, 201 will most prominently execute store-and-forward operations such that fronthaul data and control signalling, i.e. including synchronization data-packets or messages, may traverse the packet-based fronthaul network 100. This means that a delay will be introduced in the packet-based fronthaul network 100 that is at least partly dependent on the number of hops between the baseband processing units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, and the remote radio units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Further, it should also be noted that the use of multiple intermediate fronthaul network switching nodes may be required in the packet- based fronthaul network 100, for example, in indoor deployments where the remote radio units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ are scattered in multiple floor levels. In addition, the intermediate fronthaul network switching nodes 101, 201 may also comprise clocks or built-in uncertainties that may contribute to the overall delay experienced by a data packet, for example, a clock having a high frequency offsets or implementation specific indeterminacies in their switch fabric or forwarding engine, etc. This contribution to the overall delay, however, is normally relatively small in comparison. However, a significant reason behind the PDV in the packet-based fronthaul network 100 is that the synchronization data-packets in the packet-based fronthaul network 100 are competing for the same outbound link in each intermediate fronthaul network switch 101, 201 as the ordinary data traffic generated by the baseband processing units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in the DL direction and the remote radio units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in the UL direction. Here, PDV may occur even if the synchronization messages have strictly higher priority than ordinary data packets, also referred to herein as fronthaul data or control packets. This is because, due to the store-and-forward operations implemented in the intermediate fronthaul network switch 101, 201, data packets that are already being transmitted on the outbound link are not considered when deciding which data packet should be transmitted next. As part of the developing of the embodiments described herein, an important realization is that, when carrying radio content for TDD systems, a packet-based fronthaul network exhibits a similar periodic utilization pattern as that of the radio or air interface. For example, in a DL direction, the traffic characteristics generated by multiple baseband processing units may be observed to have a periodicity similar to the subsequent air interface. In other words, the DL traffic in the packet-based fronthaul network shows a TDD pattern where the links essentially are utilized in half-duplex mode even when signals are aggregated. Similar reasoning may also be applied to the UL direction from the remote network units. Thus, the dynamic TDD behaviour of the air interface will also likely be observed in the fronthaul network interfaces used. One example of how this may be utilized is described below with reference to the timing diagram of a fronthaul network 100 carrying TDD data traffic in Fig.3. For the sake of simplicity and for illustrative purposes, the signalling example shown in Fig.3 is performed between a first fronthaul network unit, such as, e.g. a baseband processing unit ^^ ^^_^, and a second fronthaul network unit, such as, a remote radio unit ^^ ^^_^, over a fronthaul network, such as, the packet-based fronthaul network 100. Here, the timing from the perspective of a single DL slot in the DL direction followed by a single UL slot in the UL direction is illustrated, but also the timing of the subsequent signalling on the radio interface, i.e. over the air. In Fig.3, a series of time instances are referenced. These are described below (wherein the subscript i is used to denote the i-th time occurrence): ^ Time instance ^^ denotes the start of DL slot transmission on the fronthaul network interface of the baseband processing unit ^^ ^^_^; ^ Time instance ^^ denotes the start of DL slot transmission on the remote radio unit’s antenna, i.e. over the radio interface. This means that the time difference between time instance ^^ and time instance ^^ covers the time period that the data packets take to traverse the packet-based fronthaul network 100 plus the processing time at the remote radio unit ^^ ^^_^; ^ Time instance ^^ denotes the end of the DL slot transmission on the fronthaul network interface of the baseband processing unit ^^ ^^_^. This means that the time difference between time instance ^^ and time instance ^^ covers the DL slot duration in the packet-based fronthaul network 100. This duration may differ compared with the DL slot duration over the radio interface because of, for example, transmission of beamforming weights and other control information between the baseband processing unit ^^ ^^_^ and the remote radio unit ^^ ^^_^. The latter may occur when having certain functional splits between the baseband processing unit ^^ ^^_^ and the remote radio unit ^^ ^^_^; ^ Time instance ^^ denotes the end of DL slot transmission on the remote radio unit’s antenna, i.e. over the radio interface. This means that the time difference between time instance ^^ and time instance ^^ covers the duration of a DL slot on the radio interface; ^ Time instance ^^ denoted the start of uplink reception at the remote radio unit’s antenna, i.e. over the radio interface. This means that the time difference between time instance ^^ and time instance ^^ covers the guard period between DL and UL slots; ^ Time instance ^^ denotes the start of UL slot transmission over the fronthaul network interface of the remote radio unit ^^ ^^_^. This means that the time difference between time instance ^^ and time instance ^^ covers the processing time of the remote radio unit ^^ ^^_^; ^ Time instance ^^ denotes the end of UL slot reception at the remote radio unit’s antenna, i.e. over the radio interface; and ^ Time instance ^^ denotes the end of UL slot transmission over the fronthaul network interface of the remote radio unit ^^ ^^_^. This means that the time difference between time instance ^^ and time instance ^^ covers the UL uplink slot duration in the packet-based fronthaul network 100. Also, this duration may differ compared with the UL slot duration over the radio interface because of, for example, transmission of channel estimates and other control information between the baseband processing unit ^^ ^^_^ and the remote radio unit ^^ ^^_^. The latter may occur when having certain functional splits between the baseband processing unit ^^ ^^_^ and the remote radio unit ^^ ^^_^. In Fig.3, scheduling opportunities in UL and DL for synchronization data-packet streams in the fronthaul network 100 is denoted by the dashed time periods, i.e. the PTP OP. These scheduling opportunities in UL and DL may be utilized by a synchronization data-packet stream and its synchronization data-packets in the fronthaul network so as to mitigate variance, PDV. One issue here is that, since the synchronization data-packet stream is usually operated independently of the TDD radio transmission data-packet stream, implementing a schedule of a synchronization data-packet stream that takes advantage of these scheduling opportunities implies that the synchronization data-packets of the synchronization data-packet stream that are scheduled for transmission outside of these scheduling opportunities are simply discarded, e.g. by a second fronthaul network unit, such as, a remote radio unit ^^ ^^_^, i.e. a PTP slave/follower unit. This may cause a reduced time and phase tracking performance of the synchronization data-packet stream, which may reduce the overall synchronization performance. Certain modifications or restrictions may also be made for the TDD radio transmission data-packet stream so as to prolong or extend the scheduling opportunities. However, this results in that less data-packets of the TDD radio transmission data-packet stream will be sent out on the fronthaul network 100, i.e. reduced radio interface capacity. In order to address these issues, an adjustment procedure according to some embodiments described herein is instead suggested. For example, a misalignment metric may be calculated between synchronization data-packets departures in an original synchronization data-packet stream, e.g. as determined by another network node such as a GM, and the TDD pattern in fronthaul network. Then, for each possible position of a synchronization data-packet in the original synchronization data-packet stream within the TDD pattern, a decision may be made whether to advance or delay the departure of a synchronization data-packet and by how much. The original synchronization data-packet stream may thus be adjusted to implement the new schedule and fix the original misalignment. In other words, the embodiments herein may modify each synchronization data-packet departure time into a new modified synchronization data-packet stream in view of fronthaul network usage patterns, such that the synchronization data-packets of the new modified synchronization data-packet stream experience lower delays than they would without modification of their departure times according to the original synchronization data-packet stream or avoids being discarded. This is achieved by understanding where in a TDD usage of fronthaul the synchronization data-packets would be positioned, and delaying or advancing them to avoid intervals with high probability of contention. Hence, an advantage of some of the embodiments herein is that the variance, PDV, for time offset estimations is reduced due to using synchronization data-packet streams that are less impacted by queuing delays. An advantage of some of the embodiments herein is also that no modifications to any standards is required, while tolerance margins and requirements from IEEE 1588 may still be respected. A further advantage of some of the embodiments herein is that the increased number of useful exchanges enabled will allow the use of smaller observation windows. This is advantageous both for memory consumption, as well as, for keeping certain parameters, such as, e.g. time offset and frequency offset, constant during estimation. In reference to the embodiments described hereinafter, the term “network entity” or “fronthaul network unit” may refer to any one of the baseband processing units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, or the remote radio units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Fig.4 shows a timing diagram of a fronthaul network 100 carrying TDD data traffic similar to the timing diagram of Fig.3. Here, it should be noted that in these TDD systems of the fronthaul network 100, synchronization data-packet distribution relies on message- based protocols, such as, e.g. IEEE 1588v2 PTP. Thus, the synchronization data-packets of a synchronization data-packet stream or probe, e.g. PTP Sync-messages, will traverse the fronthaul network 100 alongside ordinary fronthaul data-packets. These synchronization data-packets or probes are configured to depart the baseband processing units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, or the remote radio units, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, periodically; typically with a power-of-two rate, such as, e.g. with 16, 64 or 128 synchronization data-packets per second, effectively performing a uniform sampling of the fronthaul network’s one-way delays. Thus, additionally, Fig.4 also illustrates, in the uppermost part, an example of transmit opportunities ^^ for synchronization data-packets of a synchronization data-packet stream in a fronthaul network 100. The transmit opportunities ^^ may be referred to as time slots in which synchronization data-packets may be scheduled for transmission. This scheduling may, for example, be performed by a Grand Master, GM, synchronization unit, e.g. a baseband processing unit ^^ ^^_^ comprising a master/leader clock. Here, it should be noted that the transmit opportunities ^^ in set B indicate time-slots for which sent synchronization data-packets would experience low DL competition in the fronthaul network 100, while the transmit opportunities ^^ in set A indicates time-slots for which sent synchronization data-packets would experience higher DL competition. Analogous low- and high competition sets may be derived for the transmit opportunities S on the UL, i.e. in the other transmit direction. Note that in Fig.4, even though 16 transmit opportunities ^^ per 1 ms slot is a realistic number, the timing diagram in Fig.4 is not drawn to scale, but included for illustrative purposes. The transmission opportunities ^^ arise due to the pairing between an inverse power-of-two period (e.g., 1/32 s, 1/64 s) of the synchronization data- packet stream and the repeating TDD transmit pattern in the fronthaul network 100. These are commonly in the order of milliseconds, such as, for example, 1 ms for a normal LTE/NR slot duration, 5 ms for a common slot sequence DDDSU in an NR TDD configuration, or 10 ms. As previously mentioned, the embodiments described herein suggest an adjustment or manipulation of an original synchronization data-packet stream or probe’s departure time in order to avoid regions of the TDD window that would present a high competition for network resources in the fronthaul network 100. Thus, avoiding higher one-way delays, which is the main source of errors or noise for the synchronization estimation algorithms in the fronthaul network 100. This is described more in detail below with reference to Figs. 7-9. Examples of embodiments of a method performed by a network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ for synchronizing one or more baseband network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ with one or more radio network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ across a packet- based fronthaul network 100 carrying Time-Division Duplex, TDD, radio transmissions, will now be described with reference to the flowchart depicted in Fig.5. Fig.5 is an illustrated example of actions or operations which may be taken by the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in the packet-based fronthaul network 100. The method may comprise the following actions. Action 501 First, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ obtains a time misalignment ^^ ^^^∗ between a synchronization data-packet stream and a TDD radio transmission data-packet stream traversing the packet-based fronthaul network 100. Upon starting the fronthaul interface subsystems and the synchronization between the one or more baseband network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ and the one or more radio network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ across a packet-based fronthaul network 100, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ has no guarantee that the synchronization data-packet stream, e.g. a PTP data-packet stream, is aligned with the TDD radio transmission data- packet stream at, for example, one-second beats. This may result in a constant offset of the transmit opportunities ^^ in the synchronization data-packet stream with respect to the repeating TDD pattern of the TDD radio transmission data-packet stream. This constant offset is captured by the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in obtaining the time misalignment ^^ ^^^∗. In some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may obtain the time misalignment ^^ ^^^∗by determining the time misalignment ^^ ^^^∗ based on the departure time of a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream and the timing of the data-packet transmission periods ^[ ^^_^ , ^^_^ ^], ^[ ^^_^ା^, ^^_^ା^ ^], ^[ ^^_^ , ^^_^ ^], ^[ ^^_^ା^, ^^_^ା^ ^] in the TDD radio transmission data-packet stream. the DL direction, this means, for example, that a baseband network unit ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may query a timestamping unit internally in the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in order to compare the synchronization data packet stream’s departure times with the repeating TDD pattern of the TDD radio transmission data-packet stream. This case may, for example, apply to scenarios wherein a PTP two-step synchronization or similar is utilized. Alternatively, besides querying a timestamping unit internally in the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may, for example, directly extract the departure time ^^_^ ^{(^)} from PTP Follow-up-messages issued after the first synchronization data i.e. main PTP Sync-message probes, have been sent. Correspondingly, for data- packet streams in the UL directions, this may instead be performed by a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Further, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may determine the time misalignment ^^ ^^^∗ further as the minimum value between a departure time of a synchronization data-packet ^^^ᇱ in the synchronization data- packet stream and a start ^^_^, ^^_^ା^, ^^_^, ^^_^ା^ of a data-packet transmission period in the TDD radio transmission data-packet stream. In the DL direction, this means, for example, that a baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may determine the time misalignment ^^ ^^^∗ as the smallest absolute value to the next ^^_^ time instant, as shown in Figs.3-4. In other words, ( ^^^∗, ^^^∗) = argmin_^,^| ^^_^ ^{(^)} − ^^_^| will yields the time misalignment ^^ ^^^∗ metric according to ^^ ^^^∗ = ^^_^ ^{(^∗)} − ^^_^ ^∗ (Eq.1) Correspondingly, for synchronization data-packet streams in the UL directions, this may be performed by radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ with respect to the smallest absolute value to the next ^^_^ time instant, i.e. the departure time of the next scheduled UL data packet in the fronthaul network. Alternatively, in some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may obtain the time misalignment ^^ ^^^∗ by receiving the time misalignment ^^ ^^^∗ from another fronthaul network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in the packet-based fronthaul network 100. In the DL direction, this means, for example, that in cases where a timestamping unit is not easily accessible in the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may use information from a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, at the other side of the packet-based fronthaul network 100. Here, the radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may start gathering one-way delay statistics as measured by synchronization data packet streams, i.e. PTP Sync-message probes. Once a significant number of samples to distinguish the low-delay from high-delay transmit opportunities, the time misalignment ^^ ^^^∗ may be determined based on from their transition, as illustrated in Fig.6. This information may subsequently be transmitted to the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ by the the radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, e.g. via a message in the control plane. In Fig.6, two diagrams depicting examples of one-way delays in a packet- based fronthaul network 100 as determined by a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ for the UL and DL directions, respectively are presented. In the two diagrams, the one-ways delays, from ^^_ଶ − ^^_^ for DL direction (left) and ^^_ସ − ^^_ଷ for the UL direction (right) are grouped by the synchronization exchange start time, ^^_^mod 10 ms. Here, ^^_^ to ^^_ସ follows the notation of synchronization timing according to the PTP protocol as previously described. Thus, for example, the time misalignment ^^ ^^^∗ in the DL direction may be extracted and determined from the low-to-high transition at approximately 4 ms (left). Correspondingly, for synchronization data-packet streams in the UL directions, this may instead be performed by the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. In some embodiments, the synchronization data-packet stream and the TDD radio transmission data-packet stream are both traversing the packet-based fronthaul network 100 in either an uplink, UL, direction or a downlink, DL, direction. For the DL, this means that the network entity may be a baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ synchronizing with a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ and that both the synchronization data-packet stream and the TDD radio transmission data-packet stream are both traversing the packet-based fronthaul network 100 in the DL direction. For the UL, this means that the network entity may be a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ synchronizing with a baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ and that both the synchronization data-packet stream and the TDD radio transmission data-packet stream are both traversing the packet-based fronthaul network 100 in the UL direction. According to some embodiments, the packet-based fronthaul network 100 may be full-duplex. This means that fronthaul data and control signalling, i.e. including packet- based synchronization messages, may be simultaneously transmitted in the UL and DL direction across the packet-based fronthaul network 100. Also, in some embodiments, the synchronization data-packets ^^^ᇱ in the synchronization data-packet stream are timestamped data packets according to a packet-based synchronization protocol. For example, the packet-based synchronization messages may be synchronization messages as defined in the Precision Time Protocol, PTP, e.g. Sync- and Delay request messages, as previously described. Action 502 After obtaining the time misalignment ^^ ^^^∗ in Action 501, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ adjusts the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data-packet stream using the determined time misalignment ^^ ^^^∗. This enables a simpler determination of potential shifts in departure times of one or more synchronization data- packets ^^^ᇱ in the synchronization data-packet stream as described below with reference to Action 503. Action 503 After the adjustment in Action 502, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ shifts the departure time of one or more synchronization data-packets ^^^ᇱ in the synchronization data-packet stream to one or more time periods [ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^] in which no data-packet in the TDD radio transmission data-packet stream is scheduled for transmission. In the DL direction, this means, for example, that a baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may determine whether each transmission opportunities ^^ used for transmitting a synchronization data-packet ^^^ᇱ in an original synchronization data-packet stream must be shifted, i.e. delayed or advanced, and if so, by how much. Naturally, there may be no need to alter transmission opportunity ^^ used for transmitting a synchronization data-packet ^^^ᇱ in an original synchronization data-packet stream that are already scheduled within the low-delay portions [ ^^_^, ^^_^ା^] of the TDD window [ ^^_^ , ^^_^ା^]. Correspondingly, for synchronization data-packet streams in the UL directions, this may instead be performed by a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. In other words, for synchronization data-packet streams in the DL direction, instead of allowing a synchronization data-packet ^^^ᇱ in an synchronization data-packet stream to depart the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ during the interval ^[ ^^_^ , ^^_^ ^] of the TDD window [ ^^_^ , ^^_^ା^], the synchronization data-packet ^^^ᇱ in an synchronization data- packet stream would either be postponed to the interval [ ^^_^, ^^_^ା^] or advanced to the interval [ ^^_^ି^, ^^_^] by the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Similarly, for data-packet streams in the UL direction, instead of allowing a data-packet ^^^ᇱ in an synchronization data-packet stream to depart the radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ during the interval [ ^^_^ , ^^_^], the synchronization data- packet ^^^ᇱ in an synchronization data-packet stream would either be postponed to the interval [ ^^_^, ^^_^ା^] interval or advanced to the interval [ ^^_^ି^, ^^_^] by the radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Intuitively, avoiding regions where fronthaul data-packets are being transmitted decreases the chances of queueing synchronization data-packets ^^^ᇱ in intermediate switching nodes. In some embodiments, the shift in departure time of one or more synchronization data-packets ^^^ᇱ in the synchronization data-packet stream may either be an advancement ^^ or a delay ^^ of the departure time based on one or more thresholds ^^_^ , ^^_ௗ. In the DL direction, this means, for example, that a baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may comprise one or more thresholds ^^_^ , ^^_ௗ that may be considered in order to determine whether the one or more synchronization data-packets ^^^ᇱ in the synchronization data- packet stream should be advances or delayed. Here, it should be noted that the thresholds ^^_^ , ^^_ௗ may comprise an overlap in the decision regions (e.g. as demonstrated in the below examples). This means that transmission opportunities ^^ used for transmitting a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream that are within the intervals given by ^^_^ , ^^_ௗ may either be delayed or advanced. In this case, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may determine which is more suitable in each specific case; for example, if there are more transmission opportunities ^^ in the [ ^^_^ , ^^_^] interval shown in Fig.8, i.e. the decision region indicating that an advance should be made, than in the [ ^^_ௗ , ^^_i] interval shown in Fig.7, i.e. the decision region indicating that an delay should be made, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may determine that some transmission opportunities ^^ used for transmitting a synchronization data- packet ^^^ᇱ in the synchronization data-packet stream in the overlapping part of the decision regions is to be delayed (i.e. not advanced) in order to avoid sending too many synchronization data-packets ^^^ᇱ of the synchronization data-packet stream during a short period of time. Alternatively, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may also determine to decrease the thresholds ^^_^ , ^^_ௗ such that there is no longer any overlap in the decision regions. Here, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^,, may determine the one or more thresholds ^^_^ , ^^_ௗ based on the duration of the data-packet transmission period in the TDD radio transmission data-packet stream and the transmission rate of the synchronization data- packets ^^^ᇱ in the synchronization data-packet stream. In the DL direction, this means, for example, that the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may determine that transmission opportunities ^^ used for transmitting a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream that would originally depart during the DL portion [ ^^_^ , ^^_^] of the TDD window [ ^^_^ , ^^_^ା^] is to be delayed until the next low-delay portion of the TDD window [ ^^_^, ^^_^] if their departure time is at least ^^_ௗ ms after the beginning of the DL portion, ^^_^. Correspondingly, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may determine that transmission opportunities ^^ used for transmitting a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream that would originally depart during the DL portion [ ^^_^ , ^^_^] of the TDD window [ ^^_^ , ^^_^ା^] is to be advanced to the previous low-delay portion of the TDD window [ ^^_^ି^, ^^_^ି^] if their departure time is at most ^^_^ ms after the beginning of the DL portion, ^^_^. As an example, consider a TDD window [ ^^_^, ^^_^ା^] of 10 ms, wherein 7 ms is reserved for the DL portion [ ^^_^, ^^_^]. The duration of the DL portion [ ^^_^, ^^_^] is here denoted ^^_DL. Further consider a synchronization data-packet stream comprising 64 synchronization data-packets ^^^ᇱ per second. Adhering to a 30% tolerance margin, this would yield a delay decision threshold ^^_ௗ according to Eq.2: ^^_ௗ = ^^_DL − ^ ^ସ ∗ 0,3 = 2.3125 ^^ ^^ (Eq.2) to the same example, adhering to a 30% tolerance margin, this would yield an advance decision threshold ^^_^ according to Eq.3: ^^_^ = ^ ^ସ ∗ 0,3 = 4.6805 ^^ ^^ (Eq.3) In this case, to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may determine the one or more thresholds ^^_^ , ^^_ௗ further based on a tolerance margin 1202 for the time intervals between the synchronization data-packets in the synchronization data-packet stream. In the DL direction, this means, for example, that the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may use the thresholds ^^_^ , ^^_ௗ for each decision to shift a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream which adheres to standard tolerance margins for intervals between data-packets. In some embodiments, the tolerance margin 1202 may be as defined in the standard IEEE-1588-2019, section 9.5.9.2. Here, in the case of PTP, section 9.5.9.2 of IEEE 1588-2019, PTP Sync messages should be transmitted within a tolerance margin of ±30% of the configured period with 90% confidence. This means that, for scenarios in which the TDD window [ ^^_^, ^^_^ା^] is sufficiently long, the tolerance margin may result in a new departure instant for the PTP Sync message somewhere inside a shorter portion of the TDD window [ ^^_^ , ^^_^ା^] than the [ ^^_^, ^^_^ା^] interval shown in Figs.7-8. Also, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, may configure the one or more thresholds ^^_^ , ^^_ௗ, the advancement ^^ of the departure time, and/or the delay ^^ of the departure time such that the departure time of the one or more synchronization data-packets ^^^ᇱ in the synchronization data-packet stream is shifted to the one or more time periods [ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^] wherein the one or more time periods [ ^^_^ , ^^_^ା^], [ ^^_^ି^, ^^_^] comprise one or more guard periods ^^_^ towards the start and/or end of the one or more time periods [ ^^_^ , ^^_^ା^], [ ^^_^ି^, ^^_^]. In the DL direction, this means, for example, that the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may also determine to alter the thresholds ^^_^ , ^^_ௗ by at least a marginal value, so that the delays or advances would position the synchronization data-packets ^^^ᇱ of the synchronization data-packet stream further into the low-delay regions [ ^^_^, ^^_^ା^]. This may be performed in order to not position the synchronization data-packets ^^^ᇱ of the synchronization data-packet stream too close to the start ^^_^ or end ^^_^ of a high-delay region in the DL. For example, by taking into account one or more guard periods, ^^_^, as shown in Fig.9. This would improve the probability that the synchronization data-packets ^^^ᇱ of the synchronization data-packet stream are sent before data-packets of the TDD radio transmission data-packet stream start leaving the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. As mentioned above, the synchronization data-packet stream may be adjusted and synchronization data-packets shifted by a baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ for synchronization data-packet streams in the DL directions. However, optionally, the synchronization data-packet streams may be adjusted and synchronization data-packets shifted by a radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ for synchronization data-packet streams in the UL directions. This requires a similar analysis as described above to be performed by the radio network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, however, synchronization data-packet streams in the UL direction has a requirement that the arithmetic mean should be no less than 90% of the configured period, although with possibly a wider probability distribution. This noted in the standard IEEE-1588-2019, section 9.5.11.2, and may result in slight changes the calculation of the thresholds ^^_^, ^^_ௗ. Here, according to some embodiments, a synchronization data-packet stream in the UL direction may be configured to be sent as soon as possible after the receipt of a synchronization data-packet streams in the DL direction. In this case, the baseband network unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ determine to position the synchronization data-packets ^^^ᇱ as close as possible to the end of the UL portion so that the next synchronization data-packet stream in the UL direction has a higher chance of departing during the next DL portion. Finally, it should also be noted that after the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ has adjusted synchronization data-packet stream and shifted the departure time of one or more synchronization data-packets ^^^ᇱ in the synchronization data-packet stream, i.e. determined all of the transmission opportunities ^^ that is to be used for transmitting a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may start to implement, i.e. restart, the synchronization data-packet stream in order for the new adjusted and shifted schedule to come into effect. Following this “restart”, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may, for example, keep a look-up table mapping each of the transmission opportunities ^^ that is to be used for transmitting a synchronization data-packet ^^^ᇱ in the synchronization data-packet stream (i.e., the position of a synchronization data-packet ^^^ᇱ relative to the TDD window) to how much the departure time of the synchronization data-packet ^^^ᇱ should be delayed or advanced. Because this tweak to the original synchronization data-packet stream is necessarily smaller than the configured period (due to the tolerance margins mentioned previously), the scheduling horizon need not be much longer than one or two future synchronization data-packet streams. Action 504 Optionally, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may detect any subsequent time misalignment between the synchronization data-packet stream and the TDD radio transmission data-packet stream continuously after the initial adjustment. This means, for example, that the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may continuously monitor any subsequent timing misalignment occurring between the synchronization data-packet stream and the TDD radio transmission data-packet stream after the initial adjustment and shift in the departure time of one or more synchronization data-packets ^^^ᇱ in the synchronization data-packet stream. Action 505 After a possible detection in Action 504, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may adjust the synchronization data-packet stream based on the detected subsequent time misalignment. This means, for example, that the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may repeat the process to correct for the detected subsequent timing misalignment occurring between the synchronization data-packet stream. In some embodiments, if the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ has a sufficient performance precision, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may implement the new schedule by looking up the new tweak value and altering the synchronization data-packet stream directly as soon as each synchronization data-packet stream leaves. Fig.10 shows a diagram depicting departure times of synchronization data- packets ^^^ᇱ in a synchronization data-packet stream according to some embodiments versus departure times of synchronization data-packets in the original synchronization data-packet stream. In Fig.10, the absolute value of departure times of synchronization data-packets in the synchronization data-packet streams is shown on the horizontal axis of the diagram, while their position inside the TDD window (10 ms) is shown on the vertical axis of the diagram. The repeating TDD pattern, DL-Gap-UL, is also illustrated at the bottom of the diagram, i.e. the dashed areas (DL) and black areas (UL) separated by grey areas (Gaps). Here, the departure times of synchronization data-packets in the original synchronization data-packet stream are denoted by the graph comprising circles, while the departure times of the synchronization data-packets ^^^ᇱ in the synchronization data- packet stream according to the embodiments herein are denoted by the graph comprising crosses (that are either delayed or advanced in order to avoid being sent during the DL portion of the TDD window). These graphs shows that the applied delays ^^ or advances ^^ to the departure times of the synchronization data-packets ^^^ᇱ in the synchronization data- packet stream according to the embodiments herein always positions the synchronization data-packets ^^^ᇱ in the synchronization data-packet stream within the “gap” or “UL” portions of the TDD window, i.e. in the low-delay regions of the TDD window, while most of the departure times of synchronization data-packets in the original synchronization data-packet stream is positioned within the DL portion of the TDD window, i.e. the high- delay region of the TDD window. Fig.11 is a histogram depicting positions within the TDD window for synchronization data-packets according to the embodiments herein versus positions within the TDD window for synchronization data-packets in the original synchronization data-packet stream. The histogram in Fig.11 shows that modified departure times of the synchronization data-packets according to the embodiments herein are concentrated on the Gap or UL portions of the TDD window where there is less competition (as shown by the dashed bars). This as opposed to the uniform distribution of the synchronization data- packets in the original synchronization data-packet stream (as shown by the black bars). Fig.12 is a histogram depicting the interval spread of data packets in a synchronization data-packet stream according to the embodiments herein, e.g. PTP intervals as denoted by the dashed bars. In Fig.12, this is shown versus the interval period 1201 of data packets in the original synchronization data-packet stream. The histogram in Fig.12 shows that the intervals of data packets in a synchronization data- packet stream according to the embodiments herein is spread around the interval period 1201 of data packets in the original synchronization data-packet stream, here, equivalent to 64 synchronization data-packets per second. However, the interval spread of data packets in the synchronization data-packet stream of the embodiments herein remain entirely within the tolerance margin 1202 (i.e. between the fully drawn lines on each end of the histogram). To perform the method actions in a network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ for synchronizing one or more baseband network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ with one or more radio network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ across a packet- based fronthaul network 100 carrying Time-Division Duplex, TDD, radio transmissions, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may comprise the following arrangement depicted in Fig.13. Fig.13 shows a schematic block diagram of embodiments of a network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. The embodiments of the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ described herein may be considered as independent embodiments or may be considered in any combination with each other to describe non-limiting examples of the example embodiments described herein. The network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may comprise processing circuitry 1310 and a memory 1320. The processing circuitry 1310 may also comprise a receiving module 1311 and a transmitting module 1312. The receiving module 1311 and the transmitting module 1312 may also be configured to communicate and perform transmissions over the packet-based fronthaul network 100, for example, transmit and receive payload data for TDD radio transmissions and synchronization data-packets, such as, e.g. PTP messages. Optionally, in case the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ is a remote radio unit ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^, the receiving module 1311 and the transmitting module 1312 may comprise Radio Frequency, RF, processing circuitry capable of transmitting a radio signal via a radio interface 1330. The receiving module 1311 and the transmitting module 1312 may also form part of a single transceiver. It should also be noted that some or all of the functionality described in the embodiments above as being performed by the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may be provided by the processing circuitry 1310 executing instructions stored on a computer- readable medium, such as, e.g. the memory 1320 shown in Fig.13. Alternative embodiments of the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may comprise additional components, such as, for example, an obtaining module 1313, an adjusting module 1314, and a shifting module 1315, each responsible for providing its respective functionality necessary to support the embodiments described herein. The network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 is configured to, or may comprise the obtaining module 1313 configured to, obtain a time misalignment ^^ ^^^∗ between a synchronization data-packet stream and a TDD radio transmission data-packet stream traversing the packet-based fronthaul network 100. Also, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 is configured to, or may comprise the adjusting module 1314 configured to, adjust the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data-packet stream using the determined time misalignment ^^ ^^^∗. Further, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 is configured to, or may comprise the shifting module 1315 configured to, shift the departure time of one or more synchronization data-packets S’ in the synchronization data-packet stream to one or more time periods [ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^] in which no data-packet in the TDD radio transmission data-packet stream is scheduled for transmission. According to some embodiments, the synchronization data-packet stream and the TDD radio transmission data-packet stream are both traversing the packet-based fronthaul network 100 in either an uplink, UL, direction or a downlink, DL, direction. In some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the obtaining module 1313 configured to, determine the time misalignment based on the departure time of one or more data-packets ^^^ᇱ in the synchronization data-packet stream and the timing of the data-packet transmission periods [ ^^_^, ^^_^], [ ^^_^ା^, ^^_^ା^], [ ^^_^, ^^_^], [ ^^_^ା^, ^^_^ା^] in the TDD radio transmission data-packet stream. In this case, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the obtaining module 1313 configured to, determine the time misalignment ^^ ^^^∗ as the minimum value between a departure time of a data-packet in the synchronization data-packet stream and a start ^^_^, ^^_^ା^, ^^_^, ^^_^ା^ of a data-packet transmission period in the TDD radio transmission data-packet stream. Alternatively, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the obtaining module 1313 configured to, receive the time misalignment ^^ ^^^∗ from another network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ in the packet-based fronthaul network 100. According to some embodiments, the shift in departure time of one or more synchronization data-packets in the synchronization data-packet stream is either an advancement ^^ a or a delay ^^ of the departure time based on one or more thresholds ^^_^ , ^^_ௗ. In this case, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the shifting module 1315 configured to, determine the one or more thresholds ^^_^ , ^^_ௗ based on the duration of the data-packet transmission period in the TDD radio transmission data-packet stream and the transmission rate of the synchronization data-packets in the synchronization data-packet stream. Also, according to some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the shifting module 1315 configured to, determine the one or more thresholds ^^_^ , ^^_ௗ based on a tolerance margin for the time intervals between the synchronization data-packets in the synchronization data-packet stream. Here, in some embodiments, the tolerance margin is as defined in the standard IEEE-1588-2019, section 9.5.9.2. In some embodiments, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the shifting module 1315 configured to, configure the one or more thresholds ^^_^ , ^^_ௗ, the advancement ^^ of the departure time, and/or the delay ^^ of the departure time such that the departure time of the one or more synchronization data-packets ^^^ᇱ in the synchronization data-packet stream is shifted to the one or more time periods [ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^] wherein the one or more time periods [ ^^_^ , ^^_^ା^], [ ^^_^ି^, ^^_^] comprise one or more guard periods ^^_^ towards the start and/or end of the one time periods ^[ ^^_^, ^^_^ା^ ^], ^[ ^^_^ି^, ^^_^ ^]. Furthermore, according to some entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or may be configured to, or may comprise the obtaining module 1313 configured to, detect any subsequent time misalignment between the synchronization data-packet stream and the TDD radio transmission data-packet stream continuously after the initial adjustment. In this case, the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or processing circuitry 1310 may be configured to, or may comprise the adjusting module 1314 configured to, adjust the synchronization data-packet stream based on the detected subsequent time misalignment. Furthermore, the embodiments for synchronizing one or more baseband network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ with one or more radio network units ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ across a packet-based fronthaul network 100 carrying Time-Division Duplex, TDD, radio transmissions described above may be implemented through one or more processors, such as the processing circuitry 1310 in the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ depicted in Fig.13, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code or code means for performing the embodiments herein when being loaded into the processing circuitry 1310 in the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. The computer program code may e.g. be provided as pure program code in the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ or on a server and downloaded to the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^. Thus, it should be noted that the modules of the network entity ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ may in some embodiments be implemented as computer programs stored in memory, e.g. in the memory modules 1320 in Fig.13, for execution by processors or processing modules, e.g. the processing circuitry 1310 of Fig.13. Those skilled in the art will also appreciate that the processing circuitry 1310 and the memory 1320 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory, that when executed by the one or more processors such as the processing circuitry 1320 perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC). The description of the example embodiments provided herein have been presented for purposes of illustration. The description is not intended to be exhaustive or to limit example embodiments to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various alternatives to the provided embodiments. The examples discussed herein were chosen and described in order to explain the principles and the nature of various example embodiments and its practical application to enable one skilled in the art to utilize the example embodiments in various manners and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products. It should be appreciated that the example embodiments presented herein may be practiced in any combination with each other. It should be noted that the word “comprising” does not necessarily exclude the presence of other elements or steps than those listed and the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements. It should further be noted that any reference signs do not limit the scope of the claims, that the example embodiments may be implemented at least in part by means of both hardware and software, and that several “means”, “units” or “devices” may be represented by the same item of hardware. It should also be noted that the various example embodiments described herein are described in the general context of method steps or processes, which may be implemented in one aspect by a computer program product, embodied in a computer- readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), etc. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes. The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be construed as limiting.

Abbreviations CPRI Common Public Radio Interface DCI Downlink Control Information DL Downlink GM Grand Master GNSS Global Navigation Satellite System GPS Global Positioning System OFDM Orthogonal Frequency Division Multiplexing OTDOA Observed Time Difference of Arrival PTP Precision Time Protocol PDV Packet Delay Variation RDS Radio Dot System RRC Radio Resource Control SFI Slot-format Indicator TAE Timing Alignment Error TDD Time-Division Duplexing UL Uplink

Claims

CLAIMS 1. A method performed by a network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) for synchronizing one or more baseband network units ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) with one or more radio network units ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) across a packet-based fronthaul network (100) carrying Time-Division Duplex, TDD, radio transmissions, the method comprising obtaining (501) a time misalignment ( ^^ ^^^∗) between a synchronization data- packet stream and a TDD radio transmission data-packet stream traversing the packet-based fronthaul network (100); and adjusting (502) the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data-packet stream using the determined time misalignment ( ^^ ^^^∗), and shifting (503) the departure time of one or more synchronization data- packets ( ^^^ᇱ) in the synchronization data-packet stream to one or more time periods ([ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^]) in which no data-packet in the TDD radio transmission stream is scheduled for transmission.

2. The method according to claim 1, wherein the synchronization data-packet stream and the TDD radio transmission data-packet stream are both traversing the packet- based fronthaul network (100) in either an uplink, UL, direction or a downlink, DL, direction.

3. The method according to claim 1 or 2, wherein the obtaining (501) further comprises determining the time misalignment ( ^^ ^^^∗) based on the departure time of a synchronization data-packet ( ^^^ᇱ) in the synchronization data-packet stream and the timing of the data-packet transmission periods ([ ^^_^ , ^^_^], [ ^^_^ା^, ^^_^ା^], [ ^^_^ , ^^_^], [ ^^_^ା^, ^^_^ା^]) in the TDD radio transmission data-packet

4. The method according to claim 3, wherein the obtaining (501) further comprises determining the time misalignment ( ^^ ^^^∗) as the minimum value between a departure time of a synchronization data-packet ( ^^^ᇱ) in the synchronization data- packet stream and a start ( ^^_^, ^^_^ା^, ^^_^, ^^_^ା^) of a data-packet transmission period in the TDD radio transmission data-packet stream.

5. The method according to claim 1 or 2, wherein the obtaining (501) further comprises receiving the time misalignment ( ^^ ^^^∗) from another network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) in the packet-based fronthaul network (100).

6. The method according to any of claims 1-5, wherein the shift in departure time of one or more synchronization data-packets ( ^^^ᇱ) in the synchronization data-packet stream is either an advancement ( ^^) or a delay ( ^^) of the departure time based on one or more thresholds ( ^^_^ , ^^_ௗ).

7. The method according to claim 6, further comprising determining the one or more thresholds ( ^^_^ , ^^_ௗ) based on the duration of the data-packet transmission period in the TDD radio transmission data-packet stream and the transmission rate of the synchronization data-packets ( ^^^ᇱ) in the synchronization data-packet stream.

8. The method according to claim 7, further comprising determining the one or more thresholds ( ^^_^ , ^^_ௗ) further based on a tolerance margin (1202) for the time intervals between the synchronization data-packets ( ^^^ᇱ) in the synchronization data-packet stream. 9. The method according to claim 8, wherein the tolerance margin (1202) is as defined in the standard IEEE-1588-2019, section 9.5.

9.2.

10. The method according to any of claims 6-9, further comprising configuring the one or more thresholds ( ^^_^ , ^^_ௗ), the advancement ( ^^) of the departure time, and/or the delay ( ^^) of the departure time such that the departure time of the one or more synchronization data-packets ( ^^^ᇱ) in the synchronization data-packet stream is shifted to the one or more time periods ([ ^^_^ , ^^_^ା^], [ ^^_^ି^, ^^_^]), wherein the one or more time periods ([ ^^_^ , ^^_^ା^], [ ^^_^ି^, more guard periods ( ^^_^) towards the start and/or end of the one or more time periods ([ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^]).

11. The method according to any of claims 1-10, further comprising obtaining (504) any subsequent time misalignment between the synchronization data-packet stream and the TDD radio transmission data-packet stream continuously after the initial adjustment; and adjusting (505) the synchronization data-packet stream based on the detected subsequent time misalignment.

12. The method according to any of claims 1-11, wherein the packet-based fronthaul network (100) is full-duplex, and the data-packets ( ^^^ᇱ) in the synchronization data- packet stream are timestamped data packets according to a packet-based synchronization protocol.

13. A network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) for synchronizing one or more baseband network units ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) with one or more radio network units ( ^^ ^^_ଶ, … , ^^ ^^_^) across a packet-based fronthaul network (100) carrying Time- Division Duplex, TDD, radio transmissions, the network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) being configured to obtain a time misalignment ( ^^ ^^^∗) between a synchronization data-packet stream and a TDD radio transmission data-packet stream traversing the packet- based fronthaul network (100), adjust the synchronization data-packet stream such that the synchronization data-packet stream is aligned with the TDD radio transmission data-packet stream using the determined time misalignment ( ^^ ^^^∗), and shift the departure time of one or more synchronization data-packets ( ^^^ᇱ) in the synchronization data-packet stream to one or more time periods (^[ ^^_^, ^^_^ା^ ^], ^[ ^^_^ି^, ^^_^ ^]) in which no data-packet in the TDD radio transmission data- is scheduled for transmission.

14. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to claim 13, wherein the synchronization data-packet stream and the TDD radio transmission data-packet stream are both traversing the packet-based fronthaul network (100) in either an uplink, UL, direction or a downlink, DL, direction.

15. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to claim 13 or 14, further configured to determine the time misalignment based on the departure time of one or more data-packets ( ^^^ᇱ) in the synchronization data-packet stream and the timing of the data-packet transmission periods ([ ^^_^ , ^^_^], [ ^^_^ା^, ^^_^ା^], [ ^^_^ , ^^_^], [ ^^_^ା^, ^^_^ା^]) in the TDD radio transmission data-packet stream.

16. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to any of claim 15, further configured to determine the time misalignment ( ^^ ^^^∗) as the minimum value between a departure time of a data-packet in the synchronization data-packet stream and a start ( ^^_^, ^^_^ା^, ^^_^, ^^_^ା^) of a data-packet transmission period in the TDD radio transmission data-packet stream.

17. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to any of claims 13-14, further configured to receive the time misalignment ( ^^ ^^^∗) from another network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) in the packet-based fronthaul network (100).

18. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to any of claims 13-17, wherein the shift in departure time of one or more synchronization data- packets in the synchronization data-packet stream is either an advancement ( ^^) or a delay ( ^^) of the departure time based on one or more thresholds ( ^^_^ , ^^_ௗ).

19. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to claim 18, further configured to determine the one or more thresholds ( ^^_^ , ^^_ௗ) based on the duration of the data-packet transmission period in the TDD radio transmission data- packet stream and the transmission rate of the synchronization data-packets in the synchronization data-packet stream.

20. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to claim 19, further configured to determine the one or more thresholds ( ^^_^ , ^^_ௗ) based on a tolerance margin (1202) for the time intervals between the synchronization data- packets in the synchronization data-packet stream.

21. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to claim 20, wherein the tolerance margin (1202) is as defined in the standard IEEE-1588-2019, section 9.5.9.2.

22. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to any of claims 18-21, further configured to configure the one or more thresholds ( ^^_^ , ^^_ௗ), the advancement ( ^^) of the departure time, and/or the delay ( ^^) of the departure time such that the departure time of the one or more synchronization data-packets in the synchronization data-packet stream is shifted to the one or more time periods ([ ^^_^, ^^_^ା^], [ ^^_^ି^, ^^_^]), wherein the one or more time periods ([ ^^_^ , ^^_^ା^], [ ^^_^ି^, ^^_^]) comprise one or more guard periods ( ^^_^) towards the or more time periods (^[ ^^_^ , ^^_^ା^ ^], ^[ ^^_^ି^, ^^_^ ^]).

23. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to any of claims 13-22, further configured to detect any subsequent time misalignment between the synchronization data-packet stream and the TDD radio transmission data-packet stream continuously after the initial adjustment, and adjust the synchronization data-packet stream based on the detected subsequent time misalignment.

24. The network entity ( ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^ , ^^ ^^_^, ^^ ^^_ଶ, … , ^^ ^^_^) according to any of claims 13-23, comprising a processor (1310) and a memory (1320), wherein the memory (1320) is containing instructions executable by the processor (1310).

25. A computer program, comprising instructions which, when executed on at least one processor (1310), cause the at least one processor (1310) to carry out the method according to any of claims 1-12.

26. A carrier containing the computer program according to claim 25, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer- readable storage medium.