The OpenCall Business Unit of Hewlett-Packard began an investigation and prototyping project three years ago focused on addressing the issues faced by Mobile Communication Service Providers and especially those embarking on providing "3G" services. The primary focus of this work was not "the mobile web" However, we faced many of the same issues noted in the Mobile Web Initiative Call for Participation. The result of this effort was both an approach to mobile services and a working portal providing communication services (telephony, messaging) as well as content services (web, streaming media).
In this short note we summarize the capabilities of the portal, the technology used, the approach that emerged, and the issues faced.
The archetypical mobile device is the mobile phone. This is a device that is fundamentally a person-to-person communications device, not a content or information access device.
From this base, certainly, one can add other devices and variants: both connected and dis- or un-connected devices such as players, PDA's, portable computers, sensors, capture devices. As well, devices found or discovered while in motion should be considered: printers, beacons, communication access points.
Network resources also play a role in mobility: presence, availability, and location in particular.
We came to see the mobile case as the normal one with fixed connectivity and a powerful, graphically rich (browsing) platform as a special case.
Naturally, we wanted the Web—with its huge body of resources, pervasive and familiar model—available in the richer mobile context. When we started, the issues (which still remain) were ones of device independence, rendering, and avoiding fragmentation. By the end of the work, we believed that we had taken significant steps towards integration and extension of the Web to mobile context and to communication and services.
Looking back, we see the evolution of the Web moving from structured content separated from presentation, then addressing more seriously the presentation layer. Then, the fact that web browsers were hosted on computing platforms naturally introduced computation and services into the Web. The current work on the semantic Web is partly motivated by the need to better share, exchange, and use information: i.e. collaboration between people and services. Our work adds communication.
Generally, mobile services deliver a user experience in several dimensions: space (large and local scale, geographies, devices & access networks diversity), time (how information is created, accessed or delayed. e.g. conversations require real-time while information access or email use store and forward or download techniques), activity or context (including willingness to communicate, entertainment vs. work, usage in groups,) and identity (privacy, billing, safety, control, rules, regulations, signatures, payments, communities).
To this already multi-dimensional landscape, one must add quality of service considerations: appeal and usefulness of services; latency and responsiveness; always on connectivity; simplicity and intuition.
Emerging from this complexity came several key ideas which were subsequently built as a prototype:
As will be explained below, we also need to support multiple persistent and shared contexts, re-aggregation, a common development and use model, and mobile device mediation. This is also accomplished with the Web resource model where we call these container/portal resources "places." That is, not only are communication services (e.g. "call my parent") and content (e.g. "show me the way home") resources, but so is the aggregation "place" (e.g. "help").
Context can be the current state: in a given location, with certain preferences, with a particular device, and engaged in a certain conversation. This can be captured and expressed as structured data referenced and/or queried—the usual Web approach.
In extending context—multiple contexts, shared and collaborative contexts, and contexts to which services can be integrated—more powerful methods need to be employed. We used web services and RDF.
Just as content, communication, and services are aggregated in "places", so is context. Context ranges from the static (e.g. settings and preferences) to the more ephemeral (e.g. my current connection bandwidth). Our architectural bias was to objectify context and make it available, at least, in the "places." Some drivers for this direction included not being able to rely on cookies and the need to do context sensitive mediation at the portal layer.
As context becomes a first class resource, it opens the possibility for the role of "context provider." While not fully explained here, contexts can be captured, re-packaged and re-targeted; can serve as prototypical starting points for roles, etc. In short, just as information and presentation are separated in the (original) Web model, so can context be separated but still represented in the Web.
The mobile phone introduces interactive voice and streamed audio as media types. If the phone or mobile device has a screen, then graphics are added. Other devices such as printers or projectors can add other media types.
Each of these devices tends to support a limited or have a favored media type. So, it is desirable to use each device at its best.
Not only does mobility introduce disparate media, but also disparate modes or control paths. For example, interactive voice to navigate (select, search) and control; location and orientation devices to navigate or constrain.
Of course, the desktop has various devices as well and hence multiple modes and media. However, the desktop-based browser has a fairly complete picture and control of all these devices. This is not the case in the mobile setting where it is not clear where the browser is hosted (if we can even define well "where" and "the").
To cope with changes in context, device, and network capabilities, mobile services need to adapt dynamically and in real-time. This needs to be done without losing, for example, session information or navigation focus. This must be done at the origin as well as the portal layer.
Communication immediately leads to collaboration. Collaboration between two people can be extended to others (conferencing) and to collaborative use of media (e.g. sharing), collaborative use of services, and collaborative browsing. In our prototype we used, for example, the esquirtviewer from Cooltown supporting both co-browsing and the sharing/pushing of web resources.
Collaboration requires a shared context. Again, the vanilla phone call shares a connection. More involved collaboration requires more context as well as more control, as does any form of sharing.
Web resource creation for this mobile world should be open to end users as well as to providers and publishers. In fact, one needs to be able to mix resources from many parties: an intuitive, shared architecture along with likewise intuitive and reliable composition are required.
It is also important to not distinguish between creation/composition time and "use" time: creation and composition is always open-ended. Put another way, there is a common model for users and developers, for both creation and consumption. For example, users can combine contexts ("places") in real-time, they can introduce new content and services in real-time, and (of course) produce, share, and consume interactive communication.
The insistence on end-user creation/composition is derived from the collaborative perspective.
The above key concepts points to a dis-aggregated Web interaction model: multi-party and multi-device. However, for collaboration to work and for multiple devices to be effective, re-aggregation is necessary.
We have used a portal model to re-aggregate for the above reasons but also because:
Driven by these concepts as well as the need to support:
our architecture developed around a personal portal which not only mediated user access to the Web and communications, but also was the point of contact and mediation for services and people communicating with the users.
The base platform for the portal was HP Labs' Web Presence Manager (WPM). This platform is built in Java and embedded in the Tomcat Servlet Container. The WPM was built to host web accessible interfaces to everyday objects such as people, places, and things. There is a model of aggregation and relation between web objects that often corresponds to physical relations. For example, collocated print, display, and communication devices in a room would be discoverable and operable via the web.
To help complete the link between the physical world and the virtual (Web) world, various other software morsels were leveraged including beacons to advertise web presence in the physical world and enhance navigation, esquirt as an alternative to HTTP and the browser model, and the esquirtviewer to enable collaboration and sharing.
Naturally, normal desktop-centric HTTP/HTML access was supported to the portal. The usual variants of lighter weight HTML such as WML were supported. As will be described below, we also provided speech interfaces via VoiceXML.
During the prototype development, it became apparent to us that the re-targeting of content for WAP or voice added significant effort. It had nothing to do with providing alternative presentations of underlying data: it had to do with building new navigational styles without arriving at a least common denominator.
Subsequent work on the Web Presence Manager included the introduction Web Services in addition to servlet-style messages/invocation.
We extended the web presence software and concept from simple relations and collocations of objects to include a richer model of context. "Place" became a meeting and communication place by adding telephony based communication, instant messaging including SMS, joint browsing and media sharing, and a connection model for places.
We employed RDF to represent context within a place and for connections between places (our connections could be much richer than media pipes). We found the learning curve steep and clearly more refinement of our approach is needed.
Being focused on mobile communication providers, we needed to bring network resources into the portal. Our internal model for session/connection management was SIP. We pursued the path of SOAP encapsulation and transport of our "rich connection" information over SIP.
Legacy connection management was supported via voice media front-ends that supported SS7 signalling. This front end served as a SS7/SIP gateway/proxy and interfaced to our portal.
Web or Web Service interfaces for position determining equipment, short message service were provided. We did not build interfaces to billing systems, intelligent network services, etc. Standard API's such as OSA/Parlay cover these network resources.
Our presence and availability model was also based on SIP and SIMPLE, with appropriate interfaces to legacy resources such as Home Location Registers.
Web content, services, media, and interactive multi-party communication were aggregated and mediated by one or more places. Places also served as multi-media, multi-mode coordination points. For example, placing a call through a place might (depending on the place) generate changes to call state displays, to availability indications.
Places capture context as well as provide it. Places can send and receive events, including navigation events. This history mechanism allowed decoupling of what is traditionally volatile session state from logical connection allowing the coming and going of people and the migration of connections between devices.
This note does not permit all of our conclusions to be presented. Many of these conclusions are, however, already incorporated in the above architectural themes which became clearer to us as the work progressed.
However, a few key points should be mentioned here:
15-october-2004 Hewlett Packard; Robert Hyerle.