arch.xml

The Kannel Open Source WAP and SMS gateway works as both an SMS gateway, for implementing keyword b

</sect1>

<sect1>
<title id="sec.prewap">Pre-WAP solutions</title>

	<para>Current (GSM) networks have two ways of implementing
	services for mobile phones: normal voice calls and short
	textual messages (SMS messages).</para>

	<para>A mobile phone can be used to make a normal voice call
	to a service number, which is typically answered by a computer.
	The computer plays recorded voice messages, and the user can
	interact by pressing the number buttons on his phone. This
	is awkward and slow, and if there is any information that
	needs to be saved, the user needs to make notes with a pen
	and paper. This is uncomfortable enough that it is not a viable
	solution except in very rare cases.</para>

	<para>SMS messages are short textual messages (up to 160
	characters) that are sent from or to GSM phones. Similar
	functionality exists in alphanumeric pagers in the US, and
	elsewhere. The messages are sent to a particular phone number,
	and can be processed by a computer. The computer can then send a
	reply message. This allows many simple services. For example, one
	could implement a service where by sending the words <literal>WEATHER
	HELSINKI</literal> to a given number, one could get the current
	weather forecast for Helsinki in reply.</para>

	<para>SMS based services fill most business requirements
	given in the previous section. They work in current networks,
	and a billing infrastructure already exists. They are not,
	however, very user friendly, since the messages are short,
	and it is difficult to memorize long lists of service keywords
	and arguments.</para>

	<para>An additional current option is to run a dial-up Internet
	connection over a GSM data call. The phone would then use normal
	HTTP to fetch normal HTML pages. This is doable immediately, and
	requires modification to the phone only. The mobile network and
	the services can exist as they already do.  The main problem is
	that existing HTML pages are written in such a way as to require
	fast connections, fast processors, large memories, big screens,
	audio output, and may require fairly efficient input mechanisms.
	That means they can be made attractive for users of traditional
	computers and networks.  However, portable phones have very
	slow processors, very little memory, abysmal and intermittent
	bandwidth, and extremely awkward input mechanisms. Most existing
	HTML pages simply will not work on them, nor will they ever
	do that. Even simple HTML pages with minimal markup will be
	hard to use on a display with only a few lines of text with
	a few words each. Content needs to be specially tailored for
	such small screens.</para>

	<para>Even if content were tailored, normal HTTP is fairly
	verbose for use in a mobile network with slow bandwidth.
	An HTTP request constists of up to dozens of lines of text,
	or up to a couple of hundred of bytes. This can be made much
	more efficient by using a special protocol.</para>


</sect1>

</chapter>


<!-- -------------------------------------------------------------------- -->



<chapter>
<title>The Wireless Application Protocol</title>

	<para>This chapter explains the goals of WAP, and summarizes its
	history so far. It introduces WML and WMLScript, and explains why
	they are used instead of the normal Internet languages (HTML,
	Java, JavaScript, and other formats). It explains shortly the
	on-the-air protocols of WAP, and why the normal TCP/IP or other
	existing protocols weren't chosen, and the role of the gateway
	in translating between air and Internet protocols. It covers
	features such as sessions.</para>
	
	<para>This section also covers the current status of WAP (what
	is implemented and in use, and market penetration), and the
	expected future, with GPRS (and wouldn't it be sensible to use
	HTTP with GPRS?), UMTS, and 3G coming (and I need to look up
	what those acronyms mean). XXX does it?</para>


<sect1>
<title>Goals and history of WAP and the WAP Forum</title>

	<para>The WAP Forum, which creates and maintains the WAP
	specifications, was founded in June, 1997 by Ericsson, Nokia,
	Motorola, and Unwired Planet (later Phone.com, later Openwave
	Systems). The  1.0 specification was published in April,
	1998, but wasn't implemented in phones. The 1.1 specification
	came out in July, 1999, and was the first one implemented in
	publically available phones. 1.2.1 came out in June 2000, and 
        phones implementing it (and specially push) are now available, 
        too. Work on WAP 2.0 is closing. It will converge WAP with Internet 
        protocols and W3C markup languages.</para>

	<para>The goal of the WAP Forum is to develop an open, freely
	licensed specification that is not tied to any network technology,
	nor to any specific device. They want to do this in a way that
	is as compatible as possible with existing Internet technologies,
	to allow existing content providers to use existing content when
	creating mobile services.</para>

</sect1>

<sect1>
<title>The WAP architecture</title>

	<para>WAP is a collection of languages and tools and an
	infrastructure for implementing services for mobile phones. WAP
	makes it possible to implement services using hyper-text,
	similar to the World Wide Web.</para>

        <para>Here WAP Push and Pull are handled separately, because 
        they are, indeed, very different services. Meaning of these 
        terms will, hopefully, come clear later.</para>

	<para>WAP pull does not bring the existing content of the Internet
	directly to the phone.	As discussed in <xref linkend="sec.prewap"
	endterm="sec.prewap">, existing content is unlikely to display
	properly on a phone anyway.  Instead, WAP defines a completely
	new markup language, the Wireless Markup Language (WML), which
	is simpler and much more strictly defined than HTML, making it
	easier for the hypertext browser in the phone to interpret and
	display it.  WAP also defines a scripting language, WMLScript,
	which all browsers are required to support. To make things even
	simpler for the phones, WAP even defines its own bitmap format
	(Wireless Bitmap, or WBMP).</para>

	<figure>
	<title>WAP architecture</title>
	<graphic fileref="wap-arch#FIGTYPE#"></graphic>
	</figure>
	
	<para>WAP defines a protocol semantically equivalent to HTTP,
	but being in a binary and compressed format it reduces the
	protocol overhead to a few bytes per request, instead of up
	to hundreds of bytes. However, to make things simpler also for
	the people actually implementing the services, WAP introduces
	a gateway between the phones and the servers providing content
	to the phones.</para>

	<para>The WAP gateway talks to the phone using the WAP protocol
	stack, and translates the requests it receives to normal
	HTTP. Thus, the content providers can use any HTTP servers, and
	can utilize existing know-how about HTTP service implementation
	and administration.</para>
	
	<para>In addition to protocol translations, the gateway
	also compresses the WML pages into a more compact form, to
	save bandwidth on the air and to further reduce the phone's
	processing requirements. It also compiles WMLScript programs
	into a bytecode format.</para>
	
</sect1>

<sect1>
<title>WML and WMLScript</title>

	<para>Content and services in WAP are presented to the phone
	using the Wireless Markup Language (WML) and the WMLScript
	programming language. WML is a simple markup language defined
	with XML and is used to mark the contents of the file as
	actual text, title, hyperlinks, etc.
	
		<footnote><para>Using XML gives some syntactical
		benefits, such as fairly simple rules for parsing,
		which means that the parser in the WAP browser in the
		phone can be kept simple. It is also likely that the
		WAP gateways and the browsers in the phones will not
		tolerate syntactic and semantic errors in WML pages very
		well. Much of the complexity in WWW browsers is a result
		of having to cope with numerous versions of HTML, some
		of which conflict with each other, and accomodating for
		bad HTML in a heroic attempt to present the user with at
		least something interesting from the web page. Since WAP
		browsers are embedded into phones, and phones won't be
		upgraded as easily or as often as WWW browsers, WML needs
		to evolve much more carefully than HTML has done and WML
		pages need to follow the specifications.</para></footnote>
	</para>
	
	<para>A WML page is a <glossterm>deck</glossterm> of
	<glossterm>cards</glossterm>. One card at a time is displayed
	by the phone. It is possible to switch between cards on the same
	deck quickly, since the whole deck is downloaded at once. A WAP
	application might fit onto one card, or be divided into several,
	depending on its size and how big decks the phone accepts.</para>

	<para>WMLScript is a simple programming language based on
	ECMAScript and JavaScript, which are usually but not always
	implemented in WWW browsers. A WAP browser is required to
	implement WMLScript.  WMLScript is used to make WAP pages
	more dynamic. It is not always enough to provide only a static
	page. The application might, for example, use WMLScript to let
	the user only fill in valid values into a form. The validation
	can be done on the content server as well, but then it will need
	to be sent there and the result needs to be fetched back. This is
	both slow and potentially expensive, if a new connection to the
	gateway needs to be established.</para>
	
	<para>WMLScript also defines a number of libraries for
	controlling phone functionality.  This could, for example,
	be used to implement better phone book browsers than what is
	implemented in the phone itself.</para>
	
	<para>A WML page is typically provided by the content server
	in its textual form, and the WMLScript code as source code. The
	gateway will then translate WML into a binary format, which is
	more compact, and WMLScript into bytecode, which is simple for
	the phone to execute and requires no CPU intensive parsing on
	the phone. The phones typically can't handle textual WML or
	WMLScript source code, but rely on the gateway to do the
	translations.</para>

</sect1>

<sect1>
<title>The WAP protocol stack</title>

	<para>The WAP protocol stack takes care of transporting requests
	for pages from the phone to the gateway, and transporting the
	pages (possibly converted to a binary form) back to the phone. The
	protocol stack consists of three core layers:

		<itemizedlist>

		<listitem><para>Wireless Datagram Protocol (WDP): Moves
		single packets to and from the phone. This is the
		lowest level layer defined by WAP. It is implemented
		on whatever suitable mechanism is available on the
		underlying network. For TCP/IP networks, it maps
		directly to UDP packets.
		</para></listitem>

		<listitem><para>Wireless Transaction Protocol (WTP):
		Implements a single request-response pair between
		phone and gateway. The request may be for a new
		page, or it may be something related to the higher
		level protocols.
		</para></listitem>

		<listitem><para>Wireless Session Protocool (WSP):
		Takes care of handling actual requests for pages.
		Sessions are used to optimize bandwidth usage.
		</para></listitem>

		</itemizedlist>
	</para>

	<para>A representative use case for the protocol is shown
	in <xref linkend="wap-session">.

		<orderedlist>

		<listitem><para>Phone opens session, using WSP. Phone and
		gateway negotiate protocol features and HTTP headers to
		be used in requests gateway makes on behalf of the phone.
		</para></listitem>

		<listitem><para>Phone sends URL for the page the user
		has configured as his home page. </para></listitem>
		
		<listitem><para>Gateway makes HTTP request, with
		negotiated headers.  </para></listitem>

		<listitem><para>Gateway encodes page in a binary form
		and sends it to the phone.</para></listitem>

		<listitem><para>User shuts down the browser and the
		phone terminates the session.  </para></listitem>

		</orderedlist>

	</para>

	<figure id="wap-session">
	<title>A representative WAP session</title>
	<graphic fileref="wap-session#FIGTYPE#"></graphic>
	</figure>

	<para>The behavior of each end of the WAP connection is defined by
	a set of layer-specific state machines, which define the handling
	of timeouts and other errors. We shall not discuss these at any
	length, since the details are not relevant this document.</para>

	<para>The WAP protocol stack contains several additional
	optional layers and optional features of the layers we
	have mentioned. These are not interesting for the discussion
	of the design of Kannel.</para>