--- a/Symbian3/SDK/Source/GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,126 +1,126 @@
-<?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_d0e82800_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_d0e82848_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_d0e82865_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>
+<?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>
</conbody></concept>
\ No newline at end of file