BGAN Live Video Broadcasting

The BGAN service enables remote offices or users to establish audio/video communications with company headquarters or business partners anywhere in the world.

Audio/Video solutions are divided into 3 main categories. This guide covers Live audio/video broadcasting only. Contact us for the other categories:

• Broadcasting solutions (Encoder & Decoder based)

• Typically one-way broadcast of live audio/video from the field.

• Includes a high quality Store-and-Forward option for near real-time breaking news coverage.

• Video conferencing solutions (Hardware or Software based)  typically, two-way video conferencing between remote and fixed office.

• Remote surveillance solutions (Remote IP camera)  typically, a one-way JPEG or motion video clip from field to fixed office when motion is detected; alternatively, the fixed office can access a live video stream remotely.

IMPORTANT: It is important that you select the correct BGAN terminal and streaming IP quality of service for the solution you want to use. Refer to the appropriate Solutions Guide for details.

Symmetrical QoS over BGAN

It is important to note that BGAN streaming IP offers symmetrical QoS. For instance 256kbps streaming IP offers 256kbps in the up direction, and 256kbps in the down direction. Normally, broadcast solutions only use the uplink (return channel) for live broadcast and the downlink (forward channel) for audio feed from news room studio. You can also use BGAN 4K voice channel simultaneously, but it is more efficient and cost effective to use BGAN streaming IP channel for both audio and video transmission.

The arrival of BGAN, which utilises Internet Protocol (IP) and has a bandwidth capacity of up to seven times that of the Inmarsat GAN service, has started a revolution in television coverage of breaking news. BGAN certainly presents a compelling proposition to the professional broadcaster, because the terminals are small and as easily portable as a laptop computer, while the BGAN streaming IP service delivers high quality live video back to studio room from anywhere within the satellite foot print.

Typically BGAN service offers two core options for broadcasters:

• Live video, which is typically transmitted one-way from the field, using Streaming IP data rates of up to 256Kbit or 64K ISDN

• Store-and-forward video, using Streaming IP, ISDN or Standard IP.

The BGAN IP service allows you to use some of the latest broadcasting compression protocols, such as H.264, MPEG 4 and Windows Media 9, for live broadcasting over BGAN.

The BGAN IP service also plays a bigger role in broadcasting store-and-forward video, giving you the ability to transmit high quality video at a variety of connection rates, including standard IP.

The flexibility of the BGAN service when compared to GAN is another highly attractive feature for video broadcasting. On Class 1 terminals, such as the HNS 9201, multi-user functions allow users to perform more than one task simultaneously. For instance, it is possible to send store-and-forward video via Standard IP, while simultaneously using Streaming IP for a live broadcast. In this way, important footage can be received by the studio and edited ready for broadcast at the earliest opportunity. The level of compression determines the quality of picture received at the other end and the time taken to transmit.

Typical setup requires a laptop-based encoder with firewire camera connected to a BGAN terminal over the Ethernet interface.

Audio/Video broadcasting solutions introduce additional requirements over the ordinary transfer of data. For example, latency must be guaranteed to ensure that frames are transmitted in the form of a moving image, and sound must be synchronized with image. Audio/video solutions require the following:

• A large amount of information to be sent simultaneously, requiring a consistent bandwidth with guaranteed end-to-end QoS. Typically, a BGAN streaming IP connection is required (refer to Selecting the right terminal and Quality of Service).

• Some form of data compression (refer to Understanding codecs).

• The selection of a bit rate type (refer to Understanding bit rates ).

• A number of protocols to be used alongside the streaming IP connection to control data flow and provide additional conferencing capabilities (refer to section Introducing protocols and Protocol requirements).

• End-to-end QoS for the required data rate. This is particularly important for UDP-basedapplications running over Streaming IP connections. To maintain throughput and quality it is important that QoS is maintained across the terrestrial last mile link as well as the satellite interface. EX4U Telecom can provide details of available interconnect last mile options.

When these requirements are met, you can further optimize your applications based on Inmarsats recommended settings. Refer to Introducing broadcast solutions, EX4U Telecom supports you on the specific solutions for your preferred video broadcasting application.

In addition, you can set up a streaming IP connection in BGAN LaunchPad, dedicated to your video conferencing application. Refer to Setting up a video broadcast connection in LaunchPad.

This section explains IP data connections over BGAN, data compression algorithms, and the data transfer protocols and audio/video protocols used to ensure effective audio/video solution over BGAN.

The BGAN terminal provides two classes of connection: standard IP and streaming IP.

On a standard IP connection, traffic throughput varies depending on terminal and network usage. Streaming IP differs from standard IP in that it offers a guaranteed, consistent connection rate, provided network resources are available end to end.

Tip:

• Inmarsat strongly recommends that you use a streaming IP connection for live audio/video applications.

The streaming rates provided by the BGAN terminals differ, as shown in the following table:

Terminal Standard IP (up to) Streaming IP

HNS 9201 492kbps send / receive 32kbps, 64kbps, 128kbps, 256kbps

EXPLORER 700 492kbps send / receive 32kbps, 64kbps, 128kbps

EXPLORER 500 464 kbps send / 448 kbps receive 32kbps, 64kbps, 128kbps

EXPLORER 300 384kbps send / 240kbps receive  32kbps, 64kbps

Explorer 100 / 110  384kbps send / 240kbps receive 32kbps, 64kbps

Wideye SABRE I  384kbps send / 240kbps receive 32kbps, 64kbps

You can also link your audio/video application to a particular streaming class connection. To do this, you must configure a dedicated streaming IP connection, and use a traffic flow template to ensure that only the AV traffic is transmitted over that particular connection. All other traffic uses the standard IP connection.

To set up this connection, refer to "Setting up a video broadcast connection AV connection".

If you want to use BGAN for live video and audio streaming traffic using UDP-based applications,

Inmarsat recommends that you investigate and implement last mile' routing arrangements which guarantee end-to-end QoS. This is particularly important for UDP-based applications running over a Streaming IP connection on BGAN. To maintain throughput and quality it is important that QoS is maintained across the terrestrial last mile' link as well as the satellite interface.

A codec is the name given to the encoding/decoding algorithm that compresses and decompresses audio video data. The effectiveness of a streaming IP connection is determined partly by the codec.

A high compression codec will provide the data stream quickly, but at low quality. In general, compression schemes can be classified as "lossy" and "lossless."

• Lossy compression schemes reduce the size of the data stream by discarding some data during the encoding process before it is sent over the BGAN network. Once received on the client side, the codec attempts to reconstruct the information that was lost or discarded. Lossy compression offers data savings of around 10:1. If a voice file was compressed using lossy compression, silence would be removed, and both high and low frequency data may be lost from the data stream. The resultant file could sound different to the original (depending on how aggressive the codec was).

• Lossless compression simply squeezes data into smaller packets of information without permanently discarding any of the data. Lossless compression algorithms usually require more computing power to compress and decompress the data stream, and do not give the same data savings as lossy compression. If a voice file was compressed using lossless compression, it could still be encoded, in order to reduce the size, but no data would be lost. The resultant file would sound exactly the same as the original.

Codecs typically used combine elements of both compression schemes; in this way, for example, silence can be discarded from a voice file, but all non-silent parts retained and compressed. Streaming IP applications over BGAN must therefore choose a codec that will provide the necessary quality of stream, whilst reducing the data rate as much as is possible.

The tested applications described in this document all come with their own coding schemes. Some allow you to change various settings which can make a difference in the way the application works over BGAN.

Audio/Video solutions are designed to use either Constant bit rate or Variable bit rate depending upon the network behaviour. BGANs streaming IP connection is different to ADSL-type IP networks, as the BGAN network supplies the requested Quality of Service (QoS) from the time you request the connection until you disconnect

It is important to understand the difference between Constant bit rate and Variable bit rate, as the quality of the audio/video solution over BGAN may vary depending upon whether the solution uses Constant or Variable bit rate.

Constant Bit Rate

Constant bit rate is recommended for use with streaming applications over the BGAN streaming IP service as the output from the codec is sent in a steady stream with a fixed bit rate. Since the BGAN streaming IP service is assigned to a specific QoS (32kbps, 64kbps, 128kbps and 256kbps, depending on the terminal), Contact bit rate performs better than Variable bit rate. This is because on a defined BGAN channel, a Constant bit rate takes advantage of all the capacity of the streaming IP connection.

Variable Bit Rate

Variable bit rate is designed to cope with variable network bandwidth, such as that provided by ADSL or the BGAN standard IP connection, which adjust audio/video quality according to the available bandwidth. A Variable bit rate solution has the capability to throttle back when it detects any packet drop or loss, which typically occurs when IP traffic travels through a series of Internet routers. This throttling back reduces the speed of data transmission and results in loss of video quality. Variable bit rate solutions are therefore more suitable for a standard IP connection than a streaming IP connection.

Inmarsat recommends that you use a streaming IP connection to send and receive video data. A number of protocols can be used alongside the streaming connection to control the data flow and provide additional video broadcasting capabilities.

The following two transport protocols are for the general transmission of data over IP:

• TCP
• UDP

Protocols that are specific to video solutions over IP are relatively new, and still evolving. The following two main sets of call control protocol are in use by the Internet at the time of publication:

• H.323
• SIP

All these protocols are described below.

TCP and UDP

TCP and UDP are transport protocols that are used to transmit data over IP connections. The TCP protocol is configured to deliver data from end to end in a reliable manner. It is connection- oriented, and provides flow control and retransmission of lost packets. The UDP protocol is connectionless and designed for speedy delivery, but does not guarantee reliability, flow control or detection of lost packets.

TCP/IP application will be more effective over Standard IP due to the nature of BGAN Standard IP service. Typical corporate application i.e. Email, Web browsing, FTP etc uses TCP.

UDP is more suited to Streaming IP because if packets are lost, they are ignored and packet transmission continues. This may cause a slight loss of quality in the transmission, but the transmission is not interrupted. If the same packets were lost over a TCP connection, TCP would stop delivery of further packets until the lost packets are successfully been retransmitted. This would cause an unacceptable break in the flow of the application.

Therefore, UDP thus gives streaming applications greater control over the data flow than TCP.

These characteristics mean that majority of the audio video applications use a combination of TCP and UDP where needed. Typically, call set-up and data flow control is carried out using TCP. The audio and video data is sent using UDP.

Tip

• BGAN LaunchPad allows the configuration of error correction. Inmarsat recommends that you disable error correction for UDP applications. Refer to BGAN LaunchPad Help for details.

H.323

The H.323 protocol is defined by the ITU-T (International Telecommunications Union). It describes how real-time multimedia communications can be exchanged on packet-based networks. The standard was drawn up following collaboration between traditional telephony experts and those from the computer communications arena. In addition to fully-interactive media communications such as video conferencing, H.323 also has provisions for other forms of communication, such as multi-media streaming.

During a point to point H.323 call, an initial TCP connection is made (using default port 1720). Data is exchanged over this connection (using Q.931 packets) to determine which port will be used for the actual multi-media connection. Once this port has been decided, an H.245 connection is made, to the new port.

The H.245 protocol handles all of the call parameter negotiations, such as which codecs to use. H.245 also has commands that make UDP connections. Once the audio and video codecs and parameters have been negotiated, the H.245 session starts the underlying data stream.

The data stream consists of an RTCP (Real-Time Transport Connection Protocol) connection (UDP), and the actual data stream which uses the RTP (Real Time Protocol).

The H.323 protocol covers all aspects of telephony and conferencing, including capability exchange, conference control, basic signalling, Quos, registration, service discovery, gateways etc..

SIP

SIP (Session Initiation Protocol) is defined by the IETF (Internet Engineering Task Force) and is a relatively simple protocol when compared to H.323. It is designed to be modular, allowing the protocol to be extended to cover specific applications.

SIP is defined as being responsible for basic call signalling, user location, and registration.

Whereas H.323 can operate in a peer to peer mode, two SIP users require a SIP server in order for them to communicate. SIP clients send a series of messages (defined in the Session Description Protocol) to the server in order to set-up a call with another user. The client must first register with the server, then invite the other user to join a call. The SDP message will detail what is to be included in the call; audio, video, Codecs etc.

Once the call recipient has accepted the call by responding to messages from the SIP server, the actual data connection is set-up directly between the two SIP users. The data connection uses the RTCP and RTP protocols, as for H.323.

Both H.323 and SIP use the same data transport protocols to send and receive data across the BGAN network.

The applications that use these protocols use different encoding techniques however. In addition, the applications normally impose a higher level protocol to control the user session. For instance, whilst Yahoo Messenger and iChat may both use the SIP protocol for audio and video, the applications must first initiate a session using their respective Instant Messaging (IM) protocols with the IM servers.

In order to use either the H.323 or SIP protocols through a firewall, based on your computer or corporate servers, the following ports must be open. Due to the dynamic nature of the lower protocols, it may be necessary to allow the whole application access through the firewall, rather than rely on specific port entries.

Protocol Ports

• UDP ports 1718 and 1719 (discovery and registration of gatekeepers)
• TCP/UDP 1720 (call signalling)
• TCP 1300 (secure call signalling)
• H.323
• TCP dynamic port 1024-65535 (H.245)
• UDP dynamic port 1024-65535 (RTCP)
• UDP dynamic port 1024-65535 (RTP)
• TCP port 5060 (SIP)
• SIP UDP dynamic port 1024-65535 (RTCP)
• UDP dynamic port 1024-65535 (RTP)

Note: When using a streaming IP connection from a mobile client to a fixed server, the above ports refer to the firewall protecting the fixed server (any firewall on the client must be correctly configured for outbound traffic).

The solutions were all tested to ensure that they work over the BGAN network. Then a typical configuration was set up, and the application data stream examined to see how much bandwidth is required to run the application.

Tip

• All these applications operate more effectively over a streaming IP connection than a standard IP connection. Note the following:

• Ensure that you choose a streaming IP connection that matches the data requirements or settings of your application. Leave some capacity for IP overheads when selecting the bandwidth. Some of these solutions now have a built-in BGAN profile for ease of use.
• Do not leave the application (or the streaming IP connection) active when not in use.

In addition to Live broadcast, some of these solutions also offer Store and Forward capability for sending high quality video in highly compressed format without compromising on picture quality.

File sizes and transmission times

The following table shows the typical file sizes and approximate transmission times of a 250MB, 1 minute DV file, using different encoding rates.

Encoding rate used to compress file   Approx. compressed file size *   Approx. transmission time over BGAN 256kbps connection 
750kbps                                                  6MB                                                4-5 minutes 
1Mbps                                                     8MB                                                5-6 minutes
1.5Mbps                                                  12MB                                              7-8 minutes  
2Mbps                                                     16MB                                              9-10 minutes 

*May vary from solution to solution.

Note that the actual transmission time is fundamentally determined by a number of factors including data channel rate, video sequence length, physical signalling overhead, Layer 4 transport and transmission protocol overhead (i.e. TCP overhead), error checking, protocol headers and handshaking negotiation procedures like "TCP slow start". Also, the transmission speed varies between solution to solution due to the different type of compression and transport protocols used.

• Make sure that you have pointed the terminal correctly the terminal must have un- obstructed line of sight and maximum possible signal strength before network registration
• Make sure you are using a higher streaming IP class QoS for higher quality video.
• Make sure you have a dedicated last mile connection to ensure end-to-end QoS.
• Use the Ethernet Interface to achieve high transmission speed.
• Make sure that you have chosen the correct protocol. Inmarsat recommends UDP.
• Make sure that for a UDP-based live broadcast, you use BGAN LaunchPad to switch off packet retransmission for your streaming IP connection before you open the streaming IP connection.
• Make sure you switch off any windows or MAC auto download while doing live broadcast
• Test your solution before take it out in the field.
• Use a correct format camera, that is PAL or NTSC
• Configure your decoder with a static IP address that can be accessed from the BGAN terminal.
• It is recommended that you do not use any VPN connection for live broadcast as it can add extra VPN overheard of between 10-40% based on your VPN application.

It is recommended that you configure a data connection in BGAN LaunchPad that is dedicated to your video broadcasting application. You can then open a video broadcasting connection when required by clicking on an icon in BGAN LaunchPad.
To do this:

a. In BGAN LaunchPad, click on BGAN services > LaunchPad Data Tab Options (or click on Advanced in the Connection control window). The following screen displays; Open BGAN LaunchPad, and click on the Data icon:

b. Click on Add new connection. The Connection Configuration screen is displayed:

c. Select Create new Dedicated Streaming IP Data connection, and click on OK. The Dedicated Connection Tab screen is displayed, as shown below:

d. From the Icon menu, select an icon to associate with your video broadcasting application.

e. In the Icon label text box, enter a name for this connection, e.g. Quicklink, Streambox and so on.

f. Select the video broadcasting application you want to associate with this icon and icon label from the Application Traffic Flow Template check box. The traffic flow template ensures that only traffic associated with the application can use this dedicated connection.

Note: TFTs for Streambox and QuickLink are supplied with BGAN LaunchPad. Contact your Service Provider if you require a TFT for any other video broadcasting application.

g. Select the Desired Rate from the drop-down list. This is the QoS that you want to use for this connection.

h. Select the Minimum Rate from the drop-down list. This is the minimum QoS that you will accept for this connection. Inmarsat recommends that you set the Minimum Rate to the same as the Desired Rate, to ensure that you are allocated the data rate that you require.

i. If required, change the error correction setting. By default, error correction is switched off because UDP applications do not require re-transmission.

j. Click on OK to save these settings.

The new icon is displayed in the Data connections screen in BGAN LaunchPad. This connection is associated exclusively with your video broadcasting application. Your video broadcasting application does not share the connection with any other traffic.

To open the video broadcasting connection from BGAN LaunchPad, click on the icon that you created.

To close the data connection and the video broadcasting application (and therefore your broadcasting call), click on the video conferencing icon again. Note If you close your video broadcasting application only, the BGAN data connection remains open.

Note You can also start a video broadcast call by connecting to the BGAN network using one of the pre-configured data connections, and then opening the video broadcasting application in the normal way. However, the video broadcasting application has to share this connection with other terminal traffic.

Support and feedback
For help with the BGAN service, contact us here

top

back