Distributed unit workload management

Abstract

Systems and methods are described for implementing distributed units in an open radio access network that manage their workloads to reduce the risk of missing radio unit slots. A distributed unit may receive data from a centralized unit and transmit the data to a radio unit, which may transmit the data to a user device during a fixed time slot. Thus, the distributed unit must transmit data to the radio unit for delivery during each time slot to prevent'dead 'and potential connectivity issues. Thus, the distributed unit monitors its workload, determines whether its risk of missing a window for transmitting data to the radio unit satisfies a criterion, and then reduces its workload if necessary until the criterion is no longer satisfied. The distributed units may communicate with access and mobility management functions or other network components to facilitate workload management.

Description

Background Art

[0001] In general, computing devices can be used to exchange information over a network. Computing devices can utilize wireless networks provided by service providers to facilitate information exchange according to one or more wireless communication protocols. For example, a service provider can maintain a wireless network that enables mobile computing devices to exchange information according to a fourth generation wireless telecommunications protocol, such as the Long Term Evolution ("LTE") protocol. A wireless network can be composed of separate network components, such as a radio unit that transmits and receives radio signals within a specific 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, a radio unit can receive data from a distributed unit and transmit the data to a 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 illustrating 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, in accordance with aspects of the present disclosure.

[0004] Figure 2 is a flow chart 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 in accordance with 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 in accordance with 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 in accordance with 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 in accordance with aspects of the present disclosure. DETAILED DESCRIPTION

[0012] In general, 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 a distributed unit (e.g., an open radio access network) in a radio access network ("RAN") by synchronizing its clock with one or more radio units of the radio access network and managing its workload to ensure that it does not miss a time slot for transmitting data to a radio unit of the RAN.

[0013] The functionality of a RAN may be dispersed among various elements, such as a radio unit ("RU"), a distributed unit ("DU"), and a centralized unit ("CU"). A RU 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 time windows and at specified frequencies, etc. The RU 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 for different geographic areas, which may partially overlap with areas of adjacent RUs to facilitate handover and provide seamless communication. A DU may generally receive data from a CU for delivery to a RU (and vice versa), and may process the data to encode or decode it, modulate or demodulate it, add or remove error correction or redundancy, or otherwise prepare data received from a CU for transmission by the RU over the air, and vice versa. The functions implemented by the DU may include some layer 1 functions, such as encoding the digital signals to be transmitted by the RU, adding redundancy and error correction codes to the digital signals, mapping the transport channels to the physical channels, etc. In some embodiments, the DU may include dedicated hardware for performing layer 1 functions, such as an accelerator card that performs signal processing functions. The DU may also implement some "layer 2" (which may be referred to as "L2" in this article) functions, such as mapping logical channels to transport channels, determining the timing of RU digital signal transmission within a timing window, etc. Subsequently, the CU may implement "layer 3" ("L3") functions, such as mediating access to external networks, authorizing access to the RAN, etc.

[0014] Thus, the distributed unit may receive data from the centralized unit, which may then be transmitted 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 may then 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" herein). Therefore, it may be important that the clocks of the distributed unit and the radio unit are synchronized so that communication occurs at the appropriate time. Timing synchronization in a cellular network may be an important element of the system, not only enabling the system to operate properly, but also achieving increasing data rates while reducing latency, such as in a 5G network. 5G cellular systems have particularly stringent synchronization requirements at the RAN end and the device end. To meet 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 protocols such as the Precision Time Protocol ("PTP"). PTP is designed to provide nanosecond accuracy for time synchronization.

[0015] However, not all 5G components may require or be able to obtain such high levels of precise timing. In some embodiments, the DU may run on edge hardware of a cloud provider network provided to a customer site that requires a 5G network, and multiple such DUs may be located at convenient locations within the site (e.g., in a temperature-controlled room). Depending on the required 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 crucial because the RU is a component that sends electromagnetic waves to the UE over the air interface. Nanosecond accuracy may not be necessary for the DU that provides digital processing of received and transmitted data. However, the DU must generate data to be transmitted by the RU at each time slot boundary. The time slot duration depends on the subcarrier spacing, and in some implementations, the time slot duration is typically 1ms. Due to the tight integration between the DU and the RU, it may be desirable to have GPS provide timing information for the DU. However, in 5G network deployments, it may be costly to have a GPS receiver on each DU, and this may also increase installation costs due to the need to connect a GPS antenna to a place with good GPS signal coverage, because the DU may be located in indoor facilities with relatively poor GPS signal quality (or no signal at all). Additionally, PTP typically requires specialized hardware support to achieve nanosecond accuracy. For example, PTP may rely, at least in part, on hardware-based timestamping of data transmissions. This requirement hinders the ability to use general-purpose hardware in DUs and further increases their cost. An alternative to PTP is the Network Time Protocol (“NTP”), but NTP has an accuracy in the 1-10 millisecond range, which may be unacceptable in some cases. For example, this range may be incredibly wide compared to typical time slot durations, especially for high-speed technologies such as 5G networks.

[0016] Thus, in some embodiments, these elements of the RAN may rely on different sources of timing information with different reliability levels, 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 in 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 point where the DU misses the time slot boundary at which it must deliver data to the RU. This may be the result of a slow drift of the DU's internal clock due to an inaccurate (relative to PTP) local oscillator crystal or the temperature response of the crystal. When the DU does not provide the necessary data to the RU, dead silence may occur on the system because the RU does not receive any time data in time to transmit within a particular time slot. In this case, 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 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 limited bandwidth between RU and DU, including initial time synchronization and duration 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 can request timing information from the RU at fixed intervals relative to its own clock over a period of time. This interval can be configured at both the RU and the DU, or the DU can actively request timing information from the RU based on its own time. The RU can respond with a packet containing the requested timing information, and if the RU has hardware marking capabilities, these packets can be hardware marked. The DU can then estimate its own clock drift based on the response from the RU. Allocating a longer time duration for this time synchronization and transmitting a larger number of packets can improve the accuracy of this estimate. The specific implementation method can weigh the increased estimation accuracy against the increased amount of time required for synchronization to achieve the desired balance.

[0018] For ongoing time synchronization, a procedure similar to that for initial time synchronization may continue during RAN operation. In ongoing time synchronization, an additional consideration in determining the frequency and duration of timing synchronization is that the request / response consumes bandwidth between the RU and the DU that would otherwise be used for data packet transmission, and may therefore affect the overall performance of the system in terms of the amount of data that can be sent and received from the UE. To alleviate this problem, in implementations that include multiple RUs connected to the same DU (e.g., for redundancy, increased regional 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 a round-robin match or based on an analysis of the load on the RU. Another solution is to have the RU send data packets containing timing information (and which may be hardware-marked) at regular intervals (such as time slot boundaries) and have the DU extract the 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, which may cause the amount of clock drift to become less predictable. Therefore, when a DU's clock drift is less consistent, the DU may request timing synchronization more frequently, and when the DU's workload and other factors make its clock drift predictable, the DU may request timing synchronization less frequently.

[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 it from sending data to the RU in a timely manner so that the RU can transmit the data in the next time slot. In addition to transmitting data to the RU, the DU usually has to perform other tasks. For example, when the data is generated and uploaded by the UE, the distributed unit receives and processes the data from the radio unit. As another example, the DU may receive more data from the CU than it can process in a single time slot. Therefore, the DU may not be able to transmit the data to the RU in a timely manner, resulting in "dead silence" (time slots without data transmission), reduced utilization efficiency of the RU and radio spectrum, and poor 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 with 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 a single 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 in a specified time slot. The time slot can start at any time based on the internal clock of the radio unit. For example, the radio unit can deliver data to the user device in each time slot that lasts for a millisecond 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 its clock by obtaining timing information from a satellite. For example, the radio unit can obtain timing information from a GPS satellite, which can provide highly accurate timing information, thereby allowing each radio unit to maintain consistent time. This then allows the radio unit to accurately determine the start and end of each time slot that sends data to the user device.

[0021] In order to transmit data to a user device in each of its time slots, the radio unit must receive the data to be transmitted from the distributed unit before the start of the time slot. Therefore, the distributed unit may be required to also maintain consistent and accurate time in order to determine the start of each radio unit time slot and deliver data to the radio unit before that time. However, the distributed unit may not have the ability to obtain timing information from the satellite. The radio unit is typically located near the antenna of a cellular tower and has the necessary equipment and programming for receiving and processing radio signals from the satellite. The distributed unit may be located at 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 the satellite.

[0022] Therefore, the clock of the distributed unit may not be as accurate 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 maintained by the component may vary depending on factors such as the temperature of the crystal. Thus, if the clock of the distributed unit "drifts" and maintains a slower or faster time than the clock of the radio unit, the drift will eventually cause the distributed unit to miss the time slot for sending data to the radio unit, or send more data than the radio unit can transmit in a given time slot. These results are undesirable because they can cause "dead silence" (time slots with no data transmission) or cause lost data packets that must be retried and retransmitted. In some embodiments, the radio unit may have a limited capacity to buffer data received too early from the distributed unit, which can allow the radio unit to temporarily compensate the distributed unit using a faster time than the radio unit clock. However, a distributed unit with a clock speed that is too fast 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 with the distributed unit, which may cause one or more user devices to stop receiving data for a longer duration.

[0023] In addition, in addition to transmitting data to the RU, the DU has other tasks to perform, which may prevent the DU from transmitting data to the RU in a timely manner if the DU workload is large enough. For example, when data is generated and uploaded by the UE, the DU receives and processes data from the RU. As another 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 not be able to transmit data to the RU in a timely manner, which may in turn lead to "dead silence" and inefficient use of the RU and radio spectrum.

[0024] To address these issues, the operator of the radio access network can implement a distributed unit that performs timing synchronization and manages its workload, as described herein. As discussed in more detail below, the distributed unit described herein can synchronize its clock with the radio unit by obtaining timing information from the radio unit, can determine whether its clock drifts relative to the radio unit and the degree of drift, and can apply a correction factor to keep its clock synchronized. The correction factor can be dynamically adjusted as the amount of clock drift changes (e.g., due to changes in the workload of the distribution unit, changes in the temperature of the distribution unit, etc.), and the distribution unit can determine the frequency of synchronization of its clock with the radio unit based on factors such as the workload of the radio unit, the variability of the clock drift, and other criteria. In addition, the distributed unit described herein can assess the risk that its workload will cause it to miss the window for transmitting data to the radio unit, and if the distributed unit is likely to be unable to transmit data in time, then preventive measures can be taken to reduce its workload and mitigate the risk. In various embodiments, the distributed unit can, for example, offload processing tasks to another distributed unit, limit or postpone connections from a radio unit or a centralized unit, or cause the radio unit to limit or postpone connections.

[0025] It should be understood that the techniques described herein solve technical problems that arise particularly in the field of computer networks, and specifically solve problems that arise in the field of radio access networks in the following situations, when the distributed unit cannot access GPS-based timing information (or, more generally, when the distributed unit cannot access 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 transmitting data to the radio unit in a timely manner. It should also be 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 dead 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, thereby preventing "dead 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 refers to 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 refers to 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 also be understood that the present disclosure is not limited to a specific source of precise timing information such as GPS. For example, the RU may obtain timing information from satellites other than GPS satellites or from a land-based 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 the 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 provides 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, communication between the user device 102 and a server or other computing device on the Internet.

[0029] In general, user device 102 can be any device that can 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, etc. Illustratively, air interface 104 can be an air interface to any wireless network, including but not limited to a cellular telecommunications network, a Wi-Fi network, a mesh network, a personal area network, or any combination thereof. In some embodiments, air interface 104 can be an interface to a global system for mobile communications (GSM) network, a code division multiple access (CDMA) network, a long term evolution (LTE) network, or a combination thereof. Satellite 122 can generally be any satellite that provides accurate timing information to a land-based device via a 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 their radio frequencies for communicating with land-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, in some embodiments, may be set to the current absolute time).

[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 generally be any receiver capable of receiving 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. As a result, the radio unit 112 may deliver data to the user device 102 at precise intervals, which may mitigate or prevent radio interference caused by multiple radio units 112 transmitting 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 acts 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] Reference below Figure 6Describing the distributed unit 114 in more detail, the distributed unit 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 in 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 functions 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] The centralized unit 116 is responsible for the network layer functions of the radio access network 110 and provides communication with other computing devices through the backhaul network 130 and the network core 140. Illustratively, the backhaul network 130 can be any wired or wireless network or a combination thereof. In addition, the 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 wired 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, the 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 dispersed to modular components that provide different functions and can be sourced 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 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" wins and loses. The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to variable loads. Therefore, cloud computing can be considered as both: applications delivered as services over a public accessible network (e.g., the Internet, a cellular communication network) and the hardware and software in a cloud provider data center that provides these services.

[0034] The cloud provider network provides users with an on-demand scalable computing platform over the network, for example, allowing users to have scalable "virtual computing devices" for their use through their use of computing servers (which provide computing instances via one or both of a central processing unit (CPU) and a graphics processing unit (GPU), optionally in conjunction with local storage devices) and block storage servers (which 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 devices), operating system selection, network capabilities, and pre-loaded application software. Each virtual computing device can also virtualize its console input and output (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 a personal computing device. 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 depending on 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 to enable customers 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 can 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 a region is a separate geographic area in which the cloud provider clusters data centers. Each region can include two or more availability zones connected to each other through a private high-speed network, such as 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 can be co-located in other network provider facilities (e.g., an Internet service provider, a telecommunications provider). For redundancy, two TCs can be operated per region.

[0036] The cloud provider network can include a physical network (e.g., sheet metal boxes, cables, rack hardware) called the underlay. You can think of the underlay as the network fabric that contains the physical hardware that runs the provider network's services. The underlay can be isolated from the rest of the cloud provider network, for example, it may not be possible to route from an underlay network address to an address in the production network 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 simultaneously 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 within 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 via 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 cloud 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. The data plane represents the movement of user data through a distributed computing system, while the control plane represents the movement of control signals through a distributed computing system. The control plane typically includes one or more control plane components distributed across and implemented by one or more control servers. Control plane traffic typically 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, and provisioning additional hardware as needed. 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 typically includes non-management operations, such as transmitting data to and from customer resources.

[0040] As shown, 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 a cloud provider network. Providers 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. An 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 devices), network resources (e.g., the characteristics of its network interface and / or network capabilities), and / or other suitable descriptive characteristics. Using 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 for 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 techniques described herein enable 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] PSE can be pre-configured with a suitable combination of hardware and software and / or firmware elements by the provider network operator, for example, to support various types of computing-related resources, and to do so in a way that reflects the experience of using the provider network. For example, one or more PSE servers can be prepared in the customer network by the cloud provider. As described above, the provider network can provide a collection of predefined instance types, each instance type having different types and quantities of lower-level hardware resources. Each instance type of various sizes can also be provided. In order to enable customers to continue to use the same instance type and size used in their PSE as they do in the region, the PSE server can be a heterogeneous server. Heterogeneous servers can support multiple instance sizes of the same type at the same time, and can also be reconfigured to host any instance type supported by its lower-level hardware resources. The reconfiguration of heterogeneous servers can be performed instantly using the available capacity of the PSE server, which means that other VMs are still running and consuming other capacities of the PSE server. This can improve the utilization of resources within the PSE by allowing better packaging of instances running on physical hosts, and also provide a seamless experience of instance use across regions and PSEs.

[0044] In one embodiment, the PSE server can host one or more VMs. Customers can use these virtual machines 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 can 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 at the PSE than in the region, if the PSE includes such dedicated block storage servers, it may not be possible to 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 volumes within the PSE can be replicated to achieve persistence and availability. These volumes can be provisioned within its own VPC within the PSE. 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 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 PST servers if necessary 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 via the customer network. However, in general, the control plane of the PSE will remain in the region 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 function even during periods of time when connectivity to the provider network data center is temporarily interrupted.

[0046] In the above manner, PSE forms edge locations because it provides resources and services of cloud provider network outside traditional cloud provider data center and closer to customer device. Edge locations as mentioned herein can be structured in a variety of ways. In some implementations, edge locations can be an extension of cloud provider network bottom layer, including a limited amount of capacity provided outside the available area (e.g., in a small data center of a cloud provider or located near customer workload and possibly away from other facilities in any available area). Such edge locations can be referred to as local areas (due to being more local or closer to a group of users than traditional availability zones). Local areas can be connected to publicly accessible networks such as the Internet in various ways (e.g., directly, via another network or via a private connection with a region). Although usually local areas can have more limited capacity than a certain area, in some cases, local areas can have considerable capacity, such as thousands or more racks.

[0047] In some embodiments, all or part of the radio access network 110 may be implemented on edge location hardware, which may be physically closer to devices such as RUs and UEs, for example. In some embodiments, the edge location may be a provider substrate extension formed by one or more servers located within 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 bottom layer 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 the RU of the network. The limited capacity of an internal outpost may be available only to customers who own the premises (and any other accounts permitted by the customer). Similarly, the limited capacity of an outpost integrated into a cell network may be shared between multiple applications (e.g., games, virtual reality applications, healthcare applications) that send data to users of the telecommunications network. The outpost integrated into the telecommunications network may also include data plane capacity, which may be controlled at least in part by a control plane implemented in a nearby availability zone of the cloud provider network. Thus, an availability zone group may include a "parent" availability zone and any "child" edge locations that are subordinate to the parent availability zone (e.g., at least partially controlled by its control plane). Certain limited control plane functionality (e.g., features required for low-latency communication with customer resources, and / or features that enable edge locations to continue to operate when disconnected from the parent availability zone) may also exist in some edge locations.

[0048] Thus, the radio access network 110 can communicate with a network core 140, which in various embodiments is implemented on a nearby availability zone of a cloud provider network, an internal edge location, another edge location, or other network-accessible computing resources. For example, the network core 140 can be implemented using spare capacity of a sentinel that implements RAN functions, or on a separate sentinel. In various embodiments, the backhaul network 130 can similarly be implemented in part or in whole on a cloud provider network. The network core 140 provides control plane functions (as described above) and performs management and control functions of the telecommunications network, such as authenticating users, 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 can control the workload of the distributed unit 114 and can be used to manage the workload of the distributed unit 114, as described in more detail below. In some embodiments, the network core 140 can support multiple RANs, and can also support RANs from multiple tenants or customers. In other embodiments, the network core 140 can be implemented on dedicated computing resources of a specific wireless network operator, which can be provided within the premises or within the 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 More (or fewer) components than those depicted in the drawings may be included. However, it is not necessary to show all of these typically conventional elements in order to provide a feasible disclosure.

[0050] Figure 2 is a flow chart depicting an example interaction for transmitting data from the distributed unit 114 to the radio unit 112 for delivery to the user device 102 according to aspects of the present disclosure. Illustratively, Figure 2 The interaction depicted in, if performed at a time when synchronization is performed between the distributed unit 114 and the radio unit 112 using the techniques described herein, allows the distributed unit 114 to supply data to the radio unit 112 at a rate that allows each of the time slots 206A-D to be utilized without providing too much data or failing to provide data for one of the time slots 206A-D. 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 beginning 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 radio unit 112 can deliver the data to the user device 102 in a timely manner during time slot 206A. In some embodiments, time 204A may be earlier than 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 the data 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 for data 202C, time 204C, and time slot 206C, further for data 202D, time 204D, and time slot 206D, and so on, repeating 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 the distributed unit 114 "drifts" relative to the clock of the radio unit 112, such that, for example, 1.0 milliseconds have passed on the clock of the distributed unit 114 while 1.1 milliseconds have passed on the clock of the radio unit 112, the net result will be that the distributed unit 114 misses one of its windows for delivering data to the radio unit 112. Missing this window may result in a "dead silence" during which the radio unit 112 does not deliver data to the user device 102, and in some embodiments, may cause the radio unit 112 to reset the connection with the distributed unit 114 or the user device 102, which may further disrupt the delivery of data to the user device 102. Similarly, if the clock of the distributed unit 114 is faster than the clock of the radio unit 112 (e.g., if 1.0 milliseconds have passed on the clock of the distributed unit 114 while 0.9 milliseconds have passed on the clock of the radio unit), the distributed unit 114 may send more data than the radio unit 112 can transmit or buffer during one of the time slots 206A-D. 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-D. If the distributed unit 114 falls behind due to excessive workload, it will miss one of the windows for delivering data to the radio unit 112, which may again result in "dead air" and inefficient use of computing resources and radio spectrum. Therefore, it is desirable that the distributed unit 114 manage its workload so that it has sufficient resources to transmit the data 202A-D to the radio unit 112 in a timely manner, which can be achieved using the techniques described herein.

[0053] Figure 31 is a flow chart depicting example interactions for initially setting the clock of distributed unit 114 in accordance with 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 maintains a higher degree of accuracy than distributed unit 114. In some embodiments, distributed unit 114 may select radio unit 112 from a plurality of radio units with which it communicates, and may select radio unit 112 based on factors such as radio unit workload (e.g., by selecting radio unit 112 as the "least busy" unit in a group of radio units). At (2), radio unit 112 provides the requested timing information, and distributed unit 114 uses the 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 an 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 may therefore include 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 an embodiment, 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. Thus, distributed unit 114 may set its clock to compensate for the time delay (e.g., by setting its clock "ahead" of radio 112 by the amount of the time delay). In some embodiments, distributed unit 114 may repeatedly perform the interactions at (1) and (2) (e.g., within a specified time period) before performing the interaction at (3), and may initially set its clock based on multiple responses to the timing information request (and, in some embodiments, determine an initial correction factor as described below). In other 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 this determination based on factors such as the desired estimated accuracy or the amount of time initially allocated for clock synchronization.

[0055] Figure 4 1 is a flow chart depicting example interactions for aligning the clock of distributed unit 114 with the clock of radio unit 112 and for determining a synchronization frequency and applying a correction factor to the frequency of the clock of distributed unit 114 in accordance with aspects of the present disclosure. As discussed in more detail above, synchronizing the clock of distributed unit 114 with the clock of radio unit 112 enables timely delivery of data from distributed unit 114 to radio unit 112, enabling radio unit 112 to fully utilize its available time slots to transmit data to user device 102 and not receive more data than it can transmit during a time slot. At (1), the distributed unit may again request timing information from radio unit 112. In some embodiments, as described above, the interaction at (1) may be omitted, and radio unit 112 may provide timing information without an explicit request. At (2), radio unit 112 provides the requested timing information, and at (3), the 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 timestamps, 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 is drifting 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 runs slower than the clock of radio unit 112, such that for every 1.0 millisecond that passes by the clock of radio unit 112, 0.9 milliseconds pass by the clock of distributed unit 114. As another example, distributed unit 114 may determine that its clock runs faster, such that for every 1.0 millisecond that passes by the clock of radio unit 112, 1.12 milliseconds pass by 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 other 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 to bring its internal clock into line with the clock of the radio unit 112. In some embodiments, the correction factor may be the amount of time that is added or subtracted from the clock after each millisecond has passed. For example, the correction factor may be an amount of time that is added or subtracted from the clock after each millisecond has passed since the last clock synchronization. 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 every millisecond at (5). Thus, the first application of the correction factor synchronizes 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 timing information obtained at (2) before or after applying the correction factor.

[0058] At (6), the distributed unit 114 may determine when to send additional timing information requests 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 additional timing information requests 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 how the workload of the distributed unit 114 changes 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 defer sending its next timing information request 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 timing information request may be triggered by an event, such as processor utilization exceeding a threshold, or may be based on the estimated reliability of a correction factor. For example, if the correction factor is determined based on an average of multiple drift measurements, the reliability of the correction factor may be estimated based on the standard deviation of the drift measurements.

[0059] In some embodiments, distributed unit 114 may consider the workload of radio unit 112 when determining whether and when to send additional timing information requests to radio unit 112. For example, distributed unit 114 may consider whether the timing information request will consume bandwidth that would otherwise be used for data packet transmission, and may postpone transmitting the timing information request (or, in some embodiments, transmit the timing information request to a different radio unit) if radio unit 112 is busy or its performance will be affected. In other embodiments, distributed unit 114 may identify a radio unit with sufficient capacity among multiple radio units connected to distributed unit 114 to respond to the timing information request, or may distribute the timing information request to multiple radio units on a round-robin or other algorithmic basis. In other embodiments, radio unit 112 may periodically send timing information to distributed unit 114 regardless of whether it receives a request from distributed unit 114, and distributed unit 114 may determine when to issue the request at (6) only when the periodic reception interval of the timing information is long enough that the clock of distributed unit 114 may desynchronize during the period. In other embodiments, radio unit 112 may periodically send timing information more frequently than required by distributed unit 114, and distributed unit 114 may determine at (6) which of the periodically received timing information to process and which to discard.

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

[0061] It should be understood that Figure 4 is 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 yet another example, the interactions at (1), (2), (3), and (4) may be performed multiple times before the interactions at (5) and (6) are performed, and the correction factor determined and applied at (5) may be based on an average clock drift measured over multiple times. Furthermore, in some embodiments, the correction factor and the time to make the next timing information request may be determined based on factors other than the current clock drift, such as a predicted workload or an operating temperature trend of a processor of distributed unit 114. Thus, Figure 4 It is to be construed as illustrative rather than restrictive.

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

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

[0064] At (2), distributed unit 114 may determine whether the likelihood meets a threshold. For example, distributed unit 114 may determine whether the estimated time at which the data will be transmitted is within a threshold time interval (e.g., 50 nanoseconds) of the end of the window. As another 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 that the data transmission window will be missed.

[0065] In embodiments where it is determined at (2) 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 8As described in more detail, the access and mobility management function 142 can reduce the workload of the distributed unit 114 by rejecting or redirecting (e.g., redirecting to another distributed unit 114) new service requests from the user device 102. In some embodiments, the distributed unit 114 can alternatively reduce its own workload by rejecting new service requests from the user device 102, limiting the services provided to the user device 102 (e.g., limiting data throughput), causing existing services to be switched to another distributed unit 114, or otherwise modifying its workload. In other embodiments (e.g., cloud computing environments), the distributed unit 114 can obtain additional computing resources and increase its capacity rather than reducing 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), distributed unit 114 transmits the data to 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 distributed unit 114 meets the deadline for transmitting data to radio unit 112. At (5), radio unit 112 may transmit the data received from distributed unit 114 to one or more user devices 102 during the time slot. Then, Figure 5 The interactions depicted in (1) may be implemented for the next time slot and the next deadline, and may be implemented iteratively while the distributed unit 114 remains in service. In some embodiments, the interactions at (1), (2), and (3) may be implemented less frequently than the interactions at (4) and (5). For example, the interactions at (1) and (2) may be implemented once for every ten interactions at (4) and (5), and if it is determined at (2) that the distributed unit 114 is at an unacceptably high risk of missing the deadline for transmitting data to the radio unit 112, the interaction at (3) may be implemented as needed. In some embodiments, the distributed unit 114 may make the determination at (1) based on the average time for the distributed unit 114 to transmit data to the radio unit 112, the average workload metric, the peak workload, the worst time, or other measurements collected and aggregated over multiple time slots. In other embodiments, the distributed unit 114 may identify trends in the data collected over multiple time slots (e.g., the distributed unit 114 is getting closer to a miss window) and may make the determination at (2) based on these trends.

[0067] It should be understood that Figure 5is provided for example purposes, and many variations on the interactions depicted are within the scope of the present disclosure. For example, the interaction at (3) may be implemented 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 yet another example, distributed unit 114 may determine whether it is possible to increase its capacity rather than request a workload reduction, 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 unit 114 are within the scope of the present disclosure. In the illustrated embodiment, in response to a request from distributed unit 114 (e.g., Figure 5 The access and mobility management function 142 can reduce the workload of the distributed unit 114 by rejecting the new service request from the user device 102, by accepting the new service request but then having a different distributed unit ( Figure 6 The distributed unit 114 may be configured to reduce the workload of the distributed unit 114 by providing the requested service (not depicted) or by switching one or more existing services being provided by the distributed unit 114 to a different distributed unit. In other embodiments, as discussed in more detail below, the distributed unit 114 may reduce its workload independently of the access and mobility management function 142.

[0069] In the illustrated embodiment, at (1), one or more user devices 102 request 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 service request 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 approves the request, rate-limited or otherwise restricted 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 5 In some embodiments, the access and mobility management function 142 accepts the request from the user device 102, but instructs the user device 102 to switch to a different distributed unit (e.g., a unit that is not at risk of missing the data transmission window). In some embodiments, the access and mobility management function 142 may continue to reject or switch requests from the user device 102 until it receives a message from the distributed unit 114 indicating that its workload has been reduced to an acceptable level and that its likelihood of missing the data transmission window no longer meets the threshold. In other embodiments, the access and mobility management function 142 may reject or switch requests from the user device 102 at fixed intervals each time it receives a workload reduction request from the distributed unit 114, or may directly or indirectly monitor the workload of the distributed unit 114 and determine on its own whether the workload has been reduced to an acceptable level. For example, the distributed unit 114 may transmit workload information and other status information to a server in the cloud provider network, and the access and mobility management function 142 may monitor the workload of the distributed unit 114 by obtaining workload information from the cloud-based server. In another embodiment, the access and mobility management function 142 may be performed by obtaining and analyzing workload data from servers in the cloud provider network. Figure 5 and Figure 6 Various other interactions depicted in .

[0072] In some embodiments, as discussed above, the distributed unit 114 can reduce its workload by limiting the services currently provided by the distributed unit 114 to the user devices 102. For example, the distributed unit 114 can implement a schedule for use by the user devices 102 and can limit the number of spots on the schedule that are allocated to one or more user devices 102. In other embodiments, the distributed unit 114 can request that the radio unit 112 identify and hand off the user device 102 that can be handed off to another radio unit.

[0073] Figure 7 is a diagram illustrating a method for synchronizing distributed units (eg, Figure 1 14). The routine 700 may be executed, 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 unit. As discussed above, the timing information can be obtained from the radio unit in response to a request, or in some embodiments, can be obtained from information transmitted by the radio unit (e.g., a packet header with a timestamp) without an explicit request. The timing information may include, for example, a hardware timestamp or other timestamp on a packet transmitted by the radio unit, GPS information received by the radio unit, or other information that enables synchronization with the clock of the radio unit. At block 704, the clock of the distributed unit can be synchronized with the clock of the radio unit.

[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 a scheduled time slot, and thus may require the distributed unit to send the data to be transmitted before each time slot arrives. 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, it may be determined whether the clock of the distribution unit has drifted relative to the clock of the radio unit. If this determination cannot be made because routine 700 does not have enough timing information (e.g., because block 702 has only been implemented once), routine 700 may branch to block 702 and obtain additional timing information from the radio unit. If it is determined at decision block 708 that the clock of the distribution unit has drifted, a correction factor may be determined and applied iteratively at block 710. As described in more detail above, the correction factor may be applied periodically (e.g., once per 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 it is determined at decision block 708 that the clock of the distribution unit has not drifted significantly from the clock of the radio unit, then at decision block 712 it can be determined whether the workload, temperature, or other local conditions of the distribution unit have changed in a manner that may cause the amount of clock drift to change. In some embodiments, a machine learning model can be trained based on historical clock drift information and used to predict expected clock drift. In such embodiments, it can therefore be determined at decision block 708 whether the machine learning model has sufficient confidence in its prediction. If it is determined at decision block 708 that local conditions have changed and / or the amount of clock drift cannot be predicted with confidence, the routine 700 returns to block 702, obtains updated timing information from the radio unit, and resynchronizes the clock of the distribution unit with the clock of the radio unit.

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

[0078] At decision block 716, it may be determined 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 synchronize the clock of the distributed unit with the clock of the radio unit. If it is determined at decision block 716 that the time determined at block 714 has not yet been reached, the distributed unit may rely on its current correction factor to compensate for any clock drift at block 718, and may transmit data to the radio unit for delivery to the user device during the next data transmission window. In some embodiments, decision block 716 may be combined with decision block 712, and it may be determined whether the time determined at block 714 has been reached or whether local conditions have changed. Routine 700 may then iterate indefinitely to synchronize the clock of the distributed unit with the clock of the radio unit.

[0079] It should be understood that Figure 7 is provided for purposes of example, and many variations on the illustrated routine 700 are within the scope of the present disclosure. For example, decision block 716 may be implemented after block 718. As yet another example, blocks 702, 704, and 706 may be implemented multiple times before decision block 708 is implemented, or decision block 708 may be implemented multiple times before block 710 is implemented. As yet another 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. Furthermore, in some embodiments, the routine 700 may limit the frequency with which block 702 is implemented 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 illustrating a method for managing distributed units (e.g., Figure 1 14). The routine 800 may be executed, for example, by a workload management module (e.g., Fig. 98) or by another component of the distributed unit. Routine 800 begins at block 802, where a time at which data must be transmitted to the radio unit so that the radio unit can utilize its next data transmission window can be obtained. In various contexts herein, this time may be referred to as the end of a "deadline" or "window." Illustratively, the distributed unit may send data to the radio unit prematurely (i.e., before the window begins), but this can typically be prevented by waiting until the radio unit is expected to be ready to receive the next batch of data. As discussed above, the time available at block 802 may correspond to the beginning of the radio unit's data transmission window, and in some embodiments, may be offset from the window by an amount of time corresponding to the time required for the radio unit to receive and process the data before transmitting the data.

[0081] At block 804, workload information for the distributed units may be obtained. As discussed in more detail above, the workload information may include metrics such as memory usage, processor usage, processor temperature, and information about work performed by the distributed units, such as the number of services provided, the amount of data sent 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, it may be determined that the distributed unit has a 5% chance of transmitting data to the radio unit after the deadline. In some embodiments, this 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 another 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 the deadline has also increased over time, but it may be understood that in many embodiments, the risk of missing the 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 the deadline. In other embodiments, a machine learning model trained on historical workloads and historical data transfer times can be applied to the current workload of the distributed unit and can generate as its output the probability of missing a deadline. Additionally, in some embodiments, statistical analysis, trend analysis, and / or machine learning can be used to predict the probability that a future deadline (e.g., a deadline that arrives at the next later time slot, or more generally, any deadline after the deadline obtained at block 802) will be missed, and routine 800 can use this prediction to proactively begin reducing the workload of the distributed unit before the future deadline arrives.

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

[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, the likelihood or confidence level that a distributed unit will meet a deadline may be determined, rather than the likelihood or confidence level that a distributed unit will miss a deadline.

[0085] At decision block 808, it is determined whether the probability that the distributed unit will miss the deadline meets a threshold. In some embodiments, it may be determined whether the probability of missing the deadline is above a threshold (e.g., 2%). In other embodiments, it may be determined whether the difference 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 probability from meeting the threshold may be quantified based on, for example, the size of the delta or the amount by which the probability exceeds the threshold.

[0086] If it is determined at decision block 808 that the likelihood meets the threshold (and therefore, the workload of the distributed unit should be reduced), then a process for reducing the workload of the distributed unit may be initiated at block 810. For example, this may be accomplished by executing Figure 6 The process is initiated by the interaction depicted in and causing the access and mobility management function to reject new service requests 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 implemented over time, and is generally completed after the routine 800 continues to block 812.

[0087] If it is determined at decision block 808 that the workload of the distributed unit does not need to be reduced, or after workload reduction is initiated at block 810, routine 800 continues to block 812, where data can be transmitted to the radio unit before the deadline obtained at block 802. Routine 800 then returns to block 802 and iterates to the next deadline for transmitting data to the radio unit and the deadline thereafter. In some embodiments, routine 800 can be implemented when it is too late to prevent the distributed unit from missing a deadline, and thus, block 812 can be postponed or omitted. For example, routine 800 can be implemented as a response to a distributed unit missing a deadline, and it can 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 can be implemented 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 implemented more frequently than other blocks of routine 800. For example, the workload information obtained at block 804 may be aggregated or averaged over several data transfer windows, and routine 800 may "spot check" every ten windows. As yet another example, blocks 806 and 808 may be implemented only when the workload information obtained at block 804 indicates that the workload of the distributed unit is relatively high (e.g., a workload that has historically been associated with missed deadlines or indicates a relatively high risk of missed deadlines). Thus, it should be understood that Figure 8 Provided for purposes of example, 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 (referred to 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 general 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 with physical electronic devices, as discussed in more detail below. The distributed unit 114 may include more than Fig. 9 There may be more (or fewer) elements than those shown in the drawings. However, it is not necessary to show all of these generally conventional elements in order to provide a feasible disclosure. In addition, Fig. 9 The overall architecture shown in can be used to implement Figure 1 One or more of the other components shown.

[0090] As shown, the distributed unit 114 includes a processor 902, an input / output device interface 904, a network interface 906, and a data storage area 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 The processor 902 may also provide output information to an optional display (not shown) via the input / output device interface 904. The input / output device interface 904 may also accept input from an optional input device (not shown).

[0091] The memory 920 may contain computer program instructions (which are 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 used by the processor 902 in the general management and operation of the distributed unit 114. The memory 920 may also include computer program instructions and other information for implementing various 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 it) 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 conjunction with the interface module 924, the memory 920 may include a timing synchronization module 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 functions of the clock 113. The memory 920 may also include a workload management module 928 that may 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 also include radio unit timing information 930, which is described in more detail above and may be obtained from a radio unit (e.g., Figure 1 112). The memory 920 may also 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 also 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 also 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 also include, for example, a clock drift model 936 (e.g., a machine learning model trained to predict temporal drift changes), data received from the radio, workload predictions, historical clock drift, or other information.

[0094] In some embodiments, the distributed unit 114 may also include Fig. 9 For example, the memory 920 may also include a workload prediction module for predicting 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 understood as illustrative rather than restrictive. Various exemplary embodiments of the present disclosure may be described by the following terms:

[0095] Clause 1. A system comprising:

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

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

[0098] 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 synchronizes the clock of the distributed unit with the clock of the radio unit;

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

[0100] 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;

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

[0102] 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 causes the clock of the distributed unit to resynchronize with the clock of the radio unit;

[0103] 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;

[0104] 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;

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

[0106] 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

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

[0108] 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.

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

[0110] determining a third time to transmit third data to the distributed unit based at least in part on applying the correction factor a plurality of times 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

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

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

[0113] 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.

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

[0115] 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;

[0116] 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;

[0117] 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;

[0118] 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

[0119] 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.

[0120] 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.

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

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

[0123] 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 a workload of the radio unit, a workload of the distributed unit, a temperature of the distributed unit, a change in the workload of the distributed unit, or an estimated reliability of the correction factor.

[0124] 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.

[0125] 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.

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

[0127] 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.

[0128] 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.

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

[0130] 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:

[0131] transmitting first data from the distributed unit to a 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;

[0132] 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

[0133] 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.

[0134] 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 multiple timestamps on data packets sent by the radio unit via an enhanced Common Public Radio Interface ("eCPRI") protocol.

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

[0136] 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.

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

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

[0139] 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.

[0140] Clause 22. A system comprising:

[0141] A centralized unit of a radio access network;

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

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

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

[0145] obtaining a first time for transmitting the first data 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;

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

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

[0148] 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.

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

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

[0151] 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.

[0152] 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.

[0153] Clause 27. A system as described in clause 22, wherein the distributed unit executes additional executable instructions to perform additional operations, the additional operations including 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 is a fixed interval earlier than the first time.

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

[0155] obtaining, by a distributed unit, a first time for transmitting first data 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;

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

[0157] 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

[0158] 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.

[0159] 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.

[0160] 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.

[0161] Clause 31. A computer-implemented method as described in Clause 28, further comprising obtaining, by the distributed unit, a second time for transmitting second data 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.

[0162] 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.

[0163] 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.

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

[0165] 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").

[0166] 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.

[0167] Clause 37. The computer-implemented method of Clause 35, wherein the message comprises a request that the AMF reject new service requests that would increase the workload of the distributed unit.

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

[0169] 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:

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

[0171] 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

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

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

[0174] 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.

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

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

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

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

[0179] 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.

[0180] 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.

[0181] 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, may be added, merged, or omitted entirely (e.g., not all of the described actions or events are necessary for the practice of the algorithm). Furthermore, in certain embodiments, actions or events may be performed simultaneously (e.g., by multithreading, interrupt handling, or multiple processors or processor cores or on other parallel architectures), rather than sequentially. Additionally, different tasks or processes may be performed by different machines and / or computing systems that may run together.

[0182] 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).

[0183] Unless expressly provided otherwise, conditional language, such as, inter alia, "can," "may," "might," or "could," should additionally 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.

[0184] Unless expressly provided otherwise, connective language such as the phrase "at least one of X, Y, or Z" should additionally be understood within the context as being 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.

[0185] 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. It should be understood by those skilled in the art 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.

[0186] 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. The one or more recited devices may also be collectively configured to perform the recited statements. For example, "a processor configured to perform statements A, B, and C" may include a first processor configured to perform statement A working in conjunction with a second processor configured to perform statements B and C.

Claims

1. A system comprising: A centralized unit of a radio access network; a radio unit of the radio access network; as well as a distributed unit of the radio access network, the distributed unit comprising a process, the process executing computer executable instructions to perform operations comprising: receiving, from the centralized unit, first data to be transmitted to the radio unit; obtaining a first time for transmitting the first data 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; obtaining workload information about the workload of the distributed unit; determining a likelihood that the distributed unit will transmit the first data to the radio unit after the first time based at least in part on the workload information; and 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.

2. The system of claim 1, wherein one or more of the centralized unit and the distributed unit are implemented on an edge server of a cloud provider network.

3. A system as described in claim 1, wherein reducing the workload of the distributed unit includes one or more of the following items: the distributed unit requests the access and mobility management function to reject the new service request, the distributed unit rejects the new service request, the distributed unit switches the new service to the second distributed unit, the distributed unit switches the existing service to the second distributed unit, or the distributed unit limits the existing service.

4. The system of claim 1, wherein the workload information comprises one or more of memory utilization, processor utilization, processor temperature, amount of data transmitted, or amount of data received.

5. The system of claim 1 , wherein the distributed unit determines a 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.

6. The system of claim 1 , wherein the distributed unit executes additional executable instructions to perform additional operations, the additional 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 is a fixed interval earlier than the first time.

7. A computer-implemented method comprising: obtaining, by a distributed unit, a first time for transmitting first data 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; obtaining, by the distributed unit, workload information regarding the workload of the distributed unit; 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; as well as 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.

8. The computer implemented method of claim 7, 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.

9. The computer-implemented method of claim 7, wherein determining the likelihood that the distributed unit will transmit the first data to the radio unit after the first time comprises applying a machine learning model to the workload information.

10. The computer-implemented method of claim 7, further comprising obtaining, by the distributed unit, a second time for transmitting second data 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.

11. The computer-implemented method of claim 10, 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.

12. The computer-implemented method of claim 7, 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.

13. The computer-implemented method of claim 7, wherein reducing the workload of the distributed unit comprises transmitting a message from the distributed unit to an access and mobility management function ("AMF").

14. The computer-implemented method of claim 13, wherein the message is in response to a request from the AMF for the workload information.

15. The computer-implemented method of claim 13, wherein the message comprises a request that the AMF reject new service requests that would increase the workload of the distributed unit.

Images