Overview
This chapter describes how application suites and LIBlets are provisioned if an implementation chooses OTA (Over the Air) Provisioning as an implementation of the Provisioning algorithm as generally described here.
Device owner provisioning. Use one of the following methods to set up device owner (DO) provisioning. Provisioning via NFC. DO provisioning via NFC is similar to the profile owner method but requires more bootstrapping. To use this method, NFC bump the device during the initial setup step (i.e., first page of the setup wizard). This low-touch. Stage 2 and Stage 3 specifications for over-the-air (OTA) provisioning and activation. Package #2: Provisioning Mgmt Actions.
As emphasized in the Provisioning chapter, there MUST be only one provisioning mechanism in a concrete implementation and it must remain unchanged. For OTA provisioning this means that, if OTA provisioning is implemented in a certain implementation, there MUST NOT be any other way to install, update or delete application suites and LIBlets in this implementation.
All statements made in the Provisioning chapter are also valid here. The following statements have to be additionally considered if an OTA Provisioning implementation is chosen.
Installation Mechanisms
The default installation mechanism for OTA provisioning as defined in the IMP-NG specification is the one via HTTP/HTTPS protocol. This installation mechanism is likely to be the most popular one for OTA Provisioning in MEEP 8 as well (chosing HTTP or HTTPS, whatever the respective MEEP 8 implementation supports).
On the other hand, other installation mechanisms (e.g. Bluetooth TM wireless technology, serial cable, IrDA TM, etc.) are mentioned to be possibly supported by devices, but stated as outside the scope of this specification. Here, we will speak of all these as 'external triggers' to initiate OTA User Provisioning. Also 'internal triggers' such as Timer events or requests from running Java applications are solutions one can think of.
Functional Requirements for OTA Provisioning
An OTA provisioning compliant device MUST be capable of:
- Browsing, or otherwise locating application suite and LIBlet Application Descriptors in the network.
- Downloading an application suite or LIBlet and its associated Application Descriptor to the device from a server using a protocol supported for OTA provisioning by the device's implementation (which could be HTTP 1.1 or later or HTTPS or both).
- Installing the application suite or LIBlet on the device
- Invoking Applications
Application Suite and LIBlet Lifecycle
Discovery
Everything stated in the Discovery section of the Provisioning chapter applies, and in addition the following OTA Provisioning specific requirements MUST be fulfilled:
- The provisioning server can request that a full client device profile be sent to the server with the request for the Application Descriptor.
- If the Application Descriptor is not available, or after the AMS has transferred the Application Descriptor and determined that installation should continue, the application suite or LIBlet JAR transfer begins.
- If the application suite or LIBlet depends on one or more LIBlets, the Application Descriptors for all dependency LIBlets are transferred prior to the application suite or to-be-installed LIBlet JAR transfer. The decision on whether to proceed with the application suite or LIBlet JAR transfer (and subsequent installation) depends on the verification of the JAD and JAR of both the application suite or LIBlet and dependency LIBlets.
OTA Application Suite Provisioning
As mentioned before, the mechanism of discovery (if supported) is out of scope of this specification. If the location of an application suite or LIBlet refers to a JAR as described in the application specification, the JAR and its URL are passed to the AMS on the device to start the installation process. If the link refers to an Application Descriptor, as described in the this specification, the following steps are performed:
- Once the application suite or LIBlet has been located, the server MUST indicate in the response that the data being transferred (i.e., the Application Descriptor) has a MIME type of
text/vnd.sun.j2me.app-descriptor
. - After completing this transfer, the Application Descriptor and its URL are passed to the AMS on the device to start the installation process. The Application Descriptor is used by the AMS to determine if the associated application suite or LIBlet can be successfully installed and executed on the device. This may involve transfer of Application Descriptors of any LIBlets the application suite or LIBlet depends on, if any LIBlet dependencies are specified by the application suite or LIBlet.
- If Application Descriptor is delivered in a transport format that is not the Unicode encoding that is specified by the specification it MUST be converted before it can be used. The default character set specified for the MIME type
text/vnd.sun.j2me.app-descriptor
isUTF-8
. If the device supports other character sets, the appropriateAccept-Charset
header SHOULD be included in the request, and the content MUST be converted based on the charset attribute returned on theContent-Type
header. If charset is undefined, the encoding defaults toUTF-8
, and it MUST be converted accordingly. It is expected that an implementation is able to recognize and convert the transport format used, otherwise the installation MUST fail.The attributes in the Application Descriptor MUST be formatted according to the syntax defined in Application Attributes; otherwise the provisioning MUST fail. All of the application attributes designated as mandatory by Appendix A MUST be present in the Application Descriptor; if this is not the case, the provisioning MUST fail. If the Application Descriptor contains any application attributes that are allowed only in the Jar manifest (see Appendix A), then the provisioning MUST fail.
Installation of Application Suites and LIBlets
To install an application suite or LIBlet, the AMS performs the following series of steps and checks and MAY provide the user with feedback about the progress:
- The device initiates the download of the application suite or LIBlet. Every download of an application descriptor by the AMS for installation or update MUST supply the headers needed by UAProf for Device Identification. If an Application Descriptor was first downloaded as described in the Discovery section either without the UAProf headers or if it is unknown whether the headers were sent and the descriptor includes the
MIDlet-Profile-Request: true
attribute then the download of the descriptor must be repeated using the URL of the descriptor and including the headers required by UAProf. The new descriptor supersedes the original descriptor in the processing that follows. The requests for downloading descriptors and JARs in the application suite or LIBlet MUST be for exactly the URL specified in the descriptor; additional headers are unnecessary. - If the server or proxy responds to the request for the application suite with a 401 (Unauthorized) or 407 (Proxy Authentication Required), the device MAY re-send the request with the appropriate credentials in an Authorization or Proxy-Authorization header field as specified in [RFC2617]. The device MUST be able to support at least the Basic Authentication Scheme as described in [RFC2617].
- If the OTA takes place via IP, and
MIDlet-Required-IP-Version
attribute is specified, and that IP version is not supported by the implementation, the installation MUST fail (see Status Codes for Status Reporting).In case the OTA does not take place via IP, theMIDlet-Required-IP-Version
attribute, if specified, is ignored with respect to OTA. - If the JAR is not available at the
MIDlet-Jar-URL
orLIBlet-Jar-URL
attribute in the descriptor, the installation MUST fail. Similarly, if a dependency LIBlet is not already installed on the device and the JAR is not available at theLIBlet-Jar-URL
, the installation of the dependent application suite or LIBlet MUST fail (see Status Codes for Status Reporting).
Automatic Application Update
If the provisioned application suite has the
MIDlet-Update-URL
attribute in the JAD file or the JAR manifest, the implementation MUST use it to configure the automatic update feature. The value of this attribute MUST either be empty or contain a valid URL. For details, see the description of the MIDlet-Update-URL
attribute in Application Attributes. Application Suite and LIBlet Update
If RMS is supported by the implementation, the handling of RMS record stores of an untrusted application suite or LIBlet when being updated is the following:
- If the scheme, host, and path of the URL that the new Application Descriptor is transferred from is identical to the scheme, host, and path of the URL the original Application Descriptor was transferred from, then the RMS MUST be retained and made available to the new application suite or LIBlet.
- If the scheme, host, and path of the URL that the new application suite or LIBlet is transferred from is identical to the scheme, host, and path of the URL the original application suite or LIBlet was transferred from, then the RMS MUST be retained and made available to the new application suite or LIBlet.
- If none of the conditions above are met, then the device MUST use a predefined policy to decide whether the data from the original application suite or LIBlet should be retained and made available to the new application suite or LIBlet.
Status Reports
The operation status is reported by means of an HTTP POST request to the relevant URL specified. The server is expected to respond with a valid HTTP response. For an example of a status report, see Example: Install Status via HTTP Post Request. Status reports are only sent for application suites or LIBlets downloaded Over The Air (OTA).
The body of the POST request MUST include a status code and status message on its first line. See Provisioning Status Codes and Messages for a list of valid status codes and suggested status messages. The messages are informational only.
The implementation MUST transcode the request body into UTF-8, and MUST set the
Content-Type
entity-header field of the request as follows: If the server receives the status report successfully, it MUST reply with a 2xx response code (typically 200 OK) and SHOULD NOT include a message body. Any content in the message body MUST be ignored by the implementation.
Since the body of the status report is short and simple, the implementation SHOULD NOT set the
Expect: 100-continue
header in the request, and MAY ignore any 100 Continue response sent by the server. For other typical server responses, the implementation MUST maintain a retry count and attempt to retry the sending of the report as follows:
- If the server response is 301 Moved Permanently, 302 Found, 303 See Other or 307 Temporary Redirect, retry the request using the URI supplied in the response.
- If the server response is 4xx, retry. The request SHOULD be examined for errors though before retrying.
- If the server response is 5xx, defer the retrying by an implementation-defined amount of time.
Device Identification and Request Headers
The process of discovering an application suite or LIBlet via the DA can be customized by the device sending information about itself to the server. The DA MAY provide the network server with information (e.g. the manufacturer and device model number) so that the server can determine the device's capabilities. In many cases, a DA will already have identified the device type to the server by means consistent with its network connection and markup language.
During the download of an application suite or LIBlet, a device SHOULD identify its characteristics and the type of the content being requested as completely as possible to the server. The HTTP request headers used to fetch the content MUST include User-Agent, Accept-Language, and Accept. Servers SHOULD use this additional information to select the appropriate Application Descriptor for the device.
UAProf for Device Identification
Provisioning servers require detailed information about the configuration of the device hardware, software, and installed middleware. However, the Discovery Agent, is not expected to provide detailed information because it does not have access to the detailed configuration of the Java Runtime.
The Open Mobile Alliance (OMA) has developed the UAProf Specification to communicate device and software configuration. See OMA User Agent Profile V2.0 for detailed specifications and schemas. UAProf is based on the Composite Capability/preference Profiles (CC/PP). The configuration schemas are extensible and the processing of profile instances is defined to allow static and difference profile instances to be merged to yield a complete description. The static configuration information is presented to the network using the URL of a profile that describes the device including hardware details and the software provisioned with the device. The client device can supply both the URL of a profile (by reference) and a difference profile (by value in a XML stream) in http headers using the UAProf specification.
The difference profile includes information that has changed relative to the static configuration due to installation of software, changes in the SIM card, etc.
The UAProf specification defines the additional HTTP headers required to deliver configuration information to the server. The headers include x-wap-profile, and x-wap-profile-diff headers. These HTTP Request Headers MUST be supplied on the initial request by the AMS to retrieve a JAD.
MIDP Configuration Profile for UAProf
The predefined configuration schema is not adequate to describe the features of the runtime and the optional packages and shared libraries. The additional schema defined below addresses configuration of the Execution environment. The MIDP Configuration Profile builds on the established mobile profile. The specific RDF schema elements are defined below and are used incrementally as extensions to the existing schema.
The RDF elements are described Table 3-4 below.
Table 3-4 : MIDP RDF Elements | ||
---|---|---|
RDF Element | Domain of Element | Description |
MIDSharedLibrary | MIDProfile | A MIDP Shared Library property contains values for Name, Vendor, Version and JAR hash. The LIBlet Name, Vendor and Version are defined by LIBlet attributes. |
Client | MIDProfile | Client provides values to describe the Client's name, certificate subject and certificate hash (Base64 encoded) for each Client. |
Certificate | MIDProfile | For each certificate used for application authentication, the subject name as the key and the hash of the public key (Base64 encoded). |
SystemProperty | MIDProfile | An RDF Bag containing, for each system property the name and the value. |
PushProtocols | MIDProfile | An RDF Bag containing each of protocols supported for Push. |
The RDF schema for the IMP / MEEP specific elements is:
A partial example might look like:
User-Agent Product Tokens
The specification identifies HTTP User-Agent request headers to identify the client to the server. [RFC2616] specifies a format for product tokens such as:
'User-Agent' ':' 1*(product | comment)
The product tokens used to identify the device as supporting the underlying configuration (e.g. CLDC-8) and the used profile (e.g. MEEP-8.0) are specified the CLDC 8 specification. As in [RFC2616], the comment field is optional.
In addition, the device SHOULD further identify itself by adding a device-specific product token to the User-Agent header as defined by [RFC2616]. The device-identifying token SHOULD be the first token. The product-token and product-version values are specific to each device and are outside of the scope of this specification.
Accept-Language Header
The device MAY supply the Accept-Language request header as specified in [RFC2616] to indicate the language that is in use on the device.
Accept Header
The Accept HTTP header is used to indicate the type of content being requested. When requesting application suites, this header SHOULD include application/java-archive. For retrieving application descriptors, this header SHOULD include text/vnd.sun.j2me.app-descriptor.
Example: HTTP Request for Application Descriptor
When requesting the download of an Application Descriptor, the request headers might look as follows:
The response headers from the server might look as follows:
Example: HTTP Request to Install/Update an Application Suite
When requesting the download of an application suite JAR, the request headers might look as follows:
The response headers from the server might look as follows:
Example: Install Status via HTTP Post Request
For example, installing an application suite with an application descriptor given below:
After a successful install of the application suite, the following would be posted:
The response from the server might be:
Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
In telecommunication, provisioning involves the process of preparing and equipping a network to allow it to provide new services to its users. In National Security/Emergency Preparedness telecommunications services, 'provisioning' equates to 'initiation' and includes altering the state of an existing priority service or capability.[1]
The concept of network provisioning or service mediation, mostly used in the telecommunication industry, refers to the provisioning of the customer's services to the network elements.[clarification needed] It requires the existence of networking equipment and depends on network planning and design.
In a modern signal infrastructure employing information technology (IT) at all levels, there is no possible distinction between telecommunications services and 'higher level' infrastructure.[citation needed] Accordingly, provisioning configures any required systems, provides users with access to data and technology resources, and refers to all enterprise-level information-resource management involved.
Organizationally, a CIO typically manages provisioning, necessarily involving human resources and IT departments cooperating to:
- Give users access to data repositories or grant authorization to systems, network applications and databases based on a unique user identity.
- Appropriate for their use hardware resources, such as computers, mobile phones and pagers.
As its core, the provisioning process monitors access rights and privileges to ensure the security of an enterprise's resources and user privacy. As a secondary responsibility, it ensures compliance and minimizes the vulnerability of systems to penetration and abuse. As a tertiary responsibility, it tries to reduce the amount of custom configuration using boot image control and other methods that radically reduce the number of different configurations involved.
Discussion of provisioning often appears in the context of virtualization, orchestration, utility computing, cloud computing, and open-configuration concepts and projects. For instance, the OASIS Provisioning Services Technical Committee (PSTC) defines an XML-based framework for exchanging user, resource, and service-provisioning information - SPML (Service Provisioning Markup Language) for 'managing the provisioning and allocation of identity information and system resources within and between organizations'.[citation needed]
Once provisioning has taken place, the process of SysOpping ensures the maintenance of services to the expected standards. Provisioning thus refers only to the setup or startup part of the service operation, and SysOpping to the ongoing support.
Network provisioning[edit]
One type of provisioning.The services which are assigned to the customer in the customer relationship management (CRM) have to be provisioned on the network element which is enabling the service and allows the customer to actually use the service. The relation between a service configured in the CRM and a service on the network elements is not necessarily a one-to-one relationship; for example, services like Microsoft Media Server (mms://) can be enabled by more than one network element.
During the provisioning, the service mediation device translates the service and the corresponding parameters of the service to one or more services/parameters on the network elements involved. The algorithm used to translate a system service into network services is called provisioning logic.
Electronic invoice feeds from your carriers can be automatically downloaded directly into the core of the telecom expense management (TEM) software and it will immediately conduct an audit of each single line item charge all the way down to the User Support and Operations Center (USOC) level. The provisioning software will capture each circuit number provided by all of your carriers and if bills outside of the contracted rate an exception rule will trigger a red flag and notify the pre-established staff member to review the billing error.
Server provisioning[edit]
Server provisioning is a set of actions to prepare a server with appropriate systems, data and software, and make it ready for network operation. Typical tasks when provisioning a server are: select a server from a pool of available servers, load the appropriate software (operating system, device drivers, middleware, and applications), appropriately customize and configure the system and the software to create or change a boot image for this server, and then change its parameters, such as IP address, IP Gateway to find associated network and storage resources (sometimes separated as resource provisioning) to audit the system. By auditing the system, you ensure OVAL compliance with limit vulnerability, ensure compliance, or install patches. After these actions, you restart the system and load the new software. This makes the system ready for operation. Typically an internet service provider (ISP) or Network Operations Center will perform these tasks to a well-defined set of parameters, for example, a boot image that the organization has approved and which uses software it has license to. Many instances of such a boot image create a virtualdedicated host.
There are many software products available to automate the provisioning of servers, services and end-user devices. Examples: BMC Bladelogic Server Automation, HP Server Automation, IBM Tivoli Provisioning Manager, Redhat Kickstart, xCAT, HP Insight CMU, etc. Middleware and applications can be installed either when the operating system is installed or afterwards by using an Application Service Automation tool. Further questions are addressed in academia such as when provisioning should be issued and how many servers are needed in multi-tier,[2] or multi-service applications.[3]
In cloud computing, servers may be provisioned via a web user interface or an application programming interface (API). One of the unique things about cloud computing is how rapidly and easily this can be done. Monitoring software can be used to trigger automatic provisioning when existing resources become too heavily stressed.[4]
In short, server provisioning configures servers based on resource requirements. The use of a hardware or software component (e.g. single/dual processor, RAM, HDD, RAIDcontroller, a number of LAN cards, applications, OS, etc.) depends on the functionality of the server, such as ISP, virtualization, NOS, or voice processing. Server redundancy depends on the availability of servers in the organization. Critical applications have less downtime when using cluster servers, RAID, or a mirroring system.
Service used by most larger-scale centers in part to avoid this. Additional resource provisioning may be done per service.[5]
There are several software on the market for server provisioning such as Cobbler or HP Intelligent Provisioning.
User provisioning[edit]
User provisioning refers to the creation, maintenance and deactivation of user objects and user attributes, as they exist in one or more systems, directories or applications, in response to automated or interactive business processes. User provisioning software may include one or more of the following processes: change propagation, self-service workflow, consolidated user administration, delegated user administration, and federated change control. User objects may represent employees, contractors, vendors, partners, customers or other recipients of a service. Services may include electronic mail, inclusion in a published user directory, access to a database, access to a network or mainframe, etc. User provisioning is a type of identity management software, particularly useful within organizations, where users may be represented by multiple objects on multiple systems and multiple instances.
Self-service provisioning for cloud computing services[edit]
On-demand self-service is described by the National Institute of Standards and Technology (NIST) as an essential characteristic of cloud computing.[6] The self-service nature of cloud computing lets end users obtain and remove cloud services―including applications, the infrastructure supporting the applications,[7] and configuration―[8] themselves without requiring the assistance of an IT staff member.[9] The automatic self-servicing may target different application goals and constraints (e.g. deadlines and cost),[10][11] as well as handling different application architectures (e.g., bags-of-tasks and workflows).[12] Cloud users can obtain cloud services through a cloud service catalog or a self-service portal.[13] Because business users can obtain and configure cloud services themselves, this means IT staff can be more productive and gives them more time to manage cloud infrastructures.[14]
One downside of cloud service provisioning is that it is not instantaneous. A cloud virtual machine (VM) can be acquired at any time by the user, but it may take up to several minutes for the acquired VM to be ready to use. The VM startup time is dependent on factors, such as image size, VM type, data center location, and number of VMs.[15] Cloud providers have different VM startup performance.
Mobile subscriber provisioning[edit]
Mobile subscriber provisioning refers to the setting up of new services, such as GPRS, MMS and Instant Messaging for an existing subscriber of a mobile phone network, and any gateways to standard Internet chat or mail services. The network operator typically sends these settings to the subscriber's handset using SMS text services or HTML, and less commonly WAP, depending on what the mobile operating systems can accept.
A general example of provisioning is with data services. A mobile user who is using his or her device for voice calling may wish to switch to data services in order to read emails or browse the Internet. The mobile device's services are 'provisioned' and thus the user is able to stay connected through push emails and other features of smartphone services.
Device management systems can benefit end-users by incorporating plug-and-play data services, supporting whatever device the end-user is using.[citation needed]. Such a platform can automatically detect devices in the network, sending them settings for immediate and continued usability.[citation needed] The process is fully automated, keeping the history of used devices and sending settings only to subscriber devices which were not previously set. One method of managing mobile updates is to filter IMEI/IMSI pairs.[citation needed] Some operators report activity of 50 over-the-air settings update files per second.[citation needed]
Mobile content provisioning[edit]
This refers to delivering mobile content, such as mobile internet to a mobile phone, agnostic of the features of said device. These may include operating system type and versions, Java version, browser version, screen form factors, audio capabilities, language settings and many other characteristics. As of April 2006, an estimated 5,000 permutations were relevant. Mobile content provisioning facilitates a common user experience, though delivered on widely different handsets.
Internet access provisioning[edit]
When getting a customer online, the client system must be configured. Depending on the connection technology (e.g., DSL, Cable, Fibre), the client system configuration may include:
- Modem configuration
- Network authentication
- Installing drivers
- Setting up Wireless LAN
- Securing operating system (primarily for Windows)
- Configuring browser provider-specifics
- E-mail provisioning (create mailboxes and aliases)
- E-mail configuration in client systems
- Installing additional support software or add-on packages
There are four approaches to provisioning internet access:
- Hand out manuals: Manuals are a great help for experienced users, but inexperienced users will need to call the support hotline several times until all internet services are accessible. Every unintended change in the configuration, by user mistake or due to a software error, results in additional calls.
- On-site setup by a technician: Sending a technician on-site is the most reliable approach from the provider’s point of view, as the person ensures that the internet access is working, before leaving the customer’s premises. This advantage comes at high costs – either for the provider or the customer, depending on the business model. Furthermore, it is inconvenient for customers, as they have to wait until they get an installation appointment and because they need to take a day off from work. For repairing an internet connection on-site or phone support will be needed again.
- Server-side remote setup: Server-side modem configuration uses a protocol called TR-069. It is widely established and reliable. At the current stage it can only be used for modem configuration. Protocol extensions are discussed, but not yet practically implemented, particularly because most client devices and applications do not support them yet. All other steps of the provisioning process are left to the user, typically causing lots of rather long calls to the support hotline.
- Installation CD: Also called a 'client-side self-service installation' CD, it can cover the entire process from modem configuration to setting up client applications, including home networking devices. The software typically acts autonomously, i.e., it doesn’t need an online connection and an expensive backend infrastructure. During such an installation process the software usually also install diagnosis and self-repair applications that support customers in case of problems, avoiding costly hotline calls. Such client-side applications also open completely new possibilities for marketing, cross- and upselling. Such solutions come from highly specialised companies or directly from the provider’s development department.
See also[edit]
References[edit]
- ^ This article incorporates public domain material from the General Services Administration document 'Federal Standard 1037C'.
- ^Urgaonkar, Bhuvan; Shenoy, Prashant; Chandra, Abhishek; Goyal, Pawan; Wood, Timothy (2008). 'Agile dynamic provisioning of multi-tier Internet applications'. ACM Transactions on Autonomous and Adaptive Systems. 3: 1–39. CiteSeerX10.1.1.294.6606. doi:10.1145/1342171.1342172.
- ^Jiang Dejun, Guillaume Pierre and Chi-Hung Chi. Autonomous Resource Provisioning for Multi-Service Web Applications. In Proceedings of the 19th International World-Wide Web conference, April 2010.
- ^Amies A, Sanchez J, Vernier D, and Zheng X D, 2011. 'Monitor services in the cloud', IBM developerWorks, February 15.
- ^He, Sijin; L. Guo; Y. Guo; M. Ghanem (2012). 'Improving Resource Utilisation in the Cloud Environment Using Multivariate Probabilistic Models'. 2012 IEEE Fifth International Conference on Cloud Computing. 2012 2012 IEEE 5th International Conference on Cloud Computing (CLOUD). pp. 574–581. doi:10.1109/CLOUD.2012.66. ISBN978-1-4673-2892-0.
- ^Mell, Peter; Grance, Timothy. 'The NIST definition of cloud computing', Special Publication 800-145, National Institute of Standards and Technology
- ^He, Sijin; L. Guo; Y. Guo; C. Wu; M. Ghanem; R. Han (2012). 'Elastic Application Container: A Lightweight Approach for Cloud Resource Provisioning'. 2012 IEEE 26th International Conference on Advanced Information Networking and Applications. 2012 IEEE 26th International Conference on Advanced Information Networking and Applications (AINA). pp. 15–22. doi:10.1109/AINA.2012.74. ISBN978-1-4673-0714-7.
- ^Perera, David. 'The real obstacle to federal cloud computing', Fierce Government IT, July 12, 2012
- ^MSV, Janakiram. 'Top 10 reasons why startups should consider cloud'. Cloud Story, July 20, 2012
- ^Mao, Ming; M. Humphrey (2011). Auto-scaling to minimize cost and meet application deadlines in cloud workflows. Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and Analysis (SC2011). doi:10.1145/2063384.2063449. ISBN978-1-4503-0771-0.
- ^Mao, Ming; M. Humphrey (2013). Scaling and Scheduling to Maximize Application Performance within Budget Constraints in Cloud Workflows. Proceedings of the 2013 IEEE 27th International Symposium on Parallel and Distributed Processing(IPDPS2013). pp. 67–78. doi:10.1109/IPDPS.2013.61. ISBN978-0-7695-4971-2.
- ^Mao, Ming; J. Li; M. Humphrey (2010). 2010 11th IEEE/ACM International Conference on Grid Computing (Grid2010). pp. 41–48. CiteSeerX10.1.1.467.5771. doi:10.1109/GRID.2010.5697966. ISBN978-1-4244-9347-0.
- ^Onisick, Joe. 'Five steps to building a private cloud', Network Computing, July 23, 2012
- ^Cowie, Jason. 'How to make private cloud initiatives matter to your CEO', The Data Center Journal, July 17, 2012
- ^Mao, Ming; M. Humphrey (2012). A Performance Study on the VM Startup Time in the Cloud. Proceedings of 2012 IEEE 5th International Conference on Cloud Computing (Cloud2012). p. 423. doi:10.1109/CLOUD.2012.103. ISBN978-1-4673-2892-0.
External links[edit]
- Customer provisioning at Curlie
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Provisioning_(telecommunications)&oldid=923561944'