<?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-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5"><title>What are Tiers?</title><shortdesc>This topic describes the concepts of a <i>Tier</i> and a <i>Tier Manager</i> in the Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>A Tier is a group of Access Points (APs) related to one or more technologies sharing the same Selection and Availability monitoring logic. The Tier Manager provides the means for an application to connect to a communication service to send and receive data, or to check the current status of a communication service. </p> <p>When an application needs to contruct a stack either to request availability on a particular service or to establish a connection with a remote device or service, it will explicitly select a specific Tier Manager at the top of the stack to define the service. If the application does not explicitly select a specific Tier Manager, the default TM will be used. The selection process and connection preferences will define how the rest of the stack is constructed. Each Tier Manager is responsible for selecting the most appropriate AP from a range of alternatives and may also pass up availability information in some cases, depending on the Tier Manager. </p> <p>When a higher Layer wants to bind to a lower layer, it uses the supplied selection criteria to select a Tier and request a specific AP. Once the Tier has returned an AP and the stack has been bound together, the upper layer queries the availability to see if it is possible to connect at that moment. </p> <p>On a device there will be multiple Tier Managers, each responsible for a separate technology or group of technologies. Each Tier Manager will have distinct selection and availability logic and other technology specific algorithms. </p> <p>A single Tier Manager will be responsible for multiple instances of a layer, i.e. multiple APs of the same type. So the Wi-Fi Tier Manager would allow connection to multiple Wi-Fi Access Points, a Telephony Tier Manager will be responsible for connections to different APNs. </p> <p>Tier Managers (<xref href="GUID-33AD3175-2480-3D56-A6DB-FC1FE11E31B4.dita"><apiname>CTierManagerBase</apiname></xref>) are Comms Framework nodes created by their respective factories. Tier Managers respond to Node Messages sent across the Transport, in a similar way to Stack Nodes. </p> <p>The Tier Manager keeps track of the current Access Points that have been created through a query API, see Availability below. The Tier Manager responds to messages sent when an Access Point changes state. For example, when a Bearer stops being available, a message will be sent to the Tier Manager. </p> <p>In the diagram below, two Tier Managers are shown. The diagram shows that one Tier Manager can be responsible for more than one layer in a Stack. </p> <fig id="GUID-983CF8C4-A1DD-59AD-91BD-27E8EE2C5AA7"><title>

          Communications Architecture showing Tier Managers 

        </title> <image href="GUID-F97EA91E-35E3-5E69-A4C4-7415AB91C1BC_d0e77072_href.png" placement="inline"/></fig> <p>When a client application wants to start a connection it will request an AP by calling <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita#GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD/GUID-ECA90A33-ED2C-331C-8D5B-62927B7CF690"><apiname>RConnection::Open()</apiname></xref> with a Tier Identifier (the <codeph>iTag</codeph> field in the <xref href="GUID-387A8240-0765-52F2-98A4-8F9FC809E03E.dita#GUID-387A8240-0765-52F2-98A4-8F9FC809E03E/GUID-437C4AE0-D16B-50B7-8AD8-A4E8FA5F15E5">Tier</xref> table). This will cause a stack of APs that meet the selection and availability criteria to be returned. When the <xref href="GUID-A0C5A43A-C1AD-347E-A57E-4C7BA819FBBA.dita"><apiname>RConnection:Start()</apiname></xref> occurs, a specific AP will be selected at the top layer and the matching CPRs, SCPRs and Data Flows in each of the layers for the connection will be started (unless the connection is already active and this new <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita"><apiname>RConnection</apiname></xref> can share the open connection). </p> <section id="GUID-20688D48-4536-5B1E-B7F5-8C466FA59031"><title>Configuration</title> <p>The configuration for a Tier Manager is held in a number of <xref href="GUID-BD971173-E009-58DA-AF9C-F4AAFF77B138.dita">Comms Database</xref> tables: most importantly the <xref href="GUID-387A8240-0765-52F2-98A4-8F9FC809E03E.dita#GUID-387A8240-0765-52F2-98A4-8F9FC809E03E/GUID-437C4AE0-D16B-50B7-8AD8-A4E8FA5F15E5">Tier</xref> table, and the <xref href="GUID-387A8240-0765-52F2-98A4-8F9FC809E03E.dita#GUID-387A8240-0765-52F2-98A4-8F9FC809E03E/GUID-52230909-4652-5613-8E52-6761E948907D">Access Point</xref> table. </p> <p>The Tier Table contains the ECom ID of the loaded module that processes Tier Manager requests, and the Default Access Point. The Default Access Point is the one used if the client makes no special requests, see <xref href="GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5.dita#GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5/GUID-0D40CC6A-AFAE-505C-B791-898B4994AE6D">Explicit and Implicit Selection</xref> below. </p> <p>The Access Point Table contains the identifiers of the MCPR, CPR and SCPR for this layer, the selection policy, the protocol, the Tier ID and a protocol identifier. </p> <p>It is recommended that all connections should specify a Tier in the <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita#GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD/GUID-CB62E838-A380-309C-8B08-1F804EDB4387"><apiname>RConnection::Start()</apiname></xref>, but for backward compatability, <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita#GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD/GUID-CB62E838-A380-309C-8B08-1F804EDB4387"><apiname>RConnection::Start()</apiname></xref> without a Tier identifier will use the <codeph>Default Tier</codeph> which is stored in the <xref href="GUID-387A8240-0765-52F2-98A4-8F9FC809E03E.dita#GUID-387A8240-0765-52F2-98A4-8F9FC809E03E/GUID-7383902B-10D2-52F3-8BDB-478CA6FB587D">GlobalSettings</xref> table. Important note: for legacy code to function correctly, the Default Tier must be the "<codeph>Network</codeph> " Tier. See <xref href="GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5.dita#GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5/GUID-0D40CC6A-AFAE-505C-B791-898B4994AE6D">Explicit and Implicit Selection</xref> below for more information. </p> </section> <section id="GUID-DD707869-1B90-5707-9D6E-DCB45D2DD1E5"><title>Usage</title> <p id="GUID-A9CF89B0-C3DC-5E60-A697-483DA829FD9C"><b>Selection</b> </p> <p>A Tier Manager uses selection to decide which Access Points can be used for a connection. A top-level Tier Manager responds to selection requests that originate from <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita"><apiname>RConnection</apiname></xref> or <xref href="GUID-55FE59B7-4FA9-3B1A-BD4C-9B7611FE75C2.dita"><apiname>RConnectionServ</apiname></xref>. </p> <p>Selection selects a stack of APs that may be used to provide a service. The result is a stack or inverted tree showing potential APs at each layer. Remember that a higher layer AP provides a service, but there may be several options at each lower layer for supporting that service (Wi-Fi, 3G telephony etc.). For example, when a client asks for a service to provide a data socket, the list returned will include all the available APs at each layer. The Tier Manager for each layer decides which AP to use. </p> <p id="GUID-0D40CC6A-AFAE-505C-B791-898B4994AE6D"><b>Explicit and Implicit Selection</b> </p> <p>If Freeway/Mobility is required it is required that communications clients explicitly open an <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita"><apiname>RConnection</apiname></xref> on an AP. and associate the <xref href="GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.dita"><apiname>RSocket</apiname></xref> with it. But to for legacy applications or connections that don't require mobility, Implicit Selection is supported which uses the Default Connection. </p> <p>Explicit Selection occurs when an application specifies the top-level Access Point when calling <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita#GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD/GUID-CB62E838-A380-309C-8B08-1F804EDB4387"><apiname>RConnection::Start()</apiname></xref> with a parameter bundle that specifies an AP. Explicit selection selects the top-level AP and joins this connection to the stack. </p> <p>Implicit selection occurs when a user calls <xref href="GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.dita#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0/GUID-3491CE2A-A94D-34E0-B0DD-D476EE3334D7"><apiname>RSocket::Open()</apiname></xref> on a socket that is not associated with any connection. Implicit selection will associate the socket with the Default Connection. Implicit selection also occurs when an <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita#GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD/GUID-CB62E838-A380-309C-8B08-1F804EDB4387"><apiname>RConnection::Start()</apiname></xref> is called without specifying an AP in the connection preferences. </p> <p>For Implicit Selection, only the top layer of the stack is created by the <xref href="GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.dita#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0/GUID-3491CE2A-A94D-34E0-B0DD-D476EE3334D7"><apiname>RSocket::Open()</apiname></xref>, the remainder of the layers are created when a Data Plane event occurs such as <xref href="GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.dita#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0/GUID-AC5A49E9-337D-334A-9CD0-DB8226372306"><apiname>RSocket::Connect()</apiname></xref> or <xref href="GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.dita#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0/GUID-ADE2383D-3075-30B4-8F63-6D837EB75AEF"><apiname>RSocket::Send()</apiname></xref>. </p> <p>When the Data Plane activation event occurs: </p> <ul><li id="GUID-DF27A381-6BAC-51D0-91CA-42FF85AAE02F"><p>if there is no bearer (no AP for the next layer in the stack), the Control Plane will finish the selection and start the selected connection. </p> </li> <li id="GUID-0B71B7A0-BF9B-5F49-A6B5-F37382039E9A"><p>if there is a bearer, the Data Plane states it has found a flow in the Layer below by protocol-specific means, for example IP routing table. </p> </li> </ul> <p id="GUID-E1C0D897-48A2-58C7-BA2C-0AF406DCDFED"><b>Availability</b> </p> <p>When a client application wants to monitor a technology or existing connection, it can call <xref href="GUID-55FE59B7-4FA9-3B1A-BD4C-9B7611FE75C2.dita#GUID-55FE59B7-4FA9-3B1A-BD4C-9B7611FE75C2/GUID-E80C3173-3777-317A-8007-E9C331FAD9AE"><apiname>RConnectionServ::AccessPointStatusQuery()</apiname></xref> for an immediate status, or <xref href="GUID-55FE59B7-4FA9-3B1A-BD4C-9B7611FE75C2.dita#GUID-55FE59B7-4FA9-3B1A-BD4C-9B7611FE75C2/GUID-D4348A26-176D-3C2D-9BA6-CD055E6EC7D3"><apiname>RConnectionServ::AccessPointNotification()</apiname></xref> to be informed of each status change. As the format of the query bundle is configurable by the MCPR, each technology can specify what information will be returned in a query or notification. For example, the query bundle could contain Wi-Fi hotspot availability, maximum data rate supported, costs etc. </p> </section> </conbody><related-links><link href="GUID-01029B52-55E0-5598-994F-BB5DE73D37EE.dita"><linktext>Layers</linktext> </link> <link href="GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita"><linktext>Planes</linktext> </link> <link href="GUID-E3E4E9A1-359E-5475-A355-1DA446FE7170.dita"><linktext>Nodes</linktext> </link> </related-links></concept>