12 <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>

    12 <concept id="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0" xml:lang="en"><title>Goals

    13              Separation of Data Flows and Control in the Comms Architecture 

    13 of the Comms Architecture</title><shortdesc>This topic describes the goals of the Symbian platform Comms Architecture

    14           </title> <image href="GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e87777_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>

    14 and summarises how the architecture addresses these goals. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15              Example of several potential stacks of protocols reusing the same

    15 <p>The Symbian platform Comms Architecture is also known by other terms such

    16              protocols. 

    16 as the <i>Three-Plane Comms Architecture</i> and <i>Freeway</i>. The Comms

    17           </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_d0e87823_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>

    17 Architecture provides several framework components for generic functionality

    18              The Comms Architecture shown in the scope of a complete protocol

    18 and a number of plug-in modules which plug into this framework to implement

    19              stack and the end-to-end path between the applications on each device. 

    19 the comms protocols. </p>

    20           </title> <image href="GUID-26399981-1E45-5578-851E-D234295F3B05_d0e87838_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>

    20 <p>The small number of components that make up the framework itself are referred

    21 to as "Comms Framework" components while the plug-in modules themselves are

    22 known as "Nodes" which are arranged in "Layers" within the framework. Many

    23 of the Nodes are supplied as part of Symbian platform but their plug-in nature

    24 allows some of these to be replaced with tailored modules by a device-manufacturer. </p>

    25 <p>The Comms Architecture has several goals: </p>

    26 <ul>

    27 <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>

    28 <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>

    29 <li id="GUID-BFC6D0A0-1650-592E-91C1-48E32A4E634F"><p>no limitations in the

    30 creation of individual stacks from the available protocols </p> </li>

    31 <li id="GUID-B8E890D7-3CA9-5764-BED5-6A4632C0B998"><p>streamline the addition

    32 of new protocols </p> </li>

    33 <li id="GUID-723FCD21-A8A5-577F-BF8B-25462955DD3D"><p>support for switching

    34 between protocols depending on the current network availability </p> </li>

    35 </ul> </li>

    36 <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

    37 by lower-priority tasks. </p> </li>

    38 </ul>

    39 <p>Other requirements on the Architecture include the need to remain efficient

    40 in the use of ROM, RAM and processor resources, and to provide a high level

    41 of reliability. </p>

    42 <section id="GUID-D7936ACA-491A-545F-98CB-002F789A276A"><title>Separation

    43 of Data and Control functions</title> <p>By separating the code for the data

    44 flow and the control functions, it is possible to have each in a separate

    45 thread or even each in a separate process. This allows appropriate resources

    46 to be allocated and priority to be assigned to support Quality of Service,

    47 prioritisation of time-critical data flows and optimised plug-ins for specific

    48 protocols. </p> <p>Communication between the data and control threads, and

    49 between the layers is performed by an asynchronous messaging system known

    50 as the <i>Transport</i>. </p> <fig id="GUID-5467DE40-01FB-5D50-BB6D-866D5C425ADA">

    51 <title>              Separation of Data Flows and Control in the Comms Architecture

    52            </title>

    53 <image href="GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e111255_href.png" placement="inline"/>

    54 </fig> <p>In fact the Comms Architecture actually divides the area marked

    55 Control above into two areas, <i>Control</i> and <i>Management</i>. This is

    56 the reason that this Comms Architecture is also known as the <i>Three-Plane

    57 Architecture</i>. In future diagrams there will be three <i>Planes</i>: Data

    58 Flow, Control, and Management. The Control Plane is often shown divided in

    59 half to indicate that the Control Plane handles both Connections and data

    60 channels within a Connection. This is described in more detail in <xref href="GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita">Planes</xref>. </p> </section>

    61 <section id="GUID-CD056265-7468-557A-A6F6-85B13E63A238"><title>Flexibility </title> <p>The

    62 Comms Architecture uses the concept of multiple stacks of technologies, from

    63 high level technologies such as FTP down to lower level technologies (link

    64 layer technologies) running on GPRS or Wi-Fi. An individual <i>Stack</i> is

    65 a set of technologies which make up a communication path. A Stack in this

    66 context is a single list of technologies from the application to the physical

    67 hardware. An example of such a Stack is: HTTP over TCP over IP over GPRS,

    68 which might be used in web browsing via a subscriber's mobile network. The

    69 layered architecture allows both flexibility in the configuration of these

    70 Stacks, as well as dynamic reconfiguration of the Stacks in response to changes

    71 in the environment of the device (for example moving from a Wi-Fi to a 3G

    72 environment). The link-layer technologies are known as <i>Bearers</i> and

    73 the ability to switch a Data Flow from one bearer to another is called <i>Bearer

    74 Mobility</i>. But it is possible to have the ability to switch from one technology

    75 to another at any level in the stack providing full mobility. </p> <fig id="GUID-BE9C7C7A-DD4C-5199-81C1-E8856BA48AD6">

    76 <title>              Example of several potential stacks of protocols reusing

    77 the same              protocols.            </title>

    78 <desc><p>In this example IP and TCP are used in three different stacks. A

    79 combination of these Stacks could be running concurrently. </p> </desc>

    80 <image href="GUID-FBBC7F0D-FD4B-58B7-BEAC-B68EEBD19ACF_d0e111303_href.png" placement="inline"/>

    81 </fig> <p>Each stack requires a configuration that details how these protocols

    82 find and work with each other; the protocols themselves need to know how to

    83 talk with the other protocols. To allow flexibility, each protocol must avoid

    84 making assumptions about the protocols below or above it, and instead rely

    85 on the framework and device configuration. The framework ensures that each

    86 protocol is created and appropriately configured when required, and is attached

    87 to the protocols above and below it. </p> <p>The advent of multiple wireless

    88 technologies has allowed a device to switch between protocols depending on

    89 what is available. This is known as Freeway, and an example would be for a

    90 browser to switch from Wi-Fi to GPRS when a mobile device goes out of range

    91 of a Wi-Fi hotspot but is in range of a GPRS signal. The Comms Architecture

    92 provides for this by allowing such transitions to be defined on the device

    93 as part of the definition of the possible combinations of protocols that could

    94 make up the various Stacks. </p> <p>The figure below illustrates the scope

    95 of the Comms Architecture in Symbian platform from the point of view of an

    96 end-to-end connection. </p> <fig id="GUID-8DFF2EAE-21F7-5119-88E7-19BF2076A76F">

    97 <title>              The Comms Architecture shown in the scope of a complete

    98 protocol              stack and the end-to-end path between the applications

    99 on each device.            </title>

   100 <image href="GUID-26399981-1E45-5578-851E-D234295F3B05_d0e111320_href.png" placement="inline"/>

   101 </fig> </section>

   102 <section id="GUID-1BAC904D-F705-5416-A0F6-3D5FA3B10A7E"><title>Performance</title> <p>A

   103 key requirement of the Comms Architecture is the performance of data transfer.

   104 The data transfer performance can be measured in three different ways: </p> <ul>

   105 <li id="GUID-02E93F2D-E249-516C-98B2-AFB9A22CCEF4"><p> <b>Throughput</b> -

   106 the amount of data transferred measured against time </p> </li>

   107 <li id="GUID-73E3B61E-C731-5BFC-9E5D-01C50FC94344"><p> <b>Latency</b> - the

   108 amount of time it takes a single element of data to move from one end of the

   109 communication route to the other </p> </li>

   110 <li id="GUID-0C8AE3B7-C9BC-56C7-9372-99657EF64E79"><p> <b>Jitter</b> - the

   111 unwanted variance in the potential delay for each item of data sent, which

   112 in turn causes data to arrive in the wrong order or for unacceptably-long

   113 pauses in the data stream . </p> </li>

   114 </ul> <p>The Comms Architecture addresses these needs by separating all control

   115 and data tasks. The control tasks are those that are involved with the creation

   116 and management of the data connections, but which are not directly involved

   117 with the transfer of data itself. The data tasks are those involved directly

   118 with the transfer of data. The control tasks are deemed as lower priority

   119 than the data tasks, and thus the data tasks are always run in preference

   120 to the control tasks. For example, if an application requests a new connection,

   121 the creation of this connection will not interrupt any existing data transfer

   122 operations. </p> <p>The Comms Architecture also improves the handling of Quality

   123 of Service resource reservation by structuring the framework around the concept

   124 of channels, with the framework then able to specify the Quality of Service

   125 parameters per channel. </p> </section>

   126 </conbody></concept>