Patent Publication Number: US-9426088-B2

Title: System and method for cloud-based implementation of control of focused overload of service element (COFO-SE) via explicit (or virtualized) machine-to-machine (M2M) gateway element

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a national stage application (under 35 U.S.C. §371) of PCT/US2012/061645, filed Oct. 24, 2012, claiming the priority of U.S. Provisional Application No. 61/552,158, filed Oct. 27, 2011, the contents of which are incorporated herein by reference in their entirety. 
    
    
     FIELD OF THE INVENTION 
     The field of the present invention is cloud-based systems, and more particularly, control of focused overload of service elements using distributed virtual resources. 
     BACKGROUND 
     In communication networks, overload occurs when a networked service element has insufficient resources (e.g., CPU processing capacity, memory, network bandwidth, input/output, disk resources, etc.) to successfully process all of the requests that it receives. Some networked service elements can experience prolonged overload due to high rates of incoming service requests and/or partial network outage leading to failures. Service elements include—but are not limited to—voice mail server, instant messaging (IM) server, presence server, location server, address book server, subscriber profile server, self-service kiosks, surveillance trigger/input aggregator, mobile-device-originated traffic aggregator or gateway, policy server, protection and security service manager, etc. Focused overload is a special case of a network overload where the overload is focused on a service element. This subset can range from network destination (e.g., a telephone number or an IP address) to a group of switching and network servers. 
     In the absence of overload control, such overloads can threaten the stability of a communication network, and can cause a severe reduction in successful completion of service requests. Ultimately, service elements can fail to provide service(s) due to lost requests resulting in the unavailability of services to clients. Often, overload problems can compound themselves, which can cause even more sustained load on a service element. Furthermore, during overload, the overall capacity of server(s) can be significantly reduced, since much of their resources are spent rejecting and/or treating loads that they cannot actually process. Under severe overload conditions, the throughput can drop down to a small fraction of the original processing capacity. This is often called congestion collapse. In addition, overload conditions tend to cause service requests to be delayed and/or lost, which can trigger high rates of client abandonment and/or reattempts. 
     Traditionally, focused overload is controlled in two different ways. One way is by reducing the incoming load by rejecting services. For example, only higher priority sessions or transactions may be allowed and all others may be rejected. Unfortunately, this may cause customer frustration, and ultimately churn, leading to loss of revenue. 
     Another way focused overload is controlled is by routing the incoming sessions or transaction requests to native standby service elements which are usually owned and operated by the same organization that owns the service elements whose overload needs to be controlled. However, this may call for drastically higher capital and operation expenses because neither the occurrence nor the duration of the overload events can be accurately predicted. Further, certain drawbacks of utilizing native infrastructure element-based implementation of overload control of service elements include:
     a) Cost;   b) Time required for testing and integration of overload service elements with network;   c) Static allocation of resources;   d) Less flexibility in repositioning the resources; Tighter coupling of computing and communications resources with pre-designed features and functions including services (that are traditionally offered by the service element that is being protected from overload); and   e) Reduced opportunity for system upgrade and innovation   

     Service providers in a dynamic and continuously-evolving networking and service development environment need:
     a) Protection of investment, i.e., investment in the resources that can be rapidly repositioned or repurposed for different revenue generating applications and services; and/or   b) Agility and flexibility, i.e., deploying emerging features and functions utilizing the computing and communications resources that already exist in the network.   

     Accordingly, there is a need for a system that enables network operators and service providers to allocate their budget for computing, communications, and control infrastructure development based on expected design limits. Consequently, there would be no need to create and install silos of computing and networking gears for controlling focused overload of service elements. 
     SUMMARY OF THE INVENTION 
     Aspects of the present invention address these issues and, for example, enable service providers to allocate their budget for computing, communications, and control infrastructure development rather than creating and installing these silos of computing and networking gears which very often either remain underutilized or become obsolete before reaching the full potential (or providing the full return on investment). 
     In one aspect, there is provided a method that includes obtaining blocks of resources for a signaling part of a service element from a variety of networked resources, wherein the resource blocks are integrated into a pool and a unified view is presented to applications and services communicating with the signaling part of the service element. The signaling part of the service element controls allocation of resources from a media part of the service element via instructions over virtual private network links. Blocks of resources for the media part of the service element are obtained from a variety of networked resources, wherein the blocks of resources are integrated into a pool and a unified view is presented to the signaling part of the service element. The media part of the service element uses the resource blocks for the applications and services for a duration of time. The duration of time can range from a few seconds to tens or hundreds of hours. The resource blocks can be obtained from public, private, or community networks through open application and resource programming interfaces (APIs and RPIs). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows block diagrams of current models for control of focused overload of service element (“COFO-SE”) implementations (traditional Implementation—using one for one standby—of Control of Focused Overload of Service Element (COFO-SE) [one for N standby is not shown]). 
         FIG. 2  presents a high level cloud-based COFO-SE implementation model. 
         FIG. 3  illustrates a detailed diagram of the cloud-based implementation of the COFO-SE. 
         FIG. 4  shows a flow chart of steps for gathering the resources from internal and/or external sources (e.g., private, public clouds) for COFO-SE. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
     In traditional stand-alone or infrastructure element-based implementation of protection of COFO-SE, dedicated computing, memory, and communications resources may be needed. These resources need to be integrated with the service and network infrastructure and need to be operated in a harmonious way both in terms of traffic management and privacy/authentication/security administration. 
     As a result, the time required for making these additional elements service ready for supporting the disaster management and overload control features/functions and the costs for successfully achieving the desired results become prohibitively high. For example, additional switching/routing, control/processing, and protection resources need to be allocated and integrated for supporting the desired overload control features/functions. 
     According to certain aspects of the present invention, COFO-SE implementation overcomes the aforementioned drawbacks of traditional standalone overload control implementations because there is no need to pre-allocate native computing, memory, and communications resources—either stand-alone or in the infrastructure service elements—for the purpose of controlling the overloads. Instead, the resources are obtained from public, private, or community networks via open application and resource programming interfaces (APIs and RPIs) through for example, resources broker or exchange firm. 
     These AIPs/RPIs can use any one or more of the following: SOAP, XML, WSDL, Parlay/Parlay-X, HTTP, CORBA, and the like. The details of the API/RPI design and profiling are beyond the scope of this patent application. It is notable that these APIs/RPIs not only simplify access to the desired resources, but also guarantee rapid integration and interoperability with the existing network/infrastructure and security, availability, service continuity mechanisms, and the like. This is due to the fact that the desired overload control features/functions are obtained by browsing available networked resources through open APIs/RPIs and fetching them so that they can be utilized per the requirements of the applications and services for the duration of the session/service. For example, real-time availability of firewalling and encryption key resources is useful for real-time enterprise secure voice communications services over the public internet for the duration of the voice communication session. Legitimate overload of this FAAS (Firewall as a Service) can be handled using embodiments of the present invention. 
     In sum, any application or service that needs to utilize overload control features/functions can obtain those resources through open APIs/RPIs from the network (e.g., the Internet) and then can use those resources for the duration of the session with guaranteed availability, security and reliability. In other aspects, the invention provides a system and a computer program having features and advantages corresponding to those discussed above. 
       FIG. 1  shows block diagrams of current COFO-SE implementations. The service element that is being protected is directly connected to an Application server, session control elements, service gateway, and the like. The service element receives a request for identity verification of a subscriber and a user in order to authenticate access to a transaction or a session-based service (e.g., ID verification, voice mail, IM, location, presence, etc.). The service element may use a pre-determined number of attributes (e.g., service name and location), credentials (e.g., secret codes or biometrics information), and identifier (names, userId, MACId, IP address, geo-location, etc.). The service element may or may not control resources for session and media once the user/subscriber has been authenticated. It is possible that policy, quality of service and security requirements may dictate these allocations. The interface between the signaling elements of the SE and the media control elements of the SE can be open (standard protocol) or proprietary protocol, and the interface can be point-to-point or point-to-multi-point in order to support reliability through distribution of the resource requests. 
     The details of the Cloud framework reference model can be found at http://tools.letf.org/id/draft-khasnabish-cloud-reference-framework-01.txt, which is incorporated by reference in its entirety. 
       FIG. 2  shows a COFO-SE implementation model according to an aspect of the present invention. In this implementation, the additional resources that constitute the Signaling and Media Control parts of the service element (for protecting from overload or for disaster management) are obtained from a set of networked resources, and utilized for the duration of time they are required, and then released back to the resources pool. This duration can vary from a few seconds to many hours. 
     The resource blocks for managing signaling overload control can be obtained from a variety of networked resources and these blocks can be integrated into a pool of service element resources so that a unified view can be presented to the applications and services—subscriber information/profile server, trust and key authority, access/media policy control, session/transaction control server—that are communicating with the Signaling part of the service element that is being protected from overload/disaster. The Signaling part of the service element controls the allocation of resources from the session and media control part of the service element with instructions over virtual private network links that run open protocol with a standardized profile. 
     The resources used for controlling the media part of the service element are obtained from a set of networked resources, and utilized for the duration of the requirements. This duration can vary from a few minutes to many hours. The resource blocks for the media part of the service element can be obtained from a variety of networked sources and these blocks can be integrated into a pool of the media control part of resources so that a unified view can be presented to the signaling part of the service element. 
       FIG. 3  shows further details of how a combination of fixed (internal) resources and borrowed or rented (external) resources can be utilized for control of focused overload on service elements in a cost-effective manner. 
       FIG. 4  shows a flow chart of steps for gathering the resources from internal and/or external sources (e.g., private, public clouds) for COFO-SE. Taking into consideration the historic trends and the monitoring of current resources and requirements, requirements are projected for the next few time periods, Next, the availability of internal resources is determined. If sufficient internal resources are available, then the request for additional resources is fulfilled. If the availability of internal resources is not available, a request is dispatched for resources from the private or public cloud. 
     It should be understood that the methods and systems of the present invention are executed employing machines and apparatus including simple and complex computers. Moreover, the architecture and methods described above can be stored, in part or in full, on forms of machine-readable media. For example, the operations of the present invention could be stored on machine-readable media, such as magnetic disks or optical disks, which are accessible via a disk drive (or computer-readable medium drive). Alternatively, the logic to perform the operations as discussed above, could be implemented in additional computer and/or machine readable media, such as discrete hardware components as large-scale integrated circuits (LSI&#39;s), application-specific integrated circuits (ASIC&#39;s), firmware such as electrically erasable programmable read-only only memory (EEPROM&#39;s); and the like. Implementations of certain embodiments may further take the form of machine-implemented, including web-implemented, computer software. 
     While aspects of this invention have been shown and described, it will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts that are described herein. The invention, therefore, is not to be restricted except in the spirit of the following claims.