Apparatus and method for new model adaptation network function

Abstract

Apparatuses and methods for new model adaptation network functions are provided herein. An apparatus for a model adaptation function includes an interface; and a processor coupled with the interface, wherein the processor is to: receive, via the interface, an inference request related to a communication network from a service consumer; determine an adapter from an adapter repository based on the inference request; integrate the adapter into a generic base model to obtain an analysis result for the inference request; and provide, via the interface, the analysis result to the service consumer as an inference response. Other embodiments can be described and / or claimed.

Description

[0001] Priority Statement This application is based on and claims priority to International Patent Application No. PCT / CN2024 / 137990, filed on December 10, 2024, which is incorporated herein by reference in its entirety. Technical Field

[0002] The embodiments of this disclosure generally relate to wireless communication, and more specifically, to apparatus and methods for adapting network functions to new models in sixth-generation (6G) systems. Background Technology

[0003] 6G systems are envisioned as AI-native systems, where AI and machine learning (ML) are indispensable, enabling advanced use cases and empowering intelligent network functions. Researchers have already conducted some studies to propose relevant technical solutions. Summary of the Invention

[0004] One aspect of this disclosure provides an apparatus for model adaptation functionality, comprising: an interface; and a processor coupled to the interface, wherein the processor is configured to: receive, via the interface, a communication network-related inference request from a service consumer; determine an adapter from an adapter repository based on the inference request; integrate the adapter into a general base model to obtain an analysis result for the inference request; and provide the analysis result as an inference response to the service consumer via the interface, wherein the interface includes a service-based interface (SBI).

[0005] One aspect of this disclosure provides an apparatus for a general base model, comprising: an interface; and a processor coupled to the interface, wherein the processor is configured to: receive, via the interface, an inference request related to a communication network from a model adaptation function; integrate an adapter associated with the inference request, wherein the adapter is selected by the model adaptation function from an adapter repository based on the inference request; perform analysis on the inference request based on the adapter to obtain analysis results; and provide the analysis results to the model adaptation function via the interface. Attached Figure Description

[0006] In the accompanying drawings, embodiments of the present disclosure will be illustrated by way of example rather than limitation, wherein like reference numerals refer to similar elements.

[0007] Figure 1 An example architecture of a system according to some embodiments of this disclosure is shown.

[0008] Figure 2 An example of an isolated AI / ML function is shown.

[0009] Figure 3 Examples of implementations of model adaptation network functionality according to some embodiments of this disclosure are shown.

[0010] Figure 4 Examples of integration models in a wireless network architecture according to some embodiments of this disclosure are shown.

[0011] Figure 5 A flowchart is shown illustrating a method for dynamically customizing and integrating a base model according to some embodiments of the present disclosure.

[0012] Figure 6 A flowchart is shown illustrating a method for dynamically customizing and integrating a base model according to some embodiments of the present disclosure.

[0013] Figure 7 An example functional framework for ML and / or RAN intelligence is described.

[0014] Figure 8 An example AI / ML-assisted communication network is depicted, including communication between two MLFs.

[0015] Figure 9 Networks according to various embodiments are shown.

[0016] Figure 10 The illustrations depict wireless networks according to various embodiments.

[0017] Figure 11 The block diagram illustrates components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein, according to some example embodiments.

[0018] Figure 12 Networks according to various embodiments are shown. Detailed Implementation

[0019] Various aspects of the illustrative embodiments will be described using terminology commonly employed by those skilled in the art to convey the essence of this disclosure to others skilled in the art. However, it will be readily understood by those skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. Specific figures, materials, and configurations are set forth for illustrative purposes to provide a thorough understanding of the illustrative embodiments. However, it will be readily understood by those skilled in the art that alternative embodiments can be practiced without these specific details. In other instances, well-known features may be omitted or simplified to avoid obscuring the illustrative embodiments.

[0020] Furthermore, the various operations will be described as multiple discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations do not need to be performed in the order presented.

[0021] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly throughout this document. These phrases do not typically refer to the same embodiment; however, they may refer to the same embodiment. Unless the context otherwise specifies, the terms “comprising,” “having,” and “including” are synonyms. The phrases “A or B” and “A / B” mean “(A), (B) or (A and B).”

[0022] This disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, cloud computing, data centers, network topology, communication system implementation, network convergence, and artificial intelligence (AI) / machine learning (ML) technologies.

[0023] Figure 1 An example architecture of system 100 according to some embodiments of this disclosure is shown. The following description is provided for example system 100 operating in conjunction with Long Term Evolution (LTE) system standards, 5G or New Radio (NR) system standards provided by the 3GPP Technical Specification (TS), and future system standards (e.g., second generation (6G)). However, the example embodiments are not limited in this respect, and the described embodiments can be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., Wireless Metropolitan Area Network (MAN), Global Microwave Access Interoperability (WiMAX), etc.).

[0024] like Figure 1As shown, system 100 may include UE 101a and UE 101b (collectively referred to as "(one or more) UE 101"). As used herein, the term "user equipment" or "UE" may refer to a device with radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous and may refer to a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device including a wireless communication interface. In this example, UE 101 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronics devices, cellular phones, smartphones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptops, in-vehicle infotainment systems (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (ICs), head-up displays (HUDs), on-board diagnostics (OBD) devices, dashboard mobile devices (DMEs), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or “smart” devices, machine-type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, and / or the like.

[0025] In some embodiments, any of UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a PLMN, Proximity-Based Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE may execute background applications (e.g., keeping messages active, state updates, etc.) to facilitate connectivity within the IoT network.

[0026] UE 101 can be configured to connect (e.g., communicatively coupled) to a radio access network (RAN) 110. In embodiments, RAN 110 can be a next-generation (NG) RAN or a 5G RAN, a 6G RAN, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), or a legacy RAN, such as UTRAN (UMTS terrestrial radio access network) or GERAN (GSM (Global System for Mobile Communications or Groupe Spécial Mobile) EDGE (GSM evolution) radio access network). As used herein, the term "NG RAN," etc., can refer to RAN 110 operating in NR or 5G system 100 or 6G system 100, and the term "E-UTRAN," etc., can refer to RAN 110 operating in LTE or 4G system 100. UE 101 utilizes connections (or channels) 103 and 104, each connection including a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" can refer to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" can be synonymous and / or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and / or any other similar term indicating a path or medium through which data is transmitted. Additionally, the term "link" can refer to a connection between two devices for the purpose of sending and receiving information via radio access technology (RAT).

[0027] In this example, connections 103 and 104 are shown as air interfaces for communication coupling and can be consistent with cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Cellular PTT (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, New Radio (NR) protocol, 6G protocol, and / or any other communication protocols discussed herein. In this embodiment, UE 101 can directly exchange communication data via ProSe interface 105. ProSe interface 105 can alternatively be referred to as sidelink (SL) interface 105 and may include one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0028] UE 101b is shown configured to access access point (AP) 106 (also referred to as "WLAN node 106", "WLAN 106", "WLAN terminal 106", or "WT 106", etc.) via connection 107. Connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 106 will include a Wi-Fi® router. In this example, AP 106 is shown connected to the Internet but not to the core network of the wireless system (described in further detail below). In various embodiments, UE 101b, RAN 110, and AP 106 may be configured to utilize LTE-WLAN aggregation (LWA) operation and / or WLAN LTE / WLAN radio-grade integration (LWIP) operation with IPsec tunneling. LWA operation may involve UE 101b in RRC_CONNECTED being configured by RAN node 111 to utilize LTE and WLAN radio resources. LWIP operation may involve UE 101b using WLAN radio resources (e.g., connection 107) via an Internet Protocol Security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) sent through connection 107. The IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0029] RAN 110 may include one or more RAN nodes 111a and 111b (collectively referred to as "(one or more) RAN nodes 111") that enable connections to 103 and 104. As used herein, the terms "access node (AN)," "access point," "RAN node," etc., can describe equipment that provides radio baseband functionality for data and / or voice connections between the network and one or more users. These access nodes may be referred to as base stations (BS), next-generation Node Bs (gNBs), RAN nodes, evolved Node Bs (eNBs), Node Bs, roadside units (RSUs), transmit / receive points (TRxPs or TRPs), etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the term "NGRAN node" and the like may refer to RAN node 111 (e.g., gNB) operating in NR or 5G system 100 or RAN node 111 operating in 6G system 100, and the term "E-UTRAN node" and the like may refer to RAN node 111 (e.g., eNB) operating in LTE or 4G system 100. According to various embodiments, RAN node 111 may be implemented as one or more dedicated physical devices such as macro cell base stations and / or low-power (LP) base stations, such as femtocells, picocells, or other similar cells, used to provide smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells.

[0030] In some embodiments, all or part of RAN node 111 can be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud Radio Access Network (CRAN) and / or a Virtual Baseband Unit Pool (vBBUP). In these embodiments, CRAN or vBBUP can implement RAN function partitioning, such as: PDCP partitioning, where the RRC and PDCP layers are operated by CRAN / vBBUP, while other Layer 2 (L2) protocol entities are operated by individual RAN node 111; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP, and the PHY layer is operated by individual RAN node 111; or a “lower PHY” partitioning, where the upper part of the RRC, PDCP, RLC, MAC, and PHY layers is operated by CRAN / vBBUP, and the lower part of the PHY layer is operated by individual RAN node 111. This virtualization framework allows the processor cores of RAN node 111 to be freed up for executing other virtualized applications. In some implementations, individual RAN node 111 may represent a virtualized application running via an individual F1 interface (…). Figure 1(Not shown) Individual gNB-DUs connected to the gNB-CU. In these implementations, the gNB-DU may include one or more remote radio heads or radio front-end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in RAN 110 or by a server pool in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more RAN nodes 111 may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol termination to UE 101, and are connected to the 5GC or 6G core network via the NG interface.

[0031] In a V2X scenario, one or more RAN nodes 111 can be or act as RSUs. The terms "roadside unit" or "RSU" can refer to any transport infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively static) UE, wherein an RSU implemented in or by a UE can be referred to as a "UE-type RSU," an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU," and so on. In one example, an RSU is a computing device coupled to radio frequency circuitry located on the roadside, providing connectivity support for passing vehicle UE 101 (vUE 101). An RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can operate on the 5.9 GHz Direct Short Range Communication (DSRC) band to provide very low-latency communication required for high-speed events, such as collision avoidance and traffic warnings. Alternatively or additionally, the RSU can operate on the cellular V2X band to provide the aforementioned low-latency communication as well as other cellular communication services. Alternatively or additionally, the RSU can operate as a WiFi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. One or more computing devices and some or all of the RF circuitry of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired (e.g., Ethernet) connectivity to traffic signal controllers and / or backhaul networks.

[0032] Any RAN node 111 can terminate the air interface protocol and can be the first point of contact for UE 101. In some embodiments, any RAN node 111 can fulfill various logical functions of RAN 110, 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.

[0033] In an embodiment, UE 101 may be configured to communicate with each other or with any RAN node 111 via a multi-carrier communication channel using various communication technologies, such as, but not limited to, Orthogonal Frequency Division Multiple Access (OFDM) communication technology (e.g., for downlink communication) or Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiment is not limited to this aspect. The OFDM signal may include multiple orthogonal subcarriers.

[0034] In some embodiments, the downlink resource grid can be used for downlink transmissions from any RAN node 111 to UE 101, while uplink transmissions can use a similar technique. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink for each time slot. This time-frequency plane representation is common practice in OFDM systems, making radio resource allocation intuitive. Each column and 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 time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid comprises multiple resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this can represent the minimum amount of resources that can currently be allocated. Several different physical downlink channels exist that are transmitted using such resource blocks.

[0035] According to various embodiments, UE 101 and RAN node 111 transmit (e.g., send and receive) data through licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). The licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum may include a 5 GHz band.

[0036] To operate in unlicensed spectrum, UE 101 and RAN node 111 can use Licensed Assisted Access (LAA), Enhanced LAA (eLAA), and / or other eLAA (feLAA) mechanisms. In these implementations, UE 101 and RAN node 111 can perform one or more known media sensing and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. Media / carrier sensing operations can be performed according to a Listen-After-Talk (LBT) protocol.

[0037] LBT is a mechanism in which a device (e.g., UE 101, RAN nodes 111, 112, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits data when the medium is sensed to be idle (or when a specific channel in the medium is sensed to be unoccupied). The medium sensing operation may include idle channel assessment (CCA), which utilizes at least energy detection (ED) to determine the presence of other signals on the channel to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with incumbent systems in unlicensed spectrum and with other LAA networks. ED may include sensing radio frequency (RF) energy in the intended transmission band for a period of time and comparing the sensed RF energy with a predetermined or configured threshold.

[0038] Typically, current systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). Here, when a WLAN node (e.g., a mobile station (MS) such as UE 101 or AP 106) intends to transmit, the WLAN node can first perform CCA before transmitting. Additionally, a backoff mechanism is used to avoid collisions when more than one WLAN node senses the channel as idle and transmits simultaneously. The backoff mechanism can be a counter randomly drawn within the contention window size (CWS), which increases exponentially upon collision and is reset to a minimum upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA for WLANs. In some implementations, the LBT process for DL ​​or UL transmission bursts that respectively include PDSCH or PUSCH transmissions can have an LAA contention window of variable length between X and Y extended CCA (ECCA) slots, where X and Y are the minimum and maximum values ​​of the CWS for LAA. In one example, the minimum CWS for LAA transmission can be 9 microseconds (μs); however, the size of the CWS and the maximum channel occupancy time (MCOT) (e.g., transmission burst) can be based on government regulatory requirements.

[0039] The LAA mechanism is based on the carrier aggregation (CA) technology of LTE-Advanced systems. In CA, each aggregated carrier is called a component carrier (CC). A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, thus the maximum aggregated bandwidth is 100 MHz. In Frequency Division Duplex (FDD) systems, the number of aggregated carriers can differ for DL ​​and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, an individual CC can have a different bandwidth than the other CCs. In Time Division Duplex (TDD) systems, the number of CCs and the bandwidth of each CC are typically the same for DL ​​and UL.

[0040] CA also includes separate serving cells to provide separate CCs. The coverage of serving cells may differ, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell, or primary cell (PCell), can provide the primary CC (PCC) for both UL and DL, and can handle Radio Resource Control (RRC) and Non-Access Stratum (NAS) related activities. Other serving cells are called secondary cells (SCells), and each SCell can provide a separate secondary CC (SCC) for both UL and DL. SCCs can be added and removed as needed, and changing the PCC may require UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all SCells can operate in unlicensed spectrum (referred to as "LAA SCells"), and LAA SCells are assisted by PCells operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE can receive a UL grant on the configured LAASCell, which indicates the start position of different Physical Uplink Shared Channels (PUSCHs) within the same subframe.

[0041] The Physical Downlink Shared Channel (PDSCH) carries user data and higher-layer signaling to UE 101. The Physical Downlink Control Channel (PDCCH) carries information such as the transmission format and resource allocation related to the PDSCH channel. It can also inform UE 101 of the transmission format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to UE 101b within the cell) can be performed at any RAN node 111 based on channel quality information fed back from any UE 101. Downlink resource allocation information can be transmitted on the PDCCH used (e.g., allocated to) each UE 101.

[0042] PDCCH can use Control Channel Elements (CCEs) to convey control information. Before mapping to resource elements, PDCCH complex-valued symbols are first organized into quadruplets, which are then permuted using a sub-block interleaver for rate matching. Each PDCCH can be transmitted using one or more of these CCEs, where each CCE can correspond to nine groups of four physical resource elements called Resource Element Groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. One or more CCEs can be used to transmit the PDCCH, depending on the size of the Downlink Control Information (DCI) and channel conditions. In LTE, four or more different PDCCH formats (e.g., aggregation levels, L=1, 2, 4, or 8) with different numbers of CCEs can be defined.

[0043] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the concepts described above. For example, some embodiments may use 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 Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to nine groups of four physical resource elements, referred to as Enhanced Resource Element Groups (EREGs). In some cases, there may be an additional number of EREGs for the ECCE.

[0044] RAN nodes 111 can be configured to communicate with each other via interface 112. In embodiments where system 100 is an LTE system, interface 112 can be an X2 interface 112. The X2 interface can be defined between two or more RAN nodes 111 connected to EPC 120 (e.g., two or more eNBs, etc.) and / or between two eNBs connected to EPC 120. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). X2-U can provide flow control mechanisms for user data packets transmitted via the X2 interface and can be used to transmit information about user data transfers between eNBs. For example, X2-U can provide specific sequence number information for user data transmitted from the primary eNB (MeNB) to the secondary eNB (SeNB); information about successful sequential transmission of PDCP PDUs from the SeNB to UE 101 for user data; information about PDCP PDUs not delivered to UE 101; information about the current minimum required buffer size at the SeNB for sending user data to the UE; and so on. X2-C can provide LTE intra-eNB access mobility functions, including context transmission from the source eNB to the destination eNB, user plane transmission control, load management functions, and inter-cell interference coordination functions.

[0045] In embodiments where system 100 is a 5G, NR, or 6G system, interface 112 may be an Xn interface 112. The Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gNBs) connected to the core network (CN) 120, between a RAN node 111 (e.g., a gNB) connected to the CN 120 and an eNB, and / or between two eNBs connected to the CN 120. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U can provide unsecured delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C can provide: management and error handling functions; functions for managing the Xn-C interface; and mobility support for UE 101 in connected modes (e.g., CM-CONNECTED), including functions for managing UE mobility in connected modes between one or more RAN nodes 111. Mobility support may include context delivery from the old (source) serving RAN node 111 to the new (destination) serving RAN node 111; and control of the user plane tunnel between the old (source) serving RAN node 111 and the new (destination) serving RAN node 111. The Xn-U protocol stack may include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer built on top of one or more UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may reside above the IP layer and may provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to one or more user plane and / or control plane protocol stacks shown and described herein.

[0046] RAN 110 is shown communicatively coupled to the core network—in this embodiment, the core network (CN) 120. CN 120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to consumers / subscribers (e.g., users of UE 101) connected to CN 120 via RAN 110. The term “network element” can describe a physical or virtualized device used to provide wired or wireless communication network services. The term “network element” can be considered synonymous with and / or referred to as: networked computer, network hardware, network device, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, virtualized network function (VNF), network function virtualization infrastructure (NFVI), and / or the like. Components of CN 120 may be implemented in a single physical node or separate physical nodes, including components that read and execute instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, Network Functions Virtualization (NFV) can be used to virtualize any or all of the aforementioned network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. A logical instantiation of CN 120 may be referred to as a network slice, and a logical instantiation of a portion of CN 120 may be referred to as a network subslice. NFV architectures and infrastructures can be used to virtualize one or more network functions, or to execute them by dedicated hardware onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, an NFV system can be used to execute a virtual or reconfigurable implementation of one or more EPC components / functions.

[0047] Typically, application server 130 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.). Application server 130 may also be configured to support one or more communication services (e.g., Internet Protocol Voice (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE 101 via EPC 120.

[0048] In some embodiments, RAN 110 may be connected to CN 120 via NG interface 113. In an embodiment, NG interface 113 may be divided into two parts: NG user plane (NG-U) interface 114, which carries service data between RAN node 111 and user plane function (UPF); and S1 control plane (NG-C) interface 115, which is the signaling interface between RAN node 111 and AMF.

[0049] The sixth-generation (6G) cellular system is envisioned to be implemented in a manner that can be described as “AI-native,” where AI and machine learning (ML) are indispensable, enabling advanced use cases and empowering intelligent network functions. Examples of such implementations can be seen in the 18th or 19th versions of the 3GPP specifications, such as 3GPP TR 38.843 V18.0.0 (2023-12) (“3GPP; Radio Access Networks Technical Specification Group; Study on Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface (Release 18)”), or 3GPP TS 29.520 V19.0.0 (2024-09) (“3GPP; Core Network and Terminals Technical Specification Group; 5G Systems; Network Data Analytics Services; Phase 3 (Release 19)”).

[0050] Some problems have arisen due to the spread of isolated AI / ML functions across various network layers and nodes. Figure 2 An example of isolated AI / ML functions is illustrated. As shown, these functions (e.g., Network Data Analysis Function (NWDAF) AI / ML in the core network and RAN Intelligent Controller (RIC) rApp AI / ML in the Radio Access Network (RAN)) can be modeled for different tasks from various service consumers (e.g., Policy Control Function (PCF), Session Management Function (SMF), Access and Mobility Management Function (AMF), Centralized Unit (CU), etc.). This isolated approach may lead to at least one of the following example technical challenges.

[0051] One challenge is inefficient model utilization. The silos of AI / ML models across different network functions can lead to a lack of knowledge sharing and reuse. Although commonalities may exist in certain layers or neurons, each model may operate independently, resulting in redundancy and missed opportunities to leverage shared learning across the network.

[0052] Another challenge is the limitation of service consumers' capabilities. Service consumers may have limited capabilities in customizing AI / ML functions. Legacy network architectures (e.g., NWDAF) may only allow direct inference requests and responses, without allowing users to modify or customize the analysis process according to their specific needs, or with limited options in this regard.

[0053] The AI ​​field has recently undergone a significant shift with the rise of foundational models. These models, trained on vast amounts of labeled / unlabeled data, can adapt to a wide range of downstream tasks, even across different data types. This advancement may mark a departure from traditional task-specific AI approaches. For example, techniques such as Low-Rank Adaptation (LoRA) enable foundational models to dynamically and on-the-fly specialization for specific use cases, as demonstrated by example use cases such as Apple's intelligent frameworks.

[0054] The embodiments described herein may involve or include a model adaptation network function (or model adaptation function), which serves as an interface between the common base foundation model and various service consumers. Figure 3 Examples of implementations of the Model Adaptive Network Function (MAF) according to some embodiments of this disclosure are illustrated. As shown, the proposed MAF serves as an interface between a general base model and various network functions (NFs), which act as service consumers. NFs can interact with customized MAFs via the 3GPP 6G Service-Based Interface (SBI). MAFs can interact with the general base model via implementation-specific interfaces. However, in some embodiments, NFs can also interact with the general base model via the 3GPP SBI interface for predefined inference services.

[0055] Using such model-adapted network functions can provide one or more of the following advantages: A common base model and model-adapted network functions can facilitate knowledge sharing between different network functions and different domains (RAN, core network (CN), etc.). Using model-adapted network functions and a common base model enables service consumers to dynamically customize AI models to meet their specific needs through adaptation techniques. Embodiments of this disclosure can improve the efficiency and flexibility of AI / ML frameworks in wireless networks and surpass older task-specific approaches.

[0056] Figure 4 Examples of integrating models in a wireless network architecture according to some embodiments of the present disclosure are shown. As illustrated, the integrated example components and functions may include a general base model and model adaptation functions.

[0057] In some embodiments, a general base model can be trained on a large amount of labeled / unlabeled data from the radio access network and core network, and even application data from the user equipment (UE) side. The general base model can be adapted to various downstream tasks according to different adapters.

[0058] In some embodiments, the model adaptation function can serve as an interface between a general base model and various network services. Various service consumers (e.g., PCF, SMF, AMF, CU, etc.) can send inference requests to the model adaptation function via, for example, 6G SBI, or service consumers can forward non-access stratum (NAS) messages to the model adaptation function via AMF, and so on.

[0059] In some embodiments, the model adaptation functionality may include one or more of the following: an adapter repository, dynamic adapter loading / switching, an SBI protocol handler, data transformation, or retrieval enhancement generation (RAG) functionality. In some embodiments, the model adaptation functionality may include more, fewer, or different functionalities, and this disclosure is not limiting in this regard. Figure 4 As can be seen, these functions are included in the model adaptation function, which is just one example. However, any one or more of these functions can be independent modules, and this disclosure does not impose any restrictions on this.

[0060] In some embodiments, the adapter repository may contain a set of adapters (e.g., a wide collection of adapters), each of which is fine-tuned for specific features or tasks in the network.

[0061] In some embodiments, the dynamic adapter loading / switching function can select an appropriate adapter (e.g., from an adapter repository) and insert it into the common base model when an inference request for a specific analysis task is received.

[0062] In some embodiments, the SBI protocol handler can support various subscription / notification and request / response processes and related protocols. In some embodiments, in request and response processing, the SBI protocol handler can manage request-response workflows where service consumers (e.g., network functions) can send inference requests to the model adaptation function. This process may include parsing incoming requests, which may specify details such as the analysis type (task), preferred accuracy level, time window for data analysis, and any other multimodal information to be used (e.g., text-based log data) as input. More detailed information about the inputs can be found in the model adaptation function service API design example described below. In some embodiments, in subscription and notification processing, the SBI protocol handler can support subscription-based mechanisms where service consumers (e.g., network functions) can subscribe to the model adaptation function for specific types of analysis or inference requests. When relevant events or data become available, the model adaptation function can proactively notify the subscribed services for timely and efficient information sharing.

[0063] In some embodiments, the data conversion function can convert between standardized 3GPP protocol data used by service consumers (e.g., network functions) and the internal data format (e.g., tensor data) and processing requirements of the model adaptation function.

[0064] In some embodiments, the Retrieval Enhancement Generation (RAG) function may include an enhancement information data warehouse or a prompt generation function. In some embodiments, the enhancement information data warehouse may store indexed data that provides information about specific network functions. In some embodiments, the prompt generation function may generate prompts for the base model by combining an input query with information retrieved from the enhancement information data warehouse.

[0065] Figure 5 A flowchart of a method 500 for dynamically customizing and integrating an underlying model according to some embodiments of the present disclosure is shown. Method 500 can be applied to model adaptation functions. For example, method 500 can be performed by means for model adaptation functions (e.g., one or more processors or other means including one or more processors), and the present disclosure is not limiting in this respect. As shown, method 500 may include operations 510 to 540. However, in some embodiments, method 500 may include more, fewer, or different operations to achieve dynamic customization and integration of the underlying model, and the present disclosure is not limiting in this respect.

[0066] At 510, (e.g., via an interface (e.g., a service-based interface (SBI)) a reasoning request related to the communication network is received from the service consumer. At 520, an adapter is determined (e.g., selected) from the adapter repository based on the reasoning request. At 530, the adapter is integrated into the general base model to obtain the analysis results for the reasoning request. At 540, the analysis results are provided to the service consumer via the interface as a reasoning response.

[0067] In some embodiments, the model adaptation function may receive analysis results in a first format (e.g., a format conforming to the model input) for a general base model and convert the analysis results from the first format to a second format (e.g., a format conforming to the 3GPP protocol) for the service consumer before providing an inference response to the service consumer.

[0068] In some embodiments, the inference request received from the service consumer adopts a second format for the service consumer, and the model adaptation function can convert the inference request from the second format to a first format for the general base model, and provide the converted inference request to the general base model for inference analysis.

[0069] In some embodiments, the service consumer may include network elements or network functions of the communication network, or external application functions (AF). In some embodiments, network elements or network functions of the communication network include PCF, SMF, AMF, CU, network exposure function (NEF), etc.

[0070] In some embodiments, inference requests are associated with subscription services, and the model adaptation function can update the analysis results when trigger conditions are met, and provide the updated analysis results to service consumers via an interface.

[0071] In some embodiments, the model adaptation function can retrieve augmentation information from the augmentation information data warehouse based on inference requests and provide the augmentation information to a general base model to generate analysis results.

[0072] Figure 5 This section describes methods for dynamically customizing and integrating base models from the perspective of model adaptation functionality. In contrast, Figure 6 A flowchart of a method 600 for dynamically customizing and integrating a base model according to some embodiments of the present disclosure is shown. The method 600 describes methods for dynamically customizing and integrating a base model from the perspective of a general base model.

[0073] Method 600 can be applied to a general-purpose base model. For example, method 600 can be executed by means of a general-purpose base model (e.g., one or more processors or other means including one or more processors), and this disclosure is not limiting in this respect. As shown, method 600 may include operations 610 to 640. However, in some embodiments, method 600 may include more, fewer, or different operations to enable dynamic customization and integration of the base model, and this disclosure is not limiting in this respect.

[0074] At 610, (e.g., via an interface) an inference request related to the communication network is received from the model adaptation function. At 620, an adapter associated with the inference request is integrated. This adapter is selected by the model adaptation function from an adapter repository based on the inference request. At 630, analysis is performed on the inference request based on the adapter to obtain the analysis results. At 640, the analysis results are provided to the model adaptation function via an interface.

[0075] In some embodiments, the general base model can obtain augmentation information related to the inference request from the model adaptation function and also perform analysis based on the augmentation information. In some embodiments, the augmentation information may be included in the inference request. In some embodiments, the augmentation information may be provided independently, i.e., not included in the inference request.

[0076] In some embodiments, inference requests and analysis results may be in a format suitable for a common underlying model.

[0077] In some embodiments, the general base model is trained based on data from multiple domains, including RAN, CN, and UE application data.

[0078] Back Figure 4 It can be combined Figure 4 An example describing a high-level workflow. As shown in the figure, at operation 1, the service consumer (e.g., PCF, SMF, AMF) sends an inference request to the model adaptation function. At operation 2, the model adaptation function selects an appropriate adapter based on the request and integrates that adapter with the general base model. The adapted model processes the request and performs the required analysis. The analysis results are converted from tensor data back to the appropriate protocol format. At operation 3, when using RAG technology, the prompt generation function selects relevant information (e.g., the most relevant information) from the augmented information data warehouse based on the input inference request and generates a new inference request as input to the base model. At operation 4, the model adaptation function sends a response back to the service consumer.

[0079] In some embodiments, the inference request data structure may support: a request ID (requestId) as an identifier provided by the optional client; an analyticsType specification; an accuracy level; a time window defined for the data analysis; input data parameters; optional custom adapter configuration; or optional RAG configuration.

[0080] In some embodiments, RAG configuration may include: a boolean flag for enabling / disabling RAG functionality; an input query string for contextual data retrieval; retrieval parameters; or an enhanced information data warehouse for indexed network-specific data. Retrieval parameters may specify the number of the top k documents to retrieve or an optional time range for data selection.

[0081] In some embodiments, the service application programming interface (API) can be designed to have the following endpoints: POST " / v1 / inference", for submitting inference requests; GET " / v1 / adapters", for retrieving available adapters; GET " / v1 / adapters / {adapterId}", for retrieving specific adapter information; or POST " / v1 / adapters", for uploading new adapters to the repository.

[0082] In some embodiments, the inference response structure may include: an inference state enumeration (InferenceStatusenum) (COMPLETED, FAILED, PARTIAL); a result object; a performance metric; or a timestamp indicating inference completion. The result object may include an inference value or a confidence score. The performance metric may track accuracy, latency, or the overall confidence score.

[0083] In some embodiments, the Sample Model Adaptation Functionality Service API may be designed as follows.

[0084]

[0085]

[0086]

[0087] This disclosure provides a method for dynamically integrating a common base model in a wireless network architecture, comprising: providing a common base model trained on multi-domain data from radio access networks, core networks, and user equipment application data; establishing a Model Adaptive Network Function (MAF) as an interface between the common base model and service consumers; and supporting real-time, on-demand model specialization through SBI.

[0088] The design proposed in this disclosure enables AI-as-a-Service (AIaaS) capabilities within a wireless network architecture to support: dynamic model customization, integration with existing network functions (PCF, SMF, AMF, CU), and flexible adaptation to diverse AI / ML tasks.

[0089] The proposed model adaptation network functionality may include: an adapter repository that includes task-specific fine-tuning adapters; a dynamic adapter loading and switching mechanism for handling inference requests; RAG functionality that includes an enhancement information data repository and cue generation capabilities; and an SBI protocol handler that supports request-response workflows, subscription and notification mechanisms, and data conversion between 3GPP protocols and model input formats.

[0090] In some embodiments, a high-level workflow for processing inference requests may include: receiving inference requests from service consumers selected from PCF, SMF, AMF, etc.; dynamically selecting an appropriate adapter based on the characteristics of a specific inference request; integrating the selected adapter with a general base model; processing the request through the adapted model to perform the required analysis; and converting the results from tensor data into an appropriate network protocol format.

[0091] In some embodiments, the implementation of RAG technology may include: using prompt generation functionality to select the most relevant information from an augmented information data warehouse; generating a new inference request by combining the selected information with the original input query; and providing the generated request as augmented input to the base model.

[0092] This disclosure introduces a model-adaptive network function that serves as an interface to a common underlying model in 6G systems, allowing service consumers to use custom adapters via their inference request API. This approach enables dynamic customization and integration of the underlying model within existing wireless network architectures, addressing the limitations of current task-specific AI implementations (NWDAF, RICrAPP, etc.). Furthermore, this method can also provide AI-as-a-Service (AIaaS) capabilities through NEF, similar to cloud-based AI platforms such as AWS SageMaker.

[0093] Figure 7 An example functional framework 700 for ML and / or RAN intelligence is depicted. Functional framework 700 includes a data collection function 705 that provides input data to model training function 710 and model inference function 715. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting and transformation) may or may not be performed in data collection function 705. Examples of input data may include: measurements from UEs, RAN nodes, and / or attached or alternative network entities; feedback from actor 720; and / or outputs from one or more ML models. The input data fed to model training function 710 is training data, and the input data fed to model inference function 715 is inference data.

[0094] Model training function 710 is responsible for performing ML model training, validation, and testing. As part of the model testing and / or model validation process, model training function 710 can generate model performance metrics. Examples of model performance metrics are discussed below. If needed, model training function 710 can also handle data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the training data provided by data collection function 705.

[0095] Model training function 710 performs model deployment / update, wherein model training function 710 initially deploys a trained, validated, and tested ML model to model inference function 715, and / or delivers one or more updated models to model inference function 715. Examples of model deployment and update are discussed below.

[0096] Model inference function 715 provides ML model inference outputs (e.g., statistical inference, prediction, decision-making, probability and / or probability distributions, actions, configurations, strategies, data analysis, results, optimizations, etc.). Model inference function 715 can provide model performance feedback to model training function 710 when applicable. Model performance feedback may include various performance metrics related to the generation of inference (e.g., any metrics discussed herein). Model performance feedback can be used to monitor the performance of the ML model when applicable. If necessary, model inference function 715 can also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the inference data provided by data collection function 705.

[0097] Model inference function 715 produces inference output, which is the inference generated by model inference function 715 when manipulating the ML model using inference data, or otherwise produced. Model inference function 715 provides the inference output to actor 720. The details of the inference output are related to the specific use case and may be based on the specific type of ML model being used.

[0098] Actor 720 is a function that receives inference output from model inference function 715 and triggers or otherwise performs corresponding operations based on the inference output. Actor 720 can trigger operations against other entities and / or itself. In some examples, actor 720 is an NES function, a mobility optimization function, and / or a load balancing function. Additionally or alternatively, the inference output is associated with NES, mobility optimization, and / or load balancing, and actor 720 is one or more RAN nodes that perform various NES operations, mobility optimization operations, and / or load balancing operations based on the inference.

[0099] The actor 720 can also provide feedback to the data collection function 705 for storage. The feedback includes information related to the actions performed by the actor 720. The feedback may include any information that might be needed to acquire training data (and / or test data and / or validation data), inference data, and / or data for monitoring the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0100] Figure 8An example AI / ML-assisted communication network including communication between ML Function (MLF) 802 and MLF 804 is depicted. In some implementations, ML models / entities may be used or utilized to facilitate wired and / or over-the-air communication between MLF 802 and MLF 804. In this embodiment, the operation of MLF 802 and MLF 804 conforms to 3GPP technical specifications and / or technical reports for 5G and / or 6G systems, such as any technical reports discussed herein. In some examples, the communication mechanism between MLF 802 and MLF 804 includes any suitable access technology and / or RAT, such as any technology and / or RAT discussed herein. Furthermore, Figure 8 The communication mechanism in can be Figure 1-7 and / or other components, devices, systems, networks and / or deployments described herein, or operating concurrently with them.

[0101] MLF 802 and 804 may correspond to any entity / component discussed herein. In one example, MLF 802 corresponds to the UE and MLF 804 corresponds to the gNB; or MLF 802 corresponds to the gNB and MLF 804 corresponds to the UE. In one example, MLF 802 is implemented by the UE and MLF 804 is implemented by the gNB; or MLF 802 is implemented by the gNB and MLF 804 is implemented by the UE. In another example, MLF 802 corresponds to MnF and / or MnS-P, and MLF 804 corresponds to the consumer, MnS-C, or vice versa. In this example, the groups of MLFs may be mutually exclusive, or some or all of the MLFs in the groups may overlap or be shared. Additionally or alternatively, some or all of the components / entities in individual MLF 802 and 804 may be implemented or operated by separate entities / components.

[0102] like Figure 8 As shown, MLF 802 and MLF 804 include various AI / ML-related components, functions, elements, or entities that can be implemented as hardware, software, firmware, and / or some combination thereof. In some examples, one or more AI / ML-related elements are implemented as part of the same hardware (e.g., integrated circuit, chip, or multiprocessor chip), software (e.g., program, process, engine, etc.), or firmware as at least one other element, function, element, or entity. AI / ML-related elements of MLF 802 may be the same as or similar to AI / ML-related elements of MLF 804. For brevity, the various elements will be described from the perspective of MLF 802, but it is understood that, unless explicitly stated otherwise, such description applies to similar named / numbered elements of MLF 804.

[0103] Data repository 815 is responsible for data collection and storage. As an example, data repository 815 may collect and store RAN configuration parameters, NF configuration parameters, measurement data, RLM data, key performance indicators (KPIs), SLAs, model performance indicators, knowledge base data, ground fact data, ML model parameters, hyperparameters, and / or other data used for model training, updates, and inference. In some examples, a data collection function (not shown) is part of or connected to data repository 815. The data collection function is a function that provides input data to MLTF 825 and model inference function 845. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) may or may not be performed in the data collection function. Examples of input data may include measurements from UEs, RAN nodes, and / or attached or alternative network entities; feedback from actors; and / or outputs from one or more ML models. The input data fed to MLTF 825 is training data, and the input data fed to model inference function 845 is inference data.

[0104] The collected data is stored in / through repository 815, and the stored data can be discovered and retrieved from data repository 815 by other components. For example, inference data selector / filter 850 can retrieve data from data repository 815 and provide that data to inference engine 845 to generate / determine inference. In various examples, MLF 802 is configured to discover and request data from data repository 815 in MLF 804, and / or vice versa. In these examples, data repository 815 of MLF 802 may be communicatively coupled to data repository 815 of MLF 804, so that the respective data repositories 815 can share collected data with each other. Additionally or alternatively, MLF 802 and / or MLF 804 are configured to discover and request data from one or more external sources and / or data storage systems / devices.

[0105] Training data selection / filter 820 is configured to generate training, validation, and test datasets for ML training (MLT) (or ML model training). One or more of these datasets may be extracted from data repository 815 or otherwise obtained. Data can be selected / filtered based on the specific ML model to be trained. The data may optionally be transformed, augmented, and / or preprocessed (e.g., normalized) before being loaded into the dataset. Training data selection / filter 820 may label the data in the dataset for supervised learning or leave the data unlabeled for unsupervised learning. The resulting dataset can then be fed into MLT function (MLTF) 825.

[0106] The MLTF 825 is responsible for training and updating (e.g., tuning and / or retraining) ML models. Selected models (or sets of models) can be trained using datasets (including training, validation, and testing) fed in from the training data selector / filter 820. The MLTF 825 generates trained and tested ML models that are ready for deployment. The generated trained and tested models can be stored in the model library 835. Additionally or alternatively, the MLTF 825 performs ML model training, validation, and testing. As part of the model testing and / or model validation process, the MLTF 825 can generate model performance metrics. Examples of model performance metrics are discussed below. If needed, the MLTF 825 can also handle data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the data collection capabilities and / or the training data provided by the training data selector / filter 820. The MLTF 825 performs model deployment / updates, whereby the MLTF 825 initially deploys a trained, validated, and tested ML model to the Model Inference Function 845, and / or delivers one or more updated models to the Model Inference Function 845. Examples of model deployment and updates are discussed below.

[0107] Model library 835 is responsible for the storage and exposure of ML models (trained and untrained). Various types of model data can be stored in model library 835. For example, model data may include (one or more) trained / updated models, model parameters, hyperparameters, and / or model metadata such as model performance metrics, hardware platform / configuration data, model execution parameters / conditions, etc. In some examples, model data may also include inferences made while running the ML model. Model data can be discovered and requested by other MLF components (e.g., training data selection / filter 820 and / or MLTF 825). In some examples, MLF 802 can discover and request model data from model library 835 of MLF 804. Additionally or alternatively, MLF 804 can discover and / or request model data from model library 835 of MLF 802. In some examples, MLF 804 can configure models, model parameters, hyperparameters, model execution parameters / conditions, and / or other ML model aspects in model library 835 of MLF 802. To indicate manageability, this paper also refers to the ML model as an ML entity; that is, the terms ML model and ML entity are interchangeable in this paper.

[0108] Model management function 840 is responsible for managing the ML models generated by MLTF 825. Such management functions may include: deploying trained models, monitoring ML entity performance, reporting ML entity validation and / or performance data, etc. When deploying a model, model management function 840 can allocate and schedule hardware and / or software resources for inference based on the received trained and tested model. For the purposes of this disclosure, the term "inference" refers to the process of generating statistical inference, predictions, decisions, probabilities and / or probability distributions, actions, configurations, policies, data analysis, results, optimizations, etc., based on new, unseen data (e.g., "input inference data") using one or more trained ML models. In some examples, the inference process may include: feeding input inference data to an ML model (e.g., inference engine 845), forward-passing the input inference data through the architecture / topology of the ML model, wherein the ML model performs computations on the data using its learned parameters (e.g., weights and biases), and predicting outputs. In some examples, the inference process may include data transformation prior to forward passing, wherein the input inference data is preprocessed or transformed to match the format required by the ML model. In performance monitoring, based on model performance KPIs and / or metrics, model management function 840 can decide to terminate a running model, start model retraining and / or tuning, select another model, etc. In the example, model management function 840 of MLF 804 can configure model management policies in MLF 802, and vice versa.

[0109] As described below, the inference data selection / filter 850 is responsible for generating the dataset for model inference at inference 845. For example, inference data can be extracted from the data repository 815. The inference data selection / filter 850 can select and / or filter data based on the deployed ML model. The data can be transformed, enhanced, and / or preprocessed in the same or similar manner as the training data selection / filtering (e.g., as described for training data selection filter 820). The generated inference dataset can be fed into the inference engine 845.

[0110] The inference engine 845 (also referred to as "model inference function 845", etc.) is responsible for performing / generating the inference described herein. The inference engine 845 consumes the inference dataset provided by the inference data selection / filter 850 and generates ML model inference output, which includes one or more inferences. For example, inference can be or include statistical inference, prediction, decision-making, probability and / or probability distribution, action, configuration, strategy, data analysis, outcome, optimization, etc. One or more inferences / one or more results may be provided to the performance measurement function 830. Where applicable, the model inference function 845 may provide model performance feedback to the MLTF 825 and / or the performance measurement function 830. Model performance feedback may include various performance metrics related to the generation of inference (e.g., any metrics discussed herein). Model performance feedback may be used, where applicable, to monitor the performance of the ML model. If necessary, the model inference function 845 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting and transformation) based on the inference data provided by the data collection function and / or the inference data selection / filter 850. Model inference function 845 generates inference output, which is the inference generated by model inference function 845 when running an ML model using inference data (set), or otherwise generated. The details of the inference output are related to the specific use case and can be based on the specific type of ML model being used.

[0111] In some examples, model inference function 845 provides inference output to an actor (not shown). An actor is a function, engine, component, device, system, network, and / or other entity that receives inference output from model inference function 845 and triggers or otherwise performs corresponding actions(s) based on the inference output. An actor may trigger actions against other entities and / or itself. In some examples, an actor is a Network Energy Saving (NES) function, a Mobility Robustness Optimization (MRO) function, a Load Balancing Optimization (LBO) function, and / or other Self-Organizing Network (SON) function, including any functions mentioned herein. Additionally or alternatively, the inference output is related to NES, MRO, and / or LBO, and the actor is one or more RAN nodes that perform various NES, MRO, and / or LBO operations based on inference. The actor may also provide feedback to performance measurement function 830 and / or data collection function / data repository 815 for storage. The actor feedback includes information related to the actions performed by the actor. For example, feedback includes any information that may be needed to obtain training data, test data and / or validation data; inference data; and / or data to monitor the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0112] Performance measurement function 830 is configured to measure model performance metrics (e.g., accuracy, momentum, precision, magnitude, recall / sensitivity, model bias, runtime latency, resource consumption, and / or other suitable metrics / measures, such as any of those discussed herein) of deployed and executing models based on one or more inference methods for monitoring purposes. Model performance data may be stored in data repository 815 and / or reported according to the validation reporting mechanism discussed herein.

[0113] The performance measurement function 830 can measure and / or predict performance metrics based on specific AI / ML tasks and other inputs / parameters of ML entities. Performance metrics can include model-based metrics and platform-based metrics. Model-based metrics are metrics related to the performance of the model itself and / or do not consider the underlying hardware platform. Platform-based metrics are related to the performance of the underlying hardware platform when running the ML model.

[0114] Model-based metrics can be based on specific types of ML models and / or AI / ML domains. For example, regression-related metrics can be used to predict regression-based ML models. Examples of regression-related metrics include error values, mean error, mean absolute error (MAE), mean reciprocal rank (MRR), mean squared error (MSE), root MSE (RMSE), correlation coefficient (R), coefficient of determination (R²), Golbraikh and Tropsha criteria, and / or other similar regression-related metrics, such as those discussed in the paper Naser et al. (Insights into Performance Fitness and Error Metrics for Machine Learning, arXiv:2006.00887v1 (17 May 2020) (“[Naser]”)).

[0115] In another example, correlation metrics can be used to predict correlation-related models. Examples of correlation metrics include accuracy, precision (also known as positive predictive value (PPV)), mean precision (mAP), negative predictive value (NPV), recall (also known as true positive rate (TPR) or sensitivity), specificity (also known as true negative rate (TNR) or selectivity), false positive rate, false negative rate, F-score (e.g., F1 score, F2 score, Fβ score, etc.), Matthews correlation coefficient (MCC), significance, receiver operating characteristic (ROC), area under the ROC curve (AUC), distance score, and / or other similar correlation metrics, such as those discussed in [Naser].

[0116] It is also possible to predict other or alternative model-based metrics, such as cumulative gain (CG), discounted CG (DCG), normalized DCG (NDCG), signal-to-noise ratio (SNR), peak signal-to-noise ratio (PSNR), structural similarity (SSIM), joint crossover (IoU), perplexity, bilingual evaluation surrogate study (BLEU) score, initial score, Wasserstein metric, Fréchet inception distance (FID), string metric, edit distance, Levenshtein distance, Damerau–Levenshtein distance, number of evaluation instances (e.g., iterations, duration, or events), learning rate (e.g., how quickly the algorithm reaches (converges) the optimal weights), learning rate decay (or weight decay), number and / or type of computations, number and / or type of multiply and accumulates (MAC), number and / or type of multiply adds (MAdds) operations, and / or other similar performance metrics related to ML model performance.

[0117] Platform-based metrics include latency, response time, throughput (e.g., the rate at which a processor or platform / system processes jobs), availability and / or reliability, power consumption (e.g., performance per watt and / or similar metrics), number of transistors, execution time (e.g., the amount of time to obtain inference and / or similar metrics), memory footprint, memory utilization, processor utilization, processor time, computation count, instructions per second (IPS), floating-point operations per second (FLOPS), and / or other similar performance metrics related to the performance of the ML model and / or the underlying hardware platform used to run the ML model.

[0118] Additionally or alternatively, surrogate metrics (e.g., metrics or attributes used as substitutes or substitutes for another metric or attribute) may be used to predict the performance of the ML model. For any of the performance metrics described above, any suitable data collection and / or measurement mechanism may be used to predict and / or measure the total, mean, and / or other distributions of such metrics.

[0119] Figure 9 A network 900 according to various embodiments is illustrated. The network 900 can operate in a manner conforming to the 3GPP technical specifications of LTE or 5G / NR systems. However, the example embodiments are not limited thereto, and the described embodiments are applicable to other networks that benefit from the principles described herein, such as future 3GPP systems, etc.

[0120] Network 900 may include UE 902, which may include any mobile or non-mobile computing device designed to communicate with RAN 904 via an over-the-air connection. UE 902 may be communicatively coupled to RAN 904 via a Uu interface. UE 902 may be, but is not limited to, a smartphone, tablet computer, wearable computing device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, dashboard, head-up display device, in-vehicle diagnostic device, dashboard mobile device, 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 device, machine-type communication device, M2M or D2D device, IoT device, etc.

[0121] In some embodiments, network 900 may include multiple UEs that are directly coupled to each other via sidelink interfaces. 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.

[0122] In some embodiments, UE 902 may also communicate with AP 906 via an over-the-air connection. AP 906 can manage a WLAN connection that can be used to offload some / all of network traffic from RAN 904. The connection between UE 902 and AP 906 can conform to any IEEE 802.11 protocol, where AP 906 can be a Wi-Fi® router. In some embodiments, UE 902, RAN 904, and AP 906 may utilize cellular-WLAN aggregation (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve UE 902 being configured by RAN 904 to utilize both cellular radio resources and WLAN resources.

[0123] RAN 904 may include one or more access nodes, such as AN 908. AN 908 can terminate the air interface protocol for UE 902 by providing access layer protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this way, AN908 can enable data / voice connectivity between CN 920 and UE 902. In some embodiments, AN 908 may be implemented in a separate device or as one or more software entities running on a server computer as part of, for example, a virtual network, which may be referred to as CRAN or a virtual baseband unit pool. AN 908 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN 908 may be a macrocell base station or a low-power base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell.

[0124] In embodiments where RAN 904 includes multiple ANs, they can be coupled to each other via an X2 interface (if RAN 904 is an LTE RAN) or an Xn interface (if RAN 904 is a 5G RAN). The X2 / Xn interface (which in some embodiments can be separated into a control / user plane interface) allows the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, and so on.

[0125] Each AN of RAN 904 can manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to UE 902. UE 902 can simultaneously connect to multiple cells provided by the same or different ANs of RAN 904. For example, UE 902 and RAN 904 can use carrier aggregation to allow UE 902 to connect to multiple component carriers, each component carrier corresponding to a Pcell or Scell. In dual connectivity scenarios, the first AN can be the primary node providing the MCG, and the second AN can be the secondary node providing the SCG. The first / second AN can be any combination of eNB, gNB, ng-eNB, etc.

[0126] RAN 904 provides an air interface via licensed or unlicensed spectrum. To operate in unlicensed spectrum, nodes can use LAA, eLAA, and / or feLAA mechanisms based on CA technology and PCell / Scell. Before accessing unlicensed spectrum, nodes can perform medium / carrier sensing operations based on, for example, a listen-before-talk (LBT) protocol.

[0127] In a V2X scenario, UE 902 or AN 908 can be or may act as an RSU, which can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU"; and so on. In one example, the RSU is a computing device coupled to roadside radio frequency circuitry that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic flow statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic flow. The RSU can provide extremely low-latency communication required for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. RSU components may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic flow signal controllers or backhaul networks.

[0128] In some embodiments, RAN 904 may be an LTE RAN 910 with an eNB, such as eNB 912. The LTE RAN 910 provides an LTE air interface with the following characteristics: 15 kHz SCS; CP-OFDM waveforms for DL ​​and SC-FDMA waveforms for UL; turbo coding for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; rely on PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and rely on CRS for cell search and initial acquisition, channel quality measurement, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface may operate in frequency bands below 6 GHz.

[0129] In some embodiments, RAN 904 can be an NG-RAN 914 with a gNB, such as gNB 916, or an NG-RAN 914 with an ng-eNB, such as ng-eNB 918. gNB 916 can connect to a 5G-enabled UE using a 5G NR interface. gNB 916 can connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 918 can also connect to the 5G core via an NG interface, but can connect to the UE via an LTE air interface. gNB 916 and ng-eNB 918 can connect to each other via an Xn interface.

[0130] In some embodiments, the NG interface can be divided into two parts: an NG user plane (NG-U) interface, which carries traffic data between the NG-RAN 914 node and the UPF 948 (e.g., the N3 interface), and an NG control plane (NG-C) interface, which is the signaling interface between the NG-RAN 914 node and the AMF 944 (e.g., the N2 interface).

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

[0132] In some embodiments, the 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adaptation of SCS. For instance, UE 902 can be configured with multiple BWPs, each configured with a different SCS. When a BWP change is indicated to UE 902, the transmitted SCS is also changed. Another example of a use case for BWPs relates to power saving. Specifically, multiple BWPs with different amounts of frequency resources (e.g., PRBs) can be configured for UE 902 to support data transmission under different traffic load scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with low traffic loads, while allowing power savings at UE 902 and, in some cases, at gNB 916. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic loads.

[0133] RAN 904 is communicatively coupled to CN 920, which includes network elements to provide various functions to support data and telecommunications services to customers / subscribers (e.g., users of UE 902). Components of CN 920 may be implemented in a single physical node or in separate physical nodes. In some embodiments, NFV may be used to virtualize any or all of the functions provided by the network elements of CN 920 onto physical computing / storage resources in servers, switches, etc. A logical instantiation of CN 920 may be referred to as a network slice, and a logical instantiation of a portion of CN 920 may be referred to as a network subslice.

[0134] In some embodiments, CN 920 may be LTE CN 922, which may also be referred to as EPC. LTE CN 922 may include MME 924, SGW 926, SGSN 928, HSS 930, PGW 932, and PCRF 934, which are coupled to each other via an interface (or "reference point"), as shown in the figure. The functions of the components of LTE CN 922 can be briefly described below.

[0135] The MME 924 enables mobility management functions to track the current location of the UE 902, facilitating paging, bearer activation / deactivation, handover, gateway selection, authentication, and more.

[0136] The SGW 926 can terminate the S1 interface to the RAN and route data packets between the RAN and the LTE CN 922. The SGW 926 can serve as a local mobility anchor point for handovers between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0137] The SGSN 928 can track the location of UE 902 and perform security functions and access control. Furthermore, the SGSN 928 can perform EPC inter-node signaling for mobility between different RAT networks; select PDN and S-GW according to MME 924; select MME for handover; and so on. The S3 reference point between MME 924 and SGSN 928 can enable user and bearer information exchange for mobility between 3GPP access networks in idle / active states.

[0138] The HSS 930 may include a database for network users, including reservation-related information to support network entities in managing communication sessions. The HSS 930 provides support for routing / roaming, authentication, authorization, naming / addressing resolution, location compliance, and more. An S6a reference point between the HSS 930 and the MME 924 enables the transmission of reservation and authentication data to authenticate / authorize user access to the LTE CN 920.

[0139] The PGW 932 can terminate an SGi interface toward a data network (DN) 936, which may include an application / content server 938. The PGW 932 can route data packets between the LTE CN 922 and the data network 936. The PGW 932 can be coupled to the SGW 926 via an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 932 may also include nodes for policy enforcement and charging data collection (e.g., PCEF). Furthermore, the SGi reference point between the PGW 932 and the data network 936 can be an external public or private PDN or an internal packet data network, such as a configuration for IMS services. The PGW 932 can be coupled to the PCRF 934 via a Gx reference point.

[0140] PCRF 934 is the policy and charging control element of LTE CN 922. PCRF 934 can be communicatively coupled with application / content server 938 to determine appropriate QoS and charging parameters for service flows. PCRF 932 can configure associated rules into PCEF (via Gx reference point) with appropriate TFT and QCI.

[0141] In some embodiments, CN 920 may be 5GC 940. 5GC 940 may include AUSF 942, AMF 944, SMF946, UPF 948, NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, and AF 960, which are coupled to each other via interfaces (or "reference points"), as shown in the figure. The functionality of the components of 5GC 940 can be briefly described below.

[0142] The AUSF 942 stores data for UE 902 authentication and handles authentication-related functions. The AUSF 942 facilitates a common authentication framework for various access types. In addition to communicating with other components of the 5GC 940 via a reference point, as shown in the figure, the AUSF 942 also presents a Nausf service-based interface.

[0143] The AMF 944 allows other functions of the 5GC 940 to communicate with UE 902 and RAN 904, and to subscribe to notifications regarding mobility events for UE 902. The AMF 944 can handle registration management (e.g., for registering UE 902), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 944 can provide transport for SM messages between UE 902 and SMF 946 and acts as a transparent broker for routing SM messages. The AMF 944 can also provide transport for SMS messages between UE 902 and the SMSF. The AMF 944 can interact with the AMFF 942 and UE 902 to perform various security anchoring and context management functions. Furthermore, the AMF 944 can be a termination point for the RAN CP interface, which may include or be the N2 reference point between the RAN 904 and the AMF 944; and the AMF 944 can be a termination point for NAS (N1) signaling, performing NAS encryption and integrity protection. The AMF 944 can also support NAS signaling with the UE 902 via the N3 IWF interface.

[0144] SMF 946 can be responsible for SM (e.g., session establishment, tunnel management between UPF 948 and AN 908); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuration of traffic manipulation at UPF 948 to route traffic to appropriate destinations; termination of interfaces for policy control functions; control portions for policy enforcement, charging, and QoS; lawful interception (for SM events and interfaces to the LI system); termination of the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent to AN 908 via N2 through AMF 944; and determining the SSC mode of the session. SM can refer to the management of PDU sessions, while a PDU session or "session" can refer to the PDU connectivity service that provides or enables the exchange of PDUs between UE 902 and data network 936.

[0145] The UPF 948 can serve as an anchor point for mobility within and between RATs, an external PDU session point for interconnection to the data network 936, and a branch point supporting multi-homed PDU sessions. The UPF 948 can also perform packet routing and forwarding, packet inspection, enforce policy rules in the user plane portion, legally intercept packets (UP collection), perform traffic usage reporting, perform QoS actions for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic authentication (e.g., SDF-to-QoS flow mapping), transport-level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 948 may include an uplink classifier to support traffic flow routing to the data network.

[0146] The NSSF 950 can select a set of network slice instances to serve UE 902. If needed, the NSSF 950 can also determine the allowed NSSAIs and the mapping to the pre-booked S-NSSAIs. The NSSF 950 can also determine, based on appropriate configuration and possibly by querying the NRF 954, the set of AMFs to be used for serving UE 902, or a list of candidate AMFs. The selection of a set of network slice instances for UE 902 can be triggered by the AMF 944 to which UE 902 has registered, through interaction with the NSSF 950, which can result in a change of AMF. The NSSF 950 can interact with AMF 944 via reference point N22; and can communicate with another NSSF in the visited network via reference point N31 (not shown). Furthermore, the NSSF 950 can present a service-based interface for NNSSF.

[0147] The NEF 952 can securely expose services and capabilities provided by 3GPP network functions, internal exposure / re-exposure, AFs (e.g., AF 960), edge computing, or fog computing systems, etc., to third parties. In this embodiment, the NEF 952 can authenticate, authorize, or suppress AFs. The NEF 952 can also translate information exchanged with the AF 960 and information exchanged with internal network functions. For example, the NEF 952 can translate between AF service identifiers and internal 5GC information. The NEF 952 can also receive information from other NFs based on their exposure capabilities. This information can be stored as structured data at the NEF 952 or stored at a data storage NF using a standardized interface. The stored information can then be re-exposed by the NEF 952 to other NFs and AFs, or used for other purposes, such as parsing. Furthermore, the NEF 952 can expose the Nnef's service-based interface.

[0148] NRF 954 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to them. NRF 954 also maintains information about available NF instances and the services they support. As used herein, terms like "instantiation" can refer to the creation of an instance, while "instance" can refer to the actual occurrence of an object, which can happen, for example, during the execution of program code. Furthermore, NRF 954 can present a service-based interface for NnRF.

[0149] PCF 956 can provide policy rules to control plane functions to enable their enforcement and also supports a unified policy framework to constrain network behavior. PCF 956 can also enable front-ends to access reservation information related to policy decisions in the UDR of UDM 958. In addition to communicating with functions via reference points as shown in the figure, PCF 956 can also present an NPCF service-based interface.

[0150] The UDM 958 can handle reservation-related information to support network entities in managing communication sessions and can store reservation data for UE 902. For example, reservation data can be communicated via the N8 reference point between the UDM 958 and AMF 944. The UDM 958 may include two parts: an application front-end and a UDR. The UDR can store reservation data and policy data for the UDM 958 and PCF 956, and / or store structured data and application data (including PFDs for application detection and application request information for multiple UE 902) for the NEF 952. The Nudr's service-based interface can be presented by the UDR 221 to allow the UDM 958, PCF 956, and NEF 952 to access a specific set of stored data, as well as to read, update (e.g., add, modify), delete, and notify of relevant data changes in the reservation UDR. The UDM may include a UDM-FE, which is responsible for handling credentials, location management, reservation management, etc. Several different front-ends can serve the same user in different transactions. The UDM-FE accesses reservation information stored in the UDR and performs authentication credential processing, user identity disposal, access authorization, registration / mobility management, and reservation management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 958 can also present a Nudm service-based interface.

[0151] The AF 960 can provide application impact on traffic routing, provide access to NEF, and enable interaction with policy frameworks for policy control.

[0152] In some embodiments, the 5GC 940 can enable edge computing by selecting an operator / third-party service to be geographically close to the point where the UE 902 is attached to the network. This can reduce latency and load on the network. To provide edge computing implementation, the 5GC 940 can select a UPF 948 close to the UE 902 and perform traffic manipulation from the UPF 948 to the data network 936 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 960. In this way, the AF 960 can influence UPF (re)selection and traffic routing. Based on operator deployment, when the AF 960 is considered a trusted entity, the network operator can allow the AF 960 to interact directly with the relevant NF. In addition, the AF 960 can expose a service-based interface of the Naf.

[0153] Data network 936 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, such as application / content servers 938.

[0154] Figure 10 A wireless network 1000 according to various embodiments is illustrated schematically. The wireless network 1000 may include a UE 1002 that communicates wirelessly with an AN 1004. The UE 1002 and the AN 1004 may be components with similar names as described elsewhere herein and are substantially interchangeable with these components.

[0155] UE 1002 can be communicatively coupled to AN 1004 via connection 1006. Connection 1006 is illustrated as an air interface for communication coupling and can comply with cellular communication protocols, such as LTE or 5G NR protocols operating at mmWave or sub-6 GHz frequencies.

[0156] UE 1002 may include a host platform 1008 coupled to a modem platform 1010. Host platform 1008 may include application processing circuitry 1012, which may be coupled to protocol processing circuitry 1014 of modem platform 1010. Application processing circuitry 1012 may run various applications for UE 1002 to source / pool application data. Application processing circuitry 1012 may further implement one or more layer operations to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0157] Protocol processing circuitry 1014 can implement one or more layer operations to facilitate the transmission or reception of data via connection 1006. Layer operations implemented by protocol processing circuitry 1014 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0158] The modem platform 1010 may also include digital baseband circuitry 1016, which implements one or more layer operations in the network protocol stack that are "below" the layer operations performed by the protocol processing circuitry 1014. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functionality, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding (which may include one or more of space-time, space-frequency, or spatial coding), reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, blind decoding of control channel signals, and other related functions.

[0159] The modem platform 1010 may also include transmitting circuitry 1018, receiving circuitry 1020, RF circuitry 1022, and an RF front end (RFFE) 1024, which may include or be connected to one or more antenna panels 1026. In short, transmitting circuitry 1018 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; receiving circuitry 1020 may include an analog-to-digital converter, a mixer, an IF component, etc.; RF circuitry 1022 may include a low-noise amplifier, a power amplifier, a power point tracking component, etc.; and RFFE 1024 may include filters (e.g., surface acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of components such as the transmitting circuit 1018, receiving circuit 1020, RF circuit 1022, RFFE 1024, and antenna panel 1026 (generally referred to as the "transmit / receive assembly") can depend on the details of the specific implementation, such as whether the communication is TDM or FDM, at mmWave or below 6 GHz, etc. In some embodiments, the transmit / receive assembly may be arranged in multiple parallel transmit / receive chains, may be arranged in the same or different chips / modules, etc.

[0160] In some embodiments, the protocol processing circuitry 1014 may include one or more instances of control circuitry (not shown) to provide control functions for the transmitting / receiving components.

[0161] UE reception can be established and established via antenna panel 1026, RFFE 1024, RF circuit 1022, receiving circuit 1020, digital baseband circuit 1016, and protocol processing circuit 1014. In some embodiments, antenna panel 1026 can receive transmissions from AN 1004 via receive beamforming signals received by a plurality of antennas / antenna elements of one or more antenna panels 1026.

[0162] UE transmission can be established and established via the protocol processing circuitry 1014, digital baseband circuitry 1016, transmission circuitry 1018, RF circuitry 1022, RFFE 1024, and antenna panel 1026. In some embodiments, the transmission components of UE 1004 can apply a spatial filter to the data to be transmitted to form a transmission beam emitted by the antenna elements of antenna panel 1026.

[0163] Similar to UE 1002, AN 1004 may include a host platform 1028 coupled to a modem platform 1030. Host platform 1028 may include application processing circuitry 1032 coupled to protocol processing circuitry 1034 of modem platform 1030. The modem platform may also include digital baseband circuitry 1036, transmitting circuitry 1038, receiving circuitry 1040, RF circuitry 1042, RFFE circuitry 1044, and antenna panel 1046. Components of AN 1004 may be similar to those of similarly named components in UE 1002 and are substantially interchangeable. In addition to performing data transmission / reception as described above, components of AN 1008 may perform various logical functions, including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0164] Figure 11 The block diagram illustrates components, according to some example embodiments, capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein. Specifically, Figure 11 A schematic representation of hardware resources 1100 is shown, including one or more processors (or processor cores) 1110, one or more memory / storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via bus 1140 or other interface circuitry. In embodiments utilizing node virtualization (e.g., NFV), a hypervisor 1102 may be executed to provide an execution environment for one or more network slices / subslices utilizing hardware resources 1100.

[0165] Processor 1110 may include, for example, processor 1112 and processor 1114. Processor 1110 may be, for example, 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 DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination of these.

[0166] The memory / storage device 1120 may include main memory, disk storage devices, or any suitable combination thereof. The memory / storage device 1120 may include, but is not limited to, any type of volatile, non-volatile, or semi-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 devices, and so on.

[0167] Communication resource 1130 may include interconnect or network interface controllers, components, or other suitable devices to communicate via network 1108 with one or more peripheral devices 1104 or one or more databases 1106 or other network elements. For example, communication resource 1130 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Low Energy Bluetooth®) components, Wi-Fi® components, and other communication components.

[0168] Instructions 1150 may include software, programs, applications, applets, or other executable code for causing at least any one of the processors 1110 to perform any one or more of the methods discussed herein. Instructions 1150 may reside wholly or partially within at least one of the processors 1110 (e.g., within the processor's cache memory), within memory / storage device 1120, or any suitable combination thereof. Furthermore, any portion of instructions 1150 may be transferred from any combination of peripheral device 1104 or database 1106 to hardware resource 1100. Therefore, the memory of processor 1110, memory / storage device 1120, peripheral device 1104, and database 1106 are examples of computer-readable and machine-readable media.

[0169] Figure 12 Network 1200 is illustrated according to various embodiments. Network 1200 can operate in a manner conforming to 3GPP technical specifications or technical reports for 6G systems. In some embodiments, network 1200 can operate simultaneously with network 900. For example, in some embodiments, network 1200 can share one or more frequency or bandwidth resources with network 900. As a specific example, a UE (e.g., UE 1202) can be configured to operate in both network 1200 and network 900. This configuration may be based on the UE including circuitry configured to communicate with the frequency and bandwidth resources of both network 900 and network 1200. Generally, several elements of network 1200 may share one or more characteristics with elements of network 900. For the sake of brevity and clarity, these elements may not be repeated in the description of network 1200.

[0170] Network 1200 may include UE 1202, which may include any mobile or non-mobile computing device designed to communicate with RAN 1208 via an over-the-air connection. UE 1202 may be similar to, for example, UE 902. UE 1202 may be, but is not limited to, a smartphone, tablet computer, wearable computing device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, dashboard, head-up display device, in-vehicle diagnostic device, dashboard mobile device, 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 device, machine-type communication device, M2M or D2D device, IoT device, etc.

[0171] Although Figure 12Not specifically shown, but in some embodiments, network 1200 may include multiple UEs that are directly coupled to each other via sidelink interfaces. 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 in Figure 12 Not specifically shown, but UE 1202 can be used with AP (e.g., reference). Figure 9 The AP 906 described is coupled in communication. Furthermore, although in Figure 12 Not specifically shown, but in some embodiments, RAN 1208 may include one or more ANs, for example, as referenced. Figure 9 The AN908 described. RAN 1208 and / or the AN of RAN 1208 may be referred to as a base station (BS), RAN node, or some other term or name.

[0172] UE 1202 and RAN 1208 can 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 the terahertz (THz) or sub-THz bandwidth, or combined communication and sensing. As used herein, the term "combined communication and sensing" can refer to a system that implements wireless communication and radar-based sensing via various types of multiplexing. As used herein, THz or sub-THz bandwidth can refer to communication in the frequency range of 80 GHz and above. This frequency range may additionally or alternatively be referred to as the "millimeter wave" or "mmWave" frequency range.

[0173] RAN 1208 enables communication between UE 1202 and 6G core network (CN) 1210. Specifically, RAN 1208 facilitates the transmission and reception of data between UE 1202 and 6G CN 1210. 6G CN 1210 may include various functions such as NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, AF 960, SMF 946, and AUSF 942. Figure 12 As shown, 6G CN 1210 may also include UPF 948 and DN 936.

[0174] In addition, RAN 1208 may include various additional functions that are additions to or replacements for functions of traditional cellular networks (such as 4G or 5G networks). Two such functions may include Computation Control Function (Comp CF) 1224 and Computation Service Function (Comp SF) 1236. Comp CF 1224 and Comp SF 1236 may be parts or functions of the Computation Service Plane. CompCF 1224 may be a control plane function that provides functions such as: management of Comp SF 1236, generation and management of computation task contexts (e.g., creation, reading, modification, deletion), interaction with the underlying computation infrastructure for computation resource management, etc. Comp SF 1236 may be a user plane function that acts as an interface gateway between computation service users (e.g., UE 1202) and the computation nodes behind the CompSF instance. Some functions of Comp SF 1236 may include: parsing computation service data received from users to compute tasks that can be performed by the computation nodes; maintaining the service mesh ingress gateway or service API gateway; enforcing service and charging policies; performance monitoring and telemetry collection, etc. In some embodiments, a Comp SF 1236 instance can serve as a user plane gateway for a cluster of compute nodes. A Comp CF 1224 instance can control one or more Comp SF 1236 instances.

[0175] Two other such functions may include a communication control function (Comm CF) 1228 and a communication service function (CommSF) 1238, which may be part of the communication service plane. Comm CF 1228 may be a control plane function for managing Comm SF 1238, creating / configuring / releasing communication sessions, and managing communication session contexts. Comm SF 1238 may be a user plane function for data transfer. Comm CF 1228 and Comm SF 1238 can be considered upgrades to SMF 946 and UPF948, for which reference has been made. Figure 9 The 5G system described in the document. Upgrades provided by Comm CF 1228 and Comm SF 1238 enable service-aware transport. For legacy data transmission (e.g., 4G or 5G), SMF 946 and UPF 948 can still be used.

[0176] Two other such functions may include a data control function (Data CF) 1222 and a data service function (Data SF) 1232, which may be part of the data service plane. Data CF 1222 may be a control plane function and provide functions such as data SF 1232 management, data service creation / configuration / release, data service context management, etc. Data SF 1232 may be a user plane function and act as a gateway between data service users (e.g., various functions of UE 1202 and 6G CN 1210) and the data service endpoints behind the gateway. Specific functions may include: parsing data service user data and forwarding it to the appropriate data service endpoint, generating billing data, and reporting data service status.

[0177] Another such function could be the Service Orchestration and Chaining (SOCF) function 1220, which can discover, orchestrate, and chain communication / computing / data services provided by functions within the network. Upon receiving a service request from a user, SOCF 1220 can interact with one or more of Comp CF 1224, Comm CF 1228, and Data CF 1222 to identify instances of Comp SF 1236, Comm SF 1238, and Data SF 1232, configure service resources, and generate a service chain that may contain multiple instances of Comp SF 1236, Comm SF 1238, and Data SF 1232 and their associated compute endpoints. Workload processing and data movement can then be performed within the generated service chain. SOCF 1220 can also be responsible for maintaining, updating, and releasing the created service chains.

[0178] Another such function could be the service registration function (SRF) 1214, which can act as a registry center for system services provided in the user plane, such as services provided by service endpoints behind the Comp SF 1236 and Data SF1232 gateways, as well as services provided by UE 1202. SRF 1214 can be considered a counterpart to NRF 954, which can act as a registry center for network functions.

[0179] Other such capabilities may include an evolved service communication proxy (eSCP) and a service infrastructure control function (SICF) 1226, which provide service communication infrastructure for control plane services and user plane services. The eSCP may be related to the 5G service communication proxy (SCP) and adds user plane service communication proxy capabilities. The eSCP is therefore expressed as two parts: eCSP-C 1212 and eSCP-U 1234, used for the control plane service communication proxy and the user plane service communication proxy, respectively. SICF 1226 can control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configuration, performance monitoring, and more.

[0180] Another such function is AMF 1244. AMF 1244 can be similar to 944, but with additional functionality. Specifically, AMF 1244 may include potential function refactoring, such as moving message forwarding functionality from AMF 1244 to RAN 1208.

[0181] Another such feature is the service orchestration exposure function (SOEF) 1218. SOEF can be configured to expose service orchestration and chaining services to external users (such as applications).

[0182] UE 1202 may include additional functionality called Computational Client Service Function (comp CSF) 1204. comp CSF 1204 may have both control plane and user plane functions and may interact with corresponding network-side functions (e.g., SOCF 1220, Comp CF 1224, Comp SF 1236, Data CF 1222, and / or Data SF 1232) to perform service discovery, request / response, computational task workload exchange, and so on. Comp CSF 1204 may also cooperate with network-side functions to determine whether computational tasks should run on elements of UE 1202, RAN 1208, and / or 6G CN 1210.

[0183] UE 1202 and / or Comp CSF 1204 may include a service mesh agent 1206. The service mesh agent 1206 may act as a proxy for service-to-service communication in the user plane. The functions of the service mesh agent 1206 may include one or more of addressing, security, load balancing, etc.

[0184] The following paragraphs describe examples of various embodiments.

[0185] Example 1 includes an apparatus for model adaptation functionality, comprising: an interface; and a processor coupled to the interface, wherein the processor is configured to: receive, via the interface, a communication network-related inference request from a service consumer; determine an adapter from an adapter repository based on the inference request; integrate the adapter into a general base model to obtain an analysis result for the inference request; and provide the analysis result as an inference response to the service consumer via the interface.

[0186] Example 2 includes the apparatus described in Example 1 or any other example herein, wherein the interface includes a service-based interface (SBI).

[0187] Example 3 includes the apparatus described in Example 1 or any other example herein, wherein the processor is further configured to: receive the analysis results in a first format for the general underlying model; and convert the analysis results from the first format to a second format for the service consumer before providing the inference response to the service consumer.

[0188] Example 4 includes the apparatus described in Example 1 or any other example herein, wherein the inference request received from the service consumer is in a second format for the service consumer, and wherein the processor is further configured to: convert the inference request from the second format to a first format for the general base model; and provide the converted inference request to the general base model for inference analysis.

[0189] Example 5 includes the apparatus described in Example 1 or any other example herein, wherein the service consumer includes: network elements or network functions of the communication network, or external application functions (AF).

[0190] Example 6 includes the apparatus described in Example 5 or any other example herein, wherein the network elements or network functions of the communication network include: policy control function (PCF), session management function (SMF), access and mobility management function (AMF), central unit (CU), or network exposure function (NEF).

[0191] Example 7 includes the apparatus described in Example 1 or any other example herein, wherein the inference request is associated with a subscription service, and wherein the processor is further configured to: update the analysis results when a triggering condition is met; and provide the updated analysis results to the service consumer via the interface.

[0192] Example 8 includes the apparatus described in Example 1 or any other example herein, wherein the processor is further configured to: retrieve augmented information from the augmented information data warehouse based on the inference request; and provide the augmented information to the general base model to generate the analysis results.

[0193] Example 9 includes the apparatus described in Example 1 or any other example herein, wherein the inference request includes: a request ID; an analysis type specification; an accuracy level; a time window; input data parameters; a custom adapter configuration; or a retrieval enhancement generation (RAG) configuration.

[0194] Example 10 includes the apparatus described in Example 9 or any other example herein, wherein the RAG configuration includes: a flag for enabling / disabling RAG functionality; an input query string for contextual data retrieval; retrieval parameters; or an enhanced information data warehouse.

[0195] Example 11 includes the apparatus described in Example 1 or any other example herein, wherein the inference response includes: an inference state enumeration; a result object; a performance metric; or a timestamp indicating inference completion.

[0196] Example 12 includes the apparatus described in Example 11 or any other example herein, wherein the result object includes: an inference value; or a confidence score.

[0197] Example 13 includes the apparatus described in Example 11 or any other example herein, wherein the performance metrics include: accuracy; latency; or overall confidence score.

[0198] Example 14 includes an apparatus for a general base model, comprising: an interface; and a processor coupled to the interface, wherein the processor is configured to: receive, via the interface, an inference request related to a communication network from a model adaptation function; integrate an adapter associated with the inference request, wherein the adapter is selected by the model adaptation function from an adapter repository based on the inference request; perform analysis on the inference request based on the adapter to obtain analysis results; and provide the analysis results to the model adaptation function via the interface.

[0199] Example 15 includes the apparatus described in Example 14 or any other example herein, wherein the processor is further configured to: obtain augmentation information related to the inference request from the model adaptation function; and also perform the analysis based on the augmentation information.

[0200] Example 16 includes the apparatus described in Example 15 or any other example herein, wherein the enhanced information is included in the inference request.

[0201] Example 17 includes the apparatus described in Example 14 or any other example herein, wherein the inference request and the analysis result are in a format specific to the general underlying model.

[0202] Example 18 includes the apparatus described in Example 14 or any other example herein, wherein the general base model is trained based on cross-domain data from radio access network (RAN), core network (CN), or user equipment (UE) application data.

[0203] Example 19 includes the apparatus described in Example 14 or any other example herein, wherein the model adaptation function acts as an interface between the general base model and the service consumer.

[0204] Example 20 includes the apparatus described in Example 19 or any other example herein, wherein the service consumer includes: network elements or network functions of the communication network, or external application functions (AF).

[0205] Example 21 includes a method for model adaptation functionality, comprising: receiving a communication network-related inference request from a service consumer via an interface; determining an adapter from an adapter repository based on the inference request; integrating the adapter into a general base model to obtain analysis results for the inference request; and providing the analysis results as an inference response to the service consumer via the interface.

[0206] Example 22 includes the methods described in Example 21 or any other example herein, wherein the interface includes a service-based interface (SBI).

[0207] Example 23 includes the method described in Example 21 or any other example herein, further comprising: receiving the analysis results in a first format for the general underlying model; and converting the analysis results from the first format to a second format for the service consumer before providing the inference response to the service consumer.

[0208] Example 24 includes the method described in Example 21 or any other example herein, wherein the inference request received from the service consumer is in a second format for the service consumer, and wherein the method further includes: converting the inference request from the second format to a first format for the general base model; and providing the converted inference request to the general base model for inference analysis.

[0209] Example 25 includes the method described in Example 21 or any other example herein, wherein the service consumer includes: network elements or network functions of the communication network, or external application functions (AF).

[0210] Example 26 includes the method described in Example 25 or any other example herein, wherein the network elements or network functions of the communication network include: policy control function (PCF), session management function (SMF), access and mobility management function (AMF), central unit (CU), or network exposure function (NEF).

[0211] Example 27 includes the method described in Example 21 or any other example herein, wherein the inference request is associated with a subscription service, and wherein the method further includes: updating the analysis results when a triggering condition is met; and providing the updated analysis results to the service consumer via the interface.

[0212] Example 28 includes the method described in Example 21 or any other example herein, further comprising: retrieving augmented information from the augmented information data warehouse based on the inference request; and providing the augmented information to the general base model to generate the analysis results.

[0213] Example 29 includes the method described in Example 21 or any other example herein, wherein the inference request includes: a request ID; an analysis type specification; an accuracy level; a time window; input data parameters; a custom adapter configuration; or a retrieval enhancement generation (RAG) configuration.

[0214] Example 30 includes the method described in Example 29 or any other example herein, wherein the RAG configuration includes: a flag for enabling / disabling RAG functionality; an input query string for contextual data retrieval; retrieval parameters; or an enhanced information data warehouse.

[0215] Example 31 includes the method described in Example 21 or any other example herein, wherein the inference response includes: an inference state enumeration; a result object; a performance metric; or a timestamp indicating inference completion.

[0216] Example 32 includes the method described in Example 31 or any other example herein, wherein the result object includes: an inference value; or a confidence score.

[0217] Example 33 includes the method described in Example 31 or any other example herein, wherein the performance metrics include: accuracy; latency; or overall confidence score.

[0218] Example 34 includes a method for a general base model, comprising: receiving a communication network-related inference request from a model adaptation function; integrating an adapter associated with the inference request, wherein the adapter is selected by the model adaptation function from an adapter repository based on the inference request; performing analysis on the inference request based on the adapter to obtain analysis results; and providing the analysis results to the model adaptation function.

[0219] Example 35 includes the method described in Example 34 or any other example herein, further comprising: obtaining augmentation information related to the inference request from the model adaptation function; and also performing the analysis based on the augmentation information.

[0220] Example 36 includes the method described in Example 35 or any other example herein, wherein the enhanced information is included in the inference request.

[0221] Example 37 includes the method described in Example 34 or any other example herein, wherein the inference request and the analysis results are in a format specific to the general underlying model.

[0222] Example 38 includes the method described in Example 34 or any other example herein, wherein the general base model is trained based on cross-domain data from radio access network (RAN), core network (CN), or user equipment (UE) application data.

[0223] Example 39 includes the method described in Example 34 or any other example herein, wherein the model adaptation function acts as an interface between the general base model and the service consumer.

[0224] Example 40 includes the method described in Example 39 or any other example herein, wherein the service consumer includes: network elements or network functions of the communication network, or external application functions (AF).

[0225] Example 41 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by processing circuitry, cause the processing circuitry to perform the methods described in any of Examples 21-33 or any other example herein.

[0226] Example 42 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by processing circuitry, cause the processing circuitry to perform the methods described in any of Examples 34-40 or any other example herein.

[0227] Embodiments of this disclosure are specifically disclosed in the appended claims for methods, storage media, apparatus, and computer program products, wherein any feature mentioned in one claim class (e.g., method) may also be claimed in another claim class (e.g., system). Dependencies or references in the appended claims are chosen solely for formal reasons. However, any subject matter arising from an intentional retrospective to any prior claim (particularly multiple dependencies) may also be claimed, such that any combination of claims and their features is disclosed and may be claimed, regardless of the dependency chosen in the appended claims. Claimable subject matter includes not only combinations of features listed in the appended claims but also any other combination of features in the claims, wherein each feature mentioned in a claim may be combined with any other feature or combination of features in the claims. Furthermore, any embodiments and features described or depicted herein may be claimed in individual claims and / or in any combination with any embodiments or features described or depicted herein or with any features of the appended claims.

[0228] The foregoing description of one or more embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings, or may be obtained from practice with various embodiments.

[0229] The foregoing description of block diagrams and flowcharts of systems, methods, apparatuses, and / or computer program products according to various embodiments has described certain aspects of this disclosure. It should be understood that one or more blocks in the block diagrams and flowcharts, as well as combinations of blocks in the block diagrams and flowcharts, can be implemented by computer-executable program instructions. Similarly, according to some embodiments, some blocks in the block diagrams and flowcharts may not necessarily need to be executed in the order presented, or may not need to be executed at all.

[0230] These computer-executable program instructions can be loaded onto a special-purpose computer or other specific machine, processor, or other programmable data processing apparatus to produce a particular machine, such that these instructions, which execute on the computer, processor, or other programmable data processing apparatus, create means for implementing one or more functions specified in one or more flowchart blocks. These computer program instructions can also be stored in a computer-readable storage medium or memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of art comprising instructional means for implementing one or more functions specified in a flowchart block or block. As an example, some embodiments may provide a computer program product comprising a computer-readable storage medium having computer-readable program code or program instructions implemented therein, the computer-readable program code being adapted to be executed to implement one or more functions specified in one or more flowchart blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide elements or steps for implementing the functions specified in one or more flowchart blocks.

[0231] Therefore, blocks in block diagrams and flowcharts support combinations of means for performing a specified function, combinations of elements or steps for performing a specified function, and program instruction means for performing a specified function. It will also be understood that each block in a block diagram and flowchart, as well as combinations of blocks in block diagrams and flowcharts, can be implemented by a dedicated, hardware-based computer system or a combination of dedicated hardware and computer instructions that performs the specified function, element, or step.

[0232] Conditional language, such as “may” or “possibly,” unless explicitly stated otherwise or otherwise understood in the context in which it is used, is generally intended to convey that certain implementations may include certain features, elements, and / or operations, while other implementations do not. Therefore, such conditional language is generally not intended to imply that features, elements, and / or operations are necessary in any way for one or more implementations, or that one or more implementations must include logic for determining whether such features, elements, and / or operations are included in or will be performed in any particular implementation, with or without user input or prompting.

[0233] Many modifications and other embodiments of this disclosure set forth herein will clearly benefit from the teachings presented in the foregoing description and associated drawings. Therefore, it should be understood that this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terminology is used herein, it is used only in a general and descriptive sense and not for limiting purposes.

Claims

1. A device for model adaptation function, comprising: interface; and The processor coupled to the interface, The processor is used for: Receive inference requests related to the communication network from the service consumer via the interface; Based on the inference request, determine the adapter from the adapter repository; The adapter is integrated into a general base model to obtain analysis results for the inference request; and The analysis results are provided to the service consumer as an inference response via the interface. The interface includes a service-based interface (SBI).

2. The apparatus according to claim 1, wherein, The processor is also used for: The analysis results are received in a first format for the general underlying model; and Before providing the inference response to the service consumer, the analysis results are converted from the first format to a second format for the service consumer.

3. The apparatus according to claim 1, wherein, The inference request received from the service consumer adopts a second format for the service consumer, and wherein the processor is further configured to: The inference request is converted from the second format to a first format for the general base model; and The transformed inference request is provided to the general base model for inference analysis.

4. The apparatus according to claim 1, wherein, The service consumers include: network elements or network functions of the communication network, or external application functions (AF).

5. The apparatus according to claim 4, wherein, The network elements or network functions of the communication network include: policy control function (PCF), session management function (SMF), access and mobility management function (AMF), central unit (CU), or network exposure function (NEF).

6. The apparatus according to claim 1, wherein, The inference request is related to the subscription service, and the processor is further configured to: The analysis results are updated when the triggering condition is met; and The updated analysis results are provided to the service consumer via the interface.

7. The apparatus according to claim 1, wherein, The processor is also used for: Based on the inference request, enhanced information is retrieved from the enhanced information data warehouse; and The enhanced information is provided to the general base model to generate the analysis results.

8. The apparatus according to claim 1, wherein, The inference request includes: Request ID; Analysis type specification; Accuracy level; Time window; Input data parameters; Custom adapter configuration; or Retrieval Enhanced Generation (RAG) configuration.

9. The apparatus according to claim 8, wherein, The RAG configuration includes: Flags used to enable / disable RAG functionality; The input query string used for contextual data retrieval; Search parameters; or Enhance information data warehouses.

10. The apparatus according to claim 1, wherein, The reasoning response includes: Enumeration of reasoning states; Result object; Performance indicators; or The timestamp indicating completion of the reasoning.

11. The apparatus according to claim 10, wherein, The result objects include: Inference value; or Confidence score.

12. The apparatus according to claim 10, wherein, The performance indicators include: Accuracy; Delay; or Overall confidence score.

13. An apparatus for a general-purpose basic model, comprising: interface; and The processor coupled to the interface, The processor is used for: The inference request related to the communication network is received from the model adaptation function via the interface. Integrate the adapters associated with the inference request, wherein the adapters are selected from the adapter repository by the model adaptation function based on the inference request; The adapter performs analysis on the inference request to obtain analysis results; and The analysis results are provided to the model adaptation function via the interface.

14. The apparatus according to claim 13, wherein, The processor is also used for: The enhanced information related to the inference request is obtained from the model adaptation function; and The analysis is also performed based on the enhanced information.

15. The apparatus according to claim 14, wherein, The enhanced information is included in the inference request.

16. The apparatus according to claim 13, wherein, The inference request and the analysis results are in a format specific to the general underlying model.

17. The apparatus according to claim 13, wherein, The general basic model is trained based on multi-domain data from radio access network (RAN), core network (CN), or user equipment (UE) application data.

18. The apparatus according to claim 13, wherein, The model adaptation function acts as an interface between the general base model and service consumers.

19. The apparatus according to claim 18, wherein, The service consumers include: network elements or network functions of the communication network, or external application functions (AF).

Images