Timing analysis of packets in fronthaul

Abstract

A method and system are provided for determining at least one Open Radio Access Network (O-RAN) element causing timing drift in an O-RAN network. Specifically, the method may include: receiving at least one fronthaul (FH) packet by a Radio Unit (RU), said at least one FH packet including the Time of Day (TOD) from a Distributed Unit (DU); detecting timing drift in the FH by the RU based on the received at least one FH packet; and identifying at least one O-RAN element causing timing drift in the FH by the RU based on the detected timing drift.

Description

Technical Field

[0001] Systems and methods consistent with exemplary embodiments of this disclosure relate to the analysis of timing of packets in a fronthaul network. Background Technology

[0002] The Radio Access Network (RAN) is a crucial component of telecommunications systems because it connects end-user equipment (or user gear) to other parts of the network. The RAN comprises a combination of various network elements (NEs) that connect end-user equipment to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0003] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. To this end, O-RAN breaks down RAN functions into Centralized Units (CUs), Distributed Units (DUs), and Radio Units (RUs). A CU is a logical node that hosts the Radio Resource Control (RRC), Serving Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. A DU is a logical node that hosts the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. An RU is a physical node that converts radio signals from antennas into digital signals that can be transmitted to the DU via fronthaul. Because these entities have open protocols and interfaces, they can be developed by different vendors.

[0004] The Evolved Universal Public Radio Interface (eCPRI) is a protocol that can be used in fronthaul (FH) transmission networks, particularly between the DU and RU.

[0005] Figure 1 The diagram illustrates an example structure of an eCPRI message according to existing technology. Specifically, the eCPRI common header and payload can be provided and included as part of the transport network layer payload (e.g., transport networks such as UDP / IP or Ethernet). The total size of the eCPRI message can correspond to an eCPRI Protocol Data Unit (PDU). Summary of the Invention

[0006] The existing eCPRI protocol in the fronthaul cannot carry the Time of Day (TOD) in UTC. Therefore, when the RU acts as a Telecommunication Time Sub-Clock (T-TSC) (where it has a radio application requiring timing), the RU lacks UTC timing reference information for the IQ packets it is receiving, which have subframe number (SFN) information. Consequently, any timing drift occurring in fronthaul L1 packets that causes the counter to increment too early / too late (which can affect cell performance and key performance indicators (KPIs)) cannot be easily debugged / isolated for its root cause, i.e., whether the timing drift is caused by the DU (e.g., synchronization plane (S-plane) drift) or by the RU itself (e.g., the S-plane itself causing fronthaul packets to fail to be received on time due to timing drift).

[0007] Therefore, an improved method is needed to include TOD in fronthaul packets and analyze timing information in packets used in the fronthaul network.

[0008] Example embodiments of this disclosure provide a method and system for including and analyzing the Time of Day (TOD) in fronthaul packets. Specifically, embodiments may include: receiving at least one fronthaul (FH) packet by a radio unit (RU) in an open radio access network (O-RAN) network, the at least one FH packet including the Time of Day (TOD) from a distributed unit (DU) in the O-RAN network; detecting timing drift in the fronthaul (FH) by the RU based on the received at least one FH packet; and identifying at least one O-RAN network element in the O-RAN network that causes the timing drift in the FH based on the detected timing drift.

[0009] Therefore, this implementation allows for the analysis and debugging of timing drift issues in fronthaul packets, since RUs typically do not otherwise have a TOD reference for received IQ packets from DUs. This can be particularly useful because in O-RAN, different units (e.g., DUs and RUs) can come from different vendors, and adding TOD to fronthaul packets can improve interoperability between different devices.

[0010] According to an embodiment, a system that can be implemented in a radio access network (RAN) may be provided, the system including: a radio unit (RU); a distributed unit (DU); and at least one transport network element; wherein the RU is configured to: receive at least one fronthaul (FH) packet, the at least one FH packet including time of day (TOD) information from the DU, detect timing drift in the fronthaul (FH) based on the received at least one FH packet, and identify at least one of the RU, DU, or at least one transport network element as causing timing drift in the FH based on the detected timing drift.

[0011] According to an embodiment, a non-transitory computer-readable recording medium having instructions thereon for performing a method may be provided, the method comprising: receiving at least one fronthaul (FH) packet by a radio unit (RU) in an open radio access network (O-RAN) network, the at least one FH packet including a time of day (TOD) from a distributed unit (DU) in the O-RAN network; detecting timing drift in the fronthaul (FH) by the RU based on the received at least one FH packet; and identifying at least one O-RAN network element in the O-RAN network that causes the timing drift in the FH by the RU based on the detected timing drift.

[0012] Additional aspects will be set forth in part in the description which follows, and in part will be apparent from the description, or may be realized by practicing the embodiments presented in this disclosure. Attached Figure Description

[0013] The features, aspects, and advantages of certain exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which the same reference numerals denote the same elements, and in the drawings:

[0014] Figure 1 The illustration shows an eCPRI message according to existing technology;

[0015] Figure 2 The illustration shows an eCPRI message including the time of day (TOD) according to an embodiment;

[0016] Figure 3 The figure illustrates a flowchart of a method for detecting O-RAN network elements that cause timing drift, according to an embodiment.

[0017] Figure 4 The illustration shows a flowchart of a method for analyzing timing drift based on subframe number (SFN) according to an embodiment;

[0018] Figure 5 The illustration shows a flowchart of a method for detecting O-RAN network elements that cause timing drift according to an embodiment, the method including forming a fronthaul (FH) packet;

[0019] Figure 6 The diagram illustrates an example environment in which the systems and / or methods described herein can be implemented; and

[0020] Figure 7 The diagram illustrates example components of a device according to an embodiment. Detailed Implementation

[0021] The following detailed description of the exemplary embodiments is with reference to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0022] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the precise forms disclosed. Modifications and variations are possible based on the foregoing disclosure, or may be obtained from the practice of implementation. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, as will be understood from the following flowcharts and descriptions, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be switched.

[0023] It is evident that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit these implementations. Therefore, since the operation and behavior of systems and / or methods are described herein without reference to specific software code, it should be understood that software and hardware can be designed to implement these systems and / or methods based on the descriptions herein.

[0024] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the possible disclosure. In fact, many of these features can be combined in ways not specifically referenced in the claims and / or not disclosed in the specification. Although each dependent claim listed below may depend directly on only one claim, the possible disclosure includes combinations of each dependent claim with every other claim in the claim set.

[0025] Unless explicitly stated otherwise, no element, action, or instruction used herein should be construed as critical or necessary. Furthermore, as used herein, the terms “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” Figure 1 For individual items, the term "a" or similar language is used. Furthermore, as used herein, the terms "having," "containing," "including," "comprise," etc., are intended to be open-ended terms. Additionally, unless explicitly stated otherwise, the word "based on" means "at least partially based on." Furthermore, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0026] Example embodiments of this disclosure provide a method and system for including and analyzing the Time of Day (TOD) in fronthaul packets. Specifically, embodiments may include: receiving at least one fronthaul (FH) packet by a radio unit (RU) in an open radio access network (O-RAN) network, the at least one FH packet including the Time of Day (TOD) from a distributed unit (DU) in the O-RAN network; detecting timing drift in the fronthaul (FH) by the RU based on the received at least one FH packet; and identifying at least one O-RAN network element in the O-RAN network that causes the timing drift in the FH based on the detected timing drift.

[0027] Therefore, this implementation allows for the analysis and debugging of timing drift issues in fronthaul packets, since RUs typically do not have a TOD reference for IQ packets received from DUs otherwise. This can be particularly useful because in O-RAN, different units (e.g., DUs and RUs) can come from different vendors, and adding TOD to fronthaul packets can improve interoperability between different devices.

[0028] Figure 2 The illustration shows an eCPRI message including the time of day (TOD) according to an embodiment.

[0029] In particular, such as Figure 2 As shown, TOD can be added in UTC format ( Figure 2 (This is shown as "UTC TOD"). Therefore, the new eCPRI payload size will be the combined size of UTC TOD and the existing eCPRI payload, and the new eCPRI message / protocol data unit (PDU) size will be the existing eCPRI common header plus UTC TOD and the existing eCPRI payload.

[0030] The size of the TOD can vary depending on the specific implementation. For example, it can be allocated 80 bits, or any other desired number of bits (more or less) depending on the specific implementation. According to some embodiments, the TOD can be expressed in seconds or nanoseconds.

[0031] The Time of Shift (TOD) can serve as the UTC reference time for the forward (FH) packets containing IQ data received by the RU (which can be transmitted from the DU). Since the RU receives IQ data from the DU along with the TOD, the RU can observe timing drift (e.g., packets being received too late or too early), and the problem can be analyzed by examining the subframe number (SFN) of the FH packet and comparing it with the TOD from the same FH packet. Therefore, the amount of timing drift can be determined.

[0032] For example, if the amount of timing drift matches TOD, it can be concluded that the timing drift is caused by DU sending FH packets. Alternatively, if TOD matches SFN, it can be concluded that the problem is caused by different modules within the RU receiving FH packets containing IQ, rather than a problem with DU packets.

[0033] Figure 3 The illustration shows a flowchart of a method 300 for detecting O-RAN network elements that cause timing drift, according to an embodiment.

[0034] At operation 301, the RU receives at least one FH packet, the at least one FH packet comprising at least one FH packet, and the at least one FH packet comprising a TOD from the DU. According to an embodiment, the DU may first use an eCPRI protocol that includes a TOD (e.g., using a protocol with...). Figure 2 The FH packet is formed using a structure that is the same as or similar to the one shown. After formation, the DU can send the FH packet to the RU.

[0035] At operation 302, the RU can detect timing drift in the FH based on at least one received FH packet. According to an embodiment, the RU can determine whether the SFN of the FH packet received from the DU matches the SFN derived by the RU. Based on the determination that the SFN of the FH packet received from the DU is different from the SFN derived by the RU, timing drift can be detected.

[0036] At operation 303, the RU can identify the O-RAN network element that caused the timing drift based on the determined timing drift.

[0037] According to an embodiment, the RU can determine multiple synchronization plane (S-plane) parameters. Specifically, S-plane parameters may include: timestamps carried in Precision Time Protocol (PTP) event packets, and clock states carried in PTP general packets. O-RAN network elements that cause timing drift may include, but are not limited to, the RU, DU, and one of the transport network elements.

[0038] The RU can first compare the TOD in at least one FH packet received from the DU with the TOD available to the RU. Although the comparison of TODs can be used to conclude which O-RAN element is causing the timing drift, according to an embodiment, further checks can be performed using the RU's S-plane parameters or S-plane status to identify the O-RAN element causing the timing drift.

[0039] Specifically, if it is determined that the TOD in the FH packet received from the DU does not match the TOD available for the RU, while it can be concluded that the RU is responsible for the timing drift, it can also be determined whether the RU's S-face state indicates an anomaly. If an anomaly exists, the RU can be identified as responsible for the timing drift. For example, the anomaly can be determined based on the S-face lock status and / or a combination of delay / offset calculated from the S-face, as well as any S-face alarms / events indicating that a problem has occurred.

[0040] Conversely, if the TOD in at least one FH packet received from the DU matches the TOD available for the RU, while it can be concluded that the DU or a transport network element is responsible for the timing drift, it can also be determined whether multiple S-plane parameters indicate any anomalies, and if no anomalies are found, then the DU or a network element in the transport network can be identified as responsible for the timing drift. For example, the responsible network element in the transport network could be a switch or a router.

[0041] According to the embodiments, the above method 300 can be implemented in systems such as radio access networks (RAN), including but not limited to RU, DU, control unit (CU) and other suitable network elements.

[0042] Figure 4 The illustration shows a flowchart of a method 400 for analyzing timing drift based on subframe number (SFN) according to an embodiment.

[0043] At operation 401, the RU can receive at least one FH packet. The FH packet can originate from the DU and include the time of day (TOD). The FH packet can use the eCPRI protocol (e.g., as described above). Figure 2 The protocols shown are the same or similar.

[0044] At operation 402, the RU can determine whether at least one FH packet has timing drift based on the subframe number (SFN). This can include the RU determining whether the subframe number (SFN) of an FH packet received from the DU matches the SFN derived by the RU.

[0045] Based on the results of operation 402, if it is determined that the SFN of the FH packet does not match the derived SFN, the RU can send a notification to indicate the presence of timing drift from the DU. Alternatively, if the SFN of the FH packet does match the derived SFN, the RU can simply indicate the presence of timing drift without necessarily determining which network element caused the timing drift.

[0046] Figure 5The illustration shows a flowchart of a method 500 for detecting O-RAN network elements causing timing drift according to an embodiment, the method including forming a fronthaul (FH) packet. It should be noted that operations 503, 504, and 505 are respectively similar to those described above regarding... Figure 3 Operations 301, 302, and 303 are described, and therefore redundant descriptions can be omitted to improve readability.

[0047] At operation 501, the DU forms an FH packet, which includes the TOD from the DU. According to an embodiment, the FH packet can be used according to... Figure 2 The eCPRI message format shown is used to form the message.

[0048] At operation 502, DU sends the FH packet formed in operation 501 to RU.

[0049] At operation 503, the RU receives at least one FH packet, the at least one FH packet including a TOD from the DU.

[0050] At operation 504, the RU can detect timing drift in the FH based on at least one received FH packet.

[0051] At operation 505, the RU can identify the O-RAN network element causing the timing drift based on the determined timing drift. Based on the above embodiment, it can be understood that adding the TOD to the fronthaul (FH) packet allows for the analysis and troubleshooting of timing drift issues in the FH packet, since the RU typically does not otherwise use the TOD as a reference. This can be particularly useful because in the O-RAN, different units (e.g., DU and RU) can come from different vendors, thus improving interoperability between different devices by adding the TOD to the FH packet.

[0052] Figure 6 This is a diagram of an example environment 600 in which the systems and / or methods described herein can be implemented. (See diagram 600 for example environment 600.) Figure 6 As shown, environment 600 may include user equipment 610, platform 620, and network 630. Devices in environment 600 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, the above references... Figures 2 to 5 Any functions and operations described can be provided by Figure 6 Any combination of the network elements shown can be used to perform this.

[0053] User equipment 610 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 620. For example, user equipment 610 may include computing devices (e.g., desktop computers, laptops, tablets, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, cordless phones, etc.), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some implementations, user equipment 610 may receive information from and / or send information to platform 620.

[0054] Platform 620 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 620 may include a cloud server or a group of cloud servers. In some implementations, platform 620 may be designed to be modular, allowing certain software components to be swapped in or out as needed. Therefore, platform 620 can be easily and / or quickly reconfigured for different purposes.

[0055] In some implementations, as shown in the figure, platform 620 can be hosted in a cloud computing environment 622. It is worth noting that although the implementations described herein depict platform 620 as being hosted in a cloud computing environment 622, in some implementations, platform 620 may not be cloud-based (i.e., it may be implemented outside of a cloud computing environment), or may be partially cloud-based.

[0056] The cloud computing environment 622 is the environment of the hosting platform 620. The cloud computing environment 622 can provide services such as computing, software, data access, and storage, without requiring end users (e.g., user device 610) to know the physical location and configuration of the (multiple) systems and / or (multiple) devices of the hosting platform 620. As shown in the figure, the cloud computing environment 622 may include a computing resource group 624 (collectively referred to as computing resource 624, and individually as computing resource 624).

[0057] Computing resource 624 includes one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resource 624 may host platform 620. Cloud resources may include computing instances executing in computing resource 624, storage devices provided in computing resource 624, data transmission devices provided by computing resource 624, etc. In some implementations, computing resource 624 may communicate with other computing resources 624 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0058] like Figure 6As further shown, computing resources 624 include cloud resource groups, such as one or more applications (APP) 624-1, one or more virtual machines (VM) 624-2, virtualized storage devices (VS) 624-3, one or more hypervisors (HYP) 624-4, etc. While the current example embodiment refers to virtualized network functionality, it should be understood that one or more other embodiments are not limited thereto and can be implemented in at least one of containers, cloud-native services, one or more container platforms, etc. For example, in one or more other example embodiments, any of the above components (e.g., nodes, E2 nodes, SMO functionality, RIC, systems, devices, etc.) can be software-based components deployed or hosted in, for example, server clusters (such as hybrid cloud servers, data center servers, etc.). Software-based components can be containerized and can be deployed and controlled by one or more machines (referred to as “nodes”) that run or execute containerized network elements and are addressable. In this regard, the server cluster can contain at least one master node and multiple worker nodes, wherein the master node(s) controls and manages the associated set of worker nodes.

[0059] Application 624-1 includes one or more software applications that can be provided to or accessed by user device 610. Application 624-1 can eliminate the need to install and execute software applications on user device 610. For example, application 624-1 may include software associated with platform 620, and / or any other software that can be provided via cloud computing environment 622. In some implementations, an application 624-1 may send / receive information to or from one or more other applications 624-1 via virtual machine 624-2.

[0060] Virtual machine 624-2 includes a software implementation of a machine (e.g., a computer) that executes programs (such as physical machines). Virtual machine 624-2 can be a system virtual machine or a process virtual machine, depending on the extent to which virtual machine 624-2 is used and corresponds to any real machine. A system virtual machine can provide a complete system platform supporting the execution of a full operating system (OS). A process virtual machine can execute a single program and can support a single process. In some implementations, virtual machine 624-2 can execute on behalf of a user (e.g., user device 610) and can manage the infrastructure of the cloud computing environment 622, such as data management, synchronization, or long-duration data transfer.

[0061] Virtualized storage device 624-3 includes one or more storage systems and / or one or more devices that utilize virtualization technology within the storage system or device of computing resource 624. In some implementations, the type of virtualization, within the context of the storage system, may include block virtualization and file virtualization. Block virtualization can refer to the abstraction (or separation) of logical storage from physical storage, enabling access to the storage system regardless of physical storage or heterogeneous architecture. This separation allows storage system administrators flexibility in how they manage storage for end users. File virtualization eliminates the dependency between data accessed at the file level and the location where the file is physically stored. This can enable performance optimization for storage usage, server consolidation, and / or non-disruptive file migration.

[0062] Hypervisor 624-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., guest operating systems) to run simultaneously on a host (such as computing resource 624). Hypervisor 624-4 can present a virtual operating platform to the guest operating system and manage the execution of the guest operating system. Multiple instances of various operating systems can share virtualized hardware resources.

[0063] Network 630 includes one or more wired and / or wireless networks. For example, network 630 may include cellular networks (e.g., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LAN), wide area networks (WAN), metropolitan area networks (MAN), telephone networks (e.g., public switched telephone network (PSTN)), private networks, self-organizing networks, intranets, the Internet, fiber-optic networks, etc., and / or combinations of these or other types of networks.

[0064] Figure 6 The number and arrangement of devices and networks shown are provided as examples. In practice, similar arrangements may exist. Figure 6 The comparison shown is between more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently. Furthermore, Figure 6 The two or more devices shown can be implemented within a single device, or Figure 6 The single device shown can be implemented as multiple distributed devices. Alternatively or additionally, the set of devices in environment 600 (e.g., one or more devices) can perform one or more functions described as being performed by another set of devices in environment 600.

[0065] Figure 7 This is a diagram of example components of device 700. Device 700 may correspond to user device 610 and / or platform 620. Figure 7 As shown, device 700 may include bus 710, processor 720, memory 730, storage component 740, input component 750, output component 760 and communication interface 770.

[0066] Bus 710 includes components that allow communication between components of device 700. Processor 720 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 720 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor 720 includes one or more processors that can be programmed to perform functions. Memory 730 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, and / or optical storage) that stores information and / or instructions for use by processor 720.

[0067] Storage component 740 stores information and / or software related to the operation and use of device 700. For example, storage component 740 may include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), optical disk (CD), digital versatile disk (DVD), floppy disk, cassette tape, magnetic tape, and / or another type of non-transitory computer-readable medium, and a corresponding drive. Input component 750 includes components that allow device 700 to receive information, such as via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone). Additionally or alternatively, input component 750 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, accelerometer, gyroscope, and / or actuator). Output component 760 includes components that provide output information from device 700 (e.g., a display, speaker, and / or one or more light-emitting diodes (LEDs)).

[0068] The communication interface 770 includes transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter) that enable the device 700 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 770 can allow the device 700 to receive information from and / or provide information to another device. For example, the communication interface 770 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0069] Device 700 can perform one or more processes described herein. Device 700 can perform these processes in response to processor 720 executing software instructions stored in a non-transitory computer-readable medium, such as memory 730 and / or storage component 740. Computer-readable medium is defined herein as a non-transitory memory device. A memory device includes storage space within a single physical storage device or storage space distributed across multiple physical storage devices.

[0070] Software instructions may be read from another computer-readable medium or from another device via communication interface 770 into memory 730 and / or storage component 740. When executed, the software instructions stored in memory 730 and / or storage component 740 may cause processor 720 to perform one or more of the processes described herein.

[0071] Alternatively or concurrently, hardwired circuitry can be used in place of or in combination with software instructions to perform one or more of the procedures described herein. Therefore, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0072] Figure 7 The number and arrangement of components shown are provided as an example. In practice, with Figure 7 Compared to the examples shown, device 700 may include more components, fewer components, different components, or components arranged differently. Additionally or alternatively, a set of components of device 700 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 700.

[0073] In an embodiment, Figures 2 to 5 Any operation or process can be accessed or used Figure 6 and Figure 7 Any of the network elements shown can be implemented. It should be understood that other embodiments are not limited to this and can be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architecture, such as Kubernetes, Docker, OpenStack, etc.).

[0074] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the precise forms disclosed. Modifications and variations are possible in light of the foregoing disclosure, or may be derived from the practice of implementation.

[0075] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of integration technical detail. Furthermore, one or more of the above components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include (multiple) computer-readable non-transitory storage media having computer-readable program instructions thereon for causing the processor to perform operations.

[0076] Computer-readable storage media can be tangible devices that can retain and store instructions for use by instruction execution devices. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital universal disc (DVD), memory sticks, floppy disks, mechanical encoding devices on which instructions are recorded (such as punched cards or raised structures in recesses), and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0077] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0078] Computer-readable program code / instructions used to perform operations can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, configuration data of an integrated circuit system, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). Computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or a connection to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, an electronic circuit system (including, for example, a programmable logic circuit system, a field-programmable gate array (FPGA), or a programmable logic array (PLA)) can execute computer-readable program instructions by utilizing the status information of the computer-readable program instructions to personalize the electronic circuit system, thereby performing aspects or operations.

[0079] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create parts for implementing the functions / actions specified in the flowcharts and / or block diagram blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of writing comprising instructions that implement aspects of the functions / actions specified in the flowcharts and / or block diagram blocks.

[0080] These computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus or other device implement the functions / actions specified in the flowchart and / or block diagram blocks.

[0081] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent one or more microservices, instruction modules, segments, or portions, including one or more executable instructions for implementing one or more specified logical functions. The method, computer system, and computer-readable medium may include more blocks, fewer blocks, different blocks, or blocks arranged differently compared to those shown in the figures. In some alternative implementations, the functions described in a block may not appear in the order shown in the figures. For example, in fact, two blocks shown consecutively may be executed simultaneously or substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block illustrated in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs the specified functions or actions or executes a combination of dedicated hardware and computer instructions.

[0082] It is evident that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of these systems and / or methods are described herein without reference to any specific software code. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the descriptions herein.

[0083] Various aspects of the embodiments

[0084] Various other corresponding aspects and features of the embodiments of this disclosure may be defined by the following terms: Clause [1]: A method comprising: At least one fronthaul (FH) packet is received by a radio unit (RU) in an open radio access network (O-RAN) network, wherein the at least one FH packet includes the time of day (TOD) from a distributed unit (DU) in the O-RAN network. The RU detects timing drift in the forward pass (FH) based on at least one received FH packet; and Based on the detection of timing drift, the RU identifies at least one O-RAN network element in the O-RAN network that causes timing drift in FH. Clause [2]: According to the method of Clause [1], receiving at least one forward pass (FH) packet includes: The DU forms the FH group, which includes the TOD from the DU; and The DU sends an FH packet to the RU. Clause [3]: The method according to any one of Clauses [1] to [2], wherein detecting timing drift includes: The RU compares the subframe number (SFN) of the FH packets received from the DU with the SFN derived by the RU; and The RU determines that timing drift exists based on the fact that the SFN of the FH packet received from the DU is different from the SFN derived by the RU. Clause [4]: ​​According to any one of Clauses [1] to [3], wherein identifying at least one O-RAN network element that causes timing drift in FH includes: Compare whether the TOD in at least one FH packet received from the DU matches the TOD available for the RU; and The RU determines multiple synchronization plane (S-plane) parameters, wherein at least one O-RAN network element includes the RU, DU, and one of the transport network, and wherein the multiple S-plane parameters include at least one of the following: timestamps carried in Precision Time Protocol (PTP) event packets, and clock states carried in PTP general packets. Clause [5]: According to the method of Clause [4], wherein identifying at least one O-RAN network element that causes timing drift in FH further includes: If the TOD in at least one FH packet received from the DU does not match the TOD available for the RU, determine whether the RU's s-face state indicates any anomaly; and If the s-plane state indication of the RU is determined to be abnormal, then the RU is identified as responsible for the timing drift. Clause [6]: According to the method of Clause [4], the identification of at least one O-RAN network element that causes timing drift in FH further includes: If the TOD in at least one FH packet received from the DU matches the TOD available for the RU, then determine whether multiple s-surface parameters indicate any anomalies; and If it is determined that multiple S-surface parameters do not indicate any anomalies, then the DU or the transport network is identified as responsible for the timing drift, where the transport network includes at least one of the switches and routers. Clause [7]: The method of any one of Clauses [1] to [6], wherein at least one FH packet adopts the format for the Evolved Common Public Radio Interface (eCPRI) protocol. Clause [8]: A system implemented in a radio access network (RAN) comprising: Wireless Unit (RU); Distributed Unit (DU); and At least one transmission network element; The RU is configured to: receive at least one fronthaul (FH) packet, the at least one FH packet including time of day (TOD) information from the DU, detect timing drift in the fronthaul (FH) based on the received at least one FH packet, and identify at least one of the RU, DU, or at least one transport network element as causing timing drift in the FH based on the detected timing drift. Clause [9]: According to Clause [8], the system in which the DU is configured to: form an FH packet, the FH packet including the TOD from the DU, and send the FH packet to the RU. Clause

[10] : A system pursuant to any one of Clauses [8] to [9], wherein the RU is further configured to detect timing drift by: The subframe number (SFN) of the FH packets received from the DU is compared with the SFN derived from the RU; and Based on the fact that the SFN of the FH packet received from the DU is different from the SFN derived from the RU, it is determined that timing drift exists. Clause

[11] : A system pursuant to any one of Clauses [8] to

[10] , wherein the RU is further configured to identify at least one of the RU, DU, or at least one transport network element as causing timing drift in the FH by: Compare whether the TOD in at least one FH packet received from the DU matches the TOD available for the RU; and Determine multiple synchronization plane (S-plane) parameters, wherein the multiple S-plane parameters include at least one of the following: timestamps carried in Precision Time Protocol (PTP) event packets and clock states carried in PTP generic packets. Clause

[12] : In a system according to Clause

[11] , wherein the RU is further configured to identify at least one of the RU, DU, or at least one transport network element as causing timing drift in the FH by: If the TOD in at least one FH packet received from the DU does not match the TOD available for the RU, determine whether the RU's s-face state indicates any anomaly; and If the s-plane state indication of the RU is determined to be abnormal, then the RU is identified as responsible for the timing drift. Clause

[13] : In a system pursuant to Clause

[11] , wherein the RU is further configured to identify at least one of the RU, DU, or at least one transport network element as causing timing drift in the FH by: If the TOD in at least one FH packet received from the DU matches the TOD available for the RU, then determine whether multiple s-surface parameters indicate any anomalies; and If it is determined that multiple S-plane parameters do not indicate any anomalies, then the DU or the transport network is identified as responsible for the timing drift, wherein at least one transport network element includes at least one of a switch and a router. Clause

[14] : In any of Clauses [8] to

[13] , at least one FH packet is in the format used for the Evolved Common Public Radio Interface (eCPRI) protocol. Clause

[15] : A non-transitory computer-readable recording medium having instructions recorded thereon for performing a method comprising: At least one fronthaul (FH) packet is received by a radio unit (RU) in an open radio access network (O-RAN) network, wherein the at least one FH packet includes the time of day (TOD) from a distributed unit (DU) in the O-RAN network. The RU detects timing drift in the forward pass (FH) based on at least one received FH packet; and Based on the detection of timing drift, the RU identifies at least one O-RAN network element in the O-RAN network that causes timing drift in FH. Clause

[16] : A non-transitory computer-readable recording medium according to Clause

[15] , wherein receiving at least one forward (FH) packet comprises: The DU forms the FH group, which includes the TOD from the DU; and The DU sends an FH packet to the RU. Clause

[17] : A non-transitory computer-readable recording medium according to any one of Clauses

[15] to

[16] , wherein detecting timing drift includes: The RU compares the subframe number (SFN) of the FH packets received from the DU with the SFN derived by the RU; and The RU determines that timing drift exists based on the fact that the SFN of the FH packet received from the DU is different from the SFN derived by the RU. Clause

[18] : A non-transitory computer-readable recording medium according to any one of Clauses

[15] to

[17] , wherein identifying at least one O-RAN network element causing timing drift in FH includes: Compare whether the TOD in at least one FH packet received from the DU matches the TOD available for the RU; and The RU determines multiple synchronization plane (S-plane) parameters, wherein at least one O-RAN network element includes the RU, DU, and one of the transport network, and wherein the multiple S-plane parameters include at least one of the following: timestamps carried in Precision Time Protocol (PTP) event packets, and clock states carried in PTP general packets. Clause

[19] : A non-transitory computer-readable recording medium pursuant to Clause

[18] , wherein identifying at least one O-RAN network element causing timing drift in FH further includes: If the TOD in at least one FH packet received from the DU does not match the TOD available for the RU, determine whether the RU's s-face state indicates any anomaly; and If the s-plane state indication of the RU is determined to be abnormal, then the RU is identified as responsible for the timing drift. Clause

[20] : A non-transitory computer-readable recording medium pursuant to Clause

[18] , wherein identifying at least one O-RAN network element causing timing drift in FH further includes: If the TOD in at least one FH packet received from the DU matches the TOD available for the RU, then determine whether multiple s-surface parameters indicate any anomalies; and If it is determined that multiple S-surface parameters do not indicate any anomalies, then the DU or the transport network is identified as responsible for the timing drift, where the transport network includes at least one of the switches and routers.

[0085] It is understood that many modifications and variations of this disclosure are possible in light of the foregoing teachings. It is apparent that this disclosure may be practiced in ways other than those specifically described herein, within the scope of the appended provisions.

Claims

1. A method comprising: At least one fronthaul (FH) packet is received by a radio unit (RU) in an open radio access network (O-RAN) network, the at least one FH packet including the time of day (TOD) from a distributed unit (DU) in the O-RAN network. The RU detects timing drift in the forward pass (FH) based on the received at least one FH packet; as well as The RU identifies at least one O-RAN network element in the O-RAN network that causes the timing drift in the FH based on the detected timing drift.

2. The method of claim 1, wherein receiving the at least one fronthaul (FH) packet comprises: The DU forms an FH packet, the FH packet including the TOD from the DU; as well as The DU sends the FH packet to the RU.

3. The method of claim 1, wherein detecting the timing drift comprises: The RU compares the subframe number (SFN) of the FH packet received from the DU with the SFN derived by the RU; as well as The RU determines that timing drift exists based on the fact that the SFN of the FH packet received from the DU is different from the SFN derived by the RU.

4. The method of claim 1, wherein identifying the at least one O-RAN network element causing the timing drift in the FH comprises: Compare whether the TOD in the at least one FH packet received from the DU matches the TOD available for the RU; as well as The RU determines multiple synchronization plane (S-plane) parameters, wherein the at least one O-RAN network element includes the RU, the DU, and one of the transport network, and wherein the multiple S-plane parameters include at least one of the following: timestamps carried in Precision Time Protocol (PTP) event packets, and clock states carried in PTP general packets.

5. The method of claim 4, wherein identifying the at least one O-RAN network element causing the timing drift in the FH further comprises: If the TOD in the at least one FH packet received from the DU does not match the TOD available for the RU, then determine whether the s-face state of the RU indicates any anomaly. as well as If it is determined that the s-face state indication of the RU is abnormal, then the RU is identified as responsible for causing the timing drift.

6. The method of claim 4, wherein identifying the at least one O-RAN network element causing the timing drift in the FH further comprises: If the TOD in the at least one FH packet received from the DU matches the TOD available for the RU, then it is determined whether the plurality of s-surface parameters indicate any anomaly. as well as If it is determined that the plurality of S-surface parameters do not indicate any anomaly, then the DU or the transmission network is identified as responsible for the timing drift, wherein the transmission network includes at least one of switches and routers.

7. The method of claim 1, wherein the at least one FH packet adopts a format for the Evolved Common Public Radio Interface (eCPRI) protocol.

8. A system implemented in a radio access network (RAN), comprising: Wireless Unit (RU); Distributed Unit (DU); as well as At least one transmission network element; The RU is configured to: receive at least one fronthaul (FH) packet, the at least one FH packet including time of day (TOD) information from the DU, detect timing drift in the fronthaul (FH) based on the received at least one FH packet, and identify at least one of the RU, the DU, or the at least one transport network element as causing the timing drift in the FH based on the detected timing drift.

9. The system of claim 8, wherein the DU is configured to: form an FH packet, the FH packet including the TOD from the DU, and send the FH packet to the RU.

10. The system of claim 8, wherein the RU is further configured to detect the timing drift by: The subframe number (SFN) of the FH packet received from the DU is compared with the SFN derived from the RU; and A timing drift is determined to exist based on the fact that the SFN of the FH packet received from the DU is different from the SFN derived from the RU.

11. The system of claim 8, wherein the RU is further configured to identify at least one of the RU, the DU, or the at least one transport network element as causing the timing drift in the FH by: Compare whether the TOD in the at least one FH packet received from the DU matches the TOD available for the RU; and Determine multiple synchronization plane (S-plane) parameters, wherein the multiple S-plane parameters include at least one of the following: timestamps carried in Precision Time Protocol (PTP) event packets and clock states carried in PTP generic packets.

12. The system of claim 11, wherein the RU is further configured to identify at least one of the RU, the DU, or the at least one transport network element as causing the timing drift in the FH by: If the TOD in the at least one FH packet received from the DU does not match the TOD available for the RU, then determine whether the s-face state of the RU indicates any anomaly; and If it is determined that the s-plane state indication of the RU is abnormal, then the RU is identified as responsible for causing the timing drift.

13. The system of claim 11, wherein the RU is further configured to identify at least one of the RU, the DU, or the at least one transport network element as causing the timing drift in the FH by: If the TOD in the at least one FH packet received from the DU matches the TOD available for the RU, then determine whether the plurality of s-surface parameters indicate any anomaly; and If it is determined that the plurality of S-surface parameters do not indicate any anomaly, then the DU or the transmission network is identified as responsible for the timing drift, wherein the at least one transmission network element includes at least one of a switch and a router.

14. The system of claim 8, wherein the at least one FH packet adopts a format for the Evolved Common Public Radio Interface (eCPRI) protocol.

15. A non-transitory computer-readable recording medium having instructions recorded thereon for performing a method, the method comprising: At least one fronthaul (FH) packet is received by a radio unit (RU) in an open radio access network (O-RAN) network, the at least one FH packet including the time of day (TOD) from a distributed unit (DU) in the O-RAN network. The RU detects timing drift in the forward pass (FH) based on the received at least one FH packet; as well as The RU identifies at least one O-RAN network element in the O-RAN network that causes the timing drift in the FH based on the detected timing drift.

16. The non-transitory computer-readable recording medium of claim 15, wherein receiving the at least one forward (FH) packet comprises: The DU forms an FH packet, the FH packet including the TOD from the DU; as well as The DU sends the FH packet to the RU.

17. The non-transitory computer-readable recording medium of claim 15, wherein detecting the timing drift comprises: The RU compares the subframe number (SFN) of the FH packet received from the DU with the SFN derived by the RU; as well as The RU determines that timing drift exists based on the fact that the SFN of the FH packet received from the DU is different from the SFN derived by the RU.

18. The non-transitory computer-readable recording medium of claim 15, wherein identifying the at least one O-RAN network element causing the timing drift in the FH comprises: Compare whether the TOD in the at least one FH packet received from the DU matches the TOD available for the RU; as well as The RU determines multiple synchronization plane (S-plane) parameters, wherein the at least one O-RAN network element includes the RU, the DU, and one of the transport network, and wherein the multiple S-plane parameters include at least one of the following: timestamps carried in Precision Time Protocol (PTP) event packets, and clock states carried in PTP general packets.

19. The non-transitory computer-readable recording medium of claim 18, wherein the at least one O-RAN network element identifying the timing drift in the FH further comprises: If the TOD in the at least one FH packet received from the DU does not match the TOD available for the RU, then determine whether the s-face state of the RU indicates any anomaly. as well as If it is determined that the s-face state indication of the RU is abnormal, then the RU is identified as responsible for causing the timing drift.

20. The non-transitory computer-readable recording medium of claim 18, wherein the at least one O-RAN network element identifying the timing drift in the FH further comprises: If the TOD in the at least one FH packet received from the DU matches the TOD available for the RU, then it is determined whether the plurality of s-surface parameters indicate any anomaly. as well as If it is determined that the plurality of S-surface parameters do not indicate any anomaly, then the DU or the transmission network is identified as responsible for the timing drift, wherein the transmission network includes at least one of switches and routers.

Images