The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 N.G.Vasantha Kumar1, Mohanchur Sarkar2, Vishal Agarwal2, B.P. Chaniara2, S.V.Mehta3, V.S.Palsule4, K.S.Dasgupta5 1 ISRO Hq., Bangalore, India vasant63@isro.gov.in 2 Space Applications Centre, ISRO {msarkar, vagarwal, bpchaniara}@sac.isro.gov.in 3 Space Applications Centre, ISRO svmehta80@hotmail.com 4 DECU, ISRO vilaspalsule@sac.isro.gov.in 5 Indian Institute of Space Technology, Trivendrum ksdasgupta@yahoo.com A BSTRACT This paper discusses in-house designed and developed scale-down DVB-RCS hub along with the performance of the realized hub. This development is intended to support the Satellite Based e-Learning initiative in India. The scale-down DVB-RCS HUB is implemented around a single PC with other subsystems making it very cost effective and unique of its kind. This realization will drastically reduce the total cost of Satellite based Education Networks as very low cost commercially available Satellite Interactive Terminals (SITs) complying to open standard could be used at remote locations. The system is successfully tested to work with a commercial SIT using a GEO satellite EDUSAT which is especially dedicated for satellite based e-Learning. The internal detail of the DVB-RCS Forward and Return Link Organization and how it manages the Satellite Interactive Terminals access to the satellite channel using MF-TDMA approach has been described. K EYWORDS DVB-RCS, VSAT, HUB, MPEG, MFTDMA 1. INTRODUCTION Indian Space Research Organization (ISRO) has launched an exclusive satellite viz., EDUSAT (GSAT-3), to meet the demand for an interactive satellite based distance education system in the country. EDUSAT is primarily meant for providing connectivity to school, college and higher levels of education and also to support non-formal education including developmental communication. This reflects India’s strong commitment to use space technology for national development, especially for the development of the population in remote and rural areas. Education technology has undergone a sea change with the convergence of computers and communications. Much more versatile systems are now available and this calls for a fresh look at the communication segment of distance education [8]. In terms of technology, it is necessary to be simple and easy to deploy and to operate. They must be fully multimedia capable and Internet enabled. The Digital Video Broadcast-Return Channel via Satellite (DVB-RCS) [1] is an open standard defined by ETSI in late 2000. It is a potential technology for supporting the goals set by EDUSAT. The intent of the open standard is to accelerate economies of scale, thereby DOI : 10.5121/ijma.2011.3112 133 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 generating lower-cost solutions and opening the market in a shorter timeframe than could be possible with competing proprietary solutions. Conventional commercial VSAT networks do not support inter-operability between terminals or between terminals and HUB as they use proprietary protocols. The DVBRCS, an open standard [1] is designed to combat this issue. So any vendor can develop either DVB-RCS compliant Hub or terminals, which by default become inter operable. However, implementation techniques vary from implementers to implementers. This paper discusses the implementation approach, which in general is not included in standard. Keeping in view of these advantages, of inter operability and growth potential it is decided to use the DVB RCS standard for our proposed EDUSAT network. Commercially off-the-shelf DVBRCS Hubs and terminals are available. However these HUBS very costly for the sophisticated features, it provides and the IPR of their manufactures. All the sophisticated features of a commercial HUB may not be needed in network dedicated for education. There is a need to provide multiple Hubs as in our country education is a state policy and each state or university may need its own HUB. This calls for realization of a cost effective scaled down version of DVB RCS HUB, which can work with the commercially available terminals thereby encouraging the growth potential of the EDUSAT network. In order to support distance education application (Lecture broadcast and interaction of student with teacher one-at-a-time), a scale-down DVB-RCS hub is proposed with support of Constant Rate Assignment (CRA) and MPEG option only [5]. The other functionalities like AAL5 and capacity management features will be added at a later stage to make a full-fledged hub utilizing the efficient usage of return link bandwidth. In section II an overview is given about the scale-down DVB-RCS hub. In section III the implementation and realization of the scale-down DVB-RCS system is described. Section IV describes the test and evaluation of the implemented system using live satellite link. 2. OVERVIEW OF SCALE-DOWN DVB-RCS HUB The basic building blocks of the scale-down DVB-RCS hub consists of a Forward link sub system (FLSS), Return link subsystem (RLSS) and Hub Management. Fig. 1 gives an overview of the system architecture for DVB-RCS hub and cross marked subsystems are not implemented in the scale-down version from the full-fledged DVB-RCS hub. The scale-down DVB-RCS hub supports MPEG in Return link and CRA in capacity management. The support of CRA eliminates the development of complex network resource allocation and MPEG option eliminates the development of AAL5 Decapsulation at Hub side. The FLSS consists of Static tables [1] generator, IP Encapsulator, DVB Multiplexing (data stream), Program Clock Reference (PCR) inserter and the DVB modulator. The RLSS consists of Multi channel Multi carrier burst demodulator (MCD), IP Decapsulator and IP router. The hub management includes burst processing (control), dynamic tables [1] generation and capacity management. The static tables like Superframe Composition Table (SCT), Frame Composition Table (FCT), Timeslot Composition Table (TCT), Satellite Position Table (SPT), Broadcast Terminal Information Message (TIM-B) are generated in FLSS. The dynamic tables Unicast Terminal Information Message (TIM-U), Correction Message Table (CMT) and Terminal Burst Time Plan (TBTP) are generated in RLSS and forwarded to the FLSS module. These tables are generated on-the fly for the proper operation of the total network. The IP based traffic corresponding to all the users are multiplexed into a conventional DVB/MPEG-2 data broadcast stream at the Hub and relayed to all the Satellite Interactive Terminals (SITs). The return link traffic received from SITs is either sent to the local LAN of the HUB or forwarded to the FLSS for sending it to other SITs based on the destination IP address. The total network is synchronized using a Network Clock Reference (NCR). The NCR is similar Protocol (NTP) Server is used to synchronize with all individual subsystems of 134 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 the hub and the total network. The outdoor unit at the hub consists of RF elements like BUC / HPA, LNBC / LNA and antenna. DVB DEMOD DVB-RCS Gateway ODU PCR MONITOR* MCAST SERVER* BACKBONE SERVICE PROVIDERS FIREWALL* INTERNET Traffic LAN CONTROL SCHEDULER CSC TIM-U LOG ON CMT LOG OFF TBTP REFERENCE TERMINAL* DVB MOD. CAS* Static Tables & IP-DVB Encap DVB MUX IP-ATM Encap IPSEC* PCR INSERTER IP ACCESS^ ROUTER IDU FLSS PEP* WEB CACHE* NTP Server SIT SYNC RF TRF CAPACITY MANAGEMENT + CRA HOSTS ODU SNMP AGENT RLSS IDU VBDB AVBDC HUB MANAGEMENT IP-DVB DECAP RBDC TRAFFIC LAN FCA CONTROL LAN MCD ATM IP ROUTER^ /ATM SIGNALING LOCAL OP. CONSOL TIME & FREQ. REF. * OPTIONAL + CRA ONLY CONTROL & MANAGEMENT LAN ^ Part of RLSS FIG. 1 : DVB-RCS SCALED DOWN VERSION 2.1. Forward Link Sub System (FLSS) The FLSS Software performs four main functions: (I) SI Table Generation (II) IP Encapsulation, (III) NCR Generation (IV) Multiplexing. 2.1.1. SI Table Generation The DVB-RCS service Information tables can be broadly divided into two categories: Static tables and Dynamic tables (there is a change in the configuration of the network). DVB RCS Forward Link Packet Generator software provides a flexible way of generating the Forward link Signaling as per user requirement and fully compliant with the DVB-RCS standard [1]. A highly user interactive GUI takes the relevant information from the network operator and generates the following static DVB RCS Service Information tables: (I) NIT [16]/PAT/PMT/PMT_RMT/RMT [1] generator (II) SCT/FCT/TCT/SPT generator (III) TIM Broadcast generator (IV) Multicast Mapping Table generator 2.1.1.1. NIT/PAT/PMT/PMT_RMT/RMT Generator This module generates the static tables of the Forward link like Network Information table, Program Map Table, Program Map Table for the DVB-RCS Tables and the RCS Map table. NIT and RMT combined give the network parameters and tuning parameters for the terminal like the frequency in which the forward link is transmitted, symbol rate, coding rate etc. The PAT, PMT, PMT_RMT convey the PIDs in which other DVB-RCS tables and PCR are transmitted. 135 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 After analyzing these tables the terminal understands the way in which all the SI tables are organized in the Forward Link. The contents of these tables generally don’t change unless there is a change in the network configuration, which can be done using the GUI of the Forward Link Packet Generator 2.1.1.2. SCT/FCT/TCT/SPT Generator This module generates the Superframe Composition Table, Frame Composition Table, Timeslot Composition Table and Satellite Position Table. These four tables combined give the frequency plan of the return link to the terminal. The FCT, TCT, SPT are static tables and the contents generally don’t change. The SCT is a dynamic table and contains all information about a superframe like when the superframe starts, how long it lasts and the sequence number of that superframe. It contains the superframe_start_time_base field which signifies the start of a superframe in terms of PCR ticks, duration field to specify the duration in terms of PCR ticks and superframe counter to signify the superframe number. The generator increments these value accordingly. Each new superframe is updated with the new value of PCR and count. This helps new terminals to know the current superframe going on and acquire the forward link. 2.1.1.3. TIM Broadcast Generator The TIM generator generates the Terminal Information Message Table. The broadcast TIM conveys network conditions, which affect all terminals. 2.1.1.4. MMT Generator The MMT generator generates the Multicast Map Table to signify the PIDs in which the multicast data is to be transmitted in the forward link. 2.1.2. IP Encapsulation IP Encapsulation into DVB is done using the Multi-protocol Encapsulation as specified [2]. The software module for IP Encapsulation performs the following major functions: (i) The software takes the IP data through socket and packs it into DSMCC Sections with the appropriate MAC address of the destination SIT. The IP packets corresponding to the SIT's are sent to the application layer using the methodology defined in [13]. The IP Address to MAC translation is done using lookup table whose size depends on the number of terminals registered in the network. (ii) The DSMCC sections can take a maximum of 4KB of IP data. So IP data with larger length is to be segmented by the software into multiple DSMCC Sections using the section number and last section number fields of DSMCC [1]. (iii) The software distributes DSMCC Sections containing IP Packets into 188 bytes MPEG2TS packets which act as containers of the IP data. In case the length of the DSMCC Section does not match with the 184 bytes payload of MPEG2 TS the remaining space is stuffed with 0xFF (FFh). 2.1.3. NCR Generation The overall synchronization of the network is based on satellite distributed NCR timestamps. This synchronization concept is based on program synchronization methods originally used in MPEG2 through the use of the Program Clock Reference concept. The PCR basically represents the highly stable 27 MHz system clock at the HUB, which acts as the master clock for the network. PCR is 42 bit format where the first 33 bits represent a 33bit base counter driven at 90 KHz thereby signifying a scaled down value of the network clock and the remaining 9 bits represent 9 bit modulo-300 extension counter. The terminals receive these PCR packets through 136 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 the forward link and try to generate an exact replica of the system clock using a PLL approach to remove low frequency jitter. The SIT uses a low crystal oscillator to generate 27MHz clock and compares its values with each received PCR packets thereby stabilizing the local clock. PLL is a feedback loop that uses an external signal (the incoming PCR packets in our case) to tune a local signal source (generated by the local Oscillator in our case) in order to generate a relatively more stable result signal (the receiver’s reconstructed local clock in our case). The Forward link Packet generator sends the NCR packets with the same syntax as PCR packets [3] on a separate PID. This PID is indicated to the network in the Program Map Table. The NCR is sent every 10 milliseconds taking the time from the system clock. The system clock is stabilized by installing a NTP Client in the Forward link Packet generator PC which takes NTP time from the GPS integrated NTP Server [12] to synchronize its own system clock. This stabilized clock is used to generate the NCR. The PCR packets may suffer from small variations called PCR jitter arising from buffering, truncation of PCR values and small processing variability. There can be an error introduced in the PCR during the time of generation in which case the PCR value itself is erroneous. It may also happen that the PCR is generated correctly but transmitted with variable delay so a correct PCR reaches the receiver at a wrong time. The DVB timing synchronization is based on the basic idea that there should be a constant time difference between the encoder and decoder side [17]. The fixed delay can be taken care of by sending the information in Optional PCR Insertion TS packets but the variable delay causes PCR jitter and thereby an instability of timing and frequency of the terminal. 2.1.4. Multiplexing: The major functions of Multiplexing [17] module are as follows: (i) Take multiple inputs like static tables, encapsulated IP packets, dynamic tables from RLSS, PCR [19] [20] packets and generate a single output transport stream. (ii) For constant data rate output NULL packets are added as and when required. 2.2. Return Link Sub System (RLSS) and Hub Management: The RLSS & Hub Management Software performs following main functions: (i) Handle SIT logon / logoff (ii) SIT Synchronization (iii) Dynamic table Generation (iv) IP Decapsulation 2.2.1. SIT Log ON / Log OFF Procedure After receiving Forward link, if any SIT wants to interact with hub, it sends CSC burst in the CSC slot. On receiving CSC Burst, hub checks whether SIT is authorized, by seeing its MAC address. Then it assigns Logon ID and Group ID to the SIT and SIT may go for coarse synchronization. If the SIT does not receive the TIM-U containing the information about Logon ID etc., the SIT will wait for random period and then send the CSC burst again. The Log OFF procedure is initiated as a normal session termination or as a failure (abnormal) case. Abnormal log-off is initiated in case of loss of synchronization. When terminal is logged off, its logon ID, group ID and SYNC slots are released into the pool for reuse by another SIT trying to enter the network. 137 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 2.2.2. SIT synchronization The synchronization of the SIT is an important feature of any satellite interactive network. This is required to obtain efficient TDMA (here MF-TDMA) operation with maximum throughput and minimum interference. The SIT synchronization scheme operates on the Clock Reference and signaling information received through the forward link, which is MPEG2-TS. The Network Clock Reference (NCR) [1] is derived from the HUB reference clock (27 MHz) and distributed through the forward link with a separate PID in the MPEG2 transport stream. This enables all terminals in the network to receive the reference clock at 27 MHz for synchronization [19]. The 27MHz clock is slaved with the GPS based NTP server [12]. Since the MFTDMA operation requires a high precision in timing and frequency accuracy there is a need for periodic correction of the terminals when they are in communication. The HUB manages terminal synchronization through a set of messages exchanged between HUB and terminal on reserved time slots. It allows the fine-tuning of the synchronization parameters like, frequency offsets and time offsets between the terminal and the HUB. It also controls the SITs transmit power through the dynamic tables TIM-U and CMT. The dynamic tables change with time and the HUB has to generate those taking data from the return channel. The generation of the dynamic tables is the main objective of the HUB. For terminal synchronization dynamic tables like TIM-U and CMT are used sent on forward link and CSC, ACQ and SYNC bursts are used on the return link. The ACQ and SYNC bursts are special bursts containing symbols dedicated for the HUB to be able to measure frequency and timing offset. SYNC bursts are continuously sent by terminal to the hub for fine synchronization. As soon as the SIT gets the TIM unicast from the hub, it will follow the synchronization procedure. SIT should remain synchronized till the session ends. The synchronization procedure is briefly explained here. (a) Course Synchronization Procedure: The SIT sends ACQ burst in the slot allotted via TIM unicast. Hub receives ACQ burst and sends Correction Message Table. In this table Hub sends the parameters to be corrected e.g. Burst Time, Frequency and Power. (b) Fine Synchronization Procedure: The SIT sends SYNC burst in the slot allotted via TIM unicast. Hub receives SYNC burst and sends Correction Message Table. In this table Hub sends the parameters to be corrected e.g. Burst Time, Frequency and Power. (c) Synchronization Maintenance Procedure: After achieving the fine synchronization the SIT is allowed to transmit TRF bursts. It is required to maintain synchronization parallel to sending the traffic throughout the session. The SYNC bursts are sent according to sync repeat period given through the TIM unicast, and Hub will send the CMT in response to every SYNC burst received. The HUB requests a terminal to transmit a sequence of ACQ bursts via the TIM by assigning a BTP ACQ timeslot for a limited number of repeats. The HUB also requests terminal to transmit SYNC burst periodically via the TIM by signaling a SYNC time slot once every N super frames. By receiving the ACQ and SYNC bursts, the HUB determines the power, frequency, and burst time error of the terminal. Corrections for frequency and burst time are sent in CMT for correction to the terminal. A SIT can request for TRF slots based on its requirement either in SYNC burst or as in-band data of TRF burst. The hub receives the requests from all the logged in SITs in the network and allocate the time slots in the MF-TDMA structure. The assignment of timeslots is sent from the HUB using TBTP table. A SIT will receive this information and transmits the TRF burst based on the assignment received from the HUB. 138 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 2.2.3. Dynamic Table Generation The RLSS generates the following dynamic tables required for the operation of the total network. (I) TIM-U generators (II) CMT generator (III) TBTP generator 2.2.3.1. TIM Unicast Generator The TIM generator generates the Terminal Information Message Table. The TIM contains the descriptors like logon_initialize_descriptors, ACQ assign descriptor, and SYNC assign descriptor [1] needed to handle logon of terminals to the network and inform specific information to SITs. The TIM generator is mainly used to handle logon of terminals to the network. 2.2.3.2. CMT Generator The CMT generator generates the Correction Message Table, which contains the timing, frequency and power corrections of all terminals in ACQ or SYNC phase. The CMT generator is needed during the coarse synchronization and fine synchronization and synchronization maintenance phase of the HUB Management. 2.2.3.3. TBTP Generator The TBTP generator generates the Terminal Burst Time Plan for all the terminals logged on to the network. The Hub for traffic assignment of terminals uses the generator, after it has passed the ACQ and SYNC phase. 2.2.4. IP decapsulation The IP packets are received in the HUB as IP-MPE packets in the TRF slots assigned to the SIT, which are to be either sent to other SITs by forwarding them through Forward link or on the local LAN of the hub. These IP packets are received in fragments and are to be combined to build a proper IP packet. If the IP packet is destined for other SITs it is forwarded to the Forward link. If the IP packet is destined for the local LAN it is sent through the Ethernet card of the system. This module works as the router. 3. IMPLEMENTATION A scale-down DVB-RCS hub prototype is implemented and is tested via satellite using a single SIT. The total test setup diagram is shown in Fig2. The NTP server, MCD, DVB Modulator, Servers etc. are the COTS items on the hub side. The SIT, the PC etc. are the COTS items on the remote side. This implementation is based on one frame in one super frame with a single carrier frequency in Return Link The timeslots defined in the frame are 1 CSC, 1 ACQ, 2 SYNC and 11 MPEG TRF[1] slots with a data rate of 624.3 Kbps using Turbo code of 2/3 [1]. The burst formats used in the test setup are defined in the TCT. The NTP [12] server based on GPS provides a frequency stability of 2x10-11. A GPS based NTP server is used for disciplining all the clocks used within the total system. The NTP client services running on the Server and the MCD get disciplined with the NTP server time. The most critical part in this system is the generation of proper time stamp [9]. A system call is used for getting the current time and this time is converted in to the NCR time. The Golden Rule is applied in calculation of NCR time [3]. The NCR rollover has also be taken into account while calculating the current NCR time. The forward and return link software runs on a standard server running Linux operating system. These two software are running as independent programs on the same server. The MCD ver 1.1 139 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 used in this set up is from M/S Alcatel Bell Space. The demodulated data is distributed in the multicast IP packets on the local LAN of the hub. The return link software uses a socket to obtain the information regarding the start time of the first superframe, in the network, from the forward link software. This is the critical information as all the dynamic tables generated are based on the current superframe number. All the subsystems of the hub i.e., MCD, Forward link and return link software uses the NCR as reference. The Hub Management software is also part of the return link software An Object Oriented Design approach is adopted in designing the forward link software. The GUI of the Forward Link generator takes the input from the user to generate the tables like the Name of network, forward link symbol rate, frequency in which the forward link is transmitted, the PIDs of the other tables and the way the forward link is arranged in terms of PIDs and all other files necessary for the generation of the tables as per the standard [1]. More details on the forward link software are given in [10]. All the Service Information tables, Descriptors, IP Encapsulated data and NCR are coded as separate objects, with associated routines of generating them as member functions. The general SI Header’s objects and DSMCC Sections [1] objects are inherited by SI Table and IP Encapsulation objects. The return link software is developed on multithreading environment for handling different tasks at the same time. The main objective of the RLSS software is to receive the bursts sent by MCD at multicast IP address, identify the bursts and distribute them to the appropriate software module threads for further processing. More details on the return link software are given in [11]. The functionalities of different threads that are developed in the RLSS software are as follows: Figure 2. Test Setup of Scale-down DVB-RCS system. Receive data from MCD Identifying the Bursts. CSC burst processing TIM-U generation and sending it to FLSS module ACQ burst processing CMT generation and sending it to FLSS module SYNC burst processing 140 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 CMT generation and sending it to FLSS module TRF burst processing & IP Decapsulation. TBTP generation. Sending IP packets in to the network using raw sockets.The IP packet handling method in this implementation does not require a router at the hub and a patent [13] has been filed on this concept. This method can be adopted in any application where there are different paths for sending and receiving IP packets at the hub. 4. TEST & EVALUATION The scaled-down DVB-RCS hub was tested with 4.3404 MSPS with FEC ½ rate using western beam (Ku-band) of EDUSAT (GSAT-3) in the forward link. A 1.2m Antenna with 2 W SSPB was used for up linking from the hub. A 1.2m Antenna with 2 W SSPB and a COTS SIT. A snapshot showing the various states of the SIT which it has undergone to become active is shown in figure 3. The e-learning requires the delivery of lecture from a central location to all the remote locations. This is accomplished by IP multicast of video streaming the lectures from the Hub to all the SIT's. For supporting multiple lecture sessions, multicast broadcasting of multiple video streams aggregating to the 3.5 Mbps were used and found to be working satisfactorily. Basic functionality of ICMP (ping), UDP and TCP/IP was tested. For ICMP, ping command was given from the PC attached to the SIT to the PC connected with hub. This ping data (request command) was received by BMD through SIT. BMD passed this ping data as traffic burst to the RLSS software module. RLSS s/w module decoded this traffic burst and forwarded this decapsulated packet to the PC attached with hub according to the IP. Then the PC attached with hub sent the reply to the RLSS module of hub. This in turn sent it to the FLSS module of hub. After encapsulation, FLSS module sent this reply as forward link to the SIT and SIT after decapsulation, forwarded it the PC attached with it. Thus a loop of ping got completed. The UDP is checked through free available software VLC (Video LAN Client). And it was found that packets are received. . Figure 3. Log of SIT showing the various states For the TCP support on the network, we have used File Transfer Protocol (FTP). Files were successfully transferred from Hub side PC to the PC attached with SIT. The TCP/IP throughput was obtained by assigning all the traffic slots to the SIT as shown in Table 1 for the commercial 141 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 hub and for the in-house developed hub. The results obtained using in-house developed hub, are comparable with the results obtained using the commercial hub The results obtained using the in house HUB is seen to perform 10%-20% lower than the commercial HUB as the size of the file increases. This is attributed because of the fact that the commercial HUB uses dedicated commercial router and uses hardware based solutions for forward and return link processing. The in house developed HUB uses a total software based approach for the generation of the forward link and return link processing including the IP packet processing and all the software runs on a single PC. Table 1. FTP Throughput with commercial HUB & our hub Sr. No. File Size (in bytes) 1 2 3 4 5 6 1M 2M 5M 50M 100M 200M Commercial Hub Throughput (KB/Sec) 133.47 174.06 204.93 237.28 239.51 240.87 Our Hub Throughput (KB/Sec) 132.13 172.91 206.48 214.25 200.26 203.78 5. CONCLUSIONS & FUTURE WORK A scale-down DVB-RCS hub has been realized and functionally tested with a COTS SIT in the satellite mode. This system can be used for e-learning in supporting live lecture and also for file transfer between the hub and the SIT. The realized hub is PC centric and does not require a commercial router, which reduces the cost of the total hub. The in-house HUB developed uses COTS items for Modulator, NTP Server and Multi Channel Demodulator and all other functionalities are realized in house using indigenous technology. The TCP/IP throughput obtained with in house developed hub is comparable with that of the commercial hub. In future the hub can be implemented to support AAL5 and other capacity management techniques to realize a full-fledged DVB-RCS hub. ACKNOWLEDGEMENTS The authors wish to thank Mr. Peter Amendusan, Mr. Oyvin Slungard, Mr. Hallvard of M/s Verisat, Norway for providing the Hub emulation software, analyzers, active technical support, and advices without which we could have not achieved this. We also would like to thank all the staff members of Advanced Communication Technology Division for their advice and active technical support towards the realization of this work. REFERENCES [1] ETSI EN 301 790 V1.4.1 Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems (2005-09) [2] ETSI TR 101 202 V1.2.1 – Digital Video Broadcasting Implementation Guidelines for Data Broadcasting [3] ISO / IEC 13818 - Information technology -- Generic coding of moving pictures and associated audio information: Systems 142 The International Journal of Multimedia & Its Applications (IJMA) Vol.3, No.1, February 2011 [4] Steven W. Richard - TCP/IP Illustrated: The Protocols Vol.1, 2, 3 Addison Wesley, (1994). [5] Proposal on Study Simulation & Proof of Concept of DVB-RCS, DVB-RCS Task Team, SAC/SITAA/TP/16, October (2002) [6] Video LAN Client Software http://www.videolan.org [7] Multi-Channel Multi-Frequency Burst Mode Demodulator Version 1.1 Specification. Doc: BMD-ABSP-SPE-0004 from Alcatel Bell Space N.V [8] Project Report on GSAT-3 (EDUSAT) Applications Programmer March 2003 Space Applications Centre. [9] Timing and synchronization using MPEG-2 Transport Stream David K. Fibush SMPTE Journal July (1996) [10] Mohanchur Sarkar, N.G.Vasantha Kumar, V.S.Palsule, K.S.Dasgupta DVB-RCS Compliant Forward Link Packet Generator In National Conference on Communication NCC (2005). [11] Mohanchur Sarkar, N.G.Vasantha Kumar, S.V.Mehta, V.S.Palsule, K.S.Dasgupta Implementation of Application Specific DVB-RCS Hub In International Conference On Communication ADCOM (2006) [12] References of Tym Server 2000 from Symmetricom, www.symmetricom.com [13] N. G. Vasantha Kumar, Vishal Agarwal, Mohanchur Sarkar A method for processing a plurality of Internet Protocol (IP) packets of a DVB-RCS Hub. A Patent with Application No.2739/CHE/2008 filed on Nov 7, 2009 and published on May 14, 2010. [14] SatLabs System Recommendations January (2004) [15] ETSI ETS 300 802: "Digital Video Broadcasting (DVB); Network-independent protocols for DVB Interactive services" [16] ETSI EN 300 468: "Digital Video Broadcasting (DVB) Specification for Service Information (SI) in DVB systems" [17] Implementation of a New MPEG-2 Transport Stream Processor for Digital Television Broadcasting by Liang Longfei, Yu Songyu and Wang Xingdong, IEEE Transactions on broadcasting Vol 48 No 4 December (2002) [18] Implementation of MPEG2 TS Remultiplexer and data transport unit for HDTV Satellite Broadcasting by Soo in Lee, Sung Bae Cho IEEE Transaction on Consumer electronics Vol 43 No 3 August (1997) [19] Terminal timing synchronization in DVB-RCS systems using on-board NCR generation by Neale and Guy Begin Space Communications 17(2001) [20] 20.Timing and synchronization using MPEG-2 Transport Stream by David K. Fibush SMPTE Journal July (1996). 143