Manual CLI

CLI MANUAL
Teleste Corporation
Luminato
SW RELEASE 9.4.X
1
2
1 INTRODUCTION 28
1.1 GENERAL 28
1.2 APPLICATION EXAMPLES 29
2 ABOUT THE CLI 31
2.1 OVERVIEW 31
2.2 CLI DOCUMENT CONVENTIONS 31
2.3 COMMAND MODES AND GROUPS 32
2.3.1 ENTERING AND EXITING COMMAND MODES 32
2.3.2 COMMAND GROUPS 33
2.4 CONTEXT SENSITIVE HELP AND COMMAND COMPLETION 34
2.4.1 TAB KEY 35
2.4.2 QUESTION MARK 36
2.5 CLI COMMAND-LINE EDITOR 37
2.6 ‘NO’ KEYWORD 38
2.7 KNOWN ISSUES 38
3 PREPARING FOR SYSTEM CONFIGURATION 39
4 SYSTEM ADMINISTRATION 40
4.1 OVERVIEW 40
4.2 RESERVED PORTS & ADDRESSES 40
4.3 PREPARATIONS 40
4.3.1 TFTP SERVER INSTALLATION 40
4.4 MANAGEMENT INTERFACE IP SETTINGS 41
3
4.4.1 OVERVIEW 41
4.4.1.1 IP address 41
4.4.1.2 Network mask 41
4.4.1.3 Hostname 42
4.4.1.4 Gateway 42
4.4.1.5 Static routing 42
4.4.1.6 DHCP 42
4.4.1.7 VLAN 43
4.4.1.8 TTL 43
4.4.2 CONFIGURATION 43
4.4.2.1 Management port operating mode 43
4.4.2.1.1 Separate MGMT networks in older chassis 43
4.4.2.2 Hostname 44
4.4.2.2.1 Assigning 44
4.4.2.2.2 Viewing 44
4.4.2.3 IP address, netmask & default gateway 44
4.4.2.4 Default gateway 45
4.4.2.5 Static route 45
4.4.2.5.1 Adding 45
4.4.2.5.2 Removing 46
4.4.2.6 Enabling/Disabling the management interfaces 46
4.4.2.7 Viewing the IP settings 47
4.4.3 NETWORKING UTILITIES 48
4.4.3.1 Ping 48
4.4.3.2 Traceroute 49
4
4.5 USING CUSTOM HTTPS CERTIFICATES 49
4.6 TIME AND DATE 50
4.6.1 VIEWING CURRENT TIME AND DATE 50
4.6.2 VIEWING TIME AND DATE SETTINGS 50
4.6.3 CONFIGURING 51
4.6.3.1 Selecting clock source type 51
4.6.3.2 Internal clock source 51
4.6.3.2.1 Time zone 52
4.6.3.2.2 Time 52
4.6.3.3 Custom daylight saving time 52
4.6.3.3.1 DST time period 53
4.6.3.3.2 DST offset 53
4.6.3.3.3 Enabling/disabling custom DST 53
4.6.3.4 External clock source 54
4.6.3.4.1 About the NTP 54
4.6.3.4.2 Adding NTP servers 54
4.6.3.4.3 Removing NTP servers 55
4.6.3.4.4 Monitoring NTP configuration 55
4.7 TERMINAL SETTINGS 55
4.7.1 CONFIGURATION MODE 55
4.7.2 SHOW SETTINGS 56
4.7.3 SCREEN LENGTH 56
4.7.4 SESSION TIMEOUT 57
4.7.5 COLOUR USAGE 57
4.8 USER MANAGEMENT 57
5
4.8.1 USER GROUPS 58
4.8.2 MANAGING LOCAL USER ACCOUNTS 58
4.8.2.1 Viewing all registered user accounts 58
4.8.2.2 User account creation 59
4.8.2.3 Changing password 59
4.8.2.3.1 Current user 59
4.8.2.3.2 Specific user 60
4.8.2.4 Removing a user account 60
4.8.3 LDAP REMOTE USER LOGIN AUTHENTICATION 60
4.8.3.1 Configuration 60
4.8.3.1.1 Connection 60
4.8.3.1.2 Search parameters 63
4.8.3.1.3 Testing user login 66
4.8.3.1.4 Viewing LDAP configuration 66
4.9 REBOOT COMMANDS 67
4.9.1 SYSTEM REBOOT 67
4.9.2 MODULE REBOOT 67
4.10 LOG SETTINGS 67
4.10.1 CONFIGURING EXTERNAL SYSLOG SERVERS 67
4.10.1.1 Adding 67
4.10.1.2 Removing 68
4.10.2 EVENT SEVERITY AND STORAGE LOCATION 68
4.11 SNMP SETTINGS 69
4.11.1 ABOUT SNMP 69
4.11.1.1 Transport protocol 69
6
4.11.1.2 SNMP entities 70
4.11.1.3 SNMP standards 70
4.11.1.4 Community name 70
4.11.1.5 Management Information Base 71
4.11.1.6 Structure of Management Information 71
4.11.2 LUMINATO MIBS 72
4.11.2.1 Downloading the MIB files 75
4.11.3 CONFIGURING THE SNMP SETTINGS 76
4.11.3.1 Location information 76
4.11.3.2 Contact information 77
4.11.3.3 Community string 77
4.11.3.4 SNMP trap generation mode 77
4.11.3.4.1 HMS trap generation 78
4.11.3.4.2 Extended trap generation 78
4.11.3.5 Extended trap severity settings 79
4.11.3.5.1 Adding a severity rule 79
4.11.3.5.2 Removing a trap severity 80
4.11.3.5.3 To display all configured severity rules: 80
4.11.3.5.4 Use example 81
4.11.3.6 Trap severity filters 82
4.11.3.7 Trap destination address 83
4.12 SOFTWARE UPDATE 83
4.12.1 PREREQUISITES 83
4.12.2 ENTITLED SOFTWARE RELEASES 83
4.12.3 VIEWING CURRENT SW VERSION 84
7
4.12.4 LOADING SOFTWARE IMAGE 84
4.12.5 SOFTWARE REVERSION 85
4.13 LICENSE MANAGEMENT 85
4.13.1 VIEWING LICENSES 85
4.13.1.1 Single module or chassis 85
4.13.1.2 All modules & chassis 86
4.13.2 ORDERING LICENSES 86
4.13.3 ENTERING LICENSE KEYS 86
4.14 CONFIGURATION MANAGEMENT 87
4.14.1 RUNNING CONFIGURATION 87
4.14.1.1 Viewing 88
4.14.1.1.1 Stored configuration files 88
4.14.1.1.2 Whole running configuration 89
4.14.1.1.3 Module running configuration 90
4.14.1.1.4 Interface running configuration 90
4.14.1.2 Removing configuration files 93
4.14.1.2.1 Based on Module type & slot location 93
4.14.1.2.2 Based on slot location 93
4.14.1.2.3 All configuration files 94
4.14.1.3 exporting the running configuration 94
4.14.1.4 Importing a running configuration file or a script file 95
4.14.2 CONFIGURATION BACKUP 96
4.14.3 RESTORING FACTORY DEFAULT SETTINGS 96
4.15 FILE MANAGEMENT 97
4.15.1 VIEWING USER FOLDER CONTENT 97
8
4.15.2 MANAGING 97
4.15.2.1 Uploading 98
4.15.2.2 Downloading 98
4.15.2.3 Deleting 99
4.16 MULTICHASSIS MANAGEMENT 99
4.16.1 OPERATING PRINCIPLES 99
4.16.2 CONFIGURING MULTICHASSIS MANAGEMENT GROUPS 100
4.16.2.1 Viewing the multichassis management group status 100
4.16.2.2 Creating and populating multichassis management groups 100
4.16.2.3 Removing management group members 101
4.16.2.4 Removing management groups 102
4.16.2.5 Defining multichassis payload port interconnections 102
4.16.2.6 Viewing payload connection group port assignments 102
4.16.2.7 Removing a payload connection group member 103
4.16.2.8 Deleting a payload connection group 103
4.17 SESSION ANNOUNCEMENT PROTOCOL SETTINGS 103
4.17.1 OVERVIEW 103
4.17.1.1 SAP 103
4.17.1.2 SDP 104
4.17.2 SAP AND SDP IN LUMINATO 104
4.17.3 CONFIGURING 104
4.17.3.1 Viewing the SAP settings 104
4.17.3.2 Group address 105
4.17.3.3 Announcement interval 105
4.17.3.4 SDP session description fields 106
9
4.17.3.4.1 Manual SDP fields – chassis level 107
4.17.3.4.2 Manual SDP fields – streamer level 107
4.17.3.5 Enabling/disabling chassis level session announcement 107
4.17.3.6 Enabling/disabling streamer level session announcement 108
4.17.3.7 Enabling/disabling session announcement reception 109
4.18 CONDITIONAL ACCESS PRELIMINARY CONFIGURATION 109
4.18.1 DVB-CSA BASED CONDITIONAL ACCESS SYSTEMS 110
4.18.1.1 SimulCrypt synchronizer 110
4.18.1.2 Control word 110
4.18.1.3 Entitlement Control Message 110
4.18.1.4 Entitlement Management Message 110
4.18.1.5 Supported modules 111
4.18.2 AES BASED CONDITIONAL ACCESS SYSTEMS 111
4.18.3 EMBEDDED LYNK DRM SERVER 112
4.18.3.1 License requirements 112
4.18.3.2 Hardware requirements 112
4.18.3.3 TV or STB system requirements 113
4.18.3.4 Configuring 113
4.18.3.4.1 Enabling & disabling the server 113
4.18.3.4.2 Online license activation 113
4.18.3.4.3 Offline license activation 114
4.18.3.4.4 License deactivation 114
4.18.3.4.5 Viewing server status 114
4.18.4 LUMINATO CAS INTEROPERABILITY 115
4.18.5 CA SYSTEM REQUIREMENTS 115
10
4.18.6 GENERAL CA SETTINGS 115
4.18.6.1 Scrambling presets 116
4.18.6.1.1 General 116
4.18.6.1.2 Configuring 116
4.18.6.1.3 Viewing the current component scrambling presets 116
4.18.6.1.4 Defining component scrambling presets 116
4.18.6.1.5 Applying the presets to all scrambled output services 117
4.18.6.2 CA descriptor’s PMT loop location 117
4.18.6.3 Extended crypto period 118
4.18.6.4 Scrambling algorithm 119
4.18.6.4.1 Overview 119
4.18.6.4.2 Chassis wide default 122
4.18.6.4.3 Module level default 123
4.18.7 ECM GENERATOR CONFIGURATION 123
4.18.7.1 CAS configuration mode 123
4.18.7.2 Creating an ECMG entry 123
4.18.7.3 ECMG profile parameters 124
4.18.7.3.1 ECMG configuration mode 124
4.18.7.3.2 Primary ECMG IP address and port number 124
4.18.7.3.3 Changing the primary ECMG port number 125
4.18.7.3.4 Secondary ECMG IP address and port 125
4.18.7.3.5 Changing the secondary ECMG port number 125
4.18.7.3.6 Super CAS ID 126
4.18.7.3.7 Channel ID 126
4.18.7.3.8 Crypto period 127
11
4.18.7.3.9 SimulCrypt protocol version 127
4.18.7.3.10 Scrambling algorithm 128
4.18.7.3.11 Enabling/disabling ECMG connection 128
4.18.7.3.12 ECM stream private bytes 129
4.18.7.4 Removing an ECMG entry 129
4.18.8 MONITORING AND TROUBLESHOOTING ECMGS 129
4.18.9 ADDING ECM STREAMS 131
4.18.9.1 ECMG configuration mode 131
4.18.9.2 Creating an ECM stream entry 131
4.18.9.3 ECM ID 132
4.18.9.4 Access criteria 132
4.18.9.5 Control word group 133
4.18.9.6 ECM stream private bytes 133
4.18.9.7 Enabling/disabling ECM streams 133
4.18.10 MONITORING ECM STREAMS 134
4.18.11 REMOVING AN ECM STREAM ENTRY 134
4.18.12 EMM GATEWAY CONFIGURATION 135
4.18.12.1 Creating an EMM gateway entry 135
4.18.12.1.1 TCP port 135
4.18.12.1.2 Channel ID 136
4.18.12.1.3 Removing a channel entry 136
4.18.12.2 Adding EMM streams 137
4.18.12.2.1 EMMG channel configuration mode 137
4.18.12.2.2 Creating an EMM stream entry 137
4.18.12.2.3 EMM stream private bytes 138
12
4.18.12.2.4 EMM stream bandwidth allocation 139
4.18.12.3 Removing an EMM stream entry 139
5 INTERFACE CONFIGURATION 141
5.1 PRODUCT AND HW IDENTIFICATION 141
5.1.1 LUMINATO INPUT MODULES: 142
5.1.2 LUMINATO OUTPUT MODULES: 144
5.1.3 LUMINATO PROCESSING MODULES: 144
5.2 COMMANDS COMMON TO ALL INTERFACES 145
5.2.1 INTERFACE INDEXING CONVENTIONS 145
5.2.2 ENTERING MODULE LEVEL CONFIGURATION MODE 145
5.2.3 ENTERING CONNECTOR LEVEL CONFIGURATION MODE 146
5.2.4 ENTERING STREAM LEVEL CONFIGURATION MODE 146
5.2.5 SI CHARACTER ENCODING 147
5.2.5.1 Default character SI character encoding 147
5.2.5.2 SI character set override 148
5.2.5.2.1 Chassis wide default SI character set override 148
5.2.6 PASSTHROUGH SERVICE TIMEOUT 149
5.2.6.1 Chassis wide default 149
5.2.7 COMMON COMMANDS IN INTERFACE CONFIGURATION MODE 149
5.2.7.1 Enabling and disabling input or output interfaces 149
5.2.7.2 Labelling interfaces 150
5.3 PAYLOAD PORT CONFIGURATION 150
5.3.1 PAYLOAD PORT SEPARATION MODE 151
5.3.2 SFP INTERFACE 151
5.3.2.1 Entering SFP level configuration mode 151
13
5.3.2.2 SFP interface operating mode 152
5.3.2.3 SFP interface speed 152
5.3.3 MODULE PAYLOAD IP ADDRESS 153
5.3.3.1 Reserved ports & addresses 153
5.3.3.2 IP address 153
5.3.3.3 UDP port 154
5.3.3.4 Virtual IP source addressing 154
5.3.3.4.1 Assigning a virtual source IP address 155
5.3.3.4.2 Removing an assigned virtual source IP address 155
5.3.3.5 Default gateway 155
5.3.3.6 Default transmission protocol 156
5.3.4 STATIC PAYLOAD PORT ROUTING 156
5.3.4.1 Creating a route 156
5.3.4.2 Removing a route 156
5.3.4.3 Viewing the payload routing tables 156
5.3.5 VIRTUAL LOCAL AREA NETWORK (VLAN) STREAMING INTERFACES 157
5.3.5.1 Adding VLAN streaming interfaces 157
5.3.5.2 Network mask 158
5.3.5.3 IP address allocation 159
5.3.5.4 Removing a VLAN entry 160
5.3.5.5 Adding a static route for VLAN interfaces 160
5.3.5.6 Removing a route 160
5.3.5.7 Viewing payload port VLAN configuration 160
5.3.5.8 Viewing VLAN payload interface IP address assignments 161
5.3.6 CBR STREAMING STRICT MODE 161
14
5.3.7 LINK-LEVEL FLOW CONTROL 162
5.4 INPUT INTERFACES 162
5.4.1 INPUT INTERFACE COMMON COMMANDS 162
5.4.1.1 Emphasizing missing input signals in status reports 162
5.4.1.2 Clearing PID statistical counters 163
5.4.1.3 Clearing RTP peak jitter counter 163
5.4.1.4 Input PSI/SI table capture 163
5.4.1.5 SDT descriptor forwarding 164
5.4.1.6 Shared TS reception 165
5.4.1.7 SI character set override 166
5.4.1.8 Warning timeout settings 166
5.4.1.8.1 Warning timeout for missing input signal or input service 166
5.4.1.8.2 Signal lost threshold 167
5.4.1.8.3 Warning timeout for missing input PIDs 168
5.4.1.9 Descrambling module setup 169
5.4.1.9.1 Compatibility and requirements 169
5.4.1.9.2 CA-module identification 170
5.4.1.9.3 CAM routing 172
5.4.1.9.4 CI clock setting for IP inputs 172
5.4.1.9.5 CAM failure action settings 173
5.4.1.9.6 Resetting a CAM manually 174
5.4.1.9.7 CAM failure actions with time-shared services 175
5.4.2 DVB-ASI RECEIVERS 175
5.4.2.1 DVB-ASI input interface configuration 176
5.4.2.1.1 Entering ASI input interface level configuration mode 176
15
5.4.3 SATELLITE RECEIVERS 177
5.4.3.1 DVB-S/S2 input interface configuration 178
5.4.3.1.1 Entering DVB-S or DVB-S2 input interface level configuration mode 178
5.4.3.1.2 Tuning frequency 179
5.4.3.1.3 Carrier frequency shift warning limit 179
5.4.3.1.4 LNB frequency 180
5.4.3.1.5 Symbol rate 180
5.4.3.1.6 Demodulation 181
5.4.3.1.7 DVB-S2 multiple input stream reception 182
5.4.3.1.8 LNB feed 182
5.4.3.1.9 DiSEqC 184
5.4.3.1.10 Spectrum inversion 189
5.4.4 TERRESTRIAL RECEIVERS 190
5.4.4.1 DVB-T/T2 input interface configuration 190
5.4.4.1.1 DVB-T receivers: LRT-A 190
5.4.4.1.2 DVB-T/T2 receivers: LRT-B and LRT-C 193
5.4.4.2 ISDB-T receivers: LRT-H and LRT-I 197
5.4.4.2.1 Entering ISDB-T input interface level configuration mode 197
5.4.4.2.2 DC feed 198
5.4.4.2.4 Channel bandwidth 198
5.4.4.2.5 Transmission mode & Guard interval 198
5.4.5 CABLE RECEIVERS 199
5.4.5.1 DVB-C receivers 199
5.4.5.1.1 Entering DVB-C input interface level configuration mode 199
16
5.4.6 MULTISTANDARD RECEIVERS LRM-A, LRM-B 200
5.4.6.1 Input standard 201
5.4.6.2 Entering multistandard receiver input interface level configuration mode 201
5.4.6.2.1 DVB-T2 202
5.4.6.2.2 DVB-S2X 204
5.4.6.2.3 DVB-C 205
5.4.6.2.4 ITU-T J.83 Annex B 206
5.4.6.2.5 ISDB-Tb 206
5.4.7 IP INPUT INTERFACES 207
5.4.7.1.1 IP stream broadcast type 207
5.4.7.2 Creating an IP input interface and entering configuration mode 208
5.4.7.2.1 In an output module 208
5.4.7.2.2 In an input module 208
5.4.7.3 configuring an IP input interface 208
5.4.7.3.1 Input stream destination IP address and UDP port 208
5.4.7.3.2 Payload interface 209
5.4.7.3.3 SSM source IP address 209
5.4.7.3.4 Disabling SSM source IP address 209
5.4.7.4 Removing an IP input interface 210
5.4.7.4.1 From an output module 210
5.4.7.4.2 From an input module 210
5.4.8 IP-TO-IP DESCRAMBLER 210
5.4.8.1 Configuration 210
5.5 OUTPUT INTERFACES 211
17
5.5.1 OUTPUT INTERFACE COMMON COMMANDS 211
5.5.1.1 Passthrough service timeout 211
5.5.1.2 Module default passthrough service timeout 211
5.5.1.3 Stream level Passthrough service timeout 211
5.5.2 LOW-LEVEL PID EXCLUSION 211
5.5.2.1 Adding a PID to the low-level exclusion list 211
5.5.2.2 Removing a PID from the low-level exclusion list 211
5.5.3 DVB-ASI OUTPUTS 212
5.5.3.1.1 Entering DVB-C input interface level configuration mode 212
5.5.3.1.2 Multiplex bandwidth 213
5.5.3.1.3 ASI output mode 213
5.5.4 QAM MODULATOR OUTPUTS 214
5.5.4.1 QAM output interface configuration 214
5.5.4.1.1 Entering connector level interface configuration mode 214
5.5.4.1.2 Entering modulator level configuration mode 219
5.5.5 DVB-T (COFDM) OUTPUT 220
5.5.5.1 DVB-T (COFDM) output interface configuration 221
5.5.5.1.1 COFDM Transmission mode 221
5.5.5.1.2 Entering connector level configuration mode 221
5.5.5.1.3 Entering modulator level configuration mode 224
5.5.6 ISDB-TB OUTPUT: LCM-I 225
5.5.6.1 Configuring 225
5.5.6.1.1 LCM-I specificity 226
5.6 IP OUTPUT INTERFACES 226
5.6.1 STREAM ROUTING STRATEGIES 226
18
5.6.1.1 SPTS IP streaming 226
5.6.1.2 MPTS IP steaming 226
5.6.1.3 Unicast vs multicast 227
5.6.1.4 Internal vs external streaming 227
5.6.2 CREATING AN IP STREAMER AND/OR ENTERING IP STREAMER CONFIGURATION MODE 228
5.6.2.1 Destination IP address & UDP port 228
5.6.2.2 Changing the destination IP address 228
5.6.2.3 Changing the destination UDP port 228
5.6.2.4 TTL 229
5.6.2.5 TS packet encapsulation count 229
5.6.2.6 IP transmission protocol 229
5.6.2.7 Bit rate mode 230
5.6.2.8 Payload interface 230
5.6.2.9 PCR jitter 231
5.6.2.9.1 What is the PCR and PCR jitter? 231
5.6.2.9.2 Countering PCR jitter due to Ethernet framing 231
5.6.3 REMOVING AN IP STEAMER 231
5.6.4 IP-TO-IP MULTIPLEXER 232
5.6.4.1 Enter IP output interface level configuration mode 232
5.6.4.2 Duplicating IP output streams 232
5.6.5 PRO:IDIOM™ IP-TO-IP SCRAMBLER 232
5.6.5.1 System requirements 233
5.6.5.2 About the Pro:Idiom™ content protection system 233
5.6.5.3 Enter IP output interface level configuration mode 233
5.6.5.3.1 Duplicating IP output streams 233
19
5.6.5.4 Enabling or disabling Pro:Idiom™ scrambling 233
5.6.5.5 Updating the system keys 234
5.6.5.6 System key renewal 234
5.6.5.7 Viewing Pro:Idiom™ key state 234
5.6.6 OUTPUT MULTIPLEX’ IP MIRRORING 235
5.6.6.1 Enter modulator level configuration mode 235
5.6.6.2 Primary IP mirror stream 235
5.6.6.2.1 Creating multiplex primary IP mirror stream 235
5.6.6.2.2 Changing primary IP mirror address 235
5.6.6.2.3 Changing primary IP mirror UDP port 235
5.6.6.2.4 Primary stream TTL 235
5.6.6.2.5 Primary stream TS packet count 236
5.6.6.2.6 Primary stream IP transmission protocol 236
5.6.6.2.7 Primary stream payload port 237
5.6.6.2.8 Primary stream bitrate mode 237
5.6.6.2.9 Removing a primary multiplex IP mirror stream 238
5.6.6.3 Secondary IP mirror stream 238
5.6.6.3.1 Duplicating primary IP mirror stream 238
5.6.6.3.2 Changing duplicate IP mirror address 238
5.6.6.3.3 Changing duplicate IP mirror UDP port 238
5.6.6.3.4 Duplicate stream TTL 238
5.6.6.3.5 Duplicate stream IP transmission protocol 238
5.6.6.3.6 Duplicate stream payload port 239
5.6.6.3.7 Removing a duplicated IP mirror stream 239
5.7 PRO-MPEG FEC ENCODER 239
20
5.7.1 OPERATION MODE 240
5.7.2 PRO-MPEG FEC ENCODER CONFIGURATION 241
5.7.2.1 Preliminary configuration procedures 241
5.7.2.2 General configuration guidelines 241
5.7.2.3 Default Pro-MPEG FEC encoding mode 244
5.7.2.4 Linking a media stream to an IP output 244
5.7.2.5 Stream level Pro-MPEG FEC encoding mode 244
5.7.3 EVALUATING PRO-MPEG FEC PERFORMANCE 244
5.7.3.1 Enabling packet error generation 244
5.7.3.2 Disabling packet error generation 245
5.7.3.3 Reviewing the packet error generation settings 245
5.8 PRO-MPEG FEC DECODER 245
5.8.1 OPERATION MODE 246
5.8.2 PRO-MPEG FEC PROTECTED STREAM DECODING CONFIGURATION 247
5.9 EPG PROCESSING MODULE 247
5.9.1 ABOUT EPG 247
5.9.2 FRONT PANEL OVERVIEW 247
5.9.4 SOFTWARE REQUIREMENTS 248
5.9.5 INSTALLATION PROCEDURE 249
5.9.6 CONFIGURATION PROCEDURES 249
5.9.6.1 EIT processing in multichassis environment 249
5.9.6.2 Entering EPG configuration mode 249
5.9.6.3 External EPG source configuration 250
5.9.6.3.1 External payload interface IP settings 250
21
5.9.6.3.2 Adding an external EPG source and entering external source level configuration mode 251
5.9.6.3.3 EPG information service mapping 257
5.9.6.3.4 Deleting an external EPG source 260
5.9.6.4 EIT IP streaming range settings 260
5.9.6.4.1 IP address range 260
5.9.6.4.2 UDP port range 261
5.9.6.5 EIT output profile configuration 261
5.9.6.5.1 Creating new profiles 261
5.9.6.6 Creating EIT outputs manually 266
5.9.6.6.1 Creating an EIT stream entry and entering stream configuration mode 266
5.9.6.6.2 Assigning EIT profiles to output multiplexes 267
5.10 APPLICATION MODULE 268
5.10.1 FRONT PANEL OVERVIEW 268
5.10.2 EXTERNAL INTERFACE SETTINGS 268
5.11 VIEWRIGHT™ BULK DESCRAMBLER LAB-A 269
5.11.1 SYSTEM REQUIREMENTS 269
5.11.3 INTERFACES 270
5.11.4 PREPARATIONS 270
5.11.5 RECOMMENDED CONFIGURATION WORKFLOW 270
5.11.6 UPDATING THE SOFTWARE 271
5.11.7 EXTERNAL INTERFACE SETTINGS 271
5.11.8 VCAS™ CSM SERVER CONNECTION 271
5.11.8.1 IP address 271
5.11.8.2 Port 271
22
5.11.9 AES CIPHER MODE SELECTION 272
6 SERVICE CONFIGURATION 273
6.1 OPERATING PRINCIPLES 273
6.1.1 IP CENTRICITY 273
6.1.2 TS PROCESSING MODE 273
6.1.2.1 Service mode 273
6.1.2.1.1 Selective forwarding 273
6.1.2.1.2 Promiscuous forwarding 274
6.2 COMMON COMMANDS IN SERVICE CONFIGURATION MODE 274
6.3 PID FILTERING 274
6.4 SERVICE MODE COMMANDS 275
6.5 SERVICE PASSTHROUGH 275
6.6 EMM PLAYOUT MODE 276
6.7 EMM MANUAL INCLUSION 276
6.7.1 CAS SOURCE REFERENCE 276
6.7.2 INPUT MPEG-TS REFERENCE 276
6.8 EMM PID 277
6.9 SERVICES CONFIGURATION 277
6.10 SERVICE CONFIGURATION MODE 277
6.10.1 OVERRIDING INPUT SERVICE TYPE CODE 278
6.10.1.1 Overview 278
6.10.2 DESCRAMBLING 278
6.10.2.1 Descrambling whole service 278
6.10.2.2 Disabling service descrambling 278
6.10.2.3 Component descrambling 279
23
6.10.3 SCRAMBLING 279
6.10.3.1 Associating ECM streams to scrambled services 279
6.11 PSI/SI TABLE INSERTION 282
6.11.1 TDT/TOT TABLE GENERATION 283
6.11.2 EIT PROCESSING COMMANDS 284
6.11.3 STATIC TABLE INSERTION 285
6.11.4 LANGUAGE CODE PRIORITIZED PMT COMPONENT ORDER 285
6.11.5 PSI/SI TABLE PROXYING 286
6.11.5.1 Enabling PSI/SI table proxying 286
7 DEVICE MONITORING 287
7.1 LOGGING INFO 287
7.2 CAS SYSTEM 288
7.3 ETHERNET INTERFACES 290
7.4 TS INTERFACES 290
7.5 INTERFACE MONITORING 293
7.6 PSU MONITORING 300
8 FAIL-SAFE REDUNDANCY FEATURES 302
8.1 RF/ASI INPUT & IP INPUT STREAM REDUNDANCY 302
8.1.1 INPUT REDUNDANCY APPLICATIONS 302
8.1.2 SYSTEM REQUIREMENTS 302
8.1.2.1 Hardware 303
8.1.2.2 Software 303
8.1.2.3 Licenses 303
24
8.1.3.1 Input monitoring 303
8.1.3.2 User configurable timeouts 303
8.1.3.3 Redundant input switch 304
8.1.4 RF AND ASI INPUT REDUNDANCY 304
8.1.4.1 Preliminary interface configuration 305
8.1.4.2 Assigning backup inputs to primary input 305
8.1.4.3 Redundancy triggers 305
8.1.4.4 Input switch triggering sensitivity 306
8.1.4.5 Automatic recovery timeout 307
8.1.4.5.1 Chassis level 307
8.1.4.5.2 Module level 307
8.1.4.5.3 Input level 307
8.1.4.6 Redundant input monitoring mode 308
8.1.4.7 Critical input and Critical service settings 308
8.1.5 IP INPUT REDUNDANCY 309
8.2 EMERGENCY NOTIFICATION STREAMING 309
8.3 1+1 BACKUP 310
8.3.1 1 + 1 BACKUP SYSTEM REQUIREMENTS 311
8.3.1.1 Hardware 311
8.3.1.2 Software 311
8.3.1.3 Licenses 311
8.3.1.4 CAS 311
8.3.2.1 Chassis roles in 1 + 1 backup systems 313
8.3.2.2 Handovers 313
25
8.3.2.2.1 Reasons for handover 313
8.3.2.3 1+1 backup and EIT processing modules 314
8.3.3 SETTING UP THE 1 + 1 BACKUP SYSTEM 314
8.3.3.1 The commands 315
8.3.3.1.1 Device role 315
8.3.3.1.2 Device pairing 315
8.3.3.1.3 Enabling/disabling backup control over IP 316
8.3.3.1.4 Synchronizing configurations 316
8.3.3.1.5 Aborting synchronization process 316
8.3.3.1.6 Manually activating the paired device 316
8.3.3.1.7 Recovering back from backup device to the main device 317
8.3.3.1.8 Viewing 1+1 backup status and configuration 317
8.3.3.2 1+1 Backup control over IP – Configuration procedure 317
8.3.4 RECOVERING BACK FROM THE BACKUP DEVICE TO THE MASTER DEVICE 322
8.3.5 RECONFIGURING THE ACTIVE 1+1 BACKUP SYSTEM 323
8.3.6 USING LUMINATO 1+1 BACKUP FOR SIGNAL REDUNDANCY 323
8.3.6.1 Configuring critical signal input 324
8.3.6.2 Signal lost criteria 324
8.3.6.2.1 Module level signal lost warning threshold 324
8.3.6.2.2 Interface level signal lost threshold override 324
8.3.6.2.3 Signal lost warning timeout 325
8.3.7 USING 1+1 BACKUP TOGETHER WITH THE STREAM REDUNDANCY FEATURE 325
9 EXTERNAL INPUTS AND OUTPUTS – EXT1 & EXT2 326
9.1 CONFIGURING EXT1 AND EXT2 PINS OPERATING MODE 326
9.2 BACKUP POWER ALARM 326
26
9.3 INTRUSION ALERT 327
9.4 USER DEFINED EXT I/O MODES 327
9.4.1 USER INPUT MODE 328
9.4.1.1 A use case example 328
9.4.2 USER OUTPUT MODE 329
9.4.2.1 A use case example 329
9.4.3 EMERGENCY SIGNAL TRIGGER 329
10 TECH SUPPORT FILE 330
27
1 INTRODUCTION
1.1 GENERAL
Luminato is a high density modular platform with advanced real-time stream processing for professional video head-ends.
The chassis accommodates up to six hot swappable and auto configurable modules, and a replaceable advanced power
supply module. Modules are internally switched for cable free interconnection and easy maintenance.
There are four fans, and two Gigabit Ethernet interfaces which can be equipped with SFP transceivers for IP payload traffic
purposes.
The module slots can be equipped with input modules receiving DVB-ASI/C/T/T2/S/S2 and IP streams, or output modules
transmitting ASI, QAM, COFDM and IP outputs, or with a processing module.
The platform is managed either locally or remotely via the embedded web user interface (web UI) and/or command line
rd
interface (CLI). It is also possible to integrate to 3 party management software via SNMP, CLI or XML.
System is designed for reliable 24/7 operation with low operating cost. For improved reliability, system supports several
redundancy features such as backup power supply, 1+1 HW backup, stream redundancy, several NTP server addresses and
spare Conditional Access System. Configuration management with configuration transfer tools, full configuration snapshot
and restore and reliable SW revert to previous SW with previous configuration ease up headend management.
FIGURE 1: SYSTEM BLOCK DIAGRAM.
28
1.2 APPLICATION EXAMPLES
The most basic Luminato application would be a “headend-in-a-box” where both service acquisition and service
multiplexing are done in a single chassis (Figure 2). This is a typical scenario in smaller hospitality networks (e.g. hotels and
hospitals).
FIGURE 2: HEADEND IN A BOX
An application requiring more advanced features would be a distributed and IP centric headend network, where a central
headend acquires services from various sources and creates multiplexes, transmitting them to several remote headends
through a backbone network (typically a layer 3 IP network) using multicast IP streams (Figure 3).
FIGURE 3: DISTRIBUTED HEADEND NETWORK
29
The Central Management Services are located in the central headend handling service acquisition and descrambling,
channel lineup and multiplex creation, content protection and IP streaming. Central headend chassis could contain for
example only receiving modules working as IP streamer and remote headend chassis only transmitting modules, working
as EdgeQAM. The video payload and management traffic may be e.g. separated using VLANs (Figure 4).
FIGURE 4: CENTRAL HEADEND DETAIL IN IP CENTRIC NETWORK
Remote headends could also include receivers for local service insertion of e.g. local DVB-T content (Figure 5).
FIGURE 5: LOCAL INSERTION OF SERVICES INTO REMOTE HEADEND.
30
2 ABOUT THE CLI
2.1 OVERVIEW
The Luminato’s Command-Line Interface (CLI) is the primary management interface available for the device users. It
enables users to configure, manage and monitor settings and status of the device. The CLI console can be accessed locally
via USB (universal serial bus) or via telnet or SSH (secure shell) through the Ethernet interfaces.
Luminato CLI is a straightforward command interface that follows the familiar syntax of many other communications
products. It provides a single line command editor with keyboard control sequences, command help, command
completion and a buffer for recently entered commands.
2.2 CLI DOCUMENT CONVENTIONS

The present document uses the following conventions to display the commands and the related syntax:
Convention Description
command line The whole command-line is displayed in black Consolas –font
on light blue background
boldface Text in boldface is a command or keyword that you must type in

literally as displayed.
italics Text in italics is an argument which value you must specify.
[a] Square brackets enclose an optional keyword or command
| Vertical lines are used to separate optional or required set of
commands or keywords; only one command or keyword might be
selected.
{a|b} Required choice. Braces enclose two or more entry choices
separated by vertical lines; one and only one choice must be
entered.
[a|b] Optional choice. Square brackets enclose two or more entry choices
separated by vertical lines.
Square brackets and braces might be nested. For example:
{a [b|c]} Square brackets and vertical line within braces indicates an optional choice within a required keyword or
command.
31
The examples use the following conventions:
screen
The examples use white Consolas font on black background for representing on-screen information
displayed by the command-line interpreter.
boldface
screen The examples use Consolas bold font on black background for representing text that you must literally
type in.
<…> Angle brackets enclose characters that are not displayed on the screen such as control characters (<cr> =
carriage return, passwords etc.)
2.3 COMMAND MODES AND GROUPS

Luminato CLI commands are grouped into different functional groups and modes. Modes are used to separate available
actions for user groups per functional groups. When any user logs in he/she is starting in root mode (non-configure mode).
The first set of commands is available to all users. Most of these commands are used to show system status.
The other modes (configure modes) are available only to users with privileged access. These commands can be used to
configure the system or to adjust system performance.
User group Role

Monitor Read-only access for status monitoring only
Oper Access for daily service operations
Install Access for system setup and installation
Admin Full control (excluding factory-specific settings)
Monitor –level users cannot enter to configure-modes at all and therefore cannot change configuration. Only show
commands are available.
Admin –level user has access to all commands listed in this manual.
To learn more about user groups and user management, see chapter
2.3.1 ENTERING AND EXITING COMMAND MODES
• When you log in to the CLI, you are in root mode.

o Prompt:
unnamed#
• To enter global configuration mode, type in configure from root mode.

o Prompt:
unnamed(configure)#
32
o To exit from global configuration mode and return to root mode, type in exit or end
• To enter interface configuration mode, type in an interface command (e.g. interface dvbs 1/1) from global
configuration mode.
o Prompt:
unnamed(iface-dvbs-input-1/1)#
o To return to global configuration mode type in exit

o To exit from interface configuration mode and return to root mode, type in end.
2.3.2 COMMAND GROUPS

The CLI commands are organized in several functional groups:
• Generic
• Administration
o Terminal - terminal settings for existing connection
o Reboot commands
o Logging configuration
o Time and date
o Network settings
o User management
o Licenses
o Tech support info generation
o SW update
o 1+1 backup configuration
o Configuration management
o File management
o Ext mode settings
o Environment - temperature, power, fans,lights, etc
• Interface and service configuration

o Chassis-wide settings
o Chassis-wide default settings
o CAS configuration
o Management interfaces
o Gigabit SFP interfaces
o Module interfaces
33
o Descrambling
o Input interfaces
o Output interfaces
o FEC codec
o Processing
o Redundancy
• Device monitoring - device operations, current status, alarms
Each group has show, configure and some other action-commands in common. show –commands are always available
if not stated otherwise (for example show user -command is available only to admin -users).
2.4 CONTEXT SENSITIVE HELP AND COMMAND COMPLETION

The Luminato features a context-sensitive and interactive help system:
To obtain a brief description of the help system, enter the following command:
help
To see a complete list of every possible commands in their full format, enter the following command:
list
To see a list of all commands containing a specific character string, enter the following command add the target character
string behind the command:
unnamed# list redundancy

show redundancy
configure redundancy role <standalone|master|backup|disabled>
configure redundancy pair address <<N.N.N.N>>
configure redundancy connection <off|manual-sync>
configure redundancy do handover
configure redundancy do recovery
configure no redundancy test-mode
unnamed#
34
2.4.1 TAB KEY
To automatically complete a partially-typed command, press the tab key:
unnamed# con<tab>
unnamed# configure
If the command-line interpreter is unable to uniquely identify a partially-typed command with the tab key function, it will
only complete the characters which are common to the multiple commands and display a list of all the commands starting
with the completed command fragment:
unnamed(configure)# co<tab>
configure copy
When no partial command has been typed in, the tab key will show a brief list of all commands available in the current
command mode. Pressing the tab key a second time will also reveal a short descriptive text for each available command in
the current command mode.
Example – pressing TAB the first time:
unnamed#<tab>
configure dir end erase
exit help list logout
passwd ping reboot show
traceroute
Example – pressing TAB a second time:
unnamed#<tab>
show Show various status information
configure Enter configuration mode
dir Show files in user folder
end Return to root mode
erase Remove file from user dir
help Display help for the CLI
list Print a list of available commands
35
passwd Change current user password
ping Ping destination address
reboot Reboot the whole device immediately
traceroute Trace the route of a remote host
exit Exit current mode
logout Logout from CLI
2.4.2 QUESTION MARK

Entering a question mark will provide a list of all the commands available in the current command mode along with their
respective description:
unnamed# ?<cr>
show Show various status information
dir Show files in user folder
end Return to root mode
erase Remove file from user dir
help Display help for the CLI
list Print a list of available commands
passwd Change current user password
ping Ping destination address
reboot Reboot the whole device immediately
traceroute Trace the route of a remote host
exit Exit current mode
logout Logout from CLI
36
When a question mark is appended to the end of a partially typed command, the command-line interpreter will list all the
commands that start with the current fragment:
unnamed# co?
co
When a question mark is entered after a command (the command must be separated from the question mark by a space),
the command-line interpreter will list all the commands that may immediately follow the currently typed command, on
the same line:
unnamed(configure)# interface input <?>
1-6/ Module slot number
2.5 CLI COMMAND-LINE EDITOR

In the CLI, you can use keyboard sequences to navigate and edit a command line. You can also use keyboard sequences to
scroll through a list of recently executed commands. The following table lists the line-editing keys that are available in the
CLI.
Table 6-1: CLI keystrokes
Keystroke Result
Backspace Deletes one character left of cursor
Delete Deletes the current character
Enter Executes command
Tab Completes command entry
Right arrow Move the cursor forward one character
Left arrow Move the cursor back one character
Up arrow Scrolls backward through all commands in the history buffer

starting from the most recent one. Repeat keystroke to recall
successively more recent commands.
Down arrow Scrolls forward through all commands in the history buffer after
recalling the commands using up arrow-key. Repeat keystroke to
recall successively more recent commands.
<CTRL> + A Moves the cursor to the beginning of the command line
<CTRL> + B Move the cursor back one character.
<CTRL> + C Aborts current line (aborts a command if running)
37
Keystroke Result
<CTRL> + D Deletes the character at the cursor
<CTRL> + E Move the cursor to the end of the command line

<CTRL> + F Move the cursor forward one character
<CTRL> + K Deletes all characters from cursor position to the end of command
line
<CTRL> + N Scrolls forward through the list of recently executed commands.
(Equivalent to the down arrow)
Note: you have to first scroll backwards using <CTRL> + P or up
arrow before using this command
<CTRL> + P Scrolls backward through all commands in the history buffer

starting from the most recent one. (Equivalent to the up arrow)
<CTRL> + T Transpose the character to the left of the cursor with the character
located at the cursor
<CTRL> + U Deletes all characters
<CTRL> + W Deletes the word right before the cursor
2.6 ‘NO’ KEYWORD

The no –form of a command is used to negate a specific function. Elements with one parameter supports the no –form
automatically. If the element has two or more parameters, you must specify for which parameter the no –keyword is
designated to.
It is important to specify this as it can have varying effects depending on the context, such as:
• disabling a feature
• disabling a particular option of the feature
• restoring default settings
• removing a single entry which was previously configured
2.7 KNOWN ISSUES
• Using copy/paste –method in order to setup large configuration may be unreliable depending on the terminal
software used. For transferring the whole configuration from another device, copy the running configuration file
using TFTP instead.
• Please take also into account the known issues documented in the current software release notes.
38
3 PREPARING FOR SYSTEM CONFIGURATION
Prior to the configuration process, it is assumed that Luminato has been removed from its delivery box, it installed it in a
rack, it has all needed interface modules (with possibly required Conditional Access modules in them) installed into its
module slots and also SFP modules installed into GE1 and/or GE2 slots, and all the relevant cables connected. It is also
assumed that the Luminato’s management interface has been configured and a management connection is established.
The Luminato chassis is delivered along with a USB Flash drive which contains all the necessary product manuals. Please
proceed with the manuals in the following order before proceeding forward to the next chapter:
1. ReleaseNotes_Luminato
2. Luminato_mechanicalinstallation
3. Luminato_powersupplymanual (if you ordered a PSU separately or if you intend using a backup
PSU)
Have the all the system level parameters (host name, IP address, signal frequencies etc.) ready in order to speed up the
configuration process. Also, note that Luminato has a feature based licensing mechanism, meaning some features require
a separate license key to unlock. Ensure you have acquired all the necessary licenses matching your application needs.
Typically, licenses are ordered together with the hardware, the desired features unlocked at factory. Licenses can be
ordered through your sales office.
39
4 SYSTEM ADMINISTRATION
4.1 OVERVIEW
This chapter introduces all commands related to administrative tasks such as logging server configuration, time and date
settings etc.
4.2 RESERVED PORTS & ADDRESSES

The following IP subnets are reserved by Luminato for internal communication (CIDR notation):
• 172.31.255.0/24
• 172.30.[1…23].0/24
• 172.30.[1…253].[1…23]/24
The following ports are reserved by Luminato for internal communication:
• 22
• 23
• 69
• 80
• 81
• 111
• 443
• 1200
• 1201
• 1202
• 2049
• 8061
• 8071
• 54300-54331
4.3 PREPARATIONS
4.3.1 TFTP SERVER INSTALLATION
The Luminato support two file transfer protocols: Trivial Transfer Protocol (TFTP) and Hypertext Transfer Protocol (HTTP).
The most used protocol is TFTP. In order to copy files to and from the device with TFTP, you will need a TFP server
application.
Download, install and configure a TFTP server application.
40
Hint: There are many TFTP free server application available on the Internet. Select one that supports transfers of over
20 MB in size and offers the best security features.
4.4 MANAGEMENT INTERFACE IP SETTINGS

This chapter first introduces some of the related IP technology and then the commands for configuring the IP settings of
the Luminato’s internal management interface.
4.4.1 OVERVIEW
This section serves as brief refresher about the IP technology.
If you are familiar with the technology, feel free to jump to the next chapter
“4.4.2”.
4.4.1.1 IP ADDRESS
The IP (Internet Protocol) address functions both as an identifier and a logical address of any network device. The IP
addresses of hosts or network interfaces are assigned either dynamically or statically; the management interface the
Luminato supports both assignment methods.
The IPv4 standard RFC 491 defines the IP address as a 32-bit integer. The most common notation is the so called quad-
dotted decimal notation, where the address is divided in four groups of 8-bits each converted in decimal notation and
separated by periods, e.g. 192.168.1.2.
Some blocks of the IP space are reserved for a specific purpose; the following address blocks are defined and reserved as
private address spaces for private networks (RFC 1918):
• 10.0.0.0 - 10.255.255.255
• 172.16.0.0 - 172.31.255.255
• 192.168.0.0 - 192.168.255.255
Private addresses are not routed on the Internet, however if necessary they can be routed to the Internet through
Network Address Translation (NAT).
Additionally, the following block is reserved for IP multicasting (RFC 1112):
• 224.0.0.0 - 239.255.255.255
NOTE! Parts of the multicasting space have a special meaning and are reserved for multicast routing group
maintenance protocols: e.g. 224.0.0.0 – 224.0.0.255.
4.4.1.2 N ETWORK MASK

The IP address of a host consists of two logical parts:
1. Network prefix: Designates the network address common to all hosts belonging to this specific network. This is
also sometimes referred to as the routing prefix.
2. Host identifier: A unique identifier assigned to a host within a given network.
41
The network mask is used to define which part of the IP address is the network prefix and host identifier. It consists of a
contiguous sequence of ‘1’s followed by ‘0’s. To extract the network prefix from an IP address, a bitwise AND operation
between the IP address and the network mask is performed.
Example:
Binary Dot-decimal
IP address 11000000.10101000.00000000.01100100 192.168.0.100
Network mask 11111111.11111111.11111111.00000000 255.255.255.0
Network prefix 11000000.10101000.00000000.00000000 192.168.0.0
4.4.1.3 H OSTNAME
Hostnames are human readable labels assigned to network hosts, which makes referring to a host easier than directly
using a host’s IP address. Translation of a hostname into an IP address and vice versa requires the usage of a DNS (Domain
Name System).
In the Luminato, the host name is shown as part of the command line prompt and included with the system log
information.
4.4.1.4 G ATEWAY
When a host needs to communicate to another host belonging to another network a gateway is required. Gateways are
router acting as access points from one network to another.
Whenever an IP datagram needs to be transferred from one host to another, the sender compares the network prefix of
its own IP address to the network prefix of the destination IP address. If a match occurs, no gateway is needed since both
hosts are in the same network; the datagram is delivered directly. On the other hand if a mismatch occurs, then the
sending host verifies its own IP routing table: if no route is found, the datagram is sent to the default gateway.
4.4.1.5 S TATIC ROUTING

Static routing is necessary when traffic should pass through a specific gateway other than the default gateway (e.g.
encrypted VPN tunnel) or when a less costly route is known and should be used. The network administrator specifies these
static routes manually into the host’s routing table.
A special use-case is host-specific routing where host to host static routes are specified to allow more control over
network access and use.
4.4.1.6 DHCP
DHCP (Dynamic Host Configuration Protocol, RFC 2131) is an Internet standard protocol developed for automatic host
configuration. It is client-server model protocol, where DHCP-configured clients (the hosts) request IP configuration
parameters (typically, IP address, lease time, subnet mask, and default gateway) from a DHCP server. The DHCP server
then replies with the queried parameters and allocates a free IP address from its IP address database. Once the lease time
expired, the host must renew its IP address or acquire a new one.
42
4.4.1.7 VLAN
VLANs are used to separate OSI Layer 2 traffic into discrete broadcast domains in order to reduce broadcast traffic and
improve security.
4.4.1.8 TTL
TTL (Time-To-Live) is a mechanism introduced in to the IP, to limit the lifespan of datagrams circulating on IP networks.
The TTL is an 8-bit field in the IP header of the datagram. Each time a datagram is forwarded by a router, its TTL value is
reduced by 1. Once the TTL value reaches zero, the datagram is discarded and an ICMP error message is sent to the
sending host.
4.4.2 CONFIGURATION
The Luminato features two management ports labelled MGMT1 MGMT2. In order to configure the management IP
settings, you must be logged in as administrator. The procedure consists of two steps:
1. Define management the ports’ operating mode

2. Define management the ports’ IP parameters
Enter the configuration mode:
DocumentationTest# configure
DocumentationTest(configure)#
4.4.2.1 M ANAGEMENT PORT OPERATING MODE

The management ports offer two alternative operating modes:
• Common: both ports acts as switching hub ports. MGMT2 will use MGMT1’s IP settings
Caution! With Common –mode selected, take care that both ports are not connected to same switch, as this could
result in an unpredictable loop. The connected networks must be totally separated.
• Separate: both ports acts as separate Ethernet network interfaces.
To select the management ports’ operating mode:

management-port-mode {common|separate}
4.4.2.1.1 S EPARATE MGMT NETWORKS IN OLDER CHASSIS

Older chassis may not have Separate networks item available in dropdown list. The reason is that the second MAC address
for MGMT2 interface is not set.
The session example below shows how to add a second MAC address for MGMT2 in older chassis can be fixed in the CLI.
TestChassis# configure
TestChassis (config)# interface mgmt1
TestChassis (interface-mgmt1)# upgrade-management-mac-address COMMIT
Programming management MAC2: 00:90:50:03:DD:16
43
New management MAC2 set successfully. Please reboot to activate.
TestChassis (interface-mgmt1)# exitconfigure ip address
4.4.2.2 H OSTNAME
4.4.2.2.1 A SSIGNING
Assign to the Luminato a host name for easier chassis identification. Do not use any special characters or spaces in the
name: only alphanumeric characters from a to z in uppercase or lowercase, digits from 0 to 9, and hyphen (-) are allowed.
To assign a hostname to the Luminato:
Syntax:
hostname <string>
Example:
unnamed# configure hostname DocumentationTest

4.4.2.2.2 V IEWING
To view the Luminato’s hostname:
Syntax:
show hostname
Example:
DocumentationTest(configure)# show hostname

Hostname: DocumentationTest
4.4.2.3 IP ADDRESS , NETMASK & DEFAULT GATEWAY

To configure the management interfaces’ IP address, netmask and default gateway with a single command-line you have
two alternative syntax:
Syntax1:
ip address {mgmt1|mgmt2} {dhcp|<ip_address> <netmask> [<default_gateway>]}
Syntax2:
interface {mgmt1|mgmt2} ip address {dhcp|<ip_address> <netmask> [<default_gateway>]}
44
Keywords & Arguments:
Name Description Allowed

values
dhcp Acquire management IP address from a DHCP server.
ip_address Static IPv4 address in dot-decimal notation (immediately followed by a slash ‘/’
character if in CIDR notation)
netmask IPv4 netmask in classful dot-decimal notation or in CIDR notation CIDR: {0…32}
default_gateway IPv4 address in dot-decimal notation
Hint: Select dhcp if the device will be automatically allocated management IP parameters by a DHCP server, otherwise
insert the target static values for IP_ADDRESS, NETMASK, and GATEWAY in dot-decimal notation. Setting the GATEWAY
value to 0.0.0.0 results in a no gateway configuration.
4.4.2.4 D EFAULT GATEWAY

To add or alter the default gateway address for ports MGMT1 and MGMT2, you have two alternative syntax:
Syntax1:
ip gateway {mgmt1|mgmt2} <ip_address>
Syntax2:
interface {mgmt1|mgmt2} ip gateway <ip_address>
Name Description Allowed values

ip_address IPv4 address in dot-decimal notation
4.4.2.5 S TATIC ROUTE
4.4.2.5.1 A DDING
To add a static route entry into the Luminato’s management traffic routing table:
Syntax:
ip route <destination_ip_address> <netmask> <gateway_address> {mgmt1|mgmt2}
45

values
destination_ip_address Pv4 address in dot-decimal notation (immediately followed by a slash ‘/’
character if in CIDR notation)
netmask IPv4 netmask in classful dot-decimal notation or in CIDR notation CIDR: {0…32}
Gateway_address IPv4 address in dot-decimal notation
Example:
DocumentationTest# configure ip route 192.168.1.0 255.255.255.0 192.168.0.250

4.4.2.5.2 R EMOVING
To remove a static route entry into the Luminato’s management traffic routing table:
Syntax:
no ip route <destination_ip_address>
4.4.2.6 E NABLING /D ISABLING THE MANAGEMENT INTERFACES

To enable/disable the management interfaces:
Syntax:
interface {mgmt1|mgmt2} [no] shutdown
Keywords:

no no shutdown = Enable interface
Caution! You will lose the IP management connection upon disabling the management interface. Once the
management interface disabled, the only way to access the device settings through the CLI is the local management USB
port.
46
4.4.2.7 V IEWING THE IP SETTINGS
To view the configured IP settings of the management interfaces:
Syntax:
show ip [address|route]
Keywords:

address Will display the management IP configuration without showing the routing table -
route Will only display the management routing table.
Example:
DocumentationTest# show ip
!!! Management-port-mode : separate
Management 1 :
Status : active
DHCP : disabled
IP address : 10.2.14.216
Network mask : 255.255.252.0
Gateway : 10.2.15.254
MAC address : 00:90:50:04:db:1c
MTU : 1500
TX bytes : 625365722
RX bytes : 3251428450
Management 2 :
Status : active
DHCP : disabled
IP address : 172.16.1.216
Network mask : 255.255.224.0
Gateway : 172.16.1.1
MAC address : 00:90:50:04:db:1d
MTU : 1500
TX bytes : 4337528
RX bytes : 278785163
IP routing table
Destination NetMask Gateway Interface State
172.20.2.0 255.255.255.0 * mpass_1_3 Volatile
172.30.3.0 255.255.255.0 * mpass_1_3 Volatile
172.20.1.0 255.255.255.0 * mpass_1_2 Volatile
47
172.30.2.0 255.255.255.0 * mpass_1_2 Volatile
192.168.200.0 255.255.255.0 10.2.15.254 MGMT 1 Persiste
10.2.0.0 255.255.252.0 10.2.15.254 MGMT 1 Persiste
10.2.12.0 255.255.252.0 * MGMT 1 Volatile
10.3.0.0 255.255.248.0 10.2.15.254 MGMT 1 Persiste
172.16.0.0 255.255.224.0 * MGMT 2 Volatile
default 0.0.0.0 10.2.15.254 MGMT 1 Volatile
DocumentationTest#
NOTE! The ‘State’ column in the IP routing table refers to the type of route entry:
Volatile = Dynamic route
Persistent = Static route
4.4.3 NETWORKING UTILITIES

The Luminato includes two useful network testing tool: ping and traceroute.
4.4.3.1 P ING
Ping is to test and troubleshoot problems in IP networks. It operates by sending a series of three ICMP echo requests to
the specified IP address and reports the round-trip time for each received ICMP echo reply along with any recorded packet
loss. The utility also offers a statistical summary of the received response packets. The TTL is 64 for the ICMP request,
meaning the ICMP echo request might pass a maximum of 64 routers.
To use the ping utility:
Syntax:
ping <ping_destination_address> [<ping_source>] [<source_interface>]
Keywords:

ping_destination_address The ICMP echo requests’ IPv4 destination address in dot-decimal -
notation.
ping_source Specify the ICMP echo requests’ source; it can be the chassis and or a {chassis|{1..6}}
module slot number
source_interface Specify the interface through which the ping destination is reachable. {MGMT1|MGMT2}
48
Example:
DocumentationTest# ping 192.168.0.100

PING 192.168.0.100 (192.168.0.100): 56 data bytes
64 bytes from 192.168.0.100: seq=0 ttl=64 time=0.620 ms
--- 192.168.0.100 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.358/0.445/0.620 ms
DocumentationTest#
4.4.3.2 T RACEROUTE
Traceroute is a networking utility to trace the route the IP packets from the Luminato follow to reach the target IP address
as well as to find out where routing breaks down if the target host is unreachable.
Router’s Traceroute functions by sending a sequence of series of three UDP datagrams to the target host. The sequence
begins with the first series of UDP packets having a TTL value of 1: as the first router is reached, the TTL value reaches zero
and an ICMP Time Exceeded datagram is sent to the Luminato. Traceroute records the IP source address of the ICMP
message (=the first router) and sends the next series UDP packets with a TTL value of 2. The first router forwards the
packets and the second router replies with an ICMP Time Exceeded message. Traceroute continues so on gradually
increasing the TTL and keeping track of the routers reached, until the target host is reached and an ICMP Echo Reply is
received.
To use traceroute:
Syntax:
traceroute <target_ip_address>
Example:
DocumentationTest# traceroute 10.2.0.101

traceroute to 10.2.0.101 (10.2.0.101), 30 hops max, 38 byte packets
1 192.168.0.100 (192.168.0.100) 3003.087 ms !H 3007.052 ms !H 3009.463 ms !H
DocumentationTest#
4.5 USING CUSTOM HTTPS CERTIFICATES

You may add to the Luminato your own user certificate for HTTPS connections. You need to provide two files in PEM
(Privacy Enhanced Mail) format:
• one file containing the private key with the *.key filename extension
• one file containing the public certificate with the *.pem filename extension, including the whole
chain of trust
49
The PEM files must be manually uploaded to the Luminato user file folder and then the private key and the public
certificate must be enabled through the CLI. The PEM file must include the whole chain of trust.
To learn how to upload files, see chapter Uploading
To set/unset the user certificates:
Syntax:
configure [no] use-user-certificates <key_file.key> <pem-file.pem>
Keyword:

no Disables the user custom HTTPS certificates -
Example – use private key file “my_key.key” and public certificate file “my_cert.pem”:
DocumentationTest# configure use-user-certificates my_key.key my_cert.pem
Hint: If you’re a Linux user, you may verify the certificates using the ‘openssl verify’ command on your workstation.
4.6 TIME AND DATE

The Luminato features an internal clock that can be set manually, synchronized to an incoming DVB stream (TDT/TOT) or
to an external NTP (Network Time Protocol) server for more accuracy. The clock is used for time-stamping logged events.
4.6.1 VIEWING CURRENT TIME AND DATE

To view the current time and date:
Syntax:
show date
4.6.2 VIEWING TIME AND DATE SETTINGS

To view the configured time and date settings:
Syntax:
show clock
Example:
unnamed(configure)# show clock

Source of time: Real-time clock
Device time zone: Europe/Helsinki(+0200)
50
Device local time: Sat, 08 Nov 2014 06:34:47 EET
Device system time: Sat, 08 Nov 2014 04:34:47 UTC
DST Mode: Automatic

DST Offset: -02:00
DST Start: March Last Sunday 02:00
DST End: October 1st Saturday 03:00
unnamed(configure)#
Example explanation:
The DST Mode indicates the current Daylight Saving Time –operation mode:
• Automatic: DST is automatically configured based on the configured time-zone

• Manual: DST is manually defined
4.6.3 CONFIGURING
4.6.3.1 S ELECTING CLOCK SOURCE TYPE

To select the clock source:
Syntax:
clock source {local|ntp|dvb input <slot>/<connector>.<transport_stream>}
Keywords & arguments:

values
local Internal clock is configured locally. Define the local time with clock set –command. -
ntp Internal clock is synchronized to an external NTP server. Up to three NTP servers -
may be defined with the ntp server –command.
dvb input Internal clock is synchronized to an incoming DVB stream. -
slot Chassis slot number {1…6}
connector Input connector index {1…4}
Transport_stream TS index {1…128}
4.6.3.2 I NTERNAL CLOCK SOURCE

When Luminato’s timekeeping is entirely based on its internal clock, you will first have to set manually the time and date.
The internal clock is used when no NTP servers has been defined or when connection to all NTP servers has been lost.
Consequently, if one or more NTP servers have been defined, the internal clock settings will be overridden by the time
obtained from the NTP server.
51
NOTE! The Luminato does not have a battery backed-up clock, therefore actual time will be lost if the power shuts
down. It is recommended to use a NTP server for clock synchronization if real time clock is needed.
4.6.3.2.1 T IME ZONE

To specify the time zone (UTC) of the internal clock source for local time and for automatic DST configuration:
Syntax:
clock timezone {Africa/Abidjan(+0000)…UTC(+0000)}
Hint: The time zone list is too long to be included in the present document. However, since the time zones are defined
in the CLI as command keywords, you may use the command auto-completion feature with the tab key to discover the
target time zone. Please note that command keywords are always case sensitive, this applies to the time zone names too.
Example:
DocumentationTest(configure)# clock timezone Europe/Helsinki(+0200)
4.6.3.2.2 T IME
To set the time and date of the local clock source:
Syntax:
clock set <hh>:<mm>:<ss> <dd> <MM> <yyyy>
Arguments:

hh hours {0…23}
mm minutes {0…59}
ss seconds {0…59}
dd Day {1…31}
MM Month {1…12}
yyyy Year {2000…2038}
Example - Set the clock to 12:31:0, the seventh of February 2013:
DocumentationTest(configure)# clock set 12:31:0 7 2 2013
4.6.3.3 C USTOM DAYLIGHT SAVING TIME

Luminato’s internal clock configuration takes automatically the DST into account according to the pre-defined time zone
dependent DST settings. You may override this setting by entering your own custom daylight saving time (DST). In most
cases, there is no need for custom DST settings.
52
4.6.3.3.1 DST TIME PERIOD
To manually define the DST time period:
Syntax:
clock manual-dst {start|end} <month> <week#> <weekday> <hh>:<mm>

start Defines the start of the DST time period in local time currently in effect. -
end Defines the end of the DST time period in local time currently in effect. -
month You may specify the starting or ending month either numerically or as a string. {1…12}|<string>
For example, January = ‘1’ or ‘January’ or ‘Jan’
week# Defines the starting or ending week order number. {1…5}|{1st|2nd|3rd|4th|last}
weekday Defines the starting or ending weekday either numerically or as a string. For {0…6}|<string>
example, Sunday = ‘0’ or ‘Sunday’ or ‘Sun’.
hh hours {0…23}
mm minutes {0…59}
Example - define custom daylight start at last Sunday of March 02:00 and custom daylight end at first Saturday of
October at 03:00:
unnamed(configure)# clock manual-dst start 3 5 0 2:00

unnamed(configure)# clock manual-dst end 10 1 6 3:00
unnamed(configure)#
4.6.3.3.2 DST OFFSET

To define the DST offset:
Syntax:
clock manual-dst offset [+|-]<hh>:<mm>

+ DST is ahead of UTC -
- DST is behind of UTC -
hh hours {0…23}
mm minutes {0…59}
4.6.3.3.3 E NABLING / DISABLING CUSTOM DST

To enable/disable custom DST:
Syntax:
clock [no] manual-dst offset
53
Keyword & argument:

no Disables custom DST and enables automatic time-zone based DST.
4.6.3.4 E XTERNAL CLOCK SOURCE

To synchronize Luminato’s timekeeping with a NTP (Network Time Protocol) server, you need to specify the server’s IP
address. Up to three NTP servers may be defined.
When several NTP servers are defined , a number of timestamps are polled from each specified server and the most
accurate is automatically selected.
NOTE!The accuracy and reliability of the NTP synchronization feature depends on the number of servers.
The internal clock settings are overridden by the timestamp obtained from the NTP server. The internal clock is used
whenever connection to all NTP servers has been lost.
4.6.3.4.1 A BOUT THE NTP

The Network Time Protocol (NTP) is an Internet protocol for accurate synchronization of network devices to the UTC
(Coordinated Universal Time). It offers several operational models: client-server, broadcast/multicast, symmetric
active/passive.
The most common implemented model, and the one and only implemented in the Luminato, is the client-server model
where clients send time requests to a defined server or servers, and the server(s) replies with 64-bit timestamps. NTP
messages are transported using the UDP (User Datagram Protocol) on the fixed port 123.
The protocol is at its fourth version and is standardized by the IETF in RFC 5905.
4.6.3.4.2 A DDING NTP SERVERS

To add a NTP server definition:
Syntax:
ntp server <index> <ip_address>
Argument:

index NTP server entry’s index. {1..3}
ip_address The NTP message’s IPv4 destination address in dot-decimal notation.
54
4.6.3.4.3 R EMOVING NTP SERVERS
To remove a NTP server entry:
Syntax:
no server <index>
4.6.3.4.4 M ONITORING NTP CONFIGURATION

To view current status of the configured NTP servers along with time and date information:
Syntax:
show ntp
Example:
NamiLuto# show ntp

Source of time: External NTP server(s)
Device time zone: Europe/Helsinki(+0200)
Device local time: Mon, 10 Nov 2014 13:18:39 EET
Device system time: Mon, 10 Nov 2014 11:18:39 UTC
NTP servers
Server | IP address | Reachable | Sent pkts | Rcvd pkts
1 |172.16.0.1 |Yes |35661 |35661
2 |0.0.0.0 |No |0 |0
3 |0.0.0.0 |No |0 |0
Last NTP status change: Mon, 10 Nov 2014 13:18:39 EET

NamiLuto#
4.7 TERMINAL SETTINGS

The commands introduced in this chapter are used for terminal parameter customization.
Hint: Terminal setting customization is available to all users.
4.7.1 CONFIGURATION MODE

Enter terminal configuration mode:
Syntax:
configure terminal
Example:
unnamed# configure terminal
55
4.7.2 SHOW SETTINGS
To see a summary of the terminal settings:
Syntax:
show terminal
Example:
unnamed# show terminal

!
!TERMINAL SETTINGS
!
lines 24
timeout 1200 seconds
paging enable
vt100-colour enable
To see the setting a specific terminal parameter:
Syntax:
show terminal {length|pagination|timeout|vt100-colours}
Example:
unnamed# show terminal length

Terminal length: 24
4.7.3 SCREEN LENGTH
You may configure the number of command lines displayed on the terminal screen, this affects the pagination during
multiple-screen output.
NOTE! Some remote host applications do not require you to specify the screen length and can resolve the screen
length automatically. Configure this setting if the pagination doesn’t work correctly.
To configure the terminal screen length:
Syntax:
length <lines_per_screen>
Argument:

values
lines_per_screen Amount of lines on the screen. Default value is 24. Setting length to 0 lines will 0…255
disable pagination.
56
Example:
unnamed(terminal)# length 100
unnamed(terminal)#
4.7.4 SESSION TIMEOUT

You may configure how soon a session will expire due to user inactivity (no user input). Once a session expires the inactive
user is automatically logged out.
To configure the session timeout:
Syntax:
[no] timeout <timeout>
Keyword & argument:

no This optional keyword will disable the session timeout feature
timeout Specify the session timeout in seconds. The default value is 900 seconds (=15 minutes). 60…43200
4.7.5 COLOUR USAGE

You may enable or disable colour usage in the terminal output. The VT100 –colours are enabled by default.
To enable/disable colour usage:
Syntax:
[no] vt100-colour
Keyword:

no This optional keyword will disable colour usage in the terminal output.
4.8 USER MANAGEMENT

Depending on the size of your organization and application, user accounts may be managed either locally or remotely.
In small-scale applications, such as hospitality, users are typically managed and stored locally on the Luminato.
In larger networks encompassing several main headends and sub-headends, user accounts are managed centrally on one
or several remote servers to reduce operational complexity and maintain a globally consistent security policy across the
network. Luminato supports LDAP (Lightweight Directory Access Protocol) for centralized user login authentication.
To learn how to use LDAP user authentication, see chapter “”
57
4.8.1 USER GROUPS
In the Luminato, each user account is assigned to a user group. The user group determines the access rights of a user
account. There are four user groups:
1. Admin group
• factory default:
o username: admin
o password: admin
• User has full access to all configurable parameters including administrative settings
2. Install group
• no usernames by default
• User has full access to all configurable parameters except administrative settings: cannot create/change admin-
users.
3. Oper group
• factory default:
o username: oper
o password: oper
• Access is limited only to configuration of services and view of network settings.
• User has no access to administrative settings or procedures like software upgrade.
4. Monitor group
• factory default
o username: guest
o password: guest
• Has read-only access for monitoring purposes only.
• Cannot change any settings.
4.8.2 MANAGING LOCAL USER ACCOUNTS

To manage local user accounts, log in as administrator (admin group) and enter configuration mode:
4.8.2.1 V IEWING ALL REGISTERED USER ACCOUNTS

To view a list of all registered user accounts:
Syntax:
show user
58
Example:
DocumentationTest(configure)# show user

show user
Current user : admin
========================================
Admins : admin
Operators : oper, heavyUser
Installers : -
Monitors : guest
4.8.2.2 U SER ACCOUNT CREATION

To add a new user account:
Syntax:
user <username> group {admin|install|monitor|oper} password <password>
Example:
We create a monitor group user account with login name “lightUser” and password “resctricted”.
DocumentationTest(configure)# user lightUser group monitor password restricted

0
lightUser added to group monitor.
4.8.2.3 C HANGING PASSWORD
4.8.2.3.1 C URRENT USER

To change the password of the current user account (this command is available to all user groups except the monitor
group):
Syntax:
passwd <password> <password>
Example:
DocumentationTest(configure)# passwd admin admin

configure passwd *** ***
Password changed successfully for user admin
NOTE! The password needs to be entered twice to prevent mistyped password definition.
59
4.8.2.3.2 S PECIFIC USER
To change the password of a specific user account (available to admin and install group):
Syntax:
user <username> password <password>
Example:
DocumentationTest(configure)# user lightUser password light

NOTE! Install group users cannot create or modify admin group user accounts.
4.8.2.4 R EMOVING A USER ACCOUNT

To remove a user account:
Syntax:
no user <username>
Example:
DocumentationTest(configure)# no user lightUser

4.8.3 LDAP REMOTE USER LOGIN AUTHENTICATION

Luminato supports remote user login authentication via LDAP (Lightweight Directory Access Protocol) queries. You may
define define up to three LDAP servers for high availability purposes. The communication may be secured using SSL/TLS.
When a user attempts to log into Luminato with LDAP remote user authentication enabled, the entered user credentials
are first matched against the user accounts stored locally in the Luminato: if no match occurs, the entered user credentials
are verified from the defined Directory System Agent (= the LDAP server) via an LDAP seach query using search
parameters preconfigured in Luminato’s configuration. These search parameters are configured by an admin level
Luminato local user.
4.8.3.1 C ONFIGURATION
Enter global configuration mode as described in chapter “Entering and exiting command modes”, p. 32.
4.8.3.1.1 C ONNECTION
4.8.3.1.1.1 SPECIFYING THE LDAP SERVERS
To specify a LDAP server:
Syntax:
ldap hosts {<IP_address>|<FQDN>} [<IP_address>|<FQDN>] [<IP_address>|<FQDN>]
60
Arguments:

IP_address The LDAP server’s IPv4 address in dot-decimal notation.
FQDN The LDAP server’s Full Qualified Domain Name or hostname
4.8.3.1.1.1.1 P ORT
To specify the port to connect to:
Syntax:
ldap port {default|{1…65535}}
Keyword:

values
default The default port is ‘389’ with TCP connections and ‘636’ when TLS is enabled (see chapter
4.10.3.1.1.2).
4.8.3.1.1.2 ENABLING OR DISABLING TLS

To enable or disable TLS connection:
Syntax:
[no] ldap ssl
4.8.3.1.1.3 SERVER CERTIFICATE VERIFICATION

If you have opted to use TLS when connecting to LDAP servers, you may enable LDAP server’s CA certificate verification to
ensure the server is who it claims to be prior connecting. If the verification fails, the TLS connection will be aborted.
Enabling peer certificate verification involves several configurational steps:
1. Collect the server’s CA certificates (the whole chain of trust) into a single gzipped tar file. The filename extension
MUST be .tgz.
2. Upload the tar file to the target Luminato using the copy command or the web UI’s Filemanager.
To learn how to upload a file with the ‘copy’ –command, see chapter
“Uploading”, p. 98
3. Copy the tar file to Luminato’s SSL certificate directory using the copy <tar_file> ssl-certs command
See below for more details.
4. Enable peer certificate verification in Luminato with the ldap tls-checkpeer command
See below for more details.
61
To copy the tar file to Luminato’s SSL certificate directory:
Syntax:
copy <tar_file> ssl-certs
Argument:

tar_file The gzipped tar file containing all the CA certificates contained in the The filename extension MUST be
chain of trust. .tgz
To enable server certificate verification:
Syntax:
[no] ldap tls-checkpeer
NOTE! Self-signed certificates will be rejected and will cause a verification failure.
4.8.3.1.1.4 BINDING PARAMETERS

By default, Luminato binds anonymously to the DSA. With the bind commands, the LDAP session can be authenticated.
This command binds the Luminato to the DSA with the specified user DN and password. You may adjust the bind time limit
used when connecting to the DSA.
4.8.3.1.1.4.1 B IND TIME LIMIT

To specify the bind time limit to use when connecting to server:
Syntax:
ldap bind-timelimit {default|<time_limit>}
Keyword & argument:

default The default time limit is 30 s. -
time_limit Specify the time limit in seconds. {1…180}
4.8.3.1.1.4.2 D ISTINGUISHED N AME
To specify the distinguished name with which to bind to the DSA:
Syntax:
ldap bind-dn <user_DN>
4.8.3.1.1.4.3 P ASSWORD
To specify the password with which to bind to the DSA:
62
Syntax:
ldap bind-password <user_password>
4.8.3.1.1.5 SEARCH TIME LIMIT

To specify the time limit to use when performing a search:
Syntax:
ldap timelimit {default|<time_limit>}
Keyword & argument:

default The default time limit is 0 s. Luminato waits indefinitely for the search to complete. -
time_limit Specify the time limit in seconds. {1…180}
4.8.3.1.2 S EARCH PARAMETERS

This section introduces the commands necessary to perform LDAP search queries.
4.8.3.1.2.1 BASE DISTINGUISHED NAME

To define the default base Distinguished Name (DN) used as a starting point for the searches:
Syntax:
ldap base <base_DN>
Argument:

base_DN The DN (Distinguished Name) from which search query will start from top level down The filename
in the LDAP directory. Place the DN inside double quotes, for example: extension MUST be
“dc=example,dc=org”. .tgz
4.8.3.1.2.2 SEARCH SCOPE
To specify the search scope:
Syntax:
ldap scope {base|one|sub}

values
base Search only for the entry specified by the ldap base <base_DN> command -
one Search for the entries immediately below the base DN specified by the ldap base <base_DN> -
command.
sub Search for the whole subtree below the base DN specified by the ldap base <base_DN> -
command. This is the factory default scope.
63
4.8.3.1.2.3 LOGIN ATTRIBUTE
To specify which attribute corresponds to the user’s login name data in the DSA:
Syntax:
ldap login-attribute {default|<attribute>
Keyword:

default As per RFC 2307, the user’s login name is expected to be found in the ‘uid’ attribute. -
4.8.3.1.2.4 USER PASSWORD ATTRIBUTE
The user’s password must exist in the userPassword attribute and must match the user-provided password, otherwise
the login will fail.
4.8.3.1.2.5 SEARCH FILTER

When authenticating a user in addition to the (<login_attribute>=entered_user_login_name) assertion, you may specify
additional assertions which must all be true for succesful login. These additional assertions are called search filters.
Effective search queries:
• Without search filters: (<login_attribute>=entered_user_login_name)

• With search filters: (&(filter_value)(<login_attribute>=entered_user_login_name))
To specify the search filter used when retrieving user information:
Syntax:
ldap filter <filter>

values
filter As per RFC4511, the filter “defines the conditions that must be fulfilled in order -
for the Search to match a given entry”. Multiple filter components may be compounded using
Boolean operators and the filter components may be nested. The allowed Boolean operators are ‘&’
(=AND) and ‘!’ (=NOT).
Example:
We want to search users that are classified in the DSA as Luminato administrators and that do not reside in Turku.
configure ldap filter “(&(ou=administrator)(description=Luminato)(!(L=Turku)))”
NOTE! The OR Boolean operator ‘|’ is not currently supported by the CLI. To circumvent this restriction, convert the
OR operations into AND operations by applying De Morgan’s law (!(|(A)(B)))=(&(!(A))(!(B)))
64
4.8.3.1.2.6 GROUP MEMBERSHIP ATTRIBUTE
In the Luminato, each user is assigned to a user group. The user group defines the access rights of a user. With LDAP login
authentication, the attribute that defines the user’s group membership information is queried. This attribute is by default
expected to be gidNumber.
The attribute value must contain a group ID number, or a textual group name. The allowed groups are admin (or 500),
install (or 501), oper (or 601) and monitor (or 602).
To specify which attribute corresponds to the user’s group membership information in the DSA:
Syntax:
ldap group-membership-attribute {default|<group_attribute>}
Keyword:

default The default group membership attribute is gidNumber. -
4.8.3.1.2.7 EXPECTED USER DATA OBJECT CLASS

In the LDAP, each directory entry has an objectClass attribute. The object class definitions are stored in a directory schema
in the DSA. An object class defines the set of attributes that must be present in the directory entry.
Since this specific application of the LDAP is concerned with user login information, the entry queried should obviously
belong to an object class representing users. The expected objectClass when performing a search query is by default
posixAccount, but you can change the objectClass name in accordance with the schema used in your directory system. If
the specified objectClass is not found during the search query, the user login will fail.
To specify the expected user data object class:
Syntax:
ldap login-data-objectclass {default|<objectClass>}
Keyword:

default The default user objectClass is posixAccount. -
4.8.3.1.2.8 CHECKING ALLOWED HOSTS
You may specify a list of allowed hosts for each user in your DSA’s host attribute; this will allow you to deny logins of users
with non-matching hostnames. In Luminato, you may enable or disable the verification of allowed hosts.
NOTE! Ensure that the hostname of the Luminato is resolvable, otherwise the login will fail.
65
To enable or disable logins on a per-host basis:
Syntax:
[no] ldap check-host-attr
Keyword:

no The no keyword disables checking the host attribute verification. -
4.8.3.1.3 T ESTING USER LOGIN

To test a user login:
Syntax:
configure test-user-login <user_name>
Example:
DocumentationTest# configure test-user-login jk

Password:
test-user-login: Permission denied
4.8.3.1.4 V IEWING LDAP CONFIGURATION

To view the LDAP configuration:
Syntax:
show ldap
Example:
DocumentationTest(configure)# show ldap

LDAP configuration
Hosts : 10.1.1.140
Port : default
SSL/TLS : no
Check peer certificate : no
Check 'host' attribute : no
Bind DN : "ttest\test"
Bind timelimit : 180
Timelimit : default
Base : "dc=teleste,dc=test"
Scope : default (sub)
Filter : "(&(cn=John Doe)(x7c(sn=Myname)(ou=example)"
Login data objectClass : Users
Login attribute : sAMAccountName
Group membership attribute: gidNumber
66
4.9 REBOOT COMMANDS

4.9.1 SYSTEM REBOOT
To reboot the Luminato system:
Syntax:
reboot COMMIT
4.9.2 MODULE REBOOT

To reboot a single module:
Syntax:
reboot module {1…6}
Example – Reboot module in slot 1:
unnamed# reboot module 1

Rebooting module 1, please wait a couple of minutes.
unnamed#
4.10 LOG SETTINGS

The Luminato uses the syslog industry standard protocol (RFC 5424) used for capturing log information of devices on a
network (via UDP port 514). Syslog is natively supported in Unix and Linux based systems, but not in Windows and MacOS.
However, there are many third-party applications available to add this capability to your operating system.
The Luminato supports detailed logging via syslog. However, the size of the internal log is limited by the available memory.
Therefore, the internal log is rotated so that only the latest log entries remain, when the log becomes full.
This limitation can be overcome by using an external syslog server. In the Luminato, you may specify up to four external
syslog servers.
4.10.1 CONFIGURING EXTERNAL SYSLOG SERVERS
4.10.1.1 A DDING
To add an external syslog server entry:
Syntax:
configure logging server <index> <ip_address>
67
Arguments:

Index Specify the index of the syslog server entry. 1…4
ip_address The syslog server’s IPv4 address in dot-decimal notation.
Example:
DocumentationTest# configure logging server 1 192.168.0.98
4.10.1.2 R EMOVING
To remove an external syslog server entry:
Syntax:
configure no logging server <index>
4.10.2 EVENT SEVERITY AND STORAGE LOCATION

Log entry generation is based on ‘events’ (state transitions) inside the Luminato. In accordance with the syslog protocol
standard RFC 5424, events are categorized into 8 severity levels:
1. Emergency: system is unusable. A "panic" condition

2. Alert: action must be taken immediately
3. Critical: critical conditions
4. Error: error conditions. Non-urgent failures, but that must be resolved within a given time
5. Warning: warning conditions. Not an error, but indication that an error will occur if action is not taken.
6. Notice: normal but significant condition. Events that are unusual but not error conditions - no immediate action
required.
7. Informational: informational messages - no action required
8. (Debug: debug-level messages. Info useful to developers for debugging the application, this feature is available
only in special debugging mode)
There are two kinds of internal syslog storage options: persistent (non-volatile) and volatile. The persistent log is stored in
flash memory and will remain even if the chassis is rebooted or shut down, while the volatile log is stored in volatile RAM
and will be lost in case of device power down.
To enable/disable event logging based on event severity level and log storage location:
Syntax:
configure [no] logging level {emergency|alert|critical|error|warning|notice|information}

<storage1> [<storage2>] [<storage3>]
Arguments:

no Disables event logging for the specified severity level at specified storage -
location(s)
storage1 First log storage location definition. {external|non-
volatile|volatile}
68
storage2 Second log storage location definition. {external|non-
volatile|volatile}
storage3 Third log storage location definition. {external|non-
volatile|volatile}
Example:
We want to store emergency -level syslog messages to non-volatile and volatile memory and external servers; notice -level
messages to volatile memory and no storage for information -level messages.
DocumentationTest# configure logging level emergency non-volatile volatile external

DocumentationTest(configure)# logging level notice volatile
DocumentationTest(configure)# logging level information
NOTE! Write-operations to flash memory reduce the lifetime of the component itself: avoid configuring frequently
occurring events (such as notice) to persistent (internal) logging.
4.11 SNMP SETTINGS

In this chapter, we will first give a brief overview of the SNMP, then we will describe the configuration procedures for the
SNMP related settings.
4.11.1 ABOUT SNMP

Simple Network Management Protocol (SNMP) is a standard Internet protocol for managing IP network devices, issued by
the Internet engineering task force (IETF). SNMP’s most basic purpose is to give a mean to monitor the health of network
devices, but it may also be used to control and configure network devices.
4.11.1.1 T RANSPORT PROTOCOL

SNMP uses UDP as transport protocol. Port 161 is used for sending and receiving requests and port 162 for receiving traps.
69
4.11.1.2 SNMP ENTITIES
FIGURE 6: MANAGERS SEND QUERIES THROUGH PORT 161 AND THE AGENT RESPONDS THROUGH THE SAME PORT. THE AGENT SENDS TRAPS
THROUGH PORT 162 WHENEVER A TRAP GENERATING EVENT OCCURS IN THE MANAGED DEVICE.
In the SNMP, there are two types of entities: managers and agents. The managers (usually referred to as Network
Management Stations or NMSs) send queries to the agents (managed network devices such as Luminato). The agents may
either respond to NMS’s queries or send messages called traps whenever a trap generating event has occurred. In
practice, a NMS is a server running a network management software suite and the agent a piece of software in the
managed device.
4.11.1.3 SNMP STANDARDS

1
There are currently three different versions of the Internet-standard network management framework: SNMPv1 ,
SNMPv2 and SNMPv3.
2
Luminato supports SNMP versions 1 and 2c. SNMPv2c is an experimental community-based administrative framework
version of SNMPv2, where every message is associated to a community.
4.11.1.4 C OMMUNITY NAME

Community names are used for authenticating SNMPv1 and SNMPv2c messages between SNMP entities, making them de
facto passwords. Agents are assigned three community names: read-only, read-write and trap. In Luminato respectively,
these are ro and rw.
• The ro community string lets you read data values, but doesn’t let you modify the data. The default name is
‘public’.
• The rw community is allowed to read and modify data values. The default name is ‘private’.
1
See RFC 1157
2
See RFC 1901-1908
70
Caution!In SNMPv1 and SNMPv2c, community strings are embedded as plain text within the SNMP messages and
traps, thus making the authentication vulnerable to packet sniffing!
4.11.1.5 M ANAGEMENT I NFORMATION B ASE

The agents offer a set of different parameters and variables for the manager(s) to track; these are referred to as objects.
The description of these objects is contained within a Management Information Base (MIB); in practice, the complete
description of the managed objects spans usually over several MIB –files.
4.11.1.6 S TRUCTURE OF M ANAGEMENT I NFORMATION

The exact presentation of the managed objects described in the MIBs is defined by Structure of Management
1 2
Information Version 1 & 2 (SMIv1 and SMIv2 ). The object definition contains the name, type, syntax and encoding of
the object. The name is uniquely identified by an object identifier (OID) in both numerical and verbal form. The data
3
type definition uses the system-agnostic Abstract Syntax Notation One (ASN.1 ) and, accordingly, the encoding uses
4
the device-agnostic Basic Encoding Rules (BER ).
In SNMP, managed object are hierarchically organized in a tree structure: the OID can be directly derived from this
structure. This permits to easily identify object dependencies.
Each node in the tree can be specified either in its textual or decimal form, each separated by dots. The top-most node is
called the root-node. Any node having sub-nodes is called a sub-tree and a node having no sub-node is called a leaf
node. The leaf nodes are usually monitored variables or parameters.
Figure 7, p.72, illustrates the MIB-tree for the OID of Teleste Corporation’s root node 1.3.6.1.4.1.3715 or textually
iso.org.dod.internet.private.enterprises.Teleste.
1
See RFC 1155
2
See RFC 2578
3
See ITU-T Rec. X.680-683
4
See ITU-T Rec. X.690
71
FIGURE 7: MIB-TREE STRUCTURE FOR OID 1.3.6.1.4.1.3715 (PATH ILLUSTRATED IN BLUE)
4.11.2 LUMINATO MIBS

In order to be able to query Luminato objects and interpret all Luminato traps, you will need to compile and load in your
NMS the MIB files containing the definitions of these objects. All the necessary MIBs can be downloaded directly from the
monitored device (assuming that the minimum standard MIBs are already available for your NMS).
NOTE! Upon each SW release, new object definitions might have been inserted into the MIBs and/or some changes
might have occurred in the definitions. It is therefore good practice to keep your NMS object database up to date and
always download and recompile the MIBs after upgrading Luminato software.
Luminato provides 15 MIB files in one ZIP-file for easy downloading.Table 1 gives a brief description for each node of
interest contained in the provided MIB files. The complete definitions of all objects can be obtained by reading the MIB
files in any text- or MIB-editor.
TABLE 1: THE LUMINATO PROVIDED MIB FILES ALONG WITH A BRIEF EXPLANATION FOR EACH NODE OF
INTEREST.
MIB Node(s) of interest Comment

SNMPv2-MIB 1.3.6.1.2.1.system(1) Provides generic information
about the monitored device such
as, id, uptime, hostname,
management contact and
location.
72
Contains the definition for trap
coldStart
IF-MIB 1.3.6.1.2.1.interfaces(2) Provides information about the
MGMTx and GEx interfaces such
as, Mtu, physical address, speed
etc.
1.3.6.1.2.1.31.1.ifXTable(1) Provides statistical information
about the MGMTx and GEx
interfaces in form of various
counters such as multicast and
broadcast packets sent etc.
RFC1213-MIB 1.3.6.1.2.1.4.ipAddrTable(20) MGMT ports’ index, IP address
and netmask.
ENTITY-MIB 1.3.6.1.2.1.47.1.1.entPhysicalTable(1) Provides information about the
monitored physical entities such
as, module type, slot number,
serial number etc.
RFC1155-SMI Definition of SMI names,
datatypes and definition syntax
SNMPV2-TC Textual conventions for SMIv2
SCTE-ROOT 1.3.6.1.4.1.scteRoot(5591) Definition of the SCTE root and
scteRoot.scteHmsTree(1) HMS
SCTE-HMS- 1.3.6.1.4.1.5591.1.propertyIdent(1) Definition of the objects under
ROOTS 1.3.6.1.4.1.5591.1.insidePlantIdent(11) the SCTE HMS tree
SCTE-HMS- 1.3.6.1.4.1.5591.1.1.currentAlarmTable(2) currentAlarmTable is a sequence
PROPERTY- of currentAlarmEntry providing a
MIB list of currently active
warnings/errors.
1.3.6.1.4.1.5591.1.1.discretePropertyTable(3) Keeps references to possible
status codes.
Reserved for future needs to filter
out unnecessary status codes
from monitoring.
SCTE-HMS- 1.3.6.1.4.1.5591.1.11.headEndIdentMib(0) Defines the root OID for indoor
HEADENDID headend device MIBs
ENT-MIB
SCTE-HMS- 1.3.6.1.4.1.5591.1.11.2.1.1.1.2.heCommonLog A persistent list of events that
HE- Table(3) have been logged.
COMMON-
MIB
UCD-SNMP- 1.3.6.1.4.1.2021.laTable(10) CPU load 1, 5, 15 min averages
MIB
TELESTE- 1.3.6.1.4.1.[Category](3715).Luminato(17) Definition of proprietary data
ROOT-MIB 1.3.6.1.4.1.[Category](3715).common(99) types and root nodes
TELESTE- 1.3.6.1.4.1.3715.99.1.3.elementInformation(1) Minimal equivalent of mib-
COMMON- 2.system
MIB 1.3.6.1.4.1.3715.99.1.elementStatus(2) Statuses of general nature such as
fan, HW, SW etc. status.
1.3.6.1.4.1.3715.99.1.3.controlTrapReceiverTa A table of the manager trap
ble(5) receiver addresses, ports and
73
communities. The total number
of entries cannot exceed
controlMaxNumberTrapReceiver
s. An entry is deleted from this
table by setting its IP address to
'0.0.0.0'.
1.3.6.1.4.1.3715.99.2.moduleInformation(1) Provides information about
modules such as slot number,
HW-type, serial number etc.
1.3.6.1.4.1.3715.99.2.2.1.1.statusInternalTemp Provides modules’ temperature,
erature(3) in 0.1 C° units. Value is zero (0),
if temperature is not available.
TELESTE- 1.3.6.1.4.1.3715.17.general(1) Equivalent of mib-2.system.
LUMINATO-
MIB Provides cumulative uptime of
device.
1.3.6.1.4.1.3715.17.2.statusCodeDeviceTable(2 These tables describe possible
) status codes for objects on
1.3.6.1.4.1.3715.17.2.statusCodeModuleTable( various levels: device, module,
3) interface, TS, service and PID
1.3.6.1.4.1.3715.17.2.statusCodeInterfaceTabl level.The objects may represent
e(4) real objects or classes.
1.3.6.1.4.1.3715.17.2.statusCodeTransportStre
amTable(5) The monitoring system or user
1.3.6.1.4.1.3715.17.2.statusCodeServiceTable( shall not poll these tables to
6) detect object states. Use these
1.3.6.1.4.1.3715.17.2.statusCodePidTable(7) tables only to obtain the textual
description of the alarms.
1.3.6.1.4.1.3715.17.interface(3) Extends the mib-

2.interfaces.ifTable. All the
tables of this node use ifExtIndex
for each object instance.
ifExtIndex has the following
format: SDPPVVVV, where: S =
Slot number
D = input(1) / output(2)
PP = Physical interface number
VVVV = Virtual interface
number
For example,
ifExtName.62040001 provides
the name of logical interface 1 in
physical output interface 4 in
module 6.
74
1.3.6.1.4.1.3715.17.3.ifExtTable(1) Provides information about the
names and numerical labels the
physical and logical interfaces.
1.3.6.1.4.1.3715.17.3.signalPhysTable(2) Provides information about signal

quality such as SNR, CC errors,
BER and VBER.
1.3.6.1.4.1.3715.17.3.transferTable(3) Provides interface bit rate

information in kbps.
1.3.6.1.4.1.3715.17.3.proMpegFecTable(20) Provides pro-MPEG FEC packet
counter statistics such as
corrected packets and valid
packets.
1.3.6.1.4.1.3715.17.statusFlags(5) Displays active sta-tus flags.
1.3.6.1.4.1.3715.17.moduleStatusTable(2) Table of active status flags at

1.3.6.1.4.1.3715.17.ifStatusTable(3) module, IF, TS, service and PID
1.3.6.1.4.1.3715.17.tsStatusTable(4) levels.
1.3.6.1.4.1.3715.17.serviceStatusTable(5)
1.3.6.1.4.1.3715.17.pidStatusTable(6)
TELESTE- 1.3.6.1.4.1.3715.17.notifications(4) Luminato proprietary generic and
LUMINATO- specific extended trap definition.
MIB2 The SNMP trap generation
extended mode generic or
specific mode must be enabled in
order to use these extended traps.
HOST- 1.3.6.1.2.1.25.2.hrStorageTable(3) Provides information on the user
RESOURCES- partition such as storage size and
MIB used storage expressed in
hrStorageAllocationUnits. If for
example, the
hrStorageAllocationUnit is 1024
(Bytes) then the storage size is
expressed in kB.
HOST- Registers type definitions for
RESOURCES- storage types, device types, and
TYPES file system types.
4.11.2.1 D OWNLOADING THE MIB FILES

The necessary MIB files are located in Luminato’s file system as a single ZIP file, in this folder: /documents/mibs.zip.
Extract the MIB files from the mibs.zip file (Figure 8).
75
FIGURE 8: EXTRACTING THE MIB FILES.
Open and compile the MIB files in your NMS.
Hint: Some of the provided MIB files point to other MIB files; most MIB compiler should be able to resolve the file-
dependencies automatically when compiling. However, if for some reason your compiler fails, try compiling the MIB files
one by one in the order stated in the order.txt file (included in the mibs.zip package).
4.11.3 CONFIGURING THE SNMP SETTINGS

4.11.3.1 L OCATION INFORMATION

sysLocation tells where is the monitored device physically located, this information is important with large networks when
the device needs to be repaired or replaced.
To specify sysLocation:
Syntax:
snmp-server location <sysLocation>
76
Argument:

sysLocation Write the device location in double-quotes. The maximal string length is 255 characters.
4.11.3.2 C ONTACT INFORMATION

sysContact defines who or which instance is responsible for the monitored device.
To specify the sysContact:
Syntax:
snmp-server contact <sysContact>
Argument:

values
sysContact Write the contact description in double-quotes. The maximal string length is 255
characters.
4.11.3.3 C OMMUNITY STRING

To change the community name for the read-only and read-and-write communities:
Syntax:
snmp-server community <community_string> {ro|rw}
Argument & keywords:

community_string Defines the community name for the target community.
ro Read-only community
rw Read-and-Write community
Caution! In SNMPv1 and SNMPv2c, community strings are embedded as plain text within the SNMP messages and
traps, thus making the authentication vulnerable to packet sniffing!
To learn more about SNMP community names, see chapter “Community ”, p. 70
4.11.3.4 SNMP TRAP GENERATION MODE

By default, Luminato uses the standard SCTE HMS heCommonAlarmEvent trap format which supports only two severity
levels for discrete events: heCommonDiscreteMajor and heCommonDiscreteMinor.
If you need more severity levels or if you want to customize the severity level settings of individual alarms with
connections to modules/inputs/TS/services/PIDs, you may use one of the two featured proprietary extended trap
generation modes: general or specific.
77
When using the extended trap generation mode, you may disable the HMS trap generation mode if necessary.
NOTE! The extended trap generation modes are meant for advanced users only and therefore is implemented only
the CLI.
4.11.3.4.1 HMS TRAP GENERATION

To enable/disable HMS SNMP trap generation mode:
Syntax:
[no] snmp-server traps hms
Keyword:

no Disables HMS traps. -
4.11.3.4.2 E XTENDED TRAP GENERATION

To enable extended SNMP trap generation mode:
Syntax:
snmp-server traps extended {general|specific}
Keywords:

general Enables general extended traps. Provides eight event
severity categories.
specific Enables specific extended traps. Provides eight event
severity categories and each alarm event type has its
own OID.
To disable extended SNMP trap generation mode:
Syntax:
no snmp-server traps extended
Keyword:

no Disables extended traps. -
78
4.11.3.5 E XTENDED TRAP SEVERITY SETTINGS
Caution! This is an ‘advanced user’ feature, use with caution! Illogical or invalid severity settings may have in
unexpected results and may, for example, impair the 1+1 backup triggering functionality.
When using the extended trap generation mode, you may create sets of severity rules for specific status codes applied to
user defined parameters such as, module, interface, SID, PID etc.
NOTE! The new severity settings affect only general or specific extended traps.
4.11.3.5.1 A DDING A SEVERITY RULE

To define a new trap severity rule:
Syntax:
configure severity rule <priority_number> module {all|[not] {chassis|1…6|psu}} reason

{all|[not] <status_code>} [params <P>] severity <S>
Keywords & parameters:
• The priority_number, for example 500, is used to order rules. A smaller order number means a
higher priority in the severity rule table. Due to some technical restrictions, the used
priority_numbers should be of the same order of magnitude: for example within the range of 10-
99, 1000-9999, or 10000-99999.
• module defines which module(s) is/are affected by the severity rule
• reason defines which status code(s) is/are affected by the severity rule
• P defines which parameter(s), if any, is/are affected by the severity rule. P is defined by up to four
sub-parameters. P use, if applicable, the following general format:
o P = <module_type> <input/ouput_interface_index> <SID/PID>
 module_type = {*|[not] {0|1}, where:
• 0 = input
• 1 = output
 input/ouput_interface_index = {*|[not] {0…}}
 SID/PID = {*|[not] {0…}}
o The actual parameters may be extrapolated by analyzing actual extended specific trap
content. For example, we can see from Figure 9 that P = 1 8 1580
79
FIGURE 9: EXTRAPOLATING PARAMETERS FROM AN ACTUAL EXTENDED SPECIFIC TRAP.
 S is the new severity applied if all previous rules are met.

o S=
{emergency|alert|critical|error|warning|notice|informational|debug|nominal|ignore}
o ignore = causes this rule to be ignored (Can be used to temporary disable the rule without
having to remove it).
o nominal = turns the trap severity to OK.
4.11.3.5.2 R EMOVING A TRAP SEVERITY

To disable a trap severity rule:
Syntax:
configure no severity rule <priority_number>
4.11.3.5.3 T O DISPLAY ALL CONFIGURED SEVERITY RULES :

Syntax:
show severity rules
80
4.11.3.5.4 U SE EXAMPLE
We have a fresh installation and have no rules defined:
unnamed(configure)#show severity rules

| N | Module |Reason |Params |Severity |
unnamed(configure)#
In this case, all events would have their original severities and all extended traps (if enabled) would have also same
severity.
Then, for instance, we have a large number of PID Missing –events (by default a warning severity level event), but we
would like to see those only as notice.
We add one rule:
unnamed(configure)# severity rule 500 module all reason 2 severity notice

unnamed(configure)#
Then, we would like to receive all PID Missing events from module 5 as error –level severity traps. This would be a more
specific rule, so its priority should be before 500; say 450.
unnamed(configure)# severity rule 450 module 5 reason 2 severity error

unnamed(configure)# show severity rules
| 450 | 5 | 2 - PID missing | |error |
| 500 | all | 2 - PID missing | |notice |
unnamed(configure)#
Then, we would like to have all PID Missing events from module 5 output 2 on an even higher severity level, for example
critical:
unnamed(configure)# severity rule 430 module 5 reason 2 params 1 2 severity crit

ical
| 430 | 5 | 2 - PID missing |1 2 |critical |
unnamed(configure)#
Then, we would like to have all PID Missing events from module 5 for PID 16 to be alert level traps. Again, we are going
to use a smaller rule number to place PID match at higher priority than output match (rule 430 will be applied only if PID is
not 16).
unnamed(configure)# severity rule 420 module 5 reason 2 params * * 16 severity a

lert
| 420 | 5 | 2 - PID missing |* * 16 |alert |
81
unnamed(configure)#
Last, if we would like to clean all others events, we could place the last rule which match anything and sets severity to
nominal.
unnamed(configure)# severity rule 999 module all reason all severity nominal
| 420 | 5 | 2 - PID missing |* * 16 |alert |
| 999 | all |all | |nominal |
unnamed(configure)#
4.11.3.6 T RAP SEVERITY FILTERS

Starting from SW version 4.6.x it has been possible to filter traps by severity.
SNMP traps are generated based on internal events. Each of those events can be seen in the syslog. Every event belongs
to one of severity category: from high priority EMERGENCY to low priority DEBUG.
With the trap severity filter, you may choose which event severity level will generate traps in a similar way as the syslog’s
severity filter.
NOTE! coldStart traps will not be affected by the trap severity filters and will still be generated: only
heCommonAlarmEvent traps are affected.
To enable/disable SNMP traps of specified syslog event severity level:
Syntax:
[no] snmp-server traps level {emergency|alert|critical|error|warning|notice|information}
Keyword:

no Disables trap generation for syslog events of the specified severity level. -
Example – disable trap generation for notice –level syslog events:
unnamed(configure)# no snmp-server traps level notice

unnamed(configure)#
82
4.11.3.7 T RAP DESTINATION ADDRESS
To be able to send traps, you must specify the IP destination address for the trap messages (the address of the NMS). The
command below works incrementally, you may specify up to five trap destinations by entering each address separately.
Syntax:
[no] snmp-server host <ip_address>
Keyword & argument:

no Removes the specified trap destination.
ip_address The trap message’s IPv4 destination address in dot-decimal notation.
Example:
unnamed(configure)# configure snmp-server host 192.98.0.101

4.12 SOFTWARE UPDATE

The Luminato software is preinstalled in factory. If necessary, you may upgrade the Luminato software. However, there
are a few things to bear in mind before considering software upgrade:
• Software upgrading is a licensed feature. The license specifies which (major) releases it entitles.
• Minor (maintenance) releases do not require separate licenses
• The software license is uniquely tied to the device, meaning that the product key may be used only
in one device.
• The software is located in the chassis’ mainboard: activating a new software requires a reboot of
the chassis, thus causing a pause in service delivery unless a 1 + 1 backup system is present.
• Upgrading to a software release which the software license does not entitle to use will cause the
software to enter to an Evaluation mode.
• Consult chapter 0 below for more information on license related procedures.
4.12.1 PREREQUISITES
Depending on the chosen protocol, you will need either a TFTP or HTTP server.
To learn more, read chapter “Preparations”
4.12.2 ENTITLED SOFTWARE RELEASES

You are entitled to receive all maintenance releases for the original release and older major releases. These are signified
by having the same or smaller MAJOR version number.
Example: Luminato ships from factory with version 7.2.2, so you are entitled to receive
all 7.x.x (and older) releases: 7.2.6, 7.4.2, 7.12.5 etc.
83
The software license specifies this MAJOR number (7 in the above example). The software compares the license specified
number to its own MAJOR version number. If the license number is equal or greater than the running software number,
the software will function normally. Otherwise the device will enter the Evaluation mode.
To verify the entitled SW release version, use the show license chassis
command as described in chapter “Viewing licenses”
4.12.3 VIEWING CURRENT SW VERSION

To view the current software version and build date:
Syntax:
show version
Example:
DocumentationTest# show version

No brand 7.5.5 Release (Fri Oct 31 14:04:54 EET 2014)
DocumentationTest#
4.12.4 LOADING SOFTWARE IMAGE
To load a different software image version (SW upgrade, downgrade):
Syntax:
configure load sw <URL> [reboot]
Keyword & Arguments:

values
URL The URL pointing to the SW image file. tftp://*,http://*
reboot This optional command reboots the Luminato automatically after software update
completion.
Example:
DocumentationTest# configure load sw tftp://

10.3.4.113/Luminato-7.5.7.0.bsi.bin
1/7 SW Update Started 00%
2/7 Downloading Image 10%
3/7 Verifying Image 30%
3/7 Verifying Image 40%
4/7 Cleaning Target Partition 50%
5/7 Processing Image 60%
6/7 Finishing SW update 95%
84
7/7 SW Update Completed Succesfully100
Software Update Succesful. Waiting for reboot to complete update
NOTE! To activate the new software version, reboot the device. Use the optional ‘reboot’ keyword (see above) to
automatically reboot the device after SW update completion.
To learn how to reboot the device manually, see chapter “System reboot”
4.12.5 SOFTWARE REVERSION

Luminato features two software partitions: 0 and 1. One is active and the other is inactive. Whenever updating, the
partitions are rotated so that the last uploaded software version is always written to the inactive partition. This
mechanism ensures that you can always fall back to the software version previously used.
To revert to a previously used software version:
Syntax:
configure revert sw COMMIT
Caution! Reverting to old software version will also revert to old configuration (the last known configuration used
with old software) and the chassis will reboot, thus causing a pause in service delivery unless the 1 + 1 backup system is in
use. To learn more about 1 + 1 backup system see chapter “1+1 backup”
4.13 LICENSE MANAGEMENT

In order to allow optimal timing for investments and system applications, Luminato features a pay-as-you-grow model,
where some features are available only by purchasing a license. Also upgrading software requires purchasing a license.
Please consult the SW release notes to review the license requirements, such as HW version requirements.
Typically, the proper set of licenses is ordered altogether with the hardware and is pre-installed at factory. However, as
your business grows, additional licenses may be needed, for example, if the quantity of needed scrambled services
exceeds what the current license allows. Some licenses, such as demo licenses, are expirable and will expire after a certain
time.
4.13.1 VIEWING LICENSES
4.13.1.1 S INGLE MODULE OR CHASSIS

To view the current licenses for the chassis or a specific module:
Syntax:
show licenses {chassis|interface {1…6}}
85
Example:
DocumentationTest# show licenses interface 1

|
MODULE 1
License: A886A9FAE0E62ABDE5D96F45C4F5419CE5D96F45C4F5419CB2280F2FA265A448
S/N: HL01781206
FEATURES:
| Description | Status | Licenses | Expires
|Amount of AES scrambling channels |N/A |2 |
|Demo |N/A |1 |
|Demultiplexing |OK |1 |
|DVB Processing |OK |1 |
|DVB-S2 support |OK |1 |
|EIT demultiplexing |OK |1 |
|Multiservice Descrambling |OK |1 |
|Amount of supp. scrambling channels|N/A |10 |
DocumentationTest#
The features requiring a license are listed in the Description column.
4.13.1.2 A LL MODULES & CHASSIS

To view the current licenses for all modules and chassis:
Syntax:
show licenses
4.13.2 ORDERING LICENSES

In order to acquire a new license, you should provide us with the following information:
• the module’s hardware type (for example, LCM-B)

• the module’s serial number (for example, HL01781206)
• the module’s current license key (for example,
A886A9FAE0E62ABDE5D96F45C4F5419CE5D96F45C4F5419CB2280F2FA265A448)
• the license you wish to purchase (for example, EIT demultiplexing)
Attach the above information into your email order and send it to our local sales representative.
4.13.3 ENTERING LICENSE KEYS

Once the order handled, you will receive via email a license key for each requested license. A license key is a 64 character
long hexadecimal character string, which must be fed into the Luminato in order to unlock the requested licensed
feature(s).
To insert a license key:
Syntax:
configure license {interface {1…6}|chassis} <license_key>
86
Example:
DocumentationTest# configure license interface 1

A886A9FAE0E62ABDE5D96F45C4F5419CE5D96F45C4F5419CB2280F2FA265A448
4.14 CONFIGURATION MANAGEMENT

This section explains how the Luminato’s current configuration data is stored in memory, how to view and copy a running
configuration.
4.14.1 RUNNING CONFIGURATION

The Luminato’s functionalities are based on both hardware and software implementation: the software running in the
device contains hundreds of data objects, some of them represent the status of those functionalities while some other
represent user-configurable parameters. The current state of these specific objects is known as the running
configuration.
All submodule running configurations are stored as separate files in Luminato’s non-volatile memory, organized at the
bottom level of a three level directory tree structure (Figure 10) by module type.
chassis
slot 1 slot n slot 6
previous current
submodule submodule
submodule submodule
type "k" type "m"
type "a" type "b"
Configuration Configuration Configuration Configuration

file file file file
FIGURE 10: CONFIGURATION DIRECTORY TREE STRUCTURE. ERASING AT AN UPPER LEVEL WILL REMOVE ALL THE CONFIGURATION
FILES OF THE SUB LEVELS.
NOTE! There can be several different configuration files per slot. Luminato “remembers” the configurations of any
previous module type which have been plugged into the same slot.
The Luminato’s CLI running-config command extracts the running configuration information from the active
configuration file and outputs it as series of CLI commands, depending on the used command, either on screen or to a 8-
bit ASCII text file. The resulted configuration file may be copied, edited and run as a script file on any Luminato.
87
NOTE! The running-config file is only a representation of the actual running configuration; if you need a one-to-one
copy of the running configuration for configuration backup, you should use the configuration snapshot feature instead.
You may also take a configuration snapshot which is an exact copy of the running configuration. The generated file
contains not only the configuration files, but also all the files generated or uploaded by the user (captured tables, NIT
wizard generated table amongst other things). This file format is binary and not editable.
To start configuring, enter the configuration mode:
4.14.1.1 V IEWING
Hint: If your terminal application supports the copy & paste feature, you may select and copy directly from the
terminal application’s window the command lines of interest and paste them into a standard 8-bit ASCII text editor
(Notepad, vi, etc).
Caution! Depending on the terminal software used, using the copy & paste method may be unreliable for transferring
large number of lines in the running configuration. For transferring whole configuration from one device to another, the
copy running-config command should be used instead.
4.14.1.1.1 S TORED CONFIGURATION FILES

To view a list of all stored configuration file:
Syntax:
show modules configuration
Example:
DocumentationTest# show modules configuration

Module specific configuration:
Slot 1:
LRS-C *
Slot 2:
LRT-B *
Slot 3:
LRC-B *
Slot 4:
LCM-B *
Slot 5:
LPE-A *
LQM-C
Slot 6:
LQM-C *
88
LAS-B
DocumentationTest#
NOTE! The active configurations are marked with an asterisk.
4.14.1.1.2 W HOLE RUNNING CONFIGURATION

To view the whole running configuration:
Syntax:
show running-config
Example :
NOTE! To save document space, the session example below shows only a small portion of the show running-
config command output.
DocumentationTest# show running-config

! Thu, 13 Nov 2014 12:01:40 EET
!
!Device NO BRAND; Type LCH-D; Serial# HL00471206; HW C10; SW 7.5.7
!
!HOST configuration
!
hostname "DocumentationTest"
!
!Management port separation
!
management-port-mode separate
!
!Management port 0/1 configuration
!
interface mgmt1
ip address 10.2.14.216 255.255.252.0 10.2.15.254
mtu 1500
no shutdown
exit
!
!Management port 0/2 configuration
!
interface mgmt2
NOTE! Rows starting with an exclamation point ‘!’ are comment lines and are not executable command lines. Their
purpose is to provide additional information to the user and also to improve readability.
89
4.14.1.1.3 M ODULE RUNNING CONFIGURATION
To view the running configuration of a specific module:
Syntax:
show running-config interface <slot_number>
Arguments:

slot_number Specifies target module based on its slot location {1…6}
Example:
NOTE! To save document space, the session example below shows only a fragment of the command output.
DocumentationTest# show running-config interface 1

!
!Module 1. Type LRS-C (Dual DVB-S2 CA); Serial HL01781206; HW B12
!
!Module environment configuration
!
environment
temperature module 1 threshold 5 10 85 90
exit
!
interface 1
ip address 192.168.2.101 255.255.255.0 ge1
ip address 192.168.3.101 255.255.255.0 ge2
ip default gateway 0.0.0.0 ge1
ip default gateway 0.0.0.0 ge2
timeout pid 5
timeout warning 1
timeout service default
sid step 20
sid range 40 1320
sid upper-range 8200 8299
pid range 1340 1399
cam a routing input 1.1
cam b routing input 2.1
… (abridged)
4.14.1.1.4 I NTERFACE RUNNING CONFIGURATION

There are several alternatives for viewing the running configuration of interfaces:
• by stream direction
• by input signal type
• by signal type and stream direction (applies to a few module type)
90
4.14.1.1.4.1 BY STREAM DIRECTION
To view the running configuration of a specific interface streaming to a specific direction:
Syntax:
show running-config interface {input|output}

<slot_number>/<connector_index>.<stream_index>
Arguments:

slot_number Specifies the target module based on its slot location {1…6}
connector_index Specifies the target connector index. With IP interfaces this value is always ‘1’ {1…4}
stream_index Specifies the target stream index. {1…128}
Example:
DocumentationTest# show running-config interface input 4/1.1

!
!Interface ip input 4/1.1 configuration
!
interface ip input 4/1.1
no critical
no override-si-encoding
no redundant-stream critical
udp 239.0.17.65
port 43962
payload-port internal
description "Stream from dual DVB-S2 CA 1:1.1"
no shutdown
exit
DocumentationTest#
4.14.1.1.4.2 BY INPUT SIGNAL TYPE
To view the running configuration of a specific input interface of specific signal type:
Syntax:
show running-config interface <ip|asi|dvbs|dvbs2|dvbt|dvb-c|dvb-t2|isdb-t> input

<slot_number>/<connector_index>[.<stream_index>]
Arguments:

values
stream_index Specifies the target input stream. On physical inputs this is equivalent to the target {1…128}
demodulator index.
91
Example:
DocumentationTest# show running-config interface ip input 4/1

!
!Interface ip input 4/1.1 configuration
!
interface ip input 4/1.1
no critical
no override-si-encoding
no redundant-stream critical
udp 239.0.17.65
port 43962
description "Stream from dual DVB-S2 CA 1:1.1"
no shutdown
exit
DocumentationTest#
4.14.1.1.4.3 BY OUTPUT SIGNAL TYPE AND STREAM DIRECTION
To view the running configuration of a specific input interface of specific signal type and streaming direction:
Syntax:
show running-config interface {ip|asi|qam|cofdm} output

<slot_number>/<connector_index>.<stream_index>
Arguments:

values
stream_index Specifies the target stream index. On physical outputs this is equivalent to the target {1…128}
modulator index.
Example:
DocumentationTest# show running-config interface dvbt2 output 2/1.1

!
!Interface ip output 2/1.1 configuration
!
interface ip output 2/1.1
ts-packets 7
ttl 5
port 43962
udp 239.0.33.81
bitrate vbr
sap send optional-fields
sap send default
92
packet-format udp
no low-packet-jitter-mode
!
!Processing configuration
!
mode service
ts-id 2001
network-id 0
original-network-id 0
network-name "Network1"
pid-allocation-mode follow
DocumentationTest#
4.14.1.2 R EMOVING CONFIGURATION FILES

You may remove configuration files by module type, slot location or remove all configuration files with one command.
4.14.1.2.1 B ASED ON M ODULE TYPE & SLOT LOCATION

To remove the configuration file of a specific module type in a specific slot:
Syntax:
eraseconf module <slot_number> <module_type> COMMIT
Arguments:

slot_number Specifies the target slot location {1…6}
module_type Specifies the target module type. <string>
Example:
DocumentationTest(configure)# eraseconf module 6 LAS-B COMMIT

NOTE! Removing the configuration of an active module will cause the module to be rebooted.
4.14.1.2.2 B ASED ON SLOT LOCATION

To remove all configuration files located in a specific slot:
Syntax:
eraseconf slot <slot_number> COMMIT
93
Argument:

NOTE! Removing the configuration of an active module will cause the module to be rebooted.
4.14.1.2.3 A LL CONFIGURATION FILES

To remove all configuration files from the chassis:
Syntax:
eraseconf COMMIT
NOTE! The whole Luminato will rebooted. The management IP settings will be preserved in order to not lose
management connection.
4.14.1.3 EXPORTING THE RUNNING CONFIGURATION

You may copy the running configuration either locally into the Luminato user file folder or to a specific URL.
You may use the copied running-config file to:
• Backup the device configuration

• Make scripts out of portions of the running-config file with a text editor for simple and repetitive tasks
• Transfer whole configurations from one device to another
NOTE! You can only export the whole running configuration.
To copy and/or export the running configuration:
Syntax:
copy running-config {<file_name>|<URL>}
Arguments:

values
file_name Specifying only the target configuration file name; the file will be saved locally in the
device’s user file folder.
URL The URL pointing to the target file location. tftp://*,http://*
94
Example:
DocumentationTest (configure)# configure copy running-config tftp://192.168.200.

29/myconfig.txt
myconfig.txt 100% |*******************************| 58085 0:00:00 ETA
4.14.1.4 I MPORTING A RUNNING CONFIGURATION FILE OR A SCRIPT FILE

You may import configuration or script files (whole configurations or scripts). When importing such a file, all the
commands included in the file are automatically executed; the imported configuration is appended to the existing running
configuration.
There are two alternate methods for importing the running-config file:
• regular: continuous scanning of changes in incoming PSI/SI tables is enabled during running-config file import,
which can be slow with large configurations
• boosted: continuous scanning of changes in incoming PSI/SI tables is disabled during running-config file import,
which can considerably speed up the import process with large configurations
Hint: When importing a configuration file, the configuration is appended to the existing running configuration: if you
wish to import without preserving the existing running configuration, you will need to return the device to its factory
default settings.
To import a configuration or script file:
Syntax:
copy {<file_name>|<URL>} running-config
Arguments:

values
file_name Specifying only the target configuration file name; the file must reside in the device’s
user file folder.
Example (abridged):
DocumentationTest(configure)# copy tftp://192.168.0.98/conf_backup.txt running-config

conf_backup.txt 100% |*******************************| 6654 0:00:00 ETA
Executing row 1: ! Sat, 05 Jan 2013 22:58:52 EET
Executing row 2: ! Device : DAH
Executing row 3: ! SW version : 1.1.0
95
Executing row 4: !
Executing row 5: ! HOST configuration
Executing row 6: !
Executing row 7: configure
Executing row 8: hostname DocumentationTest
Executing row 9: !
Executing row 10: ! general cable configurations
Executing row 11: !
Executing row 13: cable rangingperiod 20
Executing row 14: cable T4timeoutmultiplier 1
Executing row 15: cable loadbalancer mode static
Executing row 16: !
Executing row 17: ! interface cable-downstream configuration
Executing row 18: !
Executing row 20: cable annex A
Executing row 21: interface cable-downstream 1 frequency 298000000
Executing row 22: interface cable-downstream 1 interleaver 128:1
Executing row 23: interface cable-downstream 1 modulation 256qam
4.14.2 CONFIGURATION BACKUP

To make a backup file of the running configuration:
Syntax:
copy configuration-snapshot {<filename>|<URL>}
Arguments:

values
file_name Specifying only the target configuration file name; the file must reside in the device’s
user file folder.
NOTE! The configuration backup file is software version locked and is not compatible with any other software
versions than the one it was created with. For example, a snapshot created with SW revision 6.2.1 won’t work with 6.2.2.
4.14.3 RESTORING FACTORY DEFAULT SETTINGS

To reset the Luminato to its factory default settings:
Syntax:
factorydefaults COMMIT
96
Keyword:

preserve-ip-settings This optional keyword preserves management IP settings.
NOTE! This command will remove all configuration files and management IP settings.
Caution! Perform a total reset to factory defaults only with a local management (USB) connection! Failing to comply
will result in lost management connection.
4.15 FILE MANAGEMENT

The file management commands allow the user to import, export and remove files from/to a user file folder located in
Luminato’s NVRAM. These can be used, for example, to back up some information for later reference: captured tables,
PSI/SI-files from PSI/SI editor, volatile syslog entries, license keys for that specific device or release notes for the current
software revision.
4.15.1 VIEWING USER FOLDER CONTENT

To view the files stored in the user file folder:
Syntax1:
dir
Syntax2:
show files
Example:
DocumentationTest# show files

show files
startup-config 0 bytes Tue Jan 1 00:00:04 2013
startupbackup.txt 6326 bytes Thu Jan 3 00:36:34 2013
x 23927 bytes Tue Jan 1 18:37:57 2013
try.txt 6654 bytes Fri Jan 4 01:25:42 2013
DocumentationTest#
4.15.2 MANAGING
To start managing files, enter the configuration mode:
97
4.15.2.1 U PLOADING
To upload a file to the Luminato:
Syntax:
copy <URL> <file_name>
Arguments:

values
file_name The uploaded file is uploaded to the local user file directory with specified file_name
applied to it.
URL The uploaded file is copied from the specified URL. The supported transfer protocols are tftp://*,http://*
TFTP and HTTP.
Example:
Here, we upload to the Luminato a file named issue_A.txt through TFTP server 192.168.0.98 and preserve the original
file name.
DocumentationTest(configure)# copy tftp://192.168.0.98/issue_A.txt issue_A.txt

issue_A.txt 100% |*******************************| 26985 0:00:00 ETA
NOTE! The following special characters are not allowed in file names: #&;`|*?~<>^()[]{}$\
4.15.2.2 D OWNLOADING
To download a file from the Luminato:
Syntax:
copy <file_name> <URL>
Arguments:

values
file_name The specified file is downloaded from the local user file directory.
URL The downloaded file is copied to the specified URL. The supported transfer protocols are tftp://*,http://*
TFTP and HTTP.
98
Example:
Here, we download from the Luminato a file named x through TFTP server 192.168.0.98 and re-label the file as
mystery_file.txt.
DocumentationTest(configure)# copy x tftp://192.168.0.98/mystery_file.txt

mystery_file.txt 100% |*******************************| 23927 0:00:00 ETA
NOTE! The following special characters are not allowed in file names: #&;`|*?~<>^()[]{}$\
4.15.2.3 D ELETING
To remove a file from the user file folder:
Syntax:
configure erase file <file_name>
Arguments:

file_name The target file’s name.
Example:
DocumentationTest(configure)# erase file startupbackup.txt

Are you sure? (y/n): y
4.16 MULTICHASSIS MANAGEMENT

If your system includes several Luminato chassis, we recommend using the Multichassis management –feature in order to
enable centralized multichassis NIT generation. This feature lets you arrange several chassis into one or several
management groups.
4.16.1 OPERATING PRINCIPLES

Multi-chassis group members are primarily identified by their IP addresses: when creating a management group you need
to specify the management IP addresses of its respective members. Single Luminato chassis can be member of only one
multi-chassis group. Group creation can be initiated in any device and takes effect in all specified members
simultaneously. Similarly, any modification to the group (name, population, identification settings) can be performed in
any group member.
In order to be able to automatically route payload IP traffic between chassis in a multi-chassis environment, Luminato
needs to know which GE ports are interconnected via an external switch network. To this end, you must provide
interconnection information by assigning the GE ports to connection groups.
99
NOTE! Currently, only the Luminato EIT processing module LPE-A is able to use automatic payload routing for
interchassis EIT information traffic. LPE-A’s EIT information ingress and egress is performed via temporary ad-hoc IP
streaming, invisible to the user.
4.16.2 CONFIGURING MULTICHASSIS MANAGEMENT GROUPS

Configuration steps:
1. Create and populate the multichassis management groups

2. Define the payload port interconnections (This step is only necessary if your multichassis configuration includes
the EIT processing module, LPE-A)
4.16.2.1 V IEWING THE MULTICHASSIS MANAGEMENT GROUP STATUS

To view the multichassis management group status:
Syntax:
show group-chassis
Example:
DocumentationTest(configure)# show group-chassis
Multichassis group 'myGroup' connection status

Chassis IP: |Status: |1+1 Backup: |Hostname: |Login as:
10.2.14.216 |Connected |Active |DocumentationTest |admin
10.2.14.217 |Connected |Active |DEMO-3 |admin
4.16.2.2 C REATING AND POPULATING MULTICHASSIS MANAGEMENT GROUPS

To create and populate a multichassis management group:
Syntax:
group-chassis <group_name> <login_name>:<password>@<IP_address>
Arguments:

group_name Multichassis group name <string>
login_name Admin level login name for the specified group member <string>
100
password The login password associated to the specified login name <string>
IP_address The management IP address of target group member IPv4 address in dot-decimal notation
NOTE! You may insert several members at once by separating each entries with a comma, e.g. configure group-
chassis admin:superuser@10.2.14.216, admin:megauser@10.2.14.217, admin:hyperuser@10.2.14.218
Example:
We want to create a multichassis management group labelled “myGroup” and populate it with the localhost and host
10.2.14.217:
DocumentationTest(configure)# configure group-chassis myGroup

admin:admin@10.2.14.216,admin:admin@10.2.14.217
NOTE! Management port’s IP address cannot be modified if it is member of a multichassis management group. You
must first remove it from the group in order to be able to modify it.
To learn how to change the management port settings, see chapter “IP address, netmask & default gateway”.
4.16.2.3 R EMOVING MANAGEMENT GROUP MEMBERS

To remove a member from a management group:
Syntax:
no group-chassis <group_name> <IP_address>
Arguments:

group_name Multichassis group name <string>
IP_address The management IP address of target group member IPv4 address in dot-decimal notation
NOTE! You may remove several members by giving a comma-separated IP address list of the target members, e.g.
configure no group-chassis myGroup 10.2.14.217,10.2.14.217
Example – Removing host 10.2.14.217:
DocumentationTest(configure)# no group-chassis myGroup 10.2.14.217

101
4.16.2.4 R EMOVING MANAGEMENT GROUPS
To remove a management group:
Syntax:
no group-chassis
4.16.2.5 D EFINING MULTICHASSIS PAYLOAD PORT INTERCONNECTIONS

To assign payload ports to a payload connection group:
Syntax:
group-chassis payload-group {1…4} <group_name>

<mgmt_IP_address_1>:ge{1|2}[,<mgmt_IP_address_2>:ge{1|2}]…[,<mgmt_IP_address_(k+1)>:ge{1|2
}]…[,<mgmt_IP_address_n>:ge{1|2}]
Keyword & arguments:

group_name Payload connection group name <string>
mgmt_IP_address_n The management IP address of n target group members. Notice the IPv4 address in dot-
comma as a separator for several entries. decimal notation
ge The GE payload port accessible to other payload group members. -
Example:
We have a multichassis system with 2 chassis interconnected: 10.2.14.216 and 10.2.14.217. Their payload ports are
interconnected through GE1. We label this connection group myPayload1.
DocumentationTest(configure)# group-chassis payload-group 1 myPayload1

10.2.14.216:ge1,10.2.14.217:ge1
4.16.2.6 V IEWING PAYLOAD CONNECTION GROUP PORT ASSIGNMENTS

To view the payload connection group port assignments:
Syntax:
show group-chassis payload-group
Example:
DocumentationTest(configure)# show group-chassis payload-group

Chassis IP |myPayload1 | | |
10.2.14.216 |ge1 |- |- |-
10.2.14.217 |ge1 |- |- |-
102
4.16.2.7 R EMOVING A PAYLOAD CONNECTION GROUP MEMBER
To remove a member from a connection group:
Syntax:
no group-chassis payload-group {1…4}

<mgmt_IP_address_1>:ge{1|2}[,<mgmt_IP_address_2>:ge{1|2}]…[,<mgmt_IP_address_(k+1)>:ge{1|2
}]…[,<mgmt_IP_address_n>:ge{1|2}]
Keyword & arguments:

mgmt_IP_address_n The management IP address of n target group members. Notice the IPv4 address in dot-
comma as a separator for several entries. decimal notation
ge The GE payload port accessible to other payload group members. -
Example:
DocumentationTest(configure)# no group-chassis payload-group 1 10.2.14.217:ge1

4.16.2.8 D ELETING A PAYLOAD CONNECTION GROUP

To delete a payload connection group:
Syntax:
no group-chassis payload-group {1…4}
4.17 SESSION ANNOUNCEMENT PROTOCOL SETTINGS

This chapter introduces the session announcement feature, which when enabled makes service routing configuration
much easier. First, we will briefly explain what are the Session Announcement Protocol (SAP) and the related Session
Description Protocol (SDP). Then, we will explain how to configure the SAP settings.
4.17.1 OVERVIEW
4.17.1.1 SAP
1
Session Announcement Protocol (SAP) is an IETF issued experimental protocol for advertising multicast sessions and
transmitting periodically session descriptions to a well-known multicast address and port. SAP listening applications
construct a guide of all advertised multicast sessions.
1
RFC 2974
103
4.17.1.2 SDP
1
The SAP typically uses the IETF standard Session Description Protocol (SDP) . SDP is a protocol used for describing
multimedia sessions such as media type, format and all associated properties. The SDP session description is plain UTF-8
encoded text.
A SDP session description contains two sections:
• Session level
• Media level
4.17.2 SAP AND SDP IN LUMINATO
With the SAP and SDP feature, the devices in the system can “see” a list of multicast streams that are available from other
rd
devices: Luminato sends SAP messages to announce its SPTS/MPTS streams so that 3 party equipment can see a list of
available streams. Luminato may also vice versa receive SAP messages to form a list of the advertised multicast sessions
making easier the creation of IP inputs and service routing.
In Luminato, the SAP multicast host group is defined at chassis level. SAP announcement can be globally enabled or
disabled on chassis level and overridden for each output IP stream separately.
Some of the announcement fields are automatically generated. In addition to the automatically generated SDP fields, you
may also insert manually additional SDP session description fields.
4.17.3 CONFIGURING
The configuration procedure consists of the following steps:
4.17.3.1 V IEWING THE SAP SETTINGS

To view the current SAP configuration:
Syntax:
show sap
Example:
DocumentationTest(configure)# show sap

SAP/SDP
Host group: 239.255.255.255
Announcement interval: 10
1
RFC 4566
104
4.17.3.2 G ROUP ADDRESS
The SAP messages are transmitted to and received from a multicast group address (SAP multicast host group). The factory
default address is 239.255.255.255.
To specify the target multicast destination IP address for SAP announcements:
Syntax:
sap host-group <ip_address>
Arguments:

values
ip_address IPv4 multicast group address in dot-decimal notation. The SAP messages are transmitted
to and received from this address
Example:
DocumentationTest(configure)# sap host-group 239.255.255.255

NOTE! SAP multicast address should be within the same scope as the multicast sessions that are being announced to
ensure the recipients of the announcements are within the scope of the sessions the announcements describe.
4.17.3.3 A NNOUNCEMENT INTERVAL

The time period between repetitions of an announcement is chosen such that the total bandwidth used by all
announcements on a single SAP group remains below a preconfigured limit.
1
The recommended SAP announcement interval may be calculated by using the following formula :
• Interval (s) = (8 * number_of_announcements * announcement_size_in_bytes) /

bandwidth_limit_in_bits_per_second)
• Luminato’s maximum interval is 300 s
To set the SAP announcement interval (in seconds):
Syntax:
sap interval {1…300}
1
RFC 2974
105
Example – interval 10 seconds:
DocumentationTest(configure)# sap interval 10

4.17.3.4 SDP SESSION DESCRIPTION FIELDS

When the SAP feature is enabled, Luminato generates automatically the following SDP session description fields using
UTF-8 character encoding:
Session-level section:
v=0
o=<session_id> <version> IN IP4 <interface_ip>
s=<session_name>
c=IN IP4 <host_group>
t=0 0
Media-level section (none or one):
m= <service_type> <port> <proto> <fmt>
, where
session_id = 1000000 * chassis_index+10000 * slot_index + outputinterface_index
version= Increased every time the SDP session description is modified
interface_ip = IP address of the originator of the session (or virtual address if in use)
host_group = Multicast host group address of a stream
session_name = Service name for SPTS, Alias name for MPTS if exists, “Stream-
239.0.0.1:1234” if alias is empty.
service_type = always “video” for MPTS streams, “video” or “audio” for SPTS streams
port = Destination UDP port
proto = “UDP” or “RTP/AVC” depending on the IP output mode
fmt = “33” (= transport stream)
In addition to the automatically generated SDP fields, you may also insert manually additional SDP fields.
106
NOTE! Chassis level additional fields are inserted into the SDP session description of all IP outputs in addition to the IP
stream level additional fields.
4.17.3.4.1 M ANUAL SDP FIELDS – CHASSIS LEVEL

To insert manually SDP description fields at chassis level (field common to all streams for example, email, phone number
etc.): Use the description format defined in RFC 4566.
Syntax:
sap send optional-fields {SDP_fields}
The SDP session description fields’ definitions fall out of scope of the present
document, refer to RFC 4566 for more detail.
Example – insert URI and email SDP fields:
DocumentationTest(configure)# sap send optional-fields "u=http://acme.com/;e=elmer@acme.com"

4.17.3.4.2 M ANUAL SDP FIELDS – STREAMER LEVEL

To insert manually SDP description fields at streamer level (field common to all streams for example, email, phone number
etc.). Use the description format defined in RFC 4566.
Syntax:
interface {asi|ip|qam|cofdm} output <slot_number>/<connector_index>.<stream_index> sap

send optional-fields {SDP_fields}
The SDP session description fields’ definitions fall out of scope of the present
document, refer to RFC 4566 for more detail.
4.17.3.5 E NABLING / DISABLING CHASSIS LEVEL SESSION ANNOUNCEMENT

When SAP announcement is enabled on chassis level, all IP output streams will be included in the SAP announcement.
Individual streams may be excluded from the SAP announcement via the IP streamer settings. Accordingly, when chassis
level SAP announcement is disabled, you may enable SAP announcement for individual IP output streams via the IP
streamer settings.
To enable chassis level session announcement:
Syntax:
[no] sap send
107
Keyword:

values
no This optional keyword will disable the session announcement at chassis level. You may override
this setting in the IP streamer settings
4.17.3.6 E NABLING / DISABLING STREAMER LEVEL SESSION ANNOUNCEMENT

When SAP announcement is enabled on chassis level, all IP output streams will be included in the SAP announcement.
Individual streams may be excluded from the SAP announcement via the IP streamer settings. Accordingly, when chassis
level SAP announcement is disabled, you may enable SAP announcement for individual IP output streams via the IP
streamer settings.
To override the chassis level session announcement settings:
Syntax:
interface {asi|ip|qam|cofdm} output <slot_number>/<connector_index>.<stream_index> [no]

sap send
Arguments & keyword:

no This optional keyword will disable session announcement for the target IP streamer.
Example – disable session announcement for interface 2/1.1:
DocumentationTest(configure)# interface ip output 2/1.1 no sap send

DocumentationTest(iface-ip-output-2/1.1)#
To return the IP streamer to the chassis level session announcement settings:
Syntax:
interface {asi|ip|qam|cofdm} output <slot_number>/<connector_index>.<stream_index> sap

send default
Example – restoring the chassis level SAP settings for interface 2/1.1:
DocumentationTest(configure)# interface ip output 2/1.1 sap send default

108
4.17.3.7 E NABLING / DISABLING SESSION ANNOUNCEMENT RECEPTION
Luminato is able to receive SAP session announcements for easier service routing through the web UI.
To enable SAP session announcement reception:
Syntax:
[no] sap receive
Keyword:

no This optional keyword will disable session announcement reception
NOTE! Technically, all inserted output modules join the user configured SAP multicast host group and are listening to
incoming SAP messages using an internal IP input hidden from the user. That is why at least one output module is
required in order to be able to use the SAP reception feature.
NOTE! In order to be able to receive SAP announcements with VLANs, you must first allocate module slot payload IP
addresses to the target VLANs. By default, the VLAN payload IP addresses are undefined right after VLAN creation.
To learn how to allocate VLAN payload IP addresses, see chapter
4.18 CONDITIONAL ACCESS PRELIMINARY CONFIGURATION

Luminato offers DVB SimulCrypt compliant content protection. You can control the conditional access in order to manage
the service offering to your subscribers.
The present chapter describes the compulsory procedures for setting up the CAS
connections for ECMs and EMMs, laying groundwork for service scrambling. The actual
procedures for service scrambling are introduced in chapter 6.10.3
109
4.18.1 DVB-CSA BASED CONDITIONAL ACCESS SYSTEMS
FIGURE 11: LUMINATO DVB SIMULCRYPT CONTENT PROTECTION
4.18.1.1 S IMUL C RYPT SYNCHRONIZER

Luminato’s DVB SimulCrypt scrambling solution is embedded. It doesn’t require any additional hardware. A SimulCrypt
synchronizer is built into the chassis to create an interconnection between the Conditional Access System servers (CAS
servers) and the DVB Common Scrambling Algorithm scramblers embedded in the Luminato sub modules.
4.18.1.2 C ONTROL WORD

An IP connection is established between Luminato and CAS server(s). The Luminato chassis’ Control Word Generator
(CWG) generates 64-bit secret keys called Control Words (CW) in cycle length determined by a user set Crypto Period (CP)
value (typically 10 seconds).
4.18.1.3 E NTITLEMENT C ONTROL M ESSAGE

The CWs are passed on by the SimulCrypt Synchronizer (SCS) to the CAS server’s Entitlement Control Message Generator
(ECMG) and to the sub module’s embedded DVB-CSA (Common Scrambling Algorithm) scrambler. The stream components
are scrambled using the CWs. The ECMG generates an Entitlement Control Message (ECM) which carries the CWs
encrypted and attached to a CP identifier. It also contains other CA related information and is used for descrambling the
stream in the receiving end of the network (STB’s or sub headends).
4.18.1.4 E NTITLEMENT M ANAGEMENT M ESSAGE

Entitlement Management Messages (EMM) are also generated in the CAS server’s EMMGs and injected directly into the
transport streams altogether with the CA Tables (CAT). EMMs specify, amongst other things, authorization levels of
subscribers or group of subscribers for services or events. They also carry the key for CW decryption; this key is itself
encrypted using a master key common to both the CAS server and the CA Module (CAM) or the CA smart cart card
inserted in the CAM.
110
The EMM messages are issued much less frequently than ECMs and are subscriber specific; subscriber identification is
done through a smart card in the receiver. Without proper EMMG issued authorization the receiver won’t decrypt the
CWs and descramble the stream.
4.18.1.5 S UPPORTED MODULES

Most input and output modules support the scrambling feature, however the following modules do not support DVB-CSA -
scrambling:
• LAS-B
• LQM-B
• LCM-A
• LCM-B
4.18.2 AES BASED CONDITIONAL A CCESS SYSTEMS

The Advanced Encryption Standard (AES) is an encryption algorithm based on the Rijndael cipher. The standard was issued
by National Institute of Standards and Technology (NIST), an agency of the United States and is also included in the
ISO/IEC 18033-3 standard.
In the context of digital video distribution, AES scrambling is mainly used for service encryption in IPTV (Internet Protocol
TeleVision) distribution. Typically, the CAS architecture in IPTV distribution differs from the one in traditional digital video
broadcasting. The main difference is that the entitlement messages (EMMs) are not usually included in the transporting
stream: the authorization to decrypt services is typically negotiated directly with CAS servers.
FIGURE 12: TYPICAL CAS ARCHITECTURE USED IN IPTV DISTRIBUTION.
Our AES implementation features three AES modes: CBC and two ECB variants. AES is intended to be used in CAS systems
based on ECMs and the SimulCrypt interface. Due to the complex nature of the subject, the detailed description AES
scrambling algorithms are not within the scope of the present document.
The SimulCrypt interface and ECMs are explained from chapters 0 to 0. See also
figure Figure 11.
111
To learn more details about AES, see the AES standard and the ISO/IEC 18033-3
standard.
4.18.3 EMBEDDED LYNK DRM SERVER

In traditional CA systems, the EMMGs and ECMGs are typically located in an external server thus exposing the CA
communication between the CA servers and Luminato to potential unauthorized interception. With Luminato you may use
TM
the optional Samsung’s LYNK DRM embedded server which removes the need of an external server hence reducing the
risk of unauthorized access to protected content.
TM
Samsung LYNK DRM (Digital Rights Management) is a fully software-based digital conditional access CAS solution: the
LYNKTM DRM server resides in Luminato and does not require any additional hardware or separate chipsets.
TM TM
Samsung LYNK DRM uses AES128-CBC encryption without padding. Once the embedded LYNK DRM server has been
enabled and the required licenses successfully activated, an ECMG and EMM stream will be automatically configured.
4.18.3.1 L ICENSE REQUIREMENTS

TM
The embedded LYNK DRM server is a double licensed feature and won’t available until you purchase and activate the
related license keys:
• Luminato’s Lynk DRM license key to activate the server
To learn how to manage licenses, see chapter “License management”
TM TM
• Samsung’s LYNK DRM license key to allow the descrambling of LYNK DRM scrambled
services in STBs or TVs. Requires activation.
TM
The LYNK DRM license can be activated two ways:
• online: requires Internet access from MGMT1 or MGMT2. The license activation key is
automatically retrieved from Samsung’s server.
• offline: requires activation key. The activation key is acquired from your Samsung’s sales
services.
4.18.3.2 H ARDWARE REQUIREMENTS

TM
LYNK DRM encryption (=AES-CBC encryption) is available for the following modules:
• LAS-C
• LAS-D
• LRX-X
• LQM-A/C
• LIM-A
• LIC-A
112
4.18.3.3 TV OR STB SYSTEM REQUIREMENTS
TM 1
Make sure your TV or STB system meet Samsung’s LYNK DRM requirements :
Hardware:
• Support for greater than 600 MHz CPU

• Support for greater than 512 MB RAM
• Support for greater than 1 GB HDD or flash drive
Software:
• Support for Simulcrypt Protocol (Chapters 4, 5 and 6 of DVB Simulcrypt Specifications)

• Support for AES128-CBC encryption without padding
• Support for hardware descrambling
4.18.3.4 C ONFIGURING
DocumentationTest# configure cas lynkdrm

DocumentationTest(lynkdrm)#
4.18.3.4.1 E NABLING & DISABLING THE SERVER

TM
To enable or disable the embedded LYNK DRM server:
Syntax:
[no] shutdown
Keywords:

no no shutdown = Enable server
4.18.3.4.2 O NLINE LICENSE ACTIVATION

The online license activation mode is the typical scenario: the license activation key is automatically retrieved from
Samsung’s server through an Internet connection in either MGMT1 or MGMT2.
To activate the LYNKTM DRM license online:
Syntax:
activate online <company_name> <company_address> <email> <phone> <license_key>
1
Requirements subject to modifications. Consult Samsung’s tech support for up to date information.
113
NOTE! You will be able to activate the license only when the embedded LYNK DRM server has been enabled and fully
started.
To learn how to enable the server, see chapter “Enabling & disabling the server”
4.18.3.4.3 O FFLINE LICENSE ACTIVATION

The offline license is obviously the only option when Internet access through either MGMT1 or MGMT2 is not possible. In
this case, you must acquire the license activation key through your Samsung contact person.
When requesting the license activation key from your Samsung contact person, you will need to provide him/her with the
HW unique key displayed with the show cas lynkdrm -command. The activation key links the hardware unique key to
the license key thus binding the license to this specific chassis.
NOTE! You will be able to to activate the license only when the embedded LYNK DRM server has been enabled and
fully started.
To learn how to enable the server, see chapter “Enabling & disabling the server”
To activate the LYNKTM DRM license offline:
Syntax:
activate offline <license_key> <activation_key>
4.18.3.4.4 L ICENSE DEACTIVATION

TM
To deactivate the LYNK DRM license online/offline:
Syntax:
deactivate {online|offline} <license_key>
4.18.3.4.5 V IEWING SERVER STATUS

TM
To view the status of the embedded the embedded LYNK DRM server:
Syntax:
show cas lynkdrm
Example:
DocumentationTest(lynkdrm)# show cas lynkdrm

Result: Success
License Activated: false
Server Online: false
Start Date:
Expire Date:
114
Max Clients:
HW Unique Key: 4BAC51EF83BA6EA4
License Key:
Deactivation Key:
Message: License key is not supplied.(Activation key not verified)
DocumentationTest(lynkdrm)#
4.18.4 LUMINATO CAS INTEROPERABILITY
Luminato’s DVB SimulCrypt content protection solution is designed in accord with the DVB standards. Therefore all CA
system that is designed strictly according to these standards should be compatible with Luminato. Contact our customer
support services for latest list of tested CA systems.
NOTE! Both EMM TS packet and section formats are supported from release 3.1.23 onwards.
4.18.5 CA SYSTEM REQUIREMENTS

• Luminato software 6.2.x and above
o SimulCrypt synchronizer (SCS) license in the chassis to enable communication between the
Luminato chassis and CAS system
• scrambling channels license in the sub modules for service encryption
o this license is scalable in three incremental steps to adapt to the operators needs
For more details on licenses, refer to chapter License management.
• Ensure that your Luminato and CA system ECM generator/EMM injector IP network settings are
properly configured.
To learn how to configure management ports, refer to chapter Management

interface IP settings.
• Have the following CA system related information available (usually provided by CA system
vendor):
o Super CAS ID
o Access criteria's
o SimulCrypt protocol version
o ECMG IP-address and port
o EMM client ID, data ID, port number and required EMM bandwidth.
o Data type
4.18.6 GENERAL CA SETTINGS
This chapter explains the configuration procedures for conditional access settings of general nature:
• CA descriptor’s PMT loop location

• Scrambling presets
115
4.18.6.1 S CRAMBLING PRESETS
4.18.6.1.1 G ENERAL
As per ISO/IEC 13818-1 specification, packets may be scrambled either at PES (Packetized Elementary Stream) level or at
TS level. In Luminato, you may define which PES are scrambled either on stream type basis by selecting from one of the
1
predefined PES type ID sets or by defining the PID(s) of the target PES(s). In the UI, the PESs are referred to as
components.
4.18.6.1.2 C ONFIGURING
To make service scrambling configuration easier, output service scrambling is based on user-configurable presets. These
presets define which component types are scrambled for newly created output services.
NOTE! Changing the component scrambling presets does not change the settings of existing services, unless explicitly
applied to all scrambled services!
4.18.6.1.3 V IEWING THE CURRENT COMPONENT SCRAMBLING PRESETS

To view the current component scrambling presets:
Syntax:
show presets
Example:
DocumentationTest(interface 3)# show presets

CHASSIS WIDE PRESETS:
Components to be scrambled: 128,audio-ac3,teletext,video
DocumentationTest(interface 3)#
4.18.6.1.4 D EFINING COMPONENT SCRAMBLING PRESETS

To define the component scrambling presets:
Syntax:
configure presets scramble components {all|video|audio-

ac3|ac3|subtitle|teletext|<stream_type_ID>}
NOTE! You may specify several component types by entering them as a comma separated list (see the example
below).
1
The predefined type sets are based on the ISO/IEC 13818-1 stream type assignments
116
Keywords:

values
all All program (=service) components (ES) will be scrambled
video All ESs which contain video will be scrambled
audio-ac3 All ESs which contain non Dolby AC3 audio will be scrambled
ac3 All ESs which contain Dolby AC3 will be scrambled
subtitle All ESs which contain subtitles will be scrambled
teletext All ESs which contain teletext will be scrambled
stream_type_ID All ESs which are tagged with the specified stream_type identifier will be scrambled. {0…255}
Enter the value in decimals.
1
NOTE! If you entered the elementary stream type ID 6 (ES packets containing private data) , subtitles, teletext and
AC3 audio will also be scrambled, since the elementary stream type of those streams is ES packets containing private data.
Example – scrambling preset to scramble video, non AC3 audio, teletext and ES ID 128 (=0x80):
DocumentationTest(configure)# presets scramble components video,audio-ac3,teletext,128
4.18.6.1.5 A PPLYING THE PRESETS TO ALL SCRAMBLED OUTPUT SERVICES

Changing the component scrambling presets does not change the settings of existing services, unless explicitly applied to
all scrambled services.
To apply the component scrambling presets to all scrambled services:
Syntax:
configure presets scramble apply-to-all COMMIT
4.18.6.2 CA DESCRIPTOR ’ S PMT LOOP LOCATION

By default, the CA descriptor will be located at program level if ALL service components are scrambled; otherwise CA
descriptor will be located at component level and will exist only for components which are scrambled. However, not all
STBs are strictly standard compliant and they may not be able to find CA descriptors at the default locations. In such case,
you may force the ca_descriptors into a certain location in the PMT tables. The forced ca_descriptor location is a per-
module setting.
To force the CA descriptor into a specific location in the PMT:
Syntax:
configure interface {1…6} ca-descriptor-mode {default|es|program|program-es}
1
ISO/IEC 13818-1
117
Keywords:

values
default The CA descriptor will be located at program level if ALL service components are scrambled;
otherwise CA descriptor will be located at component level and will exist only for
components which are scrambled
es The CA descriptor is always located at the ES level of the PMT.
program The CA descriptor is always located at the program level of the PMT.
program- The CA descriptor is always located in both ES and program levels of the PMT.
es
Example: Place the CA descriptor in program and ES levels of the PMT
DocumentationTest# configure interface 3 ca-descriptor-mode program_es

4.18.6.3 E XTENDED CRYPTO PERIOD

In some special applications, a significantly longer CP duration may be useful, for example, in a hotel video network where
the customer is charged pay TV fees on 24 hour basis. In this use case, it would be convenient to set the CP duration
(Crypto period) to 1440 minutes (24h) so the CW would change only once a day.
The Luminato proprietary Extended CP setting change the way the CP duration value is interpreted as minutes instead of
seconds, for example the default CP value 10 s will turn into 10 min.
To enable/disable extended CP:
Syntax:
configure cas [no] extended-cp
Keyword:

no This optional keyword will disable the extended CP function.
To learn how to configure the CP of an ECMG, see chapter “Crypto period”
Example – ECMG 1’s CW changes every 24h:
DocumentationTest(cas)# extended-cp
DocumentationTest(cas)# ecmg 1 cp 1440
DocumentationTest(cas)#
Caution! Please bear in mind that the Extended CP violates the DVB standards and should be used with caution to
avoid any compatibility issues.
118
4.18.6.4 S CRAMBLING ALGORITHM
4.18.6.4.1 O VERVIEW
You may define the scrambling algorithm at three different levels:
• Chassis level: acts as the chassis wide default scrambling algorithm

• Module level: bypasses the chassis level setting
• ECMG level: bypasses the chassis and module level settings
This chapter shows how to define scrambling algorithm at chassis and module level.
To learn how to bypass the chassis and module level scrambling algorithm at
ECMG level, see chapter “Scrambling algorithm”
Luminato supports several scrambling algorithms:
• DVB-CSA/TS:
o DVB-CSA V2 compliant TS level scrambling algorithm
o 64-bit keys
• AES-CBC (Figure 13):
o AES with chained cipher blocks. Each block of plaintext is XORed with the previous
ciphertext block before being encrypted. Each ciphertext block depends on all plaintext
blocks processed up to that point. If the payload is not a multiple of 16, the last short block
(n-bits long) is encrypted by encrypting the ciphertext of the last full block and XORing the
leftmost n-bits of the resulting ciphertext with the plaintext short block.
o the safest block cipher mode in Luminato
o 128-bit keys
119
FIGURE 13: AES-CBC
• AES-ECB1 (Figure 14):

o Electronic codebook (ECB) mode1. The payload is divided into blocks and each block is
encrypted separately. Up to 15 bytes remainder are in clear at the end of the packet.
o 128-bit keys
120
FIGURE 14: AES-ECB1
• AES-ECB2 (Figure 15):

o Electronic codebook (ECB) mode2. The payload is divided into blocks and each block is
encrypted separately. Up to 15 bytes remainder are in clear at the beginning of the packet.
o 128-bit keys
121
FIGURE 15: AES-ECB2
Caution! The disadvantage of ECB is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus,
it does not hide data patterns well.
• AES-CBC-CISSA
• AES-CBC-IDSA
4.18.6.4.2 C HASSIS WIDE DEFAULT

To set chassis wide default scrambling algorithm:
Syntax:
configure scramble-mode {dvb-csa-ts|aes-cbc|aes-ecb1|aes-ecb2|aes-cbc-cissa|aes-cbc-idsa}
122
4.18.6.4.3 M ODULE LEVEL DEFAULT
To set the scrambling mode at module level:
Syntax:
configure interface <slot_number> scramble-mode {default|dvb-csa-ts|aes-cbc|aes-ecb1|aes-

ecb2|aes-cbc-cissa|aes-cbc-idsa}
Keyword & argument:

default Use the chassis wide default scrambling mode at module level. -
4.18.7 ECM GENERATOR CONFIGURATION
This chapter describes the necessary steps to set up a connection between Luminato and the CA system’s ECM generator.
TM
NOTE! If you use the embedded LYNK DRM server and it has been enabled and the required licenses successfully
activated, an ECMG will be automatically configured and enabled; you do not need to configure one separately.
See chapter “Embedded LYNK DRM server”
4.18.7.1 CAS CONFIGURATION MODE

Enter CAS configuration mode:
DocumentationTest# configure cas

4.18.7.2 C REATING AN ECMG ENTRY

As a first step you need to create an ECMG profile entry which will be used to refer to the actual ECM generator.
To create an ECMG profile:
Syntax:
ecmg <ECMG_index> [description <alias_str>]
Arguments:

ECMG_index Index referring to the ECMG profile {1…8192}
alias_str An optional descriptive alias for the ECM generator Character string
123
Example – Create an ECMG entry labelled MyECMG:
DocumentationTest(cas)# ecmg 1 description MyECMG

DocumentationTest(ecmg 1)#
4.18.7.3 ECMG PROFILE PARAMETERS

Once an ECMG profile entry has been created, you may enter the parameters defining the ECMG. This subchapter
describes the commands used to define these parameters.
4.18.7.3.1 ECMG CONFIGURATION MODE

To enter ECMG configuration mode:
Syntax:
ecmg <1…8192>
Example – ECMG 1:
DocumentationTest(cas)# ecmg 1
4.18.7.3.2 P RIMARY ECMG IP ADDRESS AND PORT NUMBER

To specify the IP address and port number of the primary ECMG for the target ECMG profile:
Syntax:
ip address <IP_address>:<port>
Arguments:

values
IP_address Primary ECMG’s IPv4 address in dot-decimal notation (immediately followed by a slash
‘/’ character if in CIDR notation)
port ECMG’s TCP/UDP port. {1…65535}
Example:
DocumentationTest(ecmg 1)# ip address 10.2.14.101:12704

NOTE! CAS redundancy can be used only when the unit is configured to Standalone role, i.e. CAS redundancy will not
be used together with 1+1 backup configuration. In a 1+1 backup context, the Spare IP address and Spare port have a
special function.
To learn how to configure ECMGs in 1 + 1 backup environment, see chapter “CAS”.
124
4.18.7.3.3 C HANGING THE PRIMARY ECMG PORT NUMBER
To change the port number of the primary ECMG:
Syntax:
port <port>
Arguments:

4.18.7.3.4 S ECONDARY ECMG IP ADDRESS AND PORT

As a fail-safe precaution, you may want to configure a secondary ECMG to the same ECMG profile. In case of a failure of
the primary ECMG, the secondary ECMG will be taken into use.
To specify the IP address and port number of the secondary ECMG:
Syntax:
spare ip address <IP_address>:<port>
Arguments:

values
IP_address Secondary ECMG’s IPv4 address in dot-decimal notation (immediately followed by a
slash ‘/’ character if in CIDR notation)
NOTE! ECMG redundancy can be used only when the unit is configured to Standalone role: ECMG redundancy will not
be used together in a 1+1 backup configuration. In a 1+1 backup context, the spare IP address and spare port have a
different meaning.
To learn how to configure ECMGs in 1 + 1 backup environment, see chapter “CAS”.
4.18.7.3.5 C HANGING THE SECONDARY ECMG PORT NUMBER

To change the port number of the primary ECMG:
Syntax:
spare port <port>
125
Arguments:

4.18.7.3.6 S UPER CAS ID

The Super CAS ID is a 32 bit hexadecimal identifier to identify the used CA system. It is the combination of the
CA_system_id and the CA_subsystem_id
To specify the Super CAS ID (in hexadecimal):
Syntax:
super-cas-id <identifier>
Example:
DocumentationTest(ecmg 1)# super-cas-id 0x56010000

4.18.7.3.7 C HANNEL ID
A channel represents an open TCP/UDP connection between an ECMG and the SCS. A single open connection can have
only one channel. The channel ID identifies uniquely such a channel.
To specify the channel ID for the target ECMG:
Syntax:
channel-id {1…65535}
Example:
DocumentationTest(ecmg 1)# channel-id 2

Caution! Take care to allocate unique channel ID numbers!
NOTE! If no channel ID is manually specified, Luminato will automatically allocate one.
126
4.18.7.3.8 C RYPTO PERIOD
The Crypto Period (CP) is the period when a specific Control Word is being used by a scrambler.
To define the crypto period duration of the target ECMG (in seconds):
Syntax:
cp {1…65535}
Example – CP duration 10 s:
DocumentationTest(ecmg 1)# cp 10
Hint: The recommended value is 10 s. Long CPs will result in less information overhead, but will also allow more time
for hacking.
1
NOTE! The DVB standards define the nominal_CP_duration parameter as a 16 bit unsigned integer n x 100 ms, so the
standard compliant maximum CP length is 6553,5 seconds.
To use CP durations longer than the maximum standard compliant CP duration limit, see chapter
“Extended crypto period”
4.18.7.3.9 S IMUL C RYPT PROTOCOL VERSION

Since there are several protocol versions for the ECMGSCS interface, protocol version information is passed in each
message to avoid any compatibility issues.
To specify the ECMG protocol version:
Syntax:
version <ver>
1
ETSI TS 103 197
127
Argument:

ver ECMG’s protocol version. The versions are defined in the Simulcrypt standards below: {1…4}
V1: TS 101 197 v 1
V2: TS 103 197 v1.2.1
V3: TS 103 197 v1.3.1
V4: TS 103 197 V1.4.1
Example – Simulcrypt protocol version 3:
DocumentationTest(ecmg 1)# version 3

Caution! Please bear in mind that the Extended CP violates the DVB standards and should be used with caution to
avoid any compatibility issues.
4.18.7.3.10 S CRAMBLING ALGORITHM

To set the scrambling mode at ECMG level:
Syntax:
scramble-mode {dvb-csa-ts|aes-cbc|aes-ecb1|aes-ecb2}
4.18.7.3.11 E NABLING / DISABLING ECMG CONNECTION

Enabling an ECMG profile should establish a connection between the CAS server and Luminato.
To enable/disable an ECMG connection:
Syntax:
[no] shutdown
Keywords:

no no shutdown = Enable connection
Example – enable ECMG 1:
DocumentationTest(ecmg 1)# no shutdown

128
4.18.7.3.12 ECM STREAM PRIVATE BYTES
1
CAS private data may be conveyed in the PMT’s CA descriptor private_data_byte . It is up to the implemented CAS if such
private information is to be used.
To insert ECM stream related private data in the CA descriptor (in hexadecimals) of all ECM streams originating from the
target ECMG:
Syntax:
privatebytes <string>
Example – insert CA private data ‘0x1234’ for all ECM streams from ECMG 1:
DocumentationTest(ecmg 1)# privatebytes 0x1234

4.18.7.4 R EMOVING AN ECMG ENTRY

To remove an ECMG profile:
Syntax:
configure cas no ecmg {1…8192}
4.18.8 MONITORING AND TROUBLESHOOTING ECMGS

To monitor an ECMG or all ECMGs:
Syntax:
show cas ecmg {all|1…8192}
Example – monitor EMG 1:
DocumentationTest(cas)# show cas ecmg 1

Description: MyECMG
Super CAS ID: 0x56010000
IP Address: 10.2.14.101
Port: 12704
Scramble mode: AES-ECB1
Spare IP address: 0.0.0.0

Spare port: 0
Uptime: 460
Connection counter: 1
Status: OK
1
ISO/IEC 13818-1 ed. 2.0, table 2-51
129
Channel test sent: 23
Test reply: 23
Error reply: 0
Last error time:
Last error code: 0
Number of active ECM streams: 0
Channel ID: 2
Protocol version: 3
Section ts packet flag: true
AC delay start: 0
AC delay stop: 0
Delay start: 0
Delay stop: 0
Transition delay start: 0
Transition delay stop: 0
ECM repeat period: 250
Max streams: 0
Min CP duration: 50
Lead CW: 1
CW per message: 2
Max comp time: 2000
Default cryptoperiod: 1440
Status, Channel ID and Uptime are self-explanatory.
Lead CW and CW per message are CW_provision’s parameters. Their value depends totally on the chosen CAS
implementation and is to be considered as fixed: in Luminato there is one lead CW and two CWs per message. In practice,
this means that each ECM issued to Luminato always contains the CWs of the current and next CP (Error! Reference
source not found.).
Max streams depends on the CAS implementation, for example Irdeto CAS doesn’t provide information about the
maximum amount of streams (Error! Reference source not found.).
Min CP duration is a parameter depending on the CAS implementation decisions made by CAS vendors. This information is
conveyed to the SCS by the ECMG during channel setups to indicate the minimum amount of time the CW shall remain
active. This information is displayed in milliseconds.
Section TS packet flag defines the format of the ECM. Luminato’s ECMs are always in MPEG2 Transport Stream packet
format. All TS packets should be of 188 bytes length, any other packet length is considered as an error.
Channel test sent, Test reply and Error reply are channel_test message counters.
130
Last error code gives the error_status code of the last detected error. Some of these codes are defined by the ECMG
protocol standard, while codes ranging from 0x8000 to 0xFFFF are privately defined (consult Error! Reference source not
found. of the present manual and/or your CAS administrator to obtain the definitions of the codes within this range).
4.18.9 ADDING ECM STREAMS

Once an ECMG profile has been configured, the next step is to create one or several ECM streams. The ECM stream(s)
carry the control words used for scrambling and descrambling the services. ECM streams are requested from ECMGs.
Before an ECM stream request can be sent, a few parameters must be specified:
• ECM ID
• Access criteria
• CW group
• PMT private data descriptor (optional)
4.18.9.1 ECMG CONFIGURATION MODE

Enter ECMG configuration mode of the target ECMG:
Syntax:
ecmg {1…8192}
Example – ECMG 1:
DocumentationTest(cas)# ecmg 1
4.18.9.2 C REATING AN ECM STREAM ENTRY

As a first step you need to create an ECM stream profile entry which will be used to refer to the actual ECM stream.
To create an ECM stream entry:
Syntax:
stream <stream_index> [description <alias_str>]
Arguments:

stream_index Index referring to the ECM profile {1…8192}
alias_str An optional descriptive alias for the ECM stream Character string
Example – Create ECM stream profile 1 and label it “MyStream”:
DocumentationTest(ecmg 1)# stream 1 description MyStream

Please wait creating new ecmg stream entry.
DocumentationTest(stream 1)#
131
4.18.9.3 ECM ID
The ECM ID is used to uniquely identify an ECM stream within a Super CAS ID (=CA system).
To assign an ECM ID to ECM stream:
Syntax:
ecm-id <identifier>
Argument:

identifier Ensure the ECM stream identifier is unique within same CAS. {0…65535}
Caution! Make sure the ECM identifier is unique!
Example:
DocumentationTest(stream 1)# ecm-id 1

4.18.9.4 A CCESS CRITERIA

The “Access Criteria” parameter (AC) conveys access condition information associated to programs being broadcasted.
This information is encoded in CAS proprietary format and is needed by the ECMG to generate ECMs.
To specify the AC of an ECM stream:
Syntax:
ac <access_criteria>
Argument:

access_criteria Access criteria in hexadecimal format <string>
Example:
DocumentationTest(stream 1)# ac 0x00000065

132
4.18.9.5 C ONTROL WORD GROUP
The Control Word group (CW group) is an internal data structure that regroups into one logical set the ECM streams that
will be requested simultaneously with the same CW. In a SimulCrypt configuration, several CASs (with different Super CAS
ID) may be used simultaneously to generate several ECM streams with one same CW.
Caution! In non-SimulCrypt configurations (only one CA system), it is highly recommended to use a unique CW group
(control world group) for every ECM stream. Using the same CW for two or more ECM streams, could have unwanted
effects. For example, if the end customer swapped from one scrambled service to another, the service could be visible for
a few seconds, even without authorization to this specific service.
To assign an ECM stream to a CW group:
Syntax:
cwg-id {1…4294967295}
Example:
DocumentationTest(stream 1)# cwg-id 1

4.18.9.6 ECM STREAM PRIVATE BYTES

1
CAS private data may be conveyed in the PMT’s CA descriptor private_data_byte . It is up to the implemented CAS if such
To insert ECM stream related private data in the CA descriptor (in hexadecimals) to the target ECM stream:
Syntax:
Example – insert CA private data ‘0x1234’ for ECM stream 1:
DocumentationTest(stream 1)# privatebytes 0x1234

4.18.9.7 E NABLING / DISABLING ECM STREAMS

Once all ECM stream parameters specified, you may enable the ECM stream. Technically you activate the ECM stream
profile and Luminato’s SCS will send an ECM stream request containing the configured stream parameters and the current
CW to the target ECMG.
1
ISO/IEC 13818-1 ed. 2.0, table 2-51
133
To enable/disable an ECM stream:
Syntax:
[no] shutdown
Keywords:

no no shutdown = Enable ECM streaming
Example – enable stream 1:
DocumentationTest(stream 1)# no shutdown

4.18.10 MONITORING ECM STREAMS
To monitor all configured ECM streams:
Syntax:
show cas ecmg stream
Example:
DocumentationTest(stream 1)# show cas ecmg stream

ECM Streams:
Index|Description |Stream|ECM |AccessCrit|CWG |CP |Status
| |ID |ID | | | |
1/1 |MyStream |0 |1 | |1 |0 |OK
4.18.11 REMOVING AN ECM STREAM ENTRY
To remove an ECM stream profile:
Syntax:
no stream {1…8192}
Example:
DocumentationTest(ecmg 1)# no stream 1

134
4.18.12 EMM GATEWAY CONFIGURATION
Luminato acts as a gateway between the EMMG and the multiplexer.
4.18.12.1 C REATING AN EMM GATEWAY ENTRY

The first step in EMM stream configuration is to create an EMM gateway entry.
To create an EMM gateway entry:
Syntax:
emmgw <index>
Argument:

index EMM gateway index {1…8192}
Example:
DocumentationTest(cas)# emmgw 2
Please wait. Creating new emm gw entry
DocumentationTest(emmgw 2)#
4.18.12.1.1 TCP PORT

A TCP port needs to be specified in order to create a connection between the EMMG and the Luminato EMM gateway.
To specify the TCP port:
Syntax:
port <port>
Arguments:

port EMMG’s TCP port. {1…65535}
Example:
DocumentationTest(emmgw 2)# port 5001

135
4.18.12.1.2 C HANNEL ID
A channel represents an open TCP connection between an EMMG and an EMM gateway. A single open connection can
have only one channel. The channel ID identifies uniquely such a channel.
Syntax:
channel {1…8192}
Example:
DocumentationTest(emmgw 2)# channel 8000

Please wait. Creating new channel entry
DocumentationTest(channel 2.8000)#
4.18.12.1.2.1 CLIENT ID
The client ID is a 32-bit identifier that uniquely identifies an EMMG connected to a given multiplex. In Luminato, it
specifies which EMM channels are accepted by the selected EMM gateway.
When configuring EMMGs in the CAS, consider that ETSI TS 103 197 v 1.5.1 states the following rules for selecting a unique
client ID:
• “in the case of EMMs or other CA related data, the two first bytes of the client_id should be equal to the two
bytes of the corresponding CA_system_id;”
• “in other cases a value allocated by DVB for this purpose should be used.”
To specify the accepted EMMG client ID (in hexadecimals):
Syntax:
client-id <string>
Example:
DocumentationTest(channel 2.8000)# client-id 0x00000001

4.18.12.1.3 R EMOVING A CHANNEL ENTRY

To remove a channel entry:
no channel {1…8192}
Example:
DocumentationTest(emmgw 2)# no channel 8000

136
4.18.12.2 A DDING EMM STREAMS
Once an EMM channel has been configured, the next step is to create one or several EMM streams. The EMM
(Entitlement Management Message) stream(s) carry the subscription contents (subscriber authorization levels etc.) and
the encryption key used for encrypting and decrypting the control words. The EMMGs are clients and Luminato’s EMM
gateway is the server. EMMG initiates connections and stream creation and the gateway either accepts or rejects the
setup messages based on the configured parameters. Before an EMM stream can be created, a few parameters must be
specified:
• Data ID
• Data type
• EMM bandwidth allocation
• CAT private data descriptor (optional)
4.18.12.2.1 EMMG CHANNEL CONFIGURATION MODE

Enter EMMG channel configuration mode of the target EMM gateway:
Syntax:
configure cas emmgw {1…8192} channel {0…65535}
Example – Channel 8000:
DocumentationTest(configure)# cas emmgw 2 channel 8000

4.18.12.2.2 C REATING AN EMM STREAM ENTRY

As a first step you need to create an EMM stream profile entry which will be used to refer to the actual EMM stream.
To create an ECM stream entry:
Syntax:
emm <stream_index> [description <alias_str>]
Arguments:

stream_index Index referring to the EMM stream profile {1…8192}
alias_str An optional descriptive alias for the ECM stream Character string
Example – Create EMM stream profile 1 and label it “YourStream”:
DocumentationTest(channel 2.8000)# emm 1 description YourStream

Please wait. Creating new emm entry
DocumentationTest(emm 1.8000.1)#
137
4.18.12.2.2.1 DATA ID
The data ID is allocated by the CAS and uniquely identifies an EMM stream of a given client ID. In Luminato, it specifies
which EMM streams are accepted by the selected EMM gateway.
To specify the accepted data IDs:
Syntax:
data-id {0…65535}
Example – data ID 1:
DocumentationTest(emm 1.8000.1)# data-id 1

4.18.12.2.2.2 DATA TYPE
The data type parameter indicates the type of data carried in the datagram stream. In Luminato, it defines which type of
datagram streams are accepted by the EMM gateway.
To specify the data type of the datagram stream:
Syntax:
datatype {any|emm|other|private}
Keywords:

any All data types are accepted
emm Only EMM streams (type 0x00) will be accepted
other Any stream of data_type values other than 0x00, 0x01 and 0x02 are accepted.
private Only private datagram streams (type 0x01) will be accepted
Example – accept any type of datagram stream:
DocumentationTest(emm 2.2.4)# datatype any

4.18.12.2.3 EMM STREAM PRIVATE BYTES

1
CAS private data may be conveyed in the CAT’s CA descriptor private_data_byte . It is up to the implemented CAS if such
1
ISO/IEC 13818-1 ed. 2.0, table 2-51
138
To insert EMM stream related private data in the CA descriptor (in hexadecimals) of all EMM streams from the target
EMM stream:
Syntax:
Example – insert CA private data ‘0x1234’ for EMM stream 4:
DocumentationTest(emm 2.2.4)# privatebytes 0x1234

4.18.12.2.4 EMM STREAM BANDWIDTH ALLOCATION

You may specify the bandwidth allocated per EMM stream. The EMMG will be responsible for maintaining the bitrate
within the set limit.
To specify the bandwidth (=bitrate limit) allocated to an EMM stream:
Syntax:
bandwidth <bitrate>
Argument:

values
bitrate The bandwidth allocated to the target EMM stream. The value is expressed kilobits per second {1…5000}
(kb/s)
Example:
DocumentationTest(emm 2.2.4)# bandwidth 1000

4.18.12.3 R EMOVING AN EMM STREAM ENTRY

To remove an EMM stream entry:
Syntax:
no emm <stream_index>
Arguments:

stream_index Index referring to the EMM stream profile {1…8192}
139
Example:
DocumentationTest(channel 2.8000)# no emm 1

140
5 INTERFACE CONFIGURATION
This section covers the configuration procedures of all physical interfaces for stream routing. After the module
configuration presented in this chapter has been performed, the modules are ready for service configuration.
5.1 PRODUCT AND HW IDENTIFICATION

Swing open the front panel by gently pushing the metal clips at the both ends of the light panel simultaneously (Figure 16).
FIGURE 16: SWING OPEN THE FRONT PANEL BY GENTLY PUSHING THE HIGHLIGHTED PARTS OF THE FRONT PANEL SIMULTANEOUSLY.
The chassis product type, hardware version number and serial number can be found from behind the front panel (Figure
17).
FIGURE 17: CHASSIS' PRODUCT TYPE AND SERIAL NUMBER LABELS
The interface modules have their serial number and HW-version stickers applied to the lower side PCB of the modules.
Hardware type
Hardware version
Serial number
141
To identify hardware with the CLI:
Syntax:
show modules
Argument:

slot_number Module’s chassis slot location {1…6}
Example – identify all installed modules:
DocumentationTest# show modules

MODULES STATE
Slot | Type | HW Type | HW Ver | Serial | Status
0 |MAIN |LCH-D |C10 |HL00471206 |Warning
1 |Dual DVB-S2 CA |LRS-C |B12 |HL01781206 |OK
2 |Dual IP CA |LIC-A |B13 |HK00251241 |OK
3 |LRC-B |LRC-B |B12 |HK00321239 |OK
4 |COFDM transmitter |LCM-B |B11 |HL00931109 |OK
5 |LPE-A |LPE-A |B11 |HK00571402 |OK
6 |DVB-C transmitter |LQM-C |B11 |HL00541052 |OK
7 |Power supply 120W |LPS-E |A13 |HL00561143 |OK
DocumentationTest#
5.1.1 LUMINATO INPUT MODULES:
DVB-ASI receivers (DVB Asynchronous Serial Interface):
Quadruple input:
• LAS-A
• LAS-C
DVB-S/S2 receivers (DVB Satellite/Satellite – second generation):
Dual input – dual CA-module slot:
• LRS-A
• LRS-C
Quadruple input – no CA-module slot:
• LRS-B
DVB-T receivers (DVB Terrestrial):
• LRT-A
142
DVB-T/T2 receivers (DVB Terrestrial/Terrestrial – second generation):
• LRT-B
Quadruple input – dual CA-module slot:
• LRT-C
ISDB-T-receivers (ISDB Terrestrial):
Dual input:
• LRT-H
Quad input:
• LRT-I
DVB-C receivers (DVB Cable):
• LRC-A
Quadruple input – dual CA-module slot:
• LRC-B
Multistandard receivers:
Quad input – dual CA-module slot:
• LRM-A
• LRM-B
IP-to-IP descrambler:
Dual input-dual CA-module slot:
• LIC-A
143
5.1.2 LUMINATO OUTPUT MODULES:
DVB-ASI transmitter (DVB Asynchronous Serial Interface):
Quadruple output:
• LAS-B
• LAS-D
QAM modulators:
Quadruple output:
• LQM-A
• LQM-B
• LQM-C
COFDM modulators:
Dual/Quadruple output:
• LCM-A
• LCM-B
• LCM-I
IP to IP multiplexer:
Quadruple output:
• LIM-A
IP-to-IP scrambler:
Single output Pro:Idiom™ scrambler:
• LPI-A
5.1.3 LUMINATO PROCESSING MODULES:

Pro-MPEG FEC (Forward Error Correction) encoder/decoder:
• LPF-A
EPG processing module
• LPE-A
144
Application module
• LPC-A
• LPC-B
Bulk descrambler
• LAB-A
5.2 COMMANDS COMMON TO ALL INTERFACES

5.2.1 INTERFACE INDEXING CONVENTIONS
When referencing to input/output interfaces the following syntax is used:
<slot_index_number>/<connector_index_number>.<stream_index_number>
Index Description Allowed

values
slot_index_number Specifies target module based on its slot location {1…6}
connector_index_number Specifies the target connector index. With IP interfaces this value is {1…4}
always ‘1’
stream_index_number Specifies the target stream index. {1…128}
Example:
1/2.1 means TS 1 in connector 2 in module located in slot 1.
5.2.2 ENTERING MODULE LEVEL CONFIGURATION MODE

In module level configuration mode, you may configure the module’s payload IP addresses, SID/PID allocation parameters,
CAM routing, service and PID missing warning timeouts settings and module defaults.
To enter module level interface configuration mode:
Syntax:
configure interface <slot_number>
Argument:
Index Description Allowed values

145
Example – enter configuration mode for module 1:
DocumentationTest# configure interface 1

5.2.3 ENTERING CONNECTOR LEVEL CONFIGURATION MODE
In connector level configuration mode, you may configure tuner and modulator settings.
Once you have entered connector level interface configuration mode, the CLI will stay in this mode until you explicitly exit
this mode with either the exit or the end command.
To enter connector level interface configuration mode:
Syntax:
configure interface {asi|cofdm|dvbc|dvbs|dvbs2|dvbt|dvbt2|input|isdb-t|output|qam}

{input|output} <slot_number>/<connector_number>
Arguments:

values
connector_number Specifies the target connector index. With IP interfaces this value is {1…4}
always ‘1’
Example – enter interface configuration mode for module connector 1/2:
DocumentationTest# configure interface dvbs2 input 1/2

DocumentationTest(iface-dvbs2-input-1/2)#
5.2.4 ENTERING STREAM LEVEL CONFIGURATION MODE
In stream level configuration mode, you may, depending module type, configure tuning and modulation parameters, IP
streaming parameters and/or DVB multiplexing related settings (PSI/SI table generation, input PID filtering).
Once you have entered stream level interface configuration mode, the CLI will stay in this mode until you explicitly exit
this mode with either the exit or the end command.
To enter connector level interface configuration mode:
Syntax:
configure interface <type> {input|output} <slot_number>/<connector_number>.<stream_index>
146
Arguments:

values
slot_ number Specifies target module based on its slot location {1…6}
always ‘1’
Example – enter configuration mode for stream 3/2.1:
DocumentationTest(configure)# interface dvbc input 3/2.1

DocumentationTest(iface-dvbc-input-3/2.1)#
5.2.5 SI CHARACTER ENCODING

Service information in DVB streams contains textual data encoded using the Latin alphabet (ISO-6937 plus the Euro
symbol) by default. Alternative coding schemes may be used, identified by prefixing text fields with a special byte
sequence (coding identifier). The mechanism is defined in the DVB standard ETSI EN 300 468.
Any apparatus displaying such SI text fields, including set-top boxes in end-user premises, must decode the text fields in
order to display the appropriate glyphs. By default in Luminato, the output SI text fields (service name, service provider
name etc) are copied from the input(s) unchanged, meaning the character encoding scheme will also remain the same.
Locally inserted SI text fields and created with the Luminato’s PSI/SI –editor, will use the user definable
5.2.5.1 D EFAULT CHARACTER SI CHARACTER ENCODING

To define the default character set and coding identifier when creating new SI text fields in the PSI/SI editor:
Syntax:
configure [no] default-si-encoding <ISO_charset> <encoding_format>
Argument:

ISO_charset Defines the used character coding scheme when {GB-2312-1980|ISO-
creating new SI text fields in PSI/SI editor. The 10646|ISO-10646/Big5|ISO-
factory default is ISO-6937+ (ISO/IEC 6937 with 6937+|ISO-8859-1|ISO-8859-
addition of the Euro symbol). 10|ISO-8859-11|ISO-8859-
13|ISO-8859-14|ISO-8859-
15|ISO-8859-2|ISO-8859-
3|ISO-8859-4|ISO-8859-5|ISO-
8859-6|ISO-8859-7|ISO-8859-
8|ISO-8859-9|KSX1001-
2004|UTF-8}
147
encoding_format Defines the encoding format of the character set {0|1|2}
identifier:
0 = The character set identifier is not included
1 = The character set identifier is encoded using 1 byte
2 = The character set identifier is encoded using 3
bytes
Caution! The encoding format ‘0’ violates DVB standard unless Latin Alphabet ISO-6937+ charset is used.
5.2.5.2 SI CHARACTER SET OVERRIDE

Service information received from outside the operator’s network may contain textual data encoded using any one of the
coding schemes defined in the DVB standard, for example Russian and Arabic characters use different coding schemes or
charsets (character sets). Unfortunately not all DVB broadcasts carry standard compliant coding identifiers in their SI text
fields, preventing service information, such as service name, from being correctly displayed in Luminato’s UI. To overcome
this problem Luminato is able to override input SI character set encoding.
Overriding the input SI character set will force the selected encoding scheme for the input SI text fields that don’t include
1
a valid coding identifier. The factory default charset for character set override in Luminato is ISO-6937+ . The complete list
of supported coding schemes can be found in Error! Reference source not found..
5.2.5.2.1 C HASSIS WIDE DEFAULT SI CHARACTER SET OVERRIDE

To specify and enable/disable the chassis wide default charset for SI encoding override:
Syntax:
configure override-si-encoding <ISO_charset>
Argument:

ISO_charset Forces the selected encoding scheme for the input SI {GB-2312-1980|ISO-
text fields that don’t include a valid coding identifier. 10646|ISO-10646/Big5|ISO-
6937+|ISO-8859-1|ISO-8859-
10|ISO-8859-11|ISO-8859-
13|ISO-8859-14|ISO-8859-
15|ISO-8859-2|ISO-8859-
3|ISO-8859-4|ISO-8859-5|ISO-
8859-6|ISO-8859-7|ISO-8859-
8|ISO-8859-9|KSX1001-
2004|UTF-8}
1
ETSI EN 300 468
148
Example – force input SI text fields to UTF-8:
DocumentationTest# configure override-si-encoding UTF-8

5.2.6 PASSTHROUGH SERVICE TIMEOUT
The passthrough service timeout setting controls how long passthrough services are included in the output stream if an
input service is missing. A service is considered missing if all its components’ PIDs’ bitrates are zero for a time specified by
the warning timeout setting. Once a service is flagged as missing, the service timeout counter will start. This implies that a
missing service will be present in the output for a time equal to the sum of service timeout and warning timeout. The
service timeout is either set in seconds or set to never. If it is set to never, the services will stay in the output until the next
reboot, even if the input stream has stalled completely.
The passthrough service timeout can be configured at three different levels:
• chassis default
• module default
• interface
5.2.6.1 C HASSIS WIDE DEFAULT

To set the chassis wide default service passthrough timeout:
configure timeout service {never|<timeout_in_seconds>}
5.2.7 COMMON COMMANDS IN INTERFACE CONFIGURATION MODE

The commands introduced in this chapter are in common for all input and output interfaces in interface configuration
mode.
5.2.7.1 E NABLING AND DISABLING INPUT OR OUTPUT INTERFACES

To enable/disable an input or output interface:
Syntax:
[no] shutdown
Keyword:

no no shutdown = enables interface
shutdown = disables interface
NOTE! When user enables/disables an input interface, it will turn on/off reception from the input. When user enables
an output interface, it starts to stream out. It will also enable processing for that interface. Output interfaces are disabled
by default.
149
Example – create IP output 1/1.1 and enable streaming:
DocumentationTest# configure interface ip output 1/1.1

Creating new ip output
DocumentationTest(iface-ip-output-1/1.1)# no shutdown
5.2.7.2 L ABELLING INTERFACES

For easier interface identification, you may give the input and output interfaces descriptive names.
Hint: Devote some time to naming interfaces! For example, when having hundreds of IP inputs, having logical and
consistent interface aliases is well worth the effort.
To label an interface:
Syntax:
description <alias>
Example – label IP input 1/1.1 as ‘MyIPinput:
DocumentationTest(iface-ip-output-1/1.1)# description MyIPinput

5.3 PAYLOAD PORT CONFIGURATION

Luminato has two Gigabit Ethernet ports for payload traffic purposes, which are labelled GE1 and GE2. These ports are
located in the power supply/interface module (Figure 18).
FIGURE 18: THE GIGABIT ETHERNET PORTS GE1 AND GE2
GE1 and GE2 ports supports various types of electrical and fibre SFP modules.
NOTE! It is highly recommended to always use SFP modules that have been certified by our labs as compatible with
Luminato. supplies SFP modules with guaranteed full compatibility; their order codes begin with “LSFP”.
150
For more details on SFP modules, refer to Luminato Chassis Specification
document.
5.3.1 PAYLOAD PORT SEPARATION MODE

Luminato has the flexibility to let the user configure its payload ports’ separation.
Caution! Choose the payload operating mode carefully, well before starting service routing: changing the operating
mode afterwards may prove itself very difficult. For example, when changing separate networks to common network, all
the streams residing in user configured VLANs attached to payload port GE2 will stop streaming.
To select the payload port separation mode:
Syntax:
configure payload-port-mode {common|separate}
Keywords:

values
common
Both ports act as gigabit switching hub ports; the same payload traffic exists in both
ports. IP streamer traffic is copied to both ports as an exact copy (mirrored). IP
inputs can receive from both ports. GE2 uses GE1 configuration.
separate
Both ports act as separate gigabit Ethernet network interfaces IP streamers or IP
inputs can be assigned to either GE1 or GE2. The total traffic can exceed 1 gigabit
per second, since both ports are used separately.
Caution! With Common network selected, take care that both ports are not connected to same switch, as this could
result in an unpredictable loop. The connected networks must be totally separated.
5.3.2 SFP INTERFACE
5.3.2.1 E NTERING SFP LEVEL CONFIGURATION MODE

In SFP level configuration mode, you may select the SFP interface operating mode, force a specific SFP interface speed and
enable/disable the interface.
To enter SFP level interface configuration mode:
Syntax:
configure interface {ge1|ge2}
Example – configure SFP module interface GE1:
DocumentationTest# configure interface ge1

DocumentationTest(interface-ge1)#
151
5.3.2.2 SFP INTERFACE OPERATING MODE
The GE1 and GE2 interfaces have two user selectable operating modes for the inserted SFP-modules: fiber and electrical.
To set the SFP interface operating mode:
Syntax:
mode {fiber|electrical}
Keywords:

values
fiber
SERDES-type interface between the SFP-module and the host (1000Base-X). Supports
fibre compatible SFP-modules This is the factory default operating mode.
electrical
SGMII-type interface between SFP-module and host. Supports LSFP-A electrical
10/100/1000 base-T SPF-module. Allows forcing the interface to a specific
speed.
5.3.2.3 SFP INTERFACE SPEED

Although not recommended, it is possible to change the speed of the GE ports to other than the factory default 1000
Mb/s, if a LSFP-A 10/100/1000 base-T SFP module is in use.
Caution! Other setting than 1000 Mb/s may very easily lead to over allocation with video streams’ bitrates. Make
sure that all video streams’ bitrates configured to 100Mb/s or 10Mb/s do not exceed capacity of the Ethernet link.
To configure the SFP interface operating speed:
Syntax:
speed {10|100|1000}
Keywords:

10
10Base-T
100
100Base-T
1000
1000Base-T
NOTE! Ensure that the target interface has a LSFP-A plugged in and that the operating mode is set to electrical.
152
5.3.3 MODULE PAYLOAD IP ADDRESS
Each module slot has two IP addresses for payload traffic, one associated to GE1 and the other to GE2. They are either a
receiver’s source port IP address for UPD/IP streaming or a modulator’s or multiplexer’s destination address for unicast
UDP/IP stream reception. The configuration procedures described below apply to all modules.
NOTE! Each user defined VLAN have also its own set of module payload IP addresses.
To learn how to allocate VLAN payload IP addresses, see chapter 0.
Enter module level configuration mode for the target module.
To learn how to enter module level configuration mode, see chapter “Entering
module level configuration mode”
5.3.3.1 R ESERVED PORTS & ADDRESSES

The following IP subnets are reserved for internal use (CIDR notation):
• 172.31.255.0/24
• 172.30.[1…23].0/24
• 172.30.[1…253].[1…23]/24
• The following ports are reserved for internal use:
• 22
• 23
• 69
• 80
• 81
• 111
• 443
• 1200
• 1201
• 1202
• 2049
• 8061
• 8071
• 54300-54331
5.3.3.2 IP ADDRESS
To modify a module’s payload IP address:
Syntax:
ip address <ip_address> <netmask> {ge1|ge2}
153
Arguments:

values
ip_address Static IPv4 address in dot-decimal notation (immediately followed by a slash ‘/’ character if in
CIDR notation). Specify unique module payload IP addresses for payload ports GE1 and
GE2. Typically, these addresses must be within the same subnet as the other devices
streaming or listening to UDP/IP streams. GE2 IP address is used only when the GE Port
mode is set to Separate. When Common GE Port mode is in use, only GE1 IP address is used.
netmask IPv4 netmask in classful dot-decimal notation. The factory default netmask is 255.255.255.0.
Hint: The factory default GEx IP addresses are based on the module slot index using the following formulas: Default
GE1 IP address = 192.168.2.(100 + slot index). For example, the factory default GE1 IP address for a module in slot 1:
192.168.2.(100 + 1) = 192.168.2.101. Default GE2 IP address = 192.168.3.(100 + slot index).
5.3.3.3 UDP PORT

To set the source UDP port for transmitted streams:
Syntax:
[no] payload-source-port <UDP_port>
Keyword and argument:

values
no This optional keyword sets the source UDP port to zero.
UDP_port Specifies the UDP source port for the transmitted streams by this module. The factory {0…65535}
default value is 49152 for all modules.
5.3.3.4 V IRTUAL IP SOURCE ADDRESSING

Virtual IP source addressing allows you to specify an IP source address and port to be used for outgoing IP streams
independent of the used physical device. When a virtual IP source address is assigned, it is used for all transmitted IP
packets instead of the physical interface address. One common virtual address is possible even in separate GE-mode. This
setting works per-module basis and is available for all modules.
NOTE! Virtual source addressing is not the same virtual IP addressing: the device own IP address remains unaltered
and won’t reply at its virtual source address!
154
This feature is necessary for example when your network firewall settings allow traffic from only one IP address per port.
1
It is also used in conjunction with SSM (Source-Specific Multicast) routing to relieve the source discovery burden on the
network.
5.3.3.4.1 A SSIGNING A VIRTUAL SOURCE IP ADDRESS

To assign a virtual IP source address to a submodule:
Syntax:
virtual-ip-address <ip_address>
Example – Assign virtual IP source address 180.90.0.1 to the module interface 1:
DocumentationTest(interface 1)# virtual-ip-address 180.90.0.1

5.3.3.4.2 R EMOVING AN ASSIGNED VIRTUAL SOURCE IP ADDRESS

To remove a virtual IP source address assignment from a module:
Syntax:
no virtual-ip-address
Example – remove virtual IP source address from module 1:
DocumentationTest(interface 1)# no virtual-ip-address

no virtual-ip-address
5.3.3.5 D EFAULT GATEWAY

To specify the default gateway for the target module payload interface:
Syntax:
ip default gateway <IP_address> [ge1|ge2]
NOTE! Omitting the optional keyword ge1|ge2 will assign the default gateway to the target module’s payload port
GE1. The IP address 0.0.0.0 results in a no gateway configuration.
Example – Assign the default gateway 100.255.0.1 to module’s 1 payload interface GE1:
DocumentationTest(interface 1)# ip default gateway 100.255.0.5

1
SSM requires support in last-hop routers and in the receiver's operating system and uses IGMPv3.
155
5.3.3.6 D EFAULT TRANSMISSION PROTOCOL
To select the module default transmission protocol:
Syntax:
packet-format {udp|rtp}
5.3.4 STATIC PAYLOAD PORT ROUTING

If the destination IP address of an outgoing stream from Luminato is not within the same subnetwork as the payload
interface, you must define a route to the target network for the payload port (including VLANs). Obtain the gateway
address from your network administrator. The route is inserted into a payload routing table common to all modules.
5.3.4.1 C REATING A ROUTE

To create a route between an external network and the selected payload interface through the specified gateway.
configure payload-port-ip route <network_address> <netmask> <gateway> {all|ge1|ge2|<VID>}
Example:
We wish to stream from payload address 192.168.40.1, in VLAN100, to 10.136.99.101, you’ll need to specify a route to
subnet 10.136.0.0/16 accessible through, say gateway 192.136.40.254. Then, the CLI session would look like this:
DocumentationTest# configure payload-port-ip route 10.136.0.0 255.255.0.0 192.16 8.40.254 100

5.3.4.2 R EMOVING A ROUTE

To remove a route entry from the payload routing table:
configure no payload-port-ip route <network_address> {all|ge1|ge2|<VID>}
Example – remove 10.136.0.0/16 from the payload routing table of VLAN interface 100:
DocumentationTest(configure)# no payload-port-ip route 10.136.0.0 100

1 route(s) deleted
5.3.4.3 V IEWING THE PAYLOAD ROUTING TABLES

Display the payload route entries for the specified VLAN interface or for all payload ports:
Syntax:
show payload-port-ip routes {<VID>|ports}
156
Argument & keyword:

VID
The routing table for the specified VLAN identifier is shown. {1…3999}
ports
The routing table for all ports is displayed.
Example – view the payload routing table for VID 100:
DocumentationTest(configure)# show payload-port-ip routes 100

VLAN routes:
Index: |Destination: |Netmask: |Gateway:
1 |10.136.0.0 |255.255.0.0 |192.168.40.254 |
5.3.5 VIRTUAL LOCAL AREA NETWORK (VLAN) STREAMING INTERFACES
Luminato allows the creation of up to 30 virtual LAN streaming interface to be used for IEEE 802.1Q VLAN tagged
streaming. This allows connections to external switches using VLANs for separating OSI Layer 2 traffic into discrete
broadcast domains.
Separating traffic types into distinct broadcast domains has several advantages; here are two to name a few:
• Reduced broadcast traffic:

o A layer 2 switched network is a single broadcast domain. Since many protocols and
applications rely on broadcasts and broadcasts reduce available network bandwidth,
segmenting a layer 2 network into VLANs will reduce overall broadcast traffic as
broadcasts will then be seen only on the relevant VLANs.
• Improved security:
o Communication between different VLANs is impossible without an OSI Layer 3 device
(=router)
You can select which payload ports are assigned to each configured VLAN. If the selected payload port’s operating mode is
separate, then either port GE1 or GE2 can be assigned to the VLAN. In common mode, both ports can be assigned to the
VLAN.
The payload IP interfaces of the attached Luminato modules may be assigned as members of any VLAN group. You must
specify the IP address of the member payload interfaces.
5.3.5.1 A DDING VLAN STREAMING INTERFACES

To create a VLAN streaming interface:
Syntax:
configure payload-port-vlan <VID> {all|fec|ge1|ge2|internal}
157
Argument and keywords:

values
VID
VLAN identifier {1…3999}
all
The created VLAN will be associated to both payload ports GE1 and GE2. The
keyword is only useful when the payload port separation mode is set to common
ge1|ge2
The created VLAN will be associated to the specified payload port GE1 or GE2.
The payload port separation mode must be set to separate.
fec
This keyword should not be used, it is reserved for internal FEC traffic between
ProMPEG FEC modules. It is visible in running configuration files when FEC
processing modules are in use.
internal
The create VLAN will be associated to the internal payload interface and traffic will
not be forwarded to payload ports GE1 and GE2.
NOTE! Upon VLAN streaming interface creation, all inserted modules are automatically added as members of the
created VLAN and are automatically allocated a unique payload IP address.
Example – create VLAN 100 and assign to payload port GE1:
DocumentationTest(configure)# payload-port-vlan 100 ge1

VLAN already exists. Port configuration changed.
5.3.5.2 N ETWORK MASK

To specify the network mask of the VLAN subnet:
Syntax:
payload-port-vlan <VID> {all|fec|ge1|ge2|internal} netmask <netmask>
Keywords & argument:

values
VID
all
ge1|ge2
fec
This keyword should not be used, it is reserved for internal FEC traffic between
ProMPEG FEC modules. It is visible in running configuration files when FEC
processing modules are in use.
158
values
internal
netmask
IPv4 netmask in classful dot-decimal notation. The factory default netmask is
255.255.255.0.
Example – Set network mask 255.255.255.252 for VLAN 100:
DocumentationTest(configure)# payload-port-vlan 100 ge1 netmask 255.255.255.252

5.3.5.3 IP ADDRESS ALLOCATION

When creating a VLAN interface, a unique IP address is automatically assigned to each module payload interface.
To specify manually new IP addresses to the module VLAN payload interfaces:
configure payload-port-vlan <VID> {all|ge1|ge2|internal} interface <slot_number> <IP_addr>
Arguments & keywords:

values
VID
all
ge1|ge2
internal
slot_number
Specifies target module based on its slot location {1…6}
IP_address
Static IPv4 address in dot-decimal notation (immediately followed by a slash ‘/’ character if
in CIDR notation). Specify unique module payload IP addresses for the specified VLAN.
Typically, these addresses must be within the same subnet as the other devices streaming or
listening to UDP/IP streams.
NOTE! The payload IP address 0.0.0.0 disables the interface. This is useful if only one module is used in the target
VLAN and you wish to release the IP addresses assigned to the unused module interfaces.
NOTE! If you have assigned a virtual source IP address to a module, it will bypass this VLAN payload address.
159
Example – Assign IP address 192.168.4.1 to module 1’s VLAN payload interface 100:
DocumentationTest# configure payload-port-vlan 100 ge1 interface 1 192.168.4.1

5.3.5.4 R EMOVING A VLAN ENTRY

To remove a VLAN entry:
configure no payload-port-vlan <VID>
Argument

VID
Target VLAN identifier {1…3999}
Example – Remove VLAN 10:
DocumentationTest# configure no payload-port-vlan 10

5.3.5.5 A DDING A STATIC ROUTE FOR VLAN INTERFACES

If the destination IP address of an outgoing stream from Luminato is not within the same sub network as the payload
interface, you must define a route to the target network for the payload port (including VLANs).
To learn how to add a static route for the specified VLAN, refer to chapter “Static
payload port routing”
5.3.5.6 R EMOVING A ROUTE
To learn how to remove a static payload port route, refer to chapter “Removing a
route”
5.3.5.7 V IEWING PAYLOAD PORT VLAN CONFIGURATION

To view all user-defined VLANs along with their respective output port assignments:
Syntax:
show payload-port-vlan vlans
Example:
DocumentationTest# show payload-port-vlan vlans

Current VLAN ID's available:
VLAN id |Output port:
100 |GE1 |
30 |GE2 |
160
DocumentationTest#
5.3.5.8 V IEWING VLAN PAYLOAD INTERFACE IP ADDRESS ASSIGNMENTS

To view the IP address assignments and netmask of module slots 1…6 in selected VLAN:
Syntax:
show payload-port-vlan address [<VID>]
Argument:

values
VID
View VLAN payload interface IP address assignments for the specified VLAN identifier {1…3999}
(VID). Omitting this optional argument will cause the command to show IP address
assignments for all VLAN interfaces.
Example – show all VLAN payload IP address assignments:
DocumentationTest# show payload-port-vlan address

VLAN IP configuration table:
VLAN id: 100
Module: |IP address: |Netmask:
1 |192.168.4.1 |255.255.255.252 |
2 |192.168.4.2 |255.255.255.252 |
3 |192.168.4.3 |255.255.255.252 |
4 |0.0.0.0 |255.255.255.252 |
5 |0.0.0.0 |255.255.255.252 |
6 |0.0.0.0 |255.255.255.252 |
VLAN id: 30
Module: |IP address: |Netmask:
1 |192.168.1.51 |255.255.255.0 |
2 |192.168.1.52 |255.255.255.0 |
3 |192.168.1.53 |255.255.255.0 |
4 |192.168.1.54 |255.255.255.0 |
5 |192.168.1.55 |255.255.255.0 |
6 |192.168.1.56 |255.255.255.0 |
DocumentationTest#
5.3.6 CBR STREAMING STRICT MODE
If necessary, you may set the CBR (Constant Bit Rate) streaming mode to strict mode. Strict mode means packets are
dropped if the CBR output stream is overallocated. This ensures that the stream bitrate never exceeds the specified CBR
limit and cause congestion in the transmission network, possibly breaking other signals. In non-strict mode, packets are
not dropped, which may result bit rate higher than the specified CBR. An alarm is always issued when packets are being
discarded.
161
To enable/disable the strict CBR output mode:
Syntax:
configure [no] cbr-streaming-strict-mode
Keyword:

no This optional keyword disables the CBR strict mode.
5.3.7 LINK-LEVEL FLOW CONTROL
If Luminato’s GE ports are receiving more traffic than they are capable of forwarding, the buffers of the internal switch
may run out of memory. To prevent the internal switch from being overwhelmed, you may consider using link-layer flow
control as defined by the IEEE 802.3x standard.
When Luminato’s link-level flow control is enabled, the embedded switch will emit pause frames through the GE ports
whenever the buffers are running out of memory. The transmitters at the other end of the link will then pause
transmitting for a short period of time.
NOTE! Link-level flow control must be also enabled on the end receiving end of the pause frames. Please consult the
user documentation of the transmitter to learn how to enable link-layer flow control receiving.
To enable or disable link-level flow control transmission:
Syntax:
configure [no] send-ge-pause-frames
Keyword:

no This optional keyword disables the link-level flow control.
5.4 INPUT INTERFACES

5.4.1 INPUT INTERFACE COMMON COMMANDS
5.4.1.1 E MPHASIZING MISSING INPUT SIGNALS IN STATUS REPORTS

You may define input interfaces as critical. The critical flag emphasizes the input signal in status reporting, if the signal is
missing. When enabled, a warning message will be issued if the signal is missing. When disabled, only a notification
message will be issued if the signal is missing. The critical -flag is enabled by default.
NOTE! This setting affects directly the triggering of 1 + 1 chassis redundancy. You MUST disable this option when
using stream redundancy and 1 + 1 chassis redundancy simultaneously.
162
To learn more about 1+ 1 chassis redundancy, see chapter
To mark an input interface as critical or non-critical:
Syntax:
[no] critical
Example – mark IP input 1/1.1 as non-critical:
DocumentationTest(iface-ip-input-1/1.1)# no critical
DocumentationTest(iface-ip-input-1/1.1)#
5.4.1.2 C LEARING PID STATISTICAL COUNTERS

With RF and ASI input interfaces you may clear the statistical PID counters (CC errors and peak bitrate).
To clear PID counters:
Syntax (input interface level configuration mode):
clear pid-counters all
Example – clear the statistical PID counters for DVBT-2 interface 2/1.1:
DEMO-3# configure interface dvbt2 input 2/1.1 clear pid-counters all

DEMO-3(iface-dvbt2-input-2/1.1)#
5.4.1.3 C LEARING RTP PEAK JITTER COUNTER

To clear the RTP peak jitter counter:
Syntax (IP input interface level configuration mode, RTP mode only):
Example – clear RTP peak jitter counter for IP input interface 4/1.1:
DocumentationTest(iface-ip-input-4/1.1)# configure interface ip input 4/1.1 clear stats rtp peak-

jitter
5.4.1.4 I NPUT PSI/SI TABLE CAPTURE

To capture an input PSI/SI table:
Syntax:
psi-capture pid <PID> table-id <table_id> [table-id-extension <extension_id>]

[{current|next}]
163
Arguments & keywords:

PID The PID (Packet IDentifier) for the target table in decimals.. {0…8192}
table_id The table identifier identifies to which table the section belongs. {0…8192}
For NIT: = network_id
For BAT: = bouquet_id
For EIT: = service_id
extension_id The table extension identifier identifies sub-tables. {0…8192}
current Indicates that the sub-table is the currently applicable sub-table.
next Indicates that the sub-table is not yet applicable and will be the next valid sub-table.
5.4.1.5 SDT DESCRIPTOR FORWARDING

By default, the Luminato automatically generated output SDTs includes only the following descriptors parsed from the
input SDTActual: CA identifier descriptors and service descriptors. You may forward from the input to the output other SDT
descriptors by specifying a descriptor tag list in the target input module.
NOTE! The command below is a module level configuration command and affects all the input interfaces of the target
module.
To add/remove a SDT descriptor tag into/from the SDT descriptor forwarding list:
Syntax (module level configuration mode):
[no] sdt-descriptor-forwarding <tag>
Argument:

no This optional keyword removes the specified descriptor tag from the forwarding
list.
tag Enter target descriptor tag value either in decimals or in hexadecimals. {{0…255}|{0x00…0xFF}}
NOTE! You may enter only one tag at a time. To specify several tags, you must enter each tag separately.
Example – forward the input SDT descriptors tagged as 0x86 and 0x87 in module 2:
DocumentationTest(interface 2)# sdt-descriptor-forwarding 0x86

DocumentationTest(interface 2)# sdt-descriptor-forwarding 0x87
164
5.4.1.6 S HARED TS RECEPTION
Sometimes, the incoming multiplex might be shared by two networks simultaneously. In some special applications, the
shared TS does not include any SDT nor NIT (Figure 19). The SDT information must be extracted from the SDTother of the so
called home TS, which also contains EIT schedule data.
In the illustration below (Figure 19), the received SDT and NIT data for TS5 in network 1 (=ONID 1) has to be extracted
from TS2, which is the home TS for ONID1. Similarly, in ONID2 the SDT and NIT data has to be extracted from TS4.
To support this particular application, Luminato offers the possibility to use the SDTother of another input TS (=physical
input) instead of the expected SDTactual.
NOTE! The Use SDT other –feature is for physical inputs residing in the same module, i.e. you cannot use the SDT
other of inputs residing in another module.
FIGURE 19: TS SHARING. IN THIS ILLUSTRATION, THE NETWORKS 1 AND 2 SHARE THE TS5. TS5 DOES NOT INCLUDE ANY NIT NOR SDT.
To use the SDTother of another input interface instead of SDTactual:
Syntax:
use-sdt-other input <connector_number>.<stream_index>
Arguments:

values
connector_number Specifies the connector index containing the TS which includes the desired {1…4}
SDTother. With IP interfaces this value is always ‘1’
stream_index Specifies the target stream index containing the SDTother. {1…128}
Example – for IP input 2/1.1, use the SDTother of input 2/1.2 instead of SDTactual:
DocumentationTest# configure interface ip input 2/1.1 use-sdt-other input 1.2
165
5.4.1.7 SI CHARACTER SET OVERRIDE

Overriding the input SI character set in an input interface will force the selected encoding scheme for the input SI text
fields that don’t include a valid coding identifier in this specific interface. The factory default charset for character set
1
override in Luminato is ISO-6937+ . The complete list of supported coding schemes can be found in the separate web UI
manual.
To specify the charset for SI text field encoding override:
Syntax:
[no] override-si-encoding <ISO_charset>
Argument:

no This optional keyword will cause the SI text field to
use the chassis wide default character override.
ISO_charset Forces the selected encoding scheme for the input SI {GB-2312-1980|ISO-
text fields that don’t include a valid coding identifier. 10646|ISO-10646/Big5|ISO-
6937+|ISO-8859-1|ISO-8859-
10|ISO-8859-11|ISO-8859-
13|ISO-8859-14|ISO-8859-
15|ISO-8859-2|ISO-8859-
3|ISO-8859-4|ISO-8859-5|ISO-
8859-6|ISO-8859-7|ISO-8859-
8|ISO-8859-9|KSX1001-
2004|UTF-8}
Example – IP input interface 2/1.1 shall use ISO-10646 as its character set for SI text fields without valid SI text field
encoding identifier when displayed in Luminato’s UI:
DocumentationTest# configure interface ip input 2/1.1 override-si-encoding ISO-10646

5.4.1.8 W ARNING TIMEOUT SETTINGS

You may control how fast your system reacts to missing input PIDs, services or signals with the warning timeout settings.
These are module level settings.
5.4.1.8.1 W ARNING TIMEOUT FOR MISSING INPUT SIGNAL OR INPUT SERVICE

The warning timeout defines how long (in seconds) a service (or program) or input signal has to be missing before a
warning flag is raised.
1
ETSI EN 300 468
166
An input signal is considered missing when its PID bitrates are below the signal lost threshold for a period specified by the
warning timeout value.
The signal lost threshold may be adjusted with the signal-lost-threshold –

command, see chapter Signal lost threshold
An input service is considered missing when all its components’ PID bitrates are zero for a period specified by the warning
timeout value.
To set the service/signal missing warning timeout:
Syntax (module level interface configuration mode):
timeout warning <timeout_in_seconds>
Argument:

values
timeout_in_seconds Defines how long (in seconds) a service (or program) or input signal has to be {1…99}
missing before a service missing or signal missing warning flag is raised
Example:
We want to be notified about missing input services if all the ES PID bitrates of any service has been zero for 10 seconds in
module interface 2:
DocumentationTest# configure interface 2 timeout warning 10

NOTE! In the example above, a signal lost –warning message will issued if all the PID bitrates have been below the
signal lost threshold for 10 seconds.
5.4.1.8.2 S IGNAL LOST THRESHOLD

The input signal is interpreted as lost if the bitrate is below (or equal to zero if threshold value is zero) the user specified
signal lost threshold for the time defined by the warning timeout setting. The warning timeout is module specific; inputs
within a single module cannot have different warning timeout values. However, the signal lost threshold value can be set
at module level as a default value and overridden at interface level.
5.4.1.8.2.1 MODULE LEVEL

To specify the signal lost threshold in kbit/s at module level:
Syntax:
configure interface <slot_number> signal-lost-threshold <min_bitrate>
167
Argument:

min_bitrate The minimum bitrate in kbit/s before the input signal is considered lost. {0…4000000}
5.4.1.8.2.2 INPUT INTERFACE LEVEL

To specify the signal lost threshold in kbit/s at input interface level (effectively bypasses module level threshold):
Syntax:
configure interface {asi|dvbc|dvbs|dvbs2|dvbt|dvbt2|input|isdb-t} input

<slot_number>/<connector_number>[.<tuner_number>] signal-lost-threshold {0…400000}
To remove the input interface level signal lost threshold:
Syntax:
configure interface {asi|dvbc|dvbs|dvbs2|dvbt|dvbt2|input|isdb-t} input

<slot_number>/<connector_number>[.<tuner_number>] no signal-lost-threshold
5.4.1.8.3 W ARNING TIMEOUT FOR MISSING INPUT PID S

The PID timeout defines how long (in seconds) an input PID has to be missing before a PID missing -warning flag is raised.
A PID is considered to be missing when its bitrate has dropped to zero.
NOTE! PID missing warning messages are only issued with manually filtered PIDs.
To set the PID missing warning timeout (module level interface configuration mode):
Syntax:
timeout pid <timeout_in_seconds>

values
timeout_in_seconds Defines how long (in seconds) an input PID bitrate has to be zero before a PID {1…99}
missing warning flag is raised
NOTE! TDT/TOT tables are typically updated every 30 seconds; therefore this setting must be more than TDT/TOT
interval to avoid unnecessary warnings.
168
Example:
We want to be notified about missing input PIDs in module interface 2 if the input PID bitrate has been zero for 40
seconds:
DocumentationTest# configure interface 2 timeout pid 40

5.4.1.9 D ESCRAMBLING MODULE SETUP

After receiver modules’ physical interface configuration, the next phase is to install descrambling modules and configure
the Conditional Access Modules (CAMs) for modules that are intended to descramble services.
5.4.1.9.1 C OMPATIBILITY AND REQUIREMENTS

Luminato receivers support all established manufacturers’ CAMs that are intended for professional use and complying
with the DVB-CI EN50221 standard. This is typically indicated by the words Professional or Pro in the CA module label.
If you intend to descramble multiple services per CAM, you must acquire a Multi-Service Descrambling (MSD) license. If
the MSD feature is enabled, the amount of descrambled services and PIDs, as well as the maximum TS bitrate through the
CAM are limited by the CAM, not by Luminato. You may overcome these limitations by daisy chaining the CAMs.
Luminato receivers are continuously tested with professional CAMs from e.g. Aston, SMiT, DRECrypt, RosCrypt, SmarDTV
and Neotion, CA systems including (but not limited to) Conax, Viaccess, NDS Videoguard, Irdeto, AstonCrypt, DreCrypt,
Biss, Irdeto Cryptoworks. It is recommended to use these manufacturers’ modules to avoid problems with descrambling.
We actively follow these vendors’ latest developments with CA-modules.
Our coverage of supported CAMs is continuously growing. For the compatibility of a specific CAM from a manufacturer not
listed here, please contact Sales services, Product Management or Support.
NOTE! Luminato does not support descrambling of services that requires use of a CI+ module, as the CI+ technology is
intended for end customers. The main purpose of CI+ standard is to prevent illegal distribution and copying of content,
and the CI+ consortium does not currently certify professional receivers.
1
Luminato may descramble some services (typically SD ) with consumer CI+ modules, but it is not guaranteed. However,
Luminato supports Secure Pro CAMs that descramble the same services that are descrambled using CI+ modules in
consumer applications. For obtaining these Secure Pro CAMs, contact the content provider responsible for the encryption.
The upper CA-slot in a receiver module (LRS-A/C, LRT-A, LRT-B, LRC-A, LIC-A) is labelled as A, and the lower CA-slot as B
(Figure 20).
1
SD = Standard Definition
169
A
B
FIGURE 20: CA-MODULE SLOTS’ A AND B LOCATION
5.4.1.9.2 CA- MODULE IDENTIFICATION

5.4.1.9.2.1 SHORT SUMMARY
To view a short summary of all detected CAMs:
Syntax:
show cam
Example:
DocumentationTest# show cam

CAM MODULES:
Slot | PIDS req | PIDS suc | Actions | CA menu | Module
1/A |0 |0 |0 |Closed |Conax Aston Pro 2.1901
1/B |0 |0 |0 |Closed |Videoguard CA
2/A |0 |0 |0 |Closed |Conax 4.00e
2/B |0 |0 |0 |Closed |Conax Aston Pro 2.2500
3/A |0 |0 |0 |Closed |
3/B |0 |0 |0 |Closed |Irdeto Access
DocumentationTest#
5.4.1.9.2.2 DETAILED SUMMARY
To get more information about all installed CAMs, such as Module name, System ID, Module ID, Manufacturer and
Manufacturer Code:
To view a detailed summary of all detected CAMs:
Syntax:
show cam detail
Example (abridged):
DocumentationTest# show cam detail

FAILURE ACTION
| CAM A | CAM B
Restart descrambling| 2| 2
Reset CAM | 1| 1
Reset Module |disabled|disabled
170
Timeout | 15 sec| 15 sec
ROUTING
Input|CAM A|CAM B
1/1.1| A |
1/2.1| | B
! CAM A
Module |Conax Aston Pro 2.1901
System ID |2816,2817,2818,2819,2820,2821,2822,2823
Manufacturer |2816
Manufacturer code |2816
Module identifier |Conax Aston Pro 2.1901,b00,b00,b00,b01,b02,b03,b04,b05,b06,b07
PIDs requested for descrambling|0
PIDs successfully descrambled |0
Failure actions since reboot |0
CA menu status |Closed
! CAM B
Module |Videoguard CA
System ID |2366
Manufacturer |51966
Module identifier |Videoguard CA,cafe,babe,93e
!
5.4.1.9.2.3 CA-MODULE STATUS
To access the CAM basic information of an input module:
Syntax:
show interface <slot_number> cam {a|b}
Example:
DocumentationTest# show interface 2 cam a

Module |Conax 4.00e
System ID |2816
Manufacturer |2816
Module identifier |Conax 4.00e,b00,4b1,b00
DocumentationTest#
171
5.4.1.9.3 CAM ROUTING
The input TS which contains the services you wish to descramble must be routed through a CAM. A typical use case would
be to assign one CA-module per input TS, but in order to extend descrambling capacity both CA-module slots may be
assigned to a single input TS. At the same time, the second input can be used for receiving FTA (Free To Air = unscrambled)
services. Another reason for cascading two modules could be the use of CA-modules capable of descrambling different CA
systems in the received multiplex.
5.4.1.9.3.1 TO ROUTE A CAM

To route input streams through CAMs:
Syntax (module level interface configuration mode):
cam {a|b} routing input <connector_number>.<stream_index>
Argument:

values
always ‘1’
Example – route 2/1.1 through CAM A:
DocumentationTest# configure interface 2 cam a routing input 1.1

5.4.1.9.3.2 TO UNROUTE A CAM
To unroute a CAM:
Syntax:
no cam {a|b} routing
Example – unroute CAM A in module 2:
DocumentationTest(interface 2)# no cam a routing

5.4.1.9.4 CI CLOCK SETTING FOR IP INPUTS

CI (Common Interface) is the interface between the CAM and the host (=Luminato’s RF or IP input interface). The CI
(Command Interface) clock rate defines the bandwidth of the CI.
The CI clock for RF inputs is automatically derived from the input signal bitrate. For IP inputs in LIC-A and receiver modules
1
with dual IP input capability (LRT-B/C/H/I, LRC-A/B), the default CI clock is at the DVB CI standard maximum of 9 MHz
1
ETSI EN 50221
172
which will result in a maximal bit rate of 72 Mb/s. You may set the CI clock manually if the CAM in use supports higher bit
rates or if the CAM is not DVB compliant and does not function at the default clock. However, the default CI clock value
should work with most CAMs without problems.
To set the IP input CI clock:
Syntax:
ci-clock
{7.0MHz|9.0MHz|9.4MHz|9.8MHz|10.3MHz|10.8MHz|11.4MHz|12.0MHz12.7MHz|13.5MHz|14.4MHz|15.4MHz|16.6MHz|
18.0MHz|19.6MHz|21.6MHz|24.0MHz}
NOTE! The CI clock may only be customized with IP inputs.
Example – the CAM routed to IP interface 2/1.1 is capable of a maximum transfer bitrate of 96 Mb/s:
DocumentationTest# configure interface ip input 2/1.1 ci-clock 12.0MHz

5.4.1.9.5 CAM FAILURE ACTION SETTINGS

The failure action settings define the sequence of actions that Luminato takes whenever its internal descrambling
monitoring function reports a descrambling failure.
The actions are performed in the following order:
1. Restart descrambling
2. Reset CAM
3. Reset module
Each step of action is tried a set number of times before moving to the next step until success is met. You may set the
amount of retries for actions 1 and 2.
Hint: You may also reset a CAM manually, see chapter
5.4.1.9.5.1 SET THE AMOUNT OF RETRIES

To set amount of retries for the descrambling failure action:
Syntax:
cam {a|b} failure-action {pmt-refresh|cam-reset} {off|<retries>}
173
Keywords & argument:

values
pmt- Re-sends the CA_PMT table to the CAM; this effectively restarts the descrambling process.
refresh Select the amount of retries, the default and recommended value is 2.
cam- Reboots the CAM. Select the amount of retries, the default and recommended value is 1.
reset
off Disables the target failure action.
retries The amount of retries. {1…3}
5.4.1.9.5.2 ENABLING OR DISABLING THE REBOOT MODULE FAILURE ACTION
To enable or disable the reset module descrambling failure action:
Syntax:
cam {a|b} failure-action [no] module-reset
Keyword:

no This optional keyword disables the module reboot descrambling failure action.
Caution! This descrambling failure action is disabled by default as it will interrupt all service streaming of that
module. Use with caution!
5.4.1.9.5.3 DESCRAMBLING FAILURE ACTION TIMEOUT

The descrambling failure timeout parameter determines the wait time before proceeding to the next failure action.
To set the failure action timeout of a CAM in seconds:
Syntax:
cam {a|b} failure-action timeout {1…600}
Example – We want a delay of 60 seconds before each failure action in CAM A of module 2:
DocumentationTest# configure interface 2 cam a failure-action timeout 60

5.4.1.9.6 R ESETTING A CAM MANUALLY

To reset a CAM manually:
Syntax:
cam {a|b} reset
174
Example – reset the CAM present in CA -slot A of module 1:
DocumentationTest(interface 1)# cam a reset

5.4.1.9.7 CAM FAILURE ACTIONS WITH TIME - SHARED SERVICES

If time-shared services are descrambled, different recommendations may apply:
• If multiple services are descrambled, and one or more of them are time-shared: set 2 for Restart
descrambling, Disabled for Reset CAM and Reset Module.
• If it has been proved that Restart descrambling has not helped recovering descrambling in case of a
specific time-shared service, Restart descrambling can be set as Disabled to speed up failure
recovery.
• If the descrambled services require different failure actions, it is recommended to divide the
services to different CAMs according to failure action.
• This way, those services that are not time-shared or recover well with CA_PMT update, do not
suffer from unnecessary CAM resets.
• Reset module should be enabled only in some very rare cases when Restart descrambling and Reset
CAM have been proven not to recover descrambling. This will reboot the whole receiver module,
not only the CAM, causing a break in all received services in the module.
5.4.2 DVB-ASI RECEIVERS
FIGURE 21: LAS-C QUADRUPLE ASI INPUT MODULE
175
5.4.2.1 DVB-ASI INPUT INTERFACE CONFIGURATION
There are no demodulation parameters to configure for ASI input interfaces. The configuration commands available are
those common to all input interfaces, for example:
• enabling/disabling interfaces
• labelling interfaces
• emphasizing missing input signals in status reports
5.4.2.1.1 E NTERING ASI INPUT INTERFACE LEVEL CONFIGURATION MODE

To enter DVB-ASI input interface level configuration mode:
Syntax:
configure interface asi input <slot_number>/<connector_number>
Example – enter connector level configuration mode for ASI input 1/1:
DEMO-3# configure interface asi input 1/1

DEMO-3(iface-asi-input-1/1)#
176
5.4.3 SATELLITE RECEIVERS
FIGURE 22: LRS-C DUAL DVB-S/S2 RECEIVER WITH TWO CA-MODULE SLOTS
177
FIGURE 23: LRS-D QUADRUPLE DVB-S/S2 RECEIVER
5.4.3.1 DVB-S/S2 INPUT INTERFACE CONFIGURATION
5.4.3.1.1 E NTERING DVB-S OR DVB-S2 INPUT INTERFACE LEVEL CONFIGURATION MODE

To enter DVB-ASI input interface level configuration mode:
Syntax:
configure interface {dvbs|dvbs2} input <slot_number>/<connector_number>
178
Example – enter interface level configuration mode for DVB-S2 input 1/1:
DocumentationTest# configure interface dvbs2 input 1/1

5.4.3.1.2 T UNING FREQUENCY

1
To specify the target tuning frequency for satellite broadcast reception :
Syntax:
sat frequency <frequency>
Argument:

frequency Specify the frequency in Hz {0…999999999999}
Example – Set the DVB-S tuner to 11229 MHz:
DocumentationTest(iface-dvbs-input-1/1)# sat frequency 11229000000

DocumentationTest(iface-dvbs-input-1/1)#
5.4.3.1.3 C ARRIER FREQUENCY SHIFT WARNING LIMIT

The received carrier frequency is rarely the same as the transmitted sent uplink. Frequency shifts in the received baseband
quadrature components are caused by:
• uplink to downlink frequency conversion in satellite transponders

• carrier frequency block downconversion in LNBs. The LNB local oscillator frequency may drift due to temperature
and other reasons
• the oscillators in the headend tuner
• Doppler shift
This shift in carrier frequency is called frequency offset in Luminato; i.e. the difference between the nominal frequency
and the actual received frequency. If the frequency offset becomes too large, carrier locking in the receiver’s automatic
frequency control might become unreliable. You set a warning limit for the frequency offset. Once the warning threshold
limit has been passed a warning message will be issued. By default, no warning message is issued.
To set the frequency offset warning limit:
Syntax:
frequency offset limit <warning_threshold>
1
Consult a satellite directory for the correct settings, for example: http://www.lyngsat.com/, http://www.satcodx.com/ or
http://en.kingofsat.net/.
179
Argument:

warning_threshold Specify the frequency shift limit in Hz. Once this limit has been passed, a {0…999999999999}
warning message will be issued. By default, no warning message is issued.
Example – set the frequency offset limit to 10 MHz:
DocumentationTest(iface-dvbs2-input-1/1)# frequency offset limit 10000000

5.4.3.1.4 LNB FREQUENCY

The downlink satellite signal is a high frequency (microwave) signal. Since electronic circuits operating at high frequency
are relatively difficult and expensive to design and since high frequency signals lose more power than lower frequencies
when travelling through cables, the microwave signal is downconverted to lower frequencies called intermediate
frequencies (IF) before being forwarded to the tuner. The component responsible for this conversion is called an LNB (Low
Noise Block downconverter). The LNB is actually a collection of several components: a low-noise amplifier, a frequency
mixer, a local oscillator (LO) and an IF amplifier. The LO frequency determines which block of microwave frequencies will
be downconverted to IF. For example, European Universal LNBs have switchable LO frequencies and use 9750 MHz for low
band (10.70-11.70 GHz) downconvertion and 10600 MHz for high band (11.70-12.71065 GHz) downconvertion.
1
To specify the LO frequency (=LNB frequency) :’
Syntax:
lnb frequency <LO_frequency>
Argument:

LO_frequency Specify the LNB’s local oscillator frequency in Hz. {0…999999999999}
Example – set the LO frequency for the DVB-S input interface 1/1 to 9750 MHz
DocumentationTest(iface-dvbs2-input-1/1)# lnb frequency 9750000000

5.4.3.1.5 S YMBOL RATE

Symbol rate is the amount of symbols being transmitted per second by a satellite link. The amount bits being conveyed
depends on the used modulation.
1
Consult a satellite directory for the correct settings, for example: http://www.lyngsat.com/, http://www.satcodx.com/ or
http://en.kingofsat.net/.
180
To specify the symbol rate of the input satellite signal:
Syntax:
symbolrate {auto|<symbol_rate>}
Keyword & argument:

auto Automatically detects the input symbol rate.
symbol_rate Specify the input symbol rate in sym/s {0…999999999}
Example – set the input symbol rate to 24500 ksym/s for DVB-S2 input interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# symbolrate 24500000

To find the correct value, refer to a satellite directory.
5.4.3.1.6 D EMODULATION
The input signal’s modulation is automatically detected by default. The auto mode is recommended, but if the reception
conditions vary, it might be better to choose the fixed value to avoid automatic discovery. Choose a fixed value from
dropdown menu:
To specify the input signal modulation:
Syntax:
modulation {auto|QPSK|QPSK-high|8-PSK|8-PSK-high|16-APSK|32-APSK}
Keywords:

values
auto Automatically detects the input modulation.
QPSK- Use this demodulation mode for QPSK signals with symbol rates above 47000 ksym/s.
high This mode is available in input interfaces x/1 and x/3.
8-PSK- Use this demodulation mode for 8-QPSK signals with symbol rates above 31500 ksym/s
high
NOTE! In APSK and high bitrate PSK modulation modes, the next input, x:2.1 or x:4.1, will be disabled.
181
5.4.3.1.7 DVB-S2 MULTIPLE INPUT STREAM RECEPTION
1
The DVB-S2 standard allows the transmission multiple input streams (MIS) using a single transponder. The carried TSs are
identified by their respective Input Stream Identifier (ISI) located in the base-band header.
When then received DVB-S2 signal contains multiple TSs, you must select the target input TS by providing the target ISI.
To specify the target ISI:
Syntax:
multistream-id {1…255}
NOTE! In order to be able to select the target ISI, the DVB-S2 frontend tuner must be configured to the correct
frequency and the PLL must be in locked status. DVB-S and DVB-S2 Single Input Stream (SIS) signals do not carry any
stream identifier information and the ISI will be zero.
Example – select the TS identified by ISI 30 in DVB-S2 input:
DocumentationTest# configure interface dvbs2 input 1/2 multistream-id 30

To remove an ISI entry:
Syntax:
no multistream-id
5.4.3.1.8 LNB FEED

5.4.3.1.8.1 VOLTAGE
If LNB powering shall be supplied from the DVB-S/S2 receiver, you must specify the supply voltage level. If Universal LNB is
in use, then the supply voltage level is often used to switch between polarizations, typically in Europe 13 V for vertical
polarization and 18 V for horizontal.
5.4.3.1.8.1.1 E NABLING
To specify the supply voltage fed to the target LNB:
Syntax:
lnb voltage {13v|18v}
Example – enable 13 V power feed through input connector 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# lnb voltage 13v

1
EN 302 307 v1.3.1
182
5.4.3.1.8.1.2 D ISABLING
To disable the LNB feed :
Syntax:
no lnb voltage
Example – disable 13 V power feed through input connector 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# no lnb voltage

5.4.3.1.8.2 CURRENT ALARM LIMITS
5.4.3.1.8.2.1 L OW CURRENT
To specify the low current -alarm limit:
Syntax:
lnb low current {0…4000}
Example – set low current –alarm limit to 10 mA for interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# lnb low current 10

5.4.3.1.8.2.2 H IGH CURRENT
To specify the high current –alarm limit:
Syntax:
lnb high current {0…4000}
Example – set high current –alarm limit to 400 mA for interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# lnb high current 400

5.4.3.1.8.3 LONG LINE COMPENSATION
If the coaxial cable connecting the satellite dish to the receiver travels a long distance, you may need to compensate the
power loss in the LNB power feed due to attenuation. The command below boosts LNB voltage by 1V.
To enable/disable long line compensation:
Syntax:
[no] lnb long line compensation
Example:
DocumentationTest(iface-dvbs2-input-1/1)# lnb long line compensation

183
5.4.3.1.8.4 22 KHZ TONE
The DVB-S(2) input interfaces may configured to send a 22KHz tone through the connected coaxial cable. The usage 22
kHz tone depends on the used equipment for satellite reception (LNB, switches etc.). Originally the 22 kHz tone was used
for switching between satellite dishes, but nowadays it is usually used for band selection in the LNB.
NOTE! The 22 kHz tone is sent only if the LNB feed has been enabled.
To learn how to enable the LNB feed, see chapter
To enable/disable the 22 kHz tone:
Syntax:
[no] lnb 22khz
Keyword:

no This optional keyword disables the 22kHz tone.
Hint: The usage of the 22 Khz depends on the installed third party equipment, please refer to their user manuals.
Typically:
disabled = low band (10700…11900 MHz, LNB LO frequency is 9750 MHz)
enabled = high band (11550 … 12750 MHz, LNB LO frequency is 10600 MHz)
Example – enable 22 KHz tone in DVB-S2 input interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# lnb 22khz

5.4.3.1.9 D I SE Q C 1
TM
DiSEqC is a communication protocol for use between satellite receivers and devices such as multi-dish switches.
TM
Luminato DVB-S2 receiver modules support DiSEqC 1.0 and 1.2 (Module types: LRS-A/B/C/D).
TM
You may issue DiSEqC commands through the CLI and create a failure-action DiSEqCTM macro. The command word
consists of three parts: framing, address and command. Also some commands require ancillary data byte.
1 TM
DiSEqC is a trademark of EUTELSAT
184
5.4.3.1.9.1 ISSUING SINGULAR COMMANDS
TM
To issue a DiSEqC command:
Syntax:
diseqc send <framing> <address> command <cmd_name> [data_byte]
NOTE! DiSEqC accessories have different command instruction sets. Please consult your accessory manual for
supported commands.
Keywords:
framing Description Allowed values

FirstTrans Command from Master. No reply required, first transmission. -
RepeatTrans Command from Master. No reply required, repeated transmission. -

Keywords:
address Description Allowed values

AnyDevice Any Device (Master to all devices)
AnyLNB/SW/SMATV Any LNB, Switcher or SMATV (Master to all)
AnyPolar Any polariser (Master to all polarisers)
LNB LNB
LNBLoop LNB with loop-through switching.
LinearPolar Linear polarisation (skew) controller
SMATV SMATV
Switcher Switcher (DC blocking)
SwitcherLoop Switcher with DC loop-through.

Keywords:
cmd_name Description Allowed values

Awake Respond to future bus commands normally.
Ch.No Write (receiver’s) selected channel number.
PowerOn Switch peripheral power supply on.
SetHL Select horizontal polarisation (or left circular)

SetHi Select the high Local Oscillator frequency.
SetLo Select the low Local Oscillator frequency.
185
SetPosA Select satellite position A (or position C)
SetPosB Select satellite position B (or position D)

SetS0A Select switch Option A (e.g. positions A/B)
SetS0B Select switch Option B (e.g. positions C/D)

SetS1A Select switch S1 input A (deselect input B)
SetS1B Select switch S1 input B (deselect input A)

SetVR Select Vertical Polarisation (or Right circular)
Sleep Ignore all bus commands except “Awake”
Standby Switch peripheral power supply off
WriteFreq Write channel frequency (BCD string)
WriteN0 Write to port group 0 (Committed switches)
WriteN1 Write to port group 1 (Uncommitted switches)
WriteN2 Write to port group expansion option(N2)

WriteN3 Write to port group expansion option(N3)
Argument:

data_byte This optional keyword disables the 22kHz tone.
TM
Example – reset any DiSEqC compatible device connected to the interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# diseqc send FirstTrans AnyDevice command Reset

186
5.4.3.1.9.2 FAILURE-ACTION DISEQCTM MACRO
TM
You may define a sequence of DiSEqC commands that will be automatically executed upon module startup and signal
loss (=signal missing flag is raised). When the signal goes missing a five second delay is inserted before executing this
macro. A meta-command labelled Delay allows you to insert a delay ranging from 10 to 2550 ms before or after any
command in the macro; this is useful for allowing enough time for time-consuming commands to complete before issuing
the next command.
The macro can also be executed manually whenever deemed necessary.
5.4.3.1.9.2.1 D EFINING THE MACRO

TM TM
To building up a failure-action DiSEqC macro, define DiSEqC commands to be executed in the macro in the desired
order of execution. The commands are defined exactly the same as way as described in preceding chapter “Issuing
singular commands” except that the keyword send is replaced by the keyword queue and that cmd_name now includes
the meta-command Delay for introducing a delay before proceeding to the next command in the macro (explained in
chapter above).
Syntax:
diseqc queue <framing> <address> command <cmd_name> [data_byte]
NOTE! DiSEqC accessories have different command instruction sets. Please consult your accessory manual for
supported commands.
Keyword:

Delay Delay in ms times 10. {1…255}
The remaining keywords are explained in chapter “Issuing singular commands”
Example:
TM TM
We want to make a failure-action DiSEqC macro that first resets any DiSEqC compatible device connected to the
TM
interface 1/1, then, after a 100ms delay, power on any DiSEqC compatible device connected to the interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# diseqc queue FirstTrans AnyDevice command Reset

DocumentationTest(iface-dvbs2-input-1/1)# diseqc queue FirstTrans AnyDevice command Delay 10
DocumentationTest(iface-dvbs2-input-1/1)# diseqc queue FirstTrans AnyDevice command PowerOn
The above macro will be always executed when the satellite receiving module restarts or when the signal missing flag is
raised. It may also be manually executed at any time.
187
5.4.3.1.9.2.2 E XECUTING THE MACRO
TM
You may execute at any time the failure-action DiSEqC macro manually. To execute the macro:
Syntax:
diseqc queue execute
Example:
DocumentationTest(iface-dvbs2-input-1/1)# diseqc queue execute

5.4.3.1.9.2.3 C LEARING THE MACRO
To remove all commands from the failure-action macro:
no diseqc
5.4.3.1.9.2.4 V IEWING THE MACRO CONTENT

TM
To view the content of the failure-action DiSEqC macro:
Syntax:
show diseqc <slot_number>
Keyword:

Example – view the failure-action macro for satellite receiver in slot 1:
DocumentationTest(iface-dvbs2-input-1/1)# show diseqc 1

DISEqC queues in module LRS-C:
------------------
Input connector 1:
------------------
FirstTrans AnyDevice command Reset
FirstTrans AnyDevice command Delay 10
FirstTrans AnyDevice command PowerOn
------------------
Input connector 2:
------------------
188
5.4.3.1.9.3 RECOMMENDED DISEQC ACCESSORIES
DiSEqC multiswitches from following manufacturers have been tested with Luminato and found functional:
• Triax
• Maximum
• Digiality
• EMP-Centauri
• Televes
• Sunny
• Vizyon
• Edision
DiSEqC switches from the following manufacturers have been found incompatible:
• Goobay (low isolation)
5.4.3.1.10 S PECTRUM INVERSION

When the LNB’s LO frequency is higher than the input frequency, the output spectrum of the LNB is inverted. In this case,
the spectrum needs to be inverted once more to obtain the original spectrum (the I and Q components of the QAM signal
are interchanged). By default in Luminato, the spectrum is automatically inverted when necessary.
To enable automatic input spectrum inversion:
Syntax:
spectral inversion auto
NOTE! This is the default and recommend setting.
To disable automatic input spectrum inversion:
Syntax:
no spectral inversion
Example – disable automatic input signal inversion for input interface 1/1:
DocumentationTest(iface-dvbs2-input-1/1)# no spectral inversion

189
5.4.4 TERRESTRIAL RECEIVERS
FIGURE 24: LRT-A DUAL DVB-T, LRT-B DUAL DVB-T/T2, LRT-C QUAD DVB-T/T2 MODULES WITH TWO CA-MODULE SLOTS
5.4.4.1 DVB-T/T2 INPUT INTERFACE CONFIGURATION

DVB-T receivers’ (LRT-A) configuration parameters differ slightly from DVB-T/T2 receivers’ (LRT-B and LRT-C) and the
configuration procedures are therefore presented separately.
5.4.4.1.1 DVB-T RECEIVERS : LRT-A

5.4.4.1.1.1 ENTERING DVB-T INPUT INTERFACE LEVEL CONFIGURATION MODE
To enter DVB-T (LRT-A) input interface level configuration mode:
Syntax:
configure interface dvbt input <slot_number>/<connector_number>
Example – enter connector level interface configuration mode:
webtest-3# configure interface dvbt input 2/1

webtest-3(iface-dvbt-input-2/1)#
190
5.4.4.1.1.2 TUNING FREQUENCY
In most situations, frequency and channel bandwidth are the only mandatory information to provide for successful
broadcast DVB-T reception.
To set the receiving frequency of an input interface tuner:
Syntax:
rf frequency <ch_frequency>
Argument:

ch_frequency Specify the channel frequency in Hz {47000000…862000000}
Example – set DVB-T input interface 2/1 tuning frequency to 714 MHz:
webtest-3(iface-dvbt-input-2/1)# rf frequency 714000000

5.4.4.1.1.3 DEMODULATION
The input signal’s modulation is automatically detected by default. If the receiver has trouble locking to the input signal,
you may try selecting the demodulation mode manually. In that case, you may also have to specify the channel
parameters manually.
To specify the input signal’s modulation:
Syntax:
modulation {auto|QPSK|16-QAM|64-QAM}
Example – poor weather disturbs automatic input modulation detection, set demodulation to 64QAM in input 2/1:
webtest-3(iface-dvbt-input-2/1)# modulation 64-QAM

For the correct parameter settings, refer to terrestrial broadcaster web sites.
5.4.4.1.1.4 CHANNEL BANDWIDTH

You must manually specify channel bandwidth.
To select the channel bandwidth:
Syntax:
bandwidth {6MHz|7MHz|8MHz}
191
Example – set channel bandwidth of input interface 2/1 to 8 MHz:
webtest-3(iface-dvbt-input-2/1)# bandwidth 8MHz

5.4.4.1.1.5 TRANSMISSION MODE
DVB-T employs OFDM (Orthogonal Frequency-Division Multiplexing). It is a digital multicarrier modulation scheme, where
1
data is carried by a large amount of closely spaced carriers. In accordance with the DVB-T standard , there are two modes
available: 2k and 8k. The 2k mode has 1 705 and the 8k mode 6 817 carriers per OFDM symbol. The respective
approximate carrier spacings are 1 116 Hz and 4 464 Hz.
The input signal’s transmission mode is automatically detected by default. If the receiver has trouble locking to the input
signal, you may try selecting the transmission mode manually.
To select the transmission mode:
Syntax:
transmission mode {auto|2k|8k}
Example - poor weather disturbs automatic input transmission mode detection, set transmission mode to 2k in input
2/1:
webtest-3(iface-dvbt-input-2/1)# transmission mode 2k

5.4.4.1.1.6 GUARD INTERVAL
Guard intervals were introduced to the DVB-T standard EN 300 744 to counter intersymbol interference (ISI). Such
interferences may be due to propagation delays, echoes and/or reflections.
The input signal’s guard interval is automatically detected by default. If the receiver has trouble locking to the input signal,
you may try selecting the guard interval manually.
To select the guard interval:
Syntax:
guard-interval {auto|1/16|1/32|1/4|1/8}
Example - poor weather disturbs automatic input guard interval detection, set guard interval to 1/8 in input 2/1
webtest-3(iface-dvbt-input-2/1)# guard-interval 1/8

5.4.4.1.1.7 HIERARCHY
DVB-T transmission may be hierarchical or non-hierarchical. In hierarchical transmission, two MPEG TS may be
transported with different levels of channel coding and modulation. The hierarchical streams are referred to high priority
(HP) and low priority (LP) streams.
1
ETSI EN 300 744
192
In Luminato, hierarchical signal reception is either enabled or disabled. The high priority stream is always selected.
To enable/disable hierarchical signal reception:
Syntax:
[no] hierarchy
Example – disable hierarchical signal reception in DVB-T input interface 2/1:
webtest-3(iface-dvbt-input-2/1)# no hierarchy
5.4.4.1.1.8 INNER CODING RATE
In DVB-T, FEC functionality is implemented through the use punctured convolutional coding. In hierarchical transmission,
two different code rates may be used for the high and low priority streams.
The input signal’s inner code rate is automatically detected by default for the high and low priority streams. If the receiver
has trouble locking to the input signal, you may try selecting the inner code rate manually.
To select the inner coding rate for high and low priority streams:
Syntax:
fec rate {low|high} {auto|1/2|2/3|3/4|5/6|7/8}
Keywords:

low Targets low priority stream in hierarchical signal reception
high Targets high priority stream in hierarchical signal reception
Example – set input interface 2/1 inner code rate to 1/2 for low priority streams:
webtest-3(iface-dvbt-input-2/1)# fec rate low 1/2

5.4.4.1.2 DVB-T/T2 RECEIVERS : LRT-B AND LRT-C

5.4.4.1.2.1 ENTERING DVB-T INPUT INTERFACE LEVEL CONFIGURATION MODE
To enter DVB-T/T2 (LRT-B/C) input interface level configuration mode:
Syntax:
configure interface dvbt2 input <slot_number>/<connector_number>.<stream_index>

stream_index The stream index in this context is equivalent to the tuner index.
193
Example – enter stream level interface configuration mode:
DEMO-3# configure interface dvbt2 input 2/1.1

5.4.4.1.2.2 DVB STANDARD
The DVB-T/T2 receivers can operate in two different modes: DVB-T or DVB-T2 compliant modes. Select the operating
mode according to the input signal.
To select the DVB standard:
Syntax:
standard {dvbt|dvbt2}
Example – set input interface 2/1.1 to DVB-T mode:
DEMO-3(iface-dvbt2-input-2/1.1)# standard dvbt

5.4.4.1.2.3 DC FEED
You may feed current to active antennas. The DC feed voltage is fixed to 13 V.
5.4.4.1.2.3.1 E NABLING / DISABLING

To enable/disable DC feed:
Syntax:
dc feed [no] voltage 13V
Keyword:

no This optional keyword disables DC feed.
5.4.4.1.2.3.2 C URRENT ALARM LIMITS
5.4.4.1.2.3.2.1 LOW CURRENT
To specify the low current -alarm limit (mA):
Syntax:
dc-feed low current {0…99}
5.4.4.1.2.3.2.2 HIGH CURRENT

To specify the high current –alarm limit (mA):
Syntax:
dc-feed high current {1…100}
194
5.4.4.1.2.4 TUNING FREQUENCY
In most situations, frequency and bandwidth are the only mandatory information to provide. If the receiver has trouble
locking into the input signal, you may try to select manually the other front end reception parameters.
Syntax:
Argument:

Example – set DVB-T2 input interface 2/1.1 tuning frequency to 205.5 MHz:
DEMO-3(iface-dvbt2-input-2/1.1)# rf frequency 205500000

Refer to terrestrial broadcast web sites for the correct parameters.

You must manually specify the input channel bandwidth.
Syntax:
Example – set channel bandwidth of input interface 2/1 to 8 MHz:
DEMO-3(iface-dvbt2-input-2/1.1)# bandwidth 7MHz

5.4.4.1.2.6 TRANSMISSION MODE
NOTE! This parameter can be set only when the input interface is in DVB-T operating mode.
DVB-T employs OFDM (Orthogonal Frequency-Division Multiplexing). It is a digital multicarrier modulation scheme, where
1
data is carried by a large amount of closely spaced carriers. In accordance with the DVB-T standard , there are two modes
available: 2k and 8k. The 2k mode has 1 705 and the 8k mode 6 817 carriers per OFDM symbol. The respective
approximate carrier spacings are 1 116 Hz and 4 464 Hz.
1
ETSI EN 300 744
195
The input signal’s transmission mode is automatically detected by default. If the receiver has trouble locking to the input
signal, you may try selecting the transmission mode manually.
To select the transmission mode:
Syntax:
transmission mode {auto|2k|8k}
Example - poor weather disturbs automatic input transmission mode detection, set transmission mode to 2k in DVB-T
input 2/1.1:
DEMO-3(iface-dvbt2-input-2/1.1)# transmission mode 2k

Info: Transmission mode and guard interval are now both set to manual setting mode!
5.4.4.1.2.7 GUARD INTERVAL
interferences may be due to propagation delays, echoes and/or reflections.
The input signal’s guard interval is automatically detected by default. If the receiver has trouble locking to the input signal,
you may try selecting the guard interval manually.
To select the guard interval:
Syntax:
guard-interval {auto|1/16|1/32|1/4|1/8}
Example - poor weather disturbs automatic input guard interval detection, set guard interval to 1/8 in input 2/1.1:
DEMO-3(iface-dvbt2-input-2/1.1)# guard-interval 1/8

5.4.4.1.2.8 HIERARCHY
DVB-T transmission may be hierarchical or non-hierarchical. In hierarchical transmission, two MPEG TS may be
transported with different levels of channel coding and modulation. The hierarchical streams are referred to high priority
and low priority streams.
To select a stream in hierarchical signal reception:
Syntax:
hierarchy {hp|none/lp}
196
Example – select the low priority stream in hierarchical transmission, in DVB-T input interface 2/1.1:
DEMO-3(iface-dvbt2-input-2/1.1)# hierarchy none/lp

5.4.4.1.2.9 MULTIPLE PHYSICAL LAYER PIPE RECEPTION
1
The DVB-T2 standard introduces the concept of Physical Layer Pipes (PLPs): a single DVB-T2 channel frequency may
contain one or more MPEG-2 TS, each conveyed by its own PLP. Each PLP can have its own modulation, FEC code rate and
interleaving. The benefit is that with a single frequency broadcasters may deliver several different service bouquets based
on level of signal robustness required: for example, mobile and radio with a high signal robustness and 3D/HD with lower
signal robustness.
The received DVB-T2 multiplex may be single PLP or multiple PLP. If the target DVB-T2 broadcast employs M-PLP (Multiple
Physical Pipe) technology, you have to choose the Data PLP ID manually from the drop-down menu to demodulate the
desired TS. If none is chosen the default data PLP ID will be the smallest ID number within the broadcast. Consult
terrestrial broadcast web sites for the correct ID.
To select a PLP from a DVB-T2 broadcast:
Syntax:
plp-id {unset|0…255}
NOTE! The ‘unset’ keyword allows automatic data PLP ID selection with single-PLP DVB-T2 signals. Do not use this
keyword with M-PLP signals!
5.4.4.2 ISDB-T RECEIVERS : LRT-H AND LRT-I

LRT-H is a dual ISDB-Tb receiver and LRT-I a quadruple ISDB-Tb receiver. ISDB-Tb (also known ISDB-T International or
SBTVD) is a digital television broadcasting standard based on the Japanese ISDB-T standard
5.4.4.2.1 E NTERING ISDB-T INPUT INTERFACE LEVEL CONFIGURATION MODE

To enter ISDB-T input interface level configuration mode:
Syntax:
configure interface isdb-t input <slot_number>/<connector_number>.<stream_index>

Example - enter stream level interface configuration mode:
NamiLuto# configure interface isdb-t input 6/1.1

NamiLuto(iface-isdb-t-input-6/1.1)#
1
EN 302 755 V1.3.1
197
5.4.4.2.2 DC FEED
Refer to chapter “DC feed”

In most situations, frequency and bandwidth are the only mandatory information to provide. If the receiver has trouble
locking into the input signal, you may try to select manually the other front end reception parameters.
Syntax:
Argument:

Example – set ISDB-T input interface 6/1.1 tuning frequency to 205.5 MHz:
NamiLuto(iface-isdb-t-input-6/1.1)# rf frequency 205500000

NamiLuto(iface-isdb-t-input-6/1.1)#
Refer to terrestrial broadcast web sites for the correct parameters.
5.4.4.2.4 C HANNEL BANDWIDTH

The channel bandwidth is fixed to 6 MHz.
5.4.4.2.5 T RANSMISSION MODE & G UARD INTERVAL

The OFDM carrier spacing (=transmission mode) and guard interval ratio of the input signal are automatically detected and
cannot be manually selected.
198
5.4.5 CABLE RECEIVERS
FIGURE 25: LRC-A DUAL AND LRC-B QUAD DVB-C RECEIVERS WITH TWO CA-MODULE SLOTS
5.4.5.1 DVB-C RECEIVERS
5.4.5.1.1 E NTERING DVB-C INPUT INTERFACE LEVEL CONFIGURATION MODE

To enter DVB-C input interface level configuration mode:
Syntax:
configure interface dvbc input <slot_number>/<connector_number>.<stream_index>
199
Argument

Example - enter stream level interface configuration mode:
webtest-3# configure interface dvbc input 1/1.1

webtest-3(iface-dvbc-input-1/1.1)#

The channel center frequency is the only information you need to provide for a PLL lock, the other parameters are
automatically detected.
Syntax:
Argument:

Example – set DVB-C input interface 1/1.1 tuning frequency to 242 MHz:
webtest-3(iface-dvbc-input-1/1.1)# rf frequency 242000000

webtest-3(iface-dvbc-input-1/1.1)#
Refer to terrestrial broadcast web sites for the correct channel frequency.
5.4.6 MULTISTANDARD RECEIVERS LRM-A, LRM-B

The LRM-A is a quadruple multistandard receiver with dual CI slots. It supports the following standards:
• DVB-T/T2
• DVB-S/S2/S2X
• DVB-C
• ITU-T J.83 Annex B
• ISDB-Tb
200
The LRM-B is a dual input multistandard receiver with dual CI slots. It supports the following standards:
• DVB-S/S2/S2X
• DVB-T/T2 (requires separate license)
• DVB-C (requires separate license)
• ITU-T J.83 Annex B (requires separate license)
• ISDB-Tb (requires separate license)
To learn how to acquire and install a license, see chapter 4.15
5.4.6.1 I NPUT STANDARD

Since the LRM is a multistandard receiver, you must specify the standard of the input signal. The LRM-A has two physical
input connectors and two input interface per connector; the selected standard is common to the input interfaces of the
same connector, you may however configure two different standards for both connectors.
To specify the input signal standard:
Syntax:
configure interface <slot_number> standard connector {1|2} {annexb|dvb-c|dvb-s2x|dvb-

t2|isdb-t}
Example – the input signal in input interface 2/2 is DVB-C:
Affe1# configure interface 2 standard connector 2 dvb-c

Affe1(interface 2)#
5.4.6.2 E NTERING MULTISTANDARD RECEIVER INPUT INTERFACE LEVEL CONFIGURATION MODE

To enter multistandard receiver input interface level configuration mode:
Syntax:
configure interface receiver input <slot_number>/<connector_number>.<stream_index>

Example - enter input interface 2/1.1 configuration mode:
Affe1# configure interface receiver input 2/1.1

Affe1(iface-receiver-input-2/1.1)#
201
5.4.6.2.1 DVB-T2
When the input standard dvb-t2 has been selected, the DVB-T/T2 signals are supported and automatically detected and
no further standard selection is necessary.
Once the input interface level configuration mode has been entered, the available commands are for most parts identical
to those of dedicated DVB-T/T2 modules such as the LRT-B and LRT-C. LRM has however a few additional commands
related to input signal level(s).
The commands are described in chapter “DVB-T/T2 receivers: LRT-B and LRT-C”
5.4.6.2.1.1 LOW SIGNAL LEVEL WARNING

With DVB-T(2) inputs, LRM allows you to define a threshold signal level for low input signal levels. When the signal level
goes below this threshold level, a ‘low signal level’ flag will be raised and a warning-level event added to the log.
To define the ‘low signal level’ alarm threshold level:
Syntax:
low-signal-level-alarm <threshold_level>
Argument:

values
threshold_level The threshold level for the low input signal level warning. Input the value in dBµV. {0…100}
The ‘0’ value effectively disables the ‘low signal level’ warning.
5.4.6.2.1.2 AUTOMATIC OUTPUT MUTING BASED ON INPUT SIGNAL STATUS

When input signal is DVB-T(2), the LRM is able to automatically shut down its IP outputs based on the signal status of the
inputs.
5.4.6.2.1.2.1 O PERATING PRINCIPLES

The output muting triggers are the Signal missing and/or Low signal level alarms.
When the signal –trigger is selected, the IP output is shut down when the input signal is considered as missing.
To learn how to adjust when a signal is considered as missing, see chapter

“8.2.6.2 Signal lost criteria”
When the quality –trigger is selected, the IP output is shut down when its mapped input signal level goes below the ‘low
signal level’ -warning threshold by an user definable amount. The factory default triggering limit for output muting is when
the input signal level is 10 dB below the Low signal level -threshold level.
To learn how to adjust the Low signal level warning –threshold, refer to chapter
“5.4.5.3.1.1 Low signal level warning”
202
NOTE! The limit for output muting is only configurable through the CLI.
To prevent the affected interfaces from flapping from one state to another, a user-adjustable hysteresis is added to the
low-signal-level-alarm -threshold level before the muted IP output may be re-enabled.
5.4.6.2.1.2.2 C ONFIGURATION
The muting threshold and hysteresis for the low signal level trigger are module level settings.
Enter module level configuration mode:
Syntax:
configure interface {1…6}
To adjust the IP output muting triggering limit:
Syntax:
low-signal-level-muting-threshold <limit>
Argument:

values
limit The triggering limit for IP output muting when the input signal level is below the Low signal {0…20}
level -threshold level by the specified amount. Insert the limit value in dB. The factory default
limit 10 dB.
Example:
To adjust the hysteresis for re-enabling a muted output:
Syntax:
low-signal-level-alarm-hysteresis <hysteresis>
Argument:

values
hysteresis Defines the amount by which the input signal level must exceed the low-signal-level- {0…20}
alarm threshold before a muted IP output may be unmuted. Insert thevalue in dB. The factory
default hysteresis 5dB.
203
Example:
The IP output 2/1.1 has been muted due to low input signal level. The low-signal-level-alarm has been set to 50
dBµV and the low-signal-level-alarm-hysteresis to 10 dB. The IP output 2/1.1 will re-enabled (unmuted) only
when the input signal level will reach 60 dBµV.
The muting triggers are enabled and disabled in IP output stream configuration mode.
Enter IP output stream configuration mode:
Syntax:
configure interface ip output <slot_number>/<connector_number>.<stream_index>
To enable or disable the IP output muting triggers:
Syntax:
[no] muting trigger {quality|signal} [quality|signal]
Keywords:

values
no Disables the specified muting triggers. -
quality The IP output is automatically shut down when its mapped input signal level goes below the -
‘low signal level’ -warning threshold by an amount defined by the low-signal-level-
muting-threshold value.
signal The IP output is automatically shut down when the input signal is considered as missing. -
5.4.6.2.2 DVB-S2X
When the input standard dvb-s2x has been selected, the DVB-S/S2/S2x standards are supported and automatically
detected.
5.4.6.2.2.1 ABOUT DVB-S2X

The DVB-S2X (ETSI EN 302 307-2 v1.1.1) is an optional extension to the DVB-S2 standard (ETSI EN 302 307-1 v1.4.1). This
extension enables to operate with very-low carrier-to-noise and carrier-to-interference ratios and offers higher capacity
and efficiency transmission modes.
5.4.6.2.2.2 CONFIGURATION
Once the input interface level configuration mode has been entered, the available commands are in most part identical to
those of dedicated DVB-S/S2 modules such as the LRS-C. There are three differences:
• The command for changing the channel centre frequency is different (see chapter “” below)
• Spectral inversion is not available
• The carrier frequency shift warning limit is not configurable
204
• You may specify the physical layer scrambling Gold sequence index or the PL scrambling initialization value
The common commands are described in chapter “DVB-S/S2 input interface

configuration”
5.4.6.2.2.2.1 C HANNEL CENTRE FREQUENCY

To specify channel centre frequency:
Syntax:
Argument:

ch_frequency Specify the channel centre frequency in Hz {40000000…999999999999}
5.4.6.2.2.2.2 PL SCRAMBLING G OLD SEQUENCE INDEX
In DVB-S2/S2X, Physical Layer frames are randomized prior modulation to mitigate co-channel interference: this technique
is called Physical Layer scrambling and is based on energy dispersal of the signal.
In order for LRM to be able to lock onto the signal, the Gold sequence index n (or the PL scrambling initialisation value)
value must be known. The DVB standard default Gold codes are known and automatically detected by the LRM, but any
other arbitrary Gold sequence index values must be fed to the module.
To specify the Gold sequence index or the PL scrambling initialisation value (in receiver input configuration mode):
Syntax:
pls {none|gold|root}
Keywords:

none Clear user specified Gold sequence index or PL scrambling initialisation value -
gold Specify the Gold sequence index
root Specify PL scrambling initialisation value
5.4.6.2.3 DVB-C
Once the input standard dvb-c has been selected and the input interface level configuration mode has been entered, the
available commands are in most part identical to those of dedicated DVB-C modules such as the LRC-B. There is however
one difference: in DVB-C dedicated modules such as the LRC-B, the symbol rate was automatically detected; in the LRM-A,
the symbol rate must be specified (see the chapter “Symbol rate” below).
To learn how to specify the channel centre frequency, see chapter “Tuning
frequency”
205
5.4.6.2.3.1 SYMBOL RATE
The symbol rate is the amount of symbols being transmitted per second. The amount of bits being conveyed depends on
the used modulation.
Hint: The symbol rate is not specified by the DVB-C standard, but the roll-off factor of the square-root raised cosine
filters is fixed to 15 % from which can be derived the maximum symbol rate. Typically it is 6,9 MBaud for 8 MHz channel
raster applications.
To specify the symbol rate:
Syntax:
symbolrate {0…999999999999}
5.4.6.2.4 ITU-T J.83 A NNEX B

Once the input standard annexb has been selected and the input interface level configuration mode has been entered,
the available commands are in most part identical to those of dedicated DVB-C modules such as the LRC-B. There is
however one difference: in DVB-C dedicated modules such as the LRC-B, the symbol rate was automatically detected; in
the LRM-A, the symbol rate must be manually specified (see the chapter “Symbol rate” below).
frequency”
5.4.6.2.4.1 SYMBOL RATE

The symbol rate is the amount of symbols being transmitted per second. The amount of bits being conveyed depends on
the used modulation.
NOTE! The ITU-T Recommendation J83 Annex B specifies two symbol rate modes: 5.057 Msymbols/s 64-QAM (Mode
1) and 5.361 Msymbols/s 256-QAM (Mode 2).
To specify the symbol rate:
Syntax:
symbolrate {0…999999999999}
5.4.6.2.5 ISDB-T B
Once the input standard isdb-t has been selected and the input interface level configuration mode has been entered,
the available commands are in most part identical to those of dedicated ISDB-Tb modules such as the LRT-H and LRT-I.
There is however one difference: in ISDB-T dedicated modules such as the LRT-H and the LRT-I, the channel bandwidth is
fixed to 6 MHz; in the LRM-A, the channel bandwidth must be manually specified (see the chapter “” below).
frequency”
206
You must manually specify the input channel bandwidth.
Syntax:
5.4.7 IP INPUT INTERFACES

You are able to create IP input interfaces for either internal or external streaming. IP inputs are created in output modules
and in some input modules equipped with CA descrambling (LRT-B/C/H/I, LRC-A/B, LRM-A, LIC-A).
1
Up to 120 IP inputs may be created in output modules and up to two in input modules (LRT-B/C/H/I, LRC-A/B, LRM-A, LIC-
A).
To receive an IP transport stream, you must create an IP input interface either for a GE payload port (=external streaming)
or for an internal VLAN (=internal streaming).
NOTE! You may create IP input interfaces only, if your chassis includes an output module or one of the following: LRT-
B/C/H/I, LRC-A/B an LIC-A
5.4.7.1.1 IP STREAM BROADCAST TYPE

In media streaming there are basically two types of broadcast:
• Multicast:
o copies of a single IP packet are delivered to multiple recipients
o Class D IP Address range:
o 224.0.0.0 – 239.255.255.255
o Typically used to broadcast TV content to several users simultaneously such as with live TV broadcasts
o Reduces the server and network load
• Unicast:
o IP packets are delivered to a single recipient
o Typically used to deliver personalized content over an IP network such as a specific movie to a given user
(IPTV VOD)
o Consumes a lot of bandwidth since the same content must be streamed for each users separately
1
Actually, the maximum amount of inputs is 128, but in the web UI 8 stream index are reserved for automatic internal routing. In the
CLI, such restriction does not apply.
207
5.4.7.2 C REATING AN IP INPUT INTERFACE AND ENTERING CONFIGURATION MODE
5.4.7.2.1 I N AN OUTPUT MODULE

To create an IP input in an output module and/or to enter IP input interface configuration mode:
Syntax:
configure interface ip input <slot_number>/1.<stream_index>
Arguments:

stream_index Specifies the target IP stream index. {1…128}
5.4.7.2.2 I N AN INPUT MODULE

To create an IP input in an input module and/or to enter IP input interface configuration mode:
Syntax:
configure interface ip input <slot_number>/3.<stream_index>
Arguments:

5.4.7.3 CONFIGURING AN IP INPUT INTERFACE

Enter IP input interface configuration mode as described in chapter “Creating an IP input interface and entering
configuration mode”
5.4.7.3.1 I NPUT STREAM DESTINATION IP ADDRESS AND UDP PORT

To specify the destination IP address and destination UDP port of the incoming stream:
udp {<ip_address>|unicast}:<port>

values
ip_address Multicast stream reception. The specified address must be within the class D address
range: 224.0.0.0 – 239.255.255.255.
unicast Unicast stream reception. IP address is the target module’s IP payload address.
208
values
UDP_port Specifies the UDP source port for the transmitted streams by this module. {0…65535}
To learn how to change the IP payload address of an input interface, see chapter Module payload IP address
5.4.7.3.2 P AYLOAD INTERFACE

You have two types of payload interface:
• External:
o GE1&GE2 ports
o User created VLANs assigned to the above mentioned GE1&GE2
• Internal:
o Internal payload interface labelled internal in the UI (technically it is a hardcoded VLAN
defined as internal, meaning its traffic is not forwarded by the GE1&GE2 ports)
o User created VLANs defined as internal (meaning their traffic is not forwarded by the
GE1&GE2 ports)
To specify the payload interface in which the stream is present:
Syntax:
payload-port {all|ge1|ge2|internal|vlan <id>}
Keyword:

all Stream is joined either from GE1 or GE2.
5.4.7.3.3 SSM SOURCE IP ADDRESS

If the IP input stream is multicast and SSM (Source-Specific Multicasting) is in use, you need to specify the source IP
address. Only multicast stream originating from the specified source IP address will be joined.
To specify the source IP address when SSM is in use:
Syntax:
src-ip <ip_address>
5.4.7.3.4 D ISABLING SSM SOURCE IP ADDRESS

To disable SSM in an IP input interface:
Syntax:
no src-ip
209
5.4.7.4 R EMOVING AN IP INPUT INTERFACE
5.4.7.4.1 F ROM AN OUTPUT MODULE

To remove an IP input interface for an output module:
Syntax:
configure no interface ip input <slot_number>/1.<stream_index>
5.4.7.4.2 F ROM AN INPUT MODULE

To remove an IP input interface for an input module:
Syntax:
configure no interface ip input <slot_number>/3.<stream_index>
5.4.8 IP-TO-IP DESCRAMBLER

LIC-A is a dual MPTS input IP-to-IP gateway with hardware descrambling capability, that features two CAM slots. The LIC-A
is like any other receiver type module, except that it doesn’t have any RF input connectors.
5.4.8.1 C ONFIGURATION
Take the following configuration steps:
1. Set up the CAM(s) (Conditional Access Module(s)) for service descrambling.
To learn how to set up a CA module, see chapter “Descrambling module setup”
2. Create IP inputs interfaces (up to two inputs may be created). If the input needs to be descrambled
before being multiplexed as QAM or COFDM, select Internal as the payload interface.
To learn how to create an IP input interface, see chapter IP input interfaces
3. OPTIONAL: Assess the maximal bitrate of the IP input streams and set the CI clock accordingly (the
default value is 9 MHz resulting in a max bitrate of 72 Mb/s). This step is necessary only if the CAM
supports higher CI clock rates than 9 MHz and you intend to use the full byte transfer rate capacity
of the target CAM.
To learn how to set the CI clock, see chapter “CI clock setting for IP inputs”
4. Descramble the input stream(s) if necessary
To learn how to descramble services or only some of their components, see

chapter “Descrambling”
5. Route the input services or the whole TS(s) to the target output interface
210
To learn how to route input services or TSs to output interfaces, see chapter
Service configuration
5.5 OUTPUT INTERFACES

5.5.1 OUTPUT INTERFACE COMMON COMMANDS
5.5.1.1 P ASSTHROUGH SERVICE TIMEOUT

In this chapter are described the commands for configuring the passthrough service timeout at module and TS (multiplex)
level.
To learn more about the passthrough service timeout parameter and how to
configure it at chassis level, see chapter “Passthrough service timeout”
5.5.1.2 M ODULE DEFAULT PASSTHROUGH SERVICE TIMEOUT

To set the module wide default passthrough service timeout:
configure interface {slot_number} output timeout service

{never|default|<timeout_in_seconds>}
5.5.1.3 S TREAM LEVEL P ASSTHROUGH SERVICE TIMEOUT

To set stream level passthrough service timeout:
configure interface {asi|ip|qam|cofdm} output <slot_number>.<connector_number>

<stream_index> passthrough services <connector_number>.<stream_index> timeout service
{never|default|<timeout_in_seconds>}
5.5.2 LOW-LEVEL PID EXCLUSION

The low-level PID exclude feature can be used to filter any PID from output, including inserted tables and EMMs. It does
not affect the content of SI tables, it only blocks the specified PID from the output.
5.5.2.1 A DDING A PID TO THE LOW - LEVEL EXCLUSION LIST

To exclude a PID from the output multiplex:
Syntax:
configure interface {qam|cofdm|asi|ip} output <slot_number>.<connector_number>

<stream_index> pid-erase <pid>
5.5.2.2 R EMOVING A PID FROM THE LOW - LEVEL EXCLUSION LIST

To remove a PID from the low level PID exclusion filter list:
Syntax:
configure interface {qam|cofdm|asi|ip} output <slot_number>.<connector_number>

<stream_index> no pid-erase <pid>
211
5.5.3 DVB-ASI OUTPUTS
FIGURE 26: LAS-D QUADRUPLE ASI OUTPUT MODULE
The LAS-B/D ASI output modules have four multiplexers. You must define the multiplexers’ bandwidths. Each of the four
multiplexers has its own settings.
Up to two exact copies of any output multiplex can also be transmitted as IP streams; this is sometimes referred to as IP
mirroring. This is useful for copying a multiplex to another multiplexer in another location or just simply for monitoring
purposes.
Caution! With LAS-D, disabling an ASI-output mutes also any configured multiplex IP streaming (IP mirroring) of that
particular output.
5.5.3.1.1 E NTERING DVB-C INPUT INTERFACE LEVEL CONFIGURATION MODE

To enter DVB-C input interface level configuration mode:
Syntax:
configure interface asi output <slot_number>/<connector_number>.1
212
5.5.3.1.2 M ULTIPLEX BANDWIDTH
To define the ASI output bandwidth expressed in bit/s:
Syntax:
bitrate <bit_rate>
5.5.3.1.3 ASI OUTPUT MODE

In most of the applications, the factory default ASI output mode, Byte mode, is the right choice, but in some rare cases the
1
receiving end might require instead the TS packet mode. These modes are defined by the DVB-ASI standards .
Byte mode:
In this mode, the MPEG transport packets are transmitted as data bursts with each individual bytes separated by sync
bytes called K28.5 comma characters; extra stuffing is not used between packets.
Example: when an encoder is set at a total data rate of 27.9 Mb/s, the bytes are sent
every 289 ns with either 6 or 7 commas between each data byte. The total payload rate
is changed by sending a different number of sync bytes between each data byte.
TS packet mode:
In this mode, the MPEG transport packets are transmitted as blocks of contiguous data at a constant rate of 270 MHz
without sync bytes between individual payload data bytes. 188 byte packets last around 7 ms independent of the total
data rate. K28.5 commas are added between packets until the rate of 270 MHz can be maintained.
Example: when the total data rate is set at 28 Mb/s, packets are sent with 47 ms worth
of commas. Whereas 80 Mb/s and 155 Mb/s rates require 12 ms and 3 ms respectively
and anything over 200 Mb/s requires very few commas.
This mode is commonly used when payload rates reach above the 80 Mb/s level. At this data rate, the Byte mode does not
reduce the need for buffering capacity.
To enable/disable the ASI output TS packet mode of an output interface:
Syntax:
[no] packet-mode
1
EN 50083-9
213
5.5.4 QAM MODULATOR OUTPUTS
FIGURE 27: LQM-C TRANSMITTER MODULE
The Luminato QAM modulator modules feature four modulators in adjacent channels, sharing the same upconverter.
When the base frequency of the first modulator is set, the frequencies of the other modulators follow the first one in
incremental steps defined by the channel bandwidth. Each modulator may be enabled or disabled individually.
purposes.
5.5.4.1 QAM OUTPUT INTERFACE CONFIGURATION

The configuration of QAM modulators takes place at two levels: connector level and at multiplexer level.
5.5.4.1.1 E NTERING CONNECTOR LEVEL INTERFACE CONFIGURATION MODE

At connector level, you set the global settings for all four modulators of the QAM module. Modulation scheme and symbol
rate may also be set at modulator level thus bypassing the global settings
To enter module level interface configuration mode:
Syntax:
configure interface qam output <slot_number>/1
214
5.5.4.1.1.1 CONNECTOR LEVEL COMMANDS
5.5.4.1.1.1.1 CATV STANDARD
There are two options for CATV standard; the choice depends on in which country the target CATV network operates:
choose DVB-C for the European region and J.83 Annex B for the North American region.
To select the CATV transmission standard:
Syntax:
qam-standard {dvbc|j83annexb}
5.5.4.1.1.1.2 C ONVOLUTIONAL INTERLEAVER

Signal transmission in communication systems is never ideal; various signal impairments (noise, interference, distortion)
are likely to occur in the communication channel. These impairments may induce errors in the received message. To
combat these errors, several forward error correction (FEC) techniques are employed; one of them is called convolutional
interleaving and deinterleaving.
Both DVB-C and J.83 Annex B standards use convolutional interleaving to protect the data against burst noise in the
communication channel by spreading burst errors in time. A burst noise in the channel can cause the corruption of several
consecutive bytes/symbols, but since the bytes/symbols are spread over time before transmission, deinterleaving at
reception will spread the errors over many Reed-Solomon (R-S) blocks thus moving the errors-per-R-S-blocks ratio within
range of the error correcting capability of the R-S decoder.
Technically the convolutional interleaver employs a commutator which position increments at the R-S symbol frequency,
connecting the R-S encoder output sequentially to a I paths which are shift registers. Each consecutive path has J symbols
more storage, hence the name ‘depth’. Each consecutive path adds J symbol period more delay, so that the last path, Ith
path, has (I-1) * J symbol periods of delay.
To learn more about convolutional interleaving, refer to ITU-T J83 Annex B
When the DVB-C format is in use, you cannot alter the interleaving settings since they are fixed to I=12 and J=17 by the
DVB-C standard EN 300 429. However, with J.83 Annex B selected, you must define the interleaver depth.
To configure the J.83 Annex B interleaver:
Syntax:
j83-interleaver {8/16|16/8|32/4|64/2|128/1|128/2|128/3}
NOTE! For optimal compatibility, use 128/1 (Level 1 interleaver) This setting affects all the modulators of the target
QAM-module and cannot be bypassed at modulator level.
Hint:Use Table 2 to guide your choice.
215
TABLE 2: INTERLEAVING BURST PROTECTION AND LATENCY
Paths Interleaving depth Max. error burst length (µs) Interleaver latency (ms)
(I) (J) 64-QAM 256-QAM 64-QAM 256-QAM
128 1 94,92 65,98 4,018 2,793
64 2 47,46 32,99 1,993 1,386
32 4 23,73 16,49 0,981 0,682
16 8 11,86 8,25 0,475 0,330
8 16 5,93 4,12 0,221 0,154
128 2 189,8 132,0 8,036 5,586
128 3 284,8 197,9 12,06 8,379
5.5.4.1.1.1.3 B ASE FREQUENCY
The base frequency is the lowest QAM modulator’s center frequency: the three other modulators base their own center
frequency on this setting and the selected channel bandwidth. From this follows that the allowed base frequency range
depends on the channel bandwidth:
• 8 MHz channel bandwidth: 85…975 MHz allowed Base frequency range

To set the first carrier’s frequency in Hz:
Syntax:
frequency <frequency>
5.5.4.1.1.1.4 C HANNEL BANDWIDTH

Channel bandwidth sets the channel spacing; the permitted bandwidths are bound by the CATV standards:
• DVB-C: 7 or 8 MHz
• J.83 Annex B: 6 MHz
To set the channel bandwidth in Hz (channel raster):
Syntax:
offset <bandwidth>
NOTE! It is highly recommended to use the local standard compliant bandwidths to avoid any compatibility issues.
5.5.4.1.1.1.5 D EFAULT MODULATION ORDER

Select the default QAM order from the target. The selected modulation order is common to all the four modulators. Each
modulator may be individually configured to bypass the default modulation setting.
To learn more about modulator level settings, see chapter 0 below.
216
The available options depend on the chosen CATV standard (see above):
• DVB-C: 16-QAM, 32-QAM, 64-QAM, 128-QAM, 256-QAM

• J.83 Annex B: 64-QAM, 256-QAM
modulation {16-QAM|32-QAM|64-QAM|128-QAM|256-QAM}
Hint: Typically, 64-QAM is used. Higher order QAMs like 256-QAM allow more bits per symbols to be transmitted, but
also require better CNR in the HFC plant.
5.5.4.1.1.1.6 D EFAULT SYMBOL RATE

The connector level symbol rate is common to all the four modulators and is expressed in Megabauds, MBd. Enter a value
between 3,0 and 7,4 MBaud. It is highly recommended to use standard compliant values:
• DVB-C: the symbol rate is not specified by the standard, but the roll-off factor of the square-root
raised cosine filters is fixed to 15 % from which can be derived the maximum symbol rate. Typically
it is 6,9 MBaud for 8 MHz channel raster applications. Another common symbol rate is used in
head-ends where DVB-S signal is demodulated and re-transmitted in a DVB-C network unmodified
(except for the adapted PSI/SI tables). In this case, the symbol rate can be derived from the data
rate of the received DVB-S TS:
a) DVB-S_Data_rate = DVB-S_symbol_rate * Reed_Solomon * DVB-S_bits_per_symbol *
Code_rate:
a. For the typically used DVB-S symbol and code rates, 27,5 MBaud and 3/4:
Data_rate = 27,5 * 188/204 * 2 * 3/4 Mbit/s ≈ 38,015 Mbit/s
b) DVB-C_Symbol_rate = DVB-S_Data_rate * 1/Reed_Solomon * 1/ DVB-
C_bits_per_symbol
c) From a and b above follows, that for the typically used DVB-C modulation, 64-QAM:
Symbol_rate = 27,5 * 2 * 3/4 / 6 = 6,875 MBaud
• J.83 Annex B: symbol rate is set automatically according to the standard values: 5,057 MBaud with
QAM 64, 5,361 MBaud with QAM 256
To set the symbol rate for all carriers in sym/s:
Syntax:
symbolrate <symbol_rate>
Caution! When more than one QAM RF output is enabled, the entered value must be less than the [Channel
bandwidth / (1 + roll-off_factor)], otherwise the modulators will disturb each other.
217
5.5.4.1.1.1.7 C HANNEL OUTPUT LEVEL
The power level defines the channel output level from the RF output interface. The available power level range depends
on amount of channels in use and the relative position of the modulators in use, see Table 3 below.
Enabled channels & relative positions Power level range dBµV

1___ | _2__ | __3_ | ___4 110 – 120
12__ | _23_ | __34 106 – 116
123_ | _234 | 1_3_ | _2_4 104 – 114
1234 | 12_4 | 1_34 | 1__4 102 – 112
TABLE 3: CHANNEL OUTPUT POWER LEVEL RANGES
To set power level of one carrier in dBuV:
Syntax:
power level <power>
5.5.4.1.1.1.8 R OLL - OFF FACTOR

To select the roll-off factor in %:
Syntax:
rolloff {12|15|18}
NOTE! In J83 Annex B-mode, the roll-off is always set automatically to 25%.
5.5.4.1.1.1.9 O UTPUT SPECTRUM INVERSION

If necessary, you may invert the spectrum of the output signal (the I and Q components of the QAM signal are
interchanged). To do so, change the output spectrum mode from normal (default) to inverted.
To change the output spectrum:
Syntax:
output spectrum {normal|inverted}
NOTE! This setting affects all modulators of the target QAM-module and cannot be bypassed at modulator level.
5.5.4.1.1.1.10 E NABLING RF OUTPUT

To enable/disable carrier transmission:
[no] shutdown
NOTE! Disabling QAM-module’s RF-output does not affect multiplex IP streaming.
To learn more about output multiplex IP mirroring, see chapter 0.
218
5.5.4.1.2 E NTERING MODULATOR LEVEL CONFIGURATION MODE
To enter modulator level configuration mode:
Syntax:
configure interface qam output <slot_number>/1.<modulator_index>
5.5.4.1.2.1 MODULATOR LEVEL COMMANDS

5.5.4.1.2.1.1 M ODULATION ORDER
If required, you may select a modulation order for this modulator other than the default modulation order.
To set the modulation scheme of a specific modulator:
Syntax:
modulation {default|16-QAM|32-QAM|64-QAM|128-QAM|256-QAM}
5.5.4.1.2.1.2 S YMBOL RATE

If necessary, you may set a local value for the symbol rate.
To set the symbol rate for a single carrier in sym/s:
Syntax:
symbolrate {default|<symbol_rate>}
Caution! When more than one QAM RF output is enabled, the entered value must be less than the [Channel
bandwidth / (1 + roll-off_factor)], otherwise the modulators will disturb each other.
To learn more about symbol rate and how to configure the default value, refer to
chapter 0 above
5.5.4.1.2.1.3 E NABLING / DISABLING THE MODULATOR

To enable/disable a modulator:
Syntax:
[no] shutdown
219
5.5.5 DVB-T (COFDM) OUTPUT
FIGURE 28: LCM-B DUAL/QUADRUPLE COFDM MODULATOR
Luminato COFDM modulators are intended to be used in DVB-T over coax applications. They feature four modulators in
adjacent channels, sharing the same upconverter. When the base frequency of the first modulator is set, the frequencies
of the other modulators follow the first one in incremental steps defined by the channel bandwidth. Each modulator may
be enabled or disabled individually.
The amount of modulators depends on used modulation mode:
• 2K mode supports up to 4 modulators

• 8K mode supports up to 2 modulators
Typically, DVB-T receivers support both modes, therefore the 2K mode can be used to maximize the amount of available
modulators in module. For compatibility purpose 8K mode is available, but with a reduced amount of modulators.
To maximize the available bitrate, protective features of DVB-T modulation can be set to minimum in coaxial access
network. This is not a problem since DVB-T modulation offers more robust transmission over coax than comparable QAM
modulation.
The maximum bitrate capacity is achieved with following settings:
• Guard interval: 1/32

• Modulation: 64-QAM
• FEC code rate: 7/8
220
These settings will result in a maximum multiplexing rate of 31,688 Mb/s.
purposes.
5.5.5.1 DVB-T (COFDM) OUTPUT INTERFACE CONFIGURATION

The configuration of COFDM modules takes place at two levels: module wide global level and modulator level.
5.5.5.1.1 COFDM T RANSMISSION MODE

OFDM (Orthogonal Frequency-Division Multiplexing) is digital multicarrier modulation scheme, where data is carried by a
1
large amount of closely spaced carriers. In accordance with the DVB-T standard , there are two modes available: 2k and
8k. The 2k mode has 1 705 and the 8k mode 6 817 carriers per OFDM symbol. The respective approximate carrier spacings
are 1 116 Hz and 4 464 Hz.
Caution! It is strongly advised to select the Transmission mode prior any other RF or IP configuration, since it will
cause the module to reboot in order to load the appropriate firmware
To set the transmission mode:
Syntax:
configure interface <slot_number> cofdm-transmission-mode {2k|8k}
NOTE! The selected transmission mode affects the amount of modulators available: 4 modulators in 2k –mode and 2
modulators in 8k –mode!
5.5.5.1.2 E NTERING CONNECTOR LEVEL CONFIGURATION MODE

These settings work as global settings for all four modulators of the COFDM module. Guard interval and FEC may also be
set at modulator level thus bypassing the global settings.
To enter connector level configuration mode:
Syntax:
configure interface cofdm output <slot_number>/1
5.5.5.1.2.1 CONNECTOR LEVEL COMMANDS

5.5.5.1.2.1.1 B ASE FREQUENCY
The base frequency is the lowest QAM modulator’s center frequency: the three other modulators base their own center
frequency on this setting and the selected channel bandwidth. From this follows that the allowed base frequency range
depends on the channel bandwidth:
1
ETSI EN 300 744
221
To set the first carrier’s frequency in Hz:
Syntax:
frequency <frequency>
5.5.5.1.2.1.2 C HANNEL BANDWIDTH

1
Channel bandwidth sets also the channel spacing; the available bandwidths are standard bound: 6 MHz, 7 MHz and 8
2
MHz. The preferred bandwidth should be 8 MHz .
To set the channel bandwidth in Hz (channel raster):
Syntax:
offset <bandwidth>
NOTE! It is highly recommended to use the local standard compliant bandwidths to avoid any compatibility issues.
5.5.5.1.2.1.3 C HANNEL OUTPUT LEVEL

The Power level defines the channel output level from the RF output interface. The available power level range depends
on amount of channels in use and the relative position of the modulators in use, see Table 4 below.
Enabled channels & relative positions Power level range dBµV

1___ | _2__ | __3_ | ___4 110 – 120
12__ | _23_ | __34 106 – 116
123_ | _234 | 1_3_ | _2_4 104 – 114
1234 | 12_4 | 1_34 | 1__4 102 – 112
TABLE 4: CHANNEL OUTPUT POWER LEVEL RANGES
To set power level of one carrier in dBuV:
Syntax:
power level <power>
1
ETSI EN 300 744
2
ETSI TR 101 190
222
5.5.5.1.2.1.4 D EFAULT GUARD INTERVAL
interferences may be due to propagation delays, echoes and/or reflections. ISI protection is achieved by inserting an
interval in front of each symbol. The longer is the guard interval; the better is the protection against echoes. The trade-off
of longer guard intervals is that they reduce channel efficiency.
The guard interval is defined as the ratio of the guard interval duration to the duration of the useful part of the symbol
duration.
To set the default guard interval:
Syntax:
guard-interval {1/4|1/8|1/16|1/32}
Hint: The highest bitrate bandwidth is achieved using guard interval 1/32. Other alternatives may be used, if high
reflection in your coaxial network is suspected. Ideally, the guard interval should be slightly longer than the delay spread
of the channel.
5.5.5.1.2.1.5 D EFAULT MODULATION ORDER

Select the default QAM order from the target. The selected modulation order is common to all the four modulators. Each
modulator may be individually configured to bypass the default modulation setting.
To learn more about modulator level settings, see chapter 0 above.
modulation {QPSK|16-QAM|64-QAM}
Hint: 64-QAM is the default and recommended setting.
5.5.5.1.2.1.6 D EFAULT INNER CODING RATE

In DVB-T transmission, FEC functionality is implemented through the use punctured convolutional coding. The code rate is
expressed as the ratio of useful bits per the total bits output by the inner convolutional coder, i.e. ratio of the input data
rate to output data rate.
To specify the default inner coding rate
Syntax:
fec rate {1/2|2/3|3/4|5/6|7/8}
Hint: The highest bitrate bandwidth in coax delivery is achieved using 7/8. However, this setting might not work
properly with all set top boxes. Changing to 5/6 may solve issues with certain set top boxes.
223
5.5.5.1.2.1.7 O UTPUT SPECTRUM INVERSION
If necessary, you may invert the spectrum of the output signal (the I and Q components of the QAM signal are
interchanged). To do so, change the output spectrum mode from normal (default) to inverted.
To change the output spectrum:
Syntax:
output spectrum {normal|inverted}
NOTE! This setting affects all modulators of the target QAM-module and cannot be bypassed at modulator level.
5.5.5.1.2.1.8 E NABLING RF OUTPUT

To enable/disable carrier transmission:
[no] shutdown
NOTE! Disabling COFDM -module’s RF-output does not affect multiplex IP streaming.
To learn more about output multiplex IP mirroring, see chapter 0.
5.5.5.1.3 E NTERING MODULATOR LEVEL CONFIGURATION MODE

Syntax:
configure interface cofdm output <slot_number>/1.<modulator_index>
5.5.5.1.3.1 MODULATOR LEVEL COMMANDS

5.5.5.1.3.1.1 E NABLING / DISABLING THE MODULATOR
To enable/disable a modulator:
Syntax:
[no] shutdown
5.5.5.1.3.1.2 M ODULATION ORDER

If required, you may select a modulation order for this modulator other than the default modulation order.
To set the modulation scheme of a specific modulator:
Syntax:
modulation {default|QPSK|16-QAM|64-QAM}
224
5.5.5.1.3.1.3 I NNER CODING RATE
If required, you may select for this modulator an inner coding rate other than the default inner coding rate.
To specify inner coding rate:
Syntax:
fec rate {default|1/2|2/3|3/4|5/6|7/8}
Hint: The highest bitrate bandwidth in coax delivery is achieved using 7/8. However, this setting might not work
properly with all set top boxes. Changing to 5/6 may solve issues with certain set top boxes.
5.5.5.1.3.1.4 G UARD INTERVAL

If required, you may select for this modulator a guard interval other than the default guard interval.
To set the guard interval:
Syntax:
guard-interval {default|1/4|1/8|1/16|1/32}
Hint: The highest bitrate bandwidth is achieved using guard interval 1/32. Other alternatives may be used, if high
reflection in your coaxial network is suspected. Ideally, the guard interval should be slightly longer than the delay spread
of the channel.
5.5.6 ISDB-TB OUTPUT: LCM-I
LCM-I is a quadruple ISDB-Tb modulator. ISDB-Tb (also known as ISDB-T International or SBTVD) is a digital television
broadcasting standard based on the Japanese ISDB-T standard. It is intended to be used in ISDB-T over coax applications. It
features four modulators in adjacent channels, sharing the same upconverter.
5.5.6.1 C ONFIGURING
The available commands for configuring the LCM-I are in most part identical to those of dedicated DVB-T output modules
such as the LCM-B. There are however two differences:
• The transmission mode is fixed to mode 1, i.e. FFT size 2k, and cannot be changed
• The modulation order is fixed to 64-QAM and cannot be changed
225
The commands are described in chapter “DVB-T (COFDM) output”
5.5.6.1.1 LCM-I SPECIFICITY

LCM-I has a specificity compared to other Luminato COFDM multiplexers:
• Automatic SID allocation: the PID/SID allocation mode is by default set to SID mode and the SID values are
allocated using a different logic. The SID allocation range start value is rounded up to a value which is a multiple
of 32 and the allocated SID values are incremented in 33 step size.
5.6 IP OUTPUT INTERFACES

For IP streaming, you have to create an IP output interface. This IP output interface is sometimes referred to as an IP
streamer.
IP output interfaces are always created in input modules (DVB-S2, DVB-T2, DVB-C, ISDB-T and FEC decoder). You may
create up to 120 IP streamers per input module.
NOTE! Since IP output creation is intended for MPEG streaming, some of the IP streamer settings are related to
service configuration and will be further discussed later in chapter “Service configuration”.
5.6.1 STREAM ROUTING STRATEGIES

User can choose between different strategies for stream routings.
5.6.1.1 SPTS IP STREAMING

SPTS (single program transport stream) IP streaming is typically used in IPTV configurations, where it is essential to have
only one service per multicast IP stream. This method can also be used in cable TV systems to maintain flexibility to pick
up and organize multiplexing freely. This also allows creation of localized channel line ups at remote headends.
NOTE! To assign multiple IP output streams per input connector, demultiplexing license is required.
Refer to chapter 0 above for more information on licenses.
5.6.1.2 MPTS IP STEAMING

MPTS (multiple program transport stream) IP streaming is optimum for configurations, where multiple services are chosen
from incoming transport stream and passed through to multiplexing side, i.e. transmodulation applications. This method
minimizes needed stream routings between receivers and multiplexers. The second purpose for MPTS IP streaming is to
maintain received statistical multiplexing. Demultiplexing might not be needed in this scenario, because all services are
streamed within one IP output.
Luminato supports both SPTS and MPTS IP streaming freely. Also stream copies can be created (demultiplexing licences
must be active).
226
5.6.1.3 U NICAST VS MULTICAST
Your network environment and the type of video delivery model (live video or VOD) you are using will determine which
broadcast type you should use.
• Multicast:
o copies of a single stream are delivered to multiple recipients
o Class D IP Address range:
 224.0.0.0 – 239.255.255.255
o Typically used to broadcast TV content to several users simultaneously such as with live TV
broadcasts
o Advantages:
 Reduces dramatically server and network load
 Good when you are limited on server and network bandwidth and have a
relatively large client base
o Disadvantages:
 Requires multicast support in your network devices
 Complex network configuration
• Unicast:
o One-to-one content streaming: IP packets are delivered to a single recipient
o Typically used to deliver personalized content over an IP network such as a specific movie
to a given user (IPTV VOD)
o Advantages:
 Easy to configure; doesn’t necessitate complex network configuring
 Doesn’t require multicast support in your networking devices
 Good solution if encoding with multiple bitrates (multi-bitrate streaming)
 Client-Server point-to-point connection allows session protocols such as RTP,
which in turn will allow bi-directional communication, necessary for example in
VOD applications
o Disadvantages:
 Consumes a lot of bandwidth since the same content must be streamed for each
users separately
 Requires multicasting support in all your network devices
 Complex network configuration
5.6.1.4 I NTERNAL VS EXTERNAL STREAMING

When creating a new IP streamer, you must define its destination payload port. When choosing a GE port, the IP stream is
forwarded outside the chassis, whereas when the payload port is defined as internal the IP stream won’t be forwarded
outside the chassis by the GE ports.
Internal streaming does not consume GE bandwidth; use it to preserve GE bandwidth when configuring stream
redundancy (stream backup).
To learn how to protect your streams with stream redundancy, see chapter 0
227
5.6.2 CREATING AN IP STREAMER AND/OR ENTERING IP STREAMER CONFIGURATION MODE
To create an IP input in an output module and/or to enter IP input interface configuration mode:
Syntax:
configure interface ip output <slot_number>/1.<stream_index>
Arguments:

5.6.2.1 D ESTINATION IP ADDRESS & UDP PORT

Specify the destination IP address, unicast or multicast. It is recommended to use a multicast address ranging from
239.1.1.1 to 239.255.255.255 and a unique address for each streamer
To specify the destination IP address and destination UDP port of the incoming stream:
udp <ip_address>:<port>

values
ip_address Multicast stream reception. The specified address must be within the class D address
range: 224.0.0.0 – 239.255.255.255.
UDP_port Specifies the UDP source port for the transmitted streams by this module. {0…65535}
5.6.2.2 C HANGING THE DESTINATION IP ADDRESS

To change the destination IP address of the IP stream:
Syntax:
udp <ip_address>
5.6.2.3 C HANGING THE DESTINATION UDP PORT

Specify the UDP Port of the outgoing stream. The same port may be reused for each streamer as long as they have
different IP addresses.
To change the destination UDP port of the IP stream:
Syntax:
udp <port>
228
5.6.2.4 TTL
TTL is an 8-bit field in the IP header, determining how long the IP packet can exist in the network before it is discarded.
The TTL value is reduced at each router passed: once this value reaches zero the packet is considered lost to prevent
undeliverable packets from circulating eternally and causing network congestion. Since TTL, is an 8-bit field its maximum
decimal value is 255. Typically the TTL is 5.
To specify the TTL of the outgoing packets:
Syntax:
ttl {1…255}
5.6.2.5 TS PACKET ENCAPSULATION COUNT

To specify how many TS packets are encapsulated in one IP packet:
ts-packets {1…7}
5.6.2.6 IP TRANSMISSION PROTOCOL

Select the desired transmission protocol for the IP mirror stream. There are two protocols:
• UDP is a, lightweight, connectionless protocol, with no guarantee of delivery, ordering or duplicate

protection; its main advantages are:
o lack of retransmission delays → suitable for time-sensitive purposes
o statelessness → suitable for large numbers of clients when streaming media
o works well in unidirectional communication → suitable for broadcasting
• RTP (Real-time Transport Protocol) is a protocol built on top UDP through Application Level Framing
(ALF) to provide support for real-time applications; its main advantages are:
o Time stamping to synchronize and correlate multiple streams
o Sequencing to detect lost and reordered segments
o Payload type identification
o RTP is generally used to improve interoperability between Luminato and some third party
equipment like set-top-boxes, head-ends, analysers and in some video streaming
applications. RTP usually provides better error detection/correction possibilities compared
to plain UDP transmission.
rd
NOTE! In order to be useful, RTP support is also needed in the receiving 3 party equipment.
To define the transmission protocol:
Syntax:
packet-format {default|udp|rtp}
NOTE! This command is not supported in LAS-A, LAS-B and LQM-B modules due to limited fpga resources.
229
5.6.2.7 B IT RATE MODE
1
Select the Bitrate mode
• VBR: Variable Bit Rate is the default mode

• CBR: Constant Bit Rate. For third party equipment that require constant bitrate stream for correct
operation. CBR is achieved by adding null-packets to the stream.
To specify the output bitrate mode
bitrate {vbr|cbr <bitrate>}
Hint: In CBR mode, the output bitrate should be set high enough to allow some overhead for peak bitrates, hence
avoiding stream corruption. The peak versus average bitrate ratio can be remarkably high!
NOTE! In order to keep the outgoing IP stream strictly below the specified CBR limit, there is a special global setting
for the GE ports: CBR strict mode (disabled by default).
To learn more about CBR strict mode, see chapter 0 above.
5.6.2.8 P AYLOAD INTERFACE

• External:
o GE1&GE2 ports
• Internal:
GE1&GE2 ports)
Syntax:
payload-port {all|ge1|ge2|internal|vlan <VID>}
Keyword:

1
Bitrate mode selection is not available with LAS-A
230
5.6.2.9 PCR JITTER
5.6.2.9.1 W HAT IS THE PCR AND PCR JITTER ?

In order for a digital TV receiver to reconstruct correctly a TV program from a MPEG-2 TS, it needs to keep its internal 27
MHz clock synchronized with the MPEG-2 TS source’s 27 MHz program clock. To achieve this synchronization, a Program
Clock Reference (PCR) is generated at the source and inserted into packets within the MPEG-2 TS at regular intervals.
Luminato insert them at 40 ms intervals, which is the minimum recommended PCR insertion interval. The PCR value is
essentially a timestamp sampled from the source’s PCR counter which is driven by the 27 MHz clock.
The receiver compares the received PCR value with its own 27 MHz clock counter value and the difference is used to
control the local 27 MHz clock through the use of a Phase Locked Loop (PLL).
PCR jitter is the variation over time of the delay in PCR –packet reception and may cause the PLL at the receiver to fall out
of lock. PCR jitter is caused by errors at PCR generation and regeneration and/or by timing shifts at transmission.
5.6.2.9.2 C OUNTERING PCR JITTER DUE TO E THERNET FRAMING

1
By default, Luminato queues up seven MPEG-2 TS packets into a packet buffer before UDP/IP/Ethernet framing, meaning
a frame is not sent before the packet buffer is full. This may cause some PCR jitter, when the TS has very large bit rate
variations or when its bit rate is very low. To counter this, Luminato features a special packet queuing mode where the
Ethernet frames are immediately sent after a PCR packet is added into the MPEG-2 TS packet buffer. This will result in an
IP stream with variable Ethernet frame lengths (from 1 to 7 TS packets per Ethernet frame).
To learn how to configure how many TS packets are encapsulated in one IP packet, see chapter “TS packet encapsulation
count”
NOTE! The low PCR jitter mode is likely to cause some overhead in the output stream.
To enable/disable the low PCR jitter mode:
Syntax:
[no] low-packet-jitter-mode
Example - enable the low PCR jitter mode for IP output interface 1/1.1:
DocumentationTest(iface-ip-output-1/1.1)# low-packet-jitter-mode
5.6.3 REMOVING AN IP STEAMER
To remove an IP output interface from a submodule:
Syntax:
configure no interface ip output <slot>/1.<stream_index>
1
Correspond to the maximum amount of TS packets that can fit into an Ethernet frame.
231
5.6.4 IP-TO-IP MULTIPLEXER
FIGURE 29: LIM-A QUADRUPLE IP-TO-IP MULTIPLEXER
The LIM-A is an IP-to-IP multiplexer and features four IP output interface. Each of the multiplexed IP output streams may
be duplicated as another IP output stream.
5.6.4.1 E NTER IP OUTPUT INTERFACE LEVEL CONFIGURATION MODE

To enter IP output interface level configuration mode:
Syntax:
configure interface ip output <slot_number>/1.{1…4}
To configure the IP streaming parameters, follow the instructions in chapter

“Output multiplex’ IP mirroring”
5.6.4.2 D UPLICATING IP OUTPUT STREAMS

Each output IP stream may be duplicated as IP mirror streams, once.
To duplicate LIM-A’s IP output streams, see chapters from “Duplicating primary

IP mirror stream” to “Removing a duplicated IP mirror stream”.
5.6.5 PRO:IDIOM™ IP-TO-IP SCRAMBLER

The LPI module is an IP-to-IP multiplexer for service scrambling in hospitality environments with Pro:Idiom™ system. The
module is able to scramble one output MPTS with up to 8 SPTS input services.
This chapter explains how to:
• configure the multiplexing and streaming settings of the LPI module

• enable or disable Pro:Idiom™ scrambling
• update the system keys in the LPI
• renew the system keys in the Pro:Idiom™ receivers (STBs or IRDs)
232
5.6.5.1 S YSTEM REQUIREMENTS
• A Pro:Idiom™ system license (obtained from Zenith Electronics LLC)
• A special Luminato software upgrade granting Pro:Idiom™ support (obtained on request from your local Teleste
Corporation’s sales representative)
• One or more LPI module for IP-to-IP multiplexing and Pro:Idiom™ scrambling
5.6.5.2 A BOUT THE P RO :I DIOM ™ CONTENT PROTECTION SYSTEM

The Pro:Idiom™ system provides end-to-end 128 bit AES encryption and is intended for content protection in closed
systems such as in hospitality environments. The keys are managed and passed in-band. The fixed keys present in the
receivers (STBs or IRDs) may be updated via a key renewal command.
The Pro:Idiom™ system licenses are administred by Zenith Electronics LLC.
5.6.5.3 E NTER IP OUTPUT INTERFACE LEVEL CONFIGURATION MODE

To enter IP output interface level configuration mode:
Syntax:
configure interface ip output <slot_number>/1.{1…4}
To configure the IP streaming parameters, follow the instructions in chapter

“Output multiplex’ IP mirroring”
5.6.5.3.1 D UPLICATING IP OUTPUT STREAMS

The output IP stream may be duplicated as a IP mirror stream.
To duplicate LPI-A’s IP output stream, see chapters from “Duplicating primary IP

mirror stream” to “Removing a duplicated IP mirror stream”.
5.6.5.4 E NABLING OR DISABLING P RO :I DIOM ™ SCRAMBLING

In contrast to service scrambling configuration procedures associated with other conditional access systems, content
protection is enabled or disabled at output multiplex level and not at service level.
To enable or disable Pro:Idiom™ content protection:
Syntax:
configure interface ip output <slot_number>/<connector_number>.<TS_index> [no] scramble

proidiom
When Pro:Idiom™ scrambling is enabled, all services present in LPI’s output multiplex are scrambled.
NOTE! Up to eight services may be scrambled per LPI, any additional service will be multiplexed unscrambled. An
error status flag will be raised when the limit is exceeded and error message will be generated into the log.
233
5.6.5.5 U PDATING THE SYSTEM KEYS
Updating the Pro:Idiom™ system keys (“Fixed Keys”) present in the LPI module(s) is part of the key renewal procedure.
There are two possible reasons why key rewal might be necessary:
1. You might have chosen to use Fixed keys unique to your system
2. Your Pro:Idiom™ system security has been breached
Prior to updating your Pro:Idiom™ system keys, you must copy the file containing the new system keys to the target
Luminato chassis by using the copy -command.
NOTE! The key file must be named key.hex. If no file named key.hex is found, you will be unable to update the system
keys.
To learn how to upload a file to the Luminato chassis, see chapter “4.18.2.1
Uploading”
Once the key file has been copied, you may start updating the system keys residing in LPI’s memory.
To update the system keys:
Syntax:
configure interface {1…6} scramble proidiom key-update
5.6.5.6 S YSTEM KEY RENEWAL

The fixed keys present in the receivers (STBs or IRDs) may be updated via the key renewal procedure. For example, after
updating the system keys in the LPI(s), the system keys in the receivers must be update as well to allow stream decryption.
To renew the system keys in the Pro:Idiom™ receivers:
Syntax:
configure interface {1…6} scramble proidiom key-renewal
5.6.5.7 V IEWING P RO :I DIOM ™ KEY STATE

To view the state of the Pro:Idiom™ keys:
Syntax:
show interface {1…6} scramble proidiom
Example:
DEMO-3# show interface 6 scramble proidiom

interface <6> ProIdiom key state: Key renewed
DEMO-3#
234
5.6.6 OUTPUT MULTIPLEX’ IP MIRRORING
1.
purposes. The procedure described below applies to all output modules
5.6.6.1 E NTER MODULATOR LEVEL CONFIGURATION MODE

Syntax:
configure interface cofdm output <slot_number>/1.<modulator_index>
5.6.6.2 P RIMARY IP MIRROR STREAM
5.6.6.2.1 C REATING MULTIPLEX PRIMARY IP MIRROR STREAM

To create a primary IP mirror stream:
Syntax:
udp <ip_address>:<port>
5.6.6.2.2 C HANGING PRIMARY IP MIRROR ADDRESS

To change the destination IP address of the primary multiplex IP mirror stream:
Syntax:
udp <ip_address>
5.6.6.2.3 C HANGING PRIMARY IP MIRROR UDP PORT

To change the destination UDP port of the primary multiplex IP mirror stream:
Syntax:
udp <port>
5.6.6.2.4 P RIMARY STREAM TTL

TTL is an 8-bit field in the IP header, determining how long the IP packet can exist in the network before it is discarded.
The TTL value is reduced at each router passed: once this value reaches zero the packet is considered lost to prevent
undeliverable packets from circulating eternally and causing network congestion. Since TTL, is an 8-bit field its maximum
decimal value is 255. Typically the TTL is 5.
1
Due to technical restrictions, the discontinued ASI output module LAS-B, does not support IP streaming.
235
Syntax:
ttl {1…255}
5.6.6.2.5 P RIMARY STREAM TS PACKET COUNT

To specify how many TS packets are encapsulated in one IP packet:
ts-packets {1…7}
5.6.6.2.6 P RIMARY STREAM IP TRANSMISSION PROTOCOL

Select the desired transmission protocol for the IP mirror stream. There are two protocols:
• UDP is a, lightweight, connectionless protocol, with no guarantee of delivery, ordering or duplicate

protection; its main advantages are:
o lack of retransmission delays → suitable for time-sensitive purposes
o statelessness → suitable for large numbers of clients when streaming media
o works well in unidirectional communication → suitable for broadcasting
• RTP (Real-time Transport Protocol) is a protocol built on top UDP through Application Level Framing
(ALF) to provide support for real-time applications; its main advantages are:
o Time stamping to synchronize and correlate multiple streams
o Sequencing to detect lost and reordered segments
o Payload type identification
o RTP is generally used to improve interoperability between Luminato and some third party
equipment like set-top-boxes, head-ends, analysers and in some video streaming
applications. RTP usually provides better error detection/correction possibilities compared
to plain UDP transmission.
rd
NOTE! In order to be useful, RTP support is also needed in the receiving 3 party equipment.
Syntax:
packet-format {default|udp|rtp}
236
5.6.6.2.7 P RIMARY STREAM PAYLOAD PORT
• External:
o GE1&GE2 ports
• Internal:
GE1&GE2 ports)
Syntax:
Keyword:

5.6.6.2.8 P RIMARY STREAM BITRATE MODE

1
All DVB TS broadcasts have a Constant Bit-Rate (CBR). In order to achieve a CBR, MPEG null packets are inserted into TSs.
These null packets are assigned the fixed PID value 8191D = 0x1FFF. To save bandwidth in IP distribution, Luminato
features a Null PID filter. It is enabled by default.
NOTE! When the Null PID filter is enabled, the resulting IP stream will have a VBR (Variable Bit-Rate) and a CBR if
disabled. Some other device may require constant bitrate to support MPTS reception from IP network. In this case, Null
PID filter should be disabled. It is also worth noticing that null packets are removed only from the IP stream, not the
physical output!
To enable/disable the Null PID filter of an IP stream:
Syntax:
[no] null-pid-filter
1
ISO/IEC 13818-1
237
5.6.6.2.9 R EMOVING A PRIMARY MULTIPLEX IP MIRROR STREAM
To remove a primary multiplex IP mirror steam:
Syntax:
no udp
5.6.6.3 S ECONDARY IP MIRROR STREAM
5.6.6.3.1 D UPLICATING PRIMARY IP MIRROR STREAM

A secondary IP mirror stream is obtained by duplicating the primary mirror stream.
To duplicate the primary IP mirror stream:
Syntax:
duplicate-ip udp <ip_address>:<port>
5.6.6.3.2 C HANGING DUPLICATE IP MIRROR ADDRESS

To change the destination IP address of the duplicated multiplex IP mirror stream:
Syntax:
duplicate-ip udp <ip_address>
5.6.6.3.3 C HANGING DUPLICATE IP MIRROR UDP PORT

To change the destination UDP port of the duplicated multiplex IP mirror stream:
Syntax:
duplicate-ip udp <port>
5.6.6.3.4 D UPLICATE STREAM TTL

Syntax:
duplicate-ip ttl {1…255}
5.6.6.3.5 D UPLICATE STREAM IP TRANSMISSION PROTOCOL

Syntax:
duplicate-ip packet-format {default|udp|rtp}
238
5.6.6.3.6 D UPLICATE STREAM PAYLOAD PORT
Syntax:
Keyword:

5.6.6.3.7 R EMOVING A DUPLICATED IP MIRROR STREAM

To remove the duplicate of a primary multiplex IP mirror stream:
Syntax:
no duplicate-ip udp
5.7 PRO-MPEG FEC ENCODER
FIGURE 30: LPF-A PRO-MPEG FEC MODULE.
1
The LPF-A is a dedicated Pro-MPEG FEC (forward error correction) processing module . Depending on the purchased
license, the module operates either as a FEC encoder or as a FEC decoder, but not both at the same time. The amount FEC
channel is also license dependent.
For more information on license management, refer to chapter 0 above.
Pro-MPEG CoP3 (SMPTE 2022) is an application layer forward error correction (AL FEC) protocol used in video streaming
over IP networks. To protect video streams against packet loss in IP networks, the Pro-MPEG FEC encoder sends
redundant FEC streams along with normal media streams. It makes it possible to recover lost, erroneous, delayed and
wrong order packets.
Pro-MPEG FEC is based on calculating exclusive-OR (=XOR) bitwise operations over multiple RTP packets. The stream to be
protected is called media stream which contains media packets. Media packets are arranged in a matrix with D packets in
1
compliant with Pro-MPEG Code of Practice #3 release 2 and SMPTE 2022-1-2007
239
a column and L packets in a row. XORs are calculated over each column and row of the matrix. See an example in Figure 31
below.
Row Length (L) = 4
Media Media Media Media Row

Packet XOR Packet XOR Packet XOR Packet FEC
1 2 3 4 1
XOR
XOR
XOR
XOR
Column Depth (D) = 4

5 6 7 8 2
XOR
XOR
XOR
XOR
9 10 11 12 3
XOR
XOR
XOR
XOR

13 14 15 16 4
Col Col Col Col

FEC FEC FEC FEC
1 2 3 4
FIGURE 31 FEC MATRIX USING 2D MODE WITH D=4 AND L=4
The resulting XORed media packets are called FEC packets, which are transmitted in separate FEC streams using UDP ports
relative to the media stream’s port N. Column FEC packets are transmitted in port N+2 and row FEC packets in port N+4.
Pro-MPEG FEC includes two modes: 1D and 2D. In 1D mode, only column FEC stream is transmitted. In 2D mode both
column and row FEC streams are transmitted. 2D mode provides stronger protection but bitrate overhead is higher.
5.7.1 OPERATION MODE

Luminato’s Pro-MPEG FEC processing module LPF-A is, depending on the active license, able to function either as an
encoder or a decoder. If you own licenses for both FEC encoding and decoding, you are able to select the Operation mode.
See chapter “License management” for more information about license

management.
Caution! It is strongly advised to select the Operation mode prior any other configuration of this module, since this
causes the module to reboot to load the appropriate firmware.
240
To set the operating mode of the FEC module to encoder:
Syntax:
configure interface <slot_number> fec-operating-mode encoder
5.7.2 PRO-MPEG FEC ENCODER CONFIGURATION

The configuration of Pro-MPEG FEC encoder modules takes place at IP stream level. You may configure your own FEC
encoder template settings, to speed up the configuration process.
5.7.2.1 P RELIMINARY CONFIGURATION PROCEDURES

Prior configuring the Pro-MPEG FEC streams, please first configure the stream(s) to be FEC encoded:
• Configure the MPEG TS receiver.
To learn how to configure receiving modules, see chapters from 0 through 0

above.
• Create an IP streamer for the above mentioned receiver.
To learn how to add an IP output interface, see chapter 0 above.
• Link the service(s) to the streamer
OR, if the stream is an incoming external IP stream:
• Configure the GE IP input to receive the target IP stream.
To learn how to add an IP input interface, see chapter 0 above.
5.7.2.2 G ENERAL CONFIGURATION GUIDELINES

The following criteria should serve you as general guidelines when considering application layer FEC encoding:
• Overhead vs. delay: The size of the FEC matrix affects directly the overhead/delay –relationship. A
smaller matrix results into larger overhead but shorter delay. Similarly, a larger matrix results into
smaller overhead but longer delay.
• The packet dropping pattern: Column FEC stream corrects consecutive loss of packets, while row
FEC stream corrects non-consecutive loss of packets. This should be reflected in the FEC matrix
shape:
o if you experience mostly short bursts of packet drops, then the matrix should have more
rows than columns: L < D
o if you experience mostly long bursts of packet drops, then the matrix should have more
columns than rows: L > D
o if you experience mostly random length bursts of packet drops, then the matrix should be
square: L = D
241
• FEC column alignment induced latency:
o Block aligned arrangement uses a basic rectangle shape where all column FEC packets are
calculated almost at the same time in the end of matrix. To avoid bursts in transmission the
column FEC packets are delayed regularly distributed over the next matrix. This
arrangement ensures the most linear use of the bandwidth, but also means that the
1
latency due to FEC is twice (L x D). Due to the standard requirements , if L > D in your
matrix settings, Block aligned arrangement is the only valid option.
TABLE 5: BLOCK ALIGNED FEC ARRANGEMENT WITH L=4 AND D=5.
o The Non-block aligned arrangement uses a parallelogram shape where column FEC packets
can be calculated and transmitted almost immediately after the last media packet it
belongs to. This permits to create a highly time-linear packet flow on the FEC stream and
242
can reduce latency and memory requirements in FEC decoder. Due to the standard
1
requirements , this arrangement is available only when D > L.
TABLE 6: NON-BLOCK ALIGNED FEC ARRANGEMENT WITH L=4 AND D=5.
Hint: Check the Pro-MPEG FEC overhead and estimated latency for the currently selected encoding parameters from
the stream quick-monitoring view.
1
SMPTE 2022-1-2007
243
5.7.2.3 D EFAULT P RO -MPEG FEC ENCODING MODE
To configure the module default FEC encoding settings:
Syntax:
configure interface <slot_number> fec-encoder mode {off|1D|2D} D {4…20} L {1…20} {block-

aligned|non-block-aligned}
5.7.2.4 L INKING A MEDIA STREAM TO AN IP OUTPUT

To configure the destination IP address of the incoming media stream:
Syntax:
configure interface ip output <slot_number>/1.<stream_index> input udp <ip_address>:<port>
5.7.2.5 S TREAM LEVEL P RO -MPEG FEC ENCODING MODE

To configure the stream level FEC encoding settings:
Syntax:
configure interface ip output <slot>/1.<stream_index> fec-encoder mode {default|off|1D|2D}

D {4…20} L {1…20} {block-aligned|non-block-aligned}
5.7.3 EVALUATING PRO-MPEG FEC PERFORMANCE

To evaluate or demonstrate the error-correcting performance of your Pro-MPEG FEC setup, you may use the packet error
generator located in the FEC encoder. This feature is configurable only through the CLI.
When enabling error generation, you must define:
• error burst length (how many consecutive Ethernet frames are corrupted)
• error burst probability expressed in ppm (parts-per-million)
NOTE! The packet error generation configuration is stored in volatile memory, and thus will be lost after module
reboot.
5.7.3.1 E NABLING PACKET ERROR GENERATION

To enable packet error generation:
Syntax:
configure interface {1…6} fec-encoder error-generator frames {1…255} probability

{1…1000000}
244
5.7.3.2 D ISABLING PACKET ERROR GENERATION
To disable packet error generation:
Syntax:
configure interface {1…6} fec-encoder no error-generator
5.7.3.3 R EVIEWING THE PACKET ERROR GENERATION SETTINGS

To review the packet error generation settings:
Syntax:
show interfaces {1…6} fec-encoder error-generator
5.8 PRO-MPEG FEC DECODER
FIGURE 32: LPF-A PRO-MPEG FEC MODULE.
1
LPF-A is dedicated Pro-MPEG FEC processing module . Depending on the purchased license, the module operates either as
a FEC encoder or as a FEC decoder, but not both at the same time. The amount FEC channel is also license dependent.
For more information on license management, refer to chapter 0 above.
FEC decoder corrects missing media packet in received stream by XORing received media packets and FEC packets. Each
FEC packet can be used only once in fixing process. Thus, the maximum number of correctable errors in single matrix is
L+D (row packets + column packets). However, there are many uncorrectable error patterns with less than L+D errors. All
error patterns with less than 4 missing packets can be fixed.
An example of fixing process is shown in Figure 33.
1
compliant with Pro-MPEG Code of Practice #3 release 2 and SMPTE 2022-1-2007
245
Row Length (L) = 4
5
Media Media Row
Packet Packet FEC
2 3 1
3
Column Depth (D) = 4
Media Media Row

Packet Packet FEC
7 8 2
7
Media Media Row
Packet Packet FEC
9 4 10 3
1
Media 2 Media Media Row
Packet Packet 6 Packet FEC
14 15 16 4
Col Col Col Col

FEC FEC FEC FEC
1 2 3 4
FIGURE 33 ERROR CORRECTION IN FEC DECODER
FEC decoder uses following procedure to reconstruct lost packets in Figure 33:
1. MP14 xor MP15 xor MP16 xor RowFEC4 = MP13

2. MP2 xor MP10 xor MP14 xor ColFEC2 = MP6
5.8.1 OPERATION MODE

Luminato’s Pro-MPEG FEC processing module LPF-A is, depending on the active license, able to function either as an
encoder or a decoder. If you own licenses for both FEC encoding and decoding, you are able to select the Operation mode.
See chapter 9.2 for more information about license management.
Caution! It is strongly advised to select the Operation mode prior any other configuration of this module, since this
causes the module to reboot to load the appropriate firmware.
246
To change the operating mode of the FEC module to decoder:
Syntax:
configure interface <slot_number> fec-operating-mode decoder
5.8.2 PRO-MPEG FEC PROTECTED STREAM DECODING CONFIGURATION

The decoding parameters for decoding a Pro-MPEG FEC protected stream are automatically discovered. The only
necessary steps are to create an IP input and an IP output, see the chapters above.
5.9 EPG PROCESSING MODULE
FIGURE 34: LPE-A EPG PROCESSING MODULE
The LPE-A is an EPG (Electronic Program Guide) processing module for providing full EPG information (present/following
and schedule for actual and other transport streams).
EIT generation and playout is based on user configurable profiles, allowing you flexible control over the EIT playout rate
and playout schedule, and the definition of the output languages in order of priority, thus enabling optimized bandwidth
usage.
5.9.1 ABOUT EPG

An Electronic Program Guide (EPG) is a service provided by broadcasters and/or other DTV service providers to display
information about ongoing or future events (programs) to the end-user. As defined by the DVB standard EN 300 468, the
EPG data is conveyed to the customers’ IRDs (Integrated Receiver Decoder) by the means of Event Information Tables
(EITs). As all other PSI (Program Specific Information) and SI (Service Information) tables, these tables are multiplexed
within the MPEG-2 TSs.
5.9.2 FRONT PANEL OVERVIEW
247
Non-functional ports 1000Base-T interfaces reserved for
XML-TV traffic
NOTE! None of the front panel interfaces is currently functional.
FIGURE 35: FUNCTIONAL BLOCKS
The input modules demultiplex the EITs and SDTs from input TSs and forward them to the EPG receiver as temporary
internal UDP/IP multicast streams and, if in multichassis configuration, as temporary external UDP/IP multicast streams.
The EIT processing module also accepts external UDP/IP TS and XMLTV as EPG data sources. The received EPG information
is then stored in two distinct databases (input EIT and XMLTV) located in the module’s flash memory (4GB). The
generation of the outgoing EITs is based on user configurable EPG generation profile assignments. These profiles affect the
EIT type, playout rate and schedule. Once generated, the EITs are then forwarded to the UDP/IP streamer which will
forward them as multicast streams to the proper output multiplexes.
5.9.4 SOFTWARE REQUIREMENTS

The EPG processing module’s software resides within the module itself and the update mechanism is coordinated with the
Luminato software update packages; this means that whenever you update the Luminato system software, you also
update the EPG processing module’s software. The software versions of Luminato and the EPG processing module are
248
synchronized such that if the SW version/revision numbers conflict, the EPG processing module’s functionalities will be
disabled.
To ensure that EPG processing module’s SW version do not conflict with that of Luminato, you should update the
Luminato system software when installing the EPG processing module for the first time. The minimum required software
version is 7.2.X.
See the chapter “Software update” to learn more about software upgrading
5.9.5 INSTALLATION PROCEDURE

Take the following steps:
1. Insert the EPG processing module into the chassis

2. Wait until the module has booted up
3. Update to the latest system software version you are entitled to. The minimum required software version is
7.2.X.
5.9.6 CONFIGURATION PROCEDURES

The configuration of EPG processing takes two steps, assuming you have configured all input and output services. The
third step is not mandatory, but highly recommended with larger systems:
1. If the target chassis is a member of a multichassis configuration, define how the chassis payload ports are
interconnected for interchassis EIT payload streaming by creating multichassis connection groups.
2. If you use an external EPG source such as the [Category] Broadcast Manager or a XMLTV source, define the
source parameters.
3. Map the external EPG sources (XMLTV channels or EIT input) to output services
4. Define the IP multicast address range used for EIT streaming. Ensure that this allocated IP address and UDP port
ranges will not overlap with the other IP payload streams.
5. If necessary, configure new EIT output profiles or modify the default EIT output profile
6. Assign EIT output profiles to the target output multiplexes via the NIT editor.
5.9.6.1 EIT PROCESSING IN MULTICHASSIS ENVIRONMENT

If the target chassis is a member of a multichassis configuration, define how the chassis payload ports are interconnected
for interchassis EIT payload routing by creating multichassis payload connection groups.
To learn how to configure multichassis payload connection groups, see chapter

“Defining multichassis payload port interconnections”
5.9.6.2 E NTERING EPG CONFIGURATION MODE

To enter EPG configuration mode, enter module level configuration of the target EPG module:
Syntax:
configure interface <slot_number>
249
Argument:

Example – enter configuration mode for module 1:
DocumentationTest# configure interface 1

5.9.6.3 E XTERNAL EPG SOURCE CONFIGURATION

By default, the output EIT is generated by matching the service input ONID/TSID/SID from the EIT database. However, you
may also provide EPG information from alternate sources.
The EPG processing supports two type of external EPG source:
• MPEG-2 TS: Any MPEG-2 TS containing EIT, it could for example, the [Category] Broadcast
Manager. With this source type the EIT is received from Luminato’s GE port. You must define the IP
multicast address of the broadcasted EPG information stream. The incoming stream must be
UDP/IP and compliant to ISO/IEC 13818-1 and ETSI EN 300 468.
NOTE! Ensure that the EITs and SDTs are transmitted on ETSI EN 300 468 compliant PIDs: 0x0012 for EITs and 0x0011
SDTs.
• XMLTV: In XMLTV, the EPG information is stored in a XML file. With this source type you must
specify the URL(s) of the XMLTV source and how often the XML file is updated. The on-module E1
and E2 ports are used for retrieving the XMLTV files, make sure that at least one of the ports is
connected and has access to the requested URL.
5.9.6.3.1 E XTERNAL PAYLOAD INTERFACE IP SETTINGS

All external XMLTV EPG sources must be connected to the EPG processing module’s 1000Base-T interfaces labelled E1 and
E2. The ports support DHCP and static addressing.
5.9.6.3.1.1 IP ADDRESS
To configure the external EPG source interface IP address:
Syntax:
ip address {dhcp|<ip_address> <netmask> {e1|e2}}
250
Arguments:

values
ip_address Static IPv4 address in dot-decimal notation (immediately followed by a slash ‘/’ character if
in CIDR notation). Specify unique IP addresses for the external payload ports E1 and E2.
netmask IPv4 netmask in classful dot-decimal notation. The factory default netmask is
255.255.255.0.
5.9.6.3.1.2 DEFAULT GATEWAY
To specify the default gateway for the target external payload interface:
Syntax:
ip default gateway <IP_address> {e1|e2}
NOTE! The IP address 0.0.0.0 results in a no gateway configuration.
5.9.6.3.1.3 STATIC DNS NAME SERVER ADDRESS

When the static IP addressing method is being used for external EPG source interfaces and you wish to use user-friendly
domain names instead of numerical IP addresses, you must specify manually the DNS (Domain Name System) name
server’s IP address. You may specify up to two name servers.
NOTE! Static name server configuration is only available when both external source interfaces E1 & E2 use the DHCP
addressing method.
5.9.6.3.1.3.1 A DDING
To specify the static DNS name servers’ IP addresses:
Syntax:
ip name-server <IP_address1> [<IP_address2>]
5.9.6.3.1.3.2 R EMOVING
To remove the static DNS name server entries:
Syntax:
no ip name-server
5.9.6.3.2 A DDING AN EXTERNAL EPG SOURCE AND ENTERING EXTERNAL SOURCE LEVEL CONFIGURATION MODE
To create a new external EPG source entry:
Syntax:
source <source_ID>
251
Arguments:

values
source_ID The external source identifier used as an index. If the source is configured in the Web UI, <string>
the source identifier is a GUID (Globally Unique Identifier) automatically allocated by the
Luminato.
NOTE! This command will enter EPG external source configuration mode.
5.9.6.3.2.1 SOURCE TYPE

The EPG processing supports two types of external EPG source:
• MPEG-2 TS: Any MPEG-2 TS containing EIT, it could for example, the [Category] Broadcast Manager. With this
source type the EIT is received from Luminato’s GE port. You must define the IP multicast address of the
broadcasted EPG information stream. The incoming stream must be UDP/IP and compliant to ISO/IEC 13818-1
and ETSI EN 300 468.
NOTE! Ensure that the EITs and SDTs are transmitted on ETSI EN 300 468 compliant PIDs: 0x0012 for EITs and 0x0011
SDTs.
• XMLTV: In XMLTV, the EPG information is stored in a XML file. With this source type you must specify the URL(s)
of the XMLTV source and how often the XML file is updated. The on-module E1 and E2 ports are used for
retrieving the XMLTV files, make sure that at least one of the ports is connected and has access to the requested
URL.
To define the EPG source type:
Syntax:
type {ts|xmltv}
5.9.6.3.2.2 WEB UI SOURCE NAME

To give the external source a descriptive name (only visible in the Web UI):
Syntax:
description <source_name>
5.9.6.3.2.3 ENABLING AND DISABLING

To enable/disable the external source:
Syntax:
[no] shutdown
252
Keyword:

no no shutdown = enables interface
shutdown = disables interface
5.9.6.3.2.4 MPEG-2 TS EPG SOURCE
When the external EPG source type is defined as MPEG-2 TS, the IP address, UDP port and the destination payload
interface must be specified with the commands below.
5.9.6.3.2.4.1 IP ADDRESS
To specify the multicast IP address and UDP port of the incoming stream:
Syntax:
addr <IP_address>
Argument:

values
IP_address Multicast stream reception. The specified address must be within the class D address
range: 224.0.0.0 – 239.255.255.255.
5.9.6.3.2.4.2 UDP PORT
To specify the UDP port of the incoming stream:
Syntax:
port <UDP_port>
Argument:

UDP_port Specifies the UDP source port for the received streams. {1…65535}
5.9.6.3.2.4.3 P AYLOAD INTERFACE
To specify the destination GE payload port for the incoming stream:
Syntax:
payload-port {ge1|ge2}
5.9.6.3.2.5 XMLTV SOURCE

When the external EPG source type is defined as XMLTV, the fetching interval, fetching time, XMLTV file URL and the
destination payload interface must be specified with the commands below.
253
5.9.6.3.2.5.1 F ETCHING INTERVAL
To specify the time interval at which the EPG processing module will fetch the XMLTV files:
Syntax:
interval <fetch_interval>
Argument:

values
fetch_interval The time interval at which the EPG processing module will fetch the XMLTV files {0…86400}
expressed in seconds.
NOTE! Once the command entered, the EPG processing module will immediately start fetching the XMLTV file,
fetching XMLTV files at the specified interval until the Time of Day at which point the fetching cycle will start again.
5.9.6.3.2.5.2 F ETCHING TIME

Specify, in the time of day (UTC) –input field, the time of day at which the automatic XML file fetching shall always occur in
the 24 hour cycle, in addition to the above set interval. For example, if the Time of day is set to 04:00:00, the Interval is set
to 04:00:00 and the current UTC time when saving the EPG source settings is 14:30:00, then the XMLTV file will be first
fetched at 14:30, then at 18:30, 22:30, 2:30, 4:00, 8:00 and so forth.
To specify the fetching time of day:
Syntax:
timeofday <hh>:<mm>:<ss>
Arguments:

hh hours {00…23}
mm minutes {00…59}
ss seconds {00…59}
5.9.6.3.2.5.3 XMLTV FILE LOCATION
In XMLTV, the EPG information is stored in a XML file. In order to be able to use this file, you must specify the URL(s)
pointing to this file. A single XMLTV source may have several URLs attached to it.
To specify the URL (Universal Resource Locator) of the XMLTV file:
Syntax:
url <URL_identifier> <URL>
254
Arguments:

values
URL_identifier The URL identifier used as an index. <string>
URL The URL of the XMLTV file. HTTP and FTP are supported. Although technically not an <string>
external source, you may also use local XMLTV files copied into the Luminato’s user
memory area. Use the following syntax for the files: file://<file_name>. For example,
file://my_xml_tv.xml
5.9.6.3.2.5.4 M ANUAL XMLTV FILE FETCHING
To fetch immediately the XMLTV files from all configured URLs of a single XMLTV source:
Syntax:
fetch-all-urls
Example fetching all URLs of source 4ef8d836-50a9-4145-96d7-c5744e7d6f3b:
Natolanka(source-4ef8d836-50a9-4145-96d7-c5744e7d6f3b)# fetch-all-urls
Natolanka(source-4ef8d836-50a9-4145-96d7-c5744e7d6f3b)#
5.9.6.3.2.5.5 R EMOVING AN URL FROM A XMLTV SOURCE
To remove an URL from a XMLTV source:
Syntax:
no url <URL_identifier> <URL>
Arguments:

values
URL_identifier The URL identifier used as an index. See chapter “XMLTV file location” <string>
URL The URL of the XMLTV file. HTTP and FTP are supported. Although technically not an <string>
Example – remove URL “file://weekly_vh1-europe.music_tvprofil.net.xml” from source entry ‘MyXMLTV’ URL identifier
‘VH1’:
DocumentationTest(source-MyXMLTV)# no url VH1 file://weekly_vh1-europe.music_tvprofil.net.xml

DocumentationTest(source-MyXMLTV)#
255
5.9.6.3.2.6 SOURCE MONITORING
You can monitor either all sources simultaneously or a single specific source.
5.9.6.3.2.6.1 V IEWING ALL EPG SOURCE STATUS

To view all configured EPG sources along with their status:
Syntax:
show interface <EPG_slot> source
Argument:

EPG_slot EPG module’s chassis slot location {1…6}
Example:
EPG Sources
Id |Type |Name |Address |Status
4ef8d836-50a9-4145-96d7-c5744e7d6f3b|xmltv|EPGS.com |Multiple urls (28) |Ok
1 |xmltv|Filee |file://epg_4.xml |Ok
2 |ts |VLAN_EIT |udp://229.1.9.102:11103;GE2 |Ok
Natolanka#
5.9.6.3.2.6.2 V IEWING SINGLE EPG SOURCE STATUS
To view the status of a single configured EPG source:
Syntax:
show interface <EPG_slot> source <source_ID>
Arguments:

values
source_ID The external source identifier used as an index. If the source is configured in the Web UI, the <string>
source identifier is a GUID (Globally Unique Identifier) automatically allocated by the
Luminato, for example ‘4ef8d836-50a9-4145-96d7-c5744e7d6f3b’.
Example:
Natolanka# show interface 6 source 1

Name: Filee
Interval: 86400
Time of day: 00:00:00
Id: 1
Url: file://epg_4.xml
256
Last update: 2015-06-08 00:00:28
Next update: 2015-06-09 00:00:00
Status: OK
Natolanka#
5.9.6.3.3 EPG INFORMATION SERVICE MAPPING

By default, the EIT is automatically mapped from the MPEG-2 TS input(s) of the output service by matching the service
input ONID/TSID/SID from the EIT database.
XMLTV channel descriptions do not include any ONID/TSID/SID information and must be mapped to the output services
either manually or semi-automatically by matching the XMLTV channel names with the output service names.
Manual mapping is also possible for MPEG-2 TS type EIT sources.
5.9.6.3.3.1 MAPPING EPG INFORMATION MANUALLY

5.9.6.3.3.1.1 C ONFIGURATION STEPS
To map EPG data to output services manually, take the following configuration steps:
1. Create a mapping entry and enter mapping configuration mode

2. Define the EPG source type
3. Define the input service/chanel
4. Define the output service
5.9.6.3.3.1.2 C REATING A MAPPING ENTRY AND ENTERING MAPPING CONFIGURATION MODE

For each manual mapping you need to create a mapping entry.
To create a mapping entry and/or enter EIT mapping configuration mode:
Syntax:
configure interface <EPG_slot> service-mapping <map_ID>
Arguments:

values
map_ID The mapping identifier used as an index. If the mapping is configured in the Web UI, the map <string>
identifier is a GUID (Globally Unique Identifier) automatically allocated by the Luminato, for
example ‘4ef8d836-50a9-4145-96d7-c5744e7d6f3b’.
Example –create EIT mapping entry ‘ServiceMap1’:
DocumentationTest# configure interface 5 service-mapping ServiceMap1

DocumentationTest(service-mapping-ServiceMap1)#
257
5.9.6.3.3.1.3 S OURCE TYPE
In order to fetch the EPG data from the correct database (XMLTV or EIT database), you need to define the source type.
This will affect which parameters that must be provided for pointing to the EPG data source found in the database.
To specify the source type:
Syntax:
type {eit|xmltv}
Example – specify the EPG source type as ‘EIT’ for ServiceMap1:
DocumentationTest(service-mapping-ServiceMap1)# type eit

5.9.6.3.3.1.4 I NPUT DEFINITION
In order to be able to refer to the desired entry in the EPG database, we need to specify an input pointer. Each source type
has its own set parameters which must be provided in order to unequivocally refer to a service in the database.
5.9.6.3.3.1.4.1 EIT DATABASE

To point to a service in the EIT database:
Syntax:
input onid {0…65535} tsid {0…65535} sid {0…65535}
Keywords:

onid The ONID (Original Network Identifier) of the EIT database entry.
tsid The TSID (Transport Stream Identifier) of the EIT database entry.
sid The SID (Service Identifier) of the EIT database entry.
Example – in mapping entry ServiceMap1, point to service ‘ONID 1 TSID 4001 SID 100’ in the EIT database:
DocumentationTest(service-mapping-ServiceMap1)# input onid 1 tsid 4001 sid 100

5.9.6.3.3.1.4.2 XMLTV DATABASE
To point to a XMLTV channel (equivalent to a service) in the XMLTV database:
Syntax:
input source <source_ID> url <URL_identifier> <XMLTV_URL> cid <channel_ID>
258
Arguments:

values
source_ID The external source identifier used as an index. If the source is configured in the Web UI,
the source identifier is a GUID (Globally Unique Identifier) automatically allocated by the
Luminato.
URL_identifier The URL identifier used as an index. See chapter “XMLTV file location”
XMLTV_URL The URL of the XMLTV file. HTTP and FTP are supported. Although technically not an
channel_ID This is the channel identifier as defined in the official XMLTV DTD for TV listings.
To learn more, visit http://xmltv.cvs.sourceforge.net/viewvc/xmltv/xmltv/xmltv.dtd
Example:
Define the input service for the mapping entry ServiceMap2. The source identifier is MyXMLTV. The URL identifier is VH1.
The XMLTV file is locally stored in Luminato’s chassis.
DocumentationTest(service-mapping-ServiceMap2)# input source MyXMLTV url VH1 file://weekly_vh1-

europe.music_tvprofil.net.xml cid vh1-europe.music
5.9.6.3.3.1.5 R EMOVING EPG MAPPING
To remove an EPG mapping entry:
Syntax:
configure interface <EPG_slot> no service-mapping <map_ID>
Arguments:

values
map_ID The mapping identifier used as an index. If the mapping is configured in the Web UI, the map <string>
identifier is a GUID (Globally Unique Identifier) automatically allocated by the Luminato, for
example ‘4ef8d836-50a9-4145-96d7-c5744e7d6f3b’.
NOTE! Removing the mapping of an input EIT, will revert to default EPG data mapping mode, where the EIT is
automatically mapped from the MPEG-2 TS input(s) of the output service by matching the service input ONID/TSID/SID
(see chapters above).
259
Example – remove the EPG data map labelled ServiceMap2:
DocumentationTest# configure interface 5 no service-mapping ServiceMap2

5.9.6.3.4 D ELETING AN EXTERNAL EPG SOURCE

To remove an external EPG source entry:
Syntax:
configure interface <EPG_slot> no source <source_ID>
Example – remove EPG information source entry MyXMLTV:
DocumentationTest# configure interface 5 no source MyXMLTV

5.9.6.4 EIT IP STREAMING RANGE SETTINGS

The EIT processing module ingests EPG data and transmits the processed EITs via UDP/IP streams. For this purpose, non-
persistent IP input and output interfaces are automatically created and destroyed behind curtains. These are created
within user definable EIT streaming IP address and UDP port ranges. To ensure that these interfaces will not conflict with
other multicast IP payload streams, you should plan carefully the EIT IP address and UDP port allocation ranges so they do
not overlap with other payload streaming allocation ranges.
5.9.6.4.1 IP ADDRESS RANGE

To configure the EIT streaming IP address range:
Syntax:
configure interface <EPG_slot> streaming-range addr <base_IP_address> mask

<stream_range_netmask>
Arguments:

values
base_IP_address The first IP address in the EIT streaming range.
stream_range_netmask Defines the IP address allocation range. For example, if the base IP address is
239.114.240.0 and the netmask value 255.255.240.0, the multicast address
allocation range will be 239.114.240.0 - 239.114.255.255 resulting in a total of
4095 available multicast addresses.
Example – allocate IP addresses for EIT streaming within range 239.114.240.0 - 239.114.255.255:
DocumentationTest# configure interface 5 streaming-range addr 239.114.240.0 mask 255.255.240.0

260
5.9.6.4.2 UDP PORT RANGE
To define the UDP port allocation range for EIT streaming:
Syntax:
configure interface <EPG_slot> streaming-range port <start> to <end>
Arguments:

start The first allocated UDP port for EIT streaming. {5000…65535}
end The last allocated UDP port for EIT streaming. {5000…65535}
Example – set EIT streaming UDP port range to 5000-65535:
DocumentationTest# configure interface 5 streaming-range port 5000 to 65535

5.9.6.5 EIT OUTPUT PROFILE CONFIGURATION

With the EPG processing module, the EIT generation is based on profiles. Two preconfigured profiles are offered:
• Disabled EIT Output Profile (profile_ID=-1):

o Read-only profile
• Default EIT Output Profile (profile_ID=0):
o Editable parameters
o Cannot be renamed
o Cannot be deleted
5.9.6.5.1 C REATING NEW PROFILES

To create a new EIT output profile entry and enter EIT output profile configuration mode:
Syntax:
configure interface <EPG_slot> output-profile <profile_ID>
Arguments:

profile_ID The profile identifier used as an index. <string>
Example – create EIT output profile entry “MyProfile”:
DocumentationTest(interface 5)# output-profile MyProfile

DocumentationTest(output-profile-MyProfile)#
261
5.9.6.5.1.1 PROFILE NAME
To give a profile a descriptive name:
Syntax:
description <profile_name>
Example – label output profile id ‘MyProfile’ as “My profile”:
DocumentationTest(output-profile-MyProfile)# description "My Profile"

DocumentationTest(output-profile-MyProfile)#
5.9.6.5.1.2 STANDARD MINIMUM REPETITION RATES
Select the appropriate standard for the minimum repetition rates of the p/f EITs:
Syntax:
pf repetition-rates {dvb-cs|dvb-t}
5.9.6.5.1.3 EIT PRESENT/FOLLOWING SETTINGS

5.9.6.5.1.3.1 E NABLING / DISABLING EIT A CTUAL /O THER GENERATION
To enable/disable present/following EIT generation:
Syntax:
pf [no] send {actual|other}
Keywords:

values
no Disables transmission of the EIT of the specified type.
actual Information about the present and following events in the actual (currently tuned in) multiplex is
shown. For example, 2 MUXs are declared in the NIT: A and B. The IRD is tuned in to MUX A
which includes EIT p/f actual in its tables: present/following event information is shown for all
services in MUX A only.
other Information about the present and following events are included the EIT p/f Other and is shown
other tuned-in multiplexes. For example, 2 MUX are declared in the NIT; A and B. The IRD is
tuned in to MUX A which includes EIT p/f actual + other in its tables: present/following event
information is shown for all services in MUX A and MUX B.
5.9.6.5.1.3.2 B ANDWIDTH LIMIT
To limit the allocated bandwidth for p/f EIT transmission:
Syntax:
pf bandwidth <limit>
Argument:
262
limit Maximum bandwidth limit in Kbit/s. The target value depends on the amount of services {64000…10000000}
and the quantity of related SI information.
NOTE! Allocate enough bandwidth for large p/f EITs or the configured repetition rates won’t be respected.
5.9.6.5.1.3.3 M INIMUM REPETITION RATE

The repetition rate is the minimum rate at which all sections of the EIT present/following tables are transmitted and is
expressed as intervals in milliseconds (ms). Depending on the configured bandwidth limit and the amount of services and
the quantity of related SI information, the actual repetition rate may be higher.
5.9.6.5.1.3.3.1 PRESET REPETITION RATES

There are three different options to choose from:
• Low: the intervals are based on the standard minimum intervals

o Actual = 2000 ms
o Other = 6000 ms
• Normal: the intervals are half the standard minimum intervals
o Actual = 1000 ms
o Other = 3000 ms
• High: the intervals are the eigth of the standard minimum intervals
o Actual = 250 ms
o Other = 750 ms
To select a preset repetition rate:
Syntax:
pf interval preset {low|normal|high}
5.9.6.5.1.3.3.2 CUSTOM EIT REPETITION RATE

You may manually specify the intervals for Actual and Other p/f EITs.
To use custom EIT actual/other repetition rate in ms:
Syntax:
pf interval {actual|other} {0…60000}
5.9.6.5.1.4 USING THE CUSTOM EIT REPETITION RATE

To start using the customized p/f EIT repetition rates:
Syntax:
pf interval preset custom
263
5.9.6.5.1.5 SCHEDULE
The schedule EIT transmits information about further future events than EIT p/f as a list of events in chronological order.
5.9.6.5.1.5.1 C OVERAGE
To configure how many days ahead the EIT Schedule shall cover:
Syntax:
schedule days {1…14}
5.9.6.5.1.5.2 B ANDWIDTH LIMIT

To limit the allocated bandwidth for schedule EIT transmission:
Syntax:
schedule bandwidth <limit>
Argument:

limit Maximum bandwidth limit in Kbit/s. The target value depends on the amount of services {64000…10000000}
and the quantity of related SI information.
NOTE! Allocate enough bandwidth for large schedule EITs or the configured repetition rates won’t be respected.
Hint: Plan carefully how many days the schedule EIT shall include and consider if EIT schedule other is really necessary:
the amount of data can be quite formidable and it can quickly consume your precious bandwidth.
5.9.6.5.1.5.3 B ITRATE MODE

To select the EIT schedule bitrate mode:
Syntax:
schedule mode{cbr|vbr}
Keywords:

values
cbr CBR (Constant Bitrate) mode; the complete allocated Maximum bandwidth shall be used by
increasing repetition rates.
vbr VBR (Variable Bitrate) mode (default); the EIT schedule is transmitted at variable bitrate
(VBR) with the Maximum bandwidth as a limiting factor
264
5.9.6.5.1.5.4 E NABLING / DISABLING EIT S CHEDULE
To enable/disable EIT Schedule generation:
Syntax:
schedule [no] send {actual|other}
Keywords:

values
no Disables transmission of the EIT of the specified schedule type.
actual Information about the scheduled events in the actual (currently tuned in) multiplex is shown. For
example, 2 MUXs are declared in the NIT: A and B. The IRD is tuned in to MUX A which
includes EIT schedule actual in its tables: schedule event information is shown for all services in
MUX A only.
other Information about the scheduled events are included the EIT p/f Other and is shown other tuned-
in multiplexes. For example, 2 MUX are declared in the NIT; A and B. The IRD is tuned in to
MUX A which includes EIT schedule actual + other in its tables: schedule event information is
shown for all services in MUX A and MUX B.
5.9.6.5.1.5.5 R EPETITION RATES
The repetition rate is the minimum rate at which all sections of the EIT schedule tables are transmitted and is expressed as
intervals in seconds (s). Depending on the configured Maximum bandwidth and the amount of services and the quantity of
related SI information, the actual repetition rate may be higher.
To define the EIT schedule repetition rate:
Syntax:
schedule {actual|other} <first4days> <days5_to_8> <after8th_day>
Arguments:

first4days Interval for the first four days in seconds. 0…3600
days5_to_8 Interval for days 5 to 8 in seconds 0…3600
after8th_day Interval for days after the eight 0…3600
Hint: To preserve bandwidth, events further in the future should have lower repetition rates than events closer to
present time
To see the recommended minimum repetition rates, see ETSI TS 101 211
265
5.9.6.6 C REATING EIT OUTPUTS MANUALLY
By default, the EIT multicast streams are automatically mapped to the output multiplexes behind curtains. However, in
typical IPTV applications the actual P/F data is included in the SPTS outputs, whereas the schedule EPG data is streamed in
separate IP outputs. To this end, the Luminato EPG processing module allows you to create EPG data output streams
manually.
5.9.6.6.1 C REATING AN EIT STREAM ENTRY AND ENTERING STREAM CONFIGURATION MODE
To create an EIT stream entry:
Syntax:
output-stream <stream_identifier>
5.9.6.6.1.1 NETWORK ID
In order to be able to generate correct EPG data, you must associate the EIT output stream to the same network as the
outputs containing the media streams (video, audio etc.).
To specify the target network ID:
Syntax:
network-id {1…65535}
5.9.6.6.1.2 OUTPUT PROFILE

To assign an output profile to an output stream:
Syntax:
profile <profile_ID>
5.9.6.6.1.3 SECTION TYPE

To specify the output EIT section type:
Syntax:
[no] force-actual-ts

no ‘force-actual-ts’ = use EIT actual
‘no force-actual-ts’ = use EIT other
5.9.6.6.1.4 IP DESTINATION ADDRESS
To specify the IP destination address of the output stream:
Syntax:
addr <IP_address>
266
5.9.6.6.1.5 UDP DESTINATION PORT
To specify the IP destination address of the output stream:
Syntax:
port <UDP_port>
5.9.6.6.1.6 OUTPUT PAYLOAD INTERFACE

To specify the payload interface for the output stream:
Syntax:
payload-port {ge1|ge2|internal|vlan <VID>}

values
VID
ge1|ge2
internal
5.9.6.6.2 A SSIGNING EIT PROFILES TO OUTPUT MULTIPLEXES

To assign an EIT output profile to a multiplex:
Syntax:
profile-mapping chassis <IP_address> interface output

<slot_number>/<connector_index>.<stream_index> profile <profile_ID>
Arguments

IP_address Specifies the IP address of the chassis where the target multiplexes are located -
profile_ID Specifies the target EIT output profile
267
5.10 APPLICATION MODULE
The application module, LPC, is a full-fledged Ubuntu Linux computer which allows you to run self-developed or standard
Linux applications on the module.
The module itself is connected to the Luminato platform with gigabit capacity. This internal capacity may be used to
stream payload and management traffic from the LPC to other Luminato modules and vice versa.
There are numerous applications which can be run in the module such as internet radio and TV broadcasting, local file
streaming, stream monitoring and analysis, CAS and middleware server etc.
5.10.1 FRONT PANEL OVERVIEW
The present document provides instructions on how to configure the module’s external interface settings.
For instructions about application development on the LPC, consult the separate
document: Luminato LPC Developer’s Manual
5.10.2 EXTERNAL INTERFACE SETTINGS

LPC’s external interface configuration procedures are identical to those of the EPG processing module.
To learn how to configure the external interface IP settings, please refer to

chapter 5.9.6.3.1
268
5.11 VIEWRIGHT™ BULK DESCRAMBLER LAB-A
LAB-A is a module that allows cardless descrambling of up to streams protected with Verimatrix Video Content Authority
System (VCAS™).
The LAB-A acts as a ViewRight® client and negociates entitlements from the VCAS™ CSM server via a secure HTTPS
connection.
5.11.1 SYSTEM REQUIREMENTS

• Internet access to the Verimatrix VCAS™ CSM server
• 1 x LAB-A
• 1 x UniKey USB dongle (shipped with LAB-A)
• 1…5 x LIM-A

The LIM-A module(s) (IP-to-IP multiplexer) ingest the encrypted streams. The LAB-A acts as a ViewRight® client and
negociates entitlements from the VCAS™ CSM server via a secure HTTPS connection. The LIM-A module(s) retrieve the
channel access data from LAB-A and then decrypt the streams accordingly. If desired, the output streams may be
processed and re-encrypted.
269
5.11.3 INTERFACES
The MicroSD slot is non-functional. The USB port is used for connecting the UniKey dongle. The E1 and E2 1000Base-T
ports are intended for connecting to the Verimatrix VCAS™ CSM.
5.11.4 PREPARATIONS
Before inserting the LAB-A module into the Luminato chassis, please ensure that the provided UniKey USB dongle has
been plugged into the USB port U1, if not plug the USB dongle into port U1.
Once the UniKey dongle in place, you may insert the LAB-A module into the chassis.
5.11.5 RECOMMENDED CONFIGURATION WORKFLOW

We recommend using the following workflow when setting up the bulk descrambling configuration:
1. Configure LAB-A’s external interfaces

2. Specify the VCAS™ CSM server IP address
3. Select the descramble mode for each module
270
4. Configure LIM-A’s input streams
5. Enable descrambling for LIM-A’s input streams
6. Configure LIM-A’s output streams as you normally would
5.11.6 UPDATING THE SOFTWARE

LAB-A’s embedded software contains ViewRight© client software; at some point you may be instructed to update the
software. The software is currently only upgradable through the web UI.
To learn how to update LAB-A’s software, please refer to the web UI manual
5.11.7 EXTERNAL INTERFACE SETTINGS

You may connect to the VCAS™ CSM server either via LAB-A’s external interfaces E1 and E2 or via Luminato’s payload
interfaces GE1 and GE2.
NOTE! If LAB-A is not in the same subnetwork as the VCAS™ CSM server, you must specify the default gateway which
has a route to the VCAS™ CSM server.It is also worth noting that if you wish to connect to the VCAS™ CSM server via a
payload interface (GE1 or GE2), the gateways for E1 and E2 must be set to 0.0.0.0.
LAB-A’s external interface configuration procedures are identical to those of the EPG processing module.
To learn how to configure the external interface IP settings, please refer to

chapter 5.9.6.3.1
5.11.8 VCAS™ CSM SERVER CONNECTION

LAB-A needs a connection to the VCAS™ CSM server. Specify the VCAS™ CSM server’s:
• IP address or FQDN
• port
5.11.8.1 IP ADDRESS
To specify the VCAS™ CSM server’s IP address:
Syntax:
configure blk-server-address {<IP_address>|<FQDN>}
5.11.8.2 P ORT
To specify the VCAS™ CSM server’s port:
Syntax:
configure blk-server-port {1…65535}
271
5.11.9 AES CIPHER MODE SELECTION
In the bulk descrambling configuration, the AES block cipher mode for stream descrambling is configured in the LIM-A
modules. LIM-A supports several AES block cipher modes for stream descrambling:
• CBC
• CBC-CISSA
• CBC-IDSA
• ECB1
• ECB2
You may select the cipher modes explicitly or let LIM-A detect automatically the input stream’s cipher mode.
Enter LIM-A’s module level interface configuration mode as described in chapter

5.2.2.
To select the AES block cipher mode:
Syntax:
blk-descramble-mode {auto|aes-cbc-cissa|aes-cbc-idsa|aes-ecb1|aes-ecb2|aes-cbc}
NOTE! In order to be able to descramble an AES scrambled input stream, the selected cipher mode must match the
cipher mode used in the input stream encryption; hence we highly recommend choosing the automatic cipher mode
detection auto.
272
6 SERVICE CONFIGURATION
This chapter describes the service configuration related procedures.
It is assumed in this chapter that you have configured all the necessary
interfaces, if not revert to chapter Interface configuration.
First, we will introduce the operating principles and concepts of service configuration in Luminato and then subsequently
describe in higher detail the related configuration procedures and CLI commands.
6.1 OPERATING PRINCIPLES

6.1.1 IP CENTRICITY
As previously stated, the Luminato platform features an embedded L2 switch and relies on IP streaming for internal
intermodule payload traffic. External payload IP streaming is also supported through the two Gigabit Ethernet ports.
Hence, all input modules support IP streaming and all output modules support IP stream reception. The IP output streams
can be transmitted either directly to another module on the chassis for further processing, to IP connected headend
equipment on the local or remote headend, or directly to the IPTV network. Hence, the very first step in service
configuration is to create IP output and/or IP input interfaces with matching multicast addresses and UDP ports.
6.1.2 TS PROCESSING MODE

Before being multiplexed, the routed service or PID streams are either processed or passed through unprocessed;
manually or automatically generated PSI/SI tables are either inserted, or original PSI/SI tables passed through. The next
configuration step is to define the TS processing mode for the output interfaces. The Luminato platform supports two TS
processing modes: service or PID mode.
6.1.2.1 S ERVICE MODE

In service mode, the service forwarding or filtering decision is based on SIDs. There are two methods for passing services
from the input to output: selective and promiscuous (called passthrough in the UI).
6.1.2.1.1 S ELECTIVE FORWARDING

With the selective forwarding method, you specify the SIDs of the forwarded services; all services with non-matching SIDs
are blocked. The services forwarded this way are often called static services since the forwarding criterion, the SID, is
static value.
Selective forwarding allows advanced stream processing such as:
• SID and PID remapping (manual or automatic)

• Service level component filtering – include and exclude
• TS level PID inclusion and exclusion
• Service scrambling
Selective forwarding must be used when you want to scramble services or when you want to groom services with
component filters.
273
Hint: The main advantage of selective service forwarding is that advanced processing is possible. The downside is that
any SID change of a given program in the input may cause service loss at output and require reconfiguration of the input
SID of the affected program in the output.
6.1.2.1.2 P ROMISCUOUS FORWARDING

The promiscuous forwarding method can be viewed as the opposite of the selective forwarding: all components that are
referred to in the input PAT and PMT are forwarded from the input to the output. Input services may be blocked by
specifying the SIDs of the blocked services; all services with matching SIDs are blocked.
Compared to the selective forwarding method, the stream processing options in promiscuous forwarding are far more
modest:
• Automatic SID and PID remapping through the usage SID and PID allocation rules
• TS level PID inclusion and exclusion
NOTE! The services forwarded with promiscuous forwarding cannot be processed (descrambling excluded); service
scrambling and service level PID filtering are impossible.
This forwarding method is not totally promiscuous strictly speaking: the input SI streams and unreferred PID streams are
filtered out since PSI/SI
Services are always configured via referring to output connector.
configure interface <slot_number>/<connector_index>.<stream_index>
Referenced connector must be output transport streams.
Example:
configure
interface qam output 1/1.4
6.2 COMMON COMMANDS IN SERVICE CONFIGURATION MODE

mode service
mode pid
Define processing mode.
6.3 PID FILTERING

PID filtering commands can be used used in PID -mode and service -mode. In service -mode these pids are included to the
output in addition to automatic services and without any automatic references in the tables.
passthrough pids %b.%c mode include
274
passthrough pids %b.%c mode exclude
Add PID filter for the input in include or exclude mode.
no passthrough pids %b.%c
Remove PID filter for specific input streams
passthrough pids %b.%c pid <aaa>
passthrough pids %b.%c pid <aaa>=<bbb>
no passthrough pids %b.%c pid <aaa>
Add\Remove PID into filter for specific input or add PID with remapping into filter for specific input (only in include -
mode).
Example:
passthrough pids 1.1 mode include

passthrough pids 1.1 pid 100
passthrough pids 1.1 pid 101=200
passthrough pids 1.2 mode exclude
passthrough pids 1.2 pid 8191
6.4 SERVICE MODE COMMANDS

ts-id <transport_stream_id>
Defines transport stream id. (0-65535)
network-id <network_id>
Defines network id (0-35535)
original-network-id <network_id>
Defines original network id (0-35535)
pid-allocation-mode {follow|component|sid}
Defines the PID –allocation mode. Available modes are: “SID mode”, “Component type mode” and “Input Follow Mode”.
network-name <string>
Defines the network name
6.5 SERVICE PASSTHROUGH

passthrough services <%b.%c>
275
no passthrough services <%b.%c>
Enable\Disable passthrough from specific input connector. Connector can be located in the same module only.
passthrough services <%b.%c> sid-filter %sid [%sid […]]
no passthrough services <%b.%c> sid-filter %sid [%sid […]]
Add specific service opt-out filter for specific input connector passthrough entry. Connector can be located in the same
module only.
NOTE: All services are passed through from the defined input by default.
6.6 EMM PLAYOUT MODE

emm-mode {legacy|manual-include}
Set the EMM playout mode.
By default, Luminato automatically forwards from the input TS EMM streams that have output ECM streams related to
them or injects CAS generated EMM streams to the output TS. This EMM stream handling mode is called legacy –mode.
EMM stream references are automatically inserted to the output CAT if the automatic CAT generation is enabled (default).
The manual-include mode enables you to have more control over the EMM play-out: you may manually include EMM
streams by adding EMM source references to the output interface. The EMM source reference may be either an input
interface or an EMM generator. Manual PID remapping is also possible.
6.7 EMM MANUAL INCLUSION

emm-manual-include {cas|stream}
Enter manual EMM stream inclusion level and select the EMM source type.
6.7.1 CAS SOURCE REFERENCE

cas <%idx1> emmgw <%idx2> channel <%idx3> emm <%idx4>
Enter or add a CAS reference, specify the reference index ranging from 1 to 1000.
[exclude-from-cat]
Exclude the EMM stream from CAT
[output-pid {32…8190}]
Map the EMM stream to the specified output PID.
6.7.2 INPUT MPEG-TS REFERENCE

stream <%idx> input <connector_idx>.<TS_idx>
276
Enter or add an input TS reference, specify a reference index ranging from 1 to 65535.
ca-system-id <CAS_ID> [input-pid]
Set the filtered CAS ID in hexadecimal format (for example 0x01000000) and optionnally the EMM input PID filter. The
filters are inclusive.
[exclude-from-cat]
Exclude the EMM stream from CAT
[output-pid {32…8190}]
Map the EMM stream to the specified output PID.
6.8 EMM PID

emm-pid <%ca-id> {auto|32...8190}
Automatic EMM PID mapping (default) or map a specific PID ranging from 32 to 8190. ca-id is CA Client id in hexadecimal
format (for example 0x01000000).
6.9 SERVICES CONFIGURATION

service <%user-selected-id>
Enter to service configuration mode and optionally create/select a service id.
no service <%user-selected-id>
Remove service configuration with user selected id
service <%user-selected-id> input %a.%b sid %sid
Shortcut to add a service.
Print an informational message when entering the service level, telling whether the user creates a new entry or enters an
existing entry.
6.10 SERVICE CONFIGURATION MODE

no shutdown
shutdown
Enable/disable service
input <%b>.<%c>
277
Define the source of the service
output-sid <SID>
Define service id for configured service
no manual-name
manual-name <%service-name> encoding <char_enc> length <coding_length>
Define service name, SI-character encoding and SI-character encoding length in bytes. If encoding and length values are
not inserted default values are used.
6.10.1 OVERRIDING INPUT SERVICE TYPE CODE
6.10.1.1 O VERVIEW
As per ETSI TS 101 211 V1.12.1, service type information is conveyed in the mandatory service descriptor in the SDT and
the optional service list descriptor in the NIT. By default in Luminato, this information is parsed from the input and copied
to the output tables. However, sometimes this information may be wrong, for example when convert-ing a HD service into
a SD service using an external transcoder which is unable to up-date the SI tables. Another use case could be when
converting, for example, a digital television service to a digital radio sound service by removing the video stream via
component filtering.
To override the input service type code:
Syntax:
type {auto|hdtv|radio|teletext|tv|<service_type_number>}
Argument:

values
service_type_number The service type number as per ETSI EN 300 468 V1.15.1, Table 87: Service {0…255}
type coding. Insert the value in decimals.
6.10.2 DESCRAMBLING
6.10.2.1 D ESCRAMBLING WHOLE SERVICE

descramble sid <input_sid> cam <a|b>
Descramble the SID specified input service using the selected CAM if input service is scrambled.
6.10.2.2 D ISABLING SERVICE DESCRAMBLING

no descramble sid <input_sid>
Disable service descrambling for specified SID.
278
6.10.2.3 C OMPONENT DESCRAMBLING
descramble sid <input_sid> components
{all|ac3|audio|other|subtitle|teletext|video|<stream_type>} [language]
Select a predefined component type code set determining which components associated to the specified SID are to be
1
descrambled . The language option will descramble only the specified component type containing the specified language
code(s) in the service’s PMT. Specify the target ISO 639-2 language code(s), comma separated if several are specified.
• all: descrambles all components

• ac3: descrambles AC-3 component
• audio: descrambles all audio components
• subtitle: descrambles all subtitle components
• teletext: descrambles all teletext components
• video: descrambles all video components
• <stream_type>: descrambles all specified, comma separated, components designated by stream_type values
For example, to descramble audio components in English and French for service of SID 1 found in DVS2 receiver, slot 1,
connector 1:
6.10.3 SCRAMBLING
scramble
no scramble
Scramble (or disable scrambling) the output service.
6.10.3.1 A SSOCIATING ECM STREAMS TO SCRAMBLED SERVICES

ecmg <idx> stream <idx>
no ecmg <idx> stream <idx>
Add/remove ECM association for the service.
base-pid %pid
Set the base pid in component mode pid allocation.
always-in-tables
1
The predefined type sets are based on the ISO/IEC 13818-1 stream type assignments
279
no always-in-tables
Set always in tables.
critical
no critical
Unmark service as critical /Mark service as critical (default)
ca-mode {automatic|not-scrambled|may-be-scrambled}
Set scrambling status. Normally (=automatic), a scrambled input service has CA information associated to it in various
1
PSI/SI tables (e.g. the PMT’s and the CAT’s CA_descriptors and the SDT’s flag free_CA_mode ). By default, this information
is parsed from the input and copied to the output tables. However, sometimes this information shouldn’t be present in
the input in the first place. Such situation could occur for example when using an external decoder which is unable to
update the PSI/SI tables; in such case the CA information associated to services decoded this way would remain in the
input stream.
To address this problem, you may choose to override the input service’s CA information and drop all the CA descriptors
from the PMT and the mark the SDT’s flag free_CA_mode as ‘0’ (=not-scrambled).
Another situation where you might need to override the input service CA information is when you have an MPTS output
with some services whose scrambling status change over time and you need the output service’s free_CA_mode to be
always set to ‘1’ (=may-be-scrambled).
no manual-provider-name
manual-provider-name <provider_name> encoding <char_enc> length <coding_length>
Define service provider name, its SI-character encoding format and length
type auto
type <nnn>
Specify service type automatically, based on input service (default) or define specific service type. Number can be decimal
or hexadecimal
[no] generate pmt
(Do not) generate PMT table for service
generate eit mode {default|epg-actual|present-following}
no generate eit
1
ETSI EN 300 468 v1.14.1 chapter 5.2.3, p.27
280
(Do not) generate EIT table for interface
See Configuration Guide for detailed information.
psi-capture pmt file <filename>
Capture generated pmt table.
pmt-pid auto
pmt-pid <pid>
Automatic PMT PID selection (default) or using specific PID.
pcr-pid auto
pcr-pid <pid>
Automatic PCR PID selection (default) or using specific PID.
ecm-pid <ca_id> auto
ecm-pid <ca_id> <PID>
Automatic ECM PID selection (default) or using specific PID.
ca-id is CA Client id in hexadecimal format (for example 0x01).
sdt-eit-mode {automatic|off|present-following|schedule}
Set the mode for EIT flags in SDT
component-filter default {exclude|include}
Defines default state of component filter.
If default state is exclude then filter starts with empty list.
If default state is include then filter starts fully filled by components from incoming service
[no] component-filter {include|exclude} es-type video {all|max <n> [<languages>]}
[no] component-filter <include|exclude} es-type audio {all|max <n> [<languages>]}
[no] component-filter <include|exclude} es-type ac3 {all|max <n> [<languages>]}
[no] component-filter <include|exclude} es-type subtitle {all|max <n> [<languages>]}
[no] component-filter <include|exclude} es-type teletext {all|max <n> [<languages>]}
[no] component-filter <include|exclude} es-type <nnnn> {all|max <n> [<languages>]}
281
[no] component-filter {include|exclude} pid <nnnn> [output-pid <nnnn>]
[no] component-filter {include|exclude} tag <nnnn> [output-tag <nnnn>]
[no] component-filter {include|exclude} ecm-ca-id <nnnn> [output-ecm-ca-id <nnnn>]
Add\Remove include\exclude filter rule to include\exclude component(s) with type video, audio, AC-3 audio, subtitle,
teletext or specific type (decimal or hex). If specified all then all such components will be included\excluded. Other way
user might specify maximum amount of components to include and languages (defined via comma as three letter codes or
* for any). If no language is specified then “any” is assumed (equal to “*”).
pid-, tag- and ecm-ca-id -filters are supporting remapping but only for include rules.
no component-filter
Remove all component filter settings
An example of a component filter definition where the user explicitly defines which components to have in the service:
component-filter default exclude

component-filter include es-type video all
component-filter include es-type audio max 2 “eng,fin”
component-filter include es-type ac3 max 1
component-filter include es-type ac3 teletext all
component-filter include es-type ac3 subtitle max 3 “eng,fin,*”
component-filter include es-type 27 max 1
component-filter include pid 1000
component-filter include pid 1001 output-pid 4004
An example of component filter definition where the user explicitly defines which components not to have in the service:
component-filter default include

component-filter exclude es-type ac3 all
component-filter exclude tag 3000
component-filter include es-type audio all
component-filter include es-type audio max 1 “swe”
6.11 PSI/SI TABLE INSERTION

generate pat
generate sdt
generate nit
generate cat
Enable table generation with default interval
282
generate pat interval <msec>
generate sdt interval <msec>
generate nit interval <msec>
generate cat interval <msec>
Enable table generation with specified insertion interval
no generate pat
no generate sdt
no generate nit
no generate cat
Disable table generation
generate sdt template file {<filename.psi>|<filename.bin>
SDT is inserted from the configured template file, with the exception that certain fields are added dynamically. Service
descriptor is added for each service if it does not exist in the template. For example: with this feature, it is possible to
insert a custom descriptor to a service.
6.11.1 TDT/TOT TABLE GENERATION

no generate tdt-tot
Disable TDT/TOT table generation
generate tdt-tot mode tdt
Enable “TDT only” - table generation from the device local time with the default insertion interval.
generate tdt-tot mode tdt interval <msec>
Enable “TDT only” - table generation from the device local time with specified insertion interval.
generate tdt-tot mode tdt-tot
Enable TDT- and TOT -table generation from the device local time with default insertion interval.
generate tdt-tot mode tdt-tot interval <msec1> <msec2>
Enable TDT- and TOT- table generation from the device local time with specified insertion interval.
If only msec1 is set, TDT insertion interval = TOT insertion interval = msec1
If both msec1 and msec2 are set, TDT insertion interval = msec1 and TOT insertion interval = msec2
283
generate tdt-tot mode input <%b.%c>
Enable TDT and TOT table passthrough from the specified input: <module.connector>.
The next commands are inserting LTO (local-time-offset) descriptors into TOT table.
Manual LTO can be used to add time offset information for those additional countries which are not supported in
Luminato by default.
LTO and manually defined LTO are configured separately. So if you have LTO and manual LTO, and would like to remove it,
you have to disable both by two commands
generate tdt-tot lto <country_code> <region_id>
Generate LTO -descriptor in TOT -table for specified county and its region id. The country code shall be three letters.
Example:
generate tdt-lto lto USA 0
no generate tdt-tot lto <country_code> <region_id>
Disable generation of LTO -descriptor for specific country code and region ID
generate tdt-tot lto manual <country_code> <region_id> <time_of_change>

<local_time_offset> <next_time_offset> <polarity>
Adding manually defined LTO -descriptor for selected country and region.
Examples:
generate tdt-lto lto manual IND 1 2009-04-10 03:00:00 03:00 02:00 negative
generate tdt-lto lto manual IND 2 2009-04-10 03:00:00 04:00 03:00 negative
generate tdt-lto lto manual USA 5 2009-04-10 03:00:00 04:00 03:00 positive
no generate tdt-tot lto manual <country_code> <region_id>
Remove manually defined LTO -descriptor.
Example:
no generate tdt-lto lto manual USA 5

6.11.2 EIT PROCESSING COMMANDS
show licenses interface <slot>
configure license interface <slot> <key>
284
Configuring EIT license commands
configure generate eit mode {epg-actual|present-following}
Setting the default (global) value for EIT generation
configure no generate eit
Setting the default (global) value to off
configure interface <slot> no generate eit
Setting the value to off for a specific module
show running-config
show running-config interface <slot>
All eit settings can be seen with the show running-config –commands.
6.11.3 STATIC TABLE INSERTION

[no] psi-insert pid <PID> interval <msec> file <filename> interval {100…600000}
Add/remove table insertion. Available also in pid -mode.
psi-capture {pat|cat|sdt|tdt|tot}
Capture generated tables.
6.11.4 LANGUAGE CODE PRIORITIZED PMT COMPONENT ORDER

Normally, the order of the components in the output PMT follows that of the input PMT. However, in some applications
the output PMT’s components should be arranged in a specific language order, e.g. audio tracks and subtitles. Luminato
allows you to specify your own language preferences; all the input PMT’s components with matching language descriptors
will be declared in the specified order in the output PMT. If no matching language codes are found, the components will
declared in the output PMT in the same order as in the input PMT.
To arrange the output PMT components according to specific language order preferences:
Syntax:
configure pmt-language-order <lng_code1>[,<lng_code2>][…][,<lng_coden>]
Argument:

values
lng_coden Insert the target ISO 639.2 language codes in the preferred order, separating each new entry ISO 639.2
by a comma
Example:
285
configure pmt-language-order fin,swe
To remove the output PMT language order preferences:
Syntax:
configure no pmt-language-order
6.11.5 PSI/SI TABLE PROXYING

With the PSI/SI table proxying –feature, PSI/SI tables on stream from super HE are automatically captured and stored to
internal cache and played out locally on remote HE from an input; the captured tables are inserted based on a user-
configured insertion list. A capture is defined by providing the input interface ID, PID, table ID and table ID extension.
PSI/SI table proxying can be enabled or disabled. The automatic capture of the tables is triggered by changes in the input
tables (version and CRC check).
One of the main advantages of this feature is that even if the PSI/SI source fails, the lastly captured table will still remain
inserted to the output multiplex meaning no interruption in the PSI/SI streams.
Hint: Using full PID passthrough in conjunction with the PSI/SI table proxying –feature is highly recommended in IP
centric networks with centralized PSI/SI management. This will allow service and component changes carried out at the
central headend to be automatically propagated to remote headends with minimal configurational effort at the sub-
headends. Additionally, thanks to captured table insertion method, the output PSI/SI streams at the sub-headends will
remain intact even if the central PSI/SI system should fail.
6.11.5.1 E NABLING PSI/SI TABLE PROXYING

To enable PSI/SI table proxying:
Syntax:
configure interface {asi|ip|qam|cofdm} output

<slot_number>/<connector_number>.<stream_index> psi-insert-capture input
<input_index>.<TS_index> pid {0…8191} [table-id {0…255}] [tid-ext {0…65535}] output-pid
{0…8191} interval {100…600000}
Keywords:

PID The target input PSI/SI table’s PID {1…6}
start The first allocated UDP port for EIT streaming. {5000…65535}
end The last allocated UDP port for EIT streaming. {5000…65535}
286
7 DEVICE MONITORING
show modules
Show summary of all available modules.
show modules {main|psu|{1…6}}
Show module information for selected module
Example:
DVBT_chassis# show modules 1
MODULE
HW type: LRT-C quad DVB-T2 CA (ver. B12)
Serial: HL00471214
Uptime (Cumulative): 8 days 19:12:51 (50 days 06:42:55)
Payload bitrate: RX=0 kbps TX=119672200 kbps
Payload IP address: GE1=192.168.90.111 GE2=192.168.90.121
Payload UDP source port: GE1+GE2=2001
Payload MAC address: GE1+GE2=00:90:50:04:f4:5d
STATUS
OK
show status
Show general status for modules, alarm listing and active terminal sessions.
show uptime
Display uptime for all modules.
show uptime {0…6}
Display uptime for selected module.
7.1 LOGGING INFO

To view internal syslog content:
Syntax:
show logging {volatile|non-volatile}
To generate a TAR format CSV file from the syslog:
Syntax:
configure copy {volatile-log|non-volatile-log} {%file|%url}
287
7.2 CAS SYSTEM
show cas
Show summary of ECMGs and EMMs.
show cas ecmg all
Show summary of all ECMGs
show cas ecmg <%idx>
Show ECMG status and ECM summary.
Example:
288
NOTE: Maximum number of streams depends on the amount of supported scrambling channel licenses. The number of
active ECM streams denotes as well the number of used scrambling channel licenses.
show cas ecmg %idx stream %idx
Show ECM stream status.
Example:
show cas ecmg <%idx> stream <%idx> privatebytes
Show ECMG stream private bytes.
show cas ecmg <%idx> privatebytes
Show ECMG default private bytes.
show cas emm
Show EMM summary.
show cas emm <%idx> privatebytes
Show EMM stream private bytes.
289
7.3 ETHERNET INTERFACES
Ethernet interface:
show interfaces {mgmt1|mgmt2}
Show management interface status and counters.
Example:
# show interfaces mgmt1

INTERFACE STATUSES
| Name | MGMT 1
| IP address | dhcp
| Current IP address | 192.168.150.167
| Netmask | 255.255.255.0
| Gateway | 192.168.150.1
| MAC | 00:90:50:03:c7:25
| Status | active
| TX Bytes | 40575073
| RX Bytes | 144312913
#
show interfaces {ge1|ge2}
Show payload interface status and counters.
Example:
# show interfaces ge1

INTERFACE STATUSES
| Name |GE 1 |
| Link |SFP module detected |
| Speed |1000 Mbit/s |
| Mode |Fibre combatible |
| TX Bitrate |209057 kbps |
| RX Bitrate |0 kbps |
| TX Bytes |183262770 |
| RX Bytes |1650731 |
7.4 TS INTERFACES
show interfaces {input|output} {1…6}
Show module status and info. Includes receiver/modulator overview and status.
show interfaces {1…6} cam
Show CAM module status (“ca module a/b”, “status”).
290
show interfaces {1…6} ca-descriptor-mode
Show CA descriptor mode.
show interfaces <connector>
For module level (“ip input a”): show configured inputs/outputs and their status (“input/output page”)
IP |Description |SSM |Destination IP |Port |Red|Bitrate|Status

input | | | | |und|(kbps) |
3/1.100| |ON | 224.255.255.255|12345| *3| 4521|OK
IP |Description |Destination IP |Port |Bitrate|Status

output | | | |(kbps) |
3/1.100| | 224.255.255.255|12345| 4521|OK
Dvbs2|Description |Freq |Symbolrate|SNR |FEC|Ber |Bitrate|Status

input| |(MHz) |(ksym/s) | | | |(kbps) |
1/2.1| | 12597| 24500|10.2|2/3|1.3e-8| 36103|OK
Dvb-t|Description |Freq |Mod |SNR |FEC|Ber |Bitrate|Status

input| |(MHz) | | | | |(kbps) |
1/2.1| |714.00|QPSK|24.2|2/3|2.3e-8| 36103|OK
ASI |Description |Bitrate|Status

input| |kbps |
1/2.1| | 36103|OK
COFDM |Description |Freq |QAM/|FEC|Bitrate|Bitrate max|Status

output| |(MHz) |QPSK| |(kbps) |(kbps) |
1/2.1 | |714.00|QPSK|2/3| 21563| 25000|OK
QAM |Description |Freq |Sym.rate|QAM|Bitrate|Bitrate max|Status

output| |(MHz) |ksym/s | |(kbps) |(kbps) |
1/3.1 | 714.00| 6900|256| 45712| 50100|OK
ASI |Description |Bitrate|Bitrate max|Status

output| |kbps |kbps |
1/2.1 | | 36103| 70000|OK
show interfaces <connector>
For stream (a/b.c): stream summary: output/input page row info + pid/service mode setting(out only) + service names
(service mode only).
0 1 2 3 4 5 6 7
123456789123456789123456789123456789123456789123456789123456789123456789
IP input: 3/1.4 Description: blabla
291
(type specific info here)
Status: Signal lost from input 2

Bitrate: 3860 kbps (onko tämä erikseen dvbs-inputille?)
Redundant streams: (or "No redundancy configured")

Input |Active | Status
3/1.4 | | Signal lost from input 2
3/1.5 | * | OK
3/1.6 | | OK
Mode: Service mode (only output)

Pid allocation mode: SID mode
Services: 53
Passthrough services: 1
Pids: 124
PSI/SI insertions: 5
PID filters: 2
EMM streams:
PID | CA system ID
500 | 3329
501 | 1540
502 | 6147
503 | 3331
------------------------------------------------------------------------
IP type
------------------------------------------------------------------------
IP source address: Any/192.168.0.100
IP destination address: 224.0.3.1
IP destination port: 1234
TTL: 5
TS packets per frame: 7
------------------------------------------------------------------------
DVB-S type
------------------------------------------------------------------------
Lock status: LOCK
Signal strength: 20 %
SNR estimate: 5.9 dB
Post-Viterbi BER: 3.9e-4
Final BER: 0.0e-0
Standard: DVB-S
Frequency: 12597 MHz
Frequency offset: -41365 Hz
FEC rate: 3/4

Modulation: QPSK
Symbol rate: 27499 ksym/s
(TS bitrate: 38012 kbps)
292
LNB current: 0 %
------------------------------------------------------------------------
DVB-T type
------------------------------------------------------------------------
Lock status: LOCK
Signal strength: 20 %
SNR estimate: 5.9 dB
Post-Viterbi BER: 3.9e-4
Final BER: 0.0e-0
Transmission mode: 8k
Bandwidth: 8 MHz
Frequency: 12597 MHz
Frequency offset: -41365 Hz
FEC rate (high): 1/2

FEC rate (low): 3/4
Guard interval: 1/32
Hierarchy: Off
Modulation: 64-QAM
(TS bitrate: 38012 kbps)
7.5 INTERFACE MONITORING

These commands apply for input or output interfaces.
show interfaces input <%a>/<%b>.<%c> rtp
Show RTP input monitoring info for module IP input. Not available for ip output interfaces or mirrored ip output
interfaces.
Example:
# show interfaces input 6/1.1 rtp

RTP
IP input: 6/1.1 Description:
Source address: 0.0.0.0

Destination address: 239.3.1.0
Destination port: 5000
Packet format: RTP
Status: OK
Bitrate: 24803 kbps
RTP input counters

Dropped packets: 0
Duplicate packets: 0
293
Reordered packets: 0
Discontinuities detected: 0
Incorrect sequence numbers: 0
Network jitter monitoring

Current jitter 0.00 ms
Peak jitter (2 seconds) 0.01 ms
show interfaces <input|output> <connector> services
Show all services for specified connector. Input services shown for Inputs and Outputs services shown for Outputs. For
each services, status, service name, SID, type (TV/radio), bitrate and CA-status: free/scrambled are shown.
Example:
show interface input 1/1.1 services

SERVICES
Input | SID |Service name |Type|Bitrate|CA mode|Status
1/1.1 |113 |YLE Teema | TV| | Free|OK
1/1.1 |17 |YLE TV1 | TV| | Free|OK
1/1.1 |33 |YLE TV2 | TV| | Free|OK
1/1.1 |3347 |Ohjelmistopäivitykset | 0xc| | Free|OK
1/1.1 |353 |SVT World | TV| |Encrypt|OK
1/1.1 |4369 |YLE Puhe | R| | Free|OK
1/1.1 |4401 |YLEN KLASSINEN | R| | Free|OK
1/1.1 |4433 |YLEMONDO | R| | Free|OK
1/1.1 |81 |YLE FST5 | TV| | Free|OK
show interfaces <input|output> <%a>/<%b>.<%c> services <%sid>
Displays detailed info about the service.
Example 1:
show interfaces input 1/1.1 services 17

SERVICES
Input | SID |Service name |Type|Bitrate|CA mode|Status
1/1.1 |17 |YLE TV1 | TV| | Free|OK
COMPONENTS
PID |Type |PCR|ID |Bitrate | Language
1027|Subtitle (6)| |999| 0|fin
2321|Teletext (6)| |10 | 225|fin
512 | Video (2)| * |1 | 3652|
650 | Audio (4)| |11 | 237|spa
651 | Audio (4)| |15 | 173|dut
294
Service provider: YLE
PMT PID: 256
PCR PID: 512
Example 2:
show interfaces output 1/1.2 services 60

SERVICES
Output | SID |Service name |Type|Bitrate|CAM|Scramble|Status
1/1.2 |60 |YLE TV2 | TV| | | ECMs: |OK
COMPONENTS
PID |Type |PCR|ID |Bitrate | Language
61 | Video (2)| * |2 | 2657|
62 |Teletext (6)| |10 | 227|fin
64 |Subtitle (6)| |999| 0|fin
66 | Audio (4)| |21 | 237|eng
67 | Audio (4)| |25 | 174|dut
Service provider: YLE
PMT PID: 60
PCR PID: 61
Component filters: default include (0 include filter(s), 0 exclude filter(s))
idx |ECM generator |idx|ECM stream
show interfaces {input|output} <%a>/<%b>.<%c> emm-pid [<ca_id>]
Displays emm-pid configuration.
show interfaces {input|output} <%a>/<%b>.<%c> services <sid> ecm-pid [<ca_id>]
Displays ecm-pid configuration.
show interfaces <%a>/<%b>.<%c> pids
Show all PIDs for specified connector. Not available for output interfaces or ip input interfaces.
Example:
show interface input 1/1.1 pids

PIDS
Connector |PID |CC Errors |Bitrate(kbps)|Bitrate peak (kbps)
in 1/1.1 |0 |32 | 16| 27
in 1/1.1 |1 |46 | 16| 27
in 1/1.1 |16 |5 | 0| 13
in 1/1.1 |17 |26 | 25| 41
in 1/1.1 |18 |347 | 476| 560
in 1/1.1 |20 |2 | 0| 13
in 1/1.1 |192 |81 | 101| 123
295
in 1/1.1 |256 |29 | 16| 27
in 1/1.1 |512 |839 | 4151| 8285
in 1/1.1 |513 |840 | 2653| 8176
in 1/1.1 |514 |785 | 3322| 9078
in 1/1.1 |515 |896 | 2266| 2980
in 1/1.1 |516 |671 | 2750| 8217
in 1/1.1 |581 |141 | 223| 287
in 1/1.1 |8191 |0 | 2929| 8545
configure interface <%a>/<%b>.<%c> monitor-pid <%pid>
configure interface <%a>/<%b>.<%c> no monitor-pid <%pid>
Add/remove manual PIDs for monitoring. Not available for output interfaces or ip input interfaces.
configure interface <connector> clear pid-counters {all|<%pid>}
Clear pid counters for all pids or optionally for one pid.
show interfaces input <%a>/<%b>.<%c> fec
Show FEC decoder monitoring info for module IP input. Available only for FEC decoder input interface.
Example:
# show interfaces input 3/1.1 fec

Input
Source address: any
Destination VLAN: ge2
Packet format: RTP
Output
Packet format: RTP
Status: OK
Bitrate: 4244kbps
FEC decoder status

FEC mode: 2D - Column & Row
Column FEC port: 1002
Row FEC port: 1004
296
FEC column depth (D): 5
FEC row length (L): 4
Latency: 179 ms
FEC decoder statistics
Valid packets: 405259
Uncorrected packets: 0
Corrected packets: 0
Discontinuities: 0
Current jitter: 0.00 ms
Peak jitter: (3 seconds) 0.01 ms
show interfaces output <%a>/<%b>.<%c> fec
Show FEC encoder monitoring info for module IP output. Available only for FEC encoder IP output interface.
Example:
lumi-guide# show interfaces output 2

INTERFACE ProMPEG FEC Encoder
IPtoIP |Description |FEC|Input IP |Port |For|Bitrate|Status
_______|_________________|___|Output IP______|_____|mat|(kbps)_|______________
2/1.1 |Service A |Def|239.3.1.0 |2000 |RTP| 0|Off
_______|_________________|___|239.2.1.0______|6000_|RTP|_______|______________
2/1.2 |Service B |Def|239.3.1.0 |2010 |RTP| 7018|OK
_______|_________________|___|239.2.1.1______|6010_|RTP|_______|______________
2/1.3 |Service C |On |239.3.1.0 |2020 |RTP| 7018|OK
_______|_________________|___|239.2.1.2______|6020_|RTP|_______|______________
2/1.4 |Service D |Off|239.3.1.0 |2030 |RTP| 7018|OK
_______|_________________|___|239.2.1.3______|6030_|RTP|_______|______________
2/1.5 |Service E |Def|239.3.1.0 |2040 |RTP| 7018|OK
_______|_________________|___|239.2.1.4______|6040_|RTP|_______|______________
2/1.6 |Service F |On |239.3.1.0 |2050 |RTP| 7018|OK
_______|_________________|___|239.2.1.5______|6050_|RTP|_______|______________
lumi-guide# show interfaces output 2/1.2 fec
IP output: 2/1.2 Description: Service B
Input
Source address: any
Destination VLAN: internal
Packet format: RTP
Output
297
Packet format: RTP
FEC encoder: enabled (module default settings)
Status: OK
Bitrate: 7018kbps
FEC encoder status

Row FEC port: 6014
FEC arrangement: Block-align
FEC overhead: 26 %
Latency: 180 ms
lumi-guide#
Example:
# show interfaces output 2/1.1 fec

IP output: 2/1.1 Description:
Input
Source address: any
Packet format: RTP
Output
Packet format: RTP
FEC encoder: enabled
Status: OK
Bitrate: 4249kbps
FEC encoder status

Row FEC port: 1004
FEC arrangement: Non-block-aligned
298
FEC overhead: 45 %
Latency: 99 ms
configure interface <%a> clear stats fec counters all
Clears all monitoring counters on every IP input on selected FEC decoder interface. Available only for FEC decoder
interface.
configure interface ip input <%a>/<%b>.<%c> clear stats fec {counters|peak-jitter}
Clears monitoring counters on selected FEC decoder IP input. Available only for FEC decoder IP input interface.
Example:
lumi-guide# show interfaces input 4

INTERFACE ProMPEG FEC Decoder
IPtoIP |Description |FEC|Input IP |Port |For|Bitrate|Status
_______|_________________|___|Output IP______|_____|mat|(kbps)_|______________
4/1.1 |Service A |- |239.2.1.0 |6000 |UDP| 0|Signal missing
_______|_________________|___|239.4.1.0______|5000_|RTP|_______|______________
4/1.2 |Service B |2D |239.2.1.1 |6010 |RTP| 7026|FEC corr. pckt
_______|_________________|___|239.4.1.0______|5010_|RTP|_______|______________
4/1.3 |Service C |2D |239.2.1.2 |6020 |RTP| 7026|FEC corr. pckt
_______|_________________|___|239.4.1.0______|5020_|RTP|_______|______________
4/1.4 |Service D |2D |239.2.1.3 |6030 |RTP| 7026|FEC corr. pckt
_______|_________________|___|239.4.1.0______|5030_|RTP|_______|______________
4/1.5 |Service E |2D |239.2.1.4 |6040 |RTP| 7026|FEC corr. pckt
_______|_________________|___|239.4.1.0______|5040_|RTP|_______|______________
4/1.6 |Service F |- |239.4.1.0 |5050 |UDP| 0|Signal missing
_______|_________________|___|224.1.1.1______|5406_|RTP|_______|______________
lumi-guide# show interfaces input 4/1.2 fec
Input
Source address: any
Packet format: RTP
Output
Destination VLAN: internal
Packet format: RTP
Status: FEC has corrected packets (input 2)

Bitrate: 7009kbps
299
FEC decoder status
Row FEC port: 5014
Latency: 228 ms
FEC decoder statistics
Valid packets: 740095
Uncorrected packets: 0
Corrected packets: 1381
Discontinuities: 0
Current jitter: 0.00 ms
Peak jitter: (48 seconds) 0.01 ms
lumi-guide# configure
lumi-guide(configure)# interface ip input 4/1.6
lumi-guide(iface-ip-input-4/1.6)# clear stats fec counters
lumi-guide(iface-ip-input-4/1.6)# clear stats fec peak-jitter
lumi-guide(iface-ip-input-4/1.6)#
7.6 PSU MONITORING

To view the voltage warning and alarm threshold levels:
Syntax:
show environment voltage {device|backup} threshold
To configure voltage level alarm and warning threshold settings:
Syntax:
configure environment voltage {device|backup} threshold <low_alarm> <low_warning>

<high_warning> <high_alarm>
NOTE! Device means main PSU in this context
Example:
voltage backup threshold 22.5 23 25.5 26
To set voltage monitoring on/off:
Syntax:
300
configure environment [no] voltage {device|backup} alarm
Example:
voltage backup alarm
301
8 FAIL-SAFE REDUNDANCY FEATURES
Luminato provides several fail-safe features to ensure uninterrupted service delivery:
• PSU redundancy
• 1+1 chassis redundancy
• RF/ASI input redundancy
• IP input stream redundancy
Three of these features are described in the sub-chapters below.
PSU redundancy is described in the separate “Luminato power supply installation

manual”
8.1 RF/ASI INPUT & IP INPUT STREAM REDUNDANCY

To ensure uninterrupted service delivery in case of lost or bad signal, it is advised to use Luminato’s RF/ASI input & IP
input stream redundancy features, hereon referred to as input redundancy for briefness.
Input redundancy is used to back up primary source of services with one or several redundant inputs and doesn't require
any separate backup device to work. Redundant inputs may be automatically activated in case the user defined
redundancy triggering criteria of the currently active inputs are met entirely or partially.
To learn how to back up physical inputs (RF & ASI), see chapter RF and ASI input
redundancy
To learn how to back up IP streams, see chapter IP input redundancy
8.1.1 INPUT REDUNDANCY APPLICATIONS

Diversity sources to protect against:
• Difficult weather conditions (rain, snow…)

• Disasters (fire, fibre cut…)
• Source device malfunction
Local feed backup from backbone to overcome:
• Transmitter station problems

• Antenna problems
• Local receiver malfunction
Test picture backup, if main program is lost.
8.1.2 SYSTEM REQUIREMENTS
302
8.1.2.1 H ARDWARE
Any Luminato module type.
8.1.2.2 S OFTWARE
Luminato SW 3.3.x or higher.
8.1.2.3 L ICENSES
The Input redundancy –features doesn’t require any separate license.

Input redundancy is used to back up primary source of services in case the input bitrate is lost or drops below a user
defined threshold. You may configure up to four redundant inputs for one primary input. For identical backup, the
redundant inputs should contain the same services which are configured from primary input to output. Ideally, the backup
inputs should come from independent paths and separate sources (e.g. separate antennas, separate networks etc.) in case
the signal loss is due to an external hardware or system failure.
Input redundancy feature manual and automatic input switching. You are able to define a set of triggers used as
conditions before a redundant input is automatically activated. The redundant inputs can be monitored continuously,
periodically or never. The last two modes are intended for multicast inputs when IP bandwidth is limited.
Redundant inputs are organized in a priority order list, higher priority inputs being at the top the list. Switch to a lower
priority redundant input occurs whenever any redundancy triggering conditions are met in the currently active input.
Automatic recovery to highest priority input is possible when continuous or periodical input monitoring has been enabled.
If automatic recovery isn't enabled, recovery to higher priority inputs requires user intervention.
In a configuration where both input redundancy and hardware redundancy (1+1 backup) are active, you may mark the
primary input and its redundancies as critical inputs. Failure of critical redundant inputs causes a handover to the 1 +1
backup device, even though individual primary and redundant inputs would not be marked as critical inputs.
NOTE! If no triggering criterion has been selected, the redundant streams may only be activated manually.
8.1.3.1 I NPUT MONITORING

• Continuous: The input is monitored continuously. The advantage of this mode is rapid input status update for
automatic recovery. In case inputs are multicast IP streams, they are joined continuously even if not active.
• Periodical: In this mode each redundant input is monitored in five minutes intervals. It may take over five minutes
before the redundant input status is updated to OK and automatic recovery can take place. This mode is useful
only when using IP stream redundancy with the redundant IP inputs being disabled. The advantage of disabling
redundant multicast inputs is that IP bandwidth is consumed only periodically. In case of signal loss, the next
redundant signal with status OK will be activated even if the redundant IP input is configured as disabled.
8.1.3.2 U SER CONFIGURABLE TIMEOUTS

• Warning timeout: The timeout before Input missing or Service missing –warning is reported and redundant input
is activated due to related trigger.
303
• PID timeout: The timeout before PID missing –warning is reported and before redundant input is activated due to
this trigger.
• Recovery timeout: Defines how long is waited before automatic recovery is tried. The timeout is calculated from
the moment input status has been monitored OK. The next input is the one with highest priority and OK status.
8.1.3.3 R EDUNDANT INPUT SWITCH

If Recovery is set to Automatic the next input is the highest priority input having OK status. If automatic recovery is not
enabled, the activated input is the next redundant input with OK status in the redundancy priority list.
If input Monitoring mode is set periodical, the disabled IP input is deactivated and IGMP leave is sent in case of multicast
input.
If a redundant input switch has occurred, the Redundancy activated –notification is shown in module syslog. A SNMP trap
is sent whenever a warning flag is raised.
NOTE! Signal and Service warnings are issued only, if the input stream or service is defined as critical and the input
stream doesn't have any working redundant inputs.
The stream status depends directly on the selected triggers and the triggering sensitivity settings (bitrate threshold and
timeout). Hovering the mouse over a status indicator will give additional information about current status (Error!
Reference source not found.). A SNMP trap is sent whenever a warning flag is raised.
Hint: To prevent the need of reconfiguration of end-user IRDs in case of redundancy input switching, it is
recommended to use as identical input streams as possible, with the exception of the aforementioned special use case of
test picture as redundant input.
8.1.4 RF AND ASI INPUT REDUNDANCY

To use Stream redundancy in receiving modules, one of the input interfaces (RF or ASI) is designated as primary input and
the remaining inputs may be assigned to the primary input as redundant inputs. A use case for this feature could be the
use of local redundant antennas in case antenna failure (for example, LNB failure, bird on a satellite dish, snow
accumulation, frost etc.).
We suggest the following workflow:
1. Configure the primary and redundant tuners or ASI inputs.

2. Define the primary input
3. Assign redundant inputs to the primary input and set input monitoring to Continuous for each input.
4. Define the redundancy input switch triggers.
5. Adjust the redundancy input switch triggering sensitivity.
6. If necessary, enable the automatic recovery feature.
7. Drag and drop the primary input TS or service(s) to the target output interface.
8. Adjust the Critical input and Critical service –settings.
304
NOTE! With RF and ASI input redundancy, the redundant inputs must reside within the same module. This restriction
may be overcome by converting the RF and ASI inputs to IP streams and using IP input redundancy.
8.1.4.1 P RELIMINARY INTERFACE CONFIGURATION

Configure each input interface of the target module to receive the same TS. Navigate to interface configuration level of
the intended input interface.
Example:
In the sub-sequent examples, we will use the dual DVB-T/T2 input module LRT-B and tune in both tuners to 714 MHz.
To learn how to configure input interfaces, see chapter 5.4
Input 2/1.1 is designated as the intended primary input, so navigating to its configuration level will look like this:
DocumentationTest# configure interface dvbt2 input 2/1.1

DocumentationTest(iface-dvbt2-input-2/1.1)#
8.1.4.2 A SSIGNING BACKUP INPUTS TO PRIMARY INPUT

To assign a backup input to a primary input:
Syntax:
redundant-stream <input_index> input <connector_index>.<TS_index>
Arguments:

values
input_index The input index of the redundant input. Select ‘0’ when defining the primary input. {0…5}
This value also acts as priority level, ‘0’ being highest priority and ‘5’ lowest priority.
connector_index The connector index of the intended redundant input. {1…4}
TS_index The TS index of the intended redundant input. {1…128}
Example:
First, we will define input 2/1.1 as the primary input and then we will assign input 2/2.1 to it as a redundant input.
DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream 0 input 1.1

DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream 1 input 2.1
8.1.4.3 R EDUNDANCY TRIGGERS

To define the redundancy triggering criteria:
305
Syntax:
[no] redundant-stream {0…5} trigger {signal|service|pid|auto-recover}

[signal|service|pid|auto-recover] [signal|service|pid|auto-recover]
[signal|service|pid|auto-recover]
Keywords:

values
signal Triggers an input switch if the input bitrate drops to zero or below the user set Signal lost -
threshold. Non-zero bitrate threshold is useful for example in situations where the source has
lost all services but is still able to generate PSI/SI tables and the bitrate never drops to zero.
With RF inputs, this is the only useful input switching criterion since the input TS is an over-
the-air DTV broadcast on a single channel and no redundant broadcasts are locally available.
service Triggers an input switch if a Service missing –warning is raised. The services need to be defined -
as critical. This criterion is only useful with ASI inputs containing re-multiplexed TSs.
pid This input switching trigger is not useful with ASI/RF inputs. -
auto- When one of the above criteria has triggered an input switch in an active redundant input, the -
recover input will be automatically switched to the highest priority input having ‘OK’ as its status. The
input will also be automatically switched to the highest priority input having ‘OK’ as its status
for a time defined by the recovery timeout command. This timeout value determines how
long a higher priority input status has to be OK before automatically recovering.
NOTE! If no input switching trigger has been enabled, the redundant inputs may only be activated manually.
NOTE! If automatic recovery isn't enabled, recovery to higher priority inputs requires user intervention.
Example:
In our example, the only useful input switching trigger is signal. We also wish the redundant input to automatically
recover to the primary input when its status is OK.
DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream 0 trigger signal

DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream 1 trigger signal auto-recover
8.1.4.4 I NPUT SWITCH TRIGGERING SENSITIVITY

The redundancy triggering sensitivity for signal and service triggers is adjusted with the module level signal-lost
threshold and the timeout warning commands.
The signal-lost threshold and timeout warning configuration is

described in more depth in chapter ‘Signal lost criteria’.
306
8.1.4.5 A UTOMATIC RECOVERY TIMEOUT
The automatic recovery timeout determines how long a higher priority input status has to be OK before automatically
recovering. The automatic recovery timeout can be set at three levels:
• chassis level: The recovery timeout acts as a default value for all modules
• module level: The recovery timeout acts as a default value for all inputs of the target module Can be set to a
custom value or to use the chassis level value. Custom values will override the chassis level value.
• input level: The recovery timeout affects only the target input. Can be set to a custom value or to use the
module level value. Custom values will override the module level value.
8.1.4.5.1 C HASSIS LEVEL

To define the chassis default automatic recovery timeout (in seconds):
Syntax:
configure redundant-stream autorecovery timeout {0…36000}
8.1.4.5.2 M ODULE LEVEL

To define the module’s default automatic recovery timeout (in seconds):
Syntax:
configure interface <slot_number> redundant-stream autorecovery timeout {default|0…36000}
Keyword:

default Uses the chassis default automatic recovery timeout value. -
8.1.4.5.3 I NPUT LEVEL

To define the module’s default automatic recovery timeout (in seconds):
Syntax:
redundant-stream autorecovery timeout {default|0…36000}
Keyword:

default Uses the module default automatic recovery timeout value. -
Example:
We want to set the automatic recovery timeout to 10 s for input 2/1.1 only.
DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream autorecovery timeout 10

307
8.1.4.6 R EDUNDANT INPUT MONITORING MODE
Next, select continuous as monitoring mode for each input. In this case, it is the only useful option since the RF and ASI
inputs are internally switched in the module before being streamed forward and no IP bandwidth is therefore consumed
when monitoring non-active RF and ASI inputs.
To set the input redundancy monitoring mode:
Syntax:
redundant-stream monitoring {continuous|periodical}
Keyword:

values
continuous The input is monitored continuously. The advantage of this mode is rapid input status update -
for automatic recovery. This is the only useful monitoring mode for RF and ASI inputs.
periodical In this mode each redundant input is monitored in five minutes intervals. It may take over -
five minutes before the redundant input status is updated to OK and automatic recovery can
take place. This mode is useful only when using IP stream redundancy with the redundant
IP inputs being disabled.
Example:
Continuing the example above, we set continuous for both inputs.
DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream 0 monitoring continuous

DocumentationTest(iface-dvbt2-input-2/1.1)# redundant-stream 1 monitoring continuous
8.1.4.7 C RITICAL INPUT AND C RITICAL SERVICE SETTINGS

By default, all the input interfaces and input services are pre-set as critical. These settings affect how missing signals or
services are reported in status info or event log. The primary input may be defined as a critical input. A warning flag will be
raised, when the input signal is considered lost. Otherwise the missing signal is reported as a notification.
Refer to chapters from 0 to 5.4.4.2 for more details on the Critical input –setting
for ASI and RF inputs.
If you intend using service redundancy trigger, the output services need to be configured as critical: non-critical lost
services won’t trigger a redundancy input switch.
NOTE! Passthrough output services cannot be configured as critical.
Example:
We want to define the primary input as critical.
308
DocumentationTest(iface-dvbt2-input-2/1.1)# critical
8.1.5 IP INPUT REDUNDANCY
When backing up signals originating from different input modules or when using external backup IP streams, you need to
create IP input and IP output interfaces. One of the IP inputs is designated as primary stream and up to four IP inputs may
be assigned to it as redundant inputs. The recommended configuration procedure depends on the MPEG transport stream
type: SPTS or MPTS. With SPTS redundancy we strongly recommend using the Passthrough any SID –feature for easier
configuration. With MPTS the primary and redundant TSs should be exactly identical.
To learn how to configure IP input redundancy, please refer to the separate web
UI manual
8.2 EMERGENCY NOTIFICATION STREAMING

Luminato features an emergency notification mechanism that allows you to force a single emergency notification input
stream to all output streaming interfaces when the user configurable emergency notification triggering conditions are
met.
NOTE! This chapter is intended as a brief description of all commands related to emergency notification streaming
To learn about emergency notification streaming in greater details, please refer to the separate web UI
user manual
To specify the destination UDP IP address and port of the emergency notification input stream:
Syntax:
configure emergency udp <IPv4_address>:{1…65535}
To modify the destination UDP port of the emergency notification input stream:
Syntax:
configure emergency port {1…65535}
To specify the source IP address of the emergency notification input stream in case of SSM:
Syntax:
configure emergency src-ip <IPv4_address>
To specify the payload port used for emergency notification stream reception:
Syntax:
configure emergency payload-port {all|ge1| ge2|internal|vlan {1…3999}}
309
To specify the service to use from the input emergency notification stream:
Syntax:
configure emergency service-id {any|<SID>}
To set the emergency notification streaming triggering mode:
Syntax:
configure emergency trigger {manual|ext1-io-down|ext1-io-up|ext2-io-down|ext2-io-up|stream}
NOTE! When using the triggers ext1-io-down|ext1-io-up|ext2-io-down|ext2-io-up; make sure that the
target EXT port’s functional mode is set to emergency
See chapter 9.4.3
To clear the emergency notification streaming configuration:
Syntax:
configure emergency trigger off
To activate/deactivate emergency notification streaming manually:
Syntax:
configure emergency [no] manual-trigger
8.3 1+1 BACKUP

Luminato’s 1+1 backup feature provides 1+1 redundancy at chassis level in a system with two identical chassis. The pair of
Luminato can be configured to act in master and backup schemes, where the secondary Luminato monitors the primary
Luminato’s status. All functions of the primary chassis are handed over to the secondary chassis if necessary. If both
chassis are paired over IP, configuration of both chassis may be synchronized with a single command-line; more so, chassis
activation and configuration synchronization may be performed through one chassis.
The backup Luminato stays in stand-by mode until a failure occurs in the main Luminato. When the main device identifies
a failure event or the main device is not responding, all payload outputs of the main device are shut down based on
dedicated hardware circuitry to ensure the switch-off of all streaming. The secondary Luminato then takes over the
stream processing operations.
Signal backup can be arranged if the devices in the 1+1 system have the same input signals from independent sources. If
the main device detects the loss of any input signal that is configured as critical and the 1+1 Backup system is activated, it
will react and pass control to the backup device.
Luminato’s stream redundancy feature is intended for more sophisticated signal redundancy configuration.
310
For more information about using 1+1 backup system for signal redundancy, see
chapter “Using Luminato 1+1 backup for signal redundancy”.
For more information about using 1+1 backup system simultaneously with the
stream redundancy feature, see chapter “Using 1+1 backup together with the Stream
redundancy feature”.
8.3.1 1 + 1 BACKUP SYSTEM REQUIREMENTS

Prior setting up the 1 + 1 backup system, please ensure that the requirements described below are met.
8.3.1.1 H ARDWARE
• Two identical device setups (i.e. two Luminato chassis with identical set of modules).
• Both chassis have to be of HW version B10 or higher so that they support GOE (global output
enable) signaling in the chassis.
• If LAS-A quad ASI input modules are present in the system, they need to be of HW version B13 or
higher.
• A LACCB1 cable to connect the two chassis into a 1+1 Backup system. Backup device senses the
heartbeat signal of the Main device via the LACCB cable.
NOTE! If a faulty module is replaced with a module of a more recent type, then both devices’ modules must be
updated to the same type. When ordering a replacement for a broken module, please inform our Repair service it is for a
1+1 backup system replacement.
8.3.1.2 S OFTWARE
• Configuration synchronization and backup control over IP Luminato: SW 6.2.x or higher
• Both chassis must have the same SW version and identical (synchronized) configurations at all time
8.3.1.3 L ICENSES
• Both chassis must have a 1 + 1 Backup license.
• Both chassis must have identical module licenses.
• If the chassis has no valid 1 + 1 Backup license, the 1+1 Backup feature won’t be available
For more information on license management, see chapter “License

management”.
8.3.1.4 CAS
When DVB-CSA scrambling is being used in a 1 + 1 backup system:
• Both units require their own separate ECMGs. Using the same ECMG could result in an ECM generator overload.
More so, there would be a possibility that CAS won’t accept connection to the second unit because the
parameters are the same. The ECMGs IP settings behave differently in a 1+1 backup context compared to a
1
LACCB is a cable dedicated for 1+1 backup systems
311
standalone configuration: the Main device uses the ECMG’s IP settings and the Backup device uses the ECMG’s
spare IP settings.
• Both units need to create their own ECM streams, regardless of their current active/passive state
• Both units need to receive an EMM stream, regardless of their current active/passive state. This has to be
configured in both the CAS and Luminato.
• Contact your CAS –administrator to obtain the correct settings of the ECMGs and the EMM streams.
NOTE! Since the spare IP settings are used by the backup device, ECMG redundancy is not possible in 1+1 backup
context.
To learn more about the ECMG settings, see chapter “ECM generator
configuration”.

The Luminato 1+1 Backup system has two main functions:
1. To handle a device failure in the chassis or one of its modules.

2. To provide a signal backup in case of a critical signal loss.
Under normal circumstances (no backup handover triggering event detected), the Main chassis is active and the Backup
chassis passive. In case of a failure, all the functions of the primary chassis are switched over to the secondary chassis:
Main becomes passive and Backup turns active. Recovery from a handover must always be done manually even if
failure/signal loss situation would be resolved. If necessary you may switch over manually in either direction: from main to
backup and vice versa.
Starting from Luminato SW 6.2.X, the 1 + 1 Backup scheme features 1 + 1 device IP pairing for configuration
synchronization and easy device control over IP. In normal usage, the main device is active and configuration
modifications are done to this device. After configuration is done, you may synchronize the configuration of the active
main device to the passive backup device. The synchronization is performed through an IP connection using one of the
1
MGMT port. Once synchronized, the 1 + 1 backup system setup is ready.
When DVB-CSA scrambling is used in conjunction with the 1 + 1 Backup scheme, two ECMGs are required: one for the
main device and the other for the backup device. Both devices will be connected to the ECMGs, regardless of their current
state, active or passive.
For more information on CAS in 1 + 1 backup environment, see chapter “CAS”
Device activity can be changed manually either from the main or backup device by the Handover/Recover button. Active
state means all the outputs are switched on and passive switched off.
1
Only MGMT1 is supported
312
8.3.2.1 C HASSIS ROLES IN 1 + 1 BACKUP SYSTEMS
There are four Chassis roles available in a 1+1 Backup system:
• Disabled: The chassis is working as a backup device, but the heartbeat monitoring of the main device is inactive.
All outputs are switched off, which means that all changes made in the device configuration won’t be visible on
the live network.
• Main: The chassis is working as an active main unit in the 1+1 Backup configuration, the output status depends on
the current chassis’ state (active/passive). The main ECMG is connected to this device.
• Backup: The chassis is working as a passive backup unit in the 1+1 Backup configuration, ready to take control on
main device’s request or if the connection with the main device is lost, the output status depends on the chassis
state (active/passive). The spare ECMG is connected to this device.
• Standalone: The chassis is working as a standalone unit without any active 1+1 backup configuration. All outputs
are switched on, which means that all changes made in the device configuration will be visible on the live
network. Both the main and spare ECMGs are connected to this device. Connection failure to the main ECMG will
switch to the spare ECMG.
8.3.2.2 H ANDOVERS
Handovers can be divided into two categories depending on whether the handover is controlled or not:
• Controlled handovers are triggered either manually or automatically as the result of a module failure or a
critical signal missing status code in the main chassis. The active main device disables its payload output ports and
hands over the control to the backup device, thus entering a passive state.
• Uncontrolled handover are triggered by a failure in the mainboard, rear I/O card or PSU of the main device,
causing the main device to be unable to do a controlled to handover backup device. Main device’s heartbeat
signal is lost. Backup device notices that and forces main device’s outputs offline. Backup device enables its own
outputs and becomes active device.
8.3.2.2.1 R EASONS FOR HANDOVER

There are 7 reasons when an active main device hands over the control to the backup device:
1. A manual handover request from the UI

2. Any Emergency, Alert or Critical status in system's status set
• Internal SW process that is running on the mainboard collects individual modules' (chassis is
handled as one module) status sets and forms the whole system's status set
• Examples of the possible reasons for Emergency, Alert or Critical status:
o The temperature is beyond the critical temperature limits
o A HW failure
o A fan failure
o The voltage or current is outside critical limits (action depends on whether a backup PSU is
in use or not)
o SW daemon initialization fails
o A device driver failure
o A module boot fails
o A connection to a module lost
313
o An incompatible module inserted into chassis.
o An unrecognized module inserted into chassis.
o Single SW process restart for selected processes
 Single SW process restart raises alert status if it causes a break in output services
that is expected to be longer than the delay caused by a switchover to the backup
o A repeated SW process restart
3. A local DXI communication failure within the chassis
• Three consecutive failures in reading the system's status set
o Assumption is made that the internal messaging do not work and the system is in an
unstable state
4. A module is inserted and it is booted up
• Handover is done when a module has booted up and is registered to system setup, i.e. a module
type has been recognized and internal messages are sent to/from module
5. A module is removed
6. A critical signal missing status is active
7. A fail of critical signal redundancy
There are 2 reasons when a passive backup device takes over control of the active main device:
1. Manual take over request from UI

2. Heart beat signal is missing.
NOTE! Losing connection to an ECMG will not trigger a handover to the backup device. In this case, you have two
options: investigate and re-establish the connection to the ECMG, or manually switch over to the backup device. Make
sure the spare ECMG connection is up and running before doing so!
8.3.2.3 1+1 BACKUP AND EIT PROCESSING MODULES

Only the EIT processing module in the active device will configure input streams for EPG information reception.
Only the EIT processing module in the active device will create routing for output streams and the output streams are
routed to both active and passive output modules.
The EPG database is synchronized from active to passive device once per day.
8.3.3 SETTING UP THE 1 + 1 BACKUP SYSTEM

First, we will introduce the 1+1 backup configuration commands. Then, we will describe the recommended configuration
steps to successfully set up a fully functional 1+1 backup system.
Caution! If internal IP inputs in modulators are defined as critical IP inputs, they will prevent the execution of the
restore/handover procedure. Do not configure any IP inputs as critical signals, if they are system internal interface!
314
Caution! 1+1 backup will react immediately to the loss of critical signal even though stream redundancy would be
present and thus overriding it altogether.
See chapter Using 1+1 backup together with the Stream redundancy feature.
8.3.3.1 T HE COMMANDS
8.3.3.1.1 D EVICE ROLE

To define the role of the device in the 1+1 backup setup:
Syntax:
redundancy role {master|backup|disabled|standalone}
Keywords:

values
disabled The chassis is working as a backup device, but the heartbeat monitoring of the main device is -
inactive. All outputs are switched off, which means that all changes made in the device
configuration won’t be visible on the live network.
master The chassis is working as an active main unit in the 1+1 Backup configuration, the output -
status depends on the current chassis’ state (active/passive). The main ECMG is connected to
this device.
backup The chassis is working as a passive backup unit in the 1+1 Backup configuration, ready to -
take control on main device’s request or if the connection with the main device is lost, the
output status depends on the chassis state (active/passive). The spare ECMG is connected to
this device.
standalone The chassis is working as a standalone unit without any active 1+1 backup configuration. All -
outputs are switched on, which means that all changes made in the device configuration will
be visible on the live network. Both the main and spare ECMGs are connected to this device.
Connection failure to the main ECMG will switch to the spare ECMG.
8.3.3.1.2 D EVICE PAIRING

To define the redundancy pair’s IP address:
Syntax:
redundancy pair address <ip_address>
315
Argument:

ip_address The management IP address of the target device pair. IPv4 address in dot-decimal notation
8.3.3.1.3 E NABLING / DISABLING BACKUP CONTROL OVER IP

To enable or disable backup device control over IP:
Syntax:
redundancy connection {off|manual-sync}
Argument:

values
off The IP connection to the redundancy paired device is disabled.
manual- The IP connection to the redundancy paired device is enabled and manual configuration
sync synchronization is possible.
8.3.3.1.4 S YNCHRONIZING CONFIGURATIONS

To initiate configuration synchronization from active to passive device:
Syntax:
redundancy do synchronize
NOTE! Synchronization is always done from active to passive device!
NOTE! Since synchronization requires a reboot of the passive device, it can take several minutes before the
synchronization process is over.
8.3.3.1.5 A BORTING SYNCHRONIZATION PROCESS

To interrupt an ongoing configuration synchronization:
Syntax:
redundancy do abort-synchronize
8.3.3.1.6 M ANUALLY ACTIVATING THE PAIRED DEVICE

To manually activate the passive paired device:
316
Syntax:
redundancy do handover
8.3.3.1.7 R ECOVERING BACK FROM BACKUP DEVICE TO THE MAIN DEVICE

To recover back from the backup device to the main device:
Syntax:
redundancy do recovery
NOTE! If backup control over IP is disabled, you must first manually activate the passive the main device and then,
within a 5 second window, use the ‘redundancy do recovery’ command.
8.3.3.1.8 V IEWING 1+1 BACKUP STATUS AND CONFIGURATION

To view the 1+1 backup configuration and status:
Syntax:
show redundancy
8.3.3.2 1+1 B ACKUP CONTROL OVER IP – C ONFIGURATION PROCEDURE

Be sure you have two identical chassis setups with 1 + 1 Backup licenses and GOE (Global Output Enable) support.
For more information on HW requirements, refer to chapter “Hardware”.
For more information about acquiring and managing licenses, see chapter
“License management”.
Connect the LACCB cable (length between the EXT I/O connectors of both devices. These connectors are located in the
PSU (Figure 54). If the devices are too far apart from each other, you may use the LACCA cable (length 2 m) (the cable
must be cross-connected as in Figure 53).
317
EXT 1 EXT 2 DC IN
Luminato 1 EXT
IO connector
EXT 1 EXT 2 DC IN
Luminato 2 EXT
IO connector
FIGURE 36: INTERCONNECTING 1+1 DEVICE PAIRS WITH THE LACCA CABLE.
To learn more about external inputs and outputs, EXT1 and EXT2, see chapter
Error! Reference source not found..
FIGURE 37: THE MAIN AND BACKUP DEVICES ARE CONNECTED WITH LACCB CABLES FOR 1 + 1 BACKUP SYSTEM’S HEARTBEAT DETECTION THROUGH
EXT IO CONNECTORS
Set each device’s role, master to one and backup to the other.
Example – setting master device:
Lumimato3# configure redundancy role master

Lumimato3(configure)#
Disable the Backup control over IP functionality on both devices. Disabling temporarily this feature ensures that no
unintended IP traffic will occur during the configuration procedure.
Example – disabling backup control over IP functionality on master device:
318
Lumimato3(configure)# redundancy connection off
FIGURE 38: THE CHASSIS ROLE HAS BEEN SET TO MASTER AND BACKUP CONTROL OVER IP HAS BEEN DISABLED.
Fully configure (interface, service, content protection etc.) the (active) master device.
1
Once all configuration done, pair up the master and backup devices by providing the paired device’s MGMT IP address on
both devices.
Example – pairing up the devices:
Master device (172.31.100.92):
Lumimato3(configure)# redundancy pair address 172.31.100.93

Backup device (172.31.100.93):
B-Mato3(configure)# redundancy pair address 172.31.100.92

B-Mato3(configure)#
Now, enable the Backup control over IP –functionality on both devices.
Example – enabling backup control over IP functionality on master device:
Lumimato3(configure)# redundancy connection manual-sync

The master device will now build an IP connection between both devices.
1
Only MGMT1 is supported in release version 6.2.X.
319
FIGURE 39: BUILDING CONNECTION
Next, the compatibility of the paired devices is tested. If this test fails, the synchronization feature of the Main and Backup
devices won’t be available and a warning flag will be raised specifying the reason of failure. You must resolve the ultimate
cause of incompatibility in order to proceed.
FIGURE 40: SW VERSION COMPATIBILITY TEST HAS FAILED; UPGRADE THE SW TO THE SAME RELEASE VERSION.
NOTE! A HW incompatible flag might also be due to a device reboot during configuration synchronization.
320
FIGURE 41: AN IP ONNECTION HAS BEEN ESTABLISHED AND THE COMPATIBILITY TEST HAS PASSED
Once an IP connection has been established and the compatibility test has passed, the configuration may be synchronized.
Example – synchronizing configurations:
B-Mato3(configure)# redundancy do synchronize

B-Mato3(configure)#
NOTE! Synchronization is always done from active to passive device! If necessary, press the Handover to… or Recover
from… button to activate correct device before synchronization.
There are a few seconds to abort synchronization sequence before the passive device will reboot with the new
synchronized configuration.
Once synchronized, the 1+1 Backup system should be in normal state where the Main device is active (output ports are
streaming the network) and Backup device is passive (monitoring Main device with its output ports disabled).
321
NOTE! Since synchronization requires a reboot of the passive device, it can take several minutes before the
synchronization process is over.
8.3.4 RECOVERING BACK FROM THE BACKUP DEVICE TO THE MASTER DEVICE
When a handover to the backup device has occurred and you wish to recover back to the main device, first ensure that
you have removed the cause of failure and that the main device is ready.
NOTE! Remember that if you have replaced a module in the main chassis, it must be identical to the original and its
peer module in the backup device!
To learn more about the hardware requirements, refer to chapter Hardware
There are two distinct procedures depending on whether the backup control over IP feature is enabled or disabled:
1. Backup control over IP is enabled :

• use the redundancy do recovery command in the master (passive) device
OR
• use the redundancy do handover command in the backup (active) device
2. Backup control over IP is disabled :
1. open up a CLI session on both device with the terminal windows side by side
2. Type in the backup (active) device’s CLI terminal redundancy do handover WITHOUT pressing the
enter key at the end of the command-line.
3. Type in the master device’s CLI terminal redundancy do recovery and press return key at the end
of the command-line.
322
4. Within five seconds (from the previous step), press the return key in the backup device’s CLI terminal.
Failing to comply will result in no recovery from slave to master device and you will have to repeat the
procedure from the start.
The 1+1 Backup system should now be in normal state where the main device is active (output ports are streaming to the
network) and backup device is passive (monitoring the master device with its output ports disabled).
8.3.5 RECONFIGURING THE ACTIVE 1+1 BACKUP SYSTEM

When you need to add or remove modules or change configuration in the active 1 + 1 backup system with minimal impact
the on-going live service broadcasting, follow the procedure below.
• Ensure the backup device is ready for taking over the control.
• Hand over the control manually to the backup device.
• The 1+1 Backup system should now be in a state where the main device is passive with its output
ports disabled and the backup device active with its output ports streaming to the network.
• Insert or remove module(s) to the main device.
• If possible, it is highly recommended to test the main device in a test environment before
connecting it to the live network:
1. Connect cables to the test environment.
2. Select the Standalone device role (output ports are activated)
3. Set up the configuration and verify the functionality of the new configuration in the test
environment.
4. Switch the device role back to Master.
5. Reconnect the Master device’s cables back to the live network. It remains in the passive.
• Select the Disabled device role to the Backup device and Standalone to the Master device.
• Insert or remove module(s) to/from the Backup device according to what is present in modified
Master device. Remember that identical hardware and licenses are required in both devices!
• Wait until the modules have booted up in the backup device and select Master role to the master
device.
• Select Backup role to the backup device.
• If synchronization over IP is active and the compatibility tests have passed, you may use the
redundancy do synchronize command.
• 1+1 Backup system should now be in normal state where the master device’s output ports are
streaming to the network and the backup device is monitoring the master device with its output
ports disabled.
8.3.6 USING LUMINATO 1+1 BACKUP FOR SIGNAL REDUNDANCY

The 1+1 Backup feature is mainly targeted as a hardware backup. However, it can be configured for signal redundancy as
well. If both, master and backup, chassis have same signal source, this does not normally make much sense, as in that case
the 1+1 Backup only backs up cable fault between signal source and receiver module. However, if the signal source is
duplicated, for example with a redundant satellite dish, 1+1 Backup can automatically switch to the redundant signal
source in case of a LNB failure in the main dish.
The Luminato’s stream redundancy feature offers possibilities for more sophisticated signal redundancy configuration.
323
8.3.6.1 C ONFIGURING CRITICAL SIGNAL INPUT
Signal redundancy in 1+1 backup configuration can be achieved by setting the signal as critical. The 1+1 backup feature
reacts to loss of critical input signal, but does not react to loss of individual services.
To configure a signal input as critical, see chapter “Emphasizing missing input

signals in status reports”
8.3.6.2 S IGNAL LOST CRITERIA

The 1+1 Backup and stream redundancy features share a common set of criteria for Signal lost condition. The signal is
interpreted as lost if the bitrate is below (or equal to zero if threshold value is zero) the user specified Signal lost threshold
for the time defined in the input Warning timeout setting. Both parameters are module specific; inputs within a single
module cannot have different threshold or timeout values.
The sensitivity to signal loss can be adjusted by using these parameters. The most sensitive setups are achieved if the
threshold bitrate is set close to input’s normal bitrate and timeout is set close to zero. Similarly, to prevent switchover to
backup chassis due to temporary changes, e.g., due to weather dependent reception conditions, one should set the
threshold bitrate to zero and increase the timeout to a value that is sufficiently long compared to temporary changes in
reception conditions.
8.3.6.2.1 M ODULE LEVEL SIGNAL LOST WARNING THRESHOLD

To set the input interface’s module level signal lost warning threshold (in kbit/s):
Syntax:
configure interface <slot_number> signal-lost-threshold {0…400000}
Argument:

8.3.6.2.2 I NTERFACE LEVEL SIGNAL LOST THRESHOLD OVERRIDE

Sometimes, the input signal bandwidth requirements varies greatly between inputs of the same module and one single
module level signal lost threshold value will not suffice. For instance, TV services and radio services have totally different
bandwidth comsumptions; for example, setting the signal lost threshold according to TV services would cause everlasting
signal missing status for low bitrate services (e.g. EIT and radio services) and would trigger unnecessarily redundancy
streaming. To overcome this problem, you may override the module level signal lost threshold at input interface level.
To override the module level signal lost threshold at a specific input interface:
Syntax:
configure interface <slot_number>/<connector_index>.<stream_index> signal-lost-threshold

{0…400000}
To remove the input interface level signal lost warning threshold override:
324
Syntax:
configure interface <slot_number>/<connector_index>.<stream_index> no signal-lost-

threshold
8.3.6.2.3 S IGNAL LOST WARNING TIMEOUT

To set the signal loss warning timeout (in seconds):
Syntax:
configure interface <slot_number> timeout warning {1…99}
Argument:

8.3.7 USING 1+1 BACKUP TOGETHER WITH THE STREAM REDUNDANCY FEATURE
When the 1+1 Backup feature is used together with the Stream redundancy feature, individual input signals should not be
1
configured as critical . If this is done, the 1+1 Backup feature will override the Stream redundancy feature and a
switchover to backup chassis is done before redundant signals are checked.
Instead, you should define the redundant stream to as critical. In this case, if primary stream is lost, redundant streams are
checked first before switching over to backup chassis. If none of the defined redundant streams are present and the
redundant stream is set as critical, the 1+1 Backup feature will hand over the control to the backup chassis.
1
Critical input setting is enabled by default
325
9 EXTERNAL INPUTS AND OUTPUTS – EXT1 & EXT2
Luminato features external multipurpose I/O-pins, EXT1 & EXT2, for several factory or user defined applications. These
pins are located in the PSU/interface module.
The aforementioned applications are:
• backup power supply alarm monitoring

• intrusion alert to detect external closed-circuit disconnection
• user configurable inputs to monitor external signal change
• user configurable outputs to drive external relay
• 1+1 chassis redundancy heartbeat monitoring
9.1 CONFIGURING EXT1 AND EXT2 PINS OPERATING MODE

When 1+1 chassis redundancy is in use, both EXT1 and EXT2 I/O pins are reserved and therefore all other applications are
excluded. The 1+1 backup roles that prevent from using the EXT I/O pins for other applications are: main, backup and
disabled. You must choose Standalone role to enable any other EXT I/O applications.
NOTE! 1+1 Backup is a licensed feature, if you do not have this license, Standalone role will be the chassis’ default
role and the aforementioned backup roles won’t be accessible.
To set EXT I/O ports’ functional mode:
Syntax:
configure ext-io {ext1|ext2} mode {off|user-input|user-output|backup-power-alarm|intrusion-

alert|emergency}
9.2 BACKUP POWER ALARM

You can choose either EXT1 or EXT2 pin for backup power alarm signal detector. Any alarm signal sent to EXT I/O pin
connector by a Luminato backup PSU, LPS-F or LPS-G, is detected and an alarm status flag risen in the Monitor view. This
signal is also reported to the syslog and a SNMP trap sent. The status is cleared when the backup PSU clears the signal.
Connect a two-wire cable between backup power supply device and Luminato EXT1 or EXT2 connector
326
9.3 INTRUSION ALERT
Either or both connectors, EXT1 and EXT2, can be used as intrusion alert detectors. When this intrusion detection loop
breaks the alarm is set, this could be triggered by an opening door or window for example. Luminato detects when the
intrusion detection pin goes to high-Z state. Alarm status is set in the Luminato’s web UI Monitor view. A report to syslog
and an SNMP trap will be sent. This status will stay until removed manually from device by setting the EXT I/O ports’
functional mode to off.
9.4 USER DEFINED EXT I/O MODES

It is possible to build your own applications for the EXT I/O ports, to monitor external devices and get notified or alerted
about state changes, for example. It is also possible to control external devices manually from Luminato’s user-interface.
EXT I/O’s pin specification are:
• EXT1:
o Pin 1: Output voltage 19…19.7 V, max output current 50 mA. When using this pin as an output, short
circuiting to ground is prohibited! Input voltage 19…26V, input impedance 17 kΩ.
o Pin 2: Connected to ground.
327
• EXT2:
o Pin 3: Output voltage 19…19.7 V, max output current 50 mA. When using this pin as an output, short
circuiting to ground is prohibited! Input voltage 19…26V, input impedance 17 kΩ.
o Pin 4: Connected to ground.
NOTE! Luminato cannot set the I/O pins to high-Z state by itself.
9.4.1 USER INPUT MODE

When another device’s status is monitored in Luminato via signaling wires, this status will be reflected in Luminato’s Web
UI Monitor view and syslog messages or SNMP traps. Luminato can report if a signal is down or up or if its state has
changed. By default, the detected input signal status code is active for 10 seconds after the signal state is cleared.
To configure EXT I/O connector’s user input mode:
1. set EXT I/O ports’ functional mode to user-input

2. define the alert trigger criterion
3. define the alert severity
To define the alert trigger(s):
Syntax:
configure ext-io {ext1|ext2} user-input trigger {up|down|both}
Keywords:
Name Description
up signaling wire is pulled up
down signaling wire is set to high-Z
both signaling wire state changes
To define the alert severity:
Syntax:
configure ext-io {ext1|ext2} user-input severity

{information|notice|warning|error|critical|alert|emergency|debug}
NOTE! Only the three most severe alert levels (emergency, critical and alert) will generate an SNMP trap.
9.4.1.1 A USE CASE EXAMPLE

An air conditioning device in a remote site sets signal level to high-Z (down) when preferred temperature range is
exceeded. Connect a wire between the air conditioner and Luminato. Set the EXT I/O ports’ functional mode to user-
input and the alarm trigger to down. Additionally, set the alert severity level to alert to make sure that an SNMP trap is
328
sent from Luminato when the alarm conditions are met. SNMP monitoring is now able to detect any air conditioning
problems in the remote site.
9.4.2 USER OUTPUT MODE

User may control other nearby devices via Luminato CLI. By choosing the EXT I/O user output mode from Luminato, you
are able to control the signal level in the wire connected to an auxiliary device.
To configure the EXT I/O connector’s user output settings:
1. set EXT I/O ports’ functional mode to user-output

2. set the desired signal output state
To set user output driving mode:
Syntax:
configure ext-io {ext1|ext2} user-output {high-z|pullup}
9.4.2.1 A USE CASE EXAMPLE

The electronic lock of a server room unlocks when the signal wire is up and locks the door while signal wire is high-Z
(down). Connect wire between the electronic lock and Luminato. Set EXT I/O ports’ functional mode to user-output for
the connected EXT I/O pin. Test the electronic lock by changing the signal wires state from high-z to pullup, and from
pullup to high-z. Now you are able to control the server room door remotely via Luminato’s CLI.
9.4.3 EMERGENCY SIGNAL TRIGGER

This operating mode is for triggering emergency notification streaming in the output in-terfaces based on the state of the
signal wire connected to the target EXT I/O port. This mode uses the same connection as in the intrusion alert
configuration.
To enable the emergency signal trigger:
Syntax:
configure ext-io {ext1|ext2} mode emergency
To learn more about emergency notification streaming, refer to chapter 8.2
329
10 TECH SUPPORT FILE
Whenever contacting Technical support, you should generate a tech support file which provides essential information
about your current setup.
To generate a tech support file:
Syntax:
configure copy tech-support-file {<filename>|<URL>}
330
LEGAL DECLARATIONS
COPYRIGHT ACKNOWLEDGEMENTS
Copyright © 2014-2017 Teleste Corporation. All Rights Reserved.
Teleste is a registered trademark of Teleste Corporation. Other product and service marks are property of their respective
owners.
This document is protected by copyright laws. Unauthorized distribution or reproduction of this document is strictly
prohibited.
Teleste reserves the right to make changes to any of the products described in this document without notice and all
specifications are subject to change without notice. Current product specifications are stated in the latest versions of
detailed product specifications.
To the maximum extent permitted by applicable law, under no circumstances shall Teleste be responsible for any loss of
data or income or any special, incidental, consequential or indirect damages howsoever caused.
The contents of this document are provided "as is". Except as required by applicable law, no warranties of any kind, either
express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular
purpose, are made in relation to the accuracy, reliability or contents of this document.
Teleste reserves the right to revise this document or withdraw it at any time without notice.
Teleste Corporation
P.O. Box 323
FI-20101 Turku
FINLAND
www.teleste.com
331

Manual CLI

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual CLI

Uploaded by

Copyright:

Available Formats

CLI MANUAL

1.2 APPLICATION EXAMPLES 29

2 ABOUT THE CLI 31

2.2 CLI DOCUMENT CONVENTIONS 31

2.3 COMMAND MODES AND GROUPS 32

2.3.1 ENTERING AND EXITING COMMAND MODES 32

2.3.2 COMMAND GROUPS 33

2.4 CONTEXT SENSITIVE HELP AND COMMAND COMPLETION 34

2.4.1 TAB KEY 35

2.4.2 QUESTION MARK 36

2.5 CLI COMMAND-LINE EDITOR 37

2.6 ‘NO’ KEYWORD 38

2.7 KNOWN ISSUES 38

3 PREPARING FOR SYSTEM CONFIGURATION 39

4.2 RESERVED PORTS & ADDRESSES 40

4.3.1 TFTP SERVER INSTALLATION 40

4.4 MANAGEMENT INTERFACE IP SETTINGS 41

4.4.1.2 Network mask 41

4.4.1.5 Static routing 42

4.4.2.1 Management port operating mode 43

4.4.2.1.1 Separate MGMT networks in older chassis 43

4.4.2.3 IP address, netmask & default gateway 44

4.4.2.4 Default gateway 45

4.4.2.5 Static route 45

4.4.2.6 Enabling/Disabling the management interfaces 46

4.4.2.7 Viewing the IP settings 47

4.4.3 NETWORKING UTILITIES 48

4.6 TIME AND DATE 50

4.6.1 VIEWING CURRENT TIME AND DATE 50

4.6.2 VIEWING TIME AND DATE SETTINGS 50

4.6.3.1 Selecting clock source type 51

4.6.3.2 Internal clock source 51

4.6.3.2.1 Time zone 52

4.6.3.3 Custom daylight saving time 52

4.6.3.3.1 DST time period 53

4.6.3.3.2 DST offset 53

4.6.3.3.3 Enabling/disabling custom DST 53

4.6.3.4 External clock source 54

4.6.3.4.1 About the NTP 54

4.6.3.4.2 Adding NTP servers 54

4.6.3.4.3 Removing NTP servers 55

4.6.3.4.4 Monitoring NTP configuration 55

4.7 TERMINAL SETTINGS 55

4.7.1 CONFIGURATION MODE 55

4.7.2 SHOW SETTINGS 56

4.7.3 SCREEN LENGTH 56

4.7.4 SESSION TIMEOUT 57

4.7.5 COLOUR USAGE 57

4.8 USER MANAGEMENT 57

4.8.2 MANAGING LOCAL USER ACCOUNTS 58

4.8.2.1 Viewing all registered user accounts 58

4.8.2.2 User account creation 59

4.8.2.3 Changing password 59

4.8.2.3.1 Current user 59

4.8.2.3.2 Specific user 60

4.8.2.4 Removing a user account 60

4.8.3 LDAP REMOTE USER LOGIN AUTHENTICATION 60

4.8.3.1.2 Search parameters 63

4.8.3.1.3 Testing user login 66

4.8.3.1.4 Viewing LDAP configuration 66

4.9 REBOOT COMMANDS 67

4.9.1 SYSTEM REBOOT 67

4.9.2 MODULE REBOOT 67

4.10 LOG SETTINGS 67