Workshop on Pervasive Computing: Going Beyond Internet for Small Screens. 17th Annual ACM Conference on Object Oriented Programming, Systems, Languages, and Applications (OOPSLA 2002), 4-7 November, 2002, Seattle, USA.
Software Architecture for Mobile Internet Service Platform
Christopher J. Pavlovski IBM
Global Services Wireless Practice, Australia
chripavl@au1.ibm.com
Abstract: The i-mode services platform is a unique business model that benefits service providers, the network operator, device manufacturers, and the customers. The current NTT DoCoMo solution is deployed to the PDC network, available only in Japan. Presently, several arguments have been put forward as to the success of i-mode in Japan, however such erudition has done little for other mobile operators from gaining any tangible advantage over its competitors in the mobile environment. We argue that the key observation to be made is that the success is not strictly about the underlying technology, but rather the unique business model that has been developed by NTT DoCoMo. This paper presents a reference architecture for building the Mobile Internet Services Platform, i.e, an ‘i-mode like’ platform, on a GSM packet switched GPRS network. The key theme of the reference architecture is to address the requirements of the successful business model that has provided NTT DoCoMo with overwhelming success.
1
Introduction
The overwhelming success of i-mode in Japan is renowned, with some 50,000 new subscribers every day [Mori]. These accomplishments of NTT DoCoMo represent the wireless success story that many other mobile network operator’s envy. The success is suggested, in contrast to WAP, to be attributed to several factors including availability of content, ease of use, competitive pricing models, reliability, and responsiveness [HRL]. In addition to these elements, a closer inspection of the underlying mechanisms involved reveals that i-mode also furnishes an end-to-end security model, an area where present WAP solutions are trailing. To date no other mobile network operator outside of Japan1 has been able to replicate the
success of NTT DoCoMo.
In this paper we suggest that the successful business model developed by NTT DoCoMo is the key element to furnish in any proposed solution. We use the term business model here to define the ways in which all parties involved are able to generate revenue from the fourth party, the customer (this is perhaps the most important consideration that is often overlooked). The business model must also consider what prevailing commercial dynamics will influence the customer to take up the mobile services on offer. By translating the definedbusinessmodelintoa clear set of requirements,
we propose a reference architecture for implementing such a solution. The reference architecture is also further refined from our experiences in building and deploying similar, wireless portal, solutions globally on alternative mobile network environments. As such, we propose a Mobile Services Platform that fosters the key business principles of i-mode, whilst considering the different needs of the GSM/GPRS mobile network and WAP based technologies.
1.1
Contribution
This paper identifies the critical elements of the underlying business model of the i-mode platform. In the understanding of these critical elements, we then define the requirements that alternative solutions are to satisfy. We then propose a reference architecture for building a Mobile Internet Services Platform (i.e. an i-mode like service) for other non-PDC networks, such as the GSM (GPRS) mobile network, that rely on alternative technologies such as WAP. Moreover, the solution presented is intentionally generalised so that any mobile network technology may be considered2.
By exploring the business model as a set of requirements, we are able to detail the key architectural decisions to be made and define a set of architectural principles to be preserved. Together with the business model understanding, the reference architecture is refined by our collective experiences in deploying related wireless solutions globally for alternative network environments. We view the following as the major contributions made by this paper:
• We survey the contributing factors to the i-mode success as a function of the business model. This is viewed from the perspective of the customer, service provider, device manufacturer, and the mobile network operator.
• We argue that the key factors to ensure success outside Japan is the low cost of service to customer through packet based technologies such as GPRS, ensuring an environment that reduces cost of deployment for Service Providers, and to foster customer accessibility and availability of content.
• We define a set of requirements and propose a reference architecture against these requirements for building a Mobile Internet Services Platform on alternative mobile network environments (such as the GSM mobile network).
1 Korea is also now experiencing similar success to Japan.
The next section provides some background to NTT DoCoMo, i-mode, and the mobile (or wireless) Internet domain. This is then followed in section three with an analysis of the key features of the NTT DoCoMo business model, where we also define the requirements to be addressed. In section four, a reference architecture to address the business model requirements is then proposed.
2
Background
In general, details surrounding the i-mode solution platform are sketchy at best. One can assume that this is for good reason; to protect a revenue cash cow that other network operators would be enthusiastic to reproduce. In spite of this cladenstine approach, sufficient resources and literature are generally available to develop a generalisation of the solution and the supported business model [NTT, West, Euro, HRL, Funka, Funkb, Devine, Roze].
Infrastructure Provider Customer Base
i-mode 29.3 million
J-Sky 9.0 million
EZweb 8.8 million
Total 47.1 million Table 1. Mobile Internet Subscribers (Jan 2002)
Before proceeding to elaborate upon NTT DoCoMo we first illustrate the relative market share of i-mode in Japan and its local competitors EZweb and J-Sky, see Table 1 [MMJ, Will]. It is straightforward to see that i-mode is the dominant player. It is also interesting to note that the other service providers have a non-trivial customer base and that one of these solutions is based upon WAP (we shall discuss the significance of this observation further in sections 3 and 4).
2.1
NTT DoCoMo
NTT DoCoMo was formed in July 1992 from its parent company Nippon Telegraph & Telephone (NTT). The Japanese Ministry of Posts and Telecommunications (MPT) forced NTT to standardise its PDC digital network to foster competition. Prior to this the PDC network was a proprietary standard supported by NTT. The majority of engineers who had developed the PDC network were transferred to NTT DoCoMo. NTT DoCoMo had an arrangement with it four phone suppliers (Matsushita, Mitsubishi, Fujitsu, and NEC) whereby advances in technology to handsets were provisioned to NTT DoCoMo handsets in the first instance, and withheld from other handset for a period of six months. This made NTT DoCoMo handsets the preferred option for customers offering better weight, size, and battery time. The suppliers in return obtained additional information regarding the PDC standards. The PDC standard was poorly documented resulting in prolonged problem resolution in developing mobile phones and extensive testing due to unknown incompatibilities [Funkb]. The additional information
also contributed to the better designs into the overall product.
The dominant position that NTT DoCoMo had established was being eroded by other competitors when design advantages diminished due to mass market production of cellular phones and their components. This initial dominance has been further utilised however, with the introduction of the i-mode service in February 1999.
2.2
The i-mode Service
The i-mode service is a collaboration of four entities. These are the mobile customers, the service providers, device manufacturers and the infrastructure provider (NTT DoCoMo). Perhaps the best way of defining i-mode is by directly citing from the i-mode FAQ [West]:
First introduced in Japan in February 1999 by NTT DoCoMo, i-mode is one of the world's most successful services offering wireless web browsing and e-mail from mobile phones. Whereas until recently, mobile phones were used mostly for making and receiving voice calls, i-mode phones allow users also to use their handsets to access various information services and communicate via email.
Fundamentally, the i-mode service is about extending the Internet and services offered over the Internet to users of mobile phones. However a new and innovative range of services may be provided to the users since they have the freedom of mobility and are always contactable. This may include location based services, entertainment, and ad-hoc information services.
The i-mode platform is based upon a straightforward suite of technologies that include a packet switched data network and a restricted set of HTML referred to as compact HTML, built specifically for its PDC mobile network. In addition, NTT DoCoMo have considerably influenced the device manufactures to ensure that consumers devices are enhanced significantly and with user friendly access to the i-mode services offered. Currently Service Providers use the i-mode platform as a portal to vend their services to NTT DoCoMo’s large customer base. When the platform is extended to i-mode phase II several additional services will be available to Service Providers including the Java handsets, music capabilities, and location based services [Mor].
When NTT DoCoMo launched its service the original intent was to focus on the businessman, but as NTT DoCoMo experience with the platform grew it was evident that the younger consumer market was emerging as the more dominant market segment. Furthermore, this younger market would eventually mature to the business sector and other commercial environments, representing a seed in the future of the i-mode service.
2.3
Related Work and Terminology
success has taken place [HLR, Devine, Funka, Funkb, Pik]. However there has been no substantial work to translate this understanding into a reference architecture as an implementable solution for alternative mobile networks. In this paper we extend the previous research by surveying the business model factors contributing to NTT DoCoMo’s success, interpreting these as requirements, and proposing a reference architecture for alternative mobile networks (and their underlying technologies).
3
Reference Architecture
In this section we now outline an architecture for mobile internet operators that enables the delivery of content and services to mobile devices. This architecture fosters the key principles addressed by the mobile internet platforms in Japanese telecommunications market. However, a key differentiator is capability to support the diverse range of technologies applied in other geographies such as the Europe and North America.
3.1
The Architectural Principles
The key architectural observation to make regarding the Mobile Internet Service Platform (MISP) is that transactions originating from the Internet must be authenticated, authorized, re-directed, and serviced by the MISP Provider as quickly as possible. Hence we suggest that a fundamental philosophy is that the platform is a high performance transaction processing engine. Every architectural decision must be in consideration of this notion so that the performance of the solution is not compromised. Since now the platform not only impacts the customers mobile experience but also has the capability to impair the revenue generating capabilities of Services Providers (SP) attached to the platform – not a desirable outcome.
Use of simple and well understood technologies and standards. For example, HTTP, SSL, HTML would constitute well known and simple technologies that would not unnecessarily burden SP’s and the MISP provider with development costs (these being widely supported by Internet packages).
Enhance attractiveness of the MISP to the SP’s by fielding several key services that reduce the inherent development effort (and hence cost) required to deliver a service to a customer base. For instance billing services, device abstraction, and location services. Therefore another key architectural principal is to ensure that common functions are provided within the platform. As the term platform suggests, this is an architectural base from which further constructions may be built upon. In addition, the use of the term common function is not to imply that each function supported be feature rich, but rather the intention is to start with range of vanilla functions, so that the business model may indeed initiate.
And finally (and perhaps most importantly), we suggest that the accessibility for the customer be
considered. Already discussed in the context of the business model is the fine tuning required to ensure that the cumulative costs associated with accessing the services bet set so as not too impede service take-up, since this is the customer base from which the infrastructure provider attracts additional Service Providers.
3.2
Physical Topology and Components
The following diagram, Figure 1, illustrates the physical topology of the reference architecture. The individual components of this diagram will be described in the sub-sections that follow.
It must be pointed out that the proposed architecture addresses the technical needs of the problem domain addressed and also the needs of the business model (in order to foster the success). For instance, device independence is a requirement, however the cost of building and deploying services by the SP must be suitably attractive so that there is no short supply of appropriate sites for customers to access. That is, we propose a reference architecture that is inviting for the SP to build and deploy applications, and which also provides a solution that attracts customers, and of course provides a range of revenue generating opportunities for the MISP infrastructure provider.
3.2.1 Trusted Gateways
The trusted gateways, physically composed of the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN), are required to convert the WAP protocol specific traffic into generic HTTP traffic, but have a more important role in supporting the MISP. To ensure a cost effective service requirement for customers we suggest that packet based mobile network environments (such as GPRS) are mandatory. That is, for the business model to work under a GSM network, GPRS is essential in creating a reduced cost service for customers. From this point we assume that an economical, i.e. GPRS, packet based network is provided.
An additional (and perhaps crucial function) of the WAP gateway is the ability to hide or reveal the identity of the calling customer (this feature is not widely available and requires customisation of the base products). This may take the form of the MSISDN, the IMSI, or some other temporary identifier3 (the identifier
may be allocated on a per session basis or may be a, longer term, fixed pseudonym – which will be largely dictated by the general privacy concerns. The use of a per-session identifier also overcomes the requirement to encrypt identifiers.). This is crucial as it is the fundamental mechanism that may be used to support the customer retention requirements of the overall solution, (i.e. assists the MISP provider in maintaining ownership and relationship with the customer).
3 Where the SP intends to conduct further authorization checks
Once a customer is authenticated, i.e. confirmation that the mobile customer is a valid user of the platform, the customer is redirected to the appropriate SP. At this point the SP authorizes access to the products and services available (this can be achieved by the SP itself or in conjunction with the MISP). In order to accomplish this, the SP requires the use of some trusted unique customer identifier that is also recognised by the MISP. This must also be recognizable by the platform so that the appropriate billing can be conducted, when presented for the use of platform services such as location and microbilling (see section 4.3.6).
Of course the SP may decide to accept any connection, but then they are burdened with authentication and authorization of these users and the more time consuming function of revenue collections. All of which are services offered by the MISP.
Finally the WAP gateway must provide a cookie proxy. Two alternatives exist to maintain the session state, this is by adding session information to the URL string or by storing the session details within a cookie. Current mobile phones do not support cookies and URL string manipulation is problematic due to URL limitations. Hence a cookie proxy is to be provided by the Trusted WAP gateways. This sub-component supports session state management that is to be conducted by the SP and MISP alike.
3.2.2 Transcoding Server Farm
There are fundamentally two segments within the transcoding server farm. An external segment responsible for manipulating content supplied by the SP’s, and an internal segment which takes care of content produced by the MISP. The User Agent defined in the HTTP request is the means by which specific style sheet selection is performed.
When one considers the ability of several mobile devices, whether this be a mobile phone, a Windows CE device, or some other micobrowser, several approaches may be taken in the generation of content. Here we treat the problem of where both enhanced browsers such as Pocket IE and restricted browsers such as the mobile phone microbrowser are to be accommodated.
The fundamental approach to the generation of content is to ensure that a device category specific form is generated at a tier 1 level by the SP, and then a final device specific translation occurs at a tier 2 level, by the MISP. The objective here is three fold. First, this is not to unnecessarily restrict the content for the more powerful devices, which are available today and almost certainly will become available in the future. Second, we wish to preserve device independence for the SP, and last the intent is not to overly burden the MISP with needless transformation, (i.e. ensure high performance transaction processing), which could otherwise be handled by the SP.
In consideration of the need to conduct a dual transcode of the content, two approaches exist for defining the general form that content should take, this is either as XML or a restricted HTML form which may be further refined. Of the two approaches the restricted Figure 1. Physical Topology
Trusted Gateways
Authentication Servers
B
Palm Win CE
Service Providers
B
Transcoding Server Farm
Authorisation Server
Platform Services
B
B
…
…
Legacy Systems
DMZ
LDAP
Mobile Internet Services Platform
: :
MOM
GPRS Network
WWW
HTML form is recommended. This is for several reasons. The content produced will be readable by not only mobile devices but also the general Internet community, providing the SP with further revenue opportunities. This will contribute to offsetting initial costs and hence increase the potential number of services available. There is a successful precedence of this approach with i-mode, and this approach leverages of well known standards so no additional technical skills are required by SP’s. The resulting content may also be rendered by devices with minimal change by the MISP. To cater for this compact HTML or the W3C HTML 4.0 guidelines for Mobile Access would be suitable candidates [HTML].
3.2.3 Billing Engine
An important component for both the SP and MISP infrastructure provider is the billing Services. In general, the existing billing system of the MISP will be utilized. This is most reasonable since the MISP will have an existing customer relationship, will be able to leverage from its current revenue collection facilities for sending out bills and receiving payments, and will remove the burden and responsibility for this function from the SP (allowing them to focus more on content and service).
Several additional techniques and requirements will exist however, the principal approaches to billing will involve:
Free of charge. Services offered free of charge, for instance registering with the MISP will permit the customer to access several services.
Subscription based Fee. Customers are charged (perhaps monthly) for registered services. This simplistic approach facilitates rapid deployment of both the platform and services.
Data Traffic. The MISP will always generate revenue from the data traffic. Hence this will be captured by the existing mobile network systems.
Usage Based Fees. The customer is charged for use of particular types of services, for instance each time a location based services is used. To support this approach a more complex microbiller is required to ensure that SP’s are not able to falsely charge a customer (via the MISP), or prevent the customer from falsely denying having made a purchase.
There are several additional modes of billing, however the list above is representative. The billing services may be implemented as a set of HTTP interfaces over an SSL VPN tunnel.
3.2.4 Authentication Server (External/Internal) There are fundamentally three discrete user communities accessing the MISP. These are the mobile customers, the SP’s, and the internal MISP support staff (i.e. customer service representatives and system administrators). In each case unique authentication requirements are to be satisfied.
In respect of the customer, authentication may be accomplished in to ways, the first approach is by leveraging from the WAP gateway and the second is via the use of conventional forms based, or HTTP-Basic, authentication for access via a standard Web browser. By establishing the WAP gateway as a trusted host, achievable where the owner of the WAP gateway is also the owner of the MISP4, authentication, conducted under
a WTLS session, may be trusted by the Authentication Server (hence the authenticate server need not perform any additional checks). This may be achieved by using the MSISDN provided to the WAP gateway, which is then inserted into the HTTP request to be forwarded (via the Authentication Server) to Authorisation Server. Where the customer is accessing the MISP via a conventional Web browser, for instance to manage their profile, authentication under a forms based approach, or HTTP basic, will suffice. Note that critical functions such as password changes, should be managed under a strict security policy such as password reset function only, where a new password generated by the system is sent to the customers’ mobile phone, via SMS. Regardless of the specific technique chosen a collaborative Single Sign On mechanism is put in place by ensuring that a common directory is used for the management of user-ids and passwords.
The internal support staff have a similar requirement, however their access is limited to standard web browsers. In addition, a separate (internal) Authentication Server is deployed within the corporate network, i.e. access is from within the Intranet only, to service these requests.
Due to the nature and relationship that must be put in place between the SP and the MISP a more comprehensive authentication approach must be undertaken. Once again the technology of choice for the SP is HTTPS. In a similar fashion to the customer, the SP must be a registered entity to use the MISP. Furthermore each request for a service must be authorized by the MISP. The problem of authentication and authorization is also solved through the use of standard Internet technologies. Mutual authentication of both the SP and MISP is accomplished with the use of a secure SSL session, where each SP (during registration) is allocated a X.509 digital certificate. Authorisation of individual requests for services is then performed when the service call is made.
4.3.5 Authorisation Server
The authorization server determines the access rights of a particular user of the MISP system. For the Wireless customer, the authorization model is structured at a macro (or course grained) level of authorization, whereby a customer is either granted access to a particular service or denied access. The bestowal of access rights to a particular service is performed when the customer registers for that service. The approach to
4 To some extent, overcomes the security exposure when
fine grained authorization involves the allocation of this responsibility to the SP. In some instances fine grained authorisation may be required, however in general is suggested that the individual SP applications should of such granularity such as to not warrant any additional authorization refinement5.
When SP’s attempt to access a default MISP service, the individual requests are authorized at the time of access. In general, the SP will register for one or more services that are relevant to their content or service. For example, an SP that provides downloadable music may not make use of the location engine.
3.2.5 Default Platform Services
The default Platform services are an important element in attracting customers, since these are the services that the customer obtains by merely registering with the MISP. This growing customer base, is also a factor in attracting SP’s to build and deploy content and services. The default platform services may take many forms, however the following list details key services for both the customer and the wireless Service Provider. Customer Platform Services:
Email Translator. Provides the function to send and receive email on the mobile phone. This includes e-mail redirection and e-mail response. Redirection is employed where the user has an email address with a related ISP, automatic forwarding of subject line of email address to user as an SMS message. The ability to response to email messages is provided through the use of a temporary originating numbers that are translated to/from a valid e-mail address. Given that email is the most popular application for teenagers [Roze] it is not practical to overlook.
Registration and Enrollment. Provides customer with the ability to register with the MISP and enroll in one or more services.
Internet Access. Provides the customer with specified on-line usage to browse the Internet. Sites based upon c-html would be readable based upon the transcoding function provided by the internal segment of the Transcoding server farm.
Instant Messaging. Enables a customer to chat, in real-time, with another mobile phone user.
Customer Profile Management. Profile management functions to enable the customer to personalize, modify their details, and configure their service access.
Wireless Service Redirector. The Wireless Service Redirector contains several functions essential to the operation of the MISP. These functions include the insertion of unique customer identifier (or pseudonym), SP URL identification and redirection, URL proxy
5 That is, each wireless service is small in scope to be
representative of fine grain access.
authorisation, and insertion of device category identifier6
for the SP to perform 1st level transcoding.
Service Provider Platform Web Services:
Similar to the Billing Engine, the following web services may be implemented as a set of HTTP interfaces over an SSL VPN tunnel. We use the term Web Service to not only indicate that a Web Service approach may be used but to also delineate between the advertised services to SP’s and the services that customers use – which may also be provided by the SP.
Service Provider Profile Management. Profile management functions to enable the SP to modify their details, register access to MISP services, and manage their billing arrangements.
Wireless Reference Implementation. A wireless reference implementation is provided that illustrates how a Service Provider may build and deploy a solution to deliver a product or service utilizing the MISP infrastructure. This demonstrates how the various platform services may be called by an external application built by the SP. This is an important component that may be easily overlooked, since this will be instrumental in speeding up the delivery capabilities of potential SP’s, and of course will improve the time-to-market of key products and services.
Intelligent Notification. A platform service made available to SPs. Intelligent notification allows the delivery of some notification to a range of formats, (e.g SMS, email, voice). This may be employed by the SP to augment or build their particular service, e.g. on-line chat service.
Location Engine. A platform service made available to SPs. Provides geographical position of the customer. This may be used by a SP to augment or build a particular service, (e.g. ATM, hotel, restaurant finder). A map server may also be provided which takes two positions as input and returns a map with the positions marked.
Billing Engine. A platform service made available to SPs. This enables the SP to charge customers for additional, service specific, use of their content, product, or service. This may be as a pre-paid or post-paid service. As noted previously, this function may also be performed by the SP.
3.2.6 Service Provider (SP)
The wireless service provider is the entity charged with the delivery of new products and services that are provisioned by the MISP. The SP may have one or more systems that are registered with the MISP and which appear on the customers’ menu options.
6 Whilst the User Agent specifies the device used, it is
The MISP is a provisioning agent rather than an aggregation agent, in that all requests for services are redirected to the SP. The set of services provided by the SP may be far ranging. For example: news, locate restaurant, ring tones, on-line chat, and games (both downloadable Java applications that are stand alone or on-line interactive games). The SP accepts authorized HTTP requests redirected from the MISP, and responds with content. Additional requests for services of the MISP are authorized and billed accordingly. Content produced by the MISP is in a simple HTML form, which is further transformed by the MISP for final delivery to the customer.
The Service Provider fundamentally creates applications that make use of the Platform’s advertised services. As discussed, an appropriate way to render the platform services to the SP is via a Web Services approach (with dynamic or static binding). By leveraging from the MISP, the SP is able to focus just on the business logic of the particular customer service they wish to offer – reducing their overall development costs. In this symbiotic relationship the Mobile Service Platform provider is not burdened with the cost of developing all these applications.
4
Conclusions and Summary
This paper has surveyed and defined the critical business model features that contribute to the success of NTT DoCoMo’s i-mode platform. We outline several business requirements that are essential to the i-mode business model. Focusing on these business model requirements we propose a reference architecture, for the Mobile Internet Service Provider, on a GSM/GRPS mobile network that satisfies the business model. The reference architecture, and underlying business model observations, is refined with our experiences in developing similar wireless solutions globally.
We argue that the critical success factor of a Mobile Internet Services Platform is directly linked to the implementation of a successful business model rather than an implementation of successful technologies that underlie the solution. Moreover, if the former occurs the later (improved technologies) will be funded and justified with increased revenue opportunities. We suggest that a cost effective packet network, default platform services, device abstraction, simplified Service Provider deployment, and accessibility proportioned to cost and service, are the key elements to foster in such a solution.
4.1
Acknowledgements
The author would like to thank Shigeru Tachikawa and Nobuhiro Asai for their helpful comments and discussions on this paper.
5
References
[BS] Robert Batchelder. David Smith. Instant Messaging: The Sleeping Giant. Gartner, 17 August 2001.
[Devine] Alice Devine. Mobile Internet Content Providers and their Business Models. Masters Thesis, Department of Electrical Engineering and Management. The Royal Institute of Technology, Stockholm, January 2001.
[Euro] Eurotechnology. The Unoffical independent imode-FAQ. http://www.eurotechnology.com/. [Funka] Jeffery L. Funk. Business Models and
Content/Applications in the Mobile Internet Market: Data from the Japanese Market and implications for Europe and the US. Kobe University, Strategis Group, 2000.
[Funkb] Jeffery L. Funk. Standards, Information, and Complementary Assests: How NTT DoCoMo and its Suppliers Dominate the Japanese Digital Mobile Phone Market. Kobe University, February 1999.
[HTML] HTML 4.4 Guidelines for Mobile Access. W3C. http://www.w3.org/TR/NOTE-html40-mobile/, 2001.
[HRL] Magnus Hartman, John Ragnevad, Johan Linden. Lessons from i-mode. Baskerville Communications, Northstream, September 2000.
[John] Geoff Johnson. Lessons in Mobility from Asia Pacific. Gartner, 12 July 2001.
[Mac] Delia MacMillan. Design Strategies for Wireless Consumer Applications. Gartner, 23 March 2001.
[Mori] Yoko Mori. iMode Phase II. ITU Telecom Asia 2000 Special Report, November 2000.
[MMJ] Mobile Media Japan.
http://www.mobilemediajapan.com/resources/b usiness/, September 2001.
[NTT] NTT DoCoMo Website.
http://www.nttdocomo.com/
[Pik] Victor Pikula. Mobile Internet Services in Japan. Graduation Thesis, Erasmus University of Rotterdam, March 2001.
[Roze] Irene Rozenberg. Analysis of Existing Wireless Communication Protocols. Columbia University, 2000.
[West] WestCyber Corporation. i-mode Frequently Asked Questions (FAQ), 2001.
[Will] Martyn Williams. Japan Ends 2001 with 73M wireless users. Computerworld. Tokyo, Japan. 16 January, 2002.
