This chapter is from the book
This chapter is from the book
This chapter is from the book
Delivery Protocols
The underlying protocol stack employed on the DoCoMo PDC-P network comprises the physical (air interface) and signaling layers, the network and transport layers, and the session layer. See Figure 3.3 for an overview of the i-mode protocol stack.
){kind=link}
Air Interface
In Japan, i-mode is provided over a PDC voice network upgraded to handle packet data (now referred to as the PDC-P network). The air interface is established between the MS and the cell base station, which is upgraded with a Packet Processing Module and a Packet Gateway Module.
Figure 3.3 The i-mode protocol stack makes use of HTTP and SMTP and the URL naming convention.
From the i-mode Web site designer's point of view, the details of how the air interface transmits packets are largely irrelevant. Aside from questions of latency, this interface can safely be considered as just another link in the packet-switched network connecting the Web server to the client. The air interface does suffer from latency and session management issues, and users in Japan do see a higher incidence of lost packets (no response to a URL request) on i-mode than on end-to-end wired networks. Different operators' implementations of i-mode (using newer base stations and faster packet networks), however, could expect to see improvements in these issues.
These problems can be reduced by carefully adjusting session time-outs and ensuring that Web site content does not exceed network limitations (see the next section).
Network and Transport Layers
The network and transport layers are almost identical to the existing NTT DoCoMo Do-Pa packet communications network; although Do-Pa can handle speeds as high as 28.8Kbps, i-mode operates at 9.6Kbps.
Although packet switching is more efficient with bandwidth than circuit switching (and provides the always-on functionality), the i-mode network designers felt that the majority of traffic would be text and simple graphics, making the redundancy built into TCP/IP unnecessary. Therefore, at the Mobile Station and Message Packet Gateway Module (M-PGW), i-mode implements a DoCoMo-developed packet-switching protocol, named Transport Layer Protocol (TLP), designed to be less bandwidth intensive than the Point to Point Protocol (PPP) and TCP/IP used by the Do-Pa system. At the gateway server and the M-PGW, i-mode does implement TCP/IP. As you will see in Chapter 4, "The i-mode Business Model," DoCoMo will implement full TCP/IP on its new W-CDMA 3G network.
Note
The NTT DoCoMo Do-Pa packet-switched cellular network is used to provide a number of commercial services, including remote communications with vending machines equipped with the company's Mobile Ark wireless transceiver. Vending machines can report stock levels, coin levels, and other data (like ambient temperature) to a central database. Coke has an estimated 10,000 Mobile Ark-equipped machines in service in Hokkaido.
Session Layer
Above TCP/IP (on the gateway and M-PGW) and TLP (on the M-PGW and MS), i-mode implements HTTP and SMTP as well as the DoCoMo-developed User Information Transfer Protocol (UITP). UITP is used to manage sessions between the MS and the GRIMM gateway, using a Mobile Subscriber Number unique to each MS.
Also, Network Management Protocol (NWMP) is implemented between the M-PGW terminals and the i-mode gateway to provide for communication termination signaling, message-waiting notification (an email message, for example), and the packet communication status between the M-PGW. On the TDMA/GPRS network that is expected to be implemented by AT&T Wireless for i-mode in the United States, network management is achieved by the GPRS Mobile Management/Session Management (GMM/SM) protocols.
Packet-Switching Characteristics
The packet-switched overlay on the PDC network allows for "choppy" transmission, which is useful for services like Web browsing, where a circuit-switched system incurs substantial time-use fees and lengthy call setup waiting times (one of the most serious criticisms of early WAP implementations). As a result, i-mode has an "always-on" look and feel. Also, the PDC-P network is reasonably fast, and data receipt times (depending on time of day and other factors) can be as little as one to three seconds. (When sending email from his i-mode phone to his office desktop PC, this author regularly sees a total wait time—for accessing the network, sending the mail, and logging off—of about five seconds.)
Circuit-switching operation is one of the strongest sources of criticism against WAP 1.0 and 1.2 services implemented so far (despite the fact that WAP does not require circuit switching). The problem comes from early WAP deployments on circuit-switched GSM networks. Setting up a GSM circuit-switched data (CSD) call takes several seconds to initiate, several more for handshaking, and then several more for logon and user authentication. i-mode suffers from none of this hassle.
Note
Spanish carrier Amena has been testing a GPRS data overlay on its GSM voice network since November 2000. The carrier has implemented a WAP network, and GPRS data packet latency (from the WAP client phone to the gateway) was reported in May 2001 to be 0.9 seconds against an average round-trip time of 1.8 seconds—about the same latency as on existing WAP networks on circuit-switched GSM systems.
The result? "Don't sell performance as an advantage of GPRS; better speak about low cost, always on, push services, etc.," says one mailing list posting. Of course, it's still early for GPRS, and the technology will undoubtedly improve.
Note
For more information on WAP on GPRS, sign up for the WAP Group, at http://www.smartgroups.com/groups/wapgroup.
Network Limitations
In Japan, i-mode Web pages are limited to 5KB, and mail messages are limited to 500 bytes. With packets set at 128 bytes, the largest Web page (cHTML file and all graphics) must then fit within 32 packets (4096/128). Anything additional is discarded at the MS. Again, keep in mind that these are DoCoMo i-mode–specific limitations, and other operators can be expected to adopt either more stringent or more flexible limits.
Protocol Implementation
As described in Chapter 1, The i-mode Phenomenon makes use of standard tried-and-tested W3C protocols to provide wireless information services, like mail and Web access. Although the choice of commonly used protocols is not absolutely required, this situation accounts for a large part of i-mode's success and contrasts starkly with the WAP use of new proprietary protocols that have failed to win wide acceptance.
HTTP
The i-mode wireless information service uses a proprietary cHTML-compatible microbrowser in the application layer on the MS. The microbrowser sits on top of a protocol named Application Layer Protocol (ALP), developed by DoCoMo as the mobile client-side version of standard HTTP. The conversion between HTTP and ALP is transparent to the subscriber and to the sending Web server. It reduces client burden by removing HTTP header data (which is not needed by the Mobile Station), instituting a termination notification signal and converting SMTP mail text to cHTML format. The latter allows the microbrowser to act as the onboard mail client. ALP also provides for housekeeping tasks, such as confirming that sufficient memory is available to receive mail messages before the push download.
As a result, any standard Web server that is compliant with the HTTP protocol can send Web content to an i-mode phone. The microbrowser also uses the standard Uniform Resource Locator (URL) naming convention.
cHTML
The cHTML specification was submitted to the World Wide Web Consortium (W3C) by Dr. Tomihisa Kamada, the CTO of Tokyo-based Access, maker of the Compact NetFront cHTML-compatible microbrowser that sits on the majority of all i-mode phones in Japan. Kamada, working with representatives from Matsushita, NEC, Fujitsu, Mitsubishi, and Sony, compiled the draft specification in February 1998. The microbrowser now supports cHTML, which is a defined subset of HTML 2.0, 3.2, and 4.0. cHTML does not support tables, image maps, multiple character fonts or styles, background colors or images, frames, or style sheets. The only images used on i-mode are GIF and animated GIF.
Tip
Dr. Tomihisa Kamada says, "Compact HTML is defined so that all basic operations can be done by a combination of four buttons: Cursor Forward, Cursor Backward, Select, and Back/Stop (return to the previous page). Any functions that require two- dimensional focus pointing, like image map and table, are excluded from Compact HTML." (Extract from the cHTML submission to the W3C. For details of cHTML, access http://w3.org/TR/1998/NOTE-compactHTML-19980209.)
The current NTT DoCoMo version of i-mode implements several specific extensions to cHTML, including the <tel> and <accesskey> tags. The <accesskey> tag permits the Web programmer to present a numbered list of hotlink items that can be selected by pushing the corresponding numeric keypad button. Also, NTT DoCoMo has implemented its own icon library (mentioned briefly in Chapter 2), known as emoji in Japanese (e means electronic, and moji means character). The emoji icons consist of smiling faces, hearts, and other designs intended to make sending short email messages more convenient. Note that because emoji are not recognized as part of any official character set (like ShiftJIS 6879 or any of the western ISO character sets), i-mode operators outside of Japan are unlikely to adopt them to increase compatibility between Internet standard email and Web pages.
Also note that the cHTML has in no way been adopted as an approved standard by the IETF. The cHTML submission status is formally that of an "acknowledged submission."
Mail (SMTP)
i-mode mail is based on SMTP mail, with some accommodations made for network and MS limitations. We've already mentioned the 500-byte text limit, and that attachments are not allowed. Also, each subscriber is limited to storing 50 mail messages at any time, and messages are pushed out to the MS as soon as they are received (packet fees apply for receiving messages).
Mail storage on the MS varies from handset to handset (depending on the amount of memory onboard). For example, the Panasonic P209, one of the more popular 2000 models, stores as many as 200 messages. When the 201st message is received, the oldest existing message is automatically overwritten.
In i-mode, no implementation of Post Office Protocol (POP3) allows the subscriber to manage mail between the MS and the gateway, such as choosing to leave certain messages on the server. The MS automatically sends a delete instruction to the GRIMM gateway after a mail message has been received at the handset. This setting, which is beyond user control, is not part of most wired network SMTP implementations where the mail client can be customized. The GRIMM gateway stores as many as 50 i-mode mail messages for 30 days. If a subscriber's mail account becomes full, new messages are bounced back to the sender.
These limitations, arbitrary choices of the i-mode operator, have more to do with NTT DoCoMo concerns with swamping the PDC-P network and with MS hardware limitations as much as anything else. i-mode services in the United States and Europe could offer more liberal limitations, considering that handset technology is improving and that network operators could set up additional server farms (cost not withstanding).
Mail (SMS)
SMS messages (See Chapter 2) can consist of as many as 25-double byte characters, and the recipient's mobile phone number serves as the mail address. When a recipient's phone is turned off or out of range, DoCoMo saves as many as 20 messages on the network SMS mail server for 72 hours. SMS messages are also pushed to the MS. SMS mail appears in the same inbox as i-mode mail, although the data is handled as part of the PDC circuit-switched network and not the packet-switched overlay, and therefore usage is billed based on time, not packets.
Although NTT DoCoMo hasn't released firm data, SMS usage is apparently quite low. Neither NTT DoCoMo nor any of the other operators in Japan allows their networks to exchange SMS mail with each other or with networks in Europe or the United States.
Microbrowser
The Compact NetFront v2.0 microbrowser supports cHTML and GIF images, and it requires an onboard hardware environment having at least 5–15 million instructions-per-second (MIPS) CPU, 300KB of ROM, and 150KB of RAM. The microbrowser supports the NTT DoCoMo i-mode cHTML extensions (the emoji mentioned earlier) and presumably could support similar extensions from other operators. It is CPU and OS independent and integrates with SSL and Java.
The Compact NetFront browser, like all i-mode microbrowsers, is optimized for display- and CPU-constrained devices. (Several i-mode cell phone makers, notably Nokia and Panasonic, have deployed their own proprietary browsers.) All i-mode browsers provide i-mode mail integration, bookmark functionality, and limited caching. i-mode browsers also provide visual indicators that show, for example, when the MS is in cellular contact range, when it is sending or receiving data, and when mail has arrived.
Access has announced the release of the Compact NetFront Plus browser for late fall 2001, which will be compatible with xHTML as well as with WML and cHTML. This subject is covered in more detail in Chapter 7, "Current and Future i-mode Capabilites."