PATENTSCOPE will be unavailable a few hours for maintenance reason on Tuesday 19.11.2019 at 4:00 PM CET
Search International and National Patent Collections
Some content of this application is unavailable at the moment.
If this situation persists, please contact us atFeedback&Contact
1. (WO2007004247) MULTI-PROTOCOL PROGRAMMABLE USER TERMINAL FOR TELECOMMUNICATION SATELLITE NETWORKS
Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

MULTI-PROTOCOL PROGRAMMABLE USER TERMINAL FOR
TELECOMMUNICATION SATELLITE NETWORKS

The invention consists in defining the architecture of a compact and low-cost multi-protocol User terminal, based upon HW already on the market, able to operate in the field of different types of satellite networks, called SaT.
STATE OF ART
Currently, the state of art in the field of satellite user terminals is constituted by the terminals in accordance with the DVB-RCS [3] standard and developed by several specialized manufacturers (such as, for example, EMS, Nera, Newtec, Viasat). The main purpose of these terminals is to guarantee the IP (Internet Protocol) connectivity made available through transparent satellites, and, in most cases, by using a Hub (topology of so-called star-like network).
The SaT platform allows obtaining the same connectivity scenario specifically for satellite systems based upon SKYPLEX technology, but also for transparent satellites, thanks to the possibility of properly programming the modulation section and the modular approach of the software (SW) architecture. Modular approach means that by activating or replacing the modules it is possible making compatible the use of the SaT terminal with several networks of satellite telecommunication.
SKYPLEX is a technology developed by Alenia Spazio with the contribution of the European Space Agency.
The SaT is able to expose several and alternative protocol stacks on the radio interface, so as to allow:
• the access to regenerative SKYPLEX transponders: in this case the protocol stack implements (at physical level) the relative channel coding and (at data link level) the "native" synchronization of SKYPLEX; at the control level it provides the implementation of the SIMS protocol (acronym for "Service Information Management Server") and the client part of the network control system (the so-called NCS, acronym for Network Control System), which manages the allocation of the network resources

• the access to transparent satellites: in this case the modulation section implements the DVB-S [5] coding whereas the SW modules are enabled for the generation of the SI/PSI tables; in case of networks in accordance to the DVB-RCS standard, the relative coding can be implemented (with the options chosen for the considered network)
DESCRIPTION OF THE INVENTION
The SaT architecture for the SkyplexNet network is a HW and SW platform which can be configured for:
• Providing IP connectivity in "Full Meshed" networks (with meshed connectivity) by exploiting the on board multiplexing features provided by the SKYPLEX technology

• Providing IP connectivity in DVB-RCS networks in case of satellite networks based upon transparent satellites
• Controlling the terminal through the MMI graphic interface (in "manual" mode by an operator)
• Allowing to control the allocation of the transmission resources from the remote Network Control System - NCS located by the SkyplexNet Network Operation Centre (NOC) through the client or agent of the NCS system.
• Allowing the optional reception of digital TV channels
Alenia Spazio has been the promoter of this approach and active part in the implementation thereof by generating the requirements for the whole development both of the SaT platform and of the satellite Modem Board.
The produced requirements cover the functional, performing and implementing aspects of the SaT platform.
Therefore it is an object of the invention a multi-protocol Satellite User Terminal able to support dynamic one-way/two-way connectivity in a topology of meshed networks which utilizes the SKYPLEX technology on satellite; preferably which guarantees the conformity to the "native" synchronization of the SKYPLEX unit; more preferably the transmission on satellite channel is in accordance to: (i) single-channel-per-carrier (SCPC) mode, (ii) time-division-multiple-access (TDMA) mode; (iii) extensions to other access modes (for example MF-TDMA) which can be supported after specific requests by the user (in case by integrating additional specific PCI boards which can be inserted into the slots of the SaT terminal itself); (iv) the SEVIS management protocol client.
The multi-protocol Satellite User Terminal may have a driver of the satellite modem board, inserted into a slot of the terminal itself, to support the transmission with Reed-Solomon (DVB-S compatible) or Turbo (DVB-RCS compatible) coding.

In a particular embodiment The multi-protocol Satellite User Terminal is able to support oneway and two-way IP connectivity in the following cases:
• Satellite networks in accordance to the standard for coding DVB-S channel with transparent transponders;
• Satellite networks making use of SKYPLEX radio interface on the return channel.
In a particular embodiment the multi-protocol Satellite User Terminal has an apparatus control and a management comprising:
• a manual operating mode through a local/remote man-machine interface for operator based upon Web;
• a control and monitoring remote interface based upon SNMP V2 protocol able to support the trap generation towards a centralized Network Management System (NMS);
• a both local and remote interface for manual intervention of an operator by means of a prompt in a Linux shell;
• a remote interface based upon the Connection Control Protocol (CCP) for supporting an operating mode controlled by the Network Control System (NCS) as part of the

SkyplexNet Network Operation Centre (NOC); it intervenes thanks to the support in the terminal of a NCS Agent able to support connections both Activated by NOC and Activated by the Terminal itself (with negotiation/management of the Service Quality and resource management);
• a remote interface for the dynamic management of the Service Information of DVB- S/MPEG-TS by means of the protocol towards a SIMS server, able to register/enable entire intervals of logical resources such as PIDs, SEDs, Programme, Service and Provider names in the transmission Transport Stream from the terminal itself;
• a remote interface for supporting a protocol of Medium Access Control (MAC) layer for the dynamic management of outband capability requests.
In a particular aspect a FPGA remote updating of the satellite modem board is supported in order to guarantee to maintain and to enable additional options and functions for accessing the physical channel.
In a further embodiment the apparatus itself can be updated remotely at the different inner kernel, firmware, database levels in order to guarantee to maintain and to enable additional options and functionalities upon request.
In a further embodiment the reception and the search for television services can be optionally enabled starting from the decoding of PES Audio/Video packages natives of MPEG-TS.

In a further embodiment a functionality of Operation and Maintenance for supporting the monitoring, configuration and base control of the terminal unit via satellite can be optionally enabled.
In a further embodiment the multi-protocol satellite User Terminal has a related modular architecture composed by.
• a driver of a "SATPHY" satellite modem for; (i) accessing the services of the board for accessing the channel setup, (ii) managing the transport stream cell (TSC) sequences to be sent to the modem section, (iii) performing the channel acquisition, (iv) properly formatting the burst sequences of TSC cells;
• a de-multiplexing driver of MPEG-TS cells;
• a DVB/DP receiving router with de-multiplexing function of Multi Protocol Encapsulation (MPE) sections;
• a software module of Return Channel System for (i) encapsulating IP packages in the MPEG-TS format based upon the MPE standard, (ii) implementing the client of SIMS protocol for the dynamic management of Service Information, (iii) managing the channel synchronization procedures, the steady state keeping with the support of the protocol of SKYPLEX "native" synchronization and of schemes at Superframe level, (iv) implementing the client of CCP protocol of layer three for exchanging and managing the signalling with the central System NCS, (v) performing the MAC scheduling, (vi) extracting from the MPEG-TS demux the signalling private sections, (vii) performing the advanced functionalities of IP interworking with respect to the layers of higher level, (viii) supporting the terminal Monitoring and controlling main interface by means of a SNMP sub-agent.

DESCRIPTION OF THE SAT SYSTEM
Fig.l shows the evolutive approach from STB-x to SaT
Fig.2 shows a typical scenario supported by SaT
Fig.3 shows the SaT-IDU Protocol Stack
Fig.4 shows the partitioning of SaT SW components
Fig.5 shows the SaT architecture
Fig.6 shows the whole SaT system
Fig.7 shows an example of SaT terminal MMI menu The SaT is an advanced platform for receiving DVB-S as far as the receiving section is concerned, since it offers advanced functionality's with respect to the common satellite LAN routers. The SaT offers also the access to the functionality of data and TV broadcasting supported by the SkyplexNet network or by other distribution networks.
Furthermore, it offers the possibility of accessing the TCP/IP (FTP, Web browsing, etc.) connectivity services.
As far as the transmitting section is concerned, the SaT manages the transmission of both unicast and multicast IP contents, accessing to the satellite resource both in SCPC and in TDMA. The SaT also implements the IP interworking, the Connection Control and the Traffic Management functions.
Figure 6 shows the sub-systems composing the whole SaT system.
The SaT system is composed by two main sections connected through a third interfacing section:
• OutDoor Unit - ODU, or SaT-ODU: which includes the RF apparatuses which implement the functions of physical layer at the radio interface; the ODU, in turn, is composed by:

- Block Up-Converter (BUC): which receives the signal in S band by the SaT-IDU, it converts it into Ku (or Ka) band and it amplifies it
- Low-Noise Block down-converter (LNB): it receives the TS in downlink, it moves it into L band, it amplifies it and it forwards it to the SaT-IDU
- Antenna structure, composed by reflector and supports
• In Door Unit - IDU, or SaT-IDU: which includes the SaT and in case an additional power supply for the SaT-ODU
• Inter-Facility Link (IFL): signal/power supply cables for the SaT-IDU - SaT-ODU connection.
SW interfaces of the SaT platform:
The SaT is equipped with SW interfaces towards the final user for the local and remote management of the terminal (for configuration, management, updating, etc.) and for the

Monitoring and Control (SaT status, statistics, maintenance, etc.).
The SW interfaces of SaT are enlisted hereinafter and accessible by means of authentication. - Web-based Man Machine Interface (MMI), that is accessible via web browser (for example, Internet Explorer)
- Command Line Interface (CLI), accessible by means of telnet connection or serial interface - Simple Network Management Protocol Interface (SNMP): the SaT has a SNMP agent which manages GET, SET messages and it sends TRAP to a SNMP manager; these procedures are performed on variables defined in a SaT MEB (Management Information Base) specified by Alenia Spazio
Man Machine Interface (MMI):
This interface is based upon HTTP protocol and it allows the SaT management by means of a common browser (for example, Internet Explorer).
The Web interface of the SaT allows of:
- Examining the terminal status and performing related modifications
- Remotely updating the SW and the Firmware of the machine
- Setting the information accessible via SNMP
- Examining the parameters of the receiving DVB-S interface
- Managing the parameters of Tuner and of Low Noise Block (LNB) of the receiving chain
- Collecting information on the operating status of the transmitting section and related statistics
- Accessing to the inner Database
- Re-starting the system
The Figure 7 shows an example of menu belonging to the MMI of SaT.
Typically, the menus are composed by
- Title bar
- BACK button to return back to the MMI tree
- APPLY button to make active a choice
- HELP button to access information related to the specific menu
- Area useful for selecting/choosing parameters and options
DETAILED DESCRIPTION OF THE INVENTION
Only STB-x-Receiver Satellite Terminal:
The HW and SW architecture of the only Set-Top-Box (STB-X)-receiver terminal is implemented to be flexible and at low cost. To this purpose the mother-board is based upon the pair of chips ST5514 and ST40 GXl by STMicroelectronics [2], already commonly used in the satellite TV receivers.

It is composed by a receiving section (RX Tuner) based upon the pair of chips MAXIM 2116 (the tuner) and the ST0299 (demodulation section and Forward Error Correction calculation); the STB-X has the following features:
- ST40GX1 32-bit RISC CPU with 180-MHz clock, Linux operating system
- STi5514 CPU with 120-MHz clock, OS20 operating system
- 64Mbytes DDR SDRAM
- Asynchronous flash with 16Mbytes
- 8-Mbyte SDRAM dedicated to ST5514
V90 modem on mother-board
- ETH 10/100 Mbps on mother-board
- 3 PCI slots
- 40-GB Hard Disk
The ST5514 implements the descrambling, the de-multiplexing of the MPEG flows and the filtering at PID level by receiving as input the MPEG2 Transport Stream (TS). The ST40GX1 (equipped with Linux operating system) implements the 2D-3D graphic and audio functions of the platform; furthermore, it implements the support to the TCP/IP protocol suite, the MPE (Multi Protocol Encapsulation) decapsulator and it manages the PCI bus.
The SaT transmit/receiving terminal (2 ways) has been conceived as evolution and extension of the STB-X by means of adding the transmission functionality. This is implemented by inserting a board, called SATPHY-board, in one of the inner slots of the STB-x (the concept is illustrated in Figure 1), which implements:
• HW functionality: functions of physical layer (layer 1) necessary to implement the satellite return channel; the SATPHY-board has been wholly developed at the factory of Alenia Spazio Milano [2]. This HW module implements: (i) the resources for storing the data (buffering) before the transmission; (ii) coding and scrambling of the MPEG2 cells;

(iii) modulation and up-conversion; (iv) sum of the signal and the 10MHz reference signal (for the outer section, Out Door Unit - ODU) and the power supply of the same ODU section; (v) the receiving section in accordance to the DVB-S standard: with demodulation, inner decoding, descrambling, outer decoding.
Architecture of the 2-way S aT Terminal :
The SW architecture of SaT aims at implementing a DVB gateway mainly oriented to the small business market, wherein it provides IP connectivity to PC, workstations and other terminals located in the LAN Ethernet network of an office.

Emphasis is also placed onto the optimization in the use of the processing resources so as to maximize the capability of the SaT terminal in managing the receiving and transmitting IP traffic.
Figure 2 shows the typical scenario supported by SaT.
The main task of SaT consists in:
- Receiving the IP data from the DVB-S interface and forwarding them on a Local Network (LAN) by means of Ethernet interface of 10/lOOMbps type
- Forwarding the IP data received on the Ethernet interface onto the satellite transmission interface based upon routing rules set on the terminal itself.
The second item is implemented by means of a specific package of SW modules, called Return Channel Satellite SW (RCS SW); the RCS SW provides to SaT the functionality's of layer 2 and 3 at user level, at control level and at management level (as the SATPHY-board provides the layer 1 functionality).
As a whole, the SW architecture of SaT allows the bidirectional routing of IP (multicast and unicast) packages, then the support of the applications based upon IP, such as http, Telnet, SNMP, both based upon TCP and based upon UDP. Furthermore it is studied to allow the SW development and the evolutional extension of functionality with the addition of further SW modules.
The SW architecture of SaT is based upon the stratified SW concept with particular distribution between the two previously described processors. Figure 3 shows this approach in the definition of the protocol stock.
Figure 4 shows the detail in the implementing choices adopted in the distribution and partitioning of the SW components between the 2 chips ST5514 and ST40GX1 of HW platform.
Figure 4 shows that ST5514 (or rather the real time OS20 operating system which runs on itself) is mainly dedicated to the management of satellite interfaces, the one receiving DVB-S and the one acquiring the SKYPLEX or DVB-RCS transmission; this for the possibility of scheduling the processes efficiently by means of the help of the performances guaranteed by a real time operating system such as the OS20.
The embedded Linux operating system on the ST40GX1 processor provides the processing resources for the other services of the SaT machine, by operating as "master" operating system.

As already introduced, specific SW modules are added aiming at utilizing the HW for the transmission towards the satellite:
- RCS SW, composed by several modules which run both in Kernel mode and in User mode on the ST40 SH4 processor. These modules implement the data link layer and routing layer functions in the SaT machine.
- The SATPHY-driver, the SW driver which controls and configures the SATPHY-board (the modulator board); it runs on the OS20 operating system with SW interface extended also to the ST40 co-processor.
- The SKYPLEX Acquisition Module: it runs in OS20 and it manages the synchronization procedures relating to the MAC (Medium Access Control) layer for the access to the transmission satellite channel. These procedures are different depending if the SaT operates with regenerative satellites (for example with the SKYPLEX unit) or with transparent satellites.
Figure 5 shows the detailed SaT architecture .
It is to be underlined that the illustrated architecture has been drawn in order to better utilize the available HW architecture, by talcing into account the constraints (above all in terms of processing capability) due to the use of commercial, low-cost HW.
This architecture allows:
• The access at physical level to a SKYPLEX transponder or to transparent transponders; this is possible by programming the FPGA mounted onto the SATPHY-board, specifically acting on the module (1) of Figure 5 to implement the proper channel coding.
• The relevant synchronization at data link level for accessing the SKYPLEX transponder or transparent transponders, by acting on the sections (2) and (3) of the SaT architecture (Figure 5)
• Programmable Medium Access Control (MAC) specifically implemented for the features of the satellite system wherein the SaT has to operate; this is implemented by acting on the section (4) of the SaT architecture (Figure 5)
• Proper signalling on the receiving (return channel) and transmitting (forward channel) channel with the aim of making the SaT behaviour in accordance to the features of the satellite system wherein the SaT has to operate; this is implemented by acting on the section (5) of the SaT architecture (Figure 5).

The subsequent sub-sections underline the main features of the SATPHY-driver and of the RCS SW, by considering the Synchronisation Acquisition Module as part of the SATPHY-driver.
SATPHY-driver module:
The implementation of the SATPHY-driver is divided in two parts; one running on the embedded Linux operating system on the ST40GX1 processor; the second part running on the OS20 operating system on the ST5514 processor.
The part operating on embedded Linux is responsible for the services and the interfaces for implementing the transmission on satellite channel and it provides support to the function of synchronization at data link level.
The part operating on OS20 is responsible for the management of the low- level access to the SATPHY-board for associating the above-mentioned services to registers or I/O (Input/Output) buffers.
At logical level, the following five SW components are detected:
1. D VB-CORE Kernel I/F: this interface offers to HW Abstraction Layer (H AL) the access to the SATPHY-board services; these services, in turn, are offered to the RCS SW with the aim of implementing:
a) The setting of the profile for accessing the channel in terms of:
- Symbol frequency on the transmission channel
- Encoding mode to be applied to the transmission channel
- Frame structure, etc.
b) The loading inside the SATPHY-board registers of the cell sequence to be sent, already formatted according to the profile for accessing the selected channel

2. I/O character driver I/F: interface for implementing applications in User mode in Linux 3. In band Signalling I/F: it manages with high priority the signalling to be transferred multiplied with the other MPEG cells of TS
4. Channel Acquisition Agent: it is the module which is responsible for managing the access to the physical channel preceding the start of the data transmission phase.
5. Multiplexer, Burst Formatting e /DZE Cell Filler: this module constantly provides MPEG cells to the SATPHY-board for the transmission.
As to the receiving section, the task of the SATPHY-driver is the distribution of the MPEG cells towards the User space Linux. To this purpose the Linux DVB-APIs (Application Programming Interface) have been adequately extended in order to support the filtering and the selection in "raw" mode, that is without processing (they are called ioctl ad-hoc to allow the direct extraction of MPEG cells from the TS).
RCS SW module:
From the SW point of view, the RCS SW represents the main difference between SaT and STB-x platform, by bringing the following additional main functionalities:
- Multi Protocol Encapsulation (MPE), to manage the encapsulation of IP packages in MPEG cells, by managing also the fragmentation thereof
- SIMS client and processing of the S17PSI tables: in order to manage the communication with the SIMS (SIMS is an earth member necessary to the systems operating with the SKYPLEX transponder to keep the coherence of the SI/PSI tables inside the whole network)
- Support to the synchronization management: in order to make possible the synchronization at data link level; in turn, it involves:
• The management of the "native" synchronization of SKYPLEX: construction of Interrogation (IR) packages, processing of the Telemetry (TM) packages sent in reply to the IR from the SKYPLEX unit
• Management of the Network Clock Reference (NCR) [3] for the synchronization at Frame and Superframe level
- Management of the control level (Call Control or Connection Control, CC), with the relevant functions of extracting the SI tables which transport the associated signalling: for activating, managing, releasing the connections through the exchange of signalling of layer 3 with the associated entities residing in the network control centre (NOC, [4]) The entity managing the CC in SaT supports the activation, the management, release of the following types of connections
• Point-to-point Mono-directional
• Point-to-point Bi-directional
• Point-to-multi-point Mono-directional
- Extraction and Re-assembling of IP packages: functionality which is responsible for the filtering of the IP packages sent to SaT; it implements the following functions:
• Reception from the MPEG demultiplexer (in the ST5514) of the sections containing IP data
• Extraction of the IP packages
• Re-assembling of the IP datagrams • Forwarding of the valid datagram to the upper SW layers
- MAC Scheduling [4]: management of the priorities among MPEG cells before the forwarding to the physical layer (for example, in order to manage the different priorities to be given to the MPEG cells which transport IP datagrams and those ones which transport signalling)
- Formatting the TS, in order to have a transmitting TS in accordance to the standard used on the radio interface from the satellite system wherein the SaT has to operate.
The SATPHY board:
As far as the transmission is concerned, the SATPHY board (modem) implements both the Reed-Solomon coding (in accordance to the DVB-S [5] standard) and the Turbo coding (in accordance to the DVB-RCS [3] standard); these 2 techniques can be configured as alternatives.
The coding and the scrambling related to the transmitting section are implemented in FPGA; in this way the SATPHY-board allows operating with Turbo or Reed-Solomon coding; with SCPC or TDMA access, with different frame lengths in case of TDMA access.
By means of proper programming, the SATPHY-board implements also the coding of DVB-S channel.
With respect to the receiving section, the SATPHY-board has its own receiving section, based upon the pair of chips MAXIM 2118 (tuner) and ST0499 (demodulator and decoder). Thanks to the ST0499 features, able to extract the downlink signal clock, the SATPHY-board can operate also with the transmission signal locked to the clock of the receiving signal

(synchronous operation).
Reference Documents
[1] D. Mignolo, G. Tomasicchio, R. Winkler: Ka-band Network Solutions with SkyplexNet-HB6, "VIII Ka Band Utilisation Conference", 25-27 September 2002,

Baveno/Stresa - Italy"
[2] F. Di Cola, G. Losquadro, G.Tomasicchio: Design of Satellite User Terminal for the SkyplexNet Satellite Network; 10th Ka and Broadband Communications Conference; 30 September 2004, Vicenza, Italy
[3] ETSI EN 301 790, Digital Video Broadcasting (DVB): 'Interaction channel for satellite distribution systems', ETSI DVB-RCS document vl.3.1, March 2003.
[4] G. Tomasicchio, L.Secondiani, F. Di Cola, P. Maurutschek, E. Micaloni: An Integrated Medium Access Control and Traffic Management Architecture for DVB- RCS SkyplexNet Satellite Systems; WPMC 2004, 12-15 September 2004, Abano Terme, Italy
[5] ETSI EN 300 421 Digital Video Broadcasting (DVB); 'Framing structure, channel coding and modulation for 11/12 GHz satellite services'