<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0" xml:lang="en"><title>Goals
of the Comms Architecture</title><shortdesc>This topic describes the goals of the Symbian platform Comms Architecture
and summarises how the architecture addresses these goals. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The Symbian platform Comms Architecture is also known by other terms such
as the <i>Three-Plane Comms Architecture</i> and <i>Freeway</i>. The Comms
Architecture provides several framework components for generic functionality
and a number of plug-in modules which plug into this framework to implement
the comms protocols. </p>
<p>The small number of components that make up the framework itself are referred
to as "Comms Framework" components while the plug-in modules themselves are
known as "Nodes" which are arranged in "Layers" within the framework. Many
of the Nodes are supplied as part of Symbian platform but their plug-in nature
allows some of these to be replaced with tailored modules by a device-manufacturer. </p>
<p>The Comms Architecture has several goals: </p>
<ul>
<li id="GUID-72B9693A-E2D1-560D-B640-092019245F63"><p> <xref href="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita#GUID-B7A40638-BA80-5175-B23D-2F3964C274A0/GUID-D7936ACA-491A-545F-98CB-002F789A276A">Separation of Data and Control functions</xref>  </p> </li>
<li id="GUID-F0A5DBBF-7516-54E3-8FB0-B3A2D3DC3891"><p> <xref href="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita#GUID-B7A40638-BA80-5175-B23D-2F3964C274A0/GUID-CD056265-7468-557A-A6F6-85B13E63A238">Flexibility</xref> </p> <ul>
<li id="GUID-BFC6D0A0-1650-592E-91C1-48E32A4E634F"><p>no limitations in the
creation of individual stacks from the available protocols </p> </li>
<li id="GUID-B8E890D7-3CA9-5764-BED5-6A4632C0B998"><p>streamline the addition
of new protocols </p> </li>
<li id="GUID-723FCD21-A8A5-577F-BF8B-25462955DD3D"><p>support for switching
between protocols depending on the current network availability </p> </li>
</ul> </li>
<li id="GUID-BEC4C7CB-307A-53AE-B648-C804E2C4CC83"><p>Improving <xref href="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita#GUID-B7A40638-BA80-5175-B23D-2F3964C274A0/GUID-1BAC904D-F705-5416-A0F6-3D5FA3B10A7E">performance</xref> so that high-priority data transfers are not interrupted
by lower-priority tasks. </p> </li>
</ul>
<p>Other requirements on the Architecture include the need to remain efficient
in the use of ROM, RAM and processor resources, and to provide a high level
of reliability. </p>
<section id="GUID-D7936ACA-491A-545F-98CB-002F789A276A"><title>Separation
of Data and Control functions</title> <p>By separating the code for the data
flow and the control functions, it is possible to have each in a separate
thread or even each in a separate process. This allows appropriate resources
to be allocated and priority to be assigned to support Quality of Service,
prioritisation of time-critical data flows and optimised plug-ins for specific
protocols. </p> <p>Communication between the data and control threads, and
between the layers is performed by an asynchronous messaging system known
as the <i>Transport</i>. </p> <fig id="GUID-5467DE40-01FB-5D50-BB6D-866D5C425ADA">
<title>              Separation of Data Flows and Control in the Comms Architecture
           </title>
<image href="GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e76050_href.png" placement="inline"/>
</fig> <p>In fact the Comms Architecture actually divides the area marked
Control above into two areas, <i>Control</i> and <i>Management</i>. This is
the reason that this Comms Architecture is also known as the <i>Three-Plane
Architecture</i>. In future diagrams there will be three <i>Planes</i>: Data
Flow, Control, and Management. The Control Plane is often shown divided in
half to indicate that the Control Plane handles both Connections and data
channels within a Connection. This is described in more detail in <xref href="GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita">Planes</xref>. </p> </section>
<section id="GUID-CD056265-7468-557A-A6F6-85B13E63A238"><title>Flexibility </title> <p>The
Comms Architecture uses the concept of multiple stacks of technologies, from
high level technologies such as FTP down to lower level technologies (link
layer technologies) running on GPRS or Wi-Fi. An individual <i>Stack</i> is
a set of technologies which make up a communication path. A Stack in this
context is a single list of technologies from the application to the physical
hardware. An example of such a Stack is: HTTP over TCP over IP over GPRS,
which might be used in web browsing via a subscriber's mobile network. The
layered architecture allows both flexibility in the configuration of these
Stacks, as well as dynamic reconfiguration of the Stacks in response to changes
in the environment of the device (for example moving from a Wi-Fi to a 3G
environment). The link-layer technologies are known as <i>Bearers</i> and
the ability to switch a Data Flow from one bearer to another is called <i>Bearer
Mobility</i>. But it is possible to have the ability to switch from one technology
to another at any level in the stack providing full mobility. </p> <fig id="GUID-BE9C7C7A-DD4C-5199-81C1-E8856BA48AD6">
<title>              Example of several potential stacks of protocols reusing
the same              protocols.            </title>
<desc><p>In this example IP and TCP are used in three different stacks. A
combination of these Stacks could be running concurrently. </p> </desc>
<image href="GUID-FBBC7F0D-FD4B-58B7-BEAC-B68EEBD19ACF_d0e76098_href.png" placement="inline"/>
</fig> <p>Each stack requires a configuration that details how these protocols
find and work with each other; the protocols themselves need to know how to
talk with the other protocols. To allow flexibility, each protocol must avoid
making assumptions about the protocols below or above it, and instead rely
on the framework and device configuration. The framework ensures that each
protocol is created and appropriately configured when required, and is attached
to the protocols above and below it. </p> <p>The advent of multiple wireless
technologies has allowed a device to switch between protocols depending on
what is available. This is known as Freeway, and an example would be for a
browser to switch from Wi-Fi to GPRS when a mobile device goes out of range
of a Wi-Fi hotspot but is in range of a GPRS signal. The Comms Architecture
provides for this by allowing such transitions to be defined on the device
as part of the definition of the possible combinations of protocols that could
make up the various Stacks. </p> <p>The figure below illustrates the scope
of the Comms Architecture in Symbian platform from the point of view of an
end-to-end connection. </p> <fig id="GUID-8DFF2EAE-21F7-5119-88E7-19BF2076A76F">
<title>              The Comms Architecture shown in the scope of a complete
protocol              stack and the end-to-end path between the applications
on each device.            </title>
<image href="GUID-26399981-1E45-5578-851E-D234295F3B05_d0e76115_href.png" placement="inline"/>
</fig> </section>
<section id="GUID-1BAC904D-F705-5416-A0F6-3D5FA3B10A7E"><title>Performance</title> <p>A
key requirement of the Comms Architecture is the performance of data transfer.
The data transfer performance can be measured in three different ways: </p> <ul>
<li id="GUID-02E93F2D-E249-516C-98B2-AFB9A22CCEF4"><p> <b>Throughput</b> -
the amount of data transferred measured against time </p> </li>
<li id="GUID-73E3B61E-C731-5BFC-9E5D-01C50FC94344"><p> <b>Latency</b> - the
amount of time it takes a single element of data to move from one end of the
communication route to the other </p> </li>
<li id="GUID-0C8AE3B7-C9BC-56C7-9372-99657EF64E79"><p> <b>Jitter</b> - the
unwanted variance in the potential delay for each item of data sent, which
in turn causes data to arrive in the wrong order or for unacceptably-long
pauses in the data stream . </p> </li>
</ul> <p>The Comms Architecture addresses these needs by separating all control
and data tasks. The control tasks are those that are involved with the creation
and management of the data connections, but which are not directly involved
with the transfer of data itself. The data tasks are those involved directly
with the transfer of data. The control tasks are deemed as lower priority
than the data tasks, and thus the data tasks are always run in preference
to the control tasks. For example, if an application requests a new connection,
the creation of this connection will not interrupt any existing data transfer
operations. </p> <p>The Comms Architecture also improves the handling of Quality
of Service resource reservation by structuring the framework around the concept
of channels, with the framework then able to specify the Quality of Service
parameters per channel. </p> </section>
</conbody></concept>