<?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_d0e76088_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_d0e76136_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_d0e76153_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>