<?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-EDC16636-B24E-598B-9084-EAE782A4A213"><title>What is Bearer Mobility</title><shortdesc>This topic describes the concept of <i>Bearer Mobility</i> in the Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>Bearer Mobility is a feature that allows a device to change bearers without interruption to the user's data sessions. An example of a bearer change is if a device moves into the range of a Wi-Fi hot spot and the device moves the GPRS connections over to Wi-Fi. Example data sessions include: streaming videos; surfing the internet; and downloading emails. Example bearers include: Wireless LAN (eg Wi-Fi); 3G (including HSUPA and HSDPA); Circuit Switched Data (CSD); and GPRS. </p> <fig id="GUID-64CF6B77-F451-56F2-9223-4DB0AE835E56"><title>

          Example of a bearer change 

        </title> <desc><p>A device is connected to a mobile network using GPRS. The device comes into range of a Wi-Fi network. The device decides to change to the Wi-Fi network and creates a bearer to access the Wi-Fi network. The device then moves all the existing connections across to the Wi-Fi bearer. In the final step the device disconnects from the GPRS network. </p> </desc> <image href="GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e64237_href.png" placement="inline"/></fig> <p>Bearer Mobility operates in response to changes in the environment of the device. A bearer is known as <i>available</i> when the device is in range of the bearer and the device can potentially use the bearer. </p> <p> <b>NOTE:</b> The bearer can be available but unusable because of the security requirements of the bearer. </p> <p>Symbian OS uses <i>non-seamless</i> Bearer Mobility. Non-seamless indicates that clients of the Socket Server must reconnect all sockets after the bearer has changed. The local IP address of the link changes if the bearer changes. </p> <section><title>Bearer Mobility APIs</title> <p>Two Socket Server Bearer Mobility APIs are available: <xref href="GUID-D5F43DFB-5143-3563-8655-16E245A9735F.dita"><apiname>RCommsMobilityApiExt</apiname></xref> and <xref href="GUID-6CA83252-4D0C-3B72-83ED-B5152B666C83.dita"><apiname>CActiveCommsMobilityApiExt</apiname></xref>. A client of the Socket Server cannot change bearer if the client does not use at least one Bearer Mobility API. A device can have clients that support Bearer Mobility and clients that do not support Bearer Mobility. If clients that support Bearer Mobility change bearer, the device does not disconnect a client that does not support Bearer Mobility unless that client's bearer is no longer available. </p> <p>A client of the socket server can ask the user to accept or deny the change of bearer. For example, the client can display a dialog box to ask the user to accept or deny the change. The decision to ask the user remains with the client. </p> <p>A client of the socket server can ask to use the default bearer. The default bearer is the highest priority bearer that is available. The device manufacturer or network operator creates the list of bearer priorities. </p> </section> <section id="GUID-717F07AE-6C85-5051-9CCB-9B23FC40DADD"><title>Bearer Mobility Blacklists</title> <p>The Bearer Mobility components in the Communications Architecture implement a <i>blacklist</i> feature. The Socket Server implements the blacklist feature on the server side. The blacklist feature affects the notifications that a Socket Server client receives. The blacklist feature stops notifications for bearer changes that have previously been rejected. The device keeps a blacklist for each client. </p> <p>For example: </p> <ol id="GUID-8B1E6BD1-AE7B-5BDB-A73E-A4D0FC194AF9"><li id="GUID-683FD641-5E1A-58D7-B171-2B6E28FACF0D"><p>A client receives a notification for a bearer change </p> </li> <li id="GUID-5AE721C6-10ED-5E48-9C03-451CAD47B474"><p>The client sends a response to reject the bearer change </p> </li> <li id="GUID-4AEE582D-C6E4-534E-999E-BFDC1F7C4237"><p>The device adds the rejected bearer to the blacklist for that client </p> </li> <li id="GUID-9AAD65F6-94A2-5704-B224-47A93EA9F7B6"><p>The device does not notify the client of any further opportunities to change to that bearer </p> </li> </ol> <p>There can be variations in the operation of the blacklist. For example, there can be a limit on the lifetime of the blacklist. </p> <p> <b>NOTE:</b> The blacklist scheme is dependent on the plug-ins and settings used for the Communications Architecture for the particular device. </p> </section> </conbody><related-links><link href="GUID-CB1E1921-9CF7-55B7-9F70-6AD61A961208.dita"><linktext>Using the

                Bearer Mobility APIs</linktext> </link> </related-links></concept>