Algorithm Description

The aim of the proposed mechanism in this section is to apply the concept of adaptive rate speech coding for VoIP for collective DVB-S2/RCS networks using transcoders. The concept of cross­

layer design is used for the control of the speech coding rate at a transcoder. This is achieved by transferring traffic congestion information from the MAC to the Application layer.

A transcoder is a device converting a voice signal between two different codecs. The need for transcoders in today’s networks has been raised by the existence of end-devices using different codec technologies as well as the difference in available capacity for speech across a complete network path, often crossing different networks. These differences can necessitate the further compression of voice signals when entering a new network domain. Examples of commercial uses of transcoders can be found at the edges of wireless networks usually converting signals fi-om the PSTN. In terms of commercial products, transcoders can be found in the market in both hardware and software ([62],[63]). A transcoder normally converts VoIP flows of a high speech coding rate (usually the G.711 standard codec used in the PSTN and working at 64kbps) to a codec employing a lower rate. This is normally done by reducing the number of bits per data sample, taken when converting analogue voice to a digital signal.

Data compression combined with QoS features for voice is also common practice at the interface between satellite and GSM (Global System for Mobile communications) networks. It is usually applied for backhauling GSM base stations over VS AT or DVB-RCS and it is supported by a variety of commercial products known as “abis optimisers” ([64]-[66]).

The performance objectives o f the mechanism are:

• To improve the QoS in terms of delay and PLR for concurrent VoIP sessions. This is achieved by continuously measuring the available goodput at MAC layer and setting accordingly the speech coding rate;

• To support a higher number of VoIP sessions within the same amount of capacity. This is done by reducing the speech coding rate for each or a proportion of them. In this way apart from improving bandwidth use the call blocking rate is reduced.

The novelty of the proposed mechanism with respect to existing transcoding or traffic optimiser solutions lies in the application of cross-layer design for the implementation of the rate control algorithm in the transcoder.

In the end-to-end path of a VoIP flow between a satellite and a terrestrial network user, it is expected that congestion will occur at the edges of the satellite network. It is for this reason that the transcoder is placed before the RCST or the GW. Therefore the cross-layer process takes place between the MAC layer of the RCST or GW and the transcoder (Application layer). An advantage of this network configuration is that the rate control process is kept transparent to end users and does not require any extra equipment on their side. The network architecture as well as the principle of cross-layer exchange is illustrated in Figure 4-6 for the return link. It is assumed that the network behind the RCST is a wireless LAN using WiFi (IEEE 802.11) or WiMAX (IEEE 802.16) with several users behind it. It should also be noted that several network devices are omitted from the graph for simplicity, such as the wireless base station or terrestrial routers.

VoIP '

Figure 4-6: Network architecture for the cross-layer transcoding algorithm

In terms of the MAC layer policy applied by the network, it can be safely assumed that collective or corporate types of terminals have an SLA including a guaranteed rate for priority applications

(CRA or SR). Alternatively or in addition, it can be assumed that RBDC is not overbooked and every terminal possesses a certain amount of Booked Rate.

The mechanism is described in steps below:

Step 1: Detect data flow via the transcoder

For a new VoIP flow detected, enquire the MAC layer of the RCST on the availability of resources.

Step 2a: For a new flow calculate initial rate and available capacity

In order to determine whether a new VoIP flow needs to be transcoded or not, a comparison is performed between the RCST guaranteed rate ( GR ) (in this architecture a combination of SR and BR) and the currently observed mean input data rate for the RCST EF queue

fpp is calculated using a sliding window algorithm according to which a certain time window w (the sliding window) is divided into / time slots of duration 6";. For most of the simulations presented in this section / is set to 20 and Sj to 10ms.

If r. is the calculated instantaneous input rate in slot i,i = 1,2,...,/ then the mean input rate over a window of the EF queue is:

/

^EF — (Eq. 4-4)

/ = i

Although the primary type of traffic passing via the EF queue is VoIP, signalling as well as videoconferencing may also run at the same time as a VoIP session, therefore also consuming part of the guaranteed rate. For this reason, is calculated in order to take into account this rate.

The available throughput for VoIP is:

^ fpp (Eq. 4-5)

Based on this calculation the coding mode of the transcoded signal is set as follows, where k = represents the set of m coding modes of the transcoder.

^ (Eq.4-6)

Co for < 0

where is the data rate of the VoIP flow before transcoding. Therefore, if there is available capacity to satisfy r^^.^, the flow is not further compressed; if there is not enough capacity it is compressed using a lower rate codec to the level of the available throughput; and if there is no available capacity the lowest available coding mode is used.

Step 2b: Every x superframes monitor the queue for congestion

As the rate of concurrent applications can change in the duration of a call and new VoIP calls may also arrive, there is a need for continuing to monitor the queue input rate . This is done every X superframes for updating the available capacity. As in step 2a, in the case of congestion the coding rate of the VoIP sessions is compressed by an equivalent amount to the congestion (Eq. 4- 6). Fairness between the sessions is achieved by compressing always the higher rate ones. This also ensures that all flows tend towards and equilibrium.

As a first step the n concurrent VoIP flows with respective data rates rT are sorted so that rCp > r^^}. In case of congestion the coding mode of the highest rate VoIP session is reduced and flows are again sorted continuously in a loop so that;

(Eq.4-7) Step 3: Terminate the cross-layer exchange process

The cross-layer data exchange is stopped when all VoIP flows have terminated.