Abstract: The present invention provides shortening TB Therapy and reducing relapse by co-administering Chloroquine with anti-TB drugs to drug-sensitive TB patients, multiple drug resistant (MDR) TB patients and TB patients co-infected with HIV-1. The present invention also provides shortening TB Therapy and reducing relapse by co-administering hydroxychloroquine with anti-TB drugs to drug-sensitive TB patients, multiple drug resistant (MDR) TB patients and TB patients co-infected with HIV-1.

Abstract: An optoelectronic device. The device comprising: a silicon-on-insulator, SOI, wafer, the SOI wafer including a cavity and an input waveguide, the input waveguide being optically coupled into the cavity; and a mirror, located within the cavity and bonded to a bed thereof, the mirror including a reflector configured to reflect light received from the input waveguide in the SOI wafer.

Abstract: A computing device may receive audio data from a microphone representing audio in an environment of the device, which may correspond to an utterance and noise. A model may be trained to process the audio data to cancel noise from the audio data. The model may include an encoder that includes one or more dense layers, one or more recurrent layers, and a decoder that includes one or more dense layers.

Abstract: The present disclosure encompasses solid state forms of Setogepram, in embodiments crystalline polymorphs or salts of Setogepram, particularly Setogepram sodium, processes for preparation thereof, and pharmaceutical compositions thereof.

Abstract: A mirror and method of fabricating the mirror, the method comprising: providing a silicon-on-insulator substrate, the substrate comprising: a silicon support layer; a buried oxide (BOX) layer on top of the silicon support layer; and a silicon device layer on top of the BOX layer; creating a via in the silicon device layer, the via extending to the BOX layer; etching away a portion of the BOX layer starting at the via and extending laterally away from the via in a first direction to create a channel between the silicon device layer and silicon support layer; applying an anisotropic etch via the channel to regions of the silicon device layer and silicon support layer adjacent to the channel; the anisotropic etch following an orientation plane of the silicon device layer and silicon support layer to create a cavity underneath an overhanging portion of the silicon device layer; the overhanging portion defining a planar underside surface for vertically coupling light into and out of the silicon device layer; and

Abstract: Eyewear having electrochromic lenses for controlling a light transmissive property/tinting for a user's eye and a camera. The electrochromic lenses have an eye region for controlling light transmission to a user's eye, and a separate camera region for controlling light transmission to a camera. Two or more electrochromic lenses are provided to independently control the tinting for each of the user's eye, and two or more cameras. The electrochromic lenses comprise of multiple lens layers forming a single stack. Each layer has an opening configured to receive a fill material, such as a dye, such that the fill material can have different chemistries. The displays may also have different dye chemistries to allow for different tint ranges (wavelengths of light passed).

Abstract: A device may receive a request for an operation that includes a plurality of processing steps may identify metadata information. The device may determine a first processing step, and select a first microservice to call and a first transport protocol to utilize to call the first microservice. The device may call the first microservice, and may receive, from the first microservice a first output. The device may determine a second processing step, and select a second microservice to call and a second transport protocol to utilize to call the second microservice, wherein the second transport protocol is different from the first transport protocol. The device may call the second microservice, and may receive, from the second microservice, a second output. The device may provide a response to the request based on the first output and the second output.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide various methods for offloading operations in an O-RAN (Open Radio Access Network) onto control plane (CP) or edge applications that execute on host computers with hardware accelerators in software defined datacenters (SDDCs). At the CP or edge application operating on a machine executing on a host computer with a hardware accelerator, the method of some embodiments receives data, from an O-RAN E2 unit, to perform an operation. The method uses a driver of the machine to communicate directly with the hardware accelerator to direct the hardware accelerator to perform a set of computations associated with the operation. This driver allows the communication with the hardware accelerator to bypass an intervening set of drivers executing on the host computer between the machine's driver and the hardware accelerator. Through this driver, the application in some embodiments receives the computation results, which it then provides to one or more O-RAN components (e.g.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide a method of performing control plane operations in a radio access network (RAN). The method deploys several machines on a host computer. On each machine, the method deploys a control plane application to perform a control plane operation. The method also configures on each machine a RAN intelligent controller (RIC) SDK to serve as an interface between the control plane application on the same machine and a set of one or more elements of the RAN. In some embodiments, the RIC SDK on each machine includes a set of network connectivity processes that establish network connections to the set of RAN elements for the control plane application. These RIC SDK processes allow the control plane application on their machine to forego having the set of network connectivity processes.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide a method of performing control plane operations in a radio access network (RAN). The method deploys several machines on a host computer. On each machine, the method deploys a control plane application to perform a control plane operation. The method also configures on each machine a RAN intelligent controller (RIC) SDK to serve as an interface between the control plane application on the same machine and a set of one or more elements of the RAN. In some embodiments, the RIC SDK on each machine includes a set of network connectivity processes that establish network connections to the set of RAN elements for the control plane application. These RIC SDK processes allow the control plane application on their machine to forego having the set of network connectivity processes.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide a method of performing control plane operations in a radio access network (RAN). The method deploys several machines on a host computer. On each machine, the method deploys a control plane application to perform a control plane operation. The method also configures on each machine a RAN intelligent controller (RIC) SDK to serve as an interface between the control plane application on the same machine and a set of one or more elements of the RAN. In some embodiments, the RIC SDK on each machine includes a set of network connectivity processes that establish network connections to the set of RAN elements for the control plane application. These RIC SDK processes allow the control plane application on their machine to forego having the set of network connectivity processes.

Abstract: Some embodiments provide various methods for offloading operations in an O-RAN (Open Radio Access Network) onto control plane (CP) or edge applications that execute on host computers with hardware accelerators in software defined datacenters (SDDCs). At the CP or edge application operating on a machine executing on a host computer with a hardware accelerator, the method of some embodiments receives data, from an O-RAN E2 unit, to perform an operation. The method uses a driver of the machine to communicate directly with the hardware accelerator to direct the hardware accelerator to perform a set of computations associated with the operation. This driver allows the communication with the hardware accelerator to bypass an intervening set of drivers executing on the host computer between the machine's driver and the hardware accelerator. Through this driver, the application in some embodiments receives the computation results, which it then provides to one or more O-RAN components (e.g.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide various methods for offloading operations in an O-RAN (Open Radio Access Network) onto control plane (CP) or edge applications that execute on host computers with hardware accelerators in software defined datacenters (SDDCs). At the CP or edge application operating on a machine executing on a host computer with a hardware accelerator, the method of some embodiments receives data, from an O-RAN E2 unit, to perform an operation. The method uses a driver of the machine to communicate directly with the hardware accelerator to direct the hardware accelerator to perform a set of computations associated with the operation. This driver allows the communication with the hardware accelerator to bypass an intervening set of drivers executing on the host computer between the machine's driver and the hardware accelerator. Through this driver, the application in some embodiments receives the computation results, which it then provides to one or more O-RAN components (e.g.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.