Application +Level Roaming

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 +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.

Methods +that must be implemented by client (class MMobilityProtocolResp):

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.

Methods provided by ESock (class CActiveCommsMobilityApiExt):

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.