The Open Mobile Alliance and Trends in Supporting the Mobile Services Industry

Michael R. Brenner, Michel L. F. Grech, Mohammad Torabi, and Musa R. Unmehopa

The Open Mobile Alliance (OMA) is the leading industry forum for generating market-driven specifications for interoperable mobile service enablers to facilitate global user adoption of mobile multimedia services. Since its formation in 2002, the OMA has made significant progress in delivering several enablers in areas such as mobile Web services, push-totalk over cellular, and presence, and it plans to deliver many more enablers in the coming years. This paper discusses the various projects undertaken by the OMA working groups that deal with multiservice networks and offers an early perspective on the mapping and evolution of the OMA enablers that are part of the overall OMA service environment (OSE), which spans all mobile access and core network technologies. The ideas presented in this paper are solely those of the authors; they do not reflect an official OMA point of view. 2005 Lucent Technologies Inc. Introduction
In the two years of its existence, the Open Mobile Alliance (OMA) [6] has established itself as the leading forum for generating specifications for mobile service enablers. As an industry organization that includes over 400 geographically dispersed member companies, the OMA is making giant strides in the development of specifications for a service environment that will represent a paradigm shift because it will make it possible to deploy multivendor platforms and services while avoiding costly customized integration with the operators network. This paper presents the authors perspective on the OMA and its activities; it is based on the authors participation in those activities and on publicly available OMA information, which is clearly referenced where appropriate. However, the content of the paper does not represent the official view of the OMA, nor is the paper endorsed by the OMA. Several attempts have been made in the past to create standardized tool kits for service creation, but the majority of these attempts have been narrowly targeted. For example, the intelligent network (IN)/wireless intelligent network (WIN)/Customized Applications for Mobile Network Enhanced Logic (CAMEL) concepts for voice-centric telephony and the Wireless Application Protocol (WAP) Forum concepts for mobile-specific browsers have been closely integrated with their underlying operator networks.

An exception to such close integration is the open service access (OSA)/Parlay concept [15], which allows controlled access to operators network capabilities by third-party service providers and caters to

Bell Labs Technical Journal 10(1), 5975 (2005) 2005 Lucent Technologies Inc. Published by Wiley Periodicals, Inc. Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/bltj.20079

LIFLocation Interoperability Forum MMSMultimedia messaging service OASISOrganization for the Advancement of Structured Information Standards OMAOpen Mobile Alliance OSAOpen service access OSEOMA service environment OSPEOMA service provider environment OSSOperations support system OWSEROMA Web services enabler release PEEMPolicy evaluation, enforcement, and management PoCPush-to-talk over cellular QoSQuality of service SDOStandards development organization SIPSession Initiation Protocol SMSShort Message Service TMFTeleManagement Forum TPTechnical plenary TWGTechnical working group W3C*World Wide Web Consortium WAPWireless Application Protocol W-CDMAWideband CDMA WINWireless intelligent network WLANWireless local area network XCAPXML Configuration Access Protocol XMLExtensible Markup Language
60 Bell Labs Technical Journal

Panel 1. Abbreviations, Acronyms, and Terms 1XRTTRadio transmission technology 3GPP3rd Generation Partnership Project 3GPP23rd Generation Partnership Project 2 APIApplication programming interface ARPUAverage revenue per user BoDBoard of directors BSSBusiness support system CAMELCustomized Applications for Mobile Network Enhanced Logic CDMACode division multiple access CIOChief information office EDGEEnhanced Data Rates for GSM* Evolution ETSIEuropean Telecommunication Standards Institute EV-DOEvolutiondata optimized GLMSGroup list management server GPRSGeneral Packet Radio Service GSMGlobal System for Mobile Communication* IETFInternet Engineering Task Force IMFIdentify management framework

IMSIP Multimedia Subsystem INIntelligent network IOPInteroperability testing IPInternet Protocol ISCInterface for service control ITInformation technology ITUInternational Telecommunication Union a wide range of services, including voice, data, and mCommerce. To date there has been little debate that mobile communication is a commodity. Penetration of mobile subscriptions is in the double-digit percentage range in most regions of the world, leaving ever less room for revenue growth through increased numbers of mobile subscribers. For this reason, the focus is now on average revenue per user (ARPU) and attempts are being made to increase ARPU by introducing premium services. Premium services are defined as services that provide added value (in addition to the voice commodity) for which the service provider can charge a premium. A typical example of a premium service is a so-called killer service, i.e., a service that appeals to a large number of users. Killer services are far from numerous, but each of them generates substantial revenue based on volume alone. It is characteristic of killer services that they are highly standardized and are specified in a vertical manner (i.e., service component architecture and integration are performed for each service). A prime example of such services is the Short Message Service (SMS). In such services, supporting functions (e.g., management, charging, and security) are specifically designed and customized to facilitate smooth operation of the service. Anything that would degrade performance or increase cost is methodically driven out of the service stack. As a result, these highly optimized services can easily handle as many as a million transactions an hour.
Bell Labs Technical Journal 61

However, although vertical integration may produce a highly profitable service, it is rarely possible to reuse the resources and capabilities that have been developed for that service to create another killer service. Instead, most supporting functions must be redeveloped and vertically integrated all over again. Vertical services, which by their very nature require close coupling throughout the vertical service stack, are traditionally specified by single standards bodies or by industry forums. As a result, there has been a great deal of duplicated effort and a disturbing lack of interoperability between services. These issues, along with the big question of what the next killer service will be, have caused great concern and

frustration among service providers and network operators. Consequently, there has been a paradigm shift in the world of service standards from standardizing services to standardizing service components, because it is possible to aggregate such service components to build differentiated value-added services. (These service components are variably referred to as service building blocks, service capabilities, or, in OMA terminology, service enablers.) This paradigm shift has resulted in a decreased emphasis on finding the next killer service. Rather, the focus is on creating an environment that allows the proliferation of niche services targeted at specific subscriber segments and specialized user groups. (It is expected that there will be a large number of such niche services; collectively, they are expected to generate considerable revenue through economies of scale.) This service environment, which is created by using generalized standard service components, facilitates shorter development cycles, lower integration efforts, and, hence, shorter time to market. Of course, such a service environment may also nurture the next killer service. These developments have encouraged the service standards community to move away from organizations that produce vertical specifications. Small-scale horizontal standardization efforts have been attempted, but they have not been notably successful. Thus, the way has been paved for the formation of the OMA [6].

Overview of the OMA

The OMA is different from other standards organizations because it has made a conscious effort to attract as members representatives of the widest possible range of interest groups throughout the mobile industry value chain, ranging from providers to end users, thereby ensuring that everyone will benefit from membership. In addition to the wireless operators and wireless infrastructure vendors that are traditionally represented in standards organizations, the OMA includes representatives from throughout the value chain, including mobile terminal vendors, the service developer community, information technology (IT) infrastructure vendors, content providers, tool vendors, and certification bodies. The presence of representatives of these final two sectors of the value chain is indicative of the importance the OMA attaches to the interoperability of the specifications it produces, a concern that distinguishes the OMA from a significant number of organizations that set specifications and standards. Principles of the OMA A truly open environment in which a multivendor ecosystem thrives should result in greater innovation, healthier competition between vendors, lower

costs, less market fragmentation, and a richer user experience. One of the legacies of standardization in the mobile industry is that, in some cases, there exist several solutions to the same problem. This may be because, in the past, the mobile industry has been driven more by technology than by the underlying needs of the market. To avoid such duplication, one OMA architectural principle [8] permits services to be built, managed, and deployed by reusing technology that currently provides features and functionality to the mobile industry. Another architectural principle mandates the neutrality of OMA architectures with respect to operating system, execution environment, and programming language. This principle underscores OMAs goal of achieving platform and device independence. The diversity of operating systems, application programming interfaces (APIs), programming languages, and development framework methodologies available today reflects the fact that technology is still being
62 Bell Labs Technical Journal

controlled by commercial and technological pressures. The OMA favors a fairer and more market-aware methodology in which APIs that are specific to a particular execution environment can only be referenced in OMA specifications as particular technological realizations of OMA-approved interfaces that are neutral with regard to execution environment. The success of the OMA will be measured by how widely its specifications are adopted by the marketplace (which consists of the various stakeholders) and will depend on delivering interoperable services that foster multivendor environments and eliminate barriers to service integration and deployment. To this end, the OMA has specified a common service architecturecalled the OMA service environment (OSE)that envisions an evolution toward a coherent centralized approach in which vertically specified service enablers are integrated and managed horizontally. This specification was accomplished without introducing either additional maintenance effort or bottlenecks for application developers whose product life-cycle and time-to-market requirements are different from those of terminal and infrastructure vendors. The OSE is seen as an essential framework or root architecture for specifying both how OMA enablers fit together and how they expose their resources through well-defined interfaces so that they may be discovered and accessed by other internal entities or by third-party application developers. It appears likely that, over time, the OSE will move away from an architecture of isolated and vertically integrated enablers to a horizontally integrated and centralized architecture of interworking enablers for the mobile services industry. The attempts within

the OSE to provide early architectural guidance for the implementation of future OMA enablers within an evolving service environment will make such an evolution easier. Other sections in this paper will provide further details of the OSE, including how enablers will map into it. The OMA and the Outside World The OMAs stated goal is to act as a catalyst for the consolidation of multiple forums under one umbrella organization; the affiliation integration program [7] in the OMA exists to facilitate such consolidation. To date no fewer than seven organizations (e.g., the Location Interoperability Forum [LIF] and the WAP Forum) have been affiliated with the OMA, and their work has been subsumed in the work of the OMAs technical working groups. In most cases, the specifications that were in the process of being published by the affiliates are now published as OMA specifications and care is taken to ensure that they are in line with other ongoing work in the OMAs groups. Such an approach reduces the likelihood of producing overlapping specifications within a single functional area. For example, much of the work of the WAP Forum continues today and much of the overlapping work of affiliated organizations is being coordinated with it to produce a uniform specification (e.g., the location work of the WAP Forum is being coordinated with the LIF work). The OMA seeks to work closely with other established standards organizations (e.g., the European Technical Standards Institute [ETSI] and the International Telecommunication Union [ITU]) as well as with other organizations that generate specifications (e.g., the Internet Engineering Task Force [IETF], the 3rd Generation Partnership Project [3GPP], and the 3rd Generation Partnership Project 2 [3GPP2]). The OMAs external liaison program [7] was specifically created to establish relationships with the outside world to ensure broad industry participation. Because of the disparate nature of the various standards and industry organizations (e.g., some are legal entities while others are not), the OMA has two mechanisms for collaboration with other organizations: a cooperation framework, which is an agreed upon but unsigned set of guidelines, and a cooperation agreement, which is a formally signed agreement. To date the OMA has established cooperation frameworks and agreements with a variety of organizations on topics ranging from Web services to certification. OMA Working Groups OMA technical work takes place within what are known as technical working groups (TWGs) and within committees. The former generate technical specifications; the latter, working documents related
Bell Labs Technical Journal 63

to the internal operations of the OMA. Examples of such working documents are process documents, guidelines, and tools that facilitate the development of or planning for the TWGs. The work products of the TWGs and the committees are submitted for approval to the technical plenary (TP), which oversees and ratifies all technical activities. The final layer of the OMA, the board of directors (BoD), manages the OMA as a company. Elected directors and sponsor directors compose the BoD, which, among other functions, determines the strategies, principles, and charter of the OMA and establishes liaisons with external fora in accordance with the rules and policies of the OMA. The BoDs committees work closely with the TP to ensure that the BoDs OMA strategy and the strategy and tactics of the TP and the TWGs are consistent with the OMAs charter, vision, and mission. TWGs and committees each have their own responsibilities, which are approved by the TP; they are listed in Table I. Enabler Releases The OMA enabler release program consists of three different phases: Candidate enabler phase: A complete set of approved technical specifications to realize a specific OMA enabler that can be implemented in products and solutions. To date several enabler releases have reached this phase. Approved enabler phase: A set of interoperability testing specifications added to the approved technical specifications. At the end of this phase, the enabler has successfully passed through the OMAs interoperability program, which means that interoperability testing has been performed by the OMA or will be performed by other organizations. To date several enabler releases have reached this phase, some of them legacy enablers inherited from forums that have joined the OMA, others (e.g., the OMA Web Services and the Download and Digital Rights Management Enabler releases) new enablers that are the result of development work performed in the OMA. Interoperability enabler phase: A set of end-to-end test reports that verify end-to-end interoperability and are added to an approved enabler to complete the release program. To date no enabler release has reached this final phase. Interoperability Todaysmobile network landscape contains a variety of technologies ranging from cellular technologies (e.g., code division multiple access [CDMA], wireless code division multiple access[W-CDMA], Global System for Mobile Communication* [GSM*], and General Packet Radio Service [GPRS]) to wireless access (e.g., wireless local area network [WLAN]). Standardization of service enablers has traditionally been undertaken

either by the standards bodies responsible for a particular technology (e.g., the 3GPP [2] forW-CDMA and the 3GPP2 [3] for CDMA2000*) or by small forums specific to an industry. This has meant that, within a family of technologies (e.g. GSM, GPRS, Enhanced Data Rates for GSM Evolution [EDGE], and W-CDMA or CDMA radio transmission technology [1XRTT] and CDMA evolutiondata optimized [EV-DO]), service interoperability has been guaranteed. However, there have been no such guarantees of interoperability between families of technologies. For example, despite the fact that the 3GPP2s multimedia messaging service (MMS) is based on the 3GPPs MMS, there are problems sendingMMSmessages between them and specific implementation guidelines are required [1] to ensure MMS interoperability between carriers. In general, a service becomes popular in a particular country or region when the majority of users in that country or region can use it. The phenomenal success of SMS attests to this; in some countries (e.g., the United Kingdom), over two billion messages are sent every month. In several countries (e.g., the United States, Japan, and Korea), multiple families of cellular technology are deployed nationwide. In such countries, a service that works irrespective of the underlying access technology offers benefits to end users, service providers, operators, and equipment vendors alike. Therefore, it is not surprising that the OMA places so much emphasis on interoperable services that are independent of the underlying technology of the network, where, by following the outlined OMA architectural principles, the enablers will interwork across technology families.
64 Bell Labs Technical Journal

Table I. OMA technical working groups. Technical working group Charter Architecture Defines overall OMA architecture and ensures adherence to it across the OMA. Browser and Content Specifies application technologies in the OMA. Data Synchronization Specifies data synchronization protocols, continuing the work of the former SyncML initiative. Developers Interest Group Specifies developers needs to the OMA. Device Management Specifies protocols in support of lifecycle management of mobile devices, continuing work started in the WAP Forum and the SyncML initiative. Games Services Develops interoperability specifications, APIs, and protocols for network-enabled gaming. Interoperability Identifies, specifies, and maintains testing-related processes, policies, and programs for enforcing interoperability in the OMA. Location Develops specifications for mobile location services with an emphasis on interoperability, continuing work started in the LIF and the WAP Forum. Messaging Specifies messaging features and technologies to be used in enabling messaging paradigms. Mobile Commerce and Charging Coordinates efforts to consolidate the perspective of companies and fora in the mobile industry value chain that are active in this domain, with the goal of providing a common mobile commerce

and charging view. Mobile Web Services Develops specifications for the application of Web services in the context of the OMA architecture, while making use of specifications work in external fora. Presence and Availability Specifies service enablers for the deployment of interoperable mobile presence and availability services to allow applications to exchange dynamic information about users and devices. Push-to-Talk over Cellular Develops application-enabling specifications in support of the deployment of PoC services. Release Planning and Management Plans and manages OMA enabler releases. Requirements Specifies market usability requirements within OMA. Security Specifies secure communication protocols, guidelines, and trust models between mobile clients and servers at application layers for OMA enablers.
APIApplication programming interface PoCPush-to-talk over cellular LIFLocation Interoperability Forum WAPWireless Application Protocol OMAOpen Mobile Alliance

By creating test specifications and organizing testfest events, the OMA can be reasonably sure that the specifications it releases will work together in a multivendor environment, across service provider domains, devices, and network technologies. Organizations such as the 3GPP [2] have been criticized because of the extended period of time during which their specifications undergo churn. The
Bell Labs Technical Journal 65

impression such churn creates is that interoperability testing occurs primarily when the specifications are deployed in an operators network, well after the specification has been completed. By jumpstarting the interoperability testing of its specifications, the OMA can be reasonably sure that most of the errors or ambiguities in them have been eliminated before they are deployed. In fact, a significant part of the OMAs budget is allocated for such things as interoperability testing, supporting regular testing events, providing support for tools, and developing a complete ecosystem to facilitate the testing of advanced products. Concern for interoperability is built into the OMA specification process. Each enabler specification must be accompanied by enabler test requirements that identify both the requirements and functionality that must be tested and any prioritization that is required. Furthermore, the OMA has a working group dedicated to interoperability issues (i.e., the Interoperability Testing [IOP] Working Group) that is chartered to maintain the processes, policies, and test programs required to ensure the interoperability of its enablers. This group is responsible for the definition of the test cases and the test tools. The conformity of enabler release implementations to OMA standards is tested at a test fest organized by the OMA. Because the OMA believes that its approach to the development of specifications is the right one, it seeks to act as a catalyst for the consolidation of other forums into a larger, broader organization. The OMA believes that the industry at large should not have multiple organizations working on specifications that are similar or

that appear to achieve the same goal; instead, organizations should join together to work for their common benefit. When consolidation is not possible, the OMA tries to reuse existing specifications and build upon them. Prime examples of this approach are the OMAs reuse of the work of such organizations as the IETF, the World Wide Web Consortium (W3C*), and the Organization for the Advancement of Structured Information Standards (OASIS). The OMA, Interworking, and Integration Consistent with its vision of itself as a consolidating forum for mobile service enabler specifications and with its principle of neutrality with respect to networks and implementation technologies, the OMA is currently placing a high priority on creating deliverables that will interwork with specifications from all relevant standards development organizations (SDOs) and industry forums and will facilitate integration in the operational environment of mobile operators and service providers. While the handling of specific normative dependencies and conformance reviews are being addressed in specific TWGs, the OMA has specified an OMA architectural blueprint that is in accordance with the principles of interworking and integration.

Avoiding the Silo Syndrome

The previous section has described the OMA as a new initiative in the area of services standards that was formed to promote the maturity and ubiquity of mobile multimedia services by specifying reusable enablers that are independent of the underlying networks and implementation technologies. This section will explore how the OMA intends to deal with the challenges (e.g., interworking and integration) associated with its objectives by looking more closely at its current activities and specification efforts. The term stove-pipe architecture or silo architecture is frequently used to describe the architecture of a product or service that has been specified, designed, and developed in a monolithic fashion because of considerations such as expediency, local optimization, and the low short-term cost involved in deploying a single silo service or simply because a better solution is not available. Silo architecture is based on integrating into the main functionality of a product or service all the secondary functions required. These functions are implemented and optimized around the main functionality in such a way that it is nearly impossible for them to be shared with other products or services. In the past, and to some extent even today, the lack of unified standards across service domains has been one of the main reasons for the low level of reuse in the implementation and integration efforts involved in the deployment of services. As a result, the silo syndrome (i.e., the tendency to create silo architecture) emerged in both standards and products, resulting in

a number of problems, such as high cost of investments (e.g., when multiple silos have to be deployed),
66 Bell Labs Technical Journal

excessive integration costs, slow deployment of new services and features, and high operating expenses. From the perspective of service providers, this environment of inefficient standards and specifications has led to a number of problems, including: The integration of service enablers with the underlying network infrastructure must be done from scratch for each deployment, resulting in significant cost for the operators. When new services are introduced, many functions are duplicated and much data is replicated. For example, each service implementation usually has its own subscriber database (which may duplicate user information that appears in another database, but which stores that information in unshareable profiles) and its own way of authenticating subscribers or accounting for service use. Sharing features like a preferred notification method (e.g., e-mail, text message, or voice call) across services incurs the expense of dealing with the interactions of those services and integrating them. Each service is typically associated with its own operations and management facilities, and the way one service is deployed in a network is usually different from the way other services are deployed in that network. The integration of the actual service implementation with the underlying network infrastructure or with the terminals requires a detailed knowledge of the network and the necessity of taking into account any network dependencies. This silo syndrome, which is depicted in Figure 1, has led to the deployment of multiple non-standard realizations of the same features as well as to inconsistent user interfaces across products and high costs. In many cases, the use of silo architecture in an attempt to develop products in a cost-conscious and timely manner has in fact led to the opposite result. By developing the OSE, the OMA is attempting to avoid the silo syndrome by defining an allencompassing, consistent service layer in which individual service enablers can be integrated horizontally rather than vertically (as they are in Figure 1) and managed coherently in a centralized fashion. The OSE The logical architecture for the service environment that has been developed and proposed by the OMA is intended to eliminate, to the extent possible, the problems that led to the silo syndrome. The OSE specifications and guidelines document [10] deals with the silo syndrome by proposing proper interworking,

interoperability, and integration and the use of policy enforcement mechanisms. The OSE envisions the OMA enablers as the service layer entities that will process application layer requests. Applications may reside either on application servers (e.g., content-providing sources) or on wireless or wireline devices. The apps interface arrow in Figure 2 illustrates this type of interface. The OSE will also ensure secure and protected access to network resources, regardless of whether they are in the mobile operator, core network, service provider, or terminal domains, by providing an insulating, network-agnostic environment between applications and network resources. The resource interface arrow in Figure 2 illustrates this type of interface. The OSE provides a policy-enabled invocation of the functions requested by applications. It also supports multiple technology bindings to ensure that the network-agnostic components can be deployed in specific network realizations. The invoke and tech binding interface arrow in Figure 2 illustrates this type of interface. Finally, while the OSE does not specifically include operations and management systems, the OMA enablers within the OSE will interface with the services lifecycle management systems of operators through well-defined interfaces specified by the OMA, as illustrated by the management interface arrow in Figure 2. OMA Policy Enforcement As a further means of avoiding the silo syndrome, the OSE has introduced the concept of using policy evaluation, enforcement, and management (PEEM) as an optional central enabler. When realized, the OMA PEEM enabler will allow other enablers to focus on their specific primary functionality and will also provide them with a means of using other functions (e.g., authentication, authorization, charging, and quality of service [QoS] control) that are supportive of
Bell Labs Technical Journal 67 Network operator, service provider, and terminal resources Applications domains Wireline device Application server request Wireless device request Network operator, service provider, and terminal resources Network operator, service provider, and terminal resources Vertically integrated services or silos Apps interface Resource interface Resource

interface Apps interface Resource interface Enabler 1 implementation (including functions like static policy, enforcement, life-cycle mgt., authentication, authorization, and charging, optimized for enabler 1 needs) Apps interface

Enabler n implementation (including functions like static policy, enforcement, life-cycle mgt., authentication, authorization, and charging, optimized for enabler n needs) Enabler 2 implementation (including functions like static policy, enforcement, life-cycle mgt., authentication, authorization, and charging, optimized for enabler 2 needs) Network operator, service provider, and terminal domains

Figure 1. The silo syndrome of vertically integrated services.

their core capabilities. Support for such other functions will be provided either by the PEEM enabler or, more frequently, by other enablers that can perform the needed functions and may be invoked using the PEEM enabler. Such a service environment, with Policy Evaluation, Enforcement, and Management at its core, serves as a deterrent to the proliferation of silo architecture in the specialized enablers and leads to a reduction in the cost of integration into the operators environment and other related operations. It is understood that, in this environment, the concept of policy is prevalent in the architecture of most, if not all, OMA enablers and that it is logically enforced both on requests from applications to resources and on responses in the opposite direction. However, deployment models vary and should not preclude any particular implementation. In other words, a particular

implementation may map physically to the PEEM enabler system that is shown in Figure 2, but that is not the only implementation possible. Many existing OMA enablers may already have partially implemented policy management capabilities, and most, if not all, have at least default static policies in place. Finally, because of its central role in the OSE architecture, the PEEM enabler (for which specifications do not yet exist) will have to support many different architectural requirements related to such things as scalability, availability, performance, geographical
68 Bell Labs Technical Journal Technology bindings Web services, etc. Enabler implementation Enabler implementation OSE OMAOpen Mobile Alliance OSEOMA service environment Resources in network operator, service provider, and terminal domains Wireline device request Applications domains Responding applications Wireless device request (e.g., content) Invoke and tech binding interface Policy evaluation, enforcement, and management Apps interface Resource interface Life-cycle management Management interface

Figure 2. The service provider portion of the OSE architecture.

distribution and replication, and serviceability. A letter concerning the OMAs policy management can be found in [13]. The OSE architecture is a logical architecture; specific OMA enablers have yet to be mapped into this architecture to produce detailed physical architectures. The next section provides, by means of examples, an early perspective on the evolution of some OMA enablerscurrent, as well as futurein the context of the OSE architecture.

A Perspective on the OSE and OMA Enablers

The goal of this section is to present the authors perspective on how different OMA enablers may fit into and support the OSE architecture and how they may interact with and benefit from the OSEs policy-enabled architecture. As we saw in a previous section, some OMA enablers have already been approved, some are in the candidate enabler phase, most are still in the requirements, architecture, and detailed technical specifications stages, and others have barely been initiated as work items. Each of these different

stages in the evolution of an enabler presents different challenges with respect to fitting into and benefiting from the OSE architecture. Likewise, each presents different challenges if a migration process is required to support both the OSE and the enablers it encompasses. Therefore, the following examples include the case of an approved enabler release (i.e., the mobile Web services enabler release) and cases of work products that are currently in the requirements phases (e.g., identity management framework [IMF],
Bell Labs Technical Journal 69 3GPP3rd Generation Partnership Project GUPGeneric user profile IMFIdentity management framework LALiberty Alliance OASISOrganization for the Advancement of Structured Information Standards OMAOpen Mobile Alliance W3CWorld Wide Web Consortium WSWeb services Web services and identity management in the OSE IMF OASIS LA 1.1 Parlay W3C LA next phases WS 3GPP (GUP) Open group Web services Other technology bindings Policy evaluation, enforcement, and management Other enabler implementations Mobile Web services enabler implementation

Trademark (registered in numerous countries) of the World Wide Web Consortium

Figure 3. Mobile Web services and the IMF in the OSE.

Presence, and Group Management) as well as some ideas about probable future work related to other service enablers. While work on the mobile Web services enabler has resulted in an approved enabler release, called the OMA Web services enabler release (OWSER), the IMF requirements breakout team has just produced its first requirements document. However, some of the work initiated in the mobile Web services work product with respect to the requirements for and specification of network identity is consistent with and has been endorsed as the initial phase of the IMF deliverable. Figure 3 shows the mapping of OWSER 1.0 and the current and future IMF enabler work into the OSE architecture and indicates how these OMA work products will interact with each other, with the PEEM entity, and with the external domains in the context of the OSE architecture. Mobile Web Services in the OSE The OSE specification adheres to the OMA principles outlined in the beginning of this paper, including the principle of neutrality with regard to operating system, execution environment, and programming

language. However, in order to support real-life deployments, the OSE supports multiple technology realizations and bindings. Technology choices must be made with regard to middleware, transport, interface descriptions, and the programmatic environment. One of the paradigms that is gaining wide industry support in this area is theWeb Services [4] paradigm. The OMAs MobileWeb ServicesWorking Group has specified OWSER as both a Web Services infrastructure
70 Bell Labs Technical Journal

framework and a set of best practices and guidelines that allows OMA enablers to be deployed in an interoperable manner. OWSER specifies how OMA working groups can define aWeb Services binding for their enabler and how such OMA Web Services enablers can be deployed in a horizontal Web Service environment. In other words, OWSER provides the means to realize an OSE implementation in a Web Services deployment. Interoperability between enablers is supported by mandating the use of Web Services specifications defined by the industry for transport, description, discovery, end user identity, federation, and security. These profiles in OWSER are based on the work of the Web Services Interoperability Organization [16]. Furthermore, best practices and guidelines are provided to aid enabler specification groups in making use of common usage, communication, deployment, and design patterns. These best practices and guidelines are based in part on the work done in the Parlay Group in the area of Web Services for telecommunication [12]. OWSER is one of the few OMA specifications that have reached the approved enabler release stage. When OWSER was being completed, the work on the OMA PEEM enabler was in its early stages, so no provisions for PEEM are included in the Web services infrastructure framework defined by OWSER. However, the Web Services paradigm is very well suited to support policy enforcement based on assertions and flowmanagement concepts. A more detailed discussion of how the OMA could use proxy-based architectures to unify policy enforcement based on flow-management concepts from Web Services with IETF policy information models appears in [13]. IMF in the OSE In the OMA, identity management is being addressed through the IMF work item of the REQ Working Group. The focus of this work item is on creating a comprehensive, reusable framework for handling identity discovery, transfer of information, control of availability, visibility, and the use of identities or personal information. The first phase of this work, which addresses single sign-on, single logout, federation, and attribute sharing, has reached approved enabler release

status as a subset of the mobile Web Services OWSER 1.0 enabler previously described (see Figure 3). This phase made use of the Liberty Alliances Identity Federation Framework (IDFF) 1.1 set of specifications [5] for the enabler portion that handles network identity, single sign-on, and federation. In turn, the Liberty Alliance specifications rely on work performed in other forums, such as OASIS and the W3C. The current phase of work on the framework is addressing identity-related requirements resulting from expanding the ecosystem analyzed (e.g., by including principals such as devices, applications, systems, groups of users, and enterprise employees) and expanding the scope from mobile Web Services to other services supported by other high priority market-driven OMA service enablers (e.g., the Pushtotalk over Cellular, Presence, Group Management, Device Management, and Digital Rights Management service enablers). It is widely anticipated that other aspects of the IMF work will result in additional specifications by the OMAs Mobile Web Services Working Group (some of them potentially implemented using other Liberty Alliance specifications), but other new service enablers (e.g., an authentication and authorization enabler) to address new requirements may be needed as well. With the emergence of the PEEM enabler in a central role in the OSE architecture, all enablers (e.g., the ones to be specified based on the IMF requirements) will be required to include a specification of the types of policies associated with them and the assertions (i.e., the statements that convey processable information) they produce that is consistent with any guidelines and specifications resulting from the PEEM specifications. Future enablers meeting the IMF requirements will support one of the goals of the OSE by being capable of providing some of the functions that are not considered primary for other enablers and are reusable by such enablers, if necessary. Requests from applications will be intercepted by the PEEM enabler, interpreted for applicable policies to be applied, and then delegated to specialized enablers, thereby supporting the move of the service industry environment from a silo architecture to the OSE, a globally optimized architecture based on reuse.
Bell Labs Technical Journal 71

IMS in the OSE The 3GPP/3GPP2 IP Multimedia Subsystem (IMS), which offers service-enabling functions and Internet Protocol (IP) transport, has been recognized by the OMA as a major source of relevant resources for the OSE. Furthermore, the IMSs application server concept is quite similar to the enabler concept defined in the OMA. The IMS provides its resources for external service provisioning through its direct

interfaces to Session Initiation Protocol (SIP) application servers and OSA gateways. The main components of the IMS architecture and its interfaces to the OSE are depicted in Figure 4. Because any SIP-based service enabler must have a SIP-based interface toward endpoints, the IMS architecture is open and makes it possible for these endpoints to be reached. Using the resources interface, OMA enablers can interwork with the IMS through six southbound interfaces; SIP-based service enablers can use the interface for service control (ISC). Furthermore, OMA enabler implementations may make use of IMS capabilities such as charging, authentication, and service management, in addition to the functions of the OMAs own enablers. More details and descriptions of the IMS interfaces and the functionalities of the main IMS elements in Figure 5 can be found in the IMS in OMA architecture document [11]. Through IMS, two northbound interfaces, Gm and Ut, provide interactions between the enabler implementation in the terminal and the enabler
Gm SIP Ut XCAP Sh DIAMETER Sd DIAMETER Ro DIAMETER Rf DIAMETER Mb RTP ISC SIP Reference Protocol point IMS core Terminal Mb Ut Gm Mb OSE Sh Ro Rf Dh ISC P-CSCF S-CSCF SLF HSS OCS CCF IMS core Technology binding Technology binding Technology binding Policy evaluation, enforcement, and management Enabler implementation Enabler implementation Enabler Life-cycle implementation management Management interface CCFCharging collection function HSSHome subscriber server IMSIP Multimedia Subsystem IPInternet Protocol ISCInterface for service control OCSOnline charging system OMAOpen Mobile Alliance

Figure 4. The main components of the IMS architecture in relation to the OSE.

OSEOMA service environment P-CSCFProxy call session control function RTPRemote Transfer Protocol S-CSCFServing call session control function SIPSession Initiation Protocol SLFSubscriber record locator function 72 Bell Labs Technical Journal

implementation in the OSE. For example, the Ut interface provides the terminal with a set of operations that makes it possible to configure client-specific data in the OMA service enabler implementation. A third northbound interface, Mb, provides the OMA service enabler with user-plane packet media streams over IP via the IMS core. Applications may use IMS functions directly, through an OMA enabler, or both. For example, a user of the push-to-talk over cellular (PoC) service may use the presence service by using presence information to find out if other users are available for a PoC session. The PoC server may publish such presence information to the presence server via the IMS core or by some other means. IMS network elements may also publish presence information. OMA enablers that use both IMS and non-IMS network capabilities will be specified with the requirement that the non-IMS networks offer the same capabilities as IMS networks with regard to such things as SIP, Extensible Markup Language (XML) Configuration Access Protocol (XCAP), and Remote Transport Protocol (RTP). The OMA mandates that, if an OMA enabler implementation uses IMS network capabilities, it shall not build its own network capabilities on top of the IMS [11]. This is a significant move toward ensuring the reuse of one of the mobile industrys major investments and another step in avoiding the spread and intensification of the silo syndrome. PoC, Presence, and Group Management in the OSE The OMAs PoC enabler is an open standard for interoperable push-to-talk services that has been widely used in the industry since it was introduced by the OMA in 2003; it is built on the Presence and Group Management enablers. The PoC enablers planned initial phase will focus on enabling halfduplex, one-to-one and one-to-many voice communication between PoC clients implemented on mobile subscriber devices. In keeping with the principle of access network independence, the PoC standard has focused on call flow specifications that are synergistic with the spectrum requirements of cellular networks. In particular, it has focused on the need for short message length to ensure shorter processing times and lower latencies. At its highest level, the OMA PoC architecture consists of clients in the terminal, including a PoC client, a group management client, and a presence client. In the server domain, the PoC architecture

consists of a PoC server, a group management server, and a presence server. The details of the OMA PoC architecture may be found in [9]. The group list management server (GLMS) provides a common way for mobile subscribers to create, store, and manage persistent groups and lists, such as those used for PoC group communications. The presence server provides a common way to store, access, and manage a subscribers presence information. The architectures of all these enablers rely on an IP core network that is SIPbased. In the majority of carrier networks, this SIP core is based on 3GPP/3GPP2 IMS. (See Figure 5.) The PoC architecture has evolved at the same time as the OSE. However, a tentative mapping of how the PoC architecture fits into the OSE (see Figure 6) demonstrates the flexibility of the OSE. The OSE provides an environment in which the PoC enabler implementation can integrate with Presence and Group Management (and with other enablers and service functions) to provide added value to the overall user experience, while moving away from the vertically integrated presence and group management functions in the PoC enabler. The Group Management enabler could support other enablers, such as Instant Messaging. Since the migration from vertically integrated enablers to horizontally integrated enablers will be gradual, application interfaces will not necessarily change; therefore, taking advantage of the specialized enablers will ultimately depend heavily on the PEEM enablers ability to parse requests, select and apply appropriate policies, and delegate functions appropriately. As described earlier, policy management capabilities may be distributed in individual service enabler implementations so that static policies can be evaluated by these enablers or, potentially, by a centralized policy enforcement entity that supports the integration of PoC, Presence, and Group Management. An example of the former approach is the group management server, which may store and evaluate policies related
Bell Labs Technical Journal 73

to presence subscription authorization, while the PEEM enabler takes care of more generic assertions related to policies common to the services provided by all the enablers. An example of the latter approach is the evaluation of privacy policies (which would result in some assertion flow) and their enforcement by a common PEEM (which would intercept the request with the assertion and act accordingly).

Future Work of the OMA

The OMA is still a young specifications organization and it is still evolving. The following subsections discuss some significant recent initiatives. OMA Service Enablers Life-cycle Management The OMA service provider environment (OSPE) is a work item in the OMA that addresses requirements

for the life-cycle management of OMA enablers that support the deployment and maintenance of operator services. Because it is still in an early stage of development, it is not yet clear whether this work item will result in an enabler specification. However, OMA members are closely following efforts in other forums (e.g., the TeleManagement Forum [TMF] [14], one of the leading organizations for operations support system [OSS]/business support system [BSS] guidelines and specifications) that are related to this initiative.
PoC client Terminal PoC server Group management server Presence server OSE SIP binding RTP binding Gm, Mb Ut Gm IMS core IMS core ISC, Ro/Rf, Mb ISC, Ro/Rf ISC, Ro/Rf Ut XCAP Gm SIP Mb RTP Ro/Rf DIAMETER ISC SIP Reference Protocol point IMSIP Multimedia Subsystem IPInternet Protocol ISCInterface for service control OMAOpen Mobile Alliance OSEOMA service environment PoCPush-to-talk over cellular RTPRemote Transfer Protocol SIPSession Initiation Protocol XCAPXML Configuration Access Protocol XMLExtensible Markup Language Life-cycle management Management interface Group management client Presence client Policy evaluation, enforcement, and management XCAP binding SIP binding 74 Bell Labs Technical Journal

Figure 5. Push-to-talk over cellular, presence, and group management in the OSE.

Work products from the TMF may help guide the OMA in work areas such as frameworks for telecommunications processes, data models, and service capabilities lifecycle management. By working together with the TMF in areas of joint interest, the OMA could complete its OSPE requirements sooner and could more quickly develop a management interface like the one described in the OSE architecture specification. OMA Service Enabler Strategy Many OMA members are increasing the pressure

on the OMA technical plenary to provide help in prioritizing the work on enabler releases and to accelerate the release schedule. The goal of this initiative is to induce the OMA to issue a manageable roadmap, and it has already resulted in a number of proposals from all the member companies to improve the OMA work program. These proposals include establishing guidelines for the granularity of enabler releases, tracking normative dependencies, managing the slippage of critical milestones, and collecting anonymous information on market requirements; all are reflected in the current work on enablers.

Conclusions

Young, diverse, challenging, ambitious, stabilizing, expanding, and unexpectedthe OMA is all these things. It is an organization where mobile operators, device manufacturers, wireless network equipment manufacturers, IT vendors, content vendors, and even enterprise chief information office (CIO) representatives work expeditiously together to determine the specifications that will provide the best possible business conditions for all stakeholders in the mobile industry value chain. As long as the OMA continues to provide such a forum, it is worthy of continuing support. Acknowledgments Much of the source material used for this article derives from work contributed to the OMA by our colleagues. In particular, the authors would like to acknowledge the contributions and insightful comments of IndakaWeerasekera in the areas of Policy Evaluation, Enforcement, and Management, Push-to-talk over Cellular, and Presence and GroupManagement. *Trademarks

CDMA2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA). Global System for Mobile Communication and GSM are registered trademarks of GSM Association. W3C is a trademark (registered in numerous countries) of the World Wide Web Consortium.

References [1] 3G Americas and CDMA Development Group, Americas MMS Inter-carrier Implementation Guidelines, May 2004, <http://www. 3gamericas.org/PDFs/mms_americas_ guidelines-may2004.pdf>. [2] 3rd Generation Partnership Project (3GPP), <http://www.3gpp.org>. [3] 3rd Generation Partnership Project 2 (3GPP2), <http://www.3gpp2.org>. [4] K. Lagerberg, D.-J. Plas, and M. Wegdam, Web Services in Third-Generation Service Platforms, Bell Labs Tech. J., 7:2 (2002), 167183. [5] Liberty Alliance Project, Identity Federation Framework Specifications (ID-FF), <http:// www.projectliberty.org/specs/index.html>.

[6] Open Mobile Alliance, <http://www. openmobilealliance.org>. [7] Open Mobile Alliance, Collaborating with OMA, <http://www.openmobilealliance. org/collaborating/index.html>. [8] Open Mobile Alliance, OMA Architecture Principles, <http://member. openmobilealliance.org/ftp/public_documents/ arch/Permanent_documents/>. [9] Open Mobile Alliance, Push to Talk over CellularArchitecture, June 2004, <http:// member.openmobilealliance.org/ftp/public_ documents/POC/Permanent_documents/>. [10] Open Mobile Alliance, OMA Service Environment Specification, Oct. 2004, <http://member.openmobilealliance.org/ ftp/public_documents/arch/Permanent_ documents/>. [11] Open Mobile Alliance, IMS in OMA Architecture Document, Nov. 2004, <http:// member.openmobilealliance.org/ftp/public_ documents/arch/Permanent_documents/>. [12] Parlay Group, Web Services Working Group, <http://www.parlay.org/about/web/index.asp>. [13] S. Qutub and I.Weerasekera, Advances in Policy Management Standardization in Mobility Networks, Bell Labs Tech. J., 10:1 (2005), 7782. [14] TeleManagement Forum, <http://www. telemanagementforum.org>.
Bell Labs Technical Journal 75

[15] M. R. Unmehopa, M. L. F. Grech, J. A. Dobrowolski, and J. J. Stanaway, The Support of Mobile Internet Applications in UMTS Networks through the Open Service Access, Bell Labs Tech. J., 6:2 (2002), 4764. [16] Web Services Interoperability Organization, <http://www.ws-i.org>. (Manuscript approved December 2004)

MICHAEL R. BRENNER is a consulting member of technical staff in the GSM/UMTS Standards Department in Mobility Solutions at Lucent Technologies in Holmdel, New Jersey. His expertise is in software engineering, picture archiving and communication systems, distributed systems, service and network management systems, IP protocols, and mobile data services. As a Lucent OMA contributor, his current focus is on identity management, mobile Web services, policy evaluation, enforcement, and management, and support of enterprise mobile services. Mr. Brenner has contributed to image-processing and communication technology that has won international awards. He serves as an external board advisory member for the TeleManagement Forum organization and has written technical papers for various journals and conferences. He holds an M.Sc. degree in computer science from the Polytechnic University of Bucharest, Romania.

MICHEL L. F. GRECH is a technical manager in the GSM/UMTS Standards Department in Mobility Solutions at Lucent Technologies in London, United Kingdom. He is responsible for a team driving service-related and regulatory standards encompassing the 3GPP, the Open Mobile Alliance, the UMTS Forum and various other European regulatory forums. Mr. Grech holds a B.Sc. degree in electronic engineering from the University of Essex in Colchester, England, and an M.Sc. degree in telecommunications technology from Aston University in Birmingham, England. A member of the IEEE and a chartered engineer, he holds seven patents and has written several technical papers. MOHAMMAD TORABI is a distinguished member of technical staff in the Wireless Standards Development and Industry Relations Department of Mobility Solutions at Lucent Technologies. He represents Lucent Technologies in the ITU-Ts Next Generation Network Focus Group of SG13 and the OMAs Messaging Working Groups (MWGs). He holds a B.Sc. degree in civil engineering from the University of Tehran, Iran, and an M.Sc. degree in systems engineering and a Ph.D. degree in operations research, both from the School of Engineering and Applied Sciences, University of California in Los Angeles. A member of the Institute for Operations Research and Management Sciences, Dr. Torabi holds several patents and has published papers in various scientific and technical journals. MUSA R. UNMEHOPA is a member of technical staff in the Wireless Advanced Technology Lab in Bell Labs at Lucent Technologies in Hilversum, The Netherlands. Mr. Unmehopa holds the chair position of the OMA Architecture Working Group as well as the vice-chair position in the OMA Mobile Web Services Working Group. In the past, he has held several leadership positions in Parlay/OSA, among them the vice-chairmanship of the 3GPP CN5 OSA and a seat on the technical advisory committee of The Parlay Group. He has championed the task forces on Parlay and OMA in both these organizations. Mr. Unmehopa has authored and coauthored various technical papers for journals and conferences, is coauthor of the IETF SPIRITS RFC 3910, and has several patents pending in the area of service delivery and service mediation. He holds an M.Sc. degree in computer science from the Technical University of Twente in The Netherlands. X