Heartbeat Interval Adjustment

6/2/2010

The heartbeat begins at the default rate. The heartbeat interval is specified by the client and is sent as part of the ping request. The direct push algorithm on the client then dynamically adjusts the heartbeat interval to maintain the maximum time between heartbeats without exceeding the time-out value.

To determine the optimal heartbeat interval, the algorithm keeps a log of ping requests. If a ping request receives a response, the algorithm increases the interval. If no response is received at the end of the interval, the client determines that the network timed out and the interval is decreased as follows:

• If the heartbeat was not increased during the last ping, the heartbeat is changed to the minimum heartbeat value.
• If the heartbeat was increased during the last ping, then it is changed back to the previous heartbeat.

The algorithm also uses the following configurable settings:

• HeartbeatIncrement that indicates the maximum amount that the interval can be increased or decreased.
• HeartbeatMin and HeartbeatMax indicate the maximum interval allowed.

By using this algorithm, the client eventually determines the longest idle connection possible across the cellular network and corporate firewall.

The following illustration shows how the heartbeat interval is adjusted during typical direct push communication between the client and the Exchange Server.

The “T” in this illustration indicates the progression of time.

The following steps describe the communication; the numbers correspond to the numbers in the illustration:

1. The client wakes up and issues an HTTP request over the Internet to the Exchange Server, and then goes to sleep.
   To keep the session active, the request states the heartbeat interval, which is the amount of time that the server should wait for PIM changes or new mail to arrive before sending OK to the client. In this illustration, the heartbeat interval is 15 minutes.
2. Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
   In this example, the response is lost because either the operator network or the Enterprise network was unable to sustain the long-lived HTTP connection; the client never receives it.

Note

If the connection is closed by the front-end Exchange server, the device will acknowledge the ended session and immediately reconnect. If the connection is closed by the back-end Exchange server, the device does not acknowledge the ended session and waits for the end of the heartbeat interval to reconnect.

3. The client wakes up at the end of the heartbeat interval plus 1 minute (15 + 1 = 16 minutes total).

Note

The device waits for successive round trips before attempting to adjust the heartbeat interval. A tuning component in the algorithm can change the increments to an amount different than what is specified as the HeartbeatIncrement.

In this example, because the heartbeat was not increased during the last ping, the heartbeat is changed to the minimum heartbeat value (8 minutes).  

4. Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
5. The server response wakes up the client. Because the connection did not time out during the interval, the client determines that the network can support idle connections for at least this length of time.
   If this was a successive round trip, the client determines that it can increase the interval to a longer time for the next request.

You can specify the parameters that the algorithm uses to determine the heartbeat interval. The client uses these to determine how long it will keep a connection open with the server.

The algorithm used to change the heartbeat interval uses the following information:

• There is a minimum and a maximum to the interval. This is established by using the HeartbeatMin and HeartbeatMax parameters in the Sync Configuration Service Provider. The Mobile Operator and the OEM can configure these settings.
• The heartbeat interval should not drop dramatically because there needs to be a balance between battery life and improvements in the always-up-to-date experience. Sacrificing the battery for only minor improvements in the experience is not wise. The maximum allowable change in the interval is controlled by the HeartbeatIncrement parameter in the in the Sync Configuration Service Provider. However, a tuning component in the algorithm can change the increments to an amount different than what is specified as the HeartbeatIncrement.
• The heartbeat is not adjusted when the failure has a known cause, such as a telephone call or other error.

The interval is dropped significantly in case of network error. However, the algorithm restores the optimal interval when good coverage returns.

See the following sections for more information:

• Parameters Used for Dynamically Adjusting the Heartbeat Interval
• Firewalls and Other Components
• Examples of Heartbeat Adjustment
• Error Handling In Direct Push

Parameters Used for Dynamically Adjusting the Heartbeat Interval

These parameters that are used for direct push are configurable on the client. Follow the guidelines in Requirements and Best Practices for Using MSFP to ensure that your device has optimal performance when using direct push.

The following table describes the configuration parameters; these parameters are set using the Settings characteristic in the Sync Configuration Service Provider.

Note

The Sync Configuration Service Provider changes the associated registry values. Or, the OEM can set these settings directly in the registry. For more information, see Requesting the OEM to update the OS.

Parameter	Definition
HeartbeatDefault	The initial number of seconds that the client waits between issuing heartbeat commands. The default value is 480 seconds (8 minutes)
HeartbeatIncrement	The maximum number of seconds by which the time window can change with each dynamic adjustment. The default value is 300 seconds (5 minutes). This value is also the Microsoft recommended value. The result of a small value is that the heartbeat interval will stay close to the server timeout rate when it is unknown. However, the rate will take longer to adjust if coverage is unstable. The result of a large value is that the rate adjusts in fewer steps, but may overshoot the target rate and result in outdated data.
HeartbeatMin	The minimum number of seconds that the client waits between issuing heartbeat commands. Do not change the Microsoft default value of 480 seconds (8 minutes). If the value is too small, the client can ping often which will consume power quickly for very small improvements to the synchronization experience. For more information, see Requirements and Best Practices for Using MSFP.
HeartbeatMax	The maximum number of seconds that a client waits between issuing heartbeat commands. The default value is 1680 seconds (28 minutes). The Microsoft recommended value is 28 minutes. The value should be just below the network timeout. Setting this value too high will result in the user being unsynchronized until the heartbeat dynamically adjusts appropriately.

Two more parameters are used for direct push: ClientAutdSupport and ServerAutdSupport. These read-only parameters indicate the type of communication the client and the server support:

• 1 indicates SMS
• 2 indicates HTTP
• 3 indicates SMS and HTTP

For direct push which uses HTTPS, these parameters both have the value set to 2.

Firewalls and Other Components

Firewalls complicate direct push in that they add additional timeouts during the process. The firewall session interval must be set to allow the heartbeat interval and Enterprise session interval to communicate freely. If the firewall closes the session, then mail would be undeliverable until the client reconnects, and the user could be unsynchronized for long periods of time.

The firewall session timeout should be equal to or greater than the idle timeout on the Operator Network. For information about how to set the firewall, see The Impact of Changing the Direct Push Settings and Requirements and Best Practices for Using MSFP.

Examples of Heartbeat Adjustment

This topic shows examples of how the heartbeat is changed dynamically for various settings.

The following table shows the common settings in all of these examples. These settings should not be changed.

Device	Minimum heartbeat: 8 minutes Maximum heartbeat: 28 minutes
Network appliances between the device and server, such as NATs and firewalls	Idle session timeout: 30 minutes Note   The Idle Session Timeout must be set to 30 minutes on all firewalls and network appliances in the path to facilitate direct push technology.

The overall session duration is the lowest timeout in the network path between the device and the server. As an example, this may be a firewall timeout.

For the Exchange Server, the minimum permissible heartbeat interval is 1 minute, and the maximum is 45 minutes.

Note

The range specified by the device must fall within the range specified by the Exchange server. If the Maximum heartbeat on the device is less than the minimum on the Exchange Server, then direct push will not work.

If these values are not set, the minimum and maximum values previous listed are assumed. Although there is no need to change these values, the Exchange administrator can do so in the registry by using a tool such as regedit.

The resulting heartbeat is reached by being dynamically adjusted across several heartbeats, being tuned to be optimal.

Example	Overall session duration	E-mail traffic interval	Exchange Server Permissible range for heartbeat intervals	Result
1	30 minutes	5 minutes	Min: 1 minute Max: 45 minutes	The heartbeat is not reduced because it is already at the minimum. There are no E-mail delays, and the session never closes.
2	5 minutes	7 minutes	Min: 1 minute Max: 45 minutes	The heartbeat is not reduced because it is already at the minimum. The session is closed every 5 minutes, as shown by the overall session duration. Because this is 3 minutes less that the minimum heartbeat setting, and there is a 1 minute buffer before a network timeout is assumed, there is a potential E-mail delivery delay of 4 minutes. The following shows the worst-case scenario: A E-mail arrives as soon as the network times out (at 5 minutes). The minimum heartbeat is 8 minutes, and there is an additional 1 minute as buffer. The next heartbeat is sent at 9 minutes, which is 4 minutes after the network timeout. The server will respond immediately saying that there is a change
3	15 minutes	20 minutes	Min: 1 minute Max: 45 minutes	The heartbeat is increased to between 15 and 17 minutes. There are no E-mail delays. The session closes at 15 minutes.
4	15 minutes	20 minutes	Min: 15 minute Max: 30 minutes	The heartbeat is increased to between 15 and 17 minutes. There are no E-mail delays. The session closes at 15 minutes.
5	15 minutes	20 minutes	Min: 1 minute Max: 10 minutes	Direct push does not work because the maximum heartbeat on the device is less than the minimum allowable on the server.
6	15 minutes	20 minutes	Min: 20 minute Max: 45 minutes	Direct push does not work because the session duration is less than the minimum allowable on the server.
7	30 minutes	40 minutes	Min: 1 minute Max: 45 minutes	The heartbeat is increased to the maximum of 28 minutes. There are no E-mail delays. The session closes at 30 minutes.
8	30 minutes	120 minutes	Min: 1 minute Max: 45 minutes	The heartbeat is increased to the maximum of 28 minutes. There are no E-mail delays. The session closes at 30 minutes.

Error Handling In Direct Push

Lack of connectivity, such as when a device moves out of range, impacts the direct push process.

Direct push relies on the ActiveSync Engine for most error cases. If there is a network problem and the heartbeat fails, an attempt is made to synchronize the device. One of the following occurs:

• If the synchronization fails, the SyncRetry logic is invoked.
• If the synchronization succeeds, then the direct push begins again by issuing an HTTP request to the Exchange Server.

See Also

Concepts

How the Direct Push Technology Works