s60 platform: ip bearer management

S60 Platform: IP Bearer Management

S60

p

la

tf

or

m

Version 1.0 February 22, 2007

S60 Platform: IP Bearer Management | 2 Legal notice

Copyright © 2007 Nokia Corporation. All rights reserved.

Nokia and Forum Nokia are registered trademarks of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners.

Disclaimer

The information in this document is provided “as is,” with no warranties whatsoever, including any warranty of merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or sample. Furthermore, information provided in this document is preliminary, and may be changed substantially prior to final release. This document is provided for informational purposes only.

Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to implementation of information presented in this document. Nokia Corporation does not warrant or represent that such use will not infringe such rights.

Nokia Corporation retains the right to make changes to this specification at any time, without notice.

The phone UI images shown in this document are for illustrative purposes and do not represent any real device.

License

A license is hereby granted to download and print a copy of this specification for personal use only. No other license to any other intellectual property rights is granted herein.

Version 1.0 | February 22, 2007

S60 Platform: IP Bearer Management | 3 Contents

1. Introduction ......................................................................................................... 5 2. S60 network model and APIs ............................................................................. 6

2.1 Internet Access Points (IAPs) .........................................................................................6 2.2 Service Network Access Points (SNAPs) .......................................................................6 2.3 Network APIs ..................................................................................................................7

3. Automatic network selection ............................................................................. 9 4. Application-level roaming ................................................................................ 11 5. Network-level roaming...................................................................................... 13 6. Application settings .......................................................................................... 14 7. User control in network selection.................................................................... 15 8. Handling multiple applications ........................................................................ 16 9. IAP/SNAP configuration ................................................................................... 17 10. IAP availability detection .................................................................................. 18 11. Connectivity problems...................................................................................... 19

11.1 Connection breaks ........................................................................................................19 11.2 IAP interchangeability ...................................................................................................19

12. Battery lifetime .................................................................................................. 20 12.1 Problems with NATs......................................................................................................20

13. Compatibility issues ......................................................................................... 22 14. Terms and abbreviations.................................................................................. 23 15. Evaluate this resource ...................................................................................... 24


S60 Platform: IP Bearer Management | 4 Change history

February 22, 2007 Version 1.0 Replaces the document S60 Platform: Application Networking Considerations.


S60 Platform: IP Bearer Management | 5

1 . I n t r o d u c t i o n

The traditional assumption in Internet applications has been that a host has one route to the global Internet for all IP access. That route is specified when the system is configured, so applications just open a socket, without needing to worry about which route the traffic will use.

Laptop computers introduced the issue of changing connection point: the user can unplug the computer and plug it again later, possibly in a different location. Alternatively, the user can switch to WLAN if a wired connection is not available. Either way, the connection setup is still done explicitly by the user, by plugging the cable or activating the WLAN.

In mobile devices, movement is constant. A mobile device enables users to make or receive calls without explicit network selection and continue the calls even while moving, automatically. It would be natural to assume that the same thing could happen with IP-based services.

If users have WLAN at home or in the office, they would probably like to use it when available, even if they would use GPRS elsewhere. To make this kind of selection easy for users, S60 3rd Edition, Feature Pack 2 provides two new services:

1. Automatic network selection: The application or the user does not need to specify a specific network technology or access point to be used. The system automatically selects the one that is currently the best.

2. Application-level roaming: When the device moves, the system can notify the application that a better access technology has become available or the currently used connection is lost, and provide help in reconnecting using another access network.

For many applications, automatic network selection alone gives a big usability improvement. Application-level roaming brings additional benefit, particularly for applications that keep connections open for extended periods.

Wireless networks have limited geographical coverage and suffer from radio disturbance. The connection may abruptly be lost and data rate may greatly vary during the connection. An application must be prepared for connectivity breaks and adapt to the characteristics of the connection to provide optimal user experience.

In mobile devices with small batteries, applications must be very conservative in using power to guarantee acceptable use and standby times. In a wireless environment, keeping a connection open consumes power, even when there is no actual data traffic. In some network environments such idle connections can ruin battery life if not done properly.



2 . S 6 0 n e t w o r k m o d e l a n d A P I s

2.1 Internet Access Points (IAPs)

S60 traditionally shows potential IP links as Internet Access Points (IAPs).

An IAP describes the link technology and the associated parameters. These might be technology specific, such as a telephone number for dial-up, an access point name for GPRS, or a Service Set Identifier (SSID) for WLAN. In addition, an IAP might store IP-specific general settings, such as the addresses of default gateways and DNS servers.

The system can also include ‘virtual’ IAPs that represent additional protocols on top of the actual link. An example of such virtual IAPs is VPN (virtual private network) where the virtual IAP specifies the information needed to establish the VPN secure tunnel on top of some of the ‘actual’ IAPs.

When an application opens a network connection, it must be associated with one of the IAPs, as selected by the user either statically in application settings or dynamically each time the application opens a network connection. The list to select from includes all IAPs configured in the system, including the virtual IAPs (see Figure 1).

CompanyWLAN

Home WLAN

dna WLAN

Sonera HomeRun 1X

Sonera HomeRunData bearer: WLAN

Sonera MMS

Sonera WAP

Sonera Streaming

Sonera internetProinternet

InternetData bearer: Packet data Access point Name: internetUser Name: NonePrompt password: NoPassword: ****Authentication: NormalHomepage: www.sonera.fiType: IPv4IP address: AutomaticDNS address: AutomaticProxy serv addr: NoneProxy port nbr: 0

VPN_ACCESS_SINGAPORE

VPN_ACCESS_DALLAS

User selects

VPN_ACCESS_ESPOOVPN Policy: VPN_ESPOO Internet Access pt.: CompanyWLANUser Name: NoneProxy serv address: xyz.company.comProxy port number: 8080

CompanyWLAN

Home WLAN

dna WLAN

Sonera HomeRun 1X


Sonera MMS

Sonera WAP

Sonera Streaming

Sonera internetProinternet

InternetData bearer: Packet data Access point Name: internetUser Name: NonePrompt password: NoPassword: ****Authentication: NormalHomepage: www.sonera.fiType: IPv4IP address: AutomaticDNS address: AutomaticProxy serv addr: NoneProxy port nbr: 0


VPN_ACCESS_DALLAS

User selects


Figure 1: IAP-based network selection. The user must select from a long list of IAPs and can easily have difficulties in deciding which one to choose.

2.2 Service Network Access Points (SNAPs)

S60 3rd Edition, Feature Pack 2 introduces the new concept of Service Network Access Points (SNAPs). A SNAP represents a set of hosts or services to be reached, for example Internet, corporate intranet, or operator service. A SNAP groups together a set of IAPs that can be used to reach those hosts and services, and it is associated with a policy to select the best among the IAPs. In the first versions this policy is static priority ordering.


S60 Platform: IP Bearer Management | 7 Each network connection must still be associated with an IAP, but it is now selected in two phases; see Figure 2. The user now selects a SNAP from a much shorter list, and the system selects the actual IAP to be used.

Operator services

Company Intranet User selects SNAPInternet

System selects IAPCompanyWLAN

Home WLAN dna WLAN

Sonera HomeRun 1X


Sonera MMSSonera WAP

Sonera StreamingSonera internet

ProinternetInternet

Data bearer: Packet data Access point Name: internetUser Name: NonePrompt password: NoPassword: ****Authentication: NormalHomepage: www.sonera.fiType: IPv4IP address: AutomaticDNS address: AutomaticProxy serv addr: NoneProxy port nbr: 0


VPN_ACCESS_DALLAS


Operator services

Company Intranet User selects SNAPInternet

System selects IAPCompanyWLAN

Home WLAN dna WLAN

Sonera HomeRun 1X




ProinternetInternet



VPN_ACCESS_DALLAS


CompanyWLAN

Home WLAN dna WLAN

Sonera HomeRun 1X




ProinternetInternet



VPN_ACCESS_DALLAS


Figure 2: SNAP-based selection. The list to select from is short and easy to understand.

Both SNAP and IAP are API terms — the end user will not see those terms in the user interface. The actual terms used in the user interface are more descriptive and depend on the language variant.

2.3 Network APIs

The application interfaces associated with connection management in S60 3rd Edition, Feature Pack 2 are:

Sockets Client API (RSocket)

The Symbian socket API remains unchanged, but applications need to be ready to close and open sockets at certain times to roam to a better connection.

Connection Manager API (RConnection, RCommsMobilityApiExt)

This API has been enhanced to contain the new mobility-related methods and events.

Agent Dialog API



This API provides a dialog for connection selection. It is enhanced to support SNAPs. Applications should not call this directly but let the system activate it.

Connection Monitor Server API

This API provides availability information. It is possible to query, for example, available SNAPs, IAPs, radio bearers, or WLAN SSIDs. Various information about active connections is also offered.

Connection Settings UI API

This API provides a UI dialog that lets the user select connection settings (SNAP or IAP) to be saved in application’s settings. The Connection Settings UI API was introduced in S60 3rd Edition, Feature Pack 2, and it replaced the Access Point Settings Handler API.

Connection Settings API

This API provides methods to read connection settings from CommsDat. The Connection Settings API was introduced in S60 3rd Edition, Feature Pack 2, and it replaced the Access Point Engine API.



3 . A u t o m a t i c n e t w o r k s e l e c t i o n

The user might have different network preferences in different places or at different times. The user might want to use WLAN at home but cellular while moving.

For good user experience, it is important to make the network selection natural and easy. The user should not be forced to update any application or system settings when starting an application in a new environment. This is where the SNAP selection is superior to IAP selection: instead of switching between ‘HomeWLAN’ and ‘GPRS’ IAPs, the selection may always be ‘Internet’. The system selects the actual IAPs based on the situation.

Figure 3 outlines the steps in initial network selection.

Application Connection Manager API Sockets Client API

1: RConnection::Start (SNAP = Internet)

2: RConnection handle

3: Create socket (RConnection handle)

4: RSocket handle

Normal socket communication





4: RSocket handle


Figure 3: Basic sequence in initial network selection1

1-2 The application calls RConnection::Start with a SNAP (in this case “Internet”) specified as a connection preference. The call selects the best IAP, activates it, and associates it with the RConnection handle. If no preference is given, the call activates a prompt to the user, as shown later in this chapter. It should be noted that this is not a new call. In earlier S60 editions, this same call could be used to specify an IAP preference — only the possibility to specify a SNAP preference is new.

3-4 The application opens one or more sockets and starts using them.

If the application has IAP-specific settings, such as proxy names or buffer sizes, it can find out which IAP was selected and adjust the settings accordingly.

1 The labels in the picture are a mixture of method names, information entities, or

comments.


S60 Platform: IP Bearer Management | 10 If the application does not specify the SNAP preference in RConnection::Start, or opens a socket without using RConnection at all, the system prompts the user, as shown in Figure 4.

Explicit IAP selection is also possible

IAP that would be selected now

Filtered list of SNAPs,i.e. all SNAPs that have one or more available IAPs.

User selects Internet

Explicit IAP selection is also possible

IAP that would be selected now

Filtered list of SNAPs,i.e. all SNAPs that have one or more available IAPs.

User selects Internet

Figure 4: User view if the application does not provide a SNAP preference

The prompt shows the list of available SNAPs, together with the IAP that would now be selected. After the selection, the user is informed about the steps of the connection process, depending on the system configuration.

For compatibility reasons the application or the user can still select an IAP in the old way by using the “options” menu, but that is not recommended.

The simple change of using a SNAP preference instead of an IAP preference makes a big improvement in user experience, so this should be implemented by all networking applications that are not tied to a single specific IAP, even if they would not implement the bearer change logic.

In earlier S60 versions, the IAP selection dialog used to be activated by the applications directly. It is now recommended that applications let the system activate it, by leaving the preference unspecified in RConnection::Start.



4 . A p p l i c a t i o n - l e v e l r o a m i n g

Application-level roaming is an enhancement to automatic network selection, where the system continuously observes network availability and proposes network change when appropriate — when a better network has become available or the current network is lost. This is called application-level roaming — contrasted to network-level roaming discussed in the next chapter — to highlight the fact that the application is in the key role in deciding whether and when to change the network.

Figure 5 outlines the basic sequence in application-level roaming.




3. NewL(RConnection handle, MMobilityProtocolResp&)


5: RSocket handle


6: PreferredCarrierAvailable(old IAP, New IAP, IsUpgrade)

7: Close socket

8: MigrateToPreferredCarrier


Check socket functionality if needed

11: NewCarrierAccepted or NewCarrierRejected

Better IAP becomes available

9: NewCarrierActive




3. NewL(RConnection handle, MMobilityProtocolResp&)


5: RSocket handle


6: PreferredCarrierAvailable(old IAP, New IAP, IsUpgrade)

7: Close socket

8: MigrateToPreferredCarrier


Check socket functionality if needed

11: NewCarrierAccepted or NewCarrierRejected

Better IAP becomes available

9: NewCarrierActive

Figure 5: Basic sequence in application-level roaming

1-2 Application calls RConnection::Start with a SNAP (in this case “Internet”) specified as a connection preference. The call selects the best IAP, activates it, and associates it with the RConnection handle. If no preference is given, the system prompts the user, as discussed in the previous chapter. In this case the system selects a GPRS IAP. It should be noted that this is not a new call. In earlier S60 editions, this same call could be used to specify an IAP preference — only the possibility to specify a SNAP preference is new.

3 The application registers to the mobility management system of the RConnection API, to receive mobility notifications. To get the callbacks, the application has to implement two methods defined in RCommsMobilityApiExt: PreferredCarrierAvailable and NewCarrierActive.


S60 Platform: IP Bearer Management | 12 4-5 The application opens one or more sockets and starts using them.

6 At some point the application gets a notification that a better IAP is available; for example, the user has arrived home and WLAN has become available.

7 If the application decides to change the connection, it should close the sockets at this point since migrating to the new IAP changes the IP address and breaks the sockets anyway.

8-10 The application asks the system to migrate to the new IAP. The system activates the respective IAP and changes the RConnection handle to refer to that. When the system has notified that the new carrier is active, the application can reopen the sockets using the original RConnection handle.

11 The application still has the option to cancel the change if some application-specific issues make the new IAP unusable, so the application has to call either the accept or reject method to conclude the change. In the reject case the proposed IAP is blacklisted for that RConnection handle and a new selection is made. The bearer is automatically restored but the application must anyhow reopen the sockets.

It should be noted that applications should also support user-initiated network change, that is, provide a menu item that the user can select and thus force the application to change the network.



5 . N e t w o r k - l e v e l r o a m i n g

Network-level roaming is an enhancement to automatic network selection where the system changes the IAP selection on-the-fly when network availability changes — when a better network has become available or the current network is lost. Network-level roaming differs from application-level roaming in that the application is not involved in change decision and the change is seamless to the application — sockets and application state remain valid.

Network-level roaming is not supported directly in the S60 platform but can be built on top of the existing application-level roaming support.

Network-level roaming is based on IETF mobility enhancements, such as Mobile IPv4, Mobile IPv6, or VPN Mobike extension. In a network-level roaming implementation the mobility protocol receives the mobility notifications and changes the link accordingly. The application is still able to get the notifications for an IAP change — to be able to adjust to the characteristics of the new bearer — but would have no control over the actual choice.

Mobile IP and Mobike require support both in the device and in the network — they do not work unless someone is hosting a Mobile IP home agent service or respective security gateway service in the network. This could be an operator, an Internet service provider (ISP), an enterprise, or a specialized mobility service provider.

It should be noted that network-level roaming will not replace application-level roaming. Initially application-level roaming is the primary method since mobile IP deployment is rare. Mobile IP will never be available in all markets and customer segments, so the need for application-level roaming will persist.

The S60 bearer management architecture is such that different types of roaming can coexist in the same device. Some applications could rely on network-level roaming, some use application-level roaming, and some use a fixed IAP.



6 . A p p l i c a t i o n s e t t i n g s

Networking-enabled applications must store a network preference in their own settings, and should support both SNAP and IAP preference.

Selecting a SNAP preference enables bearer mobility between the IAPs associated with that SNAP. Selecting an explicit IAP preference disables the mobility support; the system will always try to use that particular IAP for connecting.

Preference can also be of “always ask” type, where the actual SNAP or IAP is not stored in the settings, but will be prompted when the application starts an IP connection.

S60 provides the Connection Settings UI API that applications should activate to request the preference from the user (see Figure 6). The dialog lets the user select “always ask” or some of the existing SNAPs in the main view, and any of the existing IAPs in the Options submenu.

In earlier S60 Editions, an application that supported the “Always ask” functionality launched directly the dialog that prompts the actual IAP from the user. In S60 3rd Edition, Feature Pack 2 this is not recommended. The application should instead call RConnection.Start without SNAP or IAP preference, which causes the system to prompt the user, as shown in Figure 4. This assures that the dialog and behavior is consistent in all applications.

Options |

Settings

Options |

Settings

Figure 6: An example of connection selection for application settings

Some applications have IAP-specific settings, such as server or proxy settings. To make the selection easy for the user, the application should select the correct settings automatically based on the selected IAP, and not request the user to type anything.

Different bearers can have highly different characteristics, and taking those into account when designing an application can greatly improve the end-user experience. Examples of relevant bearer characteristics are Quality of Service (data rate, delay, jitter, and so on), and usage cost, both money and battery power.

Bearer properties should guide application behavior. In slow or expensive connections all traffic should be avoided unless explicitly requested by the user. In fast and flat-rate connections it might be a good idea to download data in advance for later use.

Currently there is no general way for the application to find out the properties of a specific connection, so the application has to make an assumption based on the bearer technology, even if in wireless technologies the actual data rate can vary greatly within a single technology.



7 . U s e r c o n t r o l i n n e t w o r k s e l e c t i o n

Sending data over a network causes cost to the user. Therefore, the user may want to control the network selection and not entirely trust the system.

Each IAP contains a flag indicating whether the user must confirm its usage. The confirmation applies both to the initial network selection and later network change. Confirmation is not asked if the IAP is already active: for example, some other application is already using it.

Figure 7 and Figure 8 show examples of confirmation dialogs.

In the case of the initial selection, confirmation is asked if the application specifies the SNAP or IAP in RConnection::Start. If the user explicitly selects the SNAP or IAP from a dialog, confirmation is not asked — the user can see the IAP to be chosen.

In the case of the network change, confirmation is asked after the application has indicated its desire to change the network.

If the IAP is not configured to require user confirmation, the system shows a pop-up window showing which network is being selected.

WLANWLAN

Figure 7: Confirmation when a better IAP becomes available

GPRSGPRS

Figure 8: Confirmation when the current connection is lost



8 . H a n d l i n g m u l t i p l e a p p l i c a t i o n s

In application-level roaming every application makes its roaming decisions independently.

If two concurrent applications have a connection using the same SNAP, they probably share the same PDP context or use the same WLAN connection. When they both receive a change notification, they may make different decisions on whether and when to change.

Independent decisions is no problem for the system — two or more connections using the same IAP can start using different IAPs as applications make their roaming decisions in different pace, and possibly later on end up using a common IAP again.

For the end user the situation with multiple applications can be confusing. As an example, when coming home with flat-fee WLAN, the user might be tempted to start big downloads with the browser, and not notice that browser is still using GPRS — it was e-mail that switched to WLAN.

The user might assume that the change concerns all data connections from any applications. To minimize the problem, applications should take the notifications seriously and change to the proposed IAP, except when completing ongoing transactions. If the application cannot change to the proposed IAP due to some technical reason, this should be clearly visible to the user.

It should be noted that IAP confirmation and initialization progress is only shown when the IAP is going to be activated — for the first application to use it. For the second application the IAP is already active and there is no need for confirmation or progress indication. The confirmation dialog and progress pop-up window neither specify which application caused the IAP activation.



9 . I A P / S N A P c o n f i g u r a t i o n

For the data roaming or any IP networking to work, IAPs and SNAPs need to be configured or provisioned in the device.

The user can define and modify SNAPs and IAPs using the S60 user interface.

Alternatively, SNAP and IAP definitions can be provisioned in the device through any of the following methods2:

A client provisioning system can set the SNAPs and IAPs based on an SMS message containing the respective specifications.

A device management system in the device can update the SNAP and IAP specifications on the fly as instructed by the respective system in the cellular network.

A device may also provide a special startup program which can set the SNAPs and IAPs when the device is started for the first time, based on the operator whose SIM card is in the device (device-specific feature, implemented in Nokia devices).

A provisioned definition can be protected against changes from the UI. In this way the operator can guarantee the existence and contents of specific SNAPs and IAPs.

The number of SNAPs should be kept small; otherwise much of the benefit is lost.

2 Support of the provisioning methods may vary depending on device model, market, operator, and so on.



1 0 . I A P a v a i l a b i l i t y d e t e c t i o n

Roaming proposals are based on IAP availability information from different bearers.

A cellular IAP is available when cellular coverage exists — the system will not check whether the IAP is correctly configured and really works. If a SNAP preference is given in connection opening, the system skips a GPRS IAP if it cannot open a PDP context. The system does not transfer any data through that PDP context, so checking the real connectivity is left to the application.

WLAN IAP is available when background scan has detected the network (SSID) associated with it. It should be noted that a WLAN radio cannot connect to more than one network at a time. Therefore, as long as a connection to one WLAN network is active, all other WLAN networks are unavailable.

There might be applications or tasks that only make sense when a certain IAP is available. Examples might be an application that synchronizes a mailbox when WLAN is available, or an application that synchronizes the device with a home picture gallery when home WLAN becomes available. To implement such behavior, applications can request notification on IAP availability change from the Connection Monitor Server API.



1 1 . C o n n e c t i v i t y p r o b l e m s

11.1 Connection breaks

Wireless networks have limited geographical coverage and suffer from radio disturbance. The connection may abruptly be lost and data rate may greatly vary during the connection. An application must be prepared for connectivity breaks and adapt to the characteristics of the connection to provide optimal user experience.

Any application that depends on network connections in a wireless device should be prepared to the situation where one or more of the required connections cannot be established or stop working. The application should in all conditions remain responsive to user actions — it should never keep a user stuck waiting for a network operation to complete or a time-out to expire.

The connectivity problem or break can be temporary or permanent. A temporary break — where connectivity comes back without further actions — might be due to a brief loss of the radio signal, or a handover delay.

If the temporary break does not raise any errors to the application, the application might not notice the whole situation, unless it has set timers or other means to monitor the data rate. Applications should be prepared for some silence: even if handover from the WCDMA to GSM network is seamless for voice calls, TCP connections can experience an interrupt of tens of seconds in data traffic.

11.2 IAP interchangeability

Even if multiple interfaces generally provide similar access — for example, to the public Internet — they are not identical. All networks can have connectivity problems, which may include any of the following scenarios:

An operator or ISP deliberately restricts access to some domains, pages with a certain type of content, or use of some protocols.

Network structure, for example use of NATs, prevents some access, either initially or after some inactivity.

Some services are only available through a specific access point; for example, some operator services might only be available through their own access point.

There may be temporary problems in the network for various reasons.

If the application cannot connect to the service using some network, it obviously must try another network until reachability is obtained. Some applications might find it useful to keep a black list of known bad IAPs or a white list of known good IAPs. Remember, however, that such lists must be dynamic, because the situation may change at any time. Problems come and go, and an otherwise good link may be bad for some access. In the case of a Web browser, for example, some Web pages may be accessible via some networks, while other pages are accessible via other networks.

It is not yet known how serious this problem will be in the real world — whether it is a temporary problem that will be solved by better network design or a real problem that needs to be resolved in the device.



1 2 . B a t t e r y l i f e t i m e

A specific issue in mobile devices is battery lifetime. Laptop computers basically face the same problem, but user expectations are different. Laptop users do not expect the battery to last more than a few hours without recharging and they generally have the power connected. Mobile devices have much smaller batteries, but users are used to recharge intervals ranging from a few days to a week, and they are not happy if their new device requires daily recharging.

An application should be designed to be battery friendly — a badly designed application can drain the battery in a few hours. The application should allow the system to be in a power-save mode most of the time, meaning that all background activity should be carefully considered and minimized. Power should only be used for activities that the user can clearly see and benefit from. In addition, if the application uses polling, it would be sensible to give the user the option to select between frequent polling leading to faster reaction to changes and infrequent polling leading to longer battery life.

Many network applications are user driven — the user explicitly activates the application to perform some network operation. Some network applications are event driven, waiting in the background for some change in the network and signaling the user about the event. Examples of such applications are incoming phone calls or e-mail.

The Internet approach for waiting is to open a TCP or UDP socket to listen to incoming messages. In cellular networks, this approach has problems. An application cannot trust that the connection will remain open — it may get closed by the network due to inactivity or some network problem, for example in handovers. This means that the application must periodically send data to check the connection status or to keep it open.

Persistent connections are difficult to maintain and severely restrict battery life and standup time. The need for such connections should be carefully considered, particularly in cellular networks. It is clear that an incoming VoIP call or equivalent must be acted on immediately, but it is not clear that incoming mail must always be delivered immediately.

12.1 Problems with NATs

NATs (Network Address Translators) are commonly used in the IPv4 Internet to reduce the need for globally unique IP addresses. A local network may use IP addresses from one of the private IP address ranges (for example, 192.168.x.x and 10.x.x.x) and use a NAT router to connect to the Internet. As devices send traffic from the local network, the NAT router translates the local IP address to one of its own public addresses.

The NAT needs to maintain a mapping table between the local private address and the global address; otherwise it would not be able to route responses from the global Internet back. The NAT mappings are automatically created and are associated with a guaranteed lifetime, a device-specific configuration parameter. Typical default values for the guaranteed lifetime in commonly used NAT devices are 40–180 seconds for UDP mappings and 30–60 minutes for TCP mappings.

Because the NAT mappings are created based on uplink packets from the devices, servers or external correspondents are not able to initiate connections to the device. When a NAT is used, the device behind the NAT must always be the initiating party. Additionally, the device must periodically send messages to keep the mapping alive.

Sending a message, even a short one, requires the system to leave the power-save sleep mode, and returning to power-save might take a considerable time, depending on the network technology and its configuration settings.


S60 Platform: IP Bearer Management | 21 Investigations have shown that keep-alive messages can be especially harmful in cellular networks; in some studies in a WCDMA network, sending keep-alive messages often enough to keep a default-configured UDP NAT port open, shortened battery life to a few hours, even when there was no other activity in the device.

Some network layer protocols do not work over NAT at all, unless the traffic is enclosed in UDP. An example of such a protocol is an IPSec-based virtual private network (VPN) that maintains keep-alive traffic by itself, with a configurable keep-alive interval.

If an always-on connection is needed, the NATs should be reconfigured to longer guaranteed lifetimes. If this is not possible, TCP should be used instead of UDP, with a keep-alive interval of 15 minutes. Always-on connections should not be used over VPN tunnels in cellular networks if a NAT is expected.



1 3 . C o m pa t i b i l i t y i s s u e s

The SNAP concept and related APIs are new in S60 3rd Edition, Feature Pack 2. Applications using the new SNAP functionality or the new APIs do not work in earlier S60 versions.

Applications developed for earlier S60 3rd Edition versions continue to work in Feature Pack 2 basically as before. As a new feature, if the application does not specify an IAP when opening the connection, the system activates the new dialog that enables the user to select either a SNAP or an IAP — in the SNAP case the system selects the best IAP. Any network selection dialog that the application activates directly follows the old style, showing only IAPs.



1 4 . Te r m s a n d a b b r e v i a t i o n s

Term or abbreviation

Meaning

API Application programming interface.

DNS Domain name system. Provides translation between Internet domain names (such as www.nokia.com) and IP addresses (such as 147.243.3.83).

GPRS General packet radio service. Packet-based wireless communication service in GSM and WCDMA networks.

GSM Global System for Mobile Communications. A widely used digital mobile telephone system.

IAP Internet Access Point. Defines a network interface and its connection parameters in Symbian OS.

IPv4 Internet Protocol version 4. Original protocol for sending data from one computer to another on the Internet.

IPv6 Internet Protocol version 6. Improved version of the Internet Protocol.

ISP Internet service provider.

NAT Network address translator. A device that translates an IP address used within one network to a different IP address known within another network.

PDP Packet data protocol. Part of GPRS specification.

PDP context Represents a packet data session in GPRS networks.

SSID Service Set Identifier. Differentiates one WLAN network from another.

SNAP Service Network Access Point. In Symbian OS defines a set of IAPs and a selection policy between them.

TCP Transmission control protocol. Provides connection-oriented data sending on top of IPv4 or IPv6.

UDP User Datagram Protocol. Provides connectionless data sending on top of IPv4 or IPv6.

VoIP Voice over IP. Delivering voice over the Internet network.

VPN Virtual private network.

WCDMA Wideband code division multiple access. A third-generation (3G) mobile wireless technology.

WLAN Wireless local area network.



1 5 . E v a l u a t e t h i s r e s o u r c e

Please spare a moment to help us improve documentation quality and recognize the resources you find most valuable, by rating this resource.


http://www.forum.nokia.com/main/1%2C%2C90%2C00.html?surveyId=190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf

s60 platform: ip bearer management

Documents