Title of Invention	A METHOD FOR PROCESSING A PLURALITY OF INTERNET PROTOCOL (IP) PACKETS OF A DIGITAL VIDEO BROADCAST-RETURN CHANNEL VIA SATELLITE (DVB-RCS)HUB
Abstract	A method for processing a plurality of Internet Protocol (IP) packets at a Digital Video Broadcast- Return Channel via Satellite (DVB-RCS) hub An improved method for processing IP packets at the DVB-RCS hub using a single PC with standard Linux Operating system, involves obtaining the IP packets at an application layer instead of the network layer. The IP packets can be encapsulated in the application layer based on the IP-MPE standard, and forwarded to a forward link transport stream generator. Then, the IP encapsulated packets can be sent using a UDP to a satellite interactive terminal (SIT). Similarly, in the return link, the IP encapsulated packets received fi-om the SIT can be de-capsulated and routed based on a destination address in an IP header of the packets. Then, the IP packets can either be pumped into a local LAN or encapsulated and forwarded to another SIT. This method can able to provide the functionality of the IP packet processing at the DVB-RCS hub without the need of standalone router and proprietar\' hardware and/or firmware. Fig. 4

Title of Invention

A METHOD FOR PROCESSING A PLURALITY OF INTERNET PROTOCOL (IP) PACKETS OF A DIGITAL VIDEO BROADCAST-RETURN CHANNEL VIA SATELLITE (DVB-RCS)HUB

Abstract

A method for processing a plurality of Internet Protocol (IP) packets at a Digital Video Broadcast- Return Channel via Satellite (DVB-RCS) hub An improved method for processing IP packets at the DVB-RCS hub using a single PC with standard Linux Operating system, involves obtaining the IP packets at an application layer instead of the network layer. The IP packets can be encapsulated in the application layer based on the IP-MPE standard, and forwarded to a forward link transport stream generator. Then, the IP encapsulated packets can be sent using a UDP to a satellite interactive terminal (SIT). Similarly, in the return link, the IP encapsulated packets received fi-om the SIT can be de-capsulated and routed based on a destination address in an IP header of the packets. Then, the IP packets can either be pumped into a local LAN or encapsulated and forwarded to another SIT. This method can able to provide the functionality of the IP packet processing at the DVB-RCS hub without the need of standalone router and proprietar\' hardware and/or firmware. Fig. 4

Full Text	FIELD OF THE INVENTION The present invention relates to the fields of satellite-based data communication systems. The present invention specifically relates to a PC based IP packet processing in DVB-RCS hub. BACKGROUND OF THE INVENTION One of the preferred satellite-based technologies for networking on a large scale is a Digital Video Broadcast - Return Channel via Satellite (DVB-RCS). DVB can be designed primarily with video, but it can also be intended to allow for the delivery of other digital programs. DVB is a broadcast Irom one point to many and does not provide for data traveling in the opposite direction. RCS (Return Channel via Satellite) satisfies the need for data traveling in the opposite direction, so that the DVB-RCS provides a network topology to ensure that one large data pipe broadcast from one site to many receivers and another data pipe shared by many receivers received at one site, usually referred to as hub. In the present scenario, Internet Protocol (IP) packets are processed with the help of router at the Digital Video Broadcast - Return Channel via Satellite (DVB-RCS) hub. which is operating in a star topology. In ihe case of forward link, the DVB-RCS hub can transmit the IP packets to end-users via a transport stream. A DVB-RCS compliant forward link transport stream contains contain the IP packets that are destined to remote Satellite Interactive Terminals (SITs). The router can provide routing decisions for data traveling of the IP packets from the DVB-RCS hub to the remote SITs and direct die IP packets in accordance with the routing decisions. In general, these IP packets are processed at the network layer. Since the forv.'ard link transport stream generator is provided at an application la>er, the IP packets are required at the application layer instead of network layer for generating the DVB-RCS compliant forward link transport stream. This DVB-RCS compliant forward link transport stream is provided with the Transport Stream (TS) packets at the remote SITs. In addition, the DVB-RCS is an open standard for the air interface, but it is not open in the implementation details of IP packet processing at the hub. Thus, the vendors may utilize its own proprietary' ways of implementation using specific hardware. In the case of return link, a MuSti-Carrier burst Demodulator (MCD) can be utilized )br receiving the IP packets sent by the remote SITs. The MCD sends the TS packets containing the IP packet data to another process implemented in proprietary hardware and/or firmware. The proprietary hardware and/or firmware can process the TS packets to extract the IP packets from the TS packets. Then, these IP packets are sent to the router for further pumping it in to a local area netv.-ork (LAN) or forward it to the IP over muhiprotocol encapsulation (IP-MPE) hardware for sending these packets to another SIT. However, with respect to the conventional DVB-RCS, it is necessary to utilize the standalone router and the proprietary hardware and/or firmware for processing the IP packets, which increases the costs of the DVB-RCS hub assembly and aiso leads to tedious and time-consuming. Therefore, it is desirable to provide an improved IP packet processing for the DVB-RCS hub, which eliminates the need for standalone router and proprietary hardware. OBJECT OF THE INVENTION An object of the present invention is to provide an improved method for processing IF packets in a DVB-RCS hub using a single PC with standard Linux Operating system. Another object of the present invention is to pro^'ide an improved module for processing IP packets in a DVB-RCS hub using a single PC with standard Linux Operating system. SUMMARY OF THE INVENTION According to one aspect, the present invention, which achieves this objective, relates to an improved method for processing IP packets at a DVB-RCS hub using a single PC with standard Linux Operating system, involving: obtaining the IP packets to be forwarded in a forward link transport stream of the DVB-RCS hub, at an application layer. The IP packets can be encapsulated in the application layer based on an IP over multiprotocol encapsulation (IP-MPE) standard, and forwarded to a forward link transport stream generator. Then, the IP encapsulated packets can be sent using a user datagram protocol (UDP) to a satellite interactive terminal (SIT). Similarly, in the return link, the IP encapsulated packets received ftom the SIT can be de-capsulaied and routed based on a destination address in an IP header of the packets. Then, the IP packets can be pumped into a local LAN or encapsulated and forwarded to another SIT. Furthermore, the routing decision of the IP packets can be carried out at the application layer. If the destination address of the IP packets is for the local LAN, the IP packets can be pumped into the local LAN using Raw sockets with the IP header. Similarly, if the destination address of the IP packets is for the LAN connected to other SITs, the IP packets can then be encapsulated and forwarded to the forward link transport stream generator. This method can able to provide the flmctionality of the IP packet processing at the DVB-RCS hub without the need of a standalone router and without using the proprietary hardware and/or firmware. This method also allows the IP packets to be processed at the application layer instead of the neUvork layer, which achieves easy generation of the IP encapsulated packets. BRIEF DESCRIPTION OF THE DRAWINGS The invention will be discussed in greater detail with reference to the accompanying Figures. FIG. 1 shows a protocol stack at a DVB-RCS hub for user traffic with a SIT, in accordance with an exemplary embodiment of the present invention. FIG, 2 shows a protocol stack at the SIT for user traffic with the DVB-RCS hub, in accordance with an exemplary embodiment of the present invention. FIG. 3 illustrates a basic setup used to demonstrate an IP Packet Processing Module, in accordance with an exemplary embodiment of the present invention. FIG. 4 shows a flow chart of a method for processing IP packets at the DVB-RCS hub using a muhithreaded implementation, in accordance with an exemplary embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION Referring to FIG. 1, a protocol stack at a DVB-RCS hub for user traffic with a SIT is illustrated in accordance with an exemplary embodiment of the present invention. The method as shown in FIG. 4, can utilize the typical DVB-RCS protocol stack for easy IP packet processing at the hub using a single PC with standard Linux operating system. In the proposed method, the IP packets can be sent in a forward link B of a DVB-RCS network and obtained at the application layer using standard IP tables and IP queue's implemented in the Linux Operating System with kernel version 2.6.15. The IP tables can be configured to support user datagram protocol (UDP), transmission control protocol (TCP) and Internet control message protocol (ICMP) by the DVB-RCS network. These IP tables can also be configured to support multicast UDP protocol. In addition, the method can be authenticated using the SIT protocol stack for user traffic with the DVB-RCS hub as shown in FIG. 2. The method currently shows the IP packet processing for the IP packets exchanging between the DVB-RCS hub and one SIT with both return and forward links A and B. This method can also be extended to exchange the IP packets between two different SITs. In the proposed method, it is assumed that the SIT is operating in MPEG option mode, which uses IP-MPE as per the ETSI/EN 301790 standard. Similarly, the SIT can also be operated in an As>Tichronous Transfer Mode (ATM) option, which uses ATM Adaptation Layer 5 (AAL5) as per the ETSI/EN 301790 standard. Referring to FIG. 3, a basic setup used to demonstrate an IP Packet Processing Module is illustrated in accordance with an exemplary embodiment of the present invention. The IP Packet Processing Module consists of two gateways G connected back to back with two servers B and C representing the DVB-RCS hub H and SIT S, respectively. The DVB-RCS hub H and SIT S can exhibit its own local area network (LAN) with respective IP network addresses. Each server B and C can be provided with Ethernet cards to act as gateways G. These gateways G can be physically connected through Ethernet device (ethO) EG on back to back instead of using air interface as the medium. Furthermore, the IP Packet Processing Module can utilize three different IP networks, which is most commonly seen in any DVB-RCS network, where the three different IP networks are the local LAN on Ethernet device (ethl) El of the server B and the server C and the back-to-back connected Ethernet device ethO EO of both the servers B and C, respectively. In the actual DVB~ RCS network, the third IP network is the actual air interface of the network between the DVB-RCS hub H and the SITs S. In this method, the Ethernet Hnk can be utilized instead of the satellite link. Desktop terminals A and D can be attached and/or connected to the DVB-RCS hub H and the SIT S, respectively. The IP packet processing software can reside on the servers B and C, and utilize the IP-MPE for encapsulation and de-capsulaiion of the IP packets. In the case of AAL5 support, the IP encapsulation can be implemented into the AAL5 at the server C and the IP de-capsulation can be implemented from the AAL5 at the server B. The desktop terminals A and D are set with default gateway address corresponding to the IP addresses binding to the Ethernet devices El of the servers B and C, respectively. The default gateway of the ser\'ers B and C are set with the IP addresses corresponding to the Ethernet devices EO of the desktop terminals C and B, respectively. For example, the below-mentioned table shows the IP addressing scheme along with the default gateways. Terminal Ethernet Interface IP Address Defauh Gateway A EO 192.170.1.102/24 192.170.1.101 B El 192.170.1.101/24 172.16,2,2 EO 172.16.2.1/24 C EO 172.16,2.2/24 172.16.2.1 E! 192.170.2.101/24 D ) EO 192.170.2.102/24 192,170.2.!01 Moreover, an IP forwaiding mechanism can be enabled in the servers B and C by setting the /proc/sys/net/ipv4/ip forward to 1. This can also be set in /etc/sysctl,conf file for setting this parameter permanently by inserting the following command line into the file, i.e. echo ] > /proc/sys/net/ipv4/ip forward. The 'super user' of the overall system can make all these changes. Additionally. Netfilter is a Linux kerne! framework for mangling the IP packets, and certain hooks are defined for each network IP protocol. These hooks can correspond to well-defined places in the protocol stack and allow custom packet mangling code to be inserted in form of kernel modules, as illustrated in FIGS. 1-3. Each IP packet arriving at the hooks can be delivered to the code segments that are registered on the hooks, which allows the IP packets to be altered, dropped or re-routed by the custom code segments. When the IP packets are processed, a verdict should be returned to the Netfilter. This verdict instructs Netfilter to perform some packet-related action, e.g. to drop the IP packets or to let it continue hs traversal through the protocol stack. Such Netfilter also offers the abilit>- to process the IP packets in user-space. The IP packets can be queued in kernel space and information about the IP packets can be sent to user-space over a Netlink socket by remming a special queue verdict. The IP packets remain queued until the user-space application, at the other end of the Netlink socket returns verdicts indicating the desired actions, i.e. ACCEPT or DROP, for the IP packets. These packets can also be modified in the user-space prior to re-injection back into the kernel. Finally, the Netfilter approach allows the implementation to stay independent of kernel modifications. Therefore, the IP packets corresponding to the IP network destined for the terminals A and D in the other IP network at the application layer can be retrieved using IPTABLES and Iibipq without modifying the kernel code. The IPTABLES is a tool that talks to the kernel and tells it which packets to be filtered. This tool can queue the IP packets based on the rules set to the user-space. The IPTABLES supports 3 type of chains and/or queues such as INPUT, FORWARD and OUTPUT. Here, the chain "FORWARD' supported by the IPTABLES is used. The IPTABLES are set with the commands for packet filtering of the TCP, UDP and ICMP protocols. Some of the sample IPTABLES rules for TCP/UDP.1CMP are iptables -A FORWARD -p tcp -j QUEUE, iptabtes -A FORWARD -p udp -j QUEUE and iptables -A FORWARD -p icmp -j QUEUE. These settings can allow the IP packets of TCP, UDP and ICMP destined to other network to be queued to the user-space. The IP packets of all the types can be received in the application layer by using IPQUEUES, known as iibipq'. The libipq is a development library for user-space packet queuing of the IPTABLES, For each supported protocol, a kernel module called a queue handler can be registered with the Netfilter to perform mechanics of passing the IP packets to and trom the user-space. Initially, the IP packets can be retrieved using the de-capsulation of IP-MPE for sending the IP packets received from the other side in the IP-MPE format. Then, the IP packets can be pumped into the network using the raw socket if the particular IP packets are destined for the local LAN on the HUB side H. This method can also be extended to support forwarding of the IP packets destined for the other SIT LAN's based on the destination IP address. These IP packets can be encapsulated based on the IP-MPE and forwarded to the forward link Transport Stream (TS) generation. Referring to FIG. 4, a flow chart of a method for processing IP packets at the DVB-RCS hub using a multithreaded implementation is illustrated, in accordance with an exemplary embodiment of the present invention. Such multithreading M is implemented to make the IP packet processing faster. The data between various threads is processed using the message queues. The appropriate IPTABLES and route command should be used for supporting multicast, in particular the IPTABLES can be initialized by setting up proper rules. In addition, the sockets, Pihreads and message queues can also be initialized to create a set of threads A, B and C. During multithreading implementation, in thread A, the queued packets are read and passed to the thread B through the message queues. In thread B, the IP packets sent by the thread A can be received from the message queues. Then, the IP packets are encapsulated into MPE, and the encapsulated IP packets are sent to a distant network of a distant machine D. In thread C, MPE packets can be received from other networks through the sockets. Thereafter, the received MPE packets are either sent to the distant netw'ork of the distant machine D or de-capsulated into the IP packets. Finally, the IP packets can be pumped into a local network of a local machine L using raw socket. For example, the IPTABLE rule, i.e. iptables -A INPUT -m pkttype - -pkt-type multicast -j QUEUE, is set in server B while performing the multicast from the terminal A to the terminal D. The mulicast packets can be forwarded only when the server B receives the mulicast packets transmitted by the terminal A. in order to receive the muhicast packets at the server B, the server B can join to the multicast group. At server C, no particular IPTABLE rules are required, since the transmission is one sided, i.e. nothing is sent back, but it requires the routing table entry such as route add -net 224.0.0.0 netmask 240.0.0.0 dev ethl. Then, the muhicast packets at the server C can be transmitted into the destination local network. This concept can be used in any network where the splitting of a connection is required at the gateways G. WE CLAIM: 1. A method for processing a plurality' of Internet Protocol (IP) packets at a Digital Video Broadcast - Return Channel via Satellite (DVB-RCS) hub, comprising: obtaining said plurality of IP packets at an application layer; encapsulating said plurality' of IP packets in said application layer based on an IP over multiprotocol encapsulation (IP-MPE) standard; forwarding said plurality of encapsulated IP packets to a forward link transport stream generator of said DVB-RCS hub; and sending said plurality of encapsulated IP packets using a user datagram protocol (UDP) to a satellite interactive terminal (SIT), and thereby processing said plurality of IP packets at said DVB-RCS hub without using a standalone router and a proprietary hardware and/or firmware. 2. The method of claim !, further comprising: de-capsulating said plurality of encapsulated IP packets received from said SIT in a return link; routing said plurality of IP packets based on a destination address in an IP header of said plurality of IP packets: pumping said plurality of IP packets into a local area neUvork (LAN) using a plurality of raw sockets with said IP header, if said destination address of said plurality of IP packets is for said local LAN; and encapsulating and forwarding said plurality of IP packets to another SIT, if said destination address of said pluralit>- of IP packets is for a LAN connected to other SIT. 3. The method of claim 1, wherein said application layer carries out a routing decision of said plurality of IP packets. 4. The method of claim 1, wherein said pluraUty of IP packets is encapsulated and de-capsulated using IP-MPE and AAL5. 5. The method of claim 1, wherein said plurality of IP packets is processed by multi-threading using a message queue to support and sustain a high data rate of IP packet processing at said DVB-RCS hub. 6. The meihod of claim I, wherein said plurality" of IP packets is obtained at said applications layer using a plurality of standard IP tables and a plurality of IP queues without modifying a kernel code. 7. The method of claim 1, wherein said plurality of standard IP tables and said pluraUty of IP queues are implemented in a single PC with standard Linux Operating system. 8. The method of claim 1. wherein said plurality of standard IP tables is configured to support UDP, TCP, iCMP and multicast UDP. 9. The method of claim 1, wherein said SIT is operated in both MPEG option mode and ATM option mode to. A system comprising a processor configured to perform the method as claimed in the preceding claims.

Full Text

FIELD OF THE INVENTION
The present invention relates to the fields of satellite-based data communication systems. The present invention specifically relates to a PC based IP packet processing in DVB-RCS hub.
BACKGROUND OF THE INVENTION
One of the preferred satellite-based technologies for networking on a large scale is a Digital Video Broadcast - Return Channel via Satellite (DVB-RCS). DVB can be designed primarily with video, but it can also be intended to allow for the delivery of other digital programs. DVB is a broadcast Irom one point to many and does not provide for data traveling in the opposite direction. RCS (Return Channel via Satellite) satisfies the need for data traveling in the opposite direction, so that the DVB-RCS provides a network topology to ensure that one large data pipe broadcast from one site to many receivers and another data pipe shared by many receivers received at one site, usually referred to as hub.
In the present scenario, Internet Protocol (IP) packets are processed with the help of router at the Digital Video Broadcast - Return Channel via Satellite (DVB-RCS) hub. which is operating in a star topology. In ihe case of forward link, the DVB-RCS hub can transmit the IP packets to end-users via a transport stream. A DVB-RCS compliant forward link transport stream contains contain the IP packets that are destined to remote Satellite Interactive Terminals (SITs). The router can provide routing decisions for data traveling of the IP packets from the DVB-RCS hub to the remote SITs and direct die IP packets in accordance with the routing decisions. In general, these IP packets are processed at the network layer. Since the forv.'ard link transport stream generator is provided at an application la>er, the IP packets are required at the

application layer instead of network layer for generating the DVB-RCS compliant forward link transport stream. This DVB-RCS compliant forward link transport stream is provided with the Transport Stream (TS) packets at the remote SITs.
In addition, the DVB-RCS is an open standard for the air interface, but it is not open in the implementation details of IP packet processing at the hub. Thus, the vendors may utilize its own proprietary' ways of implementation using specific hardware. In the case of return link, a MuSti-Carrier burst Demodulator (MCD) can be utilized )br receiving the IP packets sent by the remote SITs. The MCD sends the TS packets containing the IP packet data to another process implemented in proprietary hardware and/or firmware. The proprietary hardware and/or firmware can process the TS packets to extract the IP packets from the TS packets. Then, these IP packets are sent to the router for further pumping it in to a local area netv.-ork (LAN) or forward it to the IP over muhiprotocol encapsulation (IP-MPE) hardware for sending these packets to another SIT.
However, with respect to the conventional DVB-RCS, it is necessary to utilize the standalone router and the proprietary hardware and/or firmware for processing the IP packets, which increases the costs of the DVB-RCS hub assembly and aiso leads to tedious and time-consuming. Therefore, it is desirable to provide an improved IP packet processing for the DVB-RCS hub, which eliminates the need for standalone router and proprietary hardware.
OBJECT OF THE INVENTION
An object of the present invention is to provide an improved method for processing IF packets in a DVB-RCS hub using a single PC with standard Linux Operating system.

Another object of the present invention is to pro^'ide an improved module for processing IP packets in a DVB-RCS hub using a single PC with standard Linux Operating system.
SUMMARY OF THE INVENTION
According to one aspect, the present invention, which achieves this objective, relates to an improved method for processing IP packets at a DVB-RCS hub using a single PC with standard Linux Operating system, involving: obtaining the IP packets to be forwarded in a forward link transport stream of the DVB-RCS hub, at an application layer. The IP packets can be encapsulated in the application layer based on an IP over multiprotocol encapsulation (IP-MPE) standard, and forwarded to a forward link transport stream generator. Then, the IP encapsulated packets can be sent using a user datagram protocol (UDP) to a satellite interactive terminal (SIT). Similarly, in the return link, the IP encapsulated packets received ftom the SIT can be de-capsulaied and routed based on a destination address in an IP header of the packets. Then, the IP packets can be pumped into a local LAN or encapsulated and forwarded to another SIT.
Furthermore, the routing decision of the IP packets can be carried out at the application layer. If the destination address of the IP packets is for the local LAN, the IP packets can be pumped into the local LAN using Raw sockets with the IP header. Similarly, if the destination address of the IP packets is for the LAN connected to other SITs, the IP packets can then be encapsulated and forwarded to the forward link transport stream generator. This method can able to provide the flmctionality of the IP packet processing at the DVB-RCS hub without the need of a standalone router and without using the proprietary hardware and/or firmware. This method also allows the IP packets to be

processed at the application layer instead of the neUvork layer, which achieves easy generation of the IP encapsulated packets.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be discussed in greater detail with reference to the accompanying Figures.
FIG. 1 shows a protocol stack at a DVB-RCS hub for user traffic with a SIT, in accordance with an exemplary embodiment of the present invention.
FIG, 2 shows a protocol stack at the SIT for user traffic with the DVB-RCS hub, in accordance with an exemplary embodiment of the present invention.
FIG. 3 illustrates a basic setup used to demonstrate an IP Packet Processing Module, in accordance with an exemplary embodiment of the present invention.
FIG. 4 shows a flow chart of a method for processing IP packets at the DVB-RCS hub using a muhithreaded implementation, in accordance with an exemplary embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Referring to FIG. 1, a protocol stack at a DVB-RCS hub for user traffic with a SIT is illustrated in accordance with an exemplary embodiment of the present invention. The method as shown in FIG. 4, can utilize the typical DVB-RCS protocol stack for easy IP packet processing at the hub using a single PC with standard Linux operating system. In the proposed method, the IP packets

can be sent in a forward link B of a DVB-RCS network and obtained at the application layer using standard IP tables and IP queue's implemented in the Linux Operating System with kernel version 2.6.15. The IP tables can be configured to support user datagram protocol (UDP), transmission control protocol (TCP) and Internet control message protocol (ICMP) by the DVB-RCS network. These IP tables can also be configured to support multicast UDP protocol.
In addition, the method can be authenticated using the SIT protocol stack for user traffic with the DVB-RCS hub as shown in FIG. 2. The method currently shows the IP packet processing for the IP packets exchanging between the DVB-RCS hub and one SIT with both return and forward links A and B. This method can also be extended to exchange the IP packets between two different SITs. In the proposed method, it is assumed that the SIT is operating in MPEG option mode, which uses IP-MPE as per the ETSI/EN 301790 standard. Similarly, the SIT can also be operated in an As>Tichronous Transfer Mode (ATM) option, which uses ATM Adaptation Layer 5 (AAL5) as per the ETSI/EN 301790 standard.
Referring to FIG. 3, a basic setup used to demonstrate an IP Packet Processing Module is illustrated in accordance with an exemplary embodiment of the present invention. The IP Packet Processing Module consists of two gateways G connected back to back with two servers B and C representing the DVB-RCS hub H and SIT S, respectively. The DVB-RCS hub H and SIT S can exhibit its own local area network (LAN) with respective IP network addresses. Each server B and C can be provided with Ethernet cards to act as gateways G. These gateways G can be physically connected through Ethernet device (ethO) EG on back to back instead of using air interface as the medium.

Furthermore, the IP Packet Processing Module can utilize three different IP networks, which is most commonly seen in any DVB-RCS network, where the three different IP networks are the local LAN on Ethernet device (ethl) El of the server B and the server C and the back-to-back connected Ethernet device ethO EO of both the servers B and C, respectively. In the actual DVB~ RCS network, the third IP network is the actual air interface of the network between the DVB-RCS hub H and the SITs S. In this method, the Ethernet Hnk can be utilized instead of the satellite link. Desktop terminals A and D can be attached and/or connected to the DVB-RCS hub H and the SIT S, respectively.
The IP packet processing software can reside on the servers B and C, and utilize the IP-MPE for encapsulation and de-capsulaiion of the IP packets. In the case of AAL5 support, the IP encapsulation can be implemented into the AAL5 at the server C and the IP de-capsulation can be implemented from the AAL5 at the server B. The desktop terminals A and D are set with default gateway address corresponding to the IP addresses binding to the Ethernet devices El of the servers B and C, respectively. The default gateway of the ser\'ers B and C are set with the IP addresses corresponding to the Ethernet devices EO of the desktop terminals C and B, respectively. For example, the below-mentioned table shows the IP addressing scheme along with the default gateways.

Terminal Ethernet Interface IP Address Defauh Gateway
A EO 192.170.1.102/24 192.170.1.101
B El 192.170.1.101/24 172.16,2,2

EO 172.16.2.1/24

C EO 172.16,2.2/24 172.16.2.1

E! 192.170.2.101/24

D
) EO 192.170.2.102/24 192,170.2.!01

Moreover, an IP forwaiding mechanism can be enabled in the servers B and C by setting the /proc/sys/net/ipv4/ip forward to 1. This can also be set in /etc/sysctl,conf file for setting this parameter permanently by inserting the following command line into the file, i.e. echo ] > /proc/sys/net/ipv4/ip forward. The 'super user' of the overall system can make all these changes. Additionally. Netfilter is a Linux kerne! framework for mangling the IP packets, and certain hooks are defined for each network IP protocol. These hooks can correspond to well-defined places in the protocol stack and allow custom packet mangling code to be inserted in form of kernel modules, as illustrated in FIGS. 1-3.
Each IP packet arriving at the hooks can be delivered to the code segments that are registered on the hooks, which allows the IP packets to be altered, dropped or re-routed by the custom code segments. When the IP packets are processed, a verdict should be returned to the Netfilter. This verdict instructs Netfilter to perform some packet-related action, e.g. to drop the IP packets or to let it continue hs traversal through the protocol stack.
Such Netfilter also offers the abilit>- to process the IP packets in user-space. The IP packets can be queued in kernel space and information about the IP packets can be sent to user-space over a Netlink socket by remming a special queue verdict. The IP packets remain queued until the user-space application, at the other end of the Netlink socket returns verdicts indicating the desired actions, i.e. ACCEPT or DROP, for the IP packets. These packets can also be modified in the user-space prior to re-injection back into the kernel. Finally, the Netfilter approach allows the implementation to stay independent of kernel modifications.
Therefore, the IP packets corresponding to the IP network destined for the terminals A and D in the other IP network at the application layer can be

retrieved using IPTABLES and Iibipq without modifying the kernel code. The IPTABLES is a tool that talks to the kernel and tells it which packets to be filtered. This tool can queue the IP packets based on the rules set to the user-space. The IPTABLES supports 3 type of chains and/or queues such as INPUT, FORWARD and OUTPUT. Here, the chain "FORWARD' supported by the IPTABLES is used. The IPTABLES are set with the commands for packet filtering of the TCP, UDP and ICMP protocols.
Some of the sample IPTABLES rules for TCP/UDP.1CMP are iptables -A FORWARD -p tcp -j QUEUE, iptabtes -A FORWARD -p udp -j QUEUE and iptables -A FORWARD -p icmp -j QUEUE. These settings can allow the IP packets of TCP, UDP and ICMP destined to other network to be queued to the user-space. The IP packets of all the types can be received in the application layer by using IPQUEUES, known as iibipq'. The libipq is a development library for user-space packet queuing of the IPTABLES, For each supported protocol, a kernel module called a queue handler can be registered with the Netfilter to perform mechanics of passing the IP packets to and trom the user-space.
Initially, the IP packets can be retrieved using the de-capsulation of IP-MPE for sending the IP packets received from the other side in the IP-MPE format. Then, the IP packets can be pumped into the network using the raw socket if the particular IP packets are destined for the local LAN on the HUB side H. This method can also be extended to support forwarding of the IP packets destined for the other SIT LAN's based on the destination IP address. These IP packets can be encapsulated based on the IP-MPE and forwarded to the forward link Transport Stream (TS) generation.
Referring to FIG. 4, a flow chart of a method for processing IP packets at the DVB-RCS hub using a multithreaded implementation is illustrated, in

accordance with an exemplary embodiment of the present invention. Such multithreading M is implemented to make the IP packet processing faster. The data between various threads is processed using the message queues. The appropriate IPTABLES and route command should be used for supporting multicast, in particular the IPTABLES can be initialized by setting up proper rules. In addition, the sockets, Pihreads and message queues can also be initialized to create a set of threads A, B and C.
During multithreading implementation, in thread A, the queued packets are read and passed to the thread B through the message queues. In thread B, the IP packets sent by the thread A can be received from the message queues. Then, the IP packets are encapsulated into MPE, and the encapsulated IP packets are sent to a distant network of a distant machine D. In thread C, MPE packets can be received from other networks through the sockets. Thereafter, the received MPE packets are either sent to the distant netw'ork of the distant machine D or de-capsulated into the IP packets. Finally, the IP packets can be pumped into a local network of a local machine L using raw socket.
For example, the IPTABLE rule, i.e. iptables -A INPUT -m pkttype - -pkt-type multicast -j QUEUE, is set in server B while performing the multicast from the terminal A to the terminal D. The mulicast packets can be forwarded only when the server B receives the mulicast packets transmitted by the terminal A. in order to receive the muhicast packets at the server B, the server B can join to the multicast group. At server C, no particular IPTABLE rules are required, since the transmission is one sided, i.e. nothing is sent back, but it requires the routing table entry such as route add -net 224.0.0.0 netmask 240.0.0.0 dev ethl. Then, the muhicast packets at the server C can be transmitted into the destination local network. This concept can be used in any network where the splitting of a connection is required at the gateways G.

WE CLAIM:
1. A method for processing a plurality' of Internet Protocol (IP) packets at a
Digital Video Broadcast - Return Channel via Satellite (DVB-RCS) hub,
comprising:
obtaining said plurality of IP packets at an application layer;
encapsulating said plurality' of IP packets in said application layer based on an IP over multiprotocol encapsulation (IP-MPE) standard;
forwarding said plurality of encapsulated IP packets to a forward link transport stream generator of said DVB-RCS hub; and
sending said plurality of encapsulated IP packets using a user datagram protocol (UDP) to a satellite interactive terminal (SIT), and thereby processing said plurality of IP packets at said DVB-RCS hub without using a standalone router and a proprietary hardware and/or firmware.
2. The method of claim !, further comprising:
de-capsulating said plurality of encapsulated IP packets received from said SIT in a return link;
routing said plurality of IP packets based on a destination address in an IP header of said plurality of IP packets:
pumping said plurality of IP packets into a local area neUvork (LAN) using a plurality of raw sockets with said IP header, if said destination address of said plurality of IP packets is for said local LAN; and
encapsulating and forwarding said plurality of IP packets to another SIT, if said destination address of said pluralit>- of IP packets is for a LAN connected to other SIT.
3. The method of claim 1, wherein said application layer carries out a
routing decision of said plurality of IP packets.

4. The method of claim 1, wherein said pluraUty of IP packets is
encapsulated and de-capsulated using IP-MPE and AAL5.
5. The method of claim 1, wherein said plurality of IP packets is processed by multi-threading using a message queue to support and sustain a high data rate of IP packet processing at said DVB-RCS hub.
6. The meihod of claim I, wherein said plurality" of IP packets is obtained at said applications layer using a plurality of standard IP tables and a plurality of IP queues without modifying a kernel code.
7. The method of claim 1, wherein said plurality of standard IP tables and
said pluraUty of IP queues are implemented in a single PC with standard Linux
Operating system.
8. The method of claim 1. wherein said plurality of standard IP tables is
configured to support UDP, TCP, iCMP and multicast UDP.
9. The method of claim 1, wherein said SIT is operated in both MPEG
option mode and ATM option mode
to. A system comprising a processor configured to perform the method as claimed in the preceding claims.

Documents:

2739-CHE-2008 AMENDED CLAIMS 11-08-2014.pdf

2739-CHE-2008 EXAMINATION REPORT REPLY RECEIVED 11-08-2014.pdf

2739-CHE-2008 POWER OF ATTORNEY 11-08-2014.pdf

2739-che-2008 abstract.jpg

2739-che-2008 abstract.pdf

2739-che-2008 claims.pdf

2739-che-2008 correspondence-others.pdf

2739-che-2008 description (complete).pdf

2739-che-2008 drawings.pdf

2739-che-2008 form-1.pdf

2739-che-2008 form-3.pdf

2739-che-2008 form-8.pdf

« Previous Patent

Next Patent »

Patent Number

262894

Indian Patent Application Number

2739/CHE/2008

PG Journal Number

39/2014

Publication Date

26-Sep-2014

Grant Date

23-Sep-2014

Date of Filing

07-Nov-2008

Name of Patentee

INDIAN SPACE RESEARCH ORGANISATION

Applicant Address

ISRO HEADQUARTERS DEPARMENT OF SPACE ANTARIKSH BHAVAN NEW BELROAD BANGALORE 560094.

Inventors:

#	Inventor's Name	Inventor's Address
1	VISHAL AGARWAL	SPACE APPLICATIONS CENTRE, INDIAN SPACE RESEARCH ORGANISATION (ISRO), AMBAVADI VISTAR PO, JODHPUR TEKRA, AHMEDABAD 380 015
2	MOHANCHUR SARKAR	SPACE APPLICATIONS CENTRE, INDIAN SPACE RESEARCH ORGANISATION (ISRO), AMBAVADI VISTAR PO, JODHPUR TEKRA, AHMEDABAD 380 015
3	NAGAMALLI GOPALAKRISHNA VASANTHAKUMAR	SPACE APPLICATIONS CENTRE INDIAN SPACE RESEARCH ORGANISATION (ISRO)AMBAVADI VISTAR PO JODHPUR TEKRA AHMEDABAD 380 015.

PCT International Classification Number

H04B7/185

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA