Service profile and quality-of-service management at an orchestrator to support scheduling of a compute service in a wireless communications system

Abstract

In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a device that is a first node in a communication system including multiple nodes distributed in at least one network domain. The first node obtains a service profile of a service. The service profile may define performance requirement for the service. The first node generates a network-domain-specific configuration information based on the service profile. The first node sends, to a second node within the multiple nodes, the network-domain-specific configuration information to enable a network-domain-specific operation for the service. The network-domain-specific operation is related to resource allocation for the service.

Description

SERVICE PROFILE AND QUALITY-OF-SERVICE MANAGEMENT AT AN ORCHESTRATOR TO SUPPORT SCHEDULING OF A COMPUTE SERVICE IN A WIRELESS COMMUNICATIONS SYSTEMCROSS-REFERENCE TO RELATED APPLICATION (S)

[0001] This application claims the benefits of U.S. Provisional Application Serial No. 63 / 572,390, entitled “SERVICE PROFILE AND QUALITY-OF-SERVICE MANAGEMENT AT AN ORCHESTRATOR TO SUPPORT SCHEDULING OF A COMPUTE SERVICE IN A WIRELESS COMMUNICATIONS SYSTEM” and filed on April 1, 2024, which is expressly incorporated by reference herein in its entirety.BACKGROUNDField

[0002] The present disclosure relates generally to wireless communications, and more particularly, to techniques for handling, in a wireless communications system, a service that supports offloading of compute activity from a client device to one or more compute nodes. Background

[0003] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0004] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0005] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example telecommunication standard is 5G New Radio (NR) . 5G NR is part of a continuous mobile broadband evolution promulgated by Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with Internet of Things (IoT) ) , and other requirements. Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. There exists a need for further improvements in 5G NR technology. These improvements may also be applicable to other multi-access technologies and the telecommunication standards that employ these technologies.SUMMARY

[0006] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0007] In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a device that is a first node in a communication system including multiple nodes distributed in at least one network domain. The first node obtains a service profile of a service. The service profile may define performance requirement for the service. The first node generates a network-domain-specific configuration information based on the service profile. The first node sends, to a second node within the multiple nodes, the network-domain-specific configuration information to enable a network-domain-specific operation for the service. The network-domain-specific operation is related to resource allocation for the service.

[0008] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network.

[0010] FIG. 2 is a diagram illustrating a base station in communication with a UE in an access network.

[0011] FIG. 3 illustrates an example logical architecture of a distributed access network.

[0012] FIG. 4 illustrates an example physical architecture of a distributed access network.

[0013] FIG. 5 is a diagram showing an example of a DL-centric slot.

[0014] FIG. 6 is a diagram showing an example of an UL-centric slot.

[0015] FIG. 7 is a diagram illustrating interactions among nodes in a system supporting compute offload.

[0016] FIG. 8 is a diagram illustrating a system supporting compute offload and including multiple compute nodes at different locations in the system.

[0017] FIG. 9 is a flow diagram showing an example of offloading compute tasks to compute nodes.

[0018] FIG. 10 is a diagram showing interactions between a client device, an orchestrator, and a compute node for task offload and performance monitoring.

[0019] FIG. 11 is a flow diagram showing an example of a bearer setup between the client device and a compute node in the network, initiated by the orchestrator.

[0020] FIG. 12 is a diagram showing an example of interactions between a client device, an orchestrator, a compute node, and a base station comprising a radio scheduler, supporting task offload and communication adaptation influenced by a service profile of an underlying service.

[0021] FIG. 13 is a diagram showing an example of interactions between a client device, an orchestrator, a compute node, and a base station comprising a radio scheduler, supporting performance monitoring and communication adaptation corresponding to the performance monitoring.

[0022] FIG 14 is a flow diagram showing an example of a bearer setup between the client device and a compute node in the network, initiated by the compute node in the network.

[0023] FIG. 15 illustrates a flow chart of a process for service profile and quality-of-service management.DETAILED DESCRIPTION

[0024] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0025] Several aspects of telecommunications systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0026] By way of example, an element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems on a chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0027] Accordingly, in one or more example aspects, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

[0028] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network 100. The wireless communications system (also referred to as a wireless wide area network (WWAN) ) includes base stations 102, UEs 104, an Evolved Packet Core (EPC) 160, and another core network 190 (e.g., a 5G Core (5GC) ) . The base stations 102 may include macrocells (high power cellular base station) and / or small cells (low power cellular base station) . The macrocells include base stations. The small cells include femtocells, picocells, and microcells.

[0029] The base stations 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) ) may interface with the EPC 160 through backhaul links 132 (e.g., SI interface) . The base stations 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN) ) may interface with core network 190 through backhaul links 184. In addition to other functions, the base stations 102 may perform one or more of the following functions: transfer of user data, radio channel ciphering and deciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity) , inter cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS) , subscriber and equipment trace, RAN information management (RIM) , paging, positioning, and delivery of warning messages. The base stations 102 may communicate directly or indirectly (e.g., through the EPC 160 or core network 190) with each other over backhaul links 134 (e.g., X2 interface) . The backhaul links 134 may be wired or wireless.

[0030] The base stations 102 may wirelessly communicate with the UEs 104. Each of the base stations 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, the small cell 102’ may have a coverage area 110’ that overlaps the coverage area 110 of one or more macro base stations 102. A network that includes both small cell and macrocells may be known as a heterogeneous network. A heterogeneous network may also include Home Evolved Node Bs (eNBs) (HeNBs) , which may provide service to a restricted group known as a closed subscriber group (CSG) . The communication links 120 between the base stations 102 and the UEs 104 may include uplink (UL) (also referred to as reverse link) transmissions from a UE 104 to a base station 102 and / or downlink (DL) (also referred to as forward link) transmissions from a base station 102 to a UE 104. The communication links 120 may use multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication links may be through one or more carriers. The base stations 102 / UEs 104 may use spectrum up to 7 MHz (e.g., 5, 10, 15, 20, 100, 400, etc. MHz) bandwidth per carrier allocated in a carrier aggregation of up to a total of Yx MHz (x component carriers) used for transmission in each direction. The carriers may or may not be adjacent to each other. Allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated for DL than for UL) . The component carriers may include a primary component carrier and one or more secondary component carriers. A primary component carrier may be referred to as a primary cell (PCell) and a secondary component carrier may be referred to as a secondary cell (SCell) .

[0031] Certain UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL / UL WWAN spectrum. The D2D communication link 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH) , a physical sidelink discovery channel (PSDCH) , a physical sidelink shared channel (PSSCH) , and a physical sidelink control channel (PSCCH) . D2D communication may be through a variety of wireless D2D communications systems, such as for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0032] The wireless communications system may further include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 via communication links 154 in a 5 GHz unlicensed frequency spectrum. When communicating in an unlicensed frequency spectrum, the STAs 152 / AP 150 may perform a clear channel assessment (CCA) prior to communicating in order to determine whether the channel is available.

[0033] The small cell 102’ may operate in a licensed and / or an unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell 102’ may employ NR and use the same 5 GHz unlicensed frequency spectrum as used by the Wi-Fi AP 150. The small cell 102’ , employing NR in an unlicensed frequency spectrum, may boost coverage to and / or increase capacity of the access network.

[0034] A base station 102, whether a small cell 102’ or a large cell (e.g., macro base station) , may include an eNB, gNodeB (gNB) , or another type of base station. Some base stations, such as gNB 180 may operate in a traditional sub 6 GHz spectrum, in millimeter wave (mmW) frequencies, and / or near mmW frequencies in communication with the UE 104. When the gNB 180 operates in mmW or near mmW frequencies, the gNB 180 may be referred to as an mmW base station. Extremely high frequency (EHF) is part of the RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in the band may be referred to as a millimeter wave. Near mmW may extend down to a frequency of 3 GHz with a wavelength of 100 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, also referred to as centimeter wave. Communications using the mmW / near mmW radio frequency band (e.g., 3 GHz -300 GHz) has extremely high path loss and a short range. The mmW base station 180 may utilize beamforming 182 with the UE 104 to compensate for the extremely high path loss and short range.

[0035] The base station 180 may transmit a beamformed signal to the UE 104 in one or more transmit directions 108a. The UE 104 may receive the beamformed signal from the base station 180 in one or more receive directions 108b. The UE 104 may also transmit a beamformed signal to the base station 180 in one or more transmit directions. The base station 180 may receive the beamformed signal from the UE 104 in one or more receive directions. The base station 180 / UE 104 may perform beam training to determine the best receive and transmit directions for each of the base station 180 / UE 104. The transmit and receive directions for the base station 180 may or may not be the same. The transmit and receive directions for the UE 104 may or may not be the same.

[0036] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may be in communication with a Home Subscriber Server (HSS) 174. The MME 162 is the control node that processes the signaling between the UEs 104 and the EPC 160. Generally, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are transferred through the Serving Gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to the IP Services 176. The IP Services 176 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, and / or other IP services. The BM-SC 170 may provide functions for MBMS user service provisioning and delivery. The BM-SC 170 may serve as an entry point for content provider MBMS transmission, may be used to authorize and initiate MBMS Bearer Services within a public land mobile network (PLMN) , and may be used to schedule MBMS transmissions. The MBMS Gateway 168 may be used to distribute MBMS traffic to the base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start / stop) and for collecting eMBMS related charging information.

[0037] The core network 190 may include a Access and Mobility Management Function (AMF) 192, other AMFs 193, a location management function (LMF) 198, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may be in communication with a Unified Data Management (UDM) 196. The AMF 192 is the control node that processes the signaling between the UEs 104 and the core network 190. Generally, the SMF 194 provides QoS flow and session management. All user Internet protocol (IP) packets are transferred through the UPF 195. The UPF 195 provides UE IP address allocation as well as other functions. The UPF 195 is connected to the IP Services 197. The IP Services 197 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, and / or other IP services.

[0038] The base station may also be referred to as a gNB, Node B, evolved Node B (eNB) , an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a transmit reception point (TRP) , or some other suitable terminology. The base station 102 provides an access point to the EPC 160 or core network 190 for a UE 104. Examples of UEs 104 include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA) , a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player) , a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similar functioning device. Some of the UEs 104 may be referred to as IoT devices (e.g., parking meter, gas pump, toaster, vehicles, heart monitor, etc. ) . The UE 104 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0039] Although the present disclosure may reference 5G New Radio (NR) , the present disclosure may be applicable to other similar areas, such as LTE, LTE-Advanced (LTE-A) , Code Division Multiple Access (CDMA) , Global System for Mobile communications (GSM) , or other wireless / radio access technologies.

[0040] FIG. 2 is a block diagram of a base station 210 in communication with a UE 250 in an access network. In the DL, IP packets from the EPC 160 may be provided to a controller / processor 275. The controller / processor 275 implements layer 3 and layer 2 functionality. Layer 3 includes a radio resource control (RRC) layer, and layer 2 includes a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The controller / processor 275 provides RRC layer functionality associated with broadcasting of system information (e.g., MIB, SIBs) , RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release) , inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression  / decompression, security (ciphering, deciphering, integrity protection, integrity verification) , and handover support functions; RLC layer functionality associated with the transfer of upper layer packet data units (PDUs) , error correction through ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs) , re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs) , demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0041] The transmit (TX) processor 216 and the receive (RX) processor 270 implement layer 1 functionality associated with various signal processing functions. Layer 1, which includes a physical (PHY) layer, may include error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The TX processor 216 handles mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK) , quadrature phase-shift keying (QPSK) , M-phase-shift keying (M-PSK) , M-quadrature amplitude modulation (M-QAM) ) . The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from a channel estimator 274 may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a reference signal and / or channel condition feedback transmitted by the UE 250. Each spatial stream may then be provided to a different antenna 220 via a separate transmitter 218TX. Each transmitter 218TX may modulate an RF carrier with a respective spatial stream for transmission.

[0042] At the UE 250, each receiver 254RX receives a signal through its respective antenna 252. Each receiver 254RX recovers information modulated onto an RF carrier and provides the information to the receive (RX) processor 256. The TX processor 268 and the RX processor 256 implement layer 1 functionality associated with various signal processing functions. The RX processor 256 may perform spatial processing on the information to recover any spatial streams destined for the UE 250. If multiple spatial streams are destined for the UE 250, they may be combined by the RX processor 256 into a single OFDM symbol stream. The RX processor 256 then converts the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT) . The frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are recovered and demodulated by determining the most likely signal constellation points transmitted by the base station 210. These soft decisions may be based on channel estimates computed by the channel estimator 258. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the base station 210 on the physical channel. The data and control signals are then provided to the controller / processor 259, which implements layer 3 and layer 2 functionality.

[0043] The controller / processor 259 can be associated with a memory 260 that stores program codes and data. The memory 260 may be referred to as a computer-readable medium. In the UL, the controller / processor 259 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, and control signal processing to recover IP packets from the EPC 160. The controller / processor 259 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0044] Similar to the functionality described in connection with the DL transmission by the base station 210, the controller / processor 259 provides RRC layer functionality associated with system information (e.g., MIB, SIBs) acquisition, RRC connections, and measurement reporting; PDCP layer functionality associated with header compression  / decompression, and security (ciphering, deciphering, integrity protection, integrity verification) ; RLC layer functionality associated with the transfer of upper layer PDUs, error correction through ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0045] Channel estimates derived by a channel estimator 258 from a reference signal or feedback transmitted by the base station 210 may be used by the TX processor 268 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor 268 may be provided to different antenna 252 via separate transmitters 254TX. Each transmitter 254TX may modulate an RF carrier with a respective spatial stream for transmission. The UL transmission is processed at the base station 210 in a manner similar to that described in connection with the receiver function at the UE 250. Each receiver 218RX receives a signal through its respective antenna 220. Each receiver 218RX recovers information modulated onto an RF carrier and provides the information to a RX processor 270.

[0046] The controller / processor 275 can be associated with a memory 276 that stores program codes and data. The memory 276 may be referred to as a computer-readable medium. In the UL, the controller / processor 275 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover IP packets from the UE 250. IP packets from the controller / processor 275 may be provided to the EPC 160. The controller / processor 275 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0047] New radio (NR) may refer to radios configured to operate according to a new air interface (e.g., other than Orthogonal Frequency Divisional Multiple Access (OFDMA) -based air interfaces) or fixed transport layer (e.g., other than Internet Protocol (IP) ) . NR may utilize OFDM with a cyclic prefix (CP) on the uplink and downlink and may include support for half-duplex operation using time division duplexing (TDD) . NR may include Enhanced Mobile Broadband (eMBB) service targeting wide bandwidth (e.g. 80 MHz beyond) , millimeter wave (mmW) targeting high carrier frequency (e.g. 60 GHz) , massive MTC (mMTC) targeting non-backward compatible MTC techniques, and / or mission critical targeting ultra-reliable low latency communications (URLLC) service.

[0048] A single component carrier bandwidth of 100 MHz may be supported. In one example, NR resource blocks (RBs) may span 12 sub-carriers with a sub-carrier bandwidth of 60 kHz over a 0.25 ms duration or a bandwidth of 30 kHz over a 0.5 ms duration (similarly, 50MHz BW for 15kHz SCS over a 1 ms duration) . Each radio frame may consist of 10 subframes (10, 20, 40 or 80 NR slots) with a length of 10 ms. Each slot may indicate a link direction (i.e., DL or UL) for data transmission and the link direction for each slot may be dynamically switched. Each slot may include DL / UL data as well as DL / UL control data. UL and DL slots for NR may be as described in more detail below with respect to FIGs. 5 and 6.

[0049] The NR RAN may include a central unit (CU) and distributed units (DUs) . A NR BS (e.g., gNB, 5G Node B, Node B, transmission reception point (TRP) , access point (AP) ) may correspond to one or multiple BSs. NR cells can be configured as access cells (ACells) or data only cells (DCells) . For example, the RAN (e.g., a central unit or distributed unit) can configure the cells. DCells may be cells used for carrier aggregation or dual connectivity and may not be used for initial access, cell selection / reselection, or handover. In some cases DCells may not transmit synchronization signals (SS) in some cases DCells may transmit SS. NR BSs may transmit downlink signals to UEs indicating the cell type. Based on the cell type indication, the UE may communicate with the NR BS. For example, the UE may determine NR BSs to consider for cell selection, access, handover, and / or measurement based on the indicated cell type.

[0050] FIG. 3 illustrates an example logical architecture of a distributed RAN 300, according to aspects of the present disclosure. A 5G access node 306 may include an access node controller (ANC) 302. The ANC may be a central unit (CU) of the distributed RAN. The backhaul interface to the next generation core network (NG-CN) 304 may terminate at the ANC. The backhaul interface to neighboring next generation access nodes (NG-ANs) 310 may terminate at the ANC. The ANC may include one or more TRPs 308 (which may also be referred to as BSs, NR BSs, Node Bs, 5G NBs, APs, or some other term) . As described above, a TRP may be used interchangeably with “cell. ”

[0051] The TRPs 308 may be a distributed unit (DU) . The TRPs may be connected to one ANC (ANC 302) or more than one ANC (not illustrated) . For example, for RAN sharing, radio as a service (RaaS) , and service specific ANC deployments, the TRP may be connected to more than one ANC. A TRP may include one or more antenna ports. The TRPs may be configured to individually (e.g., dynamic selection) or jointly (e.g., joint transmission) serve traffic to a UE.

[0052] The local architecture of the distributed RAN 300 may be used to illustrate fronthaul definition. The architecture may be defined that support fronthauling solutions across different deployment types. For example, the architecture may be based on transmit network capabilities (e.g., bandwidth, latency, and / or jitter) . The architecture may share features and / or components with LTE. According to aspects, the next generation AN (NG-AN) 310 may support dual connectivity with NR. The NG-AN may share a common fronthaul for LTE and NR.

[0053] The architecture may enable cooperation between and among TRPs 308. For example, cooperation may be preset within a TRP and / or across TRPs via the ANC 302. According to aspects, no inter-TRP interface may be needed / present.

[0054] According to aspects, a dynamic configuration of split logical functions may be present within the architecture of the distributed RAN 300. The PDCP, RLC, MAC protocol may be adaptably placed at the ANC or TRP.

[0055] FIG. 4 illustrates an example physical architecture of a distributed RAN 400, according to aspects of the present disclosure. A centralized core network unit (C-CU) 402 may host core network functions. The C-CU may be centrally deployed. C-CU functionality may be offloaded (e.g., to advanced wireless services (AWS) ) , in an effort to handle peak capacity. A centralized RAN unit (C-RU) 404 may host one or more ANC functions. Optionally, the C-RU may host core network functions locally. The C-RU may have distributed deployment. The C-RU may be closer to the network edge. A distributed unit (DU) 406 may host one or more TRPs. The DU may be located at edges of the network with radio frequency (RF) functionality.

[0056] FIG. 5 is a diagram 500 showing an example of a DL-centric slot. The DL-centric slot may include a control portion 502. The control portion 502 may exist in the initial or beginning portion of the DL-centric slot. The control portion 502 may include various scheduling information and / or control information corresponding to various portions of the DL-centric slot. In some configurations, the control portion 502 may be a physical DL control channel (PDCCH) , as indicated in FIG. 5. The DL-centric slot may also include a DL data portion 504. The DL data portion 504 may sometimes be referred to as the payload of the DL-centric slot. The DL data portion 504 may include the communication resources utilized to communicate DL data from the scheduling entity (e.g., UE or BS) to the subordinate entity (e.g., UE) . In some configurations, the DL data portion 504 may be a physical DL shared channel (PDSCH) .

[0057] The DL-centric slot may also include a common UL portion 506. The common UL portion 506 may sometimes be referred to as an UL burst, a common UL burst, and / or various other suitable terms. The common UL portion 506 may include feedback information corresponding to various other portions of the DL-centric slot. For example, the common UL portion 506 may include feedback information corresponding to the control portion 502. Non-limiting examples of feedback information may include an ACK signal, a NACK signal, a HARQ indicator, and / or various other suitable types of information. The common UL portion 506 may include additional or alternative information, such as information pertaining to random access channel (RACH) procedures, scheduling requests (SRs) , and various other suitable types of information.

[0058] As illustrated in FIG. 5, the end of the DL data portion 504 may be separated in time from the beginning of the common UL portion 506. This time separation may sometimes be referred to as a gap, a guard period, a guard interval, and / or various other suitable terms. This separation provides time for the switch-over from DL communication (e.g., reception operation by the subordinate entity (e.g., UE) ) to UL communication (e.g., transmission by the subordinate entity (e.g., UE) ) . One of ordinary skill in the art will understand that the foregoing is merely one example of a DL-centric slot and alternative structures having similar features may exist without necessarily deviating from the aspects described herein.

[0059] FIG. 6 is a diagram 600 showing an example of an UL-centric slot. The UL-centric slot may include a control portion 602. The control portion 602 may exist in the initial or beginning portion of the UL-centric slot. The control portion 602 in FIG. 6 may be similar to the control portion 502 described above with reference to FIG. 5. The UL-centric slot may also include an UL data portion 604. The UL data portion 604 may sometimes be referred to as the pay load of the UL-centric slot. The UL portion may refer to the communication resources utilized to communicate UL data from the subordinate entity (e.g., UE) to the scheduling entity (e.g., UE or BS) . In some configurations, the control portion 602 may be a physical DL control channel (PDCCH) .

[0060] As illustrated in FIG. 6, the end of the control portion 602 may be separated in time from the beginning of the UL data portion 604. This time separation may sometimes be referred to as a gap, guard period, guard interval, and / or various other suitable terms. This separation provides time for the switch-over from DL communication (e.g., reception operation by the scheduling entity) to UL communication (e.g., transmission by the scheduling entity) . The UL-centric slot may also include a common UL portion 606. The common UL portion 606 in FIG. 6 may be similar to the common UL portion 506 described above with reference to FIG. 5. The common UL portion 606 may additionally or alternatively include information pertaining to channel quality indicator (CQI) , sounding reference signals (SRSs) , and various other suitable types of information. One of ordinary skill in the art will understand that the foregoing is merely one example of an UL-centric slot and alternative structures having similar features may exist without necessarily deviating from the aspects described herein.

[0061] In some circumstances, two or more subordinate entities (e.g., UEs) may communicate with each other using sidelink signals. Real-world applications of such sidelink communications may include public safety, proximity services, UE-to-network relaying, vehicle-to-vehicle (V2V) communications, Internet of Everything (IoE) communications, IoT communications, mission-critical mesh, and / or various other suitable applications. Generally, a sidelink signal may refer to a signal communicated from one subordinate entity (e.g., UE1) to another subordinate entity (e.g., UE2) without relaying that communication through the scheduling entity (e.g., UE or BS) , even though the scheduling entity may be utilized for scheduling and / or control purposes. In some examples, the sidelink signals may be communicated using a licensed spectrum (unlike wireless local area networks, which typically use an unlicensed spectrum) .

[0062] In a wireless communications system that supports the offloading of computationally intensive tasks, a client device-such as a smartphone, smart glasses, an extended reality (XR) headset, an Internet of Things (IoT) device, and so on-may host an application with significant computational demands. These demands may be quantified using various metrics, including central processing unit (CPU) cycles, memory footprint, and others. The client device, which may also be referred to as a tenant device, application host, or similar devices, might encounter situations where the application requires more computational resources than the client device can (or prefers to) provide. For example, the application may necessitate intensive CPU usage for computations that the client device’s CPU cannot execute in a timely manner, the client device may be constrained by battery life and prefer to offload computational tasks to a device with greater power resources, and / or the application may require more memory than the client device can allocate.

[0063] An exemplary system that supports computational offloading may include the client device, one or more compute nodes capable of performing computational tasks on behalf of the client device, and an orchestrator node responsible for managing the allocation of compute tasks to the compute nodes in a manner that meets the performance requirements of the underlying service. The collection of nodes involved in a specific task, or managed by a particular orchestrator, may be referred to as a “cluster, ” “compute cluster, ” or “subnetwork” within the communications system. The compute nodes may also be termed worker nodes, compute servers, renter devices, and so on. The orchestrator may be referred to as a master node, composition management function, compute management function, cluster manager, or similar terms. The compute nodes and the orchestrator may include mobile devices, user equipments (UEs) , nodes within a wireless network, or similar entities. For the purposes of this discussion, it is assumed that the client device is a mobile device and / or a UE, although the concepts disclosed herein are also applicable to clients located within a wireless network (e.g., a base station in a wireless network may engage one or more compute nodes to assist with computationally intensive evaluations of criteria for the mobility of the devices it serves) . It is important to note that the term “mobile device” is used broadly to refer to devices that are in service of the wireless network, and it does not necessarily imply that the device is physically mobile. For example, a mobile device could be a customer premises equipment (CPE) node that is fixed in location but presents itself to the wireless network as a device in service of the network.

[0064] In many cases, a computationally demanding service will impose specific performance requirements. For example, a rendering application may need to support a display operation at a particular frame rate, ensuring that a completed frame is delivered in time for the next scheduled display update. Typically, such performance requirements may include a maximum allowable compute time-i.e., a deadline by which the result of a compute task must be available to the client application. Additionally, some tasks may have further requirements, such as a target level of accuracy or convergence of the result. There may also be requirements related to the data flow (s) supporting the compute task, such as an expected (maximum and / or average) packet size, an expected (exact, minimum, maximum, and / or approximate) periodicity, and so on. In a compute cluster executing one or more tasks, the orchestrator must be aware of both the performance requirements of the tasks and the available compute resources at the compute nodes within the cluster. This awareness enables the orchestrator to assign tasks to appropriate compute nodes and ensure that the performance requirements are met.

[0065] However, computational requirements are not the sole performance constraints affecting the operation of compute tasks in a distributed system such as a compute cluster. The communication path between the client device and a compute node, which may be used to deliver a task image, data to support a compute operation, and / or the result of a compute operation, imposes certain limitations on the communications that traverse it. For instance, a communication path may have an associated minimum (or typical) transmission latency, a maximum (peak or average) data bandwidth, and so on. Consequently, the management of compute tasks must consider not only the computational performance requirements but also the impact of the communication paths that will be used to support compute offload operations. Furthermore, the communications system may adapt to the needs of a service that offloads compute tasks, for example, by scheduling radio resources to optimize the communication performance of data for the service (potentially at the expense of other data with lower priority, looser latency requirements, and so on) . Such a scheme of interaction between a compute service and the supporting radio layers may be referred to as integrated communication and computing (ICC) , joint communication and computing (JCC) , or similar terms.

[0066] This disclosure is directed to an approach that may realize ICC functionality by managing multiple quality-of-service (QoS) criteria between an orchestrator and one or more radio resource schedulers. This approach enables the schedulers to deliver compute data and results in a timely manner while allowing the orchestrator to accurately model the performance that can be expected from the communications system. The management of QoS criteria may be guided, in whole or in part, by one or more service profiles corresponding to one or more compute tasks of the underlying application. It should be noted that this usage of the term “QoS” is distinct from the concept of communication QoS; the QoS metrics under discussion in this disclosure refer to the performance of the entire service, including the communication and / or the compute parts. Thus, the QoS of a compute service may include or overlap with, but not be limited to, the communication QoS of an underlying set of radio transport layers, for instance. Throughout this disclosure, when the term “QoS” is used to refer to communication performance, it will be distinguished as “communication QoS” .

[0067] The approach is designed to support communication scheduling that aligns with the performance requirements of the service. In one aspect, the approach may provide assistance to a scheduler for a compute service. In a communication system including multiple compute nodes, distributed in at least one network domain, which may be a combination of user devices and / or network devices, a first node may receive, from a second node in the multiple compute nodes, a service profile of a compute service. The first node then sends, to a third node, first information derived from the service profile. The third node may perform scheduling for at least one node of the communication system.

[0068] In another aspect, the approach may request and configure a bearer for the compute service based on the requirements specified in the service profile. The approach may trigger a bearer configuration for the compute service. In such a case, the first node may receive, from the second node, a service profile of the compute service. The first node then sends, to a third node, a request for the establishment of a bearer for communication between the third node and a fourth node. The request may include information derived from the service profile.

[0069] In this disclosure, the term “network-domain” refers to a logically or functionally partitioned segment of the communication system, such as a radio access network (RAN) domain and a core network (CN) domain. For example, the RAN domain may include the base station 102, and the CN domain may include AMF 192 and / or SMF 194. Correspondingly, a network-domain-specific operation may include: performing scheduling in the RAN domain, or configuring a bearer in the CN domain.

[0070] In a distributed communication system, to meet performance requirements, a specific service may be efficiently provided through appropriate resource allocation, such as compute offloading. Specifically, the service involves a computationally intensive task. In such a scenario, the task, which is part of a service or application hosted by a client device, may be partially offloaded to a compute node. The compute node is managed by a third entity, referred to as an orchestrator. This architecture establishes a triangular relationship among the client device, the compute node, and the orchestrator, facilitating efficient coordination and management of compute resources.

[0071] FIG. 7 is a diagram 700 illustrating interactions among nodes in a system supporting compute offload. It illustrates interactions between a client device 702, a compute node 704, and an orchestrator 706, which together may be considered a compute cluster. In some embodiments, the cluster may include multiple compute nodes. However, in such cases, each compute node is expected to operate substantially independently of the others. The client device 702 and the orchestrator 706 communicate to facilitate discovery within the cluster (e.g., discovery of compute nodes by the client device 702) and offload management (e.g., allocation of specific compute tasks to corresponding compute nodes) . The orchestrator 706 and the compute node 704 communicate to support compute resource management (e.g., registration of the compute node 704 with the orchestrator 706 and / or establishment of the level of compute resources that the compute node 704 will make available within a particular cluster) . The client device 702 and the compute node 704 communicate to perform task offloading and deliver task results.

[0072] The communication links depicted in FIG. 7 may use various forms of transport, either individually or in combination, such as an air interface of a wireless communications system (using protocol stacks based on a user plane, a control plane, a management plane, and / or a compute plane) , network interfaces within the wireless communications system, inter-system interfaces through which one communications system interacts with another, and so on. The interactions may be modeled as protocol transactions, application programming interface (API) invocations, service-based interface (SBI) invocations, data streams, and the like, including combinations of different models.

[0073] For example, the client device 702 might interact with the orchestrator 706 in a wireless network using a combination of control plane transport over the air and network interfaces within the network, while interacting with the compute node 704 in the wireless network using a combination of user plane transport over the air and network interfaces within the network. Meanwhile, the orchestrator 706 interacts with the compute node 704 using network interfaces. As another example, the client device 702 might interact with the orchestrator 706 at a first peer device using a control plane of a device-to-device (D2D) architecture, and with the compute node 704 at a second peer device using a user plane of the D2D architecture, while the orchestrator 706 interacts with the compute node 704 using a control plane of the D2D architecture.

[0074] It should also be appreciated that any of the roles shown in FIG. 7 can be collocated at a single node. For instance, the client device 702 may host its own orchestrator, or the orchestrator 706 may have its own compute resources that function as a compute node. In such cases, the interactions shown in FIG. 7 between the collocated roles may be handled as a matter of implementation within the concerned node. For example, if the client device 702 and the orchestrator 706 are collocated at a single device, the process of offload management may occur within the device through inter-process communication, an API between different processes executing on the device, or similar mechanisms. Throughout this description, the functions are treated as being embodied in separate nodes for clarity.

[0075] As illustrated in FIG. 7, compute offload operates based on a triangular architecture. In this architecture, the orchestrator 706 manages the allocation and control of compute resources and coordinates with the client device 702. The client device 702 offloads computational tasks to the compute node 704 and receives the results via a configured bearer. This triangular architecture shares similarities with the Multi-Access Edge Computing (MEC) framework in 5G systems. However, unlike 5G MEC, where the compute node and orchestrator are typically located in a data network above the core network, the nodes involved in this disclosure can be flexibly located in any part of the network, such as in a User Equipment (UE) , a Radio Access Network (RAN) , a Core Network (CN) , and a Data Network (DN) . For example, the orchestrator may be located on a UE, a base station, or an element within the CN. Similarly, the compute node may also be situated at various locations, including a UE, a base station, or a core network element.

[0076] The disclosure relates to the characterization of a service, such as a compute service, through a "service profile, " which defines the performance requirements of the compute service. This service profile is exposed to the RAN and / or CN to enable dynamic configuration of network resources.

[0077] The orchestrator 706 may be configured to maintain awareness of the compute service requirements specified in the service profile, and dynamically configure network nodes (e.g., RAN, CN) to meet the requirements of the compute service. The orchestrator 706 may also coordinate with the RAN to optimize radio resource scheduling based on the compute service requirements, or coordinate with the CN to establish and configure a bearer between the client device 702 and the compute node 704, ensuring efficient data transmission for the offloaded computation.

[0078] In the described architecture, the location of the CN relative to the orchestrator depends on the specific topology of the nodes for a given service. In some implementations, the orchestrator may reside within the CN. In other implementations, all nodes may be devices, with the CN positioned separately,

[0079] While the description in FIG. 7 primarily focuses on a single client device, a single orchestrator, and a single compute node, the architecture is scalable and can be extended to scenarios involving multiple nodes, such as multiple compute nodes. In this context, the orchestrator, compute node, and client device may each be referred to as a node, such as an orchestrator node, a compute node, and a client node, respectively. The communication and coordination mechanisms described herein can be adapted to accommodate multiple compute nodes. These compute nodes may operate in parallel to enhance system performance.

[0080] The client device 702 may be a UE. However, the concept is not limited to UEs and could also apply to network clients. For instance, this compute assistance framework could be utilized for network management tasks or other similar applications.

[0081] FIG. 8 is a diagram 800 illustrating a system supporting compute offload and including multiple compute nodes at different locations in the system. It illustrates an example of a compute cluster serving a first (client) device 802. The cluster includes, in addition to the first device 802 itself, a second (orchestrator) device 804, a third device hosting a first compute node (compute node A) 806A, and a base station (BS) of a cellular network hosting a second compute node (compute node B) 806B. (Whether the client device is considered part of the cluster itself may vary depending on the embodiment; in different implementations, the cluster may be modeled as including only the compute nodes, the compute nodes and the orchestrator, or all the depicted nodes. )

[0082] It is noted that the "hosting" of functions may be realized in various ways, depending on the architecture of a particular system. For example, the network-hosted compute node (compute node B 806B) may be an MEC server associated with the BS, while the device-hosted compute node (compute node A 806A) may be a system function of a cellular system, and so on. For the purposes of this discussion, no distinction is generally made between a function (such as an orchestrator, a communication proxy for the client, or a compute node) and the node hosting it. That is, a communication between a communication proxy at a client device and a compute node function associated with a network node may be described, for simplicity, as a communication between the client device and the network node, and so on. However, it should be understood that all participants in a compute cluster use the communication mechanisms of the overlying communications system (s) , including various types of interfaces and communication models between nodes.

[0083] In FIG. 8, the orchestrator 804 may be viewed as a "controller" or "manager" of the cluster, coordinating the compute resources offered by compute nodes A and B (806A-B) and making them available to the client device 802.

[0084] FIG. 9 is a flow diagram 900 showing an example of offloading compute tasks to compute nodes. It illustrates a system similar to that depicted in FIG. 8. The nodes involved are the same as in FIG. 8: a client device 902, an orchestrator 904, and two compute nodes (compute node A 906A and compute node B 906B) .

[0085] In Step S901, the nodes perform a process of discovery and cluster formation. This process may include, for example, the distribution of device capabilities, the registration of the client device 902 and / or the compute nodes 906A-B with the orchestrator 904, and the negotiation between the orchestrator 904 and the compute nodes 906A-B regarding the level of compute resources that each node will dedicate to the cluster, among other activities.

[0086] In Step S902, the nodes carry out the association of tasks with compute nodes and the distribution of task images. This step may be realized according to various schemes. The task images may be stored in advance by the orchestrator 904 and distributed to the other nodes, provided directly by the client device 902, or stored in a repository 908 and distributed by the orchestrator 904 or the client device 902 to the compute nodes 906A-B, and so on.

[0087] In Step S903, the client device 902 delivers data for Task 1 (e.g., a set of input parameters for a computation) to compute node A 906A.

[0088] In Step S904, compute node A 906A executes the image for Task 1 using the data delivered in Step S903 as input.

[0089] In Step S905, compute node A 906A returns the result of Task 1 to the client device 902. Steps S903-905 may be repeated according to the requirements of the application that generated Task 1. For instance, an extended reality (XR) application may stream input data for each video frame to the compute node at regular intervals (Step S903) and receive the rendered frame in time to display it to the user (Step S905) .

[0090] In Step S906, the client device 902 delivers data for Task 2 to compute node B 906B.

[0091] In Step S907, compute node B 906B executes the image for Task 2 using the data delivered in Step S906 as input.

[0092] In Step S908, compute node B 906B returns the result of Task 2 to the client device 902. Steps S906-908 may be repeated according to the requirements of the application that generated Task 2. For example, a generative artificial intelligence (AI) application may deliver a prompt to a computational engine whenever the user provides the prompt (Step S906) and receive the generated response when it becomes available at the conclusion of task execution (Step S908) .

[0093] In Step S909, the nodes perform performance monitoring. This monitoring may consider various factors, such as the communication quality of service (QoS) provided to communications in the previous steps, the compute performance of compute nodes A and B (906A-B) , the requirements of the application for the computational tasks, and the quality of experience (QoE) delivered to the client device 902, among others.

[0094] FIG. 10 is a diagram 1000 showing interactions between a client device 1002, an orchestrator 1004, and a compute node 1006 for task offload and performance monitoring. The process depicted in FIG. 10 begins after the nodes have discovered one another and a cluster has been formed, when the client device 1002 is launching an application that benefits from compute services.

[0095] In Step S1001, the client device 1002 sends a service profile to the orchestrator 1004. This service profile describes the expected performance requirements and characteristics of the compute task (s) required by the application. The service profile may include, for example, a latency bound on the time for a compute task to complete, a memory requirement, a metric of anticipated CPU load from the task, an expected level of convergence, and so on. In some embodiments, the service profile may be provided to the orchestrator 1004 from a source other than the client device 1002, such as a task repository 1008. In particular, if the service requires a “user space” task whose behaviour is defined by code originating from the client device 1002, the service profile may be expected to be sent by the client device 1002. If the service requires an “operator space” task for which the code to be executed is a predefined service offered by the operator of the communications system, the orchestrator 1004 may instead retrieve the service profile from a task repository maintained by the operator. Other schemata are possible, such as the orchestrator 1004 retrieving the service profile from a third-party external repository 1010. In some embodiments, a single service may include multiple computational tasks, which may be provided by a single source or different sources, and which may be assigned to one or more compute nodes.

[0096] In Step S1002, the orchestrator 1004 sends a task assignment to the compute node 1006, reserving some compute resources at the compute node 1006 to be used for the service. In some embodiments, Step S1002 (or the subsequent Step S1003) may be followed by an acknowledgement or confirmation (not shown in the figure) indicating that the assigned computing module has been successfully instantiated at the compute node.

[0097] In Step S1003, the compute node 1006 obtains an executable image for the task. This step can be carried out in various ways. For example, the compute node 1006 may receive the task image or a repository location from the orchestrator 1004 along with the task assignment, or the compute node 1006 may retrieve the task image from a repository (e.g., at a location provided to the compute node 1006 by the orchestrator 1004) , and so on.

[0098] In Step S1004, the orchestrator 1004 sends offload instructions to the client device 1002. These instructions provide the necessary guidance for the client device 1002 to deliver data for the compute task to the appropriate compute node 1006. The offload instructions may include, for example, the identity of the compute node 1006, parameters for generating and / or transmitting data for the compute task, and so on. In some embodiments, Step S1004 may be replaced by an interaction with another node of the communications system responsible for configuring bearers towards the client device 1002, as discussed further below.

[0099] In Step S1005, the client device 1002, using the information provided in Step S1004, sends a set of task data to the compute node 1006. This data may be delivered as a single message or packet, a stream of data, or another increment that allows the compute node 1006 to execute the task image with a well-defined input.

[0100] In Step S1006, the compute node 1006, having executed the compute task, sends the result of the compute task to the client device 1002. Steps S1005 and S1006 may occur over various transport mechanisms, such as one or more data bearers, one or more signaling messages, one or more API invocations, and so on. These steps may be repeated according to the requirements of the service.

[0101] In Step S1007, the compute node 1006 sends first performance data to the orchestrator 1004. This data may include, for example, the time required to execute the task, a metric of the CPU load incurred by the compute node 1006 in executing the task, an indication of memory consumption by the task, and so on.

[0102] In Step S1008, the client device 1002 sends second performance data to the orchestrator 1004. This data may include, for example, the elapsed time between the transmission of the task data (start of Step S1005) and the reception of the result (completion of Step S1006) , an indication of whether a data delivery deadline was met, an evaluation of the quality of the result (e.g., in case of a task which attempts to approximate a known target and where the accuracy of the result can be measured) , and so on. The second performance data can be viewed as a form of service-level QoS or QoE information, indicating the extent to which the overall performance of the service meets the requirements.

[0103] In Step S1009, the orchestrator 1004 evaluates the first performance data and / or the second performance data and conducts performance evaluation. This evaluation may include, for example, assessing the first and / or second performance data against the service profile to determine whether the performance expectations of the service are met.

[0104] FIG. 11 is a flow diagram 1100 showing an example of a bearer setup between the client device 1102 and a compute node 1106 in the network, initiated by the orchestrator 1104. The orchestrator 1104 is configured to be aware of the service profile at the beginning of the flow. For example, the service profile may be obtained through one of several means: (1) negotiation with the client device, (2) reception from the compute node, or (3) retrieval from an external repository containing task images for tasks that the operator is willing to support with compute resources.

[0105] As described above, in some embodiments, the allocation of a task to a particular compute node may be indicated to the client device 1102 through indirect mechanisms, such as a user plane bearer assignment. FIG. 11 illustrates an example of a message flow in which the orchestrator 1104 triggers such a bearer assignment via interactions with other nodes of the system (e.g., CN nodes) . Notably, FIG. 11 uses the terminology from the 5G system design, but it should be understood that some nodes may be replaced by updated 6G nodes with similar functionalities.

[0106] The flow as depicted in FIG. 11 begins at Step S1100, where the orchestrator 1104 selects a compute node (e.g., a compute node 1106 hosted in the network infrastructure) to handle a specific compute task for the client device 1102. The criteria for selecting the compute node 1106 may depend on the orchestrator's implementation or the service profile associated with the corresponding application, considering factors such as the CPU and memory requirements of the task, the required latency relative to the performance and location of the compute node 1106, and so on. The notification to the compute node 1106 that it has been selected and the delivery of a task image to the compute node 1106 are not shown in FIG. 11; these aspects may proceed in accordance with other aspects of this disclosure, as described earlier.

[0107] In Step S1101, the orchestrator 1104 sends a request to a Session Management Function (SMF) for a session and / or a bearer that the client device 1102 can use to exchange compute data with the compute node 1106. In some embodiments, the request may initially be sent to a managing network function, such as a Policy Control Function (PCF) , which in turn may submit a session establishment request to the SMF. The request sent by the orchestrator 1104 may include information such as the identities of the client device 1102 and the compute node 1106, required parameters of the bearer, and so on.

[0108] In Step S1102, the SMF selects an appropriate communication anchor point, such as a User Plane Function (UPF) , to handle the bearer. For example, a particular UPF may be closely collocated with the compute node 1106, enabling communications via the UPF to reach the compute node 1106 with low latency.

[0109] In Step S1103, the SMF requests the UPF to create or modify a Protocol Data Unit (PDU) session for the transport of compute data. (If a PDU session with appropriate endpoints at the client device 1102 and the UPF already exists, the PDU session may be modified to add a new bearer. Otherwise, a new PDU session may be created at this stage. )

[0110] In Step S1104, the SMF notifies the Access and Mobility Management Function (AMF) of a PDU session update.

[0111] In Step S1105, the AMF requests the Base Station (BS) 1108 to send a reconfiguration to the client device 1102 to configure an appropriate radio bearer (e.g., a user plane data radio bearer or a compute radio bearer) to carry compute data.

[0112] In Step S1106, the BS 1108 sends a configuration message, such as a reconfiguration message of the Radio Resource Control (RRC) protocol, to the client device 1102. The client device 1102 responds with an indication that the requested configuration has been applied.

[0113] In Step S1107, the client device 1102 uses the newly configured bearer to deliver data for the compute task to the UPF, which routes the data onward to the compute node 1106.

[0114] In Step S1108, the UPF routes the compute data to the compute node 1106. The compute node 1106 executes the task using the delivered data (not shown as a separate step in the figure) to produce a compute task result.

[0115] In Step S1109, the compute node 1106 delivers the compute task result to the UPF to be routed onward to the client device 1102.

[0116] In Step S1110, the UPF delivers the compute task result to the client device 1102, for example, using the newly configured bearer.

[0117] The interactions triggered by the SMF in FIG. 11 resemble the mechanisms used in MEC operation in a 5G system. A difference is the direct involvement of the orchestrator 1104 in Step S1101 to trigger the configuration process. This involvement may be beneficial in a cluster with dynamically changing membership, where compute nodes frequently leave or join the cluster. Real-time or near-real-time involvement by the orchestrator 1104 in managing the allocation of tasks to compute nodes facilitates efficient utilization of such dynamic compute resources.

[0118] In some embodiments, a compute node (which may be one of a plurality of compute nodes involved in a particular application) may be aware of the service profile and / or the related performance requirements of a compute task (for instance, if the compute node 1106 hosts a static or semi-static set of microservices) . In such a scenario, the compute node 1106, instead of the orchestrator 1104, may initiate the session or bearer request (similar to Step S1101 in FIG. 11) . In this model, each of one or more compute nodes may trigger the establishment of a communication session (e.g., a PDU session with a user-plane bearer, a compute session with a compute-plane bearer, etc. ) between the client device 1102 and the compute node 1106 itself. Information regarding the resulting session and / or bearer may then need to be communicated to the orchestrator 1104 (for instance, by the compute node 1106 or the client device 1102) to enable the orchestrator 1104 to monitor the performance of the service.

[0119] FIG. 12 is a diagram 1200 showing an example of interactions between a client device 1202, an orchestrator 1204, a compute node 1206, and a base station (BS) 1208 including a radio scheduler, supporting task offload and communication adaptation influenced by a service profile of an underlying service.

[0120] FIG. 12 illustrates an exemplary set of interactions among nodes that facilitate service-aware scheduling, i.e., the allocation of radio resources in a manner that is sensitive to the requirements of a compute service. This set of interactions can be viewed as an enabler for ICC functionality, as it allows the communication mechanisms of a wireless system to adapt to a service that provides computation. The compute node 1206 may be a set of compute nodes. For example, as depicted in FIG. 12, it may include two compute nodes: a first compute node 1206-1 located in the network and a second compute node 1206-2 located at a mobile device. It should be noted that the inclusion of two compute nodes is exemplary. Some embodiments may feature only one compute node, either at a network node or at a mobile device, while others may include multiple compute nodes in a cluster managed by the orchestrator 1204. The functionality of these nodes aligns with what has been described earlier.

[0121] Similarly, the BS 1208 may be a set of base stations (BSs) . For example, FIG. 12 illustrates two BSs 1208-1 and 1208-2 respectively serving the client device 1202 and the second compute node 1206-2, with each BS including a radio scheduler. In some embodiments, a single BS may serve all involved mobile devices. The scheduler in each BS is responsible for allocating radio resources to wireless communications over an air interface and scheduling transmissions to and from mobile devices to utilize the allocated radio resources. In FIG. 12, this functionality is represented by arrows labeled "Scheduling" from the BSs 1208 to the client device 1202 and the second compute node 1206-2, indicating that, in this example, both the client device 1202 and the second compute node 1206-2 are considered mobile devices subject to having their communications scheduled by the BSs 1208. In this example, the orchestrator 1204 is not depicted as being scheduled by any BS-for example, the orchestrator 1204 may be hosted in a network node-but it should be understood that embodiments in which the orchestrator 1204 is also located at a mobile device, with its communications scheduled by a BS, are equally valid. In such cases, the orchestrator 1204 may be served by the same BS as the client device, the same BS as a compute node, or a separate BS.

[0122] In Step S1201, the client device 1202 delivers a service profile to the orchestrator 1204. This step represents one of several alternative methods for the orchestrator 1204 to obtain the service profile. In other embodiments, Step S1201 may involve the service profile being transmitted from a repository to the orchestrator 1204, or the service profile may be pre-configured within the orchestrator 1204 itself, among other possibilities. The critical functionality of this step is to ensure that the orchestrator 1204 possesses the service profile for subsequent operations.

[0123] In Step S1202, the orchestrator 1204 performs the assignment of a compute task associated with a service to each compute node.

[0124] In Step S1203, the orchestrator 1204 delivers information derived from the service profile, and / or the service profile itself, to each BS 1208. In some embodiments, this information may include one or more traffic patterns associated with the service (or with a specific task originating from the service) , such as a maximum packet size, a peak or average data rate, a latency requirement, an anticipated periodicity of transmissions, and so on. In such cases, a service or task may, for instance, be associated with a first traffic pattern for transmitting compute task input data from the client device 1202 (and / or to the compute node 1206) and a second traffic pattern for transmitting compute task results to the client device 1202 (and / or from the compute node 1206) . As an example, a rendering task for an XR service may be associated with a first traffic pattern for transmitting input data to the rendering engine and a second traffic pattern for transmitting rendered frames to the client device 1202. The first traffic pattern may have an associated periodicity (e.g., determined by the frame rate or a tick rate of an underlying application) and an average data rate (e.g., determined, by the anticipated size of the input data for rendering a frame, such as control inputs, pose data, etc. ) . The second traffic pattern may have an associated periodicity (e.g., determined by the frame rate) , a latency requirement (e.g., determined by the deadline for delivering a frame to the user’s display) , and a peak or average data rate and / or packet size (e.g., determined by the dimensions of a rendered frame) . The traffic pattern (s) and other information associated with a service or task may be explicitly described as part of the service profile or derived (e.g., by the orchestrator 1204 or the BS 1208) from information within the service profile.

[0125] In Step S1203, the orchestrator 1204 may also send one or more link utilization requirements, such as traffic patterns between the client device 1202 and the compute node 1206, derived from the service profile. This information may be used by the BS 1208 for radio resource allocation for both uplink and downlink in a scheduling algorithm. For instance, if the service is associated with a periodic traffic pattern and a maximum packet size, the BS 1208 may allocate grants of radio resources at a periodicity and size matching those of the traffic pattern. In some embodiments, such grants may be dedicated to a particular service, task, and / or bearer, while in other embodiments, the grants may be issued to the device to fill according to certain criteria (e.g., a prioritization scheme in which some or all of the device’s bearers with data to transmit are considered) . In some embodiments, the algorithm for scheduling at the BS 1208 may be subject to BS implementation, while the supporting information in Step S1203 may be configured according to a standardized mechanism.

[0126] In Step S1204, the orchestrator 1204 delivers to the client device 1202 a compute node assignment, such as an indication of a particular task being offloaded to a particular compute node. This assignment may, for instance, identify a communication bearer that the client device 1202 will use for offloading compute activity to the compute node 1206. In the example of FIG. 12, with two compute nodes 1206-1 and 1206-2, Step S1204 may include two assignments (one for each compute node) , or Step S1204 may be performed twice (once for each compute node) . It may be preferable for Step S1204 to follow Step S1203, ensuring that the BS 1208 is aware of the scheduling requirements of the service before the client device 1202 initiates communication with the compute node 1206. However, it is also possible for Step S1204 to precede Step S1203, with scheduling proceeding on a best-effort basis until the BS 1208 is informed of the service profile or information derived from the service profile.

[0127] In Step S1205, the client device 1202 and the compute node 1206 exchange compute data and results in a bidirectional process labeled as “Offload” in FIG. 12. The communications of Step S1205 are depicted with a direct arrow in FIG. 12, but in the context of a wireless system, the actual transmissions of data may traverse one or more BSs, one or more additional network nodes such as CN nodes, and so on, forming a route through the system between the client device 1202 and the compute node 1206. It should be understood that the topology of FIG. 12 is only exemplary, and actual systems may involve different interactions between particular nodes and one or more BSs, depending, for example, on which functionalities are embodied in mobile devices and which in network nodes.

[0128] In some embodiments, Step S1203 may be performed by the client device 1202 rather than the orchestrator 1204. That is, the client device 1202 may deliver the service profile, or information derived from the service profile, to the BSs 1208. The communication between the client device 1202 and the BSs 1208 to deliver this information may, for example, involve a message of an RRC protocol, such as a UEAssistanceInformation message, in which the client device 1202 indicates information to assist the scheduler (e.g., a traffic pattern, a latency requirement, a packet size, etc., as discussed earlier in the context of information from the orchestrator 1204) . However, it should be noted that in such cases, communication between different BSs may be required. For example, if the client device 1202 is served by the first BS 1208-1 while the compute node 1206-2 is served by the second BS 1208-2 different from the first BS 1208-1, and the client device 1202 provides information derived from the service profile to the first BS 1208-1, it may be necessary for the first BS 1208-1 to share this information with the second BS 1208-2, or the information may be delivered from the client device to the second BS 1208-2 via the first BS 1208-1. This ensures that the second BS 1208-2 can consider the information when scheduling communications for the compute node 1206-2. Alternatively, the information in Step S1203 may be delivered from the orchestrator 1204, as shown in FIG. 12, to address each involved BS individually, without requiring the BSs 1208 to engage in cross-communication of service information. Both mechanisms may coexist and be used together, depending, for example, on the accessibility of the orchestrator 1204 to each BS 1208.

[0129] FIG. 13 is a diagram 1300 showing an example of interactions between a client device 1302, an orchestrator 1304, a compute node 1306, and a base station 1308 including a radio scheduler, supporting performance monitoring and communication adaptation corresponding to the performance monitoring. These interactions are used for the management of the scheduler in an ongoing compute-intensive service, in response to monitoring performance data. FIG. 13 begins after the establishment of the service, specifically after an offload path has been established between a client device and a compute node (which may be instantiated at a network node or a mobile device) . As depicted in FIG. 13, the establishment involves the client device 1302, the orchestrator 1304 (which may also be instantiated at a network node or a mobile device) , the compute node 1306, and the BS 1308 including the radio scheduler. As with previous figures and descriptions, the compute node 1306 may be one of a plurality of compute nodes in a cluster managed by the orchestrator 1304, and the BS 1308 may be one of a plurality of BSs serving different concerned nodes (e.g., the client device 1302 may be served by a first BS similar to the BS1 1208-1 and the compute node 1306 by a second BS similar to the BS2 1208-2) . The BS 1308 is responsible for radio scheduling of the communications to and from the client device 1302 and, optionally, of the communications to and from the compute node 1306 (e.g., if the compute node 1306 is instantiated at a mobile device) .

[0130] In Step S1301, compute offload occurs between the client device 1302 and the compute node 1306. This step may involve a bidirectional operation in which the client device 1302 sends input data for a compute task to the compute node 1306, and the compute node 1306 sends the results of executing the compute task back to the client device 1302. As with the previous figures, the offload path between the client device 1302 and the compute node 1306 may use various forms of transport (e.g., a user-plane data bearer, a compute bearer, etc. ) and may be routed through the BS 1308 and / or other nodes (e.g., network nodes, nodes of a mesh network of communicating devices, etc. ) .

[0131] In Step S1302, the client device 1302 sends first performance data to the orchestrator 1304. The first performance data may represent the performance of one or more compute tasks as observed by the client device 1302. For example, it may include information on the actual latency experienced at the client device 1302 between the transmission of one or more packets of data for a compute task and the reception of one or more packets of results from executing the compute task, the motion-to-photon delay of an immersive communication service, and so on. The first performance data may be considered, for example, as service-level QoS or QoE information. It should be noted that the performance of a compute task, as observed by the client device 1302, typically includes both the actual compute performance (e.g., the time to execute the compute task at the compute node 1306) and the related communication performance (e.g., the propagation time of messages and / or packets through the system to facilitate the execution of the compute task) .

[0132] In Step S1303, the compute node 1306 sends second performance data to the orchestrator 1304. The second performance data may represent the performance of one or more compute tasks as observed by the compute node 1306; for example, it may include information on the execution time of an instance of a compute task at the compute node 1306, such as the time observed between the compute node’s reception of data for the compute task and its transmission of results from executing the compute task. The second performance data may be considered as service-level QoS information. It should be noted that the second performance data reported by the compute node 1306 may not include aspects of the related communication performance.

[0133] In Step S1304, the orchestrator 1304 conducts a performance evaluation based, for example, on the first performance data and the second performance data. The performance evaluation may consider any aspects of the first and second performance data, including comparing the two datasets in relation to one another. Specifically, comparing the first and second performance data for the same compute task may enable the orchestrator 1304 to estimate the communication performance of the offload path between the client device 1302 and the compute node 1306.

[0134] In Step S1305, the orchestrator 1304 may send communication adjustments to the BS 1308, which may be derived, for instance, from the performance evaluation. For example, the orchestrator 1304 may determine, based on performance evaluation, that the offload path is exhibiting elevated communication latency. This condition may compromise the ability of the compute service to meet predefined Quality of Service (QoS) and / or Quality of Experience (QoE) targets (such a scenario may arise, for instance, if the compute node 1306 reports low latency in the second performance data while the client device 1302 reports high latency in the first performance data) . In such a case, the orchestrator 1304 may instruct the BS 1308 in the communication adjustments to (attempt to) schedule radio resources for lower latency, for instance, by reducing a target latency previously communicated to the BS 1308. Alternatively, the client device 1302 and / or the compute node 1306 may interact with the involved BS 1308 to enhance communication. In some embodiments, the communication adjustments may include a trigger to relocate the client device 1302 and / or the compute node 1306 from a first (serving) BS to a second (target) BS, for example, via a handover to a BS expected to offer lower latency. In some embodiments, the communication adjustments may include a request or instruction for a priority change of the traffic associated with the offload of one or more compute tasks, an increase or decrease in the target data rate (e.g., a guaranteed bit rate) offered to the client device 1302 and / or the compute node 1306, and so on. The communication in Step S1305 between the orchestrator 1304 and the BS 1308 may use various forms of transport, such as an air interface and / or network interfaces, depending on the topology of the system, the location of the orchestrator 1304 in the system, whether the orchestrator 1304 is hosted at a network node or a mobile device, and so on.

[0135] In addition to the steps illustrated in FIG. 13, in some embodiments, the BS 1308 may send one or more indications of its own conditions (e.g., radio conditions, scheduler conditions, metrics of congestion, etc. ) to the orchestrator 1304 to assist in the formulation of communication adjustments. This step (not shown in FIG. 13) may occur, for example, prior to Step S1305. In some cases, such as during an ongoing offload operation for a continuous service, the BS 1308 may report its conditions to the orchestrator 1304 periodically or intermittently. In other cases, the BS 1308 may report its conditions based on one or more events, such as a congestion metric exceeding a predefined threshold. The information provided in this step may enable the orchestrator 1304 to formulate communication adjustments that enhance the performance of the service; for example, the orchestrator 1304 may determine that the communication performance for offloading a task is causing (or at risk of causing) the service to fail to meet one or more performance requirements. Accordingly, the orchestrator 1304 may request adjustments to the communication configuration, such as a reduced Packet Delay Budget (PDB) , changes to the anticipated traffic pattern, and so on, to improve communication performance and better support the underlying service. In another example, if the orchestrator 1304 is informed that a first BS is experiencing heavy congestion, it may decide to hand over the client device 1302 and / or the compute node 1306 to a second BS with lower congestion. If the orchestrator 1304 receives this information proactively from the BS 1308, it may anticipate a degradation in service performance more quickly than if it waited for the degradation to appear in the first and / or second performance data from the client device 1302 and / or the compute node 1306, respectively.

[0136] FIG. 12 and FIG. 13 involve coordination with RAN. In such scenarios, the service profile, or information derived from the service profile, is exposed to a RAN node (e.g., a BS) to enable optimized radio resource scheduling. For example, the BS may be provided with details such as expected traffic patterns, periodicity, packet size, latency requirements, and other service-specific parameters.

[0137] While some of these parameters align with traditional communication QoS metrics, others (e.g., traffic patterns) extend beyond conventional communication QoS definitions. The BS may utilize this information according to its specific implementation, as this coordination mechanism is not expected to be standardized.

[0138] In conventional systems, the RAN is typically insulated from service information, except for what is conveyed through the communication QoS profile when a bearer is set up. The present disclosure introduces a novel coordination mechanism that enables the RAN to access and act on service-specific information, thereby enhancing scheduling efficiency and performance. Specifically, FIG. 12 illustrates the service setup phase, where the service profile is communicated to the RAN, while FIG. 13 depicts adjustments made to the service configuration based on performance monitoring results.

[0139] FIG 14 is a flow diagram 1400 showing an example of a bearer setup between the client device 1402 and a compute node 1406 in the network, initiated by the compute node 1406 in the network.

[0140] In some embodiments, the distribution of the service profile (and / or information derived therefrom) and / or the request to manage a session or bearer may originate from a compute node rather than from the orchestrator 1404. FIG. 14 illustrates an exemplary message flow for such an embodiment, similar to FIG. 11 except for the origination of the first step. After the selection of the compute node 1406 in step S1400, the compute node 1406 (which may be one of a plurality of compute nodes, for example, executing different tasks associated with an application) sends a request to a network node, such as an SMF or a PCF (not shown in the figure) , to establish a session and / or a bearer for compute offload between the client device 1402 and the compute node 1406. The subsequent steps are the same as in FIG. 11, in accordance with well-known procedures for establishing a user-plane PDU session. For example, the SMF may select a UPF and trigger the creation or modification of a PDU session with the UPF and an AMF, resulting in a reconfiguration operation among the AMF, a serving BS 1408, and the client device 1402. Following the establishment of such a session, the client device 1402 can offload compute activity to the compute node 1406, as depicted in steps S1407-S1410. The session request in step S1401 may include a service profile or information derived therefrom, which may inform the configuration of the session / bearer to support radio operations (e.g., scheduling of air interface transmissions) in accordance with the requirements of the service. This embodiment may be advantageous, for example, if the compute node 1406 maintains its own knowledge of one or more offered microservices, enabling the compute node 1406 to automatically know the service profile of its own service.

[0141] In some embodiments, the message flow of Figure (s) 11 and / or 14 may be adapted to support the orchestrator and / or the compute node being hosted in mobile devices, rather than in network nodes as suggested by the figures. In such a scenario, the session request (step S1101 or step S1401) may be realized as an over-the-air signaling message, such as a Non-Access Stratum (NAS) message, from the involved mobile device to the network node (s) responsible for initiating the session establishment (e.g., the PCF and / or the SMF) . The remainder of the session establishment may proceed as shown in the figures or according to other general procedures for establishing a communication session between the client device 1402 and the compute node 1406.

[0142] The procedures described herein have used a user-plane session configuration as a running example; however, as previously noted, it should be understood that a session used for compute offload may not necessarily be realized as a user-plane session (e.g., a PDU session) . In some embodiments, a session or interaction for compute offload may be modeled as part of a "compute plane, " where sessions may, for example, transport data between the client device 1402 and the compute node 1406 without anchoring at a UPF. Data transfer over such a compute plane may exhibit certain characteristics of user-plane (UP) data transfer (e.g., the presence of communication QoS) and other characteristics of control-plane operation (e.g., direct communication to a node of the system that may be located at a peer device, at a radio node of the network, etc., without being associated with a PDU session toward an external data network) . Alternatively, communication between the client device 1402 and the compute node 1406 may be based on a control-plane model (potentially with the addition of communication QoS parameters to the control-plane bearer (s) ) , which could, for example, mean that compute data are carried in an encapsulated form between the client device 1402 and a compute node 1406 (which may be located at a network node or a peer device) within signaling messages of the control plane. In such cases, the session between the compute node 1406 and the client device 1402 may be managed by an upper-layer protocol, such as a protocol layer responsible for carrying data for compute offload.

[0143] The session configuration procedure in FIG. 11 and FIG. 14 involves coordination with the CN. Specifically, the orchestrator 1104 or the compute node 1406 initiates a request to a CN node, such as the SMF. This request may be routed through other CN nodes, such as the PCF. If the orchestrator 1104 or compute node 1406 is implemented as a UE, the request may be communicated to the CN via NAS signaling. Upon receiving the request, the CN triggers a series of messages to establish or modify a communication session. The session configuration is driven by the service profile, which defines how the compute service should be configured or reconfigured. The orchestrator 1104 or compute node 1406 shares the necessary information with the CN to ensure the session aligns with the service profile requirements. Then, the core network can configure a bearer with appropriate QoS parameters and allocate resources tailored to the service's communication needs.

[0144] The message flows in FIG. 11 and FIG. 14 are largely identical, with the primary difference being the entity that initiates the process. In FIG. 11, the orchestrator 1104 triggers the session configuration, while in FIG. 14, the compute node 1406 serves as the initiator. In both cases, the request, originating from either the orchestrator 1104 (FIG. 11) or the compute node 1106 (FIG. 14, is ultimately directed to the SMF, though it may be routed through intermediate nodes such as the PCF, as described earlier.

[0145] Upon receiving the request, the SMF performs UPF selection if a new service is being set up. This selection identifies the appropriate UPF to handle the session. The SMF then triggers the creation or modification of a PDU session and sends a PDU session update to the AMF. The AMF then triggers the reconfiguration through the base station to the client device.

[0146] Once the bearer is configured or reconfigured, data for the compute task begin to flow. The data travel from the client device to the UPF and then to the compute node, with the computation results returning from the compute node to the UPF and back to the client device.

[0147] FIG. 11 and FIG. 14 focus on scenarios where the request for session configuration originates from either the orchestrator or the compute node. In addition to session setup, this framework is also applicable to scenarios where the orchestrator monitors an ongoing session involving compute offload to a compute node. During such monitoring, the orchestrator may identify conditions necessitating changes to the session configuration. For example, if a compute node experiences a slowdown in performance, the bearer may need to be reconfigured to allocate less communication time (e.g., a reduced packet delay budget) , thereby allowing the compute node sufficient time to complete its computations. Conversely, if a compute node allocates additional resources to the cluster and accelerates its task execution, the communication QoS requirements on the bearer may be relaxed.

[0148] In conventional systems, such session configuration requests typically originate from the client device. While this configuration remains a viable solution and is currently under investigation, the present disclosure focuses on scenarios where the request originates from the orchestrator or compute node. This approach may be particularly applicable when the orchestrator monitors compute activity and determines that the performance of the compute node necessitates or allows reconfiguration of the bearer. For instance, the orchestrator may conclude that "the performance of the compute node implies that the bearer must / can be reconfigured" to meet the service profile requirements.

[0149] The present disclosure optimizes a specific service such as a compute-intensive service in a communication network through dynamic coordination among orchestrators, compute nodes, and client devices. For example, in the CN coordination mechanism, the orchestrator or compute node may trigger the core network to establish or modify data bearers, ensuring QoS requirements. In the RAN coordination mechanism, scheduling assistance information may be transmitted to a RAN node, such as a base station, enabling the base station to optimize radio resource scheduling based on performance requirements. Furthermore, during service operation, the performance of the compute node (s) may be monitored, and bearer configurations may be dynamically adjusted to maintain optimal performance. The orchestrator and compute nodes may be located at the UE, RAN cloud, or CN, supporting distributed deployment and enhancing system flexibility.

[0150] FIG. 15 illustrates a flow chart 1500 of a process for service profile and quality-of-service management. The process is directed to wireless communication of a device in a communication system including multiple nodes distributed in at least one network domain. The device is a first node within the multiple nodes. In this disclosure, the term “apparatus” or “device” is used to refer to any type of device, including but not limited to a UE, a mobile device, or a network device.

[0151] At block 1502, the process includes: obtaining, at the first node, a service profile of a service. The service profile may define performance requirement for the service.

[0152] Subsequently, at block 1504, the process includes: generating a network-domain-specific configuration information based on the service profile.

[0153] Thereafter, at block 1506, the process includes: sending, to a second node within the multiple nodes, the network-domain-specific configuration information to enable a network-domain-specific operation for the service. The network-domain-specific operation may be related to resource allocation for the service.

[0154] In certain configurations, at least one of the multiple nodes may be located on a user equipment (UE) , on a radio access network (RAN) element or on a core network (CN) element.

[0155] In certain configurations, the first node may be an orchestrator or a compute node.

[0156] In certain configurations, the at least one network domain may include a radio access network (RAN) domain or a core network (CN) domain.

[0157] In certain configurations, the second node may be a scheduler node within the RAN domain, the network-domain-specific configuration information may include scheduling assistance information for the service, and the network-domain-specific operation may include: performing, by the scheduler node, scheduling for at least one node within the multiple nodes based on the scheduling assistance information.

[0158] In certain configurations, the first node may generate the service profile, or may receive the service profile from a third node within the multiple nodes or an external repository.

[0159] In certain configurations, the third node may be a client node of the service.

[0160] In certain configurations, the third node may be in correspondence with a task repository. The task repository may contain an image for a task of the service.

[0161] In certain configurations, the process may further include: sending, to a compute node within the multiple nodes, an assignment to perform a task of the service.

[0162] In certain configurations, the process may further include: sending, to a client node within the multiple nodes, information of the compute node.

[0163] In certain configurations, the first node may receive the service profile from the client node.

[0164] In certain configurations, the process may further include: sending, to the compute node, information derived from the service profile.

[0165] In certain configurations, the network-domain-specific configuration information may include link utilization requirements, and the link utilization requirements may include one or any combination of a traffic data rate, a traffic packet size, a traffic packet periodicity, and a communication latency requirement.

[0166] In certain configurations, the multiple nodes form at least one cluster. When a client device and a compute node within a same cluster are connected via multiple base stations (BSs) , the link utilization requirements may be forwarded from one BS to another BS among the multiple base stations.

[0167] In certain configurations, the process may further include: sending, to the second node, a communication adjustment instruction to perform communication adjustment based on real-time performance monitoring feedback. For example, the adjustment may relax the communication QoS requirements as more powerful compute resources become available.

[0168] In certain configurations, the communication adjustment instruction may include: one or any combination of a changed latency target, a traffic priority change, a target data rate change, and a handover trigger from a serving base station (BS) to a target BS.

[0169] In certain configurations, the first node may generate the communication adjustment instruction based on a condition report from the serving BS.

[0170] In certain configurations, the first node may include an orchestrator and the orchestrator may generate the communication adjustment instruction by receiving first performance data from the client node and second performance data from the compute node; and evaluating a communication path between the client node and the compute node by comparing the first performance data and the second performance data.

[0171] In certain configurations, the second node may include a core network (CN) node, and the sending may include: delivering, to the second node, at least one portion of the network-domain-specific configuration information through another CN node.

[0172] In certain configurations, the second node may include an Access and Mobility Management Function (AMF) node, and the another CN node may include a Session Management Function (SMF) node or a Policy Control Function node.

[0173] In certain configurations, the second node may include a CN node; the network-domain-specific configuration information may include a request for management of a session for communication between a client node and a compute node within the multiple nodes, the request may include information derived from the service profile; and the network-domain-specific operation may include: triggering a bearer configuration or reconfiguration for the service.

[0174] In certain configurations, the information derived from the service profile may include one or any combination of a traffic data rate, a traffic packet size, a traffic periodicity, and a latency requirement.

[0175] It is understood that the specific order or hierarchy of blocks in the processes  / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes  / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0176] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”

Claims

1.A method of wireless communication of a device in a communication system comprising multiple nodes distributed in at least one network domain, the device being a first node within the multiple nodes, the method comprising:obtaining, at the first node, a service profile of a service, the service profile defining performance requirement for the service;generating a network-domain-specific configuration information based on the service profile; andsending, to a second node within the multiple nodes, the network-domain-specific configuration information to enable a network-domain-specific operation for the service, the network-domain-specific operation being related to resource allocation for the service.2.The method of claim 1, wherein at least one of the multiple nodes is located on a user equipment (UE) , on a radio access network (RAN) element, or on a core network (CN) element.3.The method of claim 1, wherein the first node is an orchestrator or a compute node.4.The method of claim 1, wherein the at least one network domain comprises a radio access network (RAN) domain or a core network (CN) domain.5.The method of claim 4, wherein the second node is a scheduler node within the RAN domain, the network-domain-specific configuration information comprises scheduling assistance information for the service, and the network-domain-specific operation comprises:performing, by the scheduler node, scheduling for at least one node within the multiple nodes based on the scheduling assistance information.6.The method of claim 1, wherein the first node generates the service profile, or receives the service profile from a third node within the multiple nodes or an external repository.7.The method of claim 6, wherein the third node is a client node of the service.8.The method of claim 6, wherein the third node is in correspondence with a task repository, and the task repository contains an image for a task of the service.9.The method of claim 1, further comprising:sending, to a compute node within the multiple nodes, an assignment to perform a task of the service.10.The method of claim 9, further comprising:sending, to a client node within the multiple nodes, information of the compute node.11.The method of claim 10, wherein the first node receives the service profile from the client node.12.The method of claim 9, further comprising:sending, to the compute node, information derived from the service profile.13.The method of claim 1, wherein the network-domain-specific configuration information comprises link utilization requirements, and the link utilization requirements comprises one or any combination of a traffic data rate, a traffic packet size, a traffic packet periodicity, and a communication latency requirement.14.The method of claim 13, wherein the multiple nodes form at least one cluster, and wherein, when a client device and a compute node within a same cluster are connected via multiple base stations (BSs) , the link utilization requirements are forwarded from one BS to another BS among the multiple base stations.15.The method of claim 10, further comprising:sending, to the second node, a communication adjustment instruction to perform communication adjustment based on real-time performance monitoring feedback.16.The method of claim 15, wherein the communication adjustment instruction comprises: one or any combination of a changed latency target, a traffic priority change, a target data rate change, and a handover trigger from a serving base station (BS) to a target BS.17.The method of claim 16, wherein the first node generates the communication adjustment instruction based on a condition report from the serving BS.18.The method of claim 15, wherein the first node comprises an orchestrator and the orchestrator generates the communication adjustment instruction byreceiving first performance data from the client node and second performance data from the compute node; andevaluating a communication path between the client node and the compute node by comparing the first performance data and the second performance data.19.The method of claim 1, wherein the second node comprises a core network (CN) node, and the sending comprises:delivering, to the second node, at least one portion of the network-domain-specific configuration information through another CN node.20.The method of claim 19, wherein the second node comprises an Access and Mobility Management Function (AMF) node, and the another CN node comprises a Session Management Function (SMF) node or a Policy Control Function node.21.The method of claim 4, wherein the second node comprises a CN node; the network-domain-specific configuration information comprises a request for management of a session for communication between a client node and a compute node within the multiple nodes, the request comprising information derived from the service profile; and the network-domain-specific operation comprises:triggering a bearer configuration or reconfiguration for the service.22.The method of claim 21, wherein the information derived from the service profile comprises one or any combination of a traffic data rate, a traffic packet size, a traffic periodicity, and a latency requirement.23.An apparatus for wireless communication, the apparatus being a first node within multiple nodes comprised in a communication system, the multiple nodes being distributed in at least one network domain, the apparatus comprising:a memory; andat least one processor coupled to the memory and configured to:obtain a service profile of a service, the service profile defining performance requirement for the service;generate a network-domain-specific configuration information based on the service profile; andsend, to a second node within the multiple nodes, the network-domain-specific configuration information to enable a network-domain-specific operation for the service, the network-domain-specific operation being related to resource allocation for the service.24.A computer-readable medium storing computer executable code for wireless communication of a device, the device being a first node within multiple nodes comprised in a communication system, the multiple nodes being distributed in at least one network domain, the computer-readable medium comprising code to:obtain a service profile of a service, the service profile defining performance requirement for the service;generate a network-domain-specific configuration information based on the service profile; andsend, to a second node within the multiple nodes, the network-domain-specific configuration information to enable a network-domain-specific operation for the service, the network-domain-specific operation being related to resource allocation for the service.

Images