<?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 xml:lang="en" id="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0"><title>Goals of the Comms Architecture</title><shortdesc>This topic describes the goals of the Symbian OS Comms Architecture and summarises how the architecture addresses these goals. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>The Symbian OS 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 OS 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_d0e62802_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_d0e62848_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 OS 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_d0e62863_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>