<?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 id="GUID-EDC16636-B24E-598B-9084-EAE782A4A213" xml:lang="en"><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_d0e77550_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 platform 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 id="GUID-0C818D67-819E-417B-9DBE-53E439555E57"><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>