WO2017075492A1

WO2017075492A1 - Dynamic virtual machine management platform

Info

Publication number: WO2017075492A1
Application number: PCT/US2016/059525
Authority: WO
Inventors: Dirk Trossen; Renan KRISHNA
Original assignee: Idac Holdings, Inc.
Priority date: 2015-10-29
Filing date: 2016-10-28
Publication date: 2017-05-04

Abstract

Methods and systems for instantiating and operating a surrogate server are disclosed herein. A method may comprise receiving an activation request corresponding to a FQDN, determining, based on a stored metric, a virtualization platform for the FQDN and instantiating, based on the determined virtualization platform, a virtual server. Once the virtual server is operating and running on the determined virtualization platform, the virtual server may receive one or more requests for stored content and transmit, in response to the received one or more requests for content, a response corresponding to the requested content.

Description

DYNAMIC VIRTUAL MACHINE MANAGEMENT PLATFORM

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application

No. 62/248,064, filed on October 29, 2015, the content of which is hereby incorporated by reference herein.

BACKGROUND

[0002] A surrogate server may refer to a server that mirrors the functionahty of another server, usually reachable through an alternative route to the fully qualified domain name that is used to expose the service(s) offered by the surrogate server. Surrogate servers may be utilized in the Internet to shorten latency by placing surrogates closer to users, improve throughput by circumventing congestion points in the network or to satisfy local regulation aspects by placing surrogates within a given legislative border to satisfy the regulatory constraints. Their integration into the network usually requires modifications to the domain name service (DNS) through redirection or the utilization of application-level redirection. There is a need for a method and apparatus for determining a virtualization approach for a given surrogate domain in an internet protocol (IP) based service environment.

[0003] Virtualization of an operating system allows for a reduced capital expenditure since lower hardware costs may be required on a per machine basis since a one-to-one relationship between an operating system and a hardware device is no longer required. Virtualization allows for operating systems and operating environments to occupy only a portion of a system's resources, e.g. power, memory/processor utilization, or the like and that portion of system resources may vary over time. In fact, a virtual machine may be allocated or deallocated on the fly, which may be of particular benefit in the area of surrogate servers. In this way, if a surrogate server is not needed at a particular time instance, it may be deallocated. SUMMARY

[0004] A system, method, and apparatus for dynamically determining a visualization approach for a given surrogate domain in an internet protocol (IP) based service environment are described herein. A method in accordance with one example embodiment for determining a virtu alization approach for a surrogate server includes receiving, by a virtual machine manager (VMM), a request to establish a virtualized web service surrogate. The VMM may then retrieve from a database a metric value associated with a fully qualified domain name (FQDN). The VMM may then execute a reasoning algorithm based on a plurality of inputs, wherein the plurality of inputs includes an ontology, service level agreements (SLAs), and operational constraints. The VMM may then choose a virtu alization technique based on the plurality of inputs.

[0005] Methods and systems for instantiating and operating a surrogate server are disclosed herein. A method may comprise receiving an activation request corresponding to a FQDN, determining, based on a stored metric, a virtu alization platform for the FQDN and instantiating, based on the determined virtu alization platform, a virtual server. Once the virtual server is in operation and running on the determined virtu alization platform, the virtual server may receive one or more requests for stored content and transmit, in response to the received one or more requests for content, a response corresponding to the requested content.

[0006] The surrogate server may comprise memory for storing one or more of: hypertext markup language (HTML) and cascading style sheet (CSS) files, web script files, server plugins and server modules. Determining a virtu alization platform for the FQDN include determining whether a hypervisor-based or a container-based technique should be used. Determining a virtu alization approach may include determining at least one of a primary or secondary image size, requirements regarding a needed operating system or preloaded storage partitions. A stored metric is a boolean metric, may be an integer based metric or may be a decimal based metric corresponding to a defined threshold.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0009] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0010] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0011] FIG. 2 is a message diagram which shows a communication flow between a surrogate server, a proxy server and a target server.

[0012] FIG. 3 is a diagram of exemplary system components in accordance with an example embodiment;

[0013] FIG. 4 is a diagram of an exemplary ontology underpinning in an example embodiment;

[0014] FIG. 5 is a diagram of an example of a metric-based instantiation of one or more surrogate servers;

[0015] FIG. 6 is a diagram of an exemplary storage element having a plurality of fully qualified domain names (FQDNs), corresponding metrics and corresponding timestamps; and

[0016] FIG. 7 is a diagram which shows an exemplary color scheme embodiment which utilizes both a color and an opacity level. DETAILED DESCRIPTION

[0017] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0018] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a pubhc switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0019] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs

102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0020] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple -input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0021] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0022] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may includecommunication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0023] In another embodiment, the base station 114a and the WTRUs

102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0024] In other embodiments, the base station 114a and the WTRUs 102a,

102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0025] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0026] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0027] The core network 106 may also serve as a gateway for the WTRUs

102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology. [0029] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display /touchp ad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

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

[0031] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0032] In addition, although the transmit/receive element 122 is depicted in

FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0033] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabhng the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0034] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0035] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

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

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

[0038] FIG. 1C is a system diagram of the RAN 104 and the core network

106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106. [0039] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

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

[0041] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0042] The MME 142 may be connected to each of the eNode-Bs 140a, 140b,

140c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0043] The serving gateway 144 may be connected to each of the eNode Bs

140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0044] The serving gateway 144 may also be connected to the PDN gateway

146, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

[0046] Other network 112 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may contain gateway functionality. The access router 165 may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router 165 and APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102d.

[0047] A system, method, and apparatus to dynamically determine the most appropriate virtu alization approach to be chosen for a given surrogate domain in an IP-based service environment are described herein. [0048] Methods and procedures for a virtual machine manager (VMM) element that may determine which virtualization technique to use for a given surrogate server are described herein.

[0049] Methods and procedures for making such decisions based on a suitability ontology are also described herein. Embodiments utilizing ontology- based or case-based reasoning engines for the methods and procedures that determine the virtualization technique to be used are described. Methods and procedures for utilizing defined SLAs as well as operational constraints in order to match against the suitability ontology within the determination of the metric are also described.

[0050] Methods and procedures for applying such suitability ontology within a metric-based system, wherein the determined metrics are consulted for the decision making on which virtualization technique is to be used are described.

[0051] Embodiments utilizing threshold-based, interval-based, or color coding schemes for determining the virtualization choice based on the metric for the suitability are also described.

[0052] The system described herein applies to network stack layers including but not limited to the Application Layer. The term surrogate server refers to a server that mirrors the functionality of another server, usually reachable through an alternative route to the fully qualified domain name that is used to expose the service(s) offered by the surrogate server. Surrogate servers may be utilized in the Internet to shorten latency by placing surrogates closer to users, improve throughput by circumventing congestion points in the network or to satisfy local regulation aspects by placing surrogates within a given legislative border to satisfy the regulatory constraints. Their integration into the network usually requires modifications to the DNS, through redirection, or via a utilization of application-level redirection.

[0053] Other efforts on providing IP or hypertext transfer protocol (HTTP) level services over an information-centric networking (ICN) substrate have helped enable solutions that may provide a management approach that allows for a constrained-based placement, activation and teardown of such surrogate servers. The easy integration into the network is facilitated by such solutions, only requiring minimal signaling of the surrogates' availability and no modification of the routing infrastructure to reach the new resources in the network. Other disclosed embodiments may not make use of the HTTP protocol. Other exemplary client/server protocols include the domain name service (DNS), file transfer protocol (FTP), Telnet, internet relay chat (IRC), dynamic host control protocol (DHCP), Quake or Doom style game protocols, Kerberos, or the like. Additionally, embodiments disclosed herein may be useful in peer-to-peer protocols.

[0054] Virtualization approaches may include but are not limited to either hypervisor-based or container-based virtualization of resources. A hypervisor- based virtualization approach may involve a plurality of guest operating systems running on top of a virtual operating platform. Guest operating systems may differ in technology and may be Windows, Linux or Macintosh based. In contrast, a container-based virtualization approach relies on a single shared operating system kernel. For the purpose of estabhshing surrogate servers both approaches are highly suitable in providing HTTP -based web services, usually in combination with database and general storage operations, for example, for media retrieval, transactions, and the like.

[0055] The methods and apparatuses described herein may be used with efforts of the European Telecommunication Standards Institute (ETSI), such as Mobile Edge Computing, or Service Aspects Stage 1 (SAl) discussions of the 3^rd Generation Partnership Project (3GPP). With the advent of Network Function Virtualization (NFV), the methods and apparatuses described herein may be used for the establishment of a surrogate service as a network function. Such surrogate service function may be provided through the operator by pooling in- network computing resources and releasing information that would allow for triggering the establishment of surrogate servers by over-the-top Internet web service providers within the computing resources allocated to the surrogate service function. Such surrogate server establishment would then need to take into account the appropriate SLA between surrogate server provider and surrogate service provider as well as constraints imposed by the underling network.

[0056] One embodiment includes establishing the most appropriate virtu alization technology choice for a surrogate server once the decision for placement, activation and integration into the network fabric has been made. Such an embodiment should take into account a collection of criteria and constraints, which stem from the characteristics and constraints of the service as well as the constraints of the management system for the virtualized resources.

[0057] A system and method that dynamically determines the appropriate visualization approach for a given surrogate service, the latter constrained through SLA, by virtue of a metric -based evaluation along a suitability ontology is described herein.

[0058] FIG. 2 is a message diagram 200 which shows communications between a surrogate server 206 in between a proxy server 204 and a target server 208. An application or browser running on a user's device 202 may send a GET request 210 for a page or object on a target site, for example foo.com. The proxy server may receive the GET request and pass the request 212 on to the surrogate server 206 instead of foo.com. In this way, traffic to foo.com 208 is lowered, assuming the surrogate server 206 may be configured handle and process the GET request. The surrogate server may respond to the proxy server in much the same way as the true destination server might have. The proxy server may then relay the RESPONSE 214 received from the surrogate 206 using RESPONSE 216 sent to the application or browser.

[0059] FIG. 3 shows an overall system 300 and components that may be used to implement the embodiments disclosed herein. With respect to FIG. 3, a web service surrogate 304 may be represented as a collection of software modules. These software modules may include application-specific modules, such as HTML/CSS files, web script files, server plugins and server modules. Additionally, libraries for network and file input/output might be included as well as an operating system (OS). Particularly the inclusion of the latter parts depends on the utilized virtualization technique, for example, VM techniques enable an entire guest OS to run on a virtual machine, while containers subsume much of this OS and library support as part of the virtualization platform, shown as the Virtual Machine Manager (VMM) 306. The VMM 306 may control the choice, for example, whether to choose a hypervisor or container-based technique 302 as well as its specific setup.

[0060] The VMM 306 may implement a VMM controller element 312, acting upon information available in the storage element 308. The storage element 308 may hold the VMM Choice DB 310, in which each row may represent a fully qualified domain name (FQDN) and the metric associated with it, together with a timestamp t for the time of its last calculation. While the web service surrogate 304 of FIG. 3 may realize several FQDNs, a 1: 1 relationship will be assumed in the following description and will specifically point to aspects that may need to be considered with respect to multiple FQDNs per surrogate assignment.

[0061] The following description outlines embodiments for realizing the dynamic virtualization platform in FIG. 3, namely the suitability ontology and the operations utilizing this ontology for instantiating most suitable surrogates in the system of FIG. 3.

[0062] The choice for a suitable virtualization technique may be driven by an ontology that allows for assessing SLAs as well as general service requirements against a suite of suitability criteria. SLAs are a means for which communication level agreements are codified and serve as a protection mechanism for consumers and providers. The organization in an ontology may allow for reasoning regarding the relationships, for example, dependency, importance and the like, of these criteria. [0063] FIG. 4 shows the ontology underpinning 400 the embodiments disclosed herein, including four main categories against which to assess. Exemplary suitability parameters 402 include access characteristics 410, configuration parameters 404, efficiency parameters 432 and isolation parameters 438. Efficiency 432 is a category which may capture key aspects that determine the provisioning of the web service through the surrogate in a timely and scalable manner. For that reason, the category may be divided into the subcategories performance 434 and scalability 436. Performance 434 captures aspects relating to CPU performance, input/output performance, network access performance and other criteria that overall determine the time to completion for individual virtualized platforms. The scalability sub-category 436 may be concerned with scaling the provisioning of a virtualized computing resource, for example, a surrogate server in relation to its underlying host platform. In other words, it may determine the number of virtualized resources that may be established under the given constraints for such resources, for example, the number of specific webservers that may be established on a given host platform.

[0064] Another category for consideration is system isolation 438. When running computing algorithms, applications and services concurrently, aspects of isolation may be important, in particular when the virtualization platform intends to provide the view to the software that it is providing its resources exclusively to this software. Isolation here may be divided into three key subcategories. Fault isolation 440 describes the ability to mitigate any impact of faults in one software on the execution of another. These impacts may vary from processor resources being slowed down through rough processes, memory consumed through faulty algorithms or space in external memory running out due to excessive storage operations. Resource isolation 442 may cover aspects where resources being claimed by one (virtualized) software appear exclusive to the software and cannot be altered, blocked or torn down by another software. It may be important to uphold the exclusivity impression of the virtualization software towards the virtualized software in that claimed resources cannot be influenced by other same-level software running elsewhere on the virtualization platform. Last but not least, security isolation 444 may capture the ability to prevent the intended or unintended leakage of information from one virtuahzed software to another, for example, through memory being read that is part of another process.

[0065] System configuration 404 may also be considered. When providing a virtuahzation platform such as that shown in FIG. 3, several aspects related to configuration may be of importance. In the first sub-category, aspects including determining the image size 412 may be captured. Requirements regarding the needed OS, preloaded storage partitions, and others may be specified as attributes of an image. An image size may specify the primary disk storage occupied by a VM, secondary storage disks, or available volatile memory. The manageability sub-category 418 may be comprised of aspects relating to setup on host machines, for example, in terms of required settings in BIOS or other low- level resource settings, possible requirements stemming from application compatibility or required licenses, as well as aspects of observabihty, for example of the underlying host or the guest system, that might feed into monitoring or other requirements. Manageability also includes aspects of live resizing, in terms of resource requirements for CPUs, memory or storage capabilities, as well as live migration, within the same VMM or across VMMs, of the virtuahzed software. The third sub-category time to readiness 426 may capture aspects that determine the time from initial request for starting the virtualization to the readiness at the level of the desired application functionality. Such aspects may include booting times, startup times for containers, registration times to gain network connectivity, and others.

[0066] Apphcation compatibihty requirements 414, single vs multiple license requirements 416, observabihty 420, live resizing 428 and live migration requirements 430 may additionally be considered. Observability 420 may reflect observability from a host 422 or from a guest 424. [0067] Another category for consideration is access characteristics 410 of a server. In the realm of providing web services, the characteristics driving the access to the web services may be important when deciding upon the right choice for the virtualization platform. In the popularity sub-category 406, the popularity of the FQDN, i.e., the domain of web services being exposed, may be measured as access per time unit, e.g., daily, weekly, per specific day of week or month, or the like. Such popularity may provide insights into the expectation of availability, stemming from the exposure to an audience of users, such expectation in turn influencing the choice of virtualization in terms of availability support, e.g., through fast ramp up of resources, traded off with robustness of existing instances. Another access characteristic sub-category may capture the locality of the access 408. With this locality pattern, mappings may be done first onto available computing resources, for example, at the edge of the network, which in turn may define the choice of virtualization platform. For instance, if considering the utilization of relatively small-scale computing resources in small cell base stations, more weight may need to be given to a virtualization choice that minimizes image sizes as well as CPU/memory requirements, while a conflict with requirements such as in the isolation category may influence the usage of such lightweight virtualization choices and instead may opt for a hypervisor choice being placed at further away, albeit better equipped, network locations.

[0068] The method in which the suitability ontology may be used in conjunction with a metric-based evaluation approach in order to come to suitable choices for virtualization approaches is described herein. These choices being constrained by defined SLAs, requirements, and operational constraints.

[0069] FIG. 5 illustrates a suitability ontology 500 which may be utilized within the operations in the VMM controller 312 of FIG. 3. For this, upon receiving the request to establish a virtualized web service surrogate, here identified through its FQDN, the VMM controller 512 may consult its VMM choice database to retrieve the metric value for said FQDN. If no such metric value exists or if the VMM controller 512 deems the existing value to be outdated based on its provided timestamp ti, the controller may execute a reasoning algorithm 508. The reasoning algorithm 508 takes as input the suitability ontology 504, operational constraints 506, in one embodiment from the network as well as the underlying computing infrastructure in the VMM, and the SLA 510 provided by the web service surrogate. The operational constraints 506 may be used as input for determination of the metric 502. In one example for such SLA 510, a financing service may express its strong requirement for a security isolation as well as a fault isolation, aiming at the security of the transaction, the former requirement, and the reliability of the transaction, the latter requirement. In this example, the reasoning algorithm may be likely to express its metric in favor of choosing other virtualization techniques, providing the necessary isolation features that would satisfy the SLA.

[0070] The metric indicated in the storage element 512 may indicate an instantiation of a surrogate 514. In one case, for a particular web service surrogate 516 or 520, a corresponding VM 518 or container 522 may be selected 524.

[0071] In an example, a local augmented reality gaming scenario may be considered. Here, the performance and scalability aspects, captured in the efficiency branch of the ontology shown in FIG. 4, may be likely expressed as a strong requirement in the service provider's SLA. In addition, live migration, as part of the manageability branch as shown in FIG. 4, may likely be important to provide a superior quality of experience to gamers by having surrogate servers move about in the network topology in an attempt to keep the experienced latency low. In addition, the operator constraint of minimizing the image sizes, as part of the configuration branch in FIG. 4, emphasizes the constraint to keep the consumed bandwidth for such live migration low. Given such requirements and constraints, the reasoning algorithm may likely be to express its metric in favor of choosing a process virtualization technique.

[0072] In one embodiment for the metric, which may be used for the decision making in choosing the right virtualization technique, a tuple v is chosen. Said tuple contains as elements a choice entry c, which expresses, for example, in the form of an integer value, the virtualization technique being used as an enumeration of agreed values, said values being defined by the virtualization techniques being supported by the surrogate service provider. Examples for this value may include, but are not limited to, a binary choice, and may be represented by a 0 or 1. Alternatively, or in combination, an integer/decimal based system may be employed using a floating point representation. The integer to the left of the decimal point of a floating point representation may represent a virtualization technique, while the portion of the floating point representation to the right of the decimal point may represent configuration settings for a virtual machine platform. The second entry configuration (conf) may describe the constraints used for setting up the specific virtualization choices, the latter expressed by entry c. In one embodiment, such description may be based on an Extensible Markup Language (XML) or Resource Description Framework (RDF) format, outlining main parameters for configuration of the virtualized resource. Said parameters may be determined as part of the reasoning algorithm, taking into account the SLA and operator constraints. Examples for such parameters may be image size, memory size, number of (virtual and physical) processors allocated, network device configuration and others. In a binary example, one might choose between the Kernel Based Virtual Machine (KVM) platform and Docker platform. KVM is a virtual machine platform for the linux kernel, which turns the linux kernel into a hypervisor. The KVM hypervisor may then be used to create and run virtual machine. In contrast the Docker platform automates deployment of applications inside containers. Docker containers may wrap up software into a complete filesystem. A decision making engine configured to determine between KVM or Docker is an example of a relatively simple rules based engine.

[0073] In one embodiment, the reasoning algorithm may be executed as an ontology-based reasoning engine that utilizes a resource description framework (RDF) or web ontology language (OWL) encoding of the ontology shown in FIG. 4 and performs the encoded reasoning rules with available reasoning engines. RDF is a general method for modeling information which typically takes on the form of a plurality of subject-predicate-object expressions. A subject may represent a particular resource. A predicate may contain information about the subject and may specify a relationship between the subject and the object. OWL is similar to RDL and allows a user to supply more context within a data model. OWL allows data to be described in terms of a set of operations, allows defined equivalences across databases and allows property values to be restricted.

[0074] In another embodiment, the reasoning algorithm may be realized through a category-based reasoning engine, where the categories represent cases in a case-based engine. A case based reasoning engine may attempt to solve new problems based on methods and solutions which were chosen for similar past problems. A case based reasoning engine may involve a four step process: retrieve, reuse, revise and retain. First, an engine may retrieve prior case information stored for similar problems. Next the engine may reuse the prior case information to propose a solution for the new problem. The revise stage involves determining if a repair is necessary and implementing a repair strategy. Lastly, the new problem and it's solution should be recursively retained in memory.

[0075] The outcome of the reasoning algorithm may be that of a numerical value representing a metric for choice between various virtu alization techniques. In one embodiment, where a choice between two possible candidate technologies may be the outcome, this metric may be structured as a integer value with a defined threshold, above which one technology choice may be utilized compared to the choice of the other technology in cases of values below said threshold. In this embodiment, the reasoning algorithm, executed on the left side of FIG. 5, may focus its suitability determination on various characteristics according to the suitability ontology.

[0076] FIG. 6 shows a table 600 with three columns including FQDN 602, metric 604 and timestamp (t) 606. The table contains exemplary FQDNs 608- 618, a numeric metric expressed as an integer and a timestamp in each cell. In this case, the stored metric takes the form of a range between 0 and 9. If the metric is in the lower half of the range, [0-4], the corresponding FQDN should be instantiated using one VMM choice. If the metric is in the upper half of the range, [5-9], the corresponding FQDN should be instantiated using a different VMM choice. The timestamp 606 column of FIG. 6 illustrates the use of an EPOCH (or Unix style) timestamp. A Unix style timestamp is structured as a number of seconds that have elapsed since January 1, 1970.

[0077] Another embodiment may be structured as a set of choices, where an interval-based metric may be used for decision between the choices. Alternatively, the metric may be structured using a color scheme where each color represents a technology choice and the choice preference may be expressed through transparency levels for each color. In this case, the instantiation decision may be based upon the least transparent choice, as expressed through the metric value.

[0078] FIG. 7 illustrates an exemplary color scheme embodiment 700.

Referring to FIG. 7, three colors are shown to indicate one of three selectable virtu alization platforms. In this example, the colors chosen are red 702, green 704 and blue 706. For each color, an opacity or transparency level 708-718 for red, 720-730 for green and 732-742 for blue may be indicated to reflect a technology choice preference.

[0079] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not hmited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

^• * *

Claims

CLAIMS What is claimed is:

1. A surrogate server for mirroring functionality of another server, the surrogate server comprising:

a transceiver for receiving an activation request corresponding to a fully qualified domain name (FQDN);

a data storage device for storing a metric; and

circuitry configured to determine, based on the stored metric, a visualization platform for the FQDN and to instantiate, based on the determined visualization platform, a virtual server;

wherein the transceiver is configured to receive one or more requests for content stored on the virtual server and transmit, in response to the received one or more requests for content, a response corresponding to the requested content.

2. The surrogate server of claim 1, wherein the data storage device of the surrogate server stores one or more of: hypertext markup language (HTML) and cascading style sheet (CSS) files, web script files, server plugins and server modules.

3. The surrogate server of claim 1, wherein the circuitry configured to determine the virtu alization platform for the FQDN includes circuitry configured to determine whether a hypervisor-based or a container-based technique should be used.

4. The surrogate server of claim 1, wherein the circuitry configured to determine the virtualization platform includes circuitry configured to determine at least one of a primary or secondary image size, requirements regarding a needed operating system or a configuration of preloaded storage partitions.

5. The surrogate server of claim 3, wherein the stored metric is a boolean metric.

6. The surrogate server of claim 1, wherein the stored metric is an integer metric corresponding to a defined threshold.

7. The surrogate server of claim 6, wherein:

on a condition the integer metric is above the defined threshold, the determined virtualization platform for the FQDN corresponds to a first virtualization platform; and

on a condition the integer metric is below the defined threshold, the determined virtualization platform for the FQDN corresponds to a second virtualization platform;

wherein the first virtualization platform and second virtualization platform are different types of virtu alization platforms.

8. A method for instantiating and operating a surrogate server which mirrors functionality of another server, the method comprising:

receiving an activation request corresponding to a fully qualified domain name (FQDN);

determining, based on a stored metric, a virtualization platform for the FQDN;

instantiating, based on the determined virtualization platform, a virtual server;

receiving one or more requests for content stored on the virtual server; and transmitting, in response to the received one or more requests for content, a response corresponding to the requested content.

9. The method of claim 8, wherein the surrogate stores one or more of: hypertext markup language (HTML) and cascading style sheet (CSS) files, web script files, server plugins and server modules.

10. The method of claim 8, wherein determining the virtu alization platform for the FQDN includes determining whether a hypervisor-based or a container-based technique should be used.

11. The method of claim 8, wherein determining a virtu alization approach includes determining at least one of a primary or secondary image size, requirements regarding a needed operating system or a configuration of preloaded storage partitions.

12. The method of claim 10, wherein the stored metric is a boolean metric.

13. The method of claim 8, wherein the stored metric is an integer metric corresponding to a defined threshold.

14. The method of claim 13, wherein:

on a condition the integer metric is above the defined threshold, the determined virtu alization platform for the FQDN corresponds to a first virtu alization platform; and

on a condition the integer metric is below the defined threshold, the determined virtu alization platform for the FQDN corresponds to a second visualization platform;

wherein the first virtualization platform and second virtu alization platform are different types of virtu alization platforms.

15. A surrogate server for mirroring functionality of another server, the surrogate server comprising:

a data storage device for storing a color scheme data structure, wherein the color scheme data structure includes a color value and a transparency level associated with the color value;

circuitry configured to determine, based on the color value of the color scheme data structure, a virtualization platform for the FQDN;

circuitry configured to determine, based on the transparency level of the color scheme data structure, one or more configuration settings for the determined virtualization platform for the FQDN; and

circuitry configured to instantiate, based on the determined virtualization platform, a virtual server;

16. The surrogate server of claim 15, wherein the data storage device of the surrogate server stores one or more of: hypertext markup language (HTML) and cascading style sheet (CSS) files, web script files, server plugins and server modules.

17. The surrogate server of claim 15, wherein the circuitry configured to determine the virtualization platform for the FQDN includes circuitry configured to determine whether a hypervisor-based or a container-based technique should be used.

18. The surrogate server of claim 15, wherein the circuitry configured to determine the virtualization platform configuration settings includes circuitry configured to determine at least one of a primary or secondary image size, requirements regarding a needed operating system or a configuration of preloaded storage partitions.

19. The surrogate server of claim 15, wherein the color value of the color scheme data structure corresponds to hypertext markup language (HTML) color values.

20. The surrogate server of claim 15, wherein the circuitry configured to determine the virtual machine platform is configured to determine the virtual machine platform based on a timestamp value.