arch.xml

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

</sect1>

<sect1>
<title>The duties of a WAP gateway</title>

	<para>This section summarizes the duties of the WAP gateway. The
	basic duty is to implement the WAP protocol stack, as outlined
	in the previous section, so that the user can actually use WAP
	services. Additional duties may include, depending on how the
	gateway is used, user authentication and billing.</para>
	
	<para>The gateway can often identify the actual user. For example,
	if the bearer used is GSM SMS messages, the user's phone number
	is known to the gateway. The gateway can then pass on this
	information to the content services. This is useful when the
	service can use this information to provide personalized service:
	it might remember the user's preferred settings, for example,
	or let him access e-mail without filling in a separate login
	form.</para>
	
	<para>An identified user can also be billed. WAP content can be
	priced in various ways, and if it is to be billed to the user,
	the user needs to be identified. In addition, something in the
	WAP system needs to keep track of what billable items the user
	actually uses, and the gateway is one good place to do this.
	The gateway doesn't actually include a billing system itself,
	but it provides user and usage data to the billing system of
	the operator.</para>
	
	<para>From the user's point of view, the gateway is also
	responsible for optimizing WAP usage as far as possible: the
	gateway should keep the number of packets small, to keep
	costs down and make best use of available bandwidth.</para>
	
</sect1>

<sect1>
<title>WAP Push Architecture</title>
       <para>Previous chapters defined pull mode of operation: a phone starts 
       everything and a content server acts passively. It is, however,
       sometimes useful that the server can start a transaction. Email 
       notifications, news services and stock quotes are some examples of
       this mode of service.</para>

       <para>However, simple pushing a content to the phone causes problems.
       User experience is badly detoriated, if incoming push messages can
       interrupt ongoing tasks. So instead an actual content, one pushes
       Service Indication, which tells that a service has become available
       and contains an URL telling where the user can found it. Then the user
       can accept or reject the service. The phone may confirm that is has
       received the push content.</para>

       <para>In addition of this basic service, <glossterm>PAP document
       </glossterm> defines way to control the push operation. A push 
       initiator can select network and bearer used, set delivery time 
       restrictions and define quality of service.</para>

       <para>SI document contains, too, some additional attributes defining
       more complex services than one defined before. For instance, a push
       initiator can force a SI content to appear on the screen of a 
       phone immediately the phone receives it, or instruct the phone
       to put it into box, so that the user can read it later. It is 
       possible, too, to define a expiring time for a content.</para>

       <para>WAP Push uses established document defining standards, like 
       XML and MIME and its protocols operates over well establised ones 
       like HTTP and WSP (well, you can argue with that). This shortens 
       the development cycle and reduces errors.</para>

       <para>WAP Push is an application layer protocol, and so in principle
       totally independent the transport layer used. So WAP 1 uses WSP/WTP
       and WAP 2 HTTP/TCP.</para>
</sect1>

<sect1>
<title>WAP Push Protocols</title>
       <para> WAP Push suite defines protocols for sending content from server
       to a push capable phone. Confirmed push includes sending a confirmation
       from the phone to the gateway, and, if this is asked for, from the 
       gateway to the initiator. There are two protocols: Push Over the Air 
       Protocol and Push Access Protocol.
       </para>

       <itemizedlist>
       <listitem><para>
       OTA (Over The Air) protocol. Lightweight protocol used for sending
       content from gateway to the phone. It maps quite directly to WSP, but
       it is possible to use it with other protocols.
       </para></listitem>

       <listitem><para>
       PAP (Push Access Protocol) used for communications between a push 
       initiator and a gateway. Protocol headers and protocol data are packed
       into XML documents, and, if necessary, MIME multipart messages and 
       these documents or messages are exchanged over HTTP.
       </para></listitem>
       </itemizedlist>

       <para> Push can be unconfirmed or confirmed. Unconfirmed one goes 
       following way (fetching the user may ask for is omitted):
       <orderedlist>
       <listitem><para>
       A push initiator send PAP message to a gateway, requesting a 
       unconfirmed push of a content to the phone.
       </para></listitem>

       <listitem><para>
       The gateway makes an OTA request for pushing the data to the phone.
       It is delivered using WSP sessionless services.
       </para></listitem>
       </orderedlist>

       and confirmed (and session-oriented) one, see <xref 
       linkend="conf-push-session">:

       <orderedlist>
       <listitem><para>
       A push initiator send PAP message to a gateway, requesting a confirmed
       push of a content to a phone.
       </para></listitem>

       <listitem><para>
       The gateway sends an OTA request to the phone, asking it to establish
       a session with it (a gateway cannot do this by itself), if there is
       no session already open.
       </para></listitem>

       <listitem><para>
       The phone establish a session using WAP protocol stack mechanisms.
       </para></listitem>

       <listitem><para>
       The gateway sends the content to the phone.
       </para></listitem>

       <listitem><para>
       The phone sends a confirmation to the gateway.
       </para></listitem>

       <listitem><para>
       The gateway sends a result notification, meaning a confirmation to 
       the push initiator.
       </para></listitem>

       </orderedlist> 

       <figure id="conf-push-session">
       <title>A confirmed WAP push</title>
       <graphic fileref="conf-push-session#FIGTYPE#"></graphic>
       </figure>
       </para>
</sect1>

<sect1>
<title>WAP Push XML languages</title>
       <para>PAP protocol data is packed into a XML document. Language used 
       for this is called PAP. User data can be of any MIME type, however,
       there are specific contents expressed with specific languages:
       Service Indication and Service Loading. </para>

       <itemizedlist>
       <listitem><para>
       Service Indication (SI). A gateway sends this type of a document to a
       phone for a push initiator. It tells to the user that a service has
       come available. He can reject, accept or postpone pulling of it. The
       indication may not interrupt the currently running task of the phone.
       </para></listitem>
      
       <listitem><para>
       Service Loading (SL). This is for a quite similar service, except now
       pulling in principle starts without an user intervention. However, the
       phone may implement a security mechanism suggested by SL specification
       and ask the user does he want to start pulling.
       </para></listitem>
       </itemizedlist>
</sect1>

<sect1>
<title>Duties of Push Proxy Gateway</title>
       <para>These are similar to WAP Gateway, because when pushing,
       the push application forms the external interface of a gateway. 
       However, there is a possibility that PPG works very closely with PI, 
       which does storing, billing and other similar services for it. This is 
       a quite realistic alternative, because PI has the content and so it, 
       not a "simple" gateway, provides visible services to the user. </para>

       <para>Of course, PPG must spare bandwith, too. Even though SI and
       SL documents are small (url being their main content) they must be
       delivered to the phone overs SMS. Difference between one and two
       SMS messages can be truly great indeed.</para>
</sect1>

</chapter>


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



<chapter>
<title>The Kannel Open Source WAP Gateway</title>

	<highlights>
	<para>This chapter is the most important part of the thesis. It
	covers the design and implementation of the Kannel Open Source
	WAP Gateway.</para>
	</highlights>

<sect1 id="project-intro-and-status">
<title>Introduction to and status of the project (1 p)</title>
  
	<highlights>
	<para>This section describes the Kannel project at Wapit: why
	it was started, and when, and what its goals are. It gives general,
	very high level requirements for the gateway, from Wapit's point
	of view, and explains why the project is open source and not a
	proprietary thing. It gives the current status of the project
	and its product. It probably even covers why we use C and not
	Java.</para>
	</highlights>
	
	<para>Wapit Ltd was founded in the fall of 1998 to develop
	services for mobile phone users, originally based on SMS. During
	the spring of 1999, when the company started growing and became
	more amibitious, it decided to start developing services and
	authoring tools for the upcoming WAP platform as well. As part
	of its strategy, it decided that it made sense to develop its
	own WAP gateway, and to make it as open source. There were few
	existing commercial gateways on the market, and all of them were
	quite expensive. Since Wapit intended to deliver its service
	platform to many customers all around the world, it would have
	been quite expensive to buy a new gateway for each customer.
	So expensive, in fact, that it was cheaper to develop a new
	one. On the other hand, since Wapit had no interest in making money
	directly from the gateway, it made sense to create an open source
	project to develop the gateway. This way, it would be possible
	to get help from other companies, and to some extent individuals,
	in developing the gateway, and specially in testing the gateway
	in various environment.</para>
	
	<para>The gateway project was launched in July, 1999, at the
	WAP Forum meeting in San Fransisco. The goal was to produce
	a gateway that was technically good enough at least for small
	operators and corporate level service providers. The author
	was hired at the end of June, 1999, to lead the project.
	By that time, there existed a very primitive proof of concept
	level prototype for an SMS gateway, which did not yet do anything
	for WAP. This was demonstrated in San Fransisco and it seemed
	that there was a huge interest in an open source WAP gateway.</para>
	
	<para>Wapit decided that it made sense to make a gateway that
	was both a WAP gateway and an SMS gateway, because there was
	already a huge existing user base of SMS capable users, and few
	or no WAP users. Also, WAP itself can benefit from SMS, for
	example via over-the-air configuration messages (OTA) for
	phones, to make it easier to configure the WAP phone for a
	particular operator or service.</para>

	<para>Initially, there was no formal requirements specification
	for the gateway - indeed, it did not even have a name. The
	gateway was just supposed to be `fast enough', but a more
	strict formulation was not even possible, since it was unclear
	what kinds of usage levels the intended customers would have.
	During the fall of 1999, the following formulation
	emerged:
	
		<blockquote>

		<attribution>Kannel Architecture and Design
		document</attribution>

		<para>The gateway needs to be able to serve thousands
		of concurrent users on reasonably priced hardware: less
		than ten PCs with high-end Intel CPUs, 128 MB of memory,
		fast network interfaces. It needs to be scalable to even
		higher levels of perfomance by adding more hardware
		(meaning that there can't be a single bottleneck that
		prevents more users from being served).</para>

		</blockquote>

	For reliability, the requirement was that when the gateway
	was being run on several hosts (the architecture allowed
	this), crash or failure of one node should not affect the
	others.</para>
	
	<para>The gateway was finally named Kannel in January, 2000. A
	kannel is a traditional Finnish musical instrument, but the name
	has no meaning for the gateway; it is just a nice name.</para>

	<para>In the summer and fall of 2000, when this is
	being written, the gateway has been in light production use
	for several months, both as an SMS gateway and a WAP gateway.
	</para>

</sect1>