Methods and systems to aggregate battery status information in a mobile network

Abstract

Embodiments include methods, network device, storage medium, and computer program for aggregating battery status information in a mobile network. In one embodiment, a method comprises obtaining battery status information of battery-powered vehicles in a plurality of geographic zones of a mobile network, wherein battery status information from one battery- powered vehicle indicates a geographic zone in which the one battery-powered vehicle is located when the battery status information is obtained; aggregating the battery status information from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network; and providing the battery status information aggregated on the per geographic zone basis to manage power demand in the plurality of geographic zones.

Description

Atty. Docket No.: 4906P112510W001SPECIFICATIONMETHODS AND SYSTEMS TO AGGREGATE BATTERY STATUS INFORMATION IN A MOBILE NETWORKTECHNICAL FIELD

[0001] Embodiments of the invention relate to the field of networking; and more specifically, to aggregating battery status information in a mobile network.BACKGROUND ART

[0002] Electric vehicles (EVs) are gaining popularity in recent years. With zero emissions and renewable energy integration, their advantages over internal combustion engine vehicles (ICEVs) in sustainable development are widely recognized and EV sales are experiencing substantial growth globally.

[0003] Yet the proliferation of EVs leads to a huge demand for recharging stations, which supply power to the EVs. Recharging stations may replace / supplement the fuel distribution stations for ICEVs and become a part of urban or even rural infrastructures. The recharging stations may be public, managed by local regulators and administrators of townships and / or metropolitan areas, or private, managed by subscribers to private garages or community spaces. Energy providers (also referred to as utility companies, electricity / power / energy suppliers, or similar terms) provide electricity to the recharging stations based on their fluctuating electricity needs.

[0004] How to provide electricity for the scattering recharging stations managed by different entities poses challenges to energy providers, public utilities commissions, energy regulators, and local / national governments alike. Additionally, where to build additional recharging stations and in what sequence to accommodate the surging volume of EVs are issues that need to be addressed soon so that the potential benefits of EVs can be fully realized.

[0005] EVs are powered by battery, and if the battery statuses of the EVs can be obtained, that information may be used to manage electricity distribution to the recharging stations. For example, if it is known that a large number of EVs are near a recharging station, the corresponding energy provider may adjust the supply to deliver more electricity to the recharging station, through the distribution grid and transformers. Additionally, if it is observed that certain regions consistently have higher volumes of operating EVs, new recharging stations may be installed in these regions.Atty. Docket No.: 4906P112510W001

[0006] However, the battery status of the EV someone drives is often considered personal data, as it may reveal the driver’s routines and additional personal information. Various jurisdictions have numerous laws and regulations to be complied with regarding personal data, including General Data Protection Regulation (GDPR) in Europe, California Consumer Privacy Act (CCPA), Payment Card Industry Data Security Standard (PCI DSS), Japan's Act on the Protection of Personal Information (APPI), and India's Digital Personal Data Protection Act (DPDP). It is thus challenging to collect battery status information of EVs (or other battery-powered vehicles) to effectively manage the resulting power demand without violating consumer privacy.SUMMARY OF THE INVENTION

[0007] Embodiments include methods, network device, storage medium, and computer program for aggregating battery status information in a mobile network. In one embodiment, a method comprises obtaining battery status information of battery-powered vehicles in a plurality of geographic zones of a mobile network, wherein battery status information from one battery-powered vehicle indicates a geographic zone in which the one battery-powered vehicle is located when the battery status information is obtained; aggregating the battery status information from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network; and providing the battery status information aggregated on the per geographic zone basis to manage power demand in the plurality of geographic zones.

[0008] Embodiments include electronic devices to aggregate battery status information in a mobile network. In one embodiment, an electronic device comprises a processor and machine-readable storage medium that provides instructions that, when executed by the processor, are capable of causing the processor to perform: obtaining battery status information of battery-powered vehicles in a plurality of geographic zones of a mobile network, wherein battery status information from one battery-powered vehicle indicates a geographic zone in which the one battery-powered vehicle is located when the battery status information is obtained; aggregating the battery status information from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network; and providing the battery status information aggregated on the per geographic zone basis to manage power demand in the plurality of geographic zones.

[0009] Embodiments include machine-readable storage media for aggregating battery status information in a mobile network. In one embodiment, a machine-readable storage medium provides instructions that, when executed by a processor, are capable of causing the processor to perform: obtaining battery status information of battery-powered vehicles in a plurality ofAtty. Docket No.: 4906P112510W001geographic zones of a mobile network, wherein battery status information from one battery-powered vehicle indicates a geographic zone in which the one battery-powered vehicle is located when the battery status information is obtained; aggregating the battery status information from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network; and providing the battery status information aggregated on the per geographic zone basis to manage power demand in the plurality of geographic zones.

[0010] Through these embodiments, the battery status information is obtained from battery-powered vehicles through network functions (NFs) of a mobile network, where the battery-powered vehicle provides the battery status information along with other information that has been provided already. By leveraging the operations of existing network functions, these embodiments minimize the risk of invading drivers’ privacy and yet allow the battery status information from the battery-powered vehicles to be used to manage the power demand.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

[0012] Figure 1 illustrates power demand management based on aggregated battery status information on a geographic-zone-basis per some embodiments.

[0013] Figure 2 illustrates a network function to obtain and aggregate battery status information from battery-powered vehicles and other existing network functions in a mobile network architecture per some embodiments.

[0014] Figure 3 illustrates operations to register a service in a mobile network to obtain aggregated battery status per some embodiments.

[0015] Figure 4 illustrates operations to register an electric vehicle (EV) in a mobile network for location tracking per some embodiments.

[0016] Figure 5 illustrates operations to collect battery status information from an electric vehicle (EV) in a mobile network per some embodiments.

[0017] Figure 6 illustrates network functions and information exchanged for battery status information aggregation in a mobile network per some embodiments.

[0018] Figure 7 is a flow diagram illustrating operations for power demand management based on aggregated battery status information on a geographic-zone-basis per someembodiments.Atty. Docket No.: 4906P112510W001

[0019] Figure 8A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.

[0020] Figure 8B illustrates an exemplary way to implement a special-purpose network device according to some embodiments of the invention.

[0021] Figure 8C illustrates various exemplary ways in which virtual network elements (VNEs) may be coupled according to some embodiments of the invention.

[0022] Figure 8D illustrates a network with a single network element (NE) on each of the NDs, and within this straightforward approach contrasts a traditional distributed approach (commonly used by traditional routers) with a centralized approach for maintaining reachability and forwarding information (also called network control), according to some embodiments of the invention.

[0023] Figure 8E illustrates the simple case where each of the NDs implements a single NE, but a centralized control plane has abstracted multiple of the NEs in different NDs into (to represent) a single NE in one of the virtual network(s), according to some embodiments of the invention.

[0024] Figure 8F illustrates a case where multiple VNEs are implemented on different NDs and are coupled to each other, and where a centralized control plane has abstracted these multiple VNEs such that they appear as a single VNE within one of the virtual networks, according to some embodiments of the invention.

[0025] Figure 9 illustrates a control plane device including a set of one or more processor(s) as well as non-transitory machine-readable storage media per some embodiments.

[0026] Figure 10 illustrates an example of a communication system per some embodiments.DETAILED DESCRIPTION

[0027] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa.Atty. Docket No.: 4906P112510W001Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.Network Function of Mobile Network for Battery Status Information

[0028] Embodiments of the present disclosure leverage network functions of mobile networks to manage power demand by battery-powered vehicles operating in the mobile networks. The term “battery-powered vehicle” encompasses vehicles such as electric car / vehicle (also referred to as EV), zero-emission vehicle (ZEV), hybrid electric vehicle (HEV), plug-in electric vehicle (PEV), plug-in hybrid electric vehicle (PHEV), battery electric vehicle (BEV), and other similar terms describing any vehicles / vessels / aircrafts that are powered at least partially by battery (instead of internal combustion engine vehicles, which rely on burning fossil fuels solely to power the engine). Additionally, the battery-powered vehicles disclosed herein include ones that operate on roads, in water (e.g., an amphibious vehicle or an electric vessel), as well as over the airspace (e.g., an electric vertical takeoff and landing (eVTOL) aircraft). Furthermore, the battery-powered vehicles disclosed herein may be operated by an onboard human driver, remote controlled by a human, or self-driven (e.g., autonomous EV (AEV) based on autonomous driving technology, using sensors, cameras, radar, LiDAR, and artificial intelligence (Al) to navigate without human input). While electric vehicles (EVs) are often used herein as examples of battery-powered vehicles, the disclosed embodiments are applicable to other types of battery-powered vehicles as well.

[0029] Recharging stations draw electricity from the electrical grid or renewal sources (e.g., solar panels) and convert high-voltage alternating current (AC) or direct current (DC) power to a form compatible with the onboard batteries of battery-powered vehicles. When the electricity of the onboard batteries of a battery-powered vehicle is deemed insufficient, the battery-powered vehicle may arrive at the premises of a recharging station to be connected to the recharging station through a charging cable. Through a charging process including authentication and payment, the battery-powered vehicle completes its charging and then drives away to continue its route to destination.

[0030] Providing sufficient electricity to the recharging stations requires knowledge of how many battery-powered vehicles would be charged at given recharging stations at what frequency. If the battery-powered vehicles provide real-time or near real-time battery status information to the recharging stations, an operator of the recharging stations may adjust electricity distribution to the recharging stations based on such information to satisfy the need of the battery-powered vehicles. Yet the battery status information of a battery-powered vehicle is often considered personal data of the driver. Even for a battery-powered vehicle without a human, the battery status information along with the location of the vehicle, reveals the owner’sAtty. Docket No.: 4906P112510W001routine and is considered personal data of the owner. The laws and regulations in the various jurisdictions may prevent the operator of the recharging stations from obtaining the battery status information. Even if the drivers / owners of the battery-powered vehicles consent to the collection of battery status information by the operator of the recharging stations, it is a demanding task to build the infrastructure to obtain, process, and disseminate the information to allow the recharging stations to operate more efficiently and / or to build future recharging stations at strategic locations.

[0031] It is observed that mobile networks already operate following rules and regulations regarding personal data under standards developed by multiple standardization bodies, including the 3rd Generation Partnership Project (3GPP), the International Telecommunication Union (ITU), the Global System for Mobile Communications Association (GSMA), the Institute of Electrical and Electronics Engineers (IEEE), the European Telecommunications Standards Institute (ETSI), and the Next G Alliance. These organizations set technical standards, ensure global interoperability, and guide spectrum allocation in the fourth generation (4G), fifth generation (5G) and six generation (6G) mobile networks. A battery-powered vehicle roaming in a mobile network already provides ample information, including personal data and with user’s consent, to the mobile network through network functions (NFs) defined per standards. The interfaces of these NFs to obtain and disseminate the information can be used for battery status information collection as they are and / or new network function and corresponding interface may be added to manage battery status information of the battery-powered vehicles (e.g., to manage power demands for recharging stations).

[0032] While recharging is discussed as one application of utilizing the battery status information collected from battery-powered vehicles, embodiments of the present disclosure are not so limited, and the battery status information may be used for applications such as urban development by governments (e.g., identifying / mitigating congestion spots where battery consumption is high), product improvement by private parties (e.g., identifying quick battery consumption scenarios such as hot / cold weather to improve upon), or other ones to provide services based on real-time or historical aggregated battery status information from battery-powered vehicles. The aggregation of the battery status information through embodiments disclosed herein, leveraging the existing mobile network architecture, is agnostic to how the aggregated battery status information is utilized subsequently.

[0033] Figure 1 illustrates power demand management based on aggregated battery status information on a geographic-zone-basis per some embodiments. The left part of Figure 1 shows a set of geographic zones, referred to as pre-defined geographic zones (PGZs), with a number of EVs roaming within. A pre-defined geographic zone refers to a specific area within a networkAtty. Docket No.: 4906P112510W001(e.g., a mobile network) where certain policies, services, or optimizations are applied based on location. These zones are typically used for network slicing, mobility management, and service differentiation. A pre-defined graphic zone may also be referred to as a tract, a locale, a subdivision, a grid, a region, a boundary / bounded area, or similar terms.

[0034] In some embodiments, a PGZ corresponds to one or more cell coverage areas of a mobile network. A cell coverage area is a geographic area covered by a single base station (e.g., a cell tower) that provides cellular service to User Equipment (UEs) within. Each cell represents a unit of the network and has a unique identifier and operates on specific frequencies, time slots, or codes to communicate with UEs such as EVs in the corresponding cell coverage area. When the PGZ corresponds to the cell coverage areas, the status of the EVs, including the battery status information may then be obtained using network functions that are already defined and that operate for other services provided in the mobile network.

[0035] The EVs are shown in the PGZs as rectangle boxes with different pattern fills. The pattern fills represent the respective battery levels of the EVs. The lightest pattern indicates the highest battery level with the least need to recharge (e.g., no need to recharge any time soon), the darker one indicates the medium battery level with a medium need to recharge (e.g., need to recharge after a certain additional milage), and the darkest one indicates the lowest battery level with the urgent need to recharge (e.g., need to recharge as soon as possible). While three levels of battery levels are shown, different battery levels may be indicated in different embodiments, e.g., the battery levels may be shown as percentage relative to full, the remaining mileages an EV may still drive with the current battery level, or other indications of battery levels.

[0036] An EV roaming in a mobile network is tracked, e.g., using an EV identity circuitry indicates an EV identifier (EV ID), which maps to the EV or the driver / owner of the EV.EV ID may be an International Mobile Subscriber Identity (IMSI). Some embodiments may use a different identifier, e.g., a Globally Unique Temporary Identifier (GUTI) temporarily assigned to EV 402 (to protect the IMSI from being exposed to enhance security / privacy), a Subscription Permanent Identifier (SUPI), a Subscription Concealed Identifier (SUCI) (an encrypted version of a corresponding SUPI), an International Mobile Equipment Identity (IMEI) to identify EV 402, Temporary Mobile Subscriber Identity (TMSI), a Mobile Station International Subscriber Directory Number (MSISDN) which is a phone number associated with the driver, or another valid identifier. The EV ID may be used for real-time vehicle diagnostics, infotainment, navigation, and over-the-air software updates.

[0037] In some embodiments, the EV ID is provided by a subscriber identity module (SIM), an embedded SIM, or an integrated SIM (iSIM). An SIM / eSIM may be implemented as a small, soldered computer chip or software logic built into the vehicle's telematics control unit (TCU) orAtty. Docket No.: 4906P112510W001connectivity module and stores multiple carrier profiles and be remotely provisioned or updated over the air (OTA) without needing physical replacement. An iSIM is integrated directly into the vehicle’s main processor or modem chipset, eliminating the need for a separate SIM chip, and it provides functions similar to eSIM. Either SIM (or other types of circuitries to identify the corresponding EV) interacts with mobile networks as the EV roams around different locations in the mobile networks. The communication between an EV’s SIM / eSIM / iSIM and a mobile network relies on several key standards to ensure secure, reliable, and efficient connectivity, including 3GPP, ITU, GSMA and others. For simplicity of explanation, eSIM is used to describe some embodiments, but other identification circuitries may be used in these and other embodiments for providing battery status information.

[0038] A new network function can be used to obtain and aggregate the battery status information from all the EVs based on the communication between the EV identity circuitries and mobile networks. The new network function is referred to as battery anonymization and aggregation function (BAAF) 125 as shown in Figure 1.

[0039] In some embodiments, BAAF 125 obtains the battery status information of the EVs per PGZ (shown at reference 110) through the south bound interface (SBI) 150 between the EVs and the mobile network, anonymizes and aggregates it prior to disseminating the resulting aggregated battery status information to an application (e.g., external service 650 in Figure 6). The dissemination is through a north bound interface (NBI 152). The application uses the aggregated status information per PGZ to provide its service (e.g., managing power demand of recharging stations). In some embodiments, the anonymization operation of BAAF 125 may be omitted (e.g., when the drivers / owners of the EVs agree to be individually tracked for battery status information without anonymization).

[0040] In some embodiments, the application provides a power demand map per PGZ as shown at reference 115. The power demand map includes the same PGZs (PGZ #1 to #6), where the shade colors indicate the relative demands of different PGZs. For a PGZ such as PGZ #6, without a roaming EV, there is no power demand. For PGZs with a large number of the lowest battery level (e.g., PGZ #3), the power demand is high, while the remaining PGZs have the medium power demand. While three levels of power demand are shown, a power demand map may have a range of different levels, and they may correspond to a variety of numbers EVs (or compositions of mixed EVs) per PGZ.

[0041] While the power demand map may indicate the current power demand by EVs per PGZ, other power demand maps may be generated to forecast future power demand by EVs per PGZ in different time scales. For example, based on the (current and / or historical) aggregated battery status information, a power demand map may be generated to indicate the power demandAtty. Docket No.: 4906P112510W001by EVs per PGZ in the next days, weeks, months, or even years. Such forecasts may allow planners to determine where to add recharging stations and in what time sequence to meet the demands of the EVs.

[0042] BAAF 125 as a network function may be implemented to comply with existing standards so that BAAF 125 may interact with existing network functions through the existing defined interfaces (e.g., APIs). Such compliance allows the battery status information to be obtained and aggregated in the existing network architecture without the need of a new network architecture, which takes substantial time to be reviewed, approved, and adopted.Interactions of Network Functions (NFs)

[0043] Embodiments of the disclosure implement a network function to obtain and aggregate the battery status information from battery-powered vehicles such as EVs interacting with existing network functions of a mobile network. The network function, referred to as BAAF 125, complies with existing standards to interact with existing network functions.

[0044] Figure 2 illustrates a network function to obtain and aggregate battery status information from battery-powered vehicles and other existing network functions in a mobile network architecture per some embodiments. The mobile network architecture 200 is based on the 3GPP’s Service-Based Architecture (SB A), the details of which is explained in standards such as the #GPP TS 23.501 version 16.6.0, release 16, entitled “System Architecture for the 5G System” and dated October 2020.

[0045] The mobile network architecture 200 includes BAAF 125, and as shown, several network functions that interact with BAAF 125 extensively are highlighted with shaded boxes and added reference numbers. A network function, through a service-based interface (e.g., Nnssf stands for Service-based interface for Network Slice Selection Function) and / or reference point (e.g., one of N1-N4, N6, and N9), to interact with other network functions, UEs, (Radio) Access Network ((R)AN), and Data Network (DN). These highlighted network functions are now explained in further detail. For generic functionalities of these network functions and other network functions, please refer to the latest mobile network architecture standards, including the 3GPP ones for SBA. An EV in a mobile network is a type of UEs that operates in the mobile network.Network Exposure Function (NEF)

[0046] Exposure of network capabilities: NEF 202 provides a standardized interface through which external applications can access various network services and capabilities. This includes accessing information about user location, session status, QoS parameters, and other network metrics.Atty. Docket No.: 4906P112510W001

[0047] Security and privacy: NEF 202 ensures that any interaction between external applications and the mobile network adheres to security and privacy requirements. It provides mechanisms for authentication, authorization, and auditing of external application requests to protect sensitive user data and network integrity.

[0048] Application programming interface (API) Gateway: NEF 202 acts as an API gateway, translating external application requests into appropriate network function calls within the mobile network. It abstracts the complexity of the underlying network architecture from external applications, offering a simplified and consistent interface.

[0049] Policy Enforcement: NEF 202 enforces network policies regarding the exposure of data and services. This can involve checking that external application requests comply with operator-defined policies and user consent.

[0050] Monitoring and Analytics: Through NEF 202, external applications can receive notifications or subscribe to events related to network and user activity. This can include changes in user context, session events, or network status, which can be used for analytics and enhanced service delivery.

[0051] Interworking with Other Network Functions: NEF 202 interacts with other network functions, such as the Policy Control Function (PCF), Session Management Function (SMF) 208, and User Plane Function (UPF) 220, to gather information or perform actions requested by external applications.Access and Mobility Management Function (AMF)

[0052] Registration Management: AMF 206 handles the registration and authentication of User Equipment (UE), such as an EV, when the UE first connects to the network. This involves managing the initial attachment procedure and maintaining the registration state of the UE. AMF 206 interacts with the Authentication Server Function (AUSF) and Unified Data Management (UDM) 204 to authenticate the user and retrieve subscription data.

[0053] Connection and Mobility Management: AMF 206 is responsible for managing the signaling connection between the UE and the network. This includes handling the setup, modification, and release of signaling connections. Additionally, AMF 206 manages mobility-related procedures, such as handovers between different radio access technologies (e.g., from 4G to 5G) and different cells or base stations within the network. It ensures seamless connectivity as users move around geographically.

[0054] Access Authorization and Security: AMF 206 plays a crucial role in ensuring secure access to the network. It enforces access control policies and manages security contexts for communication between the UE and the network. This includes establishing secure signalingAtty. Docket No.: 4906P112510W001paths and coordinating with other network functions like the Security Edge Protection Proxy (SEPP) to maintain the integrity and confidentiality of user data.

[0055] Overall, AMF 206 facilitates efficient and secure access and mobility management for users and devices. It works closely with other network functions, such as Session Management Function (SMF) 208, User Plane Function (UPF) 220, Location Management Function (LMF), and Gateway Mobile Location center (GMLC) to provide an external interface for location services, handling requests from external services (e.g., external service 650) while enforcing privacy and authorization policies in the mobile network.

[0056] Note that the LMF determines the UE locations within the network. It gathers location data from various sources like radio signals and assists AMF 206 in tracking device positions. The GMLC extends location management to a broader scope, especially for inter-network scenarios, and it helps in coordinating location data between different networks or larger geographic areas.Session Management Function (SMF)

[0057] Session establishment, modification, and release: SMF 208 is responsible for setting up, modifying, and terminating Protocol Data Unit (PDU) sessions for user equipment (UE). A PDU session represents a data connection for transferring user data between the UE and a data network. SMF 208 manages the lifecycle of these sessions, ensuring that resources are allocated and released as needed.

[0058] IP Address Allocation and Management: During the establishment of a PDU session, SMF 208 is responsible for assigning IP addresses to the UE. It manages the allocation and configuration of IP addresses, whether they are IPv4 or IPv6, and ensures that the UE can communicate with external data networks.

[0059] Traffic Routing and QoS Management: SMF 208 is involved in determining the appropriate routing path for user data traffic through the network. It interacts with UPF 220 to enforce Quality of Service (QoS) policies, ensuring that data traffic meets the required performance characteristics (e.g., latency, bandwidth) as specified by the network operator or user subscription.

[0060] Policy Enforcement and Charging: SMF 208 enforces network policies related to data sessions, such as data usage limits and prioritization of certain types of traffic. It interacts with the Policy Control Function (PCF) to retrieve and apply policy rules. Additionally, SMF 208 is involved in charging and accounting processes, tracking data usage for billing purposes.

[0061] Mobility Anchor Point: In scenarios where the UE moves between different access networks or base stations, SMF 208 maintains continuity of the data session by acting as aAtty. Docket No.: 4906P112510W001mobility anchor point. It coordinates with AMF 206 to handle mobility events and ensures that the session remains active and uninterrupted.

[0062] Interworking with Other Networks: SMF 208 also supports interworking with existing 4G Evolved Packet Core (EPC) networks to facilitate seamless transitions and interoperability between 4G and 5G (or 6G) networks.

[0063] SMF 208 plays a crucial role in managing user data services in the 5G network, working alongside other core network functions like AMF 206, UPF 220, and PCF to deliver efficient, flexible, and reliable connectivity for various applications and use cases.Unified Data Management (UDM)

[0064] UDM 204 handles the management and storage of subscriber data and policies. It is responsible for authenticating users, managing subscription profiles, and supporting session and mobility procedures. UDM 204 interacts with various NFs to provide essential data for service delivery and policy enforcement, enabling seamless user experience and network optimization. The functions of UDM 204 include:

[0065] Subscription Management: Storing and managing subscriber information, including user profiles, service subscriptions, and access permissions.

[0066] Authentication Credential Management: Handling authentication credentials and working with the Authentication Server Function (AUSF) to perform subscriber authentication.

[0067] Policy and Service Authorization: Supporting policy control by providing subscriber data and service authorization details to the Policy Control Function (PCF) and other relevant NFs.

[0068] UE Context Management: Maintaining context information for User Equipment (UE), assisting with registration, mobility, and session management.

[0069] Service Access Authorization: Managing access control decisions to ensure users can connect to authorized network services based on their subscription data.

[0070] UDM 204 operates through service-based interfaces, facilitating communication with other NFs like AMF 206, AUSF, PCF, and Short Message Service Function (SMSF). This modular and flexible design enables efficient data access and dynamic policy adaptation, supporting diverse use cases and network slices.User Plane Function (UPF)

[0071] UPF 220 handles data traffic forwarding and routing between the user equipment (UE) and external data networks. It acts as the anchor point for user data sessions, managing packet routing, quality of service (QoS) enforcement, and traffic handling to ensure efficient and flexible data delivery. The functions of UPF 220 include:Atty. Docket No.: 4906P112510W001

[0072] Data Packet Forwarding and Routing: Managing the transmission of user data packets between the radio access network (RAN) and external networks, ensuring low-latency and high-performance data delivery.

[0073] Anchor Point for Mobility: Serving as the mobility anchor for inter-base stations (e.g., eNB or gNB) handovers and roaming scenarios, facilitating seamless transitions between network cells or slices.

[0074] Traffic Steering and QoS Enforcement: Enforcing traffic handling policies, including packet filtering, shaping, and prioritization, based on QoS requirements defined by the Session Management Function (SMF).

[0075] Network Address Translation (NAT) and Tunneling: Handling IP address allocation, translating private and public addresses, and managing GTP-U tunneling for secure and efficient data transport.

[0076] Usage Data Collection and Reporting: Collecting traffic usage data for charging, billing, and analytics, and reporting it to the Charging Function (CHF) or other relevant NFs.

[0077] UPF 220 interfaces with SMF 208, which controls session management and policy application, and connects to external Data Networks (DNs) to deliver user services. Its distributed and scalable architecture supports dynamic traffic distribution, enabling ultra-reliable low-latency communication (URLLC) and massive loT use cases.

[0078] By decoupling the control and user planes, UPF 220 enhances network flexibility, enabling operators to deploy and optimize data paths closer to users, improving performance and supporting the diverse requirements of applications.

[0079] These existing functions in a mobile network interact with BAAF 125 to provide battery status information. The interactions are discussed through Figures 3 to 6.

[0080] Figure 3 illustrates operations to register a service in a mobile network to obtain aggregated battery status per some embodiments. BAAF 125 defines PGZs as a set of coverage areas in a mobile network. Each PGZ may be defined with a name, an identifier (e.g., a non -zero integer / character string), or a geographical code.

[0081] An application to use the aggregated battery status information collected from battery-powered vehicles may initiate a request to register for service at reference 312, e.g., requesting for notifications from BAAF 125. The request may be initiated through network API 302 to NEF 202. Network API 302 may be an interface for an external service (e.g., external service 650), e.g., an application to generate a power demand map (for present demand or future forecast). Network API 302 may be implemented in a variety of protocols, and the API may be a Representational State Transfer (REST) interface, a Simple Object Access Protocol (SOAP) interface, a Message Queuing Telemetry Transport (MQTT) interface, an Advanced MessageAtty. Docket No.: 4906P112510W001Queuing Protocol (AMQP) interface, or other API to provide notifications. Acting as an API gateway, NEF 202 translates the application request into network function calls to BAAF 125 and initiates a subscription registration 314 on behalf of the application.

[0082] Based on the registration, BAAF 125 may expose the available PGZs (the ones defined as the set of coverage areas in the mobile network) to network API 302 based on the service subscription level of the application at reference 316. Network API 302 may subscribe for GPZ monitoring to gain the aggregated battery status information per PGZ at one or more specific PGZs of the available PGZs at reference 318.

[0083] BAAF 125, upon authentication, may acknowledge the registration subsequently at reference 320 and send the acknowledgement to NEF 202, which confirms the registration token for querying and receiving BAAF notification at reference 322. The application then is ready to receive the aggregated battery status information per PGZ. Note that network API 302 is a north bound interface discussed relating to Figure 1, and BAAF 125 obtains the battery status information from EVs through a south bound interface, as discussed herein relating to Figures 4 to 5.

[0084] Figure 4 illustrates operations to register an electric vehicle (EV) in a mobile network for location tracking per some embodiments. EV 402 is equipped with EV identity circuitry providing a valid EV identifier (EV ID) registered in the mobile network to identify EV 402 or driver / owner of EV 402.

[0085] When EV 402 is switched on, it connects with the mobile network and identifies itself using the registered identifier, so that the mobile network learns the presence of EV 402 at a specific PGZ. For battery data collection, a request from EV 402 is forwarded at reference 412 to UDM 204, which determines whether there is a valid EV_token (EVT) for EV 402 based on the subscriber data and policies stored in UDM 204. If no valid EVT is found, a request is sent at reference 414 from UDM 204 to BAAF 125, which generates a unique EVT based on the valid EV ID, stores the mapping of EV ID to EVT in a database accessible to BAAF 125, and provides EVT to EV 402 at reference 416.

[0086] An EV token (EVT) is an identifier that uniquely identifies EV 402 in the mobile network and is generated based on an EV ID. The EVT may be a string of characters (e.g., a token) or number (e.g., a nonce which is a number used only once that is randomly generated), and the identifier may be encrypted prior to sending from one entity to another and decrypted at the receiving entity. In some embodiments, the unique EVT is assigned to temporarily EV 402 to preserve the geo-position privacy of the EV driver. For example, EVT may expire after a time period (e.g., after an hour / day), or upon the occurrence of an event regarding EV 402, e.g., EVAtty. Docket No.: 4906P112510W001402 is switched off or staying in one location for a long period of time (e.g., one hour without moving).

[0087] At reference 418, EV 402 registers the received EVT with AMF 206, which tracks location changes of EV 402. AMF 206 may request EV 402 to send periodic location updates, and upon data arriving at AMF 206 from EV 402, AMF 206 may check the UE’s last known location (PGZ) based on the data, and record that location (optionally with a time stamp).

[0088] At reference 424, AMF 206 notifies BAAF 125 upon a location change in some embodiments, e.g., from one PGZ to another. The notification includes the generated EVT to uniquely identify EV 402 as the party of the location change. When PGZs overlay cell coverage areas, the notification may be sent upon a location change from one cell coverage to another within the same PGZ. Since the notifications to BAAF 125 often correspond to EV 402 location changes, SMF 208 may be involved to coordinate with AMF 206 to maintain continuity of the data session by acting as a mobility anchor point for handovers. In some embodiments, AMF 206 sends queries to Location Management Function (LMF) and / or Gateway Mobile Location Center (GMLC) to determine the location of EV 402 (e.g., using radio measurements from the mobile network). When EV 402 moves, AMF 206 gets updates from the LMF, or the GMLC when EV 402 roams from one network to another. AMF 206 then provides the EV location change to BAAF 125.

[0089] By tracking location changes event / data, the number of EVs in a given PGZ at a given time may be tracked in real-time or near real-time, and that location information by itself provides important data point to determine the per PGZ based power demand. The location information may also be provided along with the battery status information, the collection of which is discussed herein relating to Figure 5.

[0090] Figure 5 illustrates operations to collect battery status information from an electric vehicle (EV) in a mobile network per some embodiments. The EVT and its association with EV ID of EV 402 is stored and accessible to BAAF 125 (the EVT may be stored in a database of BAAF 125 or UDM 204). The EVT may have been registered in AMF 206 for location change notification, and it may be registered in AMF 206 for battery status update notification as well.

[0091] The battery status change message, without corresponding EVT identification as shown at reference 510, will be ignored by BAAF 125. BAAF 125 may request one or more battery status queries from the registered EVT (e.g., via UPF 220) as shown at reference 512.Responsive to a battery status query, EV 402 provides a corresponding battery status response to BAAF 125 (e.g., via UPF 220) with the corresponding EVT at reference 522. In some scenarios, EV 402 may provide a battery status response without receiving a battery status query first.Atty. Docket No.: 4906P112510W001

[0092] At reference 516, BAAF 125 may also send out an EVT location query 516 to AMF 206, which may interact with SMF 208 to provide an EVT location response at reference 518. The battery status query 512 and EVT location query 516 may be sent out simultaneously from BAAF 125 or sequentially, and the EVT location response 518 and the battery status response 522 may be combined as the same update to BAAF 125 in some embodiments.

[0093] Figure 6 illustrates network functions and information exchanged for battery status information aggregation in a mobile network per some embodiments. As EV 402 is roaming in the PGZs of a mobile network, the location and battery status information are provided to BAAF 125 along with the corresponding EVT, using the existing network functions, including NEF 202, AMF 206, SMF 208, UDM 204, and UPF 220, as discussed herein. An external service 650, through NEF 202, provides an application based on the battery status information per PGZ.

[0094] As shown at reference 622, EV 402 provides an EV status notification with information including the EVT (as a string in the example), the EV type (e.g., its brand / model / serial number), the EV status (e.g., running speed), the battery capacity (e.g., how much electricity can be stored), the average consumption, the EV autonomy forecast (which predicts the distance the EV may still go without recharging ), and, optionally, coordinates. The coordinates of the EV may be ones from Global Positioning System (GPS), Galileo, BeiDou, Global Navigation Satellite System (GLONASS), or any other global and regional satellite navigation system. Note that the coordinates are not needed in some embodiments, as EV 402 provides EVT zone notification, that indicates the service cell ID or GPZ ID so the rough location is known and may be sufficient for some application (e.g., the application to generate power demand maps per PGZ).

[0095] BAAF 125 receives EV status notifications from EV 402 and other EVs in the PGZs, and it stores the corresponding battery status responses in BAAF data collection module 632. An example of the battery status response is shown at reference 624. The response for an EVT includes the EVT, the battery status (e.g., the status of recharging, discharging, degraded, or exhausted, or another hierarchy of status indications) of the corresponding EV, the battery level (e.g., percentage of battery remaining or another battery level indication), and the battery recharge and discharge statistics (e.g., how quickly the batteries of the EV are discharged and how often they are charged).

[0096] In some embodiments, when EV 402 roams from a first GPZ (GPZ / 2) to a second GPZ (GPZ / 1), EV status notification is triggered, and the generation of EV status notification may leverage the existing handover process between cells of a mobile network as each GPZ is aligned to one or more cell coverage areas of the mobile network, use the information in the existing handover process for the battery status information update, including the context of EVAtty. Docket No.: 4906P112510W001402 that is released from the first GPZ to the second GPZ. The EV 402 location may be updated through AMF 206 based on information from the LMF / GMLC as discussed herein.

[0097] The data collected from all the EVs may optionally be anonymized through a data anonymization function, which as shown at reference 634, removes personal data that is any information relating to an identified or identifiable EV or EV’s driver / owner. The anonymization includes: (1) removing explicit IDs such as EVT, EV ID, and etc., (2) generalizing to abstract away personal data, (3) pseudonymizing to replace personal data with artificial identifiers or pseudonyms, (4) masking to hide or alter the data, (5) non-PGZ aggregating (e.g., aggregate per EV type prior to aggregating data on a per PGZ basis). Any data anonymization techniques may be applied to battery status responses to remove personal data to comply with privacy rules and regulations at a given jurisdiction, as long as the remaining data may still be useful for the external service 650. As noted above, data anonymization is optional and may be skipped in some embodiments.

[0098] The data is aggregated through a data aggregation function 636. The data aggregation is performed on a per-PGZ basis. The different types of data in the per-PGZ aggregation include the battery data aggregation, autonomy aggregation per PGZ (e.g., the aggregated distances per PGZ that the EVs may still go without recharging) , autonomy aggregation per EV and per EV behavior (based on the zone notifications from EV location changes).

[0099] The data may be aggregated using an Al and / or machine learning (AI / ML) predictive model 639 based on battery recharging behaviors in some embodiments. AI / ML predictive model 639 may be implemented to account for variable drive behaviors (e.g., charging when the battery level being low or medium) and temporary / traffic conditions. The aggregation of data with the consideration of these factors relating to electricity consumption allows the data aggregation and categorization with better granularity for per PGZ based electricity management.

[0100] While AI / ML predictive model 639 is shown to be within BAAF 125, it may be implemented outside of BAAF 125 as well. For example, the aggregated data from data aggregation function 636 may be exported through an API for external AI / ML data processing by AI / ML predictive model 639 provided by another party (e.g., by a cloud service provider that offers more computing resources). The external AI / ML data processing can be more efficient (e.g., a cloud service provider that offers more computing resources) and still protect consumer privacy since the data has already been anonymized prior to the export.

[0101] Additionally, external service 650, once obtaining the aggregated battery data information, may apply another AI / ML predictive model 652 to manage the electricity per PGZ. AI / ML predictive model 652 may be implemented within or coupled to external service 650.Atty. Docket No.: 4906P112510W001The input of aggregated battery data (e.g., battery data aggregation and EV autonomy aggregation) is provided to AI / ML predictive model 652 to output the power demand per PGZ. These AI / ML predictive models 639 and 652 may use supervised learning, unsupervised learning, semi-supervised learning, or other types of learning. They can use reinforcement learning (RL), artificial neural networks (e.g., Generative Adversarial Networks (GANs), transformers, large language models (LLMs), and variational autoencoders), decision trees, support-vector machines, regression analysis, Bayesian networks, genetic algorithms, diffusion models, or any other framework. They may be trained using a sequence of pairs of historical data and corresponding historical data processing results.

[0102] For example, for AI / ML predictive model 639, pairs of the historical data provided to data aggregation function 636 and the corresponding desired historical aggregated data categorization considering variable drive behaviors and temporary / traffic conditions as previously achieved (through AI / ML or other means) are fed to the AI / ML model 639 to train and adjust the parameters of AI / ML model 639. The data used to train the AI / ML predictive model 639 may be any pairs of the historical data battery and location collected (e.g., ones in battery status response 624 or in EV status notification 622) and their corresponding historical aggregated data.

[0103] For AI / ML predictive model 652, pairs of the aggregated data provided to external service 650 and the corresponding historical power demand per PGZ as known are fed to the AI / ML model 652 to train and adjust the parameters of AI / ML model 652. The data used to train the AI / ML predictive model 652 may be any pairs of the historical data battery and location collected (e.g., ones in battery status response 624 or in EV status notification 622) and their corresponding historical power demand.

[0104] The power demand as determined may be the real-time power demand per PGZ, or future power demand per PGZ as forecast over time (e.g., days, weeks, months, or even years). The determined power demand may then be used to distribute sufficient electricity to recharging stations of the PGZ that has high power demand, and / or to install more recharging stations to that PGZ.

[0105] While AI / ML predictive models 639 and 652 are shown as two separate models (the former within BAAF 125 and the latter outside), they may be integrated into the same predictive model (a centralized instead of distributed AI / ML predictive model to aggregate and determine power demand separately). In the centralized model, BAAF 125 may determine and / or forecast the power demand per PGZ. The resulting power demand is then provided to external service 650 to provide related services.Atty. Docket No.: 4906P112510W001

[0106] Through the disclosed embodiments, the battery status information including corresponding location information (e.g., based on the EV status notifications) may be collected and disseminated using the existing mobile network architecture to manage the power demand at each PGZ of a mobile network. These embodiments comply with the laws and regulations on consumer privacy as it does not rely on information that the consumer already agrees to provide to the mobile network to operate the battery-powered vehicle. By leveraging data provided through known network functions and interfaces and adding a network function to interact with the known network functions, these embodiments manage the power demand each PGZ with minimum impact to the existing operations.

[0107] In some embodiments, the exact positions of the battery-powered vehicles are not necessary to manage the power demand. Note that EVT zone notification 612 does not contain the GPS coordinates of EV 602 and the locations at the granularity of PGZ or cell may be sufficient.

[0108] In these embodiments, battery status information may be collected anonymously to determine the current and expected power demand from a multitude of the battery-powered vehicles in mobility throughout a region or country. The power demand is then used to forecast short- and long-term dynamic changes in electrical power supply and cope with rush hours, traffic congestion, and unexpected peaks of demand. Based on the forecasts, the power providers can optimize their power distribution network and provide the recharging stations with the capacity necessary to be used by the battery-powered vehicles nearby conveniently.Additionally, the forecast also helps predict the overall traffic demand from residential users using their private subscription to recharge their battery-powered vehicles and avoids the risk of black-out due to massive usage of battery-powered vehicles recharging at the limits of their contractual commitment.Operations per some embodiments

[0109] Figure 7 is a flow diagram illustrating operations for power demand management based on aggregated battery status information on a geographic-zone-basis per some embodiments. The operations of method 700 may be implemented in a network device (see Figures 8A to 8F) to operate in a mobile network.

[0110] At reference 702, battery status information of battery-powered vehicles in a plurality of geographic zones of a mobile network is obtained, where battery status information from one battery-powered vehicle indicates a geographic zone in which the battery power vehicle is located when the battery information is obtained. At reference 704, the battery status information is aggregated from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network. At reference 706, the battery status informationAtty. Docket No.: 4906P112510W001aggregated on the per geographic zone basis is provided to manage power demand in the plurality of geographic zones.[oni] In some embodiments, the network function (e.g., BAAF 125) itself manages the power demand. Alternatively, a service that subscribes to the network function (e.g., external service 650 through network API 302) obtains the battery status information aggregated on the per geographic zone basis, and manages the power demand.

[0112] In some embodiments, managing the power demand comprises generating a map to forecast the power demand in the plurality of geographies zones.

[0113] In some embodiments, forecasting the power demand is performed based on a machine learning model that is trained using at least pairs of historical battery status information and corresponding historical power demand. Other data may be included in the training as well. For example, driver behaviors may be used to train the machine learning model as discussed herein.

[0114] In some embodiments, a geographic zone comprises one or more cell coverage areas of the mobile network.

[0115] In some embodiments, the battery status information from the one battery-powered vehicle indicates one or more of battery status, a battery level, battery recharge and discharge statistics. Examples of the battery status information are discussed relating to reference 624.

[0116] In some embodiments, an application to manage the power demand registers with the network function through a network exposure function (NEF) using an application programming interface (API) to obtain the aggregated battery status information without personal data from the battery-powered vehicles on the per geographic zone basis.

[0117] In some embodiments, the one battery-powered vehicle registers with the mobile network comprises the one battery-powered vehicle registering an identifier provided by the network function though an access and mobility management function (AMF), where the identifier is used to set up and renew a session through a session management function (SMF) for the one battery-powered vehicle to notify location change on the per geographic zone basis.

[0118] In some embodiments, the identifier provided by the network function uniquely identifies the one battery-powered vehicle in the mobile network and expires after a time period or upon occurrence of an event regarding the one battery-powered vehicle.

[0119] In some embodiments, the identifier is the EV ID discussed herein.

[0120] In some embodiments, the location change is obtained from AMF, which receives a location update from a location management function (LMF) or Gateway Mobile Location Center (GMLC).

[0121] In some embodiments, obtaining the battery status information from the one battery-powered vehicle comprises the network function requesting location information of the oneAtty. Docket No.: 4906P112510W001battery-powered vehicle, wherein the location information indicates the geographic zone in which the battery-powered vehicle is located or coordinates of the battery-powered vehicle when the battery status information is obtained.

[0122] In some embodiments, the geographic zone is mapped to a cell coverage area of the mobile network, and wherein upon the one battery-powered vehicle moving from the geographic zone to another geographic zone, the battery status information of the one battery-powered vehicle is obtained using network functions of the mobile network that are involved in handover operations.

[0123] In some embodiments, the battery status information from the battery-powered vehicles on the per geographic zone basis is aggregated with personal data corresponding to the respective battery-powered vehicles being removed.

[0124] In some embodiments, a service registers with a network exposure function (NEF) to subscribe to the network function to obtain the battery status information aggregated on per geographic zone basis. For example, the service may be external service 650 that registers through network API 302.

[0125] Through these embodiments, battery status information may be aggregated to manage dynamic changes in electrical power supply and forecast short-term or long-term power demand in different geographical regions. Based on the battery status information, the power suppliers may optimize their power distribution network and provide sufficient charging capacity to recharging stations. The battery status information may help predict the overall demand from residential users using their electricity subscription to recharge their battery-powered vehicles and avoid the risk of black-out due to massive usage of electricity by these battery-powered vehicles.Devices and Environments for Implementing Embodiments of the Invention

[0126] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and / or subscriber management), and / or provide support for multiple application services (e.g., data, voice, and video).

[0127] Figure 8A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention. Figure 8A shows NDs 800A-H, and their connectivity by way of lines between 800A-800B, 800B-800C, 800C-800D, 800D-800E, 800E-800F, 800F-800G, and 800A-800G, as well as between 800H and each of 800A, 800C, 800D, and 800G. These NDs areAtty. Docket No.: 4906P112510W001physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). An additional line extending from NDs 800A, 800E, and 800F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).

[0128] Two of the exemplary ND implementations in Figure 8A are: 1) a special-purpose network device 802 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general-purpose network device 804 that uses common off-the-shelf (COTS) processors and a standard OS.

[0129] The special -purpose network device 802 includes networking hardware 810 comprising a set of one or more processor(s) 812, forwarding resource(s) 814 (which typically include one or more ASICs and / or network processors), and physical network interfaces (NIs) 816 (through which network connections are made, such as those shown by the connectivity between NDs 800A-H), as well as non-transitory machine readable storage media 818 having stored therein networking software 820. During operation, the networking software 820 may be executed by the networking hardware 810 to instantiate a set of one or more networking software instance(s) 822. Each of the networking software instance(s) 822, and that part of the networking hardware 810 that executes that network software instance (be it hardware dedicated to that networking software instance and / or time slices of hardware temporally shared by that networking software instance with others of the networking software instance(s) 822), form a separate virtual network element 830A-R. Each of the virtual network element(s) (VNEs) 830A-R includes a control communication and configuration module 832A-R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 834A-R, such that a given virtual network element (e.g., 830A) includes the control communication and configuration module (e.g., 832A), a set of one or more forwarding table(s) (e.g., 834A), and that portion of the networking hardware 810 that executes the virtual network element (e.g., 830A). In some embodiments, networking software 820 includes an EV battery information aggregator 825 that implements operations discussed herein relating to Figures 1 to 7. For example, EV battery information aggregator 825 may implement BAAF 125 and collect data from EVs coupled to network device 802.

[0130] The special-purpose network device 802 is often physically and / or logically considered to include: 1) a ND control plane 824 (sometimes referred to as a control plane) comprising the processor(s) 812 that execute the control communication and configuration module(s) 832A-R; and 2) a ND forwarding plane 826 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 814 that utilize the forwarding table(s) 834A-R and the physical NIs 816. By way of example, where the ND is a router (or isAtty. Docket No.: 4906P112510W001implementing routing functionality), the ND control plane 824 (the processor(s) 812 executing the control communication and configuration module(s) 832A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 834A-R, and the ND forwarding plane 826 is responsible for receiving that data on the physical NIs 816 and forwarding that data out the appropriate ones of the physical NIs 816 based on the forwarding table(s) 834A-R.

[0131] Figure 8B illustrates an exemplary way to implement the special-purpose network device 802 according to some embodiments of the invention. Figure 8B shows a special-purpose network device including cards 838 (typically hot pluggable). While in some embodiments the cards 838 are of two types (one or more that operate as the ND forwarding plane 826 (sometimes called line cards), and one or more that operate to implement the ND control plane 824 (sometimes called control cards)), alternative embodiments may combine functionality onto a single card and / or include additional card types (e.g., one additional type of card is called a service card, resource card, or multi-application card). A service card can provide specialized processing (e.g., Layer 4 to Layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)). By way of example, a service card may be used to terminate IPsec tunnels and execute the attendant authentication and encryption algorithms. These cards are coupled together through one or more interconnect mechanisms illustrated as backplane 836 (e.g., a first full mesh coupling the line cards and a second full mesh coupling all of the cards).

[0132] Returning to Figure 8A, the general-purpose network device 804 includes hardware 840 comprising a set of one or more processor(s) 842 (which are often COTS processors) and physical NIs 846, as well as non-transitory machine-readable storage media 848 having stored therein software 850. During operation, the processor(s) 842 execute the software 850 to instantiate one or more sets of one or more applications 864A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment the virtualization layer 854 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 862A-R called software containers that may each be used to execute one (or more) of the sets of applications 864A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernelAtty. Docket No.: 4906P112510W001space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memoty of the other processes. In another such alternative embodiment the virtualization layer 854 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 864A-R is run on top of a guest operating system within an instance 862A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor -the guest operating system and application may not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, or through para-virtualization the operating system and / or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some or all of the applications are implemented as unikemel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including drivers / ! ibraries of OS services) that provide the particular OS services needed by the application. As a unikernel can be implemented to run directly on hardware 840, directly on a hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikemels running directly on a hypervisor represented by virtualization layer 854, unikemels running within software containers represented by instances 862A-R, or as a combination of unikemels and the above-described techniques (e.g., unikemels and virtual machines both run directly on a hypervisor, unikemels and sets of applications that are run in different software containers). In some embodiments, EV battery information aggregator 855 is implemented in networking software 850. For example, EV battery information aggregator 855 may implement BAAF 125 and collect data from EVs coupled to network device 804.

[0133] The instantiation of the one or more sets of one or more applications 864A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 852. Each set of applications 864 A-R, corresponding virtualization construct (e.g., instance 862 A-R) if implemented, and that part of the hardware 840 that executes them (be it hardware dedicated to that execution and / or time slices of hardware temporally shared), forms a separate virtual network element(s) 860A-R.

[0134] The virtual network element(s) 860A-R perform similar functionality to the virtual network element(s) 830 A-R - e.g., similar to the control communication and configuration module(s) 832A and forwarding table(s) 834A (this virtualization of the hardware 840 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware,Atty. Docket No.: 4906P112510W001physical switches, and physical storage, which could be located in Data centers, NDs, and customer premise equipment (CPE). While embodiments of the invention are illustrated with each instance 862A-R corresponding to one VNE 860A-R, alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 862A-R to VNEs also apply to embodiments where such a finer level of granularity and / or unikemels are used.

[0135] In certain embodiments, the virtualization layer 854 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 862A-R and the physical NI(s) 846, as well as optionally between the instances 862A-R; in addition, this virtual switch may enforce network isolation between the VNEs 860A-R that by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).

[0136] The third exemplary ND implementation in Figure 8A is a hybrid network device 806, which includes both custom ASICs / special-purpose OS and COTS processors / standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform VM (i.e., a VM that that implements the functionality of the special-purpose network device 802) could provide for para-virtualization to the networking hardware present in the hybrid network device 806.

[0137] Regardless of the above exemplary implementations of an ND, when a single one of multiple VNEs implemented by an ND is being considered (e.g., only one of the VNEs is part of a given virtual network) or where only a single VNE is currently being implemented by an ND, the shortened term network element (NE) is sometimes used to refer to that VNE. Also in all of the above exemplary implementations, each of the VNEs (e.g., VNE(s) 830A-R, VNEs 860 A-R, and those in the hybrid network device 806) receives data on the physical NIs (e.g., 816, 846) and forwards that data out the appropriate ones of the physical NIs (e.g., 816, 846). For example, a VNE implementing IP router functionality forwards IP packets on the basis of some of the IP header information in the IP packet; where IP header information includes source IP address, destination IP address, source port, destination port (where “source port” and “destination port” refer herein to protocol ports, as opposed to physical ports of a ND), transport protocol (e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services code point (DSCP) values.

[0138] Figure 8C illustrates various exemplary ways in which VNEs may be coupled according to some embodiments of the invention. Figure 8C shows VNEs 870A.1-870A.P (andAtty. Docket No.: 4906P112510W001optionally VNEs 870A.Q-870A.R) implemented in ND 800A and VNE 870H.1 in ND 800H. In Figure 8C, VNEs 870A.1-P are separate from each other in the sense that they can receive packets from outside ND 800A and forward packets outside of ND 800A; VNE 870A.1 is coupled with VNE 870H.1, and thus they communicate packets between their respective NDs; VNE 870A.2-870A.3 may optionally forward packets between themselves without forwarding them outside of the ND 800A; and VNE 870A.P may optionally be the first in a chain of VNEs that includes VNE 870A.Q followed by VNE 870A.R (this is sometimes referred to as dynamic service chaining, where each of the VNEs in the series of VNEs provides a different service -e.g., one or more layer 4-7 network services). While Figure 8C illustrates various exemplary relationships between the VNEs, alternative embodiments may support other relationships (e.g., more / fewer VNEs, more / fewer dynamic service chains, multiple different dynamic service chains with some common VNEs and some different VNEs).

[0139] The NDs of Figure 8 A, for example, may form part of the Internet or a private network; and other electronic devices (not shown; such as end user devices including workstations, laptops, netbooks, tablets, palm tops, mobile phones, smartphones, phablets, multimedia phones, Voice Over Internet Protocol (VOIP) phones, terminals, portable media players, GPS units, wearable devices, gaming systems, set-top boxes, Internet enabled household appliances) may be coupled to the network (directly or through other networks such as access networks) to communicate over the network (e.g., the Internet or virtual private networks (VPNs) overlaid on (e.g., tunneled through) the Internet) with each other (directly or through servers) and / or access content and / or services. Such content and / or services are typically provided by one or more servers (not shown) belonging to a service / content provider or one or more end user devices (not shown) participating in a peer-to-peer (P2P) service, and may include, for example, public webpages (e.g., free content, store fronts, search services), private webpages (e.g., username / password accessed webpages providing email services), and / or corporate networks over VPNs. For instance, end user devices may be coupled (e.g., through customer premise equipment coupled to an access network (wired or wirelessly)) to edge NDs, which are coupled (e.g., through one or more core NDs) to other edge NDs, which are coupled to electronic devices acting as servers. However, through compute and storage virtualization, one or more of the electronic devices operating as the NDs in Figure 8A may also host one or more such servers (e.g., in the case of the general purpose network device 804, one or more of the software instances 862A-R may operate as servers; the same would be true for the hybrid network device 806; in the case of the special-purpose network device 802, one or more such servers could also be run on a virtualization layer executed by the processor(s) 812); in which case the servers are said to be co-located with the VNEs of that ND.Atty. Docket No.: 4906P112510W001

[0140] A virtual network is a logical abstraction of a physical network (such as that in Figure 8A) that provides network services (e.g., L2 and / or L3 services). A virtual network can be implemented as an overlay network (sometimes referred to as a network virtualization overlay) that provides network services (e.g., layer 2 (L2, data link layer) and / or layer 3 (L3, network layer) services) over an underlay network (e.g., an L3 network, such as an Internet Protocol (IP) network that uses tunnels (e.g., generic routing encapsulation (GRE), layer 2 tunneling protocol (L2TP), IPSec) to create the overlay network).

[0141] A network virtualization edge (NVE) sits at the edge of the underlay network and participates in implementing the network virtualization; the network-facing side of the NVE uses the underlay network to tunnel frames to and from other NVEs; the outward-facing side of the NVE sends and receives data to and from systems outside the network. A virtual network instance (VNI) is a specific instance of a virtual network on a NVE (e.g., a NE / VNE on an ND, a part of a NE / VNE on a ND where that NE / VNE is divided into multiple VNEs through emulation); one or more VNIs can be instantiated on an NVE (e.g., as different VNEs on an ND). A virtual access point (VAP) is a logical connection point on the NVE for connecting external systems to a virtual network; a VAP can be physical or virtual ports identified through logical interface identifiers (e.g., a VLAN ID).

[0142] Examples of network services include: 1) an Ethernet LAN emulation service (an Ethernet-based multipoint service similar to an Internet Engineering Task Force (IETF) Multiprotocol Label Switching (MPLS) or Ethernet VPN (EVPN) service) in which external systems are interconnected across the network by a LAN environment over the underlay network (e.g., an NVE provides separate L2 VNIs (virtual switching instances) for different such virtual networks, and L3 (e.g., IP / MPLS) tunneling encapsulation across the underlay network); and 2) a virtualized IP forwarding service (similar to IETF IP VPN (e.g., Border Gateway Protocol (BGP) / MPLS IPVPN) from a service definition perspective) in which external systems are interconnected across the network by an L3 environment over the underlay network (e.g., an NVE provides separate L3 VNIs (forwarding and routing instances) for different such virtual networks, and L3 (e.g., IP / MPLS) tunneling encapsulation across the underlay network)). Network services may also include quality of service capabilities (e.g., traffic classification marking, traffic conditioning and scheduling), security capabilities (e.g., filters to protect customer premises from network - originated attacks, to avoid malformed route announcements), and management capabilities (e.g., full detection and processing).

[0143] Fig. 8D illustrates a network with a single network element on each of the NDs of Figure 8A, and within this straightforward approach contrasts a traditional distributed approach (commonly used by traditional routers) with a centralized approach for maintaining reachabilityAtty. Docket No.: 4906P112510W001and forwarding information (also called network control), according to some embodiments of the invention. Specifically, Figure 8D illustrates network elements (NEs) 870A-H with the same connectivity as the NDs 800A-H of Figure 8 A.

[0144] Figure 8D illustrates that the distributed approach 872 distributes responsibility for generating the reachability and forwarding information across the NEs 870A-H; in other words, the process of neighbor discovery and topology discovery is distributed.

[0145] For example, where the special-purpose network device 802 is used, the control communication and configuration module(s) 832A-R of the ND control plane 824 typically include a reachability and forwarding information module to implement one or more routing protocols (e.g., an exterior gateway protocol such as Border Gateway Protocol (BGP), Interior Gateway Protocol(s) (IGP) (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Routing Information Protocol (RIP), Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) (including RSVP-Traffic Engineering (TE): Extensions to RSVP for LSP Tunnels and Generalized Multi -Protocol Label Switching (GMPLS) Signaling RSVP-TE)) that communicate with other NEs to exchange routes, and then selects those routes based on one or more routing metrics. Thus, the NEs 870A-H (e.g., the processor(s) 812 executing the control communication and configuration module(s) 832A-R) perform their responsibility for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) by distributively determining the reachability within the network and calculating their respective forwarding information. Routes and adjacencies are stored in one or more routing structures (e.g., Routing Information Base (RIB), Label Information Base (LIB), one or more adjacency structures) on the ND control plane 824. The ND control plane 824 programs the ND forwarding plane 826 with information (e.g., adjacency and route information) based on the routing structure(s). For example, the ND control plane 824 programs the adjacency and route information into one or more forwarding table(s) 834A-R (e.g., Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), and one or more adjacency structures) on the ND forwarding plane 826. For layer 2 forwarding, the ND can store one or more bridging tables that are used to forward data based on the layer 2 information in that data. While the above example uses the special-purpose network device 802, the same distributed approach 872 can be implemented on the general purpose network device 804 and the hybrid network device 806.

[0146] Figure 8D illustrates that a centralized approach 874 (also known as software defined networking (SDN)) that decouples the system that makes decisions about where traffic is sent from the underlying systems that forwards traffic to the selected destination. The illustrated centralized approach 874 has the responsibility for the generation of reachability and forwardingAtty. Docket No.: 4906P112510W001information in a centralized control plane 876 (sometimes referred to as a SDN control module, controller, network controller, OpenFlow controller, SDN controller, control plane node, network virtualization authority, or management control entity), and thus the process of neighbor discovery and topology discovery is centralized. The centralized control plane 876 has a south bound interface 882 with a data plane 880 (sometime referred to the infrastructure layer, network forwarding plane, or forwarding plane (which should not be confused with a ND forwarding plane)) that includes the NEs 870A-H (sometimes referred to as switches, forwarding elements, data plane elements, or nodes). The centralized control plane 876 includes a network controller 878, which includes a centralized reachability and forwarding information module 879 that determines the reachability within the network and distributes the forwarding information to the NEs 870A-H of the data plane 880 over the south bound interface 882 (which may use the OpenFlow protocol). Thus, the network intelligence is centralized in the centralized control plane 876 executing on electronic devices that are typically separate from the NDs.

[0147] For example, where the special-purpose network device 802 is used in the data plane 880, each of the control communication and configuration module(s) 832A-R of the ND control plane 824 typically include a control agent that provides the VNE side of the south bound interface 882. In this case, the ND control plane 824 (the processor(s) 812 executing the control communication and configuration module(s) 832A-R) performs its responsibility for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) through the control agent communicating with the centralized control plane 876 to receive the forwarding information (and in some cases, the reachability information) from the centralized reachability and forwarding information module 879 (it should be understood that in some embodiments of the invention, the control communication and configuration module(s) 832A-R, in addition to communicating with the centralized control plane 876, may also play some role in determining reachability and / or calculating forwarding information - albeit less so than in the case of a distributed approach; such embodiments are generally considered to fall under the centralized approach 874, but may also be considered a hybrid approach).

[0148] While the above example uses the special-purpose network device 802, the same centralized approach 874 can be implemented with the general purpose network device 804 (e.g., each of the VNE 860A-R performs its responsibility for controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) by communicating with the centralized control plane 876 to receive the forwarding information (and in some cases, the reachability information) from the centralized reachability and forwarding information module 879; it should be understood that in some embodiments ofAtty. Docket No.: 4906P112510W001the invention, the VNEs 860A-R, in addition to communicating with the centralized control plane 876, may also play some role in determining reachability and / or calculating forwarding information - albeit less so than in the case of a distributed approach) and the hybrid network device 806. In fact, the use of SDN techniques can enhance the NFV techniques typically used in the general purpose network device 804 or hybrid network device 806 implementations as NFV is able to support SDN by providing an infrastructure upon which the SDN software can be run, and NFV and SDN both aim to make use of commodity server hardware and physical switches.

[0149] Figure 8D also shows that the centralized control plane 876 has a north bound interface 884 to an application layer 886, in which resides application(s) 888. The centralized control plane 876 has the ability to form virtual networks 892 (sometimes referred to as a logical forwarding plane, network services, or overlay networks (with the NEs 870A-H of the data plane 880 being the underlay network)) for the application(s) 888. Thus, the centralized control plane 876 maintains a global view of all NDs and configured NEs / VNEs, and it maps the virtual networks to the underlying NDs efficiently (including maintaining these mappings as the physical network changes either through hardware (ND, link, or ND component) failure, addition, or removal). In some embodiments, EV battery information aggregation 825 is implemented within application(s) 888.

[0150] While Figure 8D shows the distributed approach 872 separate from the centralized approach 874, the effort of network control may be distributed differently or the two combined in certain embodiments of the invention. For example: 1) embodiments may generally use the centralized approach (SDN) 874, but have certain functions delegated to the NEs (e.g., the distributed approach may be used to implement one or more of fault monitoring, performance monitoring, protection switching, and primitives for neighbor and / or topology discovery); or 2) embodiments of the invention may perform neighbor discovery and topology discovery via both the centralized control plane and the distributed protocols, and the results compared to raise exceptions where they do not agree. Such embodiments are generally considered to fall under the centralized approach 874, but may also be considered a hybrid approach.

[0151] While Figure 8D illustrates the simple case where each of the NDs 800A-H implements a single NE 870A-H, it should be understood that the network control approaches described with reference to Figure 8D also work for networks where one or more of the NDs 800A-H implement multiple VNEs (e.g., VNEs 830A-R, VNEs 860A-R, those in the hybrid network device 806). Alternatively or in addition, the network controller 878 may also emulate the implementation of multiple VNEs in a single ND. Specifically, instead of (or in addition to) implementing multiple VNEs in a single ND, the network controller 878 may present theAtty. Docket No.: 4906P112510W001implementation of a VNE / NE in a single ND as multiple VNEs in the virtual networks 892 (all in the same one of the virtual network(s) 892, each in different ones of the virtual network(s) 892, or some combination). For example, the network controller 878 may cause an ND to implement a single VNE (a NE) in the underlay network, and then logically divide up the resources of that NE within the centralized control plane 876 to present different VNEs in the virtual network(s) 892 (where these different VNEs in the overlay networks are sharing the resources of the single VNE / NE implementation on the ND in the underlay network).

[0152] On the other hand, Figures 8E and 8F respectively illustrate exemplary abstractions of NEs and VNEs that the network controller 878 may present as part of different ones of the virtual networks 892. Figure 8E illustrates the simple case of where each of the NDs 800A-H implements a single NE 870A-H (see Figure 8D), but the centralized control plane 876 has abstracted multiple of the NEs in different NDs (the NEs 870A-C and G-H) into (to represent) a single NE 8701 in one of the virtual network(s) 892 of Figure 8D, according to some embodiments of the invention. Figure 8E shows that in this virtual network, the NE 8701 is coupled to NE 870D and 870F, which are both still coupled to NE 870E.

[0153] Figure 8F illustrates a case where multiple VNEs (VNE 870A.1 and VNE 870H.1) are implemented on different NDs (ND 800A and ND 800H) and are coupled to each other, and where the centralized control plane 876 has abstracted these multiple VNEs such that they appear as a single VNE 870T within one of the virtual networks 892 of Figure 8D, according to some embodiments of the invention. Thus, the abstraction of a NE or VNE can span multiple NDs.

[0154] While some embodiments of the invention implement the centralized control plane 876 as a single entity (e.g., a single instance of software running on a single electronic device), alternative embodiments may spread the functionality across multiple entities for redundancy and / or scalability purposes (e.g., multiple instances of software running on different electronic devices).

[0155] Similar to the network device implementations, the electronic device(s) running the centralized control plane 876, and thus the network controller 878 including the centralized reachability and forwarding information module 879, may be implemented in a variety of ways (e.g., a special purpose device, a general-purpose (e.g., COTS) device, or hybrid device). These electronic device(s) would similarly include processor(s), a set or one or more physical NIs, and a non-transitory machine-readable storage medium having stored thereon the centralized control plane software. While some embodiments of the invention implement the centralized control plane 676 as a single entity (e.g., a single instance of software running on a single electronic device), alternative embodiments may spread the functionality across multiple entities forAtty. Docket No.: 4906P112510W001redundancy and / or scalability purposes (e.g., multiple instances of software running on different electronic devices). For instance, Figure 9 illustrates, a control plane device 904 including hardware 940 comprising a set of one or more processor(s) 942 (which are often COTS processors) and physical NIs 946, as well as non-transitory machine-readable storage media 948 having stored therein centralized control plane (CCP) software 950. In some embodiments, EV battery information aggregation 825 is implemented within CCP software 950 to collect and process EV battery information discussed relating to Figures 1-7.

[0156] In embodiments that use compute virtualization, the processor(s) 942 typically execute software to instantiate a virtualization layer 954 (e.g., in one embodiment the virtualization layer 954 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 962A-R called software containers (representing separate user spaces and also called virtualization engines, virtual private servers, or jails) that may each be used to execute a set of one or more applications; in another embodiment the virtualization layer 954 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and an application is run on top of a guest operating system within an instance 962A-R called a virtual machine (which in some cases may be considered a tightly isolated form of software container) that is run by the hypervisor ; in another embodiment, an application is implemented as a unikernel, which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library' operating system (LibOS) including drivers / libraries of OS services) that provide the particular OS services needed by the application, and the unikernel can run directly on hardware 940, directly on a hypervisor represented by virtualization layer 954 (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container represented by one of instances 962A-R). Again, in embodiments where compute virtualization is used, during operation an instance of the CCP software 950 (illustrated as CCP instance 976A) is executed (e.g., within the instance 962A) on the virtualization layer 954. In embodiments where compute virtualization is not used, the CCP instance 976A is executed, as a unikernel or on top of a host operating system, on the “bare metal” general purpose control plane device 904. The instantiation of the CCP instance 976A, as well as the virtualization layer 954 and instances 962A-R if implemented, are collectively referred to as software instance(s) 952.

[0157] In some embodiments, the CCP instance 976A includes a network controller instance 978. The network controller instance 978 includes a centralized reachability and forwarding information module instance 979 (which is a middleware layer providing the context of the network controller 878 to the operating system and communicating with the various NEs), andAtty. Docket No.: 4906P112510W001an CCP application layer 980 (sometimes referred to as an application layer) over the middleware layer (providing the intelligence required for various network operations such as protocols, network situational awareness, and user - interfaces). At a more abstract level, this CCP application layer 980 within the centralized control plane 876 works with virtual network view(s) (logical view(s) of the network) and the middleware layer provides the conversion from the virtual networks to the physical view.

[0158] The centralized control plane 876 transmits relevant messages to the data plane 880 based on CCP application layer 980 calculations and middleware layer mapping for each flow. A flow may be defined as a set of packets whose headers match a given pattern of bits; in this sense, traditional IP forwarding is also flow-based forwarding where the flows are defined by the destination IP address for example; however, in other implementations, the given pattern of bits used for a flow definition may include more fields (e.g., 10 or more) in the packet headers. Different NDs / NEs / VNEs of the data plane 880 may receive different messages, and thus different forwarding information. The data plane 880 processes these messages and programs the appropriate flow information and corresponding actions in the forwarding tables (sometime referred to as flow tables) of the appropriate NE / VNEs, and then the NEs / VNEs map incoming packets to flows represented in the forwarding tables and forward packets based on the matches in the forwarding tables.

[0159] Standards such as OpenFlow define the protocols used for the messages, as well as a model for processing the packets. The model for processing packets includes header parsing, packet classification, and making forwarding decisions. Header parsing describes how to interpret a packet based upon a well-known set of protocols. Some protocol fields are used to build a match structure (or key) that will be used in packet classification (e.g., a first key field could be a source media access control (MAC) address, and a second key field could be a destination MAC address).

[0160] Packet classification involves executing a lookup in memory to classify the packet by determining which entry (also referred to as a forwarding table entry or flow entry) in the forwarding tables best matches the packet based upon the match structure, or key, of the forwarding table entries. It is possible that many flows represented in the forwarding table entries can correspond / match to a packet; in this case the system is typically configured to determine one forwarding table entry from the many according to a defined scheme (e.g., selecting a first forwarding table entry that is matched). Forwarding table entries include both a specific set of match criteria (a set of values or wildcards, or an indication of what portions of a packet should be compared to a particular value / values / wildcards, as defined by the matching capabilities - for specific fields in the packet header, or for some other packet content), and a setAtty. Docket No.: 4906P112510W001of one or more actions for the data plane to take on receiving a matching packet. For example, an action may be to push a header onto the packet, for the packet using a particular port, flood the packet, or simply drop the packet. Thus, a forwarding table entry for IPv4 / IPv6 packets with a particular transmission control protocol (TCP) destination port could contain an action specifying that these packets should be dropped.

[0161] Making forwarding decisions and performing actions occurs, based upon the forwarding table entry identified during packet classification, by executing the set of actions identified in the matched forwarding table entry on the packet.

[0162] However, when an unknown packet (for example, a “missed packet” or a “match-miss” as used in OpenFlow parlance) arrives at the data plane 880, the packet (or a subset of the packet header and content) is typically forwarded to the centralized control plane 876. The centralized control plane 876 will then program forwarding table entries into the data plane 880 to accommodate packets belonging to the flow of the unknown packet. Once a specific forwarding table entry has been programmed into the data plane 880 by the centralized control plane 876, the next packet with matching credentials will match that forwarding table entry and take the set of actions associated with that matched entry.

[0163] A network interface (NI) may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE / VNE (physical or virtual) often used for management purposes; where such an IP address is referred to as the nodal loopback address. The IP address(es) assigned to the NI(s) of a ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE / VNE implemented on a ND can be referred to as IP addresses of that NE / VNE.

[0164] Each VNE (e.g., a virtual router, a virtual bridge (which may act as a virtual switch instance in a Virtual Private LAN Service (VPLS) is typically independently administrable. For example, in the case of multiple virtual routers, each of the virtual routers may share system resources but is separate from the other virtual routers regarding its management domain, AAA (authentication, authorization, and accounting) name space, IP address, and routing database(s). Multiple VNEs may be employed in an edge ND to provide direct network access and / or different classes of services for subscribers of service and / or content providers.Atty. Docket No.: 4906P112510W001

[0165] Within certain NDs, “interfaces” that are independent of physical NIs may be configured as part of the VNEs to provide higher-layer protocol and service information (e.g., Layer 3 addressing). The subscriber records in the AAA server identify, in addition to the other subscriber configuration requirements, to which context (e.g., which of the VNEs / NEs) the corresponding subscribers should be bound within the ND. As used herein, a binding forms an association between a physical entity (e.g., physical NI, channel) or a logical entity (e.g., circuit such as a subscriber circuit or logical circuit (a set of one or more subscriber circuits)) and a context’s interface over which network protocols (e.g., routing protocols, bridging protocols) are configured for that context. Subscriber data flows on the physical entity when some higher-layer protocol interface is configured and associated with that physical entity.A Wireless Network per Some Embodiments

[0166] Figure 1000 illustrates an example of a communication system per some embodiments. In the example, the communication system 1000 includes a telecommunication network 1002 that includes an access network 1004, such as a radio access network (RAN), and a core network 1006, which includes one or more core network nodes 1008. The access network 1004 includes one or more access network nodes, such as network nodes 1010A and 1010B (one or more of which may be generally referred to as network nodes 1010), or any other similar 3rdGeneration Partnership Project (3 GPP) access node or non-3GPP access point. The network nodes 1010 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1012A, 1012B, 1012C, and 1012D (one or more of which may be generally referred to as UEs 1012) to the core network 1006 over one or more wireless connections.

[0167] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1000 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1000 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0168] The UEs 1012 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1010 and other communication devices. Similarly, the network nodes 1010 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1012 and / or with other network nodes or equipment in the telecommunication networkAtty. Docket No.: 4906P112510W0011002 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1002.

[0169] In the depicted example, the core network 1006 connects the network nodes 1010 to one or more hosts, such as host 1016. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1006 includes one more core network nodes (e.g., core network node 1008) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1008. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0170] The host 1016 may be under the ownership or control of a service provider other than an operator or provider of the access network 1004 and / or the telecommunication network 1002, and may be operated by the service provider or on behalf of the service provider. The host 1016 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0171] As a whole, the communication system 1000 of Figure 10 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave AccessAtty. Docket No.: 4906P112510W001(WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0172] In some examples, the telecommunication network 1002 is a cellular network that implements 3 GPP standardized features. Accordingly, the telecommunication network 1002 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1002. For example, the telecommunication network 1002 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0173] In some examples, the UEs 1012 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1004 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1004. Additionally, a UE may be configured for operating in single- or multiple radio access technology (multi-RAT) or multistandard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0174] In the example, the hub 1014 communicates with the access network 1004 to facilitate indirect communication between one or more UEs (e.g., UE 1012C and / or 1012D) and network nodes (e.g., network node 1010B). In some examples, the hub 1014 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1014 may be a broadband router enabling access to the core network 1006 for the UEs. As another example, the hub 1014 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1010, or by executable code, script, process, or other instructions in the hub 1014. As another example, the hub 1014 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1014 may be a content source. For example, for a UE that is a virtual reality (VR) headset, display, loudspeaker or other media delivery device, the hub 1014 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1014 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1014 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.Atty. Docket No.: 4906P112510W001

[0175] The hub 1014 may have a constant / persistent or intermittent connection to the network node 1010B. The hub 1014 may also allow for a different communication scheme and / or schedule between the hub 1014 and UEs (e.g., UE 1012C and / or 1012D), and between the hub 1014 and the core network 1006. In other examples, the hub 1014 is connected to the core network 1006 and / or one or more UEs via a wired connection. Moreover, the hub 1014 may be configured to connect to a machine-to-machine (M2M) service provider over the access network 1004 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1010 while still connected via the hub 1014 via a wired or wireless connection. In some embodiments, the hub 1014 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1010B. In other embodiments, the hub 1014 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1010B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0176] In some embodiments, the network devices 802, 804, 806, or control plane device 904 may implement network nodes 1008, 1010A-B, or host 1017 and perform operations discussed herein above relating to Figures 1 to 7. For example, the illustrated network devices / nodes or host may perform the operations of an EV battery information aggregator discussed herein.Terms

[0177] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” and so forth, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0178] The description and claims may use the terms “coupled” and “connected,” along with their derivatives. These terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of wireless or wireline communication between two or more elements that are coupled with each other. A “set,” as used herein can refer to any whole number of items including one item.Atty. Docket No.: 4906P112510W001

[0179] An electronic device stores and transmits (internally and / or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as a computer program code or a computer program) and / or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical, or other form of propagated signals -such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., of which a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), other electronic circuitry, or a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and / or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code / data even when the electronic device is turned off (when power is removed). When the electronic device is turned on, that part of the code that is to be executed by the processor(s) of the electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random-access memory (DRAM), static random-access memory (SRAM)) of the electronic device. Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and / or receive code and / or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and / or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of (1) receiving data from other electronic devices over a wireless connection and / or (2) sending data out to other devices through a wireless connection. This radio circuitry may include transmitted s), receiver(s), and / or transceiver(s) suitable for radio frequency communication. The radio circuitry may convert digital data into a radio signal having the proper parameters (e.g., frequency, timing, channel, bandwidth, and so forth). The radio signal may then be transmitted through antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate connecting the electronic device to other electronic devices allowing them to communicate with wire through plugging in a cable to a physical port connected to an NIC. One or more parts of an embodimentAtty. Docket No.: 4906P112510W001of the invention may be implemented using different combinations of software, firmware, and / or hardware.

[0180] The terms “module,” “logic,” and “unit” used in the present application, may refer to a circuit for performing the function specified. In some embodiments, the specified function may be performed by a circuit in combination with software such as by software executed by a general -purpose processor.

[0181] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0182] The term unit may have conventional meaning in the field of electronics, electrical devices, and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

Claims

Atty. Docket No.: 4906P112510W001CLAIMSWhat is claimed is:

1. A method comprising:obtaining (702) battery status information of battery-powered vehicles in a plurality of geographic zones of a mobile network, wherein battery status information from one battery-powered vehicle indicates a geographic zone in which the one battery-powered vehicle is located when the battery status information is obtained;aggregating (704) the battery status information from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network; and providing (706) the battery status information aggregated on the per geographic zone basis to manage power demand in the plurality of geographic zones.

2. The method of claim 1, wherein managing the power demand comprises generating a map to forecast the power demand in the plurality of geographic zones.

3. The method of claim 2, wherein forecasting the power demand is performed based on a machine learning model that is trained using at least pairs of historical battery status information and corresponding historical power demand.

4. The method of any of claims 1 to 3, wherein the battery status information from the one battery-powered vehicle indicates one or more of battery status, a battery level, battery recharge and discharge statistics.

5. The method of any of claims 1 to 4, wherein a geographic zone comprises one or more cell coverage areas of the mobile network.

6. The method of any of claims 1 to 5, wherein an application to manage the power demand registers with the network function through a network exposure function (NEF) using an application programming interface (API) to obtain the aggregated battery status information without personal data from the battery-powered vehicles on the per geographic zone basis.

7. The method of any of claims 1 to 6, wherein the one battery-powered vehicle registers with the mobile network comprises the one battery-powered vehicle registering an identifier provided by the network function though an access and mobility management function (AMF), wherein the identifier is used to set up and renew a session through a session managementAtty. Docket No.: 4906P112510W001function (SMF) for the one battery-powered vehicle to notify location change on the per geographic zone basis.

8. The method of claim 7, wherein the identifier provided by the network function uniquely identifies the one battery-powered vehicle in the mobile network and expires after a time period or upon occurrence of an event regarding the one battery-powered vehicle.

9. The method of claim 7, wherein the location change is obtained from the AMF, which receives a location update from a location management function (LMF) or Gateway Mobile Location Center (GMLC).

10. The method of any of claims 1 to 9, wherein obtaining the battery status information from the one battery-powered vehicle comprises the network function requesting location information of the one battery-powered vehicle, wherein the location information indicates the geographic zone in which the one battery-powered vehicle is located or coordinates of the one battery-powered vehicle when the battery status information is obtained.

11. The method of any of claims 1 to 10, wherein the geographic zone is mapped to a cell coverage area of the mobile network, and wherein upon the one battery-powered vehicle moving from the geographic zone to another geographic zone, the battery status information of the one battery-powered vehicle is obtained using one or more network functions that are involved in handover operations.

12. The method of any of claims 1 to 11, wherein the battery status information from the battery-powered vehicles on the per geographic zone basis is aggregated with personal data corresponding to the battery-powered vehicles being removed.

13. An electronic device (904) comprising:a processor (942) and machine-readable storage medium (948) that provides instructions that, when executed by the processor (912), are capable of causing the processor (912) to perform:obtaining (702) battery status information of battery-powered vehicles in a plurality of geographic zones of a mobile network, wherein battery status information from one battery-powered vehicle indicates a geographic zone in which the one battery-powered vehicle is located when the battery status information is obtained;Atty. Docket No.: 4906P112510W001aggregating (704) the battery status information from the battery-powered vehicles on a per geographic zone basis using a network function of the mobile network; andproviding (706) the battery status information aggregated on the per geographic zone basis to manage power demand in the plurality of geographic zones.

14. The electronic device of claim 13, wherein managing the power demand comprises generating a map to forecast the power demand in the plurality of geographic zones.

15. The electronic device of claim 14, wherein forecasting the power demand is performed based on a machine learning model that is trained using at least pairs of historical battery status information and corresponding historical power demand.

16. The electronic device of any of claims 13 to 15, wherein the battery status information from the one battery-powered vehicle indicates one or more of battery status, a battery level, battery recharge and discharge statistics.

17. The electronic device of any of claims 13 to 16, wherein a geographic zone comprises one or more cell coverage areas of the mobile network.

18. The electronic device of any of claims 13 to 17, wherein an application to manage the power demand registers with the network function through a network exposure function (NEF) using an application programming interface (API) to obtain the aggregated battery status information without personal data from the battery-powered vehicles on the per geographic zone basis.

19. The electronic device of any of claims 13 to 18, wherein the one battery-powered vehicle registers with the mobile network comprises the one battery-powered vehicle registering an identifier provided by the network function though an access and mobility management function (AMF), wherein the identifier is used to set up and renew a session through a session management function (SMF) for the one battery-powered vehicle to notify location change on the per geographic zone basis.

20. The electronic device of claim 19, wherein the identifier provided by the network function uniquely identifies the one battery-powered vehicle in the mobile network and expires after a time period or upon occurrence of an event regarding the one battery-powered vehicle.Atty. Docket No.: 4906P112510W00121. The electronic device of claim 19, wherein the location change is obtained from the AMF, which receives a location update from a location management function (LMF) or Gateway Mobile Location Center (GMLC).

22. The electronic device of any of claims 13 to 21, wherein obtaining the battery status information from the one battery-powered vehicle comprises the network function requesting location information of the one battery-powered vehicle, wherein the location information indicates the geographic zone in which the one battery-powered vehicle is located or coordinates of the one battery-powered vehicle when the battery status information is obtained.

23. The electronic device of any of claims 13 to 22, wherein the geographic zone is mapped to a cell coverage area of the mobile network, and wherein upon the one battery-powered vehicle moving from the geographic zone to another geographic zone, the battery status information of the one battery-powered vehicle is obtained using one or more network functions that are involved in handover operations.

24. The electronic device of any of claims 13 to 23, wherein the battery status information from the battery-powered vehicles on the per geographic zone basis is aggregated with personal data corresponding to the battery-powered vehicles being removed.

25. A machine-readable storage medium (948) that provides instructions that, when executed by a processor (942), are capable of causing the processor (942) to perform methods 1 to 12.

Images