Method and device for providing energy policy-based media service in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. An operation method of a terminal in a wireless communication system according to an embodiment of the present disclosure may comprise the steps in which: the terminal receives, from an application function (AF) of a network, service access information including first information about an energy source type; the terminal selects, on the basis of the first information, an energy source type used by the network; and the terminal transmits second information about the selected energy source type to the AF of the network.

Description

Method and device for providing energy policy-based media services in a wireless communication system

[0001] The present application relates to wireless communication systems, and more particularly to 5G media streaming (5GMS) architecture and SWAP protocol control.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] The present disclosure allows service providers and telecommunications providers to select the energy source to be used for the services they wish to provide, and to use multiple different energy sources for the same service.

[0009] This disclosure enables service providers and telecommunications providers to provide service characteristic information that may vary depending on the energy source.

[0010] This disclosure enables businesses or users to establish conditions according to energy policies, generate events according to the conditions, and perform actions according to the events.

[0011] This disclosure allows users to identify the energy source used by a service they wish to use, and to select and use one of several different energy sources for the same service.

[0012] Through this disclosure, it is possible to make a judgment by considering service characteristic information that varies depending on the energy source when selecting a service.

[0013] This disclosure allows for establishing policies on energy consumption, receiving events reporting changes in the energy consumption of a service, and executing or modifying policies accordingly.

[0014] The solution for solving the problem of the present disclosure is as follows.

[0015] In order to provide multimedia services based on energy policies, mobile communication service providers may have at least one energy source for mobile communication components and provide energy consumption information.

[0016] Mobile communication components, including user equipment (UEs), can specify a preferred energy source or energy consumption for high-level or low-level requests as a policy. (A high-level request can be divided into multiple low-level requests.)

[0017] Mobile communication components can provide services with priority given to the use of requested preferred energy sources and provide information on the expected energy consumption to be used in the service and the actual energy consumption after the completion of an operation, by energy source.

[0018] Energy consumption information provided by mobile communication components can be divided into common energy consumption for framework operation and request waiting, energy consumption for user wireless connectivity, and energy consumption for providing multimedia services to users.

[0019] Mobile operators can manage credits, which are values ​​for the total amount of energy a user can use for a user account, to provide multimedia services based on energy policies.

[0020] Credits may be deducted based on the amount or percentage of energy consumed by the service upon receiving the service. Credits may be deducted, not deducted, or even increased depending on the type of energy source consumed by the service. For example, the credit deduction rate for using energy sources classified as environmentally friendly may be lower than for those using non-environmentally friendly sources.

[0021] At least two sub-mobile communication components identified as using different energy sources while providing the same service may have different characteristic values ​​for the same service characteristics, in addition to their different energy sources. For example, a service using an energy source with a low, non-deductible, or increasing credit deduction rate may incur trade-offs such as longer latency, lower speed, or lower quality.

[0022] Users can determine the expected credit consumption for receiving a service, determine the appropriate consumption, establish an energy consumption policy for receiving the service by combining two or more energy path options, and set this on the service provider's server, etc.

[0023] Credits consumed in receiving services can be tracked by the user UE and the service provider, and periodically settled with each other. Events that occur when more credits are consumed than initially predicted (e.g., new server allocations, duplications, etc. due to user movement) or when a target consumption limit is reached, such as advance warnings, can be received, and the energy path can be changed or a new energy consumption policy can be established accordingly.

[0024] The present disclosure identifies and enables selection of a source of energy used to realize a service that a user wishes to consume, such as a multimedia service such as messaging, calling, internet browsing, video and music viewing, through mobile communication.

[0025] The framework provided by the present disclosure provides the ability to distinguish between energy sources used to provide services, thereby enabling service providers and receivers to understand the diversity of resources and the extent to which each energy source is consumed.

[0026] The distinction of energy sources in this disclosure allows consumers to consider the diversity of energy sources and effectively select a service that uses the optimal energy source by taking into account various environmental factors such as personal values, energy efficiency, and use of renewable energy.

[0027] Figure 1 illustrates the components of the 5GMS architecture and the interfaces for interoperability.

[0028] Figure 2 illustrates a conventional media service search and reception step.

[0029] FIG. 3 is a diagram of the Simple WebRTC Application Protocol (SWAP) protocol, illustrating negotiation between UEs or servers designated as endpoints in WebRTC data communication.

[0030] FIG. 4 illustrates an architecture proposed in this disclosure, in which an Energy Policy Manager (EPM) is installed within the MSH to receive energy-related information provided by a mobile communication service and then establish an energy policy.

[0031] FIG. 5 illustrates a mobile communication service that receives an amount of received data or energy from each energy source from a UE and receives an operating status from mobile communication components including a UPF.

[0032] Figure 6 illustrates a process for receiving a combined energy consumption report from network components.

[0033] Figure 7 illustrates a method for summing the energy consumption of network components.

[0034] Figure 8 illustrates a process in which an Energy Report is generated for each NF's request and periodically reported to the ENF (or Energy Management Department), and the ENF examines the Report based on an energy policy acceptable to the UE and determines whether to continue the operation and responds.

[0035] Figures 9a and 9b illustrate a process for determining energy-related policies by considering trade-off information.

[0036] FIG. 10 illustrates the structure of a terminal according to one embodiment of the present disclosure.

[0037] FIG. 11 illustrates the structure of a server according to one embodiment of the present disclosure.

[0038] FIG. 12 illustrates the structure of a network component according to one embodiment of the present disclosure.

[0039] 0-1. 5G Media Service

[0040] Figure 1 illustrates the components of the 5GMS architecture and the interfaces for interoperability.

[0041] Mobile communication services can provide services such as messaging, voice / video calls, internet browsing, and multimedia services based on connectivity to UEs. In this regard, 5GMS (5G Media Service) can be considered as an example of an architecture for 3GPP media services. While the example of this disclosure may be described in the form of a feature addition to 5GMS, it is not limited to 5GMS.

[0042] The 5GMS architecture consists of the MSH, MAF, 5GMS-aware applications, AF, AS, and AP. Each can be described as follows.

[0043] Media Session Handler (MSH): A UE function that communicates with the AF to establish, control, and support media session delivery, and may perform additional functions such as collecting and reporting consumption and QoE metrics. The MSH may expose APIs that can be used by 5GMS-aware applications.

[0044] Media Access Function (MAF): Communicates with AS to stream media content in real-time or download media content in non-real-time (e.g. for later consumption) and provides APIs for UE's functional media playback and media session control to 5GMS-aware applications.

[0045] 5GMS-aware applications: 5GMS clients are typically controlled by external media applications (e.g., apps that implement external application or content service provider-specific logic and can establish media sessions). 5GMS-aware applications are not defined within the 5G media streaming specifications, but their functionality leverages 5GMS interfaces and APIs to leverage 5GMS client and network capabilities.

[0046] 5GMS Application Server (hereinafter referred to as AS): This is an application server that hosts 5G media functions. There can be various AS implementations, including distributing AS functions across multiple physical hosts, such as a Content Delivery Network (CDN), and it provides features such as content hosting, caching, geo-restriction (geofencing), server certificate support, and URL signing.

[0047] 5GMS Application Provider (AP): External application or content-specific media functions (e.g., media creation, encoding, and formatting using the 5GMS interface to stream media to 5GMS-aware applications).

[0048] 5GMS Application Function (AF): An application function that provides various control functions to the UE's MSH and / or AP. It can relay or initiate requests for other policy or charging function (PCF) processing, or interact with other network functions via the Network Equipment Function (NEF).

[0049] The interfaces defined for 5GMS are:

[0050] M1 (5GMS Provisioning API): An external API exposed by AF that allows APs to provision and obtain feedback on the use of the 5G media streaming system for downlink media streaming.

[0051] M2 (5GMS Ingest API): An optional external API exposed by an AS when a trusted DN (Data Network) AS is selected to host content for streaming services.

[0052] M3: Internal API used by AF to configure and manage AS instances.

[0053] M4 (Media Streaming API): An API that AS exposes to media players to stream media content in real time or download media content in non-real time.

[0054] M5 (Media Session Handling API): An API exposed by AF to MSH to support media session handling, control, reporting, and appropriate security mechanisms (e.g., authorization and authentication).

[0055] M6 (UE Media Session Handling API): An API exposed to media players by MSH for client internal communication and to 5GMS-aware applications to enable 5GMS functionality.

[0056] M7 (UE Media Player API): API exposed by the media player to 5GMS aware applications and MSHs to use the media player.

[0057] M8: (Application API): Application interface used for information exchange between 5GMS-aware applications and APs (e.g., providing service access information to 5GMS-aware applications). This API is external to the 5G system and is not specified by 5GMS.

[0058] Figure 2 illustrates a conventional media service search and reception step.

[0059] First, the aforementioned M1, M2, M4, and M5 interfaces are indicated by block arrows. The information exchange steps between the 5GMS Client, AF, AS, and AP are as follows.

[0060] Step 201. The AP uses the AF to create a provisioning session and initiates provisioning for the 5G media streaming system. During the setup phase, the capabilities to be used are negotiated and detailed configurations are exchanged. The AF receives service access information for M5 (media session processing), and if media content hosting is negotiated, it also receives service access information for M2 (collecting) and M4 (media streaming). This information is required for the 5GMS Client to access the service. Depending on the provisioning, only a reference to the service access information may be provided.

[0061] Step 202. Once content hosting is provided and selected, interaction may occur between the AF and the AS at baseline M3. For example, configuring server certificates and / or content preparation templates and allocating 5GMS content collection and distribution resources by providing: Content hosting configuration. The AS provides the AF with resource identifiers for the allocated resources, and the AF provides this information to the AP.

[0062] Step 203. The AP collects content and initiates a collection session. For live services, content is collected continuously. For on-demand streaming services, content can be uploaded once and then updated later.

[0063] Step 204. The AP provides service announcement information to the 5GMS-Aware application. The service announcement may contain full service access information (e.g., details about media session handling (M5) and media streaming access (M4)) or references or pre-configured information for service access information. If only references are included, the 5GMS Client retrieves the service access information when needed (Step 6). In certain cases, 5GMS services may be announced using the 3GPP service URL (see Section 4.10) that initiates the service defined in Section 9.

[0064] Step 205. When a 5GMS-Aware application decides to initiate streaming, service access information (full or reference) is provided to the 5GMS Client. The 5GMS Client activates a unicast downlink streaming session.

[0065] Step 206. (Optional) If the 5GMS Client only receives a reference to service access information, it obtains service access information from AF.

[0066] -The Service Access Information API is used to obtain configuration information from the AF so that the MSH can use the Media Session Handling API.

[0067] -The data model of Service Access Information includes streaming access, client consumption reporting configuration, dynamic policy invocation configuration, client metrics reporting configuration, network assistance configuration, and client edge resource configuration.

[0068] Step 207. The 5GMS Client uses the Media Session Processing API exposed by the AF of the M5d. The Media Session Processing API is used to configure content consumption measurement, logging, collection, and reporting. It also requests QoE metric measurement, logging, collection, and reporting, and other policy and billing processing. Alternatively, it supports AF-based networks. The actual usage time of the API varies depending on the features and interactions available during media content reception.

[0069] -M5 can be further divided into 5_1 and 5_2: 5_1 is the receive direction from AF to UE (e.g., reading service information), 5_2 is the transmit direction to AF (e.g., setting up a desired service).

[0070] -M5_1: Information sent to the MSH for parameter provisioning (policy descriptions generated by AF and AP). The policy description contains or references detailed service access information, i.e., a URL for activating a specific policy.

[0071] -M5_2: Information transfer from MSH to AF. Input for generating a Service Data Flow Template (see TS 23.503

[0033] ) to identify application data flows within a PDU session, identifiers for dynamic policy instances (e.g., QoS, conditional zero rating, charging, etc.), and network support information (e.g., bit rate recommendations).

[0072] Step 208. The 5GMS Client activates media content reception.

[0073] 0-2. Simple WebRTC Application Protocol (SWAP)

[0074] FIG. 3 is a diagram of the Simple WebRTC Application Protocol (SWAP) protocol, illustrating negotiation between UEs or servers designated as endpoints in WebRTC data communication.

[0075] 5G-RTC, a communication based on 3GPP's RTC, defined the Simple WebRTC Application Protocol (SWAP) to complement the existing WebRTC. The SWAP protocol is a protocol for negotiating between UEs or servers designated as endpoints in WebRTC data communication. In Fig. 3, when each endpoint transmits a SWAP message to WebRTC, the WebRTC signaling server acts as a SWAP server and performs an action for the requested message.

[0076] SWAP messages include Register, Response, Connect, Accept, Update, Reject, Close, and Application, and their descriptions are as follows.

[0077] -Register allows endpoints to register themselves with the SWAP server, providing matching criteria that can be used to match incoming connection requests to the SWAP server. Matching criteria for SWAP's Register include addresses, service identifiers, user identifiers, application identifiers, location identifiers, QoS identifiers, and processing profile identifiers.

[0078] ipv4: The IPv4 address of the target endpoint

[0079] ipv6: The IPv6 address of the target endpoint

[0080] fqdn: The FQDN of the target endpoint

[0081] service: An identifier of a service or an application

[0082] user: An identifier of the user such as a SIP address, a GPSI, or an MSISDN

[0083] eas: An EAS identifier

[0084] app: application-specific matching criteria that is compared using binary or string comparison

[0085] location: one or more identifiers of a geographic location or area

[0086] qos: a description of the QoS that is supported by the connection to the endpoint

[0087] processing: a profile description of the processing capabilities of the endpoint

[0088] -Response is the response that the SWAP server must send to every request it receives, indicating whether the message was acknowledged or contained an error.

[0089] -Connect is used to establish a connection between a source endpoint (the entity to be connected, such as a UE) and another endpoint (the target entity, such as a UE or server). The Connect message must include an SDP offer and a match condition, which is a parameter that identifies the target endpoint.

[0090] -Accept is a message sent when the endpoint accepts the source and contains the SDP answer.

[0091] -Update contains an updated SDP for adding / updating / removing media streams. The endpoint responds to an Update request from the source with an Accept message.

[0092] -Reject is sent when the endpoint does not accept the source's request, and contains an explanation of why the message was rejected.

[0093] -Close is triggered by either the source or the endpoint, and upon receipt, the opposite endpoint must respond with an Accept message, after which the WebRTC session is released and its associated resources are released.

[0094] -Applications are exchanged between endpoints as messages defined by the application. Messages must include type information (e.g., a URN) that uniquely identifies the type of application message. If the message type is not supported, the endpoint rejects it.

[0095] The operation of the SWAP protocol using this is as follows.

[0096] First, a registration phase is performed. One endpoint registers itself with the SWAP server. Other endpoints also register themselves with the SWAP server. During registration, matching conditions describing the endpoint's capabilities and address are submitted.

[0097] Next, the App-specific configuration phase is performed. In this phase, a matching condition is transmitted to specify the opposing endpoint. When the first endpoint sends an application message to the SWAP server, including configuration information for the application and the matching condition, the SWAP server forwards the configuration information of the first endpoint to the second endpoint that satisfies the matching condition. Once the configuration is completed at the second endpoint, the SWAP server forwards the connection information of the second endpoint to the first endpoint, thereby completing the application-specific negotiation phase.

[0098] The next step is the connection phase. The first endpoint sends the address of the second endpoint and an SDP offer in a Connect message, and the second endpoint sends an Accept message and an SDP answer. This completes the negotiation and establishes a data channel.

[0099] 1. Architecture

[0100] Figure 4 is an architecture proposed in this disclosure.

[0101] FIG. 4 illustrates an architecture proposed in this disclosure, in which an Energy Policy Manager (EPM) is installed within the MSH to receive energy-related information provided by a mobile communication service and then establish an energy policy.

[0102] The architecture according to the present disclosure has the following features compared to the aforementioned 5G MS architecture. An Energy Policy Manager (EPM) is provided within the MSH to receive energy-related information provided by a mobile communication service and establish an energy policy. An Energy-aware MAF (MAF) is provided to operate according to the energy policy compared to a conventional MAF. An Energy Management Function (EMF) is provided within the AF to provide energy information within a mobile communication service and provide services according to an energy policy established by a UE. An Energy-aware AS (AS) is provided to provide operations according to an energy policy compared to a conventional AS.

[0103] Additionally, the Energy Network Function (ENF) can be incorporated into the 5GC architecture to monitor and collect information on the energy consumed in the operation of NF units, which are mobile communication components. The distinction between EMF, a 5GMS architecture component, and ENF, a 5GC architecture component, can be distinguished based on whether the call level is NF level or media service level. However, since media services include NF level calls, the energy consumption can ultimately be added up, predicted, and calculated.

[0104] 2. Information

[0105] 2.1 Information on the business operator's energy source

[0106] Mobile communication service providers may provide at least one applicable energy source for mobile communication components for providing multimedia services and may notify the mobile communication components, including the user equipment (UE), of this energy source. Energy sources are sources used to produce electrical energy, and include various types, including those that utilize natural phenomena such as solar, hydroelectric, wind, tidal, and geothermal power; those that generate greenhouse gases such as carbon dioxide during power generation, such as oil and coal; and those that are classified as green energy based on the premise that radioactive waste can be managed without generating greenhouse gases, such as nuclear power (see Table 1). Mobile communication service providers may provide services using energy generated from one or more of the above energy sources, i.e., electricity. Mobile communication service providers may declare that they will provide services using energy regenerated from natural forces or nuclear energy, refrain from using energy that generates greenhouse gases, and pursue sustainable services by balancing the ratio of environmentally beneficial and environmentally harmful energy sources.

[0107] Additionally, a distinction can be made based on whether electricity generation using energy sources is internal to the service (Scope 1) or external (Scope 2). Users can determine whether the service includes electricity generation or uses external power.

[0108] As one embodiment of the invention, a mobile communication service may provide a list of energy source types that are available in the service and that can be specified when using a mobile communication component.

[0109] energySourceType Energy source type identifier - renewableEnergyThose that utilize natural phenomena such as solar, hydro, wind, and tidal power - greenHouseGasEnergyThose that generate greenhouse gases such as carbon dioxide during the power generation process, such as oil and coal - pseudoGreenEnergyThose that can be classified as a type of green energy under conditions that do not generate greenhouse gases, such as nuclear power - carbonCreditEnergyThose that are recognized as energy consumption equivalent to carbon emissions. For example, those that are recognized as having captured a certain amount of carbon through the use of the energy source - Scope 1 Includes power generation using energy sources - Scope 2 Receiving power supply from external power generation facilities / services - Scope 3 Other. The remainder excluding direct power generation and consumption for providing services

[0110] 2.2 Business operator's energy source-based service access information

[0111] A mobile communication service provider may, in the process of describing the media services it can provide in response to a service discovery request from a UE, provide information about the type of energy source used by the mobile communication service it provides.

[0112] In step 6 of the conventional flowchart of FIG. 2 described above, the AF provides Service Access Information (SAI) to the MSH of the UE via the M5 interface, and in step 7, information and policies such as consumption reporting, dynamic policies, indicator reporting, and network support can be mutually established and provided between the UE and the mobile communication service. The existing data model of SAI includes streaming access information, client consumption reporting configuration information, dynamic policy configuration information, client indicator reporting configuration information, network support configuration information, and client edge resource configuration information.

[0113] The mobile communication service according to the present disclosure may be provided for one or more types of energy sources available to the MSH of the UE. This may include streaming access information, client consumption configuration information, dynamic policy configuration information, client indicator reporting configuration information, network support configuration information, and client edge resource configuration information, as described below.

[0114] When included in streaming access information, the energy source type indicates the types of energy sources used by the media entry point and alternate media entry point. For example, if renewableEnergy is used, the energy source type may be displayed as renewableEnergy. When two or more energy sources are used in combination, the energy source information indicates the energy source types and the ratio of their respective usage. For example, if a media entry point uses a 40:60 ratio of renewableEnergy:greenHouseGasEnergy, it may be displayed in a double list format as [[renewableEnergy,40], [greenHouseGasEnergy,60]].

[0115] StreamingAccessType0..1RO5GMS Indicates if the application provider offers content hosting.> EntryPointArray(M5MediaEntryPoint)0..1RO5GMS A list of alternate media entry points that a client can choose from.> LocatorAbsolute URL1..1RODASH A pointer to a document in M2 that defines a media presentation, such as an MPD for the content or a URL for a video clip file.> ContentTypeString1..1ROThe MIME content type of this media entry point.> ProfileArray(Uri)0..1ROAn optional list of conformance profile URIs to which this media entry point conforms. If present, the array will contain one or more items.> EnergySourceTypeEnergySourceTypeIdentifier0..1ROThe types of energy sources used by the media entry point and alternate media entry points.> EnergySourceInfoArray(Object)0..1ROThe types of energy sources used by the media entry point and alternate media entry points. When two or more energy source types are used in combination, they are presented as a double list. Example: [[Energy Type Identifier 1,60],[Energy Type Identifier 2,30],[Energy Type Identifier 3,10]]]

[0116] When included in the client consumption configuration information or client metrics reporting configuration, it specifies whether the UE is required to report on energy consumption and the type of energy source for which the report is being made. Energy consumption represents the amount of energy consumed by the UE as calculated by reception. Units may be credits, energy amount, or the sum of received bits. The UE reports on the usage from the previous report to the current report. Reporting is limited to the energy source types specified in the reportable energy sources required by the mobile communication service; other reports may be submitted optionally but may ultimately be excluded and ignored. The UE's reception report and the mobile communication service's transmission log are generally expected to match, but a discrepancy can help detect services that operate regardless of the UE's reception. For example, data broadcast by a server remaining in a cell that the UE cannot receive for a UE that has left the cell may not be used and may therefore be considered a waste of energy. Through periodic verification and comparison, a mobile communication service can determine whether provided data has been received and minimize the energy consumed in producing data that has not been received. FIG. 5 illustrates a mobile communication service that receives an amount of received data or an amount of energy per energy source from a UE and receives an operating status from mobile communication components including a UPF. In the example, a UE moves from a first location to a second location, and may receive data broadcast from UPF #1 and data transmitted for the UE from UPF #2. At some point, depending on the location of the UE, when moving between cells, an Application Context Relocation (ACR) is performed between UPF #2 and #3, which may or may not be forwarded to UPF #1.When not being transmitted, UPF #1 may continuously generate data for UEs that have already left the cell, which may result in energy waste. According to the present disclosure, a mobile communication service that receives the amount of received data or energy per energy source from a UE and receives the operating status from mobile communication components including a UPF can immediately detect unused operations due to mismatch between transmission and reception and take measures such as suspending the operation of UPF #1, thereby preventing energy waste.

[0117] clientConsumptionReportingConfigurationType0..1RO5GMS Indicates if the application provider provides consumption reporting. > ReportingIntervalPeriod0..1ROThe time interval (in seconds) between consumption reporting messages sent by the media session handler. The value must be greater than 0. If this property is omitted, a single final report is sent immediately after the media streaming session ends. > ServerAddressArray(AbsoluteUrl)1..1RO A list of 5GMS AF addresses (URLs) to which the media session handler sends consumption reporting messages. Each address must be an opaque base URL following the 5GMS URL format, up to and including the {apiVersion} path element. > LocationReportingBool1..1RO Specifies whether the media session handler should provide location data to the 5GMS AF in consumption reporting messages (for MNOs or trusted third parties). Set to false if the locationReporting parameter is omitted from the consumption reporting configuration. > AccessReportingBool1..1RO Specifies whether the media session handler should provide consumption reporting messages to the 5GMS AF when the access network changes during a media streaming session. Set to false if the accessReporting parameter is omitted from the consumption reporting configuration. > SamplePercentagePercentage1..1RO The percentage of media streaming sessions that send consumption reports, in ranges from 0.0 to 1.0. It is expressed as a floating point value between 0..1 and 100.0. If the SamplePercentage parameter is omitted in the consumption reporting configuration, it is set to 100.0. > Energy Consumption Bool 0..1 The amount of energy calculated as consumed by receiving by ROUE. This is the amount of bits or energy received by the service for which the consumption report is being created. The report can be created by energy source type. If an array of energy sources to be reported is specified, only the corresponding energy sources can be reported. > Energy Source Array 0..1 The energy source that is the basis for the energy output to be reported from ROUE.There is no reporting obligation for UEs with unspecified energy sources. When more than one energy source is specified in an array, reports must be prepared in the specified order.

[0118] When included in dynamic policy configuration information, the policy provided by the mobile communication service to the UE is specified. The policy provided to the UE may include information about energy. The energy source type and energy source information may indicate the type of energy source provided for the policy template resource identifier or the composition ratio of a composite energy source. This allows the UE to understand the energy used by the policy being applied by the service.

[0119] DynamicPolicyInvocationConfigurationType0..1RO Displayed when a 5GMS application provider has provisioned policy templates and at least one of them is in the Ready state. > ServerAddressArray(AbsoluteUrl)1..1RO A list of 5GMS AF addresses (URLs) that provide an API for dynamic policy invocations sent by the media session handler. > PolicyTemplateBindingArray(Object)1..1RO A list of doubles, each binding an external reference to a policy template resource identifier. > ExternalReferenceString1..1RO An additional identifier for this policy template, unique within the scope of the provisioning session, that can be cross-referenced with external metadata for the media streaming session. > PolicyTemplateIDResourceID1..1RO The resource identifier of a policy template with the externalReference tag that is in the READY state. > sdfMethodArray(SdfMethod)1..1RO A list of recommended service dataflow description methods (descriptors) that should be used by the media session handler to describe the service dataflow for the traffic to be policyd, for example: 5-tuple, ToS, 2-tuple, etc.) > Energy Source Type Energy Source Type Identifier 0..1 RO The type of energy source for the policy template resource identifier > Energy Source Information Array (Object) 0..1 RO The type of energy source for the policy template resource identifier. When two or more energy source types are used in combination, they are displayed as a double list. Example: [[Energy Type Identifier 1,60],[Energy Type Identifier 2,30],[Energy Type Identifier 3,10]]

[0120] When included in the client edge resource configuration information, the easDiscovery template and easRelocation requirement can each have energy information to support energy source type information.

[0121] Client EdgeResources ConfigurationType0..1ROOnly provided for provisioning sessions provisioned in client-centric edge computing management mode.Eligibility CriteriaEdge Processing Eligibility Criteria0..1ROConditions for enabling edge resources for media streaming sessions within the scope of this service access information.easDiscoveryTemplateEAS Discovery Template1..1ROTemplate for EAS search filters used by the EEC to discover and select 5GMS EAS instances to provide media streaming sessions within the scope of this service access information.easRelocationRequirementsM5EAS Relocation Requirements0..1ROEAS relocation allowance scope and requirements. If none, the EEC assumes that relocation is allowed on all 5GMS EAS instances within the scope of this service access information.

[0122] 2.3 Edge Resource Search Conditions easDiscoveryTemplate is as follows. easDiscoveryTemplate is the condition information used when a UE wants to use processing services at the edge by being allocated an Edge Application Server (EAS). Mobile communication services can use this to find an EAS that satisfies the conditions and provide it to the UE. The UE can use the energy source type and energy source information fields to specify which energy source the edge resource, i.e., the EAS, to be searched for should use. The energy source type array can specify one or more energy source types, and when multiple types are specified, the first specified type takes precedence. Mobile communication services can allocate based on the available energy types among the specified energy types. However, if only an EAS using an unspecified energy source is available, it can be allocated first and then relocated later. The energy source information specifies the minimum usage amount for each energy source type if it is not 0. If it is 0, the condition is satisfied as long as the corresponding energy source is used. Depending on the service, if the usage amount is stated as a minimum value, i.e. 10, it can be understood that more than 10% must be used, or if it is stated as a maximum value, i.e. 10, it can be understood that more than 10% must not be used. Accordingly, it can be distinguished as minimum energy source information and maximum energy source information.

[0123] easId string 0..1 The application identifier (e.g., FQDN, URI) of the EAS. If omitted, 5GMS EAS instances that match the other criteria specified in the template are accepted. easType string 0..1 A non-empty string indicating the type of 5GMS EAS required to support media streaming sessions in the scope of this search template, if present. easProviderId array (string) 0..1 The set of allowed EAS provider identifiers. If omitted, 5GMS EAS instances of the specified easType from all providers are accepted. easFeatures array (string) 0..1 The service features required by the EAS to provide this session. If omitted, 5GMS EAS instances of the specified easType with the full feature set are accepted. > Energy Source Type array 0..1 The type of energy source that the edge resource being searched must use. When more than one is specified as an array, the one with the highest priority is listed first. >Minimum Energy Source Information / Maximum Energy Source Information Array (Object) 0..1 The type of energy source that the edge resource should use. When two or more energy source types are used in combination, any number other than 0 indicates the minimum usage ratio. Example: [[Energy Type Identifier 1,60],[Energy Type Identifier 2,0],[Energy Type Identifier 3,0]] specifies that a minimum or maximum of 60% or more of Energy Type Identifier 1 should be used, and 2 and 3 are other allowable Energy Type Identifiers.

[0124] The EAS relocation requirement is as follows. Energy Source Ignore Allow specifies additional considerations for selecting the target EAS when an EAS is relocated from a source EAS to a target EAS. When an EAS is initially allocated, the aforementioned easDiscoveryTemplate is used, specifying the energy source. However, since relocation occurs midway through service initiation, service interruption may occur if the allocation of a suitable EAS takes time. Therefore, the additional field Energy Source Ignore Allow is proposed. If the value of Energy Source Ignore Allow is True, it means that even if the energy source type specified in easDiscoveryTemplate is not specified, the target EAS can be considered. After the relocation is complete and the UE is receiving service from the target EAS, it can receive information about the energy source type used by the target EAS and resubmit a relocation request with Energy Source Ignore Allow set to False. Depending on the power facilities of the cell to which the UE has moved, the cell may not have energy source information or may not be able to provide the energy source desired by the UE. A mobile service may not use the energy source specified in easDiscoveryTemplate even if the Allow Energy Source Ignore value is False.

[0125] toleranceEASrelocation tolerance1..1 Indicates whether the GMS EAS instance allows relocation. maxInterruptionDurationInteger0..1 The maximum downtime (in milliseconds) that the application can tolerate during an EAS relocation. If the application's expected downtime is expected to exceed this period, the relocation of the GMS AS EAS instance is allowed. AllowIgnoreEnergySourceBool0..1 If present and True, the requirement for an energy source can be temporarily ignored when a relocation occurs. The priority of the requirement for the type of energy source is temporarily lowered to ensure a fast switchover. The UE and the edge client module in the UE can determine the relocation based on the energy source type information of the EAS allocated from the mobile communication service. If False, it means that the EAS using the same energy source type is requested during the relocation. Depending on the available resources of the mobile communication service, an EAS with a different energy source type may be allocated even if False.

[0126] 2.4 Endpoint search conditions, UE energy policy establishment

[0127] Similar to edge resource discovery, Simple WebRTC Application Protocol (SWAP), a protocol used for discovery and session negotiation between two endpoints in 3GPP's 5G-RTC (Real-time Communication) architecture, provides a way for one endpoint (e.g., a terminal) to communicate with a SWAP server to discover another endpoint (e.g., an edge resource or Media Function) that satisfies conditions (e.g., media processing such as up scaling).

[0128] Using the SWAP protocol, each endpoint registers itself with the SWAP server and, during the registration process, submits matching criteria, or search conditions, to enable other endpoints to search for it. Matching criteria are as follows, and in this disclosure, the energy item is added as a search condition.

[0129] The supported types in this version of the specification are the following:

[0130] ipv4: The IPv4 address of the target endpoint

[0131] ipv6: The IPv6 address of the target endpoint

[0132] fqdn: The FQDN of the target endpoint

[0133] service: An identifier of a service or an application

[0134] user: An identifier of the user such as a SIP address, a GPSI, or an MSISDN

[0135] eas: An EAS identifier

[0136] app: application-specific matching criteria that is compared using binary or string comparison

[0137] location: one or more identifiers of a geographic location or area

[0138] qos: a description of the QoS that is supported by the connection to the endpoint

[0139] processing: a profile description of the processing capabilities of the endpoint.

[0140] energy: The energy source used by the mobile communication component. SupportedEnergySource can be specified during registration. PreferredEnergySource or minimumEnergySourceRequirement can be specified during search.

[0141] A mobile communication component according to the present disclosure may, when registering itself with a SWAP server using the SWAP protocol, use the energy field in matching_criteria to indicate the energy source it uses. The energy source type may specify one or more energy source types, and in the case of a composite energy source, a ratio.

[0142] Meanwhile, when searching for a mobile communication component that uses a specific energy source using the SWAP protocol, preferredEnergySource or minimumEnergySourceRequirement can be specified in the energy item in the aforementioned matching criteria. preferredEnergySource can describe one or more energySourceTypes. If one is described, it indicates that a counterpart mobile communication component that uses another energy source does not need to be searched, and if multiple are described, it indicates that a conditional search can be performed in order of preference. minimumEnergySourceRequirement indicates a minimum ratio for a specific energy source. It indicates the minimum value by which the indicated energy source must be used for a counterpart mobile communication component that uses multiple energy sources in combination.

[0143] Although this disclosure describes the case of the SWAP protocol, it is also applicable to general inter-component negotiation protocols in that a component specifies the energy source it uses and the preferred energy source for discovery and calling of other components.

[0144] The MSH of the UE uses the energyPolicy in Table 8 to transmit the energy policy established by the terminal to the AF, and the AF can manage it in the EMF when selecting AS, EAS, or endpoint, or transmit it to the NEF, PCF, etc. to use it as a policy to be applied to the mobile communication components when providing services for the terminal in 5GC.

[0145] energyPolicy> energySourceTypesArray A list of energySourceTypes. If more than one is specified, it means that a mixture of two or more will be used. (Example: [renewableEnergy, pseudoGreenEnergy])> ratio The ratio of energySourceTypes. Indicates the mixture ratio for each energySourceType. (Example: [40, 60])> preferredEnergySourceArray A list of preferred energySourceTypes> minimumEnergySourceRequirementArray (object) The type of energy source that the endpoint must use. When two or more energy source types are used in combination, any non-zero number indicates the minimum usage ratio. Example: [[EnergyTypeIdentifier1,60],[EnergyTypeIdentifier2,0],[EnergyTypeIdentifier3,0]] specifies that EnergyTypeIdentifier1 will be used at least or at most 60% of the energy type identifier and that 2 and 3 are other allowable energy type identifiers. > functionalityArray Describes one or more features supported by the endpoint. > policyPriorityArray Specifies the priority to refer to when selecting an endpoint. energySource indicates that it is important to select an endpoint that uses the energy source specified in energySourceTypes. latency indicates that it is important to select an endpoint with low latency. Performance indicates that it is important to select an endpoint with high performance. For example, [energySource, latency] indicates that it will be selected even if the latency is high as long as the energy source types match. Conversely, [latency, energySource] indicates that it will be selected even if the latency is low, even if the energy source types do not match. > energyProfileArray A list of profiles defined by 3GPP. Each profile can indicate a specific energy source or a preferred method of selection.For example, greenEnergy and carbonEnergy can be used to explicitly indicate an energy source and request that services be provided using that energy source. greenerEnergyFirst, performanceFirst, and lowLatencyFirst can implicitly indicate a preference for greenEnergy, or a preference for performance or low latency regardless of the energy source type. RegulationFirFor55 and regulationRePowerEU, for example, can be used to request services using devices that comply with national or continental government regulations, indicating compliance with profiles.

[0146] 2.5 Consumption information of network components

[0147] Mobile communication components can have energy consumption information for an operation or a series of operation flows. Components that constitute a mobile communication service, such as a Network Function (NF), a User Plane Function (UPF), an Application Function (AF), an Application Server (AS), an Edge Application Server (EAS), a Central Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU), may be complexly connected to common energy consumption consumed for their own operation even if they do not operate for a specific user, energy consumption used for standby time, connection energy consumption consumed for connectivity between a specific user and mobile communication, and user session energy consumption used for performing a specific service request of a specific user.

[0148] Furthermore, mobile communication components can specify the energy source they use for a requested action or a series of action flows. Mobile communication operators can have mobile communication components that operate using electricity generated from at least one energy source. Accordingly, mobile communication components can know whether the energy source they use is one of natural reproduction, greenhouse effect, nuclear power, etc. and provide this as an additional attribute value to other entities. An entity collectively refers to a mobile communication component and a user UE, etc. For example, a service requested and provided by a user is a result of the interaction of several different mobile communication components, and the total energy usage of each mobile communication component accumulated during the call and the final call stage can be known as well as the ratio based on the total between energy sources. To this end, the first mobile communication component that responds to a user's request can receive information about the energy sources used by the second and third mobile communication components during the process of transmitting the user request to the second and third mobile communication components, the expected energy consumption, and the actual energy consumption in the response sent by the second and third components after completing the task. The second and third components can also add the energy consumption received in response to the request to their own consumption and transmit it during the process of transmitting the operation according to the request of the first component to the fourth and fifth components. Accordingly, the first mobile communication component that requests a service and receives the corresponding result can receive details about the energy sources used by all mobile communication components that were connected to resolve the request, the expected energy consumption, and the actual energy consumption. (See Table 9)

[0149] The above mobile communication components can perform some of the operations for a request themselves and delegate some of the operations to other mobile communication components to be performed. Since different mobile communication components are defined for different purposes, a high-level request can be divided into multiple lower-level requests. The mobile communication components according to the present embodiment can return the amount of energy consumed by themselves in response to a request. Energy credit consumption can be described as a pair of energy source type and energy consumption, and the calling mobile communication component can respond by adding the energy consumption returned by the called mobile communication component and the energy consumption consumed in its own execution.

[0150] Mobile communication components can distinguish between a first energy consumption consumed for connectivity with users and services, such as waiting for a user connection when there is no user, or waiting for a user request while maintaining a connection with the user when there is a user, and a second energy consumption consumed for operations such as transmitting and receiving information between NFs and transmitting it to the user according to a user request. Energy consumed by the mobility of the user can be included in the first energy consumption, but [5] When a user requests media and moves while receiving it, Application Context Relocation (ACR) may occur from UPF #2 to UPF #3 for a faster response, which can be included in the second energy consumption. In other words, even with the same mobility, additional energy may be required due to ACR if it occurs during media playback. Operators can distinguish this and provide energy consumption information.

[0151] energyCreditConsumptionEnergyCreditConsumption> energySourceTypeEnergy source type identifier used by the mobile communication component> estimatedEnergyCreditEstimated energy consumption (in credits)> measuredEnergyCreditEstimated energy consumption (in credits)> commonEnergyCommon energy consumption> idleEnergyIdle energy consumption> UEIdentifierUE identifier> energyConsumptionRatioEnergy type-specific discount rate. It is represented as a double array with two elements: energy type and discount rate. For example: [[renewableEnergy, 0.1], [greenHouseGasEnergy, 1]]> energyScheduleEnergy discount schedule. It is represented as a double array with four elements: energy type, discount rate, start time, and end time. For example: [[renewableEnergy, 0.2, 13:00, 17:00], [ renewableEnergy, 0.1, 17:00, 23:00]]

[0152] Energy consumption is not a constant and is not easy to calculate, as physically higher temperature devices can consume more energy for the same task, and in actual implementations, they operate as virtual machines within hyperscale server clusters. However, the energy consumed for a single API operation can be inferred by considering various factors such as common energy consumption for the overall process, such as the operating system (OS) and virtual machine (VM) operations, energy consumption for connectivity between the terminal and mobile communication services, and user session energy consumption, and calculating the ratio. Since the process uses resources such as the CPU, GPU, memory, and storage, the energy consumption ratio can also be calculated from the energy usage ratio of the corresponding resources. For a service requested by a user, the energy consumption for a future service period, such as transmitting a two-hour movie, may differ between the predicted energy consumption before the service is provided and the energy consumption calculated based on the measured rate after the actual service is completed. This may also vary depending on the amount of energy consumed to maintain the user session during a pause in the movie playback, and the energy consumption used to maintain user connectivity between cells as the user moves. Mobile carriers may vary the calculated rate for the same energy consumption if different energy sources are used. Mobile communication components report the energyCreditConsumption item for the requested operation, which may distinguish between the energy consumption estimated in advance (estimatedEnergyCredit) and the energy consumption calculated after the operation is completed (measuredEnergyCredit). A UE identifier may be included to distinguish the energy consumption for the UE calculated from the aforementioned standby and common energy consumption (see Table 9).

[0153] 2.6 Method of reporting total energy consumption

[0154] Figure 6 illustrates a process for receiving a combined energy consumption report from network components.

[0155] In order to call NF1, which is a mobile communication component in FIG. 6 (601), a command (610 Request) to call NF1 is transmitted to NF1. In step 602, NF1 performs part of the request and can delegate processing of another part by calling NF2. NF1 generates 620 Request to call NF2, and NF2 similarly processes part of the request and generates 630 Request to call NF3 for further processing. NF3 uses renewable energy as an energy source and generates 632 Response by entering the amount of energy used to process 630 Request and responds to NF2. NF2 processes the remainder of the request based on the response of NF3 and generates 622 Response to respond to NF1. The 622 Response includes the energy consumption of NF3 and NF2 that were included in the 632 Response. NF1 processes the remainder of the request based on the response from NF2, generates a 612 Response, and responds to the call from step 1. The 612 Response includes the energy consumption of NF3, NF2, and NF1 that were included in the 632 Response and 622 Response. The 612 Response may separately describe the energy consumption of NF1, NF2, and NF3, or may describe the combined consumption by each energy source such as GHG Energy and Renewable Energy, or may describe the combined consumption of all energy sources regardless of energy source.

[0156] 2.7 How to calculate energy consumption

[0157] Figure 7 illustrates a method for summing the energy consumption of network components.

[0158] FIG. 7 illustrates a method of including estimated energy consumption in the processing in FIG. 6. NF1 can reply to a 710 Request received from UE by writing estimatedEnergyCredit, which is an estimated energy consumption, in a 711 Ack. Energy credit consumption can be composed of a pair of energy source and energy consumption. If the UE determines that estimatedEnergyCredit is excessive, it can send a Request to cancel the execution of the request. NF1 can send a 720 Request to NF2, including part of the 710 Request or a new request generated by NF1, and NF2 can reply to the 721 Ack by writing the estimated energy consumption. NF3 can also reply to a 730 Request generated by NF2 by writing the estimated energy consumption in a 731 Ack. After NF3 finishes processing the 730 Request, it sends a 732 Response, which may include measuredEnergyCredit based on the actual energy consumed. In this case, estimatedEnergyCredit and measuredEnergyCredit may be different. NF2 may also send a 722 Response containing measuredEnergyCredit based on the actual energy consumed to NF1. NF1 may also send a 712 Response containing measuredEnergyCredit based on the actual energy consumed to the UE. NF1, NF2, and NF3 may adjust their prediction algorithms if there is a significant difference between estimatedEnergyCredit of 711, 721, and 731 and measuredEnergyCredit of 712, 722, and 732 for scheduled requests of 710, 720, and 730, respectively.

[0159] 2.8 Events; Policy / Credit Verification on Call / Action

[0160] Figure 8 illustrates a process in which an Energy Report is generated for each NF's request and periodically reported to the ENF (or energy management department), and the ENF examines the Report based on an energy policy acceptable to the UE and determines whether to continue the operation and responds.

[0161] Figure 8 illustrates a process for additionally responding to the processing in Figure 7 regarding whether to continue implementation of the energy policy. NF1 can respond to the 810 Request received from the UE by writing estimatedEnergyCredit, which is the expected energy consumption, within the 811 Ack.

[0162] FIG. 8 shows a process similar to that in FIG. 7, in which NF1 transmits some of the requests for performing the 810 Request or newly generated requests to NF2 as an 820 Request, and NF2 can write the expected energy consumption in an 821 Ack and reply. NF3 can also write the expected energy consumption in an 831 Ack and reply to the 830 Request generated by NF2.

[0163] FIG. 8 shows that, similar to the processing in FIG. 7, after NF3 completes processing for the 830 Request, it transmits the 832 Response, which may include measuredEnergyCredit based on the actual energy consumed. In this case, estimatedEnergyCredit and measuredEnergyCredit may be different. NF2 may also transmit the 822 Response, which includes measuredEnergyCredit based on the actual energy consumed, to NF1. NF1 may also transmit the 812 Response, which includes measuredEnergyCredit based on the actual energy consumed, to the UE.

[0164] When requesting and receiving a service, a user and UE can determine the expected credit consumption in advance, determine the appropriate consumption, establish an energy path (an end-to-end service path composed of a set of components that use the same or different energy source types) for it, and request service reception through this. One or more Energy event register messages can be registered from the UE to the energy management unit. The UE using this can register an Energy event to the energy management unit to determine the status of actual consumption compared to the expected credit consumption, and the energy management unit can trigger an event when a specified condition is met, so that a new policy or a new request can be created from the UE. Accordingly, the UE can receive an event that occurs when more credits are consumed than initially predicted (e.g., new server allocations, duplications, etc. due to user movement) or when a target consumption limit is reached, and can change the energy path or establish a new energy consumption policy accordingly.

[0165] Energy event register message Description source The component that requested the event registration. Identifier of the element that is subject to energy consumption and credit deduction, such as GPSI or session ID. target Energy Credit consumption target value that the source has decided to consume. If the actual consumption value approaches or exceeds the target value, events are triggered in warningPoints, hardStopPoints, etc. and delivered to the source. warningPoints Instructs to trigger a warning event when the ratio of the consumption value to the target value exceeds the instructed value. Examples: 90%, 95%, 99%, 100%, etc. hardStopPoints Instructs to stop execution and trigger an exceed event when the consumption value is at the specified ratio compared to the target value. The credit percentage to stop at is specified, such as 90% or 100%.

[0166] Energy event descriptionDescriptionwarning: 00% of credit is usedIndicates that the consumption is lower than the target value and is at the value specified in warningPoints.warning: hardStop at 00%Indicates that the consumption is at the value specified in hardStopPoints.warning: exceed 00%Indicates that the consumption is higher than the target value.warning: different energy source typeThe energy source type changed during operation (e.g. due to a service configuration change).error: not enough user creditThe user has exhausted their credit.creditSpecifies the current credit value.

[0167] The transmission of Energy Reports in steps 813, 823, and 833 may be performed periodically. Based on the ENF responses of steps 814, 824, and 834, each NF determines whether to continue the process. The Energy Reports (853, 863, and 873) that NFs report to ENFs may include the UE identifier and the estimatedEnergyCredit estimated by the NF. The Energy Reports 854, 864, and 874 that NFs report to ENFs again for the same call may include the UE identifier, the estimatedEnergyCredit estimated by the NF, and the measuredEnergyCredit actually measured since the previous report. The estimatedEnergyCredit may be a correction of the previous estimate.

[0168] The ENF exchanges information with the NEF and PCF to verify the remaining credits granted to the UE for mobile communication services and ensure that sufficient credits remain for the predicted energy consumption for the next operation. It also verifies that the preferred energy source type indicated in the policy submitted by the UE matches the energy source type used by the NF. If the available credits are insufficient or the energy source types do not match, the ENF can send a message to the NF to instruct it to stop operation or request confirmation with the UE.

[0169] The ENF can return one of the following: ok, warning, or error. If the NF needs to receive a new policy from the UE (e.g., the energy source type does not match), it passes the error code received from the ENF to the UE. The EPM in the MSH of the UE can receive the error code and switch to a new policy using an available energy source type, or wait until the requested energy source type becomes available.

[0170] 2.9 Credits (subscription)

[0171] A user's account or subscription contract registered and managed by a mobile carrier can manage the total amount of energy a user can consume. For example, in conventional mobile communication services, a user's subscription plan may be contracted based on the amount of data they can receive, such as "100 GB per month." In energy-based mobile communication services, the user's subscription plan may be based on the amount of energy they can consume. For electrical appliances, the amount of energy consumed per hour can be expressed in units such as KHW (kilowatt-hour). Energy-based mobile communication services may consider units such as kilowatt-hours or credits.

[0172] Energy credits or amounts may be granted under a contract and deducted based on the amount or percentage of energy consumed by the service upon receipt of the service.

[0173] The credit of this disclosure is a concept that combines the energy that a user can use within the contract period and the energy source used to produce the energy, and may be notified to have different credit deduction rates depending on the business operator's policies, etc. EnergyConsumptionRatio provides a credit deduction rate for each energy source type. For example, 100 credits is equivalent to 100 KHW when using an energy source that generates the greenhouse effect, but when using a naturally renewable energy source, it can be converted to 1:100, i.e. 10,000 credits. Alternatively, a different deduction rate (e.g., 1 / 100 for naturally renewable energy deduction compared to greenhouse effect energy) may be applied to the same credit. The conversion rate can be determined by the business operator based on complex factors such as the cost of energy sources at the time (e.g., oil price, inflation, international situation) and the natural environment (e.g., winter, El Niño, etc.) (e.g., fuel tax), and can be applied in real time or notified in advance.

[0174] Users can register their preferred energy source in the preferences section of their UE or mobile service account, or register a priority order among available energy sources provided by the mobile service, to receive services. It's also possible to unconditionally prioritize the highest performance source, regardless of the energy source.

[0175] Credits may be deducted, not deducted, or even increased depending on the type of energy source consumed by the service. For example, a mobile carrier may offer a higher conversion rate than its competitors to promote and increase the proportion of renewable energy. Alternatively, a policy to encourage reduced consumption of greenhouse gas energy may set a credit deduction rate higher than 1 for 1 KHW of greenhouse gas energy. Regardless of the ostensible reason, users may prefer to use energy sources that deduct fewer credits, such as renewable energy, when receiving services using mobile components that provide services using renewable energy.

[0176] Credits can be added, and this can be based on user payments, gifts, preferred energy source selection, or the service provider's acceptance of higher latency, lower speed, or lower quality. If a user exhausts all of the credits granted within the contract period, the credits can be increased for a separate additional fee or a certain fee. For example, a greater preference for renewable energy sources may attract more users, which may lead to increased latency, lower transmission speeds, and lower quality for the same service. However, from the perspective of value consumption that consumes cleaner energy, this can be understood as a desirable reward.

[0177] Operators can notify energySchedules based on several days' worth of statistics, such as recent periods of high user activity, oversupply of renewable energy, or electricity prices by energy source. EnergySchedules indicate potential changes in credit deduction rates for each energy source, including current and near-future changes. Based on this information, users and UEs can schedule desired services to be processed now or at a later time. Users can schedule a UE or service to begin receiving at the scheduled start time when the desired credit rate applies, recheck the credit rate before initiating reception, and initiate service reception if it hasn't. Streaming files, for example, can be received on the UE and played locally at a desired time.

[0178] Mobile communication service providers can separately calculate the energy consumed by mobile communication components operating for each item, such as wireless connectivity between user UE and mobile communication service, transmission of voice / video / data consumed by user UE, and data processing by the mobile communication service of the mobile communication service, and deduct it by applying different rates for each item. For example, among energy consumption by wireless connectivity, voice / video / data transmission, and computing service, a mobile communication service provider may not charge energy costs for wireless connectivity, may not deduct energy costs exceeding a certain amount for voice / video / data transmission, and may deduct it for computing service by energy source.

[0179] Mobile communication components may use the user's preferred energy source for the entire end-to-end section or a portion of the section, depending on the user's subscription plan and the mobile communication components, particularly the mobile communication components of the local cell to which the user belongs, when requesting a user service through the UE.

[0180] The MSH of the UE establishes and transmits a policy including preferred energy sources, etc. by transmitting energyPolicy during the service session setup process, and when the AF transmits this to the NEF / PCF, preferred energy source order information can be additionally added to the user subscription information of UDM and SUPI.

[0181] User preferences can be stored in the UDM of the 5GC and stored as policy data in the PCF. The NRF can group and identify single or multiple NFs into sets based on energy sources. The GPSI (Network Access and Service Activation Identifier) ​​or SUPI (User Subscription Information Management Identifier), which are identifiers assigned to identify users for user UE registration, can be linked to use a set that matches the user's preferred energy source among multiple AMF / UPF / AF / AS sets pre-created by the mobile operator for each energy source or among network slices containing these sets.

[0182] When registering and searching for NFs, NRF can additionally receive energyPolicy, similar to 5G-RTC endpoint registration and search, to know the type of energy source used by each NF and perform searches accordingly.

[0183] A network slice may contain an energy source in the S-NSSAI information and a list of NFs that use the same energy source (either single or mixed). To respond to a UE request, the 5GC may examine the UE's energyPolicy and use the network slice corresponding to the S-NSSAI that matches it.

[0184] Additionally, when the AMF sends a user request to the UPF, a GPSI is transmitted, and energy source preferences are included in the GPSI, so that a PDU session can be created by the UPF using that energy source.

[0185] An Energy Network Function (ENF) can be considered to exchange energy consumption information based on energy usage by multiple NFs and manage credit consumption information at UE requests. The ENF receives the resulting energy consumption report after each NF performs a series of processing on the UE. It then directly manages and deducts user credits or communicates with a credit-managing NF to request credit deductions. Before initiating an action at the UE's request, NFs use the expected credit consumption to inquire whether the ENF should proceed with the action. The ENF verifies whether the expected credit consumption is sufficient compared to the remaining credits and responds with a decision as to whether to allow or disallow the action. Based on this decision, the ENF generates and triggers a warning or error code based on the remaining credits and energy source type, and the NFs then return the warning or error code to the upper NF that called them. (See Figure 8)

[0186] 2.10 Trade-off Information

[0187] At least two sub-mobile communication components that are identified as using different energy sources while providing the same service may have different characteristic values ​​for the same service characteristic, in addition to the different energy sources. For example, a first mobile communication component and a second mobile communication component may be different mobile communication components with the same performance that provide the same processing of media data, wherein the first mobile communication component may use a natural renewable energy source, and the second mobile communication component may use a greenhouse-effect energy source. In this case, the first mobile communication component that uses a natural renewable energy source may receive more user requests due to the mobile communication operator's policy or the values ​​of users using the service. If the number of user requests exceeds the processing capacity of the first mobile communication component, subsequent requests may be queued and put on hold. Accordingly, the second mobile communication component may have a higher delay attribute value than the first mobile communication component.

[0188] In one embodiment, when there are one or more mobile communication components that are the target of a request request, a mobile communication component can request a list of energy source information and characteristic information, and as a result of analyzing the received response, determine whether there are different characteristic values ​​for the same service characteristic.

[0189] In another embodiment, there may be an energy management unit (EMF) (within the 5GMS architecture), a SWAP server (within the 5G-RTC architecture), or an ENF (within the 5GC architecture) that manages mobile communication components. The energy management unit, as a mobile communication component, receives a requested function and an energy source type as input and provides a list of mobile communication components that perform the function using the energy source. Meanwhile, the energy management unit may search for candidates that use different energy sources for the same function and provide items and item attribute values ​​that represent a trade-off between using the specified energy source and not using it.

[0190] The Energy Management Unit is procedurally configured to allow mobile communication components to register attribute information, such as energy source types, and a list of key characteristic values ​​during the creation process. When energy source types, type-specific ratios, or characteristic values ​​change, the mobile communication components update the Energy Management Unit, ensuring that the Energy Management Unit always provides the most up-to-date information to the mobile communication components.

[0191] Accordingly, the first mobile communication component that wishes to request a function can receive information from the energy management unit about a second component that uses a preferred energy source and a third component that uses a non-preferred energy source but has different values ​​in the trade-off attribute, and select an appropriate one among them according to priority.

[0192] Trade-off content> alternative_address Access information for alternative mobile communication components, identifier> trade_offs Lists the trade-off attribute values ​​as a double array with three elements: the item name, the identifier, and the item value. Example: [[ latency, NF1, 10], [latency, NF2, 100]]

[0193] In the process of searching and selecting mobile communication components based on trade-off information, each selection may be reported to the final requester for decision (e.g., reported to the UE for the UE to make a selection), or may be determined by a policy communicated by the requester (e.g., if a policy is communicated that prioritizes latency over energy source type, the preferred energy source type is used when latencies are the same, and the faster one is selected when latencies are different). In the former, the energy management unit may provide the aggregated energy source types of the lower-level requests when a job function request is composed of multiple lower-level requests. That is, it can convey that there are choices for the job function request without having to make a decision for each lower-level request to the job function requester.

[0194] The upper or calling mobile communication component can determine other service characteristics in addition to the energy source type when selecting the lower or called mobile communication component, and make a decision based on these characteristics. In the above example, the user, user UE, or mobile communication component can determine the difference in energy source and the presence of service characteristics with different characteristics (different values ​​of the waiting time item) when transmitting a request to the first or second mobile communication component, and decide whether to send the request.

[0195] In one example, the EPM within the MSH of a UE can select a mobile communication component based on trade-off information collected from the EMF within the AF. This information provided by the EMF can be compiled and compiled based on trade-off information received from the ENF within the 5GC or the 5G-RTC SWAP server.

[0196] In the latter case, the energy management unit can receive policies from the requester either prior to or alongside the receipt of the work request. Policies are listed in order of priority, and the energy management unit compares the collected trade-off information with the received policy priorities to select mobile communication components.

[0197] Figures 9a and 9b illustrate a process for determining energy-related policies by considering trade-off information.

[0198] Step 901. Registration

[0199] Step 902. AS1 registers itself with EMF during the generation process. The registration information includes the energy source type (naturally generated energy) and key characteristics.

[0200] Step 903. AS2 registers itself with EMF during the creation process.

[0201] Step 904. App-specific message exchange. Option 1, where the UE determines the selection, and Option 2, where the EMF determines the selection based on a policy, are shown.

[0202] Step 905. As Option 1, the UE requests functionality from the EMF via the MSH / EPM. The request may specify a preferred energy source type.

[0203] Step 906. EMF selects a component registered to provide the requested functionality using the specified energy source type and a component registered to provide the requested functionality using other energy sources, and writes trade-off information.

[0204] Step 907. EMF provides trade-off information to EPM.

[0205] Step 908. EPM selects the functional elements to use by considering the trade-off information.

[0206] Step 909. EPM passes the identifier of the functional element to be used (here AS #1) to EMF.

[0207] Step 910. The EMF forwards the UE's capability request to the component of the corresponding identifier.

[0208] Step 911. The EMF notifies the UE that the function request has been delivered.

[0209] Step 912. AS #1 forwards the response to the request to EMF.

[0210] Step 913. EMF forwards AS #1's response to EMF.

[0211] Step 914. As Option 2, the UE requests capabilities from the EMF via the MSH / EPM. The request includes a policy listing preferences in order of priority.

[0212] Step 915. EMF selects a component that corresponds to the policy priority among the components registered to provide the requested function.

[0213] Step 916. The EMF forwards the UE's capability request to the capability element to be used.

[0214] Step 917. The EMF notifies the UE that the function request has been delivered.

[0215] Step 918. AS #1 forwards the response to the request to EMF.

[0216] Step 919. EMF forwards AS #1's response to EMF.

[0217] Step 920. A transmission session is established between the UE and AS #1.

[0218] Step 921. MSH proposes a transmission message to AS #1 via EMF (e.g. SDP offer)

[0219] Step 922. AS #1 sends a response message to MSH via EMF (e.g. SDP answer)

[0220] Step 923. MSH passes the connected session establishment settings to MAF.

[0221] Step 924. Data transfer is initiated between MAF and AS #1.

[0222] 2.11 Energy Profile, Energy Profile Schedule

[0223] Services can create and publicize energy profiles. Energy profiles include information about the energy sources used by requests and services implemented using the profile, including the percentage of energy consumed, carbon emissions, service QoS performance information, and credit deduction rates.

[0224] Some or all of the energy profiles available in a service may be announced. Announced profiles may or may not be currently available. If available, the profile's status may be displayed as available. If unavailable, the profile's status may be displayed as planned. Profiles marked as planned may indicate the time they will become available. Both profiles marked as available and planned may indicate the end of their provision.

[0225] A UE can subscribe to a specific profile and be notified when that profile becomes available. Based on the notification, the UE can request or abort a task. The service can update the entire profile and its schedule in cases such as when more profiles are available or when some previously planned profiles are discontinued.

[0226] Accordingly, the events provided by the service may include events that occur when the service of a specific profile subscribed to by the UE becomes available, events that occur when the service becomes unavailable, events that notify termination in advance before the service ends, and events that notify when the list of all profiles and their schedules are updated.

[0227] A service can control which profile is used for the UE and the tasks it directs. For example, if a task requested by a UE and its profile are available, the service can provide the requested task. However, if the requested task is not completed when the profile becomes available, the service can determine and control whether to abort the task or use a different profile.

[0228] Tasks can be categorized as general tasks and optimized tasks. For optimized tasks, using specific computing resources can reduce energy consumption or process tasks faster with the same amount of energy compared to general computing resource configurations. For example, AI inference can be processed faster using an AI-accelerated GPU than a general CPU. For video encoding, using a dedicated video encoder with the corresponding codec can produce higher-quality encoded video in real time. Therefore, the service provides information on which optimized tasks can be distinguished. This information can be general tasks, AI inference optimization, AI learning optimization, or video encoding optimization. The UE can determine whether the requested task falls under one of the optimized tasks and request it. Based on the request, the task is assigned to the optimized computing resources, allowing it to complete faster or with lower energy consumption.

[0229] Tasks can be divided into those with a specified target time and those without. If a target time is specified, the service can schedule the task using the time difference between the current time and the target time. It can distinguish between currently available profiles and those available before the target time and determine which profile to use to perform the task. Depending on the type of task, the target time can be specified in more detail. For example, in the case of video transcoding, the original video uploaded by the user can be transcoded with different codecs, resolutions, and bitrates and provided to other users. If the time when the user requests transcoding to the service (request time), the time when the original video can be uploaded from the UE (upload time), the time when transcoding should begin (transcoding start time), and the time when the completed transcoding result can be provided to other users (distribution time) are clearly specified, the service can use them to notify events or initiate tasks when scheduling.

[0230] FIG. 10 illustrates the structure of a terminal according to one embodiment of the present disclosure.

[0231] The terminal of FIG. 10 may correspond to the terminal or UE described with reference to FIGS. 1 to 9.

[0232] Referring to FIG. 10, the terminal may be composed of a transceiver (1010), a memory (1020), and a control unit (1030).

[0233] According to the communication method of the terminal described above, the transceiver (1010), control unit (1030), and memory (1020) of the terminal may operate. However, the components of the terminal are not limited to the examples described above. For example, the terminal may include more or fewer components than the components described above. In addition, the transceiver (1010), control unit (1030), and memory (1020) may be implemented in the form of a single chip. In addition, the control unit (1030) may include one or more processors.

[0234] The transceiver (1010) is a general term for the receiver and transmitter of the terminal, and can transmit and receive signals with other devices. To this end, the transceiver (1010) may be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and down-converts the frequency of a received signal. However, this is only one embodiment of the transceiver (1010), and the components of the transceiver (1010) are not limited to the RF transmitter and RF receiver.

[0235] In addition, the transmitter / receiver unit (1010) can receive a signal through a wireless channel and output it to the control unit (1030), and transmit the signal output from the control unit (1030) through the wireless channel.

[0236] The memory (1020) can store programs and data required for the operation of the terminal. In addition, the memory (1020) can store control information or data included in signals acquired from the terminal. The memory (1020) can be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, the memory (1020) may not exist separately but may be configured as part of the control unit (1030).

[0237] The control unit (1030) can control a series of processes so that the terminal can operate according to the embodiment of the present disclosure described above. FIG. 11 illustrates the structure of a server according to one embodiment of the present disclosure.

[0238] The server of Fig. 11 may correspond to the server described with reference to Figs. 1 to 9. Referring to Fig. 11, the server may be composed of a transceiver (1110), a memory (1120), and a control unit (1130).

[0239] According to the communication method of the server described above, the server's transceiver (1110), control unit (1130), and memory (1120) may operate. However, the components of the server are not limited to the examples described above. For example, the server may include more or fewer components than the components described above. In addition, the transceiver (1110), control unit (1130), and memory (1120) may be implemented in the form of a single chip. Furthermore, the control unit (1130) may include one or more processors.

[0240] The transceiver (1110) is a general term for the server's receiver and transmitter, and can transmit and receive signals with other devices. To this end, the transceiver (1110) may be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and down-converts the frequency of a received signal. However, this is only one embodiment of the transceiver (1110), and the components of the transceiver (1110) are not limited to the RF transmitter and RF receiver.

[0241] In addition, the transmitter / receiver unit (1110) can receive a signal through a wireless channel and output it to the control unit (1130), and transmit the signal output from the control unit (1130) through the wireless channel.

[0242] The memory (1120) can store programs and data required for the operation of the server. In addition, the memory (1120) can store control information or data included in signals acquired from the server. The memory (1120) can be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, the memory (1120) may not exist separately but may be configured as part of the control unit (1130).

[0243] The control unit (1130) can control a series of processes so that the server can operate according to the embodiment of the present disclosure described above.

[0244] FIG. 12 illustrates the structure of a network component according to one embodiment of the present disclosure.

[0245] The network component of FIG. 12 may be any one of the multiple network entities described with reference to FIGS. 1 to 9. For example, the network entity may be any one of an application function (AF), an application server (AS), and an application provider (AP). For example, the network entity may be any one of multiple network functions (NFs).

[0246] Referring to FIG. 12, the network components may be composed of a transceiver (1210), a memory (1220), and a control unit (1230).

[0247] Depending on the communication method of the network components described above, the transceiver (1210), control unit (1230), and memory (1220) of the network components may operate. However, the network components are not limited to the examples described above. For example, the network components may include more or fewer components than the components described above. In addition, the transceiver (1210), control unit (1230), and memory (1220) may be implemented in the form of a single chip. Furthermore, the control unit (1230) may include one or more processors.

[0248] The transceiver (1210) is a general term for the receiving unit and the transmitting unit of a network component, and can transmit and receive signals with other devices. In addition, the transceiver (1210) can receive signals via a wireless channel and output them to the control unit (1230), and transmit signals output from the control unit (1230) via the wireless channel.

[0249] The memory (1220) can store programs and data required for the operation of network components. In addition, the memory (1120) can store control information or data included in signals acquired from network components. The memory (1220) can be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, the memory (1220) may not exist separately but may be configured as part of the control unit (1230).

[0250] The control unit (1130) can control a series of processes so that the network components can operate according to the embodiment of the present disclosure described above.

Claims

In a method of operating a terminal in a wireless communication system, A step of receiving service access information including first information on an energy source type from an AF (Application Function) of a network; A step of selecting an energy source type used by the network based on the first information; and A method comprising: transmitting second information about the selected energy source type to the AF of the network; In the first paragraph, when two or more types of energy sources are used, the service access information is: A method further comprising identifier information for each of the above energy source types and an energy source ratio for each of the above energy source types. In the first paragraph, the service access information is: A method further comprising: an energy consumption amount for the above energy source type and an energy source to be reported. In the first paragraph, if there is a policy change in the service access information, the service access information is: Includes third party information about the energy source type of the above changed policy, A method further comprising, when two or more energy source types of the changed policy are used, identifier information for each energy source type of the changed policy and an energy source ratio for each energy source type of the changed policy. In the first paragraph, the service access information is: A method wherein the first information further includes an energy source type searched by the terminal, and when two or more energy source types searched by the terminal are used, the method further includes identifier information for each energy source type searched by the terminal and an energy source ratio for each energy source type searched by the terminal. In a wireless communication system, at a terminal, transceiver; and comprising a processor, said processor comprising: Receive service access information including first information about the energy source type from the AF (Application Function) of the network, Selecting the type of energy source used by the network based on the first information, and A terminal that transmits second information about the selected energy source type to the AF of the network. In the 6th paragraph, when two or more types of energy sources are used, the service access information is: A terminal further comprising identifier information for each of the above energy source types and an energy source ratio for each of the above energy source types. In a method of operating a terminal in a wireless communication system, A step of transmitting a first message regarding registration to a server, wherein the first message includes conditions for an energy source used by at least one network component existing in the server; and Step of receiving a second message regarding a response from the above server - A method comprising: wherein the second message includes information related to the type of energy source and the amount of energy consumption used by the at least one network component; In the 8th paragraph, the second message is: A method further comprising at least one of information on the total energy consumption used by the at least one network component, information on the energy consumption rate of the at least one network component, and information on the predicted amount of energy consumption to be used by the at least one network component. In paragraph 8, A method further comprising: a step of registering a third message including a condition for an energy source to be used by at least one new network component, if the information related to the type of energy source and the amount of energy consumption used by at least one network component does not satisfy the condition; In the 8th paragraph, information related to the type of energy source and energy consumption used by the at least one network component, Further including information on the total amount of energy that the terminal can use, A method wherein the higher the proportion of natural renewable energy in the energy source, the lower the consumption ratio of the energy consumption is set. In the 8th paragraph, if at least one network component provides the same service but has a different energy source type, Selecting at least one network component based on the energy source type preferred by the terminal, A method in which the terminal operates by at least one network component selected above. In the 8th paragraph, the first message is: Further including conditions related to the profile information notified by the above server, The above profile information is, A method comprising information on at least one of a ratio for an energy source, carbon emissions, service QoS performance, and an energy consumption reduction rate. In the 13th paragraph, the second message is: If the server satisfies the conditions related to the profile information, the profile provided by the server further includes information related to the subscription or subscription plan of the terminal, A method wherein, when at least one network component fails to satisfy a condition related to the profile information, the profile provided by the server further includes information related to the termination or scheduled termination of the terminal. In a wireless communication system, at a terminal, transceiver; and comprising a processor, said processor comprising: The terminal registers a first message containing conditions for an energy source to be used by at least one network component existing in the server, and If the above condition is satisfied, the terminal performs receiving a second message regarding a response from the server, The terminal, wherein the second message includes information related to the type of energy source and energy consumption used by the at least one network component.

Images