Introduction
The past few years have seen a huge increase in the use of mobile communications. Today, more than 50% of all the people living on this planet have access to mobile telephony service. And an ever-increasing array of de-vices, such as cameras and music players, are being integrated into mobile phones. Like-wise, the use of mobile broadband is spread-ing to include laptop computers, mobile in-ternet devices, and other consumer electronic devices.
In many countries, an entire generation of “digital natives” has grown up with mobile phones and the internet. To them, “always connected” is the norm, multitasking is easy, and technology is for the using. Digital na-tives demand interaction with the services and media they consume, and they want to share practically every facet of their lives with friends both near and far in a growing
network of real-world and online communi-ties.
These developments are putting new de-mands on the telecommunications indus-try. As the use of mobile communications increases and expands, users become less homogeneous in outlook and habits, and require greater customization and a wider array of services. At the same time, as more services and functions are being packed into mobile devices, the user interfaces become increasingly complex, to the point of being significant barriers to the adoption of new services. This translates into greater com-plexity and costs for network operators who deploy new services and networks. The chal-lenge, then, lies in giving end-users more ser-vices and functionality while also making it easier for them to adapt to and use expanded capabilities.
The Multimedia Communication Suite,
Ericsson’s response to this challenge, gives network operators the platforms and mecha-nisms they need to create an end-user experi-ence that simplifies the discovery of, access to, and usage of new network services. It both facilitates a much higher level of customiza-tion and integracustomiza-tion of services with terminal capabilities and hides the complexities of do-ing so from end-users. MCS is a horizontal business solution that gives operators a tool for crafting an end-user experience that
maximizes the uptake of new commercial •
offerings;
protects existing revenue streams; and •
provides a much richer set of options to •
support branding strategies.
Central to the MCS user experience is the MCS client, which employs the new IP Multi media Subsystem (IMS) application programming interface (API) on choice feature phones. The MCS client integrates with the terminal’s native address book to give users a familiar starting point for us-ing services. This lowers the barrier to initial uptake and further reduces long-term UI complexity.
Using the MCS client contact list, end-users can select the people with whom they want to communicate, see which communi-cation options are available for these people, and select the options they want. The client also enables users to perform a variety of ac-tions while they are communicating – for example, they can invite additional partici-pants as well as transfer or share objects and applications.
Figure 1 illustrates the concept of starting from the address book (center) and moving outward.
MCS solution
The MCS solution integrates Ericsson’s IMS solutions with native phone features. Clients in the solution apply to everything from sophisticated smartphones to ordinary tele-phones and personal computers. Users may even have multiple clients or phones linked via a single subscription. MCS clients that belong to the same subscription share data by storing it in the network:
the
• presence group and data management
(PGM) node stores subscription lists via an extensible markup language document management server (XDMS);
the
• active address book (AAB) handles per-sonal cards, privacy settings, authorization lists and updates; and
Ericsson’s Multimedia Communication Suite (MCS) is a horizontal busi-ness solution which gives network operators the platforms and mecha-nisms they need to create an end-user experience that simplifies the discovery of, access to, and usage of new network services, facilitating a much higher level of customization and integration of services with termi-nal capabilities while hiding the complexities of doing so from end-users.
Delivering the optimal end-user experience:
Ericsson Multimedia Communication Suite
Cristina Badulescu, Nancy Greene, Åke Gustafsson, Carlos Jaramillo, Marc Leclerc,
Peter Postmus, Guillermo Saavedra and Martin Servant
TERMS AND ABBREVIATIONS
AAB Active address book
ADC Automatic device configuration AP Aggregation proxy
API Application programming interface CAB Converged address book CPM Converged IP messaging
DB Database
DM Device management EMG Enriched messaging gateway HTTP Hypertext transport protocol IARI IMS application reference identifier ICS IMS Common System
ICSI IMS communication service identifier
IM Instant message/instant messaging IMA IMS multi-access
IMPS Instant messaging and presence server
IMS IP Multimedia Subsystem IMS-M IMS messaging
IT Information technology J2ME Java Micro Edition JSR Java specification request
MAC Multi-adaptation center
MCS Multimedia Communication Suite MIEP Mobile internet-enabling proxy MMS Multimedia messaging service MSRP Message session relay protocol NNI Network-to-network interface OMA Open Mobile Alliance PGM Presence group and data
management
RCS Rich Communication Suite SIMPLE SIP for instant messaging and
presence-leveraging extensions SIP Session initiation protocol SMS Short message service SSO Single sign-on
SyncML Synchronization markup language VAS Value-added service
VoIP Voice over IP
XCAP XML configuration access protocol XDMS XML document management server XML Extensible markup language XMPP Extensible messaging and presence
the
• IMS messaging (IMS-M) node manages chat and messaging sessions.
Network-based services permit interwork-ing between native and IMS services. Many feature phones are not currently equipped to handle voice-over-IP (VoIP) calls. As a con-sequence, the MCS solution employs IMS multi-access (IMA) and the media gateways of Ericsson’s IMS Common System (ICS) to provide interworking between circuit-switched and VoIP calls. The ICS solution also supports forking and session transfer.
For single-shot messaging, MCS clients can, depending on client type and associated capabilities, use native messaging or Open Mobile Alliance (OMA) Instant Message (IM) pager-mode messaging. This way, us-ers merely choose to communicate with one another – they need not specify the actual network address.
There is a wide array of short message ser-vice (SMS), multimedia messaging serser-vice (MMS) and e-mail services with which MCS users can exchange messages. Chat messaging is offered via IMS pager-mode messaging or IMS session-mode messaging using the mes-sage session relay protocol (MSRP) in IMS-M. The choice is transparent to users and does not affect how the chat history is presented.
The enriched messaging gateway (EMG) and IMS-M solution permit network-based interworking between message classes, al-lowing messages to be delivered in an opti-mum way. The EMG solution also facilitates interworking with other messaging commu-nities, such as Google Talk, and instant mes-saging and presence service (IMPS).
Single sign-on (SSO) authentication is pro-vided via the ICS solution, PGM aggregation proxy (AP) and mobile internet-enabling proxy (MIEP). Network access is negoti-ated via the session initiation protocol (SIP), hypertext transport protocol (HTTP), ex-tensible markup language configuration access protocol (XCAP) or the synchroniza-tion markup language (SyncML).
An automatic device configuration (ADC) solution manages client version, configu-ration, and profile data. ADC pushes data to mobile terminals using OMA device- management (DM) methods. Phones and fixed clients that do not support OMA de-vice management can employ a client-pull mechanism that asks the client to request and verify the most recent version.
As stated above, the address book in the MCS client is the starting point for commu-nication. It enables users to see other users
and their services through a separate per-sonal card for each user. The address book is backed up by a network-based service.
In the MCS solution, the client publishes its status to subscribing users via the PGM presence server. The user MCS client is aware, via client-profile provisioning (by means of OMA device management), of the services to which the user has subscribed. And the network operator can align the capabilities published and presented in the user interface with the user’s subscriptions.
When a new service is introduced, the user can see which other users have this service. This increases uptake and usage of newly in-troduced services because everybody can see who has access to the service. The feature also promotes viral marketing. Users can intro-duce new services to other users by sending a message, a promotion, or by gifting a sub-scription. Users who discover an unknown service can readily obtain information about it and subscribe to it.
Main architectural drivers
To a large extent, the MCS architecture is client-driven, which brings existing and new services into an integrated end-user experience.
Figure 1
MCS facilitates enriched end-user communication. A^kZ E^XijgZh Bjh^X Kd^XZ K^YZd 6YYgZhhWdd` G^X]egZhZcXZ 7VX`je <gdjeb\bi BZhhV\^c\ 8]Vi ;^ab LZW AdXVi^dc :kZci BVcV\ZbZci EjWa^h] HjWhXg^WZ LViX] >ciZgVXi EaVn HncX]gdc^oZ EVn 8dccZXi
Automatic device configuration
The MCS client configuration is automated, both for the initial configuration and for all additional configurations as new services are added.
Client application plug-in framework with service announcement and discovery
The set of services available to end-users is dynamic and can easily be extended by downloading new applications. The client announces all new services that support the presence function. New services are registered and invoked via the IMS communication ser-vice identifier (ICSI) and IMS application ref-erence identifier (IARI) in SIP signaling.
Common portal and SSO
For ease of access to web content, all web servers in the solution have been integrated in the portal to give web clients a cohesive end-user experience. An essential part of this solution is support of the single sign-on (SSO) concept after users have identified themselves either implicitly, via a trusted access network, or explicitly, by providing login credentials.
Common data storage
To ease the burden on the client, the network architecture strives to have a single access
point for all user data. Three different types of user data have been identified:
common media store for stateless un-•
structured data (for example, a photo al-bum);
common message store for stateful struc-•
tured data (read/unread/delivered/etc.). All messages are stored, regardless of message type; and
common user database (DB) for the user •
profile.
Subscription to data updates
User data that has been shared with and stored by another user is not static. Data management permits subscriptions to share information, enabling automatic updates that ensure the validity of data.
Data sharing based on privacy preferences
User-generated data can be shared (com-pletely or partially) with authorized users, either automatically or on request. This fea-ture adds a social or community factor to the ubiquitous access and storage capabilities al-ready offered.
Standard protocol interfaces in the reference points
Standard protocol interfaces in architecture
reference points make it easy to integrate ad-ditional products and to support multi vendor product scenarios.
Fixed and mobile network convergence
By supporting multiple client terminals for any given user, the network architecture facilitates fixed and mobile network conver-gence.
This is achieved through reliance on the IMS infrastructure of a single pub-lic address tied to multiple devices and on network-based storage of user data.
Interworking with internet communities
The network architecture accommodates the inclusion of gateways for interconnect-ing with internet communities via their network-to-network interfaces (NNI) – for example, Google Talk via XMPP (extensible messaging and presence protocol) and IMPS via SIP/SIMPLE (SIP for instant messaging and presence-leveraging extensions).
Other common network functions
In general, the MCS architecture will drive a horizontalization of the products in the solution. This may need to be addressed in standards, implementation, or at the time of deployment.
Figure 2
Functional architecture of the Multimedia Communication Suite (MCS). 7gdlhZg <VbZh B8HVeea^XVi^dcXa^Zci! kd^XZ!667!bZhhV\^c\ 9Zk^XZhVcY egZb^hZhcZildg` BVcV\ZbZci HZgk^XZaVnZg HiVcYVgYhZgk^XZh VcY>BH Bjai^"VXXZhhZY\Z L^gZa^cZ$l^gZaZhh VXXZhh IgVchedgiVcYV\\gZ\Vi^dc :BB E" 8H8; 8H8; 8J97 HBH BG9 B;H B;GE B<L C"H:< 6"H:< B<8; BBH >BEH <L <L MBEE E<B 6H Kd^XZ bV^a BI 6H Ed86H >BHB6H Z"bV^a B>:E EdgiVa >BH hiVcYVgY Xa^Zci 6YYgZhh Wdd` BBH =IIE >BH ;L 8dciZci 667 HBH :B6 DHH
Target architecture
Figure 2 depicts an MCS deployment sce-nario whose feature set provides rich pres-ence, active address book, dynamic addi-tion of new applicaaddi-tions, one-to-one as well as one-to-many chat, Google interworking, IMPS interworking, multiplayer gaming, file sharing, web portal for self-management, personal data storage, push to talk, and VoIP (fixed and mobile).
Standards
OMA CPM
The OMA standardization group is driv-ing a work item for converged IP messagdriv-ing (CPM) whose scope covers “multiple user experiences converged in one conversation.” CPM also includes
multimedia group communication; •
multiple device environment; •
multiple CPM addresses; •
seamless interworking between a CPM •
user and a user of a non-CPM communi-cation service;
value-added service (VAS) application •
messaging;
network-based storage (common reposi-•
tory);
converged address book (CAB); and •
absence service. •
OMA CAB
The OMA CAB is a new enabler (currently in the requirements phase of
standardiza-tion). Ericsson is an active driver of OMA CAB standardization, which means its so-lution will be aligned with all existing and future standards.
RCS
Ericsson’s MCS is also aligned with the Rich Communication Suite (RCS) initiative, which a group of like-minded players in the industry formed to accelerate the adoption of mobile applications and services that provide an interoperable, convergent, rich communi-cation experience.
New Ericsson products in
MCS
The sections below describe some of the new product offerings that will be introduced with Ericsson’s MCS business solution. Active address book
The active address book (AAB) application gives users a perpetually up-to-date address book. Users can access it and the personal cards of all MCS-enabled devices. Users set authorization rules that control the sharing of personal cards with others. Additional fea-tures that spice up the AAB service include searches, automatic matching of contacts, and notifications to new AAB users.
A personal card can represent multiple personas. Users may thus publish personal
information in manageable entities that re-flect different end-user profiles – for exam-ple, work-related information, home-related information, or interests-related informa-tion (Figure 3).
The MCS client provides AAB service-related functionality on the terminal as well as dynamic information (for instance, pres-ence status) obtained via OMA-specified client-server models, such as OMA XDM and OMA presence.
The AAB architecture consists of the SynchML server, AAB MAC, AAB server, and AAB XDMS (Figure 4).
SyncML server
The SyncML server synchronizes the address books in user terminals. Contacts’ personal cards are XML documents stored in AAB XDMS and exchanged by the AAB server.
AAB multi-adaptation center
The AAB multi-adaptation center (MAC) component facilitates the transfer of AAB data between the SyncML server and the AAB server – for example, address book updates. It can also import, export, and syn-chronize services to and from other types of address book applications.
AAB XDMS
The AAB XCAP document management server (XDMS) manages and stores the XML documents handled by the AAB.
Figure 3
Data structure of the active address book (AAB) personal card.
CVbZ E]dcZ BdW^aZ =dbZ
e]dcZ =dbZZ"bV^a c^X`cVbZEZghdcVa Ldg` e]dcZ bdW^aZLdg` :"bV^a Ldg` Z"bV^a C^X`cVbZ <VbZgh c^X`cVbZ 8^in 8^in 8^in CVbZ Ldg`eZghdcV =dbZeZghdcV <Vb^c\eZghdcV Eg^kVXnaZkZahVXXZhh Eg^kViZa^hi EjWa^X <gdjea^hi CVbZ
Also, subject to authorization rules, it allows users or servers to subscribe to changes in other users’ personal cards. In addition, it no-tifies users of changes and conflicts based on service provider- or user-defined preferences. The AAB XML documents handled by the AAB XDMS include
AAB persona-based authorization docu-•
ment;
AAB user preferences; and •
personal cards. •
Use case: Basic AAB subscribe and notify
On the originating side, on behalf of address book owners, the AAB server triggers and refreshes subscription updates to contacts’ personal cards. On the terminating side, the AAB server receives the subscriptions, ap-plies authorization rules, and issues notifica-tions when changes have been made to con-tent in authorized personal cards.
This method (Figure 5) significantly re-duces the flow of synchronization data over the air interface, because users solely receive updates in their address books.
MCS feature phone client
The MCS client is built on the Java Micro Edition (J2ME) platform. Feature phone vendors may use an associated set of Java specification request (JSR) APIs to enable the MCS client to access a terminal’s native and network capabilities (Figure 6).
IMS service stack on feature phone
The IMS stack provides standardized IMS protocols and procedures and the OMA IM media that is needed to enable IMS-related services. The IMS stack (in the terminal) provides the following IMS-compliant pro-cedures and media:
IMS registration – early IMS security •
(SSO);
framed media session control – enabled by •
SIP INVITE and MSRP media;
pager-mode message – enabled by SIP •
MESSAGE;
file transfer – enabled by MSRP within a •
SIP session;
publish – enabled by PUBLISH procedure; •
subscription – enabled by SUBSCRIBE •
procedure; and
notify – enabled by NOTIFY procedure. •
Practical example
The following example illustrates the im-pact of the MCS solution on the end-user
Figure 4
Architecture of the active address book (AAB).
LZWedgiVa 667 EjWa^XY^g 6 >BHXdgZ EjWa^XY^g 7 Egdk^h^dc^c\ hnhiZb DHH 6\\gZ\Vi^dcegdmn$ hZVgX]egdmn Eaj\^ch¶VYVei^dch[dgVcn hncXbaegdYjXihdgaZ\VXn hZgk^XZh¶VhcZZYZY JhZg' 9Zk^XZ( M86E!MFjZgn 667:g^Xhhdchdaji^dc Dei^dcVa:g^Xhhdcdg(EE :miZgcVaZci^i^Zh M86E$=IIE JhZg' 9Zk^XZ& M86E JhZg' 9Zk^XZ' HncXBA JhZg& 9Zk^XZ& JhZg& 9Zk^XZ' M86E MFjZgn H>E Om LZW 667 B68 667YViV 97 666 667 hZgkZg 667hdaji^dc 9ViVbVcV\ZbZci[gVbZldg` 667 M9BH HncXBA hZgkZg HncXBA 6YYgZhhWdd` eZgh8Y 6YYgZhhWdd` GVY^jh dgdi]Zg>$; Figure 5
Signaling flow for subscribe-and-notify personal cards use case.
H]VgZY M9BH 667hZgkZg dlc 667hZgkZg XdciVXiM 667M9BH 667 M9BH LViX]^c\a^hi jhZghid hjWhXg^WZid EZghdcVaXVgY >BHXdgZ 6 DG>< I:GB >CC >BHXdgZ 7 HncXba hZgkZg , + ( * & ) 'dei
experience. “Alice” downloads and installs a chess game. She then has the option of invit-ing any of her contacts to play. What is more, she can see which of her contacts have already installed the application. “Bob” for example has not yet installed chess on his handset al-though he can see that Alice has it. Alice may invite Bob to play even though she knows he doesn’t yet have the service. In this case, Bob must either follow the prompt to download the game or reject Alice’s invitation.
Without the MCS solution, this example scenario would require multiple separate ac-tions by Alice and Bob. For instance, they would each have to discover the chess service, download it, subscribe to it, inform each oth-er that they have the soth-ervice, and agree on a time to play.
Conclusion
MCS gives network operators an efficient, well-integrated approach to building the
optimal end-user experience as people use more services and the capabilities of their mobile devices.
MCS makes it possible
to launch more applications and services •
faster and at lower cost;
to deliver new value to end-users that le-•
verage incremental capabilities in IMS networks. It also simplifies user inter-faces;
to maximize new service uptake and re-•
duce marketing costs via viral marketing practices;
to maximize the ability to leverage exist-•
ing enablers and protect revenue streams via combinational services;
to tap into economies of scale and the reuse •
that comes from IMS and network conver-gence; and
to harness the enormous creative potential •
of information technology (IT) and enter-prise developer bases in order to expand revenue opportunities.
TRADEMARKS
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.
Figure 6
Simplified MCS client and native applica-tion modules. ?VkVVeea^XVi^dch ^cXajY^c\XdciZci]VcYaZg ?VkVheVXZ CVi^kZheVXZ GZ\^hign B8HXa^Zci ?HG"'&& X]Ve^ 6BH CVi^kZ e]dcZ Wdd` >BHXdgZ CVi^kZ Veea^XVi^dc ?HG",* >BHhZgk^XZ 6E>
