Methods and apparatus for collaborative network data analytics and predictions to support network energy savings

Abstract

Methods and apparatus for collaborative network data analytics and predictions are described. A method, implemented in a network node, includes receiving a request for energy efficiency network data analytics for an application function. The network node sends a subscription request to NFs in a communication path between a WTRU and a user plane function (UPF) to monitor events related to the request for the energy efficiency network data analytics. The network node receives notifications from the NFs. The notifications include reports of energy consumption measurements, on the communication path, from the NFs. The network node sends a consolidated report of the energy consumption measurements to the application function.

Description

METHODS AND APPARATUS FOR COLLABORATIVE NETWORK DATA ANALYTICS AND PREDICTIONS TO SUPPORT NETWORK ENERGY SAVINGSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 541 ,184, filed September 28, 2023, and U.S. Provisional Application No. 63 / 541 ,194, filed September 28, 2023, the contents of which are incorporated herein by reference.BACKGROUND

[0002] In 5G New Radio (NR), a Network Data Analytics Function (NWDAF) is defined, for example, for using network data analytics to drive automation. To do so, the NWDAF may request energy-efficiency-related saving analytics and predictions from Operations, Administration and Maintenance (OAM) or, more specifically, from the Management Data Analytics Function (MDAF), using a subscription and / or notification-based approach, as part of the input data the NWDAF uses to generate network data analytics for Observed Service Experience. Energy savings may be achieved by activating energy saving mode for NR capacity booster cells or network functions (NFs), such as the user plane function (UPF). The MDAF may collect data in the form of measurements from Performance Management Functions, from both the Access Network (AN) and the Core Network (ON), including Minimization of Drive Tests (MDT), Radio Link Failure (RLF), and Quality of Experience (QoE) reports, as well as service experience from Application Functions (AFs). The MDAF may provide recommendations in the form of statistics and / or predictions, including root cause analysis and recommendations (e.g., whether the energy saving mode of a network element should change). The consumer of MDAF data analytics may use the analytics and recommendations, along with policies and load information, to make decisions, such as reducing power consumption.SUMMARY

[0003] Methods and apparatus for collaborative network data analytics and predictions are described. A method, implemented in a network node, includes receiving a request for energy efficiency network data analytics for an application function. The network node sends a subscription request to NFs in a communication path between a WTRU and a user plane function (UPF) to monitor events related to the request for the energy efficiency network data analytics. The network node receives notifications from the NFs. The notifications include reports of energy consumption measurements, on the communication path, from the NFs. The network node sends a consolidated report of the energy consumption measurements to the application function.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0005] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0006] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0007] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0008] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0009] FIG. 2 is a system diagram showing an example of Horizontal Federated Learning (HFL) among multiple NWDAFs;

[0010] FIG. 3 is a system diagram of an example mapping of energy efficiency event monitoring;

[0011] FIG. 4 is a signal diagram of an example of network data analytics for energy efficiency;

[0012] FIG. 5 is a signal diagram illustrating how an energy efficient application may interact with the 3GPP network to inquire about how much energy would be needed to run the application over the 3GPP network; and

[0013] FIG. 6 is a signal diagram showing energy efficient network slice services.DETAILED DESCRIPTION

[0014] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0015] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0016] The com munications systems 100 may also incl ude a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0017] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0018] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0019] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

[0020] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0021] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR.

[0022] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0023] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0024] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet anotherembodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0025] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0028] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0030] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0031] Although the transmit / receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0032] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0033] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, andstore data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0034] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li- ion), etc.), solar cells, fuel cells, and the like.

[0035] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0036] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0037] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0038] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0039] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0040] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 10, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0041] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0042] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0043] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0044] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0045] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IPmultimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0046] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0047] In representative embodiments, the other network 112 may be a WLAN.

[0048] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0049] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0050] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0051] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0052] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0053] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all ST As in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0054] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0055] FIG. 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0056] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0057] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0058] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0059] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access andMobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0060] The CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0062] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0063] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0064] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102cmay be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0065] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0066] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communications.

[0067] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0068] New requirements have been defined to enable energy efficient service delivery while maintaining a minimum level of performance. These requirements can be categorized as follows: energy efficiency as a service, operator defined energy efficiency policies, and energy consumption exposure. The entity requesting services from a 5G system, such as an AF, in the form of communication resources, should be able to specify the trade-off between energy efficiency and service performance that the entity is willing to accept when requesting a particular service for a particular user or group of users at a specific time and location. Furthermore, mobile network operators should be able to control how these services are delivered, such as: through operator specific policies that enable them to set energy consumption limits or quotas; on a per subscription basis, delivering energy efficient services, without impacting the operation of the system; and / or requiring re-deployment or decommissioning of network elements. Finally, network exposure mechanisms maybe enhanced to expose network energy consumption information, at different granularities, including network slices, WTRU level, PDU Session level, and QoS flow level.

[0069] Other NFs may indirectly request energy-efficiency-related information from the NWDAF but only as part of an Observed Service Experience network data analytics procedure. The Energy Efficiency-related information may be limited to the cell energy saving state, and the NWDAF may use this information to provide observed service experience network data analytics per user plane (UP) path.

[0070] 5GS supports Horizontal Federated Learning (HFL) amongst multiple NWDAFs, generating analytics for the same parameter types or feature sets, but for different samples. FIG. 2 is a system diagram 200 showing an example of HFL among multiple NWDAFs.

[0071] The system diagram 200 illustrated in FIG. 2 includes a consumer 210, a server NWDAF 220, one or more client NWDAFs (3 client NWDAFs 230a, 230b, and 230c are illustrated in FIG. 2), a Network Repository Function (NRF) 240 and an NF data provider 250. The server NWDAF 220 may generate network data analytics to derive the QoE features, in a particular Network Slice feature for a group of WTRU samples. The server NWDAF 220 may host a Model Training Logical Function (MTLF), which may be responsible for training Machine Learning (ML) models for the one or more consumers 210, each of which may contain an Analytics Logical Function (AnLF) that just supports inference. An NWDAF-AnLF may be a consumer of ML model training services provided by the NWDAF-MTLF, which may be the producer of these services.

[0072] The consumer 210 may establish a model training subscription (255) with the Server NWDAF 220. The Server NWDAF 220 may use HFL, for example, to request help from one or more Client NWDAFs, such as the Client NWDAFs 230a, 230b, 230c illustrated in FIG. 2 that can train ML models with their own data. In the example illustrated in FIG. 2, the Server NWDAF 220 may establish a model training subscription (260) with each of the Client NWDAFs 230a, 230b, 230c. It should be noted that the NWDAF-AnLF may not be aware of whether HFL is used or not when the Server NWDAF 220 trains the requested ML model. When HFL is used, there is an NWDAF-MTLF defined as a server (i.e., the Server NWDAF 220) and multiple NDWDAF- MTLFs defined as clients (i.e., the Client NWDAFs 230a, 230b, 230c). As mentioned above, these clients may train ML models using their own data on the same feature set.

[0073] To train ML models, the client NWDAFs 230a, 230b, 230c may collect data (270), for example from the NRF 240 and / or the NF Data Provider 250, train the requested ML mode, and return results (280) to the Server NWDAF 220. The Server NWDAF 220 may then perform model aggregation (285) by aggregating the results received from the Client NWDAFs 230a, 230b, 230c. The Server NWDAF 220 may send the aggregated model information to the Client NWDAFs 230a, 230b, 230c (290). The Client NWDAFs 230a, 230b, 230c may update their local ML model using the received aggregated model information.

[0074] Mechanisms, methods and procedures are described herein that may enable Application Servers (ASs) and WTRUs to request services and resources using energy efficiency and to request specific QoS handling for specific application traffic, under certain energy efficiency constraints. Performance indicators andoperator policies may also be defined and used as criteria for the allocation of resources and delivery of communication services. Mechanisms, methods and procedures are also described herein that may expose service specific energy consumption or levels of energy efficiency. In some embodiments, new mechanisms, methods and procedures are described that may enable network entities, such as an AF, an, or a WTRU, to obtain energy serving analytics and predictions, by collaborating in the generation of these analytics, such as through the employment of Vertical Federated Learning (VFL) -based techniques across multiple network entities.

[0075] An AF may avail itself of 5GS network capability exposure and request event notification based on monitored network capabilities and performance or based on network data analytics produced by the 5GS using Network Data Analytics Frameworks described herein. The embodiments described herein may extend this network exposure framework by enabling independent energy efficiency / usage event reporting for monitoring network data analytics-based events and predictions.

[0076] As mentioned above, NFs can indirectly request energy- efficiency-related information from the NWDAF but only as part of an observed service experience network data analytics procedure. Embodiments described herein may extend 5GS external exposure of network capabilities with energy consumption information.

[0077] Energy consumption information may be reported per Application ID, per network slice (e.g., per Single - Network Slice Selection Assistance Information (S-NSSAI)), per Data Network Name (DNN), per certain geographical location, per WTRU, per group of WTRUs, per QoS Flow, per PDU Session and / or per AN (e.g., AN type or specific AN node, such as a RAN identifier). Different reporting mechanisms may be used when exposing network capabilities externally. For example, external network exposure via monitoring events and external network exposure via analytics reporting may be extended. Network exposure via monitoring can be extended by enabling monitoring of energy consumption on network entities that participate in the delivery of communication services for a particular application. Network exposure via network data analytics can be extended by enabling statistics and prediction of energy consumption on network entities that participate in the delivery of communication services for a particular application.

[0078] In some embodiments described herein, a Network Exposure Function (NEF) may receive from the Application Function (AF) an Energy Efficiency attribute indicating the rated efficiency of an application over certain conditions / criteria, such as for one or more WTRUs, per Session, per DNN, per Slice, based on location and time, and / or energy sources. The NEF may derive monitoring events based on the Energy Efficiency attribute (EE-Attribute) provided by the AF and the context in which these measurements should be taken. The NEF may filter Energy Efficiency monitoring information and correlate the notifications from different network entities in the communication path between the WTRU and the UPF and send a consolidated notification / energy monitoring report filtered based on the EE-Attribute.

[0079] An AF, or any NF in the 5GS, may request exposure of 5GS system capabilities, such as exposure of capabilities of NFs executing 5GS logic, via a Network Exposure Function (NEF). Monitoring events may be linked to WTRU behavior (or behavior of a group of WTRUs), and they may be reported when this behavior changes. Monitoring events may be added that may reflect energy consumption based on a particular context. For example, energy consumption may be monitored for WTRUs at a particular location when the throughput goes over a certain threshold. Thus, the AF may request event monitoring for a WTRU or group of WTRUs to determine, for example, when the QoE, or QoS performance indicators, are below a certain threshold, for a WTRU or a group of WTRUs operating under certain energy efficiency parameters.

[0080] To this end, the AF may include an energy efficiency attribute or class, which may, for example, be similar to the energy saving classifications given to house appliances and indicate to the NEF that this attribute should be applied when monitoring QoS performance indicators, QoEs, mobility patterns, or high data volumes, for a WTRU or a group of WTRUs. In addition, the AF may indicate the network slice (e.g., the S-NSSAI) and DNN, or even a specific DNAI, or a geographical location, where these measurements should apply. This energy attribute may be associated with specific CO2 emissions, or it may be associated with clean energy sources. The Energy Classification attribute provided by the AF may indicate to the NEF that monitoring should consider the energy source (e.g., renewable or CO2 based).

[0081] The NEF may take the energy source into consideration when selecting the energy consumption thresholds to use when sending the event monitoring request. The actual measurement may be obtained from the 0AM system, or, for a more specific example, the MDAF. However, the NEF may provide a different energy efficiency threshold if the network entity from which energy consumption is measured is powered using a specific energy source type. For example, the threshold for energy consumption for the UPF for a particular application may be given as a percentage of the total contribution in terms of used power (kW / h), temperature and humidity, over a period of time, and this threshold may be different depending on the energy source (e.g., CO2 or renewable).

[0082] Additionally or alternatively, the Energy Efficiency attribute may indicate the maximum expected contribution that a WTRU or group of WTRUs running a specific Application may incur during or at a specific period of time. The maximum expected contribution may be measured, for example, as a percentage of the total energy consumption (e.g., Watts / time unit) on the communication path. Alternatively or additionally, the energy attribute may be associated to an energy credit, or maximum credit limit, such as defined, for example, in 3GPP TR 22.882, Study on Energy Efficiency as Service Criteria (V 19.0.0).

[0083] FIG. 3 is a signal diagram of an example mapping of energy efficiency event monitoring. In the example illustrated in FIG. 3, an AF 310 subscribes to Energy Efficiency event monitoring, for example by sending an event exposure subscribe request message 315 to an NEF 320. The AF 310 may provide, in the event exposure subscribe request message 315, either a new Event ID and a context, or an EE-Attribute (e.g., as a scalar) and may also provide the scope and / or context for which energy consumption monitoring shouldtake place (e.g., low / medium / high handover rate, QoE threshold, QoS parameter values, and / or low / medium / high data volume or DNAI when carrying traffic for a particular application identified by an Application ID). The EE-Attribute may also be associated with an EE credit or EE credit limit.

[0084] The NEF 320 may derive and / or map the EE-Attribute onto specific monitoring event requests (325) or may use the Event ID corresponding to Energy Efficiency monitoring provided by the AF 310 in the event exposure subscribe request 315. For example, the EE-Attribute may require event reporting from NFs (e.g., SMF and / or UPF) and / or from the RAN. The NEF 320 may derive the Event ID corresponding to the Event Reporting request for NFs that are contributing to the overall Energy Consumption on the path.

[0085] The NEF 320 may subscribe to one or more received events identified by the Event IDs derived in (325) by sending an event exposure subscribe request message 335 to a UDM 340. The UDM 340 may authorize event monitoring and forward the event exposure subscribe request (345) to relevant NFs, such as the NF 350 illustrated in FIG. 3. For example, to collect energy consumption measurements, the UDM 340 may send exposure subscriptions to the SMF, the UPF and the RAN. In some embodiments, this may be done through the 0AM interface (e.g., MDA). The UDM may choose the NFs to subscribe to based on the Event ID requested by the NEF 320.

[0086] The relevant NFs may acknowledge the Event Monitoring subscription. For example, the NF 350 illustrated in FIG. 3 may send an event exposure subscribe response 355 to the UDM 340, which may forward the event exposure subscribe response to the NEF 320 (360). The NEF 320 may forward the event exposure subscribe response to the AF 310 (365).

[0087] The relevant NFs may detect an event and send an event report to the NEF 320. Byway of example, the NF 350 may send an event report to the UDM 340, which may send an event exposure subscribe notify message 370 to the NEF 320. The NEF 320 may correlate the notifications from different network entities in the communication path between the WTRU and the UPF (375). The NEF 320 may send a consolidated notification, filtered based on the EE-Attribute and the context provided by the AF 310 in the event exposure subscribe request message 315. For example, the NEF 320 may consider notification within a time period, coming from multiple AFs and the AN, to derive an overall threshold, such as a DNAI and an S-NSSAI / DNN combination. Furthermore, the NEF 320 may provide recommendations to the AF 310 (e.g., in the form of one or more suggested DNAI or S-NSSAI), which can be used to fulfill EE credit limits, a different time period when the application may be running while meeting EE targets, and / or a new Slice / Service Type and Slice Differentiator (SST / SD).

[0088] The NEF 320 may store information from different NFs 350 and ANs (not shown in FIG. 3) correlated with time stamps (380). The NEF 350 may provide the consolidated event report and recommendations (385) derived in (375). The AF 310 may use the recommendation provided by the NEF 320 to move to a different DNAI and fulfill the EE requirement as given by the EE-Attribute.

[0089] An AF (or any NF in the 5GS) may request exposure of 5GS system capabilities (e.g., exposure of capabilities of NFs executing 5GS logic) via an NEF. Network data analytics may be added that may reflect the energy consumption, considering energy consumption for WTRUs at a particular location when the throughput goes over a certain threshold. Thus, the AF may request network data analytics, in the form of statistics and predictions for a WTRU or group of WTRUs running a particular application, identified by an application identifier, and configured with a minimum QoS threshold to be fulfilled. The AF may also provide a specific location or a location in the form of, for example, a DNAI.

[0090] FIG. 4 is a signal diagram 400 of an example of network data analytics for energy efficiency. In the example illustrated in FIG. 4, the AF 410 subscribes to energy efficiency network data analytics by sending an event exposure subscribe request message 415 to an NEF 420, which may include an Analytics ID, which may indicate to the NEF 420 that the AF 410 is energy efficient. In addition, the event exposure subscribe request message 415 may indicate whether network data analytics should be conducted on network entities that are powered with CO2 energy sources or renewable energy sources and a possible location where this measurement may take place (e.g., by indicating the DNAI, S-NSSAI / DNN combination). The AF may also provide minimum requirements for energy consumption at the location and time (e.g., in the form of an energy efficient credit or an EE-Attribute).

[0091] The event exposure subscribe request message 415 may indicate what activity should be monitored. Examples of activity that should be monitored may be all activity related to a WTRU, all activity related to a WTRU’s PDU Session, activity related to one or more traffic flows, all activity related to a particular WTRU or application, or activity related to one or more specific network slice (e.g., S-NSSAI). When monitoring is per WTRU, the AF 410 may provide a WTRU ID. When monitoring is per PDU Session, the AF 410 may provide a WTRU ID and a DNN. When monitoring is per traffic flow, the AF 410 may provide a WTRU ID and flow descriptors (i.e. 5-Tuples). When monitoring is per WTRU application, the AF 410 may provide a WTRU ID and an application ID.

[0092] The event exposure subscribe request 415 may indicate what event or events related to the activity should trigger a notification. For example, the event exposure subscribe request 415 may indicate that a notification should be sent to the AF 410 if the total energy consumption of the activity exceeds a threshold over a time period. The threshold and time period may also be provided in the event exposure subscribe request 415.

[0093] The NEF 420 may provide the cell IDs of the geographical location provided by the AF 410 and forward the event exposure subscribe request to an NWDAF 430 (425). The NEF 420 may select an appropriate NWDAF, for example based on the location provided by the AF 410 in the event exposure subscribe request 415. The NWDAF 430 may subscribe to energy efficiency events from NFs (e.g., NF 450 illustrated in FIG. 4) and an MDA 440 to collect measurements over a validity period in a certain location. In the example illustrated in FIG. 4, the NWDAF 430 sends an event exposure subscribe request 435 to the MDA 440 and another eventexposure subscribe request 455 to the NF 450. The NFs can be one or more network function, such as an AMF, a PCF, and a UPF, which are described in more detail above.

[0094] By way of example, if the monitoring request was to monitor activity related to a WTRU’s PDU session, the NWDAF 430 may interact with a BSF and UDM to determine the UPF and PCF that serves the PDU Session. The NWDAF 430 may then subscribe to the UPF to monitor events related to the PDU session. For another example, if the monitoring request was to monitor activity related to a traffic flow of a WTRU, the NWDAF 430 may interact with a BSF and UDM to determine the UPF and PCF that serves the PDU Session. The NWDAF 430 may then subscribe to the UPF to monitor events related to the traffic flow. For another example, if the monitoring request was to monitor activity related to a WTRU’s activity, the NWDAF 430 may interact with a UDM to determine the AMF that serves the WTRU. The NWDAF 430 may then subscribe to the AMF to monitor events related to the WTRU transitioning between the CM-CONNECTED and CM-IDLE states. For another example, if the monitoring request was to monitor activity related to a WTRU’s activity in an Application, the NWDAF 430 may interact with a UDM to determine the PCF that serves the WTRU for AM Policies. The PCF may then obtain the URSP Rules that are configured in the WTRU in order to determine the PDU Session that serves the WTRU of the application. The NWDAF 430 may then subscribe to the UPF to monitor events related to the traffic flow. For another example, if the monitoring request was to monitor activity related to a WTRU’s network slice activity, the NWDAF 430 may interact with a UDM to determine the network slices serving the WTRU. The NWDAF 430 may then subscribe to the MDAF to monitor events related to the network slice energy consumption (e.g., the Core Network part, the Access Network part, or both). The NWDAF 430 may receive notifications from the MDAF related to the monitored activity related to the network slice serving the WTRU and the WTRU’s application.

[0095] The NWDAF 430 may receive notifications from network functions, such as the AMF, PCF, and UPF, related to the monitored activity. In the example illustrated in FIG. 4, the NWDAF 430 receives an event exposure subscribe notification 445 from the MDA440 (for example based at least in part on the event exposure subscribe request 435), and / or the NWDAF 430 receives another event exposure subscribe notification 460 from the NF 450 (for example, based at least in part on the event exposure subscribe request 455). The NWDAF 430 may associate an energy cost or metric with each event notification that it receives and may then use the cost of each event to derive an overall energy cost for the monitored event.

[0096] The NWDAF 430 may consolidate measurements from the events reported from different network entities and correlate time stamps and location (465). The NWDAF 430 may generate a consolidated energy consumption. The NWDAF may also provide a recommendation for, for example, using a different DNAI to meet energy efficiency requirements and using the Energy Efficiency Credit provided by the AF 410. This consolidation may also be done at the NEF 420. The measurements may include the overall energy cost for the monitored event. The overall energy cost for the monitored event may be an estimate that is derived by the NWDAF 430. It may be a prediction of future cost under the assumption that current WTRU behavior continues.

[0097] The NWDAF 430 may send an event exposure subscribe notify message 470 to the NEF 420. The event exposure subscribe notify message 470 may include energy efficiency measurements and / or the recommendation. If the event exposure subscribe notify message 470 is triggered because the estimated or predicted overall energy cost for the monitored event exceeds a threshold, the event exposure subscribe notify message 470 may also include recommended parameter values for the activity. For example, the event exposure subscribe notify message 470 may include a DNAI that can be used for the PDU Session and result in overall lower energy consumption. For example, the event exposure subscribe notify message 470 may include maximum data rates or assumed end to end latency values that may be used by the application flow and that will result in overall lower energy consumption.

[0098] The NEF 420 may send energy efficiency measurements and recommendations provided by the NWDAF 430, for example in the event exposure subscribe notification 470, to the AF 410, for example in the form of one or more suggested DNAI or S-NSSAI that can be used to fulfill EE credit limits, different times, or time periods, when the application may be running while meeting EE targets. In the example illustrated in FIG. 4, the NEF 420 sends an event exposure subscribe notification 475 to the AF 410, which may indicate this information. The AF 410 may take into account the recommendation provided by the NWDAF 430 and move to a different DNN, as indicated by the DNAI. The recommendation assumes that the UPF servicing the DNAI meets requirements for energy efficiency as requested by the AF 410.

[0099] The Application as described above may also be energy efficient and / or aware. An application or application server should be able to request information from the 3GPP network about how much energy is consumed for a particular application server. An application server may in some cases want to inquire about the energy required to run the application. A parallel can be drawn to searching for flights and carbon offsets being one of the parameters. By way of example, for an application providing QoS / QoE parameters and needing assistance from the 3GPP network in terms of how much energy will be used to run the application, the application may send QoE / QoS parameters to the 3GPP network. These parameters may include bit rate, throughput, and / or latency requirements. The application may invoke the API offered by the 3GPP network. The API response expected by the application may be energy usage for the particular application requirements.

[0100] FIG. 5 is a signal diagram 500 illustrating how an energy efficient application may interact with the 3GPP network to inquire about how much energy would be needed to run the application over the 3GPP network. The example illustrated in FIG. 5 is an example of how an NWDAF 530 may provide information to an AF 510 about future application layer activity. Alternatively, the PCF may provide information to an AF about future application layer activity. When the PCF provides information to an AF about future application layer activity, the information may be based on the PCF interacting with the NWDAF.

[0101] In the example illustrated in FIG. 5, the AF 510 invokes an API with a 3GPP NEF 520 indicating its desire to be energy efficient / aware. The AF 510 may do this by sending an application request 535 to the NEF 520. The API may request energy consumption information from the 3GPP network. The AF 510 may provide,for example in the application request 535, all the application parameters (e.g., QoS, QoE, and / or bit rate) to the 3GPP NEF 520. The AF 510 may also indicate that it is an energy efficient application. For example, the API may provide the network with a description of the planned application layer activity (e.g., bit rate and data volume), a value that is indictive of a desired energy consumption limit, a time window when the planned application layer activity should take place, the identity of the WTRU or WTRUs that will take part in the application layer activity, and the location of the WTRU or WTRUs that will take part in the application layer activity.

[0102] The NEF 520 may receive the application request 535 and send the message to the UDM / UDR to verify the request and get subscription parameters (540), which may include energy saving indications. This may additionally or alternatively occur during other portions of the process described below.

[0103] The NEF 520 may also request to receive energy analytics from the NWDAF 530 by, for example, sending a request 545 to receive energy analytics along with the parameters received from the AF 510. The NWDAF 530 may contact other network functions (550) in the core network, including, for example, the MDAF, 0AM, and / or RAN. The NWDAF 530 may provide the requested particular energy usage information to the NEF 520 by sending a response 555 to the energy estimate request, which may include information indicating the energy estimates.

[0104] The NEF 520 may receive the information from the NWDAF 530 (e.g., in the response 555) and / or from other core network function or functions. The NEF 520 may translate the received information into an energy usage impact. The NWDAF 530 or other core network functions may send a multitude of information to the NEF 520 regarding the particular application energy usage.

[0105] The NWDAF 530 may use the location information and WTRU identifiers that were included in the application request 535 to determine which network functions may serve the planned application layer activity (e.g. which RAN Node or Nodes, which AMF or AMFs and / or which UPF or UPFs). The NWDAF 530 may interact with the network functions to collect or derive predictions about utilization of the network functions in the time frame that was indicated by the AF 510 in the application request 535. The NWDAF 530 may then use the information in the application request 535 from the AF 510 to derive a prediction of the energy cost of the requested operation, a recommended time for performing the operation, a recommended maximum data rate for performing the operation, and / or a validity time that indicates how long the prediction or recommendation can be assumed to be valid for. The NWDAF 530 may provide multiple sets of information. For example, a first set of information and energy cost value may apply in a first time window and a second set of information and energy cost value may apply in a second time window.

[0106] The NEF 520 may reply back to the application function (560), responding as to how much energy would be needed by the application given its QoS / QoE requirements. The energy information may be given to the application function, and the units may be in watts, credits or other units of measuring energy efficiency. Based on the NEF’s reply, the AF 510 knows the energy usage based on its initial requirements. For example,the AF 510 may decide, as a trade-off, to lower the QoS requirements (e.g., bit rate) in order to meet its energy efficiency requirements. For example, the AF 510 may decide to not perform the operation in a certain time window because the energy cost will be too great.

[0107] A User may want to request services delivered under specific energy efficient conditions. Embodiments described herein introduce a new network slice / service type and slice differentiator to handle a WTRU request for connectivity via energy efficient network slices.

[0108] FIG. 6 is a signal diagram 600 showing energy efficient network slice services. In the example illustrated in FIG. 6, an application ID may be configured in a WTRU 610 to operate using an energy efficient network slice (615). The ASP may configure the WTRU 610, either over the air or via pre-configuration, with a slice / service type and a slice differentiator (SD) that indicate an energy efficient slice. The application may use the SD to signal the expected energy source, such as CO2 or renewable energy. The WTRU 610 may store a slice usage policy that may include energy efficient on demand or temporarily available S-NSSAIs associated to specific energy efficient applications.

[0109] The WTRU 610 may register with the system by, for example, sending a registration request 625 to an AMF 620. Based on the configuration in (615), the registration request 625 may indicate that the WTRU 610 is capable of handling energy efficient rules (e.g., WTRU route selection priority rules). The WTRU 610 may request an EE network slice by indicating the SST and SD relevant to the EE Network Slice. The WTRU 610 may base its request for an S-NSSAI on an association between an energy efficient application and an on demand energy efficient S-NSSAI. The WTRU 610 may, alternatively or in addition, use a temporarily available energy efficient S-NSSAI.

[0110] The AMF 620 may send a subscriber data registration request 635 to a U DM 630, which may request updating / creation of subscriber information regarding the SST and SD and may request a new session management capability indicating that the WTRU 610 may use URSP rules to direct traffic to a sponsored network slice. The AMF 620 may check an energy consumption level for the slice, such as at the WTRU level, PDU session level or slice level, before granting the WTRU 610 access to the network slice requested by the WTRU 610. The AMF 620 may get this information directly from the MDAF or through the NWDAF. The AMF 620, based on energy consumption predictions, may provide the WTRU 610 with energy consumption ratings for an on demand S-NSSAI, along with the validity time these ratings are valid. In addition, the validity time may be used for temporarily available network slices.

[0111] The UDM 630 may store SM capability and derive new charging characteristics (645), such as whether the WTRU 610 is charged using a sponsored approach through the EE network slice. The UDM 630 may notify the UDR 640 about the new sponsored service, for example by sending a subscriber data change notification 650 to the UDR 640. The UDR 640 may notify the PCF about the modification of the Policy Data (655) regarding sponsored charging of PDU sessions. The UDM 630 may confirm the creation / update of subscriber capabilities and EE network slice information by sending a subscriber data registration acceptmessage 660 to the AMF 620. The AMF 620 may store a new charging characteristic indicating EE based sponsored services (662). The AMF 620 may send a registration accept message 665 to the WTRU 610. The registration accept message 665 may indicate a new allowed energy efficient network slice and new URSP rules to the WTRU 610. The WTRU 610 may use the URSP rules to route EE sponsored traffic to a PDU Session supported by a EE Network slice (670). The WTRU 610 may establish a new PDU session based on the energy efficient S-NSSAI received in the registration accept message or route the data to an existing energy efficient PDU session.

[0112] An Application Service Provider (ASP) may negotiate different rates for subscribers that are willing to use low energy consumption resources across network entities to deliver communication services, possibly at a reduced performance, or as sponsored services. For example, a particular service, or a specific Application ID, may be sponsored and changed accordingly, for example by associating energy efficiency values to charging keys and sponsoring identities. Information about the energy source, such as whether the service is delivered using CO2 or renewable energy, can also be included when reporting usage information for a charging key associated with the application.

[0113] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A method, implemented in a network node, the method comprising: receiving a request for energy efficiency network data analytics for an application function; sending a subscription request to each of a plurality of network functions (NFs) in a communication path between a WTRU and a user plane function (UPF) to monitor events related to the request for the energy efficiency network data analytics; receiving notifications from the plurality of NFs, wherein the notifications comprise reports of energy consumption measurements, on the communication path, from the plurality of NFs; and sending a consolidated report of the energy consumption measurements to the application function.

2. The method of claim 1 , wherein the request for the energy efficiency network data analytics comprises at least one of an indication of a geographical location of the application function, an indication of a minimum energy requirement of the application at the location of the WTRU at a specified time, or an indication of whether the network data analytics are to be conducted using renewable energy resources or carbon dioxide (CO2) energy sources.

3. The method of claim 2, further comprising sending at least one recommendation to the application function of a different geographical location or a different time to run the application to meet the minimum energy requirement of the application.

4. The method of claim 3, wherein the geographical location and the different geographical location are specified as data network access identifiers (DNAIs) where the application resides.

5. The method of any one of claims 1-4, wherein the plurality of NFs comprise at least two of a management data analytics (MDA) function, a user plane function (UPF), an access and mobility management function (AMF), a session management function (SMF), a policy control function (PCF), a binding support function (BSF) and a network data analytics function (NWDAF).

6. The method of any one of claims 1-5, wherein the network node is one or both of a network exposure function (NEF) or a network data analytics function (NWDAF).

7. The method of any one of claims 1 -5, wherein the request for energy efficiency network data analytics further comprises a minimum quality of service (QoS) threshold.

8. A network node comprising:a transceiver; and a processor, wherein the transceiver and the processor are configured to: receive a request for energy efficiency network data analytics for an application function, send a subscription request to each of a plurality of network functions (NFs) in a communication path between a WTRU and a user plane function (UPF) to monitor events related to the request for the energy efficiency network data analytics, receive notifications from the plurality of NFs, wherein the notifications comprise reports of energy consumption measurements, on the communication path, from the plurality of NFs, and send a consolidated report of the energy consumption measurements to the application function.

9. The network node of claim 8, wherein the request for the energy efficiency network data analytics comprises at least one of an indication of a geographical location of the application function, an indication of a minimum energy requirement of the application at the location of the WTRU at a specified time, or an indication of whether the network data analytics are to be conducted using renewable energy resources or carbon dioxide (CO2) energy sources.

10. The network node of claim 9, wherein the transceiver and the processor are further configured to send at least one recommendation to the application function of a different geographical location or a different time to run the application to meet the minimum energy requirement of the application.

11. The network node of claim 10, wherein the geographical location and the different geographical location are specified as data network access identifiers (DNAIs) where the application resides.

12. The network node of any one of claims 8-11 , wherein the plurality of NFs comprise at least two of a management data analytics (MDA) function, a user plane function (UPF), an access and mobility management function (AMF), a session management function (SMF), a policy control function (PCF), a binding support function (BSF) and a network data analytics function (NWDAF).

13. The network node of any one of claims 8-12, wherein the network node is one or both of a network exposure function (NEF) or a network data analytics function (NWDAF).

14. The network node of any one of claims 8-13, wherein the request for energy efficiency network data analytics further comprises a minimum quality of service (QoS) threshold.

Images