SCOMO: Enabling the Remote Lifecycle Management of Software Components

The Open Mobile Alliance's (OMA) Software Component Management Object Version 1.0 (SCOMO V1.0) is the name of the service enabler that allows a management authority to remotely deliver and manage individual software components on connected devices. The end result enables the remote lifecycle management of individual software components.

Red Bend Software's vRapid Mobile™ offers unmatched capabilities to enhance and customize the growing software assets of mobile devices. vRapid Mobile, which supports SCOMO, is the first comprehensive solution to give the mobile value chain complete flexibility and control over updating, adding, changing and removing any software component on any feature phone or smartphone at any point during the device lifetime.

Red Bend's vDirect Mobile™ is the industry's only independent device management (DM) client that is interoperable with any DM server supporting the standards from the OMA. Supporting SCOMO V1.0, vDirect Mobile makes it easier for device manufacturers to quickly integrate device management functionality into the mobile device, thereby improving time to market.

The SCOMO specification describes the management object employed in a software component management process that leverages the OMA Device Management protocol. SCOMO provides a standard DM management object and associated client and server side behavior necessary to manage devices' individual software components.

Management objects are interfaces that are exposed to a management authority, through which it can exert its control using the OMA DM protocol. The collection of management objects are kept in an abstraction of nodes in a tree structure (known as the Management Tree). The OMA DM protocol is neutral about the contents or values of the nodes as opaque data.

Firmware over-the-air (FOTA) updating, which is based on OMA's Firmware Update Management Object (FUMO) standard, is used to manage the firmware of a device. SCOMO, on the other hand, is designed to manage any other type of software resource that is not firmware. While FOTA focuses on updating a single monolithic image, managing software components over the air (SCOTA) is about individual software assets. Examples of software components are mobile applications, middleware, executables, libraries, UI elements, browser plug-ins, certificates, licenses, etc.

To improve the user experience by delivering new features and new services for handsets already in users' hands, the management authority can perform everything from updating a messaging client that will add a new push e-mail function to adding a new audio codec to support richer music downloads.

The SCOMO V1.0 enabler supports the:

• Delivery of software components to a device
• Installation of software components on a device
• Update of software components on a device
• Removal of software components from a device
• Activation of software components on a device
• Deactivation of software components on a device
• Inventory query of software components on the device

Because of the real-time software inventory capability, authorized management authorities are able to know exactly what discrete software components are on a device post-sale at all times. By tracking what type of software is on a device after it has been sold, management authorities are able to install, activate or upgrade other supporting or complementary software components to ensure a just-downloaded application, for example, will work efficiently. Bottom line: With SCOMO, management authorities are able to offer more relevant and personalized services that are compatible for each consumer's device.

Process of Installing a New Software Component

Below is an example of the workflow installation of a mobile application onto a consumer's mobile phone. The consumer subscribes to an application service, and the service provider always installs the newest applications on the end user's phone as soon as they are available. The service provider remotely checks the device's software inventory and assigns what application software should be installed by default on the end user's specific device type. The provider is authorized to define and change the default software on a device type. A device management system issues and handles the commands in the service. (Note: The device management system can reside under different authorities, such as a service provider or network operator, depending on the business environment and settings. The software component targeted at the device has been remotely delivered and installed, allowing the end user to use the newest version of services.

This process is similar for the activation/deactivation of services, performing software upgrades on devices as soon as they are available, removing software components from devices when subscription plans expire, or periodically checking the software inventory on the device in order to ensure the appropriate versions of required software components are installed on the device.

About OMA

Open Mobile Alliance (OMA) is the leading industry forum for developing market driven, interoperable mobile service enablers.

OMA was formed in June 2002 by nearly 200 companies, including the world's leading mobile operators, device and network suppliers, information technology companies and content and service providers. The fact that the whole value chain is represented in OMA marks a change in the way specifications for mobile services are done. Rather than keeping the traditional approach of organizing activities around 'technology silos,' with different standards and specifications bodies representing different mobile technologies, working independently, OMA is aiming to consolidate into one organization all specification activities in the service enabler space.

OMA is the focal point for the development of mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services. OMA drives service enabler architectures and open enabler interfaces that are independent of the underlying wireless networks and platforms. OMA creates interoperable mobile data service enablers that work across devices, service providers, operators, networks, and geographies. Toward that end, OMA will develop test specifications, encourage third party tool development, and conduct test activities that allow vendors to test their implementations.

OMA Enabler Releases (ERP)

OMA is committed to deliver releases with proven interoperability that fulfils the needs of the marketplace. In doing so, OMA has instituted a clear working process to develop open technical specifications that when combined, produce an Enabler Release with which differentiable and interoperable services can be created. The working process is a continuous program designed to deliver two key milestones for each Release. The OMA Release Program consists of the two phases:

• Phase 1 (Candidate Release): An approved set of open technical specifications forming an Enabler Release that can be implemented in products and solutions and which can be tested for interoperability.
• Phase 2 (Approved Release): The Enabler Release has undergone a period of public comment (minimum 30 days) and in addition completed the applicable interoperability validation.

OMA Definitions:

• Delivery Package: An abstract collection of Deployment Components that are delivered as a single unit. Installing a Delivery Package can result in deployment of multiple Deployment Components.
• Device: In this context, a Device is a voice and/or data terminal that uses a Wireless Bearer for data transfer. Device types may include (but are not limited to): mobile phones (GSM, CDMA, 3GSM, etc.), data-only terminals, PDAs, laptop computers, PCMCIA cards for data communication, unattended data-only Devices (e.g., vending machines), and smart cards if associated with these Devices. If within a particular context an associated smart card should not be regarded as part of a Device this is marked explicitly.
• Device Management: Management of the Device configuration and other managed objects of Devices from the point of view of the various Management Authorities. Device Management includes:
• Setting initial configuration information in Devices
• Subsequent updates of persistent information in Devices
• Retrieval of management information from Devices
• Device Management System: A background system capable to interact with a (set of) Device(s) for the purpose of Device Management.
• Enabler Release: Collection of specifications that combined together form an enabler for a service area, e.g., a download enabler, a browsing enabler, a messaging enabler, a location enabler, etc. The specifications that are forming an enabler should combined fulfill a number of related market requirements.
• Management Authority: An entity that has the right to perform a specific Device Management function on a Device or manipulate a given data element or parameter. For example, the Network Operator, handset manufacturer, enterprise or Device owner may be the authority or share authority for managing the Device. One Management Authority may own all Device resources or may share or delegate all or parts of these with/to other Management Authorities.
• Management Object: A Management Object (MO) is the data model for information which is a logical part of the interfaces exposed by DM.
• SCOMO Operations: Download, Install, Update, Remove, Activate and Deactivate operations which may be invoked on a Software Component MO as well as inventory queries.
• Software Component: Software Component is a resource utilized by Device software platform.
• Software Component Management Object: A management tree object defined for software components, which will be used for delivering and managing software components within client device.

Sources: Open Mobile Alliance and Red Bend Software