Methods and arrangements for management of machine learning models

Abstract

Logic may manage shared machine learning (ML) models for a core cellular network. Logic may receive a management request initiated by consumer via the interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF). Logic may process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network. Logic may communicate a result to the NWDAF. And logic may include an application program interface (API) for the ML Model Management service of the ARDF to support a request to store or update the ML models, to retrieve stored ML models from the ADRF, and to delete stored ML models in the ADRF.

Description

[0001] METHODS AND ARRANGEMENTS FOR MANAGEMENT OF MACHINE LEARNING MODELS

[0002] CROSS REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority under 35 USC § 119 from U.S. Provisional Application No. 63 / 517,447, entitled “ADVANCED DATA REPOSITORY FUNCTION (ADRF) SERVICE TO STORE, DELETE AND RETRIEVE MACHINE LEARNING MODELS”, filed on August 3, 2023, and U.S. Provisional Application No. 63 / 583,546, entitled “ADVANCED DATA REPOSITORY FUNCTION (ADRF) SERVICE TO STORE, DELETE AND RETRIEVE MACHINE LEARNING MODELS”, filed on September 18, 2023, the subject matter of which is incorporated herein by reference.

[0004] BACKGROUND

[0005] The cellular industry has been striving to incorporate intelligence into cellular networks. The intelligence may include, e.g., artificial intelligence (Al) and machine learning (ML) based intelligence. The purpose of introducing AI / ML spans not only to increase performance of existing networks, but also to optimize and / or steer various network components to a certain key performance indicator (KPI) of interest in an efficient and elegant way.

[0006] BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1A depicts an embodiment of a communications system;

[0008] FIG. IB illustrates another embodiment of a communications system;

[0009] FIG. 2 illustrates another embodiment of a communications system;

[0010] FIGs. 3A-3H illustrates alternative embodiments for illustrating communications between a consumer and the Analytic Data Repository Function (ADRF) for management services;

[0011] FIGs. 31 illustrates an embodiment for a machine learning model according to embodiments herein;

[0012] FIG. 4 illustrates an embodiment of artificial (Al)-assisted communication between a user equipment (UE) and a radio access node (RAN) according to embodiments herein; FIG. 5 depicts an embodiment of a block diagram of a base station and a user equipment according to embodiments herein;

[0013] FIGs. 6-7 depicts flowcharts of different embodiments according to embodiments herein;

[0014] FIG. 8 depicts an embodiment of protocol entities for wireless communication devices;

[0015] FIG. 9 illustrates embodiments of the formats of PHY data units;

[0016] FIGs. 10A-B depicts embodiments of communication circuitry for devices in a communications system;

[0017] FIG. 11 depicts an embodiment of a storage medium;

[0018] FIG. 12 illustrates an embodiment of an architecture of a communications system;

[0019] FIG. 13 illustrates an embodiment of components of a device in a communications system;

[0020] FIG. 14 illustrates an embodiment of interfaces of baseband circuitry in a communications system; and

[0021] FIG. 15 depicts an embodiment of a block diagram of components to perform functionality described.

[0022] DETAILED DESCRIPTION OF EMBODIMENTS

[0023] The following is a detailed description of embodiments depicted in the drawings. The detailed description covers all modifications, equivalents, and alternatives falling within the appended claims.

[0024] Embodiments herein focus on management of shared machine learning (ML) models for a core cellular network. Embodiments may receive a management request initiated by consumer via the interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytics Data Repository Function (ADRF). Many embodiments may process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network. Some embodiments may pass a result to the NWDAF. For instance, the NWDAF and the ADRF may comprise code executing on the same server so the ADRF may pass or communicate the result to the NWDAF through one or more buffers, one or more registers, one or more memory address locations, or the like. If the NWDAF and the ADRF may comprise code executing on the different servers and possibly in different physical or geographical locations, the ADRF may pass or communicate the result to the NWDAF through one or more servers, networks, communications media, and / or the like. And some embodiments may include an application program interface (API) for the ML Model Management service of the ARDF to support a request to store or update the ML models, to retrieve stored ML models from the ADRF, and to delete stored ML models in the ADRF.

[0025] Note that references to clauses referenced in this disclosure may refer to clauses of 3GPP Technical Specification (TS) 29.275 V18.6.0 (2024-06) unless otherwise specified.

[0026] A network function (NF) is a processing function in a network that has defined functional behavior and interfaces. A network function can be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform. Dedicated hardware may include, e.g., user equipment (UE), base station or radio access network (RAN), a packet data network gateway (PGW), a serving gateway (SGW), mobility management entity (MME), home subscriber server (HSS), user plane function (UPF), unified data repository (UDM), other communications network hardware element, and / or the like. An appropriate platform may include, e.g., a server, a laptop, a workstation, a tablet, other processing device, and / or the like, with hardware to virtualize one or more network functions.

[0027] The following discussion provides various examples of systems, sub-systems, planes, components, operations, and attribute names, however, the systems, sub-systems, planes, components, operations, and attributes can have alternative names to those provided infra. Additionally, or alternatively, the various example systems, sub-systems, planes, components, operations, and attributes can be combined or divided in any suitable manner, which may be based on implementations and / or use cases.

[0028] Various embodiments may be designed to address different technical problems associated management of machine learning (ML) models including how to share ML models amongst various physical resource locations for an operator or between various operators; how to store the ML models in a core cellular network rather than locally; how the use a decomposed Network Data Analytics Function (NWDAF) to store, retrieve, and delete ML models; how to use a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF) to store, retrieve, and delete ML models; how to provide an interface for the ADRF to store or update, retrieve, and delete or remove ML models in the ADRF; how to support OAuth2 protocol for security in communications of shared ML models; how to define resource URIs, resource standard methods and custom operation method for the ADRF; how to enhance the ADRF to support service description, service architecture, and service operations of a new Nadrf ML Model Management service for the ADRF for the management of ML models; how the Nadrf ML Model Management service and individual service operations to store, retrieve, and delete uses Service Based Interfaces (SBI) design principles, and / or the like.

[0029] Different technical problems such as those discussed above may be addressed by one or more different embodiments. Embodiments may address one or more of these problems associated with management of machine learning (ML) models. For instance, some embodiments that address problems associated with ML models may do so by one or more different technical means, such as, sharing of ML models with other consumers or operators; storing of ML models in a core cellular network rather than locally; storing of a ML model in the Analytics Data Repository Function (ADRF) to share with other consumers or operators; retrieving of a ML model from the ADRF to share with other consumers or operators; deletion / removal of a ML model from the ADRF to manage the ML models stored in the ADRF; provision of an application program interface (API) for a ML Model Management service of the ARDF to support storing or updating ML models, retrieving ML models, and deleting ML models; provision of a ML Model Management service of the ARDF using Service based interface (SBI) design principles; definition of the resource Uniform Resource Identifiers (URIs), resource standard methods, and custom operation method; provision of a ML Model Management service of the ARDF including an application data model; provision of a ML Model Management service of the ARDF including security using OAuth2 protocol for access authorization; provision of an API interface for a ML Model Management service of the ARDF developed using the yet another mark-up language (YAML) programming language; and provision of a result to a retrieve request, a store request, and a delete request; and / or the like.

[0030] Several embodiments comprise systems with multiple processor cores such as central servers, access points, and / or stations (STAs) such as modems, routers, switches, servers, workstations, netbooks, mobile devices (Laptop, Smail Phone, Tablet, and the like), sensors, meters, controls, instruments, monitors, home or office appliances, Internet of Things (loT) gear (watches, glasses, headphones, cameras, and the like), and the like. Some embodiments may provide, e.g., indoor and / or outdoor “smart” grid and sensor services. In various embodiments, these devices relate to specific applications such as healthcare, home, commercial office and retail, security, and industrial automation and monitoring applications, as well as vehicle applications (automobiles, self-driving vehicles, airplanes, drones, vchiclc-to-vchiclc (V2V), vchiclc-to- everything (V2X), and the like), and the like.

[0031] The techniques disclosed herein may involve transmission of data over one or more wireless connections using one or more wireless mobile broadband technologies. For example, various embodiments may involve transmissions over one or more wireless connections according to one or more 3rd Generation Partnership Project (3GPP), 3GPP Long Term Evolution (LTE), 3GPP LTE-Advanced (LTE-A), 4G LTE, 5G New Radio (NR) and / or 6G, technologies and / or standards, including their revisions, progeny and variants. Various embodiments may additionally or alternatively involve transmissions according to one or more Global System for Mobile Communications (GSM) / Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS) / High Speed Packet Access (HSPA), and / or GSM with General Packet Radio Service (GPRS) system (GSM / GPRS) technologies and / or standards, including their revisions, progeny and variants.

[0032] Examples of wireless mobile broadband technologies and / or standards may also include, without limitation, any of the Institute of Electrical and Electronics Engineers (IEEE) 802.16 wireless broadband standards such as IEEE 802.16m and / or 802.16p, International Mobile Telecommunications Advanced (IMT-ADV), Worldwide Interoperability for Microwave Access (WiMAX) and / or WiMAX II, Code Division Multiple Access (CDMA) 2000 (e.g., CDMA2000 IxRTT, CDMA2000 EV-DO, CDMA EV-DV, and so forth), High Performance Radio Metropolitan Area Network (HIPERMAN), Wireless Broadband (WiBro), High Speed Downlink Packet Access (HSDPA), High Speed Orthogonal Frequency-Division Multiplexing (OFDM) Packet Access (HSOPA), High-Speed Uplink Packet Access (HSUPA) technologies and / or standards, including their revisions, progeny and variants.

[0033] Some embodiments may additionally perform wireless communications according to other wireless communications technologies and / or standards. Examples of other wireless communications technologies and / or standards that may be used in various embodiments may include, without limitation, other IEEE wireless communication standards such as the IEEE 802.11-2020, IEEE 802.1 lax-2021, IEEE 802.1 lay-2021, IEEE 802.1 lba-2021, and / or other specifications and standards, such as specifications developed by the Wi-Fi Alliance (WFA) Neighbor Awareness Networking (NAN) Task Group, machine-type communications (MTC) standards such as those embodied in 3GPP Technical Specification (TS) 23.288 VI 8.6.0 (2024- 06), 3GPP Technical Report (TR) 23.700-81 V18 (2022-12), 3GPP TS 29.500 V18.6.0 (2024- 06), 3GPP TS 29.501 V18.5.0 (2024-06), and / or TS 29.275 V18.0.0 (2024-03), and / or near-fteld communication (NFC) standards such as standards developed by the NFC Forum, including any revisions, progeny, and / or variants of any of the above. The embodiments are not limited to these examples.

[0034] FIG. 1A illustrates a communication network 190 comprising communications system resources for data collection, data analytics, machine learning (ML) model training, ML inference, data and analytics storage, and ML model storage or update, retrieval, and deletion or removal for one or more subsystems of the communications network 190. A subsystem may be, e.g., a geographical area having a network of one or more base stations or radio access nodes (191 and 192), access points (not shown), and UEs (UE-1, UE-2, and UE-3). A management function (Mnf) of a core network service 193, one or more of the base stations 191 and 192, and / or the one or more of the UEs (UE-1, UE-2, and UE-3) may collect and analyze data in conjunction with utilization of existing services and resources.

[0035] A consumer or operator 194 may reside within the subsystem and communicate with the core network service 193 via an interface (I / F) 195 by a wired or wireless connection with a base station 191 or an application program interface (API) with the core network service 193. Another consumer or operator 196 may reside outside the subsystem and communicate with the core network service 193 via an interface (VF) 197 by a wired or wireless connection with a base station 191 or an application program interface (API) with the core network service 193.

[0036] In some situations, consumer or operator 194 and / or the consumer or operator 196 may communicate with a network function (NF) of the cloud-base service referred to as a Network Data Analytics Function (NWDAF). The NWDAF may offer services to provide data and analytics to the consumer or operator 194 and / or the consumer or operator 196 and the consumer or operator 194 and / or the consumer or operator 196 may want to build and train a ML model, re-train an existing ML model for a subsystem of the cellular network for a subsystem in specific geographical area, or access a pre-trained ML model for the cellular network for a subsystem in specific geographical area to improve communications and data services in that subsystem. For example, the consumer or operator 194 may want to improve communications and data services for UEs, access points, base stations, and / or the like in a geographical area having a soccer stadium. The subsystem of the cellular system about the stadium might have periods of time, such as when there arc no games, wherein the infrastructure of the cellular system has little to no communications and data traffic and periods of time, such as during a soccer game, wherein there is a significant amount of communications and data traffic. In such situations, the consumer or operator 194 may want to optimize usage of cellular system resources during which a game is occurring in the stadium. The resources may include time and bandwidth resources to uplink (UL) and downlink (DL) data via base stations, access points, and UEs located fixed positions about the stadium to for fans attending the games.

[0037] To optimize the resources, the consumer or operator 194 may request for the NWDAF to train a ML model based on data collected and data analytics from historical data or based on new data collected and analyzed during a subsequent game. After the ML model is trained, the trained model may be provided to the consumer or operator 194 or operated in an inference mode for the consumer or operator 194 within the core network service 193 to predict usage of resources for the stadium during the games so base stations, access points, and / or UEs may receive configurations and / or parameters to optimize communications and data traffic.

[0038] ML model training may generally fall into the following main types of learning problem categories: supervised learning, unsupervised learning, and reinforcement learning. Supervised learning involves building models from a set of data that contains both the inputs and the desired outputs. Unsupervised learning is an ML task that aims to learn a function to describe a hidden structure from unlabeled data. Unsupervised learning involves building models from a set of data that contains only inputs and no desired output labels. Reinforcement learning (RL) is a goal- oriented learning technique where an RL agent aims to optimize a long-term objective by interacting with an environment.

[0039] In some embodiments, the consumer or operator 194 may request that the ML model be stored in the core network service 193, rather than storing the ML model locally at a server of the consumer or operator 194 in the geographical location of the stadium, for ML model sharing and / or for data security or privacy. For instance, the consumer or operator 194 may communicate a request to the NWDAF to store the ML model in the core network service 193.

[0040] In some embodiments, the NWDAF may be decomposed into two NFs in the core network service 193 including a NWDAF containing a Model Training Logical Function (MTLF) and a NWDAF containing an Analytics Logical Function (AnLF) to support ML model training and federated learning support. Tn such embodiments, the MTLF of the NWDAF may support storage or updating of ML models, retrieval of stored ML models, and deletion or removal of stored ML models. Furthermore, an Analytics Data Repository Function (ADRF) of the core network service 193 may support storage and sharing of ML models via a ML Model Management service API.

[0041] In many embodiments, the ADRF is accessible to consumers to store, retrieve, or remove data or analytics from the ADRF via NFs including the NWDAF, a Data Collection Coordination Function (DCCF), and a Messaging Framework Adaptor Function (MFAF). In many embodiments, the ADRF is accessible to consumers to store or update, retrieve, and delete or remove ML models from the ADRF via NFs including the NWDAF.

[0042] After receiving the request from the consumer or operator 194 to store the ML model trained for the subsystem about the stadium, the MTLF of the NWDAF may generate a management request to store the ML model in the ADRF in a form of a message including a Hypertext Transfer Protocol (HTTP) POST request with a Resource Uniform Resource Identifier (URI) representing a store record resource for the first ML model, a storage transaction identifier or a unique ML model identifier, a record data structure including a ML model info data structure in an ML model info attribute. The ML model info data structure may include a unique ML model identifier within a model Unique identifier (ID) attribute, an address of the ML model within a ML file Address attribute, and a storage size required for the ML model in a ML storage size attribute.

[0043] After receipt of the message from the MTLF of the ADRF to store the ML model, the ARDF may process the message by creating a new ML model store record; assigning a store transaction ID, and downloading and storing the ML model.

[0044] In many embodiments, ARDF may communicate a result to the MTLF of the NWDAF in the form of a message including a store result attribute indicating that the ML model is stored, the ML model file address is not found, or the file download for the ML model failed, depending on the result of processing the message to store the ML model.

[0045] In some embodiments, the consumer or operator 196 is associated with the consumer or operator 194 and may want an ML model for a second stadium in a different geographical area. In such embodiments, the consumer or operator 196 may request, via the interface 197, that the NWDAF retrain the ML model trained for the area about the stadium for the consumer or operator 194 with data and analytics for the geographical area about the second stadium. In response, the MTLF of the NWDAF may communicate a management request to the ADRF to retrieve the ML model. The management request may comprise a message comprising a HTTP GET request with a Resource URI representing a store record resource for the ML model, to request the store record resource for the ML model based on a storage transaction identifier or a unique ML model identifier. The ADRF may find the ML model according to the requested parameters and communicate a result to the MTLF of the NWDAF with a status code with a message body containing a data structure for the ML model.

[0046] The NWDAF may retrain the ML model with data and analytics for the geographical area about the second stadium and communicate the retrained ML model or predictions from inference by the retrained ML model to the consumer or operator 196 via the interface 197.

[0047] After the usefulness of the ML model is exhausted or a new ML model is created and trained to replace the ML model, the consumer or operator 194 may send a request to NWDAF of the core network service 193 to delete or remove the ML model from storage in the ARDF. The MTLF of the NWDAF may respond by generating a management request to delete or remove the ML model from the ADRF. The management request may include a HTTP DELETE request with a Resource URI representing a store record resource, wherein the Resource URI includes a transaction identifier of a stored record for the ML model that is to be deleted.

[0048] After receipt of the message from the MTLF of the ADRF, the ARDF may process the message by removing the storage transaction corresponding stored ML model record and responding with a result including a HTTP "204 No Content" status code.

[0049] Many embodiments may include security protocols for communications with NFs. For instance, prior to communicating with the NWDAF, the consumer or operator 194 may communication with an authorization service to obtain an authorization token. The authorization token may be included in a management request communicated to the NWDAF. Similarly, the MTLF may obtain an authorization token to communicate a message to the ADRF. For instance, unless the security protocols are determined to be unnecessary overhead for specified communications, the communications between the consumer or operator 194 (or the consumer or operator 197), the NWDAF, and the ARDF may require an authorization token prior to communicating a request, message, and / or result. In some embodiments, the request for an authorization token may include a NF ID, a vendor ID, and a location. The NF ID may comprise an identifier for the NF to which the request, message, or result is directed. The vendor ID may include an identifier for a specific vendor such as the vendor ID for the consumer or operator 194. And the location may comprise an indication of the service location such as an indication or identifier or set of identifiers for the geographical area about the stadium.

[0050] The communication network 190 is an Orthogonal Frequency Division Multiplex (OFDM) network comprising a primary base station 191, a secondary base station 192, a core network service 193, a first user equipment UE-1, a second user equipment UE-2, and a third user equipment UE-3. In a 3GPP system based on an Orthogonal Frequency Division Multiple Access (OFDMA) downlink, the radio resource is partitioned into subframes in time domain and each subframe comprises of two slots. Each OFDMA symbol further consists of a count of OFDMA subcarriers in frequency domain depending on the system (or carrier) bandwidth. The basic unit of the resource grid is called Resource Element (RE), which spans an OFDMA subcarrier over one OFDMA symbol. Resource blocks (RBs) comprise a group of REs, where each RB may comprise, e.g., 12 consecutive subcarriers in one slot.

[0051] Several physical downlink channels and reference signals use a set of resource elements carrying information originating from higher layers of code. For downlink channels, the Physical Downlink Shared Channel (PDSCH) is the main data-bearing downlink channel, while the Physical Downlink Control Channel (PDCCH) may carry downlink control information (DCI). The control information may include scheduling decision, information related to reference signal information, rules forming the corresponding transport block (TB) to be earned by PDSCH, and power control command. UEs may use cell-specific reference signals (CRS) for the demodulation of control / data channels in non-precoded or codebook-based precoded transmission modes, radio link monitoring and measurements of channel state information (CSI) feedback. UEs may use UE-specific reference signals (DM-RS) for the demodulation of control / data channels in non-codebook-based precoded transmission modes.

[0052] The communication network 190 may comprise a cell such as a micro-cell or a macro-cell and the base station 191 may provide wireless service to UEs within the cell. The base station 192 may provide wireless service to UEs within another cell located adjacent to or overlapping the cell. In other embodiments, the communication network 190 may comprise a macro-cell and the base station 192 may operate a smaller cell within the macro-cell such as a micro-cell or a picocell. Other examples of a small cell may include, without limitation, a micro-cell, a femto- ccll, or another type of smaller-sized cell.

[0053] In various embodiments, the base station 191 and the base station 192 may communicate over a backhaul. In some embodiments, the backhaul may comprise a wired backhaul. In various other embodiments, backhaul may comprise a wireless backhaul. In some embodiments, the backhaul may comprise an Xn interface or a Fl interface, which are interfaces defined between two RAN nodes or base stations such as the backhaul between the base station 191 and the base station 192. The Xn interface is an interface for gNBs and the Fl interface is an interface for gNB- Distributed units (DUs) if the architecture of the communication network 190 is a central unit / distributed unit (CU / DU) architecture. For instance, the base station 191 may comprise a CU and the base station 192 may comprise a DU in some embodiments. In other embodiments, both the base stations 191 and 192 may comprise eNBs or gNBs.

[0054] The base stations 191 and 192 may communicate protocol data units (PDUs) via the backhaul. As an example, for the Xn interface, the base station 191 may transmit or share control plane PDUs via an Xn-C interface and may transmit or share data PDUs via a Xn-U interface. For the Fl interface, the base station 191 may transmit or share control plane PDUs via an Fl-C interface and may transmit or share data PDUs via a Fl-U interface. Note that discussions herein about signaling, sharing, receiving, or transmitting via a Xn interface may refer to signaling, sharing, receiving, or transmitting via the Xn-C interface, the Xn-U interface, or a combination thereof. Similarly, discussions herein about signaling, sharing, receiving, or transmitting via a Fl interface may refer to signaling, sharing, receiving, or transmitting via the Fl-C interface, the Fl-U interface, or a combination thereof.

[0055] FIG. IB illustrates an embodiment of a network 190B in accordance with various embodiments such as the network 190 in FIG. 1A. The network 190B may operate in a manner consistent with 3GPP technical specifications for LTE or 5G / NR systems. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.

[0056] The network 190B includes a UE 192B, which is any mobile or non-mobile computing device designed to communicate with a RAN 104 via an over-the-air connection. The UE 192B is communicatively coupled with the RAN 104 by a Uu interface, which may be applicable to both LTE and NR systems. Examples of the UE 192B include, but are not limited to, a smartphone, tablet computer, wearable device (c.g., smart watch, fitness tracker, smart glasses, small clothing / fabrics, head-mounted displays, smart shows, and / or the like), desktop computer, workstation, laptop computer, in-vehicle infotainment system, in-car entertainment system, instrument cluster, head-up display (HUD) device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) device, Internet of Things (loT) device, smart appliance, flying drone or unmanned aerial vehicle (UAV), terrestrial drone or autonomous vehicle, robot, electronic signage, single-board computer (SBC) (e.g., Raspberry Pi, Arduino, Intel Edison, and the like), plug computers, and / or any type of computing device such as any of those discussed herein.

[0057] In some embodiments, network 190B may include a set of UEs 192B coupled directly with one another via a D2D, ProSe, PC5, and / or sidelink (SL) interface, and / or any other suitable interface such as any of those discussed herein. In 3GPP systems, SL communication involves communication between two or more UEs 192B using 3GPP technology without traversing a network node. These UEs 192B may be M2M / D2D / MTC / IoT devices and / or vehicular systems that communicate using an SL interface, which includes, for example, one or more SL logical channels (e.g., Sidelink Broadcast Control Channel (SBCCH), Sidelink Control Channel (SCCH), and Sidelink Traffic Channel (STCH)); one or more SL transport channels (e.g., Sidelink Shared Channel (SL-SCH) and Sidelink Broadcast Channel (SL-BCH)); and one or more SL physical channels (e.g., Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Control Channel (PSCCH), Physical Sidelink Feedback Channel (PSFCH), Physical Sidelink Broadcast Channel (PSBCH), and / or the like). The UE I92B may perform blind decoding attempts of SL channels / links according to the various examples herein.

[0058] In some embodiments, the UE 192B may additionally communicate with an AP 106 via an over-the-air connection. The AP 106 may manage a WLAN connection, which may serve to offload some / all network traffic from the RAN 104. The connection between the UE 192B and the AP 106 may be consistent with any IEEE 802.11 protocol, wherein the AP 106 could be a wireless fidelity (Wi-Fi®) router. In some embodiments, the UE 192B, RAN 104, and AP 106 may utilize cellular- WLAN aggregation (for example, LWA / LWIP). Cellular- WLAN aggregation may involve the UE 192B being configured by the RAN 104 to utilize both cellular radio resources and WLAN resources.

[0059] The RAN 104 may include one or more access nodes, for example, AN 108. AN 108 may terminate air-interface protocols for the UE 192B by providing access stratum protocols including RRC, PDCP, RLC, MAC, and PHY / L1 protocols. In this manner, the AN 108 may enable a service for data / voice connectivity between CN 120 and the UE 192B. In some embodiments, the AN 108 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. The AN 108 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 108 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0060] Some embodiments comprise a “CU / DU split” architecture where the ANs 108 are embodied as a gNB -Central Unit (CU) that is communicatively coupled with one or more gNB -Distributed Units (DUs), where each DU may be communicatively coupled with one or more Radio Units (RUs) (also referred to as RRHs, RRUs, or the like). In some implementations, the one or more RUs may be individual RSUs. In some implementations, the CU / DU split may include an ng- eNB-CU and one or more ng-eNB-DUs instead of, or in addition to, the gNB-CU and gNB-DUs, respectively. The ANs 108 employed as the CU may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network including a virtual Base Band Unit (BBU) or BBU pool, cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), centralized RAN (C-RAN), virtualized RAN (vRAN), and / or the like (although these terms may refer to different implementation concepts). Any other type of architectures, arrangements, and / or configurations can be used.

[0061] In embodiments in which the RAN 104 includes a plurality of ANs, they may be coupled with one another via an X2 interface (if the RAN 104 is an LTE RAN) or an Xn interface (if the RAN 104 is a 5G RAN). The X2 / Xn interfaces, which may be separated into control / user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data / context transfers, mobility, load management, interference coordination, etc. The ANs of the RAN 104 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 192B with an air interface for network access. The UE 192B may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 104. For example, the UE 192B and RAN 104 may use carrier aggregation to allow the UE 192B to connect with a plurality of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG. The first / second ANs may be any combination of eNB, gNB, ng-eNB, etc.

[0062] The RAN 104 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCells / Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium / carrier- sensing operations based on, for example, a listen-before-talk (LBT) protocol.

[0063] Additionally, or alternatively, individual UEs 192B provide radio information to one or more ANs 108 and / or one or more edge compute nodes (e.g., edge servers / hosts, and the like). The radio information may be data in the form of one or more measurement reports, and / or may include, for example, signal strength measurements, signal quality measurements, and / or the like. Each measurement report is tagged with a timestamp and the location of the measurement (e.g., the UEs 192B current location). As examples, the measurements collected by the UEs 192B and / or included in the measurement reports may include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round trip time (RTT), number of interrupts, out-of-order delivery of data packets, transmission power, bit error rate, bit error ratio (BER), Block Error Rate (BLER), packet error ratio (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) delay, signal-to-noise ratio (SNR), signal- to-noise and interference ratio (SINR), signal-plus-noise-plus-distortion to noise-plus-distortion (SINAD) ratio, carrier-to-interference plus noise ratio (CINR), Additive White Gaussian Noise (AWGN), energy per bit to noise power density ratio (Eb / NO), energy per chip to interference power density ratio (Ec / 10), energy per chip to noise power density ratio (Ec / NO), peak-to- average power ratio (PAPR), reference signal received power (RSRP), reference signal received quality (RSRQ), received signal strength indicator (RSSI), received channel power indicator (RCPI), received signal to noise indicator (RSNI), Received Signal Code Power (RSCP), average noise plus interference (ANPI), GNSS timing of cell frames for UE positioning for E-UTRAN or 5G / NR (c.g., a timing between an AP 106 or RAN node 108 reference time and a GNSS-spccific reference time for a given GNSS), GNSS code measurements (e.g., the GNSS code phase (integer and fractional parts) of the spreading code of the ith GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier-phase cycles (integer and fractional parts) of the ith GNSS satellite signal, measured since locking onto the signal; also called Accumulated Delta Range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, power histogram measurements, channel load measurements, STA statistics, and / or other like measurements. The RSRP, RSSI, and / or RSRQ measurements may include RSRP, RSSI, and / or RSRQ measurements of cellspecific reference signals, channel state information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks for 3GPP networks (e.g., LTE or 5G / NR), and RSRP, RSSI, RSRQ, RCPI, RSNI, and / or ANPI measurements of various beacon, Fast Initial Link Setup (FILS) discovery frames, or probe response frames for WLAN / WiFi networks. Other measurements may be additionally or alternatively used. Additionally, or alternatively, any of the aforementioned measurements (or combination of measurements) may be collected by one or more ANs 108 and provided to the edge compute node(s).

[0064] Additionally or alternatively, the measurements can include one or more of the following measurements: measurements related to Data Radio Bearer (DRB) (e.g., number of DRBs attempted to setup, number of DRBs successfully setup, number of released active DRBs, insession activity time for DRB, number of DRBs attempted to be resumed, number of DRBs successfully resumed, and the like); measurements related to Radio Resource Control (RRC) (e.g., mean number of RRC connections, maximum number of RRC connections, mean number of stored inactive RRC connections, maximum number of stored inactive RRC connections, number of attempted, successful, and / or failed RRC connection establishments, and the like); measurements related to UE Context (UECNTX); measurements related to Radio Resource Utilization (RRU) (e.g., DL total PRB usage, UL total PRB usage, distribution of DL total PRB usage, distribution of UL total PRB usage, DL PRB used for data traffic, UL PRB used for data traffic, DL total available PRBs, UL total available PRBs, and the like); measurements related to Registration Management (RM); measurements related to Session Management (SM) (e.g., number of PDU sessions requested to setup; number of PDU sessions successfully setup; number of PDU sessions failed to setup, and the like); measurements related to GTP Management (GTP); measurements related to IP Management (IP); measurements related to Policy Association (PA); measurements related to Mobility Management (MM) (e.g., for inter-RAT, intra-RAT, and / or Intra / Inter-frequency handovers and / or conditional handovers: number of requested, successful, and / or failed handover preparations; number of requested, successful, and / or failed handover resource allocations; number of requested, successful, and / or failed handover executions; mean and / or maximum time of requested handover executions; number of successful and / or failed handover executions per beam pair, and the like); measurements related to Virtualized Resource(s) (VR); measurements related to Carrier (CARR); measurements related to QoS Flows (QF) (e.g., number of released active QoS flows, number of QoS flows attempted to release, in-session activity time for QoS flow, in-session activity time for a UE 192B, number of QoS flows attempted to setup, number of QoS flows successfully established, number of QoS flows failed to setup, number of initial QoS flows attempted to setup, number of initial QoS flows successfully established, number of initial QoS flows failed to setup, number of QoS flows attempted to modify, number of QoS flows successfully modified, number of QoS flows failed to modify, and the like); measurements related to Application Triggering (AT); measurements related to Short Message Service (SMS); measurements related to Power, Energy and Environment (PEE); measurements related to NF service (NFS); measurements related to Packet Flow Description (PFD); measurements related to Random Access Channel (RACH); measurements related to Measurement Report (MR); measurements related to Layer 1 Measurement (L1M); measurements related to Network Slice Selection (NSS); measurements related to Paging (PAG); measurements related to Non-IP Data Delivery (NIDD); measurements related to external parameter provisioning (EPP); measurements related to traffic influence (TI); measurements related to Connection Establishment (CE); measurements related to Service Parameter Provisioning (SPP); measurements related to Background Data Transfer Policy (BDTP); measurements related to Data Management (DM); and / or any other performance measurements.

[0065] The radio information (data) may be reported in response to a trigger event and / or on a periodic basis. Additionally, or alternatively, individual UEs 192B report radio information either at a low periodicity or a high periodicity depending on a data transfer that is to take place, and / or other information about the data transfer. Additionally, or alternatively, the edge compute node(s) may request the measurements from the ANs 108 at low or high periodicity, or the ANs 108 may provide the measurements to the edge compute nodc(s) at low or high periodicity. Additionally, or alternatively, the edge compute node(s) may obtain other relevant data from other edge compute node(s), core network functions (NFs), application functions (AFs), and / or other UEs 192B such as Key Performance Indicators (KPIs), with the measurement reports or separately from the measurement reports.

[0066] Additionally or alternatively, in cases where is discrepancy in the observation data from one or more UEs, one or more RAN nodes, and / or core network NFs (e.g., missing reports, erroneous data, and the like) simple imputations may be performed to supplement the obtained observation data such as, for example, substituting values from previous reports and / or historical data, apply an extrapolation filter, and / or the like. Additionally, or alternatively, acceptable bounds for the observation data may be predetermined or configured. For example, CQI and MCS measurements may be configured to only be within ranges defined by suitable 3GPP standards. In cases where a reported data value does not make sense (e.g., the value exceeds an acceptable range / bounds, or the like), such values may be dropped for the current learning / training episode or epoch. For example, on packet delivery delay bounds may be defined or configured, and packets determined to have been received after the packet delivery delay bound may be dropped.

[0067] The UE 192B can also perform reference signal (RS) measurement and reporting procedures to provide the network with information about the quality of one or more wireless channels and / or the communication media in general, and this information can be used to optimize various aspects of the communication system. The physical signals and / or reference signals can include demodulation reference signals (DM-RS), phase-tracking reference signals (PT-RS), positioning reference signal (PRS), channel-state information reference signal (CSI-RS), synchronization signal block (SSB), primary synchronization signal (PSS), secondary synchronization signal (SSS), sounding reference signal (SRS), and / or the like.

[0068] In any of the examples discussed herein, any suitable data collection and / or measurement mechanism(s) may be used to collect the observation data. For example, data marking (e.g., sequence numbering, and the like), packet tracing, signal measurement, data sampling, and / or timestamping techniques may be used to determine any of the aforementioned metrics / observations. The collection of data may be based on occurrence of events that trigger collection of the data. Additionally, or alternatively, data collection may take place at the initiation or termination of an event. The data collection can be continuous, discontinuous, and / or have start and stop times. The data collection tcchniqucs / mcchanisms may be specific to a HW configuration / implementation or non-HW-specific, or may be based on various software parameters (e.g., OS type and version, and the like). Various configurations may be used to define any of the aforementioned data collection parameters. Such configurations may be defined by suitable specifications / standards, such as 3GPP (e.g., [SA6Edge]), ETSI (e.g., [MEC]), O- RAN (e.g., [O-RAN]), Intel® Smart Edge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., MAMS [RFC8743]), lEEE / WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], and the like), and / or any other like standards such as those discussed herein.

[0069] In V2X scenarios, the UE 192B or AN 108 may be or act as a roadside unit (RSU), which may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications / software to sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communications required for high-speed events, such as crash avoidance, traffic warnings, and the like. Additionally, or alternatively, the RSU may provide other cellular / WLAN communications services. The components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.

[0070] Furthermore, one or more V2X RATs may be employed, which allow V2X nodes to communicate directly with one another, with infrastructure equipment (e.g., AN 108), and / or other devices / nodes. In some embodiments, at least two distinct V2X RATs may be used including WLAN V2X (W-V2X) RATs based on IEEE V2X technologies (e.g., DSRC for the U.S. and ITS-G5 for Europe) and cellular V2X (C-V2X) RATs based on 3GPP V2X technologies (e.g., LTE V2X, 5G / NR V2X, and beyond). In one example, the C-V2X RAT may utilize a C-V2X air interface and the WLAN V2X RAT may utilize a W-V2X air interface. The W-V2X RATs include, for example, IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture, IEEE STANDARDS ASSOCIATION, IEEE 1609.0-2019 (10 Apr. 2019) (“[IEEE16090]”), V2X Communications Message Set Dictionary, SAE INT’L (23 Jul. 2020) (“[J2735_202007]”), Intelligent Transport Systems in the 5 GHz frequency band (ITS-G5), the [IEEE80211p] (which is the layer 1 (LI) and layer 2 (L2) part of WAVE, DSRC, and ITS-G5), and / or IEEE Standard for Air Interface for Broadband Wireless Access Systems, IEEE Std 802.16-2017, pp.1-2726 (02 Mar. 2018) (“[WiMAX]”). The term “DSRC” refers to vehicular communications in the 5.9 GHz frequency band that is generally used in the United States, while “ITS-G5” refers to vehicular communications in the 5.9 GHz frequency band in Europe. Since any number of different RATs are applicable (including [IEEE80211p] RATs) that may be used in any geographic or political region, the terms “DSRC” (used, among other regions, in the U.S) and “ITS-G5” (used, among other regions, in Europe) may be used interchangeably throughout this disclosure. The access layer for the ITS-G5 interface is outlined in ETSI EN 302 663 VI.3.1 (2020-01) (hereinafter “[EN302663]”) and describes the access layer of the ITS-S reference architecture. The ITS-G5 access layer comprises [IEEE80211] (which now incorporates [IEEE80211p]), as well as features for Decentralized Congestion Control (DCC) methods discussed in ETSI TS 192B 687 Vl.2.1 (2018-04) (“[TS192B687]”). The access layer for 3GPP LTE-V2X based interface(s) is outlined in, inter alia, ETSI EN 303 613 VI.1.1 (2020-01), 3GPP TS 23.285 vl6.2.0 (2019-12); and 3GPP 5G / NR-V2X is outlined in, inter alia, 3GPP TR 23.786 vl6.1.0 (2019-06) and 3GPP TS 23.287 vl8.0.0 (2023-03-31) (“[TS23287]”).

[0071] In some embodiments, the RAN 104 may be an LTE RAN 110 with eNBs, for example, eNB 112. The LTE RAN 110 may provide an LTE air interface (Uu) with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface may operate on sub-6 GHz bands.

[0072] In some embodiments, the RAN 104 may be an NG-RAN 114 with gNBs, for example, gNB 116, or ng-eNBs, for example, ng-eNB 118. The gNB 116 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 1 16 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng-cNB 118 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface. The gNB 116 and the ng-eNB 118 may connect with each other over an Xn interface.

[0073] In some embodiments, the NG interface may be split into two parts, an NG user plane (NG- U) interface, which carries traffic data between the nodes of the NG-RAN 114 and a UPF 148 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN114 and an AMF 144 (e.g., N2 interface).

[0074] The NG-RAN 114 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed- Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH / PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G-NR air interface may operate on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS / SSS / PBCH.

[0075] In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 192B can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 192B, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 192B with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 192B and in some cases at the gNB 116. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.

[0076] In some implementations, individual gNBs 116 can include a gNB-CU and a set of gNB- DUs. Additionally, or alternatively, gNBs 116 can include one or more RUs. In these implementations, the gNB-CU may be connected to each gNB-DU via respective Fl interfaces. In case of network sharing with multiple cell ID broadcast(s), each cell identity associated with a subset of PLMNs corresponds to a gNB-DU and the gNB-CU it is connected to share the same physical layer cell resources. For resiliency, a gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. Additionally, a gNB-CU can be separated into gNB-CU control plane (gNB-CU-CP) and gNB-CU user plane (gNB-CU-UP) functions. The gNB-CU-CP is connected to a gNB-DU through an Fl control plane interface (Fl-C), the gNB-CU-UP is connected to the gNB-DU through an Fl user plane interface (Fl-U), and the gNB-CU-UP is connected to the gNB-CU-CP through an El interface. In some implementations, one gNB-DU is connected to only one gNB-CU-CP, and one gNB-CU-UP is connected to only one gNB-CU- CP. For resiliency, a gNB-DU and / or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation. One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and one gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP. Data forwarding between gNB-CU-UPs during intra- gNB-CU-CP handover within a gNB may be supported by Xn-U.

[0077] Similarly, individual ng-eNBs 118 can include an ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, the ng-eNB-CU and each ng-eNB-DU are connected to one another via respective W1 interface. An ng-eNB can include an ng-eNB-CU-CP, one or more ng-eNB-CU- UP(s), and one or more ng-eNB-DU(s). An ng-eNB-CU-CP and an ng-eNB-CU-UP is connected via the El interface. An ng-eNB-DU is connected to an ng-eNB-CU-CP via the Wl-C interface, and to an ng-eNB-CU-UP via the Wl-U interface. The general principle described herein w.r.t gNB aspects also applies to ng-eNB aspects and corresponding El and W1 interfaces, if not explicitly specified otherwise.

[0078] The node hosting user plane part of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB depending on the bearer split) performs user inactivity monitoring and further informs its inactivity or (re)activation to the node having control plane connection towards the core network (e.g., over El, X2, or the like). The node hosting the RLC protocol layer (e.g., gNB-DU) may perform user inactivity monitoring and further inform its inactivity or (re)activation to the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP).

[0079] In these implementations, the NG-RAN 114, is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN 114 architecture (e.g., the NG-RAN logical nodes and interfaces between them) is part of the RNL. For each NG-RAN interface (e.g., NG, Xn, Fl, and the like) the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and / or signaling transport. In NG-Flex configurations, each NG-RAN node is connected to all AMFs 144 of AMF sets within an AMF region supporting at least one slice also supported by the NG-RAN node.

[0080] The RAN 104 is communicatively coupled to CN 120 that includes network elements to provide various functions to support data and telecommunications services to customers / subscribers (for example, users of UE 192B). The components of the CN 120 may be implemented in one physical node or separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 120 onto physical compute / storage resources in servers, switches, etc. A logical instantiation of the CN 120 may be referred to as a network slice, and a logical instantiation of a portion of the CN 120 may be referred to as a network sub-slice.

[0081] In some embodiments, the CN 120 may be an LTE CN 122, which may also be referred to as an EPC. The LTE CN 122 may include MME 124, SGW 126, SGSN 128, HSS 130, PGW 132, and PCRF 134 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 122 may be briefly introduced as follows.

[0082] The MME 124 may implement mobility management functions to track a current location of the UE 192B to facilitate paging, bearer activation / deactivation, handovers, gateway selection, authentication, etc.

[0083] The SGW 126 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 122. The SGW 126 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

[0084] The SGSN 128 may track a location of the UE 192B and perform security functions and access control. In addition, the SGSN 128 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 124; MME selection for handovers; etc. The S3 reference point between the MME 124 and the SGSN 128 may enable user and bearer information exchange for inter-3GPP access network mobility in idle / active states.

[0085] The HSS 130 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. The HSS 130 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. An S6a reference point between the HSS 130 and the MME 124 may enable transfer of subscription and authentication data for authenticating / authorizing user access to the LTE CN 120.

[0086] The PGW 132 may terminate an SGi interface (interface 182A) toward a data network (DN) 136 that may include one or more application / content servers 138 such as the framework logic circuitry 100 shown in FIG. 1A and / or other application content servers 138. The PGW 132 may route data packets between the LTE CN 122 and the data network 136. The PGW 132 may be coupled with the SGW 126 by an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 132 may further include a node for policy enforcement and charging data collection (for example, PCEF). Additionally, the SGi reference point between the PGW 132 and the data network 136 may be an operator external public, a private PDN, or an intraoperator packet data network, for example, for provision of IMS services. The PGW 132 may be coupled with a PCRF 134 via a Gx reference point.

[0087] The PCRF 134 is the policy and charging control element of the LTE CN 122. The PCRF 134 may be communicatively coupled to the app / content server 138 to determine appropriate QoS and charging parameters for service flows. The PCRF 132 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.

[0088] In some embodiments, the CN 120 may be a 5GC 140. The 5GC 140 may include an Authentication Server Function (AUSF) 142, Access and Mobility Management Function (AMF) 144, Session Management Function (SMF) 146, User Plane Function (UPF) 148, Network Slice Selection Function (NSSF) 150, Network Exposure Function (NEF) 152, Network Repository Function (NRF) 154, Policy Control Function (PCF) 156, Unified Data Management (UDM) 158, Unified Data Repository (UDR), Application Function (AF) 160, Edge Application Server Discovery Function (EASDF) 161, Network Data Analytics Function (NWDAF) 162, and Analytics Data Repository Function (ADRF) 163 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the 5GC 140 may be briefly introduced as follows.

[0089] The NWDAF 162 includes one or more of the following functionalities: support data collection from NFs and AFs 160; support data collection from Operations, Administration, and Maintenance (0AM); NWDAF service registration and metadata exposure to NFs and AFs 160; support analytics information provisioning to NFs and AFs 160; support machine learning (ML) model training and provisioning to NWDAF(s) 162 (e.g., those containing analytics logical function); and support storing or updating, retrieving, and deletion or removal of ML models from storage in the ADRF 163. The NWDAF 162 also includes an analytics reporting capability, which comprises means that allow discovery of the type of analytics that can be consumed by an external party and / or the request for consumption of analytics information generated by the NWDAF 162. In some embodiments, some of or all the NWDAF functionalities can be supported in a single instance of an NWDAF 162. In some embodiments, the NWDAF 162 is decomposed into two NFs including a NWDAF containing MTLF and a NWDAF containing AnLF. In many embodiments, the NWDAF containing MTLF may perform ML model training as well as ML model storage or updating, retrieval, and deletion or removal via the ADRF 163.

[0090] The NWDAF 162 interacts with different entities for different purposes, such as one or more of the following: data collection based on subscription to events provided by AMF 144, SMF 146, PCF 156, UDM 158, NSACF, AF 160 (directly or via NEF 152) and 0AM (not shown); analytics and data collection using the Data Collection Coordination Function (DCCF); retrieval of information from data repositories (e.g. UDR via UDM 158 for subscriber-related information); data collection of location information from LCS system; storage / updating, deletion / removal, and retrieval of data, analytics, and ML models from an Analytics Data Repository Function (ADRF) 163; analytics and data collection from a Messaging Framework Adaptor Function (MFAF); retrieval of information about NFs (e.g. from NRF 154 for NF- related information); on-demand provision of analytics to consumers,; and / or provision of bulked data related to analytics ID(s).

[0091] A single instance or multiple instances of NWDAF 162 may be deployed in a PLMN. If multiple NWDAF 162 instances are deployed, the architecture supports deploying the NWDAF 162 as a central NF, as a collection of distributed NFs, or as a combination of both. If multiple NWDAF 162 instances are deployed, an NWDAF 162 can act as an aggregate point (e.g., aggregator NWDAF 162) and collect analytics information from other NWDAFs 162, which may have different serving areas, to produce the aggregated analytics (e.g., per analytics ID), possibly with analytics generated by itself. When multiple NWDAFs 162 exist, not all of them need to be able to provide the same type of analytics results. For example, some of the NWDAFs 162 can be specialized in providing certain types of analytics. An analytics ID information element is used to identify the type of supported analytics that NWDAF 162 can generate. In some implementations, NWDAF 162 instancc(s) can be collocated with a 5GS NF.

[0092] Different NWDAF 162 instances may be present in the 5GC 140, with possible specializations per type of analytics. The capabilities of an NWDAF 162 instance are described in the NWDAF profile stored in the NRF 154. The NWDAF architecture allows for arranging multiple NWDAF 162 instances in a hierarchy / tree with a flexible number of layers / branches. The number and organization of the hierarchy layers, as well as the capabilities of each NWDAF 162 instance remain deployment choices and may vary depending on implementation and / or use case. In a hierarchical deployment, NWDAFs 162 may provide data collection exposure capability for generating analytics based on the data collected by other NWDAFs 162, when DCCFs 163 and / or MFAFs 165 are not present in the network.

[0093] An Analytics Data Repository Service is used for the ADRF 163 for storage and updating, retrieval, and deletion or removal of data and ML model(s) by e.g. NF service consumers (e.g. NWDAF) which access the data or ML model(s) using Nadrf service. The ADRF 163 offers to NF service consumers the services in Table 1:

[0094] TABLE 1 Table 2 summarizes the corresponding APIs defined for the ADRF:

[0095] TABLE 2

[0096] In many embodiments, the ADRF 163 may also request and / or receive notifications about data or analytics that arc about to be deleted.

[0097] The AUSF 142 may store data for authentication of UE 192B and handle authentication- related functionality. The AUSF 142 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 140 over reference points as shown, the AUSF 142 may exhibit an Nausf service-based interface.

[0098] The AMF 144 may allow other functions of the 5GC 140 to communicate with the UE 192B and the RAN 104 and to subscribe to notifications about mobility events with respect to the UE 192B. The AMF 144 may be responsible for registration management (for example, for registering UE 192B), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 144 may provide transport for SM messages between the UE 192B and the SMF 146, and act as a transparent proxy for routing SM messages. AMF 144 may also provide transport for SMS messages between UE 192B and an SMSF. AMF 144 may interact with the AUSF 142 and the UE 192B to perform various security anchor and context management functions. Furthermore, AMF 144 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 104 and the AMF 144; and the AMF 144 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection. AMF 144 may also support NAS signaling with the UE 192B over an N3 IWF interface.

[0099] The AMF 144 also supports NAS signaling with the UE 192B over an N3IWF interface. The N3IWF provides access to untrusted entities. N3IWF may be a termination point for the N2 interface between the (R)AN 104 and the AMF 144 for the control plane, and may be a termination point for the N3 reference point between the (R)AN 104 and the 148 for the user plane. As such, the AMF 144 handles N2 signaling from the SMF 146 and the AMF 144 for PDU sessions and QoS, encapsulate / de-encapsulate packets for IPSec and N3 tunneling, marks N3 user-plane packets in the UL, and enforces QoS corresponding to N3 packet marking taking into account QoS requirements associated with such marking received over N2. N3IWF may also relay UL and DL control-plane NAS signaling between the UE 192B and AMF 144 via an N1 reference point between the UE 192B and the AMF 144, and relay UL and DL user-plane packets between the UE 192B and UPF 148. The N3IWF also provides mechanisms for IPsec tunnel establishment with the UE 192B. The AMF 144 may exhibit an Namf service-based interface, and may be a termination point for an N14 reference point between two AMFs 144 and an N17 reference point between the AMF 144 and a 5G-EIR (not shown by Figure 1). In addition to the functionality of the AMF 144 described herein, the AMF 144 may provide support for Network Slice restriction and Network Slice instance restriction based on NWDAF analytics.

[0100] The SMF 146 may be responsible for SM (for example, session establishment, tunnel management between UPF 148 and AN 108); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 148 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 144 over N2 to AN 108; and determining SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 192B and the data network 136.

[0101] The SMF 146 may also include the following functionalities to support edge computing enhancements: selection of EASDF 161 and provision of its address to the UE as the DNS server for the PDU session; usage of EASDF 161 services; and for supporting the application layer architecture, provision and updates of ECS address configuration information to the UE.

[0102] The UPF 148 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 136, and a branching point to support multihomed PDU session. The UPF 148 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., SDF-to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 148 may include an uplink classifier to support routing traffic flows to a data network.

[0103] The NSSF 150 may select a set of network slice instances serving the UE 192B. The NSSF 150 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed. The NSSF 150 may also determine the AMF set to be used to serve the UE 192B, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 154. The selection of a set of network slice instances for the UE 192B may be triggered by the AMF 144 with which the UE 192B is registered by interacting with the NSSF 150, which may lead to a change of AMF. The NSSF 150 may interact with the AMF 144 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 150 may exhibit an Nnssf service-based interface.

[0104] The NEF 152 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure / re-exposure, AFs (e.g., AF 160), edge computing or fog computing systems, etc. In such embodiments, the NEF 152 may authenticate, authorize, or throttle the AFs. NEF 152 may also translate information exchanged with the AF 160 and information exchanged with internal network functions. For example, the NEF 152 may translate between an AF-Service-Identifier and an internal 5GC information. NEF 152 may also receive information from other NFs based on exposed capabilities of other NFs. In particular, the NEF 152 handles masking of network and user sensitive information to external AF's 160 according to the network policy. The NEF 152 also receives information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 152 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 152 to other NFs and AFs, or used for other purposes such as analytics. For example, NWDAF analytics may be securely exposed by the NEF 152 for external party. Furthermore, data provided by an external party may be collected by the NWDAF 162 via the NEF 152 for analytics generation purpose. The NEF 152 handles and forwards requests and notifications between the NWDAF 162 and AF(s) 160. Additionally, the NEF 152 may exhibit an Nnef service-based interface.

[0105] The NRF 154 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 154 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0106] The NRF 154 supports service discovery functions, receives NF discovery requests from NF instances, and provides information of the discovered NF instances to the requesting NF instances. The NRF 154 also maintains NF profiles of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0107] The NF profile of NF instance maintained in the NRF 154 includes the following information: NF instance ID; NF type; PLMN ID in the case of PLMN, PLMN ID + NID in the case of SNPN; Network Slice related Identifier(s) (e.g., S-NSSAI, NSI ID); an NF’s network address(es) (e.g., FQDN, IP address, and / or the like), NF capacity information, NF priority information (e.g., for AMF selection), NF set ID, NF service set ID of the NF service instance; NF specific service authorization information; names of supported services, if applicable; endpoint address(es) of instance(s) of each supported service; identification of stored data / information (e.g., for UDR profile and / or other NF profiles); other service parameter(s) (e.g., DNN or DNN list, LADN DNN or LADN DNN list, notification endpoint for each type of notification that the NF service is interested in receiving, and / or the like); location information for the NF instance (e.g., geographical location, data center, and / or the like); TAI(s); NF load information; Routing Indicator, Home Network Public Key identifier, for UDM 158 and AUSF 142; for UDM 158, AUSF 142, and NSSAAF in the case of access to an SNPN using credentials owned by a Credentials Holder with AAA Server, identification of Credentials Holder (e.g., the realm of the Network Specific Identifier based SUPI); for UDM 158 and AUSF 142, and if UDM 158 / AUSF 142 is used for access to an SNPN using credentials owned by a Credentials Holder, identification of Credentials Holder (e.g., the realm if network specific identifier based SUPI is used or the MCC and MNC if IMSI based SUPI is used); for AUSF 142 and NSSAAF in the case of SNPN Onboarding using a DCS with AAA server, identification of DCS (e.g., the realm of the Network Specific Identifier based SUPI); for UDM 158 and AUSF 142, and if UDM 158 / AUSF 142is used as DCS in the case of SNPN Onboarding, identification of DCS ((e.g., the realm if Network Specific Identifier based SUPI, or the MCC and MNC if IMSI based SUPI); one or more GUAMI(s), in the case of AMF 144; UDM Group ID, rangc(s) of SUPIs, range(s) of GPSIs, range(s) of internal group identifiers, range(s) of external group identifiers for UDM 158; UDR Group ID, range(s) of SUPIs, range(s) of GPSIs, range(s) of external group identifiers for UDR; AUSF Group ID, range(s) of SUPIs for AUSF 142; PCF Group ID, range(s) of SUPIs for PCF 156; HSS Group ID, set(s) of IMPIs, set(s) of IMPU, set(s) of IMSIs, set(s) of PSIs, set(s) of MSISDN for HSS; event ID(s) supported by AFs 160, in the case of NEF 152; event Exposure service supported event ID(s) by UPF 148; application identifier(s) supported by AFs 160, in the case of NEF 152; range(s) of external identifiers, or range(s) of external group identifiers, or the domain names served by the NEF, in the case of NEF 152 (e.g., used when the NEF 152 exposes AF information for analytics purpose; additionally the NRF 154 may store a mapping between UDM Group ID and SUPI(s), UDR Group ID and SUPI(s), AUSF Group ID and SUPI(s) and PCF Group ID and SUPI(s), to enable discovery of UDM 158, UDR, AUSF 142 and PCF 156 using SUPI, SUPI ranges, and / or interact with UDR to resolve the UDM Group ID / UDR Group ID / AUSF Group ID / PCF Group ID based on UE identity (e.g., SUPI)); IP domain list, Range(s) of (UE) IPv4 addresses or Range(s) of (UE) IPv6 prefixes, Range(s) of SUPIs or Range(s) of GPSIs or a BSF Group ID, in the case of BSF; SCP Domain the NF belongs to; DCCF Serving Area information, NF types of the data sources, NF Set IDs of the data sources, if available, in the case of DCCF 163; supported DNAI list, in the case of SMF 146; for SNPN, capability to support SNPN Onboarding in the case of AMF and capability to support User Plane Remote Provisioning in the case of SMF 146; IP address range, DNAI for UPF 148; additional V2X related NF profile parameters are defined in 3GPP TS 23.287; additional ProSe related NF profile parameters are defined in 3GPP TS 23.304; additional MBS related NF profile parameters; additional UAS related NF profile parameters; among many others. In some examples, service authorization information provided by an 0AM system is also included in the NF profile in the case that, for example, an NF instance has an exceptional service authorization information. Additionally, the NRF 154 may exhibit the Nnrf service-based interface.

[0108] For NWDAF 162, the NF profile includes: supported analytics ID(s), possibly per service, NWDAF serving area information (e.g., a list of TAIs for which the NWDAF can provide services and / or data), Supported Analytics Delay per Analytics ID (if available), NF types of the NF data sources, NF Set IDs of the NF data sources, if available, analytics aggregation capability (if available), analytics metadata provisioning capability (if available), ML model filter information parameters S-NSSAI(s) and area(s) of interest for the trained ML model(s) per analytics ID(s) (if available), federated learning (FL) capability type (e.g., FL server or FL client, if available), Time interval supporting FL (if available). The NWDAF's 162 Serving Area information is common to all its supported analytics IDs. The analytics IDs supported by the NWDAF 162 may be associated with a supported analytics delay, for example, the analytics report can be generated with a time (including data collection delay and inference delay) in less than or equal to the supported analytics delay. The determination of supported analytics delay, and how the NWDAF 162 avoid updating its Supported Analytics Delay in NRF frequently may be NWDAF-implementation specific.

[0109] The PCF 156 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 156 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 158. In addition to communicating with functions over reference points as shown, the PCF 156 exhibit an Npcf service-based interface.

[0110] The UDM 158 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 192B. For example, subscription data may be communicated via an N8 reference point between the UDM 158 and the AMF 144. The UDM 158 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 158 and the PCF 156, and / or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 192B) for the NEF 152. The Nudr servicebased interface may be exhibited by the UDR 546 to allow the UDM 158, PCF 156, and NEF 152 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 158 may exhibit the Nudm servicebased interface.

[0111] An Edge Application Server Discovery Function (EASDF) 161 exhibits an Neasdf servicebased interface, and is connected to the SMF 146 via an N88 interface. One or multiple EASDF instances may be deployed within a PLMN, and interactions between 5GC NF(s) and the EASDF 161 take place within a PLMN. The EASDF 161 includes one or more of the following functionalities: registering to NRF 154 for EASDF 161 discovery and selection; handling the DNS messages according to the instruction from the SMF 146; and / or terminating DNS security, if used. Handling the DNS messages according to the instruction from the SMF 146 includes one or more of the following functionalities: receiving DNS message handling rules and / or BaselineDNSPattem from the SMF 146; exchanging DNS messages from / with the UE 192B; forwarding DNS messages to C-DNS or L-DNS for DNS query; adding EDNS client subnet (ECS) option into DNS query for an FQDN; reporting to the SMF 146 the information related to the received DNS messages; and / or buffering / discarding DNS messages from the UE 192B or DNS Server. The EASDF has direct user plane connectivity (e.g., without any NAT) with the PSA UPF over N6 (interface 182A) for the transmission of DNS signaling exchanged with the UE. The deployment of a NAT between EASDF 161 and PSA UPF 148 may or may not be supported.

[0112] The AF 160 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control. The AF 160 may influence UPF 148 (re)selection and traffic routing. Based on operator deployment, when AF 160 is considered to be a trusted entity, the network operator may permit AF 160 to interact directly with relevant NFs. In some implementations, the AF 160 is used for edge computing implementations.

[0113] An NF that needs to collect data from an AF 160 may subscribe / unsubscribe to notifications regarding data collected from an AF 160, either directly from the AF 160 or via NEF 152. The data collected from an AF 160 is used as input for analytics by the NWDAF 162.

[0114] In some embodiments, the 5GC 140 may enable edge computing by selecting operator / 3rd party services to be geographically close to a point that the UE 192B is attached to the network 190B. This may reduce latency and load on the network 190B. To provide edge-computing implementations, the 5GC 140 may select a UPF 148 close to the UE 192B and execute traffic steering from the UPF 148 to data network (DN) 136 via the N6 interface (interface 182A). This may be based on the UE subscription data, UE location, and information provided by the AF 160. In this way, the AF 160 may influence UPF (rc)sclcction and traffic routing. Based on operator deployment, when AF 160 is considered to be a trusted entity, the network operator may permit AF 160 to interact directly with relevant NFs. Additionally, the AF 160 may exhibit a Naf service-based interface.

[0115] The DN 136 may represent various network operator services. Internet access, or third-party services that may be provided by one or more servers including, for example, an application / content server 138 such as the framework logic circuitry 100 and / or other application / content servers 138. In some embodiments, the DN 136 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services. In this example, the app server 138 can be coupled to an IMS via an S-CSCF or the I-CSCF. In some implementations, the DN 136 may represent one or more local area DNs (EADNs), which are DNs 136 (or DN names (DNNs)) that is / are accessible by a UE 192B in one or more specific areas. Outside of these specific areas, the UE 192B is not able to access the LADN / DN 136.

[0116] Additionally, or alternatively, the DN 136 may be an edge DN 136, which is a (local) DN that supports the architecture for enabling edge applications. In these examples, the app server 138 may represent the physical hardware systems / devices providing app server functionality and / or the application software resident in the cloud or at an edge compute node that performs server function(s). In some examples, the app / content server 138 provides an edge hosting environment that provides support required for Edge Application Server's execution.

[0117] In some embodiments, the 5GS can use one or more edge compute nodes to provide an interface and offload processing of wireless communication traffic. In these examples, the edge compute nodes may be included in, or co-located with one or more RANs 104 or RAN nodes 114. For example, the edge compute nodes can provide a connection between the RAN 104 and UPF 148 in the 5GC 140. The edge compute nodes can use one or more NFV instances instantiated on virtualization infrastructure within the edge compute nodes to process wireless connections to and from the RAN 114 and UPF 148.

[0118] In some implementations, the edge compute nodes provide a distributed computing environment for application and service hosting, and also provide storage and processing resources so that data and / or content can be processed in close proximity to subscribers (e.g., users of UEs 192B) for faster response times. The edge compute nodes also support multitenancy run-time and hosting cnvironmcnt(s) for applications, including virtual appliance applications that may be delivered as packaged virtual machine (VM) images, middleware application and infrastructure services, content delivery services including content caching, mobile big data analytics, and computational offloading, among others. Computational offloading involves offloading computational tasks, workloads, applications, and / or services to the edge compute nodes from the UEs 192B, CN 140, DN 136, and / or server(s) 138, or vice versa. For example, a device application or client application operating in a UE 192B may offload application tasks or workloads to one or more edge compute nodes. In another example, an edge compute node may offload application tasks or workloads to a set of UEs 192B (e.g., for distributed machine learning computation and / or the like).

[0119] The edge compute nodes may include or be part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as an “edge computing framework” or the like). The edge compute nodes may also be referred to as “edge hosts” or “edge servers.” The edge system includes a collection of edge servers and edge management systems (not shown) necessary to run edge computing applications within an operator network or a subset of an operator network. The edge servers are physical computer systems that may include an edge platform and / or virtualization infrastructure, and provide compute, storage, and network resources to edge computing applications. Each of the edge servers are disposed at an edge of a corresponding access network, and are arranged to provide computing resources and / or various services (e.g., computational task and / or workload offloading, cloud-computing capabilities, IT services, and other like resources and / or services as discussed herein) in relatively close proximity to UEs 192B. The VI of the edge compute nodes provide virtualized environments and virtualized resources for the edge hosts, and the edge computing applications may run as VMs and / or application containers on top of the VI.

[0120] In one example implementation, the ECT is and / or operates according to the MEC framework, this example implementation (and / or in any other example implementation discussed herein) may also include NFV and / or other like virtualization technologies. Other virtualization technologies and / or service orchestration and automation platforms may be used.

[0121] In another example implementation, the ECT is and / or operates according to the O RAN framework. Typically, front-end and back-end device vendors and carriers have worked closely to ensure compatibility. The flip-side of such a working model is that it becomes quite difficult to plug-and-play with other devices and this can hamper innovation. To combat this, and to promote openness and inter-operability at every level, several key players interested in the wireless domain (e.g., carriers, device manufacturers, academic institutions, and / or the like) formed the Open RAN alliance (“O-RAN”) in 2018. The O-RAN network architecture is a building block for designing virtualized RAN on programmable hardware with radio access control powered by AI / ML.

[0122] In another example implementation, the ECT is and / or operates according to the 3rd Generation Partnership Project (3GPP) System Aspects Working Group 6 (SA6) Architecture for enabling Edge Applications (referred to as “3GPP edge computing”).

[0123] In another example implementation, the ECT is and / or operates according to the Intel® Smart Edge Open framework (formerly known as OpenNESS).

[0124] In another example implementation, the ECT operates according to the Multi-Access Management Services (MAMS) framework.

[0125] It should be understood that the aforementioned edge computing frameworks / ECTs and services deployment examples are only illustrative examples of ECTs, and that the present disclosure may be applicable to many other or additional edge computing / networking technologies in various combinations and layouts of devices located at the edge of a network including the various edge computing networks / sy stems described herein. Further, the techniques disclosed herein may relate to other loT edge network systems and configurations, and other intermediate processing entities and architectures may also be applicable to the present disclosure. Examples of such edge computing / networking technologies include [MEC]; [O- RAN]; [ISEO]; [SA6Edge]; Content Delivery Networks (CDNs) (also referred to as “Content Distribution Networks” or the like); Mobility Service Provider (MSP) edge computing and / or Mobility as a Service (MaaS) provider systems (e.g., used in AECC architectures); Nebula edgecloud systems; Fog computing systems; Cloudlet edge-cloud systems; Mobile Cloud Computing (MCC) systems; Central Office Re- architected as a Datacenter (CORD), mobile CORD (M- CORD) and / or Converged Multi- Access and Core (COMAC) systems; and / or the like. Further, the techniques disclosed herein may relate to other loT edge network systems and configurations, and other intermediate processing entities and architectures may also be used for purposes of the present disclosure. The interfaces of the 5GC 140 include reference points and service-based interfaces. The reference points include: N1 (between the UE 192B and the AMF 144), N2 (between RAN 114 and AMF 144), N3 (between RAN 114 and UPF 148), N4 (between the SMF 146 and UPF 148), N5 (between PCF 156 and AF 160), N6 (between UPF 148 and DN 136 such as interface 182A), N7 (between SMF 146 and PCF 156), N8 (between UDM 158 and AMF 144), N9 (between two UPFs 148), N10 (between the UDM 158 and the SMF 146), Ni l (between the AMF 144 and the SMF 146), N12 (between AUSF 142 and AMF 144), N13 (between AUSF 142 and UDM 158), N14 (between two AMFs 144; not shown), N15 (between PCF 156 and AMF 144 in case of a non-roaming scenario, or between the PCF 156 in a visited network and AMF 144 in case of a roaming scenario), N16 (between two SMFs 146; not shown), and N22 (between AMF 144 and NSSF 150). Other reference point representations not shown in FIG. 1C can also be used. The service-based representation of FIG. 1C represents NFs within the control plane that enable other authorized NFs to access their services. The service-based interfaces (SBIs) include: Namf (SBI exhibited by AMF 144), Nsmf (SBI exhibited by SMF 146), Nnef (SBI exhibited by NEF 152), Npcf (SBI exhibited by PCF 156), Nudm (SBI exhibited by the UDM 158), Naf (SBI exhibited by AF 160), Nnrf (SBI exhibited by NRF 154), Nnssf (SBI exhibited by NSSF 150), Nausf (SBI exhibited by AUSF 142), Nnwdaf (SBI exhibited by NWDAF 162), and Nardf (SBI exhibited by ARDF). Other service-based interfaces (e.g., Nudr, N5g-eir, and Nudsf) not shown in FIG. 1C can also be used. In some examples, the NEF 152 can provide an interface to edge compute nodes 136x, which can be used to process wireless connections with the RAN 114.

[0126] Although not shown by FIG. 1C, the system 190B may also include NFs that are not shown such as, for example, UDR, Unstructured Data Storage Function (UDSF), Network Slice Admission Control Function (NSACF), Network Slice-specific and Stand-alone Non-Public Network (SNPN) Authentication and Authorization Function (NSSAAF), UE radio Capability Management Function (UCMF), 5G-Equipment Identity Register (5G-EIR), CHarging Function (CHF), Time Sensitive Networking (TSN) AF 160, Time Sensitive Communication and Time Synchronization Function (TSCTSF), Data Collection Coordination Function (DCCF), Analytics Data Repository Function (ADRF), Messaging Framework Adaptor Function (MFAF), Binding Support Function (BSF), Non-Seamless WLAN Offload Function (NSWOF), Service Communication Proxy (SCP), Security Edge Protection Proxy (SEPP), Non-3GPP InterWorking Function (N3IWF), Trusted Non-3GPP Gateway Function (TNGF), Wireline Access Gateway Function (W-AGF), and / or Trusted WLAN Interworking Function (TWIF).

[0127] FIG. 2 illustrates an embodiment of a network 2000 in accordance with various embodiments. The network 2000 may operate in a matter consistent with 3GPP technical specifications or technical reports for 6G systems. In some embodiments, the network 2000 may operate concurrently with network 190B. For example, in some embodiments, the network 2000 may share one or more frequency or bandwidth resources with network 190B. As one specific example, a UE (e.g., UE 2002) may be configured to operate in both network 2000 and network 190B. Such configuration may be based on a UE including circuitry configured for communication with frequency and bandwidth resources of both networks 190B and 2000. In general, several elements of network 2000 may share one or more characteristics with elements of network 190B. For the sake of brevity and clarity, such elements may not be repeated in the description of network 2000.

[0128] The network 2000 may include a UE 2002, which may include any mobile or non-mobile computing device designed to communicate with a RAN 2008 via an over-the-air connection. The UE 2002 may be similar to, for example, UE 192B. The UE 2002 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.

[0129] Although not specifically shown in FIG. 2, in some embodiments the network 2000 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. Similarly, although not specifically shown in FIG. 2A, the UE 2002 may be communicatively coupled with an AP such as AP 106 as described with respect to FIG. IB. Additionally, although not specifically shown in FIG. 2, in some embodiments the RAN 2008 may include one or more ANs such as AN 108 as described with respect to FIG. IB. The RAN 2008 and / or the AN of the RAN 2008 may be referred to as a base station (BS), a RAN node, or using some other term or name.

[0130] The UE 2002 and the RAN 2008 may be configured to communicate via an air interface that may be referred to as a sixth generation (6G) air interface. The 6G air interface may include one or more features such as communication in a terahertz (THz) or sub-THz bandwidth, or joint communication and sensing. As used herein, the term “joint communication and sensing” may refer to a system that allows for wireless communication as well as radar-based sensing via various types of multiplexing. As used herein, THz or sub-THz bandwidths may refer to communication in the 80 GHz and above frequency ranges. Such frequency ranges may additionally or alternatively be referred to as “millimeter wave” or “mmWave” frequency ranges.

[0131] The RAN 2008 may allow for communication between the UE 2002 and a 6G core network (CN) 2010 such as the core network (CN) 120 shown in FIG. IB. Specifically, the RAN 2008 may facilitate the transmission and reception of data between the UE 2002 and the 6G CN 2010. The 6G CN 2010 may include various functions such as NSSF 150, NEF 152, NRF 154, PCF 156, UDM 158, AF 160, SMF 146, and AUSF 142. The 6G CN 2010 may additionally include UPF 148 and DN 136 as shown in FIG. 2A.

[0132] The DN 136 may include application / content servers such as the application / content servers 138 shown in FIG. IB. In many embodiments, a Comm SF 2038 may connect with other Comm SFs 2038 via N9’interfaces, may the UPF 148 via a N19’ interface, and the DN 136 via a N6’ interface. The UPF 148 may connect with other UPFs 148 via a N9 interface and may connect with the DN 136 (such as the framework logic circuitry 100 and / or other application / content servers 138) via a N6 interface (182A).

[0133] Additionally, the RAN 2008 may include various additional functions that are in addition to, or alternative to, functions of a legacy cellular network such as a 4G or 5G network. Two such functions may include a Compute Control Function (Comp CF) 2024 and a Compute Service Function (Comp SF) 2036. The Comp CF 2024 and the Comp SF 2036 may be parts or functions of the Computing Service Plane. Comp CF 2024 may be a control plane function that provides functionalities such as management of the Comp SF 2036, computing task context generation and management (e.g., create, read, modify, delete), interaction with the underlaying computing infrastructure for computing resource management, etc. Comp SF 2036 may be a user plane function that serves as the gateway to interface computing service users (such as UE 2002) and computing nodes behind a Comp SF instance. Some functionalities of the Comp SF 2036 may include: parse computing service data received from users to compute tasks executable by computing nodes; hold service mesh ingress gateway or service API gateway; service and charging policies enforcement; performance monitoring and telemetry collection, etc. In some embodiments, a Comp SF 2036 instance may serve as the user plane gateway for a cluster of computing nodes. A Comp CF 2024 instance may control one or more Comp SF 2036 instances.

[0134] Two other such functions may include a Communication Control Function (Comm CF) 2028 and a Communication Service Function (Comm SF) 2038, which may be parts of the Communication Service Plane. The Comm CF 2028 may be the control plane function for managing the Comm SF 2038, communication sessions creation / configuration / releasing, and managing communication session context. The Comm SF 2038 may be a user plane function for data transport. Comm CF 2028 and Comm SF 2038 may be considered as upgrades of SMF 146 and UPF 148, which were described with respect to a 5G system in FIG. IB. The upgrades provided by the Comm CF 2028 and the Comm SF 2038 may enable service-aware transport. For legacy (e.g., 4G or 5G) data transport, SMF 146 and UPF 148 may still be used.

[0135] Two other such functions may include a Data Control Function (Data CF) 2022 and Data Service Function (Data SF) 2032 may be parts of the Data Service Plane. Data CF 2022 may be a control plane function and provides functionalities such as Data SF 2032 management, Data service creation / configuration / releasing, Data service context management, etc. Data SF 2032 may be a user plane function and serve as the gateway between data service users (such as UE 2002 and the various functions of the 6G CN 2010) and data service endpoints behind the gateway. Specific functionalities may include parse data service user data and forward to corresponding data service endpoints, generate charging data, and report data service status.

[0136] Another such function may be the Service Orchestration and Chaining Function (SOCF) 2020, which may discover, orchestrate and chain up communication / computing / data services provided by functions in the network. Upon receiving service requests from users, SOCF 2020 may interact with one or more of Comp CF 2024, Comm CF 2028, and Data CF 2022 to identify Comp SF 2036, Comm SF 2038, and Data SF 2032 instances, configure service resources, and generate the service chain, which could contain multiple Comp SF 2036, Comm SF 2038, and Data SF 2032 instances and their associated computing endpoints. Workload processing and data movement may then be conducted within the generated service chain. The SOCF 2020 may also be responsible for maintaining, updating, and releasing a created service chain.

[0137] Another such function may be the service registration function (SRF) 2014, which may act as a registry for system services provided in the user plane such as services provided by service endpoints behind Comp SF 2036 and Data SF 2032 gateways and services provided by the UE 2002. The SRF 2014 may be considered a counterpart of NRF 154, which may act as the registry for network functions.

[0138] Other such functions may include an evolved service communication proxy (eSCP) and service infrastructure control function (SICF) 2026, which may provide service communication infrastructure for control plane services and user plane services. The eSCP may be related to the service communication proxy (SCP) of 5G with user plane service communication proxy capabilities being added. The eSCP is therefore expressed in two parts: eCSP-C 2012 and eSCP- U 2034, for control plane service communication proxy and user plane service communication proxy, respectively. The SICF 2026 may control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configurations, performance monitoring, etc.

[0139] Another such function is the AMF 2044. The AMF 2044 may be similar to 144, but with additional functionality. Specifically, the AMF 2044 may include potential functional repartition, such as move the message forwarding functionality from the AMF 2044 to the RAN 2008.

[0140] Another such function is the service orchestration exposure function (SOEF) 2018. The SOEF may be configured to expose service orchestration and chaining services to external users such as applications.

[0141] The UE 2002 may include an additional function that is referred to as a computing client service function (comp CSF) 2004. The comp CSF 2004 may have both the control plane functionalities and user plane functionalities, and may interact with corresponding network side functions such as SOCF 2020, Comp CF 2024, Comp SF 2036, Data CF 2022, and / or Data SF 2032 for service discovery, request / response, compute task workload exchange, etc. The Comp CSF 2004 may also work with network side functions to decide on whether a computing task should be run on the UE 2002, the RAN 2008, and / or an element of the 6G CN 2010.

[0142] The UE 2002 and / or the Comp CSF 2004 may include a service mesh proxy 2006. The service mesh proxy 2006 may act as a proxy for service-to- service communication in the user plane. Capabilities of the service mesh proxy 2006 may include one or more of addressing, security, load balancing, etc.

[0143] FIGs. 3A-B illustrate embodiments for the ML Model Management service, Nadrf MLModelManagement, provided by the ADRF. FIG. 3A provides an embodiment 3000 of a Service Based Interface (SBI) for an ML Model Management service, Nadrf MLModelManagement, provided by the ADRF. FIG. 3B provides an embodiment 3005 of a reference point representation model for the ML Model Management service, Nadrf MLModelManagement, provided by the ADRF.

[0144] The Nadrf_ MLModelManagement service as defined in 3GPP TS 23.288, is provided by the Analytics Data Repository Function (ADRF). This service allows NF consumers to store ML models in the ADRF, allows NF consumers to retrieve ML models from an ADRF, and allows NF consumers to delete ML models from an ADRF.

[0145] The 5G System Architecture is defined in 3GPP TS 23.501. The Network Data Analytics Exposure architecture is defined in 3GPP TS 23.288. The Nadrf_MLModelManagement service is part of the Nadrf service-based interface exhibited by the Analytics Data Repository Function (ADRF). Known consumers of the Nadrf_MLModelManagement service include the NWDAF.

[0146] The Nadrf_MLModelManagement service is provided by the ADRF and consumed by the NF service consumers as shown in FIGs. 3 A and 3B. The ADRF provides the functionality to allow NF consumers to store, retrieve, and remove ML models from the ADRF. The NWDAF supports storing of ML models in the ADRF, supports retrieving of ML models from an ADRF; and supports deletion of ML models from an ADRF. Table 3 describes operations of Operations of the Nadrf_MLModelManagement Service.

[0147] TABLE 3

[0148] FIG. 3C shows an embodiment 3010 of the ML Model Management storage service, Nadrf_MLModelManagement_StorageRequest, operation. In FIG. 3C, the NF service consumer (e.g., NWDAF) sends a request to the ADRF to store ML models. The NF service consumer may invoke the Nadrf_MLModelManagement_StorageRequest service operation to store ML models. The NF service consumer may send an HTTP POST request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records" as Resource URI representing the "ADRF ML Model Store Records" resource, as shown in action 1, to create an "Individual ADRF ML Model Store Record" according to the information in the message body. The NadrfMLModelStoreRecord data structure provided in the request body may include the MLModellnfo data structure in the "mlModellnfo" attribute. The MLModellnfo data structure may include the unique ML model identifier within the "modelUniqueld" attribute, the address of the ML model within the "mlFileAddr" attribute, and the storage size required for each of the ML models in the "mlStorageSize" attribute. Note that the ML Model Management storage service may store one or more ML models based on the action 1.

[0149] Upon the reception of an HTTP POST request with "{apiRoot} / nadrf-mlmodelmanagement / <apiVersion> / mlmodel- store-records" as Resource URI and NadrfMLModelStoreRecord data structure as request body, the ADRF may create a new ML model store record, assign a store transaction ID, storeTransId, and download and store the ML models.

[0150] NOTE 1: If one or more of the ML models are already stored or are being stored in the ADRF, the ADRF may create a new "Individual ADRF ML Model Store Record" resource and assign a new storeTransId if the ADRF intends not to store the ML models in the memory again based on the implementation.

[0151] If the ADRF created an "Individual ADRF ML Model Store Record" resource, the ADRF may respond, in action 2, with "201 Created" with the message body containing a representation of the created ML model record. The ADRF may include the MLModellnfo data structure in the "mlModellnfo" attribute with the unique ML model identifier in the "modelUniqueld" attribute, and the ML model address in "mlFileAddr" attribute and the result (e.g., ML model file stored in ADRF, ML model file address not found, ML file download failed) in the “storeResult" attribute within the HTTP POST response. The ADRF may include a Location HTTP header field. The Location header field shall contain the URI of the created record i.e. "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records / { storeTransId} " .

[0152] If an error occurs when processing the HTTP POST request, the ADRF may send an HTTP error response. FIG. 3D shows an embodiment 3020 of the ML Model Management service retrieval, Nadrf_MLModclManagcmcnt_Rctricval, operation. The

[0153] Nadrf_MLModelManagement_Retrieval service operation is used by an NF service consumer to retrieve stored ML models. In FIG. 3D, the NF service consumer (e.g., NWDAF) sends a request to the ADRF to retrieve stored ML models. The NF service consumer may invoke the Nadrf MLModelManagement Retrieval service operation to retrieve stored ML models. The NF service consumer may send an HTTP GET request with "{apiRoot} / nadrf- mlmodelmanagemen t / <api Ver sion> / mlmodel- store-records" as Resource URI representing the "ADRF ML Model Store Records" resource, as shown in action 1, to request ADRF ML model store records according to the storage transaction identifier within the "store-trans-id" attribute or the unique ML model identifier within the "modelUniqueld" attribute.

[0154] Upon the reception of the HTTP GET request, the ADRF may find the ML models according to the requested parameters. If one or more of the requested ML models are found, the ADRF may respond with a result of a message having a "200 OK" status code and a message body containing the NadrfMLModelStoreRecord data structure. The NadrfMLModelStoreRecord data structure in the response body may include the MLModellnfo data structure in the "mlModellnfo" attribute with the unique ML model identifier in the "modelUniqueld" attribute and the address of the ML model file stored in the ADRF in the "mlFileAddr" attribute.

[0155] If none of the requested ML models exist, the ADRF may respond with a result of a message having a "204 No Content" in action 2. If an error occurs when processing the HTTP GET request, the ADRF may send an HTTP error response.

[0156] FIG. 3E shows an embodiment 3030 of the ML Model Management delete service operation, Nadrf_MLModelManagement_Delete, with a store transaction ID. The Nadrf_MLModelManagement_Delete service operation is used by an NF service consumer (e.g., NWDAF) to delete or request removal of stored ML models. In FIG. 3E, the NF service consumer sends a request to the ADRF to delete stored ML models.

[0157] The NF service consumer may invoke the Nadrf_MLModelManagement_Delete service operation to remove the ML models that are stored in the corresponding storage transaction. The NF service consumer may send an HTTP DELETE request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records / {storeTransId}" as Resource URI representing an "Individual ADRF ML Model Store Record" resource, as shown in action 1 , where "{storcTransId}" is the transaction identifier of the stored record that is to be deleted.

[0158] Upon the reception of an HTTP DELETE request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records / {storeTransId}" as Resource URI, if the ADRF successfully processed and accepted the received HTTP DELETE request, the ADRF may remove the storage transaction corresponding stored ML model record and respond with a result as a message having a HTTP "204 No Content" status code.

[0159] If errors occur when processing the HTTP DELETE request, the ADRF may send an HTTP error response. If the ADRF determines the received HTTP DELETE request needs to be redirected, the ADRF may send an HTTP redirect response.

[0160] FIG. 3F shows an embodiment 3040 of the ML Model Management delete service operation, Nadrf_MLModelManagement_Delete, with a unique ML model ID. In FIG. 3F, the NF service consumer (e.g., NWDAF) sends a request to the ADRF to delete stored ML models based on the unique ML model identifier.

[0161] The NF service consumer may invoke the Nadrf_MLModelManagement_Delete service operation to remove stored ML models based on the unique ML model identifier. The NF service consumer may send an HTTP POST request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / remove-stored-mlmodel" as URI, as shown in action 1. The POST request body may contain a NadrfMLModelStoreRecord data structure. The NadrfMLModelStoreRecord data structure provided in the request body may include the MLModellnfo data structure in the "mlModellnfo" attribute with the unique ML model identifier in the "modelUniqueld" attribute.

[0162] Upon the reception of an HTTP POST request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / remove-stored-mlmodel" as URI, if the ADRF successfully processed and accepted the received HTTP POST request, the ADRF shall respond with a result in a message having a status code of HTTP "204 No Content" status. The ADRF may remove any stored ML model(s) that match the unique ML model identifier received in the request and respond with HTTP "204 No Content200 OK" status with the message body containing the NadrfMLModelStoreRecord data structure. The ADRF may include the MLModellnfo data structure with the unique ML model identifier in the "modelUniqueld" attribute and the result (i.e. ML model deleted, ML model not found, ML model found but not deleted) in the "delResult" attribute. The ADRF may remove any stored ML models that match the unique ML model identifier received in the request. If errors occur when processing the HTTP POST request, the ADRF may send an HTTP error response.

[0163] FIG. 3G shows an embodiment 3050 of the ML Model Management service API, Nadrf_MLModelManagement Service API, resource URI structure. The Nadrf_MLModelManagement service may use the Nadrf_MLModelManagement API.

[0164] The API URI of the Nadrf_MLModelManagement API may be:

[0165] { apiRoo t } / <apiN ame> / <api V ersion>

[0166] The request URIs used in HTTP requests from the NF service consumer towards the NF service producer may have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501, i.e.:

[0167] { apiRoot } / <apiName> / <apiVersion> / <apiSpecificResourceUriPart> with the following components:

[0168] The {apiRoot} shall be set as described in 3GPP TS 29.501.

[0169] The <apiName> shall be "nadrf-mlmodelmanagement".

[0170] The <apiVersion> shall be "vl".

[0171] The <apiSpecificResourceUriPart> shall be set as described in clause 5.2.3 of TS 29.575.

[0172] For usage of HTTP, the HTTP / 2, IETF RFC 7540, may be used as specified in clause 5 of 3GPP TS 29.500. HTTP / 2 may be transported as specified in clause 5.3 of 3GPP TS 29.500.

[0173] The OpenAPI specification of HTTP messages and content bodies for the Nadrf_MLModelManagement API is contained in Annex A of TS 29.575.

[0174] The usage of HTTP standard headers are described in clause 5.2.2 of 3GPP TS 29.500.

[0175] The Content type of HTTP bodies of requests may be JSON, IETF RFC 8259, as specified in clause 5.4 of 3GPP TS 29.500. The use of the JSON format may be signaled by the content type " application / j son" .

[0176] The "Problem Details" JSON object may be used to indicate additional details of the error in a HTTP response body and may be signaled by the content type "application / problem+json", as defined in IETF RFC 7807. Furthermore, the mandatory HTTP custom header fields specified in clause 5.2.3.2 of 3GPP TS 29.500 may be applicable. FIG. 3G depicts the resource URIs structure for the Nadrf_MLModelManagement API.

[0177] Table 4 provides an overview of the resources and applicable HTTP methods.

[0178] TABLE 4

[0179] The ADRF ML Model Store Records resource represents all ML model storage records to the Nadrf_MLModelManagement Service at a given ADRF. The resource allows an NF service consumer to create a new Individual ADRF ML Model Store Record resource and to retrieve Individual ADRF ML Model Store Record resources that fulfil certain criteria.

[0180] The Resource Definition Resource URI may be {apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records. The <apiVersion> may be set as described in clause 5.2.1 of TS 29.275 V18.6.0 (2024-06). This resource may support the resource URI variables defined in Table 5.

[0181] TABLE 5

[0182] The Resource Standard Methods may include POST and GET. The POST method may support the URI query parameters specified in Table 6.

[0183] TABLE 6

[0184] The POST method may support the request data structures specified in Table 7, the response data structures and response codes specified in Table 8, and the headers supported by the 201 response code on this resource in Table 9.

[0185] TABLE 7

[0186] TABLE 8

[0187] TABLE 9

[0188] The GET method may support the URI query parameters specified in Table 10.

[0189] TABLE 10 The GET method may support the request data structures specified in Table 11 and the response data structures and response codes specified in Table 12.

[0190] TABLE 11

[0191] TABLE 12

[0192] In some embodiments, the GET method may not include Resource Custom Operations. For the Resource: Individual ADRF ML Model Store Record, the Individual ADRF ML Model Store Record resource represents ML models stored via the Nadrf_MLModelManagement_StorageRequest in ADRF. The resource is defined as Resource URI: { apiRoot } / nadrf-mlmodelmanagement / <api V ersion> / mlmodel- s tore- records / { storeTransId}

[0193] The <apiVersion> shall be set as described in clause 5.2.1 of TS 29.575.

[0194] This resource shall support the resource URI variables defined in table 13.

[0195] TABLE 13

[0196] The Resource Standard Method of DELETE may support the URI query parameters specified in Table 14.

[0197] TABLE 14

[0198] The DELETE method may support the request data structures specified in Table 15 and the response data structures and response codes specified Table 16. The headers supported for 307 response code, that the ADRF may include in a response to the DELETE method, are shown in Table 17 and the headers supported for the 308 response code, that the ADRF may include in a response to the DELETE method, are shown in Table 18.

[0199] TABLE 15

[0200] TABLE 16

[0201] TABLE 17

[0202] TABLE 18

[0203] In some embodiments, the DELETE method may not include Resource Custom Operations.

[0204] FIG. 3H shows an embodiment 3055 of custom operations without associated resources.

[0205] The structure of the custom operation URIs of the Nadrf_MLModelManagement service is shown in FIG. 3H.

[0206] Table 19 provides an overview of the custom operations and applicable HTTP methods.

[0207] TABLE 19

[0208] The operation to remove or delete a stored ML model, remove-stored-mlmodel, is used by the NF service consumer (e.g., NWDAF) to request the ADRF to remove stored ML models based on a unique ML model identifier. This operation shall support the request data structures shown in Table 20 and the response data structures and error codes specified in Tables 21.

[0209] TABLE 20

[0210] TABLE 21

[0211] In some embodiments, notifications are not available.

[0212] The application data model supported by the Nadrf_MLModelManagement API may include different data types. Table 22 specifies the data types defined for the Nadrf_MLModelManagement service based interface protocol.

[0213] TABLE 22

[0214] Table 23 specifies data types re-used by the Nadrf_MLModelManagement service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the

[0215] Nadrf_MLModclManagcmcnt service based interface.

[0216] TABLE 23 Structured data types may include data structures used in resource representations. The structured data types may include NadrfMLModelStoreRecord and MLModellnfo. The Table 24 may describe the data structure for the NadrfMLModelStoreRecord data type.

[0217] TABLE 24

[0218] The Table 25 may describe the data structure for the MLModellnfo data type.

[0219] TABLE 25

[0220] The results of operations to store or update a ML model may be listed in Table 26 and the results of operations to delete a ML model may be listed in Table 27.

[0221] TABLE 26

[0222] TABLE 27

[0223] For the Nadrf_MLModelManagement API, HTTP error responses shall be supported as specified in clause 4.8 of 3GPP TS 29.501. Protocol errors and application errors specified in table 5.1 .7.2-1 of 3GPP TS 29.500 [4] shall be supported for an HTTP method if the corresponding HTTP status codes arc specified as mandatory for that HTTP method in table 5.1.7.1-1 of 3GPP TS 29.500.

[0224] In addition, the Nadrf_MLModelManagement API.

[0225] The application errors defined for the Nadrf_MLModelManagement service may include application errors in some embodiments. Furthermore, the Nadrf_MLModelManagement API may include optional features in some embodiments. These features may be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500.

[0226] As indicated in 3GPP TS 33.501 and 3GPP TS 29.500, the access to the Nadrf_MLModelManagement API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749), based on local configuration, using the "Client Credentials" authorization grant, where the NRF (see 3GPP TS 29.510) plays the role of the authorization server.

[0227] As indicated in 3GPP TS 33.501 and 3GPP TS 29.500, the access to the Nadrf_MLModelManagement API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749), based on local configuration, using the "Client Credentials" authorization grant, where the NRF (see 3GPP TS 29.510) plays the role of the authorization server. If OAuth2 is used, an NF Service Consumer (e.g., NWDAF), prior to consuming services offered by the Nadrf_MLModelManagement API, may obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in 3GPP TS 29.510, clause 5.4.2.2.

[0228] NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF that the NF Service Consumer used for discovering the Nadrf_MLModelManagement service.

[0229] The Nnwdaf_MLModelManagement API defines a single scope "nnwdaf- mlmodelmanagement" for the entire service, and it does not define any additional scopes at resource or operation level.

[0230] In many embodiments, the Nadrf_MLModelManagement API may include the following code: openapi: 3.0.0 info: version: 1.0.0-alpha.l title: Nadrf_ description:

[0231] ADRF ML Model Management Service. © 2023, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).

[0232] All rights reserved. extemalDocs: description: 3GPP TS 29.575 V18.2.0; 5G System; Analytics Data Repository Services; Stage 3. url: 'https: / / www.3gpp.org / ftp / Specs / archive / 29_series / 29.575 / '

[0233] # servers:

[0234] - url: '{apiRoot} / nadrf-mlmodelmanagement / vl' variables: apiRoot: default: https: / / example.com description: apiRoot as defined in clause 4.4 of 3GPP TS 29.501.

[0235] # security:

[0236] - { }

[0237] - oAuth2ClientCredentials:

[0238] - nadrf-mlmodelmanagement

[0239] # paths:

[0240] / mlmodel-store-records : post: summary: Creates a new Individual ADRF ML Model Store Record resource. operationld: CreateADRFMLModelStoreRecord tags:

[0241] - ADRF ML Model Store Records (Collection) requestBody: content: application / json: schema:

[0242] $ref: '# / components / schemas / NadrfMLModelStoreRecord' required: true description: ADRF ML model store record to be stored. responses:

[0243] '201': description: Successful creation of new Individual ADRF ML Model Store Record resource. headers:

[0244] Location: description: >

[0245] Contains the URI of the newly created resource, according to the structure

[0246] {apiRoot} / nadrf-mlmodelmanagement / <apiVersion> / mlmodel-store- records / { storeTransId} required: true schema: type: string content: application / json: schema:

[0247] $ref: '# / components / schemas / NadrfMLModelStoreRecord'

[0248] '400':

[0249] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 400'

[0250] '401':

[0251] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 401'

[0252] '403':

[0253] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 403'

[0254] '404':

[0255] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 404'

[0256] '411':

[0257] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 411'

[0258] '413':

[0259] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 413'

[0260] '415':

[0261] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 415'

[0262] '429':

[0263] $ref: 'TS29571_CommonData.yaml# / components / responses / 429'

[0264] '500':

[0265] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 500'

[0266] '502':

[0267] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 502'

[0268] '503':

[0269] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 503' default:

[0270] $ref: 'TS29571_CommonData.yaml# / components / responses / default' get: summary: Retrieves existing Individual ADRF ML Model Store Record. operationld: GetAdrfMLModelStoreRecord tags:

[0271] - ADRF ML Model Store Records (Collection) parameters:

[0272] - name: store-trans-id description: A storage transaction identifier of a ML model store record in ADRF. in: query required: false schema: type: string

[0273] - name: modelUniqueld description: Unique Model identifier of a ML model. in: query required: false schema: type: array items:

[0274] $ref: 'TS29571_CommonData.yaml# / components / schemas / Uinteger' minltems: 1 responses:

[0275] '200': description: ML model store records are returned. content: application / json: schema:

[0276] $ref: '# / components / schemas / NadrfMLModelStoreRecord'

[0277] '204’: description: No matching ADRF ML Model were found.

[0278] '400':

[0279] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 400'

[0280] '401':

[0281] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 401'

[0282] '403':

[0283] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 403'

[0284] '404':

[0285] $ref: 'TS29571_CommonData.yaml# / components / responses / 404'

[0286] '406':

[0287] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 406'

[0288] '429':

[0289] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 429'

[0290] '500':

[0291] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 500'

[0292] '502':

[0293] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 502'

[0294] '503':

[0295] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 503' default:

[0296] $ref: 'TS29571_CommonData.yaml# / components / responses / default'

[0297] / mlmodel-store-records / { storeTransId} : delete: summary: Delete an existing Individual ADRF ML Model Store Record. operationld: DeleteADRFMLModelStoreRecord tags:

[0298] - Individual ADRF ML Model Store Record (Document) parameters:

[0299] - name: storeTransId in: path description: String identifying a ML Model Store Record in ADRF. required: true schema: type: string responses: '204': description: >

[0300] No Content. The Individual ADRF ML Model Store Record resource matching the storeTransId was deleted.

[0301] '307':

[0302] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 307'

[0303] '308':

[0304] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 308'

[0305] '400':

[0306] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 400'

[0307] '401':

[0308] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 401'

[0309] '403':

[0310] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 403'

[0311] '404':

[0312] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 404'

[0313] '429':

[0314] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 429'

[0315] '500':

[0316] $ref: 'TS29571_CommonData.yaml# / components / responses / 500'

[0317] '502':

[0318] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 502'

[0319] '503':

[0320] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 503' default:

[0321] $ref: 'TS29571_CommonData.yaml# / components / responses / default'

[0322] / remove-stored-mlmodel: post: summary: Remove stored ML model based on unique ML model identifier. operationld: DeleteADRFMLModel tags:

[0323] - ADRF Stored ML Model requestBody: content: application / json: schema: type: array items:

[0324] $ref: '# / components / schemas / NadrfMLModelStoreRecord' minltems: 1 required: true responses:

[0325] '200': description: The ADRF ML model matching the provided unique ML model identifier was deleted. The result is returned. content: application / json: schema:

[0326] $ref: '# / components / schemas / NadrfMLModelStoreRecord'

[0327] '400':

[0328] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 400'

[0329] '401':

[0330] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 401'

[0331] '403':

[0332] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 403'

[0333] '404':

[0334] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 404'

[0335] '411':

[0336] $ref: 'TS29571_CommonData.yaml# / components / responses / 411'

[0337] '413':

[0338] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 413'

[0339] '415':

[0340] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 415'

[0341] '429':

[0342] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 429'

[0343] '500':

[0344] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 500'

[0345] '502':

[0346] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 502'

[0347] '503':

[0348] $ref: 'TS2957 l_CommonData.yaml# / components / responses / 503' default:

[0349] $ref: 'TS29571_CommonData.yaml# / components / responses / default'

[0350] # components: security Schemes: o Auth2ClientCredentials : type: oauth2 flows: clientCredentials : tokenUrl : ' { nrf ApiRoot } / oauth2 / token' scopes: nadrf-mlmodelmanagement: Access to the nadrf-mlmodelmanagement API

[0351] # schemas:

[0352] #

[0353] N adrfMLModelS toreRecord : description: Represents an Individual ADRF ML Model Store Record. type: object allOf:

[0354] - oneOf:

[0355] - required: [nflnstanceld] - required: [nfSetld]

[0356] - required: [mlModelldnfo] properties: nflnstanceld:

[0357] $ref: 'TS29571_CommonData.yaml# / components / schemas / NfInstanceId' nfSetld:

[0358] $ref: 'TS2957 l_CommonData.yaml# / components / schemas / NfSetId' mlModellnfo: type: array items:

[0359] $ref: '# / components / schemas / MLModelInfo' minltems: 1 description: List of ML Model Information. suppFeat:

[0360] $ref: 'TS29571_CommonData.yaml# / components / schemas / SupportedFeatures'

[0361] #

[0362] MLModellnfo: description: Represents information! of the ML Model. type: object allOf:

[0363] - required: [modelUniqueld]

[0364] - required: [mlFileAddr]

[0365] - required: [mlStrorageSize] properties: modelUniqueld:

[0366] $ref: 'TS2957 l_CommonData.yaml# / components / schemas / Uinteger' mlModelAddr:

[0367] $ref: 'TS29520_Nnwdaf_MLModelProvision.yaml# / components / schemas / MLModelAddr' mlStforageSize:

[0368] $ref: 'TS2957 l_CommonData.yaml# / components / schemas / Uinteger' storeResult:

[0369] $ref: '# / components / schemas / StoreResulf delResult:

[0370] $ref: '# / components / schemas / DeleteResult'

[0371] FIG. 31 shows an embodiment of a neural network 3060 (an example of an AI / ML model). Machine learning (ML) involves programming computing systems to optimize a performance criterion using example (training) data and / or past experience such as training 132A shown in FIG. 1A. ML refers to the use and development of computer systems that are able to learn and adapt without following explicit instructions, by using algorithms and / or statistical models to analyze and draw inferences from patterns in data. ML involves using algorithms to perform specific task(s) without using explicit instructions to perform the specific task(s), but instead relying on learnt patterns and / or inferences. ML uses statistics to build mathematical model(s) such as ML model 131A shown in FIG. 1A (also referred to as “ML models” or simply “models”) in order to make predictions or decisions based on sample data (e.g., training data). The model is defined to have a set of parameters, and learning is the execution of a computer program to optimize the parameters of the model using the training data or past experience. The trained model may be a predictive model that makes predictions based on an input dataset, a descriptive model that gains knowledge from an input dataset, or both predictive and descriptive. Once the model is learned (trained), it can be used to make inferences (e.g., predictions).

[0372] Some implementations of Al and ML use data and neural networks (NNs) such as the NN 3060 in a way that mimics the working of a biological brain. The NN 3060, which may be suitable for use by one or more of the computing systems (or subsystems) of the various implementations discussed herein, implemented in part by a HW accelerator, and / or the like. The NN 3060 may be deep neural network (DNN) used as an artificial brain of a compute node or network of compute nodes to handle very large and complicated observation spaces. Additionally or alternatively, the NN 3060 can be some other type of topology (or combination of topologies), such as a convolution NN (CNN), deep CNN (DCN), recurrent NN (RNN), Long Short Term Memory (LSTM) network, a Deconvolutional NN (DNN), gated recurrent unit (GRU), deep belief NN, a feed forward NN (FFN), a deep FNN (DFF), deep stacking network, Markov chain, perception NN, stochastic NN, Bayesian Network (BN) or Bayesian NN (BNN), Dynamic BN (DBN), Linear Dynamical System (LDS), Switching LDS (SLDS), Optical NNs (ONNs), an NN for reinforcement learning (RL) and / or deep RL (DRL), and / or the like. NNs are usually used for supervised learning, but can be used for unsupervised learning and / or RL.

[0373] The NN 3060 may encompass a variety of ML techniques where a collection of connected artificial neurons 3061, 3064, 3067, 3070 and 3074 that (loosely) model neurons in a biological brain that transmit signals to other neurons / nodes 3061, 3064, 3067, 3070 and 3074. The neurons 3061, 3064, 3067, 3070 and 3074 may also be referred to as nodes, processing elements (PEs), or the like. The connections 3062, 3066, 3068, and 3072 (or edges) between the neurons 3061, 3064, 3067, 3070 and 3074 are (loosely) modeled on synapses of a biological brain and convey the signals between no neurons 3061, 3064, 3067, 3070 and 3074. Note that not all neurons 3061, 3064, 3067, 3070 and 3074 and connections 3062, 3066, 3068 are labeled for the sake of clarity. Each connection 3062, 3066, and 3068 has one or more inputs and produces an output, which can be sent to one or more other connections 3062, 3066, and 3068 (the inputs and outputs may be referred to as “signals”). Inputs to the neurons 3061 of the input layer L_x can be feature values of a sample of external data (e.g., input variables x_i). The input variables x_i can be set as a vector containing relevant data (e.g., observations, ML features, and the like). The inputs to hidden units, neurons 3064, 3067, and 3070, of the hidden layers L_a, L_b, and L_c, respectively, may be based on the outputs of other neurons. The outputs of the final output neurons 3074 of the output layer L_y (e.g., output variables yj) include predictions, inferences, and / or accomplish a desired / configured task. The output variables yj may be in the form of determinations, inferences, predictions, and / or assessments. Additionally, or alternatively, the output variables yj can be set as a vector containing the relevant data (e.g., determinations, inferences, predictions, assessments, and / or the like).

[0374] In the context of ML, an “ML feature” (or simply “feature”) is an individual measurable property or characteristic of a phenomenon being observed. Features are usually represented using numbers / numerals (e.g., integers), strings, variables, ordinals, real-values, categories, and / or the like. Additionally, or alternatively, ML features are individual variables, which may be independent variables, based on observable phenomenon that can be quantified and recorded. ML models use one or more features to make predictions or inferences. In some implementations, new features can be derived from old features.

[0375] Neurons 3061, 3064, 3067, 3070 and 3074 may have a threshold such that a signal is sent only if the aggregate signal crosses that threshold. A neuron 3061, 3064, 3067, 3070 and 3074 may include an activation function (a), which defines the output of that neuron 3061, 3064, 3067, 3070 and 3074 given an input or set of inputs. Additionally, or alternatively, a neuron 3061, 3064, 3067, 3070 and 3074 may include a propagation function that computes the input to a neuron 3061, 3064, 3067, 3070 and 3074 from the outputs of its predecessor neurons 3061, 3064, 3067, 3070 and 3074 and their connections 3062, 3066, and 3068 as a weighted sum. A bias term can also be added to the result of the propagation function.

[0376] The NN 3060 also includes connections 3062, 3066, and 3068, some of which provide the output of at least one neuron 3061, 3064, 3067, 3070 and 3074 as an input to at least another neuron 3061, 3064, 3067, 3070 and 3074. Each connection 3062, 3066, and 3068 may be assigned a weight that represents its relative importance. The weights may also be adjusted as learning proceeds. The weight increases or decreases the strength of the signal at a connection 3062, 3066, and 3068.

[0377] The neurons 3061, 3064, 3067, 3070 and 3074 can be aggregated or grouped into one or more layers L where different layers L may perform different transformations on their inputs. In the present embodiment, the NN 3060 comprises an input layer L_x, one or more hidden layers L_a, L_b, and L_c, and an output layer L_y (where a, b, c, x, and y may be numbers), where each layer L comprises one or more neurons 3061, 3064, 3067, 3070 and 3074. Signals travel from the first layer (e.g., the input layer L_l), to the last layer (e.g., the output layer L_y), possibly after traversing the hidden layers L_a, L_b, and L_c multiple times. In the present embodiment, the input layer L_a receives data of input variables x_i (where i = 1 , ... ,p, where p is a number). Hidden layers L_a, L_b, and L_c processes the inputs x_i, and eventually, output layer L_y provides output variables yj (where j= 1,..., p', where p' is a number that is the same or different than p). In the present embodiment, for simplicity of illustration, there are only three hidden layers L_a, L_b, and L_c in the NN 3060, however, the NN 3060 may include many more (or fewer) hidden layers L_a, L_b, and L_c than are shown.

[0378] FIG. 4 illustrates an embodiment of a simplified block diagram of artificial (Al)-assisted communication between a UE 4005 and a RAN 4010, such as UE 190B and RAN 104 shown in FIG. IB, in accordance with various embodiments. More specifically, as described in further detail below, Al / machine learning (ML) models may be used or leveraged to facilitate over-the- air communication between UE 4005 and RAN 4010.

[0379] One or both of the UE 4005 and the RAN 4010 may operate in a matter consistent with 3GPP technical specifications or technical reports for 6G systems. In some embodiments, the wireless cellular communication between the UE 4005 and the RAN 4010 may be part of, or operate concurrently with, networks 2000 shown in FIG. 2, 190B shown in FIG. IB, and / or some other network described herein.

[0380] The UE 4005 may be similar to, and share one or more features with, UE 2002 shown in FIG. 2, UE 192B shown in FIG. IB, and / or some other UE described herein. The UE 4005 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc. The RAN 4010 may be similar to, and share one or more features with, RAN 114, RAN 2008, and / or some other RAN described herein.

[0381] As may be seen in FIG. 4, the Al-related elements of UE 4005 may be similar to the AI- related elements of RAN 4010. For the sake of discussion herein, description of the various elements will be provided from the point of view of the UE 4005, however it will be understood that such discussion or description will apply to equally named / numbered elements of RAN 4010, unless explicitly stated otherwise.

[0382] As previously noted, the UE 4005 may include various elements or functions that are related to AI / ML. Such elements may be implemented as hardware, software, firmware, and / or some combination thereof. In embodiments, one or more of the elements may be implemented as part of the same hardware (e.g., chip or multi-processor chip), software (e.g., a computing program), or firmware as another element.

[0383] One such element may be a data repository 4015. The data repository 4015 may be responsible for data collection and storage. Specifically, the data repository 4015 may collect and store RAN configuration parameters, measurement data, performance key performance indicators (KPIs), model performance metrics, etc., for model training, update, and inference. More generally, collected data is stored into the repository. Stored data can be discovered and extracted by other elements from the data repository 4015. For example, as may be seen, the inference data selection / filter element 4050 may retrieve data from the data repository 4015. In various embodiments, the UE 4005 may be configured to discover and request data from the data repository 4010 in the RAN, and vice versa. More generally, the data repository 4015 of the UE 4005 may be communicatively coupled with the data repository 4015 of the RAN 4010 such that the respective data repositories of the UE and the RAN may share collected data with one another.

[0384] Another such element may be a training data selection / filtering functional block 4020. The training data selection / filter functional block 4020 may be configured to generate training, validation, and testing datasets for model training. Training data may be extracted from the data repository 4015. Data may be selected / filtered based on the specific AI / ML model to be trained. Data may optionally be transformed / augmented / pre-processed (e.g., normalized) before being loaded into datasets. The training data selection / filter functional block 4020 may label data in datasets for supervised learning. The produced datasets may then be fed into model training the model training functional block 4025.

[0385] As noted above, another such element may be the model training functional block 4025. This functional block may be responsible for training and updating(re-training) AI / ML models. The selected model may be trained using the fed-in datasets (including training, validation, testing) from the training data selection / filtering functional block. The model training functional block 4025 may produce trained and tested AI / ML models which are ready for deployment. The produced trained and tested models can be stored in a model repository 4035.

[0386] The model repository 4035 may be responsible for AI / ML models’ (both trained and untrained) storage and exposure. Trained / updated model(s) may be stored into the model repository 4035. Model and model parameters may be discovered and requested by other functional blocks (e.g., the training data selection / filter functional block 4020 and / or the model training functional block 4025). In some embodiments, the UE 4005 may discover and request AI / ML models from the model repository 4035 of the RAN 4010. Similarly, the RAN 4010 may be able to discover and / or request AI / ML models from the model repository 4035 of the UE 4005. In some embodiments, the RAN 4010 may configure models and / or model parameters in the model repository 4035 of the UE 4005. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may create models, configure models, configure model parameters, configure training data selection / filtering functional block 4020, configure data repository 4015 for data collection, and / or the like for the UE 4005 and / or the RAN 4010.

[0387] Another such element may be a model management functional block 4040. The model management functional block 4040 may be responsible for management of the AI / ML model produced by the model training functional block 4025. Such management functions may include deployment of a trained model, monitoring model performance, etc. In model deployment, the model management functional block 4040 may allocate and schedule hardware and / or software resources for inference, based on received trained and tested models. As used herein, “inference” refers to the process of using trained AI / ML model(s) to generate data analytics, actions, policies, etc. based on input inference data. In performance monitoring, based on wireless performance KPIs and model performance metrics, the model management functional block 4040 may decide to terminate the running model, start model re-training, select another model, etc. In embodiments, the model management functional block 4040 of the RAN 4010 may be able to configure model management policies in the UE 4005 as shown. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure model management functional block 4040.

[0388] Another such element may be an inference data selection / filtering functional block 4050. The inference data selection / filter functional block 4050 may be responsible for generating datasets for model inference at the inference functional block 4045, as described below. Specifically, inference data may be extracted from the data repository 4015. The inference data selection / filter functional block 4050 may select and / or filter the data based on the deployed AI / ML model. Data may be transformed / augmented / pre-processed following the same transformation / augmentation / pre-processing as those in training data selection / filtering as described with respect to functional block 4020. The produced inference dataset may be fed into the inference functional block 4045. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure the inference data selection / filtering functional block 4050.

[0389] Another such element may be the inference functional block 4045. The inference functional block 4045 may be responsible for executing inference as described above. Specifically, the inference functional block 4045 may consume the inference dataset provided by the inference data selection / filtering functional block 4050 and generate one or more outcomes. Such outcomes may be or include data analytics, actions, policies, etc. The outcome(s) may be provided to the performance measurement functional block 4030. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure the inference functional block 4045.

[0390] The performance measurement functional block 4030 may be configured to measure model performance metrics (e.g., accuracy, model bias, run-time latency, etc.) of deployed and executing models based on the inference outcome(s) for monitoring purpose. Model performance data may be stored in the data repository 4015. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure the performance measurement functional block 4030.

[0391] FIG. 5 is an embodiment of a simplified block diagram 500 of a base station 501 and a user equipment (UE) 511 that may carry out certain embodiments in a communication network such as the base stations or RANs, the UEs, and communication networks shown in FIGs. 1-4. For the base station 510, the antenna 546 transmits and receives radio signals. The RF circuitry 544 coupled with the antenna 546, which is the physical layer of the base station 510, receives RF signals from the antenna 546 and performs operations on the signals such as amplifying signals, and splitting the signals into quadrature phase and in-phase signals. The receiver circuitry 590 may convert the signals to digital baseband signals, or uplink data, and pass the digital in-phase and quadrature phase signals to the processor 520 of the baseband circuitry 514, also referred to as the processing circuitry or baseband processing circuitry, via an interface 525 (e.g., RF interface 1416 shown in FIG. 14) of the baseband circuitry 514 for communications such as an interface for network communications with UEs, an interface for network communications with a core cellular network such as a 5G core, an interface for network communications with other base stations, or an interface for other related network communications. In other embodiments, analog to digital converters of the processor 520 may convert the in-phase and quadrature phase signals to digital baseband signals.

[0392] The transmitter circuitry 592 may convert received, digital baseband signals, or downlink data, from the processor 520 to analog signals. The RF circuitry 544 processes and amplifies the analog signals and converts the analog signals to RF signals and passes the amplified, analog RF signals out to antenna 546.

[0393] The processor 520 decodes and processes the digital baseband signals, or uplink data, and invokes different functional modules to perform features in the base station 510. The memory 522 stores program instructions or code and data 524 to control the operations of the base station 510. The host circuitry 512 may execute code such as RRC layer code from the code and data 524 to implement RRC layer functionality and code. Note that code executed above the medium access control (MAC) layer and physical layer (PHY) is often referred to as higher layer code.

[0394] A similar configuration exists in UE 560 where the antenna 596 transmits and receives RF signals. The RF circuitry 594, coupled with the antenna 596, receives RF signals from the antenna 596, amplifies the RF signals, and processes the signals to generate analog in-phase and quadrature phase signals. The receiver circuitry 590 processes and converts the analog in-phase and quadrature phase signals to digital baseband signals via an analog to digital converter, or downlink data, and passes the in-phase and quadrature phase signals to processor 570 of the baseband circuitry 564 via an interface 575 (e.g., RF interface 1416 shown in FIG. 14) of the baseband circuitry 564 for communications such as an interface for network communications with other UEs, an interface for network communications with base stations, or an interface for other related network communications. In other embodiments, the processor 570 may comprise analog to digital converters to convert the analog in-phase and quadrature phase signals to digital in-phase and quadrature phase signals.

[0395] The transmitter circuitry 592 may convert received, digital baseband signals, or downlink data, from the processor 570 to analog signals. The RF circuitry 594 processes and amplifies the analog signals and converts the analog signals to RF signals and passes the amplified, analog RF signals out to antenna 596.

[0396] The RF circuitry 594 illustrates multiple RF chains. While the RF circuitry 594 illustrates four RF chains, each UE may have a different number of RF chains such as 8 RF chains and each of the RF chains in the illustration may represent multiple, time domain, receive (RX) chains and transmit (TX) chains. The RX chains and TX chains include circuitry that may operate on or modify the time domain signals transmitted through the time domain chains such as circuitry to insert guard intervals in the TX chains and circuitry to remove guard intervals in the RX chains. For instance, the RF circuitry 594 may include transmitter circuitry and receiver circuitry, which is often called transceiver circuitry. The transmitter circuitry may prepare digital data from the processor 570 for transmission through the antenna 596. In preparation for transmission, the transmitter may encode the data, and modulate the encoded data, and form the modulated, encoded data into Orthogonal Frequency Division Multiplex (OFDM) and / or Orthogonal Frequency Division Multiple Access (OFDM A) symbols. Thereafter, the transmitter may convert the symbols from the frequency domain into the time domain for input into the TX chains. The TX chains may include a chain per subcarrier of the bandwidth of the RF chain and may operate on the time domain signals in the TX chains to prepare them for transmission on the component subcarrier of the RF chain. For wide bandwidth communications, more than one of the RF chains may process the symbols representing the data from the baseband processor(s) simultaneously.

[0397] The processor 570 decodes and processes the digital baseband signals, or downlink data, and invokes different functional modules to perform features in the UE 560. The memory 572 stores program instructions or code and data 574 to control the operations of the UE 560. The processor 570 may also execute medium access control (MAC) layer code of the code and data 574 for the UE 560. For instance, the MAC layer code may execute on the processor 570 to cause UL communications to transmit to the base station 510 via one or more of the RF chains of the physical layer (PHY). The PHY is the RF circuitry 594 and associated logic such as some or all the functional modules.

[0398] The host circuitry 562 may execute code such as RRC layer code to implement RRC layer functionality and code. In some embodiments, the RRC layer code may be the higher layer code that provides configuration information to the precoder logic circuitry 535 and 580 of the base station 510 and the UE 560, respectively. The configuration information provided by the higher layer may comprise parameters such as the transmission mode (txConfig), PUSCH configuration (puschconfig), dmrs-Type, maxEength, and the number of codewords. In some embodiments, the number of codewords is provided by the logic circuitry 535 of the base station 510 in a DCI preceding transmission of the DM-RS to the logic circuitry 580 of the UE 560.

[0399] The base station 510 and the UE 560 may include several functional modules and circuits to carry out some embodiments. The different functional modules may include circuits or circuitry that code, hardware, or any combination thereof, can configure and implement. Each functional module that can implement functionality as code and processing circuitry or as circuitry configured to perform functionality, may also be referred to as a functional block. For example, the processor 520 (e.g., via executing program code 524) is a functional block to configure and implement the circuitry of the functional modules to allow the base station 510 to schedule (via scheduler 526), encode or decode (via codec 528), modulate or demodulate (via modulator 530), and transmit data to or receive data from the UE 560 via the RF circuitry 544 and the antenna 546.

[0400] The processor 570 (e.g., via executing program code in the code and data 574) may be a functional block to configure and implement the circuitry of the functional modules to allow the UE 560 to receive or transmit, de-modulate or modulate (via de-modulator 578), and decode or encode (via codec 576) data accordingly via the RF circuitry 594 and the antenna 596.

[0401] FIG. 6 depicts a flowchart 6000 of an embodiment to manage shared machine learning (ML) models such as the embodiments described in conjunction with FIGs. 1-5. The flowchart 6000 begins with processing circuitry of a core network of a cellular network receiving a management request initiated by consumer via an interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF) (clement 6005). In some embodiments, receipt of the management request via the ML Model Management service may include receiving a message from the NWDAF to store the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) POST request with a Resource Uniform Resource Identifier (URI) for the first ML model to create a record based on information in a message body of the message. In some embodiments, receipt of the management request via the ML Model Management service may include receiving a message from the NWDAF to retrieve the first ML model, the message comprising a HTTP GET request with a Resource URI representing a store record resource for the first ML model, to request the store record resource for the first ML model based on a storage transaction identifier or a unique ML model identifier. In some embodiments, receipt of the management request via the ML Model Management service may include receiving a message from the NWDAF to delete the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) DELETE request with a Resource Uniform Resource Identifier (URI) representing a store record resource, wherein the Resource URI includes a transaction identifier of a stored record for the first ML model that is to be deleted.

[0402] After receiving the management request, the processing circuitry may process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network (element 6010). Processing the management request may download the first ML model for storage of the first ML model or finding the first ML model to update the model. For management requests to retrieve or delete the first ML model, processing may involve finding the first ML model and either retrieving or deleting the model.

[0403] After processing the management request, the processing circuitry may pass a result to the NWDAF (element 6015). In some embodiments, the result includes an attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to the management request to store the first ML model. In some embodiments, the result includes a first status code with a message body containing a data structure for the first ML model in response to the management request to retrieve the first ML model. In some embodiments, the result includes a second status code in response to a management request to delete the first ML model. FIG. 7 depicts a flowchart 7000 of an embodiment for a framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A and the embodiments described in conjunction with FIGs. 1-5. The framework logic circuitry may include multiple stages of operation that may be performed in order or any one or more of the stages may be performed as needed. The flowchart 7000 begins with processing circuitry of a core network receiving a management request initiated by consumer via an interface, at a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF) (element 7005).

[0404] After processing the management request, the processing circuitry may communicating, after receipt of the management request, a message to store, retrieve, or delete the first ML model in a ML Model Management service of an Analytic Data Repository Function (ADRF) (element 7010). In some embodiments, the message from the NWDAF to store the first ML model may include a Hypertext Transfer Protocol (HTTP) POST request with "{apiRootj / nadrf- mlmodelmanagement / <apiVersion> / mlmodel- store-records" as a Resource Uniform Resource Identifier (URI) representing a "ADRF ML Model Store Records" resource to create an "Individual ADRF ML Model Store Record" according to information in a message body of the message. In some embodiments, the message to store the first ML model further includes a NadrfMLModelStoreRecord data structure, including a MLModellnfo data structure in an "mlModellnfo" attribute of the message, wherein the MLModellnfo data structure includes a unique ML model identifier within a "modelUniqueld" attribute, an address of the first ML model within a "mlFileAddr " attribute, and a storage size required for the first ML model in a mlStorageSize" attribute.

[0405] In some embodiments, the message from the NWDAF to store the first ML model may include a HTTP GET request with "{apiRootj / nadrf- mlmodelmanagement / <apiVersion> / mlmodel- store-records" as a Resource Uniform Resource Identifier (URI) representing a "ADRF ML Model Store Records" resource, to request ADRF ML model store records for the first ML model according to a storage transaction identifier within a "storetrans-id" attribute or a unique ML model identifier within a "modelUniqueld" attribute. In some embodiments, the message from the NWDAF to store the first ML model may include a HTTP DELETE request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records / {storeTransId}" as a Resource Uniform Resource Identifier (URI) representing an "Individual ADRF ML Model Store Record" resource, where "{storeTransId}" is a transaction identifier of a stored record that is to be deleted.

[0406] After communicating the management request, the processing circuitry may receive a result from the ADRF (element 7015). In some embodiments, the result includes a “storeResult” attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to a management request to store the first ML model. In some embodiments, the result includes a status code with a message body containing a NadrfMLModelStoreRecord data structure for the first ML model in response to a management request to retrieve the first ML model. In some embodiments, the result includes a status code in response to a management request to delete the first ML model.

[0407] FIG. 8 depicts an embodiment of protocol entities 8000 that may be implemented in wireless communication devices, including one or more of a user equipment (UE) 8060 such as UEs described in conjunction with FIGs. 1-7, an evolved node B (eNB), or a new radio, next generation node B (gNB) 8080 such as base stations or RANs described in conjunction with FIGs. 1-7, and a network function (e.g., MnF), which may be a MnS, a mobility management entity (MME), or an access and mobility management function (AMF) 8094, according to some aspects. In further embodiments, the NodeB may comprise an xNodeB for a 6thgeneration or later NodeB.

[0408] According to some aspects, gNB 8080 may be implemented as one or more of a dedicated physical device such as a macro-cell, a femto-cell or other suitable device, or in an alternative aspect, may be implemented as one or more software entities running on server computers as part of a virtual network termed a cloud radio access network (CRAN).

[0409] According to some aspects, one or more protocol entities that may be implemented in one or more of UE 8060, gNB 8080 and AMF 8094, may be described as implementing all or part of a protocol stack in which the layers are considered to be ordered from lowest to highest in the order physical layer (PHY), medium access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) and non-access stratum (NAS). According to some aspects, one or more protocol entities that may be implemented in one or more of UE 8060, gNB 8080 and AMF 8094, may communicate with a respective peer protocol entity that may be implemented on another device, using the services of respective lower layer protocol entities to perform such communication.

[0410] According to some aspects, UE PHY layer 8072 and peer entity gNB PHY layer 8090 may communicate using signals transmitted and received via a wireless medium. According to some aspects, UE MAC layer 8070 and peer entity gNB MAC layer 8088 may communicate using the services provided respectively by UE PHY layer 872 and gNB PHY layer 8090. According to some aspects, UE RLC layer 8068 and peer entity gNB RLC layer 8086 may communicate using the services provided respectively by UE MAC layer 8070 and gNB MAC layer 8088. According to some aspects, UE PDCP layer 8066 and peer entity gNB PDCP layer 8084 may communicate using the services provided respectively by UE RLC layer 8068 and 5GNB RLC layer 8086. According to some aspects, UE RRC layer 8064 and gNB RRC layer 8082 may communicate using the services provided respectively by UE PDCP layer 8066 and gNB PDCP layer 8084. According to some aspects, UE NAS 8062 and AMF NAS 8092 may communicate using the services provided respectively by UE RRC layer 8064 and gNB RRC layer 8082.

[0411] The PHY layer 8072 and 8090 may transmit or receive information used by the MAC layer 8070 and 8088 over one or more air interfaces. The PHY layer 8072 and 8090 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as the RRC layer 8064 and 8082. The PHY layer 8072 and 8090 may still further perform error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.

[0412] The MAC layer 8070 and 8088 may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, demultiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.

[0413] The RLC layer 8068 and 8086 may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer 8068 and 8086 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. The RLC layer 8068 and 8086 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.

[0414] The PDCP layer 8066 and 8084 may execute header compression and decompression of Internet Protocol (IP) data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

[0415] The main services and functions of the RRC layer 8064 and 8082 may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point to point Radio Bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. Said MIBs and SIBs may comprise one or more information elements (IES), which may each comprise individual data fields or data structures.

[0416] The UE 8060 and the RAN node, gNB 8080 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer 8072 and 8090, the MAC layer 8070 and 8088, the RLC layer 8068 and 8086, the PDCP layer 8066 and 8084, and the RRC layer 8064 and 8082.

[0417] The non-access stratum (NAS) protocols 8092 form the highest stratum of the control plane between the UE 8060 and the AMF 8005. The NAS protocols 8092 support the mobility of the UE 8060 and the session management procedures to establish and maintain IP connectivity between the UE 8060 and the Packet Data Network (PDN) Gateway (P-GW).

[0418] FIG. 9 illustrates embodiments of the formats of PHY data units (PDUs) that may be transmitted by the PHY device via one or more antennas and be encoded and decoded by a MAC entity such as the processors 520 and 570 in FIG. 5, the baseband circuitry 1304 in FIGs. 13 and 14 according to some aspects. In several embodiments, higher layer frames such as a frame comprising an RRC layer information element may transmit from the base station to the UE or vice versa as one or more MAC Service Data Units (MSDUs) in a payload of one or more PDUs in one or more subframes of a radio frame.

[0419] According to some aspects, a MAC PDU 9100 may consist of a MAC header 9105 and a MAC payload 9110, the MAC payload consisting of zero or more MAC control elements 9130, zero or more MAC service data unit (SDU) portions 9135 and zero or one padding portion 9140. According to some aspects, MAC header 8105 may consist of one or more MAC sub-headers, each of which may correspond to a MAC payload portion and appear in corresponding order. According to some aspects, each of the zero or more MAC control elements 9130 contained in MAC pay load 9110 may correspond to a fixed length sub-header 9115 contained in MAC header 9105. According to some aspects, each of the zero or more MAC SDU portions 9135 contained in MAC payload 9110 may correspond to a variable length sub-header 9120 contained in MAC header 8105. According to some aspects, padding portion 9140 contained in MAC pay load 9110 may correspond to a padding sub-header 9125 contained in MAC header 9105.

[0420] FIG. 10A illustrates an embodiment of communication circuitry 1000 such as the circuitry in the base station 510 and the user equipment 560 shown in FIG. 5. The communication circuitry 1000 is alternatively grouped according to functions. Components as shown in the communication circuitry 1000 are shown here for illustrative purposes and may include other components not shown here in Fig. 10A.

[0421] The communication circuitry 1000 may include protocol processing circuitry 1005, which may implement one or more of medium access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) and non-access stratum (NAS) functions. The protocol processing circuitry 1005 may include one or more processing cores (not shown) to execute instructions and one or more memory structures (not shown) to store program (code) and data information.

[0422] The communication circuitry 1000 may further include digital baseband circuitry 1010, which may implement physical layer (PHY) functions including one or more of hybrid automatic repeat request (HARQ) functions, scrambling and / or descrambling, coding and / or decoding, layer mapping and / or de-mapping, modulation symbol mapping, received symbol and / or bit metric determination, multi-antenna port pre-coding and / or decoding which may include one or more of space-time, space-frequency or spatial coding, reference signal generation and / or detection, preamble sequence generation and / or decoding, synchronization sequence generation and / or detection, control channel signal blind decoding, and other related functions.

[0423] The communication circuitry 1000 may further include transmit circuitry 1015, receive circuitry 1020 and / or antenna array 1030 circuitry.

[0424] The communication circuitry 1000 may further include radio frequency (RF) circuitry 1025 such as the RF circuitry 544 and 594 in FIG. 2. In an aspect of an embodiment, RF circuitry 1025 may include multiple parallel RF chains for one or more of transmit or receive functions, each connected to one or more antennas of the antenna array 1030.

[0425] In an aspect of the disclosure, the protocol processing circuitry 1005 may include one or more instances of control circuitry (not shown) to provide control functions for one or more of digital baseband circuitry 1010, transmit circuitry 1015, receive circuitry 1020, and / or radio frequency circuitry 1025.

[0426] FIG. 10B illustrates an embodiment of radio frequency circuitry 1025 in FIG. 10A according to some aspects such as a RF circuitry 544 and 594 illustrated in FIG. 5. The radio frequency circuitry 1025 may include one or more instances of radio chain circuitry 1072, which in some aspects may include one or more filters, power amplifiers, low noise amplifiers, programmable phase shifters and power supplies (not shown).

[0427] The radio frequency circuitry 1025 may include power combining and dividing circuitry 1074. In some aspects, power combining and dividing circuitry 1074 may operate bidirectionally, such that the same physical circuitry may be configured to operate as a power divider when the device is transmitting, and as a power combiner when the device is receiving. In some aspects, power combining and dividing circuitry 1074 may one or more include wholly or partially separate circuitries to perform power dividing when the device is transmitting and power combining when the device is receiving. In some aspects, power combining and dividing circuitry 1074 may include passive circuitry comprising one or more two-way power divider / combiners arranged in a tree. In some aspects, power combining and dividing circuitry 1074 may include active circuitry comprising amplifier circuits.

[0428] In some aspects, the radio frequency circuitry 1025 may connect to transmit circuitry 1015 and receive circuitry 1020 in FIG. 10A via one or more radio chain interfaces 1076 or a combined radio chain interface 1078. The combined radio chain interface 1078 may form a wide or very wide bandwidth.

[0429] In some aspects, one or more radio chain interfaces 1076 may provide one or more interfaces to one or more receive or transmit signals, each associated with a single antenna structure which may comprise one or more antennas.

[0430] In some aspects, the combined radio chain interface 1078 may provide a single interface to one or more receive or transmit signals, each associated with a group of antenna structures comprising one or more antennas.

[0431] FIG. 11 illustrates an example of a storage medium 1100 to store code and data for execution by any one or more of the processors and / or processing circuitry to perform the functionality of the logic circuitry described herein. Storage medium 1100 may comprise an article of manufacture. In some examples, storage medium 1100 may include any non-transitory computer readable medium or machine-readable medium, such as an optical, magnetic or semiconductor storage. Storage medium 1100 may store diverse types of computer executable instructions, such as instructions to implement logic flows and / or techniques described herein. Examples of a computer readable or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or nonremovable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

[0432] FIG. 12 illustrates an architecture of a system 1200 of a network in accordance with some embodiments. The system 1200 is shown to include a user equipment (UE) 1510 and a UE 1522 such as the UEs shown in FIGs. 1-11. The UEs 1510 and 1522 are illustrated as smartphones (c.g., handheld touch screen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

[0433] In some embodiments, any of the UEs 1510 and 1522 can comprise an Internet of Things (loT) UE, which can comprise a network access layer designed for low-power loT applications utilizing short-lived UE connections. An loT UE can utilize technologies such as machine-to- machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or loT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network describes interconnecting loT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

[0434] The UEs 1510 and 1522 may to connect, e.g., communicatively couple, with a radio access network (RAN) - in this embodiment, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) 1210 such as the base stations shown in FIGs. 1-11. The UEs 1510 and 1522 utilize connections 1520 and 1204, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 1520 and 1204 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.

[0435] In this embodiment, the UEs 1510 and 1522 may further directly exchange communication data via a ProSe interface 1205. The ProSe interface 1205 may alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidclink Discovery Channel (PSDCH), and a Physical Sidclink Broadcast Channel (PSBCH).

[0436] The UE 1522 is shown to be configured to access an access point (AP) 1206 via connection 1207. The connection 1207 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1206 would comprise a wireless fidelity (WiFi®) router. In this example, the AP 1206 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below). The E-UTRAN 1210 can include one or more access nodes that enable the connections 1520 and 1204. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNB), RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The E-UTRAN 1210 may include one or more RAN nodes for providing macro-cells, e.g., macro RAN node 1560, and one or more RAN nodes for providing femto-cells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro-cells), e.g., low power (LP) RAN node 1572.

[0437] Any of the RAN nodes 1560 and 1572 can terminate the air interface protocol and can be the first point of contact for the UEs 1510 and 1522. In some embodiments, any of the RAN nodes 1560 and 1572 can fulfill various logical functions for the E-UTRAN 1210 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0438] In accordance with some embodiments, the UEs 1510 and 1522 can be configured to communicate using Orthogonal Frequency -Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 1560 and 1572 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency-Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers. In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 1560 and 1572 to the UEs 1510 and 1522, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest timefrequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink (DL) channels that are conveyed using such resource blocks.

[0439] The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs 1510 and 1522. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 1510 and 1522 about the transport format, resource allocation, and HARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 192 within a cell) may be performed at any of the RAN nodes 1560 and 1572 based on channel quality information fed back from any of the UEs 1510 and 1522. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 1510 and 1522.

[0440] The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can he four or more different PDCCH formats defined in LTE with different numbers of CCEs (c.g., aggregation level, L=l, 2, 4, or 8).

[0441] Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar’ to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

[0442] The RAN nodes 1560 and 1572 may communicate with one another and / or with other access nodes in the E-UTRAN 1210 and / or in another RAN via an X2 interface, which is a signaling interface for communicating data packets between ANs. Some other suitable interface for communicating data packets directly between ANs may be used.

[0443] The E-UTRAN 1210 is shown to be communicatively coupled to a core network - in this embodiment, an Evolved Packet Core (EPC) network 1220 via an SI interface 1570. In this embodiment the SI interface 1570 is split into two parts: the SI-U interface 1214, which carries traffic data between the RAN nodes 1560 and 1572 and the serving gateway (S-GW) 1222, and the SI- mobility management entity (MME) interface 1215, which is a signaling interface between the RAN nodes 1560 and 1572 and MMEs 1546.

[0444] In this embodiment, the EPC network 1220 comprises the MMEs 1546, the S-GW 1222, the Packet Data Network (PDN) Gateway (P-GW) 1223, and a home subscriber server (HSS) 1224. The MMEs 1546 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 1546 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 1224 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The EPC network 1220 may comprise one or several HSSs 1224, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 1224 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. The S-GW 1222 may terminate the SI interface 1570 towards the E-UTRAN 1210, and routes data packets between the E-UTRAN 1210 and the EPC network 1220. In addition, the S- GW 1222 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

[0445] The P-GW 1223 may terminate an SGi interface (such as interface 182A) toward a PDN. The P-GW 1223 may route data packets between the EPC network 1220 and external networks such as a network including the application server 1230 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 1225. Generally, the application server 1230 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW 1223 is shown to be communicatively coupled to an application server 1230 via an IP interface 1225. The application server 1230 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 1510 and 1522 via the EPC network 1220.

[0446] The P-GW 1223 may further be a node for policy enforcement and charging data collection. Policy and Charging Enforcement Function (PCRF) 1226 is the policy and charging control element of the EPC network 1220. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H- PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 1226 may be communicatively coupled to the application server 1230 via the P-GW 1223. The application server 1230 may signal the PCRF 1226 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 1226 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 1230.

[0447] FIG. 13 illustrates example components of a device 1300 in accordance with some embodiments such as the base stations and UEs shown in FIGs. 1- 12. In some embodiments, the device 1300 may include application circuitry 1302, baseband circuitry 1304, Radio Frequency (RF) circuitry 1306, front-end module (FEM) circuitry 1308, one or more antennas 1310, and power management circuitry (PMC) 1312 coupled together at least as shown. The components of the illustrated device 1300 may be included in a UE or a RAN node such as a base station or gNB. In some embodiments, the device 1300 may include less elements (e.g., a RAN node may not utilize application circuitry 1302, and instead include a processor / controller to process IP data received from an EPC). In some embodiments, the device 1300 may include additional elements such as, for example, memory / storage, display, camera, sensor, or input / output (R0) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud- RAN (C-RAN) implementations).

[0448] The application circuitry 1302 may include one or more application processors. For example, the application circuitry 1302 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general- purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with or may include memory / storage and may be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 1300. In some embodiments, processors of application circuitry 1302 may process IP data packets received from an EPC.

[0449] The baseband circuitry 1304 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1304 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1306 and to generate baseband signals for a transmit signal path of the RF circuitry 1306. The baseband circuity 1304 may interface with the application circuitry 1302 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1306. For example, in some embodiments, the baseband circuitry 1304 may include a third generation (3G) baseband processor 1304A, a fourth generation (4G) baseband processor 1304B, a fifth generation (5G) baseband processor 1304C, or other baseband processor(s) 1304D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). In many embodiments, the fourth generation (4G) baseband processor 1304B may include capabilities for generation and processing of the baseband signals for LTE radios and the fifth generation (5G) baseband processor 1304C may capabilities for generation and processing of the baseband signals for NRs.

[0450] The baseband circuitry 1304 (e.g., one or more of baseband processors 1304A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1306. In other embodiments, some of or all the functionality of baseband processors 1304A-D may be included in modules stored in the memory 1304G and executed via a Central Processing Unit (CPU) 1304E. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc.

[0451] In some embodiments, modulation / demodulation circuitry of the baseband circuitry 1304 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping / demapping functionality. In some embodiments, encoding / decoding circuitry of the baseband circuitry 1304 may include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder / decoder functionality. Embodiments of modulation / demodulation and encoder / decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

[0452] In some embodiments, the baseband circuitry 1304 may include one or more audio digital signal processor(s) (DSP) 1304F. The audio DSP(s) 1304F may be include elements for compression / decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some of or all the constituent components of the baseband circuitry 1304 and the application circuitry 1302 may be implemented together such as, for example, on a system on a chip (SOC). In some embodiments, the baseband circuitry 1304 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1304 may support communication with an evolved universal terrestrial radio access network (E-UTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 1304 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. The RF circuitry 1306 may enable communication with wireless networks using modulated electromagnetic radiation through a non- solid medium. In various embodiments, the RF circuitry 1306 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. The RF circuitry 1306 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1308 and provide baseband signals to the baseband circuitry 1304. The RF circuitry 1306 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1304 and provide RF output signals to the FEM circuitry 1308 for transmission.

[0453] In some embodiments, the receive signal path of the RF circuitry 1306 may include mixer circuitry 1306a, amplifier circuitry 1306b and filter circuitry 1306c. In some embodiments, the transmit signal path of the RF circuitry 1306 may include filter circuitry 1306c and mixer circuitry 1306a. The RF circuitry 1306 may also include synthesizer circuitry 1306d for synthesizing a frequency, or component carrier, for use by the mixer circuitry 1306a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1306a of the receive signal path may to down-convert RF signals received from the FEM circuitry 1308 based on the synthesized frequency provided by synthesizer circuitry 1306d. The amplifier circuitry 1306b may amplify the down-converted signals and the filter circuitry 1306c may be a low-pass filter (LPF) or band-pass filter (BPF) to remove unwanted signals from the down- converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1304 for further processing.

[0454] In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1306a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0455] In some embodiments, the mixer circuitry 1306a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1306d to generate RF output signals for the FEM circuitry 1308. The baseband signals may be provided by the baseband circuitry 1304 and may be filtered by filter circuitry 1306c. In some embodiments, the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a of the transmit signal path may be configured for super-heterodyne operation.

[0456] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1306 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1304 may include a digital baseband interface to communicate with the RF circuitry 1306.

[0457] In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0458] In some embodiments, the synthesizer circuitry 1306d may be a fractional-N synthesizer or a fractional NIN+ I synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1306d may be a delta- sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0459] The synthesizer circuitry 1306d may synthesize an output frequency for use by the mixer circuitry 1306a of the RF circuitry 1306 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1306d may be a fractional NIN+ I synthesizer.

[0460] In some embodiments, frequency input may be an output of a voltage-controlled oscillator (VCO), although that is not a requirement. Divider control input may be an output of either the baseband circuitry 1304 or an application processor of the applications circuitry 1302 depending on the desired output frequency. Some embodiments may determine a divider control input (e.g., N) from a look-up table based on a channel indicated by the applications circuitry 1302.

[0461] The synthesizer circuitry 1306d of the RF circuitry 1306 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0462] In some embodiments, the synthesizer circuitry 1306d may generate a carrier frequency (or component carrier) as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a local oscillator (LO) frequency (fLO). In some embodiments, the RF circuitry 1306 may include an IQ / polar converter.

[0463] The FEM circuitry 1308 may include a receive signal path which may include circuitry to operate on RF signals received from one or more antennas 1310, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1306 for further processing. FEM circuitry 1308 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1306 for transmission by one or more of the one or more antennas 1310. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1306, solely in the FEM circuitry 1308, or in both the RF circuitry 1306 and the FEM circuitry 1308.

[0464] In some embodiments, the FEM circuitry 1308 may include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (c.g., to the RF circuitry 1306). The transmit signal path of the FEM circuitry 1308 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1306), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1310).

[0465] In the present embodiment, the radio refers to a combination of the RF circuitry 130 and the FEM circuitry 1308. The radio refers to the portion of the circuitry that generates and transmits or receives and processes the radio signals. The RF circuitry 1306 includes a transmitter to generate the time domain radio signals with the data from the baseband signals and apply the radio signals to subcarriers of the carrier frequency that form the bandwidth of the channel. The PA in the FEM circuitry 1308 amplifies the tones for transmission and amplifies tones received from the one or more antennas 1310 via the LNA to increase the signal-to-noise ratio (SNR) for interpretation. In wireless communications, the FEM circuitry 1308 may also search for a detectable pattern that appears to be a wireless communication. Thereafter, a receiver in the RF circuitry 1306 converts the time domain radio signals to baseband signals via one or more functional modules such as the functional modules shown in the base station 510 and the user equipment 560 illustrated in FIG. 2.

[0466] In some embodiments, the PMC 1312 may manage power provided to the baseband circuitry 1304. In particular, the PMC 1312 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1312 may often be included when the device 1300 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 1312 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0467] While FIG. 13 shows the PMC 1312 coupled only with the baseband circuitry 1304. However, in other embodiments, the PMC 1312 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1302, RF circuitry 1306, or FEM circuitry 1308.

[0468] In some embodiments, the PMC 1312 may control, or otherwise be part of, various power saving mechanisms of the device 1300. For example, if the device 1300 is in an RRC > Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1300 may power down for brief intervals of time and thus save power.

[0469] If there is no data traffic activity for an extended period of time, then the device 1300 may transition off to an RRC Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1300 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1300 may not receive data in this state, in order to receive data, it must transition back to RRC Connected state.

[0470] An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[0471] The processors of the application circuitry 1302 and the processors of the baseband circuitry 1304 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1304, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1302 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE / RAN node, described in further detail below.

[0472] FIG. 14 illustrates example interfaces of baseband circuitry in accordance with some embodiments such as the baseband circuitry shown and / or discussed in conjunction with FIGs. 1- 13. As discussed above, the baseband circuitry 1304 of FIG. 13 may comprise processors 1304A-1304E and a memory 1304G utilized by said processors. Each of the processors 1304A- 1304E may include a memory interface, 1404A-1404E, respectively, to send / receive data to / from the memory 1304G.

[0473] The baseband circuitry 1304 may further include one or more interfaces to communicatively couple to other circuitries / devices, such as a memory interface 1412 (e.g., an interface to send / receive data to / from memory external to the baseband circuitry 1304), an application circuitry interface 1414 (c.g., an interface to scnd / rcccivc data to / from the application circuitry 1302 of FIG. 13), an RF circuitry interface 1416 (e.g., an interface to send / receive data to / from RF circuitry 1306 of FIG. 13), a wireless hardware connectivity interface 1418 (e.g., an interface to send / receive data to / from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 1420 (e.g., an interface to send / receive power or control signals to / from the PMC 1312.

[0474] FIG. 15 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, FIG. 15 shows a diagrammatic representation of hardware resources 1500 including one or more processors (or processor cores) 1510, one or more memory / storage devices 1520, and one or more communication resources 1530, each of which may be communicatively coupled via a bus 1540. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1502 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1500.

[0475] The processors 1510 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1512 and a processor 1514.

[0476] The memory / storage devices 1520 may include main memory, disk storage, or any suitable combination thereof. The memory / storage devices 1520 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random-access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0477] The communication resources 1530 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1504 or one or more databases 1506 via a network 1508. For example, the communication resources 1530 may include wired communication components (c.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

[0478] Instructions 1550 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1510 to perform any one or more of the methodologies discussed herein. The instructions 1550 may reside, completely or partially, within at least one of the processors 1510 (e.g., within the processor's cache memory), the memory / storage devices 1520, or any suitable combination thereof. Furthermore, any portion of the instructions 1550 may be transferred to the hardware resources 1500 from any combination of the peripheral devices 1504 or the databases 1506. Accordingly, the memory of processors 1510, the memory / storage devices 1520, the peripheral devices 1504, and the databases 1506 are examples of computer-readable and machine-readable media.

[0479] In embodiments, one or more elements of FIGs. 12, 13, 14, and / or 15 may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof. In embodiments, one or more elements of FIGs. 12, 13, 14, and / or 15 may be configured to perform one or more processes, techniques, or methods, or portions thereof, as described in the following examples.

[0480] As used herein, the term "circuitry" may refer to, be pail of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and / or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable hardware components that provide the described functionality.

[0481] Various examples may be implemented using hardware elements, software elements, or a combination of both. In some examples, hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. In some examples, software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and / or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

[0482] Some examples may be described using the expression “in one example” or “an example” along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one example. The appearances of the phrase “in one example” in various places in the specification are not necessarily all referring to the same example.

[0483] Some examples may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, descriptions using the terms “connected” and / or “coupled” may indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0484] In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single example for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate example. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein," respectively. Moreover, the terms "first," "second," "third," and so forth, are used merely as labels, and are not intended to impose numerical requirements on their objects.

[0485] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above arc disclosed as example forms of implementing the claims.

[0486] A data processing system suitable for storing and / or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code to reduce the number of times code must be retrieved from bulk storage during execution. The term “code” covers a broad range of software components and constructs, including applications, drivers, processes, routines, methods, modules, firmware, microcode, and subprograms. Thus, the term “code” may be used to refer to any collection of instructions which, when executed by a processing system, perform a desired operation or operations.

[0487] Processing circuitry, logic circuitry, devices, and interfaces herein described may perform functions implemented in hardware and also implemented with code executed on one or more processors. Processing circuitry, or logic circuitry, refers to the hardware or the hardware and code that implements one or more logical functions. Circuitry is hardware and may refer to one or more circuits. Each circuit may perform a particular function. A circuit of the circuitry may comprise discrete electrical components interconnected with one or more conductors, an integrated circuit, a chip package, a chip set, memory, or the like. Integrated circuits include circuits created on a substrate such as a silicon wafer and may comprise components. And integrated circuits, processor packages, chip packages, and chipsets may comprise one or more processors.

[0488] Processors may receive signals such as instructions and / or data at the input(s) and process the signals to generate the at least one output. While executing code, the code changes the physical states and characteristics of transistors that make up a processor pipeline. The physical states of the transistors translate into logical bits of ones and zeros stored in registers within the processor. The processor can transfer the physical states of the transistors into registers and transfer the physical states of the transistors to another storage medium.

[0489] A processor may comprise circuits or circuitry to perform one or more sub-functions implemented to perform the overall function of “a processor”. Note that “a processor” may comprise one or more processors and each processor may comprise one or more processor cores that independently or interdependently process code and / or data. Each of the processor cores are also “processors” and arc only distinguishable from processors for the purpose of describing a physical arrangement or architecture of a processor with multiple processor cores on one or more dies and / or within one or more chip packages. Processor cores may comprise general processing cores or may comprise processor cores configured to perform specific tasks, depending on the design of the processor. Processor cores may be processors with one or more processor cores. As discussed and claimed herein, when discussing functionality performed by a processor, processing circuitry, or the like; the processor, processing circuitry, or the like may comprise one or more processors, each processor having one or more processor cores, and any one or more of the processors and / or processor cores may reside on one or more dies, within one or more chip packages, and may perform part of or all the processing required to perform the functionality.

[0490] One example of a processor is a state machine or an application-specific integrated circuit (ASIC) that includes at least one input and at least one output. A state machine may manipulate the at least one input to generate the at least one output by performing a predetermined series of serial and / or parallel manipulations or transformations on the at least one input.

[0491] Several embodiments have one or more potentially advantages effects. The enhancements advantageously enable management of ML models; sharing of ML models with other consumers or operators; storing of ML models in a core cellular network rather than locally; storing of a ML model in the ADRF to share with other consumers or operators; retrieving of a ML model from the ADRF to share with other consumers or operators; deletion / removal of a ML model from the ADRF to manage the ML models stored in the ADRF; provision of an application program interface (API) for a ML Model Management service of the ARDF to support storing or updating ML models, retrieving ML models, and deleting ML models; provision of a ML Model Management service of the ARDF using Service based interface (SBI) design principles; definition of the resource Uniform Resource Identifiers (URIs), resource standard methods, and custom operation method; provision of a ML Model Management service of the ARDF including an application data model; provision of a ML Model Management service of the ARDF including security using OAuth2 protocol for access authorization; provision of an API interface for a ML Model Management service of the ARDF developed using the yet another mark-up language (YAML) programming language; and provision of a result to a retrieve request, a store request, and a delete request. EXAMPLES OF FURTHER EMBODIMENTS

[0492] The following examples pertain to further embodiments. Specifics in the examples may be used anywhere in one or more embodiments.

[0493] Example 1 is an apparatus to manage shared machine learning (ML) models, comprising an interface for communication with the consumer of the management services; a processing circuitry coupled with the interface to perform operations to receive a management request initiated by consumer via the interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF); process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network; and pass a result to the NWDAF. In Example 2, the apparatus of Example 1, wherein the processing circuitry comprises one or more processors of one or more servers, coupled with the interface and a memory, wherein the memory comprises code to generate and communicate the management request via at least one of the one or more processors. In Example 3, the apparatus of Example 1, wherein the ML Model Management service of the ARDF comprises an Nadrf_MLModelManagement application program interface (API) to support a Nadrf_MLModelManagement_StorageRequest to request the ADRF to store or update the ML models, Nadrf_MLModelManagement_Retrieval to retrieve stored ML models from the ADRF, and a Nadrf_MLModelManagement_Delete to delete stored ML models in the ADRF. In Example 4, the apparatus of Example 1, wherein the ML Model Management service comprises a Service Based interface (SBI). In Example 5, the apparatus of Example 1, wherein the NWDAF is a NF service consumer, the ADRF to receive a message from the NWDAF to store the first ML model comprising a Hypertext Transfer Protocol (HTTP) POST request with "{apiRoot} / nadrf-mlmodelmanagement / <apiVersion> / mlmodel- store-records" as a Resource Uniform Resource Identifier (URI) representing a "ADRF ML Model Store Records" resource to create an "Individual ADRF ML Model Store Record" according to information in a message body of the message. In Example 6, the apparatus of Example 5, wherein the message to store the first ML model further comprises a NadrfMLModelStoreRecord data structure, including a MLModellnfo data structure in an "mlModellnfo" attribute of the message, wherein the MLModellnfo data structure comprises a unique ML model identifier within a "modelUniqueld" attribute, an address of the first ML model within a "mlFileAddr " attribute, and a storage size required for the first ML model in a mlStoragcSizc" attribute. In Example 7, the apparatus of Example 1, wherein the NWDAF is a NF service consumer, the ADRF to receive a message from the NWDAF to retrieve the first ML model comprising a Hypertext Transfer Protocol (HTTP) GET request with "{apiRoot} / nadrf- mlmodelmanagemen t / <api Ver sion> / mlmodel- store-records" as a Resource Uniform Resource Identifier (URI) representing a "ADRF ML Model Store Records" resource, to request ADRF ML model store records for the first ML model according to a storage transaction identifier within a "storetrans-id" attribute or a unique ML model identifier within a "modelUniqueld" attribute. In Example 8, the apparatus of Example 1, wherein the NWDAF is a NF service consumer, the ADRF to receive a message from the NWDAF to delete the first ML model comprising a Hypertext Transfer Protocol (HTTP) DELETE request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records / {storeTransId}" as a Resource Uniform Resource Identifier (URI) representing an "Individual ADRF ML Model Store Record" resource, where "{storeTransId}" is a transaction identifier of a stored record that is to be deleted. In Example 9, the apparatus of any one of Examples 1-8, wherein the result comprises a “storeResult” attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to a management request to store the first ML model; a status code with a message body containing a NadrfMLModelStoreRecord data structure for the first ML model in response to a management request to retrieve the first ML model; or a status code in response to a management request to delete the first ML model.

[0494] Example 10 is a method to manage shared machine learning (ML) models, comprising receiving a management request initiated by consumer via an interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF); processing the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network; and communicating a result to the NWDAF. In Example 11, the method of Example 10, wherein receiving the management request includes receiving a message from the NWDAF to store the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) POST request with a Resource Uniform Resource Identifier (URI) for the first ML model to create a record based on information in a message body of the message. In Example 12, the method of Example 9, wherein receiving the management request includes receiving a message from the NWDAF to retrieve the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) GET request with a Resource Uniform Resource Identifier (URI) representing a store record resource for the first ML model, to request the store record resource for the first ML model based on a storage transaction identifier or a unique ML model identifier. In Example 13, the method of Example 9, wherein receiving the management request includes receiving a message from the NWDAF to delete the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) DELETE request with a Resource Uniform Resource Identifier (URI) representing a store record resource, wherein the Resource URI includes a transaction identifier of a stored record for the first ML model that is to be deleted. In Example 14, the method of any Example 9-13, wherein the result comprises an attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to the management request to store the first ML model; a first status code with a message body containing a data structure for the first ML model in response to the management request to retrieve the first ML model; or a second status code in response to a management request to delete the first ML model.

[0495] Example 15 is a machine-readable medium containing instructions to manage shared machine learning (ML) models, which when executed by a processor, cause the processor to perform operations, the operations to receive a management request initiated by consumer via an interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF); process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network; and pass a result to the NWDAF. In Example 16, the machine-readable medium of Example 15, the operations to receive the management request includes operations to receive a message from the NWDAF to store the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) POST request with a Resource Uniform Resource Identifier (URI) for the first ML model to create a record based on information in a message body of the message. In Example 17, the machine-readable medium of Example 15, the operations to receive the management request includes operations to receive a message from the NWDAF to retrieve the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) GET request with a Resource Uniform Resource Identifier (URI) representing a store record resource for the first ML model, to request the store record resource for the first ML model based on a storage transaction identifier or a unique ML model identifier. In Example 18, the machine- readable medium of Example 15, the operations to receive the management request includes operations to receive a message from the NWDAF to delete the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) DELETE request with a Resource Uniform Resource Identifier (URI) representing a store record resource, wherein the Resource URI includes a transaction identifier of a stored record for the first ML model that is to be deleted. In Example 19, the machine-readable medium of Example 15, wherein the ML Model Management service of the ARDF comprises an application program interface (API) to support a request to store or update the ML models, to retrieve stored ML models from the ADRF, and to delete stored ML models in the ADRF. In Example 20, the machine-readable medium of any Example 15-19, wherein the result comprises an attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to the management request to store the first ML model; a first status code with a message body containing a data structure for the first ML model in response to the management request to retrieve the first ML model; or a second status code in response to a management request to delete the first ML model.

[0496] Example 21 is an apparatus comprising a means for any action in Examples 1-20.

Claims

WHAT IS CLAIMED IS:

1. An apparatus to manage shared machine learning (ML) models, comprising: an interface for communication with the consumer of the management services; a processing circuitry coupled with the interface to perform operations to: receive a management request initiated by consumer via the interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF); process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network; and pass a result to the NWDAF.

2. The apparatus of claim 1, wherein the processing circuitry comprises one or more processors of one or more servers, coupled with the interface and a memory, wherein the memory comprises code to generate and communicate the management request via at least one of the one or more processors.

3. The apparatus of claim 1, wherein the ML Model Management service of the ARDF comprises an Nadrf_MLModelManagement application program interface (API) to support a Nadrf_MLModelManagement_StorageRequest to request the ADRF to store or update the ML models, Nadrf_MLModelManagement_Retrieval to retrieve stored ML models from the ADRF, and a Nadrf_MLModelManagement_Delete to delete stored ML models in the ADRF.

4. The apparatus of claim 1, wherein the ML Model Management service comprises a Service Based interface (SBI).

5. The apparatus of claim 1, wherein the NWDAF is a NF service consumer, the ADRF to receive a message from the NWDAF to store the first ML model comprising a Hypertext Transfer Protocol (HTTP) POST request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel- store-records" as a Resource Uniform ResourceIdentifier (URI) representing a "ADRF ML Model Store Records" resource to create an "Individual ADRF ML Model Store Record" according to information in a message body of the message.

6. The apparatus of claim 5, wherein the message to store the first ML model further comprises a NadrfMLModelStoreRecord data structure, including a MLModellnfo data structure in an "mlModellnfo" attribute of the message, wherein the MLModellnfo data structure comprises a unique ML model identifier within a "modelUniqueld" attribute, an address of the first ML model within a "mlFileAddr " attribute, and a storage size required for the first ML model in a mlStorageSize" attribute.

7. The apparatus of claim 1, wherein the NWDAF is a NF service consumer, the ADRF to receive a message from the NWDAF to retrieve the first ML model comprising a Hypertext Transfer Protocol (HTTP) GET request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel- store-records" as a Resource Uniform Resource Identifier (URI) representing a "ADRF ML Model Store Records" resource, to request ADRF ML model store records for the first ML model according to a storage transaction identifier within a "storetrans-id" attribute or a unique ML model identifier within a "modelUniqueld" attribute.

8. The apparatus of claim 1, wherein the NWDAF is a NF service consumer, the ADRF to receive a message from the NWDAF to delete the first ML model comprising a Hypertext Transfer Protocol (HTTP) DELETE request with "{apiRoot} / nadrf- mlmodelmanagement / <apiVersion> / mlmodel-store-records / {storeTransId}" as a Resource Uniform Resource Identifier (URI) representing an "Individual ADRF ML Model Store Record" resource, where "{storeTransId}" is a transaction identifier of a stored record that is to be deleted.

9. The apparatus of any one of claims 1-8, wherein the result comprises a “storcRcsult” attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to a management request to store thefirst ML model; a status code with a message body containing a NadrfMLModelStoreRecord data structure for the first ML model in response to a management request to retrieve the first ML model; or a status code in response to a management request to delete the first ML model.

10. A method to manage shared machine learning (ML) models, comprising: receiving a management request initiated by consumer via an interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF); processing the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network; and communicating a result to the NWDAF.

11. The method of claim 10, wherein receiving the management request includes receiving a message from the NWDAF to store the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) POST request with a Resource Uniform Resource Identifier (URI) for the first ML model to create a record based on information in a message body of the message.

12. The method of claim 9, wherein receiving the management request includes receiving a message from the NWDAF to retrieve the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) GET request with a Resource Uniform Resource Identifier (URI) representing a store record resource for the first ML model, to request the store record resource for the first ML model based on a storage transaction identifier or a unique ML model identifier.

13. The method of claim 9, wherein receiving the management request includes receiving a message from the NWDAF to delete the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) DELETE request with a Resource Uniform Resource Identifier (URI) representing a store record resource, wherein the Resource URI includes a transaction identifier of a stored record for the first ML model that is to be deleted.

14. The method of any claim 9- 13, wherein the result comprises an attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to the management request to store the first ML model; a first status code with a message body containing a data structure for the first ML model in response to the management request to retrieve the first ML model; or a second status code in response to a management request to delete the first ML model.

15. A machine-readable medium containing instructions to manage shared machine learning (ML) models, which when executed by a processor, cause the processor to perform operations, the operations to: receive a management request initiated by consumer via an interface, from a Model Training logical function (MTLF) of a Network Data Analytics Function (NWDAF), the management request to store, retrieve, or delete the first ML model via a ML Model Management service of an Analytic Data Repository Function (ADRF); process the management request, wherein the NWDAF and the ADRF comprise network functions (NFs) of a core cellular network; and pass a result to the NWDAF.

16. The machine-readable medium of claim 15, the operations to receive the management request includes operations to receive a message from the NWDAF to store the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) POST request with a Resource Uniform Resource Identifier (URI) for the first ML model to create a record based on information in a message body of the message.

17. The machine-readable medium of claim 15, the operations to receive the management request includes operations to receive a message from the NWDAF to retrieve the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) GET request with a Resource Uniform Resource Identifier (URI) representing a store record resource for the first ML model, to request the store record resource for the first ML model based on a storage transaction identifier or a unique ML model identifier.

18. The machine-readable medium of claim 15, the operations to receive the management request includes operations to receive a message from the NWDAF to delete the first ML model, the message comprising a Hypertext Transfer Protocol (HTTP) DELETE request with a Resource Uniform Resource Identifier (URI) representing a store record resource, wherein the Resource URI includes a transaction identifier of a stored record for the first ML model that is to be deleted.

19. The machine-readable medium of claim 15, wherein the ML Model Management service of the ARDF comprises an application program interface (API) to support a request to store or update the ML models, to retrieve stored ML models from the ADRF, and to delete stored ML models in the ADRF.

20. The machine-readable medium of any claim 15-19, wherein the result comprises an attribute indicating that the first ML model is stored, the first ML model file address is not found, or the file download for the first ML model failed, in response to the management request to store the first ML model; a first status code with a message body containing a data structure for the first ML model in response to the management request to retrieve the first ML model; or a second status code in response to a management request to delete the first ML model.

Images