What are Tiers?
This topic describes the concepts of a Tier and a Tier Manager in the Communications Framework.
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.
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.
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.
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.
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.
Tier Managers (CTierManagerBase) 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.
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.
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.
When a client application wants to start a connection it will request an AP by calling RConnection::Open() with a Tier Identifier (the iTag field in the Tier table). This will cause a stack of APs that meet the selection and availability criteria to be returned. When the RConnection:Start() 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 RConnection can share the open connection).
Configuration
The configuration for a Tier Manager is held in a number of Comms Database tables: most importantly the Tier table, and the Access Point table.
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 Explicit and Implicit Selection below.
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.
It is recommended that all connections should specify a Tier in the RConnection::Start(), but for backward compatability, RConnection::Start() without a Tier identifier will use the Default Tier which is stored in the GlobalSettings table. Important note: for legacy code to function correctly, the Default Tier must be the "Network " Tier. See Explicit and Implicit Selection below for more information.
Usage
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 RConnection or RConnectionServ.
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.
Explicit and Implicit Selection
If Freeway/Mobility is required it is required that communications clients explicitly open an RConnection on an AP. and associate the RSocket with it. But to for legacy applications or connections that don't require mobility, Implicit Selection is supported which uses the Default Connection.
Explicit Selection occurs when an application specifies the top-level Access Point when calling RConnection::Start() with a parameter bundle that specifies an AP. Explicit selection selects the top-level AP and joins this connection to the stack.
Implicit selection occurs when a user calls RSocket::Open() 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 RConnection::Start() is called without specifying an AP in the connection preferences.
For Implicit Selection, only the top layer of the stack is created by the RSocket::Open(), the remainder of the layers are created when a Data Plane event occurs such as RSocket::Connect() or RSocket::Send().
When the Data Plane activation event occurs:
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.
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.
When a client application wants to monitor a technology or existing connection, it can call RConnectionServ::AccessPointStatusQuery() for an immediate status, or RConnectionServ::AccessPointNotification() 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.