2010 Annual Reportby OMA | Wednesday, December 1, 2010
2010 Annual Report
The full Annual Report and its component pieces are available in PDF format. Please contact the OMA Communications Team for assistance with requests to reuse the content.
VII. 2010 OMA Members
VIII. Contact OMA
by Fred Harrison
Chairman of the Board, Open Mobile Alliance
Head of Standards, Telefonica SA
I am pleased to see that following a year of change there is now a clear new momentum gathering in OMA. Faced with an ever-increasing pace of technical innovation, it is encouraging to see that we are developing the flexibility and speed of response in order to ensure our work is relevant to the market. The Board, our Members and OMA staff have all contributed to ensure that OMA is performing well and delivering value, and I am grateful for the support and enthusiasm that has developed within our organization.
One of the significant changes last year has been the focus on delivery of the OMA 2010 Annual Release. Thanks to focussed leadership and the commitment of our members, I am pleased to report that the completed release contains many new enabler specifications together with further enhancements to previous releases. Notable areas include device management, converged address book, converged IP messaging, mobile advertising and Application Programming Interfaces (APIs); fuller detail of the OMA 2010 Release is provided in this report. Based on the success of this approach, the Board has approved the 2011 Release Plan and we can look forward to working on a wide range of developments to support the new market opportunities which are arising in our industry.
Over the last year the Board has been working on several strategic initiatives to establish the direction of new technical work. In particular we have focused on four key topics. One of these is the development of API specifications for devices and networks that will be needed to support the growing market for mobile applications. Our work on architecture and service interfaces provides a strong foundation for this and we can see that further work on API specifications will form a major focus for OMA in 2011. The Board also established a Task Force to establish direction and priorities for work relevant to developments in machine-machine (M2M) applications. This identified a range of existing OMA specifications related to device management and personal networks that can readily support M2M solutions and set out priorities for further work. The Board has also started a study into cloud computing to assess what new work may be needed. In addition, we have spent time on reviewing and re-focusing our approach to interoperability. The program of testing events which has proved invaluable in demonstrating interoperability is being enhanced to include the concept of test on demand. This will give greater flexibility in testing, improved time to market and lower cost to our members.
During 2010 we have seen some important market facing initiatives which are exploiting the work of OMA. For example, the GSM Association’s Rich Communication Suite (RCS) is supported by OMA specifications, and we are working on further requirements for future RCS releases. In the API field, the OMA Parlay specifications form the foundation for the GSMA OneAPI initiative. I see these as very encouraging developments which will help speed up the deployment of OMA specifications and will provide good market guidance for further work.
Whilst the Board has been busy with ensuring OMA is fit for the future, the day-to-day technical work has continued to proceed at full flow. As usual our Annual report gives an overview and also some detailed insights into the work of OMA. I hope you will see that OMA continues to be a vigorous environment, delivering valuable results and working on important topics to support our members in creating future value. Looking forward to 2011, I am very optimistic that we are improving and extending our contribution to the Industry.
Outlook from the new Technical Plenary Chair
by Musa Unmehopa
Chairman of the Technical Plenary, Open Mobile Alliance
Senior Manager – Alcatel-Lucent
Where 2009 was a period of transition for OMA (with a focus on financial consolidation, reorganization, and process improvement), in 2010 our working groups rose to the challenge, embraced the new working environment and succeeded to develop and publish their deliverables more quickly and efficiently. I would like to express my sincere gratitude to the great teams and individuals who are diligently carrying out and supporting the technical work in OMA with such commitment.
Among the most noteworthy and pertinent process improvements that have helped OMA to further drive time-to-market and enhance industry relevance, are the Fast Track process and the Min Max procedure.
Our Fast Track Process, where we take a critical look at which process steps and deliverable types can be combined or omitted, is now being adopted in many places throughout the organization and the initial results in terms of quality and timely delivery are promising. This allows OMA to be more nimble and flexible where necessary, in response to new requirements and changing market conditions.
The Min Max Procedure provides an alternative path to final approval for enablers which are not progressing through formal IOP testing. Testing may be omitted for example for enablers that have already found their way to early beta implementations, that have been tested in bi-lateral environments, or for which other ways of testing/validation are adopted outside OMA’s domain but from which OMA may benefit. The new procedure ensures that our enablers smoothly move from Candidate (intended for validation and public review) to Approved (fit for implementation and commercial deployment).
2010 Technical Achievements
This year we introduced the Annual Release to improve the predictability of OMA specification delivery and on-time completion. By the end of 2010, we published 32 Candidate Releases and 8 Approved Releases for a wide range of service enablers. The 2010 Annual Release covers the entire breadth and depth of OMA’s core technology domains. In addition, we approved 21 Requirements Documents and Architecture Documents, as well as 29 Testing Specifications and Validation Plans. That is a significant achievement that demonstrates OMA’s ability to deliver on its commitments, an achievement that I am particularly proud of.
And there is a lot more to come. In 2010 we approved 18 new work items, whilst there are six more expected to be approved in the first quarter of 2011. Over a dozen of those new work items address Application Programming Interfaces (APIs), an area that our Board of Directors has identified as a strategic focus for the organization going forward. It is great to see the Technical Plenary take up this challenge with such enthusiasm, and I am looking forward to seeing many APIs added to the already extensive portfolio of OMA technologies.
2010 and 2011 Leadership Changes
In 2010, we welcomed new members and we said goodbye to delegates who have moved on to other challenges. In particular, within the Technical Plenary, we have said goodbye to Mark Cataldo, who led OMA’s technical activities for eight years to many successes. The organization owes Mark a debt of gratitude, and we wish him all the best in his next assignment. Mark was recently elected Vice Chair of the OMA Board, and we look forward to working with him in this capacity and in this new role.
In 2010, the OMA Technical Plenary has demonstrated its ability to deliver high quality technical specifications in ever shorter development cycles. In 2011 we need to not only continue on this track and deliver on our challenging commitments, but in addition fully and seamlessly incorporate the new strategic focus areas set by the Board of Directors into our technical work program. The Board has finalized the Annual Release Plan for 2011, and contains some 50 Releases for completion and publication. I for one am very much looking forward to many more satisfying technical achievements for OMA in 2011!
Application Programming Interfaces (APIs)
OMA API Overview
Based on the success of its API specification work for the GSMA OneAPI Initiative, which began in 2009, OMA has created a standardized API specification framework in 2010 and plans to create API packages and subsets of APIs throughout 2011. OMA API specifications can include abstract interface definitions as well as specific protocol bindings.
The channel to third parties is through the implementation of OMA API specifications by network operators, wholesale or open application environments and other communities. OMA APIs expose service functions residing either on the network or on the device side, and are designed to allow operators and other organizations to expose their own service functionality to the wider developer community. This creates a new and reliable paradigm for application development.
With the affiliation of Parlay in 2008, making the valuable technical work of Parlay a permanent part of OMA’s body of technical work, OMA members extended their commitment to interoperability with legacy Web Services. This offered a natural progression to the profiling and specification of the GSMA OneAPI Initiative, and allowed OMA to further evolve this work by defining Representational State Transfer (REST) bindings.
Through this initial GSMA work, OMA’s existing technical expertise in APIs, timely response to industry demand, and strong member support of this new initiative, OMA members understood that there was a wider industry need for API specification and standards. Now and in the future, OMA will accept requirements for API specifications from its own members, as well as from external industry consortia and standards organizations.
OMA ParlayREST V1_0
OMA ParlayREST specifies a set of APIs with an HTTP protocol binding according to the REST architectural style. Within this set, the common technical specification contains all items that are common across all individual interface definitions—such as namespaces, naming conventions and fault handling. In addition, data types that are shared between two or more protocol bindings are included in this common specification.
Each REST API specification contains sequence diagrams, data type definitions, resource definitions and operations on those resources, as well as fault semantics. Three representation formats are supported (XML, JSON, and form-urlencoded) and examples are included for each of these within each API.
SMS and MMS APIs
- Send MMS, SMS or IM to a terminal
- Check delivery status of the outgoing message
- Check incoming messages in polling mode
- Manage subscriptions and notifications for inbound and outbound messages
- Retrieve message content
- Confirm message retrieval (execute delete command)
- Support for Binary SMS/MMS
- Charge and split charges
- Charge and split based on volume
- Process refunds of charges and volumes
- Reserve charges and volumes
- Add/subtract charge and volumes to/from existing reservations
- Charge to previous reservation
- Release funds in a previous reservation
Location Monitoring API
- Obtain current terminal location, distance from a given location, or the distance between two terminals
- Subscribe to various notifications such as periodic notifications, distance notifications such as going beyond a specified distance), or notifications when a terminal enters a pre-defined area
Guidelines and White Paper
- Defines REST bindings
- Include key principals used in mapping Simple Object Access Protocol (SOAP) bindings to REST bindings
- Documentation conventions
- Considerations for XML, JSON, and form-urlencoded formats
- Encoding and serialization details for MIME messages
OneAPI Profile of ParlayREST (OMA PXPROF)
The OMA PXPROF ‘OneAPI Profile of the Parlay X SOAP Web Services’ provides a lightweight subset of previously defined APIs. This will encourage developer communities to build applications using enablers that are consistently available across mobile carriers. The profile also helps to further reduce the complexity often inherent in telecommunications signaling protocols. This brings the enablers back to their basic operation (e.g. ‘send SMS’).
OMA PXPROF provides Web Services profiles for the very same APIs as OMA Parlay REST 1.0:
- SMS API for sending, receiving and notification of messages
- MMS API for sending, receiving and notification of messages
- Payment API for charging, splitting and refunding
- Location API for current location, distance from location or other terminal, location within specific area
OMA Parlay Service Access (PSA) V1_0
OMA PSA is a suite of twenty-one web services APIs, consisting of WSDL interface definitions and XML data type definitions. The PSA APIs expose the typical service capabilities available in today’s 3G and wireless networks, such as call control, conferencing, messaging and location, and make them available as Web Services.
OMA PSA V1_0 completes the API requirements for 3GPP Release 8, following the transfer of API activities from Parlay, 3GPP, and ETSI to OMA.
OMA Next Generation Service Interfaces (NGSI) V1_0
OMA NGSI focuses on new requirements and API extensions for server-to-server based third party services. Evolving from the integration of the Parlay work into OMA, NGSI will expand next generation networking and services for seamless integration of fixed and mobile networks. These extensions are defined in response to lessons learned from current commercial deployments of Parlay. In particular, experiences from the Japanese market led to many of the new requirements. Furthermore, the desire to expose new service capabilities offered by the ever-evolving networks, was another driver for this work.
NGSI v1.0 covers both new functional interfaces as well as extensions of existing PSA v1.0 interfaces. OMA NGSI includes technical specifications for the following APIs:
- NGSI Call Control and Configuration
- NGSI Context Management
- NGSI Data Configuration and Management
- NGSI Identity Control
- NGSI Multimedia List Handling
- NGSI Registration and Discovery
OMA Next Generation Service Interfaces – SOAP Bindings V1_0
OMA Simple Object Access Protocol (SOAP) bindings are defined for a subset of the abstract interfaces from NGSI V1_0. To ensure consistency for the usage of the extended Parlay X interfaces and to respect the references between the interfaces and the related XSD, the NGSI-S specifications provide all updated WSDL and XSD files (even in cases where only a subset of the related Parlay X interfaces is extended in NGSI).
- SOAP binding for NGSI Call Control Extension API
- SOAP binding for NGSI Call Handling Extension API
- SOAP binding for NGSI Call Notification Extension API
- SOAP binding for NGSI Multimedia Conference Extension API
- SOAP binding for NGSI Multimedia List Handling Extension API
- SOAP binding for NGSI Identity Management API
- SOAP binding for NGSI Identity Resolution API
OMA CPNS Overview
OMA CPNS enables full convergence between Personal Networks and WAN/Cellular networks. This can be achieved through a Personal Network Gateway (PN GW) that serves as a mediator between the WAN and the PN. This allows access to services from outside a single network and also allows one network or user to offer services to another user or external network.
Market Aspects of OMA CPNS
The number of smart phones in the market that can serve as a PN GW is increasing, creating demand for interoperable services between smart phone and consumer electronics devices—in both home and personal networks. Data traffic on smart phones will also continue to expand. As the number of applications and content available for these smart phones increases, market demand will keep pace.
With these trends, OMA CPNS is poised to have great impact and relevance in the growing market.
Benefits of OMA CPNS Implementation
OMA CPNS offers many benefits across the mobile spectrum. These include benefits to Operators, manufactures, service and content providers and end users.
Benefits to Operators
- Greater adoption of wireless data services by leveraging fixed network connected devices
- Enables cooperation among service providers interested in home, personal and M2M network services
- Allow operators to differentiate services and prevent or minimize customer churn
- Enables expanded service areas from cellular networks to various local networks (e.g. Home networks and Office networks)
Benefits to Manufacturers
- Development of new products to leverage the convergence of cellular and personal networks
- Enables expansion of the product portfolio
- Fosters consumer and retailer confidence in reliable and high-quality products
- Improves vendors’ position in the market
Benefits to Service/Solution/Content Providers
- Creates opportunities to develop new applications for services targeted to specific devices
- Extends access to existing markets by leveraging convergence between cellular and fixed networks
- Enhances existing services and content distribution to end users
- Provides consumable content delivery to an increased number of devices once content is delivered to the CPNS server
Benefits to End-Users
- Provides seamless access to content throughout the home, improving the user experience across mobile phones and home electronic devices
- Increases the ability to get more personalized traffic, services and entertainment
- Users can enjoy various converged network services independently from terminals, operators and manufacturers
OMA CPNS Use Cases
Multimedia Content Delivery
Watch high-quality movies on a wide screen in the home using their mobile device as a gateway between a movie-streaming server (via Cellular network) and home consumer electronics via WPAN technologies.
Remote Connection of Personal Networks (M2M Connection)
OMA CPNS enables the extension of Internet-based services to home appliances. The extension of these services could facilitate interactions with M2M services and applications. From cars to home appliances, Internet-based services to viral content distribution, OMA CPNS will greatly expand access capabilities to users, machines and networks across the globe.
Extension for eHealth Scenarios
OMA CPNS provides an extension for ehealth scenarios. Using a PN GW, Health Sensors can access the CPNS server in the global network. This enables regular monitoring and simple daily care. Businesses such as hospitals and pharmacies can access information from monitoring devices attached to patients. Additional eHealth uses could allow parents to access health sensors for their children remotely.
OMA CPNS Functionality
OMA CPNS provides a wide range of functionality to support converged-network services, including multimedia content delivery, end-to-end management of service sessions, publication and discovery of services and customization of service characteristics based upon device capabilities.
- CPNS Entity Discovery & Personal Network Registration performs the discovery of operational modes and registration of Personal Networks
- Service/Content Delivery facilitates the delivery of content and services to and from the CPNS and external entities
- Device Capabilities delivers and manages the information about device capabilities, such as hardware, firmware and software
- Service Publication & Discovery
- Collection and Reporting of Usage Statistics informs the content selection process
- Service Group Management manages service groups as a set of Personal Network Elements sharing the same service and content that stretches over multiple personal networks
- Personal Network Management manages personal networks and updates Personal Network inventory
- Security provides the security required for CPNS when the required level of security is not provided by the underlying technology
- Status Management manages the status and status information of CPNS entities, such as presence information of Personal Network Elements and Personal Network Gateways online, offline, busy etc.
- Non-CPNS Device Proxy facilitates interaction between non-CPNS and CPNS devices
OMA CPNS and Industry Cooperation
The OMA CPNS Working Group will continue to collaborate with other standards organizations to enhance the interoperability between similar technologies, such as M2M. OMA and ETSI M2M have already begun collaboration, and ETSI considers OMA CPNS as one of the enablers to be used for M2M services. OMA CPNS compliments and can co-exist with the ongoing work of DLNA. In particular, OMA CPNS plays a key role when it comes to interaction with mobile handset and a non-CPNS proxy.
The OMA Communications Working Group (COM) is responsible for service layer standardization of communications related technologies, allowing companies to build proprietary communications solutions on top of OMA Mobile Service Enablers. OMA COM specifications include such areas as Messaging, Push-to-talk over Cellular, Presence, Contact Information, Media and Data Management and Spam Reporting. With a focus on interoperability among a wide variety of legacy systems and the convergence of those systems with new IP based services and technologies, the primary goal of OMA COM is to enhance the user experience and the operator’s ability to build comprehensive messaging and communications systems.
2010 Focus and Achievements
The OMA COM Working Group has continued to be a leader in the creation of many service enablers focused on convergence and enriched communications experience and support. OMA COM specifications create an integrated architecture for messaging and contact information using the SIP/IP core among others. This reduces fragmentation and enhances the user experience by simplifying the array of choices and decisions around new and existing services, connection points and service models.
In 2010, the OMA Board of Directors approved 17 various Candidate Enabler Releases that make way for the evolution of rich services and content sharing by integrating the various silos of existing messaging systems, as well as a new array of IP channels for sharing rich content, live chat and instant messaging, and sharing selective data.
OMA Converged IP Messaging (OMA CPM)
OMA CPM defines a framework that provides the convergence of multi-media communication services built on top of a SIP/IP core infrastructure, while leveraging standardized service functionalities from existing communication enablers. This framework comprises a set of functional components and interfaces that have been designed to facilitate easy deployment of existing and future communication services.
OMA CPM requires a broad set of functionalities that mirror the silos of a wide variety of messaging systems that currently work independently. In order to integrate these various messaging technologies and models, OMA CPM allows messaging traffic to move in each of the following modes.
- Immediate/deferred delivery
- Push/pull delivery
- Pager/session mode
- Group communication
- Discrete/continuous media
OMA CPM also supports communication with multiple devices at various end-points, and offers enhanced communication scenarios among multiple users in a single session. OMA CPM features include the following:
- Support of any arbitrary conversation sequence, which includes messages, sessions, file transfers and media.
- Interworking with non-CPM users (e.g. SMS, MMS, email)
- Support of multiple devices environments
- Centralized network repository for all types of user data
- A wide set of user preferences available to decide how a CPM service should be perceived (e.g. to decide how to handle an incoming message)
OMA CPM 1.0 Features and Functionality
OMA Converged Address Book (OMA CAB)
OMA CAB is an evolution of the address book and is expected to serve as a launch pad for new services that are built around contact information. This allows the use of a single network-based address book environment by a variety of services and devices. It provides advanced features aimed at enhancing the functionality and user experience of the address book.
Some of the features of OMA CAB include:
- Address Book (AB) synchronization
- Management of CAB User’s Personal Contact Card (PCC)
- Multiple Contact Views
- Contact subscription and publishing
- Contact sharing of AB and PCC information or subsets
OMA CAB 1.0 Main features
OMA Spam Reporting (SpamRep)
OMA Spam Reporting defines a mechanism to allow recipients to designate any unwanted media as “spam.” This prompts a report to a network entity with information about the origin and content of the unwanted media.
Some of the key features of OMA SpamRep include:
- Creation, formatting and transfer of Spam Reports between client and server
- Categorization by the User of the type of abusive message (e.g., spam, malware, phishing
- Action requests (e.g., Block Sender, Unblock Sender, Retrieve Blocked Messages)
- Reporting automatically or by User initiation.
- Spam Reporting is applicable to all media including SMS, MMS, IM, video
OMA Spam Reporting Overview
OMA Presence Access Layer (PAL)
OMA Presence Access Layer defines a common access layer to presence information for clients by defining common interoperable Presence Aspects and Presence Triggers. It also enables interworking with the presence owning enabler such as OMA Presence.
Some of the key features of OMA PAL include:
- Client interaction: PAL Client receives consolidated presence information indicators based on consistent, interoperable Presence Aspects/Triggers
- Presence Context: PAL establishes and resolves Presence Context (view of presence for a given watcher) associated with a presence aware service
- Interworking: Interface and interworking with information owning Enablers (e.g. OMA SIMPLE Presence)
- Privacy & Security: Ensuring privacy and security of information sources and clients
- Configuration & Administration Configuration and administration of PAL Profiles
OMA PAL Enabler – Logical View
XML Document Management (OMA XDM)
XML Document Management defines a common mechanism that makes user-specific service-related information (e.g. presence subscription rules, user preferences) accessible to the service enablers that need it. OMA XDM 2.1 extends previous versions of XDM to support the OMA Converged IP Messaging (CPM) and OMA Converged Address Book (CAB) enablers.
The main features of OMA XDM 2.1 include:
- Management of XML document access permissions—ACLs
- History of XDM operations performed on an XML document
- Extensions to User Access Policy
- Extensions to Group
- User Preference Profiles
- Document forwarding – in support of OMA CAB 1.0)
- Non-sip notifications of changes to XML Documents—utilizing OMA Push
OMA XDM Enabler – Logical View
Application of OMA COM Enablers in the Market
Korean Mobile IM Initiative—Major Success for Korean Operators
- National initiative to make IMS-based Mobile IM service interoperable among three Korean operators (SK Telecom, KT, LGT)
- Feature sets (common to all operators)
• Presence (log in/out, nickname): OMA Presence SIMPLE 1.0.1, OMA XDM 1.0.1
• IM (text, emoticon, flashcon, picture / 1:1, 1:N): OMA SIMPLE IM 1.0
New and Future OMA COM Activities
Enhanced Visual Voice Mail V1.0 (PMA EVVM) – Candidate Enabler planned for November 2011
- Common mechanism to offer enhanced voicemail service
- Builds upon the OMTP/GSMA VVM 1.3 Specifications
- Leverages OMTP/GSMA VVM 1.3 to add new functions and interfaces as needed
- Flexible user greetings to cover different scenarios
- Extension of voicemail to LTE deployment with multi-device supports
- Easier sharing a voice message with a 3rd party
- Converging voicemail service with existing and future messaging services
OMA Device Management Working Group Overview
The OMA Device Management suite of mobile service enablers is well established across the mobile value chain and widely respected for their reliability. Interoperability of services and devices is at the foundation of the OMA Device Management (DM) Working Group approach to standardization. Using the OMA DM Enabler and the various Management Objects provides seamless maintenance and integration of devices, services and applications—now and in the future. Before standardization, the only way to configure devices was in the factory or in the store.
OMA DM Enablers help operators and IT departments manage access capabilities, diagnose problems, fix and update devices over their networks. At home, in the office, on the road, consumer and enterprise applications must work with evermore-complex multi-use devices. These devices must work reliably in multiple environments across a variety of networks and regions. Interoperable and standardized OMA DM Enablers have the agility and complexity to meet the demands of this complex ecosystem.
The OMA DM Working Group has consistently produced device management specifications for more than eight years. As a result, billions of handsets deploy OMA DM specifications on the full spectrum of platforms.
In 2010, the OMA DM Working Group continued to extend OMA DM to standardize converged DM—the interoperability of all network connected devices and appliances.
OMA Device Management Objects
OMA Management Objects ensure the evolution of devices and services. The MOs work like an add-on: OMA XXMO on top of OMA DM 1.x. This modularity allows help desks and service providers to pick and choose what they want from the list of existing MOs. Certain functions can be managed over the network to greatly improve the timeliness of repair and upgrades, as well as reduce the cost of repair and maintenance. Such functions include:
- Connectivity configuration
- Firmware update
- Diagnosis and monitoring
- Software installation and update
- Lock and wipe
- Device Capability Management
- Scheduling of all of these tasks
Management Objects can be created, updated and deleted even when devices are already deployed.
OMA Device Management Objects – Industry Cooperation
Currently, there are several industry organizations that create Management Objects such as 3GPP, 3GPP2, WiMAX.
- To date, there hover 15 MOs from other fora registered with OMA, as well as over 35 MOs registered from other OMA Working Groups outside of OMA DM.
- The list of registered MOs can be found:
OMA Device Management Objects – Architecture Diagrams
OMA Device Management Objects – Approved
OMA Firmware Update Management Object (OMA FUMO)
OMA Firmware Update Management Object (FUMO) enables firmware updates by specifying the locations in the management tree where update packages could be downloaded. It also specifies commands that need to be invoked on specific nodes of the management tree to start an update activity.
OMA Software Component Management Object (OMA SCOMO)
The OMA Software Component Management Object (SCOMO) enables remote operations for software components within the device. SCOMO specifications allow operator and corporate IT departments to manage software inventory such as libraries and user interface elements. SCOMO ensures the compatibility of old and new software by removing/updating existing software and installing new software.
OMA Connectivity and Management Object (OMA ConnMo)
OMA Connectivity Management Objects (ConnMO) enables the seamless operation of devices over all the various protocols without manual administration of the device including UMTS, CDMA2000, Wi-Fi and 3GPP Packet Switch and other Proxy settings. ConnMO improves interoperability by reducing version driven fragmentation within the market.
OMA Device Capabilities Management Objects (OMA DCMO)
DCMO allows control of device features such as Bluetooth, WiFi access and the camera; and specifies the mechanisms required for the remote management of device capabilities. In particular, DCMO will allow the Management Authority to remotely enable and/or disable certain features and capabilities. The basic features and capabilities of the device will be exposed by DCMO to facilitate management of the components.
OMA Device Management Scheduling (OMA DM Sched)
OMA DM Scheduling Enabler V_.0 specifies the Device Management Scheduling Framework and corresponding Management Objects that can be layered on top of the OMA DM v1_2 to add seamlessly the common scheduling functionality to existing management infrastructure.
OMA Diagnostic and Monitoring Management Object (OMA DiagMon)
DiagMon determines the capabilities of any given device, performs fault detection and provides the ability to invoke diagnostic functions. This allows the Management Authority (network operators and corporate helpdesks) to detect and repair actual or potential troubles. This also enables fault reporting back to the network. DiagMon also allows terminals to measure and report key performance indicators. Management Authorities can use the diagnostic enabler to query the device for additional diagnostic data or to invoke specific repair procedures embedded in a given handset model.
OMA Lock and Wipe Management Object (OMA LAWMO)
OMA Lock and Wipe Management Object (LAWMO) allows deactivation of the device over the network giving operators an effective way to protect user and enterprise related data. Specific capabilities include locking and unlocking the device, wiping the device data and remote factory reset.
OMA Device Management Smart Card (OMA DM SC)
OMA Device Management Smart Card (DM SC) allows dynamic provisioning of management objects in the device and provisioning performed through local DM sessions between the smartcard and the DM Client in the device. It extends the provisioning capabilities of the smart card to cover more of thing the security of DM related operations. OMA DM SC is dependent OMA DM 1.2 and OMA SCWS1.1.
OMA Browser Management Object (OMA BMO)
OMA Browser Management Object (BMO) facilitates management of Browser parameters. The enabler’s Home Page node acts as a special bookmark, automatically going to the URL defined for the Home Page/URL. The Favorites node provides top-level bookmarks for the browser—similar to toolbars on many modern browsers. The Folders node may contain more bookmarks and folders, but is not required to exist if folders are not supported. *OMA DM protocol compatibility for the BMO is version 1.2 or any later compatibility version.
OMA Device Management Objects – Pipeline
OMA Software and Application Control Management Object (SACMO)
OMA Software and Application Control Management Object (SACMO), enables remote operations for software and application control in the device. Software and application control management specifications will provide capabilities of processing management actions such as workflow, processing or on device management of software and applications utilizing existing management objects.
OMA Gateway Management Object (GwMO)
OMA Gateway Management Object (GwMO) enables the management of devices that are not directly accessible to the OMA-DM server. These devices may be deployed behind a firewall or the device does not support OMA-DM. OMA GwMO supports the ability to fan-out commands from a DM server to multiple end devices and to aggregate responses from multiple end devices in order to facilitate a consolidated response back to the DM Server.
OMA List Management Object
OMA List Management Object lists the Management Objects supported by the OMA DM Client resident on the device and exposed by the device. OMA ListMO allows a device management server to easily retrieve the list of the supported MOs and any associated details.
OMA Software Component Management Object 1.1 (OMA SCOMO)
OMA Software Component Management Object 1.1 (SCOMO) will provide several enhancements for remote software management.
OMA Device Management 1.3 (OMA DM 1.3)
OMA Device Management 1.3 (OMA DM 1.3) represents an expansion of OMA DM 1.2. OMA DM 1.3 and supports the following additional functionalities: support for SIP/UDP transport bindings, specifications for mandatory support for bootstrap/TNDS, support for rich information in notification message including expiration, reason for session, etc., multiple management authority and delegation mechanisms and support for the discovery of optional DM features supported by the DM Client.
- OMA DM 1.3 is scheduled to reach candidate approved status in September 2011.
OMA Device Management Client Side API Framework (OMA DMClientAPIFw)
OMA DMClientAPIFw defines a standardized framework to enable applications on a device to access the Management Objects supported by the OMA DM Client resident on the device in a secure manner.
OMA Device Management M2M Initiatives and Industry Cooperation
OMA has identified areas where further standardization will enhance support of generic M2M implementations including Device Management. The current assumption within the OMA DM working group is that devices have significant memory and processing power, and that they are connected to a fixed or cellular network. In order to support devices with restricted capability, OMA will consider protocols, Management Objects, and other network bearers using a work item definition (WID) to extend existing OMA DM work. These areas include:
- Lightweight DM protocol for M2M devicesSince many of the devices currently being deployed in M2M solutions are microcontrollers with limited capabilities, OMA will consider existing light-weight M2M protocols or those currently under development in other standards efforts. If none of these are applicable to develop new lightweight M2M protocols to support limited capability devices, OMA will consider a new WID to meet this need.
- DM gateway supporting M2M networksOMA DM Working Group has already introduced the concept of an OMA Gateway Management Object (GWMO). It will enable remote operations for the DM Gateway as well as devices behind the DM Gateway. GWMO allows for such management actions as fan-outs of DM commands from a DM Server to multiple devices. It also enables the aggregation of responses from multiple devices.
- DM security enhancements specific to M2M applicationsMany of the devices that will be deployed in M2M applications will have a considerably longer lifetime than traditional mobile devices. Considering the expected life span of many of these systems, M2M device management security should be identified and implemented based on the market requirements.
In 2010, OMA’s Interoperability Working Group (IOP Working Group) made significant refinements to the testing program. These changes reflect OMA’s continued commitment to deliver accessible, cost-effective testing models such as virtual testing, test bank, bi-lateral and test on demand.
In 2010, OMA initiated a program to facilitate increased flexibility to extend the options for the provision of testing environments. The interoperability of specifications and commercial deployments can now be checked in a variety of ways including testing of OMA work outside the OMA test environment. These changes to the OMA interoperability process allow specifications to move from candidate to approved status without invoking formal test events. Additionally, these changes will enable improve testing efficiency and reduce risk for the deployment of new services.
2010 – Interoperability Program Highlights
Virtual Test Events
OMA’s Virtual Test Fests (VTF) were a key success of the IOP Program in 2010. Held in September and December, the VTF events demonstrated the successful testing of OMA Enabler implementations remotely, eliminating the need for any team to travel to a neutral or member test location. This virtual testing is performed by using secure SMS messaging to support the enablers being tested, and is fully supported by OMA staff for logistics planning and reporting.
OMA validation process
Parallel to tentative testing activities each Enabler is subject to a Public Review Period. If at the end of this period IOP has not gathered enough test results and there are no outstanding comments provided during the Public Review, then the Enabler can be submitted for Approval. Allowing Enablers to move from candidate to approved status without the necessity of gathering test results enhances the Validation process.
OMA Deployment Suites
As part of OMA’s commitment to provide flexibility in the provision of testing environment, initiated a new trial “Deployment Suites” in 2010. Operators and vendors worked together to deliver a service based on OMA Enablers.
2010 OMA IOP Survey
During the June meeting in Las Vegas, the OMA Board IOP Committee and the IOP Working Group leadership created a survey to assess the challenges and evaluate the best way to evolve the current IOP program. Based on the feedback provided by the Survey, the OMA Board ratified its commitment to continue supporting its IOP program by providing accessible and cost effective testing models.
2011 – Interoperability Program Innovations
In early 2011, OMA will launch to OMA will launch TestOnDemand platform. This project will be delivered over a nine-month period. Cyclical checks built into the program will ensure the platform will gain new functionality and allow members to provide feedback on their user experience. TestOnDemand will confirm to the Testing Community that the OMA IOP program is well placed and prepared to meet the challenges ahead.
The creation of TestOnDemand platform will enhance the current IOP program by promoting a flexible, low cost and efficient way of testing: Test Any OMA Enabler, Any Where, Any Time.
The platform automates existing services such as event registration, (TestBank); finding testing partners; matching registrations, etc. It also incorporates a new set of features:
- Sharing & collection of test results in real-time
Automatic Report Creation
- Automate the creation of Test Reports
Meeting Point for the OMATesting Community
- Recreate the service provided by Wikipedia but in this case for the OMA Test Engineers community
- LinkedIn Test
- Create a meeting point for the OMA Test Engineers community
- Online test forum
- Online forum to share experiences and challenges
TABLE GOES HERE
On 17 November 2010, OMA and KWISA, along with TTA co-hosted the Next Generation Mobile Technology and Standardization Event in Seoul, SK.
With over 300 participants, the event was well received by the Korean wireless technology industry. Headliners included JoonHo Park, Head of Standards Technology Enabling Team for Samsung Electronics. Dr. Park addressed convergence of the Internet and wireless technologies. Byungsun Hwang, General Manager of LG Electronics, took the topic of convergence one step further, asking why the Tablet PC and Interactive Mobile TV had not been successful. He offered scenarios for how converged services might present new opportunities in the future.
Fred Harrison of Telefonica, Chairman of the Board for OMA led his delegation, which included specific and detailed presentations:
- OMA Strategy for Open API Standardization, presented by Musa Unmehopa of Alcatel-Lucent and new Chairman of OMA’s Technical Plenary
- OMA Strategies for Device Management, presented by Axel Ferrazzini of Research in Motion, Vice Chair OMA Board and Vice Chair OMA DM Working Group
- OMA Strategies for Messaging, presented by Kyung Tak Lee of Samsung Electronics and Chair of OMA Communications Working Group
- OMA Converged Personal Network Services, presented by Jeonghoon Lee of SK Telecom, Chair of OMA CPNS Working Group and Xhafer Krasniqi of NEC and the OMA CPNS Working Group
To cap off the day’s events, eight OMA member companies presented commercial implementations of OMA Enablers:
- NEC — NC7000 Device Management Platform using OMA DM 1.2, OMA Firmware Update, OMA Lock and Wipe, OMA Remote Configuration and OMA Diagnostics
- SK Telecom — Presented a commercialized use case for content delivery and control using OMA Converged Personal Network Services
- Comverse — Mobile Internet Hub and Converged Messaging Services using OMA Converged IP Messaging and Parlay X Web Services
- Huawei — Enhanced Communication System using OMA Converged Address Book
- Gemalto — Audience Monitoring System using OMA BCAST Smart Card
- INNOACE — INNO DM using a OMA DM 1.2 and OMA FUMO
- Websync — Data Synchronization and Device Management Services using OMA Device Management and Data Sync Enablers
- KT subsidiary Show Talk — Commercialized Android application using OMA Converged IP Messaging
For more information about these commercial deployments, please contact Bobby Fraher.
OMA is not alone in its role of establishing standards, and recognizes the importance of working with other organizations that perform similar or complementary activities. To assist in this effort, the OMA External Liaison Program works to establish relationships with outside organizations and standards bodies to ensure broad industry participation.
Liaison agreements with OMA work in one of two ways:
- Cooperation Framework (CF) provides a set of guidelines agreed (but not formally signed) by OMA and the external organization.
- Cooperation Agreement (CA) where there is formal, signed agreement in place between the external organization and OMA.
OMA currently holds liaison agreements with the following organizations:
TABLE GOES HERE
In April 2010, the OMA Board of Directors convened a Taskforce focused on Machine-to Machine Computing (M2M). The purpose was to create a white paper and establish a priority for the potential of M2M work items within OMA. More than 20 companies participated. The Taskforce evaluated the activities of other SDO’s, industry fora and trade associations to identify gaps where OMA could provide valuable work for the market. In November, the Taskforce presented its finding to the OMA Board during the Seoul meeting.
- Extend OMA Device Management to support M2M devicesThe current assumption within the OMA DM working group is that devices have significant memory and processing power, and that they are connected to a fixed or cellular network. In order to support devices with restricted capability, OMA will consider protocols, Management Objects, and other network bearers using a work item definition (WID) to extend existing OMA DM work.
- M2M Device Management using a lightweight DM ProtocolSince many of the devices currently being deployed in M2M solutions are microcontrollers with limited capabilities, OMA will consider existing light-weight M2M protocols or those currently under development in other standards efforts. If none of these are applicable to develop new lightweight M2M protocols to support limited capability devices, OMA will consider a new WID to meet this need.
- Continue work on the OMA DM gateway and extend the requirements necessary to address M2M NetworksOMA DM Working Group has already introduced the concept of an OMA Gateway Management Object (GWMO). It will enable remote operations for the DM Gateway as well as devices behind the DM Gateway. GWMO allows for such management actions as fan-outs of DM commands from a DM Server to multiple devices. It also enables the aggregation of responses from multiple devices.
- Network APIs addressing M2M service capabilitiesBased on the success of OMA’s APIs, including OneAPI and others, OMA will develop a WID for a set of Network APIs that address the service capabilities defined in the ETSI M2M architecture. Already, the ETSI M2M framework is relevant with many existing OMA Enablers, and any new API work should be done in close cooperation with ETSI.
- Address OMA DM Security related issuesMany of the devices that will be deployed in M2M applications will have a considerably longer lifetime than traditional mobile devices. Considering the expected life span of many of these systems, M2M device management security should be identified and implemented based on the market requirements.
Additional Areas for Consideration
- Location services for mobile M2M applications
- Messaging to M2M devices that are sleeping
- Solutions for addressing specific M2M devices
Remote Connection of Personal Networks using OMA Converged Personal Network Service (CPNS)
Mapping OMA Enablers into ETSI Framework
M2M Service Architecture Framework
RCS Market Analysis and Requirements
The GSMA RCS Program is the joint effort of leading industry players to speed up and facilitate the adoption of applications and services that provide users with an interoperable, converged, rich communication experience. Based on IMS, the interoperability of RCS is achieved reusing existing standards, including 3GPP and OMA based enablers.
More than 100 companies are part of RCS, with a strong involvement of the different worldwide actors in the industry. Participating companies include operators, device manufacturers, network infrastructure vendors and software vendors. The primary goal of RCS is to offer interoperability across the four billion existing mobile customers.
The RCS Initiative delivered RCS Release 1 in December 2008 and RCS Release 2 in June 2009. Release 2 offers extension of RCS to the PC. In December 2009, RCS Initiative issued RCS Release 3 which provides some enhancements to RCS Release 1 and 2 service features. In December 2010, RCS Program delivered RCS Release 4 which extends the scope of previous releases in various areas (including Chat Interworking with legacy SMS/MMS, extension of RCS to full fixed access and LTE).
RCS Initiative is also working on openness (i.e. elaboration of RCS APIs) to allow developer communities to develop applications on top of RCS and to steer application creation. Hence, from a technical specification perspective, the GSMA RCS Program and Open Mobile Alliance recently started collaboration on the specification of RCS network APIs using Representational State Transfer (REST) bindings. In OMA, the technical work is currently anchored by a dedicated ‘APIs for Rich Communications’ work item.
With requirements provided by operators, device manufacturers, infrastructure vendors, RCS will offer an easy way for any end-user wishing to use enhanced communication services. This will ensure interoperability, economies of scale, and will further enable the wider IMS marketplace.
- RCS offers interoperable services across multiple platforms and customer interfaces.
- RCS leverages the existing Mobile number (MSISDN) without the need to create new accounts on multiple platforms.
- RCS operates just like voice, SMS and MMS today.
- RCS is tightly integrated with the native address book on the handset.
Features and the Use of OMA Standards
Profiling existing specifications from 3GPP, OMA and GSMA, RCS integrates them into a single communication suite. In order to deliver enhanced messaging, rich call and enhanced address book services, RCS makes these features available on any device and enables interoperable communication across different devices and networks.
The core feature set of RCS includes the following services:
- Enhanced phonebook, with service capabilities and presence enhanced contact information
- Enhanced messaging, which enables wider messaging options including chat, messaging history and conversational views
- Enriched call features such as sharing images, live video and video clips during a voice call
RCS relies on standards from other bodies for each of its component services, including OMA Enablers such as Presence, XML Document Management (XDM), Instant Messenger, Converged Messaging and Converged Address Book.
- OMA DS 1.2.1.
- OMA Presence SIMPLE 1.1 and 2.0
- OMA Presence Data Extension (PDE) 1.0
- OMA XDM 1.1 and 2.0 (in using Permanent Presence State and Presence Content XDMS)
- OMA XDM and Presence implementation guidelines (OMA XDM PRS IMPL 1.0)
Enhanced messaging features
- OMA SIMPLE IM 1.0
- OMA CPM 1.0
Support for management objects and operations
- OMA Device Management
Current Achievements and Future Plans
The GSMA RCS program has defined a core feature set, developed reference implementations of the services and conducted interoperability testing in a multi-vendor environment. To date, IMS core network standards are being developed in 3GPP while IMS based services are standardized in OMA.
Using a common, well-defined set of features, based on profiling of the available specifications coming from 3GPP and OMA, RCS ensures that interoperability can be achieved within that common feature set.
Latest OMA achievements in meeting RCS business needs
The RCS Initiative and Open Mobile Alliance recently started work collaboration on the specification of RCS network APIs for the different RCS Releases in order to allow developer communities to develop applications on top of RCS and to steer application creation. This technical work is anchored by a dedicated OMA work item (entitled APIs for Rich Communications) formally agreed in November 2010.
This joint work between GSMA and OMA mainly addresses technical specification work for SMS/MMS, IM, file transfer, presence and video/image sharing and security framework (i.e. authorization), APIs. This technical work is expected to be completed by mid-2011.
Request a PDF version of OMA Service Enablers Play Crucial Role in GSM Association’s Rich Communication Suite Initiative (RCS).
Request a PDF version of the full OMA Annual Report.
Return to Table of Contents
Using a clear working process, the Enabler Release Program is designed to deliver four key milestones for each enabler:
OMA Candidate Enabler Releases (CER)
An OMA Candidate Enabler Release delivers an approved set of open technical specifications that can be implemented in products and solutions, and then tested for interoperability. Upon publication as a Candidate, specifications then enter the OMA Interoperability Testing Program where they will eventually reach Approved Enabler Release status.
OMA Candidate Reference Releases (CRR)
An OMA Candidate Reference Release delivers a set of specifications and/or white papers which form a formal deliverable of OMA. The release can be referenced or otherwise used to support implementable enabler releases, but it cannot by itself be implemented in products.
OMA Approved Enabler Release (AER)
An OMA Approved Enabler Release represents a Candidate Enabler Release that has gone through the Interoperability Program (IOP) of OMA. The IOP tests interoperability between different member companies’ implementations-either within the OMA or through other means.
OMA Approved Reference Releases (ARR)
An OMA Approved Reference Release represents Candidate Enabler Releases that have gone through the Interoperability Program (IOP) of OMA.
*Please note. Graphics of basic architecture for OMA Enablers are available by rolling your cursor over the title of the enabler.
Architecture, Security and Charging
OMA Application Layer Security Common Functions (SEC_CF) provides a common set of security mechanisms with their possible deployment options that can be re-used by OMA Enablers. OMA SEC_CF will make it possible for all types of OMA enablers to use this architecture to provide security.
OMA Global Service Architecture V1.0 (OGSA), represents a comprehensive architectural view of OMA enablers leveraging the OSE (OMA Service Environment). OSE promotes common architectural principles for how OMA Enablers are specified and how they interact with one another while ensuring architecture integrity, scalability and interoperability. The OGSA primary focus is to support new (and/or revised) enabler specifications clarifying how they fit into the current OMA landscape and how they may be used to support services.
OMA Global Service Architecture V1.1 (OGSA), represents a comprehensive architectural view of OMA enablers leveraging the OSE (OMA Service Environment). OSE promotes common architectural principles for how OMA Enablers are specified and how they interact with one another while ensuring architecture integrity, scalability and interoperability. The OGSA primary focus is to support new (and/or revised) enabler specifications clarifying how they fit into the current OMA landscape and how they may be used to support services.
OMA Charging Data enables charging for various types of transactions. The value of OMA Charging Data rests in the ability to enable new business models and entities to benefit from open, standardized access to Charging Events generated in an OMA Service Environment (OSE) domain.
OMA Smart Card Web Server allows local communication between the Smart Card Web Server and an HTTP application (e.g. Web browser) running in the handset.
OMA Browser Management Object (BMO) facilitates management of Browser parameters. The enabler’s HomePage node acts as a special bookmark, automatically going to the URL defined for the HomePage/URL. The Favorites node provides top-level bookmarks for the browser—similar to toolbars on many modern browsers. The Folders node may contain more bookmarks and folders, but is not required to exist if folders are not supported.
**OMA DM protocol compatibility for the BMO is version 1.2 or any later compatibility version.
OMA Device Management 1.3 (OMA DM 1.3) represents an expansion of OMA DM 1.2. OMA DM 1.3 supports the following additional functionalities: support for SIP/UDP transport bindings, specifications for mandatory support for bootstrap/TNDS, support for rich information in notification message including expiration, reason for session, etc. and support for the discovery of optional DM features supported by the DM Client.
OMA Diagnostics and Monitoring(DiagMon) Enabler manages distributed, mobile wireless devices, inorder to optimize a subscriber’s experience and reduce network operating costs. With DiagMon, operators, vendors and enterprises can perform various diagnostics and monitoring operations on handsets across a network. These include Diagnostics Policies Management, Fault Detection and Reporting, Performance Monitoring, Device Interrogation and Remote Device Repair.
OMA Device Management Smart Card (DM SC) allows dynamic provisioning of management objects in the device and provisioning performed through local DM sessions between the smartcard and the DM Client in the device. It extends the provisioning capabilities of the smart card to cover more of the security of DM related operations. OMA DM SC is dependent OMA DM 1.2 and OMA SCWS1.1.
OMA Lock and Wipe Management Object (LAWMO) allows deactivation of the device over the network giving operators an effective way to protect user and enterprise related data. Specific capabilities include locking and unlocking the device, wiping the device data and remote factory reset.
OMA DCMO allows control of device features such as Bluetooth, WiFi access and the camera; and specifies the mechanisms required for the remote management of device capabilities. In particular, DCMO will allow the Management Authority to remotely enable and/or disable certain features and capabilities. The basic features and capabilities of the device will be exposed by DCMO to facilitate management of the components.
OMA Converged Address Book (CAB) is an evolution of the address book and is expected to serve as a launch pad for similarly evolving services dependent upon contact information. It allows the use of a single network-based address book environment by a variety of services and devices. It provides advanced features aimed at enhancing the functionality and user experience of the address book. Some of the features of OMA CAB include: Address Book (AB) synchronization, management of CAB User’s Personal Contact Card (PCC) into different Contact Views, contact subscription and publishing of PCCs to other CAB Users and contact share of AB and PCC information or subsets to other users (CAB Users or legacy).
OMA Presence Access Layer (PAL) Enabler complements OMA Presence SIMPLE. OMA PAL specifies logically interoperable abstractions known as Presence Aspects. Presence Aspects consolidate Presence Information based on one or more Presence Information Elements. Presence Context associates applicable Presence Aspects required to fulfill service function points with a Presence Aware Service. This provides PAL Client’s with a consolidated and determinate view of Presence Information.
OMA XML Document Management (XDM) enables the storage of user-specific information in the network, which is managed by authorized principals and accessed by service enablers that require this information. XDM specifies how such information will be defined in XML documents, as well as the common protocol for access and manipulation of such XML documents.
OMA Key Performance Indicators in OMA (KPIinOMA) creates a standard KPI framework and KPI definitions for OMA Enablers. The KPIinOMA enabler V1.0 defines the Key Performance Information framework and Key Performance Information definition.
OMA Presence SIMPLE enabler manages the collection and controlled dissemination of Presence Information. The Presence Enabler provides a variety of services that can be invoked from other enablers including OMA Push to Talk over Cellular and OMA XML Document Management.
OMA Location in SIP/IP core network (OMA LOCSIP) provides a SIP based interface to expose the location information of selected targets. The location information may be processed and utilized by other applications or services in the SIP/IP core network such as a Presence SIP Application server or a PoC Server to enrich the end user experience.
The OMA Mobile Location Service V1.1 (MLS V1.1) consists of a set of location specifications complying with 3GPP Release 6 LCS Specification. OMA MLS 1.1 is primarily intended for use in a 3GPP environment.
OMA Mobile Location Service V1.2 (MLS V1.2) consists of a set of location specifications complying with 3GPP Release 7 LCS Specification. OMA MLP describes the protocol between an MLS client and the LS. In the 3GPP context, MLP was chosen to be an instantiation of the stage 3 specification for the Le reference point.
OMA Secure User Plane Location (SUPL) utilizes existing standards where available, to transfer assistance data and positioning data over a User Plane bearer, such as IP, to aid network and SUPL Enabled Terminal (SET) based positioning technologies in the calculation of a SET’s position.SUPL utilizes existing standards where available and possible, and SUPL should be extensible to enabling more positioning technologies as the need arises so that they utilize the same mechanism.
OMA Presence Data V1.1 (PRS) reference release components and Presence Data Information Format extensions (PIDF) either defined in IETF or OMA.
OMA Presence Data V1.2 (PRS) reference release defines further Presence Information extensions and their mapping to the presence data model components and Presence Data Information Format extensions (PIDF) either defined in IETF or OMA.
OMA IMPS 1.3 Implementation Guidelines provide common and actual practices currently implemented and deployed for IMPS 1.3. The benefits of IMPS 1.3 Implementation Guidelines include the description of common solutions to recurring requirements, smoother interactions between clients and servers form different vendors based on a common set of practices, avoidance of a multiplicity of custom-based solutions and in general, improvements to IM services.
OMA Push to talk over Cellular (PoC) is intended to provide rapid communications for business and consumer customers of mobile networks. OMA’s PoC V2.1 will allow audio (e.g. speech, music), video (without audio component), still image, text (formatted and non-formatted) and files shared with a single recipient, (one-ton-one) or between groups of recipients as in a group chat session. OMA-PoC seeks interoperability among the network entities to avoid market fragmentation, by realizing the PoC service in a widely acceptable and standardized manner.
PoC Version 2.1 defines new functionalities beyond Push to talk over Cellular (PoC) service extending the PoC Version 1.0 PoC service including PoC Sessions with multiple PoC Groups, Browser based PoC Client Invocation, Dispatcher function and requests with other media types such as video, images, text and files.
The aim of the CPM Enabler is to reuse existing and define new reusable building blocks to be able to create a variety of interpersonal, interactive, multimedia communication services that run on top of an IP network. It is possible for third party Applications to use these capabilities, and these third party Applications also can interact with CPM Users as Participants. The CPM Enabler provides the functionality to enable CPM based service users to communicate seamlessly with the users of Non-CPM Communication Services such as SMS and MMS.
OMA Mobile Spam Reporting (SpamRep) enabler provides a mechanism for a Reporter to designate received content as “spam” and provide a report to a network entity. The scope of OMA SpamRep enabler includes only the message transfer between the mobile device and network entity.
OMA Simple Instant Messaging (SIMPLE IM) provides a framework for service development and an application allowing near real-time exchanges of instant messaging between users on mobile and fixed connections. SIMPLE IM architecture relies on common OMA enablers such as Presence, XDM and Device Management Services to provide the overall functionality and support for server hosted and client hosted IM conversations. It also supports conferences and one-to-one modes of the IM service.
Access to Content
OMA Secure Removable Media (SRM) offers a removable media service that protects against unauthorized access to internal content and data. Examples of SRM are secure memory cards and smartcards. OMA Digital Rights Management with SRM provides a secure mechanism to write, read, delete and update rights within SRM. This specification defines mechanisms and protocols of the SRM to extend the OM A Digital Rights Management version 2.0 or 2.1. This extension allows users to move rights among multiple devices and SRM. It also allows users to consume rights stored in SRM without generating and managing complex groups of devices in a domain.
OMA In Game Advertising (IGA) provides requirements and architectural principles for game developer advertisement-related consideration. Key objectives of IGA are identifying related functionalities that enable models and a focus on game-ad specific use cases and functionalities not addressed by other OMA enablers. OMA’s IGA enabler covers in-game advertising models, ads handling in game, best-practice and case for in-game advertising.
OMA Mobile Advertising enabler (MobAd) specifies mechanisms related to user profiles and context as well as mechanisms related to the associated content. Content providers, advertisers and operators will personalize and contextualize advertisements to be sent to a specific type of user. OMA’s MobAd supports interactivity, so users can interact with advertisements and other content. The standard specifies how to ‘use’ interactive advertisements to help users interact with advertisers and content. The specification enables metrics and data collection, including mechanisms to achieve accurate measurement of advertising campaigns based on user behavior.
OMA Broadcast (BCAST) is an open global standard for interactive mobile TV as well as on-demand video services, and is adaptable to any IP-based mobile content delivery technology. Currently, OMA’s BCAST 1.0 can be adapted to broadcast systems like DVB-H as well as cellular systems like 3GPP MBMS, 3GPP2 BCMCS and mobile unicast streaming systems.
OMA Mobile Codes (MC) enabler seeks to halt fragmentation by providing guidelines on existing standards as well as creating specifications to support interoperability between devices and regions. OMA MC creates a standard in which Mobile Codes act as conduits for camera-equipped handsets to access content and services, thus enabling the barcode to connect the physical world to virtual digital content and services.
OMA Customized Multimedia Ringing (CMR) presents multimedia resources to an end user according to a specified event, e.g. the establishment of a call, the arrival of a message or mail. The CMR enabler provides these main functionalities: service management, resource management, and resource delivery and presentation controls. Additional basic functions of CMR Enabler include; charging, security, and privacy. Certain OMA/non-OMA enablers or third party applications can invoke the open APIs of OMACMR to implement the CMR services.
OMA Mobile Search Framework (MSrch Framework) defines a mobile search service that integrates the capabilities of professional search engines including mobile search server capabilities and mobile search client capabilities.
OMA Secure Content Identification Mechanism (SCIDM) enabler improves the management of intellectual property in a networked environment and allows the construction of automated services and transactions. The potential applications of secure content identification include charging, content search/management, automatic content monitoring for copyright verification and usage statistics, content filtering/blocking, content tracing, selective recording/playback, remote triggering of ads in broadcast chains, etc.
Secure identification and authentication of digital content would allow secure interactions between content and all other entities such as content providers, content distributor, service provider, operators and end users in the mobile service environment. This will result in a more trustworthy and efficient service and transaction environment.
OMA Push (Push) allows a Push Initiator (PI) to transmit push content and delivery instructions to a Push Proxy Gateway (PPG), according to the delivery instructions. Because ‘push’ transactions are server-initiated, the Push framework introduces a means to transmit information to a device without a user request.
OMA DRM V2.1.1 specification enables content providers to grant permissions for media objects that define how they should be consumed. A content provider can grant appropriate permissions to the user for each of these media objects. OMA DRM V2.1.1 represents significantly improved security and functionality. Improved security is achieved by providing bilateral authorization between Rights Issuer and Device, based on PKI certificates and confidentiality and integrity protecting Rights Objects. Improved functionality and usability is achieved by providing preview functions, mechanisms for sharing of content within a registered community of devices, and by enabling devices without a wide-area network connection (unconnected devices) to par.
OMA SIP Push Enabler defines the protocol used to implement a SIP Push based service. A SIP Push based service allows a client to receive content in a communication initiated by the server, or ‘pushed’ over the SIP/IP Core. The SIP Push Enabler provides analogous functionality such as Push Over the Air (OTA), using SIP as the underlying transport mechanism. For example, content is sent from the Push Initiator to thePush Proxy Gateway using the Push Access Protocol.
Service Access Interfaces
The aim of OMA Parlay Service Access (PSA) is to address (per OMA processes) those 3GPP Release 8 requirements for which no technical work has been done in 3GPP and for which the responsibility of defining the resulting solution specification has been moved to OMA ARC WG.
OMA Next Generation Service Interfaces (NGSI) focuses on new requirements and API extensions for server-to-server based third party services. Evolving from the integration of the Parlay work into OMA, NGSI expands next generation networking and services for seamless integration of fixed and mobile networks. By creating a uniform and accepted standard of open APIs, third parties will use application interfaces to access network capabilities as well as further enhance existing capabilities. The scope of NGSI includes the standardization of new functional APIs for: Data Configuration and Management, Call Control and Configuration, Multimedia List Handling extensions, Context Management, Identity Control and Registration and Discovery functions.
OMA SOAP Bindings for NGSI (OMA NGSI_S) aims to specify a first protocol binding choice for selected abstract NGSI interfaces. SOAP binding will comprehend with the style/design as given for the existing PSA v1.0. OMA NGSI SOAP comprehend Parlay-X with extensions for call control, conferencing, and multimedia list handling.
OMA OneAPI Profile of the Parlay X SOAP Web Services ( PXPROF) provides a lightweight subset of already defined APIs. This will encourage developer communities to build applications using enablers that are consistently available across mobile carriers. The profile also helps to further reduce the complexity often inherent in telecommunications signaling protocols, bringing back the enablers to their basic operation (e.g. ‘send SMS’). OMA PXPROF provides Web Services profiles for the very same APIs as OMA Parlay REST 1.0: Short Messaging Service API, Multi Media Messaging Service API, Payment Service API and Terminal Location Service API.
The OMA Client-Side Enabler API (CSEA) enabler defines a set of requirements for API’s to be made available for Web applications running in browser or widget context web runtime environments; in its first phase CSEA is focused on OMA DCD, OMA Push and OMA DPE.
OMA RESTful Bindings for Parlay X Web Services (OMA REST) specifies an HTTP protocol binding for a subset of Parlay X Web Services specifications in OMA, using the REST architectural style. These REST bindings are defined for abstract API definitions from existing OMA enablers. By defining a REST binding for these interfaces, the larger Web developer community can now integrate OMA Enablers in their own service compositions using the tools and methodologies they are already familiar with. OMA Parlay REST 1.0 defines REST protocol bindings for the following APIs: Short Messaging Parlay X Web Services, Multi Media Messaging Parlay X Web Services, Payment Parlay X Web Services and Terminal Location Parlay X Web Services.
The following list of Mobile Service Enablers was approved by the Board in December 2010 for release throughout 2011, and may require some changes and modification throughout the year.
Architecture, Security and Charging
TABLE GOES HERE
Person to Person
TABLE GOES HERE
TABLE GOES HERE
Access to Content
TABLE GOES HERE
Service Access Interface
TABLE GOES HERE
TABLE GOES HERE
Sponsor Members (11)
TABLE GOES HERE
Full Members (56)
TABLE GOES HERE
Associate Members (52)
TABLE GOES HERE
Supporter Members (51)
TABLE GOES HERE
TABLE GOES HERE
NOTE: Please use the San Diego, California address for ALL written correspondence.
TABLE GOES HERE