Decomposed user equipment (UE) architecture and method

Abstract

Embodiments implement a decomposed user equipment (UE). A method for a UE physical layer server to interact with one or more UE clients includes: receiving, by a control endpoint, a request from a UE client to allocate resources for the UE client; when it is determined that the request is permitted, internal resources of the UE physical layer server are allocated to the UE client, and the internal resources comprise contexts for the UE client to communicate with the base station through the UE physical layer server; providing a handle to the UE client, the handle to be used to identify the UE client for interaction between the physical layer server and the UE client, the UE client performing operations in one or more layers above the physical layer of the UE; and performing one or more message exchanges between the UE physical layer server and the UE client through the data endpoint.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 471445, filed June 6, 2023, which is incorporated herein by reference. Technical Field

[0002] Embodiments of the present invention relate to the field of networking; and more specifically to decomposed user equipment (UE). Background Technology

[0003] Numerous approaches have been proposed as solutions for UE emulation. One of the earlier approaches describes a scalable architecture for LTE multi-UE emulation using a combined digital signal processing (DSP) and field-programmable gate array (FPGA) system. The described multi-UE emulator is connected to a single evolved Node B (eNodeB). A common portion of signal processing is performed together for all UEs, including processing up to channel estimation and equalization. Following this, UE-specific processing is performed for each UE. The processed signals are then sent to the radio link control and / or media access control (RLC / MAC) layer for higher-level processing. This approach also defines that signal processing can be performed sequentially or in parallel.

[0004] The second, earlier approach defines a method and system for testing uplink multiple-input multiple-output (MIMO) air interface using a multi-UE emulator. The emulator receives uplink licenses for transmissions across multiple UEs and allocates (temporally) overlapping licenses to different uplink signal processing chains and associated antennas. Similarly, a third, earlier approach defines a method and system for simulating signal fading for each UE to test air interface devices using each UE signal generation chain.

[0005] The related concept is that the Fifth Generation (5G) Function Application Programming Interface (FAPI) is defined by the Small Cell Forum as a set of specifications. This set of specifications specifically defines the interface (MAC-PHY interface) between the MAC (Media Access Control) layer and the PHY (Physical) layer for 5G next-generation node Bs (gNodeBs). The 5G UE-like FAPI interface is defined in the standard titled "5G - New Radio (NR) User Equipment (UE) API-like Interface" released by EURECOM OpenAirInterface in August 2018. This interface specifies the interaction procedures and messages between the 5G UE MAC and PHY layers within a single UE. Summary of the Invention

[0006] Embodiments include methods, electronic devices, storage media, and computer programs for implementing a disaggregated user equipment (UE). In one embodiment, a method for a UE physical layer server to interact with one or more UE clients is disclosed. The method includes receiving, by a control endpoint of the UE physical layer server, a request from a UE client to allocate resources for the UE client; allocating, upon determining to grant the request, internal resources of the UE physical layer server to the UE client, the internal resources including a context for the UE client corresponding to resources in the UE physical layer server for the UE client to communicate with a base station through the UE physical layer server; providing a handle to the UE client, the handle to be used to identify the UE client for interactions between the UE physical layer server and the UE client, the UE client performing operations in one or more layers above a physical layer of the UE; and performing, by a data endpoint of the UE physical layer server, one or more message exchanges between the UE physical layer server and the UE client.

[0007] In one embodiment, an electronic device for implementing a user equipment (UE) physical layer server to interact with one or more UE clients is disclosed. The electronic device includes a processor and a non-transitory machine-readable storage medium, the non-transitory machine-readable storage medium providing instructions that, when executed by the processor, cause the electronic device to perform: receiving, by a control endpoint of the UE physical layer server, a request from a UE client to allocate resources for the UE client; allocating, upon determining to grant the request, internal resources of the UE physical layer server to the UE client, the internal resources including a context for the UE client corresponding to resources in the UE physical layer server for the UE client to communicate with a base station through the UE physical layer server; providing a handle to the UE client, the handle to be used to identify the UE client for interactions between the UE physical layer server and the UE client, the UE client performing operations in one or more layers above a physical layer of the UE; and performing, by a data endpoint of the UE physical layer server, one or more message exchanges between the UE physical layer server and the UE client.

[0008] In one embodiment, a non-transitory machine-readable storage medium is disclosed. The non-transitory machine-readable storage medium provides instructions that, when executed by a processor of an electronic device, cause the electronic device to perform: receiving, by a control endpoint of a UE physical layer server, a request from a UE client for allocation of resources for the UE client; upon determining to grant the request, allocating internal resources of the UE physical layer server to the UE client, the internal resources including a context for the UE client corresponding to resources in the UE physical layer server for the UE client to communicate with a base station through the UE physical layer server; providing a handle to the UE client, the handle to be used to identify the UE client for interactions between the UE physical layer server and the UE client, the UE client performing operations in one or more layers above a physical layer of the UE; and performing, by a data endpoint of the UE physical layer server, one or more message exchanges between the UE physical layer server and the UE client.

[0009] In one embodiment, a method for a user equipment (UE) client to interact with a UE physical layer server is disclosed. The method includes: performing service discovery to find a control endpoint of the UE physical layer server; sending, to the control endpoint of the UE physical layer server, a request for allocation of resources for the UE client, the request indicating an identifier of the UE client; receiving a handle from the UE physical layer server; and performing interactions between the UE client and the UE physical layer server using the handle.

[0010] In one embodiment, an electronic device for enabling a user equipment (UE) client to interact with a UE physical layer server is disclosed. The electronic device includes a processor and a non-transitory machine-readable storage medium that provides instructions that, when executed by the processor, cause the electronic device to perform: performing service discovery to find a control endpoint of the UE physical layer server; sending, to the control endpoint of the UE physical layer server, a request for allocation of resources for the UE client, the request indicating an identifier of the UE client; receiving a handle from the UE physical layer server; and performing interactions between the UE client and the UE physical layer server using the handle.

[0011] In one embodiment, a non-transitory machine-readable storage medium is disclosed. The non-transitory machine-readable storage medium provides instructions that, when executed by a processor of an electronic device, cause the electronic device to perform: performing service discovery to find a control endpoint of the UE physical layer server; sending, to the control endpoint of the UE physical layer server, a request for allocation of resources for the UE client, the request indicating an identifier of the UE client; receiving a handle from the UE physical layer server; and performing interactions between the UE client and the UE physical layer server using the handle.

[0012] These embodiments enable distributed deployments with one or more UE clients to interact with a single UE physical layer server and allow for an efficient and scalable solution to emulate and / or test radio networks. BRIEF DESCRIPTION OF DRAWINGS

[0013] The application can best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:

[0014] Figure 1 An operating environment for a UE interacting with a RAN is shown in accordance with some embodiments.

[0015] Figure 2 An overall system architecture is shown in accordance with some embodiments.

[0016] Figure 3 Operation of a UE physical layer server (PHY server) handling UE allocation and release requests is shown in accordance with some embodiments.

[0017] Figure 4 A start-up operation of a UE MAC client is shown in accordance with some embodiments.

[0018] Figure 5 Normal operation of a UE MAC client is shown in accordance with some embodiments.

[0019] Figure 6 A termination operation of a UE MAC client termination is shown in accordance with some embodiments.

[0020] Figure 7 Deployment of an inline UE PHY (L1) server in the context of a digital twin test environment is shown in accordance with some embodiments.

[0021] Figure 8 Implementation of a synchronized system clock for coordinating communications is shown in accordance with some embodiments.

[0022] Figure 9 Some basic use cases in some embodiments of L2 to L1 communications for sending memory access patterns are shown in accordance with some embodiments.

[0023] Figure 10 Advanced behavior of a L1 server is described in accordance with some embodiments.

[0024] Figure 11 A procedure to describe a service level configuration (as opposed to a UE level) is shown in accordance with some embodiments.

[0025] Figure 12 Steps in a UE L1 procedure are shown in accordance with some embodiments.

[0026] Figure 13A -B shows two exemplary types in some embodiments.

[0027] Figure 14 A UE L1 allocation procedure is shown in accordance with some embodiments.

[0028] Figure 15 A UE L1 deallocation procedure is shown in accordance with some embodiments.

[0029] Figure 16 A UE cell search procedure is shown in accordance with some embodiments.

[0030] Figure 17 An expected sequence in the context of a successful execution path is depicted in accordance with some embodiments.

[0031] Figure 18 An expected sequence in the context of a successful execution path is shown in accordance with some embodiments.

[0032] Figure 19 An expected sequence in the context of a successful execution path is depicted in accordance with some embodiments.

[0033] Figure 20 Operations at a user equipment (UE) physical layer server (e.g., a UE PHY server or L1 server) are shown in accordance with some embodiments.

[0034] Figure 21 Operations at a user equipment (UE) client (e.g., a UE MAC client and / or a UE L2) are shown in accordance with some embodiments.

[0035] Figure 22A Exemplary signal transmission levels in a wireless network are shown.

[0036] Figure 22B Resource elements for data and signaling transmission are shown.

[0037] Figure 23 An electronic device implementing a UE L1 / L2 interaction coordinator is shown in accordance with some embodiments.

[0038] Figure 24 An example of a communication system is shown in accordance with some embodiments.

[0039] Figure 25 A user equipment (UE) is shown in accordance with some embodiments.

[0040] Figure 26 A network node is shown in accordance with some embodiments.

[0041] Figure 27is a block diagram of a host according to various aspects described herein, which can be a Figure 24 embodiment of a host.

[0042] Figure 28 is a block diagram illustrating a virtualized environment in which functions implemented by some embodiments can be virtualized.

[0043] Figure 29 is a communication diagram illustrating a host communicating with a UE via a network node over a partial wireless connection according to some embodiments. DETAILED DESCRIPTION

[0044] The first through third earlier approaches discussed herein above have their challenges in terms of emulating the operation of a real-world wireless network deployment. For example, they fail to provide individual user equipment (UEs) (referred to as emulated UEs, soft UEs, or soft UEs) with unique channel conditions in a computationally efficient manner. State-of-the-art solutions fall broadly into two categories. The first category of solutions provides non-unique channel conditions for each UE, e.g., by simply providing the same settings for all UEs. Thus, these emulations fail to properly capture the variations of the radio channel due to factors such as fading. Alternatively, in the second category, each UE’s one physical layer (L1 layer or PHY layer) is naively emulated, which becomes computationally very expensive.

[0045] Furthermore, existing solutions operate in relation to a single base station, which limits testing for certain deployment scenarios, e.g., handover or cell search. Moreover, no published soft UE architecture allows distribution using pooled L1 processing and separate higher layer instances.

[0046] A core limitation of the first earlier approach is that it defines a single hardware system containing all L1 (PHY) and L2 (RLC / MAC) and higher processing components. This limits scalability and makes the system non-distributable. It defines a single RLC / MAC entity connected to a single PHY entity. It also specifically defines a single eNodeB for connecting all UEs over wired connections or radio links, which means that all UEs will experience the same physical channel conditions. Note that the terms Layer 1 (L1) and physical layer (PHY) can be used interchangeably herein, as can the terms Layer 2 (L2) and RLC / MAC layer (RLC / MAC).

[0047] The systems and methods defined in the second and third earlier approaches use a dedicated signal processing chain per UE to communicate with a single base station. Again, as before, a “single box” design limits scalability in these cases. Furthermore, all UEs are connected to a single base station / cell, and thus, for example, handover scenarios cannot be emulated.

[0048] The procedures and messages of FAPI only cover base station side interaction between MAC and PHY layers and only in a one-to-one setup. The interface defined in the FAPI-like interface standard targets a single UE and defines a single MAC layer interacting with one or more PHY layers to support carrier aggregation. It also offloads cell synchronization completely to the PHY layer and thus cannot support multi-gNodeB / cell configuration or handover.

[0049] UE distributed deployment The present disclosure provides embodiments that overcome these and other challenges in earlier approaches. A new architecture is proposed that enables distributed deployment through a defined MAC-PHY interface that is able to connect one or more MAC instances to a pooled single PHY instance. The embodiments provide careful design of the API and location of radio functions to support the decomposition of L1 and L2. This in turn will provide an efficient and scalable emulation setup, among other things, for testing radio networks.

[0050] As described in the background, the described disclosure relates to providing a dual (multi-) active emulation (SIM) supported UE, where each emulation entity has a dedicated set of antennas. The described solution can be used to implement such a physical UE (referred to as hard / actual / physical UE) or soft UE that is deployed in an operational radio network.

[0051] For (physical or emulated) handsets, the UE stack (L1, L2, L3) is usually very tightly integrated together. The present disclosure proposes the decomposition of the stack by providing an efficient MAC-PHY separation. In a testing or simulation scenario, this allows aggregating or pooling the L1 processing of all UEs, enabling an efficient and scalable acceleration. In connection with this, a well-defined UE MAC-PHY interface is needed, which includes an application programming interface (API) description, message structure, service procedures (e.g., discovery), and UE-specific procedures (e.g., management of uplink and downlink channels).

[0052] In addition to the architecture and interface, some related aspects are also considered important: Decoupling of the PHY and MAC layers by using an independent (synchronized) time source of the third generation partnership project (3GPP) timing event. Automatic release of buffers on the MAC-PHY interface according to the elapsed 3GPP time since the allocation.

[0053] Certain embodiments can provide one or more of the following technical advantages, including the following. • A clean interface makes components easier to replace and can be provided by multiple participants. Today, there is no such interface. • The proposed design of the MAC-PHY interface enables an efficient simulation and testing environment by using a PHY (L1) server that handles multiple UEs simultaneously. • While the interface is primarily designed for test cases, the existence of the established interface will also provide opportunities for non-soft UEs. We envision future use cases involving physical phones (or other communication devices) where the MAC and PHY interface would be beneficial.

[0054] The present disclosure proposes a disaggregated stack for a UE and defines a new Medium Access Control layer to Physical layer interface (MAC-PHY interface). Use cases include digital testing of a telecommunication network where multiple UEs are connected to a radio network. Digital testing can use soft UEs instead of physical phones (also referred to as hard / actual / physical UEs). For example, when building a test environment similar to a “digital twin” for a RAN system, the functionality of several UEs running on commercial off-the-shelf (COTS) hardware needs to be replicated. A digital twin of a RAN system is a virtual representation of the physical RAN infrastructure and its components. It is a digital copy that simulates the behavior and characteristics of the actual RAN system in real-time. While digital testing is used as an example for the new MAC-PHY interface, the new MAC-PHY interface can be used for physical RAN systems where the MAC-PHY interface is used for interaction between MAC layers (L2 layers) of multiple UEs on a common PHY layer (L1 layer). For example, dual (or multiple) active physical UEs (instead of simulated UEs) have as many (a set of) antennas as the simulation and the internal implementation can be related to the described solution.

[0055] Due to the computational requirements of the L1 functionality at the UE side, one or more accelerators (e.g., a graphics processing unit (GPU)) can be used for efficient processing. A naive approach of utilizing an accelerated L1 layer instance per UE does not scale well, while a single L1 instance processing a pool of UEs provides good scalability.

[0056] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0057] System with new MAC-PHY interface Figure 1 An operating environment of a UE interacting with a RAN is shown in accordance with some embodiments. As Figure 1 It is proposed that, in some embodiments, a radio access network (RAN) is a unit under test / monitoring at 112 of the drawing. The RAN is an intermediary between the UE and the core network. The UE communicates with the RAN over the fronthaul, while the RAN communicates with the core network over the backhaul.

[0058] In some embodiments, radio unit (RU) functionality is implemented by the RU Sim module 102, and there is also a channel or channel emulator 104 between the RU and the UE L1 that provides time-varying channel conditions for each UE according to its location in (virtual) space.

[0059] The operating environment 100 can be used for simulation as well as testing in actual deployments. In simulation, the test environment can operate as a “digital twin” of the corresponding RAN system, with the functionality of several UEs running duplicated on COTS hardware. Due to the processing requirements of the UE-side L1 functionality, for efficiency reasons, an accelerator (e.g., a GPU) should be used to process the pool of UEs. Radio unit (RU) functionality is implemented by the RU Sim module, and there is also a channel emulator between the RU and the UE L1 that emulates unique time-varying channel conditions for each UE according to its location in (virtual) space.

[0060] Figure 2 An overall system architecture is shown in accordance with some embodiments. This figure shows that, on the RAN side, there is one or more base stations, such as a gNodeB 202, and connected to a radio unit (Rus) 204. Note that this figure is slightly simplified in that a gNodeB can also be connected to multiple Rus. The key point on the RAN side in the figure is that there is one or more cells in the system. The channel 206 can be a virtual channel emulated with a channel emulator, or a radio channel implemented over radio signals. Note that while we use 5G terminology and components (e.g., gNodeB) in this description, the concepts presented can be applied to different past and future generations of 3GPP or other radio / wireless systems (e.g., a gNodeB is just one type of base station that embodiments of this disclosure can implement).

[0061] The UE side includes physical or simulated UEs (soft UEs) 232. A single UE physical layer (PHY) server 234 handles the L1 for multiple soft UEs and one or more soft UEs present in the system. A soft UE is composed of a UE MAC client (e.g., one of UE MAC clients 252 or 254), which contains the MAC and higher layers of the UE stack, and a UE PHY context with an associated antenna or antenna port (one or more depending on the MIMO configuration) within the UE PHY server 234. The UE PHY server 234 and the UE MAC client communicate over the described MAC-PHY interface.

[0062] The UE PHY server exposes two endpoints: - Control endpoints 242 are used for service procedures, including state requests, initial connection creation, UE handle allocation and deallocation. Control endpoints are also used for service discovery, e.g. a UE can find a control endpoint (e.g. IP address and port) at a well-known location. - Data endpoints 244 are used for uplink and downlink data procedures per UE. This endpoint can be implemented using regular networking, or for example by shared memory communication for better performance.

[0063] The UE MAC-PHY interface 236 can be implemented with a shared library used in the UE instance. This shared library provides an application programming interface (API) for the UE to use, which exposes the features of the UE PHY server.

[0064] The UE PHY server creates the control endpoints 242 at startup and can make connection details available to the UE MAC client at a well-known location (e.g. in a service registry). Figure 3 The operation of a UE physical layer server (PHY server) handling UE allocation and deallocation requests is shown according to some embodiments. Note that the request types handled through the control endpoints can be more, e.g. state requests.

[0065] The UE MAC client (as shown in Figure 2 provides, for example, the number of antennas, frequency band, bandwidth as part of the allocation request. The figure shows that, once an allocation message is received from the UE MAC client (as determined at reference numeral 304), it is verified at reference numeral 306 whether the UE PHY server has the capability to serve the client. If not, the flow goes to 312 where the allocation request is rejected. If the client can be served, the UE PHY server allocates internal resources, e.g. context, handle and one or more antennas at reference numeral 308. This handle is used to identify during future interactions between the UE PHY server and the UE MAC client. At reference numeral 310, the handle is sent to the UE MAC client. The internal structure of the handle object is not meant to be resolved / understood at the UE MAC client side. The handle can be created based on information received as part of the UE allocation (e.g. this information can include the international mobile subscriber identity (IMSI)). If the received message is not an allocation message, but a UE deallocation message as determined at reference numeral 316, the UE related resources are released at reference numeral 318 by deallocating the UE context, handle and antennas and clearing remaining requests, and an acknowledgement is sent to the UE MAC client at reference numeral 320.

[0066] Figure 4The startup operation of the UE MAC client is shown, according to some embodiments. First, service discovery is performed at reference numeral 402 to find the control endpoint of the UE PHY server. This can be a query to a service registry or based on configuration input. Then, at reference numeral 404, the UE MAC client sends an allocation request to the UE PHY server. If the request is accepted, as determined at reference numeral 406, the UE handle is received at reference numeral 408, and the UE enters normal operation at reference numeral 410. Otherwise, the request is rejected, and the UE MAC client is rejected at reference numeral 412. The UE MAC client can also receive configuration related to the data endpoints to be used during normal UE operation.

[0067] Figure 5 The normal operation of the UE MAC client is shown, according to some embodiments. The processing on the MAC layer is based on time slots (see the section on “Emulation Features” below for related explanation). The procedure waits for the next time slot to process incoming messages at reference numeral 502. Once a message is received from the corresponding UE PHY server, the UE MAC client processes the message at reference numeral 504. The message is processed from the UE PHY server’s data endpoints, and based on the message and other configuration, the MAC and higher layer logic is executed at reference numeral 506. Finally, any messages to be sent to the UE PHY server are sent to the data endpoints, with the UE handle included at reference numeral 508.

[0068] Figure 6 The termination operation of the UE MAC client termination is shown, according to some embodiments. Once the UE termination is initiated, the UE MAC client sends a UE deallocation message with the UE handle to the corresponding UE PHY server at reference numeral 602. Once an acknowledgement is received at reference numeral 604, the UE MAC client terminates the UE at reference numeral 606.

[0069] Simulation test While Figures 1-6 The operations shown in FIG. 6 can be used for both actual RAN deployments and emulation testing, but more details will be discussed regarding emulation testing. Figure 7 The deployment of an inline UE PHY (L1) server in the context of a digital twin test environment is shown, according to some embodiments. In some embodiments, the UE PHY L1 server can be implemented using one or more accelerators. The system 700 includes a disaggregated UE stack deployment in a virtual distributed unit (vDU) digital test context.

[0070] In some embodiments, the L1 server 752 and the L2 / L3 instance 754 correspond to a UE physical layer server (e.g., the UE PHY server 234) and a UE MAC client (e.g., one of the UE MAC clients 252 or 254), respectively. From this figure, it is noted that, according to some embodiments, the following points: • The L1 server is an independent process that can support the creation of multiple L1 contexts. These contexts abstract completely from the connection of the channel emulator towards higher layers according to a given configuration (e.g., number of antennas, bandwidth, etc.). • The L2 / L3 instance can be located in a different process or hosted in a single process that can support multiple UE instances. The addressability method is based on an L1 local identifier that can be used as a handle for each instance. This identifier can be represented as an integer value {0...N}. • The L2 / L3 instance can communicate with the L1 server through a shared object library (ue_driver.so) that acts as a software driver encapsulating the transport layer and other implementation aspects of the channel emulator, as well as the overall connection with the vDU.

[0071] The UE L1 server is deployed as an independent process that supports a message-based interface. Network details (e.g., transport method and serialization) are implemented by a shared object library (ue_driver.so). This software module acts as a driver that can be dynamically linked to any client L2 / L3 UE process that needs to accelerate L1 functionality.

[0072] Simulation features In this section, we provide simulation features implemented in some embodiments.

[0073] NR time-based slot indication in UE MAC UE MAC and higher layer operations are managed by 3GPP timing as certain messages need to be sent and received according to a given instant. The given instant is identified by the system frame number, subframe, slot, and symbol. Typically, the MAC layer derives the timing from the PHY layer by receiving a slot indication (e.g., in the case of a gNodeB side, the aforementioned FAPI specification details the slot indication). The length of each slot, and thus the frequency of the indication, depends on the numerology used.

[0074] In the described multi-UE environment, sending such an indication to each UE causes a large number of messages to compete with the regular uplink and downlink-related interactions between the layers. Moreover, it is necessary to ensure that the messages arrive with very low jitter, which causes further complexity if one or more networking hops are included.

[0075] In the proposed solution, the synchronization system clock is used (instead of explicit slot indication) to coordinate the communication. The 3GPP over-the-air communication is aligned with the GPS clock. Then, the regular system time can be converted into what we call NR time, i.e. the number of radio slots elapsed since a well-known point in time (e.g. January 1st, 1980, midnight).

[0076] In a single physical node deployment (i.e. the physical layer server and the UE instance are deployed to the same node), no specific synchronization is needed since all components can query the single system time and convert it into NR time. For the multi-node case, each node can be equipped with a GPS receiver or use a protocol such as PTP (Precision Time Protocol) to synchronize the clocks of the nodes, similarly to the radio access network side.

[0077] Figure 8 An implementation of the synchronization system clock for coordinating the communication is shown according to some embodiments. In this figure, the UE physical layer server and each UE instance are connected to a NrTime provider that can generate slot or symbol events based on the system time. The NrTime provider is first configured, e.g. for determining how the system time is converted into NR time and the current set of parameters for the basic event rate. We note that if the UE physical layer server is serving multiple sets of parameters, it can request events for the highest set of parameters or for each set of parameters.

[0078] In the given example, when the NrTime provider in the UE instance generates an event for slot 9 in a given radio frame, one or more UEs send a message (e.g. a downlink decoding request or an uplink transmission request) for the upcoming future slot (e.g. slot 10) at reference 802 through the described MAC-PHY interface. On the other hand, the UE physical layer server uses its own event from the NrTime provider to handle the uplink and downlink related requests and sends a message to the UE through the described MAC-PHY interface at reference 804.

[0079] Time limited buffer between PHY and MAC layer During the uplink and downlink communication process, a buffer is used for the communication between the UE PHY server and the UE MAC client. The buffer contains messages that can carry different information between the layers, e.g.: - for the Physical Downlink Control Channel (PDCCH) o a request from MAC to PHY for decoding the Downlink Control Information (DCI) at a specific time and frequency location o a response from PHY to MAC with the DCI - For Physical Downlink Shared Channel (PDSCH) o Request from MAC to PHY to decode incoming data according to specific configuration (e.g. MCS, number of PRBs, etc.). o Response from PHY to MAC with actual decoded data. - For PUSCH data to be transmitted and time and frequency location.

[0080] In case of shared memory based implementation on the interface between the UE PHY server and the UE MAC client, buffer ownership is a key issue. Specifically, where is the buffer allocated and deallocated. In traditional implementation, when a buffer is opened from one entity to another, a second round of interaction is needed to signal that the buffer has been processed and can be released.

[0081] Some embodiments can use an automatic buffer deallocation mechanism based on a predefined time expressed in radio slots. Both bidirectional messages (MAC to PHY and PHY to MAC) are time sensitive and valid for a limited time, so it can be safely assumed that it can be discarded after a certain amount of time.

[0082] For example, on the downlink (PHY to MAC), a buffer is allocated for a DCI or transport block and filled by the PHY server and handed over to the MAC client. The buffer is then released and invalidated after a certain number of NR slots (e.g. one radio frame). The deallocation time or lifetime of the buffer can be communicated as part of the message. The deallocation time can be given as a configuration or automatically adjusted or tuned based on, for example, monitoring of the components in a given environment.

[0083] MAC-PHY API The shared library provides the following APIs to the UE MAC and higher layers to support communication with the UE L1 accelerator.

[0084] (1) int GPhyInit(...); This function allows to define the transport type, for example: - Transport type: Transmission Control Protocol / User Datagram Protocol (TCP / UDP), shared memory, etc. - SLOT_IND per UE or none (i.e. use NR time on the client side) - PDCCH configuration options - and other operational parameters.

[0085] (2) GphyMsg::allocate <t>(size); The client can use GphyMsg::allocate <t>The GPHY message allocation function is called with a message type T and an optional size parameter (size) function call to allocate memory, where T is the message type and size is the optional additional size to be added to the message size. For example, to create a message for PUSCH allocation, the following can be followed: auto*msg = GphyMsg::allocate <gphyifpuschallocmsg>(1234); / / where the transport block size is 1234 bytes.

[0086] The L2 participant can then use this buffer to fill in the content of the parameters needed for sending a PUSCH transmission. Note that L2 does not need to worry about freeing the memory itself, as this buffer is managed by the interface library.

[0087] Note that the L2 participant will block the message send, not the response from the L1 server. In this context, blocking and non-blocking refer to the fact that the linux thread needs to wait for the return of the function call to send the message.

[0088] (3) int GPhyUeMsgSend(GphyMsg *msg); Using the message pointer (*msg) from the previous API, this function can be used to instruct the interface library to transmit the message to the L1 server or L1 instance.

[0089] This is a blocking function used by the L2 / L3 participant to specify a message to be sent to the L1 accelerator.

[0090] (4) GphyMsg *GPhyUeMsgQuery(); This non-blocking function is used to poll for a message from the L1 server. In this case, the function returns a pointer to the buffer containing the message sent by the L1 server. The client does not need to worry about freeing the memory.

[0091] Figure 9 Some basic use cases in some embodiments of L2 to L1 communication for sending memory access patterns are shown. Note that the subframe (SF), subframe number (SFN), and slot number are elapsed from the NR time used for synchronization. For more information on slots, frames, and subframes, see the discussion related to Figure 22A .

[0092] (5) GPhyIf3gppTime GphyGetNrTime(void *nrTime); UE MAC and higher layer operations are managed by 3GPP timing, as certain messages need to be sent and received according to a given instant. The given instant is identified by the system frame number (SFN), subframe (SF), slot, and symbol (see Figure 9 and 22A This helper function can help the client to validate incoming messages and also to schedule operations towards the L1 server. According to some embodiments, the GPhyIf3gppTime data structure is defined as follows: typedef struct { uint16_t radioFrame; uint16_t subFrame; uint16_t slot; uint16_t symbol; uint64_t timeInNs; } GPhyIf3gppTime;.

[0093] This data type appears as part of the standard header in every message. It is included for the purpose of debugging and tracing the messages exchanged between L1 and L2. Most of the interactions between L1 and L2 are time sensitive, and thus their values are only valid during a very specific time window, so time stamping the message transmission and reception is crucial to determine communication delays or subsystem faults.

[0094] L1 Server Procedures The following is a summary of the messages associated with the L1 Server Range procedures: o STATUS_REQ o STATUS_RESP o CONFIG_REQ o CONFIG_RESP.

[0095] The context of the above messages can be best understood by describing the finite state machine (FSM) that governs the L1 Server.

[0096] L1 server status Figure 10 The high-level behavior of the L1 Server is described in accordance with some embodiments.

[0097] Off ( OFF ) This state indicates that the L1 Server has not yet been found (or created). This is determined by a discovery procedure initiated by the driver to determine whether the L1 Server procedure has been created in the system and whether it has responded to an initial STATUS_REQ.

[0098] Idle ( IDLE ) This state indicates that the L1 server process exists, but has not been configured. During this state, the L1 server can accept CONFIG REQ messages. Note that only one L2 / L3 client can act as a configuration participant. Although the L1 server can support connections with multiple L2 / L3 clients for L1 instance processes (i.e. cell search, PUSCH transmission, etc.), only one external entity can configure the global settings of the L1 server.

[0099] In a simplified implementation, this state can be bypassed to allow a fixed configuration that can be loaded at startup, e.g. from a configuration file.

[0100] Ready ( READY ) This state indicates that the L1 server has received global configuration to determine the general behavior.

[0101] This state indicates that the L1 server has been configured and has established communication with the vDU through the channel emulator. This has many implications, e.g. the fact that the radio frame synchronization has been established.

[0102] Only after reaching this state, the L1 server will be able to accept UE-specific procedures (see section "L1 procedures per UE" below).

[0103] STATUS REQ / RESP This procedure allows the client to determine several things: - Discovery - Protocol version - Statistics - etc.

[0104] CONF REQ / RES Figure 11 The procedure describing the service level configuration (as opposed to the UE level) is shown.

[0105] L1 procedures per UE The following is a message summary associated with each L1 range procedure: o UE_ALLOC_REQ o UE_ALLOC_RESP o UE_DEALLOC_REQ o UE_DEALLOC_RESP o SLOT_IND.

[0106] Detailed description of the above messages is found in the sections below.

[0107] A prerequisite for these procedures is that the UE L1 server is ready. In the ready state, the procedures shall be executed as follows.

[0108] Figure 12 Steps in the UE L1 procedure are shown, according to some embodiments.

[0109] The UE L1 server supports one or more clients, and each client can run one or more UEs. This supports two main deployment types of higher layers: • A single deployment unit (e.g. container / pod) running multiple UEs. • Multiple deployment units (e.g. containers / pods), each running one UE.

[0110] When interfacing with the UE L1 server, messages from different clients and for different UEs can be interleaved in order to correctly support concurrent and independent operation of the UEs.

[0111] Figure 13A -B shows two exemplary types, according to some embodiments. Note that these are not the only possible deployments.

[0112] Device configuration This section describes the procedure to configure the UE "device". In a phone, there are aspects that are tied to the hardware - such as the number and configuration of antennas.

[0113] UE_ALLOC_REQ / RESP This procedure is used to allocate physical resources associated with a given UE L1 context. The L1 server has a limited number of physical resources, i.e. antenna buffers, processing power, etc. In some embodiments, when a client requests a new UE L1 resource, it receives a handle in the form of a simple integer value (provided that the maximum value is not exceeded).

[0114] Once this unique identifier is received, the client shall use it in any subsequent per-UE procedure (e.g. transmitting PUSCH data, etc.).

[0115] Figure 14 UE L1 allocation procedure is shown, according to some embodiments.

[0116] UE_DEALLOC_REQ / RESP This procedure is used to deallocate resources previously occupied by UE_ALLOC_REQ.

[0117] The client is expected to explicitly order deallocation, e.g. at the time of closing the UE. Note that in case of e.g. client crash, the library and service can take measures to clean up dangling resources, but this is only for exceptional use cases.

[0118] Figure 15 A UE L1 deallocation procedure is shown in accordance with some embodiments.

[0119] The applicable response codes are: Cell search / measurement Pre-conditions • The UE successfully performed the UE_ALLOC_REQ / REP. Design assumptions • The UE L1 performs measurements as instructed by the UE higher layers. • The UE higher layers will use the measurements to select the strongest cell and request the UE L1 (through the relevant UE L1 procedure) to acquire: o PBCH / MIB (for use by the UE higher layers to e.g. check if the cell is barred) o PDSCH / SIB1 (for use by the UE higher layers to e.g. check measurement thresholds and PLMN ID) • If the strongest does not meet the selection criteria, the higher layers can need to perform MIB / SIB1 acquisition on other cells.

[0120] Message sequence Figure 16 A UE cell search procedure is shown in accordance with some embodiments.

[0121] PBCH / MIB acquisition Figure 17 The expected sequence in the context of a successful execution path is depicted in accordance with some embodiments.

[0122] SIB acquisition (PDCCH / PDSCH) Pre-conditions Once the MIB is decoded, a System Information Block Type 1 (SIB1) acquisition is performed.

[0123] Successful path Figure 18 The expected sequence in the context of a successful execution path is shown in accordance with some embodiments.

[0124] Random access This chapter describes the random access procedure. • Contention-based random access • Contention-free random access.

[0125] Prerequisites When the UE has acquired information from MIB and SIB1, it can start random access.

[0126] Success path Figure 19 The expected sequence in the context of a successful execution path is depicted according to some embodiments. Design assumptions - UE L1 accelerator does not perform PRACH power control, the transmission power should be configured by the UE L2 through a message - In case of random access failure, the UE L1 accelerator does not repeat the PRACH attempt.

[0127] Operation in some embodiments Figure 20 Operation of a user equipment (UE) physical layer server (e.g., a UE PHY server or a L1 server) is shown according to some embodiments. The UE physical layer server can be implemented in an electronic device such as the electronic device 2302, and the UE physical layer server can be the UE PHY server 234 or the L1 server 752 discussed above herein.

[0128] At reference number 2002, a request to allocate resources for a UE client is received from the UE client by a control endpoint of a UE physical layer server. At reference number 2004, upon determining to grant the request, internal resources of the UE physical layer server are allocated to the UE client, the internal resources including a context for the UE client corresponding to resources in the UE physical layer server for the UE client to communicate with a base station through the UE physical layer server. At reference number 2006, a handle is provided to the UE client, the handle to identify the UE client for interactions between the UE physical layer server and the UE client, the UE client to perform operations in one or more layers above a physical layer of the UE. At reference number 2008, one or more message exchanges are performed between the UE physical layer server and the UE client through a data endpoint of the UE physical layer server.

[0129] In some embodiments, the request includes one or more of a number of antennas, a frequency band, a bandwidth to be allocated to the UE client.

[0130] In some embodiments, the UE physical layer server is to initiate creation of one context for one UE client.

[0131] In some embodiments, the one or more layers above the physical layer of the UE include a medium access control (MAC) layer of the UE.

[0132] In some embodiments, messages exchanged between the UE physical layer server and the UE client indicate a corresponding timing of the messages, where the timing corresponds to one or more of a system frame number, a subframe, a slot, and a symbol.

[0133] In some embodiments, messages exchanged between the UE physical layer server and the UE client use buffers allocated and released based on a predefined time period.

[0134] In some embodiments, the control endpoint and the data endpoint of the UE physical layer server are implemented using an application programming interface (API). In some embodiments, the API defines message types and sizes of messages to be exchanged with the UE physical layer server. In some embodiments, the state of the UE physical layer server is configured and queried through the API. In some embodiments, based on a measurement request from the UE client, the UE physical layer server measures cells serving the UE client using one or more UE antennas coupled to a base station.

[0135] Figure 21 Operations of a user equipment (UE) client (e.g., a UE MAC client and / or a UE L2) are shown in accordance with some embodiments. The UE client can be implemented in an electronic device such as the electronic device 2302, and the UE client can be one or more of the UE MAC clients 252, 254 and the L2 / L3 instance 754 to interact with a UE physical layer server as described herein above.

[0136] At reference numeral 2102, service discovery is performed to find a control endpoint of a UE physical layer server. At reference numeral 2104, a request to allocate resources for a UE client is sent to the control endpoint of the UE physical layer server, the request indicating an identifier of the UE client. At reference numeral 2106, a handle is received from the UE physical layer server, and at reference numeral 2108, the handle is used to perform interactions between the UE client and the UE physical layer server.

[0137] In some embodiments, the request includes one or more of a number of antennas, a frequency band, a bandwidth to be allocated to the UE client.

[0138] In some embodiments, the control endpoint and the data endpoint of the UE physical layer server are implemented using an application programming interface (API).

[0139] In some embodiments, the handle is created based on the identifier of the UE client.

[0140] In some embodiments, the interactions between the UE client and the physical layer are based on a synchronized system clock between the UE client and the physical layer, and where the synchronized system clock is indicated by one or more of a system frame number, a subframe, a slot, and a symbol.

[0141] Radio resources used in wireless networks Figure 22A An example signal transmission hierarchy in a wireless network is shown. The example signal transmission hierarchy includes a transmission unit of a frame (e.g., radio frame 2202). In one embodiment, a radio frame 2202 takes 10 milliseconds to transmit. The frame can contain multiple subframes, e.g., subframe 2204. In this example, radio frame 2202 contains ten subframes, each taking one millisecond. Each subframe can contain multiple slots. For example, one subframe can contain two slots. Each slot, e.g., slot at reference 2206, can contain multiple symbols. In one example, a slot contains 7 or 14 symbols. In one embodiment, the symbols are orthogonal frequency division multiplexing (OFDM) symbols.

[0142] The frame-subframe-slot-symbol hierarchy is an example of a time domain hierarchy. In the frequency domain (as shown at reference 2232), each symbol can be transmitted on multiple subcarriers. A symbol can be transmitted using multiple resource blocks (RBs), each of which can contain 12 subcarriers in one embodiment. In one embodiment, each subcarrier includes a bandwidth for transmission (e.g., 7.5 kHz or 15 kHz). One subcarrier A symbol can be referred to as a resource element (RE), which is the smallest unit of resources to be allocated for signal transmission in one embodiment.

[0143] The frame structure shown provides an example of signal transmission. In this frame structure or other frame structures, data and signaling transmission is performed at the lowest level of time unit (in this case, the symbol level), which in one embodiment is contained in the level of time unit above the lowest level of time unit (in this example, the slot level). Data and signaling for one transmission from a source network device to a destination network device generally uses the same location in the signal transmission hierarchy, e.g., the same symbol location in a subframe or consecutive slots (e.g., symbol #2 of each slot), or a subframe or alternate slots (e.g., symbol #2 in every other slot).

[0144] Figure 22B Resource elements for data and signaling transmission are shown. The physical resources used for transmission can be viewed as a time and frequency grid as shown, where each resource element occupies a time period in the time domain and a frequency range in the frequency domain. Each OFDM symbol includes a cyclic prefix, as shown by reference number 2252. Each OFDM symbol utilizes multiple resource elements. In this example, the subcarrier spacing is 15 kHz, and a resource element (RE) 2252 occupies an orthogonal frequency-division multiplexing (OFDM) subcarrier within an OFDM symbol. The network device can allocate some resource elements for a particular type of signaling. Such an allocation can be specified by identifying a time period in the time domain and a frequency range in the frequency domain within a signaling transmission hierarchy; or can be specified by identifying a particular resource element within a signaling transmission hierarchy.

[0145] For downlink control, the wireless network can use the PDCCH (Physical Downlink Control Channel) to transmit downlink control information (DCI), which provides downlink scheduling assignments and uplink scheduling grants. The PDCCH is transmitted at the beginning of a slot and is related to data in the same or later slot in some embodiments (for mini-slots, the PDCCH can also be transmitted within a regular slot). Different formats (sizes) of the PDCCH can handle different DCI payload sizes and different aggregation levels (i.e., different code rates for a given payload size). A UE can be (implicitly and / or explicitly) configured to blindly monitor (or search) multiple PDCCH candidates of different aggregation levels and DCI payload sizes. Upon detecting a valid DCI message (e.g., the decoding of a candidate is successful and the DCI contains an ID that the UE is told to monitor), the UE follows the DCI (e.g., receives corresponding downlink data or transmits in the uplink). The blind decoding process comes at the expense of the UE’s complexity, but is needed to provide flexible scheduling and handle different DCI payload sizes.

[0146] Different NR use cases (e.g., MBB (Mobile Broadband), URLLC (Ultra-Reliable Low-Latency Communication)) require different control regions (e.g., time, frequency, numerology, etc.) and PDCCH configurations (e.g., operating points, etc.). PDCCH in NR is transmitted in configurable / dynamic control regions called control resource sets (CORESETs) to enable variable use cases. A CORESET is a subset of downlink physical resources configured to carry control signaling. It is similar to the control region in LTE, but broadly refers to the set of physical resource blocks (PRBs) and the set of OFDM symbols it is in are configurable.

[0147] In one embodiment, NR DL resource allocation Type 0: bitmap of RB groups (RBG) is used to complete CORESET configuration in frequency allocation in units of 6 RBs. CORESET configuration is within a time span of 1-3 consecutive OFDM symbols. For slot-based scheduling, if the demodulation reference signal (DMRS) is located in OFDM symbol (OS) #2, the CORESET span at the beginning of the slot is at most 2, and if the DMRS is located in OS #3, it is at most 3. A UE monitors one or more CORESETs. Multiple CORESETs of a UE can overlap in frequency and time.

[0148] Cloud implementation The invention is directly related to cloud usage, and when describing L1 and L2 procedures / units / entities, it should be understood that these can be deployed using different cloud technologies, e.g. by VMs, containers or Pods in Kubernetes.

[0149] O-RAN implementation The described invention directly supports the goals of O-RAN (decomposition, components possibly provided by different vendors), but focuses on the UE rather than the network side.

[0150] Impact on technical specifications In some embodiments, implementing the invention requires implementing various 3GPP procedures. To our knowledge, 3GPP does not directly cover soft UE implementation nor the specific aspects related to multiple emulated UEs.

[0151] Devices and systems implementing some embodiments Figure 23 An electronic device implementing a UE L1 / L2 interaction coordinator is shown in accordance with some embodiments. The electronic device can be a host in a cloud system, a network node / UE in a wireless / wired network, as well as an operating environment. Further embodiments of the host, network node, UE are discussed in more detail herein below.

[0152] The electronic device 2302 can be implemented using a custom application-specific integrated circuit (ASIC) as the processor and a dedicated operating system (OS), or using a general-purpose off-the-shelf (COTS) processor and a standard OS. In some embodiments, the electronic device 2302 implements a UE L1 / L2 interaction coordinator 2355 that performs the operations discussed herein above with respect to Figures 1-19 The electronic device can include a UE physical layer server, one or more UE clients (e.g. UE MAC clients), or a combination of both.

[0153] The electronic device 2302 includes hardware 2340 comprising a set of one or more processors 2342 (typically COTS processors or processor cores or ASICs) and physical NIs 2346, and a non-transitory machine-readable storage medium 2349 having stored therein software 2350. During operation, the one or more processors 2342 can execute the software 2350 to instantiate a set or multiple sets of one or more applications 2364A-R. While one embodiment does not implement virtualization, alternative embodiments can use different forms of virtualization. For example, in one such alternative embodiment, the virtualization layer 2354 represents a kernel of an operating system (or a shim program executing on an underlying operating system) that allows creation of multiple instances 2362A-R, called software containers, each of which can be used to execute one (or more) of the sets of applications 2364A-R. The multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically virtual memory spaces) that are isolated from each other and from the kernel space running the operating system. Unless explicitly permitted, a set of applications running in a given user space cannot access the memory of other processes. In another such alternative embodiment, the virtualization layer 2354 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 2364A-R runs on a guest operating system within an instance 2362A-R called a virtual machine (which in some cases can be viewed as a form of tightly isolated software container) running on top of the hypervisor - the guest operating system and applications can be unaware that they are running on a virtual machine rather than on a "bare metal" host electronic device, or through para-virtualization, the operating system and / or applications can be aware of the presence of virtualization for optimization purposes. In still other alternative embodiments, one, some or all of the applications are implemented as a mono-kernel, which can be generated by directly compiling the application with only a limited set of libraries (e.g., of a library operating system (LibOS) comprising OS services) that provide the specific OS services required by the application. As the mono-kernel can be implemented to run directly on the hardware 2340, directly on the hypervisor (in which case the mono-kernel is sometimes described as running within a LibOS virtual machine), or within a software container, embodiments can be implemented entirely as mono-kernels running directly on the hypervisor represented by the virtualization layer 2354, mono-kernels running within software containers represented by the instances 2362A-R, or as a combination of mono-kernels and the above techniques (e.g., mono-kernels and virtual machines both running directly on a hypervisor, mono-kernels and sets of applications running in different software containers).

[0154] UE L1 / L2 interworking coordinator 2355 can be instantiated within an application 2364A-R. The instantiation of one or more applications 2364A-B of one or more sets, and virtualization, if implemented, of the same is collectively referred to as software instance(s) 2352. Each set of applications 2364A-R, the corresponding virtualization construct (e.g., instances 2362A-R), if implemented, and that portion of the hardware 2340 (whether hardware and / or time slices of hardware that are dedicated to that execution or time shared) executing them form an individual virtual electronic device 2360A-R.

[0155] Network interfaces (NIs) can be physical or virtual. In the context of Internet Protocols (IP), an interface address is an IP address assigned to a NI, whether a physical NI or a virtual NI. Virtual NIs can be associated with physical NIs, other virtual interfaces, or exist independently (e.g., loopback interfaces, point-to-point protocol interfaces). NIs (physical or virtual) can be numbered (NIs with IP addresses) or unnumbered (NIs without IP addresses). NIs are shown as network interface cards (NICs) 2344. Physical network interfaces 2346 can include one or more antennas of the electronic device 2302. Antenna ports can or can not correspond to physical antennas. Antennas include one or more radio interfaces.

[0156] Wireless network according to some embodiments Figure 24 An example of a communication system is shown in accordance with some embodiments. In the example, the communication system 2400 includes a telecommunication network 2402, which comprises an access network 2404, for example a Radio Access Network (RAN), and a core network 2406, which comprises one or more core network nodes 2408. The access network 2404 comprises one or more access network nodes, such as network nodes 2410a and 2410b (one or more of which can be commonly referred to as network nodes 2410), or any other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 2410 facilitate direct or indirect connection of user equipment (UE) such as UEs 2412a, 2412b, 2412c, and 2412d (one or more of which can be commonly referred to as UEs 2412) to the core network 2406, e.g., by way of one or more wireless connections.

[0157] Example wireless communications via wireless connections include the transmission and / or reception of wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable to convey information over a distance without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 2400 can include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in communication of data and / or signals whether via wired or wireless connections. Communication system 2400 can include any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0158] UE 2412 can be any of a variety of communication devices, including wireless devices arranged, configured and / or operable to wirelessly communicate with network node 2410 and other communication devices. Similarly, network node 2410 is arranged, capable, configured and / or operable to communicate directly or indirectly with UE 2412 and / or with other network nodes or devices of telecommunication network 2402 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management in telecommunication network 2402.

[0159] In the depicted example, core network 2406 connects network node 2410 to one or more hosts, such as host 2416. These connections can be direct or indirect, such as through one or more intermediate networks or devices. In other examples, a network node can be directly coupled to a host. Core network 2406 includes one or more core network nodes (e.g., core network node 2408) constructed of hardware and software components. These components can be substantially similar to those described with respect to UEs, network nodes, and / or hosts such that their description generally applies to corresponding components of core network node 2408. Example core network nodes include functionality of one or more of a Mobile Switching Center (MSC), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Subscription Identifier De-concealing Function (SIDF), a Unified Data Management (UDM), a Security Edge Protection Proxy (SEPP), a Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0160] The host 2416 can be under the ownership or control of a service provider other than the operator or provider of the telecommunication network 2402 and / or the access network 2404, and can be operated by or on behalf of the service provider. The host 2416 can host various applications to provide one or more services. Examples of such applications include the following: live and pre-recorded audio / video content, data collection services (such as retrieving and compiling data on various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by servers.

[0161] Generally, Figure 24 The communication system 2400 enables connectivity between UEs, network nodes, and a host computer. In that sense, the communication system can be considered a connected system. The communication system can be configured to operate according to predefined technical specifications or standards, such as certain standards issued by an Standards Developing Organization (SDO), such as: Global System for Mobile Communications (GSM); Universal Mobile Telecommunication System (UMTS); Long Term

[0162] In some examples, the telecommunication network 2402 is a cellular network that implements 3GPP-standardized features. Thus, the telecommunication network 2402 can support network slicing to provide different logical networks for different devices connected to the telecommunication network 2402. For example, the telecommunication network 2402 can provide Ultra-Reliable and Low-Latency Communications (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or providing massive Machine Type Communications (mMTC) / massive IoT services to yet other UEs.

[0163] In some examples, the UEs 2412 are configured to transmit and / or receive information without direct human interaction. For example, a UE can be designed to transmit information to the access network 2404 on a pre-authorized basis at predetermined times based on internal or external events or responses to requests from the access network 2404. In addition, UEs can be configured for operation in single or multiple radio access technologies (multi-RAT) or multi-standard modes. For example, a UE can operate in any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., be configured for multi-radio dual connectivity (MR-DC) such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0164] In examples, the hub 2414 communicates with the access network 2404 to facilitate indirect communication between one or more UEs (e.g., UEs 2412c and / or 2412d) and a network node (e.g., network node 2410b). In some examples, the hub 2414 can be a controller, router, content source and analyzer, or any other communication device described herein with respect to UEs. For example, the hub 2414 can be a broadband router for the UEs that enables access to the core network 2406. As another example, the hub 2414 can be a controller that sends commands or instructions to one or more actuators in the UEs. The commands or instructions can be received from the UEs, the network nodes 2410, or can be received by executable code, scripts, processes, or other instructions in the hub 2414. As another example, the hub 2414 can be a data collector that acts as a temporary storage device for UE data, and in some embodiments, the hub 2414 can perform analysis or other processing of the data. As another example, the hub 2414 can be a content source. For example, for a UE that is a virtual reality (VR) headset, display, speaker, or other media delivery device, the hub 2414 can retrieve VR assets, video, audio, or other media or data related to sensory information via the network nodes, which the hub 2414 then provides to the UE directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 2414 acts as a proxy server or coordinator for the UEs, particularly if one or more of the UEs are low-energy loT devices.

[0165] The hub 2414 can have a constant / persistent or intermittent connection to the network node 2410b. The hub 2414 can also account for different communication schemes and / or schedules between the hub 2414 and UEs (e.g., UEs 2412c and / or 2412d) and between the hub 2414 and the core network 2406. In other examples, the hub 2414 is connected to the core network 2406 and / or one or more UEs via a wired connection. Further, the hub 2414 can be configured to connect to a machine-to-machine (M2M) service provider over the access network 2404 and / or to another UE over a direct connection. In some scenarios, a UE can establish a wireless connection with the network node 2410 while still being connected via a wired or wireless connection, via the hub 2414. In some embodiments, the hub 2414 can be a dedicated hub - that is, a hub whose primary function is to route communications from the network node 2410b to UEs / route communications from UEs to the network node 2410b. In other embodiments, the hub 2414 can be a non-dedicated hub - that is, a device that is capable of operating to route communications between UEs and the network node 2410b, but is additionally capable of operating as a communication origin and / or terminus for certain data channels.

[0166] UE according to some embodiments Figure 25 A user equipment (UE) according to some embodiments is shown. As used herein, a UE refers to a device that is capable, configured, arranged and / or operable to communicate wirelessly with a network node and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, a mobile phone, a cellular phone, a Voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-mounted device (LEE), a laptop-installed device (LME), a smart device, a wireless customer-premise equipment (CPE), a vehicle-mounted or vehicle-embedded wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including Narrow- Band Internet of Things (NB-IoT) UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs. The UE 2500 can be implemented with the UE physical layer server and UE MAC client discussed above herein.

[0167] A UE can support device-to-device (D2D) communication, e.g., by implementing 3GPP standards for sidelink communication, dedicated short range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-anything (V2X). In other examples, a UE can not necessarily have a user in the sense of a human user that owns and / or operates the related device. Rather, a UE can represent a device that is intended for sale to, or operation by, a human user but can not, or can not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE can represent a device that is not intended for sale to, or operation by, an end user but can be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0168] The UE 2500 includes processing circuitry 2502 operatively coupled to input / output interface 2506, power source 2508, memory 2510, communication interface 2512, and / or any other component(s) or subcomponents thereof, by way of bus 2504 or a similar communication means. Some of the components of the UE can have sub-components Figure 25 The level of integration between the components shown in FIG. 25 can vary from one UE to another UE. Additionally, some UE can contain multiple instances of a component, such as multiple processing circuitry 2502, memories, transceivers, transmitters, receivers, etc.

[0169] The processing circuitry 2502 is configured to process instructions and data and can be configured to implement any order- state machine operational to execute instructions stored in the memory 2510 as a machine-readable computer program. The processing circuitry 2502 can be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field programmable gate array (FPGA), application- specific integrated circuit (ASIC), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general purpose processors (e.g., microprocessors or digital signal processors (DSP)) together with appropriate software, or any combination of the above. For example, the processing circuitry 2502 can include multiple central processing units (CPUs).

[0170] In an example, the input / output interface 2506 can be configured to provide an interface or interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device can allow a user to capture information into the UE 2500. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital still or motion camera), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and so forth. A presence-sensitive display can include a capacitive or resistive touch sensor to sense input from a user. A sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biosensor, and so forth, or any combination thereof. An output device can use the same types of interfaces as an input device. For example, a universal serial bus (USB) port can be used to provide input to the UE 2500, as well as serve as an output device.

[0171] In some embodiments, the power supply 2508 is configured as a battery or battery pack. Other types of power supplies, such as an external power supply, photovoltaic device, or generator, can be used. The power supply 2508 can also include a power circuit to deliver power from the power supply 2508 and / or an external power source to portions of the UE 2500 via an interface or input circuit, such as a power cable. The delivered power can be used, for example, to charge the power supply 2508. The power circuit can perform any formatting, converting, or other modification to the power from the power supply 2508 to make the power suitable for use by components of the UE 2500 being powered.

[0172] The memory 2510 can be or include a memory such as a random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), magnetic disks, optical disks, hard drives, removable cartridges, flash drives, and / or the like. In one example, the memory 2510 includes one or more applications 2514 (such as an operating system, a web browser application, a widget, a gadget engine, or other application) and corresponding data 2516. The memory 2510 can store any of a variety of different operating systems, or combinations of operating systems, for use by the UE 2500.

[0173] Memory 2510 can be configured to include a plurality of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard drives, thumb drives, pen drives, key drives, High-Density Digital Versatile Disc (HD-DVD) optical disc drives, internal hard drives, Blu-Ray optical disc drives, Holographic Digital Data Storage (HDDS) optical disc drives, external mini-dual in-line memory modules (DIMMs), synchronous dynamic random access memory (SDRAM), external micro-DIMMs, smart card memory (including one or more subscriber identity modules (SIMs), such as a Universal Integrated Circuit Card (UICC), including a Universal Subscriber Identity Module (USIM) and / or an IP Multimedia Services Identity Module (ISIM), a tamper-resistant module such as in the form of a UICC, other memory, or any combination thereof). The UICC may, for example, be an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." Memory 2510 can allow UE 2500 to access instructions, application programs, and the like stored on transitory or non-transitory memory media to off-load data or to upload data. An article of manufacture, such as of a machine-accessible medium, can have tangible, physical manifestations of the article such as memory 2510 or be contained in memory 2510, which can be or include a device readable storage medium.

[0174] Processing circuitry 2502 can be configured to communicate with an access network or other networks using communication interface 2512. Communication interface 2512 can include one or more communication subsystems and can include, or be, a communication interface coupled to one or more antennas 2522. Communication interface 2512 can include one or more transceivers used to communicate with one or more remote transceivers, such as a network node in an access network or another UE capable of wireless communication. Each transceiver can include a transmitter 2518 and / or a receiver 2520 adapted to provide network communications, such as optical, electrical, and / or frequency-based communications. Further, transmitter 2518 and receiver 2520 can be coupled to one or more antennas, such as antenna 2522, and can share circuit components, software, or firmware, or alternatively can be implemented separately.

[0175] In the illustrated embodiment, the communication functionality of the communication interface 2512 can include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as determining a location using the global positioning system (GPS), another like communication functionality, or any combination thereof. The communication can be implemented in accordance with one or more communication protocols and / or standards such as IEEE 802.11, code division multiple access (CDMA), wideband code division multiple access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), Quick UDP Internet Connections (QUIC), Hypertext Transfer Protocol (HTTP), and / or the like.

[0176] Regardless of the type of sensor, the UE can provide an output of data captured by its sensor through its communication interface 2512 or via a wireless connection to a network node. Data captured by a sensor of the UE can be communicated via another UE, through a wireless connection to a network node. The output can be periodic (e.g., every 15 minutes if it reports sensed temperature), random (e.g., to balance the load of reports from several sensors), in response to a triggering event (e.g., sending an alarm when moisture is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0177] As another example, the UE includes an actuator, motor, or switch related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch can change. For example, the UE can include a control surface or rotor of a drone in flight that is adjusted according to the received input or a motor of a robotic arm performing a medical procedure that is adjusted according to the received input.

[0178] A UE, when in the form of an Internet of Things (IoT) device, can be a device that is used for use in one or more application domains, including, but not limited to, urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are devices that are, or are embedded in, a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robotic vacuum cleaner, a voice-controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / water sensor, an electric door lock, a connected doorbell, a heat-pump-like air conditioning system, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for augmented reality (AR) or virtual reality (VR), a wearable device for haptics or sensory augmentation, a sprinkler, an animal or item tracking device, a sensor for monitoring plants or animals, an industrial robot, an unmanned aerial vehicle (UAV), and any kind of medical device like a heart rate monitor or a remotely controlled surgical robot. In addition to the other components described with respect to the UE 2500 shown in FIG. 6, a UE in the form of an IoT device includes circuit and / or software that is dependent on the intended application of the IoT device. Figure 25

[0179] As yet another specific example, in an IoT scenario, a UE can represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE in this case could be a machine-to-machine (M2M) device, which in a 3GPP context can be referred to as an MTC device. As one specific example, a UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle, such as an automobile, a bus, a truck, a boat, and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0180] In fact, any number of UEs can be used together with respect to a single use case. For example, a first UE can be an unmanned aerial vehicle or can be integrated into an unmanned aerial vehicle and provide speed information of the unmanned aerial vehicle (obtained by a speed sensor) to a second UE that is a remote control that operates the unmanned aerial vehicle. When the user makes a change from the remote control, the first UE can adjust a throttle valve on the unmanned aerial vehicle (e.g., by controlling an actuator) to increase or decrease the speed of the unmanned aerial vehicle. The first and / or second UE can also include more than one of the functions described above. For example, a UE can include a sensor and an actuator and handle the communication of data for both the speed sensor and the actuator.

[0181] ​A network node according to some embodiments Figure 26 A network node according to some embodiments is shown. As used herein, a network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).

[0182] Base stations can be categorized based on the amount of coverage they provide (or, in other words, their transmission power level) and thus, depending on the provided coverage, base stations can be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station can be a relay node, or a relay-donating node controlling relays. A network node can also include one or more (or all) parts of a distributed radio base station, such as centralized core, and / or one or more (or all) parts of a remote radio unit (RRU), also known as a remote radio head (RRH). Such a remote radio unit can or can not be integrated with an antenna, as an antenna-integrated radio. Parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0183] Other examples of network nodes include multi -transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Center (E-SMLC)), and / or minimizing drive testing (MDT).

[0184] The network node 2600 includes processing circuitry 2602, memory 2604, communication interface 2606, and power source 2608. The network node 2600 can be composed of multiple physically separate components (e.g., Node B components and RNC components, or BTS components and BSC components, etc.), which can each have their own respective components. In certain scenarios in which the network node 2600 includes multiple separate components (e.g., BTS and BSC components), one or more of the separate components can be shared among several network nodes. For example, a single RNC can control multiple Node Bs. In such a scenario, each unique Node B and RNC pair, in some instances, can be considered a single independent network node. In some embodiments, the network node 2600 can be configured to support multiple radio access technologies (RATs). In such embodiments, some components can be duplicated (e.g., separate memory 2604 for

[0185] The processing circuitry 2602 can comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other processing circuit, or any combination thereof, as well as any other processing circuitry as will be readily appreciated by those of ordinary skill in the art. The processing circuitry 2602 can be implemented as a combination of different processors, such as a combination of one or more processors and one or more microcontrollers.

[0186] In some embodiments, the processing circuitry 2602 includes a system on a chip (SOC). In some embodiments, the processing circuitry 2602 includes one or more of radio frequency (RF) transceiver circuitry 2612 and baseband processing circuitry 2614. In some embodiments, radio frequency (RF) transceiver circuitry 2612 and baseband processing circuitry 2614 can be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 2612 and baseband processing circuitry 2614 can be on the same chip or set of chips, boards, or units.

[0187] Memory 2604 can include any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a compact disk (CD), or a digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that can be used with processing circuitry 2602. Memory 2604 can store any

[0188] Communication interface 2606 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As demonstrated, communication interface 2606 includes port(s) / terminal(s) 2616 to send and receive data, for example, to and from a network through a wired connection. Communication interface 2606 also includes radio front-end circuitry 2618 that can be coupled to, or in some embodiments a part of, antenna 2610. Radio front-end circuitry 2618 includes filters 2620 and amplifiers 2622. Radio front-end circuitry 2618 can be connected to antenna 2610 and processing circuitry 2602. Radio front-end circuitry can be configured to condition signals communicated between antenna 2610 and processing circuitry 2602. Radio front-end circuitry 2618 can receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front-end circuitry 2618 can convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using combinations of filters 2620 and / or amplifiers 2622. The radio signal can then be transmitted via antenna 2610. Similarly, when receiving data, antenna 2610 can collect radio signals, which are then converted into digital data by radio front-end circuitry 2618. The digital data can be passed on to processing circuitry 2602. In other embodiments, communication interface can include different components and / or different combinations of components.

[0189] In certain alternative embodiments, network node 2600 does not include separate radio front-end circuitry 2618, instead, processing circuitry 2602 includes radio front-end circuitry and is connected to antenna 2610. Similarly, in some embodiments, all or some of RF transceiver circuitry 2612 is part of communication interface 2606. In still other embodiments, communication interface 2606 includes one or more ports or terminals 2616, radio front-end circuitry 2618, and RF transceiver circuitry 2612 as part of a radio

[0190] Antenna 2610 can include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna 2610 can be coupled to radio front-end circuitry 2618 and can be any type of antenna and / or antenna array capable of inducting and / or radiating wireless communications (e.g., radio frequency, microwave, infrared, optical, etc.). In certain embodiments, antenna 2610 is separate from network node 2600 and is connectable to network node 2600 through an interface or port.

[0191] Antenna 2610, communication interface 2606, and / or processing circuitry 2602 can be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by a network node. Any information, data and / or signals can be received from a UE, another network node and / or any other network equipment. Similarly, antenna 2610, communication interface 2606, and / or processing circuitry 2602 can be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data and / or signals can be transmitted to a UE, another network node and / or any other network equipment.

[0192] Power source 2608 provides power to various components of network node 2600 in a form suitable for use by each respective component (e.g., at a voltage and current level needed for each respective component). Power source 2608 can also include, or be coupled to, power management circuits to supply, control, and regulate the power to components of network node 2600 for performing the functionality described herein. For example, network node 2600 can be connectable to an external power source (e.g., an electricity outlet), via an input circuitry or interface, such as an electrical cable, whereby the external power source supplies power to the power supply circuitry of the power source 2608. As a further example, power source 2608 can comprise one or more electrically rechargeable batteries or batteries having a certain energy storage capacity to provide the power supply for network node 2600, connected to, or integrated into, the power supply circuitry. If the external power source fails, the battery can provide the backup power supply.

[0193] Embodiments of network node 2600 can include fewer, more, and / or different components than those shown in FIG. 26. Additionally, or alternatively, one or more components of network node 2600 can perform one or more functions described as being performed by a different component. Figure 26 Additional components beyond those shown in FIG. 26 can be included in the network node 2600 for providing various aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary for supporting the subject matter described herein. For example, the network node 2600 can include user interface equipment to allow input of information into the network node 2600 and to allow output of information from the network node 2600. This can allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 2600.

[0194] Host according to some embodiments Figure 27 Host 2700, in accordance with various aspects described herein, can be or include various combinations of hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or a processing resource in a server farm. The host 2700 can provide one or more services to one or more UEs. In some embodiments, the host 2700 can implement a UE physical layer server and / or a UE MAC client, as discussed above herein. Figure 24

[0195] The host 2700 includes processing circuitry 2702, which is operatively coupled to input / output interface 2706, network interface 2708, power source 2710, and memory 2712 via bus 2704. Other embodiments can include additional or different components. Features of these components can be similar to those described with respect to the devices of previous figures, such as the UE 200 and the host 2300, such that the description of those features generally applies to the corresponding components of the host 2700. Figure 25 and Figure 26

[0196] ​​Memory 2712 can include one or more computer programs, including one or more host applications 2714 and data 2716, which can include user data (e.g., data generated by a UE for the host 2700 or data generated by the host 2700 for a UE). Embodiments of the host 2700 can utilize only a subset of the components shown or utilize all of the components shown. Host applications 2714 can be implemented in a container-based architecture and can provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), Motion Picture Experts Group (MPEG), VP9) and audio codecs (e.g., Free Lossless Audio Codec (FLAC), Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types, or implementations of UEs (e.g., cellphones, desktop computers, wearable display systems, heads-up display systems). Host applications 2714 can also provide user authentication and permission checks and can periodically report health, routing, and content availability to a central node, such as a device in the core network or on the edge. Thus, the host 2700 can select and / or instruct different hosts for over-the-top services for UEs. Host applications 2714 can support various protocols, such as HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0197] Virtualized environment according to some embodiments Figure 28 is a block diagram illustrating a virtualized environment in which functions implemented by some embodiments can be virtualized. In this context, virtualization means the creation of virtual versions of devices or devices that can include virtualized hardware platforms, storage devices, and networking resources. As used herein, virtualization can apply to any device or component thereof described herein and relate to implementations in which at least a portion of the functionality is implemented as a virtual component executed by one or more virtual machines implemented in one or more virtual environments 2800 hosted by one or more hardware computing devices, such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts. In addition, in embodiments in which a virtual node does not require radio connectivity (e.g., a core network node or a host), then the node can be entirely virtualized.

[0198] The application 2802 (which alternatively can be referred to as a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) running in the virtualization environment 2800 is to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0199] The hardware 2804 comprises processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware that can be used by the hardware processing circuitry, such as network interfaces, input / output interfaces, etc. as described herein. The software can be executable by the processing circuitry to instantiate one or more virtualization layers 2806 (also referred to as a hypervisor or virtual machine monitor (VMM)) to provide VMs 2808a and 2808b (one or more of which can be generally referred to as VM 2808), and / or to execute any of the functions, features and / or benefits described in relation with some of the embodiments described herein. The virtualization layer 2806 can present a virtual operating platform that appears like networking hardware to the VMs 2808.

[0200] The VMs 2808 comprise virtualized processing, memory, networking or interface, and storage, and can be run by a corresponding virtualization layer 2806. Different embodiments of the instance of virtual appliance 2802 can be implemented on one or more of the VMs 2808, and can be implemented in different ways. Virtualization of the hardware is sometimes referred to as Network Function Virtualization (NFV). NFV can be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches and physical storage, which can be located in data centers, and customer premise equipment.

[0201] In the context of NFV, the VMs 2808 can be software implementations of physical machines that run programs just as if they were executing on physical, non-virtualized, machines. Each VM 2808, along with the hardware 2804 of that VM, whether it is hardware dedicated to that VM and / or hardware shared by that VM with others, form a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for handling a specific network function that is run in one or more VMs 2808 on top of hardware 2804 and corresponds to the application 2802.

[0202] Hardware 2804 can be implemented in a standalone network node with general or specific components. Hardware 2804 can utilize virtualization to implement some functions. Alternatively, hardware 2804 can be part of a larger hardware cluster (e.g., in a data center or CPE), where many hardware nodes work together and are managed via management and orchestration 2810, which in particular also oversees the lifecycle management of application 2802. In some embodiments, hardware 2804 is coupled to one or more radio units, each including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units can communicate directly with other hardware nodes via one or more suitable network interfaces and can be combined with virtual components to provide radio capabilities to virtual nodes, such as radio access nodes or base stations. In some embodiments, control system 2812 can be used to provide signaling, and control system 2812 can alternatively be used for communication between hardware nodes and radio units.

[0203] Communication between a host, a network node, and a UE according to some embodiments Figure 29 A communication diagram is shown for a host communicating with a UE via a network node through a partial wireless connection, according to some embodiments. Reference will now be made to... Figure 29 To describe the UEs discussed in the preceding paragraphs (such as...) Figure 24 UE 2412a and / or Figure 25 UE 2500), network nodes (such as Figure 24 Network node 2410a and / or Figure 26 Network node 2600) and hosts (such as Figure 24 Host 2416 and / or Figure 27 Example implementations of the host 2700 according to various embodiments.

[0204] Like host 2700, embodiments of host 2902 include hardware such as a communication interface, processing circuitry, and memory. Host 2902 also includes software stored in or accessible by host 2902 and executable by the processing circuitry. The software includes a host application operable to provide services to a remote user, such as UE 2906 connected via an over-the-top (OTT) connection 2950 extending between UE 2906 and host 2902. In providing services to a remote user, the host application can provide user data transmitted using the OTT connection 2950.

[0205] The network node 2904 includes hardware that enables it to communicate with the host 2902 and with the UE 2906. The connection 2960 can be a direct connection or a connection over a core network (like core network 2406) and / or one or more other intermediate networks (such as one or more public, private, or hosted networks). For example, the intermediate network(s) can be a backbone network or the Internet. Figure 24

[0206] The UE 2906 includes hardware and software, the software being stored in or accessible by the UE 2906 and executable by processing circuitry of the UE. The software includes a client application, such as a web browser or a special application (e.g., a "thin" or "thick" client), that can be operable to provide a service to a human or non-human user via the UE 2906 with the support of the host 2902. In the host 2902, an executing host application can communicate with the executing client application via OTT connection 2950 terminating at the UE 2906 and the host 2902. In providing the service to the user, the UE's client application can receive request data from and provide user data to the host's host application, OTT connection 2950 carrying both the request data and the user data. The UE's client application can interact with the user to generate user data that it provides over OTT connection 2950 to the host application.

[0207] OTT connection 2950 can extend via connection 2960 between host 2902 and network node 2904, and via wireless connection 2970 between network node 2904 and UE 2906, to provide a

[0208] ​As an example of transmitting data via OTT connection 2950, in step 2908, host computer 2902 provides user data, which can be provided in response to execution of a host application. In some embodiments, the user data is associated with a particular human user interacting with UE 2906. In other embodiments, the user data is associated with UE 2906, the UE 2906 sharing data without explicit human interaction. In step 2910, host computer 2902 initiates a transmission carrying the user data towards UE 2906. Host computer 2902 can initiate the transmission in response to a request transmitted by UE 2906. The request can be elicited by a human interaction with UE 2906, or by an operation of a client application executed on UE 2906. The transmission can pass through network node 2904, according to the teachings of the embodiments described throughout this disclosure. Therefore, in step 2912, network node 2904 transmits to UE 2906 the user data that was carried in the transmission that was initiated by host computer 2902, according to the teachings of the embodiments described throughout this disclosure. In step 2914, UE 2906 receives the user data that was carried in the transmission, which can be executed by a client application associated with the host application that was executed by host computer 2902.

[0209] In some examples, UE 2906 executes a client application that provides user data to host computer 2902. The user data can be provided in reaction to the data received from host computer 2902 or in response to the user interface of the client application. Thus, in step 2916, UE 2906 can provide user data, which can be executed by executing a client application. In providing the user data, the client application can also take into account user input received from a user via an input / output interface of UE 2906. Regardless of the specific manner in which the user data is provided, UE 2906 initiates, in step 2918, a transmission of the user data towards host computer 2902 via network node 2904. In step 2920, network node 2904 receives the user data from UE 2906 and initiates a transmission of the received user data towards host computer 2902, according to the teachings of the embodiments described throughout this disclosure. In step 2922, host computer 2902 receives the user data carried in the transmission initiated by UE 2906.

[0210] In an example scenario, factory status information can be collected and analyzed by the host computer 2902. As another example, the host computer 2902 can process audio and video data that can have been retrieved from the UE for creating a map. As another example, the host computer 2902 can collect and analyze real-time data to assist in controlling traffic congestion, e.g., controlling traffic lights. As another example, the host computer 2902 can store monitoring videos uploaded by UEs. As another example, the host computer 2902 can store or control access to media content, such as videos, audio, VR or AR, that it can broadcast, multicast, or unicast to UEs. As further examples, the host computer 2902 can be used for energy pricing, for balancing power generation needs, location services, representation services such as compiled maps from data collected from remote devices, remote control of non-time critical power loads, or any other functionality that collects, retrieves, stores, analyzes and / or transfers data.

[0211] In some embodiments, a measurement procedure can be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There can further be an optional network functionality to reconfigure the OTT connection 2950 between the host computer 2902 and the UE 2906, in response to variations in the measurement results. The measurement procedure and / or the network functionality to reconfigure the OTT connection can be implemented in software and hardware of the host computer 2902 and / or the UE 2906. In some embodiments, sensors (not shown) can be deployed in or in association with other devices through which the OTT connection 2950 passes; the sensors can participate in the measurement procedure by providing values of the monitored quantities exemplified above, or providing values of other physical quantities from which software can compute or estimate the monitored quantities. The reconfiguration of the OTT connection 2950 can include message format, retransmission settings, preferred routing etc.; the reconfiguration need not

[0212] Although the computing devices described herein (e.g., UEs, network nodes, hosts) can include the combination of hardware components as illustrated, other embodiments can include computing devices with different combinations of components. It is contemplated that these computing devices can include any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determinations, calculations, or similar operations described herein can be performed by processing circuitry, which can process information, e.g., by transforming the information into other information, comparing the information to information stored in the network node, and / or performing one or more operations based on the information and / or results of the transformations and / or comparisons, and as a result, make a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices can include multiple different physical components constituting a single illustrated component, and the functionality can be divided between separate components. For example, a communication interface can be configured to include any of the components described herein, and / or the functionality of the components can be divided between the processing circuitry and the communication interface. In another example, non-computationally intensive functionality of any of such components can be implemented in software or firmware and computationally intensive functionality can be implemented in hardware.

[0213] In certain embodiments, some or all of the functionality described herein can be provided by a processing circuitry executing instructions stored in a memory, which in certain embodiments can be a computer program product in the form of a non-transitory computer readable storage medium. In alternative embodiments, some or all of the functionality can be provided by a processing circuitry without executing instructions stored by a separate or discrete device readable storage medium, e.g., in a hardwired manner. In any of these particular embodiments, whether executing instructions stored on a non-transitory computer readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry or to other components of the computing device alone, but are enjoyed by the computing device as a whole and / or by end users and wireless networks generally.

[0214] Terminology Reference in the specification to "one embodiment", "an embodiment”, "example embodiment”, or the like, means that a described embodiment can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, these phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of those in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described herein.

[0215] The specification and claims can use the term "coupled" and "connected" along with their derivatives. Such terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements, which can or can not be in direct physical or electrical contact with each other, co-operate or interact with each other. "Connected" is used to indicate the establishment of a wireless or wired communication between two or more elements. As used herein, "set" or "set of" can mean any integer number of items including one item.

[0216] Electronic devices, such as electronic device 2302, use machine-readable media ("computer-readable media") to store and transmit (internally and / or with other electronic devices over a network) code (composed of software instructions and sometimes called computer program code or computer program) and / or data, machine-readable media such as machine-readable storage media (e.g., magnetic disks; optical disks; solid state drives; read-only memory (ROM); flash memory devices; phase-change memory) and machine- readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustic, or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., a processor is a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), another electronic circuit, or a combination of any of the foregoing, which is coupled to one or more machine-readable storage media to store code executed by the set of processors and / or to store data. For example, an electronic device can include non-volatile memory including code that persists even when the electronic device is turned off (when power is removed). The portion of the code that the processor(s) of an electronic device are to execute is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of the electronic device when the electronic device is turned on. A typical electronic device also includes a set of one or more physical network interfaces (NIs) for establishing network connections with other electronic devices (to transmit and / or receive code and / or data using propagated signals). For example, a set of physical NIs (or a combination of a set of physical NIs and a set of processors executing code) can perform any formatting, encoding, or translating to allow the electronic device to send and receive data over wired and / or wireless connections. In some embodiments, a physical NI can include radio circuitry capable of (1) receiving data from other electronic devices over a wireless connection and / or (2) sending data to other devices over a wireless connection. The radio circuitry can include transmitter(s), receiver(s), and / or transceiver(s) suitable for radio frequency communications. The radio circuitry can convert digital data into radio signals having appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signals can then be transmitted through an antenna to the appropriate recipient(s). In some embodiments, the set of physical NIs can include network interface controller(s) (NICs), also known as network interface cards, network adapters, or local area network (LAN) adapters. The NIC(s) can facilitate connecting an electronic device to other electronic devices, allowing them to communicate in wired fashion by plugging cables into physical ports connected to the NICs.One or more portions of an embodiment of the application can be implemented using different combinations of software, firmware, and / or hardware.

[0217] The terms "module," "logic," and "unit" as used herein can refer to a circuit for performing a specified function. In some embodiments, the specified function can be performed by the circuit in conjunction with software (e.g., software executed by a general purpose processor).

[0218] Any appropriate steps, methods, features, functions, or benefits disclosed herein can be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus can comprise a number of these functional units. These functional units can be implemented by processing circuitry, which can include one or more microprocessor or microcontrollers, as well as other digital hardware, which can include digital signal processors (DSPs), special-purpose computer chips, application- specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other discrete or integrated logic or circuitry. The processing circuitry can be configured to execute program code stored in memory, which can include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data

[0219] The term "unit" can have the conventional meaning in the field of electronics, electrical devices and / or electronic devices, and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete electrical components, computer programs or instructions, etc., for performing various tasks, processes, computations, outputs, and / or displays, as described herein, for example. Embodiments A group of embodiments 1. A method of a user equipment (UE) physical layer server interacting with one or more UE clients, comprising: receiving (2002), by a control endpoint of the UE physical layer server, a request from a UE client to allocate resources for the UE client; upon determining to grant the request, allocating (2004) internal resources of the UE physical layer server to the UE client, the internal resources comprising a context for the UE client corresponding to resources in the UE physical layer server for the UE client to communicate with a base station through the UE physical layer server; providing (2006) a handle to the UE client, the handle to be used to identify the UE client for interaction between the UE physical layer server and the UE client, the UE client operating in one or more layers above a physical layer of a UE; and performing (2008) a message exchange between the UE physical layer server and the UE client through a data endpoint of the UE physical layer server. 2. The method of embodiment 1, wherein the request includes one or more of a number of antennas, a frequency band, a bandwidth to be allocated to the UE client. 3. The method of embodiment 1, wherein the UE physical layer server is to initiate creation of one context for one UE client. 4. The method of embodiment 1, wherein the one or more layers above a physical layer of a UE include a medium access control (MAC) layer of the UE. 5. The method of embodiment 1, wherein messages exchanged between the UE physical layer server and the UE client are indicated with a corresponding timing of the messages, wherein timing indication corresponds to one or more of a system frame number, a subframe, a time slot, and a symbol. 6. The method of embodiment 1, wherein messages exchanged between the UE physical layer server and the UE client use a buffer allocated and released based on a predefined time period. 7. The method of embodiment 1, wherein the control endpoint and the data endpoint of the UE physical layer server are implemented using an application programming interface (API). 8. The method of embodiment 7, wherein the API defines message types and sizes of messages to be exchanged with the UE physical layer server. 9. The method of embodiment 7, wherein the API is used to configure and query a status of the UE physical layer server. 10. The method of embodiment 7, wherein based on a measurement request from the UE client, the UE physical layer server measures a cell serving the UE client using one or more UE antennas coupled to the base station. Group B Embodiments 11. A method of a user equipment (UE) client interacting with a UE physical layer server, comprising: running (2102) a service discovery to find a control endpoint of the UE physical layer server; sending (2104) to the control endpoint of the UE physical layer server a request to allocate resources for the UE client, the request indicating an identifier of the UE client; receiving (2106) from the UE physical layer server a handle; and performing (2108) interactions between the UE client and the physical layer server using the handle. 12. The method of embodiment 11, wherein the request comprises one or more of a number of antennas, a frequency band, a bandwidth to be allocated to the UE client. Group C embodiments 13. An electronic device for a user equipment (UE) physical layer server to interact with one or more UE clients, comprising: processing circuitry configured to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry. 14. An electronic device for a user equipment (UE) physical layer server to interact with one or more UE clients, comprising: processing circuitry configured to perform any of the steps of any of the Group B embodiments; and power supply circuitry configured to supply power to the processing circuitry. 15. An electronic device for a user equipment (UE) physical layer server to interact with one or more UE clients, comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and processing circuitry and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the electronic device. 16. A host configured to operate in a communication system, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group A or Group B embodiments to transfer the user data from the host to the UE. 17. The host of the preceding embodiment, wherein: the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE includes processing circuitry configured to execute a client application associated with the host application to receive transmission of user data from the host. 18. A communication system, comprising: a host, the host including: processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with an over-the-top service; and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transfer the user data from the host to the UE. 19. The communication system of the preceding embodiment, further comprising: the network node; and / or the UE.< / gphyifpuschallocmsg> < / t> < / t>

Claims

1. A method for a user equipment (UE) physical layer server to interact with one or more UE clients, comprising: The UE physical layer server receives (2002) a request to allocate resources to the UE client from the UE client via its control endpoint; When it is determined that the request should be granted, the internal resources of the UE physical layer server are allocated (2004) to the UE client. The internal resources include a context for the UE client corresponding to the resources in the UE physical layer server, so that the UE client can communicate with the base station through the UE physical layer server. Provide the UE client with a (2006) handle, the handle being used to identify the UE client for interaction between the UE physical layer server and the UE client, the UE client performing operations in one or more layers above the UE's physical layer; as well as One or more message exchanges (2008) are performed between the UE physical layer server and the UE client via the data endpoint of the UE physical layer server.

2. The method according to claim 1, wherein, The request includes one or more of the following: number of antennas, frequency band, and bandwidth to be allocated to the UE client.

3. The method according to claim 1 or 2, wherein, The UE physical layer server needs to initiate the creation of a context for a UE client.

4. The method according to any one of claims 1 to 3, wherein, The one or more layers above the physical layer of the UE include the Media Access Control (MAC) layer of the UE.

5. The method according to any one of claims 1 to 4, wherein, The message exchanged between the UE physical layer server and the UE client indicates the corresponding timing of the message, wherein the timing indication corresponds to one or more of the system frame number, subframe, time slot and symbol.

6. The method according to any one of claims 1 to 5, wherein, Messages exchanged between the UE physical layer server and the UE client use buffers that are allocated and released based on predefined time periods.

7. The method according to any one of claims 1 to 6, wherein, The control endpoint and the data endpoint of the UE physical layer server are implemented using an application programming interface (API).

8. The method according to claim 7, wherein, The API defines the message type and size of the messages to be exchanged with the UE physical layer server.

9. The method according to claim 7, wherein, The API is used to configure and query the status of the UE physical layer server.

10. The method according to claim 7, wherein, Based on a measurement request from the UE client, the UE physical layer server uses one or more UE antennas coupled to the base station to measure the cell serving the UE client.

11. An electronic device (2302) for enabling interaction between a user equipment (UE) physical layer server and one or more UE clients, comprising: A processor (2342) and a non-transitory machine-readable storage medium (2349) provide instructions that, when executed by the processor (2342), cause the electronic device (2302) to perform: The UE physical layer server receives (2002) a request to allocate resources to the UE client from the UE client via its control endpoint; When it is determined that the request should be granted, the internal resources of the UE physical layer server are allocated (2004) to the UE client. The internal resources include a context for the UE client corresponding to the resources in the UE physical layer server, so that the UE client can communicate with the base station through the UE physical layer server. Provide the UE client with a (2006) handle, the handle being used to identify the UE client for interaction between the UE physical layer server and the UE client, the UE client performing operations in one or more layers above the UE's physical layer; as well as One or more message exchanges (2008) are performed between the UE physical layer server and the UE client via the data endpoint of the UE physical layer server.

12. The electronic device according to claim 11, wherein, The request includes one or more of the following: number of antennas, frequency band, and bandwidth to be allocated to the UE client.

13. The electronic device according to claim 11 or 12, wherein, The UE physical layer server needs to initiate the creation of a context for a UE client.

14. The electronic device according to any one of claims 11 to 13, wherein, The one or more layers above the physical layer of the UE include the Media Access Control (MAC) layer of the UE.

15. The electronic device according to any one of claims 11 to 14, wherein, The message exchanged between the UE physical layer server and the UE client indicates the corresponding timing of the message, wherein the timing indication corresponds to one or more of the system frame number, subframe, time slot and symbol.

16. The electronic device according to any one of claims 11 to 15, wherein, Messages exchanged between the UE physical layer server and the UE client use buffers that are allocated and released based on predefined time periods.

17. The electronic device according to any one of claims 11 to 16, wherein, The control endpoint and the data endpoint of the UE physical layer server are implemented using an application programming interface (API).

18. The electronic device according to claim 17, wherein, The API defines the message type and size of the messages to be exchanged with the UE physical layer server.

19. The electronic device according to claim 17, wherein, The API is used to configure and query the status of the UE physical layer server.

20. The electronic device according to claim 17, wherein, Based on a measurement request from the UE client, the UE physical layer server uses one or more UE antennas coupled to the base station to measure the cell serving the UE client.

21. A non-transitory machine-readable storage medium (2349) providing instructions that, when executed by a processor (2342) of an electronic device (2302), cause the electronic device (2302) to perform: The user equipment (UE) physical layer server receives (2002) a request to allocate resources to the UE client from the UE client via the control endpoint; When it is determined that the request should be granted, the internal resources of the UE physical layer server are allocated (2004) to the UE client. The internal resources include a context for the UE client corresponding to the resources in the UE physical layer server, so that the UE client can communicate with the base station through the UE physical layer server. Provide the UE client with a (2006) handle, the handle being used to identify the UE client for interaction between the UE physical layer server and the UE client, the UE client performing operations in one or more layers above the UE's physical layer; as well as One or more message exchanges (2008) are performed between the UE physical layer server and the UE client via the data endpoint of the UE physical layer server.

22. The electronic device according to claim 21, wherein, The request includes one or more of the following: number of antennas, frequency band, and bandwidth to be allocated to the UE client.

23. The electronic device according to claim 21 or 22, wherein, The UE physical layer server needs to initiate the creation of a context for a UE client.

24. The electronic device according to any one of claims 21 to 23, wherein, The one or more layers above the physical layer of the UE include the Media Access Control (MAC) layer of the UE.

25. The electronic device according to any one of claims 21 to 24, wherein, The message exchanged between the UE physical layer server and the UE client indicates the corresponding timing of the message, wherein the timing indication corresponds to one or more of the system frame number, subframe, time slot and symbol.

26. The electronic device according to any one of claims 21 to 25, wherein, Messages exchanged between the UE physical layer server and the UE client use buffers that are allocated and released based on predefined time periods.

27. The electronic device according to any one of claims 21 to 26, wherein, The control endpoint and the data endpoint of the UE physical layer server are implemented using an application programming interface (API).

28. The electronic device according to claim 27, wherein, The API defines the message type and size of the messages to be exchanged with the UE physical layer server.

29. The electronic device according to claim 27, wherein, The API is used to configure and query the status of the UE physical layer server.

30. The electronic device according to claim 27, wherein, Based on a measurement request from the UE client, the UE physical layer server uses one or more UE antennas coupled to the base station to measure the cell serving the UE client.

31. A method for interaction between a user equipment (UE) client and a UE physical layer server, comprising: Perform service discovery (2102) to locate the control endpoint of the UE physical layer server; Send (2104) a request to allocate resources for the UE client to the control endpoint of the UE physical layer server, the request indicating the identifier of the UE client; Receive the (2106) handle from the UE physical layer server; as well as The handle is used to perform (2108) interaction between the UE client and the UE physical layer server.

32. The method according to claim 31, wherein, The request includes one or more of the following: number of antennas, frequency band, and bandwidth to be allocated to the UE client.

33. The method according to claim 31 or 32, wherein, The control endpoint is identified using either an Internet Protocol (IP) address or a port number.

34. The method according to any one of claims 31 to 33, wherein, The handle is created based on the identifier of the UE client.

35. The method according to any one of claims 31 to 34, wherein, The interaction between the UE client and the UE physical layer is based on a synchronization system clock between the UE client and the physical layer, wherein the synchronization system clock is indicated by one or more of a system frame number, subframe, time slot, and symbol.

36. An electronic device (2302) for enabling interaction between a user equipment (UE) client and a UE physical layer server, comprising: A processor (2342) and a non-transitory machine-readable storage medium (2349) provide instructions that, when executed by the processor, cause the electronic device to perform: Perform service discovery (2102) to locate the control endpoint of the UE physical layer server; Send (2104) a request to allocate resources for the UE client to the control endpoint of the UE physical layer server, the request indicating the identifier of the UE client; Receive the (2106) handle from the UE physical layer server; as well as The handle is used to perform (2108) interaction between the UE client and the UE physical layer server.

37. The electronic device according to claim 36, wherein, The request includes one or more of the following: number of antennas, frequency band, and bandwidth to be allocated to the UE client.

38. The electronic device according to claim 36 or 37, wherein, The control endpoint is identified using either an Internet Protocol (IP) address or a port number.

39. The electronic device according to any one of claims 36 to 38, wherein, The handle is created based on the identifier of the UE client.

40. The electronic device according to any one of claims 36 to 39, wherein, The interaction between the UE client and the UE physical layer is based on a synchronization system clock between the UE client and the physical layer, wherein the synchronization system clock is indicated by one or more of a system frame number, subframe, time slot, and symbol.

41. A non-transitory machine-readable storage medium (2349) providing instructions, when executed by a processor of an electronic device, causing the electronic device to perform: Perform service discovery (2102) to locate the control endpoint of the UE physical layer server; Send (2104) a request to allocate resources for the UE client to the control endpoint of the UE physical layer server, the request indicating the identifier of the UE client; Receive the (2106) handle from the UE physical layer server; as well as The handle is used to perform (2108) interaction between the UE client and the UE physical layer server.

42. The non-transitory machine-readable storage medium according to claim 41, wherein, The request includes one or more of the following: number of antennas, frequency band, and bandwidth to be allocated to the UE client.

43. The non-transitory machine-readable storage medium according to claim 41 or 42, wherein, The control endpoint is identified using either an Internet Protocol (IP) address or a port number.

44. The non-transitory machine-readable storage medium according to any one of claims 41 to 43, wherein, The handle is created based on the identifier of the UE client.

45. The non-transitory machine-readable storage medium according to any one of claims 41 to 44, wherein, The interaction between the UE client and the UE physical layer is based on a synchronization system clock between the UE client and the physical layer, wherein the synchronization system clock is indicated by one or more of a system frame number, subframe, time slot, and symbol.

Images