Bearer mobility allows the email Message Type Modules (MTM) to non-seamlessly switch between networking bearers, such as, GPRS, WiFi, CDMA, GSM, and so on. Switching between network bearers enables destination networks to connect without dropping the connection with the remote server.
The POP3, IMAP4 and SMTP email server MTMs support this functionality.
The bearer mobility must be enabled in the Networking bearer mobility framework to provide bearer mobility functionality in the Messaging Application module.
After the bearer mobility is set for the email server MTMs at the client-side using the SetBearerMobility function, the bearer mobility manager registers with the bearer mobility framework in the Networking subsystem. This informs the bearer mobility manager about any change in the bearers.
The bearer mobility plug-in gets the notifications about the change in the bearer. When the required bearer is available, the server MTMs uses this plug-in to get notifications. The following illustration shows the architecture of the bearer mobility implementation in the Messaging Application module.
The email client MTM CEmailAccounts interfaces are enhanced to configure the email account settings. These settings modify the behaviour of the relevant server MTMs for the following functionality:
Non-seamless bearer mobility
The IMAP4, POP3, and SMTP server MTMs are extended to allow messaging applications to use the non-seamless network bearer mobility when connecting to a destination network using the respective protocols. The following functions are added to the CImBaseEmailSettings (CImPop3Settings, CImImap4Settings, and CImSmtpSettings) class:
Per bearer-type configuration for IMAP email accounts
Specifically for IMAP email accounts, the CEmailAccounts class enables the following per bearer-type configuration that affect the behaviour of IMAP accounts:
Download rules
Download rules specify which parts of message to automatically download (according to bearer type) when synchronising the contents of an IMAP email account. You can configure an IMAP email account for IMAP download rules on each bearer type and for each account using the CImapSyncDownloadRules class.
When synchronising an IMAP email account you can do the following:
Indicate that a list of email download rules for each type of bearer must be used during the email account synchronisations.
Retrieve emails during the synchronisation using the mail options specified in the list for the bearer type that is currently in use by the connection to the server.
The CImapSyncDownloadRules class is used to store per IMAP account sync download rules. This class describes the download rules that provide the ability to automatically get the email content. This is configurable on a per account and per bearer-type basis.
Different download rules can be specified for different bearers. For example, you can specify that all text and attachments should be retrieved when connecting through a WiFi connection; whereas, only text parts should be retrieved when connecting over GPRS connection.
Synchronisation is performed in two stages: the email header synchronisation is performed first followed by the email content retrieval. If the email account settings indicate that the per-bearer-type list should not be used, or no per-bearer-type list is defined, or the current bearer type is not listed in the per-bearer-type list, then during the synchronisation the email headers for inbox and personal folders are downloaded.
Note: The per-bearer-type list is a set of IMAP download and transport buffer size rules defined for each type of bearer.
Messages that are not previously populated are retrieved using this method. So a message that has been populated according to GPRS settings will not be retrieved again according to WiFi settings, if a subsequent connection is made.
Messages that arrive on the server while IMAP is in the IDLE state are also automatically downloaded according to the Inbox download rules for the connected bearer type.
A single instance of a set of download rules is applicable to multiple bearer types.
Transport buffer size
Transport buffer size specifies the size of the data transferred from server to client to get email body and attachments from an IMAP server using a per bearer-type list of transport buffer sizes. You can configure an IMAP account for IMAP transport buffer size on each bearer type using the CImapTransportBufferSizes class.
This class allows a client to configure transport buffer sizes of IMAP accounts according to the bearer type for retrieving large message parts. It is possible to specify in the following:
Maximum retrieve size. Default is 20480 octets.
Maximum outstanding retrieve requests. Default is two outstanding requests.
Important considerations
If there are is no bearer type specific list defined, or the current bearer type is not listed in the per-bearer-type list of transport buffer sizes, then the maximum retrieve request size specified in the email account settings is used. The maximum and default number of outstanding retrieve requests is two.
The transport buffer sizes that can be specified are the maximum retrieve request size sent in IMAP retrieve requests.
Download email body and attachments from an IMAP server using the retrieve request buffer size specific to the bearer type that the server connection is using.
Download email body and attachments from an IMAP server using the maximum number of outstanding retrieve requests specific to the bearer type that the server connection is using.
A single instance of a set of transport buffer sizes is applicable to multiple bearer types.
Bearer mobility policy plug-in
The bearer mobility policy plug-in enables you to customise the migration behaviour of email accounts, the bearer mobility policy plug-in is provided. It consists of an ECOM interface class (CImMobilityPolicyPlugin) and a call-back class (MImMobilityPolicyHandler),which allows the plug-in to issue policy decisions on an individual mobility events.
To enable bearer mobility, you must first enable it at the Networking bearer mobility framework.
Bearer mobility is possible only on the connections that are established using a SNAP preference list.
To use the bearer mobility, you must configure the email account settings to specify the SNAP preference when creating the RConnection notification (events).
Multiple SNAP preferences for each service entry is not supported.
It is not possible to specify both IAPs and a SNAP for a single email account. The API for setting a SNAP preference clears any provisioned IAPs. Likewise, the API for setting IAPs are updated to clear any SNAP preference that is set.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.