COMPUTING SERVER REGISTRATION WITH A COMPOSITION MANAGEMENT FUNCTION FOR COMPUTING OFFLOAD ON A WIRELESS NETWORK

Description

1 / 58 COMPUTING SERVER REGISTRATION WITH A COMPOSITION MANAGEMENT ROLE FOR COMPUTING OFFLOAD INTO A WIRELESS NETWORK Cross-reference to related request(s)

[0001] This application claims the benefits of U.S. Provisional Application Serial No. 63 / 506,839, entitled “Compute server registration with a composition management function in a wireless network,” filed June 8, 2023, and U.S. Provisional Application Serial No. 63 / 506,841, entitled “Composition management function for compute offload in a wireless network,” filed June 8, 2023. Disclosure of each of the above-identified applications is expressly incorporated by reference herein in its entirety. Technical field

[0002] This disclosure relates generally to communication systems and, more particularly, to techniques, methods and apparatus for a computing server register with a composition management function for computing offload on a wireless network. State of the art

[0003] The statements in this section provide background information only in relation 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 broadcasting. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users through the sharing of available system resources. Examples of such multiple access technologies include code division multiple access (CDMA) systems, access systems Petition 870250096357, dated 10 / 22 / 2025, page 10 / 101 2 / 58 Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), and Time Division Synchronous Code Division Multiple Access (TD-SCDMA).

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

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

[0007] According to one aspect of the disclosure, are Petition 870250096357, dated 10 / 22 / 2025, p. 11 / 101 3 / 58 provided a method, a computer-readable medium, and an apparatus. The method can be implemented by a device in a wireless system. In certain configurations, the device instantiates a Composition Management Function (CMF). The device receives, via the CMF, from a client node in the wireless system, a client registration request. The device transmits, via the CMF, to the client node, a client registration response. The device receives, via the CMF, from the client node, a compute resource request. The device transmits, via the CMF, to the client node, a compute resource response.

[0008] According to another aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The method can be implemented by a device of a wireless system. In certain configurations, the device instantiates a CMF. The device receives, via the CMF, from a computing server function (CSF) of the wireless system, a server registration request. The device transmits, via the CMF, to the CSF, a server registration response.

[0009] According to a further aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The method can be performed by a client node of a wireless system. The client node transmits a client registration request to a composition management function (CMF) in the wireless system. The client node receives a client registration response from the CMF. The client node transmits a computation resource request to the CMF. The client node receives a computation resource response from the CMF.

[0010] The method can be performed by a UE. In certain configurations, the UE initiates an initial registration procedure on a first autonomous non-public network. Petition 870250096357, dated 10 / 22 / 2025, page 12 / 101 4 / 58 (standalone non-public network) (SNPN). In response to a first event, the UE performs one or more actions, including: aborting the first registration procedure, resetting a procedure attempt counter corresponding to the first registration procedure, stopping a timer corresponding to the first registration procedure, locally releasing a non-access stratum signaling connection (NAS) if the NAS signaling connection exists, and entering a public land mobile network (PLMN) search state to execute an SNPN selection procedure.

[0011] For the purposes set forth above and for related purposes, one or more aspects comprise the features described in detail below and particularly indicated in the claims. The following description and the accompanying figures set out in detail certain illustrative features of one or more aspects. These features are indicative, however, of only some 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 figures

[0012] FIG. 1 is a diagram that illustrates an example of a wireless communications system and an access network.

[0013] FIG. 2 is a diagram illustrating a base station communicating with a UE on an access network.

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

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

[0016] FIG. 5 is a diagram that illustrates an MEC architecture according to a 5G system design.

[0017] FIG. 6 is a diagram illustrating an example of computing offloading to different locations in a Petition 870250096357, dated 10 / 22 / 2025, page 13 / 101 5 / 58 wireless system.

[0018] FIG. 7 is a diagram that illustrates an example of an architecture for offloading computing in a way that is integrated with communication in a wireless system.

[0019] FIG. 8 illustrates an example of a protocol set for communication between a client device, a composition management function (CMF), and a compute server function (CSF).

[0020] FIG. 9 illustrates an example of a transaction type set for a computation control protocol (CCP) between a client device and a CMF.

[0021] FIG. 10 illustrates an example of a transaction type set for a computation management protocol (CMP) between a CMF and a CSF.

[0022] FIG. 11 illustrates an example of a transaction type for a compute offload protocol (COP) between a client device and a CSF.

[0023] FIG. 12 illustrates an example of an architecture for offloading computation in a way that is integrated with communication in a wireless system, in which each of a CMF and a CSF is instantiated on a device.

[0024] FIG. 13 illustrates an example of an architecture for offloading computing in a way that is integrated with communication in a wireless system, in which a CMF is associated with a distributed unit (DU) of a base station.

[0025] FIG. 14 illustrates an example of an architecture for computing offloading in a way that is integrated with communication in a wireless system, in which a CMF is instantiated on the network and a CSF is instantiated on a device.

[0026] FIG. 15 illustrates an example of a protocol stack set for transporting CCP over a radio resource control (RRC) protocol.

[0027] FIG. 16 illustrates an example of a stack assembly. Petition 870250096357, dated 10 / 22 / 2025, p. 14 / 101 6 / 58 of protocol for transporting CCP over a packet data convergence protocol (PDCP) layer, in which the CMF is associated with a DU of a base station.

[0028] FIG. 17 illustrates an example of a protocol stack set for CCP transport over a PDCP layer, in which the CMF is associated with a central unit (CU) of a base station.

[0029] FIG. 18 illustrates an example of a protocol stack set for CCP transport between two peer devices, in which one device acts as a client and the other hosts a CMF.

[0030] FIG. 19 illustrates another example of a protocol stack set for CCP transport between two peer devices, in which one device acts as a client and the other hosts a CMF.

[0031] FIG. 20 illustrates an example of a protocol stack set for COP transport between a client and a CSF, in which the CSF is associated with a DU of a base station.

[0032] FIG. 21 illustrates an example of a protocol stack set for COP transport between two peer UEs, in which one device acts as a client and the other hosts a CSF.

[0033] FIG. 22 illustrates another example of a protocol stack set for COP transport between two peer UEs, in which one device acts as a client and the other hosts a CSF.

[0034] FIG. 23 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which the CMF is associated with a CU of a base station and the CSF is associated with a DU of a base station.

[0035] FIG. 24 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, Petition 870250096357, dated 10 / 22 / 2025, p. 15 / 101 7 / 58 in which the CMF is associated with a DU of a base station and the CSF is associated with another DU of a base station.

[0036] FIG. 25 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which the CMF is associated with a CU of a base station and the CSF is associated with another CU of a base station.

[0037] FIG. 26 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which the CMF is instantiated on a base station and the CSF is hosted on a UE.

[0038] FIG. 27 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which the CMF is associated with a base station CU and the CSF is hosted on a UE.

[0039] FIG. 28 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which both the CMF and the CSF are hosted on two UEs.

[0040] FIG. 29 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which the CMF is instantiated on a CN and the CSF is hosted on a UE.

[0041] FIG. 30 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, in which the CMF is instantiated on a CN and the CSF is hosted on a UE.

[0042] FIG. 31 illustrates an example of message flow for a computing session involving a client, a first CSF, a second CSF, and a CMF.

[0043] FIG. 32 is a flowchart of a method (process) for wireless communication of a device.

[0044] FIG. 33 is a flowchart of a method (process) for wireless communication of a device.

[0045] FIG. 34 is a flowchart of a method (process) Petition 870250096357, dated 10 / 22 / 2025, page 16 / 101 8 / 58 for wireless communication from a client node. Detailed description

[0046] The detailed description presented below in connection with the accompanying figures is intended to describe various configurations and is not intended to represent the only configurations in which the concepts described herein can be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be evident to those skilled in the art that these concepts can be practiced without these specific details. In some cases, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0047] Various aspects of telecommunications systems will now be presented with reference to various devices and methods. These devices and methods will be described in the detailed description below and illustrated in the attached figures 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 of the two. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0048] By way of example, an element, or any part 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), processors with Petition 870250096357, dated 10 / 22 / 2025, page 17 / 101 9 / 58 Reduced Instruction Set Computing (RISC), systems on a chip (SoC), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in the processing system may execute software. The term software should be interpreted broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, execution threads, procedures, functions, etc., regardless of whether they are termed software, firmware, middleware, microcode, hardware description language, or another equivalent term.

[0049] Thus, in one or more example aspects, the functions described may be implemented in hardware, software, or any combination of the two. If implemented in software, the functions may be stored or encoded as one or more instructions or codes on a computer-readable medium. Computer-readable media include 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 may comprise random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the types of computer-readable media mentioned above, or any other media that may Petition 870250096357, dated 10 / 22 / 2025, page 18 / 101 10 / 58 can be used to store executable computer code in the form of instructions or data structures that can be accessed by a computer.

[0050] 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 stations) and / or small cells (low-power cellular base stations). Macrocells include base stations. Small cells include femtocells, picocells, and microcells.

[0051] Base stations 102 configured for 4G LTE (collectively referred to as the Evolved Terrestrial Radio Access Network (E-UTRAN) of the Evolved Universal Mobile Telecommunications System (UMTS)) can interconnect with the EPC 160 via backhaul links 132 (e.g., interface S1). Base stations 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN)) can interconnect with the core network 190 via backhaul links 184.In addition to other functions, 102 base stations can perform one or more of the following functions: user data transfer, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), cell interference coordination, connection establishment and release, load balancing, non-access stratum (NAS) message distribution, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast and multicast service (MBMS), tracking. Petition 870250096357, dated 10 / 22 / 2025, page 19 / 101 11 / 58 subscriber and equipment, RAN information management (RIM), paging, positioning, and alert message delivery. Base stations 102 can communicate directly or indirectly (e.g., via EPC 160 or the central network 190) with each other through backhaul links 134 (e.g., X2 interface). The backhaul links 134 can be wired or wireless.

[0052] Base stations 102 can communicate wirelessly with UEs 104. Each of the base stations 102 can provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, small cell 102' may have a coverage area 110' that overlaps with the coverage area 110 from one or more macro base stations 102. A network that includes both small cells and macrocells may be known as a heterogeneous network. A heterogeneous network may also include Home Evolved Node Bs (home eNBs) (HeNBs), which may provide service to a select group known as a closed subscriber group (CSG). Communication links 120 between base stations 102 and UEs 104 may include uplink (UL) transmissions (also referred to as reverse link) from a UE 104 to a base station 102 and / or downlink (DL) transmissions (also referred to as direct link) from a base station 102 to a UE 104. Communication links 120 may employ multiple-input multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or broadcast diversity. Communication links can be established through one or more carriers.Base stations 102 / UEs 104 can use spectrum up to 7 MHz (e.g., 5, 10, 15, 20, 100, 400, etc. MHz) of bandwidth per carrier, allocated in a carrier aggregation of up to a total of Yx MHz (x carriers). Petition 870250096357, dated 10 / 22 / 2025, p. 20 / 101 12 / 58 components) used for transmission in each direction. Carriers may or may not be adjacent to each other. Carrier allocation may be asymmetrical with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL than to UL). Component carriers may include a primary component carrier and one or more secondary component carriers. A primary component carrier may be called a primary cell (PCell) and a secondary component carrier may be called a secondary cell (SCell).

[0053] Certain UEs 104 can communicate with each other using a device-to-device (D2D) communication link 158. The D2D communication link 158 can use the WWAN DL / UL spectrum. The D2D communication link 158 can 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 can occur through various D2D wireless communication systems, such as FlashLinQ, WiMedia, Bluetooth, ZigBee, IEEE 802.11-based Wi-Fi, LTE, or NR.

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

[0055] The 102' small cell can operate in a licensed and / or unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the 102' small cell Petition 870250096357, dated 10 / 22 / 2025, p. 21 / 101 13 / 58 can employ NR and use the same unlicensed 5 GHz frequency spectrum used by the Wi-Fi access point 150. The small cell 102', employing NR in an unlicensed frequency spectrum, can extend coverage and / or increase the capacity of the access network.

[0056] A base station 102, whether a small cell 102' or a large cell (e.g., macro base station), may include an eNB, a gNodeB (gNB), or another type of base station. Some base stations, such as gNB 180, may operate in traditional spectrum below 6 GHz, at millimeter wave (mmW) frequencies and / or frequencies close to millimeter waves, in communication with UE 104. When gNB 180 operates at mmW or near mmW frequencies, gNB 180 may be referred to as an mmW base station. Extremely high frequency (EHF) is part of the radio frequencies (RF) in the electromagnetic spectrum. EHF has a range from 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in this range may be referred to as millimeter waves. Frequencies close to mmW can extend up 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 called centimeter wave. Communications using the mmW / near mmW radio frequency band (e.g., 3 GHz to 300 GHz) exhibit extremely high path loss and short range. The mmW 180 base station can use beamforming 182 with UE 104 to compensate for the extremely high path loss and short range.

[0057] Base station 180 can transmit a beamformed signal to UE 104 in one or more transmission directions 108a. UE 104 can receive the beamformed signal from base station 180 in one or more reception directions 108b. UE 104 can also transmit a beamformed signal to the Petition 870250096357, dated 10 / 22 / 2025, p. 22 / 101 14 / 58 base station 180 in one or more transmission directions. Base station 180 can receive the beamformed signal from UE 104 in one or more reception directions. Base station 180 / UE 104 can perform beam training to determine the best reception and transmission directions for each of them. The transmission and reception directions of base station 180 may or may not be the same. The transmission and reception directions of UE 104 may or may not be the same.

[0058] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Service Gateway 166, a Multicast Multimedia Broadcast Service Gateway (MBMS) 168, a Multimedia Broadcast 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 signaling between the UEs 104 and the EPC 160. In general, the MME 162 provides logical bearer and connection management. All user Internet Protocol (IP) packets are transferred through Service Gateway 166, which, in turn, is connected to PDN Gateway 172. PDN Gateway 172 provides UE IP address allocation as well as other functions. PDN Gateway 172 and BM-SC 170 are connected to IP Services 176. IP 176 services can include the Internet, an intranet, a IP Multimedia Subsystem (IMS), a streaming service (PS) and / or other IP services. The BM-SC 170 can provide functions for the provisioning and delivery of MBMS user service. The BM-SC 170 can serve as an entry point for MBMS transmission from the content provider, can be used to authorize and initiate MBMS Carrier Services within a public terrestrial mobile network (PLMN), and can be used to schedule MBMS transmissions. The MBMS Gateway 168 can be used to distribute MBMS traffic to base stations 102. Petition 870250096357, dated 10 / 22 / 2025, page 23 / 101 15 / 58 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area that transmits a specific service, and may be responsible for session management (start / stop) and for collecting billing information related to eMBMS.

[0059] The core network 190 may include an 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. AMF 192 may be in communication with a Unified Data Management (UDM) 196. AMF 192 is the control node that processes signaling between UEs 104 and the core network 190. In general, SMF 194 provides QoS and session flow management. All user Internet Protocol (IP) packets are transferred through UPF 195. UPF 195 provides UE IP address allocation as well as other functions. UPF 195 is connected to IP Services 197. IP Services 197 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a PS streaming service, and / or other IP services.

[0060] The base station may also be referred to as gNB, Node B, evolved Node B (eNB), access point, transmitting base station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), transmit and receive point (TRP), or other suitable terminology. 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 mobile phone, a smartphone, 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 device Petition 870250096357, dated 10 / 22 / 2025, page 24 / 101 16 / 58 smart, a wearable device, a vehicle, an electric meter, a fuel pump, a large or small household appliance, a health device, an implant, a sensor / actuator, a display, or any other similarly functioning device. Some of the UEs 104 may be referred to as IoT devices (e.g., parking meter, fuel pump, toaster, vehicles, heart monitor, etc.). The UE 104 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communications device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handheld device, user agent, mobile client, client, or other suitable terminology.

[0061] Although this disclosure may refer to 5G New Radio (NR), this 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.

[0062] FIG. 2 is a block diagram of a base station 210 communicating with a UE 250 in an access network. On the downlink (DL), IP packets from EPC 160 can be provided to a controller / processor 275. The controller / processor 275 implements Layer 3 and Layer 2 functionalities. 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 Media Access Control (MAC) layer. The controller / processor 275 provides RRC layer functionalities associated with the transmission of system information (e.g., MIB, Petition 870250096357, dated 10 / 22 / 2025, page 25 / 101 17 / 58 SIBs), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), mobility between radio access technologies (RAT), and measurement configuration for UE measurement reports; PDCP layer functionalities associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functionalities associated with the transfer of upper-layer packet data units (PDUs), error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs;and MAC layer functionalities associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs into transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reports, error correction via HARQ, priority handling, and prioritization of logical channels.

[0063] The 216 transmit processor (TX) and the 270 receive processor (RX) implement Layer 1 functionalities associated with various signal processing functions. Layer 1, which includes a physical layer (PHY), may include error detection in transport channels, forward error correction (FEC) encoding / decoding of transport channels, interlacing, rate adjustment, mapping to physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The TX 216 processor performs signal constellation mapping based on various modulation schemes (e.g., binary phase-shift modulation (BPSK), quadrature phase-shift modulation (QPSK), M-level phase-shift modulation). Petition 870250096357, dated 10 / 22 / 2025, page 26 / 101 18 / 58 (M-PSK), M-level quadrature amplitude modulation (MQAM). The encoded and modulated symbols can then be divided into parallel streams. Each stream can be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined via an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a stream of OFDM symbols in the time domain. The OFDM stream is spatially pre-coded to produce multiple spatial streams. Channel estimates from a channel estimator 274 can be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate can be derived from a reference signal and / or channel condition feedback transmitted by UE 250. Each spatial stream can then be provided to a different antenna 220 via a separate transmitter 218TX.Each 218TX transmitter can modulate an RF carrier with the corresponding spatial stream for transmission.

[0064] In UE 250, each receiver 254RX receives a signal through its respective antenna 252. Each receiver 254RX retrieves modulated information about an RF carrier and provides this information to the receiving processor (RX) 256. The transmitting processor (TX) 268 and the receiving processor (RX) 256 implement Layer 1 functionalities associated with various signal processing functions. The RX 256 processor can perform spatial processing on the information to retrieve any spatial streams destined for UE 250. If multiple spatial streams are destined for UE 250, they can be combined by the RX 256 processor into a single OFDM symbol stream. The RX 256 processor then converts the OFDM symbol stream from the time domain to the frequency domain using a Petition 870250096357, dated 10 / 22 / 2025, page 27 / 101 19 / 58 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, determining the most probable signal constellation points transmitted by base station 210. These soft decisions can be based on channel estimates calculated by channel estimator 258. The soft decisions are then decoded and deinterlaced to recover the data and control signals that were originally transmitted by base station 210 on the physical channel. The data and control signals are then provided to the controller / processor 259, which implements the functionalities of layers 3 and 2.

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

[0066] Similar to the functionalities described in connection with DL transmission by base station 210, controller / processor 259 provides RRC layer functionalities associated with system information acquisition (e.g., MIB, SIBs), RRC connections, and measurement reports; PDCP layer functionalities associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); and RLC layer functionalities associated with upper-layer PDU transfer and error correction. Petition 870250096357, dated 10 / 22 / 2025, page 28 / 101 20 / 58 via ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs and reordering of RLC data PDUs; and MAC layer functionalities associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs into TBs, demultiplexing of MAC SDUs from TBs, scheduling information reports, error correction via HARQ, priority handling and prioritization of logical channels.

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

[0068] The controller / processor 275 may be associated with a memory 276 that stores program codes and data. Memory 276 may be referred to as computer-readable media. In the uplink (UL), the controller / processor 275 provides demultiplexing between transport channels and logical channels, packet reassembly, decryption, header decompression, and control signal processing to retrieve IP packets from UE 250. IP packets from the controller / processor 275 may be supplied to EPC 160. The controller / processor 275 is also responsible for detection Petition 870250096357, dated 10 / 22 / 2025, page 29 / 101 21 / 58 of errors using an ACK and / or NACK protocol to support HARQ operations.

[0069] New Radio (NR) may refer to radios configured to operate under a new air interface (e.g., different from Orthogonal Frequency Division Multiple Access (OFDMA)-based air interfaces) or fixed transport layer (e.g., different from Internet Protocol (IP)). NR may use OFDM with cyclic prefix (CP) on the uplink and downlink and may include support for semi-duplex operation using time-division duplexing (TDD). NR may include Enhanced Mobile Broadband (eMBB) service targeting wide bandwidth (e.g., above 80 MHz), millimeter waves (mmW) targeting high carrier frequencies (e.g., 60 GHz), massive MTC (mMTC) targeting non-backward compatible MTC techniques, and / or critical service targeting ultra-reliable low-latency communications (URLLC).

[0070] A single component carrier bandwidth of 100 MHz may be supported. In one example, NR resource blocks (RBs) may span 12 subcarriers with a subcarrier bandwidth of 60 kHz for a duration of 0.25 ms or a bandwidth of 30 kHz for a duration of 0.5 ms (similarly, 50 MHz bandwidth for 15 kHz intercarrier spacing (SCS) for a duration of 1 ms). Each radio frame may consist of 10 subframes (10, 20, 40, or 80 NR slots) with a duration 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 can be described in more detail below, with reference to FIGS. 5 and 6. Petition 870250096357, dated 10 / 22 / 2025, page 30 / 101 22 / 58

[0071] An NR RAN may include a central unit (CU) and distributed units (DUs). An NR base station (e.g., gNB, 5G Node B, Node B, transmit / receive point (TRP), access point (AP)) may correspond to one or more base stations. NR cells may be configured as access cells (ACells) or data-only cells (DCells). For example, the RAN (e.g., a central unit or distributed unit) may 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 other cases, DCells may transmit SS. NR base stations may transmit downlink signals to UEs indicating the cell type. Based on the cell type indication, the UE may communicate with the NR base station.For example, the EU may determine the NR base stations to be considered for cell selection, access, handover and / or measurement based on the indicated cell type.

[0072] FIG. 3 illustrates an example of the logical architecture of a distributed RAN 300, according to aspects of this 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 for the next-generation core network (NG-CN) 304 may terminate at the ANC. The backhaul interface for neighboring next-generation access nodes (NG-ANs) 310 may also terminate at the ANC. The ANC may include one or more TRPs 308 (which may also be referred to as base stations, NR base stations, Node Bs, 5G NBs, APs, or other equivalent terms). As described earlier, a TRP may be used interchangeably with “cell”.

[0073] 308 TRPs can be distributed units (DUs). TRPs can be connected to one ANC (ANC 302) or more than Petition 870250096357, dated 10 / 22 / 2025, p. 31 / 101 23 / 58 an ANC (not shown). For example, for RAN sharing, radio as a service (RaaS), and service-specific ANC implementations, the TRP may be connected to more than one ANC. A TRP may include one or more antenna ports. TRPs may be configured to serve traffic from an UE individually (e.g., dynamic selection) or jointly (e.g., joint transmission).

[0074] The local architecture of the distributed RAN 300 can be used to illustrate the definition of fronthaul. The architecture can be defined to support fronthauling solutions in different types of implementation. For example, the architecture can be based on transmission network capabilities (e.g., bandwidth, latency, and / or jitter). The architecture can share characteristics and / or components with LTE. In certain aspects, the next-generation access node (NG-AN) 310 can support dual connectivity with NR. The NG-AN can share a common fronthaul for LTE and NR.

[0075] The architecture can enable cooperation between and among TRPs 308. For example, there can be cooperation within a TRP and / or between TRPs via ANC 302. In certain aspects, no interface between TRPs may be necessary or present.

[0076] In certain aspects, a dynamic configuration of split logic functions may be present within the architecture of the 300 distributed RAN. The PDCP, RLC, and MAC protocols can be adaptively positioned in the ANC or TRP.

[0077] FIG. 4 illustrates an example of the physical architecture of a distributed RAN 400, according to aspects of this disclosure. A centralized core network unit (C-CU) 402 can host core network functions. The C-CU can be implemented centrally. The functionality of the C-CU Petition 870250096357, dated 10 / 22 / 2025, p. 32 / 101 24 / 58 capacity can be offloaded (e.g., to Advanced Wireless Services (AWS)) to handle peak capacity. A centralized RAN unit (C-RU) 404 can host one or more ANC functions. Optionally, the C-RU can host core network functions locally. The C-RU can have a distributed implementation. The C-RU can be located closer to the network edge. A distributed unit (DU) 406 can host one or more TRPs. The DU can be located at the network edges with radio frequency (RF) functionality.

[0078] In some circumstances, two or more subordinate entities (e.g., UEs) may communicate with each other using side-link signals. Real-world applications of such side-link communications may include public safety, proximity services, UE-to-network and / or UE-to-UE relay, vehicle-to-vehicle (V2V) communications, Internet of Everything (IoE) communications, Internet of Things (IoT) communications, mission-critical meshes, and / or various other appropriate applications. Generally, a side-link 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 base station), even though the scheduling entity may be used for scheduling and / or control purposes.In some examples, side link signals can be communicated using licensed spectrum (unlike wireless local area networks, which typically use unlicensed spectrum).

[0079] In a wireless communications environment, user devices are routinely called upon to perform computational tasks. A typical example occurs in a virtual reality (VR) or augmented reality (AR) application. Petition 870250096357, dated 10 / 22 / 2025, page 33 / 101 25 / 58 or mixed reality (MR), collectively referred to as XR applications, in which the user's device processes a stream of information and renders it to present an environment to the user. However, the computational demands of such an application can be considerable, and a mobile device, which may have battery limitations and / or processing capacity restrictions due to its physical form factor, may struggle to process all the data in a timely manner to meet the service's performance requirements. On the other hand, other nodes in the system (e.g., in the vicinity of the device with lower capacity) may possess high processing capabilities; for example, a network node will typically not need to rely on battery power and may host extensive computing resources. Similarly, a device with limited capacity, such as a VR headset, may be paired with a more capable device, such as a smartphone.In these cases, the lower-capacity device may benefit by offloading some computational tasks to the network node and / or to the more capable device.

[0080] Existing computing offloading systems typically operate “over” a communication system. For example, a communication system might provide Internet Protocol (IP) connectivity between a user device and one or more remote servers that can coordinate and execute computing tasks on behalf of the user device. A widely used example of this mode of operation is Kubernetes, in which a “control plane” orchestrator manages the offloading of tasks from a client to one or more nodes in a cluster that can execute the requested tasks within a container. (Note that the use of the term “control plane” in the context of Kubernetes refers to a different concept than that used in systems...) Petition 870250096357, dated 10 / 22 / 2025, page 34 / 101 26 / 58 cell phones.) Such systems have the limitation that they can only operate on a connectivity layer exposed to the client device; that is, they cannot integrate with the underlying communication system to take advantage of low-latency or localized computing capabilities that operate below a user connectivity layer, such as a protocol data unit (PDU) layer. Thus, there is a motivation for a computing model more deeply integrated into the communication system; such an approach is sometimes called integrated communication and computing.

[0081] In the Mobile Edge Computing or Multiaccess Edge Computing (MEC) architecture defined as part of the 5G system, a user device, such as a user appliance (UE), can offload computational tasks to a server on the network associated with a Local User Plane Function (L-UPF). User plane traffic to the computing server is routed through the local UPF. This architecture allows for moderately low-latency offloading to a server at the so-called “network edge,” without the latency costs of communication with the operator's core network, provided the L-UPF is implemented as close as possible to the UE; however, the reuse of the legacy user plane routing mechanism imposes a limit on the latency reduction benefits.For example, if the base station is disaggregated into a centralized unit (CU) and a distributed unit (DU), the server may be roughly colocated and deployed up to the CU, but not up to the DU. There are also additional latency impacts associated with traversing the interface to the UPF (particularly in scenarios with more than one UPF in the data path, for example, a separate "uplink classifier" UPF). Furthermore, once the L-UPF is deployed within... Petition 870250096357, dated 10 / 22 / 2025, p. 35 / 101 27 / 58 of the Core Network (CN), any associated MEC computing server cannot be instantiated on a mobile device, which implies that the existing MEC architecture does not allow peer-to-peer offloading between mobile devices. Therefore, a more flexible architecture that addresses these limitations is being sought.

[0082] Certain aspects of this disclosure relate to the operation of a composition management function (CMF), the controller and / or orchestrator node in an offload computing architecture integrated into the operation of a wireless system.

[0083] FIG. 5 is a diagram illustrating a 700 MEC architecture according to a 5G system design. Specifically, FIG. 5 shows a partial representation of the existing 5G MEC architecture. As shown in FIG. 5a, the 5G Core Network (5GC), with nodes interconnected via Service-Based Interfaces (SBIs), is shown in block A of the figure and comprises the following nodes: a Network Repository Function (NRF), which acts as a registry manager and manager of services offered by other network functions; an Access and Mobility Management Function (AMF), which coordinates the operations of a UE on the access network (AN); a Policy Control Function (PCF), which controls the allocation of user data traffic to logical carriers according to system policies;a Session Management Function (SMF), which manages user service sessions; an Application Function (AF), which controls the application and assists in determining traffic policies; and a Network Exposure Function (NEF), which manages the exposure of services. Petition 870250096357, dated 10 / 22 / 2025, page 36 / 101 28 / 58 to third-party application functions (AFs) via APIs within the system; a unified data management (UDM) system, which acts as a repository for signature data; and an Edge Application Server Discovery Function (EASDF), responsible for discovering servers running applications capable of operating with computing at the network edge. (Additional nodes, not shown in the figure, may also be included in the 5GC.)The nodes shown as being outside the 5GC include a UE; an AN, which provides radio access to the UE; a first UPF operating as an uplink classifier (UL CL) and branch point (BP); a second UPF operating as a central protocol data unit session anchor (C-PSA); a third UPF, marked as block B in the figure, operating as a local protocol data unit session anchor (L-PSA); and a data network (DN), which is external to the operator's system and is shown in the figure decomposed into a central part and a local part, with the local part marked as block C in the figure and containing an edge application server (EAS). The EAS hosts the computational activity that occurs at the network edge, in cooperation with the AF, based on traffic directed from the UE to the UPF L-PSA.Note that UPFs can be considered nodes of the 5GC, but due to their specific role in traffic distribution in the MEC architecture, as well as to emphasize the local nature of the termination point, they are shown outside block A in the figure.

[0084] FIG. 6 is a diagram illustrating an example of computing offload to multiple locations in a wireless system. As shown in FIG. 6, the exemplified wireless system 600 can, for example, be considered Petition 870250096357, dated 10 / 22 / 2025, page 37 / 101 Figure 29 / 58 represents a 6G system. An application runs on an XR device (the headset on the left of the figure), connected by a short-range link to a smartphone that receives service from the wireless system. The smartphone is connected, through a relay node, to a base station that is disaggregated into at least one DU (one shown in the figure) and one CU, and the base station is connected to a CN. The application running on the headset can offload computational work to various nodes located throughout the system. For example, the figure shows a first hyperlocal server hosted on the smartphone, a second hyperlocal server hosted on (or near) the DU, a local server (which could, for example, be a local MEC server) closely co-located with the CU, and additional computational capacity hosted on the CN (not shown as participating in the computing offload activity in the figure).It is observed that the local server can be implemented in association with a local UPF, that is, closely associated with the CU, but, in terms of modeling the roles of the nodes in the system, it is still located on a node of the CN. Each server (local or hyperlocal) can offer a computational service, and the application can take advantage of these services to offload part of its computational work. For example, latency-sensitive tasks can be offloaded to the smartphone or to the hyperlocal service on the DU, while demanding but less latency-sensitive tasks can be offloaded to the local server.

[0085] FIG. 7 is a diagram illustrating an example architecture for computing offloading integrated with communication in a wireless system. As shown in FIG. 7, in the example wireless system 700, a UE 710 is connected to the system via an air interface with a DU 720. The DU 720 is closely co-located with a computing server that can accept work offloading. Petition 870250096357, dated 10 / 22 / 2025, page 38 / 101 30 / 58 computational, and DU 720 hosts a Compute Server Function (CSF) 725, which acts as a standardized proxy for Compute Server 722 with respect to the other nodes in the wireless system. DU 720 is connected, via an interface, to CU 730; DU 720 and CU 730 (potentially along with other DUs, not shown in the figure) constitute a base station. CU 730 is connected to CN 750, which provides connectivity to a data network (not shown). The arrangement of the elements, including UE 710, DU 720, CU 730, and CN 740, may conform to an existing 5G system. Along with the already mentioned CSF 725, the figure adds a Composition Management Function (CMF) 740, which is a network node connected to CU 730 (in this example) and CN 750.The CMF 740 can be viewed as a controller and / or orchestrator node for computing offloading in the wireless system, responsible for coordinating and allocating servers to provide computing resources for offloading computational tasks from a client. In some embodiments, the CMF 740 can be considered an AN node. In other embodiments, the CMF 740 can be considered a CN node. In some embodiments, the client may be on a device, such as a UE 710. In other embodiments, the client may be on a fixed node, such as a network node.

[0086] In certain embodiments, other connectivity topologies can be conceived for an environment such as that shown in FIG. 7. For example, CMF 740 can obtain connectivity with CN 750 through CU 730. Alternatively, CMF 740 can have a direct link with DU 720, and so on. In this context, UE 710 can communicate with CMF 740 using a protocol that traverses DU 720 and CU 730. CMF 740 can communicate with CSF 725 (as a proxy for compute server 722) using a Petition 870250096357, dated 10 / 22 / 2025, page 39 / 101 31 / 58 protocol that traverses CU 730 and DU 720. UE 710 can communicate with CSF 725 (as a proxy for compute server 722) using a protocol that traverses DU 720. The protocol stacks responsible for transporting these control protocols may vary depending on additional aspects of the architecture, but are assumed to provide the necessary connectivity between endpoints: between UE 710 and CMF 740 for a first protocol, hereinafter referred to as the Computing Control Protocol (CCP); between CMF 740 and (one or more instances of) CSF 725 for a second protocol, hereinafter referred to as the Computing Management Protocol (CMP); and between UE 710 and (one or more instances of) CSF 725 for a third protocol, hereinafter referred to as the Computing Offload Protocol (COP).In some embodiments, COP can be implemented through the transport of computing data in the User Plane (UP) or through communications from a new “computing plane,” rather than a control plane protocol. In certain aspects of the discussion that follows, the distinction between CSF 725 and the computing server 722 can be omitted. From a functional point of view, it is convenient to consider UE 710 and CMF 740 as corresponding to the computing server, without explicit consideration of CSF 725, which can only act as a network proxy to expose the functions of the computing server 722 to the standardized wireless system nodes 700.

[0087] FIG. 8 illustrates an example of a protocol set for communication between a client device, a CMF, and a CSF. As shown in FIG. 8, client device 810 (e.g., UE 710) communicates with CMF 820 (e.g., CMF 740) via CCP and with CSF 830 (e.g., CSF 725) via COP. CMF 820 communicates with CSF 830 via Petition 870250096357, dated 10 / 22 / 2025, p. 40 / 101 32 / 58 CMP and the client device 810 via CCP. The CSF 830 communicates with the client device 810 via COP and with the CMF 820 via CMP. Any or all of the CCP, CMP, and COP protocols can be implemented as a protocol defined over a point-to-point reference point and / or as an Application Programming Interface (API) defined over a Service-Based Interface (SBI). If one of the protocols is defined as a protocol over a reference point, the protocol operations can be understood as purpose-specific messages that trigger standardized and / or implementation-dependent behaviors in the nodes that receive them.If one of the protocols is defined as an API over an SBI, the protocol operations can be understood as API service invocations that trigger standardized and / or implementation-dependent handling on the node that receives a service invocation, executes related functional behavior, and optionally responds with a service invocation. In this disclosure document, these operations are referred to as protocol transactions, but it should be understood throughout the text that substantially the same functional behavior can be achieved by modeling the operations as API invocations.

[0088] FIG. 9 illustrates an example of a set of transaction types for a CCP between a client device and a CMF. As shown in FIG. 9, the first flow (A) shows a registration transaction from client device 902 to CMF 904, in which client 902 sends a first message to request registration (labeled Device Registration Request message - 910) and CMF 904 responds with a second message to confirm or deny registration (labeled Response message). Petition 870250096357, dated 10 / 22 / 2025, page 41 / 101 33 / 58 Device Registration Response (920). The Device Registration Request message 910 may contain various information about the client device 902, such as capacity information, a profile of supported applications and / or computing profiles on the client, radio information, and so on. The Device Registration Response message 920 may contain a field, such as a flag indicating whether the registration was accepted, information about one or more available computing servers, and so on.The second flow (B) shows a transaction to update the registration of client device 902 with CMF 904, in which client 902 sends a third message to request an update of its registration information (labeled as Device Registration Update message (930)) and CMF 904 responds with a fourth message to confirm or deny the update (labeled as Device Registration Response message (940)). The Device Registration Update message 930 may contain information similar to that described previously for the first message 910. The Device Registration Update message 930 may be sent due to a change in the conditions of client device 902, such as a change in its capabilities, its supported applications and / or computing profiles, its radio conditions, and so on.The Device Registration Response message 940 may contain a field, such as a flag indicating whether the registration update was accepted, information about one or more available computing servers, and so on. The third stream (C) shows a transaction for a client 902 request for computing resources for one or more computing tasks, in which client 902 sends a fifth message requesting information about one or more resources. Petition 870250096357, dated 10 / 22 / 2025, page 42 / 101 34 / 58 computing (labeled as Compute Resource Request message (950)) and CMF 904 responds with a sixth message providing or denying the requested information (labeled as Compute Resource Response message (960)). The Compute Resource Request message 950 may contain a description of the requested computing resources, such as a profile of the expected computing load of the requested tasks, a quantified level of computational support required (e.g., a metric for predicted computing cycles over time), a latency requirement, an identifier of a requested CSF (or a server associated with the CSF), an identifier of a requested task, and so on.The Compute Resource Response message 960 may contain a field, such as a flag indicating whether the compute resource request was accepted, one or more identifiers of one or more assigned CSFs (or servers associated with the CSFs), an image of the requested task, and so on.

[0089] FIG. 10 illustrates an example of a set of transaction types for a CMP between a CMF and a CSF. As shown in FIG. 10, the first flow (A) shows a request from a CSF 1006 to a CMF 1004 to register a computing server associated with CSF 1006. CSF 1006 sends a first message requesting server registration (labeled Server Registration Request message - 1010). The message of Server Registration Request 1010 may contain information about the server's computing capabilities (such as a maximum value for a load metric, an achievable latency for a task with certain computing demand assumptions, and so on), an indication that the server will accept one or more defined tasks (such as Petition 870250096357, dated 10 / 22 / 2025, page 43 / 101 35 / 58 a list of admissible task identifiers that reference a task image repository), and so on. CMF 1004 sends a second message confirming or denying server registration (labeled Server Registration Response - 1020). Server Registration Response 1020 may contain a field, such as a flag indicating whether server registration was accepted, one or more runtime images of tasks that the server may execute, and so on. The second flow (B) illustrates a request from a CSF 1006 to a CMF 1004 to update a registration of a compute server associated with CSF 1006 (which may be necessary, for example, if the server's current capabilities and / or demand change).CSF 1006 sends a third message requesting an update of the server's registration information (labeled Server Update Request - 1030). Server Update Request 1030 may contain information similar to the first message, such as information about the server's computing capabilities, an indication that the server will accept one or more defined tasks, and so on. CSF 1004 sends a fourth message confirming or denying the server update (labeled Server Update Response - 1040). Server Update Response 1040 may contain a field, such as a flag indicating whether the server update was accepted, one or more runtime images of tasks that the server may perform, and so on.

[0090] FIG. 11 illustrates an example of a transaction type for a COP between a client device and a CSF. As shown in FIG. 11, the flow illustrates a request to offload computing from one or more tasks on a device. Petition 870250096357, dated 10 / 22 / 2025, page 44 / 101 36 / 58 Client 1102 sends a message to a compute server represented by a CSF 1106. Client 1102 sends a first message requesting the offload of one or more tasks to the server (labeled as a Task Offload Request message (1110)). The Task Offload Request message 1110 may contain one or more performance requirements (e.g., a compute profile, a requested level of compute support, a latency requirement, and so on), one or more identifiers of the requested tasks, and / or one or more runtime images of the requested tasks, and so on. CSF 1106 sends a second message (labeled as a Task Offload Response message (1120)), which may indicate whether CSF 1106 accepts the task.In some embodiments, the Task Offload Response message 1120 may be sent after the task has been executed on the compute server associated with CSF 1106, and in that case, the Response message is... Task Offload 1120 may include a result of the task execution. In other embodiments, the Task Offload Response 1120 message may be sent when CSF 1106 determines whether to accept the task, and may be followed by a third message (e.g., a Task Offload Result message, which is not shown in FIG. 11) containing a result of the task execution.

[0091] In the example of wireless system 700 shown in FIG. 7, the CMF 740 and the CSF 725 are incorporated into network nodes. However, it is possible that the wireless system may have an alternative architecture to the example of wireless system 700.

[0092] FIG. 12 illustrates an example of an architecture for offloading computing in a manner integrated with communication in a wireless system, in which each of a CMF and a CSF is instantiated in a device (e.g., UE). As shown in FIG. 12, the 1200 wireless system includes three UEs. Petition 870250096357, dated 10 / 22 / 2025, page 45 / 101 37 / 58 1210, 1220, and 1230 (respectively referred to as UE 1, UE 2, and UE 3), and no network node is shown in the figure. The three UEs 1210, 1220, and 1230 may be outside cellular network coverage and communicating on a peer-to-peer, mesh, or ad-hoc network, or one or more of them may be within coverage and communicating with a network but interacting with a computing architecture embedded in the other UEs. In FIG. 12, UE 1210 (i.e., UE 1) is a client device, CMF 1225 is instantiated on UE 1220 (i.e., UE 2), and CSF 1235 and the computing server 1232 are embedded in UE 1230 (i.e., UE 3), but it should be understood that these roles can be combined. For example, in some embodiments, the CMF and the client may be co-located on a single device, meaning that the client device has the responsibility of coordinating computing resources across other UEs.In some embodiments, the CMF and the computing server / CSF may be colocated in a single device, meaning that the CMF coordinates computing resources from one or more devices, including itself. In principle, the client and computing server / CSF could be considered colocated in a single device in some embodiments, but the client device would not typically rely on an external CMF to control its own computing resources. This situation can instead be modeled as the client device making autonomous decisions about its own computing, but there is no fundamental violation of principle in colocating the client and the CSF / server. The air interfaces between the devices may be short-range radio interfaces using one or a combination of radio technologies, such as a side-link technology, Wi-Fi, Bluetooth, and so on.In some embodiments, one or more of the air interfaces in the figure may be replaced by wired connections. Petition 870250096357, dated 10 / 22 / 2025, page 46 / 101 38 / 58

[0093] FIG. 13 illustrates an example of an architecture for offloading computing in a manner integrated with communication in a wireless system, in which a CMF is associated with a DU of a base station. In the example of the 1300 wireless system shown in FIG. 13. The architecture of the UE 1310, DU 1320, compute server 1322, CSF 1325, CU 1330, and CN 1350 is similar to that of the UE 710, DU 720, compute server 722, CSF 725, CU 730, and CN 750 in the 700 wireless system, the only difference being that the CMF 1340 is associated (i.e., tightly co-located) with the DU 1320 instead of the CU 1330. This alternative can enable low-latency communication between the client device and the CMF 1340, which may be desirable if the CMF 1340 is on the critical path for offloading a task.As an example, if the client device (i.e., UE 1310) encounters a task that it has not previously authorized with CMF 1340 (and for which it may need to retrieve a runtime image, for example), any delay in the device's communication with CMF 1340 may result in a corresponding delay in the task's execution. FIG. 13 shows CMF 1340 with alternative or complementary interfaces (represented by dashed lines) connecting it to CU 1330 and CN 1350, and, depending on the overall network architecture, either or both of these interfaces may be used. For example, if CMF 1340 is responsible for orchestrating computing resources on CU 1330, as well as on one or more DUs 1320 and / or one or more devices 1310, a direct connection between CMF 1340 and CU 1330 facilitates this operation. As another example, if CMF 1340 needs to interact with nodes on CN 1350, a direct connection between CMF 1340 and CN 1350 might be useful.In some environments, such as a scenario where all interfaces on the network are SBIs, the direct connections shown in the figure can be replaced by a "service bus" concept. Petition 870250096357, dated 10 / 22 / 2025, p. 47 / 101 39 / 58 which allows any node to communicate with any other node, according to the requirements of the services exposed.

[0094] FIG. 14 illustrates an example of an architecture for computing offload integrated with communication in a wireless system, in which a CMF is instantiated on the network and a CSF (along with its corresponding computing server) is instantiated on a device. As described earlier, it may also be desirable to offload tasks from a first device (e.g., a first UE) to a second device (e.g., a second UE). Thus, it is desirable to instantiate a CSF on a device rather than a network node. In the example 1400 wireless system shown in FIG. 14, the architecture of UE 1410, DU 1420, CU 1430, CMF 1440 and CN 1450 is similar to that of UE 710, DU 720, CU 730, CMF 740 and CN 750 in the 700 wireless system, and the only difference lies in the fact that a second UE 1415 (labeled as UE 2) is provided, and the compute server 1417 and CSF 1419 are instantiated on UE 1415.The roles of the client device (i.e., UE 1410, labeled UE 1), CMF 1440, and CSF 1419 are similar to those described above, but the protocol routing differs. Specifically, CMF 1440 is instantiated on the network, associated with a CU 1430 of a base station, and the client device (i.e., UE 1410) is in communication with the network via an air interface with a DU 1420 of the base station. Furthermore, a second UE 1415 (labeled UE 2) is also in communication with the DU 1420 of the base station via a first air interface and with the client device (i.e., UE 1410) via a second air interface. For example, the first air interface could be a Uu interface connecting UEs to a cellular network, and the second air interface could be a short-distance interface connecting peer devices to each other, such as a side link interface or PC5, or other technology. Petition 870250096357, dated 10 / 22 / 2025, page 48 / 101 40 / 58 radio, such as Bluetooth or Wi-Fi. In some embodiments, UE 1 and UE 2 may be connected by a wired interface instead of wirelessly. In some embodiments, UE 1 and UE 2 may be connected by an ideal interface. CMF 1440 may communicate via CMP (or a similar computing management protocol) with CSF 1419 located in UE 2, and the client device (i.e., UE 1) may communicate via COP (or a similar computing offload protocol) with CSF 1419 located in UE 2. In some embodiments, UE 1 and / or UE 2 may be indirectly connected to the network using a relaying or mesh architecture, in which their communication link to the network is mediated by one or more intermediate nodes, rather than being directly connected to the network, as shown in the figure.In certain embodiments, it should be understood that an architecture with a first compute server (e.g., compute server 1417) and a first CSF (e.g., CSF 1419) located on a device, such as UE 1415 (i.e., UE 2), can coexist with an architecture with a second compute server (e.g., compute server 722) and a second CSF (e.g., CSF 725) located on a network node, such as DU 720 shown in FIG. 7. That is, the client device (i.e., UE 1) may be able to offload one or more tasks to the first compute server and to the second compute server, under the management of CSF 1440.

[0095] FIG. 15 illustrates an example of a protocol stack set for transporting CCP over an RRC protocol, for a case where the CMF is associated (e.g., tightly co-located) with the UC. In the example protocol stack set 1500, the client device instantiates a physical layer (PHY), a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol layer. Petition 870250096357, dated 10 / 22 / 2025, p. 49 / 101 41 / 58 (PDCP), an RRC layer, and a CCP layer. The PHY, MAC, and RLC layers can terminate at the DU. The DU and CU are connected by network interfaces and protocols that are outside the scope of this discussion, represented in the figure as "network layers" (NW layers). The client's PDCP and RRC layers can terminate at the CU. The CU and CMF are connected in a way that can be proprietary or specified, based on network interfaces outside the scope of this discussion, again represented in the figure as "network layers". The client's CCP layer can terminate at the CMF. This stacking can be achieved, for example, by encapsulating one or more CCP messages as PDUs in an RRC message, so that when the CU interprets the RRC message, it forwards the CCP PDU to the CMF for processing.It should be understood that the layers in the figure are exemplary, and specific protocol layers can be modified, reordered, deleted, combined, and / or replaced by other layers with similar or different functions. As an example, the so-called sublayers of layer 2, comprising MAC, RLC, and PDCP, can be replaced by any combination of sublayers that can deliver an RRC PDU between the client and the CU. In certain embodiments, the example protocol stack set 1500 can be implemented in the example wireless system 1200 shown in FIG. 12.

[0096] FIG. 16 illustrates an example of a protocol stack set for CCP transport over a PDCP layer, for a case where the CMF is associated (e.g., tightly co-located) with the DU. In the 1600 protocol stack set example, the client device instantiates a physical layer (PHY), a medium access control layer (MAC), a radio link control layer (RLC), a packet data convergence protocol layer (PDCP), and a CCP layer. The PHY, MAC, RLC, and PDCP layers can terminate at the DU. DU and CMF are connected in a way that Petition 870250096357, dated 10 / 22 / 2025, p. 50 / 101 42 / 58 can be proprietary or specified, based on network interfaces outside the scope of this discussion, represented in the figure as “network layers” (NW layers). The client CCP layer can terminate at the CMF. This stacking can be achieved, for example, by encapsulating one or more CCP messages as PDUs communicated over the PDCP layer. It should be noted that the protocol stacks in FIG. 16 include PDCP termination at the DU, which diverges from current practice in 5G systems; this is because security (which is a PDCP function in 5G) needs to be terminated at the node where the CMF resides. Thus, compared to 5G standards, one or more protocol layer termination points can be relocated from the CU to the DU.In some embodiments, protocol layers may terminate in different locations for different logical carriers or services; for example, PDCP may be terminated on the DU for a radio logical carrier carrying CCP signaling, but on the CU for other radio logical carriers. In certain embodiments, the 1600 protocol stack example may be implemented in the 1300 wireless system example shown in FIG. 13.

[0097] FIG. 17 illustrates an example of a protocol stack set for transporting CCP over a PDCP layer, for a case where the CMF is associated with a base station CU. In the example protocol stack set 1700, the CMF is associated (i.e., tightly co-located) with the CU, but instead of being transported as a PDU encapsulated within an RRC message, a CCP PDU is transported directly over the PDCP protocol; that is, a PDCP Service Data Unit (SDU) can comprise a CCP PDU. The termination points of all included protocols are the same as in FIG. 8 (the RRC layer is not shown as it does not play a role in CCP processing in this model). The PDCP layer on the CU can Petition 870250096357, dated 10 / 22 / 2025, p. 51 / 101 43 / 58 Differentiate between RRC PDUs, which need to be delivered to an RRC layer and processed in the CU, and CCP PDUs, which need to be forwarded to the CMF and processed there. This differentiation may depend on a radio carrier identity or a protocol discriminator in a PDCP PDU, for example. The PDCP layer on the client may also differentiate between RRC PDUs and CCP PDUs, each of which needs to be delivered to the respective protocol layer for processing. This differentiation may depend on a radio carrier identity or a protocol discriminator in a PDCP PDU, for example.In some embodiments, one or more radio logical carriers may be reserved to carry CCP between the client device and the CMF; these radio logical carriers may be considered as data logical carriers of a wireless system user plane, signaling logical carriers of a wireless system control plane, or computation logical carriers of a wireless system computation plane. In certain embodiments, the 1700 protocol stack example may be implemented in the 700 wireless system example shown in FIG. 7 or in the 1400 wireless system example shown in FIG. 14.

[0098] FIG. 18 and FIG. 19 illustrate two examples of protocol stack sets for transporting CCP between two peer devices, where one device acts as a client and the other hosts a CMF. In the 1800 and 1900 protocol stack set examples, UE 1 acts as a client (e.g., hosting a client application) and UE 2 hosts a CMF. In the 1800 protocol stack set example, the CCP is transported directly over PDCP, and in the 1900 protocol stack set example, the CCP is encapsulated in a PC5 Radio Resource Control (PC5-RRC) protocol. The encapsulation Petition 870250096357, dated 10 / 22 / 2025, p. 52 / 101 44 / 58 of CCP in PC5-RRC messages is similar to the encapsulation of CCP in RRC messages described earlier. In certain embodiments, the examples of 1800 and 1900 protocol stack sets can be implemented in the 1200 wireless system example shown in FIG. 12.

[0099] FIG. 20 illustrates an example of a protocol stack set for transporting COP between a client (located, for example, in a UE) and a CSF, where the CSF is associated with a DU of a base station. In the example of protocol stack set 2000, the COP is transported directly over a PDCP layer terminated between the client and the DU. The interface between the DU and the CSF can be proprietary or specified; it can be considered as an internal interface of the DU. In some embodiments, one or more logical radio carriers may be reserved to transport COP between the client device and the CSF; these logical radio carriers can be considered as logical data carriers of a wireless system user plane, logical signaling carriers of a wireless system control plane, or logical computation carriers of a wireless system computation plane.In certain embodiments, the example protocol stack set 2000 can be implemented in the example wireless system 700 shown in FIG. 7, in the example wireless system 1300 shown in FIG. 13, or in the example wireless system 1400 shown in FIG. 14.

[0100] FIG. 21 and FIG. 22 illustrate two examples of protocol stack sets for transporting COP between two peer UEs, in which one device acts as a client and the other hosts a CSF. In the 2100 and 2200 protocol stack set examples, UE 1 acts as a client (e.g., hosting a client application) and UE 2 hosts a CSF. In the 2100 protocol stack set example, the COP is transported directly over the PDCP, i.e., an SDU. Petition 870250096357, dated 10 / 22 / 2025, p. 53 / 101 45 / 58 PDCP can comprise a COP PDU. In the 2200 protocol stack example, the COP is carried over a PC5-RRC protocol, for example, being encapsulated in one or more PC5-RRC messages. In certain embodiments, the 2100 and 2200 protocol stack examples can be implemented in the 1200 wireless system example shown in FIG. 12.

[0101] There are several protocol stack options for CMP transport between a CMF and a CSF, as transport depends on network implementation and configuration. If the CMF is located in a CU and the CSF in a DU, the CMP protocol can be transported over a network protocol, such as the F1 Application Protocol (F1AP). If the CMF is located in a DU and the CSF in the same DU, the interface that carries CMP between them can be proprietary or specified, and can be considered an internal interface between DU functions. If the CMF is located in a DU and the CSF in a different DU, CMP can be transported over a DU-DU interface, using, for example, an application protocol or an API applicable to that interface. If the CMF is on the network and the CSF in a UE, CMP can be transported over an air interface, with several protocol options similar to those in the FIGS.8, 9, and 10; that is, the CMP can be transported over RRC or over PDCP, between the UE and a DU or between the UE and a CU. If the CMF and CSF are both located in UEs, the CMP can be transported over a short-distance interface between the two UEs, with options similar to those in FIG. 14, allowing the CMP to be transported over PDCP or over PC5-RRC. In cases where the CMP is transported over an air interface, it can be associated with specific radio logical carriers, which can be modeled as logical data carriers of a wireless system user plane. Petition 870250096357, dated 10 / 22 / 2025, page 54 / 101 46 / 58 signaling logic of a wireless system control plane or computing logic carriers of a wireless system computing plane.

[0102] In some embodiments (not illustrated), a CSF may be instantiated in a CU of a base station, and the COP may be terminated between a client device and a CSF in a CU. In this case, the COP may be transported over an RRC protocol (e.g., by encapsulating a COP PDU in an RRC message) and / or over a PDCP layer. If the COP is transported over PDCP, COP PDUs may be distinguished from other higher-layer PDUs by a logical carrier identity, a protocol discriminator, and so forth. In some embodiments, one or more logical radio carriers may be reserved to transport COP between the client device and the CSF; these logical radio carriers may be considered as logical data carriers of a wireless system user plane, logical signaling carriers of a wireless system control plane, or logical computation carriers of a wireless system computation plane.

[0103] FIG. 23 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, where the CMF is associated with a base station CU and the CSF is associated with a base station DU. In the example protocol stack set 2300, the CMP protocol can be transported over the F1AP. It should be noted that the node roles can be reversed, applying to the case of a CMF on a DU and a CSF on a CU. Furthermore, a future specification may include a protocol other than F1AP on the F1 interface between a CU and a DU, and CMP can be transported over that protocol on a CU-DU interface.

[0104] FIG. 24 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, Petition 870250096357, dated 10 / 22 / 2025, p. 55 / 101 47 / 58 where CMF is associated with a DU of a base station and CSF is associated with another DU of a base station. In the 2400 protocol stack example, the CMP protocol can be transported over a DU-DU interface protocol, using, for example, an application protocol or an API applicable to that interface. It should be noted that there is no 5G interface between DUs, and the interface protocol is a protocol specified over a hypothetical DU-DU interface in 6G.

[0105] FIG. 25 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, where the CMF is associated with one base station CU and the CSF is associated with another base station CU. In the example protocol stack set 2500, the CMP protocol can be transported over XnAP, which is the application protocol for the 5G Xn interface between CUs. It should be noted that a future specification may include a protocol other than XnAP on the Xn interface between CUs, and CMP may be transported over that protocol between CUs.

[0106] FIG. 26 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, where the CMF is instantiated on a base station and the CSF is hosted on a UE. In the example protocol stack set 2600, the CMP protocol can be transported over air interface layers, such as the PDCP layer or the optional RRC layer. Specifically, the RRC is optional in this example. The L2 sublayers shown (PDCP / RLC / MAC) are aligned with 5G, and the L2 stack implementation may differ. Note that the node roles can be reversed, applying to the case of a CMF on a UE and a CSF on a base station.

[0107] FIG. 27 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, Petition 870250096357, dated 10 / 22 / 2025, p. 56 / 101 48 / 58 where the CMF is associated with a base station CU and the CSF is hosted in a UE. In the 2700 protocol stack example, the CMP protocol can be transported over air interface layers, such as the PDCP layer or the optional RRC layer. CMP is transported directly over a PDCP layer terminated between the CSF and the DU. The interface between the DU and CMF can be proprietary or specified. Specifically, the RRC is optional in this example. The L2 sublayers shown (PDCP / RLC / MAC) are aligned with 5G, and the L2 stack implementation may differ. Note that the node roles can be reversed, applying to the case of a CMF in a UE and a CSF in a CU.

[0108] FIG. 28 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, where both the CMF and the CSF are hosted on two UEs. In the 2800 protocol stack set example, the CMP protocol can be transported over the PDCP layer or over the optional PC5-RRC layer. Specifically, PC5-RRC, which represents the radio resource control protocol of a direct UE-UE interface (called the PC5 interface in 5G), is optional in this example. The L2 sublayers shown (PDCP / RLC / MAC) are aligned with 5G, and the L2 stack implementation may differ.

[0109] FIG. 29 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, where the CMF is instantiated on a CN and the CSF is hosted on a UE. In the example protocol stack set 2900, there is a single anchor element on the CN (similar to AMF in 5G), with which the UE communicates via a point-to-point NAS protocol, and the CN anchor communicates with other nodes on the CN (one of which may host the CMF). In this case, the CMP can be encapsulated in a NAS message between the UE and the CN anchor and transported over SBIs between the CN anchor and the CMF. Petition 870250096357, dated 10 / 22 / 2025, p. 57 / 101 49 / 58 Note that the roles of the nodes can be reversed, applying to the case of a CMF in a UE and a CSF in the CN. In certain embodiments, virtually any node in the CN can physically host the CMF / CSF and communicate with the CSF / CMF according to the 2900 protocol stack set example. In certain embodiments, the base station can be disaggregated into a CU and a DU.

[0110] FIG. 30 illustrates an example of a protocol stack set for CMP transport between a CMF and a CSF, where the CMF is instantiated on a CN and the CSF is hosted on a UE. In the example protocol stack set 3000, there is no single anchor element on the CN, and the base station has access to the service bus, i.e., communication between the base station and the CN nodes occurs via SBIs. Specifically, the use of RRC as transport to the base station is optional. The use of a NAS protocol (which can be one of several protocols in the NAS layer) terminated between the UE and the CN node is also optional. It should be noted that the roles of the nodes can be reversed, applying to the case of a CMF on a UE and a CSF on a CN. In certain embodiments, virtually any node in the CN can physically host the CMF / CSF and communicate with the CSF / CMF according to the exemplary set 3000 of protocol stacks. In certain embodiments, the base station can be disaggregated into a CU and a DU.

[0111] FIG. 31 illustrates an example of message flow for a computing session involving a client 3102, a first CSF 3106, a second CSF 3108, and a CMF 3104. Specifically, the operations 3100 shown in FIG. 31 include four operation phases: a first CMP-based phase to establish relationships between the CMF 3104 and the CSFs 3106 and 3108 (procedures 3110-3140); a second CCP-based phase to register client 3102 (procedures 3150 and 3160); a third CCP-based phase to assign Petition 870250096357, dated 10 / 22 / 2025, pp. 58 / 101 50 / 58 a CSF 3108 and resources for a computation task (procedures 3170 and 3180); and a fourth phase based on the COP for offloading the computation task to the designated CSF (procedures 3190 and 3195).

[0112] In procedure 3110, CSF 3106 (i.e., CSF 1) sends a CMP protocol server registration request to CMF 3104. The server registration request may include, for example, the capabilities of the CSF and / or its associated server. In procedure 3120, CMF 3104 sends a server registration response to CSF ​​3106 (i.e., CSF 1), which may, for example, confirm the successful registration of the server in procedure 3110. As discussed earlier, the server registration response message may include additional information beyond the registration confirmation, such as one or more job images. In procedures 3130 and 3140, procedures similar to those in procedures 3110 and 3120 are repeated between CMF 3104 and CSF 3108 (i.e., CSF 2). This completes the first phase of the procedures, and the CSFs (CSF 1 and CSF 2) are now registered with CMF 3104 and available to offer computing services.

[0113] In procedure 3150, client 3102 sends a device registration request (also called a client registration request, since it is transmitted by the client requesting registration) to CMF 3104 using the CCP protocol. The device registration request may include, for example, the capabilities of the client device, characteristics of an application running on the client device, a request for task images, and so on. In procedure 3160, CMF 3104 sends a device registration response (also called a client registration response) to client 3102 using the CCP protocol, which may, for example, confirm the successful registration of the Petition 870250096357, dated 10 / 22 / 2025, pp. 59 / 101 51 / 58 Client 3102 in procedure 3150. As discussed earlier, the device registration response message may include additional information beyond the registration confirmation, such as one or more job images. This completes the second phase of the procedures, and client 3102 is now registered with CMF 3104 and ready to request computing services for an application running on the client device.

[0114] In procedure 3170, client 3102 sends CMF 3104 a CCP protocol request for computing resources. The computing resource request may include, for example, a computing profile of one or more requested tasks, a request for one or more task images, required performance limits for a computing service, and so on. In procedure 3180, CMF 3104 sends client 3102 a computing resource response, which in this example identifies CSF 3108 (i.e., CSF 2) as the CSF associated with a server suitable for executing the requested computing task(s). As discussed earlier, the computing resource response may include one or more identifiers of one or more selected CSFs, one or more task images, and so on. This completes the third phase of the procedures, and client 3102 is now able to request task offload to CSF ​​2.

[0115] In certain embodiments, the customer registration request in procedure 3150 and the computing resources request in procedure 3170 may be in the same message. In other words, customer 3102 may send a single message containing both the customer registration request and the computing resources request to CMF 3104. In response, the customer registration response in procedure 3160 and the computing resources response in Petition 870250096357, dated 10 / 22 / 2025, pp. 60 / 101 52 / 58 procedure 3180 can be in the same message. In other words, CMF 3104 can send a single message containing both the client registration response and the compute resource response back to client 3102. Alternatively, CMF 3104 can send the client registration and compute resource responses in separate messages to client 3102, in response to a single message containing both requests.

[0116] In procedure 3190, client 3102 sends a COP protocol task offload request to CSF ​​3108 (i.e., CSF 2). The task offload request may include one or more runtime images, input data for one or more requested tasks, expected performance profiles for one or more requested tasks, and so on. In procedure 3195, CSF 3108 (i.e., CSF 2) sends a task offload response to client 3102. As discussed earlier, the task offload response may include an indication of whether one or more requested tasks were accepted, expected performance information, and so on. In some embodiments, the task offload response may be sent after the task execution and comprise a result of the task execution (e.g., output data, such as a representation of a rendered scene).In other embodiments, the task offload response can be sent as soon as acceptance of the requested task is determined, and in that case, in an optional procedure 3398, CSF 3108 (i.e., CSF 2) can send to client 3102 a task offload result of the COP protocol. As discussed earlier, the task offload result can include the result of the task execution (e.g., output data).

[0117] FIG. 32 is a flowchart of a method (process) Petition 870250096357, dated 10 / 22 / 2025, pp. 61 / 101 53 / 58 for wireless communication of a device. The method can be executed by a device in a wireless system. In operation 3210, the device instantiates a CMF. In operation 3220, the device receives, via CMF, from a client node in the wireless system, a client registration request. In operation 3230, the device transmits, via CMF, to the client node, a client registration response. In operation 3240, the device receives, via CMF, from the client node, a computing resource request. In operation 3250, the device transmits, via CMF, to the client node, a computing resource response.

[0118] In certain embodiments, the device is a CU or a DU of a wireless system base station, and the CMF is instantiated on the CU or DU.

[0119] In certain embodiments, the client node is a first mobile device, the device is a second mobile device, and the CMF is instantiated on the second mobile device. In one embodiment, communication between the first mobile device and the second mobile device occurs via at least one short-range radio interface or a wired connection.

[0120] In certain embodiments, the device is a node of an AN or a CN of the wireless system, and the CMF is instantiated at that node.

[0121] In certain embodiments, the client node is a mobile device or a network node.

[0122] In certain embodiments, the client registration response comprises policy information to control the distribution of computational tasks from the client node.

[0123] In certain embodiments, the customer registration request and the computing resource request are in the same message.

[0124] In certain realizations, the registration response of Petition 870250096357, dated 10 / 22 / 2025, pp. 62 / 101 54 / 58 client and the computing resource response are in the same message.

[0125] In certain embodiments, each of the client registration request, client registration response, compute resource request, and compute resource response is a PDU of a computing control protocol or a transaction of a computing control SBI.

[0126] FIG. 33 is a flowchart of a method (process) for wireless communication of a device. The method can be executed by a device in a wireless system. In operation 3310, the device instantiates a CMF. In operation 3320, the device receives, via the CMF, from a CSF of the wireless system, a server registration request. In operation 3330, the device transmits, via the CMF, to the CSF, a server registration response. Optionally, in operation 3340, the device receives, via the CMF, from a client node, a computing resource request. Optionally, in operation 3350, the device transmits, via the CMF, to the client node, a computing resource response related to the CSF.

[0127] In certain embodiments, the device is a CU or a DU of a wireless system base station, and the CMF is instantiated on the CU or DU.

[0128] In certain embodiments, the device is a mobile device, and the CMF is instantiated on the mobile device.

[0129] In certain embodiments, the CSF is instantiated on a CU or on a DU of a wireless system base station.

[0130] In certain embodiments, the CSF is instantiated on a mobile device.

[0131] In certain embodiments, both the server registration request and the server registration response are protocol data units Petition 870250096357, dated 10 / 22 / 2025, pp. 63 / 101 55 / 58 PDUs) of a computing management protocol.

[0132] In certain embodiments, the computing resource response includes information about the CSF.

[0133] In certain embodiments, the CSF information comprises at least one CSF identifier.

[0134] In certain embodiments, the request for computing resources comprises information about at least one computational task.

[0135] In certain embodiments, the information comprises a computation profile of at least one computational task.

[0136] In certain embodiments, the computing profile comprises a measure of the processing load predicted for at least one computational task.

[0137] In certain embodiments, the computing profile comprises a latency requirement for at least one computational task.

[0138] In certain embodiments, the device transmits, via CMF, to a client node, an indication of the availability of computing resources on a server associated with the CSF.

[0139] In certain embodiments, the indication is contained in a computing resource response of a computing control protocol.

[0140] FIG. 34 is a flowchart of a method (process) for wireless communication from a client node. The method can be executed by a client node of a wireless system. In operation 3410, the client node transmits a client registration request to a Composition Management Function (CMF) in the wireless system. In operation 3420, the client node receives a client registration response from the CMF. In operation 3430, the client node transmits a resource request to the CMF. Petition 870250096357, dated 10 / 22 / 2025, pp. 64 / 101 56 / 58 computing. In operation 3440, the client node receives a computing resource response from the CMF. Optionally, in operation 3450, the client node transmits a task offload request to a Compute Server Function (CSF) in the wireless system. Optionally, in operation 3660,

[0141] In certain embodiments, the customer registration request and the computing resource request are in the same message.

[0142] In certain embodiments, the customer registration response and the computing resource response are in the same message.

[0143] In certain embodiments, communication with the CSF is established based, at least in part, on the content of the computing resource response.

[0144] In certain embodiments, the CSF is instantiated on a CU or on a DU of a base station.

[0145] In certain embodiments, the client node is a first mobile device, and the CSF is instantiated on a second mobile device.

[0146] In certain embodiments, communication between the first mobile device and the second mobile device occurs via at least one short-range radio interface or a wired connection.

[0147] In certain embodiments, each of the client registration request, client registration response, compute resource request, and compute resource response is a PDU of a compute offload protocol or a transaction of a compute offload SBI.

[0148] In certain realizations,

[0149] It is understood that the specific order or hierarchy of the blocks in the published processes / flowcharts constitutes an illustration of exemplary approaches. Based on preferences Petition 870250096357, dated 10 / 22 / 2025, pp. 65 / 101 57 / 58 of the design, it is understood that the specific order or hierarchy of the blocks in the processes / flowcharts may be rearranged. Furthermore, some blocks may be combined or omitted. The method claims presented below describe elements of the various blocks in an example order and are not intended to be limited to the specific order or hierarchy presented.

[0150] The preceding description is provided to enable anyone skilled in the art to implement the various aspects described herein. Various modifications of 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 presented herein and should be interpreted in their full scope consistent with the wording of the claims, and reference to an element in the singular is not intended to mean “one and only one,” unless expressly stated otherwise, but rather “one or more.” The word “example” is used in this document in the sense of “to serve as an example, instance, or illustration.” Any aspect described as “exemplary” should not necessarily be interpreted as preferred or advantageous in relation to other aspects. Unless expressly 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 multiple occurrences of A, multiple occurrences of B, or multiple occurrences 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 correspond only to A, only to B, only to C, to A and B, to A and C, to B and C, or to A, B, and C, wherein. Petition 870250096357, dated 10 / 22 / 2025, pp. 66 / 101 58 / 58 Any of these combinations may contain one or more instances of A, B, or C. All structural and functional equivalents of the elements of the various aspects described throughout this disclosure, which are known or may become known to persons skilled in the art, are expressly incorporated by reference and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be dedicated to the public domain, whether or not such disclosure is explicitly stated in the claims. The words “module,” “mechanism,” “element,” “device,” and the like should not be considered substitutes for the term “means.” Thus, no element of a claim should be interpreted as “means plus function” unless the element is expressly worded with the expression “means for.” Petition 870250096357, dated 10 / 22 / 2025, pp. 67 / 101

Claims

1 / 4 CLAIMS 1. A wireless communication method of a device in a wireless system, characterized in that it comprises: instantiating a composition management function (CMF); receiving, via the CMF from a client node in the wireless system, a client registration request; transmitting, via the CMF to the client node, a client registration response; receiving, via the CMF from the client node, a computing resource request; and transmitting, via the CMF to the client node, a computing resource response.

2. Method, according to claim 1, characterized in that the device is a centralized unit (CU) or a distributed unit (DU) of a wireless system base station, and the CMF is instantiated in the CU or DU.

3. A method according to claim 1, characterized in that the client node is a first mobile device, the device is a second mobile device, and the CMF is instantiated on the second mobile device; wherein communication between the first mobile device and the second mobile device occurs over at least one of a short-range radio interface and a wired connection.

4. A method according to claim 1, characterized in that the client registration response comprises policy information for controlling the distribution of computational tasks from the client node.

5. A method according to claim 1, characterized in that the customer registration request and the computing resource request are in the same message.

6. Method, according to claim 1, characterized in that the customer registration response and the Petition 870250090551, dated 03 / 10 / 2025, page 21 / 33 2 / 4 computing resource response are in the same message.

7. A method according to claim 1, characterized in that each of the client registration request, client registration response, computing resource request, and computing resource response is a protocol data unit (PDU) of a computing control protocol or a transaction of a computing control service-based interface (SBI).

8. A wireless communication method of a device in a wireless system, characterized in that it comprises: instantiating a Composition Management Function (CMF); receiving, via the CMF, from a Computation Server Function (CSF) of the wireless system, a server registration request; and transmitting, via the CMF to the CSF, a server registration response.

9. A method according to claim 8, characterized in that it further comprises: receiving, via the CMF from a client node, a computing resource request; and transmitting, via the CMF to the client node, a computing resource response relating to the CSF.

10. A method according to claim 8, characterized in that the computing resource request comprises information about at least one computational task; wherein the information comprises a computing profile of at least one computational task; wherein the computing profile comprises a measure of anticipated computational load for at least one computational task or a latency requirement for at least one computational task.

11. Method, according to claim 8, characterized in Petition 870250090551, dated 10 / 03 / 2025, page 22 / 33 3 / 4, in that it further comprises: transmitting, via CMF to a client node, an indication of the availability of computing resources on a server associated with CSF; wherein the indication is contained in a computing resource response from a computing control protocol.

12. Wireless communication method of a client node of a wireless system, characterized in that it comprises: transmitting a client registration request to a composition management function (CMF) in the wireless system; receiving a client registration response from the CMF; transmitting a computing resource request to the CMF; and receiving a computing resource response from the CMF.

13. Method according to claim 12, characterized in that the customer registration request and the computing resource request are in the same message.

14. A method according to claim 12, characterized in that the customer registration response and the computing resource response are in the same message.

15. A method according to claim 12, characterized in that it further comprises: transmitting a task offload request to a computing server function (CSF) in the wireless system; and receiving a task offload response from the CSF.

16. Method, according to claim 15, characterized in that communication with the CSF is established based at least in part on the content of the response to Petition 870250090551, dated 03 / 10 / 2025, page 23 / 33 4 / 4 computation.

17. Method, according to claim 15, characterized in that the client node is a first mobile device, and the CSF is instantiated on a second mobile device; wherein the communication between the first mobile device and the second mobile device occurs over at least one of a short-range radio interface and a wired connection.

18. Method according to claim 12, characterized in that each of the client registration request, client registration response, compute resource request, and compute resource response is a protocol data unit (PDU) of a compute offload protocol or a transaction of a compute offload service-based interface (SBI). Petition 870250090551, dated 10 / 03 / 2025, pp. 24 / 33

Images