Apparatus and method for high-efficiency mechanisms for networks

Abstract

Apparatuses and methods for a high-efficiency mechanism for a network are provided herein. An apparatus includes a memory and a processor circuit coupled with the memory. The processor circuit is configured to: encode a session energy assessment request for transmission to a service producer, the session energy assessment request comprising a session ID for a session and energy policy information for the session; decoding a session energy assessment response received from the service producer in response to the session energy assessment request, the session energy assessment response including session modification suggestions for parameters of the session to optimize energy usage; and performing establishment of the session based on the session modification suggestion. The memory is configured to store a session ID and energy policy information for a session. Other embodiments may be described and / or claimed.

Description

[0001] Priority Statement

[0002] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 620,127, filed on January 11, 2024, U.S. Provisional Patent Application No. 63 / 620,606, filed on January 12, 2024, and U.S. Provisional Patent Application No. 63 / 620,742, filed on January 12, 2024, and all of these applications are hereby incorporated by reference in their entirety. TECHNICAL FIELD

[0003] Embodiments of the present disclosure generally relate to wireless communication, and more particularly, to apparatuses and methods for energy-efficient mechanisms for a network. BACKGROUND OF THE DISCLOSURE

[0004] Climate change and global energy shortages are issues that require international cooperation and coordination at all levels to address. Many regions and countries have issued relevant strategies and requirements to control carbon emissions and improve energy efficiency. These strategies have made energy efficiency a strategic focus for many telecommunications operators globally. Many standards groups and specifications have considered energy efficiency issues. SUMMARY OF THE DISCLOSURE

[0005] One aspect of the present disclosure provides an apparatus, including: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: encode a session energy assessment request for transmission to a service producer, the session energy assessment request including a session ID of a session and energy policy information for the session; decode a session energy assessment response received from the service producer in response to the session energy assessment request, the session energy assessment response including session modification suggestions for parameters of the session to optimize energy usage; and perform establishment of the session based on the session modification suggestions, and wherein the memory is configured to store the session ID and the energy policy information of the session.

[0006] One aspect of the present disclosure provides an apparatus, including: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: decode a session energy assessment request received from a service consumer, the session energy assessment request including a session ID of a session and energy policy information for the session; and in response to the session energy assessment request, encode a session energy assessment response for transmission to the service consumer for establishment of the session, the session energy assessment response including session modification suggestions for parameters of the session to optimize energy usage, and wherein the memory is configured to store the session ID and the energy policy information of the session. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In the accompanying drawings, embodiments of the present disclosure will be illustrated by way of example and not limitation, where like reference numerals refer to like elements.

[0008] Figure 1 An example architecture of a system according to some embodiments of the present disclosure is shown.

[0009] Figure 2 An example network architecture according to some embodiments of the present disclosure is shown.

[0010] Figure 3 An example 5GS architecture according to some embodiments is shown.

[0011] Figure 4 An example of a method for obtaining energy information analysis according to some embodiments of the present disclosure is shown.

[0012] Figure 5 An example of a method for obtaining energy information analysis according to some embodiments of the present disclosure is shown.

[0013] Figure 6 An example process for obtaining an analysis from the NWDAF according to some embodiments of the present disclosure is shown.

[0014] Figure 7 A flowchart of an example of a method for energy policy control according to some embodiments of the present disclosure is shown.

[0015] Figure 8 An example process of energy policy control based on EECF according to some embodiments of the present disclosure is shown.

[0016] Figure 9 A flowchart of an example of a method for energy policy control according to some embodiments of the present disclosure is shown.

[0017] Figure 10 An example process of energy policy control without EECF according to some embodiments of the present disclosure is shown.

[0018] Figure 11 An example process of energy policy control without EECF according to some embodiments of the present disclosure is shown.

[0019] Figure 12 A flowchart of an example of a method for energy saving support according to some embodiments of the present disclosure is shown.

[0020] Figure 13 A flowchart of an example of a method for energy saving support according to some embodiments of the present disclosure is shown.

[0021] Figure 14 Shows an example of EECF communication with UDM, NFR, and SMF according to some embodiments of the present disclosure.

[0022] Figure 15 Shows an example of a PDU session establishment process with energy saving policy control per PDU session according to some embodiments of the present disclosure.

[0023] Figure 16 Shows a network according to various embodiments.

[0024] Figure 17 Schematically shows a wireless network according to various embodiments.

[0025] Figure 18 The block diagram of shows components that can read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and execute any one or more of the methods discussed herein according to some example embodiments.

[0026] Figure 19 Shows a network according to various embodiments.

[0027] Figure 20 Depicts an example functional framework for ML and / or RAN intelligence.

[0028] Figure 21 Depicts an example AI / ML-assisted communication network including communication between two MLFs. Detailed Description

[0029] Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the present 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. For purposes of explanation, specific numbers, materials, and configurations are set forth 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.

[0030] Furthermore, various operations will be described as multiple discrete operations in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must be order-dependent. In particular, these operations need not be performed in the order presented.

[0031] This document repeatedly uses the phrases "in an embodiment", "in one embodiment", and "in some embodiments". This phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. Unless the context otherwise dictates, the terms "comprising", "having", and "including" are synonyms. The phrases "A, B, or C" and "A / B / C" mean "(A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C)".

[0032] The present disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, data centers, network topologies, communication system implementations, network convergence, artificial intelligence (AI) / machine learning (ML) technologies, and more particularly to techniques for energy-saving mechanisms for networks or systems.

[0033] Figure 1 An example architecture of a system 100 in accordance with some embodiments of the present disclosure is shown. The following description is provided with respect to an example system 100 operating in conjunction with the Long-Term Evolution (LTE) system standard and the 5G or New Radio (NR) system standard provided in 3GPP Technical Specification (TS). However, the example embodiments are not limited in this regard, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., Sixth Generation (6G)) systems, Institute of Electrical and Electronics Engineers (IEEE) 802.16 protocols (e.g., Wireless Metropolitan Area Network (MAN), Worldwide Interoperability for Microwave Access (WiMAX), etc.).

[0034] As Figure 1As shown, system 100 may include UEs 101a and 101b (collectively referred to as “(one or more) UEs 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 be referred to as 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 device, reconfigurable radio device, reconfigurable mobile device, etc. Additionally, 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 smart phone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronic devices, cellular phones, smart phones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment systems (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (IC), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashboard mobile devices (DME), mobile data terminals (MDT), electronic engine management systems (EEMS), electronic / engine control units (ECU), electronic / engine control modules (ECM), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or “smart” devices, machine type communication (MTC) devices, machine-to-machine (M2M), Internet of Things (IoT) devices, and / or the like.

[0035] In some embodiments, any one of UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term 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 services (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The data exchange of M2M or MTC may be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., maintaining active messages, status updates, etc.) to facilitate the connection of the IoT network.

[0036] The UE 101 may be configured to connect (e.g., communicatively couple) to the RAN 110. In an embodiment, the RAN 110 may be a Next Generation (NG) RAN or 5G 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, terms such as "NG RAN" may refer to the RAN 110 operating in an NR or 5G system 100, and terms such as "E-UTRAN" may refer to the RAN 110 operating in an LTE or 4G system 100. The 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" may refer to any tangible or intangible transmission medium for carrying data or a data stream. The term "channel" may be synonymous and / or equivalent to "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 terms representing a path or medium through which data is carried. Additionally, the term "link" may refer to a connection between two devices for the purpose of sending and receiving information via a Radio Access Technology (RAT).

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

[0038] UE 101b is shown as being configured to access an 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 as being connected to the Internet and 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) operations and / or WLAN LTE / WLAN radio-level integration with IPsec tunnel (LWIP) operations. LWA operations may involve UE 101b in RRC_CONNECTED being configured by RAN node 111 to utilize radio resources of LTE and WLAN. LWIP operations 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 over 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.

[0039] The 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 103 and 104. As used herein, the terms "access node (AN)", "access point", "RAN node", etc. may describe a device that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as base stations (BSs), next-generation Node Bs (gNBs), RAN nodes, evolved Node Bs (eNBs), Node Bs, roadside units (RSUs), transmission and reception points (TRxP or TRP), etc., and may include terrestrial stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographical area (e.g., a cell). As used herein, the term "NGRAN node", etc. may refer to a RAN node 111 (e.g., gNB) operating in an NR or 5G system 100, and the term "E-UTRAN node", etc. may refer to a RAN node 111 (e.g., eNB) operating in an LTE or 4G system 100. According to various embodiments, the 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 femto cells, pico cells, or other similar cells that provide a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to macro cells.

[0040] In some embodiments, all or part of the RAN node 111 may 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, the CRAN or vBBUP may implement RAN function partitioning, for example: PDCP partitioning, where the RRC and PDCP layers are operated by the CRAN / vBBUP, and other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes 111; or "lower PHY" partitioning, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP, and the lower part of the PHY layer is operated by individual RAN nodes 111. This virtualization framework allows the processor cores of the RAN node 111 to be freed up to execute other virtualized applications. In some implementations, individual RAN nodes 111 may represent via individual F1 interfaces ( Figure 1Individual gNB-DUs (not shown) 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 the RAN 110 or by a pool of servers 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 the UE 101 and are connected to the 5GC via the NG interface.

[0041] In the V2X scenario, one or more RAN nodes 111 may be or act as RSUs. The term "roadside unit" or "RSU" may refer to any transportation infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or a fixed (or relatively stationary) UE, where the RSU implemented in or by a UE may be referred to as a "UE-type RSU", the RSU implemented in or by an eNB may be referred to as an "eNB-type RSU", the RSU implemented in or by a gNB may be referred to as a "gNB-type RSU", etc. In one example, the RSU is a computing device coupled to a radio frequency circuit located at the roadside, which provides connectivity support for passing vehicle UEs 101 (vUE 101). The RSU may also include an internal data storage circuit for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may 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, traffic warnings, etc. Additionally or alternatively, the RSU may operate on the cellular V2X band to provide the above low-latency communication and other cellular communication services. Additionally or alternatively, the RSU may 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. The (one or more) computing devices and some or all of the radio frequency circuits of the RSU may be encapsulated in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired (e.g., Ethernet) connection to a traffic signal controller and / or a backhaul network.

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

[0043] In an embodiment, the UE 101 may be configured to communicate with each other or with any RAN node 111 via multi-carrier communication channels using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to orthogonal frequency division multiple access (OFDMA) communication technologies (e.g., for downlink communication) or single carrier frequency division multiple access (SC-FDMA) communication technologies (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiments is not limited in this regard. The OFDM signal may include a plurality of orthogonal sub-carriers.

[0044] In some embodiments, a downlink resource grid may be used for downlink transmissions from any RAN node 111 to the UE 101, and uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resources in the downlink for each time slot. Such a time-frequency plane representation is a common practice in OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM sub-carrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in the radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of some physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the smallest amount of resources that can be currently allocated. There are several different physical downlink channels transmitted using such resource blocks.

[0045] According to various embodiments, the UE 101 and the RAN node 111 transmit (e.g., send and receive) data via a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (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 the 5 GHz band.

[0046] To operate in unlicensed spectrum, the UE 101 and the RAN node 111 can operate using Licensed-Assisted Access (LAA), Enhanced LAA (eLAA), and / or Further eLAA (feLAA) mechanisms. In these implementations, the UE 101 and the RAN node 111 can perform one or more known medium sensing operations 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. The medium / carrier sensing operations can be performed according to the Listen Before Talk (LBT) protocol.

[0047] 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 when the medium is sensed idle (or when a particular channel in the medium is sensed unoccupied). The medium sensing operation can include Clear Channel Assessment (CCA), which determines whether there are other signals on the channel using at least Energy Detection (ED) to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with incumbent systems in the unlicensed spectrum and with other LAA networks. ED can include sensing radio frequency (RF) energy on the expected transmission band for a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0048] Typically, incumbent systems in the 5 GHz 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, AP 106) intends to transmit, the WLAN node can first perform CCA before transmitting. Additionally, a backoff mechanism is used to avoid collisions in the case where 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 in the event of a collision and is reset to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to the CSMA / CA of WLAN. In some implementations, the LBT procedure for DL or UL transmission bursts respectively including PDSCH or PUSCH transmissions can have a variable-length LAA contention window 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.

[0049] The LAA mechanism is based on the carrier aggregation (CA) technology of the Long Term Evolution - Advanced (LTE - Advanced) system. 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 a Frequency Division Duplex (FDD) system, the number of aggregated carriers can be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, an individual CC can have a different bandwidth from other CCs. In a Time Division Duplex (TDD) system, for DL and UL, the number of CCs and the bandwidth of each CC are usually the same.

[0050] CA also includes separate serving cells to provide separate CCs. The coverage of serving cells may be different. For example, 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, while changing the PCC may require the UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all SCells can operate in the unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE can receive UL grants on the configured LAA SCells, and the UL grants indicate the starting positions of different Physical Uplink Shared Channels (PUSCH) within the same sub - frame.

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

[0052] The PDCCH may use control channel elements (CCEs) to convey control information. Before mapping to resource elements, the PDCCH complex-valued symbols may first be organized into quadruples and then permuted using a sub-block interleaver for rate matching. One or more of these CCEs may be used to transmit each PDCCH, where each CCE may correspond to nine groups of four physical resource elements called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols may be mapped to each REG. One or more CCEs may be used to transmit the PDCCH, depending on the size of the downlink control information (DCI) and the 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 may be defined.

[0053] Some embodiments may use a concept for resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may use an enhanced physical downlink control channel (EPDCCH), which uses PDSCH resources for control information transmission. One or more enhanced control channel elements (ECCEs) may be used to transmit the EPDCCH. Similar to above, each ECCE may correspond to nine groups of four physical resource elements called enhanced resource element groups (EREGs). In some cases, the ECCE may have other numbers of EREGs.

[0054] RAN nodes 111 may be configured to communicate with each other via interface 112. In an embodiment where system 100 is an LTE system, interface 112 may be an X2 interface 112. The X2 interface may be defined between two or more RAN nodes 111 (e.g., two or more eNBs, etc.) connected to the EPC 120 and / or between two eNBs connected to the 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). The X2-U may provide a flow control mechanism for user data packets transmitted through the X2 interface and may be used to convey information about user data transfer between eNBs. For example, the X2-U may provide specific sequence number information for user data transmitted from the master eNB (MeNB) to the secondary eNB (SeNB); information about the successful sequential transmission of PDCP PDUs from the SeNB to the UE 101 for user data; information about PDCP PDUs not delivered to the UE 101; information about the current minimum required buffer size at the SeNB for transmitting user data to the UE; and so on. The X2-C may provide intra-LTE access mobility functions, including context transfer from the source eNB to the target eNB, user plane transmission control, etc.; load management functions; and inter-cell interference coordination functions.

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

[0056] RAN 110 is shown communicatively coupled to a core network - in this embodiment, to core network (CN) 120. CN 120 may include a plurality of network elements 122, which are configured to provide various data and telecommunications services to consumers / subscribers (e.g., the user of UE 101) connected to CN 120 via RAN 110. The term "network element" may describe a physical or virtualized device for providing wired or wireless communication network services. The term "network element" may be considered synonymous with and / or referred to as the following: 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 one physical node or separate physical nodes, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, network function virtualization (NFV) may be used to virtualize any or all of the above network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. The logical instantiation of CN 120 may be referred to as a network slice, and the logical instantiation of a part of CN 120 may be referred to as a network sub-slice. The NFV architecture and infrastructure may be used to virtualize one or more network functions, or to execute them from dedicated hardware onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0057] Generally, application server 130 may be an element that provides an application that uses IP bearer resources in conjunction with a 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) session, PTT session, group communication session, social network service, etc.) for UE 101 via EPC 120.

[0058] In an embodiment, CN 120 may be a 5GC (referred to as "5GC 120", etc.), and 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 traffic data between RAN node 111 and user plane function (UPF); and S1 control plane (NG-C) interface 115, which is a signaling interface between RAN node 111 and AMF.

[0059] In an embodiment, CN 120 may be a 5G CN (referred to as "5GC 120", etc.), while in other embodiments, CN 120 may be an evolved packet core (EPC). In the case where CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 may be connected to CN 120 via the S1 interface 113. In an embodiment, the S1 interface 13 may be divided into two parts: the S1 user plane (S1-U) interface 114, which carries traffic data between the RAN node 111 and the serving gateway (S-GW); and the S1-mobility management entity (MME) interface 115, which is a signaling interface between the RAN node 111 and the MME.

[0060] Figure 2 FIG. 200 shows an example network architecture 200 according to some embodiments of the present disclosure. Network 200 may operate in a manner consistent with the 3GPP technical specifications of an LTE or 5G / NR system. However, the example embodiments are not limited in this regard, and the examples may be applicable to other networks that benefit from the principles described herein, such as future 3GPP systems or similar systems.

[0061] Network 200 includes a UE 202, which is any mobile or non-mobile computing device designed to communicate with a RAN 204 via an air interface. UE 202 is communicatively coupled to RAN 204 via a Uu interface, which may be applicable to LTE and NR systems. Examples of UE 202 include, but are not limited to, smartphones, tablets, wearable devices (e.g., smartwatches, fitness trackers, smart glasses, smart clothing / fabric, head-mounted displays, smart programs, and / or the like), desktop computers, workstations, laptops, in-vehicle infotainment systems, in-vehicle entertainment systems, dashboards, head-up display (HUD) devices, on-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networked appliances, machine-type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) devices, Internet of Things (IoT) devices, smart appliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, electronic signage, single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel Edison, etc.), plug-in computers, and / or any type of computing device (e.g., any type of computing device discussed herein).

[0062] The network 200 may include a set of UEs 202 that are directly coupled to each other via D2D, ProSe, PC5, and / or sidelink (SL) interfaces and / or any other suitable interfaces (such as any of the interfaces discussed herein). In a 3GPP system, SL communication involves communication between two or more UEs 202 using 3GPP technologies without passing through network nodes. These UEs 202 may be M2M / D2D / MTC / IoT devices and / or vehicle-mounted systems that communicate using the SL interface, which may include, for example: one or more SL logical channels (e.g., sidelink broadcast control channel (SBCCH), sidelink control channel (SCCH), and sidelink traffic channel (STCH)); one or more SL transport channels (e.g., sidelink shared channel (SL-SCH) and sidelink broadcast channel (SL-BCH)); and one or more SL physical channels (e.g., physical sidelink shared channel (PSSCH), physical sidelink control channel (PSCCH), physical sidelink feedback channel (PSFCH), physical sidelink broadcast channel (PSBCH), and / or similar channels). The UE 202 may perform blind decoding attempts on the SL channel / link according to various examples herein.

[0063] In some examples, the UE 202 may also communicate with the AP 206 via an over-the-air (OTA) connection. The AP 206 manages the WLAN connection, which can be used to offload some / all of the network traffic of the RAN 204. The connection between the UE 202 and the AP 206 may conform to any IEEE 802.11 protocol. Additionally, the UE 202, RAN 204, and AP 206 may utilize cellular-WLAN aggregation / integration (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve the RAN 204 configuring the UE 202 to utilize cellular radio resources and WLAN resources simultaneously.

[0064] The RAN 204 includes one or more network access nodes (NANs) 214. The NAN 214 terminates the air interface of the UE 202 by providing access layer protocols (including RRC, PDCP, RLC, MAC, and PHY / L1 protocols). In this way, the NAN 214 can establish a data / voice connection between the CN 240 and the UE 202. The NAN 214 may be: a macro cell base station; or a low-power base station for providing femtocells, picocells, or other similar cells, which have a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to macro cells; or some combination thereof. In these implementations, the NAN 214 is referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRP, etc.

[0065] One example implementation is the "CU / DU split" architecture, where NAN 214 is embodied as a gNB - Central Unit (CU) communicatively coupled to one or more gNB - Distributed Units (DUs), and each DU may be communicatively coupled to one or more Radio Units (RUs) (also referred to as RRHs, RRUs, etc.). In some implementations, one or more RUs may be individual RSU. In some implementations, the CU / DU split may include an ng - eNB - CU and one or more ng - eNB - DUs instead of a gNB - CU and gNB - DUs, or it may be complementary to a gNB - CU and gNB - DUs. NAN 214 used as a CU may be implemented in a discrete device or as one or more software entities running on a server computer, e.g., as part of a virtual network including a virtual baseband unit (BBU) or BBU pool, Cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), Centralized RAN (C - RAN), Virtualized RAN (vRAN), etc. (although these terms may refer to different implementation concepts). Any other type of architecture, arrangement, and / or configuration may also be used.

[0066] If RAN 204 is an LTE RAN or an Evolved Universal Terrestrial Radio Access Network (E - UTRAN) 210, a set of NAN214 are interconnected via corresponding X2 interfaces; or if RAN 204 is an NG - RAN 214, a set of NAN 214 are interconnected via corresponding Xn interfaces. In some examples, the X2 / Xn interfaces may be divided into control / user plane interfaces, which may allow ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

[0067] The NAN 214 of RAN 204 may each manage one or more cells, cell groups, member carriers, etc., to provide an air interface for UE 202 for network access. UE 202 may be connected to a set of cells provided by the same or different NAN 214 of RAN 204 simultaneously. For example, UE 202 and RAN 204 may use carrier aggregation to allow UE 202 to connect to a set of member carriers, each member carrier corresponding to a PCell or SCell. In a dual - connection scenario, the first NAN 214 may be the master node providing the MCG, and the second NAN 214 may be the secondary node providing the SCG. The first / second NAN 214 may be any combination of eNB, gNB, ng - eNB, etc.

[0068] The RAN 204 can provide an air interface through licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, nodes can use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCell / Scell. Before accessing unlicensed spectrum, nodes can perform medium / carrier sensing operations according to, for example, the listen-before-talk (LBT) protocol.

[0069] Additionally or alternatively, the individual UE 202 provides radio information to one or more NANs 214 and / or one or more edge computing nodes (e.g., edge servers / hosts, etc.). The radio information can be in the form of one or more measurement reports and / or can include, for example, signal strength measurement information, signal quality measurement information, and / or similar measurement information. Each measurement report is tagged with a timestamp and a measurement location (e.g., the current location of the UE 202). As an example, the measurement information collected by the UE 202 and / or the measurement information included in the measurement reports can include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interruptions, out-of-order delivery of packets, transmission power, bit error rate, bit error rate (BER), block error rate (BLER), packet error rate (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) latency, signal-to-noise ratio (SNR), signal-to-interference-plus-noise ratio (SINR), signal-plus-noise-plus-distortion to signal-plus-distortion (SINAD) ratio, carrier-to-interference-plus-noise ratio (CINR), additive white Gaussian noise (AWGN), energy per bit to noise power density ratio (Eb / N0), energy per chip to interference power density ratio (Ec / I0), energy per chip to noise power density ratio (Ec / N0), peak-to-average power ratio (PAPR), reference signal received power (RSRP), reference signal received quality (RSRQ), received signal strength indicator (RSSI), received channel power indicator (RCPI), received signal noise indicator (RSNI), received signal code power (RSCP), average noise-plus-interference (ANPI), GNSS cell frame timing for UE positioning in E-UTRAN or 5G / NR (e.g., the timing between the AP 206 or RAN node 208 reference time and the GNSS-specific reference time of a given GNSS), GNSS code measurement (e.g., the GNSS code phase (integer part and fractional part) of the propagation code of the i-th GNSS satellite signal), GNSS carrier phase measurement (e.g., the number of carrier phase cycles (integer part and fractional part) of the i-th GNSS satellite signal measured since the signal was locked; also known as accumulated delta range (ADR)), channel interference measurement, thermal noise power measurement, received interference power measurement, power histogram measurement, channel load measurement, STA statistics, and / or other similar measurements.RSRP, RSSI, and / or RSRQ measurements may include RSRP, RSSI, and / or RSRQ measurements of cell-specific reference signals, channel state information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks of a 3GPP network (e.g., LTE or 5G / NR), as well as RSRP, RSSI, RSRQ, RCPI, RSNI, and / or ANPI measurements of various beacons, fast initial link setup (FILS) discovery frames, or probe response frames for a WLAN / WiFi (e.g., [IEEE80211]) network. Additionally or alternatively, other measurement methods may be used, such as those discussed in 3GPP TS 36.214 v17.0.0 (2022-03-31) (“[TS36214]”), 3GPP TS 38.215 v17.3.0 (2023-03-30) (“[TS38215]”), 3GPP TS 38.314 v17.3.0 (2023-06-30) (“[TS38314]”), [IEEE80211], etc. Additionally or alternatively, one or more NAN 214s may collect any of the above measurements (or combinations of measurements) and provide them to the edge computing node(s).

[0070] Additionally or alternatively, the measurements may include one or more of the following measurements: measurements related to a data radio bearer (DRB) (e.g., the number of DRBs attempted to be established, the number of DRBs successfully established, the number of active DRBs released, the in-session activity time of a DRB, the number of DRBs attempted to be resumed, the number of DRBs successfully resumed, etc.); measurements related to radio resource control (RRC) (e.g., the average number of RRC connections, the maximum number of RRC connections, the average number of stored inactive RRC connections, the maximum number of stored inactive RRC connections, the number of RRC connection establishments attempted, successful, and / or failed, etc.); measurements related to UE context (UECNTX); measurements related to radio resource utilization (RRU) (e.g., total DL PRB usage, total UL PRB usage, the distribution of total DL PRB usage, the distribution of total UL PRB usage, DL PRBs for data traffic, UL PRBs for data traffic, total number of available DL PRBs, total number of available UL PRBs, etc.); measurements related to registration management (RM); measurements related to session management (SM) (e.g., the number of PDU sessions requested to be established; the number of PDU sessions successfully established; the number of PDU sessions with setup failures, etc.); measurements related to GTP management (GTP); measurements related to IP management (IP); measurements related to policy association (PA); measurements related to mobility management (MM) (e.g., for inter-RAT, intra-RAT, and / or intra-frequency / inter-frequency handovers and / or conditional handovers: the number of handover preparations requested, successful, and / or failed; the number of handover resource allocations requested, successful, and / or failed; the number of handover executions requested, successful, and / or failed; the average and / or longest time for requested handover executions; the number of successful and / or failed handover executions per beam pair, etc.); measurements related to (one or more) virtualized resources (VR); measurements related to carrier (CARR); measurements related to QoS flow (QF) (e.g., the number of active QoS flows released, the number of QoS flows attempted to be released, the session activity time of a QoS flow, the session activity time of UE202, the number of QoS flows attempted to be established, the number of QoS flows successfully established, the number of QoS flows with establishment failures, the number of initial QoS flows attempted to be established, the number of initial QoS flows successfully established, the number of initial QoS flows with establishment failures, the number of QoS flows attempted to be modified, the number of QoS flows successfully modified, the number of QoS flows with modification failures, etc.); measurements related to application trigger (AT); measurements related to short message service (SMS); measurements related to power, energy, and environment (PEE); measurements related to NF service (NFS); measurements related to packet flow description (PFD); measurements related to random access channel (RACH); measurements related to measurement report (MR);Measurements related to Layer 1 Measurement (L1M); Measurements related to Network Slice Selection (NSS); Measurements related to Paging (PAG); Measurements related to Non-IP Data Delivery (NIDD); Measurements related to External Parameter Provision (EPP); Measurements related to Traffic Impact (TI); Measurements related to Connection Establishment (CE); Measurements related to Service Parameter Provision (SPP); Measurements related to Background Data Transfer Policy (BDTP); Measurements related to Data Management (DM); and / or any other performance measurements, such as those discussed in 3GPP TS 28.552 v18.3.0 (2023-06-27) (“[TS28552]”), 3GPP TS 32.425 v17.1.0 (2021-06-24) (“[TS32425]”), and / or similar documents.;

[0071] Radio information can be reported in response to trigger events and / or periodically. Additionally or alternatively, an individual UE 202 can report radio information and / or other information related to data transmission with low or high periodicity according to the data transmission to be performed. Additionally or alternatively, one or more edge computing nodes can request measurement results from the NAN 214 with low or high periodicity, or the NAN 214 can provide measurement results to one or more edge computing nodes with low or high periodicity. Additionally or alternatively, one or more edge computing nodes can also obtain other relevant data, such as key performance indicators (KPIs), from one or more other edge computing nodes, core network functions (NFs), application functions (AFs), and / or other UEs 202, and these data can be obtained together with the measurement report or separately from the measurement report.

[0072] Additionally or alternatively, in the case of differences in the observed data from one or more UEs, one or more RAN nodes, and / or core network NFs (e.g., missing reports, data errors, etc.), simple extrapolation can be performed to supplement the obtained observed data, such as replacing values in previous reports and / or historical data, applying extrapolation filters, etc. Additionally or alternatively, an acceptable range of the observed data can be predetermined or configured. For example, CQI and MCS measurements can be configured to be only within the ranges defined by the appropriate 3GPP standards. In the case where the reported data value is meaningless (e.g., the value exceeds the acceptable range / boundary, etc.), the current learning / training set or such values over time can be discarded. For example, a packet transfer delay boundary can be defined or configured, and packets determined to be received after the packet transfer delay boundary can be discarded.

[0073] UE 202 can also perform procedures to determine reference signal (RS) measurements and reports to provide information about the quality of one or more wireless channels and / or the general communication medium to the network, and this information can be used to optimize various aspects of the communication system. As an example, the measurement and reporting procedures performed by UE 202 can include the measurement and reporting procedures discussed in the following documents: 3GPP TS 38.211 v17.5.0 (2023-06-26) (“[TS38211]”), 3GPP TS 38.212 v17.5.0 (2023-03-30) (“[TS38212]”), 3GPP TS 38.213 v17.6.0 (2023-06-26) (“[TS38213]”), 3GPP TS 38.214 v17.6.0 (2023-06-26) (“[TS38214]”), [TS38215], 3GPP TS 38.101-1 v18.2.0 (2023-06-30) (“[TS38101-1]”), 3GPP TS 38.104 v18.2.0 (2023-06-30) (“[TS38104]”), 3GPP TS 38.133 v18.2.0 (2023-06-30) (“[TS38133]”), [TS38331], etc. Physical signals and / or reference signals can include demodulation reference signals (DM-RS), phase-tracking reference signals (PT-RS), positioning reference signals (PRS), channel state information reference signals (CSI-RS), synchronization signal blocks (SSB), primary synchronization signals (PSS), secondary synchronization signals (SSS), sounding reference signals (SRS), etc.

[0074] In any of the examples discussed herein, any suitable data collection and / or measurement mechanism(s) can be used to collect the observed data. For example, data tagging (e.g., sequence numbers, etc.), packet tracing, signal measurements, data sampling, and / or timestamping techniques can be used to determine any of the above metrics / observed data. Data collection can be based on events that trigger data collection. Additionally or alternatively, data collection can also occur at the start or end of an event. Data collection can be continuous, discontinuous, and / or have start and stop times. The data collection techniques / mechanisms can be specific to the HW configuration / implementation or not specific to the HW and can also be based on various software parameters (e.g., OS type and version, etc.). Various configurations can be used to define any of the above data collection parameters. Such configurations can be defined by suitable specifications / standards, such as 3GPP (e.g., [5GEdge]), ETSI (e.g., [MEC]), O-RAN (e.g., [O-RAN]), Smart Edge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., MAMS [RFC8743]), IEEE / WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], etc.) and / or any other similar standards discussed herein.

[0075] In a V2X scenario, the UE 202 or the NAN 214 can be or act as a Road Side Unit (RSU), and the RSU can refer to any traffic infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. The RSU implemented in or by a UE can be referred to as a "UE-type RSU"; the RSU implemented in or by an eNB can be referred to as an "eNB-type RSU"; the RSU implemented in or by a gNB can be referred to as a "gNB-type RSU"; and so on. In one example, the RSU is a computing device coupled to a radio frequency circuit located by the roadside, which can provide connection support for passing vehicle UEs. The RSU can also include an internal data storage circuit for storing intersection map geometries, traffic statistics, media, and applications / software for sensing and controlling current vehicle and pedestrian traffic. 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 also provide other cellular / WLAN communication services. The components of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller for providing a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network. Further, one or more V2X RATs can be employed, which allow V2X nodes to communicate directly with each other, with infrastructure devices (e.g., NAN 214) and / or other devices / nodes. In some embodiments, at least two different V2X RATs can be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., DSRC in the United States and ITS-G5 in Europe) and a Cellular V2X (C-V2X) RAT based on 3GPP V2X technology (e.g., LTE V2X, 5G / NR V2X, etc.). In one example, the C-V2X RAT can use a C-V2X air interface, and the WLAN V2X RAT can use a W-V2X air interface.

[0076] W-V2X RATs include, for example: IEEE "Wireless Access in Vehicular Environments (WAVE) Architecture Guidelines", IEEE Standards Association, IEEE 1609.0-2019 (April 10, 2019) ("[IEEE16090]"); "V2X Communication Message Set Dictionary", SAE INT'L (July 23, 2020) ("[J2735_202007]"); 5 GHz band Intelligent Transportation Systems (ITS-G5), [IEEE80211] (which is the Layer 1 (L1) and Layer 2 (L2) part of WAVE, DSRC, and ITS-G5); and / or IEEE Broadband Wireless Access System Air Interface Standard, IEEE Std 802.16-2017, pages 1-2726 (March 2, 2018) ("[WiMAX]"). The term "DSRC" refers to vehicle communications in the 5.9 GHz band commonly used in the United States, while "ITS-G5" refers to vehicle communications in the 5.9 GHz band used in Europe. Due to the applicability of any number of different RATs (including [IEEE80211] RAT) that can be used in any geographical or political region, the terms "DSRC" (used in the United States among other regions) and "ITS-G5" (used in Europe among other regions) are used interchangeably in this disclosure. ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter referred to as "[EN302663]") outlines the access layer of the ITS-G5 interface and describes the access layer of the ITS-S reference architecture. The ITS-G5 access layer includes [IEEE80211], as well as the functions of the distributed congestion control (DCC) method discussed in ETSI TS102 687 V1.2.1 (2018-04) (hereinafter referred to as "[TS102687]"). The access layer of the (one or more) 3GPP LTE-V2X-based interfaces is outlined in documents such as ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS23.285 v16.2.0 (2019-12); the 3GPP 5G / NR-V2X is outlined in documents such as 3GPP TR23.786 v16.1.0 (2019-06) and 3GPP TS23.287 v18.0.0 (March 31, 2023) ("[TS23287]").

[0077] In an example where the RAN 204 is the E-UTRAN 210 with one or more eNBs 212, the E-UTRAN 210 provides an LTE air interface (Uu), whose parameters and characteristics are at least the same as those discussed in 3GPP TS 36.300 v17.2.0 (2022-09-30) (“[TS36300]”). In an example where the RAN 204 is the next-generation (NG)-RAN 214 with a set of gNBs 216, each gNB 216 is connected to the 5G-capable UE 202 using the 5G-NR air interface (also referred to as the Uu interface), whose parameters and characteristics are discussed in [TS38300] and many other 3GPP standards. When the NG-RAN 214 includes a set of ng-eNBs 218, one or more ng-eNBs 218 are connected to the UE 202 through the 5G Uu and / or LTE Uu interfaces. The gNBs 216 and ng-eNBs 218 are connected to the 5GC 240 through the corresponding NG interfaces (including the N2 interface, the N3 interface, and / or other interfaces). The gNBs 216 and ng-eNBs 218 are interconnected through the Xn interface. In addition, individual gNBs 216 are interconnected through the corresponding Xn interface, and individual ng-eNBs 218 are interconnected through the corresponding Xn interface. In some examples, the NG interface can be divided into two parts. One part is the NG user plane (NG-U) interface, which is used to transmit traffic data between the NG-RAN 214 nodes and the UPF 248 (e.g., the N3 interface); the other part is the NG control plane (NG-C) interface, which is a signaling interface between the NG-RAN 214 nodes and the AMF 244 (e.g., the N2 interface).

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

[0079] The 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adaptation of the SCS. For example, UE 202 can be configured with multiple BWPs, where each BWP is configured with a different SCS. When a BWP change is indicated to UE 202, the transmitted SCS also changes. Another use case of BWPs is related to energy saving. In particular, multiple BWPs with different numbers of frequency resources (e.g., PRBs) can be configured for UE 202 to support data transmission in different traffic load scenarios. The BWP containing fewer PRBs can be used for data transmission under low traffic loads, while allowing power consumption savings at UE 202 and in some cases at gNB 216. The BWP containing more PRBs can be used for scenarios with higher traffic loads.

[0080] In some implementations, an individual gNB 216 can include a gNB-CU and a set of gNB-DUs. Additionally or alternatively, gNB 216 can include one or more RUs. In these implementations, the gNB-CU can be connected to each gNB-DU via a corresponding F1 interface. In the case of network sharing with multiple cell ID broadcasts, each cell identity associated with a PLMN subset corresponds to a gNB-DU and its connected gNB-CU, sharing the same physical layer cell resources. To improve resilience, the gNB-DU can be connected to multiple gNB-CUs through appropriate implementations. Additionally, the gNB-CU can be divided into gNB-CU control plane (gNB-CU-CP) functions and gNB-CU user plane (gNB-CU-UP) functions. The gNB-CU-CP is connected to the gNB-DU via the F1 control plane interface (F1-C), the gNB-CU-UP is connected to the gNB-DU via the F1 user plane interface (F1-U), and the gNB-CU-UP is connected to the gNB-CU-CP via the E1 interface. In some implementations, one gNB-DU is only connected to one gNB-CU-CP, and one gNB-CU-UP is only connected to one gNB-CU-CP. To improve resilience, the gNB-DU and / or gNB-CU-UP can be connected to multiple gNB-CU-CPs through appropriate implementations. Under the control of the same gNB-CU-CP, one gNB-DU can be connected to multiple gNB-CU-UPs, and under the control of the same gNB-CU-CP, one gNB-CU-UP can be connected to multiple DUs. Xn-U can support data forwarding between gNB-CU-UPs during handovers within the gNB-CU-CP inside the gNB.

[0081] Similarly, an individual ng-eNB 218 may include an ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, the ng-eNB-CU and each ng-eNB-DU are interconnected via a respective W1 interface. The ng-eNB may include an ng-eNB-CU-CP, one or more ng-eNB-CU-UPs, and one or more ng-eNB-DUs. The ng-eNB-CU-CP and the ng-eNB-CU-UP are connected via an E1 interface. The ng-eNB-DU is connected to the ng-eNB-CU-CP via a W1-C interface and to the ng-eNB-CU-UP via a W1-U interface. Unless otherwise explicitly specified, the general principles described herein with respect to the gNB side also apply to the ng-eNB side and the corresponding E1 and W1 interfaces.

[0082] The node hosting the user plane part of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB, depending on the bearer separation scenario) performs user inactivity monitoring and further notifies its inactivity or (re)activation to the node having a control plane connection to the core network (e.g., via E1, X2, etc.). The node hosting the RLC protocol layer (e.g., gNB-DU) may perform user inactivity monitoring and further notify its inactivity or (re)activation to the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP).

[0083] In these implementations, the NG-RAN 214 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN 214 architecture (e.g., NG-RAN logical nodes and the interfaces between them) is part of the RNL. For each NG-RAN interface (e.g., NG, Xn, F1, etc.), the relevant TNL protocols and functions are specified. The TNL provides services for user plane transport and / or signaling transport. In the NG-Flex configuration, each NG-RAN node is connected to all AMFs 244 within the AMF set in the AMF area that supports at least one slice also supported by the NG-RAN node. The AMF set and the AMF area are defined in [TS23501].

[0084] RAN 204 is communicatively coupled to CN 240, which includes network elements and / or network functions (NFs) for providing various functions to support the provision of data and telecommunication services to consumers / subscribers (e.g., UE 202). The components of CN 240 may be implemented in one physical node or separate physical nodes. In some examples, NFV may be utilized to virtualize any or all of the functions provided by the network elements of CN 240 onto physical computing / storage resources in servers, switches, etc. The logical instantiation of CN 240 may be referred to as a network slice, and a partial logical instantiation of CN 240 may be referred to as a network sub-slice.

[0085] In Figure 2 the example, CN 240 is 5GC 240, which includes an Authentication Server Function (AUSF) 242, an Access and Mobility Management Function (AMF) 244, a Session Management Function (SMF) 246, a User Plane Function (UPF) 248, a Network Slice Selection Function (NSSF) 250, a Network Exposure Function (NEF) 252, a Network Repository Function (NRF) 254, a Policy Control Function (PCF) 256, a Unified Data Management (UDM) 258, a Unified Data Repository (UDR), an Application Function (AF) 260, and a Network Data Analytics Function (NWDAF) 262, which are coupled to each other through various interfaces as shown. The NFs in 5GC 240 are briefly introduced below.

[0086] NWDAF 262 is an NF capable of collecting data from: UE 202; (one or more) other NFs in 5GC 240 (e.g., AMF 244, SMF 246, UPF 248, PCF 256, UDM 258, Network Slice Admission Control Function (NSACF), AF 260 (directly and / or through NEF 252)); Operations, Administration, and Maintenance (OAM) entities / functions; external AF 260; DN 236; (one or more) servers 238; cloud computing services; edge computing nodes; and / or edge networks and / or other entities / elements available for analysis.

[0087] NWDAF 262 includes one or more of the following functions: supporting data collection from the NF and AF 260; supporting data collection from OAM; registering NWDAF services and exposing metadata to the NF and AF 260; supporting the provision of analysis information to the NF and AF 260; supporting ML model training and provision to (one or more) NWDAF 262 (e.g., those NWDAF that contain the analysis logic function). Partial or all of the NWDAF functions may be supported in a single instance of NWDAF 262. NWDAF 262 also includes an analysis reporting function, which includes means for allowing the discovery of the types of analysis consumable by external parties and / or requesting the consumption of the analysis information generated by NWDAF 262. NWDAF 262 may collect data from (one or more) NF and / or other entities / components / functions through an Nnf service-based interface associated with (one or more) NF and / or other entities / components / functions. NWDAF 262 and the NF providing the data belong to the same PLMN. The Nnf interface is defined for NWDAF 262 to request subscription for data transfer for a specific context, cancel subscription for data transfer, and request a specific data report for a specific context. The 5GS architecture also allows NWDAF 262 to retrieve management data from the OAM entity by invoking the OAM service.

[0088] NWDAF 262 interacts with different entities for different purposes, such as one or more of the following: data collection based on event subscriptions provided by AMF 244, SMF 246, PCF 256, UDM 258, NSACF, AF 260 (directly or through NEF 252), and OAM; using DCCF 263 for analysis and data collection; retrieving information from a data repository (e.g., retrieving subscriber-related information from UDR 259 via UDM 258); location information data collection from the LCS system; information storage and retrieval from ADRF 266; analysis and data collection from MFAF 265; retrieving information about the NF (e.g., retrieving NF-related information from NRF 254), providing analysis on demand to consumers according to the provisions of Article 6 of [TS23288]; providing bulk data related to (one or more) analysis IDs; providing accuracy information related to (one or more) analysis IDs; and / or providing ML model accuracy information and / or ML model accuracy degradation related to one or more ML models. The NWDAF discovery and selection process is discussed in Article 6.3.13 of [TS23501] and Article 5.2 of [TS23288].

[0089] A single instance or multiple instances of the NWDAF 262 can be deployed in a PLMN. If multiple instances of the NWDAF 262 are deployed, the architecture supports deploying the NWDAF 262 as a central NF, a distributed NF set, or a combination of both. If multiple instances of the NWDAF 262 are deployed, the NWDAF 262 can act as an aggregation point (e.g., an aggregator NWDAF 262), and collect analytics information from other NWDAF 262 (which may have different service areas) to generate aggregated analytics (e.g., by analytics ID), possibly including analytics generated by itself. When there are multiple NWDAF 262s, not all NWDAF 262s need to be able to provide the same type of analytics results. For example, some NWDAF 262s can specialize in providing some types of analytics.

[0090] The analytics ID information element (IE) is used to identify the types of supported analytics that the NWDAF 262 can generate. In some implementations, one or more NWDAF instances 262 can be collocated with another 5GS NF.

[0091] There may be different NWDAF instances 262 in the 5GC 240, and each analytics type (and / or each analytics ID) may have specialization. The NWDAF configuration file stored in the NRF 254 describes the functions of the NWDAF instances 262, which will be described in more detail below. In a multi-NWDAF deployment scenario, the NWDAF instances 262 can specialize in providing analytics for one or more analytics IDs. Each NWDAF instance 262 can serve a certain area of interest, one or more tracking area identities (TAIs), one or more service areas, one or more registration areas, one or more DN names (DNNs), one or more local DNNs, one or more DN access IDs (DNAIs), and / or some other predefined or configured area / region, service, application, or other entity / component. Multiple NWDAF 262s can jointly serve one or more specific analytics IDs. The NWDAF 262 may be capable of supporting the aggregation of analytics data received from other NWDAF 262s (e.g., by analytics ID), and may also have its own generated analytics data.

[0092] The NWDAF 262 may include an Analytics Logic Function (AnLF) 262a and / or a Model Training Logic Function (MTLF) 262b. The NWDAF 262 may include only the MTLF 262b, only the AnLF 262a, or both. The 5GS architecture allows a NWDAF that includes the AnLF 262a (referred to herein as "NWDAF-ANLF AnLF 262a", etc.) to use a trained ML model from the same or a different NWDAF that includes the MTLF 262b (also referred to herein as "NWDAF MTLF 262b") to provide services. The NWDAF-AnLF 262a uses the Nnwdaf interface to request and subscribe to the trained ML model provision service provided by the NWDAF-MTLF 262b. The Nnwdaf_MLModelProvision service provided by the NWDAF 262 enables an NF service consumer (NFc) to receive a notification (e.g., see clause 7.5 of [TS23288]) when an ML model that matches the subscription parameters in the NWDAF-MTLF 262b becomes available. The NWDAF 262 provides the Nnwdaf_MLModelInfo service, enabling the NFc to request and obtain ML model information from the NWDAF-MTLF 262b (e.g., see clause 7.6 of [TS23288]). The AnLF 262a is a logic function in the NWDAF 262 for performing inference, deriving analysis information (e.g., deriving statistics, inference, and / or predictions according to an analysis consumer request), and exposing analysis services (e.g., Nnwdaf_AnalyticsSubscription or Nnwdaf_AnalyticsInfo). In some implementations, the AnLF 262a is an AI / ML inference function included in the NWDAF 262. In various implementations, the AnLF 262a can be modeled by the NRM for AI / ML inference management discussed herein. The analysis information can be statistical information about past events or predictive information (e.g., generating predictions / inferences using one or more AI / ML models, etc.). The MTLF 262b is a logic function in the NWDAF 262 for training AI / ML models and exposing new training services (e.g., providing a trained ML model), as defined in clauses 7.5 and 7.6 of [TS23288].

[0093] To ensure the accuracy of the analysis output for an analysis ID, based on UE anomaly behavior analysis (including the anomaly UE list and the observed time window) from itself and / or other NWDAF 262, the NWDAF 262 will detect and may delete the input data from the (one or more) anomaly UEs 202, and then may generate a new ML model and / or analysis output for the analysis ID without the input data related to the anomaly UE list during the unobserved time window, and then send / update the ML model information and / or analysis output to the subscribed NWDAF service consumers.

[0094] To support the NF in discovering and selecting the NWDAF-MTLF 262b, NWDAF-AnLF 262a, or both, that can provide the required services (e.g., analysis exposure, AI / ML services (e.g., MLT, ML model provisioning, model testing, etc.), sensing services, communication services, and / or any other service(s) including any service discussed herein) for the required analysis type, each NWDAF instance 262 shall provide a list of the supported analysis ID(s) when registering with the NRF 254, in addition to the other NRF registration elements of the NF profile, which may be by the supported services (e.g., AI / ML services, analysis exposure / services, sensing services, and / or any other service(s) including any service discussed herein). An NF that needs to discover a NWDAF instance 262 that supports some specific service(s) for a specific type of analysis may query the NRF 254 to obtain the NWDAF 262 that supports the required service(s) and required analysis ID(s).

[0095] Since multiple NWDAF 262 instances may be deployed in the network, the NFc may utilize the NRF 254 to discover the (one or more) NWDAF 262 instances, unless the NWDAF information is available through other means (e.g., locally configured on the NFcs). If supported, the NFc may make additional queries to the UDM 258. The NWDAF selection function in the NFc selects the NWDAF instance 262 (or NWDAF-MTLF instance 262b and / or NWDAF-AnLF instance 262a) based on the available NWDAF 262 instances, the stored / list of supported (one or more) analysis IDs from the NRF 254 (e.g., possibly by supported services), the NWDAF capabilities (e.g., analysis aggregation capability, analysis metadata provisioning capability, ML model training capability, ML model deployment capability, etc.) and / or other NRF 254 registration elements of the NF profile. 3GPP TS23.288 (“[TS23288]”) defines other and / or alternative aspects of the NWDAF 262 function.

[0096] The AUSF 242 stores data for authenticating the UE 202 and processes authentication-related functions. The AUSF 242 may facilitate a common authentication framework for various access types.

[0097] The AMF 244 allows other functions of the 5GC 240 to communicate with the UE 202 and the RAN 204, and subscribes to notifications about UE 202 mobility events. The AMF 244 is also responsible for registration management (e.g., registering the UE 202), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 244 provides transport for SM messages between the UE 202 and the SMF 246 and acts as a transparent proxy for routing SM messages. The AMF 244 also provides transport for SMS messages between the UE 202 and the SMSF. The AMF 244 interacts with the AUSF 242 and the UE 202 to perform various security anchoring and context management functions. In addition, the AMF 244 is the termination point of the RAN-CP interface, which includes the N2 reference point between the RAN 204 and the AMF 244. The AMF 244 is also the termination point of the NAS (N1) signaling and performs NAS encryption and integrity protection.

[0098] The AMF 244 also supports NAS signaling between the UE 202 via the N3IWF interface. The N3IWF allows access to untrusted entities. The N3IWF can be the termination point of the N2 interface for the control plane between the (R)AN 204 and the AMF 244, or the termination point of the N3 reference point for the user plane between the (R)AN 204 and 248. Therefore, the AMF 244 processes N2 signaling from the SMF 246 and the AMF 244 for PDU sessions and QoS, encapsulates / decapsulates packets for IPSec and N3 tunnels, marks N3 user plane packets in the UL, and performs QoS corresponding to N3 packet marking, taking into account the QoS requirements related to such marking received via N2. The N3IWF can also relay UL and DL control plane NAS signaling between the UE 202 and the AMF 244 via the N1 reference point between the UE 202 and the AMF 244, and relay UL and DL user plane packets between the UE 202 and the UPF 248. The N3IWF also provides a mechanism for establishing an IPsec tunnel with the UE 202. The AMF 244 can expose Namf service-based interfaces and can be the termination point of the N14 reference point between two AMF 244s and the N17 reference point between the AMF 244 and the 5G-EIR ( Figure 2 not shown). In addition to the functions of the AMF 244 described herein, the AMF 244 can also provide support for network slice restrictions and network slice instance restrictions based on NWDAF analysis.

[0099] The SMF 246 is responsible for: SM (e.g., session establishment, tunnel management between the UPF 248 and the NAN 214); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuration of traffic steering at the UPF 248 to route traffic to the appropriate destination; termination of the interface towards the policy control function; control of partial policy enforcement, charging, and QoS; lawful interception (for SM events and the interface with the LI system); termination of the SM part of the NAS message; DL data notification; initiation of AN-specific SM information, sent via the AMF 244 to the NAN 214 through N2; and determination of the SSC mode of the session. SM refers to the management of the PDU session, and the PDU session or "session" refers to the PDU connection service that provides or enables the PDU exchange between the UE 202 and the DN 236. The SMF 246 may also include the following functions to support edge computing enhancements (e.g., see [TS23548]): selection of the EASDF 261 and provision of its address to the UE as the DNS server for the PDU session; use of the EASDF261 service defined in [TS23548]; and provision and update of the ECS address configuration information to the UE for supporting the application layer architecture defined in [TS23558]. The discovery and selection process for the EASDF 261 is discussed in Section 6.3.23 of [TS23501].

[0100] The UPF 248 acts as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnecting with the data network 236, and a branching point for supporting multi-homed PDU sessions. The UPF 248 also performs packet routing and forwarding, packet inspection, enforcement of the user plane part of the policy rules, lawful interception of packets (UP collection), execution of traffic usage reporting, execution of QoS handling in the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), execution of UL traffic verification (e.g., SDF to QoS flow mapping), transport layer packet marking in UL and DL, and execution of DL packet buffering and DL data notification triggering. The UPF 248 may include a UL classifier to support routing of traffic flows to the data network.

[0101] The NSSF 250 selects a set of network slice instances serving the UE 202. The NSSF 250 also determines the allowed NSSAI and its mapping to the subscribed S-NSSAI as required. The NSSF 250 also determines a set of AMFs or a list of candidate AMFs 244 for serving the UE 202 based on appropriate configuration and possibly by querying the NRF 254. By interacting with the NSSF 250, the AMF 244 to which the UE 202 is registered can trigger the selection of a set of network slice instances for that UE 202; this may result in a change of the AMF 244. The NSSF 250 interacts with the AMF 244 via the N22 reference point; and can communicate with another NSSF in the visited network via the N31 reference point (not shown).

[0102] The NEF 252 securely exposes the services and capabilities provided by 3GPP NFs to third parties, internal exposure / re-exposure, AF 260, edge computing network / framework, etc. In such examples, the NEF 252 can authenticate, authorize, or throttle the AF 260. The NEF 252 uses the Nudr interface of the Unified Data Repository (UDR) to store / retrieve information as structured data. The NEF 252 also transforms the information exchanged with the AF 260 and the information exchanged with internal NFs. For example, as described in clause 5.6.7 of [TS23501], the NEF 252 can transform between AF service identifiers and internal 5GC information (e.g., DNN, S-NSSAI). In particular, the NEF 252 shields network and user sensitive information from the external AF 260 according to network policies. The NEF 252 also receives information from other NFs based on the capabilities exposed by those other NFs. This information can be stored in the NEF 252 as structured data, or stored in a data storage NF using a standardized interface. The stored information can then be re-exposed by the NEF 252 to other NFs and AFs, or used for other purposes such as analysis. For example, according to the provisions of [TS23288], the NWDAF analysis can be securely exposed to the outside by the NEF 252. In addition, the NWDAF 262 can collect externally provided data through the NEF 252 for generating analysis results. As described in [TS23288], the NEF 252 processes and forwards requests and notifications between the NWDAF 262 and the AF(s) 260. In some examples, the NEF 252 can provide one or more interfaces to one or more edge computing nodes 238, which can be used to handle the radio connection with the RAN 214 and / or offload tasks to the edge computing nodes 238.

[0103] The NRF 254 supports the service discovery function, receives NF discovery requests from NF instances, and provides the information of the discovered NF instances to the NF instance that makes the request. The NRF 254 also maintains the NF profiles of the available NF instances and the services they support. The NF profiles of the NF instances maintained in the NRF 254 include the following information: NF instance ID, NF type, PLMN ID (if it is a PLMN), PLMN ID + NID (if it is an SNPN), one or more network slice related identifiers (e.g., S-NSSAI, NSIID), one or more network addresses of the NF (e.g., FQDN, IP address, etc.), NF capacity information, NF priority information (e.g., for AMF selection), NF set ID, NF service set ID of the NF service instance; NF specific service authorization information; the name of the supported service (if applicable); one or more endpoint addresses of one or more instances of each supported service; the identification of the stored data / information (e.g., for UDR profiles and / or other NF profiles); one or more other service parameters (e.g., DNN or DNN list, LADN DNN or LADN DNN list, notification endpoints for each type of notification that the NF service is interested in receiving, etc.); the location information of the NF instance (e.g., geographical location, data center, etc.); one or more TAI; NF load information; routing indicator; home network public key identifier (for UDM 258 and AUSF 242); for UDM258, AUSF 242 and NSSAAF, in the case of accessing an SNPN using the credentials owned by a credential holder with an AAA server, the identification of the credential holder (e.g., subscription permanent identifier (SUPI) based on the network specific identifier domain); for UDM 258 and AUSF 242, if UDM 258 / AUSF 242 is used to access an SNPN using the credentials owned by a credential holder, the identification of the credential holder (e.g., the domain if a network specific identifier-based SUPI is used; or MCC and MNC if an IMSI-based SUPI is used); for AUSF 242 and NSSAAF, in the case of SNPN Onboarding using DCS with an AAA server, the identification of the DCS (e.g., the domain of the network specific identifier-based SUPI); for UDM 258 and AUSF 242, for SNPN Onboarding if UDM 258 / AUSF 242 is used as DCS, the identification of the DCS (e.g., the domain if a network specific identifier-based SUPI is used; or MCC and MNC if an IMSI-based SUPI is used); for AMF 244, one or more GUAMI;For UPF 248, see clause 5.2.7.2.2 of [TS23502]; for UDM 258, UDM group ID, the (one or more) ranges of SUPI, the (one or more) ranges of GPSI, the (one or more) ranges of internal group identifiers, the (one or more) ranges of external group identifiers; for UDR, UDR group ID, the (one or more) ranges of SUPI, the (one or more) ranges of GPSI, the (one or more) ranges of external group identifiers; for AUSF 242, AUSF group ID, the (one or more) ranges of SUPI; for PCF 256, PCF group ID, the (one or more) ranges of SUPI; for HSS, HSS group ID, the (one or more) sets of IMPI, the (one or more) sets of IMPU, the (one or more) sets of IMSI, the (one or more) sets of PSI, the (one or more) sets of MSISDN; for NEF 252, the (one or more) event IDs supported by AF 260; for NEF 252, the (one or more) event exposure service event IDs supported by UPF 248; for NEF 252, the (one or more) application identifiers supported by AF 260; for NEF 252, the (one or more) ranges of external identifiers or the domain names served by NEF (e.g., used when NEF 252 exposes AF information for analysis, as detailed in [TS23288]); in addition, NRF 254 may also store the mappings between UDM group ID and (one or more) SUPI, between UDR group ID and (one or more) SUPI, between AUSF group ID and (one or more) SUPI, and between PCF group ID and (one or more) SUPI, to discover UDM 258, UDR, AUSF 242, and PCF 256 using SUPI, SUPI ranges as specified in clause 6.3 of [TS23501], and / or interact with UDR to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID based on the UE identity (e.g., SUPI); for BSF, the IP domain list (as described in clause 6.1.6.2.21 of 3GPP TS29.510 v18.2 (2023-03-29) (“[TS29510]”)), the (one or more) ranges of (UE) IPv4 addresses or the (one or more) ranges of (UE) IPv6 prefixes, the (one or more) ranges of SUPI or the (one or more) ranges of GPSI or BSF group ID; the SCP domain to which the NF belongs; for DCCF 263, DCCF service area information, the NF type of the data source, the NF set ID of the data source (if any); for SMF 246, the list of supported DNAI;For SNPN, the ability to support SNPN Onboarding in the case of AMF, and the ability to support user plane remote provisioning in the case of SMF 246; for UPF 248, IP address range, DNAI; additional NF profile parameters related to V2X are defined in 3GPP TS 23.287; additional ProSe-related NF profile parameters are defined in 3GPP TS 23.304; additional MBS-related NF profile parameters are defined in 3GPP TS 23.247; additional UAS-related NF profile parameters are defined in TS 23.256; and many other parameters discussed in [TS23501]. In some examples, such as when the NF instance has special service authorization information, the service authorization information provided by the OAM system is also included in the NF profile.;

[0104] For NWDAF 262, the NF profile includes: (one or more) supported analysis IDs (possibly per service), NWDAF service area information (e.g., a list of TAIs for which NWDAF can provide services and / or data), supported analysis latency per analysis ID (if any), NF type of the NF data source, NF set ID of the NF data source (if any), analysis aggregation ability (if any), analysis metadata provisioning ability (if any), (one or more) ML model filtering information parameters S-NSSAI and (one or more) regions of interest of the (one or more) trained ML models per analysis ID (if any), federated learning (FL) ability type (e.g., FL server or FL client, if any), time interval supporting FL (if any). The NWDAF 262 service area information is common for all supported analysis IDs. The analysis IDs supported by NWDAF 262 can be associated with the supported analysis latency. For example, an analysis report can be generated within a time (including data collection latency and inference latency) less than or equal to the supported analysis latency. The determination of the supported analysis latency and how NWDAF 262 avoids frequent updates of its supported analysis latency in the NRF may be related to the specific implementation of NWDAF.

[0105] PCF 256 provides policy rules for the control plane function to enforce these rules and may also support a unified policy framework to manage network behavior. PCF 256 can also implement a front end to access subscription information related to policy decisions in the UDR 259 of UDM 258. In addition to communicating with functions via reference points as shown, PCF 256 also exposes Npcf service-based interfaces.

[0106] The UDM 258 processes subscription-related information to support network entities in handling communication sessions and stores the subscription data of the UE 202. For example, the subscription data can be communicated via the N8 reference point between the UDM 258 and the AMF 244. The UDM 258 can include two parts: an application front end and a UDR. The UDR can store subscription data and policy data for the UDM 258 and the PCF 256, and / or store structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 202) for the NEF 252. An interface based on the Nudr service can be presented by the UDR to allow the UDM 258, the PCF 256, and the NEF 252 to access specific stored data sets, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM 258 can include a UDM-FE responsible for handling credentials, location management, subscription management, etc. Multiple different front ends can serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identity processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 258 can also present an interface based on the Nudm service.

[0107] Edge Application Server Discovery Function (EASDF) 261 presents an interface based on the Neasdf service and is connected to the SMF 246 via the N88 interface. One or more EASDF instances can be deployed within a PLMN, and the interaction between (one or more) 5GC NFs and the EASDF 261 occurs within the PLMN. The EASDF 261 includes one or more of the following functions: registering to the NRF 254 for EASDF261 discovery and selection; processing DNS messages according to instructions from the SMF 246; and / or terminating DNS security (if used). Processing DNS information according to instructions from the SMF 246 includes one or more of the following functions: receiving DNS message processing rules and / or BaselineDNSPattern from the SMF 246; exchanging DNS messages with / from the UE 202; forwarding DNS messages to the C-DNS or L-DNS for DNS queries; adding the EDNS Client Subnet (ECS) option to DNS queries for FQDNs; reporting information related to the received DNS messages to the SMF246; and / or buffering / dropping DNS messages from the UE 202 or DNS servers. The EASDF has a direct user plane connection with the PSA UPF via N6 (e.g., without any NAT) to transport DNS signaling exchanged with the UE. Deployment of NAT between the EASDF 261 and the PSA UPF 248 may or may not be supported. Other aspects of the EASDF 261 are discussed in [TS23548].

[0108] The AF 260 provides application influence on traffic routing, provides access to the NEF 252, and interacts with the policy framework for policy control. The AF 260 can influence UPF 248 (re)selection and traffic routing. Depending on the operator's deployment, when the AF260 is considered a trusted entity, the network operator may allow the AF 260 to directly interact with the relevant NFs. In some implementations, the AF 260 is used for edge computing implementations.

[0109] NFs that need to collect data from the AF 260 can directly subscribe / unsubscribe from the AF 260 or via the NEF 252 for notifications about data collected from the AF260. The data collected from the AF 260 is used as the analysis input for the NWDAF 262. Details of the data collected from the AF 260 and the interaction between the NEF 252, AF 260, and NWDAF 262 are described in [TS23288].

[0110] The 5GC 240 can implement edge computing by selecting an operator / third-party service that is geographically close to the point where the UE 202 is attached to the network. This can reduce latency and network load. In the edge computing implementation, the 5GC 240 can select a UPF 248 close to the UE 202 and perform traffic steering from the UPF 248 to the DN 236 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 260, which allows the AF 260 to influence UPF (re)selection and traffic routing.

[0111] The data network (DN) 236 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, such as including an application (App) / content server 238. The DN 236 can be an external public network of the operator, a dedicated PDN, or an internal packet data network of the operator, for example, for providing IMS services. In this example, the application server 238 can be coupled to the IMS via an S-CSCF or an I-CSCF. In some implementations, the DN 236 can represent one or more local DNs (LADNs), where the LADN is a DN 236 (or DN name (DNN)) that the UE 202 can access in one or more specific regions. Outside of these specific regions, the UE 202 cannot access the LADN / DN 236.

[0112] Additionally or alternatively, the DN 236 can be an edge DN 236, which is a (local) DN that supports an architecture enabling edge applications. In these examples, the application server 238 can represent a physical hardware system / device providing application server functionality, and / or application software of an edge computing node residing in the cloud or performing (one or more) server functions. In some examples, the application / content server 238 provides an edge hosting environment that provides the support required for the execution of an edge application server.

[0113] In some examples, the 5GS can use one or more edge computing nodes to provide interfaces and offload processing of wireless communication traffic. In these examples, the edge computing nodes can be included in or co-located with one or more RANs 204 or RAN nodes 214. For example, the edge computing nodes can provide a connection between the RAN 204 and the UPF 248 in the 5GC 240. The edge computing nodes can use one or more NFV instances instantiated on the virtualization infrastructure within the edge computing nodes to process wireless connections to and from the RAN 214 and the UPF 248.

[0114] In some implementations, the edge computing node provides a distributed computing environment for application and service hosting and also provides storage and processing resources to enable data and / or content to be processed closer to the subscriber (e.g., the user of UE 202), thus accelerating the response time. The edge computing node also supports the (one or more) hosting environments for multi-tenant runtimes and applications, including virtual device applications, middleware applications, and infrastructure services that can be delivered as packaged virtual machine (VM) images, content delivery services including content caching, mobile big data analytics, and compute offloading, etc. Compute offloading includes offloading compute tasks, workloads, applications, and / or services from UE 202, CN 240, DN 236, and / or (one or more) servers 238 to the edge computing node and vice versa. For example, a device application or a client application running in UE 202 can offload an application task or workload to one or more edge computing nodes. In another example, the edge computing node can offload an application task or workload to a group of UEs 202 (e.g., for distributed machine learning computations, etc.).

[0115] The edge computing node can include or be part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as "edge computing frameworks", etc.). The edge computing node can also be referred to as an "edge host" or an "edge server". The edge system includes a collection of edge servers and an edge management system (not shown) required to run edge computing applications in a carrier network or a subset of the carrier network. An edge server is a physical computer system that can include an edge platform and / or virtualization infrastructure and provides computing, storage, and network resources to edge computing applications. Each edge server is disposed at the edge of a corresponding access network and is arranged to provide computing resources and / or various services (e.g., compute task and / or workload offloading, cloud computing capabilities, IT services, and other similar resources and / or services discussed herein) relatively close to UE 202. The VI of the edge computing node provides a virtualization environment and virtualization resources for the edge host, and edge computing applications can run on the VI as VMs and / or application containers.

[0116] In an example implementation, the ECT is part of and / or operates according to the MEC framework, such as those discussed in the following documents: ETSI GR MEC 001v3.1.1 (2022-01), ETSI GS MEC 003v3.1.1 (2022-03), ETSI GS MEC 009v3.1.1 (2021-06), ETSI GS MEC 010-1v1.1.1 (2017-10), ETSI GS MEC 010-2v2.2.1 (2022-02), ETSI GS MEC 011v2.2.1 (2020-12), ETSI GS MEC 012V2.2.1 (2022-02), ETSI GS MEC 013V2.2.1 (2022-01), ETSI GS MEC 014v2.1.1 (2021-03), ETSI GS MEC015v2.1.1 (2020-06), ETSI GS MEC 016v2.2.1 (2020-04), ETSI GS MEC 021v2.2.1 (2022-02), ETSI GR MEC 024v2.1.1 (2019-11), ETSI GS MEC 028V2.2.1 (2021-07), ETSI GS MEC029v2.2.1 (2022-01), ETSI MEC GS 030v2.1.1 (2020-04), and ETSI GR MEC 031v2.1.1 (2020-10) (collectively referred to herein as "[MEC]").This example implementation (and / or any other example implementation discussed herein) may also include NFV and / or other similar virtualization technologies such as those discussed in the following documents: ETSI GR NFV 001 V1.3.1 (2021-03), ETSI GS NFV 002 V1.2.1 (2014-12), ETSI GR NFV 003 V1.6.1 (2021-03), ETSI GS NFV 006 V2.1.1 (2021-01), ETSI GS NFV-IF 001 V1.1.1 (2015-01), ETSI GS NFV-IF 003 V1.1.1 (2014-12), ETSI GS NFV-INF 004 V1.1.1 (2015-01), ETSI GS NFV-MAN 001 v1.1.1 (2014-12), and / or Israel et al., OSM Release FIVE Technical Overview, ETSI OPENSOURCE MANO, OSM White Paper, 1st ed. (January 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf (collectively referred to as "[ETSI NFV]"). Other virtualization technologies and / or service orchestration and automation platforms may be used, such as the virtualization technologies and / or service orchestration and automation platforms discussed in the following: E2E Network Slicing Architecture, GSMA, Official Doc. NG.127, v1.0 (June 3, 2021); https: / / www.gsma.com / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf, Open Network Automation Platform (ONAP) documentation, Release Istanbul, v9.0.1 (February 17, 2022); https: / / docs.onap.org / en / latest / index.html ("[ONAP]"); 3GPP TS 28.533 v17.1.0 (2021-12-23) ("[TS28533]") which discusses the 3GPP Service-Based Management Architecture (SBMA).

[0117] In another example implementation, the ECT is part of and / or operates according to the O-RAN framework. Various aspects of the O-RAN architecture are described in the following: O-RAN Working Group 1 (Use Cases and Overall Architecture), O-RAN Architecture Description, O-RAN Alliance WG1, O-RAN Hardening Description v09.00, Release 003 (June 2023) (“[ORAN.OAD]”); O-RAN Working Group 1 Slice Architecture, O-RAN Alliance WG1, Slice Architecture Technical Specification v10.00, Release 003 (June 2023); O-RAN Working Group 1 Use Case Detailed Specification Architecture, v11.00, Release 003 (June 2023) (“[ORAN.UseCases]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: Application Protocol, v04.00, R003 (March 2023) (“[ORAN.A1AP]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: General Aspects and Principles, v03.01, Release 003 (March 2023) (“[ORAN.A1GAP]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: Type Definitions, v05.01, R003 (June 2023) (“[ORAN.A1TD]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: Transport Protocol, v02.01, R003 (March 2023); O-RAN Working Group 2 AI / ML Workflow Description and Requirements v01.03 O-RAN Alliance WG2 (October 2021) (“[ORAN.AIML]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group): R1 Interface: General Aspects and Principles 5.0, v05.00, R003 (June 2023); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) Non-RT RIC Architecture, v03.00, Release 003 (June 2023) (“[O-RAN.Non-RT-RIC-ARCH]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group): Use Cases and Requirements, v07.00, Release 003 (June 2023) (“[O-RAN.Use-Case-Requirements]”); O-RAN Working Group 3 Near Real-Time RAN Intelligent Controller Architecture and E2 General Aspects and Principles, v03.01, Release 003 (June 2023) (“[ORAN.E2GAP]”); O-RAN Working Group 3, Near Real-Time Intelligent Controller, E2 Application Protocol (E2AP), v03.01, Release 003 (June 2023) (“[ORAN.=O-RAN Working Group 3, Near Real-Time Intelligent Controller E2 Service Model (E2SM), v03.01, Release R003 (June 2023) (“[ORAN.E2SM]”); O-RAN Working Group 3, Near Real-Time Intelligent Controller E2 Service Model (E2SM) KPM, v03.00, Release R003 (March 2023) (“[ORAN.E2SM-KPM]”); O-RAN Working Group 3 Near Real-Time Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control, v01.01, Release R003 (March 2023) (“[ORAN.E2SM-CCC]”); O-RAN Working Group 3 Near Real-Time Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control, v01.01, Release R003 (March 2023) (“[ORAN.E2SM-CCC]”); Controller E2 Service Model (E2SM) RAN Functional Network Interface (NI) v01.00 (February 2020) (“[ORAN.E2SM-NI]”); O-RAN Working Group 3 Near Real-Time Intelligent Controller E2 Service Model (E2SM) RAN Control v03.00, Release R003 (June 2023) (“[ORAN.E2SM-RC]”); O-RAN Working Group 3 (Near Real-Time RAN Intelligent Controller and E2 Interface Working Group): Near Real-Time RIC Architecture, v04.00, Release R003 (March 2023) (“[ORAN.RICARCH]”); O-RAN Working Group 4 (Open Fronthaul Interface Working Group) Control, User and Synchronization Platform O-RAN Fronthaul Working Group 4, Cooperative Transport Interface Transport Control Plane Specification, v04.00, Release R003 (June 2023); O-RAN Fronthaul Working Group 4, Cooperative Transport Interface Transport Management Plane Specification, v12.00, Release R003 (June 2023) (“[ORAN.MP]”); O-RAN Alliance Working Group 5, O1 Interface Specification for O-CU-UP and O-CU-CP, v05.00, Release R003 (June 2023); O-RAN Alliance Working Group 5, O1 Interface Specification for O-DU, v07.00, Release R003 Version (June 2023); O-RAN Alliance Working Group 6, O2 Interface General Aspects and Principles 4.0, v04.00, Version R003 (June 2023); O-RAN Working Group 6 (Cloudification and Coordination) O-RAN Virtualized RAN Cloud Architecture and Deployment Scenarios v04.00 (October 2022) (“[ORAN.CADS]”); O-RAN Working Group 6 (Cloudification and Coordination Working Group): O-RAN Acceleration Abstraction Layer General Aspects and Principles, v06.00, Version R003 (June 2023); O-RAN Working Group 6: O-Cloud Notification API Specification for Event Consumers, v03.00 (October 2022) (“[ORAN.O-RAN White Box Hardware Working Group, Hardware Reference Design Specification for Indoor Pico Cell with Fronthaul Split Option 6, v02.00, O-RAN Alliance WG7 (October 2021) (“[ORAN.IPC-HRD-Opt6]”); O-RAN WG7, Hardware Reference Design Specification for Indoor Pico Cell (FR1) with Split Architecture Option 7-2, v03.00, O-RAN Alliance WG7 (October 2021) (“[ORAN.IPC-HRD-Opt7-2]”); O-RAN WG7, Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 8, v03.00 (October 2021) (“[ORAN.IPC-HRD-Opt8]”); O-RAN White Box Hardware Working Group, Hardware Reference Design Specification for Outdoor Microcell with Split Architecture Option 7.2, v03.00, O-RAN Alliance WG7 (October 2022) (“[ORAN.OMC-HRD-Opt7-2]”); O-RAN White Box Hardware Working Group, Hardware Reference Design Specification for Outdoor Macro Cell with Split Architecture Option 7.2, v03.00, Release R003 (June 2023) (“[ORAN.OMAC-HRD]”); O-RAN Open X-haul Transport Working Group, Management Interface for Transport Network Elements, v06.00, Release R003 (June 2023); O-RAN Open Transport Working Group 9, Xhaul Packet Switching Architecture and Solutions, v05.00, Release R003 (2 O-RAN.XPSAAS, June 2023) (“[ORAN.XPSAAS]”); O-RAN Open Xhaul Transport Working Group, Synchronized Architecture and Solution Specification, v03.00 (October 2022); O-RAN Open Xhaul Transport WG9, WDM-based Front-end Transport, v03.00, Release R003 (March 2023); O-RAN Operation and Maintenance Architecture, v09.00, Release R003 (June 2023) (“[ORAN.OAM-Arch]”); O-RAN Operation and Maintenance Interface Specification, v10.00, O-RAN Alliance WG10, Version R003 (June 2023) (“[ORAN.O1-Interface]”); O-RAN Information Model and Data Model Specification v05.00, O-RAN Alliance WG10, Version R003 (June 2023); and O-RAN: Towards an Open and Intelligent RAN, O-RAN Alliance White Paper (October 2018) (collectively, “[O-RAN]”). .

[0118] In another example implementation, the ECT is an architecture enabling edge applications of the 3rd Generation Partnership Project (3GPP) System Architecture Working Group 6 (SA6) (referred to as "[3GPP Edge Computing]" for short) and / or operates according to the architecture enabling edge applications of 3GPP SA6 (referred to as "[3GPP Edge Computing]" for short). For example, the architecture enabling edge applications of 3GPP SA6 (referred to as "[3GPP Edge Computing]" for short) is discussed in the following documents: 3GPP TS23.222 ("[TS23222]"), 3GPP TS23.401, 3GPP TS23.434 ("[TS23434]"), 3GPP TS23.501 ("[TS23501]"), 3GPP TS23.502 ("[TS23502]"), 3GPP TS23.548 ("[TS23548]"), 3GPP TS23.558 ("[TS23558]"), 3GPP TS23.682 ("[TS23682]"), 3GPP TR 23.700-98 ("[TR23700-98]"), 3GPP TS 28.104 ("[TS28104]"), 3GPP TS28.105 ("[TS28105]"), 3GPP TS 28.532 ("[TS28532]"), 3GPP TS28.533 ("[TS28533]"), 3GPP TS 28.535 ("[TS28535]"), 3GPP TS28.536 ("[TS28536]"), 3GPP TS28.538 ("[TS28538]"), 3GPP TS28.541 ("[TS28541]"), 3GPP TS 28.545 ("[TS28545]"), 3GPP TS28.550 ("[TS28550]"), 3GPP TS 28.554 ("[TS28554]"), 3GPP TS28.622 ("[TS28622]"), 3GPP TS 29.122 ("[TS29122]"), 3GPP TS29.222 ("[TS29222]"), 3GPP TS 29.522 ("[TS29522]"), 3GPP TR 28.908 ("[TR28908]"), 3GPP TS 33.122 ("[TS33122]") (collectively referred to as "[5GEdge]").

[0119] In another example implementation, the ECT is the following item and / or operates according to the following item: The Smart Edge Open Framework (previously known as OpenNESS), which framework is in Discussed in the Smart Edge Open Developer Guide, Version 21.09 (September 30, 2021), available at https: / / smart-edge-open.github.io / (“[ISEO]”).

[0120] In another example implementation, the ECT operates according to the Multi-Access Management Service (MAMS) framework, which is discussed in the following documents: Kanugovi et al., Multi-Access Management Service (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (March 2020) (“[RFC8743]”); Ford et al., TCP Extensions for Multipath Operations with Multiple Addresses, IETF RFC 8684, (March 2020); De Coninck et al., Multipath Extensions for QUIC (MP-QUIC), IETF DRAFT-DECONINCK-QUIC-MULTIPATH-07, IETA, QUIC Working Group (May 3, 2021); Zhu et al., User Plane Protocol for Multi-Access Management Service, IETF DRAFT-ZHU-INTAREA-MAMS-USER-PROTOCOL-09, IETA, INTAREA (March 4, 2020); and Zhu et al., General Multi-Access (GMA) Convergence Encapsulation Protocol, IETF RFC 9188 (February 2022) (collectively referred to as “[MAMS]”).

[0121] It should be understood that the above-described edge computing framework / ECT and service deployment examples are merely illustrative examples of ECT, and the present disclosure is applicable to many other or additional edge computing / network technologies in various combinations and layouts of devices located at the network edge (including various edge computing networks / systems described herein). Additionally, the techniques disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be applicable to the present disclosure. Examples of such edge computing / network technologies include: [MEC]; [O-RAN]; [ISEO]; [5GEdge]; content delivery networks (CDNs) (also referred to as "content distribution networks", etc.); mobile service provider (MSP) edge computing and / or mobile as a service (MaaS) provider systems (e.g., systems used in the AECC architecture); nebula edge cloud systems; fog computing systems; small slice cloud edge cloud systems; mobile cloud computing (MCC) systems; re-architected central office as a data center (CORD), mobile CORD (M-CORD), and / or converged multi-access and core (COMAC) systems; and / or similar systems. Additionally, the techniques disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be used for the purposes of the present disclosure.

[0122] The interfaces of the 5GC 240 include reference points and service-based interfaces. At least in some examples, a reference point is a junction point of two non-overlapping functional groups, elements, or entities. The reference points include: N1 (between the UE 202 and the AMF 244), N2 (between the RAN 214 and the AMF 244), N3 (between the RAN 214 and the UPF 248), N4 (between the SMF 246 and the UPF 248), N5 (between the PCF 256 and the AF 260), N6 (between the UPF 248 and the DN 236), N7 (between the SMF 246 and the PCF 256), N8 (between the UDM 258 and the AMF244), N9 (between two UPF 248s), N10 (between the UDM 258 and the SMF 246), N11 (between the AMF 244 and the SMF 246), N12 (between the AUSF 242 and the AMF 244), N13 (between the AUSF 242 and the UDM 258), N14 (between two AMF 244s; not shown), N15 (between the PCF 256 and the AMF 244 in a non-roaming scenario or between the PCF 256 of the visited network and the AMF 244 in a roaming scenario), N16 (between two SMF 246s; not shown), and N22 (between the AMF 244 and the NSSF 250). Other reference point notations not shown may also be used, such as any of those discussed in [TS23501]. Figure 2 Other reference point notations not shown in [TS23501] may also be used, such as any of those discussed in [TS23501].

[0123] Figure 2 In the service-based notation, NFs within the control plane are represented, and such NFs enable other authorized NFs to access their services. At least in some examples, a service-based interface (SBI) can enable an NF to access the services of one or more other NFs via this interface. In some implementations, the service-based interface is an API-based interface (e.g., northbound API, southbound API, HTTP / 2, RESTful, SOAP, A1AP, E2AP, and / or any other API, web service, application layer, and / or other communication protocols, such as any protocol discussed herein), and NFs can use these interfaces to invoke or call specific services or service operations. The SBI includes: Namf (SBI presented by AMF 244), Nsmf (SBI presented by SMF 246), Nnef (SBI presented by NEF 252), Npcf (SBI presented by PCF 256), Nudm (SBI presented by UDM 258), Naf (SBI presented by AF 260), Nnrf (SBI presented by NRF 254), Nnssf (SBI presented by NSSF 250), Nausf (SBI presented by AUSF 242). Other service-based interfaces not shown herein (e.g., Nudr, N5g-eir, and Nudsf) can also be used, such as any interface discussed in [TS23501]. Figure 2 Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf), such as any interface discussed in [TS23501].

[0124] Although Figure 2 not shown, the system 200 may also include NFs not shown, such as UDR, unstructured data storage function (UDSF), network slice admission control function (NSACF), network slice specific and stand-alone non-public network (SNPN) authentication and authorization function (NSSAAF), UE radio capability management function (UCMF), 5G device identity register (5G-EIR), charging function (CHF), time-sensitive network (TSN) AF 260, time-sensitive communication and time synchronization function (TSCTSF), data collection coordination function (DCCF), analytical data repository function (ADRF), message framework adapter function (MFAF), binding support function (BSF), non-seamless WLAN offloading function (NSWOF), service communication proxy (SCP), secure edge protection proxy (SEPP), non-3GPP interworking function (N3IWF), trusted non-3GPP gateway function (TNGF), wired access gateway function (W-AGF), and / or trusted WLAN interworking function (TWIF), as described in [TS23501].

[0125] The present disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, data centers, network topologies, communication system implementation, network convergence, artificial intelligence (AI) / machine learning (ML) technologies, and more particularly to techniques for network data analytics function (NWDAF) energy information analysis to support an energy-efficient fifth generation (5G) network.

[0126] Existing 3rd Generation Partnership Project (3GPP) research related to climate change and / or energy efficiency has focused more on how to meet user experience while striving to achieve energy efficiency and implement energy efficiency within the network. As a result, the requirements, use cases, and solutions are basically within the scope of the network itself. Verticals and customers cannot obtain energy efficiency-related information from the network.

[0127] Energy consumption is an important source of the operating costs of mobile network operators (MNOs), and depending on the energy generation mix used to power the network, it may also have a negative impact on the environment. 3GPP has been doing more and more work in improving energy efficiency and saving energy. Some solutions have studied how to optimize energy consumption by adjusting the network itself, such as activating and deactivating parts of the network. In some cases, such changes to the network topology and components may be transparent to the network architecture, but in other cases, such changes must impact the architecture, such as reselecting appropriate network functions.

[0128] Introducing energy efficiency as a service (EaaS) will allow users to select appropriate energy efficiency standards and other network performance parameters when needed. For example, it includes being able to define and support energy efficiency standards as part of the communication services provided to users and application services, and / or providing information about the system's energy consumption or energy efficiency level to vertical customers.

[0129] For example, in the convenient scenario of satellites and the ground, for some areas with both satellite and ground coverage, energy conservation can be taken as a dimension when providing communication services, and users or operators can choose to find the best way to both meet user experience and improve energy efficiency. From another perspective, the network can also respond to different energy consumption patterns of applications or adjust network resources.

[0130] Both of the above aspects may require more interaction between the application and the network regarding the energy consumption status. It is worth considering how to deliver services according to the preferences of vertical industries, using EaaS standards, and how to support strategies for handling energy as part of a subscription.

[0131] SA1 has determined the requirements for the first phase of the EaaS standard in the FS_EnergyServ study. The goal of energy efficiency is to provide the same services more efficiently, while the goal of energy usage control as a service standard is to supervise services in an energy-aware manner, ensuring that service providers, network operators, or subscribers provide services as expected, and determining constraints and consequences. In the SA1 FS_EnergyServ study, a number of functional requirements have been identified that promise to strengthen the control of energy usage to achieve service goals for mobile network operators, service providers, and their customers. Examples of these functional requirements include the ability to control energy usage based on operator policies, such as "energy credit limit" and "maximum energy usage rate" applicable to services provided to a UE or a group of UEs.

[0132] In addition, 3GPP has been working in different working groups to provide recommendations on energy conservation and practical OAM or radio network enhancements to save energy. The SA plenary session has also issued a 3GPP-wide recommendation considering energy efficiency as an important design criterion for the technical solutions defined by 3GPP in its specifications (see 3GPP TDoc SP-211621). SA2 is also required to study improved system behavior scenarios aimed at energy conservation. It is recommended that SA2 study the architectural impacts and functional extensions required for efficient energy usage and energy conservation.

[0133] As part of the (Rel-)19th version study on enhancing energy efficiency and energy conservation in 5GS approved by 3GPP SA2 (e.g., see the new SID on enhancing energy efficiency and energy conservation in 5GS, 3GPP TSG-SA meeting #101, Bangalore, India, TDoc SP-231192 (September 11 - 15, 2023)), it has been agreed to study the following work tasks (WT): WT#3, study the enhancements to 5GS for network energy conservation, including the interaction, analysis, etc. of 5GC (NF) and NG-RAN (e.g., adjusting the energy usage of NFs from the CN side, energy conservation-related decisions, NF selection using the energy state of NFs). The impact on UEs is not excluded, such as the cases specified by SA1 EnergyServ in TR22.882.

[0134] Figure 3 An example 5GS architecture according to some embodiments is shown. Figure 3 The other network elements (NE) / network functions (NF) described will be discussed in detail in conjunction with Figure 2 The energy efficiency control function (EECF) (e.g., EECF in Figure 3 or EECF 270 in Figure 2 includes the following functions: energy efficiency management, policy enforcement, and monitoring and analysis.

[0135] Regarding energy efficiency management, the EECF can evaluate the energy consumption of network functions and devices based on current network conditions, user requirements, predefined energy efficiency policies, etc., and provide evaluation results.

[0136] Regarding policy execution, the EECF can execute energy-related policies set by network operators, which may include maximum energy usage thresholds per subscriber, or per PDU session, or per network slice, preferred operating states for energy saving, maximum energy credit for specific subscribers, energy-efficient routing of data, etc. In some embodiments, the EECF can query the PCF to obtain energy-related policies set by network operators.

[0137] Regarding monitoring and analysis, the EECF can provide functions to support the monitoring and analysis of energy consumption patterns or energy-efficient routing of data, enabling network operators to make informed decisions on energy management policies. In some embodiments, the EECF can use the services provided by the NWDAF to generate the required analysis of energy consumption patterns.

[0138] In some embodiments, the EECF or the functions of the EECF can be co-located with one or more other NFs (e.g., NWDAF, PCF, SMF, AMF, NEF, etc.) or otherwise incorporated into these NFs.

[0139] The following definitions may be relevant to various aspects of the present disclosure.

[0140] The term "UE's energy profile data" includes, at least in some examples, the maximum energy credit limit associated with the subscription, permanent equipment identifier (PEI), group identifier, etc. The UE's energy profile data can be defined as a new subscription data type stored in the UDM.

[0141] The term "network function's energy profile data" or "NF's energy profile data" includes, at least in some examples, the average energy consumption of the network function, the energy states supported by the network function, the energy saving levels supported by the network function, etc. defined in clause 6.7.3.1.1 of 3GPP TS28.554 V18.4.0 (2023-12) ([TS28554]).

[0142] The term "network function's energy state" or "NF's energy state" includes, at least in some examples, the energy states defined for the NF, which include the InEnergySaving state and the NotEnergySaving state. At least in some examples, the term "energy saving state" refers to a state in which the NF consumes less energy than when the NF is in the non-energy-saving state.

[0143] In some embodiments, the energy-saving state may include multiple energy-saving levels. Each energy-saving level corresponds to a predefined or configurable energy consumption range of the NF within a given time period. For example, the energy-saving levels include "low", "medium", and "high" levels. In another example, each energy-saving level may be represented by a number (e.g., 0, 1, 2, 3,......, E, where E is a number). The mapping between each energy-saving level and the corresponding energy consumption range may be determined, defined, or configured by the network operator according to the energy efficiency goals to be achieved by the 5G network. Additionally or alternatively, each energy-saving level may be set as the percentage of time that the network function is in the energy-saving state within a given time period to meet the corresponding criteria set for the maximum energy consumption limit of the NF determined, predefined, and / or configured by the network operator.

[0144] In some embodiments, terms such as "UE's energy profile data", "UE's energy profile", "UE's energy data profile subscription data", "UE's energy profile subscription data", etc. may be interchangeable. In some embodiments, terms such as "NF's energy profile data", "NF's energy profile", etc. may be interchangeable. In some embodiments, terms such as "energy-related policy information", "energy policy information", etc. may be interchangeable. In some embodiments, terms such as "energy-saving", "high energy efficiency", etc. may be interchangeable.

[0145] Below, the present disclosure provides various solutions to address how to support the energy efficiency function in 5GS. In particular, the present disclosure provides enhancements to the NWDAF (e.g., Figure 2 NWDAF 262 therein) to support the energy-saving function, and defines new analytics to support energy-saving at a granular level according to the requirements of the analysis consumer. The analysis consumer may be, for example, the EECF (e.g., Figure 3 EECF therein or Figure 2 EECF 270 therein), SMF (e.g., Figure 3 SMF therein or Figure 2 SMF 246 therein), PCF (e.g., Figure 3 PCF therein or Figure 2 PCF 256 therein), AMF (e.g., Figure 3 AMF therein or Figure 2 AMF 244 therein).

[0146] Figure 4 An example of a method 400 for obtaining energy information analysis according to some embodiments of the present disclosure is shown. Method 400 may be executed by a service consumer (e.g., a NWDAF consumer). However, the present disclosure is not limited in this regard. As shown, method 400 includes operations 410 and 420.

[0147] At 410, an encoded energy information analysis request is transmitted to the NWDAF. At 420, an energy information analysis response received by the NWDAF in response to the energy information analysis request is decoded to obtain the energy information analysis.

[0148] In some embodiments, the energy information analysis is obtained based on a subscription service or a notification service. In some embodiments, the energy information analysis request includes an Nnwdaf_AnalyticsSubscription subscription, and the energy information analysis response includes an Nnwdaf_AnalyticsSubscription notification. In some embodiments, the energy information analysis request includes an Nnwdaf_AnalyticsInfo request, and the energy information analysis response includes an Nnwdaf_AnalyticsInfo response. However, in some embodiments, the energy information analysis may be obtained based on another service, and the present disclosure is not limited in this regard.

[0149] In some embodiments, the energy information analysis includes energy efficiency data at the following levels: network level, UE level, UE group level, network slice level, protocol data unit (PDU) session level, etc.

[0150] Additionally or alternatively, in some embodiments, a service consumer may request the NWDAF to provide other analyses. For example, the service consumer may encode an NF load analysis request for transmission to the NWDAF and decode an NF load analysis response received from the NWDAF in response to the NF load analysis request to obtain the NF load analysis. In another example, the service consumer may encode an NF performance analysis request for transmission to the NWDAF and decode an NF performance analysis response received from the NWDAF in response to the NF performance analysis request to obtain the NF performance analysis. In yet another example, the service consumer may encode a data network (DN) service performance analysis request for transmission to the NWDAF and decode a DN service performance analysis response received from the NWDAF in response to the DN service performance analysis request to obtain the DN service performance analysis. However, the present disclosure is not limited in this regard.

[0151] Figure 5 An example of a method 500 for obtaining an energy information analysis according to some embodiments of the present disclosure is shown. The method 500 may be performed by a service producer (e.g., the NWDAF). However, the present disclosure is not limited in this regard. As shown, the method 500 includes operations 510 to 540.

[0152] At 510, decode an energy information analysis request received from a service consumer for energy information analysis. At 520, in response to the energy information analysis request, collect data from an NF, an operations administration and maintenance (OAM) entity / function, or an application function (AF). At 530, generate an energy information analysis based on the data. At 540, encode an energy information analysis response carrying the energy information analysis for transmission to the service consumer.

[0153] The service consumer may include a fifth-generation (5G) core network (5GC) NF, such as, for example, an EECF, a PCF, an SMF, an AMF, etc. The NF from which data is collected may include a PCF, an SMF, a UPF, etc. These NFs are merely examples and the present disclosure is not limited thereto.

[0154] Additionally or alternatively, in some embodiments, the service producer may provide other analyses to the service consumer. For example, the service producer may: decode an NF load analysis request received from the service consumer for NF load analysis; in response to the NF load analysis request, collect data from an NF, an OAM entity / function, or an AF; generate an NF load analysis based on the data; and encode an NF load analysis response carrying the NF load analysis for transmission to the service consumer. In another example, the service producer may: decode an NF performance analysis request received from the service consumer for NF performance analysis; in response to the NF performance analysis request, collect data from an NF, an OAM entity / function, or an AF; generate an NF performance analysis based on the data; and encode an NF performance analysis response carrying the NF performance analysis for transmission to the service consumer. In yet another example, the service producer may: decode a DN service performance analysis request received from the service consumer for DN service performance analysis; in response to the DN service performance analysis request, collect data from an NF, an OAM entity / function, or an AF; generate a DN service performance analysis based on the data; and encode a DN service performance analysis response carrying the DN service performance analysis for transmission to the service consumer. However, the present disclosure is not limited in this regard.

[0155] Method 500 is described from the perspective of a service producer and can be understood in combination with the embodiments of method 400, where method 400 is described from the perspective of a service consumer and will not be elaborated herein.

[0156] Figure 6Shows an example process for obtaining analytics from the NWDAF according to some embodiments of the present disclosure. As described above, the NWDAF consumer analyzes from the NWDAF. The NWDAF consumer may include NFs, such as, for example, EECF, SMF, PCF, AMF, etc. Additionally or alternatively, when the EECF function is co-located with other NFs in the 5GC (such as, for example, PCF, SMF), the consumers of the NWDAF service may be, for example, PCF, SMF, or AMF, etc. Figure 6 The process can operate as follows.

[0157] 1a. The consumer NF (e.g., NWDAF consumer) may send an Energy Information analysis request to the NWDAF using the Nnwdaf_AnalyticsInfo or Nnwdaf_AnalyticsSubscription service. The analysis ID is set to "EnergyInformation", and the settings for the target of the analysis report and the analysis filtering information are as described below.

[0158] 1b. The consumer NF (e.g., NWDAF consumer) may request statistics or predictions, and the analysis may be requested together with filtering information. The consumer NF uses the Nnwdaf_AnalyticsInfo or Nnwdaf_AnalyticsSubscription service to send a request for NF load analysis to the NWDAF. The analysis ID is set to "NF Load".

[0159] 1c. The consumer NF (e.g., NWDAF consumer) may use the Nnwdaf_AnalyticsInfo or Nnwdaf_AnalyticsSubscription service to send a request for NF performance analysis to the NWDAF. The analysis ID is set to "NF Performance".

[0160] 1d. The consumer NF (e.g., NWDAF consumer) may use the Nnwdaf_AnalyticsInfo or Nnwdaf_AnalyticsSubscription service to send a request for DN service performance analysis to the NWDAF. The analysis ID is set to "DN Service Performance".

[0161] 2. The NWDAF may collect the required data from the OAM (operation 2a), (one or more) other NFs in the 5GC (operation 2b), and / or the AF (operation 2c) as described below to generate the energy information analysis, NF load analysis, NF performance analysis, or DN service performance analysis requested in operation 1. In some examples, the NFs from which data is collected in operation 2b may include PCF, SMF, and / or UPF.

[0162] 3. The NWDAF can derive the requested analysis.

[0163] 4. The NWDAF can send an Nnwdaf_AnalyticsSubscription_Notify or Nnwdaf_AnalyticsInfo_Request response (for the output of the analysis requested in operation 1, [subscription related identifier], confidence) to the consumer NF (e.g., NWDAF consumer). In other examples, the OAM can send an Nnwdaf_AnalyticsSubscription_Notify or Nnwdaf_AnalyticsInfo_Request response to the consumer NF (e.g., NWDAF consumer).

[0164] The order of operations is not limited to Figure 6 the order shown.

[0165] In some embodiments, the NWDAF consumer (e.g., EECF) can directly request the Management Data Analytics Function (MDAF) for energy saving recommendation analysis.

[0166] Below, some embodiments will be provided to describe the energy information analysis.

[0167] In some embodiments, the NWDAF can provide analysis to the 5GC NF, OAM, and / or AF. The NWDAF including AnLF can perform inference based on the analysis information requested by the NWDAF consumer using the Nnwdaf_AnalyticsSubscription or Nnwdaf_AnalyticsInfo service operation to derive the analysis information.

[0168] According to various embodiments, the NWDAF supports new energy information analysis (and / or energy information analysis ID). According to the NWDAF consumer request, the energy information analysis can represent energy efficiency data at the following levels: network level (e.g., only UPF, UPF+gNB combination, UPF+gNB combination per UE, etc.), UE level, UE group, per network slice level, based on a given UE per PDU session, etc.

[0169] As part of the analysis report objective and analysis filtering information, the consumer of the energy information analysis can request the following information for the analysis target period: NWDAF analysis information on energy state change statistics or prediction; energy information at the required granularity (per PDU session, per UE or UE group, per network slice, per application ID, per QoS flow, per NF or NF group supporting the establishment of a PDU session, or per NF group as part of a network slice). The consumer can request subscription or individual notification through request / response service operations.

[0170] A service consumer of the NWDAF for energy information analysis can be any one or more NFs in the 5GC. For example, the EECF, PCF, SMF, AMF, AF, and / or any other NF, such as any NF mentioned in this document and / or [TS23501].

[0171] In some embodiments, the energy information analysis requested by the NWDAF service consumer may include some or all of the following parameters:

[0172] - Analysis ID: "Energy Information"

[0173] - The target of the analysis report indicates one or more objects (for which the energy information analysis is requested for the one or more objects). For example, a given UE, a group of UEs, an NF that serves a given UE or group of UEs, a gNB that serves a given UE or group of UEs, an NF that belongs to the 5GC that serves a given UE or group of UEs. Further filtering criteria for each of these analysis report targets are included in the analysis filtering information.

[0174] - The analysis filtering information indicates the criteria / conditions that the reported analysis information needs to meet. For example, this may include:

[0175] o Energy saving level;

[0176] o Support for renewable energy;

[0177] o Single Network Slice Selection Assistance Information (S-NSSAI) or a combination of S-NSSAI and Data Network Name (DNN) / Data Network Access Identifier (DNAI);

[0178] o Application ID. Certain applications result in more energy consumption. For example, a UE sends periodic data to an application server as part of data collection or monitoring for ML training. If the energy consumed in communicating with such an application reaches the maximum energy credit allocated to the NWDAF service consumer (e.g., AF), the AF may decide to reduce the priority of data collection or monitoring for ML training from a given UE or UE

[0179] group within a given time period;

[0180] o Traffic type of interest;

[0181] o Maximum energy credit allocated per subscriber (e.g., for a given UE subscription), per slice, per UE, per PDU

[0182] o session;

[0183] o Maximum energy credit allocated per session;

[0184] o Reporting threshold, which is only applicable to subscriptions and indicates the condition for the level to be achieved for the corresponding analysis information to be notified by the NWDAF. For example, the reporting threshold for the time spent in a specific energy state, which may help with the maximum energy that can be allocated for the analysis reporting target

[0185] Credit. For example: a certain day or month;

[0186] o Preferred accuracy level.

[0187] - Analysis target period: time interval [start... end], which can be in the past (both the start time and the end time are in the past) or in the future (both the start time and the end time are in the future). An analysis target period in the past is a request or subscription for statistical data.

[0188] Table 1 below lists the example input data collected from the OAM (Operation 2a).

[0189] Table 1

[0190]

[0191]

[0192] Based on the analysis filtering information received from the NWDAF service consumer, the NWDAF can determine the NF or slice for which energy efficiency information needs to be collected from the OAM (the NWDAF can determine to collect energy efficiency information for this NF or slice from the OAM).

[0193] Table 2 below lists the example input performance data from the AF (Operation 2c).

[0194] Table 2

[0195]

[0196] In some embodiments, as described herein and / or in 3GPP TS29.510, the NWDAF can request the NRF to obtain data related to the NF instance.

[0197] For the output analysis, in some embodiments, based on the time spent by the NAN (e.g., gNB, etc.) in different energy-saving states, the different energy-saving states and energy-saving levels of the NFs in the 5GC during the analysis target period, the energy consumption and energy efficiency data of the serving cell or NFs in the 5GC during the analysis target period, and the DN performance data for the UE or UE group from the AF, the NWDAF can provide an energy information output analysis. Table 3 lists examples of the energy information output analysis provided by the NWDAF.

[0198] Table 3

[0199]

[0200]

[0201] In this document, the parameters or functions applied to the gNB may also be applicable to other NG-RAN nodes, which are not restricted in this disclosure.

[0202] In some embodiments, the EECF may support session energy assessment requests from other NFs such as the SMF. The request may include: PDU session ID, UE's energy data profile data, policy information provided by the PCF for the PDU session (including energy policy recommendations for the PDU session). The EECF may evaluate these input parameters and provide session modification recommendations for the PDU session parameters to optimize energy usage. In some embodiments, the session modification recommendations for the PDU session parameters provided by the EECF may include, but are not limited to: adjusted quality of service parameters, UPF selection and configuration with high energy-efficient data processing. In some embodiments, the UPF configuration with high energy-efficient data processing may include: bandwidth management (enforcing the data rate limit provided by the PCF), data routing adjustment (guiding data packets through a specified high energy-efficient routing path), QoS enforcement (ensuring that the quality of service is aligned with the high energy-efficient policy, which can be achieved by reducing the priority of non-critical data under high network load conditions).

[0203] In some embodiments, in order to evaluate the input parameters and provide session modification recommendations, when determining the evaluation response provided to the SMF, the EECF may consider the historical energy consumption data of the network entity or the average energy consumption of the NFs involved in the PDU session. The EECF may use the NWDAF service to obtain the energy information analysis, NF load analysis, and NF performance analysis corresponding to the historical energy consumption or energy consumption prediction over a certain period as defined above.

[0204] As part of the 5GS enhanced energy efficiency and energy saving study (Rel-) 19 approved by 3GPP SA2, it has been agreed to study the following work tasks (WT): WT#2, study the enhancements of subscription and policy control to make network energy saving a service standard.

[0205] Below, this disclosure provides various solutions aimed at enhancing the existing subscription and policy control framework to support using energy-related information as a service standard. This includes: defining new energy-related UE subscription information and policies, determining how to perform energy-related policy control at different granularities, and determining what network energy-related information is required for subscription and policy control, etc.

[0206] The following definitions of energy policies may be related to various aspects of this disclosure.

[0207] The term "energy policy" (e.g., in the context of EECF or other contexts) refers to a set of rules and guidelines defined by network operators for managing and optimizing the energy consumption of various network functions and UEs in a 5G network. These policies are designed to ensure sustainable energy use while maintaining optimal network performance and quality of service.

[0208] In some embodiments, the composition of an energy policy may include:

[0209] o Policy identifier: A unique identifier for each energy policy;

[0210] o Energy efficiency target: A specific target for energy savings or improved energy efficiency that the policy aims to achieve;

[0211] o Applicability criteria: Define the conditions under which the policy applies, e.g., network load conditions, time of day, or specific network events;

[0212] o Action rules: Specific actions to be taken when the policy conditions are met; this may include adjusting

[0213] the operating state of the NF, modifying the routing path, or imposing energy consumption limits;

[0214] o Compliance metrics: Quantitative metrics used to evaluate policy compliance, e.g., energy consumption thresholds or efficiency levels; or

[0215] o Other parameters.

[0216] The term "energy efficiency level (EEL)" refers to a classification within an energy policy that specifies different levels of energy efficiency measures to be applied. The definition of EEL is based on the intensity of energy-saving actions and their impact on network functions and services.

[0217] In some embodiments, the EEL may include a low EEL, a medium EEL, and a high EEL. For example, the low EEL may involve minimal energy-saving actions, typically applied under normal network conditions to ensure optimal quality of service. The medium EEL may involve a balanced approach that provides moderate energy savings while maintaining service reliability. The high EEL may involve maximum energy savings, which may be used during low-demand periods or in specific situations where energy conservation is prioritized.

[0218] The term "energy consumption limit" refers to a threshold within an energy policy that specifies the maximum allowable energy consumption of a network function or UE over a specified period. The purpose of setting this limit is to control and reduce the overall energy consumption of the network.

[0219] As described above, for the policy control mechanism in the EECF, the EECF enforces the energy-related policies set by the network operator to optimize the energy consumption and efficiency of the 5G network. As a policy enforcement entity, the EECF interacts with various NFs to dynamically apply these policies based on real-time network conditions and energy consumption metrics.

[0220] In some embodiments, the policies may include one or more maximum energy usage thresholds, one or more energy-saving operating states, one or more energy credits for one or more subscribers, one or more energy-efficient routes, etc. The present disclosure is not limited in this regard. The one or more maximum energy usage thresholds may limit the energy consumption of NFs, devices, and subscribers. It can be dynamically adjusted according to network load, time of day, and specific events or triggers. The one or more energy-saving operating states may define various operating states of the NF (e.g., full power, reduced power, sleep mode). The mechanism to achieve the transitions between these states can optimize energy usage without affecting the quality of service. The one or more energy credits for one or more subscribers may refer to the energy credits allocated to subscribers, thereby allowing or restricting services based on their energy usage. The one or more energy credits for one or more subscribers may encourage energy-efficient usage patterns among subscribers. The one or more energy-efficient routes may preferentially select routes or paths with lower energy consumption in the network.

[0221] Figure 7 A flowchart showing an example of a method 700 for energy policy control according to some embodiments of the present disclosure is shown. The method 700 may be executed by the EECF (e.g., Figure 3 the EECF in Figure 2 or the EECF 270 in

[0222] However, the present disclosure is not limited in this regard. As shown, the method 700 includes operations 710 to 740. At 710, obtain the energy profile of the UE from the UDM (e.g., UDM 258, UDM 958, etc.). At 720, obtain the energy-related policy information for the UE from the PCF (e.g., PCF 256, PCF 956, etc.). At 730, evaluate the energy profile of the UE and the energy-related policy information to generate a session and policy evaluation result. At 740, encode the session and policy evaluation result for transmission to the SMF (e.g., SMF 246, SMF 946, etc.) for session establishment.

[0223] In some embodiments, the EECF may obtain the energy profile of an NF from an NRF (e.g., NRF 254, NRF 954, etc.), and evaluate the energy profile of the NF together with the energy profile of the UE and energy-related policy information to generate session and policy evaluation results. In some embodiments, an NF may be selected according to the session to be established for the UE to obtain the energy profile for that NF. In some embodiments, the energy-related policy information is associated with (e.g., specific to) the UE and the NF.

[0224] In some embodiments, the EECF may evaluate the energy profile of the UE, the energy consumption-related policy information, and optionally the energy profile of the NF based on network conditions and energy consumption metrics. In some embodiments, the network conditions may include network load, time of day, or a given network event or trigger. The present disclosure is not limited in this regard. The network load may be represented as low, medium, or high. The network load may also be represented by a specific value (e.g., 0, 1, 2, 3, etc.). The time of day may be used to apply different policies during peak and off-peak hours.

[0225] In some embodiments, the energy profile of the UE may include a maximum energy credit limit associated with the UE, e.g., a maximum energy credit limit associated with this subscription, PEI, group identifier of the UE, etc.

[0226] In some embodiments, the energy profile of the NF may include the average energy consumption of the NF, the energy state of the NF, the energy saving level of the NF, etc. The average energy consumption may be expressed in watts (e.g., 50 watts at low load and 100 watts at high load). The energy state may be represented by an enumerated value, e.g., InEnergySaving (energy saving), NotEnergySaving (not energy saving). The energy saving level may be represented by labels such as low, medium, high, etc., and each label may be mapped to a specific (one or more) energy consumption ranges.

[0227] In some embodiments, the energy-related policy information obtained from the PCF may be based on network conditions. As described above, the network conditions may include: network load, time of day, or a given network event or trigger. The present disclosure is not limited thereto.

[0228] In some embodiments, the energy-related policy information obtained from the PCF may include a set of rules or recommendations, such as data throttling, energy-efficient routing, adaptive mobility management, etc. Data throttling can be achieved by restricting the maximum data rate during peak hours to save energy (e.g., restricting video streaming to 480p during high network load). Energy-efficient routing can direct data through paths or nodes in an energy-saving state. Adaptive mobility management may be related to preferentially switching to a cell with a lower energy profile. In some embodiments, the energy-related policy information obtained from the PCF may include the energy usage thresholds of NFs, energy-saving states, energy credits of subscribers, or any other rules related to energy saving. The present disclosure is not limited in this regard.

[0229] In some embodiments, the session and policy evaluation results generated by the EECF may include high-energy-efficiency suggestions for modifying the parameters of the session. For example, the EECF can comprehensively evaluate the UE's energy profile, energy-related policy information, and the energy profiles of NFs. This includes: analyzing the UE's energy profile based on the current network conditions, evaluating the energy states of the involved NFs to ensure they meet the required energy efficiency targets, and carefully checking the policy information received from the PCF to confirm its compliance and its potential for optimizing energy usage.

[0230] In some embodiments, the EECF can obtain the UE's energy profile from the UDM in response to a registration notification from the AMF (e.g., AMF 244, AMF 944, AMF 1244, etc.). In some embodiments, the EECF can obtain the UE's energy profile from the UDM in response to another notification. The present disclosure is not limited in this regard.

[0231] Figure 8 An example process of EECF-based energy policy control according to some embodiments of the present disclosure is shown. The process may include the following operations. However, the order of the operations is not limited to Figure 8 the order illustrated or described in

[0232] 1. UE registers to the 5G network: The UE successfully registers to the 5G network. The AMF processes the registration process.

[0233] 2. The AMF notifies the EECF of the UE registration (AMF-EECF notification): After the registration is successful, the AMF sends a notification to the EECF. The notification includes the UE's 5G-GUTI and indicates that the UE's energy profile needs to be obtained.

[0234] 3. The EECF requests the UE's energy profile (EPR-UDM) from the UDM: After receiving the notification from the AMF, the EECF sends an energy profile request message to the UDM to obtain the energy profile of a given UE. This is done through the "Nudm_EnergyProfile" service operation. The request includes the UE's 5G-GUTI and seeks the UE's energy profile and policies.

[0235] 4. The UDM responds with the energy profile (EPRs-UDM): The UDM processes the request and sends the UE's energy profile.

[0236] 5. The EECF requests the NF's energy profile (EPR-NRF) from the NRF: The EECF sends an energy profile request message to the NRF to obtain the energy profiles of network functions. This is done by using the "Nnrf_EnergyProfile" service operation. The NRF responds with the NF's energy profile (EPRs-NRF): The NRF collects energy-related data for each requested NF and sends this data back to the EECF, providing a summary view of the energy status of the entire network functions.

[0237] 6. The EECF requests policy information (PIR-PCF) from the PCF: The EECF uses the "Npcf_PolicyAuthorizationRequest" service operation to request energy-related policy information from the PCF.

[0238] 7. The EECF requests policy information (PIR-PCF) from the PCF: After receiving the energy profiles of the UE and the relevant NFs, the EECF now needs the latest policy information to make an informed decision. It requests the PCF to provide the policy rules applicable to the current session. This includes energy-related policy information specific to the UE and the selected network functions participating in the session establishment. The PCF provides policy details (PIR-PCF) to the EECF: The PCF provides the relevant policy information, including energy usage thresholds, energy-saving operating status, etc. This policy data is sent to the EECF for further processing.

[0239] 8. Evaluate the session and policies (SPE-EECF) during the PDU session establishment: As part of the PDU session establishment process, the EECF comprehensively evaluates the proposed session settings and the relevant energy efficiency policies. This includes: analyzing the UE's energy profile based on the current network conditions, evaluating the energy status of the relevant network functions to ensure they meet the required energy efficiency goals, and carefully examining the policy information received from the PCF to confirm its compliance and its potential for optimizing energy usage.

[0240] 9. The EECF can recommend modifications or provide approvals based on this assessment. The EECF sends the assessment results to the SMF: The EECF uses the "Nsmf_SessionEnergyEvaluationResult" service operation to send the results of the session and policy evaluation to the SMF.

[0241] 10. The SMF continues the session setup: The SMF incorporates the EECF's recommendations into the session setup. Ensure that the session complies with the specified energy policy and operates within the specified energy parameter range.

[0242] 11. The SMF notifies the CHF about the charging of the session (SI-CHF): After the session setup, the SMF sends the session details to the CHF. This includes information related to charging, such as the session duration, data usage, and any energy-efficient measures adopted.

[0243] 12. The CHF acknowledges the session information (Ack-CHF): The CHF processes the received information. Sends a receipt to the SMF.

[0244] Figure 7 The operations and embodiments described above can be implemented by Figure 8 one or more of the operations described, but the present disclosure is not limited in this regard. For example, the energy profile of the UE can be obtained through Figure 8 operations 3 and 4. The energy profile of the NF can be obtained through Figure 8 operation 5. The energy-related policy information can be obtained through Figure 8 operations 6 and 7 in. The evaluation of the energy profile of the UE, the energy profile of the NF, and the energy-related policy information can be achieved through Figure 8 operation 8. The transmission of the session and policy evaluation results can be achieved through Figure 8 operation 9.

[0245] In addition, in some embodiments, the operations described above can be selected as needed Figure 8 to achieve corresponding energy savings. That is, not all of operations 1-12 are necessary. The present disclosure is not limited in this regard.

[0246] In some embodiments, the EECF can receive a "Npcf_PolicyAuthorizationResponse" in response to a "Npcf_PolicyAuthorizationRequest" from the PCF. The Npcf_PolicyAuthorizationResponse service operation here can inherit from the existing Npcf_PolicyAuthorizationResponse service operation, but the following content needs to be added.

[0247] Description: The PCF uses this service operation to provide energy policy details to the EECF. It responds to the EECF's request for energy-related policy information, which is required by the EECF when making energy efficiency decisions.

[0248] Required Input: Existing inputs described in 3GPP TS29.512 V18.4.0 (2023-12)

[0249] + Session information (including PDU session ID, UE ID), energy efficiency requirements (if any)

[0250] Optional Input: Specific network conditions (e.g., network load, time of day), energy saving status or level of the requested NF

[0251] Required Output: Energy policy details, including energy usage thresholds, energy saving status, and

[0252] Energy efficiency operation guidelines

[0253] Optional Output: None.

[0254] In some embodiments, as described above, the EECF may use the "Nsmf_SessionEnergyEvaluationResult" service operation to send its session and policy evaluation results to the SMF. The "Nsmf_SessionEnergyEvaluationResult" service operation will be described in detail below.

[0255] Description: The EECF uses this service operation to send its session and policy evaluation results to the SMF. It includes the EECF's evaluation of the energy efficiency aspects of the session settings based on the energy profiles of the UE and the NF, and the energy policy provided by the PCF.

[0256] Required Input: Session ID, energy profile of the UE, energy profile of the NF, energy policy from the PCF

[0257] Optional Input: Suggestions for modifying for high energy efficiency sessions (if applicable)

[0258] Required Output: Evaluation results indicating whether the session settings meet the energy efficiency goals. Any suggestions or necessary adjustments to the session for energy optimization.

[0259] Optional Output: Detailed reasons for any suggested modifications or decisions.

[0260] Embodiments of energy policy control based on the EECF are described above. Embodiments of energy policy control without using the EECF will be described below. Figure 9A flowchart illustrating an example of a method 900 for energy policy control according to some embodiments of the present disclosure is shown. The method 900 may be executed by an SMF (e.g., SMF 246, SMF 946, etc.). However, the present disclosure is not limited in this regard. As shown, the method 900 includes operations 910 to 940.

[0261] At 910, obtain an energy profile of the UE from an AMF (e.g., AMF 244, AMF 944, AMF 1244, etc.). At 920, obtain energy-related policy information for the UE from a PCF (e.g., PCF 256, PCF 956, etc.). At 930, generate session and routing configuration information based on the UE's energy profile and the energy-related policy information. At 940, cause the session and routing configuration information to be transmitted to a UPF (e.g., UPF 248, UPF 948, etc.) to establish a session.

[0262] In some embodiments, the SMF may obtain an energy profile of an NF from an NRF (e.g., NRF 254, NRF 954, etc.) or an AMF, and generate session and routing configuration information based on the UE's energy profile, the NF's energy profile, and the energy-related policy information. In some embodiments, an NF may be selected based on the session to be established for the UE to obtain an energy profile for that NF. In some embodiments, the energy-related policy information is associated with (e.g., specific to) the UE and the NF.

[0263] In some embodiments, the SMF may generate session and routing configuration information based on network conditions and energy consumption metrics. In some embodiments, the network conditions may include network load, time of day, or a given network event or trigger. The present disclosure is not limited in this regard. The network load may be represented as low, medium, or high. The network load may also be represented by a specific value (e.g., 0, 1, 2, 3, etc.). The time of day may be used to apply different policies during peak and off-peak hours.

[0264] In some embodiments, the session and routing configuration information includes: bandwidth management information, routing adjustment information, quality of service (QoS) enforcement information, etc.

[0265] In some embodiments, the UE's energy profile may include a maximum energy credit limit associated with the UE, e.g., a maximum energy credit limit associated with this subscription, PEI, group identifier of the UE, etc.

[0266] In some embodiments, the energy profile of an NF may include the average energy consumption of the NF, the energy state of the NF, the energy saving level of the NF, etc. The average energy consumption may be expressed in watts (e.g., 50 watts at low load and 100 watts at high load). The energy state may be represented by an enumerated value, such as InEnergySaving (energy saving), NotEnergySaving (not energy saving). The energy saving level may be represented by labels such as low, medium, high, etc., and each label may be mapped to a specific (one or more) energy consumption ranges.

[0267] In some embodiments, the energy-related policy information obtained from the PCF may be based on network conditions. As described above, the network conditions may include: network load, time of day, or a given network event or trigger. The present disclosure is not limited thereto.

[0268] In some embodiments, the energy-related policy information obtained from the PCF may include a set of rules or recommendations, such as data throttling, energy-saving routing, adaptive mobility management, etc. Data throttling may be achieved by restricting the maximum data rate during peak hours to save energy (e.g., limiting video streaming to 480p during high network load). Energy-saving routing may direct data through paths or nodes in an energy-saving state. Adaptive mobility management may be related to preferentially switching to a cell with a lower energy profile. In some embodiments, the energy-related policy information obtained from the PCF may include the energy usage threshold of the NF, the energy-saving state, the energy credit of the subscriber, or any other rules related to energy saving. The present disclosure is not limited in this regard.

[0269] In some embodiments, as part of the UE registration process, the SMF may obtain the energy profile of the UE from the AMF. In some embodiments, the SMF may obtain the energy profile of the UE in other ways. The present disclosure is not limited in this regard.

[0270] Figure 10 An example process of energy policy control without an EECF according to some embodiments of the present disclosure is shown. For example, this example process may be implemented with a traditional or legacy (e.g., existing) 5GC NF that does not have an EECF. The process may include the following operations. However, the order of operations is not limited to Figure 10 that shown or described.

[0271] 1. UE Registration and Energy Profile Handling: UE registers with the network (AMF): As part of the UE registration process described in clause 4.2.2.2.2 of 3GPP TS23.502 V18.4.0 (2023-12) ([TS23502]), the UE provides its credentials and capabilities to the AMF. As part of the registration process, the AMF now also requests the UE's initial energy profile information. After registration, the AMF uses Nudm_UEContextTransfer (modified to include an indication of the energy profile request) to send a request to the UDM to obtain the UE's energy profile.

[0272] 2. UDM Responds with UE's Energy Profile: The UDM obtains the UE's energy profile and sends it back to the AMF.

[0273] 3. Session Establishment Considering Energy Efficiency: UE requests to establish a session (sent to the SMF via the AMF): This follows the standard session establishment process in 3GPP TS23.501 V18.4.0 (2023-12) ([TS23501]). The AMF includes the UE's energy profile in the session establishment request sent to the SMF.

[0274] 4. SMF Requests Policy Rules from PCF (Including Energy Efficiency Policy): The SMF contacts the PCF to obtain the policy rules for the session. This request now also seeks energy-specific policy rules.

[0275] 5. PCF Provides Policy Rules to SMF (Including Energy Efficiency Rules): The PCF processes the request and sends the policy rules back to the SMF. Now, the PCF's response includes the energy efficiency policy.

[0276] 6. UPF Handling for High-Energy-Efficient Data Routing: The SMF configures the UPF for the session: According to TS 23.502, the SMF sends session and routing information to the UPF. It also includes instructions for high-energy-efficient data processing.

[0277] For Figure 9 the operations and embodiments described above can be implemented by Figure 10 one or more of the operations described above, but the present disclosure is not limited in this regard. For example, the UE's energy profile can be obtained through Figure 10 operation 3. Energy-related policy information can be obtained through Figure 10 operations 4 and 5. The generation and transmission of session and routing configuration information can be implemented through Figure 10 operation 6.

[0278] In addition, in some embodiments, it can be selected as needed Figure 10The operations described above are performed to achieve corresponding energy savings. That is to say, not all of the operations 1-6 are necessary. The present disclosure does not impose any restrictions in this regard.

[0279] Figure 11 FIG. shows an example process of energy policy control without EECF according to some embodiments of the present disclosure. For example, this example process can be implemented by a traditional or legacy (e.g., existing) 5GC NF that does not have EECF. The process may include the following operations. However, the order of operations is not limited to Figure 11 the order shown or described.

[0280] 1. Obtain the energy profile of the network function from the NRF: The AMF / SMF requests the energy profile of the NF from the NRF. The AMF or SMF requests the energy profile of the relevant NF from the NRF to optimize network operations.

[0281] 2. The NRF responds with the energy profile of the NF: The NRF provides the requested energy profile of the NF. Now, the response from the NRF includes the energy profile of the NF.

[0282] Figure 9 The operations and embodiments described above can be implemented by Figure 11 one or more of the operations described above, and the present disclosure does not impose any restrictions in this regard. For example, the energy profile of the NF can be obtained through Figure 11 operations 1 and 2.

[0283] In addition, in some embodiments, the operations described above can be selected as needed Figure 11 to achieve corresponding energy savings. That is to say, not all of the operations 1-2 are necessary. The present disclosure does not impose any restrictions in this regard.

[0284] In some embodiments, the SMF may perform session policy control based on "Nsmf_PDUSessionEstablishmentRequest". For an energy policy control mechanism without EECF, for example, the SMF may send "Nsmf_PDUSessionEstablishmentRequest" to the UPF; in another example, the AMF may send "Nsmf_PDUSessionEstablishmentRequest" to the SMF. For an energy policy control mechanism based on EECF, for example, the EECF may send "Nsmf_PDUSessionEstablishmentRequest" to the SMF; and in another example, the SMF may send "Nsmf_PDUSessionEstablishmentRequest" to the UPF ( Figure 8 not shown).

[0285] In some embodiments, the parameters in "Nsmf_PDUSessionEstablishmentRequest" may include one or more energy efficiency directives or one or more session characteristics. In some embodiments, one or more energy efficiency directives may include one or more data rate limits or one or more preferred routing paths. One or more data rate limits may include specific bandwidth limits based on PCF-based policies (e.g., a downlink upper limit of 5 Mbps). One or more preferred routing paths may indicate high-efficiency paths for data routing (e.g., Path_ID_123 represents a high-efficiency route). In some embodiments, one or more session characteristics may include: PDU session ID, one or more QoS requirements, or UPF configuration. The PDU session ID is the unique identifier of the session. One or more QoS requirements may be adjusted QoS parameters reflecting high-efficiency settings. For UPF configuration, the SMF may configure the UPF with instructions to ensure high-efficiency data processing (e.g., bandwidth management, routing adjustment, or QoS enforcement). Bandwidth management can be used to implement the data rate limits provided by the PCF. Routing adjustment can be used to direct packets through the specified high-efficiency routing path. QoS enforcement can be used to ensure that QoS is aligned with high-efficiency policies, which can be achieved by reducing the priority of non-critical data under high load conditions.

[0286] With the above technical solutions, network energy can be optimized through policy control. Among them, some technical solutions achieve energy optimization in the following ways: defining energy-related policies based on a set of parameters (including network load conditions, time of day, or specific network events), and dynamically applying these policies based on real-time network conditions and energy consumption metrics. Additionally or alternatively, some technical solutions can also achieve energy optimization in the following ways: as part of the registration process, requesting the energy profile of the UE; establishing a session considering energy efficiency factors; requesting policy rules from the PCF, including energy efficiency policies; and configuring the UPF for the session, including instructions for high-efficiency data processing. Additionally or alternatively, some technical solutions can also achieve energy optimization in the following ways: analyzing the energy profile of the UE under current network conditions, evaluating the energy state of network functions and their consistency with the required high-efficiency goals, and reviewing the received policy information to ensure compliance and optimized energy use.

[0287] Figure 12FIG. 1200 is a flowchart illustrating an example of a method 1200 for energy saving support according to some embodiments of the present disclosure. The method 1200 may be performed by a service consumer, which may be, for example, an SMF (e.g., SMF 246, SMF 946, etc.). However, the present disclosure is not limited in this regard. As shown, the method 1200 includes operations 1210 to 1230.

[0288] At 1210, encode a session energy assessment request for transmission to a service producer. In some embodiments, the session energy assessment request may include a session ID of the session and energy policy information for the session.

[0289] At 1220, decode a session energy assessment response received from the service producer in response to the session energy assessment request. In some embodiments, the session energy assessment response may include session modification suggestions for parameters of the session to optimize energy usage.

[0290] At 1230, perform establishment of the session based on the session modification suggestions.

[0291] In some embodiments, the service producer in the method 1200 may be an EECF (e.g., Figure 3 the EECF in Figure 2 or the EECF 270 in

[0292] Figure 13 FIG. 1300 is a flowchart illustrating an example of a method 1300 for energy saving support according to some embodiments of the present disclosure. The method 1300 may be performed by a service producer, which may be, for example, an EECF (e.g., Figure 3 the EECF in Figure 2 or the EECF 270 in

[0293] At 1310, decode a session energy assessment request received from the service consumer. In some embodiments, the session energy assessment request may include a session ID of the session and energy policy information for the session.

[0294] At 1320, in response to the session energy assessment request, encode a session energy assessment response for transmission to the service consumer for session establishment. In some embodiments, the session energy assessment response may include session modification suggestions for parameters of the session to optimize energy usage.

[0295] In some embodiments, the service consumer in method 1300 can be an SMF (e.g., SMF 246, SMF 946, etc.). However, the present disclosure is not limited in this regard.

[0296] From the above description, methods 1200 and 1300 respectively describe technical solutions for energy-saving support from the perspectives of a service consumer (e.g., an SMF) and a service producer (e.g., an EECF). Below, for ease of description, embodiments will be described using an SMF as an example service consumer and an EECF as an example service producer. However, the present disclosure is not limited in this regard.

[0297] In some embodiments, the session energy assessment request may further include an energy profile of a UE or a UE group associated with the session, and the parameters of the session are associated with the UE or the UE group. In some embodiments, the energy profile of the UE or the UE group may include a PEI, a maximum energy credit limit, or a group identifier.

[0298] For example, the energy profile (or energy profile subscription data type) of the UE or the UE group may include the following fields.

[0299]

[0300] In some embodiments, the SMF may request session management subscription data from a UDM (e.g., UDM 258, UDM 958, etc.), and the response from the UDM (or session management subscription data) may include an energy-saving indication required for a PDU session. In response to the energy-saving indication, the SMF may obtain the energy profile of the UE or the UE group from the UDM. In some embodiments, the SMF may encode a Nudm_SDM_Get request for transmission to the UDM and decode the Nudm_SDM_Get response received from the UDM in response to the Nudm_SDM_Get request to obtain the energy profile of the UE or the UE group. In some embodiments, the Nudm_SDM_Get service may also be used to obtain session management subscription data.

[0301] For example, the session management subscription data type (e.g., the session management subscription data described in clause 5.2.3 of TS23.502) may be enhanced as described below.

[0302]

[0303]

[0304]

[0305] As described above, among other things, the session management subscription data type may include an energy saving indication, and when this energy saving indication exists, it is used to indicate that the SMF needs to establish a PDU session considering the energy data profile of the UE and the energy profiles of the (one or more) NFs participating in the establishment of the PDU session according to the S-NSSAI and DNN.

[0306] In some embodiments, the UDM stores the energy profile of the UE as session management subscription data.

[0307] In some embodiments, the session modification suggestion may include: adjusted QoS parameters, or information regarding the selection and configuration of the UPF with high energy-efficient data processing. In some embodiments, the information regarding the selection and configuration of the UPF with high energy-efficient data processing may include: bandwidth management information, data routing adjustment information, or QoS execution information.

[0308] In some embodiments, the session modification suggestion for the parameters of the session may be based on: the historical energy consumption data of the NF associated with the session, the average energy consumption of the NF, or the predicted energy consumption of the NF. In some embodiments, the EECF may evaluate the energy policy information of the session based on the historical energy consumption data of the NF, the average energy consumption of the NF, or the predicted energy consumption of the NF to generate a session modification suggestion for the parameters of the session. In some embodiments, the EECF may obtain an energy information analysis corresponding to the historical energy consumption data of the NF, the average energy consumption of the NF, or the predicted energy consumption of the NF through the NWDAF service as described above.

[0309] In some embodiments, the session energy assessment request may further include the energy profile of the NF associated with the session, and the parameters of the session are associated with the NF. In some embodiments, the SMF may obtain the energy profile of the NF from the NRF (e.g., NRF 254, NRF 954, etc.). In some embodiments, if the NF supports energy saving, the NF profile of the corresponding NF in the NRF includes an energy saving support indication or an energy saving level (e.g., in the NF profile list). In this way, NFs with energy saving functions enabled in the network can be selected. For example, it is allowed that the NF selects another NF instance during the PDU session establishment process to select an NF with energy saving functions enabled in the network.

[0310] In some embodiments, the SMF may encode a policy control request for transmission to the PCF (e.g., PCF 256, PCF956, etc.), and decode the policy control response received from the PCF in response to the policy control request to obtain energy policy information. In some embodiments, the policy control request may include an energy saving indication. Additionally or alternatively, in some embodiments, the policy control request may include the energy profile of the UE or UE group or the energy profile of the NF.

[0311] In some embodiments, the energy policy information may include the maximum allowable energy credit of the UE or UE group, the energy usage threshold of the NF, the energy saving state, the energy saving level of the UE or UE group, the energy saving level of the NF, high energy efficiency routing, limiting the maximum data rate, adaptive mobility management information, etc.

[0312] In some embodiments, the SMF may select an EECF based on the S-NSSAI. For EECF discovery and selection, multiple EECF instances may be deployed in the network. The NF consumer (e.g., the SMF) may utilize the NRF to discover one or more EECF instances. Alternatively, the EECF information may also be obtained in other ways, such as local configuration on the NF consumer. The EECF selection function in the NF consumer may select an EECF instance based on the available EECF instances. The NF consumer may consider the S-NSSAI when selecting an EECF. However, the NF consumer may also consider some other factors for EECF selection, which are not limited in this disclosure.

[0313] In some embodiments, the SMF may provide session modification suggestions to the UPF (e.g., UPF 248, UPF 948, etc.) to establish a session.

[0314] In some embodiments, the session herein may include a PDU session, and the session ID may include the PDU session ID. However, this disclosure is not limited in this regard.

[0315] Figure 14 An example of EECF communication with the UDM, NFR, and SMF according to some embodiments of the present disclosure is shown.

[0316] As Figure 14 shown in process C, the SMF may send a session energy assessment request to the EECF, and the EECF may send a session energy assessment response to the SMF as a response. For example, during the PDU session establishment process, the SMF may send a session energy assessment request to the EECF. The request includes the PDU session ID, the energy data profile data of the UE, and the policy information provided by the PCF for the PDU session (including the energy policy recommendation for the PDU session). The EECF evaluates the input parameters and provides session modification suggestions for the PDU session parameters to optimize energy usage, such as adjusted QoS parameters, UPF selection and configuration with high energy efficiency data processing. When determining the evaluation response provided to the SMF, the EECF may consider the historical energy consumption data of the network entity or the average energy consumption of the NFs involved in the PDU session. The EECF may use the NWDAF service to obtain the analysis related to the historical energy consumption or the prediction of the energy consumption over a certain period. Process C may be understood in combination with the above embodiments and will not be elaborated here.

[0317] As shown Figure 14 In process A as shown below, the EECF may send an energy profile request for a UE or UE group to the UDM, and in response, the UDM may send an energy profile response for the UE or UE group to the EECF. Through process A, the EECF may obtain the energy profile of the UE or UE group from the UDM. In some embodiments, the energy profile request for the UE or UE group may include SUPI, PEI, subscription data type, group identifier, etc. In some embodiments, the EECF may evaluate the energy policy information of the session received from the SMF at least partially based on the energy profile of the UE or UE group received from the UDM to generate session modification suggestions for the parameters of the session.

[0318] In some embodiments, the Nudm_EnergyProfile service may be used to implement process A. For example, the Nudm_EnergyProfile service may be as follows:

[0319] Service operation name: Nudm_EnergyProfile service operation

[0320] Description: The consumer NF (EECF) requests the energy profile of a given UE from the UDM.

[0321] Required inputs: PEI, group identifier, subscription data type (energy profile), session management subscription data type

[0322] Optional inputs:

[0323] Required output: The consumer NF obtains the requested energy profile subscription data.

[0324] Optional output: None.

[0325] In some embodiments, Nudm_SubscriberDataManagement (SDM) allows the consumer NF (EECF) to request the energy profile of a given UE or UE group from the UDM. The request may include one or more of PEI, group identifier subscription data type, session management subscription data type as required inputs, and the UDM provides the energy profile subscription data as output.

[0326] As shown Figure 14 ​As shown in Process B, the EECF may send an energy profile request for an NF to the NRF, and the NRF may send an energy profile response for the NF to the EECF as a response. Through Process B, the EECF may obtain the energy profile of the NF from the NRF. In some embodiments, the energy profile request for the NF may include an NF identifier, an NF type, an NF instance ID, etc. Additionally or alternatively, in some embodiments, the energy profile request for the NF may further include a preferred energy-saving state or a preferred energy-saving level. In some embodiments, the EECF may evaluate the energy policy information of the session received from the SMF at least partially based on the energy profile of the NF received from the NRF to generate a session modification recommendation for the parameters of the session.

[0327] In some embodiments, the Nnrf_EnergyProfile service may be utilized to implement Process B. For example, the Nnrf_EnergyProfile service may be as follows:

[0328] Service operation name: Nnrf_EnergyProfile service operation

[0329] Description: The consumer NF (EECF) requests the energy profile of a given NF from the NRF.

[0330] Required inputs: NF type, NF instance ID

[0331] Optional inputs: Preferred energy-saving state, preferred energy-saving level.

[0332] Required output: The consumer NF (EECF) obtains the requested energy profile data for the requested NF.

[0333] Optional output: None.

[0334] In some embodiments, Process A, B, or C may run independently or separately. In some embodiments, Process A, B, or C may run dependently. The present disclosure is not limited in this regard.

[0335] Figure 15 Shows an example of a PDU session establishment process with energy-saving policy control per PDU session according to some embodiments of the present disclosure. The PDU session establishment process defined in clause 4.3.2.2 of TS23.502 may be used as a baseline to describe the enhancements required for the energy-saving policy control process per PDU session.

[0336] As Figure 15As shown, operations (or steps) 1 to 3, 5, 6, 7a, 8, 9, 10b, and 11 - 21 are substantially consistent with Article 4.3.2.2.1 of TS 23.502. Operations (or steps) 4, 7b, 7c, 7d, 7e, and 10a will be introduced in detail below.

[0337] In operation 4, if the session management subscription data for the corresponding SUPI, DNN, and S-NSSAI of the HPLMN is not available, the SMF uses Nudm_SDM_Get (SUPI, session management subscription data, selected DNN, S-NSSAI of the HPLMN, serving PLMN ID, [NID]) to obtain the session management subscription data, and uses Nudm_SDM_Subscribe (SUPI, session management subscription data, selected DNN, S-NSSAI of the HPLMN, serving PLMN ID, [NID]) to subscribe to receive notifications when the subscription data is modified. The UDM can obtain this information from the UDR through Nudr_DM_Query (SUPI, subscription data, session management subscription data, selected DNN, S-NSSAI of the HPLMN, serving PLMN ID, [NID]), and can subscribe to notifications from the UDR regarding the same data through Nudr_DM_subscribe. If the S-NSSAI is subject to network slice usage control and the S-NSSAI is dedicated to a single AF, for PDU sessions of non-roaming users, the UDM can provide slice usage policy information, including whether the network slice is used on demand and the PDU session inactivity timer value (as described in Article 5.15.15 of TS 23.501).

[0338] The SMF can use the DNN selection mode when deciding whether to obtain the session management subscription data. For example, if (selected DNN, S-NSSAI of the HPLMN) is not explicitly subscribed, the SMF can use the local configuration instead of the session management subscription data.

[0339] If the request type in step 3 indicates "existing PDU session" or "existing emergency PDU session", the SMF determines that the request is due to a handover between 3GPP access and non-3GPP access or due to a handover from EPS. The SMF identifies the existing PDU session based on the PDU session ID. In this case, the SMF does not create a new SM context but updates the existing SM context and provides a representation of the updated SM context to the AMF in the response.

[0340] If the request type is "initial request" and if the old PDU session ID is included in the Nsmf_PDUSession_CreateSMContext request, the SMF identifies the existing PDU session to be released based on the old PDU session ID.

[0341] Subscription data includes: allowed (one or more) PDU session types, allowed (one or more) SSC modes, default 5QI and ARP, subscribed session-AMBR, SMF-related external parameters. If the subscription data includes the energy saving indication required for the PDU session (as described above), the SMF uses the Nudm_SDM_Get service to request the energy data profile subscription data from the UDM. The energy data profile subscription data from the UDM includes the PEI, the maximum energy credit limit associated with the subscription, and the internal group identifier (if the UE belongs to a group in which all UEs have the same energy data profile). In some embodiments, the energy data profile subscription data type is included in the UE subscription data type.

[0342] If the UE subscribes to an IP index or a static IP address / prefix, it can be included in the subscription data.

[0343] The SMF checks the validity of the UE request. It checks:

[0344] - Whether the UE request complies with the user subscription and local policies;

[0345] -(If the selected DNN corresponds to the LADN), based on the indication of "UE present in the LADN service area" from the AMF, whether the UE is within the LADN service area. If the AMF does not provide the indication of "UE present in the LADN service area" and the SMF determines that the selected DNN corresponds to the LADN, the SMF considers the UE to be outside the LADN service area.

[0346] The SMF determines whether the PDU session requires redundancy and determines the RSN as described in clause 5.33.2.1 of TS23.501. If the SMF determines that redundancy processing is not allowed or not possible for a given PDU session, the SMF either rejects the establishment of the PDU session or accepts the establishment of the PDU session without redundancy processing according to the local policy.

[0347] If the UE request is considered invalid, the SMF decides not to accept the establishment of the PDU session.

[0348] The SMF can use the Nudm_SDM_Subscribe service operation (where the immediate report indication triggers the UDM to immediately return the subscribed data if both the SMF and the UDM support the corresponding feature), instead of using the Nudm_SDM_Get service operation.

[0349] For disaster roaming services, the UDM provides the session management subscription data to the SMF according to the local policies and / or local configurations specified in clause 5.40.4 of TS23.501.

[0350] For an S-NSSAI subject to NSAC, if LBO is applicable, the SMF in the VPLMN is supported to store the applicable NSAC admission mode.

[0351] In operation 7b, the SMF may execute the SM policy association establishment procedure defined in clause 4.16.4 to establish an SM policy association with the PCF and obtain the default PCC rules for the PDU session. The SMF may include the 3GPP data off state, if received in step 1. In the case of an ON-SNPN, the GPSI, (one or more) PVS FQDNs and / or PVS IP addresses, and the Onboarding indication may be included, if available at the SMF. The SMF may include the S-NSSAI and the alternative S-NSSAI, if received in step 3. The SMF may include the energy saving indication required for the PDU session and the energy data profile data of the UE, if received in step 4. If the request type in step 3 indicates "existing PDU session", the SMF provides information on the (one or more) policy control request trigger conditions that have been satisfied by the SM policy association modification procedure initiated by the SMF (as defined in clause 4.16.5.1). The PCF may provide the policy information defined in clause 5.2.5.4 (and 3GPP TS 23.503 V18.4.0 (2023-12)). The policy information may include energy policy recommendations for the PDU session, such as the maximum allowed energy credit for a given UE for this PDU session, the maximum energy consumption allowed for all network entities participating in the establishment of the PDU session, the energy saving level allowed for the NF selected for the PDU session, adaptive mobility management (preferred handover to a cell with lower energy consumption), and limiting the maximum data rate during peak hours to save energy. If the SMF receives a URSP rule execution from the UE (e.g., as described in clause 6.6.2.4 of TS 23.503), the PCF may provide the URSP rule execution in step 1.

[0352] The PCF for the UE subscribes to the notification of the event "UE reports connection capabilities from associated URSP rules" defined in clause 6.1.3.18 of TS 23.503 from the PCF for the PDU session using Npcf_PolicyAuthorization_Subscribe (EventId set to "UE reports connection capabilities from associated URSP rules", EventFilter set to at least "connection capabilities list"). The PCF for the session may notify the PCF for the UE of the URSP rule execution together with the PDU session parameters associated with this application via Npcf_PolicyAuthorization_Notify.

[0353] During the establishment of the SM policy association, if the PCF detects, based on local configuration, that the request is related to the SM policy association and can thus be integrated with TSN or TSC or deterministic networking (as defined in clause 5.28 of TS 23.501), the PCF may trigger a policy control request for 5GS bridge / router information (as defined in clause 6.1.3.5 of TS 23.503).

[0354] The PCF sets the ARP of the PCC rule to the value reserved for emergency services as described in TS 23.503 according to the emergency DNN.

[0355] The purpose of step 7 is to receive the PCC rule before selecting the UPF. If the PCC rule is not required as an input for UPF selection, step 7 may be executed after step 8.

[0356] During the establishment of the SM policy association for a non-roaming PDU session, if the S-NSSAI is subject to network slice usage control, the PCF may provide slice usage policy information, including whether the network slice is used on demand and the PDU session inactivity timer value, as described in clause 5.15.15 of TS 23.501.

[0357] In operation 7c, for example when the SMF receives an energy policy recommendation for a PDU session, the SMF selects the EECF.

[0358] In operation 7d, the SMF sends a session energy assessment request to the EECF. The request includes the PDU session ID, the UE's energy data profile data, and the policy information provided by the PCF for the PDU session (which includes the energy policy recommendation for the PDU session).

[0359] In operation 7e, the EECF evaluates the input parameters provided in step 7d and provides session modification recommendations for the PDU session parameters to optimize energy usage, such as adjusted quality of service parameters, selection and configuration of a UPF with high energy-efficient data processing. The UPF configuration with high energy-efficient data processing may include: bandwidth management (implementing the data rate limit provided by the PCF), data routing adjustment (guiding packets through a specified high-energy-efficient routing path), QoS enforcement (ensuring that the quality of service is aligned with the high-energy-efficient policy, which can be achieved by reducing the priority of non-critical data under high network load conditions). When determining the evaluation response provided to the SMF, the EECF may consider the historical energy consumption data of network entities or the average energy consumption of the NFs participating in the PDU session. The EECF may use the NWDAF service to obtain the analysis corresponding to the historical energy consumption or the prediction of energy consumption over a certain period.

[0360] In operation 10, if the request type indicates an "initial request", the SMF initiates an N4 session establishment procedure with the selected UPF(s); otherwise, the SMF initiates an N4 session modification procedure with the selected UPF(s):

[0361] In operation 10a, the SMF sends an N4 session establishment / modification request to the UPF and provides packet detection, enforcement, and reporting rules to be installed on the UPF for this PDU session. This may include the modification suggestions for optimizing energy usage for the PDU session parameters provided in step 7e. If the SMF is configured to request IP address allocation from the UPF as described in clause 5.8.2 of TS 23.501, the SMF indicates to the UPF to perform IP address / prefix allocation and includes the information required for the UPF to perform the allocation. If selective user plane deactivation is required for this PDU session, the SMF determines the inactivity timer and provides it to the UPF. For a PDU session of a non-roaming subscriber, if the S-NSSAI of the PDU session is subject to network slice usage control, the SMF obtains the PDU session inactivity timer value for the PDU session or uses a pre-configured value as described in step 4 or step 7, and configures the UPF to run the PDU session inactivity timer. If the SMF has received a tracing requirement, the SMF will provide the tracing requirement to the UPF. If the SMF has enabled reliable data service for the PDU session as specified in TS 23.501, the RDS configuration information is provided to the UPF in this step. If necessary, the SMF provides the small data rate control parameters to the UPF for the PDU session. If the small data rate control status is received from the AMF, the SMF will provide the small data rate control status to the UPF. If the serving PLMN intends to perform serving PLMN rate control for this PDU session (see clause 5.31.14.2 of TS 23.501), the SMF may provide the serving PLMN rate control parameters to the UPF to limit the rate of downlink control plane packets.

[0362] For an Ethernet or IP type PDU session, the SMF (e.g., for a specific requested DNN / S-NSSAI applicable to time-sensitive networking, time-sensitive communication, time synchronization, and / or deterministic networking) may include an indication to request the UPF to provide a port number.

[0363] If the SMF decides to perform redundant transmission for one or more QoS flows of a PDU session (as described in clause 5.33.1.2 of TS 23.501), the SMF requests two CN tunnel information from the UPF. The SMF also instructs the UPF to eliminate duplicate packets of the QoS flow in the uplink direction. The SMF indicates to the UPF that one CN tunnel information is used as the redundant tunnel for the PDU session, as described in clause 5.33.2.2 of TS 23.501.

[0364] If the SMF decides to insert two I-UPFs between the PSA UPF and the NG-RAN for redundant transmission (as described in clause 5.33.1.2 of TS 23.501), the SMF requests the corresponding CN tunnel information and provides it to the I-UPF and the PSA UPF respectively. The SMF also instructs the PSA UPF to eliminate duplicate packets for the QoS flow in the uplink direction. The SMF indicates to the PSA UPF that one CN tunnel information is used as the redundant tunnel for the PDU session, as described in clause 5.33.2.2 of TS 23.501.

[0365] The method of performing elimination and reordering on the RAN / UPF based on the packets received from the two GTP-U tunnels depends on the implementation of the RAN / UPF. The two GTP-U tunnels terminate at the same RAN node and UPF.

[0366] If the control plane CIoT 5GS optimization is enabled for the PDU session and the SMF selects the NEF as the anchor for this PDU session in step 8, the SMF performs the SMF-NEF connection establishment procedure described in clause 4.25.2.

[0367] If interworking with the TSN deployed in the transport network is supported (see clause 4.4.8 of TS 23.501) and the UPF supports CN-TL, the SMF includes a TL container with a fetch request in the N4 session establishment / modification request to be sent to the UPF, as described in clause 5.28a.2 of TS 23.501.

[0368] If the SMF decides to enable ECN marking for L4S by the PSA UPF, the SMF may send the QoS flow-level ECN marking for the L4S indicator to the PSA UPF via N4 as described in clause 5.37.3.3 of TS 23.501.

[0369] Through the technical solution provided by this disclosure, the energy-saving mechanism of the network is considered, enabling the network to operate in a more energy-efficient manner.

[0370] Figure 16 Network 1600 is shown according to various embodiments. Network 1600 may operate in a manner compliant with the 3GPP technical specifications of the LTE or 5G / NR systems. However, the example embodiments are not limited thereto, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, and so on.

[0371] Network 1600 may include a UE 1602, which may include any mobile or non-mobile computing device designed to communicate with a RAN 1604 via an air interface. The UE 1602 may be communicatively coupled to the RAN 1604 via the Uu interface. The UE 1602 may be, but is not limited to, a smart phone, a tablet computer, a wearable computing device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, a dashboard, a head-up display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an IoT device, and so on.

[0372] In some embodiments, network 1600 may include multiple UEs that are directly coupled to each other via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels, such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and so on.

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

[0374] RAN 1604 may include one or more access nodes, e.g., AN 1608. AN 1608 may terminate the air interface protocol for UE 1602 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this way, AN 1608 may enable data / voice connectivity between CN 1620 and UE 1602. In some embodiments, AN 1608 may be implemented in a discrete device or as one or more software entities running on a server computer, as part of, e.g., a virtual network, which may be referred to as CRAN or virtual baseband unit pool. AN 1608 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN 1608 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.

[0375] In embodiments where RAN 1604 includes multiple ANs, they may be coupled to each other via an X2 interface (if RAN 1604 is an LTE RAN) or an Xn interface (if RAN 1604 is a 5G RAN). The X2 / Xn interface (which may be separated into a control / user plane interface in some embodiments) may allow ANs to convey information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

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

[0377] RAN 1604 may provide an air interface via licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, nodes may use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCell / Scell. Before accessing unlicensed spectrum, nodes may perform medium / carrier sensing operations based on, e.g., the listen-before-talk (LBT) protocol.

[0378] In a V2X scenario, UE 1602 or AN 1608 can be or can act as an RSU, which can refer to any traffic infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. The RSU implemented in or by a UE can be referred to as a "UE-type RSU"; the RSU implemented in or by an eNB can be referred to as an "eNB-type RSU"; the RSU implemented in or by a gNB can be referred to as a "gNB-type RSU"; and so on. In one example, the RSU is a computing device coupled to a roadside radio frequency circuit that provides connectivity support to passing vehicle UEs. The RSU may also include an internal data storage circuit to store intersection map geometries, traffic flow statistics, media, and applications / software to sense and control 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, and the like. Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. The components of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic flow signal controller or a backhaul network.

[0379] In some embodiments, RAN 1604 can be an LTE RAN 1610 with an eNB, e.g., eNB 1612. The LTE RAN 1610 can provide an LTE air interface with the following characteristics: an SCS of 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo coding for data and TBCC for control; and so on. The LTE air interface can 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 can operate in a frequency band below 6 GHz.

[0380] In some embodiments, RAN 1604 may be an NG-RAN 1614 with a gNB, e.g., gNB 1616, or an NG-RAN 1614 with an ng-eNB, e.g., ng-eNB 1618. gNB 1616 may connect to a 5G-capable UE using a 5G NR interface. gNB 1616 may connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 1618 may also connect to the 5G core via the NG interface, but may connect to the UE via an LTE air interface. gNB 1616 and ng-eNB 1618 may connect to each other via an Xn interface.

[0381] In some embodiments, the NG interface may be split into two parts, one is the NG user plane (NG-U) interface, which carries traffic data (e.g., the N3 interface) between nodes of the NG-RAN 1614 and the UPF 1648, and the other is the NG control plane (NG-C) interface, which is a signaling interface between nodes of the NG-RAN 1614 and the AMF 1644 (e.g., the N2 interface).

[0382] The NG-RAN 1614 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simplex codes and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking of PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface may operate in the FR1 band including frequencies below 6 GHz or in the FR2 band including frequencies 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.

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

[0384] RAN 1604 is communicatively coupled to CN 1620, which includes network elements to provide various functions to support data and telecommunications services for customers / subscribers (e.g., the user of UE 1602). The components of CN 1620 can be implemented in one physical node or separate physical nodes. In some embodiments, NFV can be utilized to virtualize any or all of the functions provided by the network elements of CN 1620 onto physical computing / storage resources in servers, switches, etc. The logical instantiation of CN 1620 can be referred to as a network slice, and the logical instantiation of a part of CN 1620 can be referred to as a network sub-slice.

[0385] In some embodiments, CN 1620 can be an LTE CN 1622, which may also be referred to as the EPC. LTE CN 1622 may include MME 1624, SGW 1626, SGSN 1628, HSS 1630, PGW 1632, and PCRF 1634, which are coupled to each other through interfaces (or "reference points") as shown. The functions of the elements of LTE CN 1622 can be briefly introduced as follows.

[0386] MME 1624 can implement mobility management functions to track the current location of UE 1602 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc.

[0387] SGW 1626 can terminate the S1 interface towards the RAN and route data packets between the RAN and LTE CN 1622. SGW 1626 can be a local mobility anchor point for inter-RAN node handovers and can also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0388] The SGSN 1628 can track the location of the UE 1602 and perform security functions and access control. In addition, the SGSN 1628 can execute EPC inter-node signaling for mobility between different RAT networks; select the PDN and S-GW according to the provisions of the MME 1624; select the MME for handover; and so on. The S3 reference point between the MME 1624 and the SGSN 1628 can enable the exchange of user and bearer information for mobility between 3GPP access networks in the idle / active state.

[0389] The HSS 1630 can include a database for network users, which includes subscription-related information to support the handling of communication sessions by network entities. The HSS 1630 can provide support for routing / roaming, authentication, authorization, name / address resolution, location compliance, and so on. The S6a reference point between the HSS 1630 and the MME 1624 can enable the transmission of subscription and authentication data to authenticate / authorize user access to the LTE CN 1620.

[0390] The PGW 1632 can terminate the SGi interface towards the data network (DN) 1636, which can include the application / content server 1638. The PGW 1632 can route data packets between the LTE CN 1622 and the data network 1636. The PGW 1632 can be coupled to the SGW 1626 through the S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 1632 can also include a node (e.g., PCEF) for policy enforcement and charging data collection. In addition, the SGi reference point between the PGW 1632 and the data network 1636 can be an operator-external public or private PDN or an operator-internal packet data network, such as for the configuration of IMS services. The PGW 1632 can be coupled to the PCRF 1634 via the Gx reference point.

[0391] The PCRF 1634 is the policy and charging control element of the LTE CN 1622. The PCRF 1634 can be communicatively coupled to the application / content server 1638 to determine the appropriate QoS and charging parameters for the service flow. The PCRF 1632 can configure the associated rules into the PCEF with the appropriate TFT and QCI (via the Gx reference point).

[0392] In some embodiments, CN 1620 may be 5GC 1640. 5GC 1640 may include AUSF 1642, AMF 1644, SMF 1646, UPF 1648, NSSF 1650, NEF 1652, NRF 1654, PCF 1656, UDM 1658, and AF 1660, which are coupled to each other through interfaces (or "reference points") as shown in the figure. The functions of the elements of 5GC 1640 are briefly introduced as follows.

[0393] AUSF 1642 may store data for the authentication of UE 1602 and handle authentication-related functions. AUSF 1642 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of 5GC 1640 through reference points as shown in the figure, AUSF 1642 may also expose Nausf service-based interfaces.

[0394] AMF 1644 may allow other functions of 5GC 1640 to communicate with UE 1602 and RAN 1604, and subscribe to notifications regarding mobility events for UE 1602. AMF 1644 may be responsible for registration management (e.g., for registering UE 1602), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 1644 may provide transport for SM messages between UE 1602 and SMF 1646 and act as a transparent proxy for routing SM messages. AMF 1644 may also provide transport for SMS messages between UE 1602 and SMSF. AMF 1644 may interact with AUSF 1642 and UE 1602 to perform various security anchoring and context management functions. In addition, AMF 1644 may be an end point of the RAN CP interface, which may include or may be the N2 reference point between RAN 1604 and AMF 1644; and AMF 1644 may be an end point of NAS (N1) signaling and perform NAS encryption and integrity protection. AMF 1644 may also support NAS signaling with UE 1602 through the N3 IWF interface.

[0395] The SMF 1646 may be responsible for session management (e.g., session establishment, tunnel management between the UPF 1648 and the AN 1608); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuration of traffic steering at the UPF 1648 to route traffic to the appropriate destination; termination of the interface towards the policy control function; the control part of policy enforcement, charging, and QoS; lawful interception (for SM events and the interface to the LI system); termination of the SM part of NAS messages; downlink data notification; initiating AN-specific SM information sent to the AN 1608 via the AMF 1644 over N2; and determination of the SSC mode of the session. Session management may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 1602 and the data network 1636.

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

[0397] The NSSF 1650 may select a set of network slice instances to serve the UE 1602. If needed, the NSSF 1650 may also determine the allowed NSSAI and the mapping to the subscribed S-NSSAI. The NSSF 1650 may also determine, based on appropriate configuration and possibly by querying the NRF 1654, the set of AMFs or a list of candidate AMFs to be used to serve the UE 1602. The selection of a set of network slice instances for the UE 1602 may be triggered by the AMF 1644 to which the UE 1602 is registered through interaction with the NSSF 1650, which may result in a change of AMF. The NSSF 1650 may interact with the AMF 1644 via the N22 reference point; and may communicate with another NSSF in the visited network via the N31 reference point (not shown). In addition, the NSSF 1650 may expose the Nnssf service-based interface.

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

[0399] The NRF 1654 can support a service discovery function, receive NF discovery requests from NF instances, and provide information on the discovered NF instances to NF instances. The NRF 1654 also maintains information on available NF instances and the services they support. As used herein, terms such as "instantiation" can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. In addition, the NRF 1654 can expose the Nnrf service-based interface.

[0400] The PCF 1656 can provide policy rules to control plane functions to enable them to be enforced, and can also support a unified policy framework to constrain network behavior. The PCF 1656 can also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 1658. In addition to communicating with functions via reference points as shown, the PCF 1656 can also expose the Npcf service-based interface.

[0401] The UDM 1658 can handle subscription-related information to support the handling of communication sessions by network entities and can store the subscription data of the UE 1602. For example, the subscription data can be communicated via the N8 reference point between the UDM 1658 and the AMF 1644. The UDM 1658 can include two parts, an application front end and a UDR. The UDR can store subscription data and policy data for the UDM 1658 and the PCF 1656, and / or store structured data and application data for exposure (including PFDs for application detection, application request information for multiple UEs 1602) for the NEF 1652. The Nudr service-based interface can be exposed by the UDR to allow the UDM 1658, the PCF 1656, and the NEF 1652 to access a specific set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM can include a UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. Several different front ends can serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identity handling, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 1658 can also expose the Nudm service-based interface.

[0402] The AF 1660 can provide application impact on traffic routing, provide access to the NEF, and interact with the policy framework for policy control.

[0403] In some embodiments, the 5GC 1640 can implement edge computing by selecting an operator / third-party service to be geographically close to the point where the UE 1602 attaches to the network. This can reduce latency and load on the network. To provide edge computing implementation, the 5GC 1640 can select a UPF 1648 close to the UE 1602 and perform traffic steering from the UPF 1648 to the data network 1636 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 1660. In this way, the AF 1660 can influence UPF (re)selection and traffic routing. Based on operator deployment, when the AF 1660 is considered a trusted entity, the network operator can allow the AF 1660 to directly interact with the relevant NFs. In addition, the AF 1660 can expose the Naf service-based interface.

[0404] The data network 1636 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, such as including application / content servers 1638.

[0405] Figure 17FIG. 1700 schematically illustrates a wireless network 1700 in accordance with various embodiments. The wireless network 1700 may include a UE 1702 that wirelessly communicates with an AN 1704. The UE 1702 and the AN 1704 may be similar to components of similar names described elsewhere herein and may be substantially interchangeable with those components.

[0406] The UE 1702 may be communicatively coupled to the AN 1704 via a connection 1706. The connection 1706 is illustrated as an air interface to enable the communicative coupling and may conform to a cellular communication protocol, such as the LTE protocol or the 5G NR protocol operating at mmWave or sub-6 GHz frequencies.

[0407] The UE 1702 may include a host platform 1708 coupled to a modem platform 1710. The host platform 1708 may include application processing circuitry 1712, which may be coupled to protocol processing circuitry 1714 of the modem platform 1710. The application processing circuitry 1712 may run various applications for the UE 1702 that originate / sink application data. The application processing circuitry 1712 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.

[0408] The protocol processing circuitry 1714 may implement one or more layer operations to facilitate sending or receiving data over the connection 1706. The layer operations implemented by the protocol processing circuitry 1714 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0409] The modem platform 1710 may further include digital baseband circuitry 1716, which may implement one or more layer operations “below” the layer operations performed by the protocol processing circuitry 1714 in a network protocol stack. These operations may include, for example, PHY operations, which may include 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 space 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.

[0410] The modem platform 1710 may also include a transmit circuit 1718, a receive circuit 1720, an RF circuit 1722, and an RF front end (RFFE) 1724, which may include or be connected to one or more antenna panels 1726. In short, the transmit circuit 1718 may include a digital-to-analog converter, a mixer, intermediate frequency (IF) components, etc.; the receive circuit 1720 may include an analog-to-digital converter, a mixer, IF components, etc.; the RF circuit 1722 may include a low-noise amplifier, a power amplifier, a power tracking component, etc.; the RFFE 1724 may include filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of the transmit circuit 1718, the receive circuit 1720, the RF circuit 1722, the RFFE 1724, and the antenna panel 1726 (collectively referred to as "transmit / receive components") may depend on the details of the specific implementation, e.g., whether the communication is TDM or FDM, at mmWave or sub-6GHz frequencies, etc. In some embodiments, the transmit / receive components may be arranged in multiple parallel transmit / receive chains and may be disposed on the same or different chips / modules, etc.

[0411] In some embodiments, the protocol processing circuit 1714 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit / receive components.

[0412] UE reception may be established by and through the antenna panel 1726, the RFFE 1724, the RF circuit 1722, the receive circuit 1720, the digital baseband circuit 1716, and the protocol processing circuit 1714. In some embodiments, the antenna panel 1726 may receive transmissions from the AN 1704 via receive beamforming signals received by a plurality of antennas / antenna elements of one or more antenna panels 1726.

[0413] UE transmission may be established by and through the protocol processing circuit 1714, the digital baseband circuit 1716, the transmit circuit 1718, the RF circuit 1722, the RFFE 1724, and the antenna panel 1726. In some embodiments, the transmit components of the UE 1704 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panel 1726.

[0414] Similar to UE 1702, AN 1704 may include a host platform 1728 coupled to a modem platform 1730. The host platform 1728 may include an application processing circuit 1732 coupled to a protocol processing circuit 1734 of the modem platform 1730. The modem platform may also include a digital baseband circuit 1736, a transmit circuit 1738, a receive circuit 1740, an RF circuit 1742, an RFFE circuit 1744, and an antenna panel 1746. The components of AN 1704 may be similar to the similarly named components of UE 1702 and are substantially interchangeable. In addition to performing data transmission / reception as described above, the components of AN 1708 may also perform various logical functions, which include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0415] Figure 18 The block diagram of 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 of the methods discussed herein. Specifically, Figure 18 illustrates a graphical representation of hardware resources 1800, which include one or more processors (or processor cores) 1810, one or more memory / storage devices 1820, and one or more communication resources 1830, where each may be communicatively coupled via a bus 1840 or other interface circuit. For embodiments that utilize node virtualization (e.g., NFV), a hypervisor 1802 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1800.

[0416] The processor 1810 may include, for example, a processor 1812 and a processor 1814. The processor 1810 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 thereof.

[0417] The memory / storage device 1820 may include a main memory, disk storage, or any suitable combination thereof. The memory / storage device 1820 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 the like.

[0418] The communication resources 1830 may include an interconnect or network interface controller, components, or other suitable devices to communicate with one or more peripheral devices 1804 or one or more databases 1806 or other network elements via the network 1808. For example, the communication resources 1830 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, (or low-power ) components, components, and other communication components.

[0419] The instructions 1850 may include software, programs, applications, applets, apps, or other executable code for causing at least any one of the processors 1810 to perform any one or more of the methods discussed herein. The instructions 1850 may reside wholly or partially within at least one of the processors 1810 (e.g., within the cache memory of the processor), within the memory / storage device 1820, or any suitable combination thereof. Additionally, any portion of the instructions 1850 may be transferred from any combination of the peripheral devices 1804 or databases 1806 to the hardware resources 1800. Accordingly, the memories of the processors 1810, the memory / storage device 1820, the peripheral devices 1804, and the databases 1806 are examples of computer-readable and machine-readable media.

[0420] Figure 19FIG. 1900 illustrates a network 1900 according to various embodiments. The network 1900 may operate in a manner compliant with 3GPP technical specifications or technical reports for 6G systems. In some embodiments, the network 1900 may operate concurrently with the network 1600. For example, in some embodiments, the network 1900 may share one or more frequency or bandwidth resources with the network 1600. As a specific example, a UE (e.g., UE 1902) may be configured to operate in both the network 1900 and the network 1600. Such a configuration may be based on the UE including circuitry configured to communicate with the frequency and bandwidth resources of both the network 1600 and the network 1900. Generally, several elements of the network 1900 may share one or more characteristics with elements of the network 1600. For the sake of brevity and clarity, these elements may not be repeated in the description of the network 1900.

[0421] The network 1900 may include a UE 1902, which may include any mobile or non-mobile computing device designed to communicate with the RAN 1908 via an air interface. The UE 1902 may be similar to, for example, the UE 1602. The UE 1902 may be, but is not limited to, a smart phone, a tablet computer, a wearable computing device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, a dashboard, a head-up display device, an on-vehicle diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an IoT device, and so on.

[0422] Although not specifically shown in Figure 19 FIG. 1900, in some embodiments, the network 1900 may include multiple UEs that are directly coupled to each other via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and so on. Similarly, although not specifically shown in Figure 19 FIG. 1900, the UE 1902 may be communicatively coupled to an AP (e.g., the AP 1606 as referenced in Figure 16 FIG. 1606). Additionally, although not specifically shown in Figure 19 FIG. 1900, in some embodiments, the RAN 1908 may include one or more ANs, such as the AN 1608 as referenced in Figure 16 FIG. 1608. The RAN 1908 and / or the ANs of the RAN 1908 may be referred to as a base station (BS), a RAN node, or some other term or name.

[0423] UE 1902 and RAN 1908 may be configured to communicate via an air interface that may be referred to as a sixth generation (6G) air interface. The 6G air interface may include one or more features such as communication in the terahertz (THz) or sub-terahertz bandwidth, or joint communication and sensing. As used herein, the term "joint communication and sensing" may refer to a system that enables wireless communication and radar-based sensing via various types of multiplexing. As used herein, the THz or sub-THz bandwidth may 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.

[0424] RAN 1908 may allow communication between UE 1902 and 6G core network (CN) 1910. Specifically, RAN 1908 may facilitate the transmission and reception of data between UE 1902 and 6G CN 1910. 6G CN 1910 may include various functions such as NSSF 1650, NEF 1652, NRF 1654, PCF 1656, UDM 1658, AF 1660, SMF 1646, and AUSF 1642. As Figure 19 shown, 6G CN 1910 may also include UPF 1648 and DN 1636.

[0425] In addition, RAN 1908 may include various additional functions that are additive or alternative to those of traditional cellular networks such as 4G or 5G networks. Two such functions may include a Compute Control Function (Comp CF) 1924 and a Compute Service Function (Comp SF) 1936. Comp CF 1924 and Comp SF 1936 may be parts or functions of a compute service plane. CompCF 1924 may be a control plane function that provides functions such as management of Comp SF 1936, compute task context generation and management (e.g., create, read, modify, delete), interaction with the underlying compute infrastructure for compute resource management, and so on. Comp SF 1936 may be a user plane function that acts as an interface gateway between a compute service user (e.g., UE 1902) and the compute nodes behind the CompSF instance. Some functions of Comp SF 1936 may include: parsing compute service data received from a user to compute tasks executable by compute nodes; maintaining a service mesh ingress gateway or a service API gateway; service and charging policy enforcement; performance monitoring and telemetry collection, and so on. In some embodiments, the Comp SF 1936 instance may act as a user plane gateway for a cluster of compute nodes. The Comp CF 1924 instance may control one or more Comp SF 1936 instances.

[0426] Two other such functions may include a Communication Control Function (Comm CF) 1928 and a Communication Service Function (CommSF) 1938, which may be part of the communication service plane. The Comm CF 1928 may be a control plane function for managing the Comm SF 1938, creating / configuring / releasing communication sessions, and managing communication session contexts. The CommSF 1938 may be a user plane function for data transmission. The CommCF 1928 and Comm SF 1938 may be regarded as upgrades of the SMF 1646 and UPF 1648, for which the 5G system has been described in Figure 16 Reference []. The upgrades provided by the Comm CF 1928 and Comm SF 1938 enable service-aware transmission. For traditional (e.g., 4G or 5G) data transmission, the SMF 1646 and UPF 1648 may still be used.

[0427] Two other such functions may include a Data Control Function (Data CF) 1922 and a Data Service Function (Data SF) 1932, which may be part of the data service plane. The Data CF 1922 may be a control plane function and provide functions such as Data SF 1932 management, data service creation / configuring / releasing, data service context management, and so on. The Data SF 1932 may be a user plane function and act as a gateway between the data service users (e.g., various functions of the UE 1902 and 6G CN 1910) and the data service endpoints behind the gateway. Specific functions may include: parsing data service user data and forwarding it to the corresponding data service endpoints, generating charging data, and reporting data service status.

[0428] Another such function may be a Service Orchestration and Chaining Function (SOCF) 1920, which may discover, orchestrate, and chain communication / computing / data services provided by functions in the network. After receiving a service request from a user, the SOCF 1920 may interact with one or more of the Comp CF 1924, Comm CF 1928, and Data CF 1922 to identify Comp SF 1936, Comm SF 1938, and Data SF 1932 instances, configure service resources, and generate a service chain, which may contain multiple Comp SF 1936, Comm SF 1938, and Data SF 1932 instances and their associated computing endpoints. Then, workload processing and data movement may be performed within the generated service chain. The SOCF 1920 may also be responsible for maintaining, updating, and releasing the created service chain.

[0429] Another such function can be the service registration function (SRF) 1914, which can act as a registration center for system services provided in the user plane, such as services provided by the Comp SF 1936 and service endpoints behind the data SF 1932 gateway, as well as services provided by the UE 1902. The SRF 1914 can be regarded as the counterpart of the NRF 1654, which can act as a registration center for network functions.

[0430] Other such functions can include the evolved service communication proxy (eSCP) and the service infrastructure control function (SICF) 1926, which can provide service communication infrastructure for control plane services and user plane services. The eSCP may be related to the service communication proxy (SCP) of 5G and adds user plane service communication proxy capabilities. The eSCP is thus expressed as two parts: the eCSP-C 1912 and the eSCP-U 1934, for control plane service communication proxy and user plane service communication proxy respectively. The SICF 1926 can control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configurations, performance monitoring, and so on.

[0431] Another such function is the AMF 1944. The AMF 1944 can be similar to the 1644 but has additional functions. Specifically, the AMF 1944 can include potential function re-partitioning, such as moving the message forwarding function from the AMF 1944 to the RAN 1908.

[0432] Another such function is the service orchestration exposure function (SOEF) 1918. The SOEF can be configured to expose service orchestration and chained services to external users (such as applications).

[0433] UE 1902 may include an additional function called the Compute Client Service Function (comp CSF) 1904. The comp CSF 1904 may have both control plane functions and user plane functions, and may interact with corresponding network-side functions (e.g., SOCF 1920, Comp CF 1924, Comp SF 1936, Data CF 1922, and / or Data SF 1932) to achieve service discovery, request / response, compute task workload exchange, etc. Comp CSF 1904 may also cooperate with network-side functions to determine whether compute tasks should be run on elements of UE 1902, RAN 1908, and / or 6G CN 1910.

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

[0435] Figure 20 An example functional framework 2000 for ML and / or RAN intelligence is depicted. The functional framework 2000 includes a data collection function 2005 that provides input data for a model training function 2010 and a model inference function 2015. 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 2005. Examples of input data may include: measurements from UEs, RAN nodes, and / or additional or alternative network entities; feedback from an actor 2020; and / or (one or more) outputs from (one or more) ML models. The input data fed into the model training function 2010 is training data, and the input data fed into the model inference function 2015 is inference data.

[0436] The model training function 2010 is a function that performs ML model training, validation, and testing. As part of the model testing process and / or model validation process, the model training function 2010 may generate model performance metrics. Examples of model performance metrics will be discussed below. If needed, the model training function 2010 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the training data provided by the data collection function 2005.

[0437] The model training function 2010 performs model deployment / updates, where the model training function 2010 initially deploys a trained, validated, and tested ML model to the model inference function 2015, and / or delivers one or more updated models to the model inference function 2015. Examples of model deployment and updates will be discussed below.

[0438] The model inference function 2015 is a function that provides inference outputs of an ML model (e.g., statistical inference, prediction, decision-making, probability and / or probability distribution, action, configuration, policy, data analysis, result, optimization, etc.). The model inference function 2015 can provide model performance feedback to the model training function 2010 when applicable. The model performance feedback can include various performance metrics related to generating inferences (e.g., any of the metrics discussed herein). The model performance feedback can be used to monitor the performance of the ML model when applicable. If needed, the model inference function 2015 can 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 2005.

[0439] The model inference function 2015 generates inference outputs, i.e., inferences generated or otherwise produced when the model inference function 2015 operates the ML model using the inference data. The model inference function 2015 provides the inference outputs to the actuator 2020. The details of the inference outputs are related to the specific use case and can be based on the specific type of ML model being used.

[0440] The actuator 2020 is a function that receives the inference outputs from the model inference function 2015 and triggers or otherwise performs corresponding operations based on the inference outputs. The actuator 2020 can trigger operations on other entities and / or itself. In some examples, the actuator 2020 is a NES function, a mobile optimization function, and / or a load balancing function. Additionally or alternatively, the inference outputs are related to NES, mobility optimization, and / or load balancing, and the actuator 2020 is one or more RAN nodes that perform various NES operations, mobility optimization operations, and / or load balancing operations based on the inferences.

[0441] The actuator 2020 can also provide feedback to the data collection function 2005 for storage. The feedback includes information related to the actions performed by the actuator 2020. The feedback can include any information that may be required, which can be used to obtain 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.

[0442] Figure 21depicts an example AI / ML-assisted communication network that includes communication between ML functions (MLFs) 2102 and 2104. In some embodiments, ML models / entities may be used or utilized to facilitate wired and / or over-the-air communication between MLF 2102 and MLF 2104. In this embodiment, the operations of MLF 2102 and MLF 2104 comply with 3GPP technical specifications and / or technical reports of 5G and / or 6G systems, such as any of the technical reports discussed herein. In some examples, the communication mechanism between MLF 2102 and MLF 2104 includes any suitable access technology and / or RAT, such as any of the technologies and / or RATs discussed herein. Additionally, Figure 21 the communication mechanism in Figure 1-13 may be part of and / or operate concurrently with other components, devices, systems, networks, and / or deployments described herein.

[0443] MLFs 2102, 2104 may correspond to any entity / element discussed herein. In one example, MLF 2102 corresponds to MnF and / or MnS-P, and MLF 2104 corresponds to a consumer, MnS-C, and vice versa. In this example, the groups of MLFs may be mutually exclusive, or some or all of the MLFs in each group of MLFs may overlap or share. In another example, MLF 2102 and / or MLF 2104 are implemented by corresponding UEs (e.g., UE 1602, UE 1702, UE 1902). Additionally or alternatively, MLF 2102 and / or MLF 2104 are implemented by the same UE or different UEs. In another example, MLF 2102 and / or MLF 2104 are implemented by a corresponding RAN or a corresponding NAN. Additionally or alternatively, some or all of the elements / entities in individual MLFs 2102, 2104 may be implemented or operated by separate entities / elements.

[0444] As Figure 21 shown, MLF 2102 and MLF 2104 include various AI / ML-related components, functions, elements, or entities, which may 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 multi-processor chip), software (e.g., program, process, engine, etc.), or firmware as at least one other element, function, element, or entity. The AI / ML-related elements of MLF 2102 may be the same as or similar to the AI / ML-related elements of MLF 2104. For the sake of brevity, various elements will be described from the perspective of MLF 2102, but it can be understood that such descriptions apply to the similarly named / numbered elements of MLF 2104 unless otherwise explicitly stated.

[0445] The data repository 2115 is responsible for data collection and storage. As an example, the data repository 2115 may collect and store RAN configuration parameters, NF configuration parameters, measurement data, RLM data, key performance indicators (KPIs), SLAs, model performance metrics, knowledge base data, ground truth data, ML model parameters, hyperparameters, and / or other data for model training, updating, and inference. In some examples, the data collection function (not shown) is part of or connected to the data repository 2115. The data collection function is a function that provides input data to the MLTF 2125 and the model inference function 2145. 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 measurement results from UEs, RAN nodes, and / or additional or alternative network entities; feedback from actuators; and / or (one or more) outputs from (one or more) ML models. The input data fed to the MLTF 2125 is training data, and the input data fed to the model inference function 2145 is inference data.

[0446] The collected data is stored in / by the repository 2115, and the stored data can be discovered and extracted from the data repository 2115 by other elements. For example, the inference data selector / filter 2150 may retrieve data from the data repository 2115 and provide the data to the inference engine 2145 to generate / determine an inference. In various examples, the MLF 2102 is configured to discover and request data from the data repository 2115 in the MLF 2104, and / or vice versa. In these examples, the data repository 2115 of the MLF 2102 may be communicatively coupled to the data repository 2115 of the MLF 2104, such that the corresponding data repositories 2115 may share the collected data with each other. Additionally or alternatively, the MLF 2102 and / or the MLF 2104 are configured to discover and request data from one or more external sources and / or data storage systems / devices.

[0447] The training data selection / filter 2120 is configured to generate training, validation, and test data sets for machine learning training (MLT) (or ML model training). One or more of these data sets can be extracted from or otherwise obtained from the data repository 2115. The data can be selected / filtered based on the specific ML model to be trained. Optionally, the data can be transformed, augmented, and / or preprocessed (e.g., normalized) before being loaded into the data sets. The training data selection / filter 2120 can label the data in the data sets for supervised learning; or it can leave the data unlabeled for unsupervised learning. Then, the generated data sets can be fed into the MLT function (MLTF) 2125.

[0448] The MLTF 2125 is responsible for training and updating (e.g., tuning and / or retraining) the ML models. The selected model (or set of models) can be trained using the data sets (including training, validation, test) fed from the training data selection / filter 2120. The MLTF 2125 generates trained and tested ML models that can be used for deployment at any time. The generated trained and tested models can be stored in the model repository 2135. Additionally or alternatively, the MLTF 2125 performs ML model training, validation, and testing. As part of the model testing process and / or the model validation process, the MLTF 2125 can generate model performance metrics. Examples of model performance metrics will be discussed below. If needed, the MLTF 2125 can also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the data collection function and / or the training data provided by the training data selection / filter 2120. The MLTF 2125 performs model deployment / updates, where the MLTF 2125 initially deploys the trained, validated, and tested ML models to the model inference function 2145, and / or delivers the (one or more) updated models to the model inference function 2145. Examples of model deployment and updates will be discussed below.

[0449] The model library 2135 is responsible for the storage and exposure of ML models (trained and untrained). Various model data can be stored in the model library 2135. For example, the model data can include the (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, the model data can also include the inferences made when running the ML model. The model data can be discovered and requested by other MLF components (e.g., the training data selection / filter 2120 and / or the MLTF 2125). In some examples, the MLF 2102 can discover and request model data from the model library 2135 of the MLF 2104. Additionally or alternatively, the MLF 2104 can discover and / or request model data from the model library 2135 of the MLF 2102. In some examples, the MLF 2104 can configure models, model parameters, hyperparameters, model execution parameters / conditions, and / or other aspects of the ML model in the model library 2135 of the MLF 2102. For the sake of representability and manageability, the ML model is also referred to as an ML entity in this document, i.e., the two terms ML model and ML entity can be used interchangeably in this document.

[0450] The model management function 2140 is responsible for managing the ML models generated by the MLTF 2125. Such management functions can include: deploying the trained models, monitoring the performance of the ML entities, reporting the ML entity verification and / or performance data, etc. When deploying a model, the model management function 2140 can allocate and schedule the 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 using the (one or more) trained ML models to generate statistical inferences, 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"). In some examples, the inference process can include: feeding the input inference data into the ML model (e.g., the inference engine 2145), passing the input inference data forward through the architecture / topology of the ML model, where the ML model performs calculations on the data using the parameters it has learned (e.g., weights and biases), and predicting the output. In some examples, the inference process can include data transformation before the forward pass, where the input inference data is preprocessed or transformed to match the format required by the ML model. In performance monitoring, based on the model performance KPIs and / or metrics, the model management function 2140 can decide to terminate a running model, start model retraining and / or adjustment, select another model, etc. In an example, the model management function 2140 of the MLF 2104 can configure the model management policy in the MLF 2102, and vice versa.

[0451] As described below, the inference data selection / filter 2150 is responsible for generating the dataset for model inference at inference 2145. For example, the inference data can be extracted from the data repository 2115. The inference data selection / filter 2150 can select and / or filter data according to the deployed ML model. The data can be transformed, augmented, and / or preprocessed in the same or similar manner as the transformation, augmentation, and / or preprocessing of the training data selection / filtering (e.g., as described for the training data selection filter 2120). The generated inference dataset can be fed into the inference engine 2145.

[0452] The inference engine 2145 (also referred to as "model inference function 2145" etc.) is responsible for performing / generating the inferences described herein. The inference engine 2145 consumes the inference dataset provided by the inference data selection / filter 2150 and generates an ML model inference output, which includes one or more inferences. For example, the inference can be or include statistical inference, prediction, decision-making, probability and / or probability distribution, action, configuration, policy, data analysis, result, optimization, etc. The (one or more) inferences / (one or more) results can be provided to the performance measurement function 2130. When applicable, the model inference function 2145 can provide model performance feedback to the MLTF 2125 and / or the performance measurement function 2130. The model performance feedback can include various performance metrics related to generating the inferences (e.g., any of the metrics discussed herein). The model performance feedback can be used to monitor the performance of the ML model when applicable. If needed, the model inference function 2145 can 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 2150. The model inference function 2145 generates an inference output, i.e., the inferences generated or otherwise generated when the model inference function 2145 runs the ML model using the inference data (set). The details of the inference output are related to the specific use case and can be based on the specific type of the ML model being used.

[0453] In some examples, the model inference function 2145 provides an inference output to an actuator (not shown). An actuator is a function, engine, component, device, system, network, and / or other entity that receives the inference output from the model inference function 2145 and triggers or otherwise performs a corresponding action(s) based on the inference output. The actuator can trigger actions for other entities and / or itself. In some examples, the actuator 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) functions, including any functions mentioned herein. Additionally or alternatively, the inference output is related to NES, MRO, and / or LBO, and the actuator is one or more RAN nodes that perform various NES, MRO, and / or LBO operations based on the inference. The actuator can also provide feedback to the performance measurement function 2130 and / or the data collection function / data repository 2115 for storage. Actuator feedback includes information related to the actions performed by the actuator. For example, the feedback includes any information that may be required to obtain training data, 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.

[0454] The performance measurement function 2130 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 / measurements, such as any metrics / measurements discussed herein) of a deployed and executing model based on the inference(s) for monitoring purposes. The model performance data can be stored in the data repository 2115 and / or reported according to the validation report mechanism discussed herein.

[0455] The performance metrics that the performance measurement function 2130 can measure and / or predict can be based on specific AI / ML tasks and other inputs / parameters of the ML entity. The 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 metrics that 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.

[0456] Model-based metrics can be based on a specific type of ML model and / or AI / ML domain. For example, regression-related metrics for a regression-based ML model can be predicted. 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 (R2), Golbraikh and Tropsha criteria, and / or other similar regression-related metrics such as those discussed in the article by Naser et al. (Insights into Performance Fitness and Error Metrics for Machine Learning, arXiv:2006.00887v1 (17 May 2020) (“[Naser]”)).

[0457] In another example, correlation-related metrics can be used to predict a correlation-related model. Examples of correlation-related metrics include accuracy, precision (also known as positive predictive value (PPV)), mean average 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-related metrics such as those discussed in [Naser].

[0458] Additional or alternative model-based metrics can also be predicted, 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), intersection over union (IoU), perplexity, bilingual evaluation understudy (BLEU) score, start score, Wasserstein metric, Fréchet inception distance (FID), string metric, edit distance, Levenshtein distance, Damerau–Levenshtein distance, number of evaluation instances (e.g., iterations, durations, or events), learning rate (e.g., the speed at which an algorithm reaches (converges to) optimal weights), learning rate decay (or weight decay), number and / or type of computations, multiply and accumulates (MAC) number and / or type, multiply adds (MAdds) operation number and / or type, and / or other similar performance metrics related to the performance of the ML model.

[0459] Examples of platform-based metrics include latency, response time, throughput (e.g., the rate at which a processor or platform / system processes work), 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 an inference and / or similar metrics), memory footprint, memory utilization, processor utilization, processor time, number of computations, 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.

[0460] Additionally or alternatively, proxy metrics (e.g., metrics or attributes that serve as a stand-in or substitute for another metric or attribute) can be used to predict the performance of the ML model. For any of the above performance metrics, any suitable data collection and / or measurement mechanism can be used to predict and / or measure the total amount, average value, and / or other distribution of such metrics.

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

[0462] Example A1 includes an apparatus comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: encode an energy information analysis request for transmission to a network data analytics function (NWDAF); and decode an energy information analysis response received from the NWDAF in response to the energy information analysis request to obtain an energy information analysis, wherein the memory is configured to store the energy information analysis.

[0463] Example A2 includes the apparatus described in Example A1 and / or any other example herein, wherein the energy information analysis request includes: an analysis ID indicating that the energy information analysis request is for the energy information analysis; an analysis report target indicating the object for which the energy information analysis is requested; analysis filtering information indicating the criteria or conditions that need to be met for reporting the energy information analysis; or an analysis target period indicating the time interval of the energy information analysis.

[0464] Example A3 includes the apparatus described in Example A2 and / or any other example herein, wherein the analysis filtering information includes: energy saving level; renewable energy support; single network slice selection assistance information (S-NSSAI) or a combination of S-NSSAI and data network name (DNN) / data network access ID (DNAI); application ID; traffic type of interest; maximum energy credit of the subscriber; reporting threshold; or preferred accuracy level.

[0465] Example A4 includes the apparatus described in Example A1 and / or any other example herein, wherein the energy information analysis response includes: resource energy state; energy efficiency per slice; energy efficiency of the next generation (NG) radio access network (RAN) (NG-RAN) node; power consumption of the fifth generation (5G) core network (5GC); power consumption of the NG-RAN; power consumption of the NG RAN node; traffic load trend of the cell; energy saving recommendations for the NG-RAN; or energy saving recommendations for the 5GC.

[0466] Example A5 includes the apparatus described in Example A4 and / or any other example herein, wherein the resource energy state is used to indicate the energy information of the network function (NF) instance corresponding to the NF ID or NF set ID, and the resource energy state includes: NF ID; NF energy state; NF energy saving level; NF energy efficiency; NF power consumption; or NF energy saving recommendations.

[0467] Example A6 includes the apparatus described in Example A1 and / or any other example herein, wherein the energy information analysis is obtained based on a subscription service or a notification service.

[0468] Example A7 includes the apparatus described in Example A1 and / or any other example herein, wherein the energy information analysis request includes an Nnwdaf_AnalyticsSubscription subscription, and the energy information analysis response includes an Nnwdaf_AnalyticsSubscription notification; or the energy information analysis request includes an Nnwdaf_AnalyticsInfo request, and the energy information analysis response includes an Nnwdaf_AnalyticsInfo response.

[0469] Example A8 includes the apparatus described in Example A1 and / or any other example herein, wherein the energy information analysis includes energy efficiency data at a network level, a user equipment (UE) level, a UE group level, a network slice level, or a protocol data unit (PDU) session level.

[0470] Example A9 includes the apparatus described in Example A1 and / or any other example herein, wherein the processor circuit is further configured to: encode a network function (NF) load analysis request for transmission to the NWDAF; and decode an NF load analysis response received from the NWDAF in response to the NF load analysis request to obtain an NF load analysis.

[0471] Example A10 includes the apparatus described in Example A1 and / or any other example herein, wherein the processor circuit is further configured to: encode a network function (NF) performance analysis request for transmission to the NWDAF; and decode an NF performance analysis response received from the NWDAF in response to the NF performance analysis request to obtain an NF performance analysis.

[0472] Example A11 includes the apparatus described in Example A1 and / or any other example herein, wherein the processor circuit is further configured to: encode a data network (DN) service performance analysis request for transmission to the NWDAF; and decode a DN service performance analysis response received from the NWDAF in response to the DN service performance analysis request to obtain a DN service performance analysis.

[0473] Example A12 includes the apparatus described in any one of Examples A1 to A11 and / or any other example herein, wherein the apparatus is applicable to an NWDAF consumer.

[0474] Example A13 includes the apparatus described in Example A12 and / or any other example herein, wherein the NWDAF consumer includes a fifth generation (5G) core network (5GC) network function (NF).

[0475] Example A14 includes the apparatus described in Example A13 and / or any other example herein, wherein the 5GC NF includes an energy efficiency control function (EECF), a policy control function (PCF), a session management function (SMF), or an access and mobility management function (AMF).

[0476] Example A15 includes a device that includes: a memory; and processor circuitry coupled to the memory, wherein the processor circuitry is configured to: decode an energy information analysis request received from a service consumer for energy information analysis; in response to the energy information analysis request, collect data from a network function (NF), an operations, administration, and maintenance (OAM) entity / function, or an application function (AF); generate the energy information analysis based on the data; and encode an energy information analysis response carrying the energy information analysis for transmission to the service consumer, wherein the memory is used to store the data.

[0477] Example A16 includes the device as described in Example A15 and / or any other example herein, wherein the energy information analysis request includes: an analysis ID indicating that the energy information analysis request is for the energy information analysis; an analysis report target indicating an object for which the energy information analysis is requested; analysis filtering information indicating criteria or conditions that the reported energy information analysis needs to meet; or an analysis target period indicating a time interval of the energy information analysis.

[0478] Example A17 includes the device as described in Example A16 and / or any other example herein, wherein the analysis filtering information includes: an energy saving level; renewable energy support; a single network slice selection assistance information (S-NSSAI) or a combination of S-NSSAI and a data network name (DNN) / data network access identifier (DNAI); an application ID; a traffic type of interest; a maximum energy credit of a subscriber; a reporting threshold; or a preferred accuracy level.

[0479] Example A18 includes the device as described in Example A15 and / or any other example herein, wherein the energy information analysis response includes: a resource energy state; energy efficiency per slice; energy efficiency of a next generation (NG) radio access network (RAN) (NG-RAN) node; power consumption of a fifth generation (5G) core network (5GC); power consumption of the NG-RAN; power consumption of an NG RAN node; a traffic load trend of a cell; an energy saving recommendation for the NG-RAN; or an energy saving recommendation for the 5GC.

[0480] Example A19 includes the device as described in Example A18 and / or any other example herein, wherein the resource energy state is used to indicate energy information of a network function (NF) instance of a corresponding NF ID or NF set ID, and the resource energy state includes: an NF ID; an NF energy state; an NF energy saving level; an NF energy efficiency; an NF power consumption; or an NF energy saving recommendation.

[0481] Example A20 includes the apparatus described in Example A15 and / or any other example herein, wherein the energy information analysis request includes an Nnwdaf_AnalyticsSubscription subscription, and the energy information analysis response includes an Nnwdaf_AnalyticsSubscription notification; or the energy information analysis request includes an Nnwdaf_AnalyticsInfo request, and the energy information analysis response includes an Nnwdaf_AnalyticsInfo response.

[0482] Example A21 includes the apparatus described in Example A15 and / or any other example herein, wherein the data collected from the OAM entity / function includes: energy saving status; power type of the NF; power consumption of the Next Generation (NG) Radio Access Network (RAN) (NG-RAN) node; power consumption of the NG-RAN; power consumption of the Fifth Generation (5G) Core Network (5GC) NF; power consumption of the 5GC; energy efficiency per slice; energy efficiency of the NG-RAN node; energy efficiency of the 5GC NF; traffic load trend of the cell; traffic prediction of the network slice; energy saving suggestions for the NG-RAN; energy saving suggestions for the 5GC; energy saving suggestions for the NF; or energy saving level of the NF.

[0483] Example A22 includes the apparatus described in Example A15 and / or any other example herein, wherein the data collected from the AF includes: application ID; User Equipment (UE) ID; application server instance; IP filtering information; uplink (UL) / downlink (DL) performance data; or timestamp.

[0484] Example A23 includes the apparatus described in Example A15 and / or any other example herein, wherein the energy information analysis includes energy efficiency data at network level, User Equipment (UE) level, UE group level, network slice level, or Protocol Data Unit (PDU) session level.

[0485] Example A24 includes the apparatus described in Example A15 and / or any other example herein, wherein the processor circuit is further configured to: decode an NF load analysis request for NF load analysis received from the service consumer; in response to the NF load analysis request, collect data from the NF, the OAM entity / function, or the AF; generate the NF load analysis based on the data; and encode an NF load analysis response carrying the NF load analysis for transmission to the service consumer.

[0486] Example A25 includes the apparatus described in Example A15 and / or any other example herein, wherein the processor circuit is further configured to: decode an NF performance analysis request for NF performance analysis received from the service consumer; collect data from the NF, the OAM entity / function, or the AF in response to the NF performance analysis request; generate the NF performance analysis based on the data; and encode an NF performance analysis response carrying the NF performance analysis for transmission to the service consumer.

[0487] Example A26 includes the apparatus described in Example A15 and / or any other example herein, wherein the processor circuit is further configured to: decode a DN service performance analysis request for data network (DN) service performance analysis received from the service consumer; collect data from the NF, the OAM entity / function, or the AF in response to the DN service performance analysis request; generate the DN service performance analysis based on the data; and encode a DN service performance analysis response carrying the DN service performance analysis for transmission to the service consumer.

[0488] Example A27 includes the apparatus described in Example A15 and / or any other example herein, wherein the service consumer includes a network data analytics function (NWDAF) consumer.

[0489] Example A28 includes the apparatus described in Example A27 and / or any other example herein, wherein the NWDAF consumer includes a fifth generation (5G) core network (5GC) network function (NF).

[0490] Example A29 includes the apparatus described in Example A28 and / or any other example herein, wherein the 5GC NF includes an energy efficiency control function (EECF), a policy control function (PCF), a session management function (SMF), or an access and mobility management function (AMF).

[0491] Example A30 includes the apparatus described in any one of Examples A15 to A29 and / or any other example herein, wherein the apparatus is applicable to a network data analytics function (NWDAF).

[0492] Example A31 includes a method, comprising: encoding an energy information analysis request for transmission to a network data analytics function (NWDAF); and decoding an energy information analysis response received from the NWDAF in response to the energy information analysis request to obtain an energy information analysis.

[0493] Example A32 includes the method described in Example A31 and / or any other example herein, wherein the energy information analysis request includes: an analysis ID indicating that the energy information analysis request is for the energy information analysis; an analysis report target indicating the object for which the energy information analysis is requested; analysis filtering information indicating the criteria or conditions that need to be met for reporting the energy information analysis; or an analysis target period indicating the time interval of the energy information analysis.

[0494] Example A33 includes the method described in Example A32 and / or any other example herein, wherein the analysis filtering information includes: energy saving level; renewable energy support; single network slice selection assistance information (S-NSSAI) or a combination of S-NSSAI and data network name (DNN) / data network access ID (DNAI); application ID; traffic type of interest; maximum energy credit of the subscriber; reporting threshold; or preferred accuracy level.

[0495] Example A34 includes the method described in Example A31 and / or any other example herein, wherein the energy information analysis response includes: resource energy status; energy efficiency per slice; energy efficiency of the next generation (NG) radio access network (RAN) (NG-RAN) node; energy consumption of the fifth generation (5G) core network (5GC); energy consumption of the NG-RAN; energy consumption of the NG RAN node; traffic load trend of the cell; energy saving recommendations for the NG-RAN; or energy saving recommendations for the 5GC.

[0496] Example A35 includes the method described in Example A34 and / or any other example herein, wherein the resource energy status is used to indicate the energy information of a network function (NF) instance corresponding to an NF ID or NF set ID, and the resource energy status includes: NF ID; NF energy status; NF energy saving level; NF energy efficiency; NF energy consumption; or NF energy saving recommendations.

[0497] Example A36 includes the method described in Example A31 and / or any other example herein, wherein the energy information analysis is obtained based on a subscription service or a notification service.

[0498] Example A37 includes the method described in Example A31 and / or any other example herein, wherein the energy information analysis request includes an Nnwdaf_AnalyticsSubscription subscription, and the energy information analysis response includes an Nnwdaf_AnalyticsSubscription notification; or the energy information analysis request includes an Nnwdaf_AnalyticsInfo request, and the energy information analysis response includes an Nnwdaf_AnalyticsInfo response.

[0499] Example A38 includes the method described in Example A31 and / or any other example herein, wherein the energy information analysis includes energy efficiency data at the network level, user equipment (UE) level, UE group level, network slice level, or protocol data unit (PDU) session level.

[0500] Example A39 includes the method described in Example A31 and / or any other example herein, and further includes: encoding a network function (NF) load analysis request for transmission to the NWDAF; and decoding an NF load analysis response received from the NWDAF in response to the NF load analysis request to obtain the NF load analysis.

[0501] Example A40 includes the method described in Example A31 and / or any other example herein, and further includes: encoding a network function (NF) performance analysis request for transmission to the NWDAF; and decoding an NF performance analysis response received from the NWDAF in response to the NF performance analysis request to obtain the NF performance analysis.

[0502] Example A41 includes the method described in Example A31 and / or any other example herein, and further includes: encoding a data network (DN) service performance analysis request for transmission to the NWDAF; and decoding a DN service performance analysis response received from the NWDAF in response to the DN service performance analysis request to obtain the DN service performance analysis.

[0503] Example A42 includes the method described in any one of Examples A31 to A41 and / or any other example herein, wherein the method is applicable to NWDAF consumers.

[0504] Example A43 includes the method described in Example A42 and / or any other example herein, wherein the NWDAF consumer includes a fifth generation (5G) core network (5GC) network function (NF).

[0505] Example A44 includes the method described in Example A43 and / or any other example herein, wherein the 5GC NF includes an energy efficiency control function (EECF), a policy control function (PCF), a session management function (SMF), or an access and mobility management function (AMF).

[0506] Example A45 includes a method that includes: decoding an energy information analysis request received from a service consumer for energy information analysis; collecting data from a network function (NF), an operation, administration, and maintenance (OAM) entity / function, or an application function (AF) in response to the energy information analysis request; generating the energy information analysis based on the data; and encoding an energy information analysis response carrying the energy information analysis for transmission to the service consumer.

[0507] Example A46 includes the method described in Example A45 and / or any other example herein, wherein the energy information analysis request includes: an analysis ID indicating that the energy information analysis request is for the energy information analysis; an analysis report target indicating the object for which the energy information analysis is requested; analysis filtering information indicating the criteria or conditions that the reported energy information analysis needs to meet; or an analysis target period indicating the time interval of the energy information analysis.

[0508] Example A47 includes the method described in Example A46 and / or any other example herein, wherein the analysis filtering information includes: an energy saving level; renewable energy support; a single network slice selection assistance information (S-NSSAI) or a combination of S-NSSAI and a data network name (DNN) / data network access ID (DNAI); an application ID; a traffic type of interest; a maximum energy credit of a subscriber; a reporting threshold; or a preferred accuracy level.

[0509] Example A48 includes the method described in Example A45 and / or any other example herein, wherein the energy information analysis response includes: a resource energy state; energy efficiency per slice; energy efficiency of a next generation (NG) radio access network (RAN) (NG-RAN) node; power consumption of a fifth generation (5G) core network (5GC); power consumption of the NG-RAN; power consumption of an NG RAN node; a traffic load trend of a cell; an energy saving recommendation for the NG-RAN; or an energy saving recommendation for the 5GC.

[0510] Example A49 includes the method described in Example A48 and / or any other example herein, wherein the resource energy state is used to indicate energy information of a network function (NF) instance corresponding to an NF ID or an NF set ID, and the resource energy state includes: an NF ID; an NF energy state; an NF energy saving level; an NF energy efficiency; an NF power consumption; or an NF energy saving recommendation.

[0511] Example A50 includes the method described in Example A45 and / or any other example herein, wherein the energy information analysis request includes an Nnwdaf_AnalyticsSubscription subscription, and the energy information analysis response includes an Nnwdaf_AnalyticsSubscription notification; or the energy information analysis request includes an Nnwdaf_AnalyticsInfo request, and the energy information analysis response includes an Nnwdaf_AnalyticsInfo response.

[0512] Example A51 includes the method described in Example A45 and / or any other example herein, wherein the data collected from the OAM entity / function includes: energy saving status; power type of the NF; power consumption of the Next Generation (NG) Radio Access Network (RAN) (NG-RAN) node; power consumption of the NG-RAN; power consumption of the Fifth Generation (5G) Core Network (5GC) NF; power consumption of the 5GC; energy efficiency per slice; energy efficiency of the NG-RAN node; energy efficiency of the 5GC NF; traffic load trend of the cell; traffic prediction of the network slice; energy saving suggestions for the NG-RAN; energy saving suggestions for the 5GC; energy saving suggestions for the NF; or energy saving level of the NF.

[0513] Example A52 includes the method described in Example A45 and / or any other example herein, wherein the data collected from the AF includes: application ID; User Equipment (UE) ID; application server instance; IP filtering information; uplink (UL) / downlink (DL) performance data; or timestamp.

[0514] Example A53 includes the method described in Example A45 and / or any other example herein, wherein the energy information analysis includes energy efficiency data at the network level, User Equipment (UE) level, UE group level, network slice level, or Protocol Data Unit (PDU) session level.

[0515] Example A54 includes the method described in Example A45 and / or any other example herein, further comprising: decoding an NF load analysis request for NF load analysis received from the service consumer; collecting data from the NF, the OAM entity / function, or the AF in response to the NF load analysis request; generating the NF load analysis based on the data; and encoding an NF load analysis response carrying the NF load analysis for transmission to the service consumer.

[0516] Example A55 includes the method described in Example A45 and / or any other example herein, and further includes: decoding an NF performance analysis request for NF performance analysis received from the service consumer; collecting data from the NF, the OAM entity / function, or the AF in response to the NF performance analysis request; generating the NF performance analysis based on the data; and encoding an NF performance analysis response carrying the NF performance analysis for transmission to the service consumer.

[0517] Example A56 includes the method described in Example A45 and / or any other example herein, and further includes: decoding a DN service performance analysis request for data network (DN) service performance analysis received from the service consumer; collecting data from the NF, the OAM entity / function, or the AF in response to the DN service performance analysis request; generating the DN service performance analysis based on the data; and encoding a DN service performance analysis response carrying the DN service performance analysis for transmission to the service consumer.

[0518] Example A57 includes the method described in Example A45 and / or any other example herein, wherein the service consumer includes a network data analytics function (NWDAF) consumer.

[0519] Example A58 includes the method described in Example A57 and / or any other example herein, wherein the NWDAF consumer includes a fifth generation (5G) core network (5GC) network function (NF).

[0520] Example A59 includes the method described in Example A58 and / or any other example herein, wherein the 5GC NF includes an energy efficiency control function (EECF), a policy control function (PCF), a session management function (SMF), or an access and mobility management function (AMF).

[0521] Example A60 includes the method described in any one of Examples A45 to A59 and / or any other example herein, wherein the method is applicable to a network data analytics function (NWDAF).

[0522] Example A61 includes an apparatus, the apparatus including components for performing the method described in any one of Examples A31 to A44.

[0523] Example A62 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing circuit, cause the processing circuit to perform the method described in any one of Examples A31 to A44.

[0524] Example A63 includes a device that includes components for performing the method according to any one of Examples A45 to A60.

[0525] Example A64 includes a computer-readable medium storing instructions that, when executed by a processing circuit, cause the processing circuit to perform the method according to any one of Examples A45 to A60.

[0526] Example B1 includes a device comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: obtain an energy profile of a user equipment (UE) from a unified data management (UDM); obtain energy-related policy information for the UE from a policy control function (PCF); evaluate the energy profile of the UE and the energy-related policy information to generate a session and policy evaluation result; and encode the session and policy evaluation result for transmission to a session management function (SMF) for session establishment, wherein the memory is configured to store the energy profile of the UE or the energy-related policy information for the UE.

[0527] Example B2 includes the device according to Example B1 and / or any other example herein, wherein the processor circuit is further configured to: evaluate the energy profile of the UE and the energy-related policy information based on network conditions and energy consumption metrics.

[0528] Example B3 includes the device according to Example B2 and / or any other example herein, wherein the network conditions include: network load, time of day, or a given network event.

[0529] Example B4 includes the device according to Example B1 and / or any other example herein, wherein the session and policy evaluation result includes an energy-saving recommendation for modifying parameters of the session.

[0530] Example B5 includes the device according to Example B1 and / or any other example herein, wherein the processor circuit is further configured to: obtain an energy profile of a network function (NF) from a network repository function (NRF); and evaluate the energy profile of the UE, the energy profile of the NF, and the energy-related policy information to generate the session and policy evaluation result.

[0531] Example B6 includes the device according to Example B5 and / or any other example herein, wherein the energy profile of the NF includes: average energy consumption of the NF, energy state of the NF, or energy-saving level of the NF.

[0532] Example B7 includes the apparatus described in Example B1 and / or any other example herein, wherein the energy profile of the UE includes a maximum energy credit limit associated with the UE.

[0533] Example B8 includes the apparatus described in Example B1 and / or any other example herein, wherein the energy-related policy information is based on network conditions.

[0534] Example B9 includes the apparatus described in Example B8 and / or any other example herein, wherein the network conditions include: network load, time of day, or a given network event.

[0535] Example B10 includes the apparatus described in Example B1 and / or any other example herein, wherein the energy-related policy information includes: an energy usage threshold for the NF, an energy saving state, a subscriber's energy credit, an energy-efficient route, a restricted maximum data rate, or adaptive mobility management information.

[0536] Example B11 includes the apparatus described in Example B1 and / or any other example herein, wherein the processor circuit is further configured to: obtain the energy profile of the UE from the UDM in response to a registration notification from the Access and Mobility Management Function (AMF).

[0537] Example B12 includes the apparatus described in any one of Examples B1 to B11 and / or any other example herein, and the apparatus is applicable to an Energy Efficiency Control Function (EECF).

[0538] Example B13 includes an apparatus, comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: obtain an energy profile of a User Equipment (UE) from an Access and Mobility Management Function (AMF); obtain energy-related policy information for the UE from a Policy Control Function (PCF); generate session and routing configuration information based on the energy profile of the UE and the energy-related policy information; and cause the session and routing configuration information to be transmitted to a User Plane Function (UPF) to establish a session, wherein the memory is used to store the energy profile of the UE and the energy-related policy information.

[0539] Example B14 includes the apparatus described in Example B13 and / or any other example herein, wherein the processor circuit is further configured to: generate the session and routing configuration information based on network conditions and energy consumption metrics.

[0540] Example B15 includes the apparatus described in Example B14 and / or any other example herein, wherein the network conditions include: network load, time of day, or a given network event.

[0541] Example B16 includes the apparatus described in Example B13 and / or any other example herein, wherein the session and routing configuration information includes: bandwidth management information, routing adjustment information, or quality of service (QoS) enforcement information.

[0542] Example B17 includes the apparatus described in Example B13 and / or any other example herein, wherein the processor circuit is further configured to: obtain an energy profile of a network function (NF) from a network repository function (NRF) or the AMF; and generate the session and routing configuration information based on the energy profile of the UE, the energy profile of the NF, and the energy-related policy information.

[0543] Example B18 includes the apparatus described in Example B17 and / or any other example herein, wherein the energy profile of the NF includes: the average energy consumption of the NF, the energy state of the NF, or the energy saving level of the NF.

[0544] Example B19 includes the apparatus described in Example B13 and / or any other example herein, wherein the energy profile of the UE includes a maximum energy credit limit associated with the UE.

[0545] Example B20 includes the apparatus described in Example B13 and / or any other example herein, wherein the energy-related policy information is network-condition based.

[0546] Example B21 includes the apparatus described in Example B20 and / or any other example herein, wherein the network conditions include: network load, time of day, or a given network event.

[0547] Example B22 includes the apparatus described in Example B13 and / or any other example herein, wherein the energy-related policy information includes: an energy usage threshold for the NF, an energy saving state, a subscriber's energy credit, energy-efficient routing, limiting the maximum data rate, or adaptive mobility management information.

[0548] Example B23 includes the apparatus described in Example B13 and / or any other example herein, wherein the processor circuit is further configured to: obtain the energy profile of the UE as part of the registration process of the UE.

[0549] Example B24 includes the apparatus described in any one of Examples B13 to B23 and / or any other example herein, and the apparatus is applicable to a session management function (SMF).

[0550] Example B25 includes a method comprising: obtaining an energy profile of a user equipment (UE) from a unified data management (UDM); obtaining energy-related policy information for the UE from a policy control function (PCF); evaluating the energy profile of the UE and the energy-related policy information to generate a session and policy evaluation result; and encoding the session and policy evaluation result for transmission to a session management function (SMF) for session establishment.

[0551] Example B26 includes the method as described in Example B25 and / or any other example herein, further comprising: evaluating the energy profile of the UE and the energy-related policy information based on network conditions and energy consumption metrics.

[0552] Example B27 includes the method as described in Example B26 and / or any other example herein, wherein the network conditions include: network load, time of day, or a given network event.

[0553] Example B28 includes the method as described in Example B25 and / or any other example herein, wherein the session and policy evaluation result includes energy-saving suggestions for modifying parameters of the session.

[0554] Example B29 includes the method as described in Example B25 and / or any other example herein, further comprising: obtaining an energy profile of a network function (NF) from a network repository function (NRF); and evaluating the energy profile of the UE, the energy profile of the NF, and the energy-related policy information to generate the session and policy evaluation result.

[0555] Example B30 includes the method as described in Example B29 and / or any other example herein, wherein the energy profile of the NF includes: average energy consumption of the NF, energy state of the NF, or energy-saving level of the NF.

[0556] Example B31 includes the method as described in Example B25 and / or any other example herein, wherein the energy profile of the UE includes a maximum energy credit limit associated with the UE.

[0557] Example B32 includes the method as described in Example B25 and / or any other example herein, wherein the energy-related policy information is based on network conditions.

[0558] Example B33 includes the method as described in Example B32 and / or any other example herein, wherein the network conditions include: network load, time of day, or a given network event.

[0559] Example B34 includes the method described in Example B25 and / or any other example herein, wherein the energy-related policy information includes: an energy usage threshold for the NF, an energy-saving state, a subscriber's energy credit, energy-effici...

Claims

1. An apparatus, comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: encode a session energy assessment request for transmission to a service producer, the session energy assessment request including a session ID of a session and energy policy information for the session; decode a session energy assessment response received from the service producer in response to the session energy assessment request, the session energy assessment response including session modification suggestions for parameters of the session to optimize energy usage; and perform establishment of the session based on the session modification suggestions, and wherein the memory is used to store the session ID and the energy policy information of the session.

2. The device according to claim 1, wherein The session energy assessment request further includes an energy profile of a user equipment (UE) or a group of UEs associated with the session, and the parameters of the session are associated with the UE or the group of UEs.

3. The apparatus according to claim 2, wherein, The energy profile of the UE or the group of UEs includes a permanent equipment identifier (PEI), a maximum energy credit limit, or a group identifier.

4. The device according to claim 2, wherein The processor circuit is further configured to: obtain session management subscription data from a unified data management (UDM), the session management subscription data including an energy saving indication for the session; and obtain the energy profile of the UE or the group of UEs from the UDM in response to the energy saving indication for the session.

5. The apparatus according to claim 4, wherein The processor circuit is further configured to: encode a Nudm_SDM_Get request for transmission to the UDM; and decode a Nudm_SDM_Get response received from the UDM in response to the Nudm_SDM_Get request to obtain the energy profile of the UE or the group of UEs.

6. The device according to claim 1, wherein The session modification suggestions include: adjusted quality of service (QoS) parameters, or information regarding user plane function (UPF) selection and configuration with high energy-efficient data processing.

7. The apparatus according to claim 6, wherein, The information regarding UPF selection and configuration with high energy-efficient data processing includes: bandwidth management information, data routing adjustment information, or QoS enforcement information.

8. The apparatus according to claim 1, wherein The session modification suggestions are based on: historical energy consumption data of a network function (NF) associated with the session, the average energy consumption of the NF, or the predicted energy consumption of the NF.

9. The device according to claim 1, wherein, The session energy assessment request further includes an energy profile of a network function (NF) associated with the session, and the parameters of the session are associated with the NF.

10. The device according to claim 9, wherein, The processor circuit is further configured to: obtain the energy profile of the NF from a network repository function (NRF).

11. The device according to claim 1, wherein, The processor circuit is further configured to: encode a policy control request for transmission to a policy control function (PCF), the policy control request including an energy saving indication; and decode a policy control response received from the PCF in response to the policy control request to obtain the energy policy information.

12. The apparatus according to claim 11, wherein, The policy control request further includes: an energy profile of a user equipment (UE) or a group of UEs associated with the session, or an energy profile of a network function (NF) associated with the session.

13. The device according to claim 12, wherein, The energy policy information includes: a maximum allowable energy credit of the UE or the group of UEs, an energy usage threshold of the NF, an energy saving status, an energy saving level of the UE or the group of UEs, an energy saving level of the NF, an energy-efficient routing, a restricted maximum data rate, or an adaptive mobility management information.

14. The device according to claim 1, wherein, The processor circuit is further configured to: select the service producer based on single network slice selection assistance information (S-NSSAI).

15. The device according to claim 1, wherein, The processor circuit is further configured to: provide the session modification suggestion to a user plane function (UPF) to establish the session.

16. The device according to claim 1, wherein The session includes a protocol data unit (PDU) session, and the session ID includes a PDU session ID.

17. The apparatus according to claim 1, wherein The service producer includes an energy efficiency control function (EECF).

18. The device according to any one of claims 1 to 17, wherein The apparatus is applicable to a session management function (SMF).

19. An apparatus, comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: decode a session energy assessment request received from a service consumer, the session energy assessment request including a session ID of a session and energy policy information for the session; and in response to the session energy assessment request, encode a session energy assessment response for transmission to the service consumer for establishment of the session, the session energy assessment response including a session modification suggestion for parameters of the session to optimize energy usage, and wherein the memory is used to store the session ID and the energy policy information of the session.

20. The apparatus according to claim 19, wherein the apparatus is applicable to an energy efficiency control function (EECF).

Images