What are the basic techniques for sending video over Satcom?

 The radio access network (RAN) and the SwiftBroadband terminal can handle MTU of 1500. However, the MSS (max segment size) of the data portion of the packet should be smaller to accommodate the multiple encapsulation types which happen through the RAN & core network. 1420 bytes MSS should be sufficient to avoid fragmentation.

·        Optimum signal strength from the terminal is critical as most of the loss will happen over the air rather than through the ground segments.

·        Pushing Video through SwiftBroadband requires the RF path to be in excellent shape. It is super critical to have low-loss cable runs and a correctly pointing antenna. The SDU or SBU should be configured to compensate for the correct amount of cable loss. Higher cable loss means higher power consumption, more heat, and increased transmitted power.

·        Most SwiftBroadband terminals offer both Streaming IP and Background IP.

·        Background IP data rates are not guaranteed. Streaming IP offers a guaranteed consistent connection rate.

·        Video over SwiftBroadband works best when bandwidth is constant. Use Streaming IP for video; Background IP is not consistent.

·        SwiftBroadband Streaming Services is symmetrical. If using X-Stream at 512 kbps, the path both up and down is 512 kbps.

·        Some form of data compression must be used. Use your own or contact AirSatOne for solutions.

·        End-to-end quality of service is required, this is particularly important for UDP-based applications over Streaming IP connection using SwiftBroadband.

·        Inmarsat recommends that you implement ‘last mile’ routing to maintain throughput and quality, it is important that QoS is maintained across the terrestrial last mile link as well as the satellite interface.

·        AirSatOne can provide the terrestrial last-mile link, including hybrid satellite/terrestrial networking and IPsec, through our Flightstream SA services.

·        AirSatOne recommends that you disable error correction for UDP applications.

Bit Rates

Audio/Video solutions are designed to use either Constant bit rate or Variable bit rate depending upon the network behavior. SwiftBroadband IP connection is different from ADSL-type IP networks, as the SwiftBroadband network supplies the requested Quality of Service (using Streaming IP) 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 SwiftBroadband may vary depending on whether the solution uses Constant or Variable bit rate.

Constant Bit Rate

Constant bit rate is recommended for use with Streaming applications over the SwiftBroadband Streaming IP service as the output from the codec is sent in a steady stream with a fixed bit rate. Since the SwiftBroadband Streaming IP service is assigned to a specific QoS (32kbps, 64kbps, 128kbps, and X-Stream 512kbps, depending on the terminal), Constant bit rate performs better than Variable bit rate. This is because, on a defined SwiftBroadband 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 asymmetric digital subscriber line (ADSL) or the SwiftBroadband standard IP connection, which adjusts 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.

Protocols

AirSatOne and Inmarsat recommend 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.

TCP and UDP are used for the general transmission of data over IP.

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 SwiftBroadband 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 have 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 the majority of audio-video applications use a combination of TCP and UDP where needed. Typically, call set-up and data flow control are carried out using TCP. The audio and video data are sent using UDP. AirSatOne recommends that you disable error correction for UDP applications.

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. ITU H.232 PDF.

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 signaling, 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 signaling, user location, and registration.

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 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.

Protocol Requirements

Both H.323 and SIP use the same data transport protocols to send and receive data across the SwiftBroadband 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, while 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.

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).

Broadcast Solutions

This section provides guidance on the performance you can expect from your video broadcasting.

application over SwiftBroadband and gives some general recommendations to optimize your application over SwiftBroadband. Refer to the solution sheet for your particular video broadcasting application for a more detailed guide.

Performance over SwiftBroadband

The solutions were all tested to ensure that they work over the SwiftBroadband 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 AirSatOne’s solutions have a built-in SwiftBroadband profile for ease of use.

·        Do not leave the application (or the streaming IP connection) active when not in use. You will be billed for all airtime usage including unintended usage.

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 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.

* 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 signaling 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 types of compression and transport protocols used.

General recommendations

The following recommendations apply to all video broadcasting solutions over SwiftBroadband:

·        Make sure that the antenna has been aligned and calibrated with the aircraft heading and pitch – the terminal must have un- obstructed line of sight and maximum possible signal strength before network registration. Video requires an antenna that is pointing exactly at the satellite at all times during ground and flight operations.

·        Make sure you are using a higher streaming IP class QoS for higher quality video.

·        Use AirSatOne’s Hybrid satellite/terrestrial for 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. AirSatOne recommends UDP.

·        For a UDP-based live broadcast 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. Set network connection to metered.

·        Test your solution before trying it out on the aircraft.

·        Use a correct format camera or FLIR system that is PAL or NTSC

·        Configure your decoder with a static IP address that can be accessed from the SwiftBroadband terminal.

·        AirSatOne recommends that you do not use any VPN connection over the satellite link for live broadcast as it can add extra VPN overheard of between 10-40% based on your VPN application.