Introduction and Overview

The success of network computing, Java and recent technology advances in hardware, software and communications has created exciting new opportunities for developing a wide range of mobile applications, services and devices. Examples include hand held PCs, smart phones, low-end or cost reduced laptops, personal information managers (PIMs), personal productivity applications (word processor, spreadsheet, graphics), telephony, E-mail, paging, collaborative applications (video or data conferencing), Internet and Intranet access. They can address the needs of the mobile professional, the mobile worker in industry specific segments as well as consumer environments. By building on the Network Computer platform we can extend the advantages of security, availability, performance and total cost of ownership to a wide range of new mobile network computing devices.

Scope

This specification is a mobile extension of the Network Computer Reference Profile and it incorporates what is needed from the NC Reference Profile. In addition to mobile extensions, additions or enhancements to the base NC Reference Profile are included where technology or market advances have occurred (for example BusinessJava 1.1 and PersonalJava 1.0).

Objectives

While the current Network Computer Reference Profile does not preclude implementation of a Mobile NC device, it does not address many of the unique requirements for such devices. With the growing interest and requirements for Mobile NC devices, an expanded and modified profile specifically addressing the unique needs of mobile devices is required. Without such agreement, fragmentation, which the original profile intended to avoid, could occur. At the same time, the goals of the existing NC Reference Profile remain the same for the MNCRS:

"There will also be a growing variety of network-attached devices which will implement various profiles of these standards. As consumers, developers, manufacturers, corporations, education, government, service providers and others approach this complex and sometimes confusing landscape, it would be beneficial if there were a common set of guidelines which facilitate a broad application base, interoperability, simple and unified system administration, end-user ease of use, and low cost of ownership , to name a few.

The NC Reference Profile is intended to provide a common denominator of popular and widely used features and functions across a broad range of scaleable network computing devices, including personal computers. The specifications in the NC Reference Profile are intended to be open standards which anybody can implement. The profile encourages interoperability among various NCs and is designed to facilitate development of a broad application base to run on compliant devices. The profile also provides guidelines to content and service providers for designing and building applications and other Internet content which will interoperate with profile-compliant devices.

The NC Reference Profile does not specify an implementation for a Network Computer, nor does it preclude additional features and functions outside the scope of the profile. It is open, flexible, architecturally neutral and is intended to facilitate the growth of Network Computers while helping to protect investments made by customers and content, system, service, and application providers."

Requirements

The key requirements to be addressed include:

• Connection via slower speed, more expensive and less reliable networks

• Disconnected operations is the rule, not the exception

• Support for a wider variety of devices and network connections

• Ease of use and administration

• Cost of ownership improvements

Three classes of mobile NC devices can be defined:

1. The first which is called the professional assistant is fully capable of supporting rich JAVA content with a variety of productivity applications. This device can run in a disconnected mode and support replication with the host server for file or application updates. The professional assistant NC device will also need database access, mail, printing, directory service, management, access to existing enterprise applications (for example, 3270), security, and Web browsing. This device will be a fully capable NC with the added flexibility of mobility and disconnected operations.

2. The second type of mobile NC device will have less function than the professional assistant and focus primarily on being an information access device. Web browsing and basic E-mail support will still be required. This NC device will still support JAVA Applets but limited in scope i.e. performance, and memory consumption. This device is more dependent on a network connection, but there is a need for a limited function disconnected mode. This type of Mobile NC can communicate and interoperate with a range of servers and service providers.

3. The third type Mobile NC device is a very basic messaging, paging, telephony device that's main focus is on keeping the mobile professional in touch with the office. Limited or basic browser support is required for usability and to provide a common subset of functions across all Mobile NC devices. This would enable a service provider to scale their offering across all devices while maintaining communication and interoperability.
   

The initial focus of this Mobile NC profile work is targeted for the professional assistant type of NC device. It is envisioned that this MNCRS work will be extended to include the two lower tiered, less functional devices in the future. Note that type 2 and 3 devices are excellent candidates for industry specific solutions or applications.

The professional assistant is targeted at the professional user which by the nature of their responsibilities requires travel and often works from remote locations. The Mobile Network Computer is a "thin client" device that when connected to the network via a LAN will provide equivalent function to an office desktop Network Computer. The user will use the Mobile Network Computer for productivity applications like calendar, mail, word processing, spreadsheet, plus web browsing and terminal emulation when in connected mode. The intent of the device is not to be a laptop PC replacement and as such will not have local storage and files that are accesssible and/or under the direct control of the user. Many mobile workers do not need the full functionality offered by current laptops. A Mobile Network Computer would offer lower cost of ownership, enhanced security, and the convenience of reduced weight and size over a conventional laptop PC. This is possible by elimating the requirement for rotating media. The Mobile Network Computer's inherent technology will have weight and power advantages over traditional laptop PCs.

Operational Modes

The Mobile NC can operate in three different modes:

1. Fully connected via a high speed (Mbps) attachment such as a LAN. Code and data can be accessed from the network. In this mode the device can function like a desktop NC. This mode is usually preferred to update or refresh large program changes such as a new operating system kernel or application version from the network server.

2. Connected via a lower speed (Kbps) connection. Data can be accessed via the network but usually code is selectively downloaded (such as via Applets). The device depends on persistent storage for it's primary applications but Applets can be cached or may be downloaded from the network on demand.

3. Disconnected with local access only. During this period, data can be queued on the client as well as on the server until a suitable connection is established. The device is dependent on persistent storage for it's applications as well as Applets that may have been cached prior to disconnection.

The key characteristics that distinguish a Mobile Network Computer include disconnected operations when a network connection is not available (or desirable) and the ability to easily transition between different types of connections (or reconnections) and disconnected mode.

Mobile Device Considerations

Mobile devices typically have more constraints on bandwidth, screen resolution, power and size than a LAN attached NC. In addition, the Mobile NC must deal with server data access and consistency in both a connected (via wired or wireless connection) and disconnected environment. The disconnected mode is required to allow useful work to be done in cases where a host connection is not possible or desired. The need for disconnected operation and for data replication and consistency with the server requires persistent storage in the Mobile NC. This storage is to be transparent to the end user. The level of disconnected support will vary based on the device class and the applications. Conflict resolution strategies, user intervention or restrictions may be required in some scenarios.

Mobile Application Considerations

Java based applications can also be mobile aware meaning the application can understand how (or if) they are connected and react accordingly. Applications can even prepare for disconnection (or reconnection) in many cases.

Mobile Networking Considerations

An important Mobile NC networking requirement is called Virtual Private Network (VPN). It allows a mobile user to reach their home corporate Intranet securely via the Internet by connecting to a local ISP. This is accomplished via a combination of "tunneling", firewall and encryption protocols which are being developed and standardized within the IETF. They can reduce communications costs in areas such as long distance charges, 800 numbers, modem pools and outsourcing of dialup connections.

Server Proxy Mechanism

Mobile NC manufacturers will provide a server proxy (a substitute for the client that runs on the server) that enables service providers to support a wide range of devices with no impact. The benefits of this framework include enhanced support for disconected operations, the ability to transform media streams depending on device capabilities, optimized communications and enhanced security. The intent is to define the interface for this mechanism in a future update to this document.

Specification Guidelines and Standards

The Mobile NC specifications should provide enough details for Java developers to write applications that run compatibly across all NC devices, allow service providers to support the wide variety of future mobile devices, yet provide enough flexibility to Mobile NC device manufacturers to differentiate their products. It provides a high level framework for developing applications, content and services as well as connecting to servers from both a hardware and software perspective.

We have specified open technologies that are generally widely deployed and adopted. In areas where no clear standards exist, we have provided guidelines and requirements in the hope that we can influence the development of appropriate standards in the future.

The MNCRS mandates some functions while others are optional. The manufacturer may decide to exclude certain functions (designated here as optional) but for cases where they implement a function, the specified function or standard in the MNCRS should be implemented first over an alternative.

Device Attachment Options

• Cardbus

• USB (Universal Serial Bus)

• Serial port

• Parallel port

• Infrared via IRDA (Infrared Data Association)

• P.1394

• Monochrome (minimum screen resolution 320 x 240, minimum 2 bits/pel)

• Color (optional)

• An automatic recognition mechanism specific to each device is required to inform the software of the device characteristics.

• For example, mouse, touch stylus, buttons

• The user requirement for "Instant On" (measured in seconds) should be provided.

• Power management software and hardware interfaces will be needed. APIs should allow a system wide power management policy as well as allow granular control of specific devices.

• For example, keyboard, pen, speech to text

An audio output device is necessary to hear alerts and incoming calls, especially for users with special needs. Recording is optional.

• AU - is specified by SUN Audio File Format, 1992.

• WAV - is specified by RIFF Waveform Audio Format, July 1993.

Network Attachments

The Mobile NC supports a wide variety of network attachments: LANs, WANs, wired or wireless. The type of network connection (high speed, low speed, disconnected) dictates the mode of operation and performance characteristics of the device. A network connection is required via Cardbus or integrated (or external) communications.

High Speed Connections

When connected via a high speed connection (Mbps) such as a LAN, the mobile device can function as an NC defined in the NC Reference Profile. The software characteristics are summarized below. Note that there are some additions to the original NC Reference Profile to support mobile and also to incorporate recent advances in technology.

Software Guidelines

Communications protocols

TCP/IP Based standards (mandatory):

• TCP (Transmission Control Protocol)

• IP (Internet Protocol version 4)

• UDP (User Datagram Protocol)

• PPP (Point to Point Protocol)

The following are optional IP standards:

• NFS (Network File System)

• FTP (File Transfer Protocol)

• Telnet

• NNTP(Network News Transport Protocol)
  

Mobile IP and Dynamic IP (enhancements to the dynamic assignment of IP addresses) are optional emerging IETF mobility standards.

Security (optional)

Secure authentication and data encryption may be necessary for some Mobile NCs.

SSLv3 - Secure Socket Layer version 3 provides server and client authentication at the session layer.

IP Security (IPSEC), being developed in the IETF, includes ISAKMP/Oakley (Internet Security Association and Key Management Protocol/Oakley Key Determination Protocol) and SKIP (Simple Key-management for Internet Protocols) as emerging network layer security standards for key management for IP encryption.

For remote dial-up, techniques such as PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol) can be used to provide authenticated access.

SmartCard technology (optional)

If the device uses SmartCards, it must support these standards:

• ISO 7816 standard

• EMV (Europay/MasterCard/Visa) specifications

• OpenCard Framework - provides an architecture and a set of APIs for NCs.
  

Inclusion of a SmartCard can imply a multi-user device. Many, if not most, Mobile NC devices could be single user devices. In this case the SmartCard could still be needed or used for authentication or for future electronic commerce situations.

Mail

• IMAP4 - Internet Message Access Protocol Version 4 (required for mail)

• SMTP - Simple Mail Transfer Protocol (required for mail)

Directory support

JNDI (Java Naming and Directory Interface) is an API that can be used to access the underlying directory support including:

• DNS - Domain Name Service

• LDAP - Lightweight Directory Access Protocol

WWW Standards

• HTML - HyperText Markup Language (version 3.2)

• HTTP - HyperText Transfer Protocol (version 1.0)

• JAE - Java Application Environment
  (either BusinessJava version 1.1 or PersonalJava version 1.0 which both provide Internationalization support)

  -The Java Virtual Machine and runtime environment

  -Java class libraries

• Database access is via JDBC (Java Database Connectivity).

• JPEG (Joint Photographic Experts Group)

• GIF (Graphics Interchange Format Version 89a)

• MPEG4 (optional)

Management

• SNMP (Simple Network Management Protocol)
  

Startup and (re)configuration

• DHCP (Dynamic Host Configuration Protocol) which includes Bootp

• The ability to easily transition between different types of connections (or reconnections) and disconnected mode is required.

Mobile NCs should be able to boot-up or restart as a stand alone device (disconnected).

Remote Startup:

The Mobile NC software can be refreshed when required via a high speed connection or interface such as a LAN.

Capabilities Exchange (optional)

There is a need to provide a capabilities exchange for mobile devices in order to understand things like screen size, color versus monochrome, resolution, amount of storage or bandwidth available and many other optional features that applications may want to exploit or a means for the mobile device to find a specific service or type of device such as a color printer.

Lower Speed Connections

When operating in this mode (Kbps), the data on the server can still be accessed and programs such as Applets can still be downloaded from the network in most environments. Note there may be some very low speed environments such as wide area wireless where the bandwidth may constrain access to large amounts of data or programs across the network. These environments may still be well suited to specific applications or provide opportunities for network optimizations.

Collaborative Applications such as teleconferencing (optional)

When connected, there are opportunities for collaborative applications such as video or data conferencing, video phone or software phones to keep the user in touch.

A wide variety of teleconferencing applications are emerging based on standards set by the ITU-T. Many of these may be applicable to this class of device when connected either high speed or on lower speed POTs connections. Although these applications are optional, use of the appropriate ITU-T standards is required when implementing these applications. For example, T.120 addresses data conferencing, H.323 addresses video communication over LANs and H.324 addresses video conferencing over an analogue (POTS) telephone line.

Disconnected Operations

Persistent Storage Considerations

Persistent storage is needed for disconnected operations and to allow restart without reloading the base code (operating system kernel and optionally a set of key applications) from the network when powered on or restarted. The hardware technology is not specified.

Storage for resident or persistent programs

This would include the base code. Considerations for application selection would include size of the program and whether it was needed during disconnected operations as well as the amount of storage available in the device. Programs loaded and cached from the network may also be potentially saved for disconnected operations.

Storage for data

Persistent storage is necessary for disconnected operations. File or object replicas or caching may be necessary or desirable for some applications such as off-line web browsing. The minimum storage size is actually dependent on the device, operating environment (hardware and operating system), the class of mobile device, and ultimately on the kind and size of applications and data used. Persistent storage is required, but a minimum can not be stated.

Data Synchronization

Persistent storage allows data on the Mobile NC to be modified independent of the server connection, i.e. when disconnected. Therefore some form of data consistency and replication must be provided between the Mobile NC and the server. An example could be replicating your mail from the server to the Mobile NC before a trip, working on the mail while disconnected on the plane, and resending and resynchronizing with the server when a suitable connection is available. Other examples include offline Web browsing, file synchronization or calendar updates.

Since standards do not exist in this area, we have provided a model and description of requirements for persistent storage and data synchronization. High function devices may include sophisticated policy decisions for synchronization and conflict resolution, while low function devices may decide to adopt simpler models. There is a wide range of data storage abstractions available including database, document-based management systems such as Notes, and general file systems. For simplicity, the first version of this standard will use a file system based approach. As an example, the following describes the requirements for a caching file system that provides both a named persistent space and data synchronization.

A caching file system provides a basic model for a Network Computer's base operating system, application programs, and data. The Mobile NC contains replicas of data files from the server, where the primary copies reside. The file system can capture the changes made on the file access level, and may therefore schedule synchronization activities automatically.

Requirements for such a caching file system include:

• Access to local cache storage.

• A remote file system client, such as NFS.

• A file monitor layer that is capable of recording file access operations on the client (optionally the server).

• A file synchronizer that is triggered by system policy and utilizes timestamp and file type information to synchronize the cached local copy and the remote master files

• Optionally, for administration only, a user interface for configuring management policies of synchronization, remote backup, etc.

• Optionally, application-specific or file-type-specific resolution of conflicts can be utilized (e.g. the calendar update).

When connected through a low-speed and/or high-cost link, it may be desirable or necessary to restrict or weaken functional capabilities. For example, to reduce data traffic, it may allow read access only, defer the synchronization of changes, skip checking for updates and allow reading of a cached and potentially old copy, or ship deltas incrementally.

The level of disconnected support will vary based on the device class and the applications. Conflict resolution strategies, user intervention or restrictions may be required in some scenarios.

Other memory requirements

One simple scenario is to down-load a Java Applet, disconnect from network, execute the Applet and temporarily store the results until network connection is established. Again, the minimum storage is dependent on the operating environment and the class of Mobile NC, which in turn, determines the complexity of the Applets being run. (In this scenario, dependent classes of the Applet must also be pre-loaded or available in local storage during disconnected execution.)

Queuing operations

When disconnected, the user may request an operation that requires something from the network. In some cases, the request can be queued, but in others the user may want an option or automation to dynamically connect and process (or cancel) the request. Qeuing operations can occur at the client side or on the server side if new data has arrived.

Intellectual Property