Distributed unit timing synchronization method, system and medium

Abstract

Systems and methods are described for implementing a distributed unit in a radio access network that synchronizes its clock with a radio unit. A distributed unit may be deployed in a location where it cannot receive timing information from a satellite or may lack the equipment to acquire and process satellite signals. Consequently, the distributed unit's clock may drift relative to the radio unit's clock, which may cause the distributed unit to transmit data to the radio unit at the wrong time for delivery to a user device. The distributed unit can prevent clock drift by obtaining timing information from the radio unit, determining the amount of clock drift occurring, and applying a correction factor to keep the distributed unit clock synchronized with the radio unit clock. The distributed unit can determine the frequency of synchronization based on the severity and variability of the clock drift.

Description

Background Art

[0001] Generally speaking, computing devices can be used to exchange information over a network. Computing devices can utilize wireless networks provided by service providers to facilitate information exchange according to one or more wireless communication protocols. For example, a service provider may maintain a wireless network that enables mobile computing devices to exchange information according to a fourth-generation wireless telecommunications protocol, such as the Long Term Evolution ("LTE") protocol. The wireless network may be composed of separate network components, such as radio units that transmit and receive radio signals within a specific geographic area, distributed units that transmit and receive data from the radio units, and centralized units that connect the distributed units to other communication networks. Thus, the radio units can receive data from the distributed units and transmit data to user devices, and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Reference numerals may be repeated throughout the drawings to indicate correspondence between reference elements.The drawings are provided to illustrate the example embodiments described herein and are not intended to limit the scope of the disclosure.

[0003] Figure 1 is a block diagram depicting an example operating environment in which a distributed unit can synchronize its clock with a radio unit and manage its workload, and thereby transmit data to the radio unit without missing time slots due to clock drift or overload, according to aspects of the present disclosure.

[0004] Figure 2 is a flow diagram depicting example interactions and timing for transmitting data from a distributed unit to a radio unit according to aspects of the present disclosure.

[0005] Figure 3 is a flow diagram depicting an example interaction for initially synchronizing clocks of distributed units and radio units according to aspects of the present disclosure.

[0006] Figure 4 is a flow diagram depicting example interactions for maintaining synchronization between clocks of distributed units and radio units according to aspects of the present disclosure.

[0007] Figure 5 is a flow diagram depicting example interactions for managing workload of a distributed unit to reduce its risk of missing a data transmission window for transmitting data to a radio unit, according to aspects of the present disclosure.

[0008] Figure 6 is a flow diagram depicting example interactions for reducing workload of distributed units according to aspects of the present disclosure.

[0009] Figure 7is a flow chart depicting an example routine for synchronizing a clock of a distributed unit with a clock of a radio unit according to aspects of the present disclosure.

[0010] Figure 8 is a flow chart depicting an example routine for managing workload of distributed units according to aspects of the present disclosure.

[0011] Figure 9 is a block diagram depicting the overall architecture of a computing device configured to implement distributed units that synchronize their clocks and manage their workloads, according to aspects of the present disclosure. DETAILED DESCRIPTION

[0012] Generally speaking, aspects of the present disclosure relate to improved timing synchronization and workload management in wireless communication networks. More specifically, aspects of the present disclosure relate to systems, methods, and computer-readable media related to improving the performance of distributed units in a radio access network ("RAN"), such as an open radio access network, by synchronizing the distributed unit's clock with one or more radios of the radio access network and managing the distributed unit's workload to ensure that the distributed unit does not miss a time slot for transmitting data to the RAN's radios.

[0013] The functionality of the RAN may be split among various elements such as radio units ("RUs"), distributed units ("DUs"), and centralized units ("CUs"). The RUs may generally implement "layer 1" (which may be referred to herein as "L1") or "physical layer" functions related to the transmission and reception of radio signals, such as converting coded digital signals to radio waves and vice versa, transmitting and receiving radio waves during specified timing windows and on specified frequencies, and so on. The RUs may be located in close proximity to amplifiers, filters, towers, antennas, and other hardware used to transmit and receive radio signals, and each RU may provide coverage to a different geographic area, which may partially overlap with the areas of adjacent RUs to facilitate handover and provide seamless communication. The DUs may generally receive data from the CU for delivery to the RU (and vice versa), and may process the data to encode or decode it, modulate or demodulate it, add or remove error correction or redundancy, or otherwise prepare the data received from the CU for transmission over the air by the RU, and vice versa. The functionality implemented by the DU may include some layer 1 functions, such as encoding the digital signal to be transmitted by the RU, adding redundancy and error correction codes to the digital signal, mapping the transmission channel to the physical channel, etc. In some embodiments, the DU may include dedicated hardware for performing layer 1 functions, such as an accelerator card that performs signal processing functions. The DU may also implement some "layer 2" (which may be referred to as "L2" in this article) functions, such as mapping logical channels to transmission channels, determining the timing of the RU's digital signal transmission within a timing window, etc. The CU may in turn implement "layer 3" ("L3") functions, such as mediating access to external networks, authorizing access to the RAN, etc.

[0014] Thus, the distributed unit can receive data from the centralized unit and then transmit the data to the radio unit for delivery to a user device (e.g., a mobile device, which may be referred to as a "user equipment" or "UE"). Conversely, the UE can send data to the RU, which in turn can be processed by the DU and then by the CU. As described in more detail below, these elements may need to communicate with each other or with the user device during designated time windows (which may be referred to herein as "time slots"). Therefore, it may be important, for example, to synchronize the clocks of the distributed unit and the radio unit so that communication occurs at the appropriate time. Timing synchronization in cellular networks can be a critical element of the system, not only for proper system operation, but also for achieving ever-increasing data rates while reducing latency, such as in 5G networks. 5G cellular systems have particularly stringent synchronization requirements on both the RAN and device sides. To meet these requirements, some 5G RAN deployments may use GPS on components such as the RU, DU, and CU. Each component may have its own GPS receiver, or one or more components may share the same GPS signal using a protocol such as the Precision Time Protocol ("PTP"). PTP is designed to provide nanosecond accuracy for timing synchronization.

[0015] However, not all 5G components may require or have access to this high level of precise timing. In some implementations, the DU may run on edge hardware of a cloud provider network provided to a customer premises that requires a 5G network, and multiple of these DUs may be located in convenient locations on the premises (e.g., in a temperature-controlled room). Depending on the desired network coverage requirements, one or more RUs may be located away from the DU, such as on or near a ceiling. For the RU, high precision timing may be critical because the RU is the component that sends electromagnetic waves to the UE over the air interface. For the DU that provides digital processing of received and transmitted data, nanosecond accuracy may not be necessary. However, the DU must generate the data to be transmitted by the RU at each slot boundary. The slot duration depends on the subcarrier spacing, with a typical feature of some implementations being a 1 ms slot duration. Due to the tight integration between the DU and the RU, it may be desirable to have GPS also provide timing information for the DU. However, having a GPS receiver on every DU in a 5G network deployment can be costly, and this can also increase installation costs due to the need to connect a GPS antenna to a location with good GPS signal coverage, as the DU may be located in an indoor facility with relatively poor GPS signal quality (or no signal at all). Further, PTP typically requires dedicated hardware support to achieve nanosecond accuracy. For example, PTP may rely at least in part on hardware-based data transmission timestamps. This requirement hinders the ability to use general-purpose hardware in the DU and further increases its cost. An alternative to PTP is the Network Time Protocol ("NTP"), but the accuracy of NTP is in the 1ms-10ms range, which is unacceptable in some scenarios. For example, this range may be impermissibly wide compared to a typical timeslot duration, particularly for high-speed technologies such as 5G networks.

[0016] Therefore, in some embodiments, these elements of the RAN may rely on different sources of timing information with varying levels of reliability, which can cause the elements to become unsynchronized and lead to communication problems. For example, a radio unit may rely on a satellite network (e.g., the Global Positioning System, or "GPS") for timing information, but a distributed unit may be deployed in a location where GPS signals are unavailable and may therefore rely on its own internal clock or a networked time server, which may drift relative to the radio unit's GPS-synchronized clock. If timing synchronization is not performed on the DU, the clock will likely drift to the point where the DU misses the time slot boundary in which data must be delivered to the RU. This may be the result of the DU's internal clock slowly drifting due to an inaccurate local oscillator crystal (relative to PTP) or the crystal's temperature response. When the DU fails to provide the necessary data to the RU, dead air may occur on the system because the RU did not receive any data for transmission in a certain time slot in time. In such cases, the RU may need to reset its connection to the DU, which may cause all devices connected to the RAN to lose their connection and have to start over by reconnecting to the network. As will be appreciated, this can result in a very poor user experience. The present disclosure addresses this issue by enabling the distribution unit to synchronize its clock with the radio unit, thereby ensuring that the distribution unit sends data to the radio unit at the expected time. The present disclosure provides multiple techniques to achieve the required synchronization while minimizing the use of the limited bandwidth between the RU and DU, including initial time synchronization and ongoing time synchronization.

[0017] For initial time synchronization, when the RU is first connected to the DU and there is no load on the system, the DU may request timing information from the RU at fixed intervals relative to its own clock over a period of time. The intervals may be configurable at both the RU and the DU, or the DU may proactively request timing information from the RU based on its own time. The RU may respond with a packet that includes the requested timing information, and if the RU has hardware stamping capabilities, the packet may be hardware stamped. The DU may then estimate its own clock drift based on the response from the RU. Allocating a longer duration for this time synchronization and transmitting a larger number of packets may improve the accuracy of this estimate. A particular implementation may weigh the improved accuracy of the estimate against the increased amount of time required for synchronization to achieve a desired balance.

[0018] For ongoing time synchronization, a similar process to initial time synchronization may continue during operation of the RAN. In ongoing time synchronization, an additional consideration in determining the frequency and duration of timing synchronization is that the request / response consumes bandwidth that would otherwise be used for data packet transmission between the RU and the DU, and may therefore affect the overall performance of the system in terms of the amount of data it can send and receive from the UE. To alleviate this problem, in implementations that include multiple RUs connected to the same DU (e.g., to achieve redundancy, increased area coverage, or support for an increased number of devices), one of the RUs may be selected to perform timing synchronization with the DU. The RU selected for this purpose may be rotated, for example, using polling or based on an analysis of the load on the RU. Another solution may be to have the RU send data packets that include timing information (and may be hardware-stamped) at regular intervals (such as time slot boundaries), and to have the DU extract the timing information from some or all of the packets it receives. The DU may use the timing information it periodically receives to correct its clock. Another consideration in determining the frequency and duration of ongoing timing synchronization is that the clock drift of the DU may vary during operation due to factors such as workload, temperature, or other conditions that may cause the amount of clock drift to become less predictable. Thus, a DU may request timing synchronization more frequently when the DU's clock drift is less consistent, and may request timing synchronization less frequently when the DU's workload and other factors make its clock drift predictable.

[0019] In some embodiments, the DU may also monitor and manage its workload to ensure that other tasks performed by the DU do not prevent the DU from sending data to the RU in a timely manner so that the RU can transmit the data in the next time slot. In addition to transmitting data to the RU, the DU generally has other tasks to perform. For example, when data from the radio unit is generated and uploaded by the UE, the distributed unit receives and processes such data. As a further example, the DU may receive more data from the CU than it can process in a single time slot. As a result, the DU may fail to transmit data to the RU in a timely manner, resulting in "silence" (time slots in which no data is transmitted), less efficient use of the RU and radio spectrum, and a suboptimal user experience. In some embodiments, as described above, if the DU fails to provide data in a timely manner, the RU may reset its connection to the DU, which may cause the UE to stop receiving data for a longer period of time. In some embodiments, the DU can expand its capacity to meet its workload by increasing the number of parallel processing threads it is executing. However, increasing the number of threads may increase the time it takes to respond to each UE, and increasing the number of threads beyond the physical computing resources available at the DU may not result in an increase in capacity.

[0020] As mentioned above, a radio unit can deliver data to a user device during a specified time slot. The time slot can start at a time based on the radio unit's internal clock. For example, a radio unit can deliver data to a user device in time slots that are each one millisecond in duration, and these time slots can start and end at 12:00:00.000 pm, 12:00:00.001 pm, 12:00:00.002 pm, and so on, according to the radio unit's clock. The radio units can set and synchronize their clocks by obtaining timing information from satellites. For example, the radio units can obtain timing information from GPS satellites, which can provide highly accurate timing information that allows each radio unit to consistently keep time. This, in turn, allows the radio units to accurately determine the start and end of each time slot used to send data to the user device.

[0021] In order to transmit data to a user device in each of the radio unit's time slots, the radio unit must receive the data to be transmitted from the distributed unit before the start of the time slot. Therefore, the distributed unit may be required to also maintain time consistently and accurately in order to determine the start of each of the radio unit's time slots and deliver data to the radio unit before that time. However, the distributed unit may not have the ability to obtain timing information from a satellite. The radio unit is typically located near the antenna of a cellular tower and has the necessary equipment and programming to receive and process radio signals from the satellite. The distributed unit may be located in a location separate from the antenna (e.g., an office, warehouse, or data center) and may not have the necessary equipment or programming to receive or process timing information from the satellite.

[0022] As a result, the distributed unit's clock may not keep time as accurately as the radio unit's clock. For example, the distributed unit's clock may rely on a crystal oscillator or other internal components, and the time kept by such components may vary depending on factors such as the temperature of the crystal. Therefore, if the distributed unit's clock "drifts" and maintains a slower or faster time than the radio unit's clock, the drift will ultimately cause the distributed unit to miss time slots for sending data to the radio unit, or to send more data than the radio unit can transmit in a given time slot. These results are undesirable because they result in "silence" (time slots in which no data is transmitted) or discarded data packets that must be retried and retransmitted. In some embodiments, the radio unit may have limited capacity for buffering data received prematurely from the distributed unit, which may allow the radio unit to temporarily compensate the distributed unit with a clock that maintains a faster time than the radio unit's clock. However, a distributed unit with an overly fast clock may ultimately send more data than the radio unit can store. In other embodiments, if the distributed unit fails to provide data in a timely manner, the radio unit may reset its connection to the distributed unit, which may cause one or more user devices to stop receiving data for an extended period of time.

[0023] Furthermore, in addition to transmitting data to the RU, the DU has other tasks to perform, which, if the DU's workload is high enough, may prevent the DU from transmitting data to the RU in a timely manner. For example, when data from the RU is generated and uploaded by the UE, the DU receives and processes such data. As a further example, the DU may receive more data from the CU than it can process in a single time slot. As a result, the DU may fail to transmit data to the RU in a timely manner, which can also lead to "silence" and less efficient use of the RU and radio spectrum.

[0024] To address these issues, operators of radio access networks can implement distributed units that perform timing synchronization and manage their workload, as described herein. As discussed in more detail below, the distributed units described herein can synchronize their clocks with the radio units by obtaining timing information from the radio units, determine whether and to what extent their clocks are drifting relative to the radio units, and apply correction factors to maintain their clock synchronization. The correction factors can be dynamically adjusted as the amount of clock drift changes (e.g., due to changes in the workload of the distributed units, changes in the temperature of the distributed units, etc.), and the distributed units can determine how often to synchronize their clocks with the radio units based on factors such as the workload of the radio units, the variability of the clock drift, and other criteria. Furthermore, the distributed units described herein can assess the risk that their workload will cause them to miss a window for transmitting data to the radio units, and if it appears likely that the distributed units will be unable to transmit data in a timely manner, they can take preventative actions to reduce their workload and mitigate the risk. In various embodiments, the distributed units can, for example, offload processing tasks to another distributed unit, throttle or postpone connections from the radio units or centralized units, or cause the radio units to throttle or postpone connections.

[0025] It should be understood that the techniques described herein address technical problems that arise particularly in the field of computer networks, and in particular, in the field of radio access networks, when a distributed unit does not have access to GPS-based timing information (or, more generally, when a distributed unit does not have access to the same timing information used by the radio units of the radio access network), or when the workload of the distributed unit prevents it from timely data transmission to the radio units. It should be further understood that the technical problems described herein are not analogous to any pre-Internet practices, and that the distributed units described herein improve the performance of radio access networks by preventing silence and packet loss. By implementing the distributed units described herein, wireless network operators can allow the distributed units and radio units to maintain synchronized clocks and thereby prevent "silence" or packet loss. Consequently, wireless network operators can use the techniques described herein to more effectively utilize their radio access networks and more efficiently provide wireless telecommunications services.

[0026] While the present disclosure references wireless standards such as 5G, it should be understood that the present disclosure is not limited to any particular wireless standard and that embodiments of the present disclosure include other wireless standards and protocols that have similar characteristics with respect to timing (e.g., 4G, LTE, 6G, etc.). Similarly, while the present disclosure references specific components of the RAN, it should be understood that the present disclosure is not limited to these components and includes within its scope other components that may have similar issues with timing synchronization or workload. It should further be understood that the present disclosure is not limited to a particular source of precise timing information such as GPS. For example, the RU may obtain timing information from satellites other than GPS satellites or from a land-based source of precise timing information.

[0027] Embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be construed in any limiting or restrictive manner, merely because the terminology is utilized in conjunction with the detailed description of certain specific embodiments of the invention. Furthermore, embodiments of the present invention may include several novel features, no single one of which is solely responsible for its desirable properties or essential to the practice of the invention described herein.

[0028] Figure 1 1 is a block diagram of an example operating environment in which a distributed unit 114 of a radio access network 110 may operate based on communications with a radio unit 112 and a centralized unit 116 of the radio access network 110. The radio unit 112 may, in turn, communicate with a user device 102 via an air interface 104 and may receive timing information and other signals from a satellite 122 (e.g., a GPS satellite) via a global navigation satellite system ("GNSS") receiver 118 and a satellite air interface 120. In some embodiments, the radio unit 112 may communicate directly or indirectly with other satellites. For example, the radio unit 112 may communicate with a satellite in low Earth orbit that delivers telecommunication services to the user device 102 via a satellite terminal or other interface. The centralized unit 116 may communicate with a network core 140 via a backhaul network 130. The network core 140 may, in turn, communicate with devices on external networks, enabling, for example, communication between the user device 102 and a server or other computing device on the Internet.

[0029] Generally speaking, user device 102 can be any device operable to communicate over air interface 104. Examples of user device 102 include mobile phones, tablet computing devices, laptop computing devices, wearable computing devices, desktop computing devices, personal digital assistants (PDAs), hybrid PDA / mobile phones, e-book readers, set-top boxes, voice command devices, cameras, digital media players, servers, and the like. Illustratively, air interface 104 can be an air interface to any wireless network, including but not limited to a cellular telecommunications network, a Wi-Fi network, a mesh network, a personal area network, or any combination thereof. In some embodiments, air interface 104 can be an interface to a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or a combination thereof. Satellite 122 can generally be any satellite that provides accurate timing information to ground-based devices via satellite air interface 120. Examples of satellite 122 and satellite air interface 120 include but are not limited to Global Positioning System ("GPS") satellites and the radio frequencies that the GPS satellites utilize to communicate with ground-based devices. In some embodiments, radio 112 may communicate with other networks or devices (e.g., atomic clocks) to obtain timing information. As used herein, "timing information" may generally refer to any information that enables radio 112 to determine the current absolute time and / or enables distributed unit 114 to determine the current clock setting of radio 112 (which, in some embodiments, may be set to the current absolute time).

[0030] Radio 112 obtains timing information from one or more satellites 122 over satellite air interface 120 using GNSS receiver 118, which can generally be any receiver operable to receive timing information from satellites 122 over satellite air interface 120. As described above, radio 112 can use the timing information obtained from satellites 122 to set and synchronize its clock 113. Radio 112 can thereby deliver data to user devices 102 at precise intervals, which can mitigate or prevent radio interference caused by multiple radios 112 delivering data to multiple user devices 102. Radio 112 transmits and receives data from user devices 102 over air interface 104 and serves as an endpoint for these user devices 102 to access network core 140 via radio access network 110 and backhaul network 130. Radio 112 can correspond to a base station of a cellular telephone network, or in some embodiments, can be deployed separately or independently from any existing cellular telephone network. In some embodiments, multiple radio units 112 may communicate with a single distributed unit 114 , and multiple distributed units 114 may in turn communicate with a single centralized unit 116 .

[0031] Distributed unit 114 is hereinafter referred to as Figure 6 The distributed unit 114 is described in more detail and is generally responsible for at least some aspects of the physical layer and the data link layer of the radio access network 110. The distributed unit 114 receives data from the centralized unit 116 and transmits the data to the radio unit 112 for delivery to the user device 102. As discussed above, in order to fully utilize the time slots during which the radio unit delivers data to the user device 102, the distributed unit 114 must deliver an appropriate amount of data to the radio unit 112 before the start of each time slot. This, in turn, requires that the clock 115 of the distributed unit 114 be aligned with the clock 113 of the radio unit 112, which in turn requires that the distributed unit 114 implement the functionality described herein even if it cannot obtain timing information from the satellite 122. Delivering data to the radio unit 112 before the start of each time slot also requires that the distributed unit 114 manage its workload to ensure that it has sufficient capacity to transmit data at the appropriate time.

[0032] Centralized unit 116 is responsible for the network layer functions of radio access network 110 and provides communication with other computing devices via backhaul network 130 and network core 140. Illustratively, backhaul network 130 can be any wired or wireless network, or a combination thereof. Additionally, backhaul network 130 can include, but is not limited to, the Internet, a public or private intranet, a cellular telecommunications network, a Wi-Fi network, a cable network, a satellite network, a mesh network, a personal area network, a local area network (LAN), a wide area network (WAN), or one or more other public or private communication networks, or any combination thereof. In some embodiments, backhaul network 130 can be implemented entirely or partially within a cloud provider network, as described in more detail below.

[0033] Radio unit 112, distributed unit 114, and centralized unit 116 are collectively referred to as an "open" radio access network 110, and the functionality of a monolithic baseband unit is split into modular components that provide different functionality and are available from multiple vendors. In some embodiments, all or part of radio access network 110 may be implemented using a cloud provider network. A cloud provider network (sometimes simply referred to as the "cloud") refers to a pool of network-accessible computing resources (such as computing, storage, and networking resources, applications, and services) that can be virtualized or provided as "bare metal" hardware. The cloud provides convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to variable loads. Cloud computing can therefore be considered both applications delivered as services over publicly accessible networks (e.g., the Internet, cellular communication networks), and the hardware and software in the cloud provider's data center that provides these services.

[0034] A cloud provider network offers users an on-demand, scalable computing platform over the network. For example, this allows users to have scalable "virtual computing devices" (also referred to as virtual computing instances) at their disposal using compute servers (which provide computing instances using one or both of a CPU and a GPU, optionally along with local storage) and block storage servers (which provide virtualized persistent block storage for a given computing instance). These virtual computing devices have the attributes of a personal computing device, including hardware (various types of processors, local memory, random access memory ("RAM"), hard disk and / or solid-state drive ("SSD") storage), a choice of operating system, network capabilities, and pre-loaded application software. Each virtual computing device also virtualizes its console input and output devices (e.g., keyboard, display, and mouse). This virtualization allows users to connect to their virtual computing devices using computer applications (such as browsers, application programming interfaces, software development kits, etc.) to configure and use their virtual computing devices just as they would with a personal computing device. Unlike personal computing devices, which have a fixed amount of hardware resources available to the user, the hardware associated with a virtual computing device can be scaled up or down based on the resources the user requires. An application programming interface (API) refers to an interface and / or communication protocol between a client and a server such that if a client makes a request in a predefined format, the client should receive a response in a specific format or initiate a defined action. In the context of a cloud provider network, an API provides a gateway for clients to access cloud infrastructure by allowing them to obtain data from the cloud provider network or initiate actions within the cloud provider network, thereby enabling the development of applications that interact with resources and services hosted in the cloud provider network. An API can also enable different services of the cloud provider network to exchange data with each other. Users may choose to deploy their virtual computing systems to provide network-based services for their own use and / or for use by their customers or clients.

[0035] The cloud provider network can be formed into multiple regions, where a region is a separate geographic area where the cloud provider clusters data centers. Each region can include two or more availability zones connected to each other by a private high-speed network (e.g., fiber optic communication connection). An availability zone refers to an isolated fault domain that includes one or more data center facilities with power, networking, and cooling separate from those in another availability zone. Preferably, the availability zones within a region are located far enough apart from each other that the same natural disaster does not take more than one availability zone offline at the same time. Customers can connect to the availability zones of the cloud provider network through a publicly accessible network (e.g., the Internet, a cellular communication network). A transit center (TC) is the main backbone location that links customers to the cloud provider network and can be co-located at other network provider facilities (e.g., an Internet service provider, a telecommunications provider). For redundancy, two TCs can be operated per region.

[0036] A cloud provider network may include a physical network (e.g., sheet metal boxes, cables, rack hardware) called the underlay. The underlay can be thought of as the network fabric that contains the physical hardware that runs the provider network's services. The underlay can be isolated from the rest of the cloud provider network; for example, it may not be possible to route from an underlay network address to an address in the production network running the cloud provider's services, or to a customer network hosting customer resources.

[0037] The cloud provider network may also include an overlay network of virtualized computing resources running on the underlay. Thus, network packets may be routed along the underlay network based on constructs in the overlay network (e.g., VPC, security groups). A mapping service may coordinate the routing of these network packets. The mapping service may be a regionally distributed lookup service that maps a combination of an overlay IP and a network identifier to an underlay IP so that distributed underlay computing devices can find where to send packets.

[0038] For illustration, each physical host (e.g., a compute server, a block storage server, an object storage server, a control server) may have an IP address in the underlying network. Hardware virtualization technology may enable multiple operating systems to run concurrently on a host computer, for example, as virtual machines (VMs) on a compute server. A hypervisor or virtual machine monitor (VMM) on the host allocates the host's hardware resources among the various VMs on the host and monitors the execution of the VMs. Each VM may be provided with one or more IP addresses in the overlay network, and the VMM on the host may know the IP addresses of the VMs on the host. The VMM (and / or other devices or processes on the network underlay) may use encapsulation protocol technology to encapsulate network packets (e.g., client IP packets) and route the network packets between virtualized resources on different hosts within the cloud provider network through the network underlay. Encapsulation protocol technology may be used on the network underlay to route encapsulated packets between endpoints on the network underlay through overlay network paths or routes. Encapsulation protocol technology may be viewed as providing a virtual network topology overlaid on the network underlay. The encapsulation protocol technology may include a mapping service that maintains a mapping directory that maps IP overlay addresses (e.g., public IP addresses) to underlying IP addresses (private IP addresses), which can be accessed by various processes on the cloud provider network for routing packets between endpoints.

[0039] In various embodiments, the traffic and operations underlying the provider network can be broadly broken down into two categories: control plane traffic carried through a logical control plane and data plane operations carried through a logical data plane. While the data plane represents the movement of user data through a distributed computing system, the control plane represents the movement of control signals through a distributed computing system. The control plane generally includes one or more control plane components distributed across and implemented by one or more control servers. Control plane traffic generally includes management operations, such as establishing isolated virtual networks for various customers, monitoring resource usage and health, identifying specific hosts or servers on which to launch requested compute instances, provisioning additional hardware as needed, and the like. The data plane includes customer resources (e.g., compute instances, containers, block storage volumes, databases, file storage) implemented on the provider network. Data plane traffic generally includes non-management operations, such as transferring data to and from customer resources.

[0040] The data plane may include one or more compute servers, which may be bare metal (e.g., a single tenant) or virtualized by a hypervisor to run multiple VMs (sometimes referred to as "instances") for one or more customers. These compute servers may support virtualized compute services for the provider network. Providers may offer virtual compute instances with varying compute and / or memory resources. In one embodiment, each of the virtual compute instances may correspond to one of several instance types. An instance type may be characterized by its hardware type, compute resources (e.g., the number, type, and configuration of central processing units [CPUs] or CPU cores), memory resources (e.g., the capacity, type, and configuration of local memory), storage resources (e.g., the capacity, type, and configuration of locally accessible storage), network resources (e.g., the characteristics of its network interfaces and / or network capabilities), and / or other suitable descriptive characteristics. Using instance type selection functionality, an instance type may be selected for a customer based, for example, (at least in part) on input from the customer. For example, a customer may select an instance type from a set of predefined instance types. As another example, a customer may specify desired resources for an instance type and / or the requirements of the workload the instance will run, and the instance type selection functionality may select an instance type based on such specifications.

[0041] The control plane components are typically implemented on a set of servers separate from the data plane servers, and control plane traffic and data plane traffic can be sent over separate / different networks. In some embodiments, control plane traffic and data plane traffic can be supported by different protocols. In some embodiments, messages (e.g., packets) sent over the provider network include a flag indicating whether the traffic is control plane traffic or data plane traffic. In some embodiments, the payload of the traffic can be inspected to determine its type (e.g., control plane or data plane). Other techniques for distinguishing traffic types are possible.

[0042] Some customers may desire to use resources and services from a cloud provider's network, but prefer to deploy these resources and services within their own network (e.g., on the customer's premises) for various reasons (e.g., latency of communication with customer devices, regulatory compliance, security, or other reasons). The technology described herein enables a small portion of a cloud provider's network—referred to herein as a "Provider Substrate Extension" or PSE—to be deployed within a customer's network. Customers can access their PSE through the cloud provider's substrate or their own network and can create and manage resources in the PSE using the same APIs they would use to create and manage resources in a region.

[0043] A PSE can be pre-configured, for example, by a provider network operator with the appropriate combination of hardware and software and / or firmware elements to support various types of computing-related resources, and do so in a manner that reflects the experience of using the provider network. For example, a cloud provider can provision one or more PSE servers within a customer's network. As described above, the provider network can offer a set of predefined instance types, each with a different type and quantity of underlying hardware resources. Each instance type can also be offered in a variety of sizes. To enable customers to continue using the same instance types and sizes in their PSEs as they do in their regions, PSE servers can be heterogeneous. Heterogeneous servers can simultaneously support multiple instance sizes of the same type and can be reconfigured to host any instance type supported by their underlying hardware resources. Reconfiguration of heterogeneous servers can be performed on the fly, using the PSE server's available capacity, meaning that it can be performed while other VMs are still running and consuming the PSE server's remaining capacity. This improves resource utilization within the PSE by allowing for better packaging of running instances on physical hosts and provides a seamless experience for instance usage across regions and PSEs.

[0044] In one embodiment, a PSE server can host one or more VMs. Customers can use these VMs to host containers, which package code and all its dependencies so that applications can run quickly and reliably from one computing environment to another. Additionally, if desired by the customer, a PSE server can host one or more data volumes. Within a region, such volumes can be hosted on dedicated block storage servers. However, since capacity within a PSE is likely significantly smaller than within a region, including such dedicated block storage servers may not provide an optimal utilization experience. Therefore, the block storage service can be virtualized within the PSE, with one of the VMs running the block storage software and storing the volume's data. Similar to the operation of the block storage service within a region, volumes within the PSE can be replicated for persistence and availability. These volumes can be provisioned within their own VPC within the PSE. The VMs and any volumes together constitute an extension of the provider network data plane within the PSE.

[0045] In some implementations, the PSE server may host certain local control plane components, such as those that enable the PSE to continue operating in the event of a loss of connectivity back to the region. Examples of these components include a migration manager that can move VMs between PSE servers as needed to maintain availability, a key-value data store that indicates where volume replicas are located, and a local VM placement component that can respond to requests for new VMs made through the customer network. However, the PSE's control plane will generally remain in the region to allow customers to use as much of the PSE's capacity as possible. In some embodiments, at least some VMs set up at the PSE, and associated higher-level services that use such VMs as building blocks, can continue to operate even during periods of temporary disruption of connectivity to the provider network's data center.

[0046] In the manner described above, a PSE forms an edge location because it provides the resources and services of a cloud provider network outside a traditional cloud provider data center and closer to the customer's device. Edge locations as mentioned herein can be structured in several ways. In some implementations, an edge location can be an extension of the cloud provider network's underlying layer, including a limited amount of capacity provided outside an availability zone (e.g., in a cloud provider's small data center or other facility located near the customer's workload and potentially far from any availability zone). Such edge locations can be referred to as local regions (due to being more local or closer to a group of users than traditional availability zones). A local region can be connected to a publicly accessible network (such as the Internet) in various ways (e.g., directly, via another network, or via a private connection to a region). Although typically a local region will have a more limited capacity than a region, in some cases, a local region can have considerable capacity, such as thousands or more racks.

[0047] In some embodiments, all or part of the radio access network 110 may be implemented on edge location hardware, which may be physically closer to devices such as RUs and UEs, for example. In some embodiments, an edge location may be an extension of the provider underlay formed by one or more servers located on-premises at a customer or partner facility. The servers may communicate with nearby availability zones or regions of the cloud provider network via a network (e.g., a publicly accessible network such as the Internet). This type of provider underlay extension may be referred to as an "outpost" of the cloud provider network. Some outposts may be integrated into the communications network. For example, an outpost may be integrated into a base station within a telecommunications network or co-located with a RU of the network. The limited capacity of an internal outpost may be available only to the customer with the premises (and any other accounts permitted by the customer). Similarly, the limited capacity of an outpost integrated into a telecommunications network may be shared among multiple applications (e.g., games, virtual reality applications, healthcare applications) that transmit data to users of the telecommunications network. An outpost integrated into a telecommunications network may also include data plane capacity, which may be at least partially controlled by a control plane implemented in a nearby availability zone of the cloud provider network. Thus, an availability zone group may include a "parent" availability zone and any "child" edge locations that are subordinate to the parent availability zone (e.g., at least partially controlled by its control plane). Certain limited control plane functionality (e.g., features required for low-latency communication with customer resources and / or features that enable edge locations to continue operating when disconnected from the parent availability zone) may also exist in some edge locations.

[0048] Thus, the radio access network 110 may communicate with a network core 140, which, in various embodiments, is implemented in a nearby availability zone of a cloud provider network, in an internal edge location, at another edge location, or on other network-accessible computing resources. For example, the network core 140 may be implemented using spare capacity of an outpost implementing RAN functionality, or on a separate outpost. Similarly, in various embodiments, the backhaul network 130 may be implemented partially or entirely on the cloud provider network. As described above, the network core 140 provides control plane functionality and performs management and control functions for the telecommunications network, such as authenticating subscribers, applying usage policies, managing UE sessions, and other control plane functions. The network core 140 includes, for example, access and mobility management functionality 142, which may control and be used to manage the workload of the distributed units 114, as described in more detail below. In some embodiments, the network core 140 may support multiple RANs and may further support RANs from multiple tenants or customers. In other embodiments, network core 140 may be implemented on dedicated computing resources of a particular wireless network operator, which may be provided internally or within a cloud provider network.

[0049] It should be understood that the radio access network 110, the network core 140, and other elements of the example operating environment 100 may include, for example, Figure 1 However, it is not necessary to show all of these generally conventional elements in order to provide an enabling disclosure.

[0050] Figure 2 is a flow chart depicting an example interaction for transmitting data from the distributed unit 114 to the radio unit 112 for delivery to the user device 102, according to aspects of the present disclosure. Illustratively, if performed at a time synchronized between the distributed unit 114 and the radio unit 112 using the techniques described herein, then Figure 2The interaction depicted in allows the distributed unit 114 to supply data to the radio unit 112 at a rate that allows each of the time slots 206A-206D to be utilized without providing excess data or failing to provide data for one of the time slots 206A-206D. At (1), the distributed unit 114 transmits data 202A to the radio unit 112 before time 204A. In the illustrated embodiment, time 204A corresponds to the start of time slot 206A, which is a time interval (e.g., 1 millisecond) during which the radio unit 112 transmits data 202A over the air to the user device 102. Therefore, the data 202A must be delivered to the radio unit 112 before time 204A so that the data is available to the radio unit 112 in time to be delivered to the user device 102 during time slot 206A. In some implementations, time 204A may precede the start of time slot 206A by an interval (e.g., 0.2 milliseconds), which may represent the amount of time required for radio 112 to receive and process data 202A before delivering it over the air to user device 102.

[0051] At (2), radio unit 112 transmits data 202A over the air to user device 102 during time slot 206A. This is then repeated for data 202B, time 204B, and time slot 206B, further repeated for data 202C, time 204C, and time slot 206C, further repeated for data 202D, time 204D, and time slot 206D, and so on, repeating the interactions at (1) and (2) indefinitely. Because these interactions are repeated on a relatively small time scale, distributed unit 114 must keep its internal clock synchronized with the internal clock of radio unit 112 so that both distributed unit 114 and radio unit 112 agree on the values ​​of time 204A, time 204B, time 204C, and so on. Specifically, if the clock of distributed unit 114 "drifts" relative to the clock of radio unit 112, such that, for example, 1.0 milliseconds elapses on the clock of distributed unit 114 while 1.1 milliseconds elapses on the clock of radio unit 112, the net result will be that distributed unit 114 misses one of its windows for delivering data to radio unit 112. Missing a window will result in a "silence" during which radio unit 112 does not deliver data to user device 102, and in some embodiments may cause radio unit 112 to reset its connection to distributed unit 114 or user device 102, which may further disrupt the delivery of data to user device 102. Similarly, if the clock of distributed unit 114 is faster than the clock of radio unit 112 (e.g., if 1.0 milliseconds elapses on the clock of distributed unit 114 while 0.9 milliseconds elapses on the clock of radio unit 112), distributed unit 114 may send more data than radio unit 112 can transmit or buffer during one of time slots 206A-206D. Therefore, it is desirable that the clocks of the distributed units 114 and the radio units 112 remain synchronized, which may be achieved using the techniques described herein.

[0052] In addition to keeping the clocks of distributed unit 114 and radio unit 112 synchronized, distributed unit 114 must also ensure that it has sufficient capacity to perform the interaction at (1) before each of times 204A-204D. If distributed unit 114 falls behind due to excessive workload, it will miss one of its windows for delivering data to radio unit 112, which may also result in "silence" and inefficient use of computing resources and radio spectrum. Therefore, it is desirable for distributed unit 114 to manage its workload so that it has sufficient resources to transmit data 202A-202D to radio unit 112 in a timely manner, which can be achieved using the techniques described herein.

[0053] Figure 3is a flow chart depicting example interactions for initially setting the clock of distributed unit 114 according to aspects of the present disclosure. These interactions initially synchronize the clock of distributed unit 114 with the clock of radio unit 112 and thereby establish a baseline for measuring drift and determining correction factors. At (1), distributed unit 114 requests timing information from radio unit 112. As discussed above, radio unit 112 sets and maintains its clock based on timing information obtained from satellite 122 and therefore keeps time to a higher degree of accuracy than distributed unit 114. In some embodiments, distributed unit 114 may select radio unit 112 from a plurality of radio units with which it communicates and may select radio unit 112 based on factors such as radio unit workload (e.g., by selecting radio unit 112 as the "least busy" radio unit in a group of radio units). At (2), radio unit 112 provides the requested timing information and distributed unit 114 uses the requested timing information to initially set its clock at (3). In some embodiments, radio 112 may provide timing information to distributed unit 114 without receiving the explicit request at (1). For example, radio 112 may transmit data packets to distributed unit 114 using the enhanced Common Public Radio Interface ("eCPRI") protocol and may timestamp the data packets it transmits. In some embodiments, radio 112 may include a network interface card or other component that supports hardware timestamping and, therefore, include a hardware timestamp in the transmitted data packets. Distributed unit 114 may then derive the setting of the radio 112 clock from the timestamp. In such embodiments, the interaction at (1) may be omitted, and distributed unit 114 may set its clock based on the received information.

[0054] The timing information received from radio 112 may generally include any information that allows distributed unit 114 to accurately determine the setting of radio 112's internal clock and to set its own internal clock to match the radio's internal clock. In some embodiments, the timing information may include information that allows distributed unit 114 to determine the time delay between radio 112 transmitting the timing information and distributed unit 114 receiving the timing information. Thus, distributed unit 114 may set its clock to compensate for the time delay (e.g., by setting its clock "ahead" of radio 112 by the amount of the time delay). In some embodiments, distributed unit 114 may repeatedly perform the interactions at (1) and (2) (e.g., for a specified period of time) before performing the interaction at (3), and may initially set its clock based on multiple responses to the request for timing information (and, in some embodiments, determine an initial correction factor as described below). In further embodiments, distributed unit 114 may determine the number of times or the amount of time it took to perform the interactions at (1) and (2), and may make that determination based on factors such as the desired estimated accuracy or the amount of time initially allocated for clock synchronization.

[0055] Figure 4 1 is a flow chart depicting example interactions for keeping the clock of distributed unit 114 consistent with the clock of radio unit 112, and for determining the frequency at which to synchronize the clock of distributed unit 114 and apply a correction factor to the clock of distributed unit 114, according to aspects of the present disclosure. As discussed in more detail above, keeping the clock of distributed unit 114 synchronized with the clock of radio unit 112 enables timely delivery of data from distributed unit 114 to radio unit 112, so that radio unit 112 can fully utilize its available time slot for transmitting data to user device 102 and does not receive more data than it can transmit during the time slot. At (1), the distributed unit may again request timing information from radio unit 112. In some embodiments, as described above, the interaction at (1) may be omitted, and radio unit 112 may provide timing information without an explicit request. At (2), radio unit 112 provides the requested timing information, and at (3), distributed unit 114 resynchronizes its clock with the clock of radio unit 112. As discussed above, in some embodiments, radio 112 may provide timing information including hardware time stamps, information obtained from GPS satellites or other external timing sources, or other timing information.

[0056] At (4), distributed unit 114 determines whether its internal clock has drifted relative to the clock of radio unit 112, and if so, determines the amount and direction of the drift. For example, it may be determined that the clock of distributed unit 114 is running slower than the clock of radio unit 112 such that for every 1.0 millisecond that passes on the clock of radio unit 112, 0.9 milliseconds pass on the clock of distributed unit 114. As a further example, distributed unit 114 may determine that its clock is running faster such that for every 1.0 millisecond that passes on the clock of radio unit 112, 1.12 milliseconds pass on the clock of distributed unit 114. In some embodiments, the interactions at (1) and (2) may be repeated multiple times, and an average or median drift may be determined based on the timing information collected from radio unit 112 multiple times. In further embodiments, the timing information collected from radio unit 112 may be filtered to remove outliers, such as those determined to be caused by network delays.

[0057] At (5), distributed unit 114 determines and begins applying a correction factor to keep its internal clock consistent with the clock of radio unit 112. In some embodiments, the correction factor may be an amount of time that is added to or subtracted from the clock after each millisecond has passed. For example, the correction factor may be 0.1 milliseconds added to the clock of distributed unit 114 for each millisecond that has passed since the clock was last synchronized, or 0.12 milliseconds subtracted from the clock of distributed unit 114 for each millisecond that has passed. In other embodiments, the correction factor may be a multiplier or a percentage. Distributed unit 114 may apply the correction factor to its clock, or in some embodiments, may apply the correction factor when determining when to send data to radio unit 112. In some embodiments, the interaction at (3) may be omitted or combined with the interaction at (5). For example, distributed unit 114 may determine at (4) that the clock of distributed unit 114 is currently 0.11 milliseconds behind the clock of radio unit 112, and may begin applying a correction factor of 0.11 milliseconds every millisecond at (5). Thus, the first application of the correction factor will synchronize the clock of distributed unit 114 with the clock of radio unit 112. In other embodiments, the interaction at (3) may be performed after either or both of the interactions at (4) and (5). For example, the correction factor may be a value other than the delta between the two clocks, and the clocks may be resynchronized based on the timing information obtained at (2) before or after applying the correction factor.

[0058] At (6), the distributed unit 114 may determine when to send a further request for timing information to the radio unit 112 (or, in some embodiments, may determine when to re-analyze the timing information it passively received from the radio unit 112). Illustratively, determining when to send a further request for timing information and resynchronize may be based on an assessment of how stable and consistent the distributed unit's 114 clock drift is over time. In some embodiments, the clock drift may vary based on factors such as the workload of the distributed unit 114, the temperature of the distributed unit 114, or changes in the workload of the distributed unit 114 over time. For example, if the workload of the distributed unit 114 is relatively constant, the distributed unit 114 may determine that its clock drift is relatively stable and may postpone sending its next request for timing information for a relatively long interval (e.g., three to five seconds). In some embodiments, the distributed unit 114 may collect workload metrics such as processor utilization, memory consumption, etc. to assess the stability of its workload. In other embodiments, the next request for timing information may be triggered by an event such as processor utilization exceeding a threshold, or may be based on the estimated reliability of a correction factor. For example, if the correction factor is determined based on an average of multiple drift measurements, the reliability of the correction factor may be estimated based on the standard deviation of the drift measurements.

[0059] In some embodiments, distributed unit 114 may take into account the workload of radio unit 112 when determining whether and when to send further requests for timing information to radio unit 112. For example, distributed unit 114 may consider whether the request for timing information will consume bandwidth that would otherwise be used for data packet transmission, and may postpone transmitting the request for timing information (or, in some embodiments, transmit the request for timing information to a different radio unit) if radio unit 112 is busy or its performance would otherwise be affected. In further embodiments, distributed unit 114 may identify a radio unit among multiple radio units connected to distributed unit 114 that has sufficient capacity to respond to the timing information request, or may distribute the timing information request to multiple radio units based on a polling or other algorithm. In other embodiments, radio unit 112 may periodically send timing information to distributed unit 114 regardless of whether it receives a request from distributed unit 114, and distributed unit 114 may determine the time to make the request at (6) only if the interval between periodic receipts of timing information is long enough that the clock of distributed unit 114 may drift out of sync during the interval. In further embodiments, radio unit 112 may periodically send timing information more frequently than distributed unit 114 requires the timing information, and distributed unit 114 may determine at (6) which periodically received timing information to process and which periodically received timing information to discard.

[0060] Distributed unit 114 may then repeat the interaction at (1) at the time determined at (6) to obtain further timing information from radio unit 112, and then iteratively perform the interactions at (3), (4), (5), and (6) to maintain synchronization of the clock of distributed unit 114 with the clock of radio unit 112. By maintaining clock synchronization in the aforementioned manner, distributed unit 114 may ensure that it transmits data to radio unit 112 at a time that allows radio unit 112 to fully utilize available time slots for transmitting data over the air to user devices.

[0061] It should be understood that Figure 4is provided for illustrative purposes, and many variations of the interactions depicted are within the scope of the present disclosure. For example, the interactions at (3) and (4) may be performed sequentially or in parallel. As a further example, the interactions at (1), (2), (3), and (4) may be performed multiple times before performing the interactions at (5) and (6), and the correction factor determined and applied at (5) may be based on an average clock drift across multiple measurements. Still further, in some embodiments, the correction factor and the time to make the next timing information request may be determined based on other factors in addition to the current clock drift, such as an estimated workload or operating temperature trend of the processors of the distributed unit 114. Thus, Figure 4 It is to be understood as illustrative rather than restrictive.

[0062] Figure 5 is a flow diagram depicting example interactions for managing the workload of distributed unit 114 according to aspects of the present disclosure. These interactions reduce the risk that the workload of distributed unit 114 will increase to a level that prevents distributed unit 114 from transmitting data to radio unit 112 in a timely manner. At (1), distributed unit 114 determines a likelihood of missing the next window for transmitting data to radio unit 112. As discussed above, the window in which distributed unit 114 should transmit data 112 to the radio unit precedes the time slot in which the radio unit transmits data to user device 102. In some embodiments, the window may precede the time slot by a fixed amount, which may represent the time required for radio unit 112 to process received data and prepare for data transmission. In other embodiments, the determination at (1) may be a likelihood that a deadline (e.g., the end of the window) will be missed.

[0063] In some embodiments, the determination at (1) may be performed by estimating the time at which distributed unit 114 will transmit data 112 to radio unit 112. The determination may be based on, for example, historical times when distributed unit 114 has transmitted data to radio unit 112, information about the historical workload of distributed unit 114, information about the current workload of distributed unit 114, or other information that can be used to estimate the next time distributed unit 114 will transmit data. For example, distributed unit 114 may estimate that distributed unit 114 will transmit data within 450 nanoseconds based on its current memory usage, processor utilization, and the amount of data remaining to be processed before it can be transmitted. In other embodiments, the determination at (1) may be performed by estimating the likelihood that distributed unit 114 will miss a deadline for transmitting data to radio unit 112, or by determining a confidence level that distributed unit 114 will transmit data before the deadline. In some embodiments, the determination may be made using a machine learning model trained on historical workload information and historical data transmission times.

[0064] At (2), distributed unit 114 may determine whether the likelihood meets a threshold. For example, distributed unit 114 may determine whether the estimated time at which the data will be transmitted is within a threshold time interval (e.g., 50 nanoseconds) of the end of the window. As a further example, distributed unit 114 may determine whether its estimated likelihood of missing the deadline has exceeded a threshold (e.g., 10%), or whether its confidence level that the deadline will be met has fallen below a threshold (e.g., 80%). In some embodiments, the interactions at (1) and (2) may be combined, and the determination at (1) may be, for example, a determination of whether there is at least a 20% likelihood of missing the data transmission window.

[0065] In embodiments where the determination at (2) is that the distributed unit 114 is at an unacceptable risk of missing a data transmission window, the distributed unit 114 may, in some embodiments, request the access and mobility management function 142 at (3) to reduce the workload of the distributed unit 114. Figure 8 As described in more detail, the access and mobility management function 142 can reduce the workload of the distributed unit 114 by rejecting new requests for services from the user device 102 or redirecting the new requests (e.g., to another distributed unit 114). In some embodiments, the distributed unit 114 can reduce its own workload by rejecting new requests for services from the user device 102, throttling the services being provided to the user device 102 (e.g., limiting the data throughput of the services), causing existing services to be handed over to another distributed unit 114, or otherwise modifying its workload. In other embodiments (e.g., cloud computing environments), the distributed unit 114 can obtain additional computing resources and increase its capacity rather than reducing its workload. In addition, in some embodiments, the access and mobility management function 142 can obtain workload information from the distributed unit 114, perform the interactions at (1) and (2), and independently determine whether to reduce or rebalance the workload of the distributed unit.

[0066] At (4), the distributed unit 114 transmits data to the radio unit 112 before the end of the data transmission window. Illustratively, the interaction at (4) may be performed before or in parallel with the interactions at (1), (2), and (3), and in some embodiments, the interaction at (4) may take precedence over the other interactions to ensure that the distributed unit 114 meets the deadline for transmitting data to the radio unit 112. At (5), the radio unit 112 may transmit the data received from the distributed unit 114 to one or more user devices 102 during the time slot. The next time slot and the next deadline may then be performed. Figure 5, and the interactions may be performed iteratively while the distributed unit 114 remains in service. In some embodiments, the interactions at (1), (2), and (3) may be performed less frequently than the interactions at (4) and (5). For example, the interactions at (1) and (2) may be performed once for every ten interactions at (4) and (5), and if the determination at (2) is that the distributed unit 114 is at an unacceptably high risk of missing the deadline for transmitting data to the radio unit 112, the interaction at (3) may be performed as needed. In some embodiments, the distributed unit 114 may make the determination at (1) based on the average time the distributed unit 114 transmits data to the radio unit 112, an average workload metric, a peak workload, a worst-case time, or other measurements collected and aggregated across multiple time slots. In other embodiments, the distributed unit 114 may identify trends in the data collected across multiple time slots (e.g., the distributed unit 114 is getting closer to missing the window) and may make the determination at (2) based on these trends.

[0067] It should be understood that Figure 5 is provided for example purposes, and many variations of the interactions depicted are within the scope of this disclosure. For example, the interaction at (3) may be performed after or in parallel with the interaction at (4) to increase the likelihood that distributed unit 114 transmits data before the end of the window. As a further example, distributed unit 114 may determine whether it is possible to increase its capacity rather than request a reduction in workload, and if so, may omit the interaction at (3). Thus, Figure 5 It is to be understood as illustrative rather than restrictive.

[0068] Figure 6 is a flow chart depicting an example interaction for reducing the workload of distributed units 114 according to aspects of the present disclosure. It should be understood that Figure 6 The interactions depicted in are provided for example purposes, and many other techniques for reducing the workload of the distributed unit 114 are within the scope of this disclosure. In the illustrated embodiment, the workload of the distributed unit 114 is generated by the access and mobility management function 142 responding to requests from the distributed unit 114 (e.g., Figure 5 In various embodiments, by rejecting a new request for service from user device 102, by accepting a new request for service but then having a different distributed unit ( Figure 6The access and mobility management function 142 can reduce the workload of the distributed unit 114 by providing the requested service (not depicted) or by handing over one or more existing services being provided by the distributed unit 114 to a different distributed unit. In other embodiments, as discussed in more detail below, the distributed unit 114 can reduce its workload independently of the access and mobility management function 142.

[0069] In the illustrated embodiment, at (1), one or more user devices 102 request a new service from the wireless network operator by transmitting a message to the radio unit 112. For example, the user device 102 may request content from a server on the Internet, request that content be transferred to a server on the Internet, initiate a voice call, or otherwise request one or more services that the distributed unit 114 will participate in providing, thereby increasing the workload of the distributed unit.

[0070] At (2), the radio unit relays the request to the distributed unit 114, which relays the request to the access and mobility management function 142 at (3). In some embodiments, the distributed unit 114 may simply drop the request rather than relaying it to the access and mobility management function 142, which may further reduce the workload of the distributed unit 114, but may provide a suboptimal user experience if the request for service is dropped without providing feedback or response to the requesting user device 102. In other embodiments, the distributed unit 114 may allow the request to be relayed to the access and mobility management function 142, but if the access and mobility management function 142 grants the request, a rate-limited or otherwise throttled service may be provided.

[0071] At (4), the access and mobility management function 142 denies the request from the user device 102 and continues to deny requests from the user device 102 until the probability that the distributed unit 114 will miss the data transmission window no longer satisfies the requirement from the user device 102. Figure 5In some embodiments, the access and mobility management function 142 accepts the request from the user device 102 but instructs the user device 102 to hand over to a different distributed unit (e.g., a distributed unit that is not at risk of missing the data transmission window). In some embodiments, the access and mobility management function 142 may continue to reject or hand over requests from the user device 102 until it receives a message from the distributed unit 114 indicating that the workload of the distributed unit has been reduced to an acceptable level and the likelihood of the distributed unit missing the data transmission window no longer meets the threshold. In other embodiments, the access and mobility management function 142 may reject or hand over requests from the user device 102 for a fixed interval whenever a workload reduction request is received from the distributed unit 114, or may directly or indirectly monitor the workload of the distributed unit 114 and determine on its own whether the workload has been reduced to an acceptable level. For example, the distributed unit 114 may transmit workload information and other status information to a server in the cloud provider network, and the access and mobility management function 142 may monitor the workload of the distributed unit 114 by obtaining workload information from the cloud-based server. In a further embodiment, the access and mobility management function 142 may be performed by obtaining and analyzing workload data from servers in the cloud provider network. Figure 5 and Figure 6 Various other interactions depicted in .

[0072] In some embodiments, as discussed above, the distributed unit 114 can reduce the workload of the distributed unit by throttling the services currently being provided by the distributed unit 114 to the user devices 102. For example, the distributed unit 114 can enforce a schedule used by the user devices 102 and can limit the number of fixed time slots (spots) on the schedule allocated to one or more user devices 102. In other embodiments, the distributed unit 114 can request the radio unit 112 to identify and hand over user devices 102 that can be handed over to another radio unit.

[0073] Figure 7 is a depiction of aspects of the present disclosure for enabling distributed units (e.g., Figure 1 Flowchart of an example routine 700 for clock synchronization of a distributed electrical unit 114 depicted in FIG. The routine 700 may be performed, for example, by a timing synchronization module (e.g., Figure 9) or by another component of the distributed unit. Routine 700 begins at block 702, where timing information may be obtained from the radio. As discussed above, the timing information may be obtained from the radio in response to a request, or in some embodiments, from information transmitted by the radio without an explicit request (e.g., a timestamped packet header). The timing information may include, for example, a hardware timestamp or other timestamp on packets transmitted by the radio, GPS information received by the radio, or other information that enables synchronization with the radio's clock. At block 704, the distributed unit's clock may be synchronized to the radio's clock.

[0074] At block 706, data may be transmitted from the distributed unit to the radio unit at a time that allows the radio unit to transmit data during a defined data transmission window. Figure 2 As described in more detail, the radio unit may transmit data to the user device during pre-scheduled time slots and, therefore, may require the distributed unit to send data to be transmitted before the arrival of each time slot. Thus, the data transmission at block 706 may occur at a time determined after synchronizing the clocks of the distributed unit and the radio unit to ensure that the transmission is received in a timely manner at the radio unit.

[0075] At decision block 708, a determination may be made as to whether the clock of the distributed unit has drifted from the clock of the radio unit. If such a determination cannot be made because routine 700 does not have sufficient timing information (e.g., because block 702 was executed only once), routine 700 may branch to block 702 and obtain further timing information from the radio unit. If the determination at decision block 708 is that the clock of the distributed unit has drifted, then at block 710, a correction factor may be determined and iteratively applied. As described in more detail above, the correction factor may be applied periodically (e.g., once every millisecond), on demand (e.g., when the distributed unit has data ready to send), or based on other criteria. In some embodiments, as described in more detail above, block 704 may be omitted or combined with block 710. For example, the initial application of the correction factor at block 710 may cause the clocks to become synchronized.

[0076] If the determination at decision block 708 is that the distributed unit's clock has not drifted significantly from the radio unit's clock, then at decision block 712, a determination may be made as to whether the workload, temperature, or other local conditions at the distributed unit have changed in a manner that could cause the amount of clock drift to change. In some embodiments, a machine learning model may be trained on historical clock drift information and used to estimate expected clock drift. In such embodiments, the determination at decision block 708 may therefore be whether the machine learning model has sufficient confidence in its prediction. If the determination at decision block 708 is that local conditions have changed and / or the amount of clock drift cannot be estimated with confidence, then the routine 700 returns to block 702, obtains updated timing information from the radio unit, and resynchronizes the distributed unit's clock to the radio unit's clock.

[0077] If the determination at decision block 712 is that local conditions remain relatively static, or after the correction factor is determined and applied at block 710, the routine 700 continues to block 714 where a determination may be made as to when to request updated timing information from the radio and resynchronize the clocks of the distributed units. As discussed in more detail above, the determination of when to request updated timing information may be based on factors such as radio workload, distributed unit workload, changes in distributed unit workload or operating temperature, variability in recent measurements of clock drift, or other factors.

[0078] At decision block 716, a determination may be made as to whether the time determined at block 714 has arrived. If so, routine 700 branches to block 702, where updated timing information may be obtained from the radio, and then iterates through blocks 704 to 714 to keep the distributed unit's clock synchronized with the radio's clock. If the determination at decision block 716 is that the time determined at block 714 has not arrived, at block 718, the distributed unit may rely on its current correction factor to compensate for any clock drift and may transmit data to the radio during the next data transmission window for delivery to the user device. In some embodiments, decision block 716 may be combined with decision block 712, and a determination may be made as to whether the time determined at block 714 has arrived or whether local conditions have changed. Routine 700 may then iterate indefinitely to keep the distributed unit's clock synchronized with the radio's clock.

[0079] It should be understood that Figure 7is provided for example purposes, and many variations on the illustrated routine 700 are within the scope of the present disclosure. For example, decision block 716 may be performed after block 718. As a further example, blocks 702, 704, and 706 may be performed several times before decision block 708 is performed, or decision block 708 may be performed several times before block 710 is performed. As an even further example, block 706 may be combined with block 718, and the routine 700 may begin applying the correction factor before any data is transmitted to the radio. Still further, in some embodiments, the routine 700 may limit the frequency with which block 702 is performed based on factors such as the workload of the radio or the available bandwidth between the radio and the distributed units. Thus, Figure 7 It is to be understood as illustrative rather than restrictive.

[0080] Figure 8 is a diagram according to aspects of the present disclosure for managing distributed units (e.g., Figure 1 Flowchart of an example routine 800 for distributing a workload of the electrical unit 114 as depicted in FIG. The routine 800 may be executed, for example, by a workload management module (e.g., Figure 9 ) or by another component of the distributed unit. Routine 800 begins at block 802, where a time by which data must be transmitted to a radio unit in order for the radio unit to use its next data transmission window is obtained. In various contexts herein, this time may be referred to as a "deadline" or the end of a "window." Illustratively, a distributed unit may send data to a radio unit too early (i.e., before the start of a window), but this can generally be prevented by waiting until the intended radio unit is ready to receive the next batch of data. As discussed above, the time obtained at block 802 may correspond to the start of a radio unit's data transmission window and, in some embodiments, may be offset from the window by an amount of time corresponding to the time required for the radio unit to receive and process the data before transmitting it.

[0081] At block 804, workload information may be obtained for the distributed units. As discussed in more detail above, the workload information may include metrics such as memory usage, processor usage, processor temperature, etc., as well as information about the work performed by the distributed units, such as the number of services being provided, the amount of data transmitted or received in a given time interval, etc. In some embodiments, the workload information obtained at block 804 may include historical information, such as previously captured metrics or previously executed workloads.

[0082] At block 806, a determination may be made as to the likelihood that the distributed unit will transmit data to the radio unit after the deadline. In some embodiments, the likelihood may be determined as a percentage or confidence level. For example, the determination may be that there is a 5% chance that the distributed unit will transmit data to the radio unit after the deadline. In some embodiments, the determination may be made by comparing the workload information obtained at block 804 with historical workload information and the historical times at which the distributed unit transmitted data to the radio unit under those workloads. For example, the distributed unit may identify 20 historical workload instances comparable to the distributed unit's current workload and may determine, for example, that the distributed unit transmitted data before the deadline in 19 of those 20 instances. As a further example, in some embodiments, the distributed unit may use the historical information to determine that its workload has increased over time and that its risk of missing a deadline has also increased over time, though it should be understood that in many embodiments, the risk of missing a deadline may increase more rapidly and nonlinearly relative to the increase in workload. In some embodiments, statistical analysis (e.g., linear regression) may be used to detect trends in the historical information and determine the likelihood of missing a deadline. In other embodiments, a machine learning model trained on historical workloads and historical data transfer times can be applied to the current workload of the distributed units, and the machine learning model can generate as its output the probability of missing a deadline. Additionally, in some embodiments, statistical analysis, trend analysis, and / or machine learning can be used to estimate the probability that a future deadline (e.g., the next subsequent deadline for hitting a time slot, or more generally, any deadline after the deadline obtained at block 802) will be missed, and routine 800 can use this estimate to proactively begin reducing the workload of the distributed units before the future deadline arrives.

[0083] In some embodiments, block 806 may be performed by estimating the time at which the distributed unit will transmit data to the radio unit, determining a confidence level in the estimate (e.g., based on historical workload and historical data transmission times), and then determining a likelihood that the actual time at which the distributed unit transmits data to the radio unit will be after the deadline. In further embodiments, instead of or in addition to determining the likelihood that the distributed unit will miss the deadline, a delta between the estimated time and the deadline may be determined.

[0084] As discussed above, several other techniques for determining whether a distributed unit is at risk of missing a deadline are within the scope of the present disclosure. Additionally, in some embodiments, instead of determining the likelihood or confidence level that a distributed unit will miss a deadline, the likelihood or confidence level that a distributed unit will meet the deadline may be determined.

[0085] At decision block 808, a determination may be made as to whether the likelihood that the distributed unit will miss the deadline meets a threshold. In some embodiments, the determination may be as to whether the likelihood of missing the deadline is above a threshold (e.g., 2%). In other embodiments, the determination may be as to whether the delta between the estimated time and the deadline is below a threshold (e.g., at least 50 nanoseconds before the deadline). In some embodiments, the reduction in the workload of the distributed unit required to prevent the likelihood from meeting the threshold may be quantified based on, for example, the size of the delta or the amount by which the likelihood exceeds the threshold.

[0086] If the determination at decision block 808 is that the likelihood meets the threshold (and therefore, the workload of the distributed unit should be reduced), then at block 810, a process for reducing the workload of the distributed unit may be initiated. This may be done, for example, by executing Figure 6 The process is initiated by the interactions depicted in FIG8 and causing the access and mobility management function to reject new requests for services or redirect new or existing workloads to other distributed units. It should be understood that the process of reducing the workload of the distributed units is initiated at block 810 and is performed over time and is generally not completed before the routine 800 continues to block 812.

[0087] If the determination at decision block 808 is that the workload of the distributed unit does not need to be reduced, or after workload reduction is initiated at block 810, routine 800 continues to block 812, where data may be transmitted to the radio unit before the deadline obtained at block 802. Routine 800 then returns to block 802 and iterates for the next deadline for transmitting data to the radio unit, and for subsequent deadlines thereafter. In some embodiments, routine 800 may be executed when it is too late to prevent the distributed unit from missing a deadline, and thus, block 812 may be postponed or omitted. For example, routine 800 may be executed in response to a distributed unit missing a deadline and may determine that the distributed unit will miss further deadlines before its workload can be reduced to a manageable level. In other embodiments, block 812 may be executed immediately after block 802 or in parallel with any or all of blocks 804 through 810.

[0088] In some embodiments, as described in more detail above, blocks 802 and 812 may be performed more frequently than other blocks of routine 800. For example, the workload information obtained at block 804 may be aggregated or averaged across several data transfer windows, and routine 800 may perform a "spot check" every ten windows. As a further example, blocks 806 and 808 may be performed only if the workload information obtained at block 804 indicates that the workload of the distributed unit is relatively high (e.g., a workload that has historically been associated with missed deadlines or a workload that represents a relatively high risk of missing a deadline). It should be understood that Figure 8 It is provided for example purposes, and many variations on the depicted routine 800 are within the scope of the present disclosure.

[0089] Figure 9 Depicted is the overall architecture of a computing system (referenced as distributed unit 114) that synchronizes timing information, manages its workload, and transmits information to a radio unit in accordance with aspects of the present disclosure. Figure 9 The overall architecture of the distributed unit 114 depicted in FIG includes an arrangement of computer hardware and software modules that can be used to implement various aspects of the present disclosure. The hardware modules can be implemented using physical electronic devices, as discussed in more detail below. The distributed unit 114 may include more than Figure 9 However, it is not necessary to show all of these generally conventional elements in order to provide an enabling disclosure. In addition, Figure 9 The overall architecture described in Figure 1 One or more of the other components described.

[0090] As illustrated, the distributed unit 114 includes a processor 902, an input / output device interface 904, a network interface 906, a data repository 908, a clock 113, and a memory 920, all of which can communicate with each other via a communication bus 912. The network interface 906 can provide access to various devices such as Figure 1 1 , the radio unit 112, the centralized unit 116, or one or more networks or computing systems of other components of the radio access network 110 as depicted in FIG. 1 . The processor 902 may thus receive information and instructions from other computing systems or services. The processor 902 may also provide output information to an optional display (not shown) via the input / output device interface 904. The input / output device interface 904 may also accept input from an optional input device (not shown).

[0091] The memory 920 may contain computer program instructions (grouped into modules in some embodiments) that the processor 902 executes to implement one or more aspects of the present disclosure. The memory 920 typically includes random access memory (RAM), read-only memory (ROM), and / or other persistent, auxiliary, or non-transitory computer-readable media. The memory 920 may store an operating system 922 that provides computer program instructions for use by the processor 902 in the general management and operation of the distributed unit 114. The memory 920 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 920 includes an interface module 924 that generates an interface (and / or instructions for interacting with other computing devices) for interacting with other computing devices, such as via an API, CLI, and / or Web interface.

[0092] In addition to and / or in combination with the interface module 924, the memory 920 may include a timing synchronization block 926 that may be executed by the processor 902. In one embodiment, the timing synchronization block 926 implements various aspects of the present disclosure, for example, synchronizing the clock 113 of the distributed unit 114 with the clock of the radio unit 112. Figure 9 14, but in other embodiments, all or part of clock 113 may be implemented by other components of distributed unit 114. For example, in certain embodiments of the present disclosure, processor 902 may implement some or all of the functionality of clock 113. Memory 920 may further include a workload management module 928 that is executable by processor 902. In one embodiment, workload management module 928 implements various aspects of the present disclosure, such as managing the workload of distributed unit 114.

[0093] Memory 920 may further include radio timing information 930, which is described in more detail above and which may be obtained from a radio (e.g., Figure 1 112). The memory 920 may further include workload information 932, which is described in more detail above and may be obtained, for example, by measuring usage of the memory 920 or the processor 902. The memory 920 may further include data to be transmitted 932, which may be obtained from a centralized unit (e.g., Figure 116) and may be transmitted to the radios via the network interface 906. The memory 920 may further include workload information 934 for the distributed units 114 and / or one or more radios in communication with the distributed units 114. In some embodiments, the memory 920 may further include, for example, a clock drift model 936 (e.g., a machine learning model trained to estimate changes in time drift), data received from the radios, workload estimates, historical clock drift, or other information.

[0094] In some embodiments, the distributed unit 114 may further include Figure 9 For example, the memory 920 may further include a workload estimation module for estimating the workload of the distributed unit 114, or may include a user interface for configuring the distributed unit 114. Figure 9 It is to be understood as illustrative rather than restrictive.

[0095] Various example embodiments of the present disclosure may be described by the following terms:

[0096] Clause 1. A system comprising:

[0097] a radio unit comprising a first processor and a clock that keeps time based at least in part on signals received from a satellite; and

[0098] A distributed unit comprising a second processor and a clock that keeps time based at least in part on oscillations of a crystal, wherein the second processor executes computer-executable instructions to perform operations comprising:

[0099] obtaining first timing information from the radio unit based at least in part on a first signal received from the satellite, wherein the first timing information enables synchronization of the clock of the distributed unit with the clock of the radio unit;

[0100] synchronizing the clock of the distributed unit with the clock of the radio unit based on the first timing information;

[0101] determining a first time to transmit first data to the radio unit based at least in part on synchronizing the clock of the distributed unit, wherein transmitting the first data at the first time enables the radio unit to transmit the first data over a radio access network during a first timing window;

[0102] transmitting the first data to the radio unit at the first time;

[0103] obtaining second timing information from the radio unit based at least in part on a second signal received from the satellite, wherein the second timing information enables resynchronization of the clock of the distributed unit with the clock of the radio unit;

[0104] determining a drift of the clock of the distributed unit relative to the clock of the radio unit based at least in part on the second timing information;

[0105] determining a correction factor based at least in part on the drift of the clock of the distributed unit to compensate for the drift of the clock of the distributed unit;

[0106] applying the correction factor to the clock of the distributed unit;

[0107] determining a second time to transmit second data to the radio unit based at least in part on applying the correction factor to the clock of the distributed unit, wherein transmitting the second data at the second time allows the radio unit to transmit the second data over the radio access network during a second timing window; and

[0108] The second data is transmitted to the radio unit at the second time.

[0109] Clause 2. The system of Clause 1, wherein applying the correction factor to the clock of the distributed unit comprises periodically adding or subtracting time from the clock of the distributed unit.

[0110] Clause 3. The system of clause 1, wherein the processor executes further computer-executable instructions to perform further operations, the further operations comprising:

[0111] determining a third time to transmit third data to the distributed unit based at least in part on the plurality of applications of the correction factor to the clock of the distributed unit, wherein transmitting the third data at the third time allows the radio unit to transmit the third data over the radio access network during a third timing window; and

[0112] The third data is transmitted to the radio unit at the third time.

[0113] Clause 4. The system of clause 1, wherein the distributed unit is implemented using an edge location of a cloud provider network.

[0114] Clause 5. The system of Clause 1, wherein obtaining the first timing information comprises transmitting a request for the first timing information to the radio unit.

[0115] Clause 6. A computer-implemented method comprising:

[0116] synchronizing a first clock of the distributed unit with a second clock of the radio unit based on first timing information obtained from the radio unit;

[0117] transmitting first data from the distributed unit to the radio unit at a first time determined based at least in part on synchronizing the second clock;

[0118] determining a drift of the second clock relative to the first clock based at least in part on second timing information obtained from the radio unit;

[0119] periodically applying a correction factor to the second clock, wherein the correction factor is determined based at least in part on the drift of the second clock; and

[0120] Second data is transmitted from the distributed unit to the radio unit at a second time determined based at least in part on applying the correction factor to the second clock.

[0121] Clause 7. The computer-implemented method of Clause 6, wherein the correction factor is determined based at least in part on one or more of processor load, processor temperature, or memory utilization.

[0122] Clause 8. The computer-implemented method of Clause 6, wherein the correction factor is dynamically updated using a machine learning model trained to estimate clock drift.

[0123] Clause 9. The computer-implemented method of Clause 6, further comprising determining a time to obtain third timing information from the radio.

[0124] Clause 10. A computer-implemented method as described in clause 9, wherein the time at which the third timing information is obtained from the radio unit is determined at least in part based on one or more of the workload of the radio unit, the workload of the distributed unit, the temperature of the distributed unit, a change in the workload of the distributed unit, or an estimated reliability of the correction factor.

[0125] Clause 11. The computer-implemented method of Clause 6, wherein the correction factor is determined based at least in part on averaging a plurality of drifts of the second clock.

[0126] Clause 12. The computer-implemented method of Clause 6, wherein the first timing information comprises a timestamp on a data packet received from the radio unit.

[0127] Clause 13. The computer-implemented method of Clause 6, further comprising filtering timing information obtained from the radio.

[0128] Clause 14. The computer-implemented method of Clause 13, wherein filtering the timing information obtained from the radio unit comprises determining that network delays cause one or more outliers.

[0129] Clause 15. The computer-implemented method of Clause 13, wherein filtering the timing information obtained from the radio unit comprises one or more of removing one or more outliers or applying a weighting factor to individual data points in the timing information.

[0130] Clause 16. The computer-implemented method of Clause 6, further comprising selecting the radio from among a plurality of radios connected to the distributed unit based at least in part on respective workloads of the plurality of radios.

[0131] Clause 17. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a distributed unit comprising a processor, configure the distributed unit to perform operations comprising:

[0132] transmitting first data from the distributed unit to the radio unit at a first time determined based at least in part on synchronizing a clock of the distributed unit with a clock of a radio unit;

[0133] applying a correction factor to the clock of the distributed unit based at least in part on timing information obtained from the radio unit; and

[0134] Second data is transmitted from the distributed unit to the radio unit at a second time determined based at least in part on applying the correction factor to the clock of the distributed unit.

[0135] Clause 18. One or more non-transitory computer-readable media as described in Clause 17, wherein the timing information obtained from the radio unit includes: a plurality of timestamps on data packets sent by the radio unit over an enhanced Common Public Radio Interface ("eCPRI") protocol.

[0136] Clause 19. One or more non-transitory computer-readable media as recited in Clause 17, storing further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform further operations, the further operations comprising:

[0137] The clock of the distributed unit is synchronized with the clock of the radio unit based on the timing information obtained from the radio unit.

[0138] Clause 20. One or more non-transitory computer-readable media as recited in Clause 17, storing further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform further operations, the further operations comprising:

[0139] An updated correction factor is applied to the clock of the distributed unit based at least in part on further timing information obtained from the radio unit.

[0140] Clause 21. The one or more non-transitory computer-readable media of Clause 17, wherein the timing information is obtained from the radio at a plurality of times.

[0141] Clause 22. A system comprising:

[0142] a centralized unit of a radio access network;

[0143] a radio unit of the radio access network; and

[0144] a distributed unit of the radio access network, the distributed unit comprising a process for executing computer-executable instructions to perform operations comprising:

[0145] receiving, from the centralized unit, first data to be transmitted to the radio unit;

[0146] obtaining a first time before which the first data is transmitted to the radio unit, wherein transmitting the first data to the radio unit before the first time enables the radio unit to transmit the first data to one or more user devices in a first time slot;

[0147] obtaining workload information about the workload of the distributed unit;

[0148] determining, based at least in part on the workload information, a likelihood that the distributed unit will transmit the first data to the radio unit after the first time; and

[0149] In response to a determination that the likelihood satisfies a threshold, the workload of the distributed unit is reduced until the likelihood no longer satisfies the threshold.

[0150] Clause 23. The system of Clause 22, wherein one or both of the centralized unit and the distributed unit are implemented on an edge server of a cloud provider network.

[0151] Clause 24. A system as described in Clause 22, wherein reducing the workload of the distributed unit includes one or more of the following: the distributed unit requests the access and mobility management function to reject new requests for services, the distributed unit rejects new requests for services, the distributed unit transfers new services to a second distributed unit, the distributed unit transfers existing services to the second distributed unit, or the distributed unit throttles existing services.

[0152] Clause 25. The system of Clause 22, wherein the workload information comprises one or more of memory utilization, processor utilization, processor temperature, amount of data transmitted, or amount of data received.

[0153] Clause 26. The system of clause 22, wherein the distributed unit determines the likelihood that the distributed unit will transmit the first data to the radio unit after the first time based at least in part on one or more previous times that the distributed unit transmitted data to the radio unit.

[0154] Clause 27. A system as described in clause 22, wherein the distributed unit executes further executable instructions to perform further operations, the further operations comprising: determining that the likelihood satisfies the threshold based at least in part on a determination that the distributed unit will transmit the first data to the radio unit after a threshold time, and wherein the threshold time precedes the first time by a fixed interval.

[0155] Clause 28. A computer-implemented method comprising:

[0156] obtaining, by a distributed unit, a first time before which first data is transmitted from the distributed unit to a radio unit, wherein transmitting the first data from the distributed unit to the radio unit before the first time enables the radio unit to transmit the first data in a first time slot;

[0157] obtaining, by the distributed unit, workload information regarding the workload of the distributed unit;

[0158] determining, by the distributed unit based at least in part on the workload information, a likelihood that the distributed unit will transmit the first data to the radio unit after the first time; and

[0159] In response to determining that the likelihood satisfies a threshold, the workload of the distributed unit is reduced until the likelihood no longer satisfies the threshold.

[0160] Clause 29. The computer-implemented method of Clause 28, further comprising obtaining a plurality of past times at which the distributed unit transmitted data to the radio unit, wherein the likelihood is determined based at least in part on the plurality of past times.

[0161] Clause 30. The computer-implemented method of Clause 28, wherein determining the likelihood that the distributed unit will transmit the first data to the radio unit after the first time comprises applying a machine learning model to the workload information.

[0162] Clause 31. A computer-implemented method as described in Clause 28, further comprising: obtaining, by the distributed unit, a second time before which second data is transmitted from the distributed unit to the radio unit, wherein transmitting the second data from the distributed unit to the radio unit before the second time enables the radio unit to transmit the second data in a second time slot.

[0163] Clause 32. The computer-implemented method of Clause 31, wherein the first time is a fixed amount of time before the start of the first time slot, and wherein the second time is a fixed amount of time before the start of the second time slot.

[0164] Clause 33. The computer-implemented method of Clause 28, wherein the workload information comprises information regarding an amount of data received from one or more of the radio units or centralized units over a period of time.

[0165] Clause 34. The computer-implemented method of Clause 28, wherein obtaining the first time comprises obtaining timing information from the radio.

[0166] Clause 35. The computer-implemented method of Clause 28, wherein reducing the workload of the distributed unit comprises transmitting a message from the distributed unit to an access and mobility management function ("AMF").

[0167] Clause 36. The computer-implemented method of Clause 35, wherein the message is in response to a request for the workload information from the AMF.

[0168] Clause 37. The computer-implemented method of Clause 35, wherein the message comprises a request by the AMF to deny new requests for services that would increase the workload of the distributed unit.

[0169] Clause 38. The computer-implemented method of Clause 28, further comprising: receiving the first data from a centralized location.

[0170] Clause 39. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a distributed unit comprising a processor, configure the distributed unit to perform operations comprising:

[0171] obtaining workload information about the workload of the distributed unit;

[0172] determining, based at least in part on the workload information, a likelihood that the distributed unit will transmit first data to a radio unit after a first time, wherein transmitting the first data to the radio unit before the first time enables the radio unit to transmit the first data in a first time slot; and

[0173] In response to determining that the likelihood satisfies a threshold, the workload of the distributed unit is reduced.

[0174] Clause 40. One or more non-transitory computer-readable media of Clause 39 storing further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform further operations, the further operations comprising:

[0175] A second likelihood is determined based at least in part on the updated workload information that the distributed unit will transmit second data to the radio unit after a second time, wherein transmitting the second data to the radio unit before the second time enables the radio unit to transmit the second data in a second time slot.

[0176] Clause 41. One or more non-transitory computer-readable media of Clause 40 storing still further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform still further operations, the still further operations comprising:

[0177] In response to determining that the second likelihood satisfies the threshold, the workload of the distributed unit is further reduced.

[0178] Clause 42. One or more non-transitory computer-readable media of Clause 40 storing still further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform still further operations, the still further operations comprising:

[0179] In response to determining that the second likelihood does not satisfy the threshold, the workload of the distributed unit is permitted to increase.

[0180] It should be understood that not necessarily all objects or advantages may be achieved in accordance with any particular embodiment described herein. Thus, for example, those skilled in the art will recognize that certain embodiments may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages that may be taught or suggested herein.

[0181] All of the processes described herein may be embodied in and entirely automatically via software code modules comprising one or more specific computer-executable instructions executed by a computing system. The computing system may include one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods may be embodied in dedicated computer hardware.

[0182] In light of this disclosure, many other variations besides those described herein will be apparent. For example, depending on the embodiment, certain actions, events, or functions of any of the algorithms described herein may be performed in a different order, added, merged, or omitted entirely (e.g., not all of the described actions or events are necessary for the practice of the algorithm). Furthermore, in certain embodiments, actions or events may be performed simultaneously (e.g., via multithreading, interrupt handling, or multiple processors or processor cores or on other parallel architectures), rather than sequentially. Additionally, different tasks or processes may be performed by different machines and / or computing systems that can operate together.

[0183] The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein may be implemented or executed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. The processor may be a microprocessor, but in alternative embodiments, the processor may be a controller, a microcontroller, or a state machine, a combination thereof, or the like. The processor may include circuitry configured to process computer-executable instructions. In another embodiment, the processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration. Although primarily described herein with respect to digital technology, the processor may also primarily include analog components. The computing environment may include any type of computer system, including but not limited to computer systems based on microprocessors, mainframe computers, digital signal processors, portable computing devices, device controllers, or computing engines within appliances, to name a few.

[0184] Unless expressly provided otherwise, conditional language, such as, inter alia, "can," "may," "might," or "could," should be otherwise understood within the context as generally used to convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Thus, such conditional language is generally not intended to imply that one or more embodiments require a feature, element, and / or step in any way, or that one or more embodiments necessarily include logic for determining, with or without user input or prompting, whether such features, elements, and / or steps are included or will be performed in any particular embodiment.

[0185] Unless expressly provided otherwise, connective language such as the phrase "at least one of X, Y, or Z" is otherwise understood in context to be generally used to present that an item, term, etc. can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require the presence of at least one of X, at least one of Y, or at least one of Z.

[0186] Any process description, element or block in the flowcharts described herein and / or depicted in the accompanying drawings should be understood to potentially represent a module, segment or portion of code that includes one or more executable instructions for implementing the specific logical functions or elements in the process. Those skilled in the art will understand that alternative implementations are included within the scope of the embodiments described herein, in which elements or functions may be deleted, performed in an order different from that shown or discussed, including substantially simultaneously or in a reverse order, depending on the functionality involved.

[0187] Unless expressly provided otherwise, articles such as "a" or "an" are generally understood to include one or more of the described items. Thus, a phrase such as "a device configured to..." is intended to include one or more of the recited devices. Such one or more recited devices may also be collectively configured to perform the recited statements. For example, "a processor configured to perform statements A, B, and C" may include a first processor configured to perform statement A working in conjunction with a second processor configured to perform statements B and C.

Claims

1. A system comprising: a radio unit comprising a first processor and a clock that keeps time based at least in part on signals received from a satellite; as well as A distributed unit comprising a second processor and a clock that keeps time based at least in part on oscillations of a crystal, wherein the second processor executes computer-executable instructions to perform operations comprising: obtaining first timing information from the radio unit based at least in part on a first signal received from the satellite, wherein the first timing information enables synchronization of the clock of the distributed unit with the clock of the radio unit; synchronizing the clock of the distributed unit with the clock of the radio unit based on the first timing information; determining a first time to transmit first data to the radio unit based at least in part on synchronizing the clock of the distributed unit, wherein transmitting the first data at the first time enables the radio unit to transmit the first data over a radio access network during a first timing window; transmitting the first data to the radio unit at the first time; obtaining second timing information from the radio unit based at least in part on a second signal received from the satellite, wherein the second timing information enables resynchronization of the clock of the distributed unit with the clock of the radio unit; determining a drift of the clock of the distributed unit relative to the clock of the radio unit based at least in part on the second timing information; determining a correction factor based at least in part on the drift of the clock of the distributed unit to compensate for the drift of the clock of the distributed unit; applying the correction factor to the clock of the distributed unit; determining a second time to transmit second data to the radio unit based at least in part on applying the correction factor to the clock of the distributed unit, wherein transmitting the second data at the second time allows the radio unit to transmit the second data over the radio access network during a second timing window; and The second data is transmitted to the radio unit at the second time.

2. The system of claim 1 , wherein applying the correction factor to the clock of the distributed unit comprises: Time is periodically added or subtracted from the clocks of the distributed units.

3. The system of claim 1 , wherein the processor executes further computer-executable instructions to perform further operations, the further operations comprising: determining a third time to transmit third data to the distributed unit based at least in part on the plurality of applications of the correction factor to the clock of the distributed unit, wherein transmitting the third data at the third time allows the radio unit to transmit the third data over the radio access network during a third timing window; and The third data is transmitted to the radio unit at the third time.

4. The system of claim 1, wherein the distributed unit is implemented using an edge location of a cloud provider network.

5. The system of claim 1 , wherein obtaining the first timing information comprises: A request for the first timing information is transmitted to the radio unit.

6. A computer-implemented method comprising: synchronizing a first clock of a distributed unit with a second clock of the radio unit based on first timing information obtained from a radio unit, wherein the first timing information enables synchronization of the first clock of the distributed unit with the second clock of the radio unit; transmitting first data from the distributed unit to the radio unit at a first time determined based at least in part on synchronizing the second clock, wherein transmitting the first data at the first time enables the radio unit to transmit the first data over a radio access network during a first timing window; determining a drift of the second clock relative to the first clock based at least in part on second timing information obtained from the radio unit, wherein the second timing information enables resynchronization of the first clock of the distributed unit with the second clock of the radio unit; periodically applying a correction factor to the second clock, wherein the correction factor is determined based at least in part on the drift of the second clock; as well as Transmitting second data from the distributed unit to the radio unit at a second time determined at least in part based on applying the correction factor to the second clock, wherein transmitting the second data at the second time allows the radio unit to transmit the second data over the radio access network during a second timing window.

7. The computer-implemented method of claim 6, wherein the correction factor is determined based at least in part on one or more of processor load, processor temperature, or memory utilization.

8. The computer-implemented method of claim 6, wherein the correction factor is dynamically updated using a machine learning model trained to estimate clock drift.

9. The computer-implemented method of claim 6, further comprising: A time is determined at which third timing information is obtained from the radio unit.

10. The computer-implemented method of claim 9, wherein the time to obtain the third timing information from the radio unit is determined based at least in part on one or more of a workload of the radio unit, a workload of the distributed unit, a temperature of the distributed unit, a change in the workload of the distributed unit, or an estimated reliability of the correction factor.

11. The computer-implemented method of claim 6, wherein the correction factor is determined based at least in part on averaging a plurality of drifts of the second clock.

12. The computer-implemented method of claim 6, wherein the first timing information comprises a timestamp on a data packet received from the radio.

13. The computer-implemented method of claim 6, further comprising: Timing information obtained from the radio unit is filtered.

14. The computer-implemented method of claim 13 , wherein filtering the timing information obtained from the radio comprises: Determine that network latency is causing one or more outliers.

15. The computer-implemented method of claim 13 , wherein filtering the timing information obtained from the radio comprises: One or more outliers are removed, or a weighting factor is applied to one or more of the data points in the timing information.

16. The computer-implemented method of claim 6, further comprising: The radio is selected from among a plurality of radios connected to the distributed unit based at least in part on respective workloads of the plurality of radios.

17. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a distributed unit comprising a processor, configure the distributed unit to perform operations comprising: transmitting first data from the distributed unit to the radio unit at a first time determined based at least in part on synchronizing a clock of the distributed unit with a clock of the radio unit using first timing information, wherein the first timing information enables synchronization of the clock of the distributed unit with a clock of the radio unit, and wherein transmitting the first data at the first time enables the radio unit to transmit the first data over a radio access network during a first timing window; applying a correction factor to a clock of the distributed unit based at least in part on second timing information obtained from the radio unit, wherein the second timing information enables resynchronization of the clock of the distributed unit with the clock of the radio unit; as well as Transmitting second data from the distributed unit to the radio unit at a second time determined at least in part based on applying the correction factor to a clock of the distributed unit, wherein transmitting the second data at the second time allows the radio unit to transmit the second data over the radio access network during a second timing window.

18. The one or more non-transitory computer-readable media of claim 17, wherein the first timing information obtained from the radio unit comprises: Multiple timestamps on data packets sent by the radio unit over the enhanced Common Public Radio Interface ("eCPRI") protocol.

19. The one or more non-transitory computer-readable media of claim 17, storing further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform further operations, the further operations comprising: The clock of the distributed unit is synchronized with the clock of the radio unit based on the first timing information obtained from the radio unit.

20. The one or more non-transitory computer-readable media of claim 17, storing further computer-executable instructions that, when executed by the processor, configure the distributed unit to perform further operations, the further operations comprising: An updated correction factor is applied to the clock of the distributed unit based at least in part on further timing information obtained from the radio unit.

21. The one or more non-transitory computer-readable media of claim 17, wherein the second timing information is obtained from the radio at a plurality of times.

Images