|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-B7A40638-BA80-5175-B23D-2F3964C274A0" xml:lang="en"><title>Goals |
|
13 of the Comms Architecture</title><shortdesc>This topic describes the goals of the Symbian platform Comms Architecture |
|
14 and summarises how the architecture addresses these goals. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <p>The Symbian platform Comms Architecture is also known by other terms such |
|
16 as the <i>Three-Plane Comms Architecture</i> and <i>Freeway</i>. The Comms |
|
17 Architecture provides several framework components for generic functionality |
|
18 and a number of plug-in modules which plug into this framework to implement |
|
19 the comms protocols. </p> |
|
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_d0e82800_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_d0e82848_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_d0e82865_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> |