Application Level Roaming
Application-level roaming (ALR) enables your application to roam to use the best available data connection while operational.
Implementation Considerations
There is no SDK method for WLAN scanning. Your application should use Connection Monitor Server API to request the list of available access points or network names (in the case of a WLAN these are SSIDs). Connection Monitor Server API also provides notifications about changes in the access point availability list.
Handovers between GPRS and WCDMA radio networks take a long time (from 15 seconds to 2 minutes) and sometimes fail completely. You should use long application level timers (if any) and maintain a responsive UI. Note that handovers between GPRS and WCDMA cannot be controlled by the symbian platform (except with fixed settings). The control logic is in the cellular modem.
In ALR, the transfer from one connection to another always introduces an IP address change and a break in data connection (even with make-before-break when the break is really short). This is because the sockets need to be closed and re-opened. This may be problematic for the applications that maintain a stateful connection with a server in the network. The workaround for a break is to open a new RConnection handle when receiving PreferredCarrierAvailable() and establishing the server connection using that (if the application protocol allows such operation). When that is done and new sockets are created for the new RConnection, the original RConnection can be closed. There is no workaround for the IP address change.
Process Flow
Figure: Application-level roaming
Additional information
The following APIs are used to implement application-level roaming:
Sockets Server Client API (ESOCK) is the API for all IP-based socket communication. It remains unchanged, but applications need to be ready to close and open sockets at certain times to roam for a better connection.
Connection Management API (RConnection) is a collection of Symbian's connection management-related functionalities provided by ESOCK. It contains several extensions and one of them is the mobility extension. The term "mobility API" actually refers to the mobility extensions that are part of Connection Manager API and defined in header
cs_mobility_apiext.h. With the so-called mobility API the client application can register for mobility events, receive information about preferred connections, indicate whether to switch to a new connection or ignore it. In short, it enables ALR for the applications.
The mobility extension functionality of the Connection
Manager API is provided by classes MMobilityProtocolResp and CActiveCommsMobilityApiExt.
virtual void PreferredCarrierAvailable(TAccessPointInfo aOldAP, TAccessPointInfo aNewAP, TBool aIsUpgrade, TBool aIsSeamless ); This method is called by the middleware to notify a client about a new preferred connection.
virtual void NewCarrierActive(TAccessPointInfo aNewAP, TBool aIsSeamless ); This method is called by the middleware to notify a client that a preferred connection has been activated.
virtual void Error(TInt aError); This method is called by middleware to notify that there are no suitable connections available.
void MigrateToPreferredCarrier(); Client can indicate that it wants to start using a new preferred connection as a response to PreferredCarrierAvailable().
void IgnorePreferredCarrier(); Client can indicate that it doesn’t want to use a new preferred connection as a response to PreferredCarrierAvailable().
void NewCarrierAccepted(); Client indicates that a new connection is working for it.
void NewCarrierRejected(); Client indicates that a new connection is not working and it wants to use another connection. In this case it receives PreferredCarrierAvailable() again with probably the original connection as a preferred one. The non-working access point is blacklisted for that client and not suggested again.