<?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_d0e112717_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>