Distributed unit timing synchronization

Abstract

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

Description

Background Art

[0001] Generally speaking, computing devices may be used to exchange information over a network. Computing devices may 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 a Long Term Evolution ("LTE") protocol. The wireless network may be composed of separate network components, such as a radio unit that transmits and receives radio signals within a particular geographic area, a distributed unit that transmits and receives data from the radio unit, and a centralized unit that connects the distributed unit to other communication networks. Thus, the radio unit may receive data from the distributed unit and transmit data to the user device, and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Reference numerals may be repeated throughout the drawings to indicate correspondence between referenced elements.The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the present 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 a distributed unit and a radio unit 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] Fig. 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 clock of the distributed unit with one or more radios of the radio access network and managing the workload of the distributed unit to ensure that the distributed unit does not miss a time slot for transmitting data to a radio of the RAN.

[0013] The functionality of the RAN may be split between 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 associated with 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 for transmitting and receiving radio signals, and each RU may provide coverage to different geographic areas, which may partially overlap with areas of adjacent RUs to facilitate handover and provide seamless communication. The DUs may generally receive data from the CUs for delivery to the RUs (and vice versa), and may process the data to encode or decode, modulate or demodulate, add or remove error correction or redundancy, or otherwise prepare the data received from the CUs for transmission over the air by the RUs, and vice versa. The functionality implemented by the DU may include some layer 1 functions, such as encoding digital signals to be transmitted by the RU, adding redundancy and error correction codes to the digital signals, mapping transmission channels to physical channels, and the like. 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, and the like. The CU may in turn implement "layer 3" ("L3") functions, such as mediating access to external networks, authorizing access to the RAN, and the like.

[0014] Thus, the distributed unit may receive data from the centralized unit, and may 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 may send data to the RU, which in turn may 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 a specified time window (which may be referred to as a "time slot" in this article). It may therefore 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 a cellular network can be an important element of the system, not only to enable the system to operate properly, but also to achieve increasing data rates while reducing latency, such as in a 5G network. 5G cellular systems have particularly strict synchronization requirements on the RAN side and the device side. In order to fulfill these requirements, some 5G RAN deployments may use GPS on components such as 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 requirements of the desired network coverage, one or more RUs may be located away from the DU, such as on or near the 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. Nanosecond accuracy may not be necessary for the DU, which provides digital processing of received and transmitted data. However, the DU must generate data to be transmitted by the RU at each slot boundary. The slot duration depends on the subcarrier spacing, with some implementations typically featuring a 1ms slot duration. Due to the tight integration between the DU and the RU, it may be desirable to also have the GPS 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 due to the need to connect a GPS antenna to a place 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 different levels of reliability, which may cause the elements to become unsynchronized and may cause communication problems. For example, a radio unit may rely on a satellite network (e.g., a global positioning system or "GPS") to obtain timing information, but a distributed unit may be deployed at a location where a GPS signal is not available, and may therefore rely on its own internal clock or a networked time server, which may drift relative to the GPS synchronized clock of the radio unit. If timing synchronization is not performed on the DU, the clock is likely to drift to the extent that the DU misses the time slot boundary in which data must be delivered to the RU. This may be the result of a slow drift of the DU internal clock due to an inaccurate local oscillator crystal (relative to PTP) or the temperature response of the crystal. When the DU does not 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 the 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 understood, this may result in a very poor user experience. The present disclosure solves this problem 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 the 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 actively request timing information from the RU based on its own time. The RU may respond with a packet including 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 specific 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 process similar to the initial time synchronization may continue during the 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 occupies bandwidth originally 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 (for example, to achieve redundancy, increased area coverage, or increased device number support), 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 including timing information (and which may be hardware-stamped) at regular intervals (such as time slot boundaries), and have the DU extract timing information from some or all of the packets it receives. The DU may use the timing information it receives periodically 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 change 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 transmits 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. Therefore, 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 duration. 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, the radio unit can deliver data to the user device during the specified time slot. The time slot can start at a time based on the internal clock of the radio unit. For example, the radio unit can deliver data to the user device in a time slot of one millisecond each in duration, and these time slots can start and end at 12:00:00.000pm, 12:00:00.001, 12:00:00.002, etc. according to the clock of the radio unit. The radio unit can set and synchronize their clocks by obtaining timing information from satellites. For example, the radio unit 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 unit to accurately determine the start and end of each time slot for sending data to the user device.

[0021] In order to transmit data to a user device in each of the time slots of a radio unit, 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 keep time consistently and accurately in order to determine the start of each of the time slots of the radio unit and deliver the 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 close to the antenna of a cellular tower and has the necessary equipment and programming for receiving and processing radio signals from a 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 for receiving or processing timing information from a satellite.

[0022] Thus, the clock of the distributed unit may not keep time as accurately as the clock of the radio unit. For example, the clock of the distributed unit may rely on a crystal oscillator or other internal component, and the time kept by such a component may vary depending on factors such as the temperature of the crystal. Therefore, if the clock of the distributed unit "drifts" and keeps a slower or faster time than the clock of the radio unit, the drift will eventually cause the distributed unit to miss a time slot 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" (a time slot in which no data is transmitted) or discarded data packets that must be retried and retransmitted. In some embodiments, the radio unit may have a limited capacity for buffering data received too early from the distributed unit, which may allow the radio unit to temporarily compensate the distributed unit with a clock that keeps a faster time than the radio unit clock. However, a distributed unit with an overly fast clock may eventually 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 a longer duration.

[0023] Additionally, in addition to transmitting data to the RU, the DU has other tasks to perform, which, if the workload of the DU 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 may also result in "silence" and less efficient use of the RU and radio spectrum.

[0024] To address these issues, operators of radio access networks may implement distributed units that perform timing synchronization and manage their workloads, as described herein. As discussed in more detail below, the distributed units described herein may synchronize their clocks with the radio units by obtaining timing information from the radio units, may determine whether their clocks drift relative to the radio units and the extent of the drift, and may apply correction factors to keep their clocks synchronized. The correction factors may 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 may determine the frequency at which their clocks are synchronized with the radio units based on factors such as the workload of the radio units, the variability of the clock drift, and other criteria. Further, the distributed units described herein may assess the risk that their workload will cause them to miss a window for transmitting data to the radio units, and if it appears that the distributed units will not be able to transmit data in a timely manner, preventive actions may be taken to reduce their workloads and mitigate the risk. In various embodiments, the distributed units may, for example, offload processing tasks to another distributed unit, throttle or postpone a connection from a radio unit or a centralized unit, or cause a radio unit to throttle or postpone a connection.

[0025] It should be understood that the techniques described herein solve technical problems that arise specifically in the field of computer networks, and in particular solve problems that arise specifically in the field of radio access networks in the following situations: when the distributed unit does not have access to GPS-based timing information (or, more generally, when the 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 unit. It should be further understood that the technical problems described herein are not similar to any pre-Internet practices, and the distributed units described herein improve the performance of the radio access network 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. Therefore, wireless network operators can use the techniques described herein to more effectively utilize their radio access networks and provide wireless telecommunications services more efficiently.

[0026] Although 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 (e.g., 4G, LTE, 6G, etc.) that have similar characteristics in terms of timing. Similarly, although 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 be further understood that the present disclosure is not limited to a specific precise timing information source such as GPS. For example, the RU may obtain timing information from satellites other than GPS satellites or from a land-based precise timing information source.

[0027] Embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like numbers refer to like elements throughout. The terms used in the descriptions presented herein are not intended to be interpreted in any limiting or restrictive manner, simply because the terms are utilized in conjunction with the detailed description of certain specific embodiments of the present invention. In addition, embodiments of the present invention may include several novel features, a single feature of which is not solely responsible for its desired properties or essential to practicing 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 an external network, thereby enabling, for example, communications between the user device 102 and a server or other computing device on the Internet.

[0029] In general, user device 102 may be any device operable to communicate via 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 may 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 may 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 may 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 radio frequencies that the GPS satellites utilize to communicate with ground-based devices. In some embodiments, the 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 the radio 112 to determine the current absolute time and / or enables the distributed unit 114 to determine the current clock setting of the radio 112 (which may be set to the current absolute time in some embodiments).

[0030] The radio unit 112 obtains timing information from one or more satellites 122 via the satellite air interface 120 using a GNSS receiver 118, which may be generally any receiver operable to receive timing information from a satellite 122 via the satellite air interface 120. As described above, the radio unit 112 may use the timing information obtained from the satellite 122 to set and synchronize the clock 113 of the radio unit 112. The radio unit 112 may thereby deliver data to the user device 102 at precise intervals, which may mitigate or prevent radio interference caused by multiple radio units 112 delivering data to multiple user devices 102. The radio unit 112 transmits and receives data from the user devices 102 via the air interface 104, and serves as an endpoint for these user devices 102 to access the network core 140 via the radio access network 110 and the backhaul network 130. The radio unit 112 may correspond to a base station of a cellular telephone network, or in some embodiments may 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 is consistent with the clock 113 of the radio unit 112, which in turn requires the distributed unit 114 to implement the functionality described herein in the event that 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 the distributed unit 114 to manage its workload in order to ensure that it has sufficient capacity to transmit data at the appropriate time.

[0032] Centralized unit 116 is responsible for network layer functions of radio access network 110 and provides communication with other computing devices through backhaul network 130 and network core 140. Illustratively, backhaul network 130 can be any wired or wireless network or combination thereof. In addition, 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 in whole or in part within a cloud provider network, as described in more detail below.

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

[0034] A cloud provider network can provide users with an on-demand scalable computing platform over a network, for example, allowing users to have scalable "virtual computing devices" (also referred to as virtual computing instances) at their disposal by using computing servers (the computing servers provide computing instances through one or both of CPUs and GPUs, optionally used with local storage) and block storage servers (the block storage servers provide virtualized persistent block storage for designated computing instances). These virtual computing devices have the attributes of personal computing devices, 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 can also virtualize 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 do with personal computing devices. Unlike personal computing devices that have a fixed amount of hardware resources available to users, the hardware associated with virtual computing devices can be scaled up or down according to the resources required by the user. 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 the cloud infrastructure by allowing them to obtain data from the cloud provider network or cause 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 may also enable different services of a 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 one region is a separate geographic area where the cloud provider clusters data centers. Each region may include two or more availability zones connected to each other by a private high-speed network (e.g., a 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 that are separate from those in another availability zone. Preferably, the availability zones within a region are located far enough away from each other so 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 switching center (TC) is the main backbone location that links customers to the cloud provider network and may be co-located at other network provider facilities (e.g., an Internet service provider, a telecommunications provider). To achieve redundancy, two TCs may be operated per region.

[0036] The cloud provider network may include a physical network (e.g., sheet metal boxes, cables, rack hardware) called the underlay. The underlay may be considered a network fabric that contains the physical hardware that runs the provider network's services. The underlay may be isolated from the rest of the cloud provider network, e.g., it may not be possible to route from an underlay network address to an address in the production network that runs the cloud provider's services, or to a customer network that hosts 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 according to the 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 the distributed underlay computing devices can look up where to send the packet.

[0038] For illustration, each physical host (e.g., computing server, block storage server, object storage server, 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 a virtual machine (VM) on a computing server. The hypervisor or virtual machine monitor (VMM) on the host allocates the hardware resources of the host between the various VMs on the host and monitors the execution of the VM. 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 address of the VM on the host. The VMM (and / or other devices or processes on the network bottom layer) 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 in the cloud provider network through the network bottom layer. Encapsulation protocol technology may be used on the network bottom layer to route encapsulated packets between endpoints on the network bottom layer through an overlay network path or route. Encapsulation protocol technology may be viewed as providing a virtual network topology overlaid on the network bottom layer. 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 at the bottom layer of the provider network can be generally divided into two categories: control plane traffic carried by a logical control plane and data plane operations carried by 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 one or more control servers 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 to launch requested computing instances, configuring additional hardware as needed, and the like. The data plane includes customer resources (e.g., computing instances, containers, block storage volumes, databases, file storage) implemented on the provider network. Data plane traffic generally includes non-management operations, such as transmitting data to and from customer resources.

[0040] The data plane may include one or more computing servers, which may be bare metal (e.g., a single tenant) or may be virtualized by a hypervisor to run multiple VMs (sometimes referred to as "instances") for one or more customers. These computing servers may support virtualized computing services for the provider network. The provider may provide virtual computing instances with different computing and / or memory resources. In one embodiment, each of the virtual computing instances may correspond to one of several instance types. The instance type may be characterized by its hardware type, computing 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 interface and / or network capabilities), and / or other suitable descriptive characteristics. Using the instance type selection functionality, an instance type may be selected for a customer, for example (at least in part) based on input from a customer. For example, a customer may select an instance type from a set of predefined instance types. As another example, a customer may specify the desired resources of an instance type and / or the requirements of the workload that 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 the control plane traffic and the data plane traffic can be sent over separate / different networks. In some embodiments, the control plane traffic and the data plane traffic can be supported by different protocols. In some embodiments, the message (e.g., packet) sent over the provider network includes a flag indicating whether the traffic is control plane traffic or data plane traffic. In some embodiments, the payload of the traffic can be checked 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 of a cloud provider network, but prefer to provision 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, legal compliance, security, or other reasons). The technology described herein enables a small portion of a cloud provider network, referred to herein as a "provider underlay extension," or PSE, to be provisioned within a customer's network. Customers can access their PSEs through the cloud provider underlay or their own network, and can create and manage resources in the PSE using the same APIs that they would use to create and manage resources in a region.

[0043] The PSE may be pre-configured with a suitable combination of hardware and software and / or firmware elements to support various types of computing-related resources, for example, by a provider network operator, and in a manner that reflects the experience of using the provider network. For example, one or more PSE servers may be configured in a customer network by a cloud provider. As described above, the provider network may provide a set of predefined instance types, each of which has different types and quantities of underlying hardware resources. Each instance type may also be provided in various sizes. In order to enable customers to continue to use the same instance types and sizes used in their PSEs as they do in the region, the PSE server may be a heterogeneous server. Heterogeneous servers may support multiple instance sizes of the same type at the same time, and may also be reconfigured to host any instance type supported by its underlying hardware resources. The reconfiguration of heterogeneous servers may be performed instantly using the available capacity of the PSE server, which means that other VMs are still running and consuming other capacity of the PSE server. This may improve the utilization of resources within the PSE by allowing better packaging of the running instances on the physical host, and also provide a seamless experience of instance usage across regions and PSEs.

[0044] In one embodiment, the PSE server may 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. In addition, if the customer needs, the PSE server may host one or more data volumes. In the region, such volumes can be hosted on dedicated block storage servers. However, due to the possibility of having significantly smaller capacity in the PSE than in the region, if the PSE includes such dedicated block storage servers, it may not provide the best utilization experience. Therefore, the block storage service can be virtualized in the PSE so that one of the VMs runs the block storage software and stores the data of the volume. Similar to the operation of the block storage service in the region, the volume within the PSE can be replicated to achieve persistence and availability. The volume can be configured in its own VPC within the PSE. The VM and any volume 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 example components that enable the PSE to continue to operate in the event of a disruption in connectivity back to the region. Examples of these components include a migration manager that can move VMs between PSE servers when 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 control plane of the PSE will generally remain in the region in order to allow customers to use as much of the PSE's capacity as possible. In some embodiments, at least some of the 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 data center.

[0046] In the above manner, the PSE forms an edge location because it provides resources and services of the cloud provider network outside the traditional cloud provider data center and closer to the customer device. The edge location as mentioned herein can be structured in several ways. In some implementations, the edge location can be an extension of the cloud provider network bottom layer, including a limited amount of capacity provided outside the availability zone (e.g., in a small data center of a cloud provider or in other facilities located near the customer workload and possibly far away from any availability zone). Such edge locations may be referred to as local areas (due to being more local or closer to a group of users than traditional availability zones). The local area 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 the region). Although usually the local area will have a more limited capacity than the region, in some cases, the local area may have a 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, the edge location may be a provider-based extension formed by one or more servers located on-premises at a customer or partner facility. The server may communicate with a nearby availability zone or region of a cloud provider network via a network (e.g., a publicly accessible network such as the Internet). This type of provider-based extension may be referred to as a "sentinel" of a cloud provider network. Some outposts may be integrated into a communication network. For example, an outpost may be integrated into a base station within a telecommunications network or co-located with an RU of the network. The limited capacity of an internal outpost may be available only to customers with a 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 send 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 (e.g., at least partially controlled by) the parent availability zone. 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 to operate when disconnected from a 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 a sentinel implementing RAN functionality, or on a separate sentinel. Similarly, in various embodiments, the backhaul network 130 may be implemented partially or completely on a cloud provider network. As described above, the network core 140 provides control plane functionality and performs management and control functions of 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 functions 142, which may control the workload of the distributed unit 114 and may be used to manage the workload of the distributed unit 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 distributed unit 114 to radio unit 112 for delivery to user device 102 according to aspects of the present disclosure. Illustratively, if performed at a time synchronized between distributed unit 114 and 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 too much 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 (eg, 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. The interactions at (1) and (2) are 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 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, etc. 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 result in radio unit 112 resetting the 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 the radio unit), 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 the distributed unit 114 and the radio unit 112 synchronized, the distributed unit 114 must also ensure that it has sufficient capacity to perform the interaction at (1) before each of the times 204A-204D. If the distributed unit 114 falls behind due to excessive workload, it will miss one of its windows for delivering data to the radio unit 112, which may also result in "silence" and inefficient use of computing resources and radio spectrum. Therefore, it is desirable for the distributed unit 114 to manage its workload so that it has sufficient resources to transmit data 202A-202D to the 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 thus 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 thus keeps time to a higher degree of accuracy than distributed unit 114. In some embodiments, distributed unit 114 may select radio unit 112 from multiple 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, the radio unit 112 may provide timing information to the distributed unit 114 without receiving the explicit request at (1). For example, the radio unit 112 may transmit data packets to the distributed unit 114 using the enhanced Common Public Radio Interface ("eCPRI") protocol, and may timestamp the data packets it transmits. In some embodiments, the radio unit 112 may include a network interface card or other component that supports hardware timestamping, and therefore includes a hardware timestamp in the transmitted data packets. The distributed unit 114 may then derive the setting of the radio unit 112 clock from the timestamp. In such embodiments, the interaction at (1) may be omitted, and the 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. Accordingly, 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 such a determination based on factors such as the required estimated accuracy or the amount of time initially allocated for clock synchronization.

[0055] Figure 4 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 correction factors 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 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 elapses on the clock of radio unit 112, 0.9 milliseconds elapse 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 elapses on the clock of radio unit 112, 1.12 milliseconds elapse 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), the distributed unit 114 determines and begins applying a correction factor in order to keep its internal clock consistent with the clock of the radio unit 112. In some embodiments, the correction factor may be an amount of time that is added or subtracted from the clock after each millisecond has passed. For example, the correction factor may be adding 0.1 milliseconds for each millisecond that has passed since the distributed unit 114 clock was last synchronized with the clock, or subtracting 0.12 milliseconds for each millisecond that has passed. In other embodiments, the correction factor may be a multiplier or a percentage. The 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 the radio unit 112. In some embodiments, the interaction at (3) may be omitted or combined with the interaction at (5). For example, the distributed unit 114 may determine at (4) that the clock of the distributed unit 114 is currently 0.11 milliseconds slower than the clock of the radio unit 112, and may begin applying a correction factor of 0.11 milliseconds for each millisecond at (5). Thus, the first application of the correction factor will synchronize the clock of the distributed unit 114 with the clock of the 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 receives 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 clock drift of the distributed unit 114 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 the 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 consider the workload of radio 112 when determining whether and when to send further requests for timing information to radio 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 defer transmitting the request for timing information (or, in some embodiments, may transmit the request for timing information to a different radio) if radio 112 is busy or its performance would otherwise be affected. In further embodiments, distributed unit 114 may identify a radio with sufficient capacity to respond to the request for timing information among multiple radios connected to distributed unit 114, or may distribute the request for timing information to multiple radios based on polling or other algorithms. In other embodiments, radio 112 may periodically send timing information to distributed unit 114 regardless of whether it receives a request from distributed unit 114, and 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 foregoing 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 prior to 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 construed as illustrative rather than restrictive.

[0062] Figure 5 is a flow diagram depicting example interactions for managing the workload of distributed units 114 according to aspects of the present disclosure. These interactions reduce the risk that the workload of distributed units 114 will increase to a level that prevents distributed units 114 from transmitting data to radio units 112 in a timely manner. At (1), distributed units 114 determine a likelihood of missing the next window for transmitting data to radio units 112. As discussed above, the window in which distributed units 114 should transmit data 112 to the radio units precedes the time slot in which the radio units transmit data to user devices 102. In some embodiments, the window may precede the time slot by a fixed amount, which may represent the time required for radio units 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 when the distributed unit 114 will transmit the data 112 to the radio unit. The determination may be based on, for example, historical times when the distributed unit 114 has transmitted data to the radio unit 112, information about the historical workload of the distributed unit 114, information about the current workload of the distributed unit 114, or other information that can be used to estimate the time when the distributed unit 114 will next transmit data. For example, the distributed unit 114 may estimate that the 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 the distributed unit 114 will miss the deadline for transmitting data to the radio unit 112, or by determining a confidence level that the distributed unit 114 will transmit the 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 to reduce the workload of the distributed unit 114 at (3). 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 instead of reducing the 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 determine on its own 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 following interaction may then be performed for the next time slot and the next deadline. Figure 5, and the interactions may be iteratively performed 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 a 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 an average time for the distributed unit 114 to transmit data to the radio unit 112, an average workload metric, a peak workload, a worst 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., that the distributed unit 114 is getting closer to missing a window) and may make the determination at (2) based on these trends.

[0067] It should be understood that Figure 5 is provided for purposes of example, and many variations of the interactions depicted are within the scope of the present 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 construed 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 distributed units 114 are within the scope of the present disclosure. In the illustrated embodiment, the workload of distributed units 114 is caused by access and mobility management function 142 responding to requests from distributed units 114 (e.g., Figure 5 In various embodiments, by rejecting new requests for services from user device 102, by accepting new requests for services but then having different distributed units ( Figure 6The access and mobility management function 142 may reduce the workload of the distributed unit 114 by providing the requested service (not depicted) or by handing off one or more existing services being provided by the distributed unit 114 to a different distributed unit. In other embodiments, the distributed unit 114 may reduce its workload independently of the access and mobility management function 142, as discussed in more detail below.

[0069] In the illustrated embodiment, at (1), one or more user devices 102 request new services 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 transmitted 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 discard 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 discarded 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 request 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 a 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 a 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 a cloud-based server. In further embodiments, 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 may reduce the workload of the distributed unit by throttling the services that the distributed unit 114 is currently providing to the user devices 102. For example, the distributed unit 114 may implement a schedule used by the user devices 102 and may limit the number of fixed time slots (spots) on the schedule that are allocated to one or more user devices 102. In other embodiments, the distributed unit 114 may request the radio unit 112 to identify and hand over the user devices 102 that may be handed over to another radio unit.

[0073] Figure 7 is a diagram according to aspects of the present disclosure for enabling distributed units (e.g., Figure 1 14. The example routine 700 for clock synchronization of the distributed electrical unit 114 depicted in FIG. 14 is a flowchart of an example routine 700 for clock synchronization of the distributed electrical unit 114 depicted in FIG. 14. The routine 700 can be performed, for example, by a timing synchronization module (e.g., Fig. 9) or by another component of the distributed unit. Routine 700 begins at block 702, where timing information can be obtained from the radio. As discussed above, the timing information can be obtained from the radio in response to a request, or in some embodiments, can be obtained from information (e.g., a timestamped packet header) transmitted by the radio without an explicit request. The timing information can include, for example, a hardware timestamp or other timestamp on a packet 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 clock of the distributed unit can be synchronized to the clock of the radio.

[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 thus may require the distributed unit to send data to be transmitted prior to 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 has only been executed 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 applied iteratively. As described in more detail above, the correction factor may be applied periodically (e.g., once every millisecond), as needed (e.g., when the distributed unit has data ready to send), or according to 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 clock of the distributed unit has not drifted significantly from the clock of the radio unit, 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 may 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 clock of the distributed unit to the clock of the radio unit.

[0077] If the determination at decision block 712 is instead 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 been reached. If so, routine 700 branches to block 702, where updated timing information may be obtained from the radio unit, and then iterates through blocks 704 to 714 to keep the clock of the distributed unit synchronized with the clock of the radio unit. If the determination at decision block 716 is that the time determined at block 714 has not been reached, 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 unit 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 been reached or whether local conditions have changed. Routine 700 may then iterate indefinitely to keep the clock of the distributed unit synchronized with the clock of the radio unit.

[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 executed after block 718. As a further example, blocks 702, 704, and 706 may be executed several times before executing decision block 708, or decision block 708 may be executed several times before executing block 710. 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 unit. Still further, in some embodiments, the routine 700 may limit the frequency with which block 702 is executed based on factors such as the workload of the radio unit or the available bandwidth between the radio unit and the distributed units. Thus, Figure 7 It is to be construed 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 power distribution unit 114 as depicted in FIG. 800 may be performed, for example, by a workload management module (e.g., Fig. 9 8) 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, the distributed unit may send data to the radio unit too early (i.e., before the start of the window), but this may generally be prevented by waiting until the intended radio unit is ready to receive the next batch of data. As discussed above, the time available at block 802 may correspond to the start of a radio unit 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 the data.

[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 probability that the distributed unit will transmit data to the radio unit after the deadline may be determined. In some embodiments, the probability may be determined as a percentage or confidence level. For example, the determination may be that the distributed unit has a 5% chance of transmitting 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 these workloads. For example, the distributed unit may identify 20 historical workload instances that are comparable to the current workload of the distributed unit, and may determine, for example, that the distributed unit transmitted data before the deadline in 19 of the 20 instances. As a further example, in some embodiments, the distributed unit may use historical information to determine that its workload has increased over time and that its risk of missing a deadline has also increased over time, but 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 probability of missing a deadline. In other embodiments, a machine learning model trained on historical workloads and historical data transfer times may be applied to the current workload of the distributed units, and the machine learning model may generate as its output the probability of missing a deadline. Additionally, in some embodiments, statistical analysis, trend analysis, and / or machine learning may be used to estimate the probability that a future deadline (e.g., the next following deadline for hitting a time slot, or more generally, any deadline after the deadline obtained at block 802) will be missed, and routine 800 may 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 a 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 accomplished, for example, by executing Figure 6 The process is initiated by the interaction depicted in 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 it is not necessary to reduce the workload of the distributed unit, or after a reduction in workload is initiated at block 810, then 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 deadlines thereafter. In some embodiments, routine 800 may be performed when it is too late to prevent the distributed unit from missing a deadline, and therefore block 812 may be postponed or omitted. For example, routine 800 may be performed as a response to a distributed unit missing a deadline, and it may be determined that the distributed unit will miss more deadlines before its workload can be reduced to a manageable level. In other embodiments, block 812 may be performed immediately after block 802, or in parallel with any or all of blocks 804 to 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 been historically associated with missed deadlines or a workload that represents a relatively high risk of missing deadlines). 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] Fig. 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. Fig. 9 The overall architecture of the distributed unit 114 depicted in FIG. 1 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 Fig. 9 Those more (or fewer) elements shown in . However, it is not necessary to show all of these generally conventional elements in order to provide an enabling disclosure. In addition, Fig. 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, for example, Figure 1 1, 1 12, centralized unit 116, or other components of radio access network 110. Processor 902 may thus receive information and instructions from other computing systems or services. Processor 902 may also provide output information to an optional display (not shown) via input / output device interface 904. 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 a random access memory (RAM), a 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, a CLI, and / or a 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 module 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. Fig. 9 14, but in other embodiments, all or part of the clock 113 may be implemented by other components of the distributed unit 114. For example, in certain embodiments of the present disclosure, the processor 902 may implement some or all of the functionality of the clock 113. The memory 920 may further include a workload management module 928 that can be executed by the processor 902. In one embodiment, the workload management module 928 implements various aspects of the present disclosure, for example, managing the workload of the distributed unit 114.

[0093] Memory 920 may further include radio unit timing information 930, which is described in more detail above and which may be obtained from a radio unit (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 radio via the network interface 906. The memory 920 may further include workload information 934 of the distributed unit 114 and / or one or more radios in communication with the distributed unit 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 radio, workload estimates, historical clock drift, or other information.

[0094] In some embodiments, the distributed unit 114 may further include Fig. 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. Therefore, Fig. 9 It is to be construed 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. A computer-implemented method as described in 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 unit.

[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 including 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 the 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 via 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 unit 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 a 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 the new service to a second distributed unit, the distributed unit transfers the existing service to the second distributed unit, or the distributed unit throttles the existing service.

[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 about 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. A computer-implemented method as described in Clause 28, wherein determining the likelihood that the distributed unit will transmit the first data to the radio unit after the first time includes: 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 unit.

[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 from the AMF for the workload information.

[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 unit.

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

[0171] obtaining workload information about a 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 as recited in 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 that the distributed unit will transmit second data to the radio unit after a second time is determined based at least in part on the updated workload information, 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, allowing the workload of the distributed unit to increase.

[0180] It should be understood that not 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 a software code module 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 module 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] Many other variations in addition to those described herein will be apparent in light of the present disclosure. 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 completely omitted (e.g., not all of the described actions or events are necessary for the practice of the algorithm). In addition, in certain embodiments, actions or events may be performed simultaneously (e.g., by multithreading, interrupt handling, or multiple processors or processor cores or on other parallel architectures), rather than sequentially. In addition, different tasks or processes may be performed by different machines and / or computing systems that can operate together.

[0183] The various illustrative logic blocks and modules described in conjunction 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 an alternative, the processor may be a controller, a microcontroller or a state machine, a combination thereof, or the like. The processor may include a circuit 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 this article is primarily described 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 otherwise be understood within the context as being 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 features, elements, and / or steps in any way, or that one or more embodiments necessarily include logic for deciding, 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 box in the flowchart described herein and / or depicted in the accompanying drawings should be understood to potentially represent a module, segment or portion of code including one or more executable instructions for implementing a specific logical function or element in the process. Those skilled in the art will appreciate that alternative implementations are included within the scope of the embodiments described herein, wherein elements or functions may be deleted, executed in an order different from that shown or discussed, including substantially simultaneously or in 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, phrases such as "a device configured to..." are intended to include one or more of the recited devices. Such one or more recited devices may also be collectively configured to perform the stated 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 the distributed unit with a second clock of the radio unit based on first timing information obtained from 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; 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; 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 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.

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 for obtaining third timing information from the radio unit.

10. A computer-implemented method as described in claim 9, wherein the time to obtain the third timing information 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, the change in the workload of the distributed unit, or the 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 unit.

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 unit comprises: One or more outliers are removed, or weighting factors are applied to one or more of the data points in the timing information.

15. 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.

Images