METHODS AND SYSTEMS FOR DETECTING A FAILED NETWORK PROVIDER RESOURCE IN AN SOA/5G NETWORK
TECHNICAL FIELD
[0001] The present invention generally relates to communication networks and, more particularly, to mechanisms and techniques for detecting failed network resources in such systems.
BACKGROUND
[0002] Over time the number of products and services provided to users of telecommunication products has grown significantly. For example, in the early years of wireless communication, devices could be used for conversations and later also had the ability to send and receive text messages. Over time, technology advanced and wireless phones of varying capabilities were introduced which had access to various services provided by network operators, e.g., data services, such as streaming video or music service. More recently there are numerous devices, e.g., so called “smart” phones and tablets, which can access communication networks in which the operators of the networks, and other parties, provide many different types of services, applications, etc.
[0003] Over time various generations of radiocommunication systems have been designed, standardized and rolled out by the operators and network equipment providers including so-called 2G, 3G and 4G (LTE) generational systems. Now development is mostly completed on the next generation radiocommunication system, the so-called 5G system. The 5G architecture is based on Service Oriented Architecture (SOA) OR Service Based Architecture (SBA). Figure 1 generally illustrates correlations between nodes defined in an SOA architecture 100 on the left hand side of the figure and nodes defined in a 5G architecture 102 on the right hand side of the figure.
[0004] In the 5G architecture, the Network function Repository Function (NRF) is a node which provides a "Service Broker OR Service Registry or Service Repository" function as defined by the SOA or SBA. The other Network Functions (NFs) in the 5G architecture can be "Service Providers" or "Service Requester/Consumer" or both. As per the SOA/SBA principles, the 5G NFs (both Service Providers and Service Requesters/Consumers) should register themselves in the NRF together with the list of services exposed by the NF. The NRF itself also provides services to the other NFs for NFManagement (register, update or deregister its profile in another NRF) and NFDiscovery (which allows a Network Function to discover services offered by other Network Functions, by querying the NRF).
[0005] The 3GPP technical specification 29.510 provides the current technical specification for Network Function Repository Services for 5G systems. More specifically, sections 5.2.2.2.2 and 5.2.2.3.2 in this technical specification describe how NF registration with the NRF is performed and how the NF informs the NRF that it is still operational, respectively. Regarding the latter function, the standards specify that each registered NF shall contact the NRF periodically to indicate that it is still operational by sending a “heart-beat” signal. The time interval at which the NRF shall be contacted is deployment-specific, and it is returned by the NRF to the NF Service Consumer as a result of a successful registration. [0006] According to the standards, when the NRF detects that a given NF has not updated its profile for a configurable amount of time (longer than the heart-beat interval), the NRF changes the status of the NF to SUSPENDED and considers that the NF and its services can no longer be discovered by other NFs via the NFDiscovery service. The NRF notifies NFs subscribed to receiving notifications of changes of the NF Profile that the NF status has been changed to SUSPENDED. This “heart-beat” technique for discovering NF failure is described in more detail below with respect to Figure 2.
[0007] The existing method for tracking the operational status of NFs in a 5G network as described in the 3GPP TS 29.510 has the following drawbacks. It relies only on the fixed interval-based Heart-Beat information being sent from the network resources to the NRF to be able to detect whether a network resource is healthy/available/functional or not. If a network resource fails/goes down immediately after sending the heart-beat information to NRF, the NRF will not be aware that the network resource has gone down until the next interval of heart-beat, when it will miss the heart-beat from the network resource and thus determine that the network resource has failed.
[0008] The time between when a network resource has failed and when the NRF detects the failure of the network resource can be quite long (depending on what has been configured as the heart-beat interval). During this time (i.e., the time between the failure of network resource and detection of it by NRF), there could be many consumer network functions that request information from the NRF about the related provider network functions. In response to these requests, the NRF (before it detects the failure of a network resource) shall keep providing information about the unavailable network resource to the consumer network functions who request the functionality provided by the (now) unavailable NF. This, in turn, may lead to delay in response times for a service request (where the consumer network function sends a request to the unavailable network resource and after response time-out, tries some other resource) or even temporary unavailability of a service.
[0009] One solution to this problem would be to increase the frequency of the heart-beat interval so that the NRF would be able to detect the network resource failure more quickly. However this will increase the network signaling significantly (considering that many network resources will send heart-beat information to the NRF) which is not efficient because this signaling is not related to the actual traffic that brings revenue to the customer and instead consumes network resources unnecessarily.
[0010] Thus, there is a need to provide methods and systems that overcome the above-described drawbacks associated with detecting network resource failure.
SUMMARY
[0011] Embodiments enable network function resource function nodes in, for example, a 5G telecommunication network to more rapidly detect network node failures.
[0012] According to an embodiment, there is a method for indicating failure of a provider network function instance by a consumer network function instance in a telecommunication network, the method including requesting, by the consumer network function (NF) instance, a service from the provider NF instance; failing to receive, by the consumer NF instance, a response from the provider NF instance; and transmitting a signal, by the consumer NF instance, towards a network function repository function (NRF) node indicating a lack of response to its request from the provider NF instance.
[0013] According to an embodiment, there is an instance in a telecommunication system including a processor and interface configured to request, a service from a provider NF instance and which fail to receive a response from the provider NF instance; and which are further configured to transmit a signal, by the consumer NF instance, towards a network function repository function (NRF) node indicating a lack of response to its request from the provider NF instance.
[0014] According to an embodiment, a method for detecting failure of a provider network function instance includes receiving, by a network function repository function (NRF) node from a consumer network function (NF) instance, a message indicating a lack of response by the provider NF instance to a request for service from the consumer network function (NF) instance; and taking, by the NRF node, remedial action associated with the message indicating a lack of response by the provider NF instance to a request for service.
[0015] According to an embodiment, a network function repository function (NRF) node includes a processor and interface configured to receive, a message from a consumer NF instance indicating a lack of response by a provider NF instance to a request for service from the consumer network function (NF) instance; and further configured to take remedial action associated with the message indicating a lack of response by the provider NF instance to a request for service.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:
[0018] Figure 1 illustrates an architecture according to an embodiment;
[0019] Figures 2A-2C show a signaling diagram according to an embodiment;
[0020] Figures 3A-3E illustrate a use example according to an embodiment;
[0021] Figure 4 shows a flowchart for indicating failure of a provider network function node according to an embodiment;
[0022] Figure 5 illustrates a flowchart for detecting failure of a provider network function instance according to an embodiment;
[0023]
[0024] Figure 6 depicts a communication node according to an embodiment; and
[0025] Figure 7 depicts an electronic storage medium on which computer program embodiments can be stored.
7
RECTIFIED SHEET (Rule 91) DETAILED DESCRIPTION
[0026] The following description of the embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. The embodiments to be discussed next are not limited to the configurations described below, but may be extended to other arrangements as discussed later.
[0027] Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification is not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.
[0028] As described in the Background section, there are problems associated with current mechanism for detecting network resource failure in, for example, 5G communication networks. Embodiments described herein support various techniques for network functions which are consuming services (referred to herein as “consumer NFs” or “consumer nodes”) from other network functions which provide services (referred to herein as “provider NFs” or “provider nodes”) to enable the consumer NFs to inform the NRF when a provider NF registered with the NRF has failed to respond to a request for service. According to an embodiment, the consumer NF can inform the NRF of information associated with a failed or potentially failed provider NF in conjunction with sending its own heart-beat signal to the NRF. According to other embodiments, the consumer NF can inform the NRF of information associated with a failed or potentially failed provider NF in a signal to the NRF which is separate from the sending of its own heart-beat signal to the NRF.
[0029] Prior to discussing such embodiments, the problem with the current techniques for informing the NRF of an NF failure in (for example) a 5G communication network that are briefly described in the Background section above, will now be described in more detail with respect to the signaling diagram of Figures 2A-2C. Therein, the NRF 200 is the network function that acts as a “Service Registry” where other network functions register and publish the services which they provide or consume. The Charging Function (CHF) 202 is the network function responsible for providing “Charging” and “Policy” services and has multiple network function instances, i.e., NFi1 , NFi2, NFi3... NFin. The Session Management Function (SMF) or Policy Control Function (PCF) 204 is the network function that consumes “Charging” and “Policy” services provided by CHF 202 and may also have multiple network function instances. As used herein, the terms “instance” or “instances” are used herein to include both virtual servers in a cloud environment as well as physical servers or nodes which are all used to supply sufficient bandwidth in a telecommunication system to support the CHF, SMF, PCF or other functions.
[0030] Given the exemplary network architecture shown in Figures 2A-2C and assuming that the heart-beat interval is configured for every 1 hour, the NRF 200 will expect that after an NF or NF instance registers itself, the NF will send a heart-beat signal every 1 hour after the successful registration (as long as it remains operational). To better understand the challenges presented by this conventional mechanism for the NRF 200 to track NF operability consider the following scenario
[0031] Starting at time 00:00h consider that the following steps take place. First, as shown in block 208, each of the CHF 202 instances N Fi 1 , N Fi2, NFi3... NFin registers in the NRF 200. The steps/signals illustrated in block 208 show the registration process of the CHF instances NFi1 , NFi2, NFi3... NFin, in the NRF 200 by sending a registration signal to the NRF 200. In response to a successful registration in the NRF 200, each CHF 202 instance receives a registration successful response signal which includes the time interval (e.g., 1 hour) for sending heart-beat signals back to the NRF 200. As will be appreciated by those skilled in the art, other NFs (like the SMF or PCF 204) also register in the NRF 200 and send heart-beat signals, but these other NFs are not shown explicitly in Figures 2A-2C for brevity.
[0032] At step 210, something goes wrong with the NFi2 instance of the CHF 202, e.g., almost immediately after that instance has registered or sent a heart-beat signal to the NRF 200. At this time, the NRF 200 is unaware of the failure of the NFi2 instance and, therefore, still considers it as healthy and available. At step 212, the NRF 200 receives a request for service discovery form SMF/PCF 204 for charging/policy services. Still unaware of the NFi2 instance failure, the NRF 200 responds to SMF/PCF 204 with the information about network functions that provide the charging/policy services via signal 214. In this response 214, NRF 200 also includes NFi2 as one of the resources that provides the requested charging/policy services. [0033] At step/signal 216, SMF/PCF 204 randomly (or otherwise) selects the NFi2 instance from the list that the NRF 200 has provided and requests service from NFi2. As NFi2 is unavailable, there is no response to the request 216 from SMF/PCF 204. Therefore, at step 218, the request from SMF/PCF 204 times out due to no response from NFi2 and SMF/PCF 204 has to retry the request towards some other NF instance from the list that the NRF 200 has provided. As will be appreciated by those skilled in the art, this adds to the delay in the actual provision of service to the SMF/PCF 204 and, if there were more NF instances that were unavailable, the delay would increase further.
[0034] At step/signal 220, SMF/PCF 204 retries the request to a different NF instance from the list provided by the NRF 200 and, at step/signal 222 gets a successful response. However, it will be appreciated by those skilled in the art that this wait and retry has caused delay in the actual response to the end-user service. Additionally, at this point in time, the NRF 200 is still unaware that NFi2 is down. Steps 216, 218, 220 and 222 may even be repeated by SMF/PCF 204 as it is acting on information received from NRF 200, randomly requesting service from N Fi2, reaching a time-out status and then retrying to a different NF instance to eventually obtain the service. This has the effect of increasing the load/traffic towards other NF instances of CHF 202 as shown in steps 224, 226, and 228, while NRF 200 continues to be unaware of the NFi2 instance failure.
[0035] Then, after an hour has passed (i.e. the time interval for heart-beat from the NFs to NRF 200), CHF 202 NFs NFi1 , NFi3... NFin send their heart-beat signals and load information to the NRF 200 at steps 230, 232 and 234 (and NRF responds at steps 236, 238 and 240). But NFi2 does not send any heart-beat signal and load information to the NRF 200 as it has crashed (step 242). It is only after this point that the NRF 200 becomes aware that NFi2 is not available and has crashed and changes NFi2 instance status to SUSPENDED such that NFi2’s services can no longer be discovered by the NFDiscovery service. NRF 200 then notifies the other NFs (e.g., SMF/PCF 204) that have subscribed to receiving notifications about the unavailability of NFi2 and its status being changed to SUSPENDED.
[0036] Thus, in conclusion, since the NRF 200 has no way of quickly finding out that a network resource has crashed, it waits for the next heart-beat interval to determine whether a certain network resource is working or not. In the above example the heart-beat interval was considered to be 1 hour, but in reality, it can be even longer which means there will be an even longer service disruption during the time between when a network resource fails and its eventual determination by NRF 200 as having failed.
[0037] Embodiments which address this problem will now be described starting with the signaling diagram of Figures 3A-3E. As in the above description of Figures 2A-2C, in the flow shown in Figures 3A-3E, the NRF 300 is the network function that acts as a “Service Registry” where other network functions register and publish the services they provide or consume. The CHF 302 is the network function responsible for providing “Charging” and “Policy” services and has multiple network function instances (i.e., NFi1 , NFi2, NFi3... NFin) and the SMF or PCF 304 is the network function that consumes “Charging” and “Policy” services provided by CHF 302 and, in this embodiment, also has multiple instances (i.e., SMF or PCF 1 , SMF or PCF 2, SMF or PCF 3... SMF or PCF n). Again, for this embodiment, assume that the heart-beat interval is configured for every 1 hour, such that the NRF 300 will expect that after a NF or NF instance registers itself, it will send a heart-beat signal every 1 hour after its successful registration as shown by block
306
[0038] Starting at time 00:00h the following steps take place. Signals in block 308 show the registration process of the CHF 302 instances NFi1 , NFi2, NFi3... NFin, in the NRF 300 as well as the NRF’s successful registration response and setting of the time interval (1 hour) for the CHF instances to send their respective heart-beat signal. It will be appreciated by those skilled in the art NFs or NF instances (like SMF or PCF 304) will also register in the NRF 300 and send heart-beat signals, albeit such is not shown explicitly in Figures 3A-3E.
[0039] At step 310, something goes wrong with the CHF 302’s NFi2 instance, e.g., almost immediately after it has registered or sent its heart-beat to the NRF 300. The NRF 300 is therefore unaware of the NFi2 failure and still considers it as healthy and available. At step 312, the NRF 300 receives a request for service discovery from SMF/PCF 304 for charging/policy services. Still unaware of the NFi2 instance failure, the NRF 300 responds to SMF/PCF 304 with the information about network functions that provide the charging/policy services. In this response 314, the NRF 300 also includes NFi2 as one of the resources that provides the requested services.
[0040] At step 316, SMF/PCF 304 randomly selects the NFi2 instance from the list that NRF 300 provided. As NFi2 is unavailable, there is no response to the request 316 from SMF/PCF 304. At step 318, the request 316 from SMF/PCF 304 times out due to no response from NFi2 and SMF/PCF 304 must retry the request towards some other NF instance from the list that NRF 300 has provided. Note that according to different embodiments, the SMF/PCF 304 can time out after it sends a single request signal 316 without a response or it could resend signal 316 one or more additional times before the time out occurs.
[0041] Thusfar, it will be seen that steps 306-318 of the embodiment of Figures 3A- 3E and steps 206-218 of the Background Art of Figures 2A-2C are substantially the same. However the embodiment of Figures 3A-3E addresses the delay in detection of the failure of NFi2 by the NRF 200 starting with the signaling illustrated in block 320 which will now be described below.
[0042] Instead of simply continuing with retrying the request 316 to a different NF instance as in Figures 2A-2C, the consumer NF node (i.e., SMF or PCF 304 in this case) informs the NRF 300 about the fact that NFi2 (provider NF node) did not respond to its request 316 for service. The manner in which the consumer NF node informs the NRF 300 of this can vary based on different embodiments.
[0043] According to one embodiment, the SMF/PCF 304 (service consuming NFs) performs an additional step 322 where it will, e.g., immediately after its request(s) 316 time out, inform the NRF 300 (e.g., via a new Representational State Transfer (REST) message) that the NF instance to which request 316 was sent and which was identified by the NRF 300 in the NFDiscovery response to the SMF/PCF is not available. In response to receiving this message 322, the NRF 300 will register the failure event reported by SMF/PCF 304 (or any other NF) and return a response in step/signal 324. According to various embodiments, the transmission of message 322 toward NRF 300 can be performed by one instances of the consumer NF, multiple instances of the consumer NF or all instances of the consumer NF (as shown in Figure 3B). This feature of various embodiments enables the NRF to obtain an overall view of the provider network resources in the network. For example, within a given period of time, there could be hundreds of consumer NFs trying to get service from the provider NFs. The reason for a certain consumer NF not being able to get a service from a given provider NF could be numerous. For example, the failure cause could be a temporary network glitch or it could be a disaster that caused the provider NF to go down until repaired.
[0044] Thus just relying on a single report form a single consumer NF may not be very reliable/accurate. But when various different consumer NFs that are trying to consume the service from the provider NF report failure, that gives a more accurate view of the failure of the provider NF’s actual status and, when reported failures cross a configured threshold, the NRF 300 can take corrective actions.
[0045] As an alternative to an independent message 322, shown by way of signal 326 in Figures 3A-3E, the SMF/PCF 304 (consumer NF node) will report the unavailability of the provider NF node instance as an additional payload in the existing heart-beat message that the consumer NF node sends to the NRF 300 at regular intervals, e.g., every hour. Assuming that the consumer NF node’s heart-beat signal is sent at a different time than the provider NF node’s heart-beat signal (i.e., the one which has become non- operational), then at some times the NRF 300 would learn more quickly about NFi2’s failure. According to some embodiments, the consumer NFs can send information about the status of more than one provider NF in the heart-beat signal. The consumer NFs can not only send information about provider NF failures, but also on successes. In any event, the NRF 300 will respond to such signals by acknowledging them via signal 328. [0046] According to most embodiments, if the consumer NF node uses the approach to inform the NRF 300 via a separate (from the heart-beat) signal 322, then it will proceed to attempt to gain service from another CHF service instance, e.g., NFi3, via signal 330. If successful, NFi3 will send a successful acknowledgement via signal 332. Alternatively, if the consumer NF node uses the technique to inform the NRF 300 of NFi2’s failure via its regularly scheduled heart-beat signal, it can attempt to gain service from another CHF service instance, e.g., NFi3, via signal 330 before it informs the NRF 300 of NFi2’s failure depending upon when its next heart-beat signal 326 is scheduled to be transmitted.
[0047] According to some embodiments, either message 322 or 326 which is used above to inform the NRF 300 of a potentially failed provider NF node, the message 322 and/or message 326 can also be used to inform the NRF 300 of provider NF node(s) which are functioning properly.
[0048] Regardless of how the consumer NF node informs NRF 300 of NFi2’s failure, the NRF 300 can then take one (or more) of several different remedial actions. At step 334, NRF 300, based on the information received from different NFs, immediately changes the status of the reported provider NF/NF instance (i.e., NFi2 in this example) to SUSPENDED and considers that the NF/NF instance and its services can no longer be discovered by other NFs via the NFDiscovery service. The NRF notifies NFs subscribed to receive notifications of changes of the NF Profile that the NF/NF instance status has been changed to SUSPENDED.
[0049] Optionally, instead of changing the status of the reported provider NF node to
SUSPENDED based on information received from one or more consumer NFs, the NRF 300 can first check the identified NF/NF instance itself to see if it is operational. Thus, at step 336 NRF can, based on the information received from a different NF, request a status report from the NF that was reported as unavailable. The NRF 300 can analyze all consumer NF reports of a provider NF/NFs before taking a decision on the availability of the provider NF. If the NRF 300 receives a status update 338 from the NF/NF instance, it means that the network resource is OK and no further action is required. If, alternatively the NRF 300 does not receive any response from a NF/NF instance, the NRF 300 changes the status of the NF/NF instance to SUSPENDED and considers that the NF/NF instance and its services can no longer be discovered by other NFs via the NFDiscovery service as shown in block 340. The NRF 300 notifies NFs subscribed to receiving notifications of changes of the NF Profile that the NF/NF instance status has been changed to SUSPENDED.
[0050] Then at step 342, when the other NFs send a request to NRF 300 for NFDiscovery, the NRF 300 shall provide the correct information about the resources that are available. At the next heart-beat interval, all the available network resources shall provide the heart-beat information (indicated by the signals in block 346) and NRF 300 shall not wait for the heart-beat information from the suspended NF instance.
[0051] It will be appreciated that these embodiments will ensure that the failure of a network resource is detected and identified quickly and that actions to suspend the failed network resource are taken more quickly, instead of waiting for the next heart-beat interval. Thus, the above described embodiments shall help reduce service outage and unnecessary signaling in the network. [0052] Embodiments can be described as methods. For example, as illustrated in Figure 4 a method 400 for indicating failure of a provider network function node by a consumer network function node in a telecommunication network includes requesting 402, by the consumer network function (NF) node, a service from the provider NF node; failing 404 to receive, by the consumer NF node, a response from the provider NF node; and transmitting 406 a signal, by the consumer NF node, toward a network function repository function (NRF) node indicating a lack of response to its request from the provider NF node. [0053] According to another embodiment, as shown in the flowchart of Figure 5, a method 500 for detecting failure of a provider network function instance includes the steps of receiving 502, by a network function repository function (NRF) node from a consumer network function (NF) instance, a message indicating a lack of response by the provider NF instance to a request for service from the consumer network function (NF) instance; and taking 504, by the NRF node, remedial action associated with the message indicating a lack of response by the provider NF instance to a request for service.
[0054] Embodiments described above can be implemented in one or more nodes (or servers). An example of a communication node 600 is shown in Figure 6. The communication node 600 (or other network node) includes a processor 602 for executing instructions and performing the functions described herein, e.g., the functions performed by the NRF 300, the CHF 302 and the SMF or PCF 304. The communication node 600 also includes a primary memory 604, e.g., random access memory (RAM) memory, a secondary memory 606 which can be a non-volatile memory, and an interface 608 for communicating with other portions of a network or among various nodes/servers in support of charging. [0055] Processor 602 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other communication node 600 components, such as memory 604 and/or 606, node 600 functionality in support of the various embodiments described herein. For example, processor 602 may execute instructions stored in memory 604 and/or 606.
[0056] Primary memory 604 and secondary memory 606 may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, RAM, read-only memory (ROM), removable media, or any other suitable local or remote memory component. Primary memory 604 and secondary memory 606 may store any suitable instructions, data or information, including software and encoded logic, utilized by node 600. Primary memory 604 and secondary memory 606 may be used to store any calculations made by processor 602 and/or any data received via interface 608.
[0057] Communication node 600 also includes communication interface 608 which may be used in the wired or wireless communication of signaling and/or data. For example, interface 608 may perform any formatting, coding, or translating that may be needed to allow communication node 600 to send and receive data over a wired connection. Interface 608 may also include a radio transmitter and/or receiver that may be coupled to or a part of the antenna. The radio may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection. The radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters. The radio signal may then be transmitted via an antenna to the appropriate recipient.
[0058] Various embodiments described herein refer in some fashion to nodes which are included in the term instances. In some embodiments the non-limiting communication node (also interchangeably called a node or telecommunication node) is more commonly used and it refers to any type of network node which directly or indirectly communicates with a user equipment (UE), a node in one or more operator networks, and a core network. [0059] The disclosed embodiments provide methods and devices for detecting network function failure. It should be understood that this description is not intended to limit the invention. On the contrary, the embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention.
Further, in the detailed description of the embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the claimed invention.
However, one skilled in the art would understand that various embodiments may be practiced without such specific details.
[0060] As also will be appreciated by one skilled in the art, the embodiments may take the form of an entirely hardware embodiment or an embodiment combining hardware and software aspects. Further, the embodiments, e.g., the configurations and other logic associated with the charging process to include embodiments described herein, such as, the methods associated with Figure 4 or Figure 5, may take the form of a computer program product stored on a computer-readable storage medium having computer- readable instructions embodied in the medium. For example, Figure 7 depicts an electronic storage medium 700 on which computer program embodiments can be stored. Any suitable computer-readable medium may be utilized, including hard disks, CD-ROMs, digital versatile disc (DVD), optical storage devices, or magnetic storage devices such as floppy disk or magnetic tape. Other non-limiting examples of computer-readable media include flash-type memories or other known memories.
[0061] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts provided in the present application may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.