Network introduction

Rich Media Applications developed with Streamezzo solution take full advantage of client/server architecture. Based on this architecture, Rich Media Applications can have a very dynamic behavior and can be easily upgraded. However Rich Media Applications that rely too much on network will experience some freezes or some unexpected behaviors if the network throughput is too low or the network latency is too long.

This article focuses on issues or weaknesses related to network in the mobile world (reception quality variations, interruptions...) and provides best practices to neutralize or work around these limitations. It gives an overview on how and when a connection is used within a Rich Media Application (Rich Media content streaming, file download / upload), what are the issues related to the bandwidth and finally how you can, based on those considerations, take care of them within your Rich Media application to offer an optimal user experience.

Network usage

A typical Rich Media Application on mobile device relies on wireless network (WLAN) to retrieve information from Rich Media Server and to stream audio/video content. The Rich Media Server itself relies on network (LAN) to retrieve information from other servers (i.e. backends).

Wireless network variations

Wireless networks are in permanent evolution. If the overall quality and speed of the networks have dramatically increased, the developer should still avoid pitfalls.

Reception quality: The application cannot rely on theoretical bandwidth. The bandwidth is of course lowered by buildings, landscape, perturbation, but mostly because the available data bandwidth is shared between users will affect available bandwidth. The most users are connected on a base station (network antenna) the less bandwidth the Rich Media Application would get.

Loss of coverage: The application must take care of the loss of coverage. When the coverage is lost, the application will detect this loss after a specific period called a time-out. The time-out is usually about 10 or 30 seconds, which can be very long from an end-user’s experience point of view. Streamezzo solution provides features dedicated to network measurement: the application will trap the coverage loss and inform the end-user when such events occur.

Server proximity: Minimizing the server page generation time will reduce the time a client-server connection is open, and so will decrease the application latency and reduce the probability of connection failures (which is much higher than on the broadband Internet). First the developer shall try to reduce the requests to other servers when retrieving fresh data for the application. Second he shall keep in mind that the closer the servers are to the Rich Media Server (or the fastest the link between is) the fastest the request will be treated.

Typical network request in Streamezzo solution

The Rich Media Client dialogs with the Rich Media Server through HTTP. This protocol is a request/response protocol. The Client sends a request to the Server. The Server responds with content data. We will now see how the network impacts this dialog.

A request time over the network can be split in several phases:

• Connection establishment: the mobile device builds a data connection to the base station, this happens only for the first connection in an application lifetime.
• Request: the Rich Media Client sends the request to the Rich Media Server.
• Scene processing: the Rich Media Server processes the requested scene and populates the Rich Media Application with new and fresh data. To do so it can retrieve up-to-date information from the backend(s).
• Response: the Rich Media Server sends back the generated scene data to the Rich Media Client using a progressive download protocol.
• Rich Media Client decodes the scene data while it receives the response. The important notion of scene progressive download and access unit will be exposed below, it allow optimizing display of scenes while loading.

Features using network

Some functionality is available in the Streamezzo solution to control and use the network. This section will expose them.

The first family of features gives control of the network connection

• Network strength listening: an animated content can be enslaved to the network reception level, and application scenario (available features…) can be adapted to the current network level. The end-user could also be informed that the reception level is good enough and that some latency is expected.
• Network error catching: HTTP connection failures can be caught by the Rich Media Client and handled by the application to provide a meaningful information to the user.

The second family of features makes an intensive usage of the network

• Audio/Video Streaming: The Rich Media Client directly receives the streamed media from the streaming server. The bit rate of the media should be carefully chosen to match the network capacity. If the emitting bit rate from the streaming server is higher than the network capacity then the video playback will be jerky with some rendering freezes. To have a fluid video playback on 3G networks the encoding rate of the total clip shall be around 200Kbit/s and not higher than 250Kbit/s. A usual encoding configuration is as follows: around 150Kbit/s for the video encoding rate in H264 format and 50Kbit/s for the audio encoding rate in AAC format.
• Content Download: The Streamezzo Download Engine is used to download files from a HTTP server. The HTTP server could also be located in the Rich Media Server. The download session can be stopped and resumed; the Download Engine can handle errors or acknowledge a download success or failure.
  • On EDGE network, the maximum data rate is 400 Kb/s, and the typical rate is around 210 Kbit/s.
  • On 3G network the typical bandwidth goes from 128 Kbit/s in a car to and 2 Mbit/s in fixed applications.
  • On 3G+ it goes from 1,8 Mbit/s to 14,4 Mbit/s.
  As an example, a 1MB video requires from 1s to be downloaded on 3G+ to 40s on EDGE. To upload this same video using the Upload Engine (see next bullet) on a 3G network, an upload time of 100 s shall be expected.
• Content Upload: The Upload Engine is used to send files to a specific server. The upload can also be stopped and resumed. The file is split into several chunks to successfully go through network. This is mostly done to solve issues faced when attempting to send large files. The Server shall be able to concatenate the different chunks into a valid content; to do so Streamezzo has developed an Upload Servlet that receives the chunks and reassembles them into a complete content. The Upload Servlet can run on any J2EE Server. The uplink throughput depends on the mobile network type, the following range shall be considered when using the Upload Engine:
  • On EDGE network, the typical uplink throughput is about 40 Kbit/s.
  • On 3G network, the typical uplink throughput is about 80 Kbit/s.
  • On 3G+ network (using HSDPA or HSUPA), the typical uplink throughput is between 128 Kbit/s and 384Kbit/s.

The download bandwidth is directly linked to networks one, the following range shall be considered when using the Download Engine.

Rich Media Progressive Download

To allow early decoding and scene construction while loading, Streamezzo Solution offers Rich Media progressive download. A Rich Media Scene is composed of a serie of Access Units (consistent data packets). Each Access Unit can transport instructions enabling to add, replace, and delete content from the currently rendered scene. Thus the developer is able to send first the structure of the scene and then add content to it, for example send a table border and then progressively add the images into the table.

Thanks to this solution the end-user gets an early visual rendering without having to wait for the complete scene to download. As Access Units can be time stamped, advanced scene construction or even animation can be achieved.