|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-EDC16636-B24E-598B-9084-EAE782A4A213" xml:lang="en"><title>What |
|
13 is Bearer Mobility</title><shortdesc>This topic describes the concept of <i>Bearer Mobility</i> in the |
|
14 Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <p>Bearer Mobility is a feature that allows a device to change bearers without |
|
16 interruption to the user's data sessions. An example of a bearer change is |
|
17 if a device moves into the range of a Wi-Fi hot spot and the device moves |
|
18 the GPRS connections over to Wi-Fi. Example data sessions include: streaming |
|
19 videos; surfing the internet; and downloading emails. Example bearers include: |
|
20 Wireless LAN (eg Wi-Fi); 3G (including HSUPA and HSDPA); Circuit Switched |
|
21 Data (CSD); and GPRS. </p> |
|
22 <fig id="GUID-64CF6B77-F451-56F2-9223-4DB0AE835E56"> |
|
23 <title> Example of a bearer change </title> |
|
24 <desc><p>A device is connected to a mobile network using GPRS. The device |
|
25 comes into range of a Wi-Fi network. The device decides to change to the Wi-Fi |
|
26 network and creates a bearer to access the Wi-Fi network. The device then |
|
27 moves all the existing connections across to the Wi-Fi bearer. In the final |
|
28 step the device disconnects from the GPRS network. </p> </desc> |
|
29 <image href="GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e84262_href.png" placement="inline"/> |
|
30 </fig> |
|
31 <p>Bearer Mobility operates in response to changes in the environment of the |
|
32 device. A bearer is known as <i>available</i> when the device is in range |
|
33 of the bearer and the device can potentially use the bearer. </p> |
|
34 <p> <b>NOTE:</b> The bearer can be available but unusable because of the security |
|
35 requirements of the bearer. </p> |
|
36 <p>Symbian platform uses <i>non-seamless</i> Bearer Mobility. Non-seamless |
|
37 indicates that clients of the Socket Server must reconnect all sockets after |
|
38 the bearer has changed. The local IP address of the link changes if the bearer |
|
39 changes. </p> |
|
40 <section id="GUID-0C818D67-819E-417B-9DBE-53E439555E57"><title>Bearer Mobility APIs</title> <p>Two Socket Server Bearer Mobility |
|
41 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>. |
|
42 A client of the Socket Server cannot change bearer if the client does not |
|
43 use at least one Bearer Mobility API. A device can have clients that support |
|
44 Bearer Mobility and clients that do not support Bearer Mobility. If clients |
|
45 that support Bearer Mobility change bearer, the device does not disconnect |
|
46 a client that does not support Bearer Mobility unless that client's bearer |
|
47 is no longer available. </p> <p>A client of the socket server can ask the |
|
48 user to accept or deny the change of bearer. For example, the client can display |
|
49 a dialog box to ask the user to accept or deny the change. The decision to |
|
50 ask the user remains with the client. </p> <p>A client of the socket server |
|
51 can ask to use the default bearer. The default bearer is the highest priority |
|
52 bearer that is available. The device manufacturer or network operator creates |
|
53 the list of bearer priorities. </p> </section> |
|
54 <section id="GUID-717F07AE-6C85-5051-9CCB-9B23FC40DADD"><title>Bearer Mobility |
|
55 Blacklists</title> <p>The Bearer Mobility components in the Communications |
|
56 Architecture implement a <i>blacklist</i> feature. The Socket Server implements |
|
57 the blacklist feature on the server side. The blacklist feature affects the |
|
58 notifications that a Socket Server client receives. The blacklist feature |
|
59 stops notifications for bearer changes that have previously been rejected. |
|
60 The device keeps a blacklist for each client. </p> <p>For example: </p> <ol id="GUID-8B1E6BD1-AE7B-5BDB-A73E-A4D0FC194AF9"> |
|
61 <li id="GUID-683FD641-5E1A-58D7-B171-2B6E28FACF0D"><p>A client receives a |
|
62 notification for a bearer change </p> </li> |
|
63 <li id="GUID-5AE721C6-10ED-5E48-9C03-451CAD47B474"><p>The client sends a response |
|
64 to reject the bearer change </p> </li> |
|
65 <li id="GUID-4AEE582D-C6E4-534E-999E-BFDC1F7C4237"><p>The device adds the |
|
66 rejected bearer to the blacklist for that client </p> </li> |
|
67 <li id="GUID-9AAD65F6-94A2-5704-B224-47A93EA9F7B6"><p>The device does not |
|
68 notify the client of any further opportunities to change to that bearer </p> </li> |
|
69 </ol> <p>There can be variations in the operation of the blacklist. For example, |
|
70 there can be a limit on the lifetime of the blacklist. </p> <p> <b>NOTE:</b> The |
|
71 blacklist scheme is dependent on the plug-ins and settings used for the Communications |
|
72 Architecture for the particular device. </p> </section> |
|
73 </conbody><related-links> |
|
74 <link href="GUID-CB1E1921-9CF7-55B7-9F70-6AD61A961208.dita"><linktext>Using the |
|
75 Bearer Mobility APIs</linktext></link> |
|
76 </related-links></concept> |