Bandwidth Manager and Multiplexer

Transcription

1 SIXTH FRAMEWORK PROGRAMME Integrated Multi-layer Optimization in broadband DVB-S.2 SAtellite Networks FP Deliverable D7-F Bandwidth Manager and Multiplexer Contractual Date of Delivery to the CEC M24 Actual Date of Delivery to the CEC Author(s) Participant(s) TGV and R&S. TGV and R&S. Workpackage, Task WP3 Task 3.3 Dissemination Level Nature Public Report / Prototype Version 1.0 Total number of pages 36 Page 1 of 36

2 Document Revision History Date Version Author/Editor/Contributor Version Description 12/20/ TGV and R&S Intermediate version 12/20/ TGV and R&S Final version Page 2 of 36

3 Executive Summary This document constitutes the final version of the seventh deliverable under WP3 entitled Final report on Bandwidth Manager and Multiplexer. The document is structured as follows: The first part Introduction describes the task 3.3 within the WP3. The second part deals with the DVB-S2 software Multiplexer, which is able to multiplex IP based and TV broadcasting services. It describes the output and synchronization which feeds the DVB-S.2 modulator. The third part deals with the Dynamic Bandwidth Management of IP-based services describing the IP Inputs traffic and signaling under the control of SRMS module. It includes an open control interface to enable the communication with the SRMS. Finally, the BWM GUI part describes the parameters of connection with the DVB-S2 multiplexer, how to define an ASI output, a PSI task, to add a IP input, to import DVB-RCS tables and global supervision. Page 3 of 36

4 Table of Contents DOCUMENT REVISION HISTORY... 2 EXECUTIVE SUMMARY INTRODUCTION DVB-S2 MULTIPLEXER AND BANDWIDTH MANAGER OVERVIEW INPUTS IP management IP traffic IP signaling DVB-RCS tables S2 table signaling Bitrates commands PCR management OUTPUTS Data format Synchronization with the DVB-S2 modulator PSI tables management DVB-RCS tables generation COMMUNICATION Control and Supervision Serialisation of the actions Management of socket errors Client / server communication mechanism BANDWIDTH MANAGER AND MULTIPLEXER INTERFACES WITHIN THE IMOSAN PROJECT BANDWIDTH MANAGER GUI CONNECTING TO THE MULTIPLEXER OUTPUT SETTING PSI SETTINGS CONFIGURE IP/MAC ASSOCIATION ADDING AN IP OR ETHERNET INPUT General Parameters IP Filter Advanced Parameters INT/RCS Parameters IMPORT DVB-RCS TABLES SUPERVISION REGISTRY CONFIGURATION CONCLUSION ABBREVIATIONS REFERENCES Page 4 of 36

5 1 Introduction This final report (D7F) describes the finalised Bandwidth Manager and Multiplexer system. It builds upon previous IMOSAN deliverables, namely D3[4], D6F[5], D7I, D13F[8] and D20[9]. It describes the Bandwidth Manager and the Multiplexer modules, their internal architecture and interfaces as well as communication protocols with Satellite Resource Manager System and DVB-S2 Modulator. 2 DVB-S2 Multiplexer and Bandwidth Manager 2.1 Overview The DVB-S2 Multiplexer (EMT) is a software/hardware module able to generate a fixed bit rate output transport stream, from existing digital and already compressed video services, whatever their incoming bit rate (CBR or VBR). Control/Supervision Input Services Source (DVB, IP) Multiplexer DVB MPEG-2 TS Figure 1. DVB-S2 overview The core of the DVB-S2 Multiplexer is a real-time transport packet multiplexer software that can process quickly many input streams and outputs a valid MPEG2-TS stream. The input transport streams ranges from IP datagrams, PSI tables, DVB-SI tables, IP packets The DVB-S2 Multiplexer relies on: A variable number of inputs: the limit is fixed by the output rate. Several kinds of input: IP, network (TCP,UDP), PSI tables (PAT, PMT, SDT, etc.) An independent and specific task bound to each one. A multiplexing kernel that generates one MPEG2 TS from the several inputs towards several outputs. ASI output (PassPro board), A communication task dedicated to configuration and supervision. Bit rate reduction with PID filtering, or service filtering,.. Page 5 of 36

6 Input PSI/SI Management DVB-RCS Tables Input DVB- RCS management PID / MODCOD Input PID/ MODCOD management Multiplexer Task TS Output 1 Management Task ASI Board IP frames IP Input Management Task Network Socket Client TS Input 4 Management Task Input PCR Management Figure 2. Available inputs and output in the DVB-S2 multiplexer The statistical multiplexer multiplexes both IP Traffic (stemming from the LAN and OAM to ST) and MPEG-2 TV program (stemming from the stream transcoder) to generate a fixed MPEG-2 Multi-Program Stream. The BWMM server manages Ethernet boards. In a 1U rack, the server has two 10/100 Base T Ethernet ports for administration and for incoming data. Each of these Ethernet ports is independent. The BWMM server manages all IP datagrams arriving on these network ports, even those datagrams that are not actually addressed to the gateway. The filtering mechanism is then responsible for selecting which IP datagrams are to be encapsulated. With those ports, the BWMM server can receive unicast and multicast datagrams independently. The ASI output is used to send the transport stream to the satellite modulator. An ASI board (Passpro) is integrated to the DVB-S2 multiplexer. The packets that belong to the same MODCOD are consecutively sent in burst to the DVB-S2 modulator. Page 6 of 36

7 2.2 Inputs IP management The following diagram describes the main tasks for the generation of IP datagrams into one PID : Ethernet Board Sub-Network PROG Y PID X Multiplexer Task 1 - Association to a network port 2 - Network burst absorption 3 - IP Filtering 4 - IP/MAC association 5 - Encapsulation 6 - Generation according to the rate definition Figure 3. Generation of IP datagrams into one PID Each IP input has an associated PID. The main options/actions are performed per PID. As each input is independent, each PID configuration is independent Independent network Different types of networks co-exist together and so the input ports are completely independent. Each PID in the server is linked to one network port and the only IP datagrams that can be encapsulated into the PID are those that come from this port. Each Ethernet port can also be independent according to the MAC/IP association. This enables different clients (i.e. different reception devices) to have the same range of IP addresses arriving on the different Ethernet ports (See the IP/MAC association chapter) Network burst absorption On an Ethernet network, the transmission of data is generally sent by burst, in unicast as well as in multicast mode. To avoid the loss of data during the reception of IP datagrams, the Multiplexer will manage two different Fifos for each PID: IP Fifo for the reception of the IP datagram, and TP Fifo for the transport packet after the encapsulation. The size of the Fifo will have no influence on the time taken for encapsulation. If the Fifo is empty, an IP datagram is immediately encapsulated and generated IP Filtering IP filtering feature will allow to select very precisely the needed IP datagram and enable simultaneous encapsulation of a particular IP frame into different protocols. This filtering is based on the IP source and the destination address. A basic filter is composed of an IP address and a sub-network mask. When an IP datagram arrives on a network port, it is submitted to each PID associated with that network port. The user will therefore have to define which IP datagrams are to be Page 7 of 36

8 encapsulated on each PID The BWM handles a very powerful filtering mechanism for this purpose. This feature selects the required IP datagram very precisely and enables the simultaneous encapsulation of a particular IP frame into different protocols. IP filtering can be divided into two IP filtering mechanisms: Basic filtering: filtering according to the sub-network, Advanced filtering: filtering according to advanced network information such as the network protocol IP/MAC association Due to the support for DVB-MPE, MAC addresses are required to identify the reception hardware. Each IP over MPEG-2 reception board, box or router has its own and unique MAC address. This feature implies that the Multiplexer will have a specific management of the MAC addresses. As a matter of fact, the destination MAC addresses are connected to the IP destination addresses. The BWMM Gateway offers 4 different ways of managing the destination MAC address: IP/MAC association table: the IP/MAC tables make a correlation between an IP destination address or group of addresses (subnet mask) and a MAC address. The gateway can manage one IP/MAC table per Ethernet port, which means that the same IP addresses can be managed twice on two different Ethernet ports i.e. for two different customers. IP Copy: if the address is a multicast one, please refer to the chapter Special case for IP multicast. Otherwise, the MAC address is a copy of the destination IP address with the two most significant bytes set at or or userdefined. Ethernet copy: the MAC address is the MAC destination address found in the Ethernet frame. Broadcast: the MAC address is set to the broadcast MAC address: FF-FF-FF-FF-FF-FF MPE and ULE encapsulator The different standards define many IP encapsulation mechanisms. For IMOSAN project, the Multiplexer handles simultaneously the following protocols: DVB Multi Protocol Encapsulation (DVB-MPE), DVB Ultra Lightweight Encapsulation (DVB-ULE). According to these protocol, the Multiplexer is able to offer all the possible standard options : LLC-SNAP or not, CRC or Checksum, 8 or 32 bit section transport alignment, The most used protocol is MPE because it is based on the MPEG 2 private section that allows a lower overhead and a definition of a MAC destination. The use of the DVB-MPE protocol means that a MAC address is required to identify the reception hardware. Since each end user is identified by a VP/VC couple, each VP/VC couple is associated with a MAC MPE address. ULE standards use smaller headers and so considerably reduce the used bandwidth. Page 8 of 36

9 The multiplexer offers two different implementations of these sections encapsulation to offer the maximum flexibility. These implementations are fully compliant with the different standard Multi Protocol Encapsulation In this protocol, one IP frame is encapsulated into one MPEG-2 section. The Opal gateway uses the data of this section to directly insert an IP frame Non-Optimized Method The following diagram gives the non-optimized section encapsulation method. In this mode there is at most one IP frame per transport packet. This non-optimized method is controlled by setting the Section Packing parameter to No (please refer to Advanced parameters in paragraph ). IP Datagram 1 < 171 Bytes 184 Bytes < IP Datagram 2 Section 1 Section 2 Stuffing Stuffing 184 Bytes pusi = 1 pusi = 1 pusi = 0 Figure 4. MPE non-optimized method Optimized Method An optimized mode exists and is represented in the following diagram. This optimized method consists in controlling the encapsulation by setting the Section Packing parameter to Yes. IP Datagram 1 < 171 Bytes 184 Bytes < IP Datagram 2 Section 1 Section 2 Section 1 Section 2 Section 2 Section 2 Section Bytes pusi = 1 pusi = 1 pusi = 1 Page 9 of 36

10 Figure 5. MPE Optimized method This implementation particularly minimizes the protocol overhead because no stuffing is added in the transport packet. This method is fully compliant with the DVB-SI DAT standard. Consequently, with this high level of optimization, the following situation can appear in one packet: Transport packet (188 bytes) Packet header End of section section header complete sections beginning of section The packet header contains a minimum of 4 bytes and the section header contains a minimum of 8 bytes. The Section Packing parameter is accessible from Advanced Parameters tab ULE Protocol In this protocol, one IP frame or one bridged Ethernet frame is encapsulated into one SNDU (Send Network Data Unit) SNDU (Send Network Data Unit) Format PDUs (IP packets and Bridged Ethernet frames) are encapsulated using ULE to form an SNDU. Each SNDU is sent as an MPEG-s Payload Unit. Page 10 of 36

11 SNDU (max : bytes) PDU SNDU header CRC (optional) Destination Address Field Type Field 1 Length (15 bits) Destination Address Present Field Length Field Figure 6. SNDU Encapsulation The Destination Address Present Field The most significant bit of the Length Field carries the value of the Destination Address Present Field, the D-bit. A value of 0 indicates the presence of the Destination Address Field. A value of 1 indicates that the Destination Address Field is not present. Length Field A 15-bit value that indicates the length, in bytes, of the SDNU counter from the bytes following the Type Field up to and including the CRC. Type Field The 16-bit Type field indicates the type of payload carried in a SNDU Ether Type Encapsulation In this kind of encapsulation, the payload of the Ethernet frame is encapsulated into one SNDU. Page 11 of 36

12 Ethernet Frame Mac source MAC destination Ether Type Payload Length Type Field Optional PDU SNDU Figure 7. SNDU format for an EtherType Payload Bridged Ethernet Encapsulation In this kind of encapsulation, the entire Ethernet frame is encapsulated into one SNDU. The bridged SNDU is of type 1. The payload includes the MAC source and Ether-Type field with the content of a bridged MAC frame. Ethernet Frame MAC source MAC Destination Ether Type Payload Length Type Field Optional PDU SNDU Figure 8. SNDU format for a Bridged Payload Generation The Multiplexer is able to generate specific tables for DVB-RCS required signaling tables (PAT, PMT, NIT, MMT and RMT). Page 12 of 36

13 Rate management The optimization of the bandwidth allocation is a major issue in the field of telecommunications. The multiplexer will adapt the rate for one PID according to the priority list. So it will possible to reallocate free bandwidth to the other services depending on their priorities needs or to give a preferential treatment to critical services IP traffic Transcoder The transcoder is responsible for multimedia content format transformation and adaptation. It receives compressed and uncompressed multimedia streams, and converts/compresses them into the format and bit rate required by the bandwidth management system. The transcoder outputs the resulting programs over an IP network interface towards the multiplexer. The latter could consider the stream as a classical IP input and encapsulates it into MPEG-2 transport packets. The protocol stack is as follow: Figure 9. MPEG-2 TS IP Input Transcoder protocol stack LAN For internet access and VoIp service, the protocol stack is as follow: TCP/IP Figure 10. IP LAN protocol stack IP signaling On the return link of the Gateway DVB-RCS, the output traffic from the RLSS is ATM cells. According to the IMOSAN architecture, an ATM to Ip interface is needed to convert ATM traffic to Ip traffic. The Ip traffic is routed according to a routed map table (each ST is assigned to a unique MAC address) into two traffics. The return traffic (OAM) Ip signalling for the ST which will feed the BWM and the user traffic (LAN traffic). For the development, an ATM Interphase board is used. Interphase company provides API interface working under Linux RedHat 8 operating system. This interface is based on an ATM OC-3 interface supporting multiple PVC configured with one PVC per Terminal. The ATM to IP interface are able to: Receive the ATM cells. The return link traffic protocol stack is compliant with IP in AAL5 over ATM, Page 13 of 36

14 Create multiple PVC configured with one VPI/VCI per terminal, Generate IP traffic for the OAM and the return traffics, Save or restore the configuration of the ATM to IP interface. IP AAL5 IEEE ATM OAM User Traffic 10/100 base T RLSS Router DVB-RCS tables Figure 11. ATM to IP interface protocol stack The DVB-RCS tables are provided by the RLSS via the SRMS module. A group of MPEG2 packets containing DVB-RCS tables composes the UDP packet of the Ethernet frame. Refer to deliverable D6F for more details. The protocol stack is as follow: UDP/IP MPEG-2 TS Figure 12. DVB-RCS tables input protocol stack S2 table signaling S2 Tables Signalling is sent on one Ethernet path by the SRMS. The UDP packet of the Ethernet frame is composed of a sequence of MODCOD and PID. Refer to deliverable D6F for more details. The protocol stack is as follow: UDP/IP Bitrates commands Figure 13. S2 table signaling input protocol stack Refer to deliverable D6F for more details. The protocol stack is as follow: UDP/IP Figure 14. Bitrate command input protocol stack Page 14 of 36

15 2.2.7 PCR management For the RCST synchronization, the NCR is distributed with a specific PID within the MPEG2- TS. The NCR distribution follows the PCR distribution mechanism as defined in ISO/IEC The PCR insertion TS packet is used for inserting the NCR value used for the return link synchronization. The multiplexer will be able to generate periodically a specific PID for NCR transport stream. 2.3 Outputs The ASI output is used to send the transport stream to the satellite modulator. The PCI board included in the BWMM is an ASI board called PassPro. The generator deals with packets of 204 bytes. The packets are generated by the application; Then they are send to the board. Regarding the communication with the DVB-S2 modulator, the ACM control information are added at the end of the packets. The 188-byte packets are followed by 3 bytes of ACM control information. The following sections describe the data format of the MPEG-2 transport stream (see also [7] IMOSAN deliverable D9F, section 2.2) Data format The transport stream is made of: MPEG-2 Transport Stream Packet header (4 bytes), MPEG-2 TS Packet payload (184 bytes), Extra bytes (16 bytes): o ACM control information (3 bytes), o fill bytes (13 bytes). Header(4) Payload (184) Extra bytes (16) Figure 15. Transport Stream data format Synchronization with the DVB-S2 modulator Two extra bytes from the 16 bytes are used for synchronization with the DVB-S2 modulator. 3 bytes (MODCOD) Extra bytes (16) 13 bytes (Stuffing) The 3 bytes ACM control information is composed of : Page 15 of 36

16 Byte 0 (compliant with [2]), Bit Comment 7 1: start a new BBFRAME (MSB) 6 Type field: FECFRAME SIZE 0: normal (64800 bits) 1: short (16200 bits) 5 Type field: Pilot Configuration 0: no pilots 1: pilots 4~0 MODCOD field: 0: no change from previous packet other: modulation value (1 to 31) refer to MODCOD coding Table 1. Table 1. MODCOD coding Byte 1 reserved for the future use; set to 0. Byte 2 set to 0 for useful packet; set to 1 for dummy packet and other reserved for future use. The multiplexer s mechanism consists of sending a sequence of BBFrame fifo. Each BBFrame fifo is fed by MPEG2-TS with the same modulation coding. The BBFrame fifo size depends on the FECFrame size and the modulation mode. To provide a constant output bit rate, stuffing with dummy packets are added between BBFrame fifo PSI tables management The BWMM gateway is fully compliant with MPEG-2 and DVB standards. It is a stand-alone platform and so manages all MPEG-2 and DVB tables. These tables are fully dynamic with regard to the services and components (PID) created by the user. The BWMM is able to generate one component per service. All kinds of service/component configurations are available. For example, the user might create two services with two components, one for Web services (Unicast) and the other for Push services (multicast). Page 16 of 36

17 The tables are specific and provided for all protocols. The following tables can all be managed in accordance with the user s requests: MPEG 2 tables PAT: number of programs (services) and therefore, the PID of each PMT. PMT: service component PID with the following descriptors: - stream identifier: gives the component tag, - data broadcast id: gives the broadcast id. DVB tables NIT: this table is found in a file stored on the Opal hard drive. SDT actual: the SDT references all the services with the following descriptors: - Service: gives the service type and name, - data broadcast: provides information about the option of encapsulation and the name of the component. TDT: gives the time. Ensures that all receivers have the same time. TOT: carries the UTC-time and date information and local time offset. The user can define the repetition rate of each table DVB-RCS tables generation IP/MAC Notification Table The INT (IP/MAC Notification Table) is a standard mechanism for carrying information about the location of IP/MAC streams within a DVB network (please refer to [3] for more information). The BWMM manages the local INT table: INT information relating to the generated transport stream. The referenced PID in the INT is defined by the user. Page 17 of 36

18 INT Table PID PID 5000 IP BWMM OPAL gateway PID 100 PID 5000 Zooming Output Stream The content of the INT table is fully dynamic, changing whenever services / PIDs are created, deleted or modified Multicast Map Table The MMT table (Multicast Map Table) is an RCS table. This table is a standard mechanism for carrying information about the location of multicast IP streams within a DVB network. The MMT table will be computed using filters defined in the encapsulator. This table could be built dynamically like the INT, or a static table file could be used RCS Map Table Additional information about the satellite interactive network is conveyed in the RMT table (RCS Map Table). This table, which has the same syntax as the NIT but is transmitted on a different PID, contains one or more linkage descriptors pointing to one or more Forward Link Signalling (FLS) services. Each linkage descriptor contains an interactive_network_id and a list of population_id, which are used by the RCST to select its appropriate FLS service. This table can be updated simply by copying a new RMT file. The RMT must be transmitted every 10 seconds Forward Link Signalling protocol stack The forward link signalling is compliant with the following protocol stack: Page 18 of 36

19 DVB mandatory signaling tables Standard DVB defined SI Tables SDT, TDT NIT MPEG-2 defined PSI Tables PAT, PMT DVB-RCS required signaling tables DVB-RCS defined SI Tables RMT, SCT, FCT, TCT, SPT, CMT, TBTP, MMT TIM SI sections PSI sections DVB-RCS "SI section" DVB-RCS "SI section" Private Section MPEG-2 Transport Stream 2.4 Communication Control and Supervision Figure 16. Protocol stack for forward signaling The communication task aims at managing and supervising the DVB-S2 Multiplexer (EMT). Any process intending for controlling or getting the DVB-S2 Multiplexer status has to connect to the communication socket server. This server always allows a connection. After a connection, a new server thread is started to wait for another possible connection and this thread is immediately waiting for the client commands (loop on reading). Thus an independent thread exists for each connection with a client. Server with no connection Server with one connection Thread socket server 1 Thread socket server 1 Thread socket server 2 wait connection One extern connection wait connection wait connection Loop on reading Figure 17. communication threads Page 19 of 36

20 The communication protocol is based on a client/server protocol. The DVB S2 Multiplexer acts as the server and is always waiting for a request. When a request arrives, it manages it and replies to the client with an acknowledge or an error message. The acknowledge message may contain data for some specific requests. By default, the port number to connect to the DVB S2 Multiplexer server is Client 1 Configurator / Supervisor request Ack or Error DVB S2 Multiplexer Port 4000 request Client 2 Data server, configuration part Ack or Error Figure 18. Client/Server communication Serialisation of the actions The communication task can manage and supervise all the DVB S2 multiplexer tasks. Each action/request made on the communication task is made in a sequential order. The communication task always waits for the end of an action/request made through the API before starting a new one Management of socket errors If the control socket breaks, the BWMM server disconnects and waits for a new connection. The client also disconnects and attempts reconnecting with a period to define Client / server communication mechanism The communication is always from the initiative of the client. The client sends a message and the DVB Multiplexer replies either with an acknowledgement message or an error message. For example, a client requiring the multiplexer state has to send the GET_MULTIPLEX_STATE message to the DVB Multiplexer that replies with a ACK_MULTIPLEX_STATE message containing all the multiplex information. 2.5 Bandwidth Manager and Multiplexer Interfaces within the IMOSAN project Page 20 of 36

21 The following diagram depicts the bandwidth manager and multiplexer interfaces within the IMOSAN project. Stream transcoder MPEG-2/IP BWMM S2 Modulator ASI controls UDP/IP SRMS IP Traffic control UDP/IP Ethernet LAN RLSS ATM IP Traffic ATM to IP Figure 19. Bandwidth Manager and DVB-S2 multiplexer interfaces The Bandwidth Manager interacts mainly with: The Satellite Resource Manager System, which provides DVB-RCS tables over Ip for the forward link signalling. The Satellite Resource Manager System, which sends request to modify PID bitrate and provides PID information status. The Ethernet LAN, which computes in real time the bandwidth management of the IP traffic. The ATM to IP system, which computes in real time the bandwidth management of the IP traffic (OAM traffic to the ST). The transcoder, which computes in real time the bandwidth management of the IP traffic (MPEG-2 over IP). The DVB-S2 Multiplexer interacts mainly with: The Bandwidth Manager, The Satellite Resource Manager System, which computes in real time the S2 Table signalling (association of Pids and modulation code) for synchronization with the DVB- S2 modulator. The DVB-S2 modulator, which encapsulates IP traffic into MPEG-TS packets of 204 bytes and broadcasts a CBR MPEG-2 TS over ASI. Page 21 of 36

22 3 Bandwidth Manager GUI The Bandwidth Manager GUI is based on Windows MFC technology and uses a proprietary protocol over TCP/IP for communication with the DVB-S2 multiplexer. In the IMOSAN project, it will be used to configure and supervise the multiplexer : o configure the multiplexer output rate, o configure the PSI task, o configure IP/MAC association, o add an IP input, o configure the DVB-RCS tables interface, o supervise already present inputs, o supervise multiplex, o set the automatic saving. 3.1 Connecting to the multiplexer Figure 20. Bandwidth manager GUI before connection to the multiplexer The button allows to connect the GUI to the DVB-S2 Multiplexer if the client and server are running in the same platform. In the other case, click on the button. Page 22 of 36

23 A dialog box appears giving a list of all servers connected to the local area network: Figure 21. Connect to a server GUI Select the computer on which you wish to manage the server. The following information is given for each server: Name of the computer where server is running, IP address and port number to communicate with server, Server version. 3.2 Output Setting Figure 22. Output Setting Page 23 of 36

24 Enter the parameters of the physical output: Name n: Name of the output. Add PassPro n: Indicates whether the output is to be added or not. To add a PassPro output set Yes in this field. Remove PassPro n: Indicates whether the output is to be removed or not. To add a PassPro output set Yes in this field. Small fifo n: - If No, the generation will use more memory in the board: the generation will take no more than 500 ms. If Yes, the generation will take approximately 50 ms. Mode n: Defines the ASI format. Packet size n: Generates a stream with transport packets with 204 bytes. 3.3 PSI Settings Before adding IP inputs, the server must have a PSI task in order to generate the PSI tables and have a valid MPEG2 stream as an output of the Opal gateway. This is done thanks to the PSI setting box. Select MPEG2 and DVB tables management such as PAT, PMT, NIT, SDT and TDT. Figure 23. PSI Settings Page 24 of 36

25 3.4 Configure IP/MAC association The user needs to select the global IP/MAC associations Table policy, one IP/Mac table for the entire gateway. Figure 24. IP/MAC association table policy The server handles entries arrays for each IP/MAC table to define the IP/MAC address associations for IP inputs. There are two ways to define these IP/MAC address associations. The first way is to use a file called AssociationIpMac.txt. This file must be placed in the same directory as the executed server.exe file. Here is an extract from an AssociationIpMac.txt file: IP address mask MAC address E2-24-7D C-4F A-6C E8-00-6A This file can be edited at any time and, when saved, is immediately applied by the server. The second way to modify the association table is to click on association table dialog box. to open the IP/Mac Page 25 of 36

26 Figure 25. Global IP/MAC table 3.5 Adding an IP or Ethernet Input Adding an input is equivalent to specifying a set of parameters relative to this input. This is done using a specific dialog box General Parameters The first tab gives access to the general parameters: Page 26 of 36

27 The first column specifies: Figure 26. General input parameters - The PSI parameters, - The kind of encapsulation, - A comment field. The second column brings together the internal parameters of the gateway: - The input adapter, - The input policy (static) and bitrate (the fixed rate reservation for the input), - The critical option IP Filter There are two kinds of IP filtering : Ipv4 and Ipv6. To define one of the two IP filtering, Encapsulated protocol for an input has to be selected Ipv4 The Ipv4 tab gives access to define the IP source and destination filters (address and Mask): Page 27 of 36

28 Ipv6 The Ipv6 tab gives access to define the IP source and destination filters (address and Mask): The Ipv6 address is composed of 128 bits. The format shows 8 blocks of 16 bits separated by a colon. Keyboard data rules are defined for the Ipv6 address as it is described bellow: Page 28 of 36

29 :: is equal to 0000:0000:0000:0000:0000:0000:0000:0000 1:: is equal to 0001:0000:0000:0000:0000:0000:0000:0000 1::2:3 is equal to 0001:0000:0000:0000:0000:0000:0002:0003 The mask value is within the range 0 to means that there is no filter and all the Ipv6 addresses are accepted. 128 means that only the Ipv6 address is filtered Advanced Parameters The fourth tab gives access to the advanced parameters: Figure 27. Advanced parameters The advanced options provide: - Additional parameters for PSI parameters, - More options for encapsulation, - More DVB-SI parameters if DVB is used, - SMPTE options, - More DVB H parameters, - Other internal parameters for the gateway. Page 29 of 36

30 3.5.4 INT/RCS Parameters The fifth tab gives access to the INT/RCS parameters: Figure 28. INT/RCS Parameters The advanced options provide an additional parameters for INT/RCS tables (INT and MMT)management. Page 30 of 36

31 3.6 Import DVB-RCS Tables This interface is dedicated to collect DVB-RCS table from RLSS. Figure 29. Import DVB-RCS Tables Settings Select the following parameters: Adapter: The interface to receive DVB-RCS tables IP streams. Rate: The maximum rate allocated for this IP input. Source filter: The IP address and mask of the provider. Destination filter: The IP address and mask of the receiver. State: set Start for running the input. Click on Apply button to add the DVB-RCS tables input. Page 31 of 36

32 3.7 Supervision It has been especially designed to configure and supervise the IP inputs in the DVB-S2 multiplexer. The main view is composed of 3 parts: the configuration window, the inputs list window and the global one. The current configuration represents the inputs, services and channels that are really and truly active on the server. The current configuration tree is composed of the following items: Root node Ethernet interface Service IP input The spy view from the Inputs list window displays a list of colored lines, each one representing an input. Each line is made up of fields showing a particular parameter of the input. It is possible to choose which fields are to be displayed. A statistics view displays a graph which illustrates the change with time of the rate of the gateway, and of the services, inputs or filters. Figure 30. IP inputs on the DVB-S2 multiplexer. Page 32 of 36

33 3.8 Registry Configuration The saving of an server configuration (inputs, outputs and multiplexer) can be configured from a client machine. Apply at OpenMux starting: indicates the configuration that is to be loaded when the server is started up. Select No if you want to start with an empty configuration. Save automatically: indicates that the user wants to save any changes that are made on the server to the selected configuration Figure 31. Configuration Settings When the Apply at Openmux starting checkbox is selected, the name of the configuration in the associated combo box will be loaded at start up of the DVB-S2 multiplexer. When the Save automatically checkbox is selected, all changes made by the user, will be saved in the configuration which name appears in the associated combo box. With the above parameters, all changes will be saved and restored when the DVB-S2 multiplexer is restarted. Page 33 of 36

34 4 Conclusion The D7F deliverable described the Bandwidth Manager and Multiplexer and communication interfaces with DVB-S2 modulator and SRMS. The Bandwidth Manager and Multiplexer along with the ATM to IP converter have been integrated to the IMOSAN Forward Link according to the work plan. Please refer to deliverables D13F and D20 for more details on integration and demonstration scenarios. For the next period according to the work plan, tests and trials will be performed to look at system under load. 5 Abbreviations ABBREVIATION AAL5 API ASI ATM BWM BWMM CBR CMT CNI DSM-CC DVB-S DVB-S2 DVB-RCS EMT FLM FCT FLSS GUI IETF INT IP LAN MAC MMT MPE MPEG-2 DESCRIPTION ATM Adaptation Layer Application Programming Interface Asynchronous Serial Interface Asynchronous Transfer Mode Bandwidth Manager Bandwidth Manager and Multiplexer Constant Bit Rate Correction Map Table Carrier to Noise plus Interference ratio Digital Storage Media Command and Control Digital Video Broadband by Satellite DVB Satellite transmission 2 nd generation Digital Video Broadband Return Channel for Satellite Encapsulateur and Multiplexer Forward Link Manager Frame Composition Table Forward Link Sub-System General User Interface Internet Engineering Task Force IP/MAC Notification Table Internet Protocol Local Area Network Media Access Control Multicast Map Table Multi Protocol Encapsulation Motion / Moving Pictures Expert Group Page 34 of 36

35 NIT PAT PDU PID PMT RLSS SCT SDT SI SNDU SNIR SPT SRMS S2MOD ST TBTP TCP TCT TIM TS UDP ULE VBR VoIP VPI/VCI Network Information Table Program Association Table Protocol Data Unit Program Identifier Program Map Table Return Link Sub-System Superframe Composition Table Service Description Date System Information SubNetwork Data Unit Signal to Noise plus Interference ratio Satellite Position Table Satellite Resource Management System Modulator DVB-S2 Satellite Terminal Terminal Burst Time Plan Transmission Control Protocol Time slot Composition Table Terminal Information Message Transport Stream User Data Protocol Ultra Lightweight Encapsulation Variable Bit Rate Voice over IP Virtual Path Identifier / Virtual Channel Identifier Page 35 of 36

36 6 References Document Name Author Date [1] CPE WAN Management Protocol TR-069 DSL Forum May 2004 [2] EN broadcast Service ETSI [3] Digital Video Broadcasting (DVB). Specification for IP Notification in DVB Systems Use of the IP/MAC Notification Table. DVB 07/2002 [4] D3 SRMS definition and specifications TGV 06/30/2007 [5] D6F - Development of SRMS and communication among modules TGV 12/20/2007 [6] D7I Bandwidth manager and multiplexer TGV 12/20/2006 [7] D8F Services generation and adaptation OPT 12/20/2007 [8] D9F DVB-S2 Modulator with ACM features R&S 12/20/2007 [9] D13F Integration of systems and components CNES 30/10/2007 [10] D20 Planning of trials and demonstration scenarios DEM 30/06/2007 Page 36 of 36