Implementing VoIP support in a VSAT network based on SoftSwitch integration

Implementing VoIP support in a VSAT network based on SoftSwitch integration Abstract Satellite communications based on geo-synchronous satellites are characterized by a large delay, and high cost of resources. VoIP applications over satellite networks must thus be handled very carefully so as to provide quality of service, as expected from voice calls, namely: secure resources for a call throughout its duration, regardless of other calls and other data traffic being present in the system. Furthermore, jitter and delay must be kept to a minimum while maintaining as high satellite resource exploitation efficient. These subjects are well treated in the previous generation of satellite telephony products (Also referred to as "Native telephony"). Basically, the circuit switching approach dominated these solutions, with specific solutions applied to both the access level and the application level. The media itself, derived from the requirement of bandwidth efficiency, used the very same CODECs used for VoIP such as G.723 and G.729. The native telephony solution is jitter free, minimal delay, total QoS (regardless of other calls or data) and extremely efficient. The purpose of the current work was to capitalize on the existing infrastructure and its benefits and to port them to the VoIP environment. The approach described herein was implemented in Gilat's SkyEdge product and is operational for about 2 years. Introduction Satellite communications based on Geosynchronous satellites are characterized by the following: High delay caused by the propagation path of the information from earth to the satellite and back (about 250[ms] and 500[ms] round trip). High cost of BW. Often, the inbound path is a FTDMA channel with bursts. As a result, transporting VoIP over a satellite medium is a demanding and challenging task: QoS must be carefully supplied so as to support the requirements of minimal delay and jitter while consuming minimal bandwidth. This task may be divided according to the following: Identify a call. This task must be achieved relatively fast so as to provide resources for the call before the actual flow of media commences. Identify the type of the call: Be it star, mesh or local. Each such type requires a different allocation pattern: A star call requires timeslot allocation and some resources at the hub to deal with the media, a mesh call would need special dedicated mesh resources on both participating VSATs, a double-hop mesh call would require timeslots to both participating VSATs, a local call requires no resources and the media must not travel over the satellite medium. Identify the resources required for the call (e.g. codec BW). Reject a call for which there are insufficient resources. Identify the media flow itself, once it commences. Compress the media and send it over the proper satellite resource. SkyEdge SkyEdge is Gilat's leading product, a "one platform does it all" satellite access solution. It provides support for both Internet access as well as other IP applications and legacy protocols. The SkyEdge VSAT includes expansion slots where telephony boards and mesh receivers may be installed. The inbound is built on a multi-slot TDM approach on which several access methods may be implemented- RA (Random Access), GA (reservation), DA (Dynamic access) and a special implementation of DA for voice called VDA. The VDA access scheme is unique in that it is dedicated to native telephony and hence requires no flow control reliability or fragmentation facilities enabling use of a very small header structure. A controller (DCAS) receives call requests from either VSATs or hub, based on native telephony protocols, analyzes the requests and allocates the resources needed for the calls. The telephony task on the VSATs and hub components are responsible for signaling termination and voice treatment including sampling and coding in one of the popular vocoders such as G729 or G723. The multislot structure is designed to fit one of these 1

vocoders, and a compromise is made on minimizing delay and maximizing efficiency such that voice is collected typically in 120[ms] intervals, thereby adding 120[ms] delay, but sharing the same headers with either 12 G729 or 4 G723 frames. The good synchronization between the CODEC requirements and the access setup yields a jitter-less transmission path. Calls for which there are no resources are being rejected. Implementing VoIP over SkyEdge Earlier products as well as the skyedge provided a VoIP solution based on the data and internet features support infrastructure. However, this approach was limited in efficiency due to the fact that it was associated with the DA access mode, it provided no guarantee of reducing the jitter when many calls were present at the same VSAT and more. A new approach was sought, such that the existing native telephony infrastructure with all of its inherent benefits may be leveraged on to gain the same benefits for the VoIP solution. The requirements were: Provide "end-to-end" VoIP solution: At each end of the system (Either VSAT or Hub), the system provides a LAN connector. Not an FXS or E1. Support H.323 protocol and SIP at the same time. Do not limit the solution to specific endpoints whichever endpoints that complies with the underlying standards must be supported by the system. Provide "total" QoS zero jitter, be completely independent of other data types on the same VSAT. Guarantee the required resources throughout the duration of the call. Reject the call if there are no resources to satisfy the QoS requirements. Use the same vocoders supported by the telephony application, use the same system elements. Provide the same BW efficiency as with the telephony application. Enable the VoIP and the Native telephony application to coexist within the same network, the same VSAT. Solution The main technical decision taken was to rely on the VoIP protocol signalling to achieve the tasks of identifying the call itself, its' type, the participating endpoints and required resources. This would be VoIP softswitch achieved through either a statefull inspection of the signalling packets in the application layer, and then reporting to the DCAS the relevant information consequently receiving the resource allocation, or through terminating the call and creating a new call leg. It seemed like a major undertaking to implement both SIP and H.323 stacks at each VSAT, and it seemed reasonable that the hub may be assumed to be the place where all signalling will pass through. At the hub, there were 2 possible solutions: A passive application that would analyze the signalling and communicate the data to the DCAS. A Gatekeeper and a Proxy server jointly referred to as softswitch. Due to the requirement that it will be possible to reject the calls in case of resource deficiency, the second option was chosen. The main reason for this selection was that in order to actively reject a call, the rejecting party must be a part of the VoIP network. A semi-passive element that would generate a reject message may lead to unforeseen results and a ping-pong of messages and acknowledgements. DCAS NMS Router VSAT Figure1: Solution topology Topology The topology is described in figure 1. A softswitch is placed at the hub having an interface to the IP world, where the following entities may exist: Internet network access to remote CPEs, Gateways, other softswitches, CPEs, and access to the CPEs behind the VSATs. The softwitch has another interface to the DCAS. The CPEs behind the VSATs connect to the VSAT over the VSAT's LAN port. There is a dedicated voice packet processor at the hub to handle VoIP media, and a different processor to handle data (and perform TCP spoofing etc). Signalling All endpoints must be registered with the softswitch, and the call models must be of 2

H.323 routed mode and SIP using SIP proxy. When a CPE behind a VSAT initiates a call, it sends the call setup message (SIP INVITE, H.323 ARQ, setup) over the "regular" data path of the VSAT, as any other IP application, subject to data QoS settings. When the softswitch receives the setup request, it resolves the source and destination IP addresses of the 2 parties involved in the call, and sends a call request message to the DCAS containing the information. The DCAS looks its tables and classifies the call as either star, mesh, local or hub call, and checks for the availability of resources. If no resources are available, the DCAS rejects the call to the softswitch and the softswitch, being a part of the VoIP topology, issues a call clearing command with the proper cause to the CPE that initiated the call. If the required resources are available, the DCAS allocates the resources and sends assign messages to the voice packet processor at the hub, to the VSATs and to the softswitch which continues the call setup process. Media path Once the assign message arrives at the VSAT, it intercepts all RTP packets having the destination IP address and UDP port which it received in the assign message from the DCAS. The VSAT then performs the following: (1) It removes IP, UDP and RTP headers. (2) It collects frames of payload until the transmit timeslot arrives. (3) It adds a 6 Byte header with some RTP fields included that is shared with the VoIP application layer and the satellite access layer. The VSAT then sends the new packet to the hub, where it is processed by the voice packet processor which reconstructs the original RTP packet structure, with some modifications e.g. the SSRC is not reconstructed, it is rather created a new for the duration of the session. The voice packet processor then forwards the RTP packet over the Ethernet port to its destination. On the reversed direction (Outbound), the packets arrive at the voice packet processor which strips them of their IP, UDP and RTP headers, constructs a new packet, and sends it to the IP encapsulator, and to the VSAT. At the VSAT the packets are reconstructed to have IP UDP and RTP headers, and the packets are sent to the CPE. Solution Pros Enables total QoS. The voice and data paths are completely separated from each other and there can be no interference caused by data traffic such as FTP upload and the voice traffic. There is no interference between different voice calls, each call has its satellite resources reserved for the entire duration of the session. The access provides a jitter-less medium for the voice data, which results in a superior voice quality. It is possible to reject a call if there are no resources available, and provide a proper cause. The bandwidth requirement is known from the signalling session, there is no need to assume bandwidth requirement a- priori, or to spend time in estimating the actual bandwidth. Decisions regarding satellite resources are taken where the VoIP decisions are taken: At the softswitch. No need to implement complex logics at the VSAT. The VSAT implementation is protocol agnostic it is only aware of RTP. The DCAS is protocol agnostic, and only aware of the protocol between itself and the softswitch. Using a softswitch from an external vendor brings the benefits of exploiting the know how of expert the softswitch vendor, and concentrate on the satellite-unique issues. It also enables the system to benefit from the VoIP market trends and developments; (to expand in the directions the market is growing in terms of new protocols, new protocol version, redundancy, cost reduction etc). Enables potential support for lawful interception, also in mesh modes. May enable support for encrypted signalling (because the encrypted tunnel must be between the CPE and the softswitch) - something that "Transparent" systems can't achieve. 3

Solution cons Not "transparent". If a carrier wants to use its existing softswitch, it can't do so. Although softswitch to softswitch communications enables such a topology, usually the carrier will not want some of the subscribers to be managed in one softswitch and others on another. It forces the service provider to be a telephony service provider, even if it is not its intention the service provider must manage the subscribers, provide class 5 services and comply with regulations that otherwise it was exempt of such as lawful interception, emergency calls. Does not provide support for protocols such as Skype that are either proprietary and wouldn't be recognized by the softswitch, or their topology is not centric, or do not use RTP. In case of a VSAT where there are many calls, it cannot benefit from statistical multiplexing based on silence suppression. Has problems with VLAN support. Forces the network to work in a working point where a certain codec is most efficient. If other codecs are used, efficiency may deteriorate. Other applications may also perform less well. Adaptation to DVB-RCS environment The new DVB-RCS access scheme poses a few challenges to the above described concept no longer are the existing tools (Such as special satellite resource pool and proprietary headers in the return channel) available, and the question of whether the concept applies in this new environment is a valid one. It can be shown that with some adaptations, the concept is still valid even in the DVB- RCS environment, providing basically the same advantages and possibly more. The method to be used to request DVB- RCS resources would be CRA, where the NCC analyzes the call needs and allocates the required resources to the RCST without receiving a request from the RCST. A minor adaptation of the standard is required to allow dynamic allocation and de-allocation of CRA resources to an RCST on a per-call basis, according to call characteristics. Providing better efficiency may also be achieved through the a-priori knowledge of the media stream end-to-end characteristics such as UDP ports. This enables header compression to be applied on each media stream, removing even the IP headers, and reconstructing them on the other side. When performing IP header compression, some deviation from the DVB-RCS standard is required due to the fact that the packets are no longer IP proper modification of the standard in the context of session management should enable this support. Of course, such header compression may require additional information transfer between the two ends of the satellite link information not currently available within the DVB-RCS specs. C2P, a new protocol currently under development, may be applied to provide such information transfer. Additional point to consider is the fact that the current approach is built on reducing the VoIP calls back to circuit switching mechanisms. These mechanisms guarantee quality of service equal to that expected by landline telephone subscribers (except for the obvious satellite delay and compression). It must be considered how to provide virtual circuit implementation in the DVB-RCS environment which is geared towards IP traffic. In this respect also arises the question of efficiency caused by the resolution of ATM cells or MPEG frames the currently available media formats in DVB-RCS. Last, moving forward with a new access scheme provides an opportunity to resolve existing deficiencies in the model such as the transparency issue, interface to IMS and standardization of the protocol between the NCC and the softswitch. Conclusion 4

Conclusion Satellite communications based on geo-synchronous satellites are characterized by a large delay, and high cost of resources. VoIP applications over satellite networks must thus be handled very carefully so as to provide quality of service, as expected from voice calls while maintaining as high satellite resource exploitation efficient. We have described above a circuit-switching approach to overcome the challenges VoIP posed to satellite network vendors and operators. The approach consists of an integrated softswitch included in the network, communicating with the hub and providing information for exact resource allocation such that each call is allocated dedicated resources. The approach had been implemented and tested and is provided by Gilat and is commercially available as a VoIP solution. Finally, some considerations of using this approach in a DVB-RCS network were discussed and required additions to the standard were indicated. The work of optimising VoIP and other session based protocols over the DVB-RCS standard was carried out under the VIVALDI project that is partially funded by the EC within the 6 th FP. 5