Method, apparatus and system for power status reporting and power optimization service configuration

Abstract

A network device may receive a message indicating an identifier of a wireless transmit / receive unit (WTRU) and / or one or more parameters associated with a power state of the WTRU. The network device may generate a power reporting policy based, for example, on the received message. The power reporting policy may include one or more triggers associated with transmitting a power status report. The network device may transmit the power reporting policy to the WTRU. The network device may receive the power status report from the WTRU according to the power reporting policy. The power status report may include one or more battery characteristics associated with the WTRU. The network device may update one or more policy charging and control (PCC) rules based on the power state report.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 411,186, filed on September 29, 2022, the entire contents of which are incorporated herein by reference. Background Art

[0003] Multimodal data may be defined as input data from different kinds of devices and / or sensors, or output data to different kinds of destinations (e.g., one or more WTRUs) required by the same task or application. Multimodal data may include more than one unimodal data. There may be strong dependencies between each instance of unimodal data. Unimodal data may be considered as one type of data.

[0004] A device or sensor that generates (e.g., transmits) unimodal data may be a WTRU or may use a WTRU to transmit unimodal data to a network. The unimodal data may be transmitted to applications hosted on other WTRUs or applications hosted on a network server. A device or sensor that receives unimodal data may be a WTRU or may use a WTRU to receive unimodal data from a network. The unimodal data may be received from one or more applications hosted on other WTRUs or applications hosted on a network server.

[0005] A PDU set consists of one or more PDUs carrying a payload of an information unit generated at the application layer (e.g., a frame or video slice for an XRM service), which have the same importance requirement at the application layer. The application layer may require one or more PDUs in the PDU set to use the corresponding information unit. In an example, when some PDUs are lost, the application layer can recover part of the information unit. The multimodal synchronization threshold can be defined as the maximum tolerable time interval at the beginning of two stimuli, where the first stimulus is presented to one sense and the second stimulus is presented to another sense, so that the accompanying sensory objects are perceived to be synchronized. The synchronization threshold may be described herein as the maximum tolerable time interval between the transmission or reception of two streams. Summary of the invention

[0006] Methods and apparatus for power state reporting and power optimization service configuration are provided. Methods and apparatus are provided for configuring a power reporting policy in a wireless transmit / receive unit (WTRU) and WTRU behavior based on the power reporting policy. The power reporting policy may be WTRU initiated and / or network initiated. Methods and apparatus are provided for network behavior based on received WTRU power states.

[0007] A network device may receive a message indicating an identifier of a WTRU and one or more parameters associated with a power state of the WTRU. The network device may generate a power reporting policy based on the received message. The power reporting policy may include one or more triggers associated with transmitting a power state report. The one or more triggers may include one or more of the following: a battery level of the WTRU, an unplugged state of the WTRU, a temperature level of the WTRU, a bit rate parameter, and / or activation / deactivation of an application. The power reporting policy may also include a time when the WTRU may start power state reporting, a power state reporting frequency, and / or location information.

[0008] The network device may transmit the power reporting policy to the WTRU. The power reporting policy may be transmitted to the WTRU in response to a request received from the WTRU in a NAS message. The power reporting policy may be transmitted to the WTRU in a NAS message. The network device may receive the power status report from the WTRU according to the power reporting policy. The power status report may include one or more battery characteristics associated with the WTRU. The power status report may also include one or more of the following: the remaining time for a full charge, the time available for certain activities, the temperature level, the power mode, the time when the WTRU was last plugged in, the WTRU storage status, the WTRU memory status, the WTRU CPU load, power consumption information associated with one or more applications, the rate of change of battery charge and / or the expected power consumption level. The network device may update one or more PCC rules based on the power status report.

[0009] A network device may receive a message indicating an identifier of a WTRU and / or one or more parameters associated with a power state of the WTRU. The network device may generate a power reporting policy, for example, based on the received message. The power reporting policy may include one or more triggers associated with transmitting a power state report. The network device may transmit the power reporting policy to the WTRU. The network device may receive the power state report from the WTRU according to the power reporting policy. The power state report may include one or more battery characteristics associated with the WTRU. The network device may update one or more policy charging and control (PCC) rules based on the power state report.

[0010] The one or more triggers may include one or more of the following: a battery level of the WTRU, an unplugged state of the WTRU, a temperature level of the WTRU, a time of day, a bit rate parameter, activation of an application, and / or deactivation of an application. The one or more triggers may include a trigger that causes the WTRU to transmit the power state report based on a determination that the battery level of the WTRU is below a threshold. The one or more triggers may include a trigger that causes the WTRU to transmit the power state report based on a detection of a traffic type. The one or more triggers may include a trigger for a frequency at which the WTRU will transmit the power state report. The one or more triggers may include a trigger that causes the WTRU to stop transmitting the power state report based on one or more of the following: detection of a change in power state; determination that the WTRU is plugged in and / or charging; time of day; and / or determination that the battery level of the WTRU is at and / or above a threshold.

[0011] The network device may use the one or more parameters to configure the WTRU for extended and multimodal reality (XRM) services.The network node may determine to transmit the power reporting policy to the WTRU when the power reporting policy is created and / or based on a request received from the WTRU.

[0012] The network node may transmit a power status indication to a session management function (SMF) and / or a radio access network (RAN) based on the power status report. The network device may transmit a report to an application function (AF) based on the power status report. The network device may transmit one or more updated rules to a user plane function (UPF) based on the power status report to update a protocol data unit session associated with the WTRU.

[0013] The network node may generate a first set of PCC rules based on one or more of: one or more XRM service requirements, one or more quality of service requirements (e.g., for XRM services), and / or power state information of the WTRU. The network node may transmit the first set of PCC rules to the SMF to generate a first set of one or more quality of service (QoS) rules to be transmitted to the WTRU. The WTRU may transmit a second set of PCC rules to the SMF (e.g., based on the XRM service / XRM service description information) to generate a second set of one or more QoS rules to be transmitted to the WTRU. For example, the WTRU may transmit the second set of PCC rules based on one or more of: the power state of the WTRU, one or more XRM service requirements, one or more QoS requirements, one or more QoS requirements associated with the XRM service, and / or the power state information (e.g., of the WTRU).

[0014] The network node may receive media codec information from an application function (AF). For example, the network node may receive one or more quality of service (QoS) values. The network node may generate one or more PCC rules for a media traffic flow based on the received media codec information and / or based on a tradeoff between quality of experience (QoE) and power consumption of the WTRU. Generating the one or more PCC rules may be based on one or more of: determining one or more latency values; determining one or more of a video modality, a battery level of the WTRU, an XRM modality, and / or video throughput; and / or determining to align delay-tolerant traffic with real-time traffic. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0016] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0017] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within an illustrated communication system.

[0018] Figure 1D is an example of an embodiment in which Figure 1A System diagram of a further example Radio Access Network (RAN) and a further example CN for use within the illustrated communication system.

[0019] Figure 2 An example WTRU power reporting procedure is depicted.

[0020] Figure 3 An example network initiated procedure for communicating a power reporting policy to a WTRU is illustrated.

[0021] Figure 4 An example WTRU initiated procedure for communicating a power reporting policy to a WTRU is illustrated.

[0022] Figure 5 An example process for a WTRU to transmit a power report to the network is illustrated.

[0023] Figure 6 Example procedures are illustrated showing which procedures may be initiated in the network based on the contents of a power report from a WTRU. DETAILED DESCRIPTION

[0024] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 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), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0025] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood 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” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, and devices operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0026] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is 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 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0027] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, 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 send and / or receive signals in a desired spatial direction.

[0028] 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).

[0029] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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 ​​UL Packet Access (HSUPA).

[0030] 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) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

[0031] 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 New Radio (NR).

[0032] 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 together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0033] 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), and GSM EDGE (GERAN).

[0034] Figure 1A The base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. 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 another embodiment, 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 a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0035] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication 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 / 113 or a different RAT.

[0037] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0038] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, 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. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0039] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0040] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV, or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0041] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, 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.

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

[0043] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an 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 a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0044] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control 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, etc.

[0045] 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 from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0046] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules 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 electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[0047] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0048] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with 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.

[0049] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-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 evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0050] Each of the evolved Node 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, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0051] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] The MME 162 may be connected to each of the evolved Node-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, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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.

[0053] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an 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 the user plane during an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0054] 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.

[0055] 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 be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0056] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0057] In a representative embodiment, the other network 112 may be a WLAN.

[0058] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a 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 to and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Direct link establishment (DLS) may be utilized to transmit point-to-point traffic between the source STA and the destination STA (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0059] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each 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.

[0060] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0061] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0062] 802.11af and 802.11ah support operating modes below 1GHz. 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 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0063] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

[0064] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

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

[0066] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 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, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send 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, gNB 180a may transmit multiple component carriers to 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, 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).

[0067] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, 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 the gNBs 180a, 180b, 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., including different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0068] 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 a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0069] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b and routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0070] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0071] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 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 mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 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.

[0072] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0073] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the 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 downlink packets, and providing mobility anchoring, etc.

[0074] The CN 115 may facilitate communications with other networks. For example, the CN 115 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 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0075] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein for one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182ab, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0076] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions 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. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0077] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0078] The terms "network device" and "network function" are used interchangeably herein.

[0079] Multimodal data may refer to input data from one or more heterogeneous devices and / or sensors. Multimodal data may refer to output data required by the same task and / or application to one or more heterogeneous destinations (e.g., one or more WTRUs). Multimodal data may include more than one unimodal data. Strong dependencies may exist between one or more (e.g., each) instances of unimodal data. Unimodal data may be considered as one type of data.

[0080] The device and / or sensor that generates (e.g., transmits) unimodal data may be a WTRU and / or may use a WTRU to transmit unimodal data to a network. The unimodal data may be transmitted to an application hosted on one or more other WTRUs and / or to an application hosted on one or more network servers.

[0081] The device and / or sensor receiving the unimodal data may be a WTRU. The device and / or sensor may use a WTRU to receive the unimodal data from a network. The unimodal data may be received from one or more applications hosted on one or more other WTRUs and / or applications hosted on one or more network servers.

[0082] A packet data unit (PDU) set may include one or more PDUs carrying a payload of an information unit generated at the application layer (e.g., frames and / or video slices of an extended and multimodal reality (XRM) service), which may have the same importance requirement at the application layer. The application layer may require one or more (e.g., all) PDUs in the PDU set to use the corresponding information unit. In an example, when some PDUs are lost, the application layer may recover one or more parts of the information unit. A multimodal synchronization threshold may refer to a maximum allowable time interval between the start of two stimuli, where a first stimulus may be presented to one sense and a second stimulus may be presented to another sense, so that the accompanying sensory objects are perceived to be synchronized. The synchronization threshold may refer to a maximum allowable time interval between the transmission and / or reception of two streams.

[0083] With respect to the PDU set, the information unit may be an application layer information unit.The terms "information unit" and "application layer information unit" are used interchangeably herein.

[0084] WTRU Routing Selection Policy (URSP) rules may be policies used by the WTRU to determine how to route outgoing traffic. Traffic may be routed to an established PDU session, may be offloaded to a non-3GPP access outside of a PDU session, may be routed outside of a PDU session via a ProSe Layer 3 WTRU-to-network relay, and / or may trigger the establishment of another (e.g., new) PDU session.

[0085] One or more (e.g., each) URSP rules may include two or more parts. The first part of the URSP rule may include a service descriptor for determining when the rule is applicable. When each component in the service descriptor matches the corresponding information from the application, it can be determined that the URSP rule is applicable. The second part of the URSP rule may include a list of routing descriptors (RSDs). The RSD list may include one or more RSDs. The RSDs may be listed in order of priority and / or may describe the characteristics of PDU sessions that can be used to carry uplink application data. The characteristics of the PDU session may include a session and service continuity (SSC) mode, a data network name (DNN), and / or a single network slice selection assistance information (S-NSSAI). Additionally or alternatively, the RSD may include a non-seamless offload indication indicating that the service may be transmitted via a non-3GPP access (e.g., WiFi) and / or outside of (e.g., any) PDU session.

[0086] The WTRU may evaluate the URSP rules for one or more (e.g., each) detected (e.g., newly detected) applications in order of rule priority and / or may determine whether the application matches a traffic descriptor of one or more (e.g., any) URSP rules. For example, when determining that a URSP rule is applicable to a given application, the WTRU may select a routing descriptor within the applicable URSP rule in order of routing descriptor priority.

[0087] For example, when a valid routing descriptor is found, the WTRU may determine whether there are existing PDU sessions that match one or more (e.g., all) components in the selected routing descriptor. For example, when there are matching PDU sessions, the WTRU may associate the application with the existing PDU sessions. For example, the WTRU may route the traffic of the detected application on the matching PDU sessions. For example, if none of the existing PDU sessions matches the RSD, the WTRU may attempt to establish another (e.g., new) PDU session using the values ​​specified by the selected routing descriptor.

[0088] The traffic descriptor may be an application descriptor, an Internet Protocol (IP) descriptor, a domain descriptor, a non-IP descriptor, a DNN, and / or a connection capability. The IP descriptor may be a destination IP 3-tuple (e.g., an IP address and / or IPv6 network prefix, a port number, a protocol ID for a protocol over IP, etc.).

[0089] A (e.g., typical) WTRU may engage in one or more (e.g., several) activities during its (e.g., normal) operation. The one or more activities may be divided into one or more (e.g., 5) broad categories: deep sleep; periodic activities in idle mode; periodic activities in connected mode; data transmission and / or reception; and / or control channel monitoring (e.g., when in connected mode). Control channel monitoring may refer to activities in which the WTRU is not engaged in (e.g., any) uplink and / or downlink data transmission, but is monitoring a control channel (e.g., in particular the Physical Downlink Control Channel (PDCCH)) to receive downlink control information (DCI) from a RAN node. Examples of DCI may include downlink (DL) and / or uplink (UL) scheduling information. Power consumption studies may show that the WTRU consumes a significant amount (e.g., a lot) of power when monitoring control channels. For example, control channel monitoring may be responsible for approximately 55% of the WTRU's power consumption (e.g., even though it may account for less than 10% of the WTRU's activities).

[0090] To address this power consumption, the network may configure the WTRU in one or more ways. For example, the network may configure the WTRU with connected mode DRX (CDRX). For example, when the WTRU stops PDCCH monitoring, CDRX may control power saving. CDRX may have an on-off cycle. The WTRU may monitor the PDCCH during the on duration. The WTRU may stop monitoring the PDCCH during the off duration. The network may ensure that the WTRU does not receive DCI during the off duration of the WTRU. The on duration (also known as the active time) of the cycle may be variable and / or may be extended based on UL and / or DL ​​activity. For NR, WTRU support for CDRX may be mandatory, but its activation and / or configuration may be controlled by the RAN node through radio resource control (RRC) signaling. For example, once the RAN node configures CDRX, the RAN node may be considered active and / or the WTRU may follow CDRX to save power. Additionally or alternatively, the network device may, for example, use one or more parameters (e.g., one or more parameters associated with the power state of the WTRU) to configure the WTRU for extended and multimodal reality (XRM) services.

[0091] Extended reality (XR) / media services may be associated with high throughput, low latency and / or high reliability requirements. The WTRU battery level may affect the user experience because high throughput requires high power consumption on the terminal side. Considering the limited radio resources and / or end-to-end QoS policy control from a system perspective, 5GS can be enhanced to support the trade-offs between throughput, latency, reliability and / or device battery life.

[0092] The WTRU configuration at the non-access stratum (NAS), RRC, and / or physical and application layers may be adjusted in one or more ways that make one or more trade-offs between battery life and user experience. For example, changing the application layer codec settings so that video and / or audio are streamed at a higher quality may result in a better user experience and / or (e.g., also) may result in more battery energy being consumed. The better user experience may include, for example, one or more of the following: application layer code that may result in higher video and / or audio quality, enhanced resolution, and / or enhanced audio quality / clarity; lower latency (e.g., the user may not wait to receive the stream and / or there may be continuity in the video stream); higher throughput (e.g., may enable video and / or audio to be transmitted with a better codec and / or resolution, which may be perceived as having better quality from the user's perspective; and / or an enhanced user experience (e.g., lower latency, higher throughput, higher resolution, etc.).

[0093] The WTRU may report information about its power state to the 5G core and / or the next generation (NG) RAN. Reporting information about the power state of the WTRU to the 5G core and / or NG Ran may include one or more benefits. The 5G core and / or NG RAN may (e.g., then) take one or more actions to balance user experience with battery life. For example, the CDRX open time may be increased to reduce data latency at the expense of consuming more battery energy. The 5GS may not support one or more (e.g., any) processes that enable the WTRU to report power, power, and / or status to the 5G core network and / or NG RAN. The 5G system may not support one or more (e.g., any processes) that enable the 5G core and / or NG RAN to configure the WTRU to know when to report the power state and / or what information to report when reporting the power state.

[0094] Figure 2 An example WTRU power reporting process 200 is depicted. The network may prepare a power reporting policy and / or may configure a power reporting policy for the WTRU. The WTRU may be triggered to report power status based on the policy and / or the network may take one or more actions to take into account the power status of the WTRU.

[0095] At 202, the network may prepare a power reporting policy (e.g., prepare its contents). Information may be included in the power reporting policy. The power reporting policy may include information transmitted from the network (e.g., 5G Core and / or NG Radio Access Network (RAN)) to the WTRU and / or may indicate to the WTRU what events may trigger a power report to be transmitted to the network and / or what information should be included in the power report.

[0096] At 204, the network may transmit a power reporting policy to the WTRU. One or more procedures may be used to transmit a power reporting policy to the WTRU. One or more events may trigger the network to transmit a power reporting policy to the WTRU.

[0097] At 206, the WTRU may transmit a power report to the network, for example, when triggered. When the WTRU is triggered to transmit a power report, one or more procedures may be used to transmit the power report to the network.

[0098] At 208, one or more processes may be triggered in the network based on the contents of the power report. For example, the contents of the power report may trigger the network to take one or more actions to improve WTRU energy consumption at the expense of user experience. For example, the contents of the power report may trigger the network to take one or more actions to reduce user experience in order to reduce WTRU energy consumption and / or extend battery life.

[0099] The WTRU may receive a power reporting policy from the network (e.g., 5G core and / or NG RAN). The power reporting policy may provide the WTRU with information about power status reporting. For example, the power reporting policy may indicate information about power status reporting.

[0100] Each power reporting policy may be associated with a power reporting policy identification (ID). The power reporting policy ID may be referenced by one or more other policies and / or one or more rules (e.g., URSP and / or wireless local area network selection policy (WLANSP) rules) in the WTRU to indicate to the WTRU when the power reporting policy may be applied.

[0101] The power reporting policy may adopt one or more different granularities. The power reporting policy may be per WTRU. In an example, a single policy may be provided to the WTRU. Additionally or alternatively, the power reporting policy may be per QoS flow. In an example, the WTRU may have one or more (e.g., multiple) power reporting policies—one or more (e.g., each) policies may be applicable to a set of service data flows. Additionally or alternatively, the power reporting policy may be per service data flow (SDF). In an example, the WTRU may have one or more (e.g., multiple) power reporting policies—one or more (e.g., each) policies may be applicable to an SDF. For example, in the case where the WTRU has one or more (e.g., multiple) reporting policies, the WTRU may combine one or more policies. For example, if a first policy instructs the WTRU to report the power status every 5 minutes and a second policy instructs the WTRU to report the power status every 7 minutes, the WTRU may decide to report the power status every 5 minutes to satisfy both policies.

[0102] The power reporting policy may indicate to the WTRU what events trigger and / or stop the power monitoring process.

[0103] The power reporting policy may include the time at which the WTRU may start power state monitoring. For example, the 5GS may expect the WTRU to have more activity at one or more (e.g., certain) times during the day (e.g., rather than at night). In an example, the 5GS may configure the WTRU to start monitoring the power state at 7 a.m. and / or not monitor the power state after midnight. The 5GS may infer one or more times of the day. The 5GS may infer one or more times of the day, for example, when the WTRU is configured to (e.g., need to) monitor the WTRU power state. The 5GS may infer one or more times of the day, for example, through WTRU activity information (e.g., data usage during the day). Additionally or alternatively, the 5GS may infer (e.g., expect, predict) that a certain (certain) time of the day is the time when the WTRU may (e.g., may need to) report its power state, for example, through information about previous WTRU behavior (e.g., data usage of a certain application at a certain time of the day, etc.).

[0104] The 5GS may notify the WTRU to stop monitoring the WTRU power state under one or more (e.g., certain) conditions. For example, the 5GS may stop monitoring the WTRU power state if the WTRU battery level is (e.g., relatively) above a certain threshold and / or at a certain time of day. For example, the WTRU may stop monitoring the WTRU power state during one or more time slots (e.g., from midnight to 7 a.m.). The 5GS may notify the WTRU to stop monitoring the WTRU power state if the WTRU is plugged in / charging.

[0105] The power reporting policy may be described based on service information. For a service session, through an application function (AF), the application may provide one or more (e.g., some) power reporting requirements and / or information. The power reporting requirements and / or information may include whether power reporting is activated when the service session is activated. For example, the network node may receive media codec information from the AF. The media codec information may include one or more QoS values. The AF may (e.g., also) include one or more (e.g., some) thresholds, such as minimum power and / or power requirements, and / or a minimum power mode and / or preferred power mode for the service. The AF may (e.g., also) take into account whether the WTRU is plugged into a power source. For example, the power requirements and / or information may take into account whether the WTRU is plugged into a power source. For example, in a case where the WTRU battery charge is below a certain threshold and the WTRU is plugged into a power source, it may not be necessary to monitor power consumption.

[0106] The PCF may use the power reporting service information to generate one or more power reporting policies associated with the service. In an example, a power reporting policy may include a service descriptor for notifying the WTRU that a corresponding power reporting policy (e.g., with one or more other reporting policy parameters) is activated when a service having the descriptor information is exchanged. This may be beneficial, for example, if there are two service sessions with different power reporting granularities (e.g., such as reporting frequency, start time, and / or stop time). The PCF may generate a power reporting policy for one or more (e.g., each) services (e.g., through different service descriptors and / or report content and / or parameters) and / or may provide one or more generated policies to the WTRU. The network node may generate a power reporting policy based on a determination associated with an application. The network node may generate a power reporting policy based on a power consumption pattern determined by one or more power state reports received from the WTRU. The network node may generate one or more PCC rules for a media service flow based on received media codec information and a trade-off between quality of experience (QoE) and power consumption of the WTRU. The network node may generate one or more PCC rules based on one or more of: determining one or more latency values; determining one or more of a video modality, a battery level of the WTRU, an XRM modality, and / or video throughput; and / or determining to align delay-tolerant services with real-time services. One reporting policy may indicate that the WTRU reports power levels (including available power levels) every 5 minutes, while another service may indicate a reporting frequency of 15 minutes with a thermal status level.

[0107] The WTRU may use one or more of the generated power reporting policies. The WTRU may be configured with one or more of these service-related power reporting policies. For example, when the WTRU detects that data having a service descriptor matching one of the one or more policies is exchanged with the WTRU, the WTRU may use the one or more policies. For example, if the WTRU detects that a service is no longer being exchanged (e.g., if the corresponding QoS flow for the service is removed), the WTRU may know to stop reporting power information according to the policy of the service.

[0108] The power reporting policy may indicate to the WTRU where to transmit the power report. For example, the generated power reporting policy may configure the WTRU to transmit the power status report to a network function and / or an application function.

[0109] The power reporting policy may (e.g., also) include which entity(ies) of the network (e.g., 5GS) to transmit the report to. The power status report may be provided to the PCF for policy control management. The power status report may (e.g., also) be provided to the network data analysis function (NWDAF). The power status report may be provided to the NWDAF for inference purposes to help better serve the WTRU. For example, the WTRU power report may be used to predict the WTRU power consumption behavior at a certain time and / or location. The WTRU power report may be used to infer the power consumption pattern of the WTRU (e.g., which may be learned from one or more reports previously received from one or more other WTRUs that use and / or have used the same application). In such a scenario, the frequency of one or more reports may be reduced (e.g., only for reports to improve accuracy) and / or the PCF may request that the WTRU no longer transmit reports (e.g., to further optimize power consumption). A decision to reduce the frequency of reports (e.g., and / or eliminate reports) may be made after receiving one or more (e.g., a certain number of) reports. The report may be used to identify power consumption patterns, for example, from existing power consumption patterns (e.g., associated with applications, locations, and / or wireless conditions).

[0110] The reporting policy may indicate whether the report is to be transmitted via the user plane (UP) and / or the control plane (CP). For the user plane, the WTRU may transmit the report to the corresponding user plane function (UPF), which may forward the report to one or more interested network functions (NFs), such as the session management function (SMF), the policy control function (PCF), the NWDAF, and / or the unified data repository (UDR). The network may decide to use the user plane or the control plane for reporting based on the reporting frequency and / or network load.

[0111] The power reporting policy may include the type of content related to the power state to be included in the report. The type of content may be indicated by one or more of the following power reporting information elements (IEs) in the power reporting policy: device battery characteristics, WTRU battery maximum capacity, charge state, battery charge, time remaining to (e.g., full) charge; time available to support one or more activities; temperature level; battery charge indication; device power mode; when the WTRU was last plugged in; information about the WTRU storage and / or memory state and / or central processing unit (CPU) load; information about power consumption of XRM services; information about high power consumption applications; charging rate of power state and / or battery charge; and / or simulated (e.g., expected) power consumption level.

[0112] The power reporting policy may include one or more device battery characteristics IEs. The device battery characteristics may include battery capacity (e.g., in milliamp hours (mAh)), battery voltage (e.g., in V), and / or battery technology (e.g., lithium polymer (Li-poly)). The one or more device battery characteristics information may be fixed for a device (e.g., the one or more device battery characteristics information does not change over time); the one or more device battery characteristics may be reported in an initial power report and / or may not be included in a cyclic power report for the WTRU.

[0113] The power reporting policy may include a WTRU Battery Maximum Capacity IE. The WTRU Battery Maximum Capacity may measure the WTRU battery capacity relative to the capacity when the WTRU was new. A new WTRU may be referenced when a customer / user purchases a brand new device with a certain initial battery capacity. The maximum battery capacity may refer to the current battery capacity of the WTRU and / or the ratio of the current battery capacity of the WTRU to the initial battery capacity of the WTRU (e.g., a brand new WTRU). Although the WTRU's battery maximum capacity may change over time, the battery maximum capacity may be fairly static (e.g., may change slowly compared to the frequency with which the WTRU is used).

[0114] The power reporting policy may include a power status IE. The power status IE may indicate whether the device is unplugged, plugged in, and / or charging. The power status IE may (for example, also) indicate whether the WTRU is mains powered and / or using fast charging.

[0115] The power reporting policy may include a battery level IE. The battery level IE may indicate a percentage and / or value (eg, in mAh) of the current WTRU battery level.

[0116] The power reporting policy may include a (eg, full) charge remaining time IE. For example, the full charge remaining time IE may indicate the time it takes for the WTRU to be fully charged (eg, in the case of a plugged in WTRU).

[0117] The power reporting policy may include a time available to support one or more certain activities IE. The time available to support certain activities IE may indicate one or more (e.g., some) estimates of how long the WTRU can support one or more specific activities at the current power level. The one or more activities may include standby, 5G Internet, calling, wireless fidelity (Wi-Fi), music, video, and / or global positioning system (GPS). This information may give an approximation of one or more certain activities to be supported by the WTRU. For example, this information may assist the network (as an output) to better infer the time available for a specific XRM service.

[0118] The power reporting policy may include a temperature level IE. The temperature level IE may indicate the current thermal level of the WTRU. For example, high throughput mode may affect the WTRU thermal level. The indication of the current thermal level of the WTRU may assist the network in helping the WTRU.

[0119] The power reporting policy may include a battery level indication IE. The battery level indication IE may include one or more certain battery level thresholds. The battery level indication IE may include one or more certain tags, such as: low battery level, average battery level, and / or high battery level. One or more tags of the battery may be mapped to a battery value (e.g., whether a percentage and / or an absolute value) associated with a battery level threshold. For example, if the network (e.g., 5GS) wants to have a brief indication of the battery level (e.g., rather than a full power status report), the network may (e.g., where the network has some initial information about the WTRU power characteristics (such as capacity and / or voltage)) configure the WTRU to report (e.g., only report) one or more indications (e.g., capacity and / or voltage). A brief indication of the battery level may be useful to the network and / or AF.

[0120] The power reporting policy may include a device power mode IE. The device power mode IE may indicate (if available) whether the WTRU is in a low power mode (eg, low power mode is activated in the device) and / or whether a power save mode is activated.

[0121] The power reporting policy may include a time when the WTRU was last plugged in IE. The time when the WTRU was last plugged in IE may indicate the time when the WTRU was last plugged in.

[0122] The power reporting policy may include IEs regarding the WTRU storage and / or memory status and / or CPU load. The information regarding the WTRU storage and / or memory status and / or CPU load may indicate information regarding the memory usage and / or CPU load of the WTRU. For example, the WTRU may provide the amount of random access memory (RAM) memory used (e.g., at a certain time and / or duration). The WTRU may provide a description of the WTRU storage level, the WTRU memory level, and / or the WTRU CPU level to the network (e.g., 5GS). For example, the WTRU may indicate that it is in a limited storage state and / or a limited memory state (e.g., to indicate that it does not have a large amount of available storage and / or available RAM memory). If an application function associated with an XRM service may provide different service requirements (e.g., throughput), QoS parameter sets, etc. associated with certain WTRU storage usage and / or certain WTRU memory usage. For example, if the WTRU is in a low memory state at a certain point in time, the network may adjust the QoS parameters used for the XRM service under consideration to reduce the bit rate and / or increase latency so that the WTRU can support the memory usage. For example, if the WTRU memory and / or storage status is in a low memory state, the AF may request a throughput value (e.g., r1). Additionally or alternatively, for example, the AF may request another (e.g., second) throughput value (e.g., r2) corresponding to when the WTRU's memory and / or storage is in a high memory state. The AF may provide both throughput values ​​(e.g., r1 and r2) and their corresponding memory and / or storage status conditions.

[0123] Similar to the power information, the power reporting policy may include information about the memory usage of a particular XRM service and / or information about high memory consumption applications running in the WTRU. This information may be useful for the network to better assist the WTRU in running XRM services, for example by taking into account memory and / or power consumption.

[0124] The power reporting policy may include an IE regarding the power consumption of the XRM service. Information regarding the power consumption of the XRM service may be provided as a percentage of the total power consumption of the WTRU. For example, the WTRU may provide an indication that the XRM service consumed 10% of the WTRU power in the last hour and / or the WTRU may provide an indication that the XRM service consumed 1 mAh in the last hour.

[0125] The power reporting policy may include IEs about high power consumption applications. Information about high power consumption applications may help the network determine whether reducing the quality of experience (QoE) of the XRM service will result in significant power savings. For example, the WTRU may have an active GPS application that consumes a lot of power. In such cases, reducing the QoE of the XRM service may not significantly help battery life. The WTRU may (e.g., also) provide an indication of the type of applications that are consuming power (e.g., GPS, camera, etc.), the number of such applications, and / or whether one or more applications are using cellular transmission.

[0126] Providing an indication of the type of application that is consuming power may be done at a finer granularity. For example, the indication may be provided at the level of an application subroutine / subfunction / process. It may be known and / or inferred that one or more components / processes of an application consume more battery life than other parts. This information may come from a network component (e.g., NWDAF). This information may be stored by the network function as part of a WTRU / subscriber / application profile (e.g., Unified Data Management Function (UDM) / UDR). This information may be provided externally to the network function by an application service provider and / or provided to the network node by an application client at the WTRU. For example, turning on augmented reality (AR) functionality in an application may significantly increase CPU usage, and therefore power consumption may also increase. When AR functionality is turned on, energy consumption may be (e.g., further) optimized.

[0127] The power reporting policy may include IEs regarding the rate of change of power state and / or battery level. The network may use the rate of change of power state and / or battery level to determine the amount of QoE reduction (e.g., the required reduction) to offset the low battery level. For example, if the rate of change of power state is high, the network may decide to use one or more QoS parameters that provide the greatest power savings; this may result in a significant change in QoE. Conversely, for example, if the rate of change of power state is slow, the network may decide to change one or more QoS parameters so that the QoE changes more gradually.

[0128] The power reporting policy may include an IE regarding simulated (e.g., and / or expected) power consumption levels. The WTRU may use the simulated and / or expected power consumption levels to request a policy associated with a given power state and / or battery level. For example, even if the WTRU power state is high, based on user selection, the WTRU may request that a "low power" policy (e.g., including a QoS profile, one or more QoS rules, etc.) be applied. For example, when the WTRU's power state is high (e.g., there is sufficient power and / or high battery power), the user may choose to put the WTRU in low power mode (e.g., using settings on the WTRU). When the WTRU's power state is low (e.g., there is not enough power and / or low battery power), the user may choose to disable the low power mode. For example, if the user is watching a video and the power state is low, the user of the WTRU may disable the low power / low battery mode in the WTRU settings. There may be one or more other simulated versions of other power reporting IEs. For security reasons, the WTRU may limit the values ​​that can be set for one or more simulated IEs (e.g., set only to the worst value) to avoid situations where malicious applications may drain an already insufficient power supply. Users may request a lower level of service to save energy.

[0129] For example, based on the time of the report (eg, if the report is the first report and / or a recurring report), and / or based on the service requirements of the XRM service, the report content may include one or more (eg, some) of the IEs described herein.

[0130] The power reporting policy may indicate to the WTRU what events trigger the WTRU to transmit a power report. For example, the power reporting policy may indicate multiple (eg, one or more) triggers associated with power reporting.

[0131] The power reporting policy may include what types of triggers are considered to transmit a power status report. An example trigger may be the battery level of the WTRU. When the battery level is below a certain threshold, the network (e.g., 5GS) may instruct the WTRU to report the power status. For example, if the battery level is below a certain level, the network may indicate that power level monitoring becomes critical (e.g., the trigger for the WTRU to transmit a power status report may be based on determining that the WTRU's battery level is below a predetermined threshold); the network may instruct the WTRU to start reporting power reports (e.g., at a certain frequency). For example, if the WTRU battery level is above a predetermined threshold, the network and / or AF may not require the WTRU to transmit a power status report to it.

[0132] Another trigger for transmitting a power report may be whether the device is plugged in (e.g., and / or charging) or unplugged (e.g., and / or not charging). The reporting policy may instruct the WTRU to transmit a power report if (e.g., only) the device is unplugged and / or may instruct the WTRU not to transmit a power report if the WTRU is not charging.

[0133] Another trigger for transmitting power reporting may be based on when the WTRU starts transmitting power status reports. The power reporting policy may include the time (e.g., time of day) at which the WTRU may start power status reporting. For example, the network (e.g., 5GS) may expect the WTRU to have more activity (at a certain time of day rather than at night). For example, the network (e.g., 5GS) may configure the WTRU to start reporting power information at a predetermined time in the morning (e.g., 7 a.m.) and / or not report power information after a predetermined time in the evening (e.g., midnight). The network (e.g., 5GS) may infer one or more times of the day that the WTRU needs to report power information, for example, through WTRU activity information (e.g., data usage during the day). The WTRU may (e.g., also) start power reporting after a certain time x has passed after a certain application has been started. For example, a certain application may be started at time t, and the WTRU may start power reporting at time t+x.

[0134] One or more triggers may be associated with when the WTRU will stop transmitting power status reports. The network (e.g., 5GS) may notify the WTRU to stop reporting power information under one or more certain conditions. For example, the network may notify the WTRU to stop reporting power information (e.g., stop transmitting power status reports) based on one or more of the following: detecting a change in power state; determining that the WTRU is plugged in and / or charging; determining that the battery charge of the WTRU is at and / or above a certain threshold, and / or when the time is within a certain time range of the day (e.g., a certain time of the day). The WTRU may stop transmitting power status reports based on one or more IEs, as described herein. The network (e.g., 5GS) may infer the power consumption pattern of the WTRU. For example, the network (e.g., 5GS) may infer the power consumption pattern of the WTRU based on learning from one or more reports previously received from one or more other WTRUs using the same application, and / or may require the WTRU to no longer transmit reports (e.g., to further optimize power consumption).

[0135] Another trigger for transmitting a power report may be based on a power status reporting frequency. One or more triggers may be associated with a frequency at which the WTRU will transmit a power status report. The power reporting policy may include a power status reporting frequency (e.g., information about the frequency with which the power status is reported). The power status reporting frequency may vary depending on the application that triggers the power reporting. For example, when the service includes a video modality where the power status may be important (e.g., because there may be changes in the power level that may change when the video service is exchanged), the power status reporting frequency may have a higher frequency (e.g., every 5 minutes). When the service includes, for example, a modality where the power consumption may change slowly over time and / or as the service is exchanged (e.g., tactile), the power status reporting frequency may have a lower frequency (e.g., every 15 minutes).

[0136] The frequency of power state reporting may be linked to one or more characteristics of the service itself. For example, the network (e.g., 5GS) may indicate to the WTRU that for a video modality, the WTRU may report power information at the end of a video burst. For example, the WTRU may report power information after one or more (e.g., 10) video bursts have been transmitted (e.g., via an uplink). For example, if the WTRU detects when a modality burst begins and / or ends, the WTRU may keep track of the number of video bursts that have been exchanged. For example, when the 10th burst has been exchanged, the WTRU may determine (e.g., based on a video modality reporting policy) that it is time to report power information. The WTRU may be configured to report the power state after one or more (e.g., every 10) video bursts have been received from the network. For example, the WTRU may report the power state after the 10th burst, the 20th burst, the 30th burst, and so on. This reporting granularity associated with a set of PDUs for a certain mode of burst and / or XRM service may be achieved through one or more service characteristic detection mechanisms at the WTRU and / or the network (e.g., 5GS) and / or through information provided to the WTRU regarding one or more XRM service modes.

[0137] The network (e.g., 5GS) may infer the power consumption pattern of the WTRU. For example, the network (e.g., 5GS) may infer (e.g., learn from) the power consumption pattern of the WTRU based on one or more reports previously received from one or more other WTRUs using the same application. The network may reduce the frequency of reporting (e.g., the reporting may be used to improve accuracy).

[0138] Another trigger for transmitting a power report may be based on and / or associated with the temperature level of the WTRU. The network (e.g., 5GS) may instruct the WTRU to transmit a power status report when the WTRU temperature becomes high (e.g., exceeds a predetermined threshold).

[0139] The power reporting policy may include WTRU location information. This may indicate to the WTRU that the reporting policy is to be applied when the WTRU is located in one or more certain locations and / or (e.g., possibly) not located in other locations. For example, if the WTRU is in an office and / or the user is at home, the network may not need to report its power status when a certain application is used. The network may not need the WTRU to report its power status, for example, because if the WTRU is in an office and / or the user is at home, the WTRU can charge quickly (e.g., if necessary). The location information used for power reporting may have one or more other considerations (e.g., in addition to charging availability). For example, an application may provide one or more power reporting requirements that are related to a specific geographic area and / or not related to one or more other geographic areas.

[0140] Another trigger for transmitting a power status report may include one or more parameters related to the bit rate and / or maximum bit rate that the WTRU has, such as the WTRU aggregated maximum bit rate (AMBR). When the WTRU-AMBR has a certain value, the network may configure the WTRU to start transmitting a power status report. For example, when the WTRU-AMBR is greater than a predetermined threshold, the network may configure the WTRU to start transmitting a power status report.

[0141] Another trigger for transmitting a power status report may include the WTRU power status / battery level exceeding one or more thresholds. The power reporting policy may include the value of one or more thresholds.

[0142] Another trigger for transmitting a power status report may include a change in power status (eg, a change from battery to mains power).The power reporting policy may include an indication to provide a power status report based on a change in power status.

[0143] Another trigger for transmitting a power status report may include activation and / or deactivation of an application. For example, a trigger for transmitting a power status report may be associated with activation of a (e.g., high power consumption) application. For example, a trigger for transmitting a power status report may be associated with deactivation of a (e.g., high power consumption) application. The WTRU may report a power status report when a high power consumption application (e.g., such as an application using GPS) is activated and / or deactivated. The power reporting policy may include an indication to provide a report based on activation / deactivation of one or more high power consumption applications. The policy may (e.g., also) provide an indication of one or more specific applications to which it applies and / or the type of application to which it applies.

[0144] Another trigger for transmitting a power status report may be based on content. When to transmit a power status report may be content-specific (e.g., service data flow-specific, application-specific, PDU session-specific, etc.). For one or more types of (e.g., some) content, one or more power status reports may be repeated periodically (e.g., battery level transmitted every 5 minutes). For one or more other types of content, one power status report may be transmitted once (e.g., only) (e.g., initially, when an application starts, when an application ends, etc.). For one or more (e.g., other) content, one or more power status reports may be transmitted aperiodically (e.g., based on one or more (e.g., some) triggering conditions.

[0145] In an example, the WTRU may modify one or more (e.g., some) parameters (e.g., brightness of a display, processing of some signals from a sensor, etc.) on its own to meet a battery life constraint. In this case, the network may exploit knowledge of the one or more actions performed by the WTRU. For example, the network may request the WTRU to report such changes in a power report. The network may configure the WTRU to report one or more events described herein. Additionally or alternatively, the WTRU may provide a status of a certain metric such as a rate of change of a power level (e.g., as described herein), which the WTRU may be able to determine based on one or more parameters including a change in display brightness and / or the like. For example, the WTRU may report the status of the certain metric (e.g., rate of change of power) to the network without the network needing to be aware of one or more (e.g., all) changes performed (e.g., locally) by the WTRU.

[0146] The power reporting policy may combine one or more of the triggers described herein, for example, for when the WTRU transmits and / or stops transmitting power status reports.

[0147] The power reporting policy may indicate to the WTRU one or more certain actions that may be taken based on the content of the power report and / or based on one or more detected conditions and / or based on one or more triggers associated with transmitting power status reports.

[0148] The network (e.g., 5GS) may (e.g., also) include one or more certain actions that the WTRU may perform under one or more certain conditions related to the power state. As described herein, the network (e.g., 5GS) may configure the WTRU to transmit a power state report under one or more certain triggers. The reporting policy may (e.g., also) instruct the WTRU to perform one or more other actions, such as activating a low power mode (e.g., throttling an application). The WTRU may be configured to perform one or more certain actions, for example, by selecting one or more URSP rules based on the power reporting IE.

[0149] Embodiments are described herein for provisioning one or more power reporting policies in a WTRU and / or how the WTRU may behave based on one or more policies. The network may provide one or more power reporting policies to the WTRU. The one or more power reporting policies may indicate one or more behaviors associated with the one or more reporting policies. Transmitting a power reporting policy to the WTRU may be a network-initiated process. For example, a network function such as a PCF may trigger a process for transmitting a power reporting policy to the WTRU based on a request from the AF. When an application on the WTRU joins an XRM session (e.g., by receiving XR-related data services from the WTRU and / or through application layer signaling), a request from the AF may be triggered (e.g., may be triggered by the AF). Additionally or alternatively, the PCF may trigger the process when the WTRU establishes a PDU session to a certain DNN / S-NSSAI combination and / or when a notification is received (e.g., through a service provisioning request from the AF) that the WTRU is running a certain application.

[0150] Transmitting a power reporting policy to the WTRU may be a WTRU initiated process. For example, the WTRU may trigger a process involving the network transmitting a power reporting policy to the WTRU. The WTRU may transmit a request for a power reporting policy to the network. The request from the WTRU may be triggered by detected application activity (e.g., a request from an application to a mobile terminal (MT) portion of the WTRU via an attention (AT) command). Additionally or alternatively, the WTRU may trigger the process when the WTRU establishes a PDU session to a certain DNN / S-NSSAI combination and / or when a notification is received that the WTRU is running a certain application. For example, a URSP rule may indicate that a power reporting policy may be required, requested, and / or enabled when a certain service descriptor matches and / or when a certain RSD is used.

[0151] A network function (e.g., a PCF) may receive a (e.g., first) message. The network function may receive a message from an AF. The (e.g., first) message may identify (e.g., indicate) a WTRU and / or one or more parameters that may be used by the PCF to configure the WTRU (e.g., for an XRM service). For example, the (e.g., first) message may include an identifier of the WTRU. The (e.g., first) message may include one or more (e.g., multiple) parameter sets. One or more (e.g., each) parameter set may be associated with a power state of the WTRU. For example, each parameter set may be associated with a power state of the WTRU. The power state of the WTRU may be used to determine which parameter set to use to configure the WTRU (e.g., which parameter set may be used to configure the WTRU may be based on the power state of the WTRU). The first message may (e.g., also) indicate to the PCF that the AF wants to subscribe to the PCF. For example, the AF may subscribe to the PCF to be notified when the PCF detects that the power state of the WTRU has changed. The first message may (e.g., also) include information about when the WTRU may be configured to report power state information. For example, the first message may indicate how often the WTRU may transmit a power status report and / or what events may trigger the WTRU to transmit a power status report.

[0152] The PCF may generate a power reporting policy. For example, based on the content of a (e.g., a first) message, the PCF may generate a power reporting policy. The generated power reporting policy may include one or more triggers associated with transmitting a power status report. For example, the WTRU may determine that one of the one or more triggers associated with transmitting a power status report has been satisfied. The PCF may transmit the power reporting policy to the WTRU (e.g., in a NAS message). For example, when the power reporting policy is created and / or based on a request received from the WTRU, the PCF may determine to transmit the power reporting policy to the WTRU. Additionally or alternatively, the PCF may determine to transmit the power reporting policy based on a request received from the WTRU in a NAS message.

[0153] The PCF may receive a power report (e.g., a power status report) from the WTRU. The power report (e.g., a power status report) may be received from the WTRU and / or from the AF in a NAS message. A network device (e.g., a PCF) may receive a power status report from the WTRU in accordance with a power reporting policy. The WTRU may transmit a power status report to a network node in accordance with the power reporting policy. The power status report may include one or more battery characteristics associated with the WTRU. The power status report may include power status information associated with the WTRU and / or an indication indicating a determined trigger for transmitting a power status report.

[0154] Based on the power report (e.g., the power status report), the PCF may transmit an indication that a set (e.g., a new set) of one or more PCC rules should be applied (e.g., the report may have indicated that the WTRU was inserted and / or that content may be transmitted to the WTRU in a higher quality encoding).

[0155] Based on the power report (e.g., the power status report), the PCF may transmit a power status indication to the SMF. For example, the SMF may forward the power status indication to the RAN based on the power status report (e.g., via N2 messaging). The RAN may adjust one or more WTRU parameters based on the power status indication (e.g., to better account for the power status of the WTRU). For example, the RAN may change one or more CDRX parameters based on the power status indication (e.g., so that the WTRU uses a larger CDRX active time when the WTRU is inserted).

[0156] The PCF may update one or more PCC rules based on the power state report. The network node (e.g., PCF) may generate a first set of PCC rules. For example, the network node (e.g., PCF) may generate a first set of PCC rules based on one or more of the following: one or more Extended and Multimodal Reality (XRM) service requirements, one or more Quality of Service (QoS) requirements (e.g., QoS requirements for XRM services), and / or power state information of the WTRU (e.g., as described herein). The network node (e.g., PCF) may transmit the first set of PCC rules to a session management function (SMF) to generate a first set of one or more QoS rules to be transmitted to the WTRU. The network node (e.g., PCF) may transmit a second set of PCC rules to the SMF to generate a second set of one or more QoS rules to be transmitted to the WTRU. For example, the PCF 610 may transmit updated PCC rules to the same SMF or a different SMF based on the XRM service, service description information, QoS parameters, and / or a PDU session carrying the service. For example, the network node (e.g., PCF) may generate a second set of PCC rules based on the power state of the WTRU, based on one or more XRM service requirements, and / or based on one or more QoS requirements (e.g., associated with the XRM traffic). The network node may generate the one or more PCC rules based on one or more of: determining one or more latency values; determining one or more of a video modality, a battery level of the WTRU, an XRM modality, and / or video throughput; and / or determining to align delay-tolerant traffic with real-time traffic.

[0157] The PCF may transmit a report to the AF. For example, when the PDC receives a report from the WTRU, the PCF may transmit a report to the AF (e.g., based on the power status report) (e.g., receiving a power report from the WTRU may trigger the PCF to transmit a report to the AF). The network device (e.g., the PCF) may transmit one or more updated rules to a user plane function (UPF) to update a protocol unit session associated with the WTRU, for example, based on the power status report. The report (e.g., the power status report) may trigger the PCF to transmit one or more updated N4 rules to the UPF for the PDU session of the WTRU.

[0158] Figure 3 An example network-initiated process 300 for communicating a power reporting policy to a WTRU is illustrated.

[0159] At 304, for example, the AF 302 may invoke a network open function (NEF) 310 application programming interface (API) to provide service information for the XRM service. For example, the AF 302 may transmit a message indicating service and / or power reporting information to the PCF 306 (e.g., via the NEF 310). The service information may include one or more of: one or more traffic descriptors, one or more QoS requirements, one or more QoS parameters associated with one or more (e.g., different) modalities of the XRM service, a WTRU identifier, and / or power state information associated with the WTRU, etc. For example, the AF may transmit media codec information to a network node (e.g., a PCF). The media codec information may include one or more QoS values.

[0160] When the WTRU 308 joins the XRM service, the AF 302 may be triggered to transmit service and / or power reporting information. The message 304 may include one or more (e.g., multiple) parameter sets. Each parameter set may be applicable to different power states. For example, when the WTRU 308 is battery powered and the energy stored in the battery is relatively low, one parameter set may be applied. When the WTRU 308 is battery powered and the energy stored in the battery is relatively high, another parameter set may be applied. When the WTRU 308 is mains powered, another parameter set may be applied. The parameters in each set (e.g., delay values) may be used to derive different PCC rule sets.

[0161] The AF 302 may indicate that the WTRU (e.g., the target WTRU) should be at a medium to high battery level for the XRM service. The AF 302 may (e.g., also) indicate a threshold value of the power level and / or battery level of the WTRU 308 involved to initiate the XRM service. For example, the AF 302 may require the WTRU (e.g., the target WTRU) to be greater than and / or equal to 20% battery level (e.g., and / or higher than a certain value in Watts (W) and / or mAh) in order to initiate the service. If the battery level of the WTRU 308 is less than 20% at the time of the AF request, the network (e.g., 5GS) may deny the AF request, which means that the WTRU 308 cannot sustain the service in terms of power consumption.

[0162] If authorized, the AF 302 may subscribe to power status information about the WTRU 308 for XRM services, and / or be notified, for example, when the WTRU battery level meets the AF power requirement (e.g., such as 20%). This battery level indication by the AF 302 may be a preference rather than a (e.g., strict) requirement.

[0163] The AF request (e.g., at 304) may include a preference as to whether the WTRU 308 is plugged in or unplugged. The AF may request and / or provide a preference as to whether the WTRU is plugged in or unplugged. For example, the AF 302 may indicate a preference for the WTRU 308 to be plugged in when the WTRU 308 is using a video modality, and / or may indicate no preference when the WTRU 308 switches tactile modalities. Additionally or alternatively, the AF may subscribe to changes in the plugged in / unplugged state of the WTRU.

[0164] The AF request (e.g., at 304) may indicate that the AF requires the network (e.g., 5GS) to configure the target WTRU with a power reporting policy and / or may include information such as a preferred reporting frequency. For example, for a video modality, the recommended reporting frequency may be 5 minutes, while for a tactile stream, the power reporting frequency may be 15 minutes. The AF 302 may (e.g., also) associate a power reporting frequency with one or more service characteristics, for example by indicating that reporting is required for a video modality after a predetermined number of video bursts have been exchanged with the WTRU (e.g., after 20 video bursts). The request from the AF may require a certain power reporting policy from the 5GS. The AF request may correspond to a subscription to a PCF. The AF request may correspond to subscription information (e.g., where the AF subscribes to the PCF for one or more events and / or event changes of the WTRU).

[0165] The AF 302 may indicate one or more events that trigger the WTRU 308 to report power status information. For example, the one or more events may include WTRU location information, and the power report may be included in the WTRU location information.

[0166] AF 302 may provide an indication of whether the XRM service allows the network (e.g., 5GS) to trade off QoE with power consumption savings. If so, AF 302 may provide one or more different service requirements with different power / power state information and / or one or more QoS parameters with different power / power state information. For example, power and / or battery power may be divided into five (5) different ranges; AF may provide 5 different QoS parameter sets. Each QoS parameter set may correspond to a respective one of the power ranges / modes. Each QoS parameter set may result in a different QoE.

[0167] In an example, the AF may provide a certain budget instead of the battery power and / or power level requirements. The certain budget may include, for example, a power budget requirement for a certain service in order to more efficiently manage the WTRU 308 power consumption. For example, if the AF 302 is requesting an XRM session for a certain time and / or duration, the AF 302 may include a WTRU power budget. The WTRU power budget may indicate an upper limit on the amount of power that the WTRU 308 consumes for that time and / or duration. This may be aligned with one or more other (e.g., new) time-related QoS aspects and the use of background data transfer (BDT) to request future sessions.

[0168] NEF 310 may forward the AF request including the power reporting information to PCF 306 .

[0169] At 312, the PCF 306 may generate one or more independent power reporting policies. For example, the PCF may generate one or more PCC rules for the media traffic flow based on the received media codec information and the trade-off between QoE and power consumption of the WTRU. The network node may generate the one or more PCC rules based on one or more of: determining one or more latency values; determining one or more of a video modality, a battery level of the WTRU, an XRM modality, and / or video throughput; and / or determining to align delay-tolerant traffic with real-time traffic. The PCF 306 that receives the message at 304 may be the PCF 306 that services the PDU session that the WTRU 308 uses for the XRM session. The PCF 306 serving the PDU session may forward this information to the PCF 306 serving the WTRU 308 for access and mobility policy, and / or the PCF 306 serving the WTRU 308 for access and mobility policy may generate a power reporting policy and / or transmit the power reporting policy to the WTRU 308.

[0170] The PCF 306 may use the service information provided by the AF 302 to generate one or more PCC rules and / or one or more power reporting policies. For example, the PCF 306 may use the service information provided by the AF 302 to generate one or more PCC rules and / or one or more power reporting policies. Additionally or alternatively, one PCF may generate one or more PCC rules while a second PCF generates a power reporting policy. The PCF 306 may (e.g., also) use information it has about the WTRU 308 (provided by the UDM, NWDAF, AMF 316, and / or the WTRU 308 itself) to generate one or more (e.g., appropriate) power reporting policies for the WTRU 308.

[0171] Having a second PCF (e.g., a PCF serving the WTRU 308 for access and mobility policy) generate a power reporting policy may cause the second PCF to receive information from the PCF of each of the PDU sessions serving the WTRU and / or use information from one or more (e.g., multiple) PDU sessions to form a single power reporting policy. Details of the power reporting policy are described herein.

[0172] If PCF 306 receives one or more different service requirements and / or QoS parameters corresponding to different power and / or charge state ranges at 304, PCF 306 may generate PCC rules for each power level value and / or range. The set of service requirements (e.g., PCC rules) may be indexed. The indexed PCC rules and / or service requirements may later be used, for example, by PCF 306 to signal to SMF 317 whether the applied PCC rule should be changed due to the charge and / or power state change. This may be signaled by PCF 306 transmitting an index of the PCC rule and / or service requirement to SMF 317.

[0173] In some examples, PCF 306 may transmit PCC rules, e.g., at 315a, to SMF 317. For example, PCF 306 may transmit PCC rules to SMF 317 servicing the PDU session (e.g., based on the XRM service description). PCC rules may be transmitted to SMF 317 by the PCF servicing the PDU session.

[0174] The SMF 317 may generate one or more QoS rules using the PCC rules and transmit the QoS rules to the WTRU 308. The SMF 317 may generate one or more (e.g., multiple) sets of QoS rules and / or transmit the one or more sets to the WTRU 308. Each QoS rule may be associated with a power state (e.g., low, medium, high, and / or mains powered). The WTRU 308 may determine to change one or more applied QoS rules when the WTRU determines that its power state has changed. The WTRU 308 may transmit an indication to the network when the WTRU determines to change the applied QoS rule. The WTRU 308 may provide an API to one or more applications, for example, to select one of the rule sets. The API may enable setting one or more values ​​of one or more (e.g., some) power reporting IEs (e.g., emulated power states). For example, a user may choose to run an application in a low power mode to save battery during a long trip. In an example, a user may select a lower power mode in the WTRU settings, which may trigger the selection of one or more low power QoS rules for one or more (e.g., all) applications. The WTRU 308 may prevent the user / application from selecting a target power state that is higher than the current power state.

[0175] The SMF 317 may generate one or more QoS profiles using the one or more PCC rules and / or may transmit the QoS profiles to the NG-RAN. The SMF 317 may generate one or more (e.g., multiple) sets of QoS profiles and / or transmit the one or more (e.g., multiple) sets to the NG-RAN. Each QoS profile may be associated with a power state (e.g., low, medium, high, and mains powered). For example, when the NG-RAN determines that the power state of the WTRU 308 has changed, the NG-RAN may determine to change the QoS profile to apply. The NG-RAN may make this determination when it receives an indication that the power state of the WTRU has changed.

[0176] The PCF 306 may communicate the power reporting policy to the WTRU 308. For example, if the power reporting policy is generated by the PCF serving the PDU session, the policy may be communicated to the WTRU 308 via the SMF 317 and / or the AMF 316 and / or NAS session management (SM) messaging. For example, at 315a, the power reporting policy may be communicated from the PCF 306 to the SMF 317. At 315b, the SMF 317 may communicate the power reporting policy to the WTRU 308 (e.g., via a NAS session management (SM) (NAS-SM) message). For example, if the power reporting policy is generated by the PCF serving the WTRU 308 for access and mobility, the policy may be communicated to the WTRU 308 via the AMF 316 and / or NAS mobility management (MM) messaging. For example, at 314a, the PCF 306 may communicate the power reporting policy to the AMF 316. At 314b, the AMF 316 may transmit the power reporting policy to the WTRU 308 via a NAS-MM message.

[0177] At 318, the PCF 306 may transmit the power reporting policy information to the WTRU 308 as part of and / or with the URSP rules. With the URSP rules may mean that the PCF 306 transmits the power reporting policy to the WTRU 308, the power reporting policy including an identifier indicating the URSP rules and / or the RSD of the URSP rules. When the traffic matches the URSP rules and / or the RSD, the WTRU 308 may apply the power reporting policy. For example, if the AF 302 provided one or more traffic descriptors associated with one or more power reporting requirements at 304, the power reporting policy may be included as part of the URSP rules having the traffic descriptors as information. In this case, the WTRU power reporting policy may be included as part of the routing descriptor and / or the RSD.

[0178] The PCF 306 may include in the RSD information whether power reporting is to be activated if the WTRU 308 starts exchanging traffic matching the traffic descriptor of the URSP rule in question.

[0179] If the AF 302 provides WTRU location information in the case where battery reporting is required, the PCF 306 may include the provided WTRU location information in the RSD of the URSP rules, e.g., as a validation criterion. The WTRU 308 may report power information if (e.g., only if) the WTRU's location matches the location in the RSD.

[0180] For example, the PCF 306 may include a start and / or stop time (e.g., a time window) when power reporting is required. The time window may be included in the validation criteria of the URSP rules. The WTRU 308 may report the power status to the network (e.g., 5GS) during (e.g., only during) the time window provided by the power reporting policy in the URSP rules.

[0181] PCF 306 may (eg, also) include other power reporting information in one or more URSP rules (eg, as described herein).

[0182] At 320, after the PCF 306 has generated the URSP rules including the one or more power reporting policies, the PCF 306 may initiate a WTRU configuration update (UCU) procedure with the WTRU 308. The WTRU UCU may be used to provide the WTRU 308 with the one or more updated / provided (e.g., new) URSP rules for the XRM service and / or update the WTRU with the one or more updated / provided URSP rules.

[0183] At 322, the PCF 306 may notify the AF 302 that the WTRU power reporting policy deployment at the WTRU 308 was successful.

[0184] The WTRU may receive a message (e.g., a NAS message) with a power reporting policy from the PCF. The power reporting policy may indicate to the WTRU which events trigger and / or stop the power monitoring process. The power reporting policy may indicate to the WTRU where to transmit the power report. The power reporting policy may include the type of content related to the power state to be included in the power report. The power reporting policy may indicate to the WTRU which events trigger the WTRU to transmit a power report. The power reporting policy may indicate to the WTRU certain actions that should be taken based on the content of the power report and / or the detected conditions.

[0185] The WTRU may determine to transmit a power report (e.g., a power status report) based on one or more of the following. For example, the WTRU may be triggered to transmit a power report by detecting a traffic type and / or detecting a change in power status (e.g., battery level, plug-in event, or unplug-in event).

[0186] The WTRU may transmit the power report to the location indicated in the power reporting policy. When the location is NF, the power report may be transmitted via NAS signaling. When the location is AF, the power report may be transmitted via application layer signaling.

[0187] The power report may include power status information (e.g., one or more battery characteristics, battery capacity, battery charge, time remaining to full charge, temperature level and / or power mode) and / or a report reason code indicating which event triggered the WTRU to transmit the report.

[0188] Figure 4 An example WTRU-initiated process 400 is illustrated for communicating a power reporting policy to a WTRU 402. In the example WTRU-initiated process 400, the network may configure the power reporting policy at the request of the WTRU 402 (eg, rather than the AF 404).

[0189] At 406, the WTRU 402 may initiate a request to the network to configure one or more power reporting policies at the WTRU 402. The WTRU 402 may request the network to configure an initial power reporting policy for the WTRU. The initial power reporting policy may be a basic and / or a general power reporting policy.

[0190] When exchanging some user plane services, the WTRU 402 may determine to report its power state information to the network (e.g., and / or determine that the WTRU 402 may need to monitor the power state by the network). For example, if the application itself does not provide information about power state requirements and / or power reporting and the WTRU 402 wants to provide some pre-configured power reporting policies to be activated when using a certain type of service, the WTRU 402 may determine to report power state information. For example, the WTRU may want the 5GS to obtain one or more pre-configured power reporting policies from the WTRU and / or configure the power reporting policies for the WTRU, and / or may activate the configured power reporting policies. For example, if an XRM application is using a specific network slice, the WTRU 402 may want to be configured with a power reporting policy even though the application itself may not provide such power reporting information.

[0191] At 408a, the WTRU 402 may transmit a request to the network (e.g., 5GS) via NAS signaling (e.g., NAS-MM message) to the AMF, which then forwards the request to the PCF 410 (e.g., at 408b) to indicate that the request is configured for power reporting. The network node may receive the power reporting policy via a NAS-MM message.

[0192] At 412, the PCF 410 may receive a WTRU initiated power reporting policy configuration request. The PCF 410 may generate one or more power reporting policies for the WTRU 402. The PCF 410 may use information available at the UDM, NWDAF, and / or AMF, and / or information provided by the WTRU 402 to generate the power reporting information.

[0193] At 414, when the power reporting policies are generated, the PCF 410 may provide the WTRU 402 with the generated one or more power reporting policies.

[0194] At 416, the PCF 410 may notify the AF 404 that the WTRU reporting policy has been configured by calling the NEF API. The PCF 410 may provide the AF 404 with relevant reporting information.

[0195] At 418, according to the policy provided by the PCF, the WTRU 402 may begin reporting its power state to the network. For example, the WTRU may transmit a power state report to the network (e.g., 5GS). The WTRU may transmit a power state report to the network according to the power reporting policy. The power state report may include power state information associated with the WTRU and / or an indication indicating a determined trigger for transmitting the power state report. The WTRU may transmit to the network node one or more of: a battery charge of the WTRU, a capacity of the battery charge of the WTRU, one or more characteristics of the battery of the WTRU, an indication of the time remaining to fully charge the battery of the WTRU, a temperature level of the battery of the WTRU, and / or a power mode of the WTRU.

[0196]

[0066] Embodiments are described herein for one or more transmission options for a power state from a WTRU.

[0197] Figure 5 An example process 500 for a WTRU to transmit a power report (eg, a power status report) to a network is illustrated.

[0198] At 502, the WTRU 504 may have been configured with a power reporting policy, for example, using a network-initiated and / or WTRU-initiated WTRU power reporting policy deployment procedure, as described herein. The WTRU 504 may be triggered (e.g., later at 502) to transmit a power report. As described herein, the WTRU 504 may determine that one or more triggering events have occurred based on the policy. The WTRU 504 may prepare a power report according to the power reporting policy and / or may prepare to transmit a power report to the network (e.g., 5GS).

[0199] The following options for the WTRU 504 to transmit power reports may be configured by the network in the power reporting policy.

[0200] In a first option (e.g., at 525), the WTRU 504 may transmit a WTRU power report to the network (e.g., 5GS) via the control plane (e.g., at 506a). At 506b, the WTRU 504 may transmit the power report to the PCF (e.g., PCF-M 510) that is serving the WTRU for the AM policy. The power report may be transmitted via a NAS-MM message.

[0201] At 508, the PCF serving the WTRU for the AM policy (e.g., PCF-M 510) may forward information from the power report to the PCFs serving the WTRU's PDU sessions (e.g., PCF-S 512), if those PCFs are interested (e.g., have subscribed to power status notifications).

[0202] For example, when a PCF (e.g., PCF-S 512) serving a PDU session receives a power report, the PCF (e.g., PCF-S 512) may perform one or more actions. For example, at 514, the PCF may change (e.g., update) one or more PCC rules. At 516, the PCF (e.g., PCF-S 512) may transmit a notification to the AF 518. At 520, the PCF (e.g., PCF-S 512) may transmit a power status indication to the SMF 522. At 524, the SMF 522 may forward the indication to the RAN 528 (e.g., via N2 messaging). For example, the SMF 522 may forward the indication to the RAN 528 so that the RAN 528 may make one or more adjustments (e.g., change one or more CDRX parameters at 526).

[0203] In a second option (e.g., at 550), the WTRU 504 may be configured to transmit power reports via a user-facing network (e.g., 5GS).

[0204] The WTRU 502 may transmit a user plane message including a power report to the AF 518. At 552a, the WTRU 504 may transmit a user plane message including a power report to the serving UPF 554. The user plane message may be application layer signaling. The user plane message may go directly to the AF 518 (e.g., via the UPF 554, but the UPF 554 does not understand the user plane message) (e.g., at 552b).

[0205] After receiving the power report, AF 518 may transmit a request to adjust QoS to a PCF (eg, PCF-S 512) servicing the PDU session at 556. For example, the network device may receive a request to adjust one or more QoS rules from the AF.

[0206] At 558, the PCF (eg, PCF-S 512) may update and / or modify one or more PCC rules. The PCF (eg, PCF-S 512) may update and / or modify one or more PCC rules, for example, based on the AF request 556.

[0207] In option 1 (e.g., at 525) and / or in option 2 (e.g., at 550), when the WTRU 504 is configured by the CN to transmit one or more (e.g., some) power reports, the one or more power reports may or may not be visible to the RAN 528. For example, if the RAN 528 desires to perform one or more (e.g., some) actions (e.g., change the WTRU state from CONNECTED to INACTIVE), the WTRU 504 may include the one or more reports in a RAN-visible container when transmitting to the CN.

[0208] In a third option (eg, at 575 ), the WTRU 504 may transmit power reports to the RAN 528 only.

[0209] At 560, the WTRU 504 may transmit a power report to the RAN via RRC signaling. Depending on the type of event to be reported and / or one or more other IEs of the power reporting policy (e.g., such as reporting frequency), the WTRU 504 may transmit one or more power-related reports and / or indications to the RAN 528 (e.g., gNB) via an UL MAC control element (CE) and / or uplink control information (UCI) message and one or more RRC messages, which may be included as part of access stratum (AS) layer signaling. Since the one or more UL signaling messages may have different latencies (e.g., MAC CE may provide a fast signaling communication exchange between the WTRU 504 and the gNB compared to RRC), the WTRU 504 may be configured with one or more different periods and / or may transmit one or more power reports to the RAN 528 (e.g., dynamically).

[0210] At 562, the RAN 528 may use the power report to perform one or more actions. For example, the RAN 528 may change one or more CDRX settings (eg, change one or more CDRX parameters).

[0211] The WTRU may be configured in the power reporting policy as to whether to transmit power reports using option 1 (eg, at 525), option 2 (eg, at 550), and / or option 3 (eg, at 575).

[0212] The network may instruct the WTRU to perform one or more actions based on the power report. One way to configure the WTRU to perform one or more actions based on the power report is to generate instructions for the WTRU. One or more generated instructions for the WTRU may be associated with a specific service such as XRM. The generated instructions may include one or more URSP rules. The one or more URSP rules may have a power state entry (e.g., and / or other power reporting IE entries, such as simulated power states) as a service descriptor component of the URSP rule. The power state entry may be a WTRU power level. The 5GS (e.g., PCF) may generate one or more different URSP rules with one or more different RSDs for one or more (e.g., various) WTRU power levels.

[0213] One or more (e.g., some) parameters in the RSD may be changed. One or more (e.g., some) of the parameters that may be changed in the RSD may depend on a power reporting IE entry (e.g., a WTRU power level). Based on the power reporting IE entry, the one or more parameters that may be changed may include a session and service continuity (SSC) mode value and / or an access type preference. For example, if the WTRU power level is below 20%, the WTRU may be instructed to use the RSD that has Wi-Fi as the preferred access type in the URSP rules. For example, if the WTRU power level is above 50%, the WTRU may be instructed to use the RSD that has 3GPP as the preferred access type in the URSP rules.

[0214] Figure 6 An example process 600 is illustrated that shows which processes may be initiated in the network based on the contents of a power report from a WTRU.

[0215] At 604, the WTRU 602 may be configured with a power reporting policy for XRM services, as described herein.

[0216] At 606a, the WTRU 602 may transmit a power status report. When one or more conditions for reporting the WTRU power status are met, the WTRU 602 may transmit the power status report. The WTRU 602 may transmit the power status information to the network (e.g., 5GS). The WTRU 602 may transmit the power status information to the network (e.g., 5GS) via the user plane or the control plane, as described herein. For example, the WTRU 602 may transmit the power status report to the SMF 608. At 606b, the SMF 608 may forward the received WTRU power report (e.g., at 606b) to the serving PCF 610. The WTRU 602 may transmit the power status information to the AMF and / or the AMF may transmit the power status information to the PCF 610.

[0217] The PCF 610 may receive the WTRU power report at 616. Based on the power report content, the PCF 610 may perform one or more corresponding actions, including the following.

[0218] If one or more service requirements from the AF 612 are provided to the PCF 610, and the WTRU 602 is unable to meet the one or more service requirements and the power and / or battery level along with the service requirements that the WTRU is unable to meet, the PCF 610 may notify the AF 612 that the WTRU 602 is unable to meet the one or more service requirements. The AF 612 may in turn provide the PCF 610 with one or more other (e.g., new) service requirements and power policy information via the NEF 614. The PCF 610 may use the one or more other (e.g., new) requirements to update and / or generate one or more PCC rules and / or one or more power reporting policies (e.g., if necessary). The PCF 610 may forward one or more corresponding N4 rules, one or more QoS profiles, and / or one or more QoS rules to the SMF 608 (e.g., at 622a), the RAN 618 (e.g., at 622b), and / or the WTRU 602 (e.g., at 622c), respectively. For example, PCF 610 may transmit updated PCC rules to the same SMF or a different SMF based on the XRM service, service description information, QoS parameters, and / or PDU session carrying the service.

[0219] If the PCF 610 is provided with one or more (e.g., multiple) service requirements from the AF 612 as well as power state information (such as required, preferred power / battery level and / or mode), then based on the WTRU power report, the PCF 610 may update one or more enforced PCC rules and / or may generate and / or enforce one or more other (e.g., new) PCC rules using one or more different QoS parameters from a set previously provided by the AF 612. If the PCF 610 has indexed these rules with certain index values, and the PCF 610 has provided alternative N4 rules, QoS profiles, and / or QoS rules to the SMF 608 (e.g., at 622a), the RAN 610 (e.g., at 622b), and / or the WTRU 602 (e.g., at 622c), respectively, the PCF 610 may transmit the index values ​​of one or more other (e.g., new) rules for use by the network (e.g., 5GS) and / or the WTRU 602. For example, the PCF 610 may transmit updated PCC rules to the same SMF or to different SMFs based on the XRM service, service description information, QoS parameters, and / or PDU sessions carrying the service.

[0220] If (e.g., also) one or more alternative QoS parameters of a set of configurations known to the application are provided to the PCF 610, such as a frame rate (e.g., which may take values ​​of 60, 90, and / or 120, etc.), then based on the WTRU power report, the PCF 610 may change the selected configuration (e.g., the frame rate). For example, the PCF 610 may change the frame rate from 90 frames per second (fps) to 60 fps, which may reduce the video modality throughput and / or the WTRU power consumed associated with the modality. At 620, if the set of QoS requirements provided by the AF 612 has been indexed by the PCF 610, the PCF 610 may report the index of the changed configuration to the AF 612. Additionally or alternatively, for example, in a scenario using multimodal streams, one or more streams of lesser importance may be stopped. For example, in an application using an audio stream, a video stream, and / or a tactile stream, if the battery level is below a predetermined battery level threshold (e.g., 10%), the tactile stream may be stopped. Stopping the haptic stream when the battery charge drops below a predetermined battery charge threshold can further conserve battery.

[0221] If the AF service requirement is to not exceed a certain latency for one or more modalities (e.g., 20ms for the video modality), the AF 612 may provide the following information. For low battery power, the video modality may use a frame rate of 60fps or 90fps. For medium to high battery power, the video modality may use a frame rate of 90fps, 120fps, or 240fps.

[0222] In an example, if the video modality used is 240fps and / or the WTRU power report indicates a medium to high battery level, the 5GS / PCF 610 may continue to use 240fps, or may use a frame rate of 120fps (e.g., which may reduce video throughput and / or may reduce WTRU power consumption for XRM services). The network may meet the 20ms latency requirement and / or may use a (e.g., appropriate) frame rate for the reported battery level while reducing power consumption.

[0223] The PCF may use the WTRU power reports, information from the AF 612, and / or one or more other network functions (such as NWDAF) to determine how to better plan the handover of the WTRU. If different modalities are forwarded to different WTRUs, the PCF may use the power reports from the WTRUs to better plan the group handover of the XRM service.

[0224] For example, based on the WTRU power reports, the network (e.g., 5GS) may optimize power consumption by aligning delay-tolerant services with real-time services. For example, the network (e.g., 5GS) may defer non-guaranteed bit rate (GBR) services within a PDU session carrying XRM services with the XRM services themselves. For example, if non-GBR services are delay-tolerant, deferring the services so that they are sent in parallel with the XRM PDUs may help reduce power consumption. The PCF and / or SMF may decide to defer non-XRM services with XRM services. Additionally or alternatively, if one or more different XRM modalities are considered, the PCF and / or SMF may align (e.g., at least slightly) PDUs, PDU sets, and / or bursts of one or more different modalities at certain times (e.g., ensuring that PDU sets are received within the same time window of other modalities), while trying to ensure that the modalities do not significantly lose synchronization.

[0225] The AF may provide information to the 5GS about whether the PDUs in a PDU set are to be processed together. For example, one or more SSC modes may be selected to provide processing mobility and / or data flows during a PDU session. For example, SSC mode 1 of PDU set processing may include that if a PDU is lost, the remaining PDUs in the PDU set are not delivered to the WTRU. SSC mode 2 may be defined as the network delivering the remaining PDUs in the PDU set to the WTRU even if up to a certain percentage of some PDUs are lost. Using this aspect, based on the WTRU power report, the PCF may determine one or more of the following. For example, if the battery level is below a certain value and / or is low battery level, so that not transmitting the remaining PDUs in the PDU set can save WTRU power, the PCF may decide and / or recommend selecting SSC mode 1. The WTRU can save power because the WTRU receives fewer packets (for example, fewer packets can reduce throughput and / or WTRU power consumption). The PCF may decide and / or recommend selecting SSC mode 2 so that (for example, still) one or more remaining PDUs in a PDU set are transmitted even if a certain percentage x of PDUs are lost. The network and / or AF may recommend and / or decide to reduce the percentage x (e.g., the tolerance for PDU loss within a PDU set) and / or (e.g., so that) all x packets not transmitted to the WTRU in this context may be increased, and / or increasing the packets not transmitted to the WTRU may save WTRU power.

[0226] In an example, the WTRU may perform one or more (e.g., some) actions by requesting (e.g., directly requesting) updates to required XR assets (e.g., by requesting streaming video segments at a lower data rate using the Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH) protocol and / or by requesting lightweight XR assets for minimizing rendering computations, etc.). The network may be informed that the WTRU requests updates to required XR assets. For example, the AF may make the network aware of such requests. The network may be made aware of such requests so that the network may be aware that such events may occur. The WTRU may request updates to one or more changes regarding one or more (e.g., some) application service related information (e.g., XR assets). For example, if the network authorizes such requests, the network may monitor one or more update changes (e.g., events when they occur). The network may notify the WTRU of one or more events. For example, the network may configure the WTRU to notify the network when the WTRU requests such changes (e.g., power-related and / or power-aware).

[0227] These one or more direct WTRU requests may be handled separately from the network-based power consumption management described herein.

Claims

1. A method, comprising: receiving a message indicating an identifier of a wireless transmit / receive unit (WTRU) and one or more parameters associated with a power state of the WTRU; generating a power reporting policy based on the received message, wherein the power reporting policy includes one or more triggers associated with transmitting a power status report; transmitting the power reporting policy to the WTRU; receiving the power status report from the WTRU according to the power reporting policy, wherein the power status report includes one or more battery characteristics associated with the WTRU; and One or more policy charging and control (PCC) rules are updated based on the power status report.

2. The method of claim 1, wherein the one or more triggers include one or more of: a battery charge of the WTRU, an unplugged state of the WTRU, a temperature level of the WTRU, a time of day, a bit rate parameter, activation of an application, or deactivation of an application.

3. The method according to claim 1, further comprising: The one or more parameters are used to configure the WTRU for extended and multimodal reality (XRM) services.

4. The method according to claim 1, further comprising: When the power reporting policy is created or based on a request received from the WTRU, it is determined to transmit the power reporting policy to the WTRU.

5. The method according to claim 1, further comprising: transmitting a power status indication to a session management function (SMF) or a radio access network (RAN) based on the power status report; transmitting a report to an application function (AF) based on the power status report; or One or more updated rules are communicated to a user plane function (UPF) based on the power status report to update a protocol data unit session associated with the WTRU.

6. The method according to claim 1, further comprising: generating a first set of policy charging and control (PCC) rules based on one or more of: one or more extended and multimodal reality (XRM) service requirements, one or more quality of service (QoS) requirements for XRM traffic, or power state information of the WTRU; transmitting the first set of PCC rules to a session management function (SMF) to generate a first set of one or more QoS rules to be transmitted to the WTRU; as well as Based on the power state of the WTRU, a second set of PCC rules is transmitted to the SMF to generate a second set of one or more QoS rules to be transmitted to the WTRU.

7. The method of claim 1 , wherein the one or more triggers include one or more of the following: causing the WTRU to transmit the power status report based on determining that the battery level of the WTRU is below a threshold; causing the WTRU to transmit the power state report based on detecting a traffic type; a trigger for a frequency at which the WTRU is to transmit the power status report; or A trigger causes the WTRU to stop transmitting the power state report based on one or more of: detecting a change in power state, determining that the WTRU is plugged in or charging, time of day, or determining that the battery charge of the WTRU is at or above a threshold.

8. The method according to claim 1, further comprising: Receive media codec information from the application function (AF); as well as One or more policy and change (PCC) rules are generated for a media traffic flow based on the received media codec information and a tradeoff between quality of experience (QoE) and power consumption of the WTRU.

9. The method of claim 8, wherein receiving media codec information comprises receiving one or more quality of service (QoS) values.

10. The method of claim 8, wherein the one or more PCC rules are generated based on one or more of: determining one or more delay values; determining one or more of a video modality, a battery level of the WTRU, an Extended and Multimodal Reality (XRM) modality, or a video throughput; or Determine the alignment of delay-tolerant services with real-time services.

11. A network node, comprising a processor and a transceiver, wherein the processor is configured to: receiving, via the transceiver, a message indicating an identifier of a wireless transmit / receive unit (WTRU) and one or more parameters associated with a power state of the WTRU; generating a power reporting policy based on the received message, wherein the power reporting policy includes one or more triggers associated with transmitting a power status report; transmitting, via the transceiver, the power reporting policy to the WTRU; receiving, via the transceiver, the power status report from the WTRU in accordance with the power reporting policy, wherein the power status report includes one or more battery characteristics associated with the WTRU; and One or more policy charging and control (PCC) rules are updated based on the power status report.

12. The network node of claim 11, wherein the one or more triggers include one or more of: a battery charge of the WTRU, an unplugged state of the WTRU, a temperature level of the WTRU, a time of day, a bit rate parameter, activation of an application, or deactivation of an application.

13. The network node according to claim 11, wherein the processor is further configured to: The one or more parameters are used to configure the WTRU for extended and multimodal reality (XRM) services.

14. The network node of claim 11, wherein the processor is further configured to: When the power reporting policy is created or based on a request received from the WTRU, it is determined to transmit the power reporting policy to the WTRU.

15. The network node of claim 11, wherein the processor is further configured to: transmitting, via the transceiver, a power status indication to a session management function (SMF) or a radio access network (RAN) based on the power status report; transmitting, via the transceiver, a report to an application function (AF) based on the power status report; or One or more updated rules are communicated to a user plane function (UPF) via the transceiver based on the power status report to update a protocol data unit session associated with the WTRU.

16. The network node of claim 11, wherein the processor is further configured to: generating a first set of policy charging and control (PCC) rules based on one or more of: one or more extended and multimodal reality (XRM) service requirements, one or more quality of service (QoS) requirements for XRM traffic, or power state information of the WTRU; transmitting, via the transceiver, the first set of PCC rules to a session management function (SMF) to generate a first set of one or more QoS rules to be transmitted to the WTRU; and Based on the power state of the WTRU, a second set of PCC rules is transmitted to the SMF via the transceiver to generate a second set of one or more QoS rules to be transmitted to the WTRU.

17. The network node of claim 11, wherein the one or more triggers include one or more of the following: causing the WTRU to transmit the power status report based on determining that the battery level of the WTRU is below a threshold; causing the WTRU to transmit the power state report based on detecting a traffic type; a trigger for a frequency at which the WTRU is to transmit the power status report; or A trigger causes the WTRU to stop transmitting the power state report based on one or more of: detecting a change in power state, determining that the WTRU is plugged in or charging, time of day, or determining that the battery charge of the WTRU is at or above a threshold.

18. The network node of claim 11, wherein the processor is further configured to: receiving media codec information from an application function (AF) via the transceiver; and One or more policy and change (PCC) rules are generated for a media traffic flow based on the received media codec information and a tradeoff between quality of experience (QoE) and power consumption of the WTRU.

19. The network node of claim 18, wherein receiving media codec information comprises receiving one or more quality of service (QoS) values.

20. The network node of claim 18, wherein the one or more PCC rules are generated based on one or more of: determining one or more delay values; determining one or more of a video modality, a battery level of the WTRU, an Extended and Multimodal Reality (XRM) modality, or a video throughput; or Determine the alignment of delay-tolerant services with real-time services.

Images