Energy aware end-to-end network flow management services

Abstract

Methods and systems are described herein that enable end-to-end energy aware network flow management to equip networks with the capability to operate with increased levels of energy efficiency and awareness at the granularity of network flows. In an example, an energy aware Service Enabler Architecture Layer for Verticals Data Delivery Enabler (SEALDD) policy configuration request comprising one or more information elements may be received from a requestor. The one or more information may correspond to one or more of energy credits, energy credit usage policies, energy consumption policies, renewable energy policies, or energy measurement policies. A policy associated with the energy aware policy configuration request policy may be stored for use in establishing energy aware SEALDD flows. An energy aware SEALDD policy configuration response with an indication that the policy was created successfully may be sent to the requestor.

Description

CNV15054W001 / 101859.002181ENERGY AWARE END-TO-END NETWORK FLOW MANAGEMENT SERVICESCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U. S. Provisional Patent Application No. 63 / 692.930, filed September 10, 2024, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] 3GPP systems may currently lack services to manage end-to-end (E2E) message flows between endpoints (e.g., VAL clients and servers) in an energy aware manner. Some examples of energy aware communication flow management capabilities that may be currently lacking include the following: lack of awareness of available energy credits of a subscriber; lack of awareness of renewable energy preferences of a subscriber; lack of energy state information of network resources within the system; lack of capability to measure / calculate the amount of network energy consumed by a subscriber; lack of capability to monitor, detect and expose energy state changes of resources in the network; and lack of capability’ to monitor, detect and expose the renewable energy mix consumed by resources in the network.

[0003] Accordingly, there is a need for improved end-to-end (E2E) message flow management techniques at the service layer.SUMMARY

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary' is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

[0005] Methods and systems are described herein that enable end-to-end energy aware network flow management to equip networks with the capability to operate with increased levels of energy efficiency and awareness at the granularity of network flows. TheCNV15054W001 / 101859.002181 described techniques define energy aware network flow management functionality for sendee layers such as the 3GPP SA6 defined Service Enabler Data Delivery (SEALDD) layer.

[0006] SEALDD clients and servers may be equipped with energy aware SEALDD flow management functionality capable of performing operations described herein. These operations may include, for example, energy aware SEALDD policy configuration operations, energy aware SEALDD flow establishment operations, SEALDD energy7measurements operations, SEALDD energy credit operations, SEALDD energy7state aware operations, and / or SEALDD renewable energy operations. These and other operations are described in detail in the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0008] FIG. 1 shows a diagram of an example Service Enabler Architecture Layer for Verticals Data Delivery Enabler (SEALDD) architecture;

[0009] FIG. 2 shows a diagram of an example SEALDD flow;

[0010] FIG. 3 shows a diagram of an example multi-modal SEALDD flow;

[0011] FIG. 4 shows a diagram of an example energy aware SEALDD flow management system;

[0012] FIG. 5 shows a diagram of an example energy7aware multi-modal SEALDD flow management system;

[0013] FIG. 6 shows an example procedure for energy aware SEALDD flow management;

[0014] FIG. 7 shows an example procedure for an energy aware SEALDD policy configuration request;

[0015] FIG. 8 shows an example procedure for energy7aware SEALDD policy enforced SEALDD flow establishment;

[0016] FIG. 9 shows an example procedure for Vertical Application Layer (VAL) client / server initiated energy aware SEALDD flow establishment;CNV15054W001 / 101859.002181

[0017] FIG. 10 shows an example procedure for SEALDD energy measurement operations;

[0018] FIG. 11 shows an example procedure for SEALDD energy’ credit operations;

[0019] FIG. 12 shows an example procedure for SEALDD energy state aware operations;

[0020] FIG. 13 shows an example procedure for SEALDD renewable energy aware operations;

[0021] FIG. 14 shows an example energy management Graphical User Interface (GUI);

[0022] FIG. 15 A illustrates an example communications system;

[0023] FIG. 15B shows a system diagram of an example RAN and core network;

[0024] FIG. 15C shows a system diagram of an example RAN and core network;

[0025] FIG. 15D shows a system diagram of an example RAN and core network;

[0026] FIG. 15E illustrates another example communications system;

[0027] FIG. 15F is a block diagram of an example apparatus or device, such as a WTRU; and

[0028] FIG. 15G is a block diagram of an exemplary computing system.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0029] Techniques are described herein that enable end-to-end energy aware network flow management to equip networks with the capability to operate with increased levels of energy efficiency and awareness at the granularity of network flows. The described techniques define energy’ ayvare netyvork floyv management functionality for service layers such as the 3GPP SA6 defined Service Enabler Data Delivery (SEALDD) layer.

[0030] The following abbreviations are described herein:CNV15054W001 / 101859.002181

[0031] The following definitions are employed herein:CNV15054W001 / 101859.002181

[0032] FIG. 1 shows the architecture 100 for the Service Enabler Architecture Layer Data Delivery (SEALDD) defined by the 3GPP SA6 working group. SEALDD supports a set of services (SEALDD clients and SEALDD servers) and corresponding reference point APIs to assist with end-to-end distribution, storage, and delivery of application content / data between Vertical Application Layer (VAL) clients and servers. The SEALDD client and SEALDD server support capabilities such as managing the establishment and tear down of individual SEALDD flows between SEALDD clients and SEALDD servers. These SEALDD flows provide high quality and reliable end-to-end network connectivity between VAL clients and VAL servers. The SEALDD flows also support the capability to measure end-to-end transmission quality between VAL clients and VAL servers and trigger actions if / when needed to maintain required quality of service. For example, switching a SEALDD flow between a SEALDD client and one SEALDD server to another SEALDD server for improved transmission quality.

[0033] SEALDD clients and servers interact with one another over the SEALDD-UU reference point. SEALDD clients provide SEALDD services to VAL clients over the SEALDD-C reference point. SEALDD servers provide services to VAL servers over the SEALDD-S reference point. The SEALDD server(s) may communicate with the underlying 3GPP network systems using the respective 3GPP reference points specified by the 3GPP network system such as N33, N5 and N6.

[0034] FIG. 2 shows the SEALDD architecture 200 currently supports managing single independent SEALDD flows between a SEALDD client and SEALDD server. Via aCNV15054W001 / 101859.002181SEALDD flow, the SEALDD client and server manage the end-to-end flow of messages between a VAL client and a VAL server in an end-to-end fashion.

[0035] FIG. 3 shows the SEALDD architecture 300 also supports multi-modal SEALDD flows (for example multi-modal audio, video, positioning, haptic data flows) that may come from different sources (e.g. a single UE, a single device or multiple devices connected to the single UE, or multiple UEs).

[0036] Via SEALDD multi-modal flows, the SEALDD server and clients perform multi-modal traffic transfer and management processing such as end-to-end synchronization of application traffic having multi-modal dependencies with one another. For example, synchronizing bursts of audio, video, positioning and haptic messages across individual flows with one another using a multi-modal SEALDD flow.

[0037] 3GPP systems may currently lack services to manage end-to-end (E2E) message flows between endpoints (e.g., VAL clients and servers) in an energy aware manner. Some examples of energy aware communication flow management capabilities currently lacking may include the following: lack of awareness of available energy credits of a subscriber; lack of awareness of renewable energy’ preferences of a subscriber; lack of energy state information of network resources within the system; lack of capability to measure / calculate the amount of network energy consumed by a subscriber; lack of capability to monitor, detect and expose energy’ state changes of resources in the network; lack of capability to monitor, detect and expose the renewable energy mix consumed by resources in the network; lack of capability’ to throttle the use of network resources by a subscriber based on the amount of energy' consumed by the subscriber vs. the available energy credits of the subscriber; lack of capability to throttle the use of network resources by a subscriber based on the energy state of resources in the network; and lack of capability' to select and manage the network resources used by a subscriber based on the current renewable energy mix consumed by the network resources and the renewable energy preferences of the subscriber. To address the aforementioned shortcomings, this description defines methods and procedures to enhance service layers such as the SEALDD service layer of the 3GPP system with energy aware E2E message flow management services.

[0038] SEALDD clients and servers described herein may be equipped with energy aware SEALDD flow management functionality' capable of performing energy aware SEALDD policy configuration operations. In some examples, the energy aware SEALDDCNV15054W001 / 101859.002181 policy configuration operations may include one or more of the following operations described in this paragraph. An energy aware SEALDD policy configuration request may be received comprising information elements defined in Table 1 such as energy credits, energy credit usage policies, energy consumption policies, renewable energy policies, and energy measurement policies. The policy may be processed and stored for use in establishing energy aware SEALDD flows. An energy aware SEALDD policy configuration response may be sent to the requestor with an indication if the policy was created successfully.

[0039] SEALDD clients and servers described herein may be equipped with energy aware SEALDD flow management functionality capable of performing energy aware SEALDD flow establishment operations. In some examples, the energy aware SEALDD flow7establishment operations may include one or more of the following operations described in this paragraph. A pre-configured energy aware SEALDD policy may be used to establish an energy aware SEALDD flow. Alternatively, an energy aware SEALDD service request may be received to establish an energy aw are SEALDD flow, wherein the request comprises an energy aware SEALDD flow7indicator, energy credit information, and / or renewable energy preferences. Another SEALDD client or server may be discovered with which an energy aware SEALDD flow is capable of being establishing. A request may be sent to the other SEALDD client or server to establish the energy aware SEALDD flow . A request may be sent to a 3GPP network to establish a QoS flow associated with the SEALDD flow7having certain renewable energy preferences, or energy credit limits. A query may be sent to a 3GPP network for available energy credits, energy consumption policies, or renewable energy policies associated with a subscriber. An energy aware SEALDD flow notification may be sent to a VAL client or server comprising energy credit consumption policy, rate and / or schedule defining required energy credits needed to use the SEALDD flow.

[0040] SEALDD clients and servers described herein may be equipped with energy aware SEALDD flow management functionality capable of performing SEALDD energy measurements operations. In some examples, the SEALDD energy measurements operations may include one or more of the following operations described in this paragraph. A preconfigured energy measurement policy may be used in association with the SEALDD energy measurements operations. Alternatively, an energy measurement request may be received, wherein the request comprises requested types of energy measurements, energy measurement collection trigger events, energy measurement schedules, and energy measurement actions.CNV15054W001 / 101859.002181Energy measurement subscription requests may be received from VAL clients and servers, wherein the requests may comprise a type of energy measurement of interest such as the energy consumed by one or more SEALDD flows, an energy measurement threshold value of interest, a time window duration of interest. An energy measurement request may be sent to a 3GPP network comprising identifiers of one or more QoS flows, network slices, or other network resources associated with SEALDD flows for which energy' measurements are to be collected by the 3GPP network, and energy’ thresholds, energy measurement locations of interest pertaining to certain applicable areas of the network or devices, and / or energy measurement reporting schedules of interest. Energy measurements may be performed on SEALDD flows during the exchange of the application layer traffic. Energy’ measurement notifications may be received from 3GPP networks, other SEALDD client or servers comprising energy measurements of interest. Individual energy measurements may be aggregated that are collected locally and / or received from other SEALDD clients and servers or 3GPP network functions. Statistical calculations may be performed such as computing the min, max or average energy consumption w ithin each time period for one or more SEALDD flows. Energymeasurement data may be stored such that it can enable future energy’ measurement statistical calculations. Energy aware SEALDD flow management operations may be performed such as energy credit calculations, energy aware flow control and throttling of SEALDD traffic based on energy’ measurement and / or energy’ measurement policies or requests. Energy measurement notifications may be sent to VAL clients or servers comprising energy measurements of interest to the VAL clients and servers along with timestamp information pertaining to the energy measurements.

[0041] SEALDD clients and servers described herein may be equipped with energy’ aware SEALDD flow' management functionality capable of performing SEALDD energy credit operations. In some examples, the SEALDD energy credit operations may include one or more of the following operations described in this paragraph. Pre-configured energy’ credit policies comprising energy’ credit rules may be used to determine how many’ energy credits are required for a given amount of energy' consumed for a given SEALDD flow. A request may be sent to a 3GPP network to query for available energy’ credits applicable to a subscriber, or a device, VAL client or VAL server associated with a subscriber. A request may be sent to a 3GPP network to retrieve energy credit usage policy information. A request may be sent to a 3GPP network to subscribe to receive energy' credits consumed by 3 GPP network resourcesCNV15054W001 / 101859.002181 associated with a subscriber’s UEs, slices, QoS flows, or other network resources. A request may be sent to a 3GPP network to configure a network function, slice, QoS flow or other network resource with energy credit consumption preferences or limits. Based on energy credit policy and / or energy aware measurements, energy credit operations may be performed for SEALDD flows used to exchange application traffic between VAL clients and servers comprising determining the number of energy credits consumed within a given time period and / or for a given amount of application traffic transferred via the energy aware SEALDD flows. An energy credit notification may be received from a 3GPP network or another SEALDD client or server comprising energy credit consumption information such as the number of credits consumed within a given time period and / or for a given amount of network traffic transferred, and / or associated network resources (e.g., slice IDs, QoS flow IDs, UE IDs). Local energy credit consumption calculations may be aggregated with calculations from 3GPP network functions and / or other SEALDD clients or servers, and statistical calculations may be performed such as computing the total, min, max or average energy credit consumption within each time period. Adaptive energy aware SEALDD flow management operations such as throttling of messages when detecting energy credit consumption has surpassed a defined credit threshold within a defined time duration may be performed based on energy credit consumption calculations. Energy credit notifications may be sent to VAL clients and servers comprising account information such as a subscriber ID and current available energy7credit balance, or low energy credit balance alerts. A request may be sent to a 3GPP network to create an energy credit consumption record and / or charging record for energy credits consumed by a subscriber comprising a number of energy credits consumed and a timestamp of the energy credit consumption.

[0042] SEALDD clients and servers described herein may be equipped with energy aware SEALDD flow management functionality capable of performing SEALDD energy state aware operations. In some examples, the SEALDD energy state aware operations may include one or more of the following operations described in this paragraph. One or more energy state change subscription requests may be sent to a 3GPP network comprising identifiers of one or more QoS flows, network slices, or other network resources associated with SEALDD flows for which energy state changes are to be detected by the 3 GPP network, and / or energy states of interest, state transitions of interest, and / or energy state detection locations of interest. One or more energy state change subscription requests may be sent to other SEALDD clients orCNV15054W001 / 101859.002181 servers to perform energy state change detection operations comprising energy states of interest, state transitions of interest, and / or energy state detection locations of interest. Energy state change subscription requests may be received from VAL clients and servers comprising identifiers of one or more VAL flows, network slices, or other network resources associated with VAL flows for which energy state changes are to be detected by SEALDD, energy states of interest, state transitions of interest, and / or energy state detection locations of interest. An energy state change notification may be received from a 3GPP network function comprising energy state changes and / or transition information of interest. Energy aware SEALDD flow management operations comprising energy aware flow control and throttling of SEALDD traffic based on energy' state of different parts of the overall system may be performed based on an energy state change detected. Energy state change notifications may be sent to VAL clients and servers comprising energy state change information of interest along with timestamp information pertaining to the energy state changes.

[0043] SEALDD clients and servers described herein may be equipped with energy aware SEALDD flow7management functionality7capable of performing SEALDD renewable energy operations. In some examples, the SEALDD renewable energy operations may include one or more of the following operations described in this paragraph. A renewable energy request may be received comprising a subscriber’s renewable energy preferences defining a targeted percentage of renewable energy7sources vs. non-renewable energy7sources (e.g., 80%) which a subscriber is requesting the MNO to use when servicing the subscriber. A request may be sent to a 3 GPP network to obtain or configure renewable energy preferences of a subscriber, a subscriber’s device, or a VAL client or VAL server associated with a subscriber. A request may be sent to a 3GPP network to subscribe to receive renewable energy7related notifications comprising criteria used by the 3GPP network to determine if / when to send renewable energy notifications. Renewable energy subscription requests may be received from VAL clients and servers comprising a network resource of interest such as a VAL flow, SEALDD flow, network slice, or network QoS flow7, and a renewable energy mix threshold value of interest. A renewable energy7notification may be received comprising percentage mix of renewable energy vs. non-renewable energy being used by a network resource of interest. Renewable energy aware operations may be performed for SEALDD flows being used to exchange application traffic between VAL clients and servers, wherein the operations comprise determining the current mix of renewable energy' sources vs. non-renewable energy sources, and if theCNV15054W001 / 101859.002181 renewable energy mix is not meeting the renewable energy' preferences of the subscriber, the SEALDD server may perform one or more actions such as: switching to a different SEALDD server, network function, network slice, QoS flow, and / or other resources having a renewable energy mix which aligns with the subscriber’s preferences. A renewable energy notification may be sent to a VAL client or server comprising account information such as a subscriber ID and the current available renewable energy' mix available, and / or an alert indicating renewable energy mix has dropped below a preferred level.

[0044] To establish and manage end-to-end (E2E) energy aware message flows between VAL clients and servers, energy aware SEALDD flow management functionality is proposed within SEALDD clients and serv ers as shown in FIG. 4 and FIG. 5. This proposed functionality enables message exchanges betw een VAL clients and VAL serv ers to take place in an energy aware manner. Energy awareness may mean that network resources are selected for SEALDD flows based on their energy mix (renewable vs non-renewable) and available energy credits. In other words, it is the process of determining the use of more energy' efficient network resources when servicing network traffic requests. For example, SEALDD message flow management may include awareness of which 3GPP CN and RAN resources are powered by renewable energy sources and the renewable energy' preferences of VAL clients and servers. SEALDD message flow management functionality may also support awareness of energy credits which may be used to control the scheduling and / or throttling of message exchanges via the flow in an energy credit aware fashion. Based on this renewable energy and energy credit information, SEALDD clients and servers may assist in the configuration and management of which 3GPP CN and RAN resources are associated with the SEALDD message flow's. SEALDD message flow' management may also include energy state aw'areness of 3GPP CN and RAN resources. For example, whether certain CN or RAN resources in certain locations / regions of the network are in a normal or low energy state. This energy state awareness may be used by SEALDD clients and servers to control the scheduling and / or throttling of message exchanges via a flow in an energy' state aware manner.

[0045] For each flow of VAL messages exchanged between one or more VAL clients and VAL servers, an energy aware SEALDD flow may be established. In addition, an energy aware multi-modal SEALDD flow may be comprised of one or more individual SEALDD flows used to exchange VAL traffic between one or more SEALDD clients and SEALDD servers in an energy aw are manner.CNV15054W001 / 101859.002181

[0046] FIG. 4 shows an energy aware use case 400 involving a single UE hosting a VAL client communicating with a VAL server. An energy aware SEALDD flow is established and used to exchange traffic between the VAL client and VAL server in an energy aware manner.

[0047] FIG. 5 illustrates a multi-modal energy aware use case 500 involving multiple UEs hosting multiple VAL clients communicating with multiple VAL servers. An energy aware multi-modal SEALDD flow is used to exchange traffic between these VAL clients and VAL servers in an energy aware manner. In this example, the energy aware multi-modal SEALDD flow requires multiple individual energy aware SEALDD flows to provide connectivity between the different SEALDD clients (on the different UEs) and the SEALDD serv er. Also shown is an interface between energy aware SEALDD clients. This interface may be used for synchronizing the energy policies of two UEs participating in the same multi-modal flow.

[0048] Although the energy aware flow management embodiments defined throughout this description refer to a SEALDD client and server, one skilled in the art will recognize that other embodiments may be possible. The described techniques may also be used to enable other types of service layers and services with energy aware flow management support. For example, an XR or Metaverse service supporting client and server functionality may be equipped with the energy aware flow management functionality proposed by this description. In addition, the described energy awareness techniques may also be applied to PDU sessions as well as end-to-end service layer sessions.

[0049] One skilled in the art will also recognize that in addition to defining energy awareness at the granularity of message flows, the ideas proposed in this description may be applied to energy awareness at higher levels of abstraction such as all messages that apply to a specific application (e.g. AIML) or subscriber rather than a message flow of a subscriber.

[0050] SEALDD clients and servers may originate and / or be configured with certain types of energy aware SEALDD flow context. For example, energy aware SEALDD flow context may exist within one or more policies that are configured onto a SEALDD client or server by a VAL client or server and / or by another function in the system. This energy aware flow context may be used by the SEALDD client or server to manage SEALDD flows in an energy aware manner. Alternatively, SEALDD clients and servers may generate and maintain certain types of energy aware SEALDD flow context themselves such as energy aware flow7CNV15054W001 / 101859.002181 measurement data. Lastly, SEALDD clients and servers may interact with other functions in the system (e.g., 3GPP core network or RAN functions) to collect energy aware SEALDD flow context such as energy consumption information.

[0051] Energy aware SEALDD flow context may be comprised of one or more information elements such as but not limited to those defined in Table 1. These information elements may pertain to one or more energy aware SEALDD flows and / or energy aware multimodal SEALDD flows. The information elements may also pertain to VAL flows associated with the SEALDD flows. These flows may be associated with one or more subscribers and their associated UEs and / or application servers. This context may comprise information stored and maintained by one or more SEALDD clients and / or SEALDD servers. The energy aware SEALDD flow context may be stored and maintained on a single entity in the system (e.g., on a SEALDD server) or distributed across multiple entities in the system (e.g., on a SEALDD client and SEALDD server). If energy aware SEALDD flow context is stored and maintained in a distributed manner, SEALDD clients and / or servers may support methods to keep the context synchronized with one another. In addition, if energy aware SEALDD flow context is stored and maintained in a distributed manner, then some entities may only require storing a subset of the context (e.g., a SEALDD client may only require storing a subset of the context while the SEALDD server may store the complete set of context).

[0052] Note, the information shown in Table 1 may be grouped together into one or more policies. A SEALDD client or SEALDD server may be configured with these one or more policies and in turn use these policies to manage energy aware SEALDD flows. A SEALDD client or SEALDD server may be configured with the one or more policies based on procedures proposed in this description and / or by other means.Table 1 - Energy aware SEALDD Flow Context Information ElementsCNV15054W001 / 101859.002181CNV15054W001 / 101859.002181CNV15054W001 / 101859.002181CNV15054W001 / 101859.002181CNV15054W001 / 101859.002181

[0053] FIG. 6 provides an overview 600 of the different types of energy aware SEALDD flow management procedures proposed in this description. For each of the procedures defined in FIG. 6, separate detailed descriptions are defined in subsequent individual procedures described herein. Note, the procedures defined in FIG. 6 may be sequenced in an order different than is shown. In addition, some procedures shown in FIG. 6 may be optional and / or performed independent of other procedures shown.CNV15054W001 / 101859.002181

[0054] FIG. 7 shows an example procedure 700 in which VAL clients or VAL servers may initiate energy aware SEALDD policy configuration requests to SEALDD clients or SEALDD servers. These operations may comprise configuring a SEALDD client or server with one or more energy aware policies such as but not limited to those defined in Table 1. The request may be initiated based on the occurrence of trigger conditions such as the launching of an application by a VAL client or server having some energy consumption requirements or preferences of the subscriber.

[0055] Although the procedure 700 defined in FIG. 7 refers to a VAL client or VAL server initiating these requests, one skilled in the art will recognize that other entities may also issue these requests. For example, another function in the system such as an 0AM function, another SEALDD client or server, or a 3GPP core network or RAN function.

[0056] At step 1, a request originator (e.g.. VAL client or server) may issue an energy aware SEALDD policy configuration request to a SEALDD client or server. The request may include but is not limited to energy aware SEALDD policies and context information defined in Table 1. For example, energy credits, energy credit usage policies, energy7consumption policies, renewable energy policies, and energy measurement policies.

[0057] At step 2, upon receiving the energy aware SEALDD policy configuration request, the targeted SEALDD client or server may process the request by creating and storing the policy for later use. For example, the policies may be used when performing one or more of the other procedures defined in this description.

[0058] At step 3. the targeted SEALDD client or server may generate and return an energy aware SEALDD policy configuration response to the VAL client or VAL server that originated the request. Where the response may include but is not limited to one or more of the energy aware SEALDD flow context information elements defined in Table 1 and / or a status indication of whether the request was successfully processed or not.

[0059] FIG. 8 shows an example procedure 800 in which, once configured with energy aware SEALDD policies, SEALDD clients and servers may use these policies to enforce the establishment of energy aware SEALDD flows. Note, the operations defined in FIG. 8 may be sequenced in an order different than is shown. In addition, some operations shown in FIG. 8 may be optional and / or performed independent of other operations shown.

[0060] At step 1, a SEALDD server can detect a trigger to establish an energy aware SEALDD flow between one or more VAL clients and servers. For example, triggers such asCNV15054W001 / 101859.002181 the connection of one or more VAL clients or servers to the SEALDD client or server or receiving an OAM request from a management function in the system. Alternatively, the SEALDD server may be provisioned with energy aware policies and upon request for SEALDD service, the SEALDD server may utilize the energy aware policies to make a determination to use energy aware SEALDD flow(s). The policies may comprise one or more information elements proposed in Table 1.

[0061] At step 2. once triggered to establish an energy SEALDD flow, a SEALDD server determines an energy aware SEALDD policy that corresponds to the applicable VAL client(s) and server(s) endpoints. Based on this energy aware policy information, the SEALDD server may associate the established flow with a quantity of energy credits available to a subscriber, an energy credit usage policy used by the SEALDD server to determine the number of energy’ credits required for a given amount of SEALDD flow bandwidth within a specific time period, an energy consumption policy used by the SEALDD server to enforce energy consumption thresholds for the flow and actions to take when the thresholds are encountered, a renewable energy policy defining the energy mix (e.g., percentage) of renewable and nonrenewable energy’ sources associated with the flow, and / or an energy measurement policy used to collect energy measurements of the floyv.

[0062] At step 3, a SEALDD server may send one or more requests to a 3GPP network. For example, a request to configure or retrieve energy credit information of a subscriber, subscribe to receive energy consumption notifications from a 3GPP network related to energy consumption for network resources used by a subscriber and / or flow associated with a subscriber, configuring renewable energy preferences of a subscriber. The SEALDD server may also obtain energy related information about network nodes and / or resources, such as average energy consumption rate and energy mix. The SEALDD server may also request energy aware metrics for the SEALDD flow upon the termination of such flow to obtain total usage rate such as energy credit value used by the SEALDD flow. The 3GPP network may determine to update URSP rules to steer traffic for the SEALDD flow to more energy aware network functions (e.g. UPFs) by configuring a particular network slice and / or DNN. Similarly, the 3 GPP network may steer traffic of SEALDD flow towards a network slice that is more energy efficient, e.g. that uses 100% renewable energy or an energy mix where renewable energy usage is a greater percentage than non-renewable energy such as 80 / 20.CNV15054W001 / 101859.002181

[0063] At step 4, a SEALDD server may send an energy aware SEALDD flow establishment request to the SEALDD client. The request may comprise one or more energy aware policies such as but not limited to those defined in Table 1. This request may inform the SEALDD client which energy policy will be used for the flow. Note that the SEALDD flow establishment request may be a regular SEALDD flow establishment request and the energy awareness is in the SEALDD servers and clients.

[0064] At step 5, the SEALDD client may send an energy aware SEALDD flow establishment response to the SEALDD server. The response may comprise a confirmation that the energy aware SEALDD flow has been established on the SEALDD client.

[0065] At step 6, the SEALDD server may send an energy7aware SEALDD flow establishment notification to the VAL server. The notification may comprise information regarding the energy aware SEALDD flow that has been established such as but not limited to information elements defined in Table 1. For example, information regarding energy credits may be sent to the VAL server (e.g. energy credits consumed by the SEALDD server to process VAL traffic over a certain time period or for a given one or more VAL requests, energy credits remaining, an energy credit balance alert, etc.).

[0066] At step 7, the VAL client and VAL server may exchange application layer traffic via the energy aware SEALDD flow once it has been established. During the exchange, the SEALDD client and server may perform energy aware operations such as but not limited to the operations defined in the subsequent procedures of this description.

[0067] FIG. 9 shows an example procedure 900 in which a VAL client or server may initiate an energy aware SEALDD flow establishment request. Upon receiving the request, a SEALDD client or server may process the request and use energy aware information from the request to establish an energy aware SEALDD flow. Note, the operations defined in FIG. 9 may be sequenced in an order different than is shown. In addition, some operations shown in FIG. 9 may be optional and / or performed independent of other operations shown.

[0068] At step 1, VAL clients and servers and / or SEALDD clients and servers may be configured with information (network addresses, security credentials, etc.) enabling them to establish network connectivity with one another and issue requests to one another.

[0069] At step 2. a SEALDD client or server may receive a request to establish an energy aware SEALDD flow between one or more VAL clients and servers. The request mayCNV15054W001 / 101859.002181 comprise energy related information (e.g., an energy aware SEALDD flow indicator, energy credit information, renewable energy' preferences).

[0070] At step 3, the SEALDD client may determine an energy aware SEALDD flow is required and in turn determine a SEALDD server capable of establishing an energy aware SEALDD flow with. The SEALDD client may perform one or more SEALDD server discovery operations in which the SEALDD client may query to find a SEALDD server capable of servicing energy aware SEALDD flows. The discovery request and / or response exchanged between a SEALDD client or server may comprise one or more indications of required and / or supported energy aware SEALDD flow capabilities (e.g. making energy measurements and performing energy' measurement actions) of the SEALDD client and / or server.

[0071] At step 4, the SEALDD client may send an energy aware SEALDD flow establishment request to the SEALDD server. The request may comprise one or more of the information elements defined in Table 1 such as energy credits, renewable energy preferences, etc.

[0072] At step 5, after receiving the request from the SEALDD client, the SEALDD server may perform one or more energy aware operations with a 3 GPP network. For example, the SEALDD server may send a request to configure the 3GPP network with energy centric information related to a SEALDD flow and / or its corresponding VAL client or server. For example, a request to establish a QoS flow associated with the SEALDD flow having certain renewable energy preferences, or energy credit limits. The SEALDD server may also query the 3GPP network to receive energy centric information. For example, to retrieve available energy credits, energy consumption policies, or renewable energy policies associated with a VAL client or server.

[0073] At step 6, upon establishing an energy aware SEALDD flow, a SEALDD server may send an energy aware SEALDD flow establishment notification to a VAL server. The notification may comprise information regarding the energy aw are SEALDD flow such as energy related aspects of the flow- such as the flow ’s energy' credit consumption policy, rate and / or schedule defining required energy credits needed to use the SEALDD flow'. The notification may also comprise renewable energy mix of the SEALDD flow.

[0074] At step 7. the SEALDD server may return an energy aware SEALDD flow establishment response to the SEALDD client. The response may comprise information regarding the energy' aware SEALDD flow' such as the flow’s energy' credit consumptionCNV15054W001 / 101859.002181 policy / rate, its renewable energy mix, and any energy measurements the SEALDD server requires the SEALDD client to perform.

[0075] At step 8, the SEALDD client may return a response to the VAL client comprising information such as energy credit consumption policy, rate and / or schedule defining required energy credits needed to use the SEALDD flow. The response may also comprise renewable energy' mix of the SEALDD flow.

[0076] At step 9, the VAL client and server may exchange VAL traffic via the energy aware SEALDD flow once it has been established. During the exchange, the SEALDD client and server may perform energy aware operations such as but not limited to the operations defined in the subsequent procedures of this description.

[0077] FIG. 10 shows an example procedure 1000 in which SEALDD clients and servers may perform energy centric measurements. While messages are exchanged via SEALDD flows, SEALDD clients and servers can collect energy measurements and / or perform energy aware statistical calculations. Energy' measurements may be based on energy consumption rates for a particular network node / resource computed over the duration of the traffic. The duration of the traffic may further be based on percentage usage over a set period of time. For example, SEALDD flow traffic may only be active for 30% of an hour and energy consumption rates may be a certain watt / hour. Therefore, the energy7computation will take into account that the SEALDD flow was active on only 30% of the hour. Note, the energy7measurement centric operations defined in FIG. 10 may be sequenced in an order different than is shown. In addition, some operations shown in FIG. 10 may be optional and / or performed independent of other operations shown.

[0078] At step 1, SEALDD clients and / or servers may be configured with policies which are used to control the collection and / or calculation of energy measurements related to energy consumption of SEALDD flows. Alternatively, SEALDD clients or servers may receive energy measurement requests from VAL clients or servers. The energy measurement policies and / or requests which a SEALDD client or server receive may comprise information such as but not limited to requested ty pes of energy measurements, energy7measurement collection trigger events, energy measurement schedules, and energy measurement actions as defined in Table 1.

[0079] At step 2, SEALDD clients and / or servers may receive energy measurement subscription requests from VAL clients and servers. The requests may comprise informationCNV15054W001 / 101859.002181 such as the type of energy' measurement of interest to the VAL client or server. The ty pe of measurement may define the energy' consumed by one or more SEALDD flows, an energy measurement threshold value of interest such as an average number of Joules consumed, a time window duration of interest such as a 1 hour, day or week.

[0080] At step 3, a SEALDD server may send one or more energy measurement requests to a 3 GPP network. The requests may comprise information such identifiers of one or more QoS flows, network slices, or other network resources associated with SEALDD flows for which energy measurements are to be collected by the 3 GPP network. The requests may also comprise energy thresholds, energy measurement locations of interest pertaining to certain applicable areas of the network or devices, and / or energy' measurement reporting schedules of interest.

[0081] At step 4, a SEALDD server may send one or more energy measurement subscription requests to SEALDD clients to request that the SEALDD clients perform energy measurement operations and send energy' measurement notifications back to the SEALDD server. The requests may comprise information such as the type of energy measurement of interest to the SEALDD server such as the energy consumed by one or more SEALDD flows, energy measurement collection triggers such as the start / end of SEALDD messages or bursts of SEALDD messages, a time window' duration of interest such as a 1 hour, day or week. Likewise, not shown in the figure, but a SEALDD client may send one or more energy' measurement subscription requests to SEALDD servers.

[0082] At step 5, VAL clients and servers may exchange uplink and downlink application layer traffic via SEALDD flows. During these exchanges SEALDD clients and servers may perform energy' measurement operations such as those described in Step 6 - 13.

[0083] At step 6, SEALDD clients may be equipped to perform energy measurements on the SEALDD flows during the exchange of the application layer traffic. The collection of these measurements by the SEALDD client may be controlled by energy aw are SEALDD flow measurement policies and requests defined in Step 1 and Table 1. The measurements may be collected for individual VAL or SEALDD flows, messages or bursts of messages. These measurements may also be collected for groups of VAL or SEALDD flows (e.g.. multi-modal SEALDD flows).

[0084] At step 7, SEALDD clients may send energy' measurement notifications to SEALDD servers. The notifications may comprise energy' measurements of interest toCNV15054W001 / 101859.002181SEALDD servers as defined by corresponding energy measurement subscriptions defined in Step 4. The notifications may be sent if / when energy measurement thresholds are exceeded, scheduled energy measurement time periods have elapsed, and / or energy measurement service areas or locations are encountered by devices.

[0085] At step 8, 3GPP network functions may be equipped to perform energy measurements. The collection of these measurements by 3GPP network functions may be controlled by energy measurement subscriptions such as those defined in Step 3.

[0086] At step 9. 3GPP network functions may send energy measurement notifications to SEALDD servers. The notifications may comprise energy measurements of interest to SEALDD servers such as those defined by corresponding energy' measurement subscriptions defined in Step 3. The notifications may be sent if / when energy measurement thresholds are exceeded, scheduled energy measurement time periods have elapsed, and / or energy measurement service areas or locations are encountered by devices.

[0087] At step 10, similar to Step 6, SEALDD servers may be equipped to perform energy measurements on the SEALDD flows during the exchange of the application layer traffic. The collection of these measurements by the SEALDD servers may be controlled by energy aware SEALDD flow measurement policies and requests such as those defined in Step 1 and Table 1. The measurements may be collected for individual VAL or SEALDD flows, messages, or bursts of messages. These measurements may also be collected for groups of VAL or SEALDD flows (e.g., multi-modal SEALDD flows).

[0088] At step 11, SEALDD servers may aggregate individual energy measurements which are collected locally by the SEALDD server and / or received from SEALDD clients, 3GPP network functions or from other SEALDD servers. During this aggregation, the SEALDD server may perform statistical calculations such as computing the min, max or average energy consumption within in each time period. These calculations may apply to one or more SEALDD flows. Energy measurement data may be stored locally by the SEALDD server such that it can enable energy measurement statistical calculations. Alternatively, the measurement data may be stored elsewhere by the SEALDD server such as a data repository service in the system. Energy measurement data may be used to perform energy aware SEALDD flow management operations such energy credit calculations, energy aware flow control and throttling of SEALDD traffic.CNV15054W001 / 101859.002181

[0089] At step 12, SEALDD clients or servers may determine if / when to send energy measurement notifications to VAL clients and servers. The determination may be based on energy measurement subscriptions received from VAL clients and servers defining energy measurement notification criteria (See Step 2).

[0090] At step 13, SEALDD clients and servers may send energy measurement notifications to VAL clients and servers. The notifications may comprise energy measurements of interest to the VAL clients and servers along with timestamp information pertaining to the energy measurements.

[0091] FIG. 11 shows an example procedure 1100 in which SEALDD clients and servers may perform energy credit operations. The operations may be performed entirely by SEALDD clients and servers themselves. Alternatively, SEALDD clients and servers may interface to 3GPP core network and / or RAN functions, or other functions or services in the system to perform energy credit operations. Note, the operations defined in FIG. 11 may be sequenced in an order different than is shown. In addition, some operations shown in FIG. 11 may be optional and / or performed independent of other operations shown.

[0092] At step 1. SEALDD clients and / or servers may be configured with policies which are used to control energy credit operations related to usage of SEALDD flows. The energy credit policies may comprise information such as but not limited to the information defined in Table 1. For example, policies defining how many energy credits are required for a given amount of energy consumed when exchanging traffic via a given SEALDD flow. The policies may be based on averages and / or statistical models (e.g., average amount of energy per hour, day or week calculated using statistical analysis / modeling). Different types of energy credit policies may be supported based on criteria such as a subscriber’s renewable energy preferences. For example, if the subscriber has agreed to pay higher subscription fees in exchange for requesting renewable energy sources, then they may be given a more favorable energy credit policy from the MNO.

[0093] At step 2, a SEALDD server may send one or more requests to a 3GPP network to query for available energy' credits applicable to a subscriber, or a device, VAL client or VAL server associated with a subscriber. A SEALDD server may send a request to a 3GPP network to retrieve allowable energy’ credit usage policy information. A SEALDD server may send a request to a 3GPP network to subscribe to receive energy credit information of 3 GPP network resources associated yvith a subscriber’s UEs, slices, QoS floyvs, or other netyvorkCNV15054W001 / 101859.002181 resources. A SEALDD server may send a request to a 3GPP network to configure a network function, slice, QoS flow or other network resources with energy credit consumption preferences or limits.

[0094] At step 3, a SEALDD server may send one or more requests to a SEALDD client to configure the client to perform energy credit operations associated with one or more SEALDD flows.

[0095] At step 4, VAL clients and servers may exchange application traffic via energy aware SEALDD flows. During this exchange. SEALDD clients and servers may perform energy credit operations such as those described in Steps 5 - 14.

[0096] At step 5, a SEALDD client may perform energy credit operations for SEALDD flows used to exchange application traffic between VAL clients and servers. The operations may comprise the SEALDD client determining the number of energy credits consumed within a given time period and / or for a given amount of application traffic transferred via the energy aware SEALDD flows. This determination may be made using the policy information defined in Step 1. This determination may also be made using energy measurements which the SEALDD client performs or collects from other entities in the system. Based on the energy credit consumption policy information and energy measurements, the SEALDD client may calculate the number of energy credits consumed. Statistical analysis and averaging methods may also be used by the SEALDD client to compute energy credit consumption.

[0097] At step 6, a SEALDD client may send an energy credit notification to a SEALDD server. The notification may comprise energy credit consumption information such as the number of credits consumed within a given time period and / or for a given amount of application traffic transferred. The energy consumption information may also include identifiers for one or more associated SEALDD flows.

[0098] At step 7, a 3GPP network function may perform energy credit operations. The operations may comprise determining the number of energy credits consumed within a given time period and / or for a given amount of traffic transferred via the 3GPP network resources (e.g.. network slice or QoS flows).

[0099] At step 8. a 3GPP network function may send an energy credit notification to a SEALDD server. The notification may comprise energy credit consumption information such as the number of credits consumed within a given time period and / or for a given amount ofCNV15054W001 / 101859.002181 network traffic transferred. The energy consumption information may also include identifiers for one or more associated network resources (e.g., slice IDs, QoS flow IDs, UE IDs).

[0100] At step 9. a SEALDD server may perform energy credit operations for SEALDD flows used to exchange application traffic between VAL clients and servers. The operations may comprise the SEALDD server determining the number of energy credits consumed within a given time period and / or for a given amount of application traffic transferred via the energy aware SEALDD flows. This determination may be made using the energy credit consumption policy information defined in Step 1. This determination may also be made using energy measurements which the SEALDD server performs or collects from other entities in the system such as but not limited to SEALDD clients, 3GPP network functions, other SEALDD servers, and / or other functions in the system. Based on the energy credit consumption policy information and energy measurements, the SEALDD server may calculate the number of energy credits consumed. Statistical analysis and averaging methods may also be used by the SEALDD server to compute energy credit consumption.

[0101] At step 10, a SEALDD server may aggregate individual energy credit consumptions which are determined locally by the SEALDD server and / or received from SEALDD clients, 3GPP network functions or from other SEALDD servers. During this aggregation, the SEALDD server may perform statistical calculations such as computing the total, min, max or average energy credit consumption within in each time period.

[0102] At step 11, based on energy credit consumption calculations, a SEALDD client and server may perform adaptive energy aware SEALDD flow management operations. For example, when detecting energy credit consumption has surpassed a defined credit threshold within a defined time duration, a SEALDD client or server may perform actions such as throttling of messages. This throttling may be performed on specific SEALDD flows used to exchange application traffic associated with subscriber’s whose energy credits have surpassed the threshold. If / when energy credits have been refreshed (e.g., at the start of the next time interval), the SEALDD client or server may stop throttling the messages within these SEALDD flows.

[0103] At step 12, a SEALDD client or server may determine whether to send energy credit notifications to VAL clients and servers. This determination may be made based on whether the VAL clients or servers have subscribed to the SEALDD clients or servers toCNV15054W001 / 101859.002181 receive energy credit notifications as well as any criteria they may have specified within these subscriptions (e.g., low energy credit balance alerts).

[0104] At step 13, a SEALDD client or server may send energy credit notifications to VAL clients or servers. The notifications may comprise account information such as a subscriber ID and current available energy credit balance. Notifications may also comprise alerts such as a low energy credit balance alert, or an alert that traffic is being throttled due to a lack of available energy credits.

[0105] At step 14. a SEALDD server may send a request to a 3GPP network to create an energy credit consumption record and / or charging record for energy credits consumed by a subscriber, their device, or their VAL client or server. The record may comprise a number of energy credits consumed and a timestamp of the energy credit consumption.

[0106] Note, a SEALDD client and / or server may perform one or more energy credit operations in addition or in place of one or more of the steps defined in the above procedure. For example, instead of steps 5-14, a SEALDD server may configure a 3GPP network to use energy efficient network nodes / resources (e.g., Network Slice, RAN, UPFs, using a certain renewable energy mix) for the SEALDD flow(s) associated with a UE. After the UE completes sending traffic via the SEALD flow(s), the SEALDD server may collect energy usage information from the network. The SEALDD server may use this information to perform energy aware calculations such as energy7mix, energy credit, and % usage time associated with servicing the UE traffic via the SEALDD flow(s). Based on these calculations, the SEALDD server may inform a VAL server and / or SEALDD client of the calculated results.

[0107] Energy states may apply to various entities, functions and services in the overall system. For example, an energy' state may apply to a UE, a network cell, a network element and / or a network function. Examples of energy states may be a network function which is fully powered up, completely powered down, low power mode, high performance mode, or some in between low power state.

[0108] FIG. 12 shows an example procedure 1200 in which SEALDD clients and servers may perform energy' state aware operations. Energy state aware operations may be performed entirely by SEALDD clients and servers. Alternatively, SEALDD clients and servers may interface to a 3GPP core network. RAN functions, and / or other functions or services in the system to perform energy state aware operations. Note, the energy state aware operations defined in FIG. 12 may be sequenced in an order different than is shown. In addition,CNV15054W001 / 101859.002181 some operations shown in FIG. 12 may be optional and / or performed independent of other operations shown.

[0109] At step 1, energy aware SEALDD flows may be established based on the aforementioned procedures defined in this description.

[0110] At step 2, a SEALDD server may send one or more energy state change subscription requests to a 3GPP network. The request(s) may comprise information such as identifiers of one or more QoS flows, network slices, or other network resources associated with SEALDD flows for which energy state changes are to be detected by the 3GPP network. The requests may also comprise energy states of interest, state transitions of interest, and / or energy state detection locations of interest.

[0111] At step 3, a SEALDD server may send one or more energy state change subscription requests to SEALDD clients to request that the SEALDD clients perform energy state change detection operations (e.g., when UE hosting the SEALDD client changes energy state) and send energy' state change notifications back to the SEALDD server. The requests may also comprise energy states of interest, state transitions of interest, and / or energy state detection locations of interest.

[0112] At step 4, SEALDD clients and / or servers may receive energy state change subscription requests from VAL clients and servers. The requests may comprise information such as identifiers of one or more VAL flows, network slices, or other network resources associated with VAL flows for which energy state changes are to be detected by SEALDD. The requests may also comprise energy states of interest, state transitions of interest, and / or energy state detection locations of interest.

[0113] At step 5, VAL clients and servers may exchange uplink and downlink application layer traffic via SEALDD flows. During these exchanges. SEALDD clients and servers may perform energy state detection and management operations such as those described in Step 6 - 12.

[0114] At step 6, SEALDD clients may be equipped to perform energy state detection and management operations. For example, detecting and / or controlling the energy state of the UE hosting the SEALDD client.

[0115] At step 7, if / when SEALDD clients detect energy state changes involving UEs, they may send energy state change notifications to SEALDD servers. The notificationsCNV15054W001 / 101859.002181 may comprise energy state changes of interest to SEALDD servers as defined by corresponding energy state change subscriptions such as those defined in Step 3.

[0116] At step 8, 3GPP network functions may be equipped to perform energy state change detection and management operations. The detection and management operations of the 3 GPP network functions may be controlled by energy state change subscriptions such as those defined in Step 2.

[0117] At step 9, 3GPP network functions may send energy state change notifications to SEALDD servers. The notifications may comprise energy state changes and / or transition information of interest to SEALDD servers as defined by corresponding energy state change subscriptions such as those defined in Step 2.

[0118] At step 10, similar to Step 6, SEALDD servers may be equipped to perform energy state change detection on the SEALDD servers during the exchange of the application layer traffic.

[0119] At step 11, based on energy' state change detected locally by the SEALDD server and / or received from SEALDD clients, 3GPP network functions or from other SEALDD servers, energy state change information may be used to perform energy’ aware SEALDD flow management operations. These operations may comprise energy' aware flow control and throttling of SEALDD traffic based on energy7state of different parts of the overall system.

[0120] At step 12, SEALDD clients and servers may send energy7state change notifications to VAL clients and servers. The notifications may comprise energy state change information of interest to the VAL clients and servers (based on Step 4) along with timestamp information pertaining to the energy state changes.

[0121] FIG. 13 shows an example procedure 1300 in which SEALDD clients and serv ers may perform renewable energy7aware operations. Renewable energy aware operations may factor the energy mix of network nodes and / or resources used to provide service for the SEALDD flow. The operations may be performed entirely by SEALDD clients and servers themselves. Alternatively, SEALDD clients and servers may interface to a 3GPP core network, RAN functions, and / or other functions or services in the system to perform renewable energy aware operations. Note, the operations defined in FIG. 13 may be sequenced in an order different than is shown. In addition, some operations shown in FIG. 13 may be optional and / or performed independent of other operations shown.CNV15054W001 / 101859.002181

[0122] At step 1 , SEALDD clients and / or servers may be configured with renewable energy policies. Alternatively, SEALDD clients or servers may receive renewable energy information from requests from VAL clients or servers. The renewable energy policies and / or requests which a SEALDD client or server receive may comprise information such as but not limited to a subscriber’s renewable energy preferences. For example, preferences may define a targeted percentage of renewable energy sources vs. non-renewable energy sources (e.g., 80%) which a subscriber is requesting the MNO to use when servicing the subscriber.

[0123] At step 2. a SEALDD server may send one or more requests to a 3GPP network to either obtain or configure renewable energy preferences of a subscriber, a subscriber’s device, or a VAL client or VAL server associated with a subscriber. A SEALDD serv er may send a request to a 3GPP network to subscribe to receive renewable energy related notifications. The subscription may define criteria used by the 3GPP network to determine if / when to send renewable energy notifications to the SEALDD server. For example, the subscription may specify network resources of interest to the SEALDD server such as resources associated with a subscriber’s UEs, network slices, network QoS flows, or other network resources. The subscription may also specify renewable energy conditions such as a certain level of change in the percentage mix of renewable energy sources vs. non-renewable energy sources that a specified network resource of interest is now using.

[0124] At step 3, SEALDD clients and / or servers may receive renewable energy7subscription requests from VAL clients and servers. The requests may comprise information such as a network resource of interest such as a VAL flow, SEALDD flow, network slice, or network QoS flow. The requests may also comprise a renewable energy7mix threshold value of interest such as equal or greater than 70% renewable energy7sources. For example, the request may indicate an energy7mix equal to or greater than 70 / 30 ratio of renewable energy to non-renewable energy usage for the desired flow. In turn, the network may select only7network functions / resources with an energy7mix of 70 / 30 or greater.

[0125] At step 4, a 3GPP network function may perform renewable energy management operations. The operations may comprise controlling and / or detecting the mix of renewable energy vs. non-renewable energy sources that other functions or slices in the network use. The 3GPP network function may also manage the assignment of network functions and slices based on renewable energy preferences of subscribers.CNV15054W001 / 101859.002181

[0126] At step 5, a 3GPP network function may send a renewable energy notification to a SEALDD server. The notification may comprise renewable energy information such as the percentage mix of renewable energy vs. non-renewable energy being used by a network resource of interest to the SEALDD server (e.g., a network function, slice or QoS flow associated with a SEALDD flow).

[0127] At step 6, VAL clients and servers may exchange application traffic via energy aware SEALDD flows. During and / or after these exchanges, a SEALDD client or server may perform renewable energy aware operations such as those defined in Steps 7 - 8.

[0128] At step 7, a SEALDD server may perform renewable energy aware operations for SEALDD flows being used to exchange application traffic between VAL clients and servers. The operations may comprise the SEALDD server determining the current mix of renewable energy sources vs. non-renewable energy sources. This determination may be made based on renewable energy information which the SEALDD server collects locally from its own SEALDD server information, information it collects from a 3GPP network, information it collects from SEALDD clients or other SEALDD servers. A SEALDD sever may compare the renewable energy mix information against the renewable energy preferences of a subscriber. If the renewable energy mix is not meeting the renewable energy preferences of the subscriber, the SEALDD server may perform one or more actions. The SEALDD server may initiate a switch to a different SEALDD server, a different 3GPP network functions, network slices, QoS flows, and / or other resources having a renew able energy mix which aligns with the subscriber’s preferences. Alternatively, the SEALDD server may adjust the energy credit usage policy based on the change in renewable energy mix. For example, a SEALDD server may provide a subscriber with a more favorable or less favorable energy credit usage rate based the renew able energy mix.

[0129] At step 8, a SEALDD client or server may send renewable energy notifications to VAL clients or servers. The notifications may comprise account information such as a subscriber ID and the current available renewable energy mix available. The notifications may comprise alerts such as a renewable energy mix has dropped below7a preferred level. The notification may comprise identifiers of one or more applicable VAL, SEALDD, or 3GPP resources associated with the renewable energy notifications. For example, the identifier of a VAL, SEALDD or QoS flow, or a netw ork slice.CNV15054W001 / 101859.002181

[0130] In one embodiment, SEALDD clients and servers may implement energy aware SEALDD flow context and sen-ices using RESTful APIs. These APIs may be realized as resources having unique addresses (e.g. URIs, URNs, etc.) and may also have one or more attributes that contain resource data and / or metadata. These energy aware SEALDD flow context and service resources may be created, retrieved, discovered, updated, or deleted by VAL clients and servers, other entities such as EESs, ECSs, as well as other SEALDD clients and servers. The SEALDD clients and servers may realize these APIs using RESTful protocols such as HTTP and CoAP. In addition, subscriptions may also be made to flow context and service resources to receive notifications if / when any modifications are made to the resources.

[0131] In another embodiment, SEALDD clients and serv ers may implement energy aware SEALDD flow- context and services as topics within the topic space of a message broker (e.g., MQTT broker, AMQP broker, etc.). A SEALDD client and / or server may function as the message broker. Alternatively, the message broker may be hosted external to the SEALDD client and / or server by another node or function in the network which the SEALDD client and / or server communicates with to create, update, retrieve, delete, and subscribe to energy- aware SEALDD flow context and service topics.

[0132] The topics may have unique addresses (e.g. topic names, etc.) and one or more attributes that contain topic data and / or metadata. These flow- context and service topics may be published to or subscribed to by VAL clients and servers as well as other SEALDD clients and servers.

[0133] FIG. 14 shows an example energy management GUI 1400 embodiment for the features described herein.

[0134] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards comprise WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards, and New Radio (NR), which is also referred to as “5G”. 3GPP NR standards development is expected to continue and comprise the definition of next generation radio access technology (new RAT), which is expected to comprise the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of anew, non-backwards compatible radio access in new spectrum belowCNV15054W001 / 101859.0021817 GHz, and it is expected to comprise different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to comprise cmWave and mmWave spectrum that may provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.

[0135] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases comprise the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency Communication (URLLC), massive machine type communications (mMTC), network operation (e.g.. network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-eveiything (eV2X) communications, which may comprise any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories comprise, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity7, automotive ecall, disaster alerts, realtime gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.

[0136] FIG. 15A illustrates an example communications system 1500 in which the systems, methods, and apparatuses described and claimed herein may be used. The communications system 1500 may comprise wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which generally or collectively may be referred to as WTRU 102 or WTRUs 102. The communications system 1500 may comprise, aradio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110. other networks 112, and Network Services 113. 113. Network Services 113 may comprise, for example, a V2X server, V2X functions, a ProSe server, ProSe functions, loT services, video streaming, federated learning (FL) services, and / or edge computing, etc.CNV15054W001 / 101859.002181

[0137] It may be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In the example of FIG. 15 A, each of the WTRUs 102a-d is depicted in FIGs. 15A-15E as a hand-held wireless communications apparatus. It is understood that with the wide variety of use cases contemplated for wireless communications, each WTRU may comprise or be comprised in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE). a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart w atch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, bus or truck, a train, or an airplane, and the like.

[0138] The communications system 1500 may also comprise abase station 114a and a base station 114b. In the example of FIG. 15A, each base stations 114a and 114b is depicted as a single element. In practice, the base stations 114a and 114b may comprise any number of interconnected base stations and / or network elements. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109. the Internet 110, Network Services 113, and / or the other networks 112. Similarly, base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the Remote Radio Heads (RRHs) 118a, 118b, Transmission and Reception Points (TRPs) 119a, 119b, and / or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication netw orks, such as the core netw ork 106 / 107 / 109, the Internet 110, othernetworks 112, and / or Network Services 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102, e.g., WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, Network Senices 113, and / or other networks 112.

[0139] TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d. to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, Network Services 113, and / or other networks 112. RSUs 120a and 120b may be any type of deviceCNV15054W001 / 101859.002181 configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or Network Services 113. By way of example, the base stations 1 14a, 114b may be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.

[0140] The base station 114a may be part of the RAN 103 / 104 / 105, which may also comprise other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also comprise other base stations and / or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may comprise three transceivers, e.g., one for each sector of the cell. The base station 114a may employ Multiple-Input Multiple Output (MIMO) technology7and, therefore, may utilize multiple transceivers for each sector of the cell, for instance.

[0141] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115 / 1 16 / 117, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable Radio Access Technology (RAT).

[0142] The base station 114b may communicate with one or more of the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b, over a wired or air interface 115b / l 16b / l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave. mmWave, etc.). The air interface 115b / l 16b / l 17b may be established using any suitable RAT.

[0143] The RRHs 118a, 118b, TRPs 119a, 1 19b and / or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interfaceCNV15054W001 / 101859.002181115c / l 16c / l 17c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.) The air interface 115c / l 16c / l 17c may be established using any suitable RAT.

[0144] The WTRUs 102 may communicate with one another over a direct air interface 115d / 116d / 117d, such as Sidelink communication which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.) The air interface 115d / l 16d / l 17d may be established using any suitable RAT.

[0145] The communications system 1500 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC- FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b,TRPs 119a, 119b and / or RSUs 120a and 120b in the RAN 103b / 104b / l 05b and the WTRUs 102c, 102d, 102e. and 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 and / or 115c / l 16c / 117c respectively using Wideband CDMA (WCDMA). WCDMA may comprise communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may comprise High-Speed Downlink Packet Access (HSDPA) and / or High- Speed Uplink Packet Access (HSUPA).

[0146] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c. and 102g, or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c. 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using Long Term Evolution (LTE) and / or LTE- Advanced (LTE- A), for example. The air interface 115 / 116 / 117 or 115c / l 16c / l 17c may implement 3GPP NR technology. The LTE and LTE-A technology may comprise LTE D2D and / or V2X technologies and interfaces (such as Sidelink communications, etc.) Similarly, the 3GPP NR technology may comprise NR V2X technologies and interfaces (such as Sidelink communications, etc.)

[0147] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c. and 102g or RRHs 1 18a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / l 04b / 105b and the WTRUs 102c, 102d, 102e, and 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave AccessCNV15054W001 / 101859.002181(WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0148] The base station 1 14c in FIG. 15A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a train, an aerial, a satellite, a manufactory, a campus, and the hke. The base station 114c and the WTRUs 102, e.g., WTRU 102e, may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRUs 102, e.g., WTRU 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRUs 102, e.g., WRTU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 15 A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0149] The RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice Over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0150] Although not shown in FIG. 15 A, it may be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM or NR radio technology.CNV15054W001 / 101859.002181

[0151] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102 to access the PSTN 108. the Internet 110, and / or other networks 112. The PSTN 108 may comprise circuit-switched telephone networks that provide Plain Old Telephone Service (POTS). The Internet 110 may comprise a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and the internet protocol (IP) in the TCP / IP internet protocol suite. The other networks 112 may comprise wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may comprise any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

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

[0153] Although not shown in FIG. 15 A, it may be appreciated that a User Equipment may make a wired connection to a gateway. The gateway maybe a Residential Gateway (RG). The RG may provide connectivity to a Core Network 106 / 107 / 109. It may be appreciated that many of the ideas contained herein may equally apply to UEs that are WTRUs and UEs that use a wired connection to connect to a network. For example, the ideas that apply to the wireless interfaces 115, 116, 117 and 115c / l 16c / l 17c may equally apply to a wired connection.

[0154] FIG. 15B is a system diagram of an example RAN 103 and core network 106. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 15B, the RAN 103 may comprise Node-Bs 140a. 140b, and 140c, which may each comprise one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) withinCNV15054W001 / 101859.002181 the RAN 103. The RAN 103 may also comprise RNCs 142a, 142b. It may be appreciated that the RAN 103 may comprise any number of Node-Bs and Radio Network Controllers (RNCs.)

[0155] As shown in FIG. 15B, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, and 140c may communicate with the respective RNCs 142a and 142b via an lub interface. The RNCs 142a and 142b may be in communication with one another via an lur interface. Each of the RNCs 142aand 142b may be configured to control the respective Node-Bs 140a, 140b. and 140c to w hich it is connected. In addition, each of the RNCs 142aand 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encry ption, and the like.

[0156] The core network 106 shown in FIG. 15B may comprise a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. While each of the foregoing elements are depicted as part of the core netw ork 106, it may be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0157] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b. and 102c, and traditional land-line communications devices.

[0158] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and 102c, and IP-enabled devices.

[0159] The core network 106 may also be connected to the other networks 112, which may comprise other wired or wireless networks that are owned and / or operated by other service providers.

[0160] FIG. 15C is a system diagram of an example RAN 104 and core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology' to communicateCNV15054W001 / 101859.002181 with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

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

[0163] The core network 107 shown in FIG. 15C may comprise a Mobility Management Gateway (MME) 162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it may be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

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

[0168] FIG. 15D is a system diagram of an example RAN 105 and core network 109. The RAN 105 may employ an NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may employ a non- 3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0169] The RAN 105 may comprise gNode-Bs 180a and 180b. It may be appreciated that the RAN 105 may comprise any number of gNode-Bs. The gNode-Bs 180a and 180b may each comprise one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When integrated access and backhaul connection are used, the same air interface may be used between the WTRUs and gNode-Bs, which may be the core network 109 via one or multiple gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU- MIMO, and / or digital beamforming technology. Thus, the gNode-B 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It should be appreciated that the RAN 105 may employ of other types of base stations such as an eNode-B. It may also be appreciated the RAN 105 may employ more than one t pe of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.CNV15054W001 / 101859.002181

[0170] The N3IWF 199 may comprise a non-3GPP Access Point 180c. It may be appreciated that the N3IWF 199 may comprise any number of non-3GPP Access Points. The non-3GPP Access Point 180c may comprise one or more transceivers for communicating with the WTRUs 102c over the air interface 198. The non-3GPP Access Point 180c may use the 802. 11 protocol to communicate with the WTRU 102c over the air interface 198.

[0171] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As shown in FIG. 15D, the gNode-Bs 180a and 180b may communicate with one another over an Xn interface, for example.

[0172] The core network 109 shown in FIG. 15D may be a 5G core network (5GC). The core network 109 may offer numerous communication services to customers who are interconnected by the radio access network. The core network 109 comprises a number of entities that perform the functionality' of the core network. As used herein, the term “core network entity” or “network function” refers to any entity that performs one or more functionalities of a core network. It is understood that such core network entities may be logical entities that are implemented in the form of computer-executable instructions (software) stored in a memory of, and executing on a processor of, an apparatus configured for wireless and / or network communications or a computer system, such as system 90 illustrated in FIG. 15G.

[0173] In the example of FIG. 15D, the 5G Core Network 109 may comprise an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPFs) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, a User Data Repository’ (UDR) 178. While each of the foregoing elements are depicted as part of the 5G core network 109, it may be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator. It may also be appreciated that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. FIG. 15D shows that network functions directly connect to one another, however, it should be appreciated that they may communicate via routing agents such as a diameter routing agent or message buses.CNV15054W001 / 101859.002181

[0174] In the example of FIG. 15D, connectivity between network functions is achieved via a set of interfaces, or reference points. It may be appreciated that network functions may be modeled, described, or implemented as a set of services that are invoked, or called, by other network functions or services. Invocation of a Network Function service may be achieved via a direct connection between network functions, an exchange of messaging on a message bus, calling a software function, etc.

[0175] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive the user plane tunnel configuration information from the SMF via an Ni l interface. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via an N1 interface. The N1 interface is not shown in FIG. 15D.

[0176] The SMF 174 may be connected to the AMF 172 via an Ni l interface. Similarly the SMF may be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for Session Management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b. and generation of downlink data notifications to the AMF 172.

[0177] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b. and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example. Other Networks 112 may be Ethernet Networks or any ty pe of network that exchanges packets of data. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting a packet data netw ork with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet data networks, the UPF 176 may be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.CNV15054W001 / 101859.002181

[0178] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates a connection between the WTRU 102c and the 5G core network 170. for example, via radio interface technologies that are not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same, or similar, manner that it interacts with the RAN 105.

[0179] The PCF 184 may be connected to the SMF 174 via an N7 interface, connected to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 15D. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. The PCF 184, may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policies to the WTRUs 102a. 102b, and 102c via an N1 interface. Policies may then be enforced, or applied, at the WTRUs 102a, 102b, and 102c.

[0180] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may connect to network functions, so that network function may add to, read from, and modify the data that is in the repository. For example, the UDR 178 may connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196 via an N37 interface, and the UDR 178 may connect to the UDM 197 via an N35 interface.

[0181] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access of the UDR 178. For example, the UDM 197 may connect to the AMF 172 via an N8 interface, the UDM 197 may connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13 interface. The UDR 178 and UDM 197 may be tightly integrated.

[0182] The AUSF 190 performs authentication related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.

[0183] The NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AF) 188. Exposure may occur on the N33 API interface. The NEF may connect to an AF 188 via an N33 interface and it may connect to other network functions in order to expose the capabilities and sendees of the 5G core network 109.

[0184] Application Functions 188 may interact with network functions in the 5G Core Network 109. Interaction between the Application Functions 188 and network functionsCNV15054W001 / 101859.002181 may be via a direct interface or may occur via the NEF 196. The Application Functions 188 may be considered part of the 5G Core Network 109 or may be external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.

[0185] Network Slicing is a mechanism that may be used by mobile network operators to support one or more ‘virtual’ core networks behind the operator’s air interface. This involves ‘slicing' the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g., in the areas of functionality, performance and isolation.

[0186] 3GPP has designed the 5G core network to support Network Slicing. Network Slicing is a good tool that network operators may use to support the diverse set of 5G use cases (e.g., massive loT, critical communications, V2X, and enhanced mobile broadband) which demand very' diverse and sometimes extreme requirements. Without the use of network slicing techniques, it is likely that the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, introduction of new network services should be made more efficient.

[0187] Referring again to FIG. 15D, in a network slicing scenario, a WTRU 102a, 102b, or 102c may connect to an AMF 172, via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU 102a, 102b, or 102c with one or more UPF 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0188] The core network 109 may facilitate communications with other networks. For example, the core network 109 may comprise, or may communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and a PSTN 108. For example, the core network 109 may comprise, or communicate with a short message service (SMS) service center that facilities communicationCNV15054W001 / 101859.002181 via the short message sendee. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets betw een the WTRUs 102a, 102b, and 102c and servers or applications functions 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may comprise other wired or wireless networks that are owned and / or operated by other service providers.

[0189] The core network entities described herein and illustrated in FIGs. 15A, 15C, 15D, and 15E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in FIGs. 15 A, 15B, 15C, 15D, and 15E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

[0190] FIG. 15E illustrates an example communications system 111 in which the systems, methods, apparatuses described herein may be used. Communications system 111 may comprise Wireless Transmit / Receive Units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and Road Side Units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base station gNBs, V2X netw orks, and / or other network elements. One or several or all WTRUs A, B, C, D, E, and F may be out of range of the access network coverage 131. WTRUs A, B, and C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members.

[0191] WTRUs A, B, C, D, E, and F may communicate with each other over a Uu interface 129 via the gNB 121 if they are within the access network coverage 131. In the example of FIG. 15E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate with each other directly via a Sidelink interface (e.g., PC5 or NR PC5) such as interface 125a, 125b, or 128, whether they are under the access network coverage 131 or out of the access network coverage 131. For instance, in the example of FIG. 15E, WRTU D, which is outside of the access network coverage 131, communicates with WTRU F. which is inside the coverage 131.

[0192] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via a Vehicle-to-Network (V2N) 133 or Sidelink interface 125b. WTRUs A, B, C, D, E, and F mayCNV15054W001 / 101859.002181 communicate to a V2X Server 124 via a Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface 128.

[0193] FIG. 15F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communications and operations in accordance with the systems, methods, and apparatuses described herein, such as a WTRU 102 of FIG. 15A, 15B, 15C, 15D, or 15E. As shown in FIG. 15F, the example WTRU 102 may comprise a processor 118, a transceiver 120, a transmit / receive element 122. a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memon 132, apower source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It may be appreciated that the WTRU 102 may comprise any sub-combination of the foregoing elements. Also, the base stations 114a and 114b, and / or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, a next generation node-B (gNode- B), and proxy nodes, among others, may comprise some or all of the elements depicted in FIG. 15F and described herein.

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

[0195] The transmit / receive element 122 of a UE may be configured to transmit signals to, or receive signals from, a base station (e.g.. the base station 114a of FIG. 15A) over the air interface 115 / 116 / 117 or another UE over the air interface 115d / l 16d / l 17d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / orCNV15054W001 / 101859.002181 receive RF signals. The transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It may be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0196] In addition, although the transmit / receive element 122 is depicted in FIG. 15F as a single element, the WTRU 102 may comprise any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may comprise two or more transmit / receive elements 122 (e g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0197] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may comprise multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, for example NR and IEEE 802. 11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0198] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / mi crophone 124, the keypad 126, and / or the display / touchpad / indicators 128 (e.g., a liquid crystal display (ECD) display unit or organic light-emitting diode (OEED) display unit. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory', such as the non-removable memory' 130 and / or the removable memory 132. The nonremovable memory 130 may comprise random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may comprise a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. The processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102. such as on a sen' er that is hosted in the cloud or in an edge computing platform or in a home computer (not shown).

[0199] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102.CNV15054W001 / 101859.002181The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may comprise one or more dry cell batteries, solar cells, fuel cells, and the like.

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

[0201] The processor 118 may further be coupled to other peripherals 138, which may comprise one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may comprise various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass. a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0202] The WTRU 102 may be comprised in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[0203] FIG. 15G is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications networks illustrated in FIGs. 15 A, 15C, 15D and 15E may be embodied, such as certain nodes or functional entities in the RAN 103 / 104 / 105. Core Network 106 / 107 / 109, PSTN 108, Internet 110, Other Networks 112, or Network Services 113. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readableCNV15054W001 / 101859.002181 instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

[0204] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data- transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically comprises data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0205] Memories coupled to system bus 80 comprise random access memory (RAM) 82 and read only memory (ROM) 93. Such memories comprise circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that may not easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it may not access memory within another process’s virtual address space unless memory sharing between the processes has been set up.CNV15054W001 / 101859.002181

[0206] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0207] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may comprise text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touchpanel. Display controller 96 comprises electronic components required to generate a video signal that is sent to display 86.

[0208] Further, computing system 90 may contain communication circuitry', such as for example a wireless or wired network adapter 97, that may be used to connect computing system 90 to an external communications network or devices, such as the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, WTRUs 102, or Other Networks 112 of FIGs. 15A, 15B, 15C, 15D, and 15E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91 , may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0209] It is understood that any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g.. program code) stored on a computer-readable storage medium which instructions, when executed by one or more processors, such as processors 118 or 91, cause the one or more processors to perform and / or implement the systems, methods and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor(s) of an apparatus or computing system configured for wireless and / or wired network communications. Computer readable storage media comprises volatile and nonvolatile, removable and nonremovable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer readable storage media do not comprise signals. Computer readable storage media comprise, but are not limited to. RAM. ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storageCNV15054W001 / 101859.002181 or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.

Claims

CNV15054W001 / 101859.002181What is claimed:

1. An apparatus comprising one or more processors and memory storing instructions which, when executed by the one or more processors, cause the apparatus to: receive an energy aware service layer policy configuration request comprising one or more information elements corresponding to at least one of energy' credits, energy credit usage policies, energy consumption policies, renewable energy policies, or energy’ measurement policies; generate, based on the energy aware policy configuration request, a policy for use in establishing one or more energy aware network floyvs; and send an energy aware service layer policy configuration response with an indication that the policy was created successfully.

2. The apparatus of claim 1, yvherein the one or more energy ayvare netyvork floyvs are associated with one or more Service Enabler Data Delivery (SEALDD) layer floyvs.

3. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more netyvork flow establishment operations.

4. The apparatus of claim 3, wherein the one or more network flow establishment operations comprise at least one of: establishing an energy ayvare netyvork floyv; receiving a request to establish an energy' aware network floyv, wherein the request indicates energy credit information or renewable energy preferences; discovering a client or server capable of establishing an energy ayvare network flow; sending a request to establish an energy ayvare network floyv; sending a request to establish a QoS flow with an energy aware netyvork flow, yvherein the QoS flow is associated with renewable energy preferences or energy credit limits; sending, to a 3GPP network, a query for available energy credits, energy consumption policies, or reneyvable energy policies associated with a subscriber; orCNV15054W001 / 101859.002181 sending an energy aware network flow notification to a Vertical Application Layer (VAL) client or server comprising energy credit consumption policy, rate, or a schedule indicating one or more required energy credits needed to use an energy aware network flow.

5. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more network flow energy measurement operations.

6. The apparatus of claim 5, wherein the one or more network flow energy measurement operations comprise at least one of: using a pre-configured energy measurement policy; receiving an energy measurement request, wherein the request comprises one or more requested types of energy' measurements, energy' measurement collection trigger events, energy measurement schedules, or energy measurement actions; receiving, from a Vertical Application Layer (VAL) client or server, an energy measurement subscnption request, wherein the request comprises a type of energy measurement of interest, wherein the energy' measurement of interest comprises at least one of energy consumed by the one or more energy' aware network flows, an energy' measurement threshold value of interest, or a time window duration of interest; sending an energy measurement request comprising one or more identifiers of one or more QoS flows, network slices, or other network resources associated with the one or more energy' aware network flows, and one or more energy thresholds, one or more energy' measurement locations of interest pertaining to certain applicable areas, or one or more energy measurement reporting schedules of interest; performing one or more energy measurements on the one or more energy aware network flows during an exchange of the application layer traffic; receiving one or more energy' measurement notifications; aggregating one or more energy measurements; performing one or more statistical calculations, wherein the one or more statistical calculations comprise one or more of computing a min, a max, or an average energy consumption within in each time period for the one or more energy' aware network flows;CNV15054W001 / 101859.002181 storing energy measurement data such that it can enable future energy measurement statistical calculations; performing, based on energy measurement or energy measurement policies or requests, energy aware network flow management operations comprising at least one of energy credit calculations, energy aware flow control, or energy aware throttling of network traffic based on energy measurement or energy measurement policies or requests; or sending energy’ measurement notifications to one or more VAL clients or serv ers comprising energy measurements of interest to the one or more VAL clients and servers along with timestamp information pertaining to the energy' measurements.

7. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more energy credit operations, wherein the one or more energy credit operations use the policy to determine a quantity' of energy credits required for a given amount of energy consumed for an energy aware network flow s of the one or more energy aware network flows.

8. The apparatus of claim 7, wherein the one or more energy credit operations further comprise sending a request for available energy' credits applicable to a subscriber, a device, Vertical Application Layer (VAL) client, or a VAL server associated with a subscriber.

9. The apparatus of claim 1 , wherein the instructions, w hen executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more network flow energy state aware operations.

10. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more network flow renewable energy' operations.

11. A method comprising: receiving an energy' aware sendee layer policy configuration request comprising one or more information elements corresponding to at least one of energy' credits, energy' credit usageCNV15054W001 / 101859.002181 policies, energy consumption policies, renewable energy policies, or energy measurement policies; generating, based on the energy aware policy configuration request, a policy for use in establishing one or more energy aware network flows; and sending an energy aware service layer policy configuration response with an indication that the policy was created successfully.

12. The method of claim 11, wherein the one or more energy aware network flows are associated with one or more Service Enabler Data Delivery (SEALDD) layer flows.

13. The method of claim 11, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more network flow establishment operations.

14. The method of claim 13, wherein the one or more network flow establishment operations comprise at least one of establishing an energy aware network flow; receiving a request to establish an energy aware network flow, wherein the request indicates energy7credit information or renewable energy preferences; discovering a client or server capable of establishing an energy aware network flow ; sending a request to establish an energy aware network flow; sending a request to establish a QoS flow with an energy aware network flow, wherein the QoS flow is associated with renewable energy’ preferences or energy’ credit limits; sending, to a 3GPP network, a query for available energy credits, energy consumption policies, or renewable energy policies associated with a subscriber; or sending an energy aware network flow notification to a Vertical Application Layer (VAL) client or server comprising energy’ credit consumption policy, rate, or a schedule indicating one or more required energy' credits needed to use an energy aware network flow.

15. The method of claim 11, wherein the instructions, when executed by the one or more processors, further cause the apparatus to:CNV15054W001 / 101859.002181 perform, based on the policy, one or more network flow energy' measurement operations.

16. The method of claim 15, wherein the one or more network flow energy measurement operations comprise at least one of: using a pre-configured energy' measurement policy; receiving an energy’ measurement request, wherein the request comprises one or more requested types of energy’ measurements, energy measurement collection trigger events, energy measurement schedules, or energy measurement actions; receiving, from a Vertical Application Layer (VAL) client or server, an energy’ measurement subscription request, wherein the request comprises a type of energy measurement of interest, wherein the energy measurement of interest comprises at least one of energy consumed by the one or more energy aware network flows, an energy measurement threshold value of interest, or a time window duration of interest; sending an energy measurement request comprising one or more identifiers of one or more QoS flows, network slices, or other network resources associated with the one or more energy aware network flows, and one or more energy thresholds, one or more energy measurement locations of interest pertaining to certain applicable areas, or one or more energy measurement reporting schedules of interest; performing one or more energy measurements on the one or more energy aware network flows during an exchange of the application layer traffic; receiving one or more energy' measurement notifications; aggregating one or more energy' measurements; performing one or more statistical calculations, wherein the one or more statistical calculations comprise one or more of computing a min, a max, or an average energy consumption within in each time period for the one or more energy aware network flows; storing energy measurement data such that it can enable future energy measurement statistical calculations; performing, based on energy measurement or energy measurement policies or requests, energy aware network flow management operations comprising at least one of energy credit calculations, energy aware flow control, or energy’ aware throttling of network traffic based on energy measurement or energy' measurement policies or requests; orCNV15054W001 / 101859.002181 sending energy' measurement notifications to one or more VAL clients or servers comprising energy measurements of interest to the one or more VAL clients and servers along with timestamp information pertaining to the energy’ measurements.

17. The method of claim 11, wherein the instructions, w hen executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more energy credit operations, wherein the one or more energy credit operations use the policy to determine a quantity’ of energy credits required for a given amount of energy’ consumed for an energy aware netw ork flows of the one or more energy aware network flows.

18. The method of claim 17, wherein the one or more energy credit operations further comprise sending a request for available energy credits applicable to a subscriber, a device, Vertical Application Layer (VAL) client, or a VAL server associated with a subscriber.

19. The method of claim 11, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more network flow energy state aw are operations.

20. The method of claim 11, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: perform, based on the policy, one or more network flow' renewable energy operations.

Images