SATLIFE-IST-1-507675
D311
DVB-RCS system and subsystem design
Contractual Date of Delivery to the CEC:01/04/05
Actual Date of Delivery to the CEC:
Author(s):
25/05/05
A. Yun, I. Moreno, F. Vallejo, J.L. Casas, Juan R. López, José A. Torrijos, Antonio
Sánchez, Sigbjørn Næss, Gaël Jahan, Andrey Shkinev, V. Huertas, M. Rodriguez,
Thierry Filoche, Thierry Quignon, David Douglas, Avi Barda.
Participant(s): AAS-E, HSA, AAS-F, NERA, EMS, SHIRON, THA, INDRA, UoS, UPM
Workpackage: WP3100
Est. person months:
82.5
Security:
Pub.
Nature:
R
Version:
Issue 2.0 draft
Total number of pages: 266
Abstract:
This document provides a description of the system and subsystem designs of the DVB RCS satellite network
for SatLife. It includes the Regenerative and Transparent equipment needed by the new SatLife services and
by the different enhancements.
Throughout the document it can be seen the approaches taken by the different manufacturers to build their
subsystems as a result of the requirements described in DE220 and mainly the DE230.
New terminal types, quality of service handling, multicast enhancements, new Internet protocols or video
transmission are some of the features which have a direct impact on the design issues described in this
document. This will also enable the support of other high level applications defined in DE321
Keyword list: DVB-RCS, Satellite network, Multimedia, Broadcasting, Interactive services, Video
on Demand, System Design, Subsystem development
AEO-005479
SATLIFE
D311
CHANGE RECORD
VERSION DATE
Draft v1
Draft v2
AUTHOR
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
2 / 266
CHANGE
SATLIFE PARTNERS
(AEO, HSA, ASP, THA,
25/04/2005
First version
EMS, NERA, SHIRON,
INDRA)
Thales contribution
19/04/2005 SATLIFE PARTNERS
Update of the document
Draft v3
21/04/2005
SATLIFE PARTNERS
ASP update
Issue 1.0
29/04/2005
SATLIFE PARTNERS
Delivery to EC
Issue 2.0
draft
21/02/2006
SATLIFE PARTNERS
17/05/2006
SATLIFE PARTNERS
14/09/2006
SATLIFE PARTNERS
TID contribution
UoS contribution
NERA contribution
UPM contribution
NERA update in Transparent System design.
ANNEX D revised.
Justifications added.
AAS-F update.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
3 / 266
TABLE OF CONTENTS
1.
EXECUTIVE SUMMARY........................................................................................12
2.
REFERENCES...........................................................................................................13
3.
ABBREVIATIONS ....................................................................................................16
4.
DOCUMENT OVERVIEW ......................................................................................20
5.
GENERAL SYSTEM DESIGN ................................................................................21
5.1 INTRODUCTION .........................................................................................................21
5.2 REGENERATIVE SYSTEM DESIGN ..............................................................................21
5.2.1 OBP Design......................................................................................................22
5.3 TRANSPARENT SYSTEM DESIGN ................................................................................28
5.3.1 Introduction to DVB RCS and Nera SatLINK system ......................................28
5.3.2 Nera DVB RCS solution - the SatLink system..................................................29
6.
REGENERATIVE NCC DESIGN ...........................................................................39
6.1 AMERHIS NCC DESIGN.............................................................................................39
6.1.1 NCC Functional description ............................................................................39
6.1.2 NCC architecture .............................................................................................41
6.2 IMPLEMENTATION OF NEW FUNCTIONS......................................................................43
6.2.1 Service Provider Terminal handling................................................................43
6.2.2 Multicast routes and routes for VSP ................................................................52
7.
TRANSPARENT HUB DESIGN..............................................................................62
7.1 OVERVIEW OF THE SATLINK GATEWAY ARCHITECTURE ..........................................62
7.2 FORWARD LINK SUBSYSTEM.....................................................................................63
7.2.1 Forward Link Subsystem components and integration....................................64
7.3 RETURN LINK SUBSYSTEM ........................................................................................65
7.3.1 Return Link Subsystem architecture ................................................................65
7.3.2 DVB-RCS Return Channel - Demodulator ......................................................68
7.4 REFERENCE AND SYNCHRONIZATION SUBSYSTEM ....................................................68
7.5 NETWORK CONTROL CENTER SUBSYSTEM...............................................................68
7.5.1 SI table generation ...........................................................................................69
7.5.2 Traffic session handling ...................................................................................70
7.5.3 Radio Resource Management ..........................................................................70
7.6 NETWORK MANAGEMENT SUBSYSTEM .....................................................................73
7.6.1 Network management.......................................................................................73
7.6.2 Terminal (Subscriber) management.................................................................74
7.6.3 Station management.........................................................................................76
7.7 SATLINK GATEWAY REDUNDANCY ARCHITECTURE .................................................77
7.8 CENTRALIZED NMS..................................................................................................78
7.8.1 Introduction......................................................................................................78
AEO-005479
SATLIFE
D311
7.8.2
8.
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
4 / 266
Design description ...........................................................................................79
NERA USER TERMINAL DESIGN .......................................................................90
8.1 ACTIVE IP QUEUE MANAGEMENT ............................................................................90
8.1.1 Introduction......................................................................................................90
8.1.2 Background ......................................................................................................91
8.1.3 System Description...........................................................................................94
8.2 QUEUE STRUCTURES AND TRAFFIC CLASSES ............................................................99
8.2.1 Scope ................................................................................................................99
8.2.2 Introduction......................................................................................................99
8.2.3 DVB-RCS Definitions.....................................................................................100
8.2.4 Non-Requested Capacity................................................................................101
8.2.5 Requested Capacity........................................................................................101
8.2.6 Algorithms for request and assignment .........................................................103
8.2.7 Support of DiffServ ........................................................................................103
8.2.8 traffic classes .................................................................................................104
8.2.9 Conclusion .....................................................................................................105
9.
EMS USER TERMINAL ........................................................................................107
9.1 INTRODUCTION .......................................................................................................107
9.2 REGULATORY REQUIREMENTS ................................................................................107
9.3 DESIGN CONSIDERATIONS .......................................................................................108
9.4 NOMADIC TERMINAL DESIGN SPECIFICATION.........................................................110
9.4.1 Safety Requirement ........................................................................................110
9.4.2 EMC Requirement..........................................................................................110
9.4.3 Terminal Equipment.......................................................................................110
9.4.4 Vehicle Mounted ODU...................................................................................110
9.4.5 Indoor Unit Subsystems Description .............................................................115
9.4.6 Service Operator ............................................................................................118
9.5 OPERATION OVER AMAZONAS ................................................................................118
9.6 LINK BUDGET CALCULATIONS ................................................................................118
9.6.1 Terminal Deployment.....................................................................................118
9.6.2 HISPASAT......................................................................................................119
9.7 CONCLUSSIONS .......................................................................................................125
10. SERVICE PROVIDER DESIGN ...........................................................................125
10.1 INTRODUCTION ...................................................................................................125
10.2 TRANSMISSION SYSTEM OVERVIEW .....................................................................126
10.3 MULTIPLEXER .....................................................................................................128
10.4 INPUTS ................................................................................................................129
10.4.1 IP Frame Input...............................................................................................129
10.4.2 Live input .......................................................................................................129
10.4.3 MPEG2 and H264 video Transport Stream packets file ...............................130
10.5 SUPERVISION.......................................................................................................131
10.6 OUTPUTS .............................................................................................................131
10.7 MULTIPLEXING ...................................................................................................135
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
5 / 266
10.8 OPENMUX® KERNEL ........................................................................................136
10.8.1 Principle.........................................................................................................138
10.8.2 MPEG-2 – DVB SI Tables management ........................................................139
10.8.3 Hardware Configuration ...............................................................................139
10.8.4 File broadcasting ...........................................................................................139
10.8.5 MPEG-2/DVB Encapsulation And Signaling Protocols................................141
10.8.6 Supervision and Command ............................................................................144
10.9 SATLIFE EVOLUTION ...........................................................................................149
11. VIDEO MONITOR UNIT DESIGN ......................................................................150
11.1 MPEG-2 MONITOR MAIN FEATURES ..................................................................150
11.2 MPEG-2 MONITOR GLOBAL ARCHITECTURE .....................................................151
11.3 MPEG-2 MONITORING DESCRIPTION..................................................................151
11.3.1 Transport Stream monitoring ........................................................................152
11.3.2 Audio/Video monitoring.................................................................................155
11.3.3 Content monitoring ........................................................................................155
11.3.4 Transport Stream Capture .............................................................................156
11.4 H264 ANALYSIS .................................................................................................157
11.4.1 MPEG2 TS Capabilities.................................................................................158
11.4.2 H264/AVC capabilities ..................................................................................161
12. SERVICE PROVIDER TERMINAL DESIGN ....................................................163
12.1 PRODUCT OVERVIEW ..........................................................................................163
12.1.1 Physical Architecture.....................................................................................163
12.1.2 RCST IDU Description ..................................................................................164
12.1.3 SP-RCST Synchronization .............................................................................167
12.2 SP-RCST SOFTWARE DESIGN ............................................................................173
12.2.1 Software platform...........................................................................................173
12.2.2 Software Architecture ....................................................................................173
12.2.3 Subsystems Design .........................................................................................175
12.3 SP-RCST HARDWARE DESIGN ...........................................................................185
12.3.1 Data/Signaling block .....................................................................................186
12.3.2 Scrambler block .............................................................................................187
12.3.3 Channel coding block ....................................................................................187
12.3.4 Preamble block ..............................................................................................187
12.3.5 MUX block .....................................................................................................187
12.3.6 Shaping filter block ........................................................................................187
12.3.7 Timing block...................................................................................................187
12.3.8 M&C Block ....................................................................................................187
13. REGENERATIVE GATEWAY DESIGN.............................................................188
13.1 RSGW OVERVIEW..........................................................................................188
13.2 SUBSCRIBERS AND SERVICES ...................................................................189
13.2.1 Summary of AmerHis services .......................................................................189
13.2.2 New SatLife services ......................................................................................193
13.3 FUNCTIONAL ARCHITECTURE .............................................................................197
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
6 / 266
13.3.1 Overview ........................................................................................................197
13.3.2 Ground system ...............................................................................................198
13.3.3 Management subsystem .................................................................................199
13.4 PHYSICAL ARCHITECTURE ..................................................................................200
13.5 VOICE/VIDEO COMMUNICATIONS .......................................................................201
13.5.1 H.323 service .................................................................................................201
13.5.2 SIP service .....................................................................................................204
13.5.3 Dial Plan ........................................................................................................210
13.5.4 Call termination optimization for ISDN/PSTN voice/video calls ..................216
13.6 STATION MANAGEMENT AND OPERATIONS ........................................................221
13.6.1 GMM Architecture .........................................................................................221
13.6.2 RSGW Subscriber Management and Configuration Tool..............................222
13.6.3 Accounting .....................................................................................................227
13.6.4 Backup............................................................................................................228
13.6.5 Performance Management.............................................................................228
13.6.6 Fault Management .........................................................................................228
13.7 CONCLUSIONS .....................................................................................................229
14. SOFTPHONE ...........................................................................................................230
14.1 INTRODUCTION .............................................................................................230
14.1.1 Purpose ..........................................................................................................230
14.1.2 Related Documentation..................................................................................231
14.2 GENERAL DESCRIPTION..............................................................................231
14.2.1 System Introduction .......................................................................................231
14.2.2 High-Level Architecture.................................................................................231
14.3 COMPONENT DESCRIPTION........................................................................232
14.3.1 APPLICATION MAIN COMPONENTS.........................................................232
14.3.2 USER INTERFACE........................................................................................240
15. SNMP BASED DVB-RCS AUTHENTICATION PROTOCOL .........................241
15.1
15.2
NMC SIDE ..........................................................................................................243
RCST SIDE .........................................................................................................244
16. IMPLEMENTING IPV6 .........................................................................................246
17. CONCLUSIONS ......................................................................................................250
18. ANNEX A: TR 101-290 ...........................................................................................251
18.1
18.2
18.3
FIRST PRIORITY: NECESSARY FOR DE-CODABILITY (BASIC MONITORING)............251
SECOND PRIORITY: RECOMMENDED FOR CONTINUOUS OR PERIODIC MONITORING
252
H264/MPEG-4 AVC..........................................................................................254
19. ANNEX B: RED IMPLEMENTATION GUIDELINES......................................255
19.1
19.2
VERIFICATION .....................................................................................................257
CALCULATED DELAY MODEL (INACCURATE): .....................................................259
AEO-005479
SATLIFE
D311
19.3
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
7 / 266
FILTERING THE BW SAMPLING ...........................................................................260
20. ANNEX C: BURST FORMATS AND COMPOSITION.....................................261
21. ANNEX D: CHECKLIST OF SIMULATION FEEDBACK COMPLIANCE
AND FUTURE IMPROVEMENTS ...............................................................................263
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
8 / 266
LIST OF FIGURES
Figure 4-1 Elements Overview ..........................................................................................20
Figure 5-1 Global diagram of boards.................................................................................21
Figure 5-2 Global diagram of boards.................................................................................23
Figure 5-3 Example of MCDDD Functional Block Diagram) ............................................24
Figure 5-4 Functional overview of the BBP ........................................................................26
Figure 5-5 Packet bus interface at multiplexer level............................................................27
Figure 5-6 Packet bus interface at MC3D level...................................................................27
Figure 5-7 Transparent System ............................................................................................28
Figure 5-8 - Subnet on the RCST Ethernet side ..................................................................29
Figure 5-9 Recommended superframe - frame composition in the SatLink Gateway.........30
Figure 5-10 TCP Acceleration over satellite .......................................................................35
Figure 5-11 Nera SatLink Gateway VoIP Subsystem .........................................................37
Figure 6-1 NCC architecture and environment....................................................................43
Figure 2 - Typical SP-RCST Service Level Agreement ......................................................46
Figure 7-1 Nera SatLink Gateway - main components........................................................63
Figure 7-2 Forward-Link Subsystem Block Diagram..........................................................64
Figure 7-3 RLS system architecture ....................................................................................66
Figure 7-4 Picture of a RLS sub-rack ..................................................................................67
Figure 7-5 Example Redundant System..............................................................................77
Figure 7-6 NMS - Tier Model..............................................................................................79
Figure 7-7 NMS for DVB-RCS System Overview..............................................................80
Figure 7-8 DAS and RCH Interface.....................................................................................82
Figure 7-9 Web Component and RCH Interface .................................................................83
Figure 7-10 RCH Extending for Manual Triggered Procedures (RCH-WC) ......................84
Figure 8-1. The different buffer handling thresholds...........................................................95
Figure 8-2 Capacity Request Model ..................................................................................104
Figure 8-3 Traffic Classes..................................................................................................105
Figure 9-1: Nomadic Terminal Block Diagram.................................................................107
Figure 9-2: ODU Block Diagram.......................................................................................110
Figure 9-3: IDU Block Diagram ........................................................................................115
Figure 9-4 Hispasat 1D European Footprint ......................................................................119
Figure 9-5 Hispasat Amazonas European Footprint ..........................................................122
Figure 10-1 Service Provider unit......................................................................................126
Figure 10-2 Global Transmission System Diagram...........................................................127
Figure 10-3 Multiplexer architecture .................................................................................128
Figure 10-4 PIA + Board ...................................................................................................129
Figure 10-5 Example of architecture .................................................................................136
Figure 10-6 OpenMux Architecture...................................................................................137
Figure 10-7 OpenMux Multiplexing Principle ..................................................................138
Figure 10-8 File Broadcasting Architecture ......................................................................140
Figure 10-9 IP Encapsulation.............................................................................................141
Figure 10-10 Data Streaming Encapsulation .....................................................................142
Figure 10-11 Multi Protocol Encapsulation.......................................................................143
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
9 / 266
Figure 10-12 Optimized MPE............................................................................................143
Figure 10-13 Multiplexer Manager....................................................................................144
Figure 10-14 Multiplexer IP Inputs ...................................................................................145
Figure 10-15 Statistical View ............................................................................................145
Figure 10-16 Dynamic Bandwidth Allocation per channel ...............................................146
Figure 10-17 Hierarchical View of Services .....................................................................147
Figure 10-18 IP Input Definition .......................................................................................147
Figure 10-19 Definition of Input Filters ............................................................................148
Figure 11-1 Video Monitoring unit....................................................................................150
Figure 11-2 General architecture .......................................................................................151
Figure 11-3 TR101290 view (DVB mode) ........................................................................153
Figure 11-4 Structure view ................................................................................................154
Figure 11-5 Syntax export view.........................................................................................154
Figure 11-6 General monitoring View...............................................................................155
Figure 11-7 Program view .................................................................................................156
Figure 11-8 Automatic Transport Stream Capture ............................................................156
Figure 11-9 Manual Transport Stream Capture .................................................................157
Figure 11-10 H264 analyzer GUI overview ......................................................................158
Figure 11-11 H264 analyzer : PSI view............................................................................158
Figure 11-12 H264 analyzer : Report view.......................................................................159
Figure 11-13 TR 101 290 Priority 1 ................................................................................159
Figure 11-14 TR 101 290 Priority 1 .................................................................................160
Figure 12-1 Video Service Provider Station ......................................................................163
Figure 12-2 SP-RCST Context ..........................................................................................164
Figure 12-3 SP-RCST IDU functional Breakdown ...........................................................165
Figure 12-4 User plane protocol stack ...............................................................................166
Figure 12-5 Control Plane protocol stack ..........................................................................166
Figure 12-6 Local Management plane protocol stack........................................................167
Figure 12-7 Remote Management plane protocol stack ....................................................167
Figure 12-8 SYNC burst IE ...............................................................................................169
Figure 12-9 SYNC MPEG packet format .........................................................................170
Figure 12-10 Multi-Channel Transmission on SP-RCST ..................................................172
Figure 12-11 SP-RCST Software Architecture..................................................................174
Figure 12-12 SP RCST Controller internals .....................................................................176
Figure 12-13 SP/SP-RCST signaling handshake ..............................................................178
Figure 12-14 SpSAL internals ...........................................................................................179
Figure 12-15 Signaling internals.......................................................................................181
Figure 12-16 Physical Layer internals ..............................................................................182
Figure 12-17 Internals of the Physical Layer Controller ...................................................183
Figure 12-18 SP RCST Management Plane.......................................................................185
Figure 12-19 SP-RCST Hardware Design .........................................................................186
Figure 13-1 Context of the SatLife return Channel Satellite Gateway .............................188
Figure 13-2 Internet Access Service ..................................................................................190
Figure 13-3 Intranet Access Service .................................................................................190
Figure 13-4 H.323 based Voice and Video Internetworking Service ................................192
Figure 13-5 Multicast Service............................................................................................192
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
10 / 266
Figure 13-6 SIP Voice Call to ISDN/PSTN.......................................................................194
Figure 13-7 SIP Voice/Video Calls to Internet SIP endopoints ........................................194
Figure 13-8 Voice/Video Calls between SatLife SIP Terminals .......................................195
Figure 13-9 H.323 Voice/Video Call Termination Optimization ......................................196
Figure 13-10 RSGW Subsystem Breakdown....................................................................197
Figure 13-11 RSGW-GS Elements ....................................................................................198
Figure 13-12 Management Modules ..................................................................................199
Figure 13-13 RSGW Physical Architecture......................................................................201
Figure 13-14 Outgoing Internet Call in GK Proxy Mode..................................................203
Figure 13-15 Internal H.323 Call.......................................................................................203
Figure 13-16 Non Record Routed Mode ...........................................................................205
Figure 13-17 Record Routed Mode ...................................................................................206
Figure 13-18 Symmetric Signaling Call Set-up.................................................................209
Figure 13-19 Symmetric Signaling Call Release...............................................................210
Figure 13-20 Optimized Call Termination Example .........................................................217
Figure 13-21 RSGW – ITSP Interworking ........................................................................218
Figure 13-22 Message Exchange between the RSGW and an external ITSP....................219
Figure 13-23 GMM Functional Architecture.....................................................................222
Figure 13-24 RSGW Configuration Tool ..........................................................................224
Figure 13-25 RSGW Subscriber Management Tool Main Screen ....................................226
Figure 13-26 Subscriber Edition/Adition Interface ...........................................................227
Figure 14-1: Multiprotocol Softphone High-Level Architecture.......................................232
Figure 14-2: Multiprotocol Softphone Components..........................................................233
Figure 14-3: OpenH323 Component..................................................................................234
Figure 14-4: SIP/SIMPLE Component ..............................................................................235
Figure 14-5: Addins Architecture ......................................................................................236
Figure 14-6: XMPP Component ........................................................................................237
Figure 14-7: Configuration Component.............................................................................237
Figure 14-8: Agenda Component.......................................................................................238
Figure 14-9: File Transfer Component ..............................................................................238
Figure 14-10: Event Management......................................................................................239
Figure 14-11: Statistics Management ................................................................................239
Figure 14-12: USB Handsets Component..........................................................................240
Figure 14-13: User Interface Components.........................................................................241
Figure 15-1: Flow Diagram of the QKE Authentication protocol .....................................241
Figure 15-2: Amerhis-RCST MIB file in each RCST .......................................................243
Figure 15-3: NMC flowchart during the sending of the QKE protocol using SNMP .......244
Figure 15-4: RCST flowchart of the QKE protocol using SNMP .....................................245
Figure 16-1: Testbed Diagram ...........................................................................................246
Figure 16-2: IPv4 and IPv6 Scenario................................................................................247
Figure 16-3: End to End delay in IPv4 network scenario ..................................................248
Figure 16-4: End to End delay difference in IPv4-IPv6 networks.....................................249
Figure 19-1: Efficient algorithm for RED gateways..........................................................257
Figure 19-2 Transient response of the assigned bw filter. .................................................260
Figure 20-1 Burst carrying ATM cells...............................................................................261
Figure 20-2 Composition of a traffic MPEG2 bursts in EN 301 790 [2]...........................261
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
11 / 266
Figure 20-3 Composition of a SYNC burst, from Fig. 7, EN 301 790 [2]. ......................262
Figure 20-4 Composition of an ACQ burst, from Fig. 8, EN 301 790 [2].........................262
Figure 20-5 Composition of a CSC burst, from Fig. 9, EN 301 790 [2]. ..........................262
LIST OF TABLES
Table 6-1 PIDs defined by the standard...............................................................................57
Table 6-2 PAT structure.......................................................................................................58
Table 8-1 Packet delay caused by 3 TCP connections at culmination, sharing a DT
gateway. .......................................................................................................................90
Table 8-2 Additional packet delay caused by buffer filling for MS W2K, at culmination. 92
Table 13-1 SIP Service ......................................................................................................211
Table 13-2 Monitored GK/SIP Proxy Server Parameters..................................................229
Table 15-1: QKE and QKE Response message structures ................................................242
Table 18-1: TR 101 290 Priority 1....................................................................................251
Table 18-2: TR 101 290 Priority 2.....................................................................................253
Table 19-1 Estimated characteristics of RED drop............................................................259
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
12 / 266
1. EXECUTIVE SUMMARY
DE220 and DE230 identify the requirements that impact on the different subsystems of
SatLife and conform the inputs used by the different partners to make their internal design.
In the case of the regenerative system, IBIS and AmerHis designs are taken as a baseline
and SatLife introduces the logical evolution to be able to support all the services and
applications described in DE210.
The transparent system is also adapted to accomplish all the requirements applicable in its
domain. In fact the convergence of the design between the elements in common is foreseen
(the RCS terminals).
The contributions done by all the partners included in this document represent a real state
of the art of the design of satellite systems facing new services and applications. This
deliverable includes all the detail designs of each subsystem SatLife prototype.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
13 / 266
2. REFERENCES
[1] D210, DVB-RCS, Regenerative (and Transparent) System Services Requirements
Report.
[2] D220, DVB-RCS, Regenerative (and Transparent) Network Aspects Report.
[3] D230, DVB-RCS, Regenerative (and Transparent) System Technology and Subsystems
Requirements Report
[4] ETSI TR 102 157
[5] ETSI EN 300 468 Digital Video Broadcast (DVB); Specification for Service
Information (SI) en DVB systems. V1.3.1
[6] ETSI EN 301 790, Digital Video Broadcast (DVB); Interaction Channel for satellite
distribution systems. V1.3.1
[7] ETSI TS 102 812, Digital Video Broadcast (DVB); Multimedia Home Platform (MHP)
Specification 1.1.1.
[8] IEEE 802.1ac, Media Access Control (MAC) Services Definition
[9] IEEE 802.1D, Media Access Control (MAC) Bridges
[10] IEEE 802.1P, LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization
[11] IEEE 802.1Q, Virtual Bridged Local Area Networks
[12] IEEE 802.3, LAN/MAN CSMA/CD Access Method
[13] ITU-T H.323
[14] ITU-T G.165, Echo cancellers
[15] ITU-T G.168, Digital network echo cancellers
[16] RFC 1590, Media Type Registration Procedure. J. Postel. March 1994.
[17] RFC 1597, Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D.
Karrenberg, G. de Groot. March 1994.
[18] RFC 1631, The IP Network Address Translator (NAT). K. Egevang, P. Francis.
May 1994.
[19] RFC 1750, Randomness Recommendations for Security. D. Eastlake 3rd, S.
Crocker, J. Schiller. December 1994.
[20] RFC 1889, RTP: A Transport Protocol for Real-Time Applications. Audio-Video
Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.
January 1996.
[21] RFC 1890, RTP Profile for Audio and Video Conferences with Minimal Control.
Audio-Video Transport Working Group, H. Schulzrinne. January 1996.
[22] RFC 2104, HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M.
Bellare, R. Canetti. February 1997.
[23] RFC 2131, Dynamic Host Configuration Protocol. R. Droms. March 1997.
[24] RFC 2138, Remote Authentication Dial In User Service (RADIUS). C. Rigney, A.
Rubens, W. Simpson, S. Willens. April 1997.
[25] RFC 2139, RADIUS Accounting. C. Rigney. April 1997.
[26] RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September
1997.
[27] RFC 2210, The Use of RSVP with IETF Integrated Services. J. Wroclawski.
September 1997.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
14 / 266
[28] RFC 2309, Recommendations on Queue Management and Congestion Avoidance
in the Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S.
Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S.
Shenker, J. Wroclawski, L. Zhang. April 1998.
[29] RFC 2326, Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R.
Lanphier. April 1998.
[30] RFC 2327, SDP: Session Description Protocol. M. Handley, V. Jacobson. April
1998.
[31] RFC 2386, A Framework for QoS-based Routing in the Internet. E. Crawley, R.
Nair, B. Rajagopalan, H. Sandick. August 1998.
[32] RFC 2402, IP Authentication Header. S. Kent, R. Atkinson. November 1998.
[33] RFC 2406, IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson.
November 1998.
[34] RFC 2409, The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November
1998.
[35] RFC 2488, Enhancing TCP Over Satellite Channels using Standard Mechanisms.
M. Allman, D. Glover, L. Sanchez. January 1999.
[36] RFC 2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. S.
Casner, V. Jacobson. February 1999.
[37] RFC 2543, SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E.
Schooler, J. Rosenberg. March 1999.
[38] RFC 2617, HTTP Authentication: Basic and Digest Access Authentication. J.
Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart.
June 1999.
[39] RFC 2663, IP Network Address Translator (NAT) Terminology and
Considerations. P. Srisuresh, M. Holdrege. August 1999.
[40] RFC 2748, The COPS (Common Open Policy Service) Protocol. D. Durham, Ed.,
J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. January 2000.
[41] RFC 2779, Instant Messaging / Presence Protocol Requirements. M. Day, S.
Aggarwal, G. Mohr, J. Vincent. February 2000.
[42] RFC 2824, Call Processing Language Framework and Requirements. J. Lennox, H.
Schulzrinne. May 2000.
[43] RFC 2960, Stream Control Transmission Protocol. R. Stewart, Q. Xie, K.
Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
Paxson. October 2000.
[44] RFC 2976, The SIP INFO Method. S. Donovan. October 2000.
[45] RFC 3022, Traditional IP Network Address Translator (Traditional NAT). P.
Srisuresh, K. Egevang. January 2001
[46] RFC 3050, Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J.
Rosenberg. January 2001.
[47] RFC 3095, RObust Header Compression (ROHC): Framework and four profiles:
RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. Degermark, H.
Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A.
Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. July 2001.
[48] RFC 3219, Telephony Routing over IP (TRIP). J. Rosenberg, H. Salama, M.
Squire. January 2002.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
15 / 266
[49] RFC 3262, Reliability of Provisional Responses in Session Initiation Protocol
(SIP). J. Rosenberg, H. Schulzrinne. June 2002.
[50] RFC 3312, Integration of Resource Management and Session Initiation Protocol
(SIP). G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. October 2002.
[51] RFC 3313, Private Session Initiation Protocol (SIP) Extensions for Media
Authorization. W. Marshall, Ed.. January 2003.
[52] RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP). J.
Peterson. November 2002.
[53] RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks. C. Jennings, J. Peterson, M. Watson. November
2002.
[54] RFC 3351, User Requirements for the Session Initiation Protocol (SIP) in Support
of Deaf, Hard of Hearing and Speech-impaired Individuals. N. Charlton, M. Gasson, G.
Gybels, M. Spanner, A. van Wijk. August 2002.
[55] RFC 3428, Session Initiation Protocol (SIP) Extension for Instant Messaging. B.
Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. December 2002.
[56] RFC 3515, The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April
2003.
[57] RFC 3545, Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet
Loss and Reordering. T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy.
July 2003.
[58] RFC 3550, RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne,
S. Casner, R. Frederick, V. Jacobson. July 2003.
[59] RFC 3702, Authentication, Authorization, and Accounting Requirements for the
Session Initiation Protocol (SIP). J. Loughney, G. Camarillo. February 2004.
[60] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion
Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp. 397413
[61] Update to the Session Initiation Protocol (SIP) Preconditions Framework draft-ietfsip-rfc3312-update-03.txt
[62] Session Timers in the Session Initiation Protocol (SIP) draft-ietf-sip-session-timer15
[63] EN 300 421 V1.1.2 (1997-08), Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for 11/12 GHz satellite services, ETSI and
EBU, 1997
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
16 / 266
3. ABBREVIATIONS
For the purposes of the present document the following abbreviations apply:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
AAA: Authentication, Authorization and Accounting
AAL: ATM Adaptation Layer
ABA: Accounting Billing Application
ABR: Available Bit Rate
AH: Authentication Header
ALG: Application Level Gateway
ASP: Application Service Provider
ATM: Asynchronous Transfer Mode
AVBDC: Absolute Volume Based Dynamic
BAT: Bouquet Association Table
BER: Bit Error Rate
BGP: Border Gateway Protocol
BoD: Bandwidth of Demand
BUC: Block Up Converter
BW: Bandwidth
C2P: Connection Control Protocol
CA: Conditional Access
CAT: Conditional Access Table
CDR: Call Detail Records
CLI: Calling Line Identification
CPE: Customer Premises Equipment
CPL: Call Processing Language
CR: Capacity Request
CRA: Constant Rate Assignment
CSC: Common Signaling Channel
CWND: Congestion Window - the maximum TCP data volume that is
unacknowledged
DAMA: Demand Assigned Multiple Access
DiffServ: Differentiated Services
DoS: Denial of Service
DSCP: Differentiated Services Codepoint
DSM-CC: Digital Storage Media - Command & Control
DT: Drop Tail
DVB-RCS: Digital Video Broadcasting- Return Channel Signaling
DVB-S: Digital Video Broadcasting- Satellite
EIT: Event Information Table
EN: European Norm
ESP: Encapsulating Security Payload
AEO-005479
SATLIFE
D311
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
17 / 266
EWMA: Exponential Weighted Moving Average
FCA: Free Capacity Allocation
FCT: Frame Composition Table
FDMA: Frequency Division Multiplex Access
FEC: Forward Error Correction
FLS: Forward Link Subsystem
FTP: File Transfer Protocol
GEO: Geostationary Earth Orbil
GK: Gatekeeper
GMM: Gateway Management Module
GRE: Generic Route Encapsulation
GUI: Graphical User Interface
HP: High Priority
HP: Hewlett Packard
HPj: High Priority Jitter Sensitive
IAS: Interactive Application Server
ICMP: Internet Control Message Protocol
IGMP: Internet Groups Management Protocol
IDU: Indoor Unit
IE: Information Element
INAP: Interactive Network Application Provider
IRD: Integrated Receiver Decoder
ISP: Internet Service Provider
LAN: Local Area Network
LNB: Low Noise Block converter
LP: Low Priority
MAC: Media Access Control
MCR: Minimum Cell Rate
MCU: Multipoint Control Unit
MHP: Multimedia Home Platform
MIB: Management Information Base
MS: Management Station
MSS: Maximum TCP data Segment Size – the data unit that can be wrapped in one
packet
MPTS: Multiple Program Transport Stream
MTU: Maximum Transfer Unit – typically the maximum size of an IP packet on the
link layer
MUX: Multiplexer
NMC: Network Management Center
NNM: Network Node Manager
NAPT: Network and Port Address Translation
NAT: Network Address Translation
NIT: Network Information Table
AEO-005479
SATLIFE
D311
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
18 / 266
NCC: Network Control Center
NCR: Network Clock Reference
NMC: Network Management Center
NVOD: Near Video On Demand
OBP: On Board Processor
ODU: Outdoor Unit
OV: OpenView
PAT: Program Association Table
PID: Packet Identifier
PIM: Protocol Independent Multicast
P-MP: Point to Multipoint
PMT: Program Map Table
QoS: Quality of Service
RBDC: Rate Based Dynamic Capacity
ROHC: Robust Header Compression
RCST: Return Channel Satellite Terminal
RS: Reed Solomon
RSGW: Regenerative Satellite Gateway
RST: Running Status Table
RTSP: Real Time Streaming Protocol
RTT: Round Trip Time
RTTmin: The minimum RTT – when there is no data in the intermediate buffers
Rwnd: receive window – the maximum volume the TCP input buffer can hold
SAC: Satellite Access Control
SDT: Service Description Table
SDP: Session Description Protocol
SIP: Session Initiation Protocol
SMS: SNO Management Station
SNMP: Simple Network Management Protocol
SNO: Satellite Network Operator
SPI: Security Parameter Index
SPT: Satellite Position Table
SPTS: Single Program Transport Stream.
TBTP: Terminal Burst Time Plan
TOS: Type Of Service
UBR: Unspecified Bit Rate
UT: User Terminal
VBDC: Volume Based Dynamic Capacity
VBR: Variable Bit Rate
VC: Video Conference
VoD: Video On Demand
VSN: Virtual Satellite Network
VTM: Virtual Traffic Module
AEO-005479
SATLIFE
D311
•
W2K: Windows 2000 – MS Windows version
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
19 / 266
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
20 / 266
4. DOCUMENT OVERVIEW
The document follows a top-down approach in the description of the design of the different
elements. First a general design of the system is presented and afterwards, one by one, the
design of the different subsystems and manufacturers. Here below the figure shows the
different parts:
%&
$
# "
!" #
$
# "
'#
#
'
Figure 4-1 Elements Overview
The set-top boxes are not included here as SatLife will use commercial ones and the design
is out of scope of the project.
Other elements are not considered because they will not be modified and they will remain
as they are for AmerHis. This is the case of the NCC-RCST and the NMC, parts of the
management station of the regenerative system.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
21 / 266
5. GENERAL SYSTEM DESIGN
5.1 Introduction
The general system design is driven by the type of payload boarded in the satellite. In
SatLife two different types are provided:
• Transparent Payload
• Regenerative Payload
5.2 Regenerative System Design
This design of the system affects the following elements:
! )* ! )
+$
#
#
(# ,
#
$
('
%
('
Figure 5-1 Global diagram of boards
•
•
OBP: On Board Processor
NCC: Network Control Center
(
$,-#
AEO-005479
SATLIFE
D311
•
•
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
22 / 266
RCST: RCS Terminal
RSGW: Regenerative Satellite Gateway
VSP: Video Service Provider
SP RCST: Service Provider Terminal
NCC RCST: NCC RCS Terminal
IRD: Integrated Receiver Decoder
As the OBP supposes an important breakthrough in the satellite technology we will
describe the design of an OBP Payload to understand more clearly the differences between
both concepts.
5.2.1 OBP Design
5.2.1.1 Decomposition into Boards
The BBP consists of two main parts :
- the OBP module, which includes all the specific parts of the On-Board Processing, and
- the Control and Supply module, which consist of the DC/DC, TM/TC and clock modules.
The OBP module consists of the following boards :
•
MC3D board : carries out from the Analogue to Digital Conversion to the formatting of
MPEG-2 error-free packet; 5 ASICs are in charge of the functions of Demultiplexing
(DEMUX ASIC) and Demodulation/Decoding/Formatting (4 DEMDEC ASICs).
•
Switch board : expands the interfaces of the multiplexers from 8 to 20 by means of an
ASIC (SWITCH ASIC); this board includes a nominal and a redundant SWITCH
ASIC.
•
Mux board : carries out the functions of packet multiplexing and DVB coding; 3 ASICs
(MUX ASIC) are implemented in this board and are in charge of generating the DVB
multiplex for 3 transponders.
The Control and Supply module consists of the following boards :
•
Clock board : this board generates all the required clocks for the processing of the
DVB as well as the frame synchronization signal (Start Of Frame); the 84.2 MHz clock
is used for the receive chain (ADC, Demultiplexing, demodulation) and the 54 MHz
clock is used for the packet request and the generation of the DVB flow.
•
TM/TC board : the control and monitoring of the boards and the interface with the
satellite is implemented by a FPGA.
•
PDM board : this board is basically composed of 4 DC/DC blocks which provide the
secondary voltages to the other boards.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
23 / 266
A mother board is in charge of interconnecting all the boards between each other and
carries several kinds of signals (secondary voltages, internal TM/TC bus, clocks, data
signals…).
' 0
&
7
' 3
# 2
# "
2
'
4.
'
41
'
43
'
49
" ' 27
&
&1/ 0 1/
./ 0 1/
' 0
6 7.
' 0
6 7.
! $#" "
#2 2
' 0
*
* '
5
' 0
6 7.
*' *
8'
Figure 5-2 Global diagram of boards
5.2.1.2 Functional Description
In the next figures it is given a general overview of the division of the Base-Band
Processor into functional units. The architecture is divided into two modules: the OBP
module which carries out the specific signal regeneration and switching functions and the
Control and Supply module which carries out the service functions such as voltage supply,
Telecommand / Telemetry and clock supply.
The OBP is composed of the following units: MC3D (Multi-Carrier Demultiplexer,
Demodulator, and Decoder) unit, MUX unit, and SWITCH unit.
5.2.1.2.1 MC3D Unit
The MC3D unit which carries out the signal regeneration functions for one 36 MHz
Transponder :
- Analogue to Digital Conversion (ADC)
- Demultiplexing of carriers included in a 36 MHz bandwidth in order to generate
elementary carriers of kRs (k=1, 2, 4, 8, 16) in 4 sub-bands of 16Rs
- Parallel demodulation of 16/k carriers of rate kRs
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
24 / 266
- Turbo decoding of MPEG-2 packets generated from the 16/k carriers in order to obtain
quasi error-free data (PER < 10-7)
- Storage of output packets in buffers (classification per carrier) in order to have them
ready to be requested by the switch or the multiplexer.
A functional block diagram of the MCDDD is shown in the figure below. Every carrier
must be demultiplexed from the rest, demodulated, and then turbo-decoded in order to
obtain the received quasi-error free MPEG2-TS packets. For every carrier demodulated
and decoded by the MCDDD, there is an associated FIFO buffer where the received quasierror free MPEG2 packets are stored ready for delivery to the OBP multiplexers. Each 8
MHz block can be configured for a choice of carrier rates in accordance with the uplink
frequency plan (carriers at 1Rs, 2Rs, 4Rs, 8Rs and 16Rs).
8 MHz Block
4Rs Carrier
4Rs Carrier
4Rs Carrier
4Rs Carrier
'
'
'
'
8 MHz Block
16Rs Carrier
'
Figure 5-3 Example of MCDDD Functional Block Diagram)
5.2.1.2.2 MUX Unit
The MUX unit carries out the packet multiplexing and DVB coding for three D/L
transponders. Each D/L transponder output consists of 54Mbps TDM composed of MPEG
2 packets requested from any one of the uplink MCDDDs in accordance with its associated
MUX-TABLE (which can be quickly reconfigured through the signaling channel, thus,
allowing FAST CIRCUIT SWITCHING at packet level).
The MUX table is a 2D array which is scanned on a frame basis and contains columns of
24 packets corresponding to the number of packets per frame of an elementary carrier Rs,
The number of columns depends on the convolutional rate (CVR) which is used for the
data output: it varies from 48 (CVR=1/2) to 84 (CVR=7/8). The content of the multiplex
table cells indicate the packet location in terms of :
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
25 / 266
- Mux interface number
- Switch interface number (if switch included)
- MC3D number
- Sub-band number
- Carrier number.
The content of this cell is turned into a serial request signal which is identified by the
buffer of the related carrier within the MC3D and this buffer responds by sending a packet
to the multiplexer. The request of all the multiplex tables are emitted in fixed time-slots in
order to avoid conflicts (overlapping between request reception and packet transmission) at
MC3D level.
Full Cross-Connectivity between U/L and D/L footprints is possible such that any
multiplexer (D/L) can request packets from any one of the MC3D (U/L). This can even be
done instantaneously by more than one multiplexer. This functionality is the physical
support for the IBIS multicast services and applications.
The output of the multiplexing process is then DVB coded (including pulse shaping) in
accordance to the DVB-S standard [AEO-2] (Scrambling, Reed-Solomon coding,
Interleaving, Convolutional coding);
Finally, Digital to Analogue Conversion of output I and Q branches must take place before
the multiplexer output may be used to modulate (QPSK in accordance with the DVB-S
Standard) an RF carrier at Ku or Ka band (L-Band for the SatLife test bed).
5.2.1.2.3 SWITCH Unit
The Switch unit is in charge of expanding the switch capability of the multiplexers (up to
20 transponders) and shall be implemented when the number of transponders to be
processed is greater than the capacity of the multiplexer; it will collect the requests from
the multiplexers, route them to the related MC3D units, collect the returning packets and
route them to the corresponding multiplexers. This switch has a dynamic configuration
since it is configured on a request basis (Switch interface number field in the request). This
implies that the contents of all the multiplex tables have to be coherent in order to avoid
conflicts. A conflict can be defined as the fact of sending two or more requests to the same
switch interface on the MC3D side in the same time slot (this conflict is managed in the
switch by only retransmitting the first received request).
The Control and Supply module includes the following units :
- Clock unit : generates all the clocks and periodic signals (Start of Frame) required for the
processing and the DVB multiplexing
- TM/TC unit : is in charge of the control and monitoring of the rest of the boards in the
BBP and their interface with the other modules of the satellite.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
26 / 266
- PDM unit : converts the regulated voltage of the primary bus into secondary voltages for
the different units.
SOF
Multiplex table
Origin
packet
96*CVR
Origin
packet 1
Origin
packet
24*96*CVR
SOF
MC3D UNITS
SWITCH
UNIT
(expand Mux)
Packet
buffering
MUX UNITS
C1-Pck 1
110011
33-MHz
transponder
Analogue to
Digital
Conversion
Demod
4Rs
carriers
110010
Packet
decoder
C1-Pck 2
Request
handling
DVB
Coding
+
DAC
54 Mbps
O/P
C4-Pk m
1
Demultiplexing
4
C1-Pck 1
16Rs
carrier
Demod
Packet
decoder
C1-Pck 2
Request
handling
DVB
Coding
+
DAC
54 Mbps
O/P
C1-Pk n
CONTROL &
SUPPLY MODULE
PDM
UNIT
TM/TC
UNIT
CLOCK
UNIT
Request
Packet
Figure 5-4 Functional overview of the BBP
5.2.1.3 Interconnection between MC3D, SWITCH and MUX Boards
This interconnection refers to the transfer of formatted packets between the MC3D boards
and the multiplexers. The basic packet bus on the multiplexer side includes the following
lines operated at 54/4 MHz (see next figure) :
- 1 line for the packet request
- 4 lines for the packet data (the packets are transmitted from the MC3D to the Muxes on a
nibble basis)
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
27 / 266
Each MC3D includes a double bus with 4 request lines each in order to handle two
independent requests in a given time slot of the MUX table from 8 possible sources
(Figure 5-6).
Request line
Data line
4
1
MUX
ASIC
Request line
Data line
4
8
Figure 5-5 Packet bus interface at multiplexer level
Request lines
MC3D
BOARD
4
Request lines
4
1
2
3
4
Packet bus 1
Data line
1
2
3
4
Packet bus 2
Data line
Figure 5-6 Packet bus interface at MC3D level
5.2.1.4 Multicast
The multicast functionality of the BBP refers to the ability of sending a packet from a
given MC3D source to various multiplexers in the same time slot.
In the case of one box, the multicast capacity is given by the number of multiplexers
connected to a packet bus of the MC3D board. It can reach a maximum of 4 and it is sized
to 3 in the example of section 6.4. The procedure is the following for operating multicast
among N muxes :
1. One MUX called the Master MUX generates a request towards the related MC3D board.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
28 / 266
2. The MC3D board responds by sending the packet on the common data bus.
3. The N Muxes in multicast acquires the packet present on the data bus and insert it in the
DVB flow.
5.3 Transparent System Design
In the case of the transparent system the elements involved are different (apart from the
functional point of view):
#
(# ,
#
('
$,-#
Figure 5-7 Transparent System
HUB: Network Control Center and Gateway
RCST: RCS Terminal
IRD: Integrated Receiver Decoder
5.3.1 Introduction to DVB RCS and Nera SatLINK system
The Nera SatLink system is based on the open standard DVB Return Channel over
Satellite, ETSI EN 301 790, and the associated Guideline document, ETSI TR 101 790.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
29 / 266
The system overview will start off with a presentation of the general DVB RCS network as
defined in the ETSI standard and then continue with a description of the Nera DVB RCS
solution; the SatLink System consisting of the SatLink Gateway and the SatLink terminal.
5.3.2 Nera DVB RCS solution - the SatLink system
The SatLink system is a star network, where the remote RCST accesses the terrestrial
network via the SatLink Gateway. The SatLink Gateway supports terminal to terminal
communication over a transparent (bent-pipe) satellite by looping the incoming RCST
traffic out onto the forward link1. The SatLink GW comprises the Feeder Station, Traffic
GW, and NCC.
The SatLink terminal acts as an IP router connecting a single PC or a LAN to the services
provided by the SatLink Gateway. For connecting multiple users or devices to the SatLink
terminal, an Ethernet hub or switch is required, as shown in below.
PC1
RCST
SW
PC2
PCn
Figure 5-8 - Subnet on the RCST Ethernet side
Satellite Interactive Network, Interactive Network ID, and Superframe ID
In the SatLink Gateway implementation, the Satellite Interactive Network consists of one
Interactive Network. The Satellite Interactive Network is identified by the SIN parameter
in the GW NMS database. The Interactive Network ID used in the DVB RCS SI tables
broadcast to the satellite terminals is set by the SatLink NCC to be equal to the operator
configured SIN.
Segmentation of satellite capacity within the Interactive Network is achieved by defining
one or more Superframes. Thus, the Interactive Network (identified by SIN in NMForms)
will be associated with one or more Superframe IDs. One or more terminal populations can
be assigned to operate on a given Superframe_ID. The Superframe_IDs must be unique
1
Terminal-to-terminal communication involves a double satellite hop.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
30 / 266
within the Interactive Network. The maximum number of Superframe_IDs within an
Interactive Network is 255.
System capabilities
One SatLink Gateway can support one or several superframe sequences (superframe IDs).
It supports a superframe construction with one frame per return link carrier, i.e. the frames
represent sub-bands of the superframe as shown in Figure 5-9.
frequency
Superframe
counter
14
Superframe_id 1
Superframe
counter
15
Superframe
counter
16
Superframe_id 2
Superframe
counter
236
Superframe
counter
237
Superframe
counter
238
Superframe
counter
239
time
frequency
Superframe counter 237
Frame number 4
Frame number 3
Frame number 2
Frame number 1
Frame number 0
time
Figure 5-9 Recommended superframe - frame composition in the SatLink Gateway
Choice of ATM traffic time slots or the optional MPEG TS time slots will depend on many
considerations related to the network operator's strategy. In the Nera baseline it is use of
MPEG TRF burst combined with Turbo-coding. ATM TRF burst carrying two ATM cells
is supported in SatLink Gateway.
The concatenated coding scheme, convolution code combined with Reed Solomon, is not
supported by the SatLink system.
Multiple FEC rates and symbol rates can be used within the same superframe.
Signaling bursts (SYNC and CSC) must be located on carriers operating at 519 ksps or
less.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
31 / 266
The optional Acquisition (ACQ) procedure of the EN 301 709 standard is not used in the
SatLink System. It is however, supported by the SatLink Gateway and terminals for
interoperability reasons.
Capacity allocation and slot assignment is performed on a superframe basis. The slot
assignment is signaled to the terminals through the TBTP. In the current SatLink system,
all terminals that are associated with a given Superframe_ID are given the same Group_ID
at log-on. Thus, only one TBTP is issued for each superframe count of a given
Superframe_ID. The Group_ID associated with a Superframe_ID is unique and can not be
re-used by another Superframe_ID.
The Gateway supports a mix of terminals capable of doing fast frequency hopping and
terminals capable of doing only slow frequency hopping. The SatLink 1900 and 1910
terminals are capable of fast frequency hopping. The SatLink 1901 and 1000 models are
designed for slow frequency hopping.
The Gateway supports adaptation to current link conditions per terminal by avoiding
marginal channels in the capacity allocation and slot assignment processes.
Both the terminal and the Gateway are designed to support differentiated QoS. This is
implemented through differentiated request, allocation, assigning and scheduling
strategies. In the first phase of the development, two classes of service were provided,
namely Best Effort and VoIP (High Priority).
Capacity request generation and signalling
The terminal calculates the required dynamic capacity and signals requests to the Gateway.
Capacity is requested specifically, either as rate or volume or a combination of both. The
Gateway can also provide capacity independent of requests using CRA and FCA. The
NCC signals the committed CRA level to the terminal in the Network Layer Information
Descriptor of the Unicast TIM.
The following signaling channels are available:
• contention slots for signaling
• dedicated slots for signaling and synchronization
• embedded in dedicated (MPEG) traffic slots
The contention-based minislot is used for slotted ALOHA access to request for initial
capacity. It is used only to reduce the system delay occurring at the start of a packet
transmission session, i.e. when the terminal might have to wait a long time for the next
dedicated SYNC slot.
Once the transmission session is established, use of dedicated signalling slots is sufficient
to keep a continuous rate service.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
32 / 266
Signaling embedded in traffic slots is used to reduce the response time for transients in the
traffic level.
The operator of the system (or ISP) can decide to impose limits on the maximum amount a
terminal is allowed to request for each capacity category in its capacity requests. These
maximum limits are defined in the default terminal profile of a Service Level Group and
can be overridden for a given terminal by defining a different value in the individual
subscriber profile of that particular terminal. The dynamic request level limits are signalled
to the terminal in the Network Layer Information Descriptor.
Allocation of capacity to terminal groups and individual terminals
The Gateway groups capacity reservation and distribution policies for predefined groups of
terminals. It is up to the network operator (or ISP) to decide which terminals shall belong
to a group. Up to 24 such terminal groups can be defined per Superframe_ID.
A capacity level is guaranteed per terminal group. Also, a maximum capacity limit can be
set per terminal group.
Excess capacity accumulated from terminal groups using less than the guaranteed capacity,
can be distributed to the other groups as required. This is done through a weighted sharing,
with a (configurable) weight factor selected for each terminal group.
Within a terminal group, capacity is distributed between requesting terminals by
employing weighted fair sharing. The weight used for a terminal is relative to the
maximum request limit set for the terminal.
The gateway enforces request limitation as defined in the individual subscriber profile of a
terminal or the default profile of the terminal group that the terminal is assigned to.
In accordance with the DVB RCS specification, the SatLink terminal requests capacity
with a request granularity of 2 kbps. The gateway adjusts the request level to match the
assignment granularity steps. Initially, the assignment granularity is one TRF slot
(corresponding to 1 MPEG packet). Later, the assignment granularity has been made finer
and currently matches the terminal’s request granularity of about 2 kbps. This is achieved
by alternating the assignment per superframe between N and N+1 slots to match the
required rate on the average.
RCST Group ID and Logon ID
On the forward link, the SatLink terminal is uniquely identified by a physical MAC
address and a logical address consisting of the Group_ID and Logon_ID. In the SatLink
system, all terminals that are assigned to the same Superframe_ID are given the same
Group_ID. The Group_ID is not visible in the operator GUI, NMForms, since the
Group_ID is automatically taken to be the same value as the Superframe_ID that is
configured in the terminal subscriber profile.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
33 / 266
The Logon ID is unique within a Superframe_ID. The Logon_ID is automatically assigned
to a terminal at log-on by the NCC, i.e. it is not operator configurable.
Terminal IP addresses
The SatLink IDU has two IP interfaces, the DVB (satellite) interface and the Ethernet LAN
interface.
Generally, these IP addresses are allocated by the network operator. These IP addresses
must be configured separately both in the GW and in the terminal, currently it is not
possible to configure the terminal IP addresses on the terminal by the GW.
The SatLink GW uses the terminal’s DVB interface IP address for network management
purposes, such as SNMP queries. However, the IP Encapsulator configuration file must
contain both the DVB and the Ethernet interface IP address of the terminal in order to be
able to route traffic destined to the terminal or the hosts residing on the terminal LAN
correctly.
DHCP server on terminal Ethernet side
The SatLink terminal can act as a DHCP server on its Ethernet interface. The DHCP
protocol is defined in RFC 2131. The main purpose of this protocol is to assign IP
addresses from a pool of predefined IP addresses automatically to the network entities
connected to the server LAN which requests this. The IP addresses are assigned to a host
for a predefined leasing time. After leasing time expiration the host, if interested, is able to
renew the IP address assignment. The DHCP server manages the whole leasing procedure.
Besides IP address allocation, the DHCP server is also able to deliver primary and
secondary DNS server names to the hosts requesting it.
The DHCP server option is not enabled by default on the terminal, but it can be enabled
and configured easily either by using the web-based management interface or the
command line interface of the terminal. The advantage of using the terminal as a DHCP
server on a LAN is that one doesn’t have to configure manually all the network entities
connected to the terminal.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
34 / 266
5.3.2.1 SatLink system options
The SatLink system provides a couple of features that are optional, and can be provided in
case of user request.
NAT – Network Address Translation
Network Address Translation (defined in RFC 3022) is a mechanism to provide transparent
IP-level access to the Internet from a local site with a private address range without
requiring all the hosts on the site to have globally valid IP addresses. It requires only one
globally valid IP address, which is then configured for the DVB interface of the Nera
SatLink terminal.
NAT translates addresses in incoming and outgoing IP packets by replacing the source
address in each outgoing IP packet with the globally valid IP address, and replacing the
destination address in each incoming IP packet with the private address of the destination
host on the local site. Network Address Port Translation (NAPT), sometimes called PortMapped NAT, is a popular variant of NAT providing concurrency by translating TCP or
UDP protocol port numbers as well as addresses2. The globally valid IP address used for
address translation when NAPT is enabled is the Nera SatLink terminal’s own DVB
interface IP address.
NAT can be enabled on a terminal by using the command line interface of the terminal.
TCP/IP enhancement
The purpose of the TCP/IP enhancement functionality is to speed up TCP connections over
a large latency satellite link. The functionality can be used for both TCP connections
between terminals and TCP connection between terminals and Internet hosts. Typical
popular applications that use TCP as transport protocol are FTP and HTTP (for webbrowsing).
Conditions particular to geostationary satellites severely constrict the performance of TCP
and reduce the end users experience of accessing the Internet over satellite. Large latency,
high bit error rates and asymmetric bandwidth which are characteristic for satellite
networks makes TCP less suitable when used over satellite. Some performance
improvements can be achieved by simply tuning the TCP parameters, but the effectiveness
of this is limited.
2 Translation of outbound TCP/UDP fragmented datagrams will fail with NAT enabled. The reason is that only the first fragment
contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent
fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment.
Consequently the sessions will be corrupted. Whether NAT drops or forwards also an ICMP fragmented packets depends on a number of
things, such as the order in which the NAT router receives the ICMP fragments and the state of the translation table at that time. Under
certain conditions, NAT translates the ICMP fragments differently, making it impossible for the destination device to reassemble the
packet.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
35 / 266
To overcome the TCP problems over satellite, several commercial products (commonly
known as TCP accelerators) have been developed which optimise the TCP performance
over satellite. These products have in common that they all use mechanisms described in
RFC 3135, TCP Performance Enhancing Proxy (TCP PEP).
The TCP PEP implementations make use of the split-connection principle. A splitconnection terminates the TCP connection from an end system (client) and establishes a
corresponding TCP connection to the other end system (server). This is done in order to
use a third connection between two TCP PEPs which is optimized for the satellite link (see
Figure 5-10 below). Both connection ➊ and ➌ in the Figure below are complete separate
TCP connections, while connection ➋ is normally a proprietary satellite optimized protocol
or a modified TCP protocol optimized for the satellite link. Data streams are forwarded
from one connection to another, and extensive buffering mechanisms are required. Other
traffic than TCP shall simply be forwarded untouched through the TCP PEPs.
Server
TCP PEP
TCP-Accelerator-Server
TCP PEP
TCP Accelerator Client
Protocol Translator
Protocol Translator
Client
TCP
TCP
Sat. opt.
protocol
Sat. opt.
protocol
TCP
TCP
IP
IP
IP
IP
IP
IP
Driver
Driver
Driver
Driver
Driver
Driver
Physical
Physical
Physical
Physical
Physical
Physical
❸
Standard TCP/IP
❷
Satellite optimised protocol
❶
Standard TCP/IP
Figure 5-10 TCP Acceleration over satellite
This architecture makes it possible to achieve vastly improved performance while
remaining entirely transparent to the end user and fully compatible with the Internet
infrastructure. No changes are required to the client and server, and all applications
continue to function without modifications. TCP congestion avoidance mechanisms
remain in place over the terrestrial connections and also maintain full TCP reliability and
end-to-end flow control.
The TCP PEPs can be integrated or distributed. In the integrated solution, a PEP
component is installed within a single node (e.g. at the client node), while in the distributed
solution a PEP component is located on a dedicated node (e.g. on the TCP enhancement
server).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
36 / 266
All TCP connections and application layer protocols running over TCP will benefit from a
TCP PEP solution. For HTTP traffic, a large number of TCP connections can be
established for each single WWW site. To reduce the number of TCP connections, some
TCP PEP solutions also improves the performance by running multiple TCP connections
through a single TCP connection.
ISP hosting
The SatLink System offers functionality for Internet Service Providers to manage and
monitor their terminals and their service level agreements through a web management
interface, without any intervention from the Gateway operator. The ISPs are able to
monitor and manage only their own terminals, but not terminals belonging to other ISPs.
The main focus is on control and supervision related to data available through the SatLink
gateway.
Three levels of ISP user privileges are defined:
• ISP user with all rights
• ISP user with “modify” rights (read/write, but not create/delete)
• ISP user with read-only access
The available data and commands for ISPs are:
- Add/delete/activate/deactivate RCSTs in the system.
To simplify initial deployment of terminals a standard profile can be selected to set
most of the terminal parameters. A standard profile is defined for each Superframe ID,
and thereby for each ISP
- Change RCSTs parameters, as e.g. capacity
Parameters can either be changed individually or another standard profile can be
selected.
- Do large configuration changes by uploading batch files
- Troubleshoot RCST connectivity and service quality
- Check overall status of the SatLink Gateway
VoIP
The SatLink system optionally can be extended to support also Voice over IP (VoIP)
services. Below is presented the system set-up that can assure this functionality.
To support VoIP, both the GW side and the terminal side must support VoIP. The SatLink
terminal supports a standard 10/100Base-T Ethernet interface for the local LAN. Most
standard VoIP-adapters can be used, so no special changes must be done at the terminal
side.
However, the GW side is more complicated. Next figure illustrates the VoIP solution for
the SatLink GW:
AEO-005479
SATLIFE
D311
A&F
Links
PSTN/ISDN/SS7
SATLIFE-AEO-SYS-DD-3
Signalling
Unit
ISSUE:
PAGE:
14/09/2006
2.0 draft
37 / 266
Gatekeeper
H.323
RAS Messages
H.323
RAS Messages
Q9xx over IP
IMT
DATE:
VoIP
Gateway
H.225 Messages
RTP
Subscriber
Equipment
RADIUS Messages
AAA Server
Read/Write
NM
Database
Optional, signalling type dependent
Figure 5-11 Nera SatLink Gateway VoIP Subsystem
The VoIP subsystem in the SatLink Gateway consists of the following main modules:
• VoIP Gateway: includes voice-processing cards that convert between PSTN voice
format and VoIP. The Gateway can support several voice compression techniques,
such as G.729ab and G.723. The compressed voice packets are transported over the
SatLink IP network in ”RTP (Real Time Protocol) over UDP over IP” packets.
• VoIP Gatekeeper: performs address translation, admission control (to allow or deny
some hosts or some users), and bandwidth management. It supports H.323 and SIP
signalling protocol for call establishment and clearing over the IP network.
• Signalling Unit: the presence of this unit is dependent on the PSTN and which
signalling is required. It also depends on the customer requirements with regard to
supplementary services such as barring, call screening, etc.
• AAA-server and database: the VoIP gateway interacts with the SatLink AAA server to
provide authentication, authorisation and accounting services. The RADIUS protocol is
used for this communication. The VoIP network management information, statistics,
and accounting information is integrated with the SatLink database.
In order to have an acceptable quality of the voice services, it is essential to provide
Quality of Service differentiation of user traffic. QoS differentiation on the SatLink GW
side is achieved at the IPE. The IPE bases its priority settings on destination IP addresses.
The priority settings are operator configurable
The SatLink terminal incorporates DiffServ functionality that classifies different
applications and gives the voice application the proper priority. The Radio Resource
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
38 / 266
Manager (RRM) module of the SatLink GW recognises terminal initiated capacity requests
linked to voice calls and grants capacities according to the policy for the VoIP-service.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
39 / 266
6. REGENERATIVE NCC DESIGN
6.1 AmerHis NCC design
6.1.1 NCC Functional description
The AmerHis NCC is in charge of the following functions:
• Management control
• Session Control
• Connection Control
• Resource Control
• OBP control
• Table Control
• MPEG Rx/TX Control
• NCC Control
6.1.1.1 Management control
The NCC is managed through two interfaces: one with the craft terminal, and one with the
Network Management center.
The craft terminal is used for the system configuration parameters as needed by the NCC
for start-up and for system control, for example
• DVB-S and DVB-RCS parameters, e.g. all data for building the tables
• PIDs parameters,
• route definition etc…
The interface with the NMC includes 3 aspects:
• network configuration: VSN and RCST profiles, permanent connections
• network monitoring and status: performances parameters, RCST status, permanent
connections status…
• management of terminals: transmission and reception of SNMP messages
6.1.1.2 Session Control
Session control handles log-on, log-off and lock of terminals, either automatically, i.e.
upon a specific event or by management upon NMC request.
6.1.1.3 Connection Control
The AmerHis system handles two types of connections: on-demand connection and
permanent connections. On-demand connections are set-up upon RCST request according
to traffic detection. Permanent connections are set-up by management (NMC command).
Both type of connections can be point to point or point to multipoint.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
40 / 266
The connection control function includes:
• C2P messages/protocol handling
• PID allocation,
• CAC (Call Admission and Control): before accepting a connection, the NCC
verifies it is compatible with current system load and with the profiles (SLA) of the
involved VSN and RCSTs
• address resolution and "routing": the NCC finds the destination RCST (MAC@)
according to the destination IP@ (in C2P request), determines the destination TDM
and selects a channelid
The NCC admits both mesh (RCST-RCST) and star (RSGW-RCST) connections.
6.1.1.4 Resource Control
The resource control is in charge of resource allocation to the RCSTs (SYNC and TRF
bursts) according to data provided by session control and connection control, and of TBTP
formatting.
The NCC implements three allocation mechanisms: CRA, RBDC and FCA. It ensures
there is no overlap on bursts allocated to a given RCST (SYNC and TRF).
6.1.1.5 OBP control
The NCC craft terminal includes a specific application software for route configuration and
generation of the corresponding OBP configuration. When a new configuration is
validated, the craft terminal operator may request the NCC to download the configuration
and to activate it at a given time and date.
The NCC implements the protocol for downloading a new configuration on-board. The
configuration commands are sent through the NCC communication link. They are
authenticated.
The NCC ensures that a change in OBP configuration does not disturb established traffic
by synchronously modifying the OBP configuration and its own configuration (routes).
6.1.1.6 Table Control
The NCC formats the DVB-S and DVB-RCS tables with the contribution of the NMC and
the Craft Terminal. Using information provided by the Craft Terminal, the NCC formats
and transmits the following tables to the downlink beams: TDT, NIT, PAT, FLS-PMT,
RMT, SCT, FCT, TCT, SPT, TIMb, MMT, TIMu, TBTP and CMT.
Using information provided by the NMC, the NCC formats and transmits the following
tables: CAT, BAT, SDT, EIT, RST.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
41 / 266
6.1.1.7 MPEG Rx/TX Control
The NCC schedules the transmission of tables and other MPEG packets according to
destination and priority: tables, OBP control (DULM), management messages for RCSTs.
It receives packets from the down-link and dispatches them to the appropriate function:
OBP control (ACK), SYNC/CSC bursts and measurements, SNMP messages for the NMC.
6.1.1.8 NCC Control
The NCC control function is in charge of:
• Installation and startup configuration files provided by the Craft Terminal allowing
the NCC to achieve its synchronization,
• NCC logon & synchronization procedures associated with the NCC-RCST,
• Internal timing distribution based on the SoSF provided by the NCC-RCST. Based
on the periodic Start of Super-Frame (SoSF) and its corresponding NCR value
notified by the NCC-RCST, it distributes the timing activation (SoSF and NCR) to
other modules for their needs.
• Monitoring & control of the NCC-RCST,
• Operational configuration provided by the NMC,
•
•
•
•
•
•
Operational commands initiated by the NMC such as:
Add/Delete/Modify VSN,
Add/Delete/Modify terminal,
Add/Delete/Modify Permanent connections,
Update DVB-S/DVB-RCS table,
Status Reports to the NMC (VSN, terminal, permanent connections, etc..)
• Redundancy of NCC:
• automatic switchover in case of primary NCC failure
• switchover upon NMC request
6.1.2 NCC architecture
The NCC is presented in the following figure in its environment. It is composed of three
main equipment:
• The NCC craft terminal:
in charge of NCC system configuration
includes the application for definition and generation of OBP configurations (called
RSA).
it is a PC integrated in the NCC rack
• The mediation device:
in charge of interface with the management system,
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
42 / 266
contains a SNMP agent with the NCC MIB
retrieves data in the NCC and store them in its MIB for NMC access (e.g. status,
performance counters)
generates commands to the NCC according to NMC requests
it is a PC integrated in the NCC rack
• The "core" NCC:
in charge of all AmerHis control functions,
in charge of SNMP messages routing and transport between the NMC and RCSTs
it is a multiprocessor computer (3 boards)
The NCC also includes some ancillary equipment like Ethernet switch and hub for
ensuring connectivity between the management station equipment, including active
equipment as well as redundant equipment.
The NCC interfaces with the Network management center (NMC) and the NCC-RCST
IDU.
Interface with NMC (Ethernet):
• one interface through the mediation device for AmerHis network configuration
(NCC, VSN profile, and RCST profile configuration) and for network monitoring
(status, alarms, performance counters)
• one interface for RCST management (red line in the figure), i.e. routing and
transport of SNMP packets from the NMC to the RCSTs, and from RCSTs to the
NMC.
Interface with NCC-RCST IDU:
• one Ethernet interface for data transmission and reception
• one RS232 interface for Start of Superframe reception from the IDU (for NCC
synchronization)
" "# $
"%
$
"
"
#
131
'
:
( $:
!
'
2-
'
#
$# + *
2
'
'
.//
";
$
"2 "
$
,
"2 "
")-
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
43 / 266
Figure 6-1 NCC architecture and environment
The NCC is fully redundant in 1+1 warm redundancy. In case of failure of the primary
NCC, the system control is transferred automatically to the secondary NCC. A preliminary
analysis of the different solutions is included hereafter.
6.2 Implementation of new functions
Three features have been selected:
• Service provider RCST handling
• Multicast routes and routes for video service provider
• Tables for video service provider
6.2.1 Service Provider Terminal handling
The video Service provider RCST is a new type of RCST. As no modification of the NMC
is foreseen, the video SP-RCST is declared as a GW-RCST.
It is assumed that the video service provider does not share its route with any other
terminal. In this way, the NCC is able to allocate always the full route capacity to the
terminal.
Session control is identical to a standard RCST. As soon as it is declared by the NMC, the
SP-RCST is able to log-on. During log-on procedure, the SP-RCST is allocated a SYNC
burst by the NCC. At the NCC level, this allocation is maintained until terminal log-off.
The SP-RCST does not implement the connection control protocol, therefore no C2P
connections will be set up with the SP-RCST. Instead, the NCC opens a "dummy" point to
multipoint unidir connection with permanent capacity immediately after the terminal
logon. This capacity is configured by the NMC.
No CAC is performed for this kind of terminal: no verification against VSN SLA, nor
RCST SLA, nor route capacity, nor terminal capability.
At resource control level, the full required capacity is allocated to the SP-RCST as long as
it is logged. The SYNC burst mask is disabled, i.e. the NCC allocates the full capacity
regardless of possible SYNC/TRF timeslot overlapping. If the NCC cannot allocate the
required capacity, it informs the NMC.
Note that, normally, this should not occur except in case of bad configuration.
The following section describes the detailed design of the SP-RCST session management
feature.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
44 / 266
6.2.1.1 SP-RCST session management detailed design
6.2.1.1.1 Dimensioning
Up to 10 SP-RCSTs registered.
Up to 10 SP-RCSTs logged simultaneously within the system.
Up to 1 SP-RCST logged simultaneously per VSN (although several SP-RCSTs registered
per VSN).
6.2.1.1.2 SP-RCST Session Management Use Case
6.2.1.1.2.1 Summary
This use-case describes the main steps of SP-RCST session management. Main steps are:
• SP-RCST Registration,
• SP-RCST Logon,
• SP-RCST Fine Synchronization,
• SP-RCST Synchronization Maintenance.
6.2.1.1.2.2 Context of use
Applies to “MONO-CHANNEL” SP-RCST.
6.2.1.1.2.3 Pre-conditions
The terminal is switched on.
The terminal has acquired the forward link signaling and the network clock.
The terminal has acquired the satellite position.
The terminal has acquired the frame description of the network. (included CSC burst
location)
The terminal has acquired contention control descriptor (TIM b message).
The NCC is in operational state.
6.2.1.1.2.4 Nominal course
6.2.1.1.2.4.1 SP-RCST Profile and SLA
The NCC detects if a terminal is a SP-RCST if and only if the terminal is a GW-RCST
without any capacity on the forward and return link, that is to say if:
• terminal type = GW-RCST,
• max star PDR FWD = 0
• max star PDR RTN = 0
• max mesh PDR FWD = 0
• max mesh PDR RTN = 0
Even though they are unused for a SP-RCST, if they are different from 0, the other
parameters of the SLA must be coherent between them. Indeed, the NCC shall perform
coherency check of RCST and GW-RCST profile.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
45 / 266
The capacity allocated to the connection mapped on channel 0 correspond to the CRA_SIG
capacity of the SLA. The CRA_SIG capacity gathers the capacity for video/audio traffic
transmission and the capacity for NCC signalization transmission (DVB tables
management). The NCC sets the CRA_SIG capacity to an entire number of burst:
“CRA_SIG” = ceil( “CRA_SIG” / “terminal traffic burst rate” ) * “terminal traffic burst
rate”.
The connection maximum number parameter of the SLA defines the number of traffic
PIDs that the NCC shall allocate to the SP-RCST. If connection max. number equals 0 no
PID allocation is done by the NCC (“standalone” test mode). If connection max. number
equals x, x traffic PIDs plus a VSP_PID are allocated to the SP-RCST. Finally, it is
assumed that there is no need to provide a SP-RCST with VSP traffic PIDs without
VSP_PID.
As an example, next figure shows a typical SP-RCST SLA requesting 10 traffic PIDs and a
VSP_PID.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
46 / 266
Figure 2 - Typical SP-RCST Service Level Agreement
6.2.1.1.2.4.2 SP-RCST Registration
The NSM sends to the MD a SNMP SET to register a new terminal. The MD sends a
“addRcst” command to the NCC.
# NCC checks
The NCC checks if the max. number of terminal registrations (5000) is not reached.
[exception: registration failure (error code: EC_MAX_RCST_QTY_REACHED)]
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
47 / 266
The NCC checks if the logonId is not already used by another terminal.
[exception: registration failure (error code: EC_DUPLICATE_OBJ_INST)]
The NCC checks if the MAC address is not already used by another terminal.
[exception: registration failure (error code: EC_DUPLICATE_MAC_ADR)]
The NCC checks if the associated VSN exists.
[exception: registration failure (error code: EC_VSN_DOESNT_EXIST)]
The NCC checks if the uplink and the downlink used by this terminal are defined.
[exception: registration failure (error code: EC_SF_DOESNT_EXIST)]
[exception: registration failure (error code: EC_TDM_DOESNT_EXIST)]
The NCC checks if there is a SIG route for the terminal (a route linking the terminal uplink
to the NCC-RCST downlink for SYNC purpose).
[exception: registration failure (error code: EC_NO_ROUTE_FOR_SYNC)]
The NCC checks if there is a route with the timeslot type of the terminal within the
terminal uplink.
[exception: registration failure (error code: EC_TRAFFIC_TS_TYPE_NOT_IN_SF)]
The NCC checks if “max star SDR RTN” ≤ “max star PDR RTN”.
[exception: registration failure (error code: ARCST_EC_MSSR_EXCEEDS_MSPR)]
The NCC checks if “max mesh SDR RTN” ≤ “max mesh PDR RTN”.
[exception: registration failure (error code: ARCST_EC_MMSR_EXCEEDS_MMPR)]
The NCC checks if “default start SDR RTN HP” ≤ “default start PDR RTN HP”.
[exception:
registration
failure
(error
ARCST_EC_DSSR_HP_EXCEEDS_DSPR_HP)]
code:
The NCC checks if “default start SDR RTN LP” ≤ “default start PDR RTN LP”.
[exception:
registration
failure
(error
ARCST_EC_DSSR_LP_EXCEEDS_DSPR_LP)]
code:
The NCC checks if “default start SDR FWD HP” ≤ “default start PDR FWD HP”.
[exception:
registration
failure
(error
ARCST_EC_DSSF_HP_EXCEEDS_DSPF_HP)]
code:
The NCC checks if “default start SDR FWD LP” ≤ “default start PDR FWD LP”.
[exception:
registration
failure
(error
ARCST_EC_DSSF_LP_EXCEEDS_DSPF_LP)]
code:
The NCC checks if RCST management PID belongs to the defined range.
[exception: registration failure (error code: EC_MNGT_PID_OUT_OF_RANGE)]
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
48 / 266
If the terminal is manageable, the NCC checks if management PID is not already used by
another manageable terminal.
[exception: registration failure (error code: EC_DUPLICATE_MNGT_PID)]
If the terminal is manageable, the NCC checks if management IP address is not already
used by another manageable terminal.
[exception: registration failure (error code: EC_DUPLICATE_MNGT_IP_ADR)]
# NCC actions
The NCC registers the terminal, sends a positive “addRcst” acknowledge to the MD. The
MD sends a SNMP response to the NSM with error code “EC_OK”.
If the terminal is manageable, the NCC reserves the management PID and IP address for
the terminal.
6.2.1.1.2.4.3 SP-RCST Logon
The terminal sends a logon request to the NCC by the mean of a CSC burst.
# NCC checks
The NCC checks if the terminal is known (i.e. the terminal MAC address matches with one
of MAC address of the registered terminal list)
[exception: logon failed: the terminal is unknown]
The NCC checks if the terminal state allows to process a logon.
[exception: logon failed: the terminal state is "fine synchronization"]
[exception: logon failed: the terminal state is "synchronization maintenance"]
[exception: logon failed: the terminal state is "locked"]
The NCC verifies the number of logged terminal in the VSN.
[exception: logon failed: the max number of logged terminal for the VSN is reached]
The NCC verifies the number of logged SP-RCST in the VSN.
[exception: logon failed: the max number of logged SP-RCST for the VSN is reached]
The NCC verifies that there is a free SYNC burst available for the terminal.
[exception: logon failed: no more SYNC burst available]
The NCC checks if there is broadcast route in the list of the routes of the VSN.
[exception: logon failed: no traffic route for SP-RCST]
The NCC checks if the new CRA_SIG capacity of the RCST plus the amount of CRA_SIG
capacity currently used by all the logged RCST does not exceed the maximum reception
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
49 / 266
capacity of the NCC (“maxRxCapacity” is a configurable
“nccGeneralSystemConfig.xml” configuration file).
[exception: logon failed: invalid signaling connection for SP-RCST]
parameter
of
The NCC checks if there is enough capacity on the VSN route
[exception: logon failed: invalid signaling connection for SP-RCST]
The NCC checks if the number of available PIDs are enough to allocate the VSP_PID and
the VSP traffic PIDs.
[exception: logon failed: no more PID for SP-RCST]
# NCC actions
The NCC creates a multicast signaling connection (channel 0).
The NCC updates the “VSN”, “terminal”, “route” on-demand capacity parameters.
The NCC updates the on-demand “VSN” and “terminal” connection counters.
The NCC allocates a SYNC burst to the SP-RCST, and compute the superframe counter of
the first allocation.
The NCC performs the SP-RCST PIDs allocation (See the two following sections and
section 6.2.2.6.1)
The NCC builds and sends back to the SP-RCST a unicast TIM with RCST status set to 0.
The logon response contains the following descriptors:
• Sync assign descriptor
• Correction message descriptor
• Network layer information descriptor with Management return and forward PIDs,
Management IP address and subnet, MSN MAC address (same IODs as for RCST
and GW-RCST).
snmpset_d -v2c -cprivate -Oa 127.0.0.1
.1.3.6.1.4.1.637.56.4.40.1.1.1.0 a x.x.x.x
.1.3.6.1.4.1.637.56.4.40.1.1.2.0 a x.x.x.x
.1.3.6.1.4.1.637.56.4.40.1.1.3.0 d "x x x x x x"
.1.3.6.1.4.1.637.56.4.40.1.1.6.0 d "x x x x x x"
.1.3.6.1.4.1.637.56.4.40.1.1.7.0 d "x"
.1.3.6.1.4.1.637.56.4.40.1.1.8.0 d "x"
.1.3.6.1.4.1.637.56.4.40.1.1.4.0 i x
.1.3.6.1.4.1.637.56.4.40.1.1.5.0 i x
.1.3.6.1.4.1.637.56.4.40.1.2.3.0 i x
•
•
Logon initialize descriptor
Return interaction path descriptor as follows:
descriptor_tag
=
descriptor_length
=
Network_Routing_Label_loop_Count
=
Allocation_Desallocation_flag =
PID_flag
=
PID_loop_Count
=
PID_0
=
PID_1
=
PID_2
=
//
//
//
//
//
//
//
//
//
ipAddRCSTMngt
ipAddNMC
ipSubnetNMC
macDestMNGT
craSig
rbdcMaxSig
pidTxMNGT
pidRxMNGT
pidMMT
0xAE
9
0
0
1
2
VSP_PID
VSP traffic PID min.
VSP traffic PID max.
AEO-005479
SATLIFE
D311
VPI/VCI_flag
Route_ID_flag
Channel_ID
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
50 / 266
= 0
= 0
= 0
Semantics for the Return interaction path descriptor:
VSP_PID: this 13-bit field provides a PID to be used by the VSP to transmit
tables to the NCC.
VSP traffic PID min: this 13-bit field provides the lower bound of the range
of PIDs allocated to the VSP for its return traffic.
VSP traffic PID max: this 13-bit field provides the upper bound of the range
of PIDs allocated to the VSP for its return traffic.
6.2.1.1.2.4.3.1 VSP table PIDs
VSP table PIDs are allocated from the specific range of “VSP table PIDs” (See section
6.2.2.6.1).
VSP table PIDs are allocated/freed to SP-RCST at logon/logoff.
One PID is allocated per SP-RCST (“VSP_PID”).
6.2.1.1.2.4.3.2 VSP traffic PIDs
VSP traffic PIDs are allocated from the specific range of “VSP traffic PIDs” (See section
6.2.2.6.1).
VSP traffic PIDs are allocated/freed to SP-RCST at logon/logoff.
The number of traffic PIDs allocated to SP-RCST depends on the number defined in the
SLA (see section 6.2.1.1.2.4.1).
The NCC allocates a contiguous set of PIDs to each SP-RCST.
6.2.1.1.2.4.4 SP-RCST Fine synchronization
Upon SYNC burst reception, the NCC computes corrections (frequency, time and power)
to be applied by the terminal and adds a record into the next CMT.
If the frequency and time corrections are within thresholds, and if the "fine sync achieved"
bit of the M&C field of the SYNC is set, the terminal enters the “Synchronization
Maintenance” state.
[exception: synchronization failure: no SYNC during a configurable timeout]
[exception: synchronization failure: "fine sync achieved" bit not received]
6.2.1.1.2.4.5 SP-RCST Synchronization Maintenance
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
51 / 266
The NCC allocates timeslots on channel 0 according to the capacity defined in the terminal
profile (CRA_SIG).
The NCC does not apply SYNC burst masking mechanism to SP-RCST.
The NCC allocates the same burst every superframe as long as the SP-RCST stay
synchronized.
Upon SYNC burst reception, the NCC computes corrections (frequency, time and power)
to be applied by the terminal and adds a record into the next CMT.
[exception: synchronization failure: no SYNC during a configurable timout]
[exception: synchronization failure: corrections over thresholds]
6.2.1.1.2.5 Exceptions processing
•
registration failure (error code ):
The terminal registration is aborted.
The NCC sends a negative “addRcst” acknowledge to the MD.
The MD sends a SNMP response to the NSM with error code.
•
logon failed: the terminal is unknown:
The NCC sends a TIMu on all downlinks with a status: logon denied and transmit
disable (the TIM contains a contention control descriptor).
The NCC generates an entry in the log file.
•
logon failed: the terminal state is " fine synchronization":
The NCC sends a TIMu on the terminal downlink with a status: logon failed (the
TIM contains a contention control descriptor).
The NCC generates an entry in the log file.
•
logon failed: the terminal state is " synchronization maintenance":
The NCC sends a TIMu on the terminal downlink with a status: log-off (the TIM
contains a contention control descriptor).
The NCC generates an entry in the log file.
•
logon failed: the terminal state is "locked":
The NCC sends a TIMu on the terminal downlink with a status: transmit disable
(the TIM contains a contention control descriptor).
The NCC generates an entry in the log file.
•
•
logon failed: the max number of logged terminal for the VSN is reached:
logon failed: no more SYNC burst available:
The NCC sends a TIMu on the terminal downlink with a status: logon failed (the
TIM contains a contention control descriptor).
The NCC generates an entry in the log file with the relevant cause.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
52 / 266
•
•
•
•
logon failed: the max number of logged SP-RCST for the VSN is reached:
logon failed: no traffic route for SP-RCST:
logon failed: invalid signaling connection for SP-RCST
logon failed: logon failed: no more PID for SP-RCST:
The NCC sends a TIMu on the terminal downlink with a status: logon failed (the
TIM contains a contention control descriptor).
•
•
•
synchronization failure: no SYNC during a configurable timeout:
synchronization failure: "fine sync achieved" bit not received:
synchronization failure: corrections over thresholds:
The NCC removes the terminal from the CMT.
The NCC releases all resource allocated to the terminal, and updates the counters.
The NCC generates an entry in the log file with the relevant cause of
synchronization loss.
6.2.1.1.2.6 Post-conditions
Nominal case: the terminal is logged on and is assigned resources on channelId 0.
6.2.1.1.2.7 Priority
This is a fundamental use-case.
6.2.1.1.2.8 Open issues
The SP-RCST sends one SYNC burst every 18 superframe, whatever the SYNC burst is
(in band vs. out of band). It is assumed that the SYNC IEs and measurement IEs received
by the NCC are the same, whatever the SYNC burst is (in band vs. out of band).
6.2.2 Multicast routes and routes for VSP
6.2.2.1 Route configuration baseline in AmerHis
Routes are configured by the NCC craft terminal operator. Route configuration includes
the following steps:
• frequency plan configuration (operator)
up-link: carrier type, burst type, turbo code
down-link: CVR
• route definition (operator)
size and characteristics of the different routes: origin, type of carrier and timeslot,
destination (one TDM or broadcast), and route capacity
• "physical" mapping of routes on timeslots (automatic upon operator request)
from frequency plan and route definition the craft terminal allocates the up-link
timeslots to the routes
• Resource switching Algorithm (RSA, upon operator request)
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
53 / 266
this algorithm allows to compute the on-board processor configuration matching the
frequency plan and the route configuration
At each step, the NCC craft terminal checks the coherency of the configuration, for
example it verifies that the total capacity towards a given TDM is lower than the TDM
capacity (including broadcast).
After route to up-link timeslots mapping, the software generates the corresponding OBP
configuration, and according to OBP design constraints and system constraints (e.g. packet
ordering must be kept unchanged on down-link). Then, the operator can request the
generated configuration to be downloaded on-board. Finally, if the download is successful,
the operator can request a configuration update at given time and date.
The update command has two effects:
• on-board configuration update
• NCC configuration update (new route configuration)
6.2.2.2 Routes configuration in Satlife
The two new requirements are:
• to allow definition of multicast routes
• to define routes with specific shape for Video service providers
The main impact is on NCC craft terminal where is located the route definition and OBP
configuration software.
Modifications in Route configuration (NCC craft terminal)
• route definition:
• the operator has to define the type of route: unicast or multicast
• for multicast routes, provide the operator with the possibility to define the list of
destinations: from 1 to 4 TDMs
• Whatever the type of route (unicast, multicast or broadcast), the operator has to
define whether the route is dedicated to a video service provider.
• "physical" mapping of routes on timeslots
• routes must be mapped in the following order: first routes with specific shape for
video SP, then routes with 4 destination TDMs, 3, 2 and finally routes with one
destination TDM
• routes for video service providers are mapped manually by the operator. That means
that it is under his responsibility to correctly balance the video traffic load among
the segments.
• Resource switching Algorithm
• the RSA must take into account the new type of route (multicast). This will mainly
impact the RSA algorithm itself, the format of RSA output, and the generation of
OBP commands
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
54 / 266
Impact on NCC
From NCC point of view, there is no difference between multicast and broadcast routes.
Actually, multicast routes will be marked as broadcast. These routes can be used for any
service provider (video or not).
For video service providers, the NCC will use the route as configured by the NMC for the
VSN. There is no specific "tag" on this route, so it is the responsibility of the NMC to
allocate proper routes for this service.
For other services using multicast routes, i.e. IP multicast, the NCC will select the route
according to the following criteria:
• the route is associated to the VSN
• the route corresponds to the transmitting terminal (up-link and timeslot id)
• the route is marked as "broadcast" (it may be actually a multicast route),
Note that there should be only one route per VSN per terminal matching all the criterias.
For example if all the terminals of a VSN are located in only two coverages (out of 4), the
VSN may be configured with multicast routes with the two destinations (these routes are
marked as broadcast). The NCC will select these routes for multicast connections inside
the VSN.
The main modification on the NCC deals with the PID management. During the
connections setup, traffic PID are dynamically allocated by the NCC. As described in
section 6.2.2.6.1, PIDs ranges are defined for the multicast traffic. During the connection
set-up, the NCC selects a PID (or a set of PIDs) in the right PID range according to traffic
type.
6.2.2.3 Routes configuration detailed design (craft terminal)
6.2.2.3.1 Multicast routes configuration
In the RSA tool, at the connectivity matrix configuration level a new folder enabling the
multicast routes configuration is added. The same HMI than the one for unicast or
broadcast routes configuration is used. In that case (multicast routes configuration), the
operator must moreover define the destination of the multicast route.
Once created and configured, a multicast route is considered as a multicast route in the
RSA tool but as a broadcast route by the NCC.
Multicast routes mapping is managed as any traffic route (NCC, TRF or INAP route)
unless the route is a VIDEO route. In that case, the route mapping is manually managed by
the operator as described in the following section.
6.2.2.3.2 VSP routes configuration
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
55 / 266
For VSP routes configuration, a new type, as for CSC, SYNC, NCC, TRF or INAP routes,
is added. This new type is VIDEO. A VIDEO route can be an unicast route, a multicast
route or a broadcast route.
CSC, SYNC, NCC, TRF or INAP routes mapping is automatically managed by the RSA
tool while mapping must be managed by the operator for the VIDEO routes. This allows
the operator to define specific shapes for the VIDEO routes (It is here reminded that those
specific shapes are needed to reduce the jitter in case of video traffics by spreading the
carrier bursts to be used along the frame duration instead of grouping them in a frame
subpart as the automatic algorithm does).
6.2.2.4 Multicast routes and multicast PID management
6.2.2.4.1 Multicast Route
The NCC “routeConfig.xml” configuration file provides the NCC with the physical routes
configuration. Multicast/broadcast routes are identified by a destination “tdmPort” equal to
4 (corresponding to a broadcast destination in the Amerhis context).
The “routeConfig.xml” file is built by the RSA tool.
6.2.2.4.2 Multicast PID Management
The NCC “nccGeneralSystemConfig.xml” configuration file defines four ranges of traffic
PIDs:
• a range of traffic PIDs
• a specific range of traffic star multicast PIDs,
• a specific range of VSP traffic multicast PIDs,
• a specific range of VSP tables multicast PIDs.
The NCC shall ensure that there is no overlapping among the four ranges of PIDs.
The “nccGeneralSystemConfig.xml” file is parsed by NCC at start-up.
6.2.2.4.2.1 Traffic mesh multicast PIDs
Traffic mesh multicast PIDs are allocated from the range of “traffic PIDs”.
PIDs are allocated in decreasing order according.
Traffic mesh multicast PIDs are allocated/freed to RCSTs at point-to-multipoint
connection establishment/release.
One PID is allocated per point-to-multipoint connection i. e., per channel [5..14].
6.2.2.4.2.2 Traffic star multicast PIDs
Traffic star multicast PIDs are allocated from the specific range of “traffic star multicast
PIDs”.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
56 / 266
Traffic star multicast PIDs are allocated/freed to GW-RCSTs at point-to-multipoint
connection establishment/release.
One PID is allocated per GW-RCST (channel 15) at the first point-to-multipoint
connection setup and released at the last point-to-multipoint connection release.
6.2.2.5 Table Handling for Video Broadcast Service
6.2.2.5.1 Table handling baseline in AmerHis
Tables are divided into four categories:
• category 1:
• tables totally generated by the NCC,
• tables contents are defined in NCC configuration files
• tables of this category are: CMT, FCT, NIT, FLS-PMT, RMT, SCT, SPT, TBTP,
TCT, TDT, TIMb, TIMu, MMT
•
•
•
•
•
category 2:
tables assembled by the NCC from pieces of table
tables of this category are: PAT
data for RCS service is contained in NCC configuration files
data for video broadcast service is provided to the NCC by the NMC, the NMC
operator stores a file on the file server and inform the NCC
• category 3:
• tables built by the NCC by concatenation of table sections
• table section are provided to the NCC by the NMC, i.e. the NMC operator stores a
file on the file server and informs the NCC
• tables of this category are: CAT, SDT, BAT, EIT, RST
• category 4:
• tables not handled by the NCC, only the PMT which is transmitted directly by the
service provider RCST.
6.2.2.5.2 Table handling for SatLife
For SatLife the tables for video broadcast service are received by the NCC through the air
interface. Then the NCC must build the tables form the received information, increase the
table version number each time a table is changed and transmit the table towards the proper
destination.
It is assumed that each service provider transmits a MPEG compliant transport stream
except that the PIDs are changed with respect to the ones imposed by the standard (see
table below). In the NCC configuration, a range of PIDs will be reserved for transmission
of these tables. Each video service provider will be allocated a subset of the reserved PIDs
for transmission of its table to the NCC.
AEO-005479
SATLIFE
D311
Table
PAT
CAT
NIT
BAT
SDT
EIT
RST
TDT
SATLIFE-AEO-SYS-DD-3
Name
Program Association
Conditional Access
Network Information
Bouquet Association
Service Description
Event Information
Running Status
Time & Date
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
57 / 266
PID (Hex)
0x0000
0x0001
0x0010
0x0011
0x0011
0x0012
0x0013
0x0014
Table 6-1 PIDs defined by the standard
Processing of tables of category 1
Tables of category one are handled in the same way as in AmerHis system. They are built
by the NCC. The data to build the tables are contained in the NCC configuration files.
Processing of tables of category 2
For these tables, the NCC has to check all the received tables, extract the proper
information from these tables and build the full table.
For example the PAT structure is shown below (reserved bits are skipped):
PAT
section header
table_id
section_syntax_indicator
0
section_length
transport_stream_id
version_number
current_next_indicator
section_number
last_section_number
value (comments)
0 (means PAT section)
1 (defined by MPEG standard)
0 (defined by MPEG standard)
number of bytes following (including CRC)
id of the transport stream carrying the PAT
version of the PAT (incremented at each change
in the PAT)
1 (current applicable PAT)
(generally will be 0, one section only)
Program loop (one entry per
program)
program_number
reserved
program_map_PID
if program number # 0: PID of the PMT
describing the program, or PID of the NIT if
program number = 0
CRC32
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
58 / 266
Table 6-2 PAT structure
The PAT includes a loop with one entry per program contained in the transport stream. An
entry simply includes the program number and the PID of the PMT describing the
program. The NCC receives one PAT per video SP. A PAT is identified by the PID (set in
video service provider profile) and its table_id (0). The NCC builds one PAT per
destination TDM containing:
• one entry for FLS (FLS-PMT) program and one entry for RCS program (RMT):
from data in its configuration files
• one entry per program sent to this down-link: PIDs and program numbers and list
of destinations are set by configuration
The PAT is transmitted always, even when no video-SP is active.
In AmerHis, only the PAT belongs to this category. For SatLife, it is foreseen that the CAT
and the NIT will be processed as category 2 tables (tbc).
Processing of tables of category 3
For category 3 tables, the NCC receives sections from the video service providers. The
NCC determines the type of table according to the table_id.
For each table, the NCC concatenates the received sections to form a complete table. This
includes section header update, renumbering of sections, version number update each time
a section is changed and CRC computation.
For each video SP, the NCC will be configured with:
• a PID for partial table reception (or a set of PIDs tbc)
• a bouquet_id
• transport_stream_ids
• service_ids
Note that, like every RCST, the video SP-RCST shall be identified by its group_id and
logon_id.
The NCC checks that the video-SP RCST is logged, and stops transmission of data related
to this video-SP if the terminal is not logged.
Tables of category 4
These tables are sent directly by the video SP. They are not processed by the NCC.
6.2.2.5.2.1 Low cost terminal preliminary assessment
6.2.2.5.2.1.1 Presentation
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
59 / 266
Low costs terminal are terminals with frequency hopping limitation: a minimum "one
timeslot guard time" is required between two successive time slots allocated to the terminal
on different carriers. The current resource control algorithm, implemented in the NCC, is
not adapted at all to take this limitation into account. Supporting such terminals would lead
to a complete redefinition of the resource control algorithm which is not affordable within
the SatLife contract.
Three simplified solutions, with lower performances, have been presented in order to
minimize impact on NCC. These solutions are presented hereafter.
6.2.2.5.2.1.2 Solution 1: specific routes
This solution consists in defining specific routes with only odd or even timeslots, e.g.
timeslots 0, 2, 4, etc…. avoiding the allocation of consecutive timeslots to terminals using
these routes.
6.2.2.5.2.1.2.1 Impact on NMC
Modification of controls when allocating a service to a RCST: maximal data rate values to
be modified for low cost terminals.
6.2.2.5.2.1.2.2 Impact on NCC
RSA
The RSA should allow to configure specific routes, and to mark them as "low cost
terminal" routes. It has to be noted that all low cost routes of the same type must use the
same timeslots (even or odds).
For example:
• low cost route 1 from up-link 1 to down-link 1 is made of even timeslots
• low cost route 2 from up-link 1 to down-link 2 is made of odd timeslots
• a low cost terminal having two connections, one towards down-link 1 and one
towards down-link 2, will not be able to use both routes
Note that the signaling connection towards the NCC is always active, so a terminal with
traffic has at least two connections.
Remaining timeslots will be mapped on standard routes.
RCST configuration
The NCC should detect that the RCST is a low cost terminal by looking at the frequency
hoping bit of the CSC burst.
CAC
For low cost terminals, the maximum terminal capacity must be divided by two with
respect to standard terminals.
The remaining timeslots would be allocated to "standard" routes. Therefore the standard
routes will include several carriers with only half the timeslots. This is not taken into
account into the CAC today, therefore, it is clear that CAC will not work properly since it
will accept connections that are not feasible due to the "shape" of the routes.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
60 / 266
Resource control
Low cost terminal must be allocated capacity on low cost routes only.
A specific mask must be defined for SYNC bursts.
Standard terminals must be allocated capacity on standard routes only.
6.2.2.5.2.1.3 Solution 2: addition of a mask in RRC
This solution consists in defining a mask for low cost terminals in resource control. For
example all "even" timeslots could be masked. This way, it would prevent the resource
control to allocate consecutive timeslots to low cost terminals.
6.2.2.5.2.1.3.1 Impact on NMC
Same as solution 1.
6.2.2.5.2.1.3.2 Impact on NCC
RCST configuration
Same as solution 1
CAC
When a connection is requested, the CAC verifies it is compatible with:
• the calling SLA: control unchanged
• the capacity on the VSN on the involved routes
• the route length (maximal temporal length): this control must be changed in order to
consider the specificity of low cost terminals either by defining a specific "maximal
temporal length" for low cost terminals (impact on RSA) or by physical capacity
Resource Control
A specific initial mask must be used for low cost terminals, in order to mask all even or all
odd timeslots.
A specific mask must be defined for SYNC bursts, matching the one defined for TRF.
Standard terminals would use standard masks (SYNC and traffic).
6.2.2.5.2.1.4 Solution 3: restriction to one carrier
The resource control would have to allocate timeslots on a single carrier for low costs
terminals. This way, the terminal would be able to use all timeslots but without frequency
hopping.
This solution is not feasible for both system and NCC implementation reasons:
•
if a terminal has more than one connection with different destinations, it will use
different routes, so most likely different carriers: for example a traffic connection
AEO-005479
SATLIFE
D311
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
61 / 266
and the signaling connection to the NCC. Therefore this solution can be envisaged
only for terminals with only one connection towards the
the resource control operates in several steps: first CRA is allocated, then RBDC in
the remaining "minimum guaranteed bandwidth" of the VSN, then RBDC in the non
guaranteed bandwidth and finally FCA. This does not allow to guarantee the use of
a single carrier to low cost RCSTs.
resource control keep trace of used timeslots positions per terminal (for avoiding
two timeslots in same position but on different carriers), but not of time and
frequency coordinates of timeslots allocated to each terminal.
when looking for a free and unmasked timeslot, the resource control uses a timeslot
mask which indicates which timeslots are usable for a given terminal but it gives no
information on the carrier on which the terminal
On the other hand, definition of routes with only one carrier is not suitable since it would
be very inefficient, and it would impose to assigned routes to terminals.
6.2.2.5.2.1.5 Preliminary conclusion on low cost terminal
As a conclusion, it appears that only solution 2 can be envisaged. But more analysis is
required to have a definitive answer (yes or no) for this feature, in particular for
performances and cost impacts.
Furthermore, it has to be noted that the terminal capacity is divided by two with respect to
a standard terminal, so the commercial interest of such a solution must be confirmed.
Note: no modification in the NMC are foreseen, so all NMC impact must be implemented
in another way, for example by the craft terminal.
6.2.2.6 Miscellaneous
6.2.2.6.1 PID ranges
Today the NCC is configured with the following PIDs:
• PIDs for DVB-S, DVB-RCS tables
• PIDs for OBP control
• PID range for the MMTs
• PID range for RCST management (RCST to NMC)
• PID range for traffic
Three additional PID ranges are added for:
• transmission of (partial) tables from Video-SP to the NCC: VSP table PIDs
• video traffic: VSP table PIDs
• multicast traffic. This range can be divided into two sub-ranges:
• star multicast traffic
• mesh multicast traffic
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
62 / 266
7. TRANSPARENT HUB DESIGN
7.1 Overview of the SatLink Gateway Architecture
The main components of the Nera SatLink Gateway are:
• Network Control Centre (NCC)/Network Management System (NMS). The
Network Control Centre is the interface between the Operator/ISP and the Gateway
and assures the traffic management, the system supervision and the protocol
handling.
• Forward Link Subsystem (FLS). The FLS consists of an IP/DVB gateway,
multiplexer and RF system for transmission of end user traffic and network
signaling.
• Return Link Subsystem (RLS). The Return Link Subsystem handles the TDMA
burst receiver channels, carrying return channel traffic signaling and end user traffic.
• Reference and Synchronization Subsystem. This equipment delivers the
synchronization and timing information in the Gateway for synchronization of the
entire satellite network.
• Routers and Switches
The Nera SatLink Gateway provides all the required interfaces and management functions
necessary to set up a DVB-RCS based service. Next figure gives an overview of the
different components of the SatLink Gateway.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
63 / 266
RF
TWTA Switching
BUC 1
LNA
RF Equipment
Redundancy Switching
Controller
BUC 2
Redundancy
Switch
Modulator
2
BDC
RLS
FLS
Modulator
1
L-band
Down Converter
ADC/AGC
ASI Switch
Demodulator
MUX/IPE 1
SatLink
8110
Traffic Ethernet Switch
MUX/IPE 2
SatLink
8110
Management
Ethernet Switch
FEC
Decoder
GPS Antenna
Reassembler
Clock and
Frequency
Reference
Network
Management
System
IP Router (Firewall)
VoIP
Gateway
VoIP Gatekeeper
Signalling Unit
Legend
Equipment to be
supplied by Nera
Internet
PSTN/ISDN/SS7
Equipment to be supplied
by Buyer
Redundant Equipment
Figure 7-1 Nera SatLink Gateway - main components
7.2 Forward Link Subsystem
The Forward Link Subsystem is used to transmit user traffic from the terrestrial network to
the satellite terminals. Its main function is to encapsulate the user IP datagrams received at
the Gateway terrestrial interface into MPEG-2 streams according to the DVB-S standard.
System broadcast and terminal specific signaling from the NCC is multiplexed onto the
appropriate forward transport stream after the IP encapsulation of user traffic.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
64 / 266
7.2.1 Forward Link Subsystem components and integration
The FLS of Nera SatLink Gateway is designed and implemented based on the philosophy
of generic, modularity, and using standard equipment in the market. The FLS consists of a
standard DVB-S compliant Modulator, a MPEG Video/Audio/Data Multiplexer (MUX),
an IP to DVB DSM-CC/MPEG-2 Encapsulator (IPE), and an NCR-generator & SI-table
insertion unit. Next figure shows the architecture of the FLS.
FLS-01
FLS-00
User
traffic
IP Encapsulator
IPE-00-00
MUX
MUX-00-00
SI-tables
Time ref.
MOD
MOD-00-00
RF
Antenna
NCR & SI
NCR-00-00
Figure 7-2 Forward-Link Subsystem Block Diagram
The generic and modular design and implementation of the FLS gives the flexibility to
replace the component IPE, MUX, and the Modulator from any vendor on the open
market. The NCR-generator & SI-table insertion unit is designed and developed by Nera. It
provides the NCR-generation and SI-table insertion functions for broadcasting on the
forward-link.
Typical Modulator Features:
• Support ETSI standard EN 300 421 (DVB-S: QPSK)
• Variable symbol rate operation: 1 to 48 Msymbol/s
• User selectable spectrum roll-off factor: 0.2, 0.25, 0.3 and 0.35
• IF output: 50 – 180 MHz, tuneable in 1 kHz steps (Option: L-band output: 950 –
1750 MHz)
• Low spurious output levels
• Front panel LCD display and keypad
• RS-232/485 control, backward compatible with System 3000 satellite modulator
• Easy software upgrades (remote Ethernet)
• Dual-redundant Ethernet control
Typical MUX Features:
AEO-005479
SATLIFE
D311
•
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
65 / 266
Output rate up to 100 Mbit/s
Reflex™ Statistical Multiplexing
Re-multiplexing by service, component or PID
Industry standard connectivity
SNMP remote monitoring
Typical IPE Features:
• DVB-S compliance: EN300 421, ISO/IEC 13818-1, ISO/IEC 13818-6, and EN301
192
• Quality of Service (QoS) Function
• Flexible Configuration and Management Options
• Monitoring and Statistics Logging
• Dependable Redundancy Support
The choice of IPE, multiplexer and modulator will depend on RFP specifications and
customer preferences. If no specific requirement or customer request imply otherwise,
Nera standard configuration is the use of Skystream Source Media Router SMR-25 and
Newtec DVB QPSK 45/60Mbaud Modulator. The SMR-25 is a combined IPE and
multiplexer. The data sheets describing the capabilities of this standard equipment can be
provided on request.
7.3 Return Link Subsystem
7.3.1 Return Link Subsystem architecture
The Return Link Subsystem (RLS) of the Nera SatLink Gateway is a modular
implementation of CSI, CCU, and FE-RX boards in a VME. A brief description of each of
the main elements constituting the RLS is given below.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
66 / 266
1 PPS
VME MotherBoard
(VMEMOB)
VME Bus
Power
CPU, I/O
Control Functions,
HW device drivers
Hub
Control LAN
RX L-band & Freq.ref.
I/O, Control Functions and
HW Device Drivers
DSP
DSP
DSP
I/O, Control Functions and HW
Device Drivers
DSP
Ethernet
Dual 100 Base-T
DDS board
2 spare PMC
modules
Down
Down
conv.
conv.
Decode Decode
Synch. Synch.
A/D
A/D
Down
conv.
Decode
Synch.
Down
conv.
Decode
Synch.
A/D
A/D
RF
RF
to
to
IF
IF
Down Down
conv. conv.
A/D
freq.
ref.
RF
RF
to
to
IF
IF
Down Down
conv. conv.
x4
Control, Supervision
& I/0 Board
(CSI)
Channel Codec
Unit RX Board
(CCU-RX)
x4
Front End RX
Board
(FE-RX)
Figure 7-3 RLS system architecture
VMEMOB
Custom-made VME64x board, which includes RF, frequency reference, and 1 PPS
distribution.
CSI
The CSI board is the interface towards the NCC, and it is the system controller in the VME
rack. De-multiplexing of decoded MPEG packets and subsequent de-capsulation from
MPEG to IP packets are performed in a software module running on the CSI board, which
is a PowerPC processor board for VME. Reassembled IP packets are output over the
Ethernet interface of this board. CSI-board supports simple and user friendly control,
configuration, and monitoring functions. Configuration is done via SDL signals carried as
UDP/IP packets over the Ethernet. Supervision and fault monitoring is done via an SNMP
client hosted on the CSI board.
CCU-RX
This is a commercially available DSP board from Pentek equipped with a down-converter,
decoder, and synchronizer (DDS) mezzanine. The DDS is a quad down-converter/decoder
mezzanine, and thus, the CCU-RX is capable of demodulating four channels. Digital
down-conversion is performed in a digital receiver chip from GrayChip residing on the
DDS mezzanine. It does quadrature demodulation to base-band, filtering and sample-rate
adaptation. The output is 16-bit signed I- and Q-values. The demodulator is a software
module running on a C6201 DSP, and handles burst acquisition, synchronization, and
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
67 / 266
demodulation. The output is soft-decision values that are input to the decoder module. The
decoder module is implemented in a FPGA on the DDS mezzanine, and handles FEC
decoding, de-scrambling and CRC checking – if applicable – of received bursts. Decoded
bursts are then sent over the VME bus for further processing by the CSI board.
FE-RX
This unit consists of four “RF to IF Down converters” and a highly stable frequency
reference used by the DDS mezzanine. The interface towards the CCU-RX is in the front
using coax connectors. Frequency reference and RF input are via the back-plane. This is a
VME-board, which supports analogue down-conversion of 4 independent channels. The
purpose of this unit is to pick out any 5MHz band of the L-band input signal, and convert it
down to an appropriate low IF, i.e. 15MHz.
Figure 7-4 Picture of a RLS sub-rack
The next figure shows a fully equipped unit comprising 6 4-channel CCU board with 6
corresponding Fe-Rx boards and one CSI-board for the entire sub-rack to the left. In front
of the sub-rack, a CCU board is shown.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
68 / 266
7.3.2 DVB-RCS Return Channel - Demodulator
The DVB-RCS return channel receivers are characterized by the following parameters:
• QPSK modulation
• 500 MHz tuning bandwidth – from 950 – 1450 MHz3
• Symbol rates from 128 ksymbols/second to 1,2 Msymbols/second
• MPEG or ATM traffic burst profiles4
• Turbo decoding
• Turbo FEC rates from ½, 2/3, ¾, 4/5,and 6/7
• Supports frequency hopping between all channels in a VME chassis
• Scaleable architecture – additional receivers added in increments of 4 channels
• Throughput per VME chassis of 15 Mbit/sec measured at decoder output level (i.e.
either MPEG or ATM packet level)
• Concatenated coding (Viterbi and Reed Solomon) is optional. The FEC rates are
compliant with ETSI EN 301 790.
Frame structure, data rates and FEC rates can be configured by the Gateway operator
individually per return channel.
7.4 Reference and Synchronization Subsystem
The SatLink Network is synchronized by means of a GPS Reference and Synchronization
Subsystem (REFS) located in the SatLink Gateway. The REFS subsystem is third-party
equipment from Datum. The main function of the REFS Subsystem is to provide time and
frequency reference signals to other subsystems in the GW.
Specifically, the functions of the REFS subsystem are:
• High stability 10 MHz frequency reference with good phase-noise characteristics
• 1 pulse per second (pps) signal locked to UTC from GPS
• Distribution of UTC (derived from the GPS signal) over the network using the
standard protocols such as TP, NTP, and SNTP.
7.5 Network Control Center Subsystem
The main functions of the NCC are:
• DVB RCS System table generation and distribution
• Traffic session handling
3
4
By use of a frequency-converter, 70 MHz IF interface can be supported.
The SatLink Gateway can be configured to handle MPEG or ATM traffic profile, but not both profiles simultaneously.
AEO-005479
SATLIFE
D311
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
69 / 266
Terminal logon handling
Terminal logoff handling
Terminal synchronization (time, frequency, and power control)
Radio Resource Management
Terminal capacity request handling and assignment (including TBTP generation)
Adaptive FEC assignment to mitigate poor link conditions
Terminal statistics logging
Network management
The different NCC functions are briefly described in the following.
7.5.1 SI table generation
As described earlier, the NCC generates only the DVB-RCS SI tables. The system specific
DVB-RCS tables are usually configured at an initial configuration step, and then these are
not changed during system operation. Such tables are the SCT, FCT, TCT. The contents of
these tables are configured by the operator through the GW NMS.
The terminal specific DVB-RCS tables are generated during system operation, based on
terminal logon, capacity request, and terminal synchronization behavior. Such tables are
the unicast TIM, CMT, TBTP. These tables are changing dynamically, thus table
generation is one of the most important tasks of the NCC. In order to be able to generate
these tables, the table generation module is closely co-operating with the RRM and the
traffic handling module. The outputs from the RRM and traffic handling modules are
actually the input to the table generation module.
Whenever a terminal attempts to log on to the system by sending a CSC burst, the NCC
answers with sending a unicast TIM table. If the terminal is allowed to the system and
there are enough system resources available, the NCC will send a logon successful
message in this TIM. In the opposite case the NCC will send a unicast TIM with a negative
response, this TIM containing also the cause for the negative response.
The CMT table is generated for already logged on terminals, this table makes possible for
terminals to remain synchronized with the GW. The RLS measures the frequency, time,
and power of the synchronization bursts sent by every terminal. The NCC then computes
the necessary time, frequency and power corrections for each terminal, fills in these values
in a separate CMT individually addressed for the terminals, and transmits it on the forward
link.
The TBTP table is used to signal the capacity allocated by the RRM for the logged on
terminals. Terminals sending traffic are sending capacity requests towards the NCC, and
then the RRM module in the NCC decides about the amount of timeslots and which
timeslots should be allocated to a given terminal. The TBTP just contains the timeslots that
the RRM module has allocated to the terminal.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
70 / 266
The TBTPs are transmitted to the terminals once every superframe.
7.5.2 Traffic session handling
The terminal logon, logoff, and synchronization procedures are as defined in the standard.
A terminal logs on by sending a CSC burst using slotted ALOHA. Information needed to
access the slotted ALOHA carrier is provided in the Forward Link Signaling tables
broadcast from NCC. The CSC burst sent from the terminal contains the terminal MAC
address and terminal capabilities5 such as MF-TDMA capability, frequency hopping range,
MPEG or ATM traffic profile, one or two forward link receivers etc.
Upon receiving logon request, authentication and authorization is performed. If access
rights are validated, the NCC checks that sufficient SYNC resources are available and
thereafter retrieves Service Level Agreement parameters as defined in the subscriber
profile in order to generate the correct logon response.
As part of the logon procedure the terminal performs fine synchronization consisting of
SYNC burst transmission to the NCC and reception of time, frequency, and power
corrections from the NCC. Once fine synchronization is achieved, the terminal is in a state
ready to transmit data. Throughout the logged on period, the terminal will perform
synchronization maintenance by means of periodic SYNC burst transmission resulting in
correction measurements from the NCC.
When the terminal has user traffic to transmit, it will send capacity requests to the NCC.
The NCC will assign timeslots to the terminal and convey this assignment to the terminal
in the Terminal Burst Time Plan transmitted over the Forward Link Signalling.
A terminal can log off from the system in several ways. When a terminal does not want to
send traffic any more, it can send a logoff request in SYNC burst, this being a normal
logoff operation. On the other hand, an abnormal logoff can occur if the terminal misses
synchronization with the GW. In both cases the NCC will remove the terminal from the list
of active terminals, and it will perform internal cleanup.
A special state for the terminals is the so-called “hold state”, when the terminals are
ordered by the GW to cease traffic transmission.
7.5.3 Radio Resource Management
One of the most critical and resource demanding functions of the NCC are the RRM,
namely return link capacity allocation for the terminals logged on to the system.
The Nera SatLink Gateway has advanced radio resource management algorithms ensuring
efficient utilization of the return channel capacity. All four capacity request categories
5
See ETSI EN 301 790 for a complete list of the RCST capabilities that can be signalled in the CSC burst.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
71 / 266
defined in the standard are supported. The Gateway operator can configure capacity
requirements per terminal or per terminal population6:
• CRA
Continuous
Rate
Assignment
It is possible for the operator to define the reserved CRA capacity per hour in
subscriber profile.
• RBDC
Rate
Based
Dynamic
Capacity
This capacity is requested dynamically by the RCST. The maximum RBDC rate can
be defined in the subscriber profile.
• VBDC
Volume
Based
Dynamic
Capacity
The capacity is normally requested dynamically by the RCST. However, it is
possible to define a minimum VBDC allocation size for all terminals in a Service
Level Group in order to ensure a minimum throughput for an active terminal.
• FCA
–
Free
capacity
assignment
The terminal subscriber profile decides whether the RCST shall be given FCA
capacity
or
not.
To avoid very small allocations per RCST when many terminals are allocated FCA
capacity, it is possible to define a minimum FCA allocation size for all terminals in
a population group.
The Nera SatLink Gateway supports RCST grouping levels which correspond to a kind of
capacity allocation priority ordering. Terminals belonging to a superframe ID can be
divided into several allocation ordering levels, where each level represents a Service Level
Group (SLG). For each Superframe ID, the operator shall configure the number of Service
Level Groups and the percentage of the total available capacity that should be defined for
each capacity category within the group.
Quality of Service support
The Nera SatLink system support a differentiated services like QoS, for allowing
prioritisation of real time traffic such as VoIP (Voice over IP), and thus assuring necessary
quality for this type of traffic. Currently there are defined 2 traffic classes, class 1 for realtime traffic such as VoIP, and class 0 for non real-time traffic such as file transfer or web
browsing. Class 0 is the default class.
6
A terminal population is the ensemble of terminals assigned to a given superframe (as defined in the standard).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
72 / 266
In the GW the following capacity parameters are configurable for a terminal group (SLG):
• CRA guaranteed capacity (kbps)
• CRA maximum capacity (kbps)
• CRA excess weight (weight factor)
• RBDC guaranteed capacity for class 0 (kbps)
• RBDC guaranteed capacity for class 1 (kbps)
• RBDC maximum capacity (kbps)
• RBDC excess weight (weight factor)
• VBDC guaranteed capacity for class 0 (kbps)
• VBDC guaranteed capacity for class 1 (kbps)
• VBDC maximum capacity (kbps)
• VBDC excess weight (weight factor)
• Order in the MF-TDMA slot assignment sequence (lowest group number first)
The excess weight controls the distribution of excess capacity between terminal groups.
Class 0 inherits unused capacity from class 1 within the group. The terminal issues as
default all dynamic requests for class 0, but can be configured to differentiate capacity
requests into class 0 and class 1.
The following terminal profile parameters must be configured for each terminal. The
configuration can be carried out either through the common default profile associated with
the SLG or individually in the terminal profile:
• Committed CRA level (kbps)
• Maximum RBDC rate request for class 0 (kbps)
• Maximum VBDC request volume for class 0(bytes)
• Maximum RBDC rate request for class 1 (kbps)
• Maximum VBDC request volume for class 1 (bytes)
When serving active terminals within a terminal group, the Radio Resource Manager
employs a fair sharing policy called Weighted Fair Sharing (WFS) for class 0. This scheme
retains the service level differences between the terminals with different class 0 request
limitations, even at high congestion levels. All class 0 requests within a congested group
are affected. For class 1, a first-come-first-served policy is used to distribute capacity
between requesting terminals, regarding contiguous requests within each terminal group.
Adaptive FEC and symbol rate
Based on return link quality measurements the Radio Resource Management system is able
to dynamically direct terminals to return channels with lower or higher FEC rates as the
quality of the return link signal gets worse or better. The RRM supports also fully adaptive
symbol rates functionality, in the same manner as for the adaptive FEC rates, to
compensate the channel quality variations.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
73 / 266
The selection of FEC and symbol rate is based on choosing the most adequate combination
of the two parameters, FEC and symbol rate, as a function of a strictly increasing interval
of signal-to-noise ratios (not a selection of FEC rates first and symbol rates second). The
possible combinations of FEC and symbol rate, internally called Return Channel Rate
(RcRate) and identified by an index, are derived off-line and stored in the NCC in a table.
The target Packet Error Rate (PER) vs. Eb/N0 is configurable from NMForms for each
superframe.
The actual combinations used by the system (i.e. rows) will depend on timeslot
configuration of the superframe configuration of the system. The Radio Resource
Management (RRM) has knowledge of the timeslot types that are defined for a given
superframe. Available through the subscriber profile, the RRM also has information of the
maximum FEC and maximum symbol rate that a given terminal can be assigned.
The signal strength is measured for a given terminal. This value is used to look up in the
table, the best combination of FEC/symbol rate that the terminal can handle. Only the
signal power of sync slots are measured, but measurements are based on the average of an
operator configurable number of sync slots.
If there are shortage of timeslots with lower index, the RRM scales down the requests for
the congested timeslot types before sharing capacity between Terminal Groups (SLGs) and
terminals. Note that if the signal measurements indicate that none of the time-slots types in
the superframe will result in the wanted PER, timeslots with the lowest available index
(best fitted) will be assigned.
Terminal statistics logging
RRM collects statistics about bandwidth utilisation (per RCST and overall) and stores it in
the NMS database for further analysis by the Gateway operator.
7.6 Network Management Subsystem
An overview of the system is given here. In another section it will be described more
concretely the design of the centralized NMS.
7.6.1 Network management
Web interface
Fault Management, Configuration Management, Accounting Management and
Performance Management operator interfaces are run via a Web interface. The operator
can use the same interfaces locally on the Intranet or from a remote location via the
Internet. This allows the Gateway operator to have full control of the Gateway from a
remote location.
Authentication, Authorization, and Accounting
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
74 / 266
The authentication and authorization procedure verifies that the terminal is registered with
a user profile in the authorization table. All capacity requests from the RCST will be
checked against this user profile to ensure that the requests are within the specified
minimum and maximum limits for that terminal. The terminal can be denied access to the
system certain hours/days by specifying time limitations in the user profile.
Accounting can be based on either the terminal user profile (subscription categories) or on
volume based accounting. Volume based accounting can be done per terminal or group of
terminals. The volume based accounting information is used for billing purposes and to
control the total traffic volume for single RCSTs or groups of RCSTs during a specified
time interval. Three types of volume control can be specified in the user profiles:
• Unlimited: The volume is indicated but there are no restrictions to the total volume
sent/received by the RCSTs.
• Limited with an option: The terminals are allowed to continue transmitting data, but
against some kind of extra charge
• Strictly limited: The terminals are not allowed to transmit any more data when the
maximum volume is reached.
RADIUS interface
The RADIUS interface performs a couple of operations:
• collection of volume based accounting data,
• gathering of statistics for the number of IP packets and the number of octets that are
sent to and received from the terminals
• keeping track of the duration of the terminal sessions.
The accounting data is stored it in the NMS database for billing, statistics and further
analysis by the Gateway operator.
RADIUS accounting requests can be handled by the Gateway’s own RADIUS server or the
requests can be distributed to one or more external RADIUS servers. External RADIUS
servers will typically be hosted by the ISPs that own the terminals.
Accounting information stored in the RADIUS server locally in the Gateway can be
automatically transferred to billing centers via FTP for processing by the ISP. RADIUS
interface for authentication and authorization also allows COTS equipment such as IP
Routers and VoIP Gateways to access subscriber profiles in the Gateway for
authentication/authorization and for resource allocations.
7.6.2 Terminal (Subscriber) management
Terminal configuration
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
75 / 266
The RCST terminal profile configuration is done in the Network Management system. The
RCST subscriber profile contains the following parameters:
• Username
• MAC address
• Network ID
• Superframe ID
• Static IP address and subnet mask for forward link routing (for operator viewing, not
used to set IP address)
• Maximum return channel symbol rate
• Maximum return channel FEC rate
• CRA capacity profile (per hour)
• Maximum RBDC capacity
• Maximum VBDC capacity
• Activation of FCA allocation
• Maximum total capacity allocation
• Guideline parameter for return channel capacity allocation algorithm
• Forward channel PIDs
• Return channel PID
• Service Level Group
• Barring status
There is also available a batch update functionality which allows ISPs to upload large
configuration files, such as subscriber data, to the Gateway.
Terminal performance monitoring
The Nera SatLink Gateway provides tools for Service Level Agreement (SLA) monitoring.
Typical parameters to monitor are:
• CRA capacity requested and assigned per terminal, and assigned per terminal
population
• RBDC capacity requested and assigned per terminal, and assigned per terminal
population
• VBDC capacity requested and assigned per terminal, and assigned per terminal
population
• FCA capacity assigned per terminal and per terminal population
• SYNC loss over last x number of expected SYNC slots per y number of seconds
• Any missing pre-assigned SYNC burst will be saved and could generate an alarm
message on the Gateway interface (the threshold of this alarm is configured by the
Gateway operator)
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
76 / 266
Statistics collected for a terminal population are:
• Total capacity assigned (all capacity categories together)
• Number of logon attempts denied by RRM due to lack of sync slots
• Allocated bandwidth and available bandwidth per timeslot type and superframe ID
• Volume of requests served per capacity request category and service level group.
The volume is measured in kbps for all categories
The statistics are made over an operator configurable time interval (not less than 5
seconds).
The Nera SatLink Gateway also provides tools for monitoring of physical link
performance. The following parameters can be monitored per terminal:
• Burst signal level
• Burst Eb/No
• Preamble Ver
• Burst frequency offset
• Burst time offset
The interval for updating monitoring information is configurable. The data are stored in the
NMS database for statistics and for further analysis by the Gateway operator.
7.6.3 Station management
Fault events from all network elements and applications in the Nera SatLink Gateway are
reported from SNMP Agents within the network elements to an HP OpenView Network
Node Manager. The Fault Management solution in the Nera SatLink Gateway can be
integrated with existing HP OpenView installations where such installations exist.
The HP OV NNM in the GW has two main functions:
• monitoring of the physical GW entities and applications running on the GW site,
such as alarm reporting in case of fault events on these entities
• remote monitoring of the terminals via SNMP, based on special RCST commands
integrated into HP OV NNM
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
77 / 266
7.7 SatLink Gateway Redundancy Architecture
RLS
CSI-TRF-00
CSI
CCU
FERX
CSI-MGMT-00
FWD-TRF-00
MUX
IP Encap.
Modulator
MUX-00
FWD-MGMT-00
RF
MOD-00
FLS
NMS
ASI Monitor
ASI-MON-00
Ref&Sync
REFS-00
NCR Generator
OV-SRV-00
MC-00
NCR-00
Power Switch MGMT-SW-00
PWR-SW-00
EXT-LAN
Internet
( Ext
Test
Load
TRF-SW-00
ROU-00
TRF-LAN
On
Line
On
Battery
Smart Replace
Boost Battery Battery
APP-SRV-00
MGMT-LAN
DB-SRV-00
Disk
Cluster
- 0)
TRF-SW-01
ROU-01
APP-SRV-01
DMZ-ROU
DMZ-LAN
ISP-SRV-00
WKST-00
PRN-00
Antenna
MGMT-SW-01
DB-SRV-01
NCR Generator
Ref&Sync
NCR-01
REFS-01
FLS
FWD-MGMT-01
IP Encap.
FWD-TRF-01
MUX
MUX-01
Modulator
RF
MOD-01
CSI-MGMT-01
CSI
CCU
CSI-TRF-01
FERX
RLS
Figure 7-5 Example Redundant System
Redundancy in the SatLink GW is achieved with redundancy in the following subsystems:
1. FLS: by using redundancy switchover units which can operate in automatic and manual
modes. The redundancy solution requires 1:1 scheme of each component of the FLS. On
detection of any errors or alarms on the active chain, the FLS will automatically switch
over to the secondary chain.
2. Return link sub-racks: Initially, a 1+1 hot redundancy scheme is envisioned. If hardware
or software failures are detected on the primary unit, the SatLink Gateway will transfer all
connections from the primary unit to the secondary stand-by unit. Switchover time will be
on the order of a second, which ensures that on-going connections are not fatally disrupted.
As traffic volume increases and additional sub-racks are added, one may continue with a
1+1 or go to a N+1 redundancy scheme, depending on the availability requirements.
3. Windows NT servers: The NCC and NMS applications are running on redundant
Windows NT servers, which are connected into a cluster by using the Microsoft Cluster
Server. This cluster solution makes possible to manage the different applications and
resources, either automatically or manually by using the “Cluster Administrator” interface.
The Microsoft Cluster Server monitors the health of the applications and servers and can
automatically recover applications from failures.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
78 / 266
4. Oracle Parallel Server: This server is used for database management in the SatLink
GW. This server makes possible to run the same database on a cluster consisting of
multiple Symmetric Multiprocessor (SMP) nodes. In a client/server environment, the
clients view the cluster as a single database. In reality, they are connected to different
database instances running on different nodes. If one node fails, its workload can be
automatically distributed among the surviving nodes.
5. Reference and synchronization equipment: The SatLink GW uses Datum GPS
equipment for synchronization and reference clock generation. Redundancy is facilitated
through the use of a redundancy switchover unit, which automatically switches from the
primary to the secondary unit on detection of failures, or when servicing the equipment.
6. Routers and switches: In the SatLink GW the routers and switches are supplied by
Cisco. These components have extremely high Mean Time Between Failure (MTBF)
numbers (20 - 50 years). Nera has therefore decided not to use hot standby IP Routers and
Ethernet Switches in the SatLink Gateway. However, cold standby equipment are
available. Hot standby solutions can be provided as an option.
7.8 Centralized NMS
7.8.1 Introduction
NMS functionality of DVB-RCS Gateway is to provide an easier approach for the gateway
operator to automate routine Gateway Operations and minimize the risk of human errors
during configuration of Network Elements in the DVB-RCS Gateway system. With
increasing number of users in the gateway also makes even more important to simplify the
operator procedures, automate the configurations and also provide a single point of
management using User Interface.
The automatic procedures are covered as part of NMS-RCH Phase 1 Development.
This document describes how the subsystem are to be fulfilled in the NMS subsystem
design for Release 10 of the NERA DVB-RCS system.
7.8.1.1 Purpose
The primary purpose is to define a framework and provide adequate background for the
designers of Remote Command Handler Module within the NMS of the Gateway.
This document is also intended for the Software developers of the NMS for DVB-RCS,
resource planners and testers of the system.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
79 / 266
7.8.2 Design description
7.8.2.1 System Overview
Client Tier
Web Client
HTTP/HTTPS
Middleware
Oracle 10G Application Server
(Web Server Application)
RCH Integration Module
XML over MexLib
Mediation Agents
DAS Communication
RCH
NLID over MexLib
Network Elements
SNMP
IP
Encapsulator(s)
Multiplexer
IP
Router(s)
Modulator
TCP PEP
Servers
Terminals
Figure 7-6 NMS - Tier Model
NccGW
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
80 / 266
JDBC
Oracle 10g
Application
Server
(Web Server + Application
Web based
Configurations (XML
over MexLib)
DAS
Initiate Terminal Commission
Process
(MexLib)
Event Log
module
RCH
Configure
PEP Server
(SNMP)
Verify IP
router(s)
(SNMP)
TCP PEP
Server
Database
NCC Gateway
(RLS)
NLID
R
F
Configure IP
Encapsulator(s)
Multiplexer
Modulator
Terminal
(SNMP)
RCS
Terminal
FLS
IP Router(s)
Internet
( Ext
- 0)
IPE(s)
MUX
Modulato
r
Configuration Paths for the current
Existing Network Paths
Modules Related to NMS
Figure 7-7 NMS for DVB-RCS System Overview
A successful logon of the terminal in DVB-RCS Gateway requires configuration of the
Network Elements IP Routers, IP Encapsulators, Multiplexers, Modulators, TCP
Accelerators and Terminals. The configuration procedures are automated based on the
information stored in the database. The configuration procedures can be grouped as,
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
81 / 266
Auto Commission - When a new terminal is deployed on the network and logs on to the
network this procedure is executed.
Event Triggered Logon Procedure - This procedure is executed whenever there is a logon
of the terminal in the network
Event Triggered Logoff Procedure - Logoff procedure is invoked during the logoff of
terminal from the network, either by Terminal Operator or Gateway Operator.
RCH operates on Execute Procedures Signal from DAS and sends back results using
Procedure Executed Signal over MexLib interface. DAS interfaces with the Database and
NccGW invoking the configuration procedures and communicating with RCH. This forms
the automatic execution of the configurations during the Logon of RCS Terminals.
DAS operates with the information from the Database and controls the execution of Auto
Commission, Event Triggered Logon and Logoff Procedures.
Web Component provides a Web User Interface for providing manual configuration of
elements of the Gateway.
WC interfaces with RCH using Manual Triggered Configuration Request and Manual
Triggered Configuration Response signals with XML syntax and over MexLib interface.
This document covers the sections of Phase 2 RCH enhancements from the following
table,
7.8.2.1.1 RCH Operation
RCH supports Win32 Architecture and Linux Platform for deployment. RCH is operated in
both versions as following,
Win32 – a Win32 service controlled by the Services (Control Panel)
Linux – a Stand Alone application
RCH consists of two instances of the same application one working with DAS
(RCH_DAS) and another working with WC (RCH_WC).
7.8.2.1.2 RCH and DAS
RCH interfaces with DAS using MexLib signals and interface. The signals
EXECUTE_PROCEDURES and PROCEDURE_EXECUTED are used along with the specified
interface message. The data exchange between the RCH and DAS is using the PORT_RCH,
PORT_RCH_WC and PORT_DAS.
AEO-005479
SATLIFE
D311
DAS
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
82 / 266
RCH (PORT_RCH)
EXECUTE_PROCEDURES
PROCEDURE_EXECUTED
Network Components
SNMP or
NLID over
MexLib
SNMP
MexLib Signals
Figure 7-8 DAS and RCH Interface
7.8.2.1.3 RCH and WC
RCH interfaces with WC using XML over MexLib. The Destination Computer, Port,
Process and Instance Number are pre-configured in the RCH Integration Module of the
Web Component. RCH receives the XML information through MexLib, which is later,
parsed, decoded and processed.
Web Server App
RCH (PORT_RCH_WC)
MANUAL_TRG_PROCEDURE
MANUAL_TRG_RESULT
MexLib Signals
Network Components
SNMP or
NLID over
MexLib
SNMP
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
83 / 266
Figure 7-9 Web Component and RCH Interface
Apart from the WC and DAS interface, RCH also transmits the Events (Event Log
Messages) to the EVL Module for logging the events in ASCII text file. The interface is
MexLib with specified Signal and Port Numbers.
7.8.2.2 RCH Enhancements
7.8.2.2.1 Extending RCH for Web Component Interface
RCH Phase 1 interfaces with DAS using MexLib for the EXECUTE_PROCEDURES and
PROCEDURE_EXECUTED signals. The message from DAS triggers the set of actions in the
RCH module. The results for the operations are sent to DAS using the
PROCEDURE_EXECUTED.
The RCH interacts with the RCH Integration Module of the Web Component using
MANUAL_TRG_PROCEDURE and MANUAL_TRG_RESULT. WC sends the information to RCH
using MexLib with XML format. The request from the Web Component is decoded and
parsed to derive a Data Structure that drives the RCH functionality.
To provide the Web Component interface a separate instance of the RCH is run listening
on the PORT_RCH_WC. The XML messages are received from this MexLib interface.
Phase 1 RCH is featured with Thread Pool architecture for executing concurrent
configurations to the network devices. The framework is re-used for the RCH-WC.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
84 / 266
RCH Main Loop
Initialize Data Structures
& Thread Pool Interface
Wait for Messages at
PORT_RCH_WC (with Time Out)
TIMEOUT
MANUAL_TRG_PROCEDURE
XML Parsing and
Convert to Manual Procedure
No
Is Free
Thread
Available
Message
Store
Yes
Run RCH Configuration
Thread for this
instance
Store Message from WC
for later processing
Is Data
Available
and Free
Thread
Available
No
Yes
Quit
Kill all Configuration
Threads and return
Figure 7-10 RCH Extending for Manual Triggered Procedures (RCH-WC)
7.8.2.2.1.1 XML Interface with Web Component
RCH Main module extracts the XML Interface message and converts to Manual Procedure
Data Structure for further processing. The Manual Procedure is used to drive the RCH
main module. Depending upon the availability of the worker threads, the data structure is
passed to the configuration threads or buffered for later use. After completion of the
configuration the results are sent to the Web Server with XML syntax over the MexLib
interface. The MexLib Information for the Web Component is registered with the MexLib
library.
7.8.2.2.1.1.1 Request from the Web Component
The following are the configurations received from the Web Interface.
Forward Link
• IP Encapsulator Configuration SMR
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
85 / 266
• Newtec Modulator Configuration
• MUX Configuration
Terminal
• DHCP Server Configuration
• Continuous Wave Configuration
• Configuration files and Statistics upload
Multiple configuration requests are embedded in a single XML message from the web
interface. The configurations are identified, separated and sent to the Configuration
Threads by RCH.
7.8.2.2.1.1.2 Response to the Web Component
The results for the above configurations are sent to the Web Component using MexLib
Interface. The result information is converted from the Data Structure format to XML
syntax and sent.
7.8.2.2.1.2 Expat XML Library
XML coding and decoding is performed using the Expat XML Library. Expat is an XML
parser library written in C. It is a stream-oriented parser in which an application registers
handlers for tags and values the parser find in the XML document.
The Expat source code is added to the RCH baseline along with Mexport, NetSNMP and
FSAP2. The library is statically linked to the RCH executable and distributed according to
the copyright license under MIT/X Consortium.
7.8.2.2.2 RCH Configuration Threads
The configuration request from the Web Component contains configuration for a list of
terminals. The threads at RCH should be able to support multiple configurations in a single
thread. For the manual triggered operations, the configurations can be sent in batches and a
single thread shall be used for a request. The request can contain configurations for
multiple entities (of same type).
The result for each configuration is sent to WC using the XML syntax and MexLib
interface.
The SNMP operation at the Terminals over the DVB Interface is considerably slow due to
Satellite Propagation delays. Configuring a group of terminals using a single thread would
increase the thread occupancy level to few seconds to minutes. Other case sending
individual configurations to separate threads would increase the number of active threads
and configurations from other Web Sessions would be delayed.
Considering both the cases, Web Server Application dispatches configurations in batches
even though more number of terminals is selected.
In both approaches the results are sent out individually and Web Component consolidates
all the results based on the Web Client ID and displays for the user.
7.8.2.2.3 Subnets Configuration for IP Encapsulators
Configuration of the IP Encapsulators for the Sub Networks behind the RCS Terminal is
achieved by creating IP forwarding Entries in the Encapsulators for all the Sub Networks.
The information about the subnets is available in the Execute Procedures message.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
86 / 266
7.8.2.2.3.1 SKY Stream Encapsulator Configuration
During Auto Commission a row is created in the skyDbnIpPacketFwdTable with the
following parameters,
• IP Address,
• Subnet Mask,
• Next Hop PID,
• Maximum Data Rate,
• MAC Address,
• MAC Method,
• Route Enabled
During Event Triggered Logon Process, the skyDbnIpPacketFwdRouteEnabled field is
modified to “Enabled” state and Maximum Data Rate is modified.
If there is change in the PID (skyDbnIpPacketFwdNextHopPid) then the Row is destroyed
after reading the current contents and a new Row is created with the previous values expect
for the PID, Max Data Rate and Route Enabled fields.
During Logoff process, the skyDbnIpPacketFwdRouteEnabled field is set to “Disabled”
state for all the entries corresponding to a Terminal.
RCH Phase 1 implementation configures the SMR IPE for DVB and LAN Interface and is
extended to include the configuration of the subnets behind terminals.
Auto Commissioning, Event Triggered Logon and Logoff control the configurations for
DVB, LAN and Subnet Entries in the IP forwarding Table (skyDbnIpPacketFwdTable) of
the IPE.
7.8.2.2.3.2 OPAL IPE Configuration
For creating/modifying/deleting IP Forwarding information of the Terminal DVB, LAN
and Subnet Networks the following SNMP Table Groups and Scalar Groups are used,
• omInputIpTable,
• omIpFilterTable omIpFilterActionGroup,
• omMacMacAssociationTable omIpAssociationActionGroup
The PID for the forward link is used as index and the corresponding Input ID is selected
from omInputIpTable. An IP Filter for the corresponding Input and an IP-MAC Association
for the IP address, Subnet Mask and MAC-Address combination is created at the OPAL
IPE during Auto Commission and Event Triggered Logon sequences.
The created entries at IP Filter Table and IP-MAC Association Table are deleted during
Event Triggered Logoff.
OPAL IPE does not provide an option to disable (or inactive) the entries so the information
is deleted during Logoff.
7.8.2.2.4 IP Router Configuration Verification for Subnets
CISCO IP Router used in the Gateway Network contains information about the routes to
interconnect the Terminals on DVB Interface, LAN Interface and Subnets behind the
Terminals.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
87 / 266
RCH Phase 1 implementation validated only the presence of Routes covering the DVB and
LAN Interface of the Terminals. Missing routes are reported as an error during Auto
Commissioning Sequence. The Next-Hop IP address used is IP Encapsulators’ IP address.
IP Router Verification option is available only during Auto Commission Sequence and
controlled by u1acIpRouterConf of tExecProc.
There are two variants of CISCO Routers available in the network,
• Supporting RFC 1213 MIB (using IP Route Table)
• Supporting IP-FORWARD-MIB (using IP Forwarding MIB)
Latest version of the router software is backward compatible with old MIB, but we use the
latest MIB in case if it is supported. The Router’s capability is verified by querying the IPFORWARD-MIB first. If there is no response for the SNMP request, Router is requested
for the RFC 1213 MIB. In either case, if there is no response from the Router, the action is
marked as failure. If either one of the MIB query is successful, the operation is continued.
The IP address, Subnet Mask and Next Hop IP Address are part of the Input Execute
Procedures Message.
The IP Router Configuration verification now extends to the Subnets behind Terminal. The
routes covering all the Networks are validated. Any missing entry is reported as an error to
DAS message.
If TCP acceleration is enabled in the User Profile, then the TCP Accelerator’s IP address is
used as Next Hop Address.
7.8.2.2.5 TCP PEP Configuration
Performance Enhancement Proxies for TCP are used in the terminals over the satellite link
to improve performance of data transmission. The configuration operation includes the
terminals and third party TCP accelerators servers (UDCast TCP accelerator and others).
ipPepConfiguration Scalar Group of the Terminal MIB is configured for the following
parameters,
•
•
•
•
(Enable of Disable PEP Option)
ipPepTcpMode
(Transparent/Direct mode of TCP-PEP Operation)
ipPepPrimaryServer (Primary TCP Accelerator Server)
ipPepSecondaryServer
(Secondary or fall-back TCP Accelerator Server)
ipPepEnable
TCP Accelerator Server Type field in the Input message provides configuration support for
other TCP Accelerators. Also the number of TCP servers for one terminal should use is
one. Based on the server type corresponding configuration procedures can be executed.
7.8.2.2.6 Terminal DHCP Server Configuration
DHCP Server configuration feature of Phase 1 is used for this configuration. DHCP
configuration was part of Auto Commission and Event Triggered Logon procedures, now
the DHCP configuration can also be reused from the Web Interface for a Terminal or
Group of Terminals.
7.8.2.2.7 Software Upgrade
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
88 / 266
Terminal Software Upgrade is feature to download the latest (or prescribed) version of the
software on the terminal. This can be accessed either through the CLI interface or SNMP.
Software Upgrade operation is performed if it is enabled in the profile.
The TFTP Server Address and file name is specified in the CLI command to download the
software.
The CLI command for the upgrade is
“dload <filename> <ipaddr> [<localname>]”
Download operation (using SNMP) is performed by configuring
Terminal MIB for the following parameters,
•
swTftpSrvAddr
(TFTP Server IP Address)
•
swTftpUpgradeDefaultFileName
(Software File Name)
•
swUpgradeFromTftp
(Start download operation)
Group of the
The status of the download process is reflected at swUpgradeFromTftp of sysSWScalar
Group and accessed by SNMP.
Once the software download is complete, the terminal reboots self to load the new software
application.
Considering the CLI and SNMP approach, SNMP approach is used to initiate the software
download operation for the following reasons,
• Provides a response for the configuration request
• The file control is done automatically. If a file with the same name (different
version, but same name like dvb-rcst.tgz) is available, it is overwritten. CLI
download operation expects either to delete the file or download with a different
file name and there is no error reported about the error from CLI to RCH.
7.8.2.2.8 Terminal Management Access Configuration
Terminal CLI, Telnet and Web Interface is controlled by User Names and Passwords
stored in the terminal. Configuration of users and passwords is performed as part of Phase
1. The CLI commands for creating the User with Password is transmitted to the terminal
over NLID mechanism from the NccGW. This is covered under RCH Phase
1Development.
7.8.2.2.9 Terminal Commissioning Status Configuration
Auto commissioning status is set to Success or Failure based on the result of the procedure.
The new scalar variable swCommStatus of sysSWScalar Group is used for storing the
result. The scalar implementation is not available in the existing version of the Terminal
Software. This is applicable only for the Release 10 and subsequent versions to follow.
While nearing the successful completion of the Auto Commission Procedure the value is
set to Auto Commission Success. If any of Auto Commission Sequence for Terminal
Configuration fails, the value is set to Auto Commission Failure. The default value is not
applicable
This operation is performed before the Terminal Save Option to ensure that the value is
stored in the config.txt file of the terminal after successful save operation (if enabled).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
89 / 266
7.8.2.2.10 Manual Triggered
The following operations are grouped for Manual Triggered Operations from the Web
Interface.
• SMR IPE Configuration
• MUX configuration
• Newtec modulator configuration
• Configuration files and Configurations upload
• Continuous wave configurations
• DHCP Server Configuration (Phase 1)
7.8.2.2.11 Auto Commission
The following operations are performed during Auto Commission and Event Triggered
Procedures.
• IP Router Configuration Verification for Terminal Subnets
• IP Encapsulators Configuration for Terminal Subnets (SMR and OPAL)
• TCP PEP Configurations (Terminal and Server)
• Software Upgrade
* All the other Phase 1 configurations are applicable
7.8.2.2.12 Event Triggered Logon
As a part of the Event Triggered Logon Procedure the following operation shall be
performed,
• IP Encapsulators Configuration for Terminal Subnets PID, Date Rate and Route
Status Modifications (SMR and OPAL)
• TCP PEP Configurations (Terminal and Server)
• Software Upgrade
* All the other Phase 1 configurations are applicable
7.8.2.2.13 Event Triggered Logoff
As a part of the Event Triggered Logoff Procedure the following operation shall be
performed,
• IP Encapsulators Route Status Modifications for Terminal Subnets (SMR and
OPAL)
* All the other Phase 1 configurations are applicable
7.8.2.3 Event Log Module
Event Log Module shall remain the same, with addition of new events for the different
configurations. The new events names, event types are added to the evldefn.h file. The list
of new events is available at the Appendix.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
90 / 266
8. NERA USER TERMINAL DESIGN
8.1 Active IP Queue Management
8.1.1 Introduction
In the SatLink DVB-RCS terminal there are at least two reasons for doing active queue
management. One is the need to fill the requested Demand Assigned Multiple Access
(DAMA) return link capacity with traffic, and simultaneously keep an acceptable
application performance. The other is to keep an acceptable application performance when
the access is congested.
In the SatLink system congestion is likely to occur both at the hub gateway and at the
terminal gateway. In fact, congestion will more likely occur at a terminal since terminals
are normally operated under capacity limitations given by the Service Level Agreement.
Also, when the hub is congested it is highly likely that also individual terminals are
congested.
The return link capacity utilization when doing simultaneous bulk data transfers like
several FTP uploads can be low when sharing access through a terminal using a drop-tail
queue management. This is shown in
Table 8-1. Drop-Tail (DT) gateways can result in packets being dropped from multiple
TCP connections at roughly the same time. The result is that the TCP connections also
reduce their congestion windows at the same time, resulting in an input rate surge, buffer
exhaustion and a lowered link utilization of the virtually congested return link.
Instantaneou Rate per TCP Buffer level Large
s
connection
at
packet
shared rate (kbps)
culmination RTT (s)
(kbps)
(bytes)
512
170,7
184872
1,9
256
85,3
190738
3,1
128
42,7
193672
5,4
64
21,3
195138
10,0
32
10,7
195872
19,3
16
5,3
196238
37,9
8
2,7
196422
75,0
Table 8-1 Packet delay caused by 3 TCP connections at culmination, sharing a DT
gateway.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
91 / 266
The user experience of transaction oriented applications like Web browsing can be
significantly reduced by simultaneous bulk data transfers like FTP uploads when sharing a
DT gateway using a large buffer. The performance of transaction oriented applications is
better with a smaller buffer, but this also lowers the return link capacity utilization. The
performance reduction can be limited by doing active queue management, like RED, in the
terminal. This is documented by [RED00].
Active queue management as a means to control the effect of congestion is recommended
by [RFC2309].
8.1.2 Background
The following mechanisms are known to stagger the TCP transmitter:
•
•
•
The receiver reduces the announced rwnd
An IP GW somewhere in the network drops a single packet to trigger fast retransmit
and fast recovery in the transmitter (avoiding reduction of cwnd to one MSS)
The transmitter reaches packet transmission timeout, resulting in both setting cwnd to
one MSS and start retransmission from the last acknowledged packet (note the data
packets already in the pipe may keep a stream of acknowledgements with increasing
segment number going at least until the pipe is drained. This will increase cwnd
rapidly)
Miscellaneous
•
The Windows XP TCP transmitter seems to utilize the optional TCP timestamps by
using these also to limit the rate of packet transmission (may be by staggering the
growth of cwnd due to a too high increase of the RTT?). This is experienced through
test and no documentation on this matter is currently known.
Due to the large capacity (BW*RTT) and the relatively low rate of the return link the
receiver cannot control the transmitter properly through rwnd. Thus, other means must be
used to limit the size of cwnd.
The relation BW * RTT = cwnd can limit the effective BW. The cwnd will grow
approximately one MSS per RTT. Dropping a packet will set cwnd to sstresh and cwin will
again grow as described. By dropping one single packet the transmitter can be expected to
half the cwnd according to the Fast Retransmit and Fast Recovery mechanisms specified
by [RFC2581]. The goal should be to let the cwnd of each TCP session at least grow to a
value that with an RTT value of RTTmin the terminal can exploit the full bandwidth. The
problem is to limit cwnd growth. As cwnd continues to grow past this point the RTT will
increase. But, in order to avoid congestion when reducing cwnd the highest experienced
RTT should not be allowed to be larger than twice the mean RTT. A larger difference may
trigger retransmission, collapse the cwnd and resume TCP slow start.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
92 / 266
The filling level of the retransmission buffer is limited by cwnd. If data is available for
transmission the sender will submit a packet as long as current retransmission buffer filling
level is less than cwnd. The maximum value of the cwnd is the rwnd announced by the
receiver. When acknowledgement for the oldest data in the retransmission buffer is
received this data is removed from the buffer and more free buffer space becomes
available.
In the following it is assumed that equation (1) holds. If it does hold then equation (2) and
equation (3) give the average values at culmination. If not, they give the peak values. At
transfer rate culmination for a TCP transferring data at saturation the additional delay
caused by the data remaining in the terminal buffer is given by (2).
cwnd > Partial_BW * RTT (1)
+delay = (cwnd/Partial_BW) – RTTmin (2)
Buffer_volume = cwnd – Partial_BW * RTTmin (3)
Each TCP session transferring data at saturation is independently capable of filling the
terminal buffer with a volume given by (3). Thus, it is feasible to fill up a very large buffer
and let the delay grow out of proportions. This can be seen from (2) and
Table 8-2.
MS W2K and MS WXP typically use 65535 bytes as the default rwnd. MS NT typically
uses 8192 bytes and Linux typically uses 32767. The cwnd size will culminate at the rwnd
level.
Partial_BW +delay
(kbps)
(ms)
800
105
512
474
256
1498
128
3546
64
7642
32 15834
16 32218
8 64985
Table 8-2 Additional packet delay caused by buffer filling for MS W2K, at
culmination.
Partial bandwidth can either be understood as the total instantaneous bandwidth used for
one single TCP session operating at saturation, or the partial instantaneous bandwidth for
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
93 / 266
each TCP session when several TCP sessions are running at saturation and sharing the
available bandwidth.
8.1.2.1 General RED
RED is described in [RED93]. RED controls buffer filling and traffic flows by giving
congestion notification. As many systems do not recognize ECN, packet dropping is
currently the most reliable way of indicating congestion to the transport protocol
transmitters.
The RED algorithm specified by [RED93] is as follows:
Initialization:
avg ← 0
count ← −1
for each packet arrival
calculate the new average queue size avg:
if the queue is nonempty
avg ← (1 − wq)*avg+wq* q
else
m ← f (time − q_time)
avg ← (1 − wq)m * avg
if minth ≤ avg < maxth
increment count
calculate probability pa:
pb ← maxp*(avg−minth)/(maxth−minth)
pa ← pb / (1 − count * pb)
with probability pa:
mark the arriving packet
count ← 0
else if maxth ≤ avg
drop/mark the arriving packet
count ← 0
else
count ← −1
when queue becomes empty
q_time ← time
Saved Variables:
avg: average queue size
q_time: start of the queue idle time
count: packets since last marked packet
Fixed parameters:
wq: queue weight
minth: minimum threshold for queue
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
94 / 266
maxth: maximum threshold for queue
maxp: maximum value for pb
Other:
pa: current packet-marking probability
q: current queue size
time: current time
f (t): a linear function of the time t
One option for the RED gateway is to measure the queue level in bytes rather than in
packets. With this option, the average queue size accurately reflects the average delay at
the gateway.
It is also possible to ensure that the probability that a packet is dropped is proportional to
the packet size in bytes. This can be utilized to more optimally limit flows when BW is the
limiting factor and not the packet processing power.
pb ← maxp * (avg − minth)/(maxth − minth)
pb’ ← pb * PacketSize / MaximumPacketSize
pa ← pb’ / (1 − count * pb’)
In this case a large FTP packet is more likely to be dropped than is a small TELNET
packet.
The average queue level is calculated by using a low-pass filter. The low-pass filter is an
exponential weighted moving average as shown in equation (4).
avg ← (1-wq) * avg + wq * q
(4)
Given a minimum threshold minth, and given that we wish to allow bursts of L packets
arriving at the gateway, then wq should be chosen to satisfy the following equation for avgL
< minth:
L+1+ ((1-wq)L+1-1)/wq < minth
(5)
Given minth = 5, and L = 50, for example, it is necessary to choose wq ≤ 0.0042.
8.1.3 System Description
8.1.3.1 Relating the RED thresholds to queue excess threshold
The packets kept in the retransmission buffer are packets that are sent but not yet
acknowledged. The sent packets, if not lost, are represented by either a data packet in the
data transfer direction or an acknowledgement in the acknowledge direction. The data
packet may either be in propagation or in a buffer in an intermediate device. The same
goes for the acknowledgement packet.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
95 / 266
In the return link of the Nera SatLink system the capacity bottleneck is normally the link
between the terminal and the hub. Thus, data will frequently accumulate in the return link
transmission buffer of the terminal.
Terminal buffer exhaustion is undesirable since it reduces the system utilization. Assigned
capacity should not go unused. It should therefore nominally be enough data in the buffer
to avoid frequent exhaustion due to effects like short time input rate variation, slot interval
variance and non-requested free capacity assignment. The capacity request mechanism will
take action to get additional return link capacity to reduce the buffer filling when the
instantaneous buffer filling is higher than targetth. No action is expected when the buffer
filling is lower than this threshold.
The RED mechanism will seek to reduce the average buffer filling level when this level
passes a threshold minth. The mechanism does this by indicating congestion. Congestion is
indicated by randomly dropping packets when the average buffer filling level is above
minth. If the level is above maxth, every packet will be dropped.
Memory limit
maxth
minth
targetth
Figure 8-1. The different buffer handling thresholds.
The previous figure shows the terminal buffer thresholds. Several objectives exist, and
some of them are contradictory:
•
•
•
•
Have a low targetth in order to have a low mean delay at non-saturation
Have a high targetth in order to increase capacity utilization at non-saturation (reduce
the probability of buffer exhaustion)
Have a low minth in order to have a low mean delay for transactions at saturation
Have a high minth in order to reduce the drop probability and thereby increase
throughput and capacity utilization at saturation
AEO-005479
SATLIFE
D311
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
96 / 266
Scale the drop probability according to the packet size to increase the probability of
success for short-lived sessions carrying transactions
8.1.3.2 Controlling the queue at non-congestion
At non-congestion and non-saturation the terminal will get additional capacity as
requested.
When the buffer filling level is below targetth the terminal should only request for capacity
to hand off the traffic that is expected to arrive. It should not try to empty the buffer. When
the buffer filling level is above this threshold additional capacity is requested to get the
buffer filling level down to targetth.
The level targetth is calculated dynamically as follows:
targetth = average_bw * target_delay
(6)
average_bw ← (1-wbw) * average_bw + wbw * bw
(7)
The target_delay should be selected to match the requirements of the relevant applications
and the target system utilisation. Typically, this value should be in the range 0 – RTTmin.
The bw is the assigned bandwidth as indicated in the TBTPs.
The factor wbw should be chosen so that a transient in the assigned bw is damped with a
time constant larger than the demand capacity assignment latency. But it should be large
enough so that the capacity request and assignment system can get the buffer_delay
stabilized at the target_delay within a reasonable period after a sudden change in the traffic
level. (It seems that wbw = 1/16 is a reasonable value given 200ms sampling. This leaves
the average 10% off the level 7 seconds after the transient, and reduces the instantaneous
effect of the transient to 6%.)
If there are several queues the bw level should be distributed between the different queues
with a portion of bw relative to the difference in the average input rate of the different
queues. The targetth should be calculated individually for each queue. This will ensure that
the target_delay is kept for each queue.
8.1.3.3 Adapting RED to DVB-RCS
8.1.3.3.1 Determining parameter values
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
97 / 266
The optimal values for minth and maxth depend on the desired average queue size. If the
typical traffic is fairly bursty, then minth must be correspondingly large to allow the link
utilization to be maintained at an acceptably high level. For connections with reasonably
large delay-bandwidth products, a minimum threshold of one packet would result in
unacceptably low link utilization.
Performance using different average queue size for a particular traffic mix is shown in
[RED00].
The optimal value for maxth depends in part on the maximum average delay that can be
allowed by the gateway.
The RED gateway functions most effectively when maxth-minth is larger than the typical
increase in the calculated average queue size in one roundtrip time. A useful rule-of-thumb
is to set maxth to about three times minth.
The RED gateway parameters wq, minth, and maxth are necessary so that the network
designer can make conscious decisions about the desired average queue size, and about the
size and duration in queue bursts to be allowed at the gateway. The parameter maxp can be
chosen from a fairly wide range, because it is only an upper bound on the actual marking
probability pb. If congestion is sufficiently heavy that the gateway cannot control the
average queue size by marking at most a fraction maxp of the packets, then the average
queue size will exceed the maximum threshold, and the gateway will mark every packet
until congestion is controlled. Typically, maxp could be set approximately to 0,1.
8.1.3.3.2 Ensure adequate calculation of the average queue size
The average queue size at the gateway is limited by maxth, as long as the calculated
average queue size avg is a fairly accurate reflection of the actual average queue size. The
weight wq should not be set too low, so that the calculated average queue length does not
delay too long in reflecting increases in the actual queue length.
Equation (5) describes the upper bound on wq required to allow the queue to accommodate
bursts of L packets without dropping/marking packets. Given a minimum threshold minth,
and given that we wish to allow bursts of L packets arriving at the gateway, then wq should
be chosen to satisfy the following equation for avgL < minth.
Given minth = 3, and L = 25, for example, it is necessary to choose wq ≤ 0.01.
The typical MS Windows cwnd maximum size of 64KB (65535 B) can theoretically
generate peaks of up to 25 packets at 1460 bytes at TCP slow start. However, since the
terminal is an edge device, the packet rate will normally be controlled by the rate of TCP
acknowledgement received through the forward link.
It is possible that the most important effect of the EWMA buffer level filter is that it to
some extent covers up for the latency in the assignment of additional capacity when the
terminal requests capacity to handle excess buffer volume. If volume capacity assignment
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
98 / 266
is available through VBDC this can contribute in keeping the average buffer level below
minth, even if the rate assignment is already at its maximum.
8.1.3.3.3 Set minth sufficiently high to maximize network power.
The thresholds minth and maxth should be set sufficiently high to maximize network power.
Because network traffic is often bursty, the actual queue size can also be quite bursty; if
the average queue size is kept too low, then the output link will be underutilized.
The threshold minth should be set to a value reflecting a delay that is large enough to allow
good utilization of unexpected capacity available in the channel and to have good
utilization even if there are fluctuations in the input data stream. More capacity may
suddenly be assigned due to that the congestion level at the GW is reduced or capacity is
randomly given as FCA.
minth = Max (REDtargetth (maxrate); Np * (MTU + DSM_CC_Overhead))
maxrate = (RBDCmax + CRA_Served_Level)
(8)
(9)
The REDtargetth is a volume threshold that reflects a delay that is equal to or higher than
the maximum additional delay that is accepted without requesting for capacity. At maxrate
capacity the rate assignment level cannot be raised, and additional measures have to be
taken by the RED mechanism.
Lets assume that it is at a maximum acceptable to utilize up to 100 ms additional delay.
This is a 14% increase in RTT and for some applications also a performance drop of 14%.
The terminal will not regard buffer filling creating up to 100 ms delay as excess buffer
filling. The RRM system requires an additional margin so additional capacity requests can
be requested and assigned. Thus, at 200 ms delay the packet drop probability should rise
from zero.
The minth will be at least Np * MTU to avoid severe drop at low rates. The MTU can be
expected to be up to 1500 byte. A reasonable value of Np can be 3. Note that with a
delayed acknowledgement scheme for TCP two data packets are immediately released for
every acknowledgement received. This is a typical behavior.
minth = Max ((200 ms * maxrate); 4548 byte)
(10)
8.1.3.4 Make maxth-minth sufficiently large to avoid global synchronization.
Make maxth-minth larger than the typical increase in the average queue size during a
roundtrip time, to avoid the global synchronization that results when the gateway drops
many packets at one time. One rule of thumb would be to set maxth to at least three times
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
99 / 266
minth. If maxth -minth is too small, then the computed average queue size can regularly
oscillate up to maxth.
If minth represents 200 ms delay then maxth represents 600 ms delay. At this buffer level
the RTT is approximately doubled and the transaction performance is reduced by 50%. At
512 kbps this is 38400 bytes.
If minth represents 3 MTUs then maxth represents 9 MTUs. This means 13644 bytes
regarding the maximum MTU.
maxth = Min ( 3 * minth ; BufferSize)
(11)
8.1.3.4.1 Drop strategy and drop probability
Head drop may give a slightly better transient performance. For steady state operation
there should not be a large difference between tail drop and head drop. Some authors
indicate a possible synchronization problem when doing head drop.
The drop probability should be scaled according to the size of the packet under
consideration. This will give a more even BW sharing and will also favor the applications
depending on small packets. This can be approximated by e.g. using two categories of drop
probabilities – for small packets and large packets, or linearly scaled with the size.
The drop probability of small packets should be about 1/27 related to the large packets
since these may be the acknowledgements for forward link TCP traffic. The limit can be
e.g. 500 bytes. Thus, the packet-drop probability of a small packet should be insignificant
compared to the packet drop probability of the large packets typically associated with a file
transfer in the return link. This will make downloads and browsing less vulnerable for
RED than uploads.
pbtrue = (Size/1516) * pb
(12)
When the average queue size is above maxth all packets are dropped until the average
queue size is below the threshold.
8.2 Queue Structures and Traffic Classes
8.2.1 Scope
This note describes a proposal for the interpretation of the different capacity request
categories defined in EN 301 790 v.1.3.1.
8.2.2 Introduction
The description of capacity request types provided here is largely independent of
differentiation of QoS.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
100 / 266
The proposal is provided due to the lack of a precise specification of how the capacity
request categories shall be interpreted. This is an obstacle for interoperability with a
sufficiently good and predictable performance. The obstacle exists even without the
introduction of QoS differentiation.
8.2.3 DVB-RCS Definitions
The specification of capacity request categories in EN 301 790 v.1.3.1 is repeated here.
References within this section are to the originating document.
8.2.3.1.1 CRA
CRA is rate capacity which shall be provided in full for each and every superframe while
required. Such capacity shall be negotiated directly between the RCST and the NCC.
8.2.3.1.2 FCA
FCA is volume capacity which shall be assigned to RCSTs from capacity which would be
otherwise unused. Such capacity assignment shall be automatic and shall not involve any
signaling from the RCST to the NCC. It shall be possible for the NCC to inhibit FCA for
any RCST or RCSTs.
FCA should not be mapped to any traffic category, since availability is highly variable.
Capacity assigned in this category is intended as bonus capacity which can be used to
reduce delays on any traffic which can tolerate delay jitter.
8.2.3.1.3 RBDC
RBDC is rate capacity which is requested dynamically by the RCST. RBDC capacity shall
be provided in response to explicit requests from the RCST to the NCC, such requests
being absolute (i.e. corresponding to the full rate currently being requested). Each request
shall override all previous RBDC requests from the same RCST, and shall be subject to a
maximum rate limit negotiated directly between the RCST and the NCC.
To prevent a terminal anomaly resulting in a hanging capacity assignment, the last RBDC
request received by the NCC from a given terminal shall automatically expire after a timeout period whose default value is 2 superframes, such expiry resulting in the RBDC being
set to zero rate. The time-out can be configured between 1 and 15 superframes (if set to 0
the time out mechanism is disabled) by the optional mechanism of clause 8.4.2.
CRA and RBDC can be used in combination, with CRA providing a fixed minimum
capacity per superframe and RBDC giving a dynamic variation component on top of the
minimum.
8.2.3.1.4 AVBDC and VBDC
VBDC is volume capacity which is requested dynamically by the RCST. VBDC capacity
shall be provided in response to explicit requests from the RCST to the NCC, such requests
being cumulative (i.e. each request shall add to all previous requests from the same RCST).
The cumulative total per RCST shall be reduced by the amount of this capacity category
assigned in each superframe.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
101 / 266
AVBDC is volume capacity which is requested dynamically by the RCST. This VBDC
capacity shall be provided in response to explicit requests from the RCST to the NCC, such
requests being absolute (i.e. this request replaces the previous ones from the same RCST).
The AVBDC is used instead of VBDC when the RCST senses that the VBDC request
might be lost (for example in the case of contention minislots).
8.2.4 Non-Requested Capacity
This group contains CRA and FCA. The RCST assumes that these categories of capacity
are assigned at the discretion of the NCC without any intervention by the RCST.
8.2.4.1 CRA
The RCST assumes that the served CRA is provided with low inter-slot interval variance
(low jitter) so that it can be used as a substitute for any RBDC.
The NCC should indicate the actually served CRA level to the RCST (currently not
standardized) – this may also be manually configured in the RCST. The RCST assumes
that the served CRA level indicated by the NCC equals the CRA currently being assigned.
The RCST should take the actually served CRA level into account when requesting for
additional capacity. E.g. if a certain rate is required the RCST subtracts the served CRA
level from the required rate level and requests for the rest as RBDC.
The specification should allow for any level and granularity of CRA, and not limit CRA to
assignment in every super-frame. Instead, CRA should be specified as being assignment of
capacity with minimal inter-slot interval variance (minimal jitter). This is the property that
affects the applications.
8.2.4.2 FCA
Free capacity is assigned at the discretion of the NCC. The RCST makes no assumptions
regarding FCA. The RCST will use any FCA on the same terms as other capacity assigned
to the RCST.
8.2.5 Requested Capacity
This group contains RBDC, VBDC and AVBDC. The RCST assumes that these categories
of capacity are assigned upon category specific requests for a tempered capacity level. The
RCST assumes further that the NCC takes the level and category of the request into
account when deciding on the assignment type and level.
8.2.5.1 RBDC
The RCST requests for assignment of slots with low inter-slot interval variance (low-jitter)
by issuing RBDC request. The RCST uses the RBDC level to indicate the average rate of
the capacity required. A new RBDC request from a RCST takes precedence to previous
RBDC requests from the RCST.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
102 / 266
The NCC indicates to the RCST the maximum RBDC request level that it will take notice
of (currently not standardized) – this parameter may also be manually configured in the
RCST. The RCST applies this limit when issuing requests.
The NCC indicates the RBDC hold-time to the RCST that the NCC applies – this
parameter may also be manually configured in the RCST. The NCC should be allowed to
sustain the assignment at least for a Synchronization Repeat Period (SRP) plus the
indicated RBDC hold-time. Requests are repeated by the RCST as necessary. This means
that repetition of an RBDC request in each dedicated synchronization slot is sufficient to
maintain continuous assignment by the NCC, independent of the RBDC hold-time and the
dynamic assignment of traffic slots. A request can then be maintained even if congestion
prohibits the NCC from providing assignment of any traffic handling capacity. The
maximum value of the RBDC hold-time of 15 superframes would be too low if the NCC
didn’t add the SRP value when applying the timeout because the timer value then would
need to be equal to or higher than SRP+1 in order to guarantee a contiguous service. The
SRP can take values up to 65535.
8.2.5.2 AVBDC/VBDC
The RCST uses AVBDC and VBDC to request for immediate assignment of a certain
number of slots. The RCST assumes that the NCC:
•
•
•
Accrues a VBDC request to a previously signaled AVBDC request
Accrues a VBDC request to previously accrued VBDC requests
Replaces previously accrued requests by an AVBDC request
The NCC indicates to the RCST the maximum accrued backlog of volume that it will take
notice of (currently not standardized) – this parameter may also be manually configured in
the RCST. The RCST applies this limit when issuing requests.
The NCC indicates to the RCST the maximum lifetime of the accrued backlog without a
refresh by a VBDC or AVBDC request (currently not standardized) - this parameter may
also be manually configured in the RCST. The RCST uses this information to refresh the
NCC as necessary.
8.2.5.3 Utilization of capacity
One problem with the current requirements is that a RCST may request for capacity
without having the sufficient ability to fill the requested capacity with user traffic.
The RCST have to be given the responsibility of filling up the requested capacity up to a
minimum level for well-known reference traffic streams like
•
•
•
Return link traffic of FTP download of a reference file size to RCST site
Return link traffic of FTP upload of a reference file size from RCST site
Return link traffic of WEB browsing of a reference web page with client at RCST site
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
103 / 266
Compliance to these requirements can be verified by assigning the low-jitter capacity and
the capacity for immediate delivery exactly as requested by the RCST. The low-jitter
capacity assigned must provide the minimum inter-slot interval variance.
If the RCST is given less capacity than requested it is required that the utilisation is at least
at the minimum level.
It is also required that the RCST reduces an RBDC request according to the level of CRA
that is assigned to the RCST and that is available for the same traffic (i.e. this CRA portion
will probably not be consumed by traffic of higher precedence).
The level of a VBDC/AVBDC request could be reduced by the CRA that becomes
available for the same traffic (i.e. this CRA portion will probably not be consumed by
traffic of higher precedence) within a reasonable time frame.
8.2.6 Algorithms for request and assignment
The specification of the request and assignment system should allow vendors to refine the
algorithms for requesting and assigning capacity as necessary. This includes adaptation to
specific applications as required.
Specific algorithms can be introduced at the discretion of the vendors to provide desirable
application performance and capacity utilization relations for miscellaneous applications
and traffic patterns.
8.2.7 Support of DiffServ
It should be possible to map DiffServ Code-Points (DSCP) to a set of DVB-RCS traffic
classes.
The proposed capacity request model can apply separately for any traffic class. Requests
can be generated independently for each traffic class. Traffic class association should be
signaled with each capacity request to allow the NCC to apply different assignment rules
for the different traffic classes. These rules are applied at the discretion of the NCC.
It is of great significance that the scheduling precedence applied by the RCST is consistent
with the assignment precedence applied by the NCC as seen over the set of supported
traffic classes.
AEO-005479
SATLIFE
D311
RCST
SATLIFE-AEO-SYS-DD-3
FL
IP
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
104 / 266
Classify
Schedule
MPE
IP
IP
MPE/AAL5
IP
NCC
Classify
Request
QoS
QoS
Polic
QoS
Polic
Polic
QoS
QoS
Polic
QoS
Polic
Polic
Assign
RL
QoS
QoS
Polic
QoS
Polic
Polic
Figure 8-2 Capacity Request Model
8.2.8 traffic classes
The diagram below shows the traffic classes in the Nera RCST in the current
implementation.
AEO-005479
SATLIFE
D311
AP
%
" #
#
SATLIFE-AEO-SYS-DD-3
!#
&
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
105 / 266
FRAGMENTATION
!
$
!!
"
#
Figure 8-3 Traffic Classes
8.2.9 Conclusion
The proposed solution for exploiting the difference between RBDC and VBDC/AVBDC
gives the opportunity to minimize the packet transfer delay under heavy load and dynamic
traffic conditions and at the same time keep the utilization at a high level. This can be
utilized to minimize the impact on the applications.
There may be similar needs for several applications, independent of traffic class. A QoS
scheme should thus support separate signaling of traffic class association of requests and
which type of assignment that is required, immediate or low-jitter assignment.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
106 / 266
Nera has been asked to give justifications for not implementing the following functionality
for SatLife:
IPsec or other security solutions
Application acceleration
Header compression
The reply given so far has been: "due to commercial restrictions", and an in-depth
explanation will therefore naturally not be possible to provide. We will however in the
following provide some more background information on the three issues.
8.2.9.1 IPsec or other security solutions
Alignment on security solutions within the DVB-RCS community has been discussed for
several years, and yet no decision has been taken on this issue. It is therefore today up to
the operator and manufacturer to chose the security solution desired, if any desired at all.
This implies, that in order to integrate a security solution in the Nera SatLink equipment,
there are 3 options:
integrate one solution that will be proposed to all customers
integrate several solutions, customer specific and one default
not integrate any solution in the equipment, but use external boxes
It should be noted that any integration of security solution would have to be done in
hardware or firmware in order not to reduce the throughput performance of the Nera
SatLink terminal drastically. It is therefore a costly development, and will also have
hardware implications, that will finally result in higher terminal cost.
So far customer demand for security solutions has not justified the development effort to
integrate the security functionality within the terminal. In addition, some customers
specifically want to use external security solutions in order to be able to control this
equipment themselves. As a consequence Nera has postponed the integration of any
security solution in the terminal.
8.2.9.2 Application acceleration
Nera has in the last release implemented normal TCP acceleration. This acceleration does
not yet include the HTTP acceleration. It has been decided that Nera shall integrate a
solution for HTTP acceleration for the next relase. This solution will not be implemented
and ready for SatLife integration.
8.2.9.3 Header compression
Nera has implemented a proprietary header compression function. But as the proprietary
header compression function currently is not compatible with the on-board processing
architecture used for SatLife tests, header compression has been withdrawn from SatLife.
9. EMS USER TERMINAL
This document defines the specifications for a Nomadic Terminal and a fixed terminal for
use in the SatLife project. It includes operation in both transparent and regenerative modes.
9.1 Introduction
Next figure shows a block diagram of a Nomadic Terminal.
FE ED A R M AS S E M B LY
F e e d H o rn
T ra n s is io n
R e je c t F ilte r
B lo c k U p
C o n v e rte r
LNB
C om pass
In c lin o m e te r
GPS
A n te n n a C o n tro ll U n it
L a p to p
S a te llite N e tw o rk s E 2 0 0 0 M o d e m
w ith A m e rh is S o ftw a re lo a d
Figure 9-1: Nomadic Terminal Block Diagram
9.2 Regulatory Requirements
Amazonas uses extended Ku-band (13.75 to 14.0 GHz) for the spot beam covering Europe.
Operation within this frequency allocation in the UK is currently subject to the fixedsatellite service having an antenna diameter greater than or equal to 4.5 m and the EIRP of
any emission should be at least 68 dBW and should not exceed 85 dBW.
This requirement does not permit the construction of a Nomadic terminal; however the UK
regulatory authority is working to introduce a relaxation to this requirement to permit
operation using 1.2m antenna. This relaxation is not expected to be in place before the end
of 2005.
To enable the Nomadic terminal development to proceed, operation over Hispasat 1D is
proposed. Once the system has been proven on 1D, operation over other satellites will be
performed. The nomadic terminal shall be constructed in such a manner to permit
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
108 / 266
airfreight of the antenna system and indoor unit. This will enable EMS to construct a
nomadic terminal using a vehicle located in Brazil to permit testing over Amazonas.
On the assumption that operation in extended Ku-band will be permitted prior to the start
of trials in 2006 a fixed antenna system shall be located in Tewkesbury to facilitate tests
over Amazonas.
9.3 Design Considerations
To minimize size, weight, cost and avoid having to structurally modify the vehicle to
accept the Nomadic antenna a smaller antenna is desirable.
Weight
The maximum weight for systems mounted on roof bars of vehicles should be less than
75kg (165 lbs). The estimated weight for a 96cm antenna and positioner is 45kg (100lbs),
whereas the weight of a 1.2m system is (91kg) 200 lbs.
Pointing Deflection due to Wind Gusts
The deflection of the positioning system during gusts of wind is proportional to D3 (where
D is the diameter of the antenna). The increase in wind load between a 96 cm dish and a
1.2m dish is almost a factor of 2. The 3dB beam width of a 1.2 m dish is 1.2 degrees; a
96cm has a 3dB beam width of 1.5 degrees so the increased likelihood of excessive
deflection under windy conditions reduces the benefit of a narrow beam width.
Cost
To combat the effects of wind loading and extra weight additional strengthening and larger
motors are required in the positioner to maintain pointing under the same conditions as a
96 cm antenna. This adds considerably to the cost of a 1.2 meter antenna positioner.
Link Budget
A link budget for operation in the UK over Hispasat 1D is presented in 9.6.2.1. This link
budget demonstrates that a 1024 Mbits/s receive and a 256 kbits/s transmit capability can
be achieved from a 96cm antenna with a G/T of 20dBK and an EIRP of 46.2 dBW.
Antenna Size
For the reasons given above a 96cm antenna has been selected for use in the Nomadic
terminal development.
Acquisition of Satellite
The antenna system shall be capable of automatically acquiring the correct satellite without
user input following the command to deploy the antenna issued by the push of a single
button.
This will be accomplished with the aid of the following sensors:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
109 / 266
Flux-gate Compass
Global Positioning System (GPS) Receiver
Integrated Digital Video Broadcast (DVB) Receiver
Level/tilt sensors for base pitch and roll to compensate for base misalignment
DC Servo motors with high resolution optical encoders in all three axes
The Acquisition Process
•
•
•
•
•
•
•
Acquire magnetic north,
Acquire GPS position
Acquire Reference satellite
Compute position of desired satellite relative to reference satellite.
Compute polarization settings
Acquire desired satellite
Peak antenna using step track technique.
Prevention of Transmission during Alignment.
Transmissions shall be inhibited until the antenna is properly aligned to the desired
satellite. Once the alignment phase has been completed the antenna controller sends GPS
data to the SIT. The GPS data is used it to perform initial synchronization and is then used
as the authorization to transmit
Prevention of Transmission to the wrong satellite
Transmission from the SIT can only be activated after Satellite Rx (Forward Link)
acquisition is achieved.
Prevention of Transmission if the antenna moves
The antenna shall have a built in transmit inhibit feature to disable the transmitter should
the user give a command to the antenna control unit to move (i.e. stow) the antenna.
The antenna controller will inhibit transmission in case of signal degradation due to beam
movement.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
110 / 266
9.4 Nomadic Terminal Design Specification
9.4.1 Safety Requirement
All equipment shall be SAFETY Compliant to the relevant sections of EN60950 AD1
9.4.2 EMC Requirement
All equipment shall be EMC / EMR Compliant to the relevant sections of EN300-386 AD2
9.4.3 Terminal Equipment
The Nomadic terminal consists of the following:
Vehicle
Out Door Unit (ODU)
In Door Unit (IDU)
Portable Generator
9.4.4 Vehicle Mounted ODU
9.4.4.1 ODU
The ODU shall comprise a Ku-band vehicle mounted antenna, GPS, Compass,
inclinometer, Block Up Converter (BUC) comprising a Solid State Power Amplifier
(SSPA) and upconverter the ODU also comprises Feed Horn, LNB, Tx Reject filter.
Compass
Inclinometer
GPS
BUC
LNB
Reject Filter
Feed Horn
To IDU Rack - Antenna
Controller
To IDU Rack - Modem
Figure 9-2: ODU Block Diagram
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
111 / 266
9.4.4.1.1 Antenna
A 96cm Ku-band vehicle mounted transportable antenna shall be used. The BUC assembly
shall be mounted on the feed arm of the antenna.
Effective Aperture
Operating Frequency
Polarization
Gain (Midband)
3 dB Beamwidth
Sidelobe Envelope (Tx, Co-Pol dBi)
96cm
Tx 13.75 - 14.50 GHz
Rx 10.70 - 12.75 GHz
Linear,Orthogonal
Tx 41.7 dBi
Rx 39.7 dBi
Tx 1.1°
Rx 1.3°
29-25 Log T
Antenna Cross-Polarization (TX)
30 dB on axis
28 dB 1 dB Contour
25 dB maximum off axis
Antenna Noise Temperature
10° EL 54° K
30° El 47° K
1.3:1 Max
VSWR
9.4.4.1.2 Compass
The Compass shall be mounted on the top edge of the antenna to minimize magnetic
deviations caused by the positioner motors and other metallic items within the positioner
structure.
9.4.4.1.3 GPS
The GPS receiving antenna shall be mounted to have a clear view of the sky. GPS data
shall be passed to the SIT to enable initial timing synchronization with the hub to be
performed. The GPS data shall use the NMEA standard, at 4800bps, N, 8, 1.
9.4.4.1.4 Inclinometer
The inclinometer shall be capable of measuring offsets in both X and Y planes.
9.4.4.1.5 BUC
Input Frequency Range
Input connector
Input VSWR
DC voltage
Reference Frequency Requirement
LO Frequency
950 – 1450 MHz
F – type
2:1
15 to 24 V
55W max
10 MHz -5 to +5 dBm
13.05 GHz
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
112 / 266
LO Phase Noise
-60 dBc / Hz @ 100 Hz
-70 dBc/Hz @ 1kHz
-80 dBc/Hz @ 10kHz
-90 dBc/Hz @ 100kHz
Output Frequency Range
Output Power @ 1 dB compression
Conversion Gain
Gain Flatness
14.0 to 14.5 GHz
36 dBm
55 dB
1.5 dB over 54 MHz
4 dB over 500 MHz
WR75
-40 to +55 degrees C
2.5 kg max
Output Connector
Operating temp
Weight
9.4.4.1.6 LNB
Frequency Range
Noise Figure
Local Oscillator
10.7 - 12.75 GHz.
0.7 dB
Switchable using 22 kHz tone between 9.75
GHz or 10.6 GHz 11/18v?
WR75
F-type.
LNB Input Interface
LNB Output Connector
9.4.4.1.7 Tx Reject Filter
The Tx Reject Filter shall have the following specifications.
The interfaces on the TX reject filter shall be WR75
'
(
'
(
' /
0(
' /
0(
1 2/
3(
1 2/
3(
(1 /
3(
(1 /
3(
11
11
' (
' (
11 '
11 '
(
(
)*
",)
",.
)
4
$
)
$
+ )$
+ ).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
113 / 266
9.4.4.1.8 Feed Horn
The feed horn shall be designed to achieve maximum illumination of the antenna. The
interface to the feed horn shall be WR75
9.4.4.1.9 Antenna Positioner Mechanical Travel
Azimuth
Elevation
Polarisation
+/- >180º from stow
0º to 95º
+/- 90º
9.4.4.1.10 ODU Power Supply
The Nomadic ODU shall not exceed the following power requirements:
Voltage
Current
24V
[20A]
This power shall be provided to the ODU via a multi-way cable from the antenna
controller unit.
9.4.4.1.11 ODU Vehicle Installation
No special tools shall be required to perform the vehicle installation.
The antenna system shall be capable of being secured to vehicle roof bars using standard
“U” bolt fixings.
9.4.4.1.12 Out Door Unit Environmental Specification
The following environmental conditions apply to the externally mounted equipment of the
Nomadic Terminal.
9.4.4.1.12.1 Wind Loading
Operational
Survival
Deployed
Stowed
30mph (48kph)
45mph (72kph)
80mph (128kph)
9.4.4.1.12.2 Temperature Specification
Operational
Survival
Solar Radiation
Relative Humidity
-30ºC to 50ºC
-35ºC to 50ºC
360 BTU/h/ft² 1000 Kcal/h/m²
0-100%
AEO-005479
SATLIFE
D311
Atmospheric Conditions
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
114 / 266
Survive a sand / snow storm. Must be able to stow / deploy
after a sand / snow storm.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
115 / 266
9.4.5 Indoor Unit Subsystems Description
The IDU shall be accommodated in a flight case fitted with an internal rack, a DVB-RCS
modem, Laptop computer, antenna controller and an UPS.
DVB-RCS Modem
ODU
Antenna Controller
UPS
Compass, GPS,
Inclinometer
Laptop
Figure 9-3: IDU Block Diagram
9.4.5.1 Modem (SIT)
The Modem to be used in the Nomadic terminal will be based on the EMS Satellite
Networks E2000. Regenerative operation over the AmerHis payload on Amazonas will be
supported with a specific software load. The standard unit shall be modified to accept GPS
data from the ODU over an RS-232 interface using the NMEA standard, at 4800bps, N, 8,
1.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
116 / 266
9.4.5.1.1 The E2000 modem shall offer the following as a minimum:
9.4.5.1.2 Forward link bit Rate
Up-to 2 Mbps
9.4.5.1.3 Return link bit Rate
Up-to 1 Mbps
9.4.5.1.4 Interoperability
Compatible with EMS and NERA hubs
9.4.5.1.5 Transmit / Receive frequencies
Transmit Frequency Band Available
Ku-Band
Receive Frequency Band Available
Ku-Band
14.0 to 14.5 GHz
(13.75
to
14.25
with
alternative BUC)
10.95 to 11.7 GHz Low Band
12.25 to 12.75 GHz High
Band
9.4.5.2 Antenna Control Unit
The antenna control until shall be mounted in the IDU equipment rack
9.4.5.2.1 Power Supply
The ODU antenna controller shall provide DC power for the azimuth, elevation and
polarization motors, LNB, Integral DVB receiver, Inclinometer, compass and GPS.
The input shall be 100 to 240 V AC 50/60 Hz.
The peak input current shall be less than 9A.
The output shall be 24 V at [20} A
9.4.5.2.2 Satellite Acquisition Modes
Automatic and Manual acquisition modes shall be supported.
9.4.5.2.3 Polarization Setting Modes
Automatic and Manual adjustment modes shall be supported.
9.4.5.2.4 Usable Satellite coordinates
The controller shall store a table of usable satellites.
9.4.5.2.5 Display
The following information display shall be capable of being displayed:
AEO-005479
SATLIFE
D311
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
117 / 266
GPS position,
Antenna pointing information (Azimuth, Elevation and Polarization)
Satellite information (longitude of Satellite)
System Status: dish stowed: satellite acquired.
9.4.5.2.6 Control buttons
•
•
•
Acquire satellite
Stow-the-Dish
Manual control of Azimuth, Elevation and Polarization.
9.4.5.3 Power Supply Unit
The AC power for the Nomadic Terminal will be supplied by use of a portable generator.
The Nomadic IDU has the following power requirements:
Voltage
Current
100-240 V AC 50 / 60 Hz
7A for ACU, 2A for SIT.
The overall power requirements of the Nomadic terminal system are
Voltage
Current
100 to 240 V AC 50/60 Hz
9A peak @ 110 V
9.4.5.4 UPS
The UPS shall be mounted in the IDU rack.
9.4.5.4.1 Input Voltage / Frequency
230Vac 50/60 Hz
9.4.5.4.2 Output Power
500VA: 300W
9.4.5.4.3 Backup Battery Time
Min 5 minutes
9.4.5.5 Portable Generator Requirements
AC Power Supply for the Nomadic Terminal is derived from a portable generator with an
option to use mains when available.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
118 / 266
9.4.5.5.1 Output Power (kw)
Rated
Max
2.0kW
2.5kW
9.4.5.5.2 Output Voltage / Frequency
230Vac 50/60Hz
9.4.5.5.3 Sound Level (dB)
Max
55dB
9.4.5.5.4 Fuel Type
Petrol preferred.
9.4.6 Service Operator
For the duration of the SatLife project Hispasat’s 1D and Amazonas satellites shall be used
in conjunction with the Hispasat hub located in Madrid.
9.5 Operation over Amazonas
For the reasons specified in section 9.2 Regulatory Requirements, operation over the
Amazonas satellite is not permitted from the UK at this time from dishes smaller than
4.5m.
EMS does expect that the regulation will be relaxed in 2006 and for this reason a fixed
antenna will be located at EMS’s UK offices to permit testing over AMHERIS.
The link budget in sections 9.6.2.3 and 9.6.2.4 show that a 1.8m antenna with a G/T of 24
dBK and an HPA of 2 Watts will deliver 518 kbits/s on the return link and 2.073 Mbs/s
forward on the forward link.
The indoor unit of the NOMADIC terminal shall be compatible with the fixed 1.8 m
antenna system.
9.6 Link Budget Calculations
9.6.1 Terminal Deployment
The Nomadic terminal shall be deployable around the world using different satellites.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
119 / 266
9.6.2 HISPASAT
9.6.2.1 Hispasat 1D Link Budget
The Hispasat 1D satellite will be used for trials from the UK due to regulatory restrictions
applying to operation in the extended Ku band as discussed in section 9.2.
Figure 9-4 Hispasat 1D European Footprint
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
120 / 266
9.6.2.1.1 Tewkesbury – Hispasat 1D - Madrid Link Budget
Nomadic Up Link budget is based upon 256Kbps and a Tx antenna size of 0.96m
Link Input Parameters
Up
Down
Units
Site latitude
51.98N
40.42N
degrees
Site longitude
2.15W
3.72W
degrees
Availability (average year)
99.9
99.9
Antenna aperture
0.96
3.7
Antenna efficiency / gain
41.7
52.9
Coupling loss
0.5
0.5
Antenna tracking / mispoint error
0.3
%
metres
% (+ prefix dBi)
dB
0.3
dB
LNB noise figure / temp
0.7
dB (+ prefix K)
Antenna noise
54
K
Satellite Input Parameters
Value
Units
Satellite longitude
30.00W
degrees
Receive G/T
Carrier/Link Input Parameters
4.5
Required Eb/No with FEC coding
Units
8
Information rate
0.256
FEC code rate
0.875
System margin
General Calculations
dB
Mbps
1
Up
Antenna efficiency
Antenna gain
Uplink Calculation
dB/K
Value
86.43
41.7
52.9
Rain Up
46.22
Mispoint loss
Atmospheric absorption
Units
76.47
Clear
Uplink transmit EIRP
dB
Down
%
dBi
Rain Dn
46.22
Units
46.22
dBW
0.3
0.3
0.3
dB
0.16
0.16
0.16
dB
Tropospheric scintillation fading
0.46
0.46
0.46
dB
Atmospheric losses total
0.63
0.63
0.63
dB
Rain attenuation
Eb/(No+Io)
Downlink Calculation
0
2.02
0
dB
16.64
14.62
16.64
dB
Clear
Rain Up
Rain Dn
Units
Satellite EIRP total
48
48
48
dBW
Mispoint loss
0.3
0.3
0.3
dB
Atmospheric absorption
0.09
0.09
0.09
dB
Tropospheric scintillation fading
0.21
0.21
0.21
dB
0.3
0.3
0.3
dB
Rain attenuation
Atmospheric losses total
0
0
1.02
dB
Noise increase due to precipitation
0
0
1.41
dB
Downlink degradation (DND)
Figure of merit (G/T)
Eb/(No+Io)
Totals per Carrier (End-to-End)
Net Eb/(No+Io)
Required Eb/(No+Io)
Excess margin
0
0
2.43
30.95
30.95
29.54
dB/K
19.99
dB
20.64
Clear
18.62
Rain Up
Rain Dn
dB
Units
14.19
12.16
13.99
dB
8
8
8
dB
6.19
4.16
5.99
dB
AEO-005479
SATLIFE
D311
Earth Station Power Requirements
EIRP per carrier
Antenna gain
Waveguide loss
Required HPA power capability
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
121 / 266
Value
Units
46.22
dBW
41.7
dBi
0.5
dB
4
W
9.6.2.1.2 Madrid - Hispasat 1D - Tewkesbury Link Budget
Nomadic Forward Link budget is based upon 1.024Kbps and a Rx antenna size of 0.96m.
Link Input Parameters
Site latitude
Site longitude
Antenna aperture
Antenna efficiency / gain
Coupling loss
Antenna tracking / mispoint error
LNB noise figure / temp
Antenna noise
Satellite Input Parameters
Satellite longitude
Receive G/T
Carrier/Link Input Parameters
Information rate
FEC code rate
System margin
General Calculations
Antenna efficiency
Antenna gain
Uplink Calculation
Uplink transmit EIRP
Mispoint loss
Free space loss
Atmospheric absorption
Tropospheric scintillation fading
Atmospheric losses total
Rain attenuation
Downlink Calculation
Satellite EIRP total
Mispoint loss
Atmospheric absorption
Tropospheric scintillation fading
Atmospheric losses total
Rain attenuation
Noise increase due to precipitation
Downlink degradation (DND)
Figure of merit (G/T)
Totals per Carrier (End-to-End)
Net Eb/(No+Io)
Required Eb/(No+Io)
Excess margin
Earth Station Power Requirements
EIRP per carrier
Antenna gain
Up
40.42N
3.72W
3.7
52.9
0.5
0.3
Value
30.00W
4.5
Value
1.048
0.875
1
Up
67.86
52.9
Clear
48.87
0.3
206.88
0.11
0.23
0.33
0
Clear
50
0.3
0.14
0.43
0.57
0
0
0
19.75
Clear
9.68
8
1.68
Value
48.87
52.9
Down
51.98N
2.15W
0.96
41.7
0.5
0.3
0.7
54
Down
97.39
41.7
Rain Up
48.87
0.3
206.88
0.11
0.23
0.33
1.41
Rain Up
50
0.3
0.14
0.43
0.57
0
0
0
19.75
Rain Up
8.27
8
0.27
Units
degrees
degrees
metres
% (+ prefix dBi)
dB
dB
dB (+ prefix K)
K
Units
degrees
dB/K
Units
Mbps
Rain Dn
48.87
0.3
206.88
0.11
0.23
0.33
0
Rain Dn
50
0.3
0.14
0.43
0.57
1.51
1.86
3.37
17.89
Rain Dn
8
8
0
dB
Units
%
dBi
Units
dBW
dB
dB
dB
dB
dB
dB
Units
dBW
dB
dB
dB
dB
dB
dB
dB
dB/K
Units
dB
dB
dB
Units
dBW
dBi
AEO-005479
SATLIFE
D311
Waveguide loss
Required HPA power capability
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
122 / 266
0.5
0.5581
dB
W
9.6.2.2 Amazonas 61ºW
The Hispasat Amazonas satellite will be used to test and verify the SatLife developments.
The European footprint will be used. The footprint is illustrated below:
Figure 9-5 Hispasat Amazonas European Footprint
Tewkesbury is approximately on the 10º and 47dB contours.
9.6.2.3 Tewkesbury - Amazonas - Madrid Link Budget
Link budget based on 518 kbits/s return channel using 1.8m antenna
Link Input Parameters
Up
Down
Site latitude
51.98N
40.42N
degrees
Site longitude
2.15W
3.72W
degrees
1.8
3.7
46.8
51.7
Antenna aperture
Antenna efficiency / gain
Units
metres
% (+ prefix dBi)
Coupling loss
0.5
0.5
dB
Antenna tracking / mispoint error
0.3
0.3
dB
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
123 / 266
LNB noise figure / temp
0.7
dB (+ prefix K)
Antenna noise
39
K
Satellite Input Parameters
Value
Satellite longitude
Units
61.00W
Receive G/T
degrees
3.7
dB/K
Carrier/Link Input Parameters
Value
Units
Information rate
0.518
Mbps
FEC code rate
0.875
System margin
1
General Calculations
dB
Up
Down
Antenna gain
46.8
51.7
dBi
Availability (average year)
99.9
99.9
%
Clear
Rain Up
Rain DnUnits
48.4
48.4
48.4 dBW
0.3
0.3
0.3 dB
207.43
207.43
207.43 dB
0.4
0.4
0.4 dB
Tropospheric scintillation fading
1.33
1.33
1.33 dB
Atmospheric losses total
1.72
1.72
1.72 dB
0
3.83
0 dB
Clear
Rain Up
50
50
50 dBW
31.69
27.86
31.69 dBW
Uplink Calculation
Uplink transmit EIRP
Mispoint loss
Free space loss
Atmospheric absorption
Rain attenuation
Downlink Calculation
Satellite EIRP total
Satellite EIRP per carrier
Mispoint loss
Free space loss
Atmospheric absorption
Units
Rain DnUnits
0.3
0.3
0.3 dB
206.24
206.24
206.24 dB
0.2
0.2
0.2 dB
Tropospheric scintillation fading
0.58
0.58
0.58 dB
Atmospheric losses total
0.79 dB
0.79
0.79
Rain attenuation
0
0
1.8 dB
Noise increase due to precipitation
0
0
2.29 dB
Downlink degradation (DND)
0
0
4.09 dB
Figure of merit (G/T)
30.22
30.22
Earth Station Power Requirements
Value
Units
EIRP per carrier
48.4
dBW
Antenna gain
46.8
Antenna feed flange power per carrier
27.93 dB/K
dBi
1.6
HPA output back off
Waveguide loss
Required HPA power capability
dBW
1
dB
0.5
dB
2.0401
W
9.6.2.4 Madrid - Amazonas - Tewkesbury Link Budget
Link budget based on 2073 kbits/s forward channel using a 1.8m antenna
Link Input Parameters
Site latitude
Site longitude
Antenna aperture
Antenna efficiency / gain
Coupling loss
Antenna tracking / mispoint error
Up
40.42N
3.72W
3.7
52.9
0.5
0.3
Down
51.98N
2.15W
1.8
45.3
0.5
0.3
Units
degrees
degrees
metres
% (+ prefix dBi)
dB
dB
AEO-005479
SATLIFE
D311
LNB noise figure / temp
Antenna noise
Satellite Input Parameters
Satellite longitude
Receive G/T
EIRP (saturation)
Carrier/Link Input Parameters
Required Eb/No with FEC coding
Information rate
FEC code rate
System margin
General Calculations
Antenna gain
Availability (average year)
Uplink Calculation
Uplink transmit EIRP
Mispoint loss
Free space loss
Atmospheric absorption
Tropospheric scintillation fading
Atmospheric losses total
Uncompensated rain fade
Eb/(No+Io)
Downlink Calculation
Satellite EIRP total
Transponder output back-off (total)
Output back-off per carrier
Satellite EIRP per carrier
Mispoint loss
Free space loss
Atmospheric absorption
Tropospheric scintillation fading
Atmospheric losses total
Total path loss (excluding rain)
Rain attenuation
Noise increase due to precipitation
Downlink degradation (DND)
Figure of merit (G/T)
Totals per Carrier (End-to-End)
Required Eb/(No+Io)
Excess margin
Earth Station Power Requirements
EIRP per carrier
Antenna gain
Required HPA power capability
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
124 / 266
0.7
43
dB (+ prefix K)
K
Units
degrees
dB/K
dBW
Units
dB
Mbps
Value
61.00W
3.7
47
Value
8
2.073
0.875
1
Up
Down
52.9
99.9
Clear
54.16
0.3
207.29
0.23
0.62
0.85
0
14.51
Clear
47
6.52
11.53
35.47
0.3
206.38
0.35
1.24
1.59
207.97
0
0
0
23.69
Clear
8
2.91
Value
54.16
52.9
1.8892
45.3
99.9
Rain Up
54.16
0.3
207.29
0.23
0.62
0.85
2.41
12.1
Rain Up
47
6.52
13.94
33.06
0.3
206.38
0.35
1.24
1.59
207.97
0
0
0
23.69
Rain Up
8
0.49
Rain Dn
54.16
0.3
207.29
0.23
0.62
0.85
0
14.51
Rain Dn
47
6.52
11.53
35.47
0.3
206.38
0.35
1.24
1.59
207.97
2.91
2.92
5.82
20.77
Rain Dn
8
0
dB
Units
dBi
%
Units
dBW
dB
dB
dB
dB
dB
dB
dB
Units
dBW
dB
dB
dBW
dB
dB
dB
dB
dB
dB
dB
dB
dB
dB/K
Units
dB
dB
Units
dBW
dBi
W
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
125 / 266
9.7 Conclussions
The EMS proposal for SATLIFE was to build and test a nomadic DVB-RCS terminal. The
addition of new software features was not part of our original input to the proposal.
During the project EMS SATCOM expected to be able provide some additional features
subject to them being available in the software load delivered by EMS SATNET. EMS
SATNET has not been funded under the SATLIFE project so any additional capabilities
could not be delivered on a contractual basis. After the first few months of the project it
became clear that EMS was going to sell EMS SATNET at this point their commitment to
add features not specifically required by their customer base diminished.
Further to the above EMS SATNET has implemented IPSEC and PEP but these features
are only compatible with an EMS hub. It is outside the scope of the project to modify
these features to work over the NERA hub.
10. SERVICE PROVIDER DESIGN
10.1 Introduction
In the framework of IST IBIS project, Thales B&M has developed a Video Service
provider unit.
The goal of the equipment was to permit to broadcast MPEG2 video through IBIS system
thanks to the Shiron SP-RCST terminal.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
126 / 266
Opal Manager
MPEG-2 TS over
RTP/UDP/IP
IP source
TCP/IP API
Video source
OpenMux Server
(Service Provider)
Coral Manager
Figure 10-1 Service Provider unit
It was also ensuring a powerful IP gateway feature that permit to simultaneously
encapsulate IP data into the same MPEG2 TS.
All combinations are possible for sources : video only, IP only, video and IP.
Video source may be a file or a live transport stream.
The Thales contribution into SatLife is mainly to permit to broadcast new codec H264 and
to offer video monitoring capabilities of the SatLife .system.
This result in two main contributions:
Improvement of the Service Provider unit at SP-SPRCST interface level,
according to new requirements raised in the "Service Requirements"
document and to offer support H264 video broadcast support,
Development of a video monitoring unit offering MPEG2 Transport
stream, MPEG2 Video and H264 video monitoring and analysis.
10.2 Transmission system overview
As said in introduction, the goal of the system is to broadcast audio-video streams and IP
streams.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
127 / 266
The streams can be made of MPEG-2 or H-264 video.
The figure below shows the global architecture of the transmission system, including
Multiplexer, server and DVB RCS satellite transmission.
Multiplexer / Server global Architecture
Audio/Video streams
in MPTS ASI
ASI
IP
IP Streams (video or data)
UDP | TCP / IP
MPEG2 packets under RTP
UDP/IP
MPEG2 Multiplexer
SOF
Server supervision &
command
SP-RCST
MPTS Audio, video, IP
MPEG2 Streams
Files
File Audio, video MPEG2
Streams
TCP/IP
DVB RCS
Satellite
Transmission
Messages
TCP/IP
Audio / Video Server
TCP/IP
Figure 10-2 Global Transmission System Diagram
The transmission system solution is based on the OpenMUX multiplexing technology to
encapsulate MPEG-2 streams and services into MPEG-2/DVB Transport Streams, ready to
be broadcast.
The OpenMUX kernel can handle various types of inputs simultaneously (Single Program
TS, Multiple Programs TS, PSI/SI tables or IP frames) and generates an MPEG-2
Transport Stream output. The Multiplexer encapsulates IP frames into DVB-SI DAT
protocols that can be handled simultaneously: Data Piping, Data Streaming, Multi Protocol
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
128 / 266
Encapsulation (with or without overhead optimisation) and Data Carrousel. Multi Protocol
Encapsulation includes: CRC or Checksum, SNAP management, 8 or 32 bit alignment.
The Openmux kernel will take into account the stream adjustment needed to broadcast
video streams through SatLife network.
The MPEG-2 and H264 audio/video stream may be a live stream or stored as a file on the
server.
The Server is designed as a broadcast server aiming to broadcast the MPEG-2 over IP or
H-264 over IP audio-video streams and to transmit it via a Network.
The Multiplexer, the Server and the DVB Transmission are described in the chapters
below.
THALES BM is in charge of the Multiplexer and Server Part.
SHIRON is in charge of the DVB RCS Transmission / Network Part.
10.3 Multiplexer
The objective of this chapter is to describe the IP to MPEG-2 multiplexer based on
THALES B&M OpenMux® server technology.
Figure 10-3 Multiplexer architecture
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
129 / 266
10.4 Inputs
Inputs are IP data, live streams, MPEG-2 and H264 files, TCP/IP messages.
IP data are coming from a network connecting to a fast ethernet board equipped with RJ45 connector.
10.4.1 IP Frame Input
This input work as a network "sniffer". It takes IP frames from the LAN connected to the
OpenMux PC Ethernet interface board and make the encapsulation in transport packets
according
to
DVB-SI
DAT
protocols.
The server has one 10/100 Base T Ethernet port for administration and one 10/100 Base T
Ethernet port for data (RJ45 connectors).
Each of these Ethernet ports is independent. The server manages all the IP datagrams
arriving on these network ports, even if these datagrams are not “in destination of “ the
gateway. This is the filtering mechanism, which selects the IP datagram that will be
encapsulated (see the IP filtering chapter).
With these ports, the server can receive independently unicast and multicast datagrams.
10.4.2 Live input
Live stream source is connecting to PIA+ Thales board.
The input is in ASI format. The expected transport packet are 188 bytes long. The ASI
format may be made in ‘packet mode’ or byte mode. The maximum input rate is 38 Mbps.
Figure 10-4 PIA + Board
Its main characteristics are as follows :
ASI input
Connector
ASI bit rate
BNC, Female
270 Mbps, ± 100 ppm
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
130 / 266
Transport stream rate per 38 Mbps, maximum
input
1 Mbps, minimum
Data format
Accepts both burst and packet mode
of ASI format
Packet length
188 bytes
Signal amplitude
880 mV p-p maximum
200 mV p-p minimum
Termination
75
Return loss
– 17 dB, 27 to 270 MHz
MPEG-2 files are stored on server hard drives.
10.4.3 MPEG2 and H264 video Transport Stream packets file
Expected H264 file format shall follow below requirements :
•
•
•
•
•
•
•
•
•
•
•
•
File containing a video component compliant with 14496-10 standard in raw byte
or MPEG2 Transport Stream.
Raw byte file shall contain data in NAL units preceded by a start code prefix
(compliant with 14496-10 Annnex B).
MPEG2 Transport stream file shall contain correct PSI (compliant with MPEG2
standard). At least, a PAT which is referencing a PMT, which is itself referencing a
H264 component.
MPEG2 Transport stream file shall contain a whole number of transport stream
packet (188 bytes long).
Expected Rate : CBR, between 1 and 2 Mbits (will be communicated by GUI or
additional file)
Frames : I, P
Progressive video (interlaced not supported)
Video component : YUV 4:2:0
GOP every second (around each 24/25 frames)
I frame = IDR frame (Intra / Instantaneous Decoder reference)
SPS/PPS before IDR (Sequence Parameter Set / Picture Parameter Set)
Audio : Dolby AC3, MPEG Layer II, AAC (HE-AAC not supported)
Expected MPEG2 video file format shall follow below requirements :
• MPEG2 Transport stream file compliant with MPEG2 standard. It shall contain
correct PSI. At least, a PAT which is referencing a PMT, which is itself referencing
a H264 component.
Provided H264 raw byte file will be first encapsulated into MPEG2 transport packet
before broadcasting.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
131 / 266
10.5 Supervision
The Multiplexer is supervised and configured through a private TCP/IP control port : A
client application permits to supervise different inputs as IP input, live input, file input,
multiplexer status, output status.
A dedicated client application permits to check more in depth IP input.
10.6 Outputs
The generated MPEG-2 transport packets are 188 bytes long.
The service provider (SP) encapsulates the MPEG-2 transport packets into an UDP/IP
datagrams (User Datagram Protocol). An UDP datagram can have a maximum length of
65,535 bytes ; the MTU of an IP frame for Ethernet is 1,500 bytes. To avoid UDP
datagram segmentation, the SP puts one UDP datagram in one IP frame. Also, the SP puts
only complete transport packet in the UDP datagram. With these features, the number of
transport packet in one UDP/IP datagram is 7.
The SP uses a RTP header just before to put the transport packet in the datagram.
RTP header is added just after the UDP header.
IP header :
UDP header:
RTP header:
Transport packets (7 * 188) :
Total IP datagram length:
The UDP/IP overhead is 2.95 %.
20
8
12
1,316
1,356
bytes
bytes
bytes
bytes
bytes
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
TS Packet
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
132 / 266
...
TS Packet
RTP Header
TS Packet
data
UDP Header
data
IP Header
data
1356 bytes
The main field that the SP manages in the RTP header are the sequence number and
the timestamp.
The RTP sequence order is a value incremented for each RTP/UDP packet sent.
This enables the receiver to detect the loss of datagrams. This loss can be caused by
the MAC layer, when a checksum is incorrect (errors of bit in the frame) or when
there is a network overflow. Therefore, the frame is dropped.
The RTP timestamp is an additional clock reference for the receiver. The SP puts in
this field a value computed like a PCR, just before sending the IP datagram onto the
network. It can help for the transport packet buffering and the synchronization
between video and audio. It can also be used to detect a network jitter.
The RTP Header is described in RFC 1889 with the following format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
|V=2|P|X| CC
|M|
PT
|
sequence number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
|
timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
AEO-005479
SATLIFE
D311
|
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
133 / 266
synchronization source (SSRC) identifier
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+
|
contributing source (CSRC) identifiers
|
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
The first twelve octets are present in every RTP packet, while the list of CSRC
identifiers is present only when inserted by a mixer.
The fields have the following meaning:
version (V): 2 bits
This field identifies the version of RTP. The version defined by this
specification is two (2). (The value 1 is used by the first draft version of RTP and
the value 0 is used by the protocol initially implemented in the "vat" audio tool.)
padding (P): 1 bit
If the padding bit is set, the packet contains one or more additional padding
octets at the end which are not part of the payload. The last octet of the padding
contains a count of how many padding octets should be ignored. Padding may be
needed by some encryption algorithms with fixed block sizes or for
carrying several RTP packets in a lower-layer protocol data unit.
The SP set this value to 0, that means no padding.
extension (X): 1 bit
If the extension bit is set, the fixed header is followed by exactly one header
extension, with a format defined in Section 5.3.1 of the RFC.
The SP set this value to 0.
CSRC count (CC): 4 bits
The CSRC count contains the number of CSRC identifiers that follow the
fixed header.
The SP set this value to 0.
marker (M): 1 bit
The interpretation of the marker is defined by a profile. It is intended to allow
significant events such as frame boundaries to be marked in the packet stream. A
profile may define additional marker bits or specify that there is no marker bit by
changing the number of bits in the payload type field (see Section 5.3).
The SP set this value to 0.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
134 / 266
payload type (PT): 7 bits
This field identifies the format of the RTP payload and determines its
interpretation by the application. A profile specifies a default static mapping of
payload type codes to payload formats. Additional payload type codes may be
defined dynamically through non-RTP means (see Section 3 of the RFC). An initial
set of default mappings for audio and video is specified in the companion profile
Internet-Draft draft-ietf-avt-profile, and may be extended in future editions of the
Assigned Numbers RFC 1700. An RTP sender emits a single RTP payload type at
any given time; this field is not intended for multiplexing separate media streams
(see Section 5.2 of the RFC).
The SP set this value to 33 (M2TP [0100001]).
sequence number: 16 bits
The sequence number increments by one for each RTP data packet sent, and
may be used by the receiver to detect packet loss and to restore packet sequence.
The initial value of the sequence
number is random (unpredictable) to make known-plaintext attacks on
encryption more difficult, even if the source itself does not encrypt, because the
packets may flow through a translator that does. Techniques for choosing
unpredictable numbers are discussed in RFC 1750.
timestamp: 32 bits
The timestamp reflects the sampling instant of the first octet in the RTP data
packet. The sampling instant must be derived from a clock that increments
monotonically and linearly in time
to allow synchronization and jitter calculations (see Section 6.3.1 of RFC
1889).
The resolution of the clock must be sufficient for the desired
synchronization accuracy and for measuring packet arrival jitter (one tick per video
frame is typically not sufficient). The clock frequency is dependent on the format
of data carried as payload and is specified statically in the profile or payload format
specification that defines the format,
or may be specified dynamically for payload formats defined through nonRTP means. If RTP packets are generated periodically, the nominal sampling
instant as determined from the sampling clock is to be used, not a reading of the
system clock. As an example, for fixed-rate audio the timestamp clock
would likely increment by one for each sampling period. If an audio
application reads blocks covering 160 sampling periods from the input device, the
timestamp would be increased by 160 for each such block, regardless of whether
the block is transmitted in a packet or dropped as silent.
The initial value of the timestamp is random, as for the sequence number. Several
consecutive RTP packets may have equal timestamps if they are (logically)
generated at once, e.g., belong to the same
video frame. Consecutive RTP packets may contain timestamps that are not
monotonic if the data is not transmitted in the order it was sampled, as in the case of
MPEG interpolated video frames. (The
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
135 / 266
sequence numbers of the packets as transmitted will still be monotonic.)
The SP set this value with the same algorithm as MPEG-2 PCR.
SSRC: 32 bits
The SSRC field identifies the synchronization source. This identifier is chosen
randomly, with the intent that no two synchronization sources within the same RTP
session will have the same SSRC identifier. An example algorithm for generating a
random identifier is presented in Appendix A.6 of RFC 1889. Although the
probability of multiple sources choosing the same identifier is low, all RTP
implementations must be prepared to detect and resolve collisions. Section 8 of
RFC 1889 describes the probability of collision along with a mechanism for
resolving collisions and detecting RTP-level forwarding loops based on the
uniqueness of the SSRC identifier. If a source changes its source transport address,
it must also choose a new SSRC identifier to avoid being interpreted as a looped
source.
The SP sets a random value for this field.
CSRC list: 0 to 15 items, 32 bits each
The CSRC list identifies the contributing sources for the payload contained in
this packet. The number of identifiers is given by the CC field. If there are more
than 15 contributing sources, only 15 may be identified. CSRC identifiers are
inserted by mixers, using the SSRC identifiers of contributing
sources. For example, for audio packets the SSRC identifiers of all sources
that were mixed together to create a packet are listed, allowing correct talker
indication at the receiver.
The SP doesn’t set any item.
10.7 Multiplexing
The Multiplexer is based on a PC server platform with at least two Ethernet network board.
The software providing the IP/DVB Multiplexer function is based on OpenMux®
technology. This technology is based on a software-multiplexing kernel of Client/Server
type. This kernel in fact provides the server side. the Multiplexing Manager mainly
provides the client part: This application is totally dedicated to supervision and definition
of the various parameters of the IP/DVB Multiplexer function.
The client/server notion can be used to obtain highly complex configurations where
various clients in different places carry out the management of a particular IP gateway. The
following figure describes this type of architecture, separating all the functions in various
places.
However, the server and the client applications may all be based on the same machine.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
Multiplexing
Manager
Multiplexing
Manager
Management
Network 1, 2,3
Management
Network 4, 5
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
136 / 266
Fast Ethernet
Ethernet Network control/supervision
IP Data
Fast Ethernet
Ethernet Network Broadcasting
SATELLITE
IP/DVB
Multiplexer
Figure 10-5 Example of architecture
In this example of configuration:
The Multiplexer receives all the data on a single Ethernet network board.
Supervision is carried out via the second Ethernet link.
Two Multiplexing Manager applications are used to define and supervise IP services (sub
network 1, 2, 3 and under network 4 and 5).
The Multiplexer broadcasts directly via a modulator (see DVB Transmission).
This configuration is given, just to show the various supervision possibilities. It is of
course, possible to manage all the features from the Multiplexer itself !
10.8 OpenMux® KERNEL
OpenMux® is a real time MPEG-2 transport stream software multiplexer. It can handle
several inputs of different types simultaneously and generate an MPEG-2 Transport Stream
output.
The inputs can be SPTS (single program transport stream), MPTS (multiple programs
transport stream), private data, PSI/SI tables or IP frames.
The main characteristics are as follows :
• Dynamic management of MPEG-2 PSI and DVB-SI tables (NIT, SDT, TDT).
• File multiplexing.
• Allocation and dynamic filtering of PIDs.
• Restamping of PCRs.
• Rate reduction by filtering of PIDs.
AEO-005479
SATLIFE
D311
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
137 / 266
Encapsulation of IP frames in DVB-SI DAT format.
Optional "live" MPEG-2 TS input by adding a PIA+ board.
Optional radio input by adding a DIGIGRAM compression board.
The OpenMux® output based on the PIA+ board has the following characteristics :
• Transport packets of 188 bytes.
• DVB-PI ASI interface.
The following diagram describes the architecture and the main OpenMux® inputs and
outputs.
BUFFER
File
SI Editor/
Compiler
Task
IP frames
Network
Socket Client
PIA+ board
TS Input 1
TS Input 1
Management
Management
Task
Task
Communication
Communication
Task
Task
TS Input 1
TS Input 1
Management
Management
Task
Task
TS Input 2
TS Input 2
Management
Management
Task
Task
TS Output 1
TS Output 1
Management
Management
Task
Task
File
Multiplexer
Multiplexer
Task
Task
TS Input 3
TS Input 3
Management
Management
Task
Task
TS Input N
TS Input N
Management
Management
Task
Task
TS Input N
TS Input N
Management
Management
Task
Task
Figure 10-6 OpenMux Architecture
TS Output 2
TS Output 2
Management
Management
Task
Task
TS Output M
TS Output M
Management
Management
Task
Task
PIA+ board
Network
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
138 / 266
Each input task manages independently one data type.
The IP gateway function is provided by the IP frames type input.
The IP Multiplexer software is dedicated to IP frames management. Due to the
OpenMux versatile architecture, different input configurations may be easily proposed.
The OpenMux® IP input can take IP frames from a network and encapsulate them to the
following protocols:
• DVB SI DAT data piping.
• DVB SI DAT data streaming.
• DVB SI DAT Multiprotocol Encapsulation (MPE).
Using the source and/or destination IP address can filter the IP frames. A particular IP
frame can be encapsulated simultaneously in different protocols.
10.8.1 Principle
Multiplexing enables simultaneous distribution of MPEG-PSI tables, DVB-SI tables, and
the packets containing the IP frames (see diagram below).
The Multiplexer can manage 25 different IP inputs simultaneously (i.e. 25 services each
having one component). These values can change depending on the server capacity.
MPEG2 PSI
Tables
Input 1
Fast Ethernet
Input 2
Multiplexing
function
Output
Input 3
Input 4
Figure 10-7 OpenMux Multiplexing Principle
For each IP input, the following can be defined :
MPEG2-TS
DVB-PI Output
AEO-005479
SATLIFE
D311
•
•
•
•
•
•
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
139 / 266
Input name (used for the service name),
Value of the PID containing the IP frames.
The bandwidth allocated in the transport stream (the rate),
The network board associated with this input,
The frame encapsulation protocol,
For MPE mode, the IP address MAC address mapping,
The program number,
The PID containing the PMT (Program Map Table),
The FIFO sizes (used to absorb the network bursts),
The IP frame filtering principle.
A filter is composed of an IP address and a sub-network mask. For each input, the user can
define:
• Up to 255 filters on the source IP address (NFs),
• Up to 255 filters on the destination IP address (NFd).
• NFs + NFd shall be lower than 255
The Multiplexer is equipped with two 10/100 Mbits/s Ethernet network boards. In addition,
other boards can be added to physically separate the networks (Up to 4 total data networks
+ 1 control network).
The Configurator and IP Manager clients can carry out input supervision. Also, with the
API (Application Programming Interface, see the "API description" chapter), the user can
develop his own applications or include information concerning the gateway in an existing
application.
10.8.2 MPEG-2 – DVB SI Tables management
The service provider unit is constructing entirely all its own PSI/SI tables (PAT, PMT,
SDT, EIT present/following, NIT).
Those tables are sent according to the global table management in SatLife. It means service
provider is sending its PSI/SI sections to the SP-RCST by a specific connection.
10.8.3 Hardware Configuration
The Multiplexer is composed of a server PC platform running under Windows NT
environment, including a THALES Broadcast & Multimedia PIA+ board in PCI format
dedicated to MPEG-2-DVB stream acquisition in DVB-PI ASI format.
10.8.4 File broadcasting
File broadcasting can be used to generate private data. This private data has to be stored in
transport packet format or section format. This can be video files, or interactive data files
for example. Each file can be broadcasted in loop mode or in “one way”.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
140 / 266
The file broadcasting can be technically shown like this :
CommuniCommunication
task :
cation
API task :
API
PSI input task
PSI input task
File
FIle input task
FIle input task
Multiplexing
Multiplexing
task
task
Following
file
Polling
Present
file
FIle input task
FIle input task
Present
file
FIle input task
FIle input task
Output
Output
Figure 10-8 File Broadcasting Architecture
With this architecture, there are tree ways to broadcast transport packet files:
• Manually
• Automatic/polling
• Throw the API
According to this:
• The file can be played without any update Manual mode
• The file can be played in loop mode with updates managed by the user. The
following file is browsed on the server and played manually or when the present
file is finished Manual mode
• The file can be played until a new file is stored in the appropriate directory (same
file name) Automatic/polling mode
• The file can be played until a new file is stored in the appropriate directory at a
specific time. The date and time are specified in the file name
Automatic/polling
mode
Manually
Advantage
Very simple
Direct action on
Disadvantage
Always need a user to
the change the broadcasted
AEO-005479
SATLIFE
D311
Polling
API
SATLIFE-AEO-SYS-DD-3
broadcast (stop, pause,
start, …)
Very easy to use.
Very simple to update the
broadcasted files
Very powerful in term of
time management and PSI
(able to do all the
configuration)
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
141 / 266
files
Less management of PSI
when
changing
the
broadcasted file
Need
specific
development
for
the
customer.
In the server, the broadcasted file mechanism is based on the “present/following” function.
The present is the actual broadcasted file, the following is the next file to broadcast. The
following can be not define. In this case, this is the present which is broadcasted until the
end of the file arrives or when the user wants (if this file is in a loop mode).
For each Input/Service the PSI SI PSIP table can be manage individually.
10.8.5 MPEG-2/DVB Encapsulation And Signaling Protocols
The various protocols and the MPEG-2/DVB signaling comply fully with the DVB-SI
DAT standard. The figure below shows the general IP Multi Protocol Encapsulation
scheme:
TS PAYLOAD
PID
TS packet
MAC
MPE/TS encapsulation
SECTION PAYLOAD
MAC
MPE section
IP datagram
IP/MPE encapsulation
IP dest IP sour
IP Payload
IP datagram
Figure 10-9 IP Encapsulation
10.8.5.1 Data Piping
In this encapsulation mode, the IP frames are placed directly in the payload of transport
packets. The payload of a transport packet can contain only one IP frame.
The following diagram gives the example of IP datagram insertion in transport packets:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
IP Datagram <
184 Bytes
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
142 / 266
184 < IP Datagram < 368 Bytes
0xFF
pusi = 1
tp = 1
184 Bytes
0xFF
pusi = 1
tp = 0
pusi = 0
tp = 1
Data Piping encapsulation
The beginning of a datagram is signaled by a payload_unit_start_indicator field set to 1.
The end of a datagram is signaled with a transport_priority field set to 1.
10.8.5.2 Data Streaming
This protocol uses "PES" encapsulation of IP frames. Only one IP frame is carried in each
PES. Organization of PES into transport packets complies with standard ISO/IEC 13818-1
(MPEG-2 system). The following diagram gives the example of IP datagram insertion in
PES and then transport packets:
Adaptation
IPDatagram <
180 Bytes
180 < IP Datagram < 368 Bytes
PES
PES
Adaptation
field
Adaptation
field
pusi = 1
184 Bytes
pusi = 1
pusi = 0
Figure 10-10 Data Streaming Encapsulation
10.8.5.3 Multi-Protocol Encapsulation
In this protocol, one IP frame is encapsulated in one MPEG-2 section. The multiplexer
uses the data of this section directly to insert the IP frame.
The following diagram gives a non optimized section encapsulation method In this mode
there is at most one IP frame per transport packet.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
IP Datagram 1
< 171 Bytes
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
143 / 266
184 Bytes < IP Datagram 2
Section 1
Section 2
Stuffing
pusi = 1
184 Bytes
Stuffing
pusi = 1
pusi = 0
Figure 10-11 Multi Protocol Encapsulation
An optimized mode exists and is shown on the following diagram:
IP Datagram 1
< 171 Bytes
184 Bytes < IP Datagram 2
Section 1
Section 1
pusi = 1
Section 2
Section 2
Section 2
184 Bytes
Section 2
pusi = 1
Section 3 ...
pusi = 0
Figure 10-12 Optimized MPE
This implementation minimizes particularly the protocol overhead because no stuffing is
added in transport packet. This method is fully compliant with DVB-SI DAT standard.
MAC address management
Standard DVB-SI-DAT 360 does not describe how to manage MAC addresses in this type
of encapsulation.
So as to manage this shortage, OpenMux® uses an IP-MAC mapping array (limited to
65000 entries) as follows :
Each entry in the array has the following format :
Destination_IP_address
178.3.1.1
Sub_network_mask
255.255.255.0
MAC_address
00-00-a2-83-4d-b8
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
144 / 266
This array is unique for the gateway and can be dynamically modified from a file or
through the API. Any modification made in the file is taken into account immediately by
the gateway.
If the destination IP address is a "multicast" IP address, the MAC address is calculated
according to the description supplied in the RFC 1112, otherwise, the MAC address is the
broadcast MAC address to ensure that the IP frame is received.
10.8.5.4 MPEG-2/DVB signaling specific to DVB SI DAT
MPEG-2/DVB signalling is provided in each protocol. It consists of management of the
PMT (Program Map Table) stream_type, the stream_identifier descriptor in the PMT and
the data_broadcast descriptor in the SDT (Service Description Table).
10.8.6 Supervision and Command
The "Multiplexer Manager" software is used to control the Multiplexer. This software can
be used to configure, manage and supervise all or some of the IP inputs in the same
Multiplexer. It is an OpenMux® client and can be run on a machine remote from the server.
Ten IP Managers can be connected simultaneously to the same OpenMux® server.
Figure 10-13 Multiplexer Manager
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
145 / 266
10.8.6.1 IP Input Supervision
The following view is used to supervise all IP inputs in the same window :
Figure 10-14 Multiplexer IP Inputs
IP input status, the encapsulation protocol used, the filters used, and statistical data are
therefore displayed simultaneously.
The following graphic displays dynamically the IP resources allocated in the multiplex :
Figure 10-15 Statistical View
One line displays the instantaneous IP datagram rate, and another the instantaneous rate of
the transport packets containing these IP frames (including the overhead relating to
encapsulation). In addition the overhead ratio can be also displayed.
This type of graphic can be displayed for each input (therefore for each service) or for each
filter (therefore for each sub-network).
To monitor the virtual channels and the dynamic bandwidth allocation, the Multiplexer
displays the following graphic :
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
146 / 266
Figure 10-16 Dynamic Bandwidth Allocation per channel
The statistics are :
• IP bytes read
• Transport packet bytes written
• IP bytes lost (due to overflow)
• IP datagram lost (due to overflow)
• Number of IP datagrams sent
Moreover, the values can be saved in a text file (for each filter if needed), which can be
imported and processed by programs such as Microsoft Excel.
The inputs (directory, tree node) can be organized logically by a hierarchical view and
each gateway configuration can be saved or restored :
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
147 / 266
Figure 10-17 Hierarchical View of Services
Each end of the tree corresponds to a service which can be enabled or disabled.
The configuration can be exported to another Multiplexer for backup purpose.
10.8.6.2 IP Input Definition
The IP input is characterized and defined by the view below :
Figure 10-18 IP Input Definition
Before adding this input, all parameters can be changed :
•
•
•
•
•
•
Input name (used for the service name).
Value of the PID containing the IP frames.
The input rate.
The network board associated with this input.
The frame encapsulation protocol.
For MPE mode, the IP address MAC address mapping :
o Association found in the mapping file.
o Copy of the Ethernet MAC address.
AEO-005479
SATLIFE
D311
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
148 / 266
o Broadcast MAC address for all frames.
The program number.
The PID containing the PMT (Program Map Table).
The FIFO sizes (used to absorb the network bursts).
During distribution, the user can modify dynamically the parameters displayed on white
background.
10.8.6.3 Definition Of Input IP Filters
The IP filters of an input can be modified at any time. This function is completely
dynamic and instantaneous. It is carried out via this interface :
Figure 10-19 Definition of Input Filters
A filter is composed of an IP address and a sub-network mask. The user can define for
each input :
• Up to 255 filter on the source IP address,
• Up to 255 filters on the destination IP address.
A maximum of 255 filters by input.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
149 / 266
10.9 SatLife evolution
According to the new requirements raised in the "Service Requirements" document,
protocol between SP and SP-RCST needs evolutions.
These evolutions are :
• adding of new messages (MGNT_Info, …)
• modification of existing messages (resource_answer)
• increase of number of burst of MPEG-2 packet per frame
• SP SP-RCST handshake modification
For a full description of the SP SP-RCST protocol see Annex F in DE220.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
150 / 266
11. VIDEO MONITOR UNIT DESIGN
MPEG-2 monitoring will be based on the existing Thales MPEG-2 monitoring product.
This product will be improved in order to support H264 video analysis.
SatLife Downlink
Monitoring
Station
- MPEG2 monitoring
Extraction, analysis and
display of H264
component
Figure 11-1 Video Monitoring unit
11.1 MPEG-2 Monitor Main features
Thales MPEG-2 monitor is a transversal real-time monitor that reports the Transport
Stream’s health status on RF, protocol, audio and video in MPEG2, DVB, ATSC and
ARIB environments.
Thales MPEG-2 monitor monitors Quality of Service in an easy to understand manner,
allowing non MPEG Experts to make decisions and maximize service availability.
Keys benefits are:
Centralized simultaneous monitoring of remote satellite cable or terrestrial
broadcast signals
Monitoring of up to 4 MPEG-2 TS
Cross Layer Monitoring (Protocol , audio/video layers)
Service based monitoring
High level interpretation of PSI, SI and PSIP tables
SCTE35 cue tones monitoring,
Automatic and manual capture of transport stream,
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
151 / 266
Windows Media 9 based Video streaming of remote site,
Web based monitoring,
Authentication,
SNMP Agent for easy integration into a network management system
11.2 MPEG-2 Monitor Global Architecture
Thales MPEG-2 monitor is based on a client server architecture.
Remote Site A
Monitor
Central Head End
Intranet
Remote Site B
Monitor
Monitoring Station
Figure 11-2 General architecture
Thales MPEG-2 monitor can be deployed on remote sites to monitor transport streams.
Each Thales MPEG-2 monitor system can be accessed by an Internet browser through an
intranet.
Required software such as Java Virtual Machine, Windows Media Player, Windows
Service Pack, may be directly downloaded from the monitor in order to facilitate the
monitoring station setup process.
11.3 MPEG-2 Monitoring description
Thales monitor performs MPEG monitoring at several levels:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
152 / 266
ETR 101 290
Bit Rate monitoring and logging
Tables syntax analysis
Clock monitoring (PCR, PTS/DTS, Megaframe timing
analysis)
Transport Stream capture
Simultaneous analysis of audio level of all programs of the
multiplex
Video decoding taking the form of thumbnails
simultaneously on all programs.
Complete Decoding of a dedicated program through
streaming
Service based monitoring
Program Guide
PID absence
Web monitoring
SNMP monitoring
Relay monitoring
11.3.1 Transport Stream monitoring
The Transport stream monitoring performs all of the 1st, 2nd and 3rd priority as specified in
“Measurement Guidelines for DVB systems” best known under the TR101290 name.
These tests ensure that the Transport stream is compliant with the latest version of the
MPEG-2 and DVB standards.
In addition to those 3 sets of tests, Thales MPEG-2 monitor performs the following
measurements:
• Transport stream structure analysis
• Syntax analysis of all DVB-SI tables and descriptors, (especially DVB-T
signaling)
• Timing analysis (PCR, PTS/DTS, section rates)
• Bit rate analysis and logging
• MIP (Megaframe Initialization Packet) analysis.
• Data broadcast analysis
Moreover, regarding transport stream monitoring, Thales MPEG-2 monitor is also offering
:
• Easy Error logging and Export to an excel spreadsheet
• Transport Stream Capture
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
153 / 266
Figure 11-3 TR101290 view (DVB mode)
After the analysis of all PSI/SI tables, Thales MPEG-2 monitor is able to display the
structure of the transport stream.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
154 / 266
Figure 11-4 Structure view
Tables syntax may be exported in HTML or Text format (directly usable with Microsoft
Excel) :
Figure 11-5 Syntax export view
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
155 / 266
11.3.2 Audio/Video monitoring
The Thales MPEG-2 monitor supports video decoding taking the form of thumbnails
simultaneously on all programs.
Figure 11-6 General monitoring View
11.3.3 Content monitoring
In addition to monitoring and streaming a specific program, the program view also lets you
to check the service Guide and Program Guide content.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
156 / 266
Figure 11-7 Program view
11.3.4 Transport Stream Capture
Thales MPEG-2 monitor supports automatic and manual captures of incoming transport
streams, allowing you to perform deferred time analysis, or play-back of captured streams
(using a stream player equipment).
Automatic capture is based on TR 101 290. Granite lets you activate a transport stream
capture for each of TR 101 290 test. It is possible to store up to ten capture per test.
Figure 11-8 Automatic Transport Stream Capture
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
157 / 266
Manual capture is directly available from the summary view by a simple click on the
“Start” button.
Figure 11-9 Manual Transport Stream Capture
After the capture, operator can then launch the H264 analyser to analyse deeply H264
video.
11.4 H264 Analysis
The H.264 Analyzer will be a software-only, off-line analyzer that supports H.264/AVC
raw byte or MPEG-2 TS formats.
MPEG-2 TS capabilities:
• Hierarchic view
• TR 101 290 priority 1 and 2 (configuration available)
• Player video (MPEG-2 or H.264/AVC) and audio (MPEG-1, AC3, AAC)
H.264/AVC capabilities:
• Video decoding
• Macroblock (MB) details with partition grid, MB type overlay and Motion
Vectors
• Trimming and extraction
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
158 / 266
Frame View
Picture
characteristics
PSI View
Thumbnail
view
Logs view
Figure 11-10 H264 analyzer GUI overview
11.4.1 MPEG2 TS Capabilities
Hierarchic view :
When a MPEG-TS file will be open, the hierarchic view will present PSI tables like below
:
Figure 11-11 H264 analyzer : PSI view
MPEG2 analysis will be report on the report view :
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
159 / 266
Figure 11-12 H264 analyzer : Report view
TR 101 290
Priority 1 and priority 2 will be performed.
No.
Indicator
Precondition
1.1
TS sync loss
Loss of synchronization with consideration of hysteresis
1.2
Sync byte
Sync_byte not equal to 0x47
1.3 a(1)
PAT rate
Sections with table_id 0x00 do not occur at least every 0,5 s
on PID 0x0000.
1.3 a(2)
PID 0x0 (PAT)
Section with table_id other than 0x00 found on PID
0x00
1.3 a(3)
PAT scrambling
Scrambling_control_field is not 00 for PID 0x0000
1.4
Continuity counter
Incorrect packet order: a packet occurs more than twice
parameters
lost packet
1.5 a(1)
PMT rate
Sections with table_id 0x02, (i.e. a PMT), do not occur at
least every 0,5 s on each program_map_PID which is referred
to in the PAT
1.5 a(2)
PMT scrambling
Scrambling_control_field is not 00 for all packets containing
information of sections with table_id 0x02 (i.e. a PMT) on
each program_map_PID which is referred to in the PAT
1.6
Absence of PID
Referred PID does not occur for a user specified
period.
Figure 11-13 TR 101 290 Priority 1
No.
Indicator
Precondition
2.1
Transport
Transport_error_indicator in the TS-Header is set to “1”
2.2
CRC
CRC error occurred in CAT, PAT, PMT, NIT, EIT, BAT, SDT
or TOT table
2.3 a
PCR repetition
Time interval between two consecutive PCR values more than
40 ms
2.3 b
PCR discontinuity
The difference between two consecutive PCR values (PCRi+1 –
PCRi) is outside the range of 0...100 ms without the
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
160 / 266
No.
Indicator
Precondition
2.4
PCR accuracy
PCR accuracy of selected program is not within ±500 ns
2.5
PTS
PTS repetition period more than 700 ms
2.6 (1)
Scrambled packet
Packets with transport_scrambling_control not 00 present, but
no section with table_id = 0x01 (i.e. a CAT) present
2.6 (2)
PID 0x1 (CAT)
Section with table_id other than 0x01 (i.e. not a CAT) found on
PID 0x0001
discontinuity_ indicator set
Figure 11-14 TR 101 290 Priority 1
All
analysis
are
fully
explained
in
annex
§
18
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
161 / 266
ANNEX A: TR 101-290.
Player video:
Player will support MPEG-2 or H.264/AVC video and audio MPEG-1, AC3, and AAC.
11.4.2 H264/AVC capabilities
H264 video analysis :
The H.264 Analyzer will perform following analysis and view :
• Frame
decoding
:
The analyzer will perform frame decoding and display frames in frame view and
thumbnail view.
• Macro
block
grid
:
The macroblock is the basic processing unit of a picture. A click on a button will
display MB Grid view
• Macro
block
partition
grid
:
During the macroblock prediction process, macroblocks may be divided into
partitions which are predicted separately. A click on a button will display MB
Partition Grid
• Macro
block
type
display
(intra,
inter,skip,
direct)
:
Macroblock prediction mode, or macroblock type, indicates how the macroblock
was predicted. A click on a button will display MB Type The macroblocks are put
into four categories: Intra predicted, Inter predicted, Skipped and Direct
• Slices
display
A video picture is coded as one or more slices, each containing an integral number
of macroblocks from 1 to the total number of macroblocks in the picture. There can
be any number of slices in a picture, and the number of MB per slice need not be
constant within a picture. To limit the propagation of errors and make parallel
processing of slices easier, the slice has been defined independent from other slices
of
the
same
picture
A click on a button will display slices.
• Motion
vector
display
:
The motion vectors, i.e. the displacement used to reconstruct blocks from blocks of
reference pictures, can be displayed on the picture. The AVC standard allows bipredicted blocks to be predicted using reference pictures from 2 different lists, List
0 (L0) and List 1 (L1). The analyzer will let you display vectors from the 2 lists,
independently and with different colors, using buttons Display L0 MV and Display
L1 MV
• Frames
&
slices
characteristics
A view on the rigth of the frame (picture characterisitics view) will display detailed
characteristics as type, size, profil, PTS, …
• Zoom
(1/2,
1,
2,
4)
:
A click on a button wll offer several zoom possibilities.
File processing :
AEO-005479
SATLIFE
D311
The H264 analyzer will perform :
• TS Trimming feature (I frame accurate)
• ES extraction
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
162 / 266
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
163 / 266
12. SERVICE PROVIDER TERMINAL DESIGN
12.1 Product Overview
The Video Service Provider is based on the RCST, because it has to have its functionality
and in addition it should be able to transmit MPEG2 video and data. It is necessary to add a
Video Streaming Unit to the RCST, which must feed the RCST with the MPEG-2 video
stream to be broadcast.
Figure 12-1 Video Service Provider Station
The Video Service Provider Station is composed of a Video Streaming Unit and a RCST.
According to this architecture, the description on the sub-units of the RCST is the same as
for the RCST itself. The main difference of this Service Provider RCST is that it
implements an interface between the streaming unit with the purpose of receiving the video
in MPEG-2 format to be broadcast. This interface consists of video input and a clock
output. The clock is required to synchronize the Video Unit with the RCST.
The Service Provider output video stream could have different data rates, thus an
information on the rate used at any time must be provided to the RCST. This is solved by
the exchange of information at the beginning of the transmission that describes the data
and video flow sent.
Therefore the main difference of this SP-RCST from a regular RCST is that it implements
an interface to SP and is able to receive the video in MPEG2 format to be broadcast. This
interface consists of signaling channel, video input and a clock output.
12.1.1 Physical Architecture
The SP-RCST consists of two parts, as a regular RCST:
•
ODU Outdoor Unit: antenna, LNB (Low Noise Block converter), and BUC (Block
Up Converter).
AEO-005479
SATLIFE
D311
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
164 / 266
IDU Indoor Unit: represents the hardware and software of the RCST.
te xt
te x t
te xt
R C S T + IR D
A M A Z O N A S S a te llite
ODU
Video and signalling
VSP
OBP
ID U
S P -R C S T
M a n a g e m e n t S ta tio n
Figure 12-2 SP-RCST Context
12.1.2 RCST IDU Description
12.1.2.1 Functional breakdown
The SP-RCST IDU is based on the following functional breakdown, used as a reference for
the definition of the design included in this document:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
165 / 266
SP Interface (LAN)
Application Layer
SP/SP-RCST signalling protocol im plem entation
RTP traffic processing
Netw rok Layer Layer
Satellite Adaptation Layer
SP-RCST
IDU
Connection Aggregation
Acess Layer
Radio Resource control
Connection Control
Session Control
System & Network Configuration
Transport Mechanism
M
A
N
A
G
E
M
E
N
T
Management
Interface
Connecivity and support to services
Routing
Addressing Plan Handling
Physicall Layer
Synchronization
Power Control
BasebandProcessing
SP-RCST ODU Interface
Figure 12-3 SP-RCST IDU functional Breakdown
As it may be seen, the SP-RCST is quite similar to a conventional RCST, the main
differences are that the SP-RCST has an ability to transmit MPEG-2 video received from
Service Provider Station (SPS), over the LAN interface (RTP format) and the terminal
interacts with SPS to setup its video transmission parameters. This interaction is done
using a proprietary SP/SP-RCST command protocol. The SP-RCST cannot operate as an
IP router for the user LAN on its own (thus not implementing network services like QoS,
PEP and so on), and has slightly different synchronization procedure. Another parts that
differ are MIB agent (implements SP-RCST MIB) and its transmission rate should be
higher, 4 Mbps at the beginning and 8 Mbps later.
12.1.2.2 Protocol stacks
The SP-RCST implements almost the same protocol stacks as a “normal” RCST.
12.1.2.2.1 User plane
The User plane refers to the protocol stack applied to the traffic data within the system:
AEO-005479
SATLIFE
D311
RTP
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
166 / 266
S P - R C S T A p p lic a tio n
UDP
IP
E th e r n e t
1 0 /1 0 0 B T
MPE
M P E G 2 -T S
D V B -R C S
fr o m / to
SP
to s a te llite
MPE
M P E G 2 -T S
D V B -S
fr o m s a te llite
Figure 12-4 User plane protocol stack
12.1.2.2.2 Control Plane
The control plane refers to the protocol stack applied to the signaling data associated to
traffic handling.
Figure 12-5 Control Plane protocol stack
12.1.2.2.3 Management Plane
There are two management planes – local and remote. On the first step only CLI and
SNMP management is going to be implemented.
The local management plane refers to the protocol stack applied to the management data.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
167 / 266
Figure 12-6 Local Management plane protocol stack
The remote management plane refers to the protocol stack applied to the management data:
Figure 12-7 Remote Management plane protocol stack
12.1.3 SP-RCST Synchronization
The SP-RCST is basically a standard RCST although with some modifications. One of
these modifications is the synchronization maintenance procedure.
The SP-RCST synchronization procedure is similar to the RCST synchronization
procedure. The Logon, Coarse synchronization and Fine Synchronization Procedures are
identical for both types, while the Fine Synchronization Maintenance procedures are
different.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
168 / 266
This SP-RCST terminal usually uses the configuration of 24 MPEG packets per frame so
the normal injection of a SYNC would not allow the transmission of a whole burst during a
frame which can increase a lot the jitter of the video played. This is not desirable so we
have to slightly modify the behavior for this kind of terminal.
From the MS point of view, the changes are as the following: SatLife system shall provide
a signaling route containing only one SYNC that will be assigned to the SP-RCST at the
logon. The MS shall not consider the overlapping of the SYNC burst when assigning
timeslots to the SP-RCST. This means that the MS will assign the timeslots reserved for
the SP-RCST in the TBTP without taking into account when the SYNC has to be inserted.
The SP-RCST decodes the CMT as a normal RCST after logon no matter the status of the
VSP. As the configuration needed for video broadcasting is usually a whole carrier of one
user (24 MPEG-2 packets per frame), there is no time to send SYNC bursts in the standard
mode. It is necessary to insert these SYNC bursts into the native MPEG traffic. The
procedure is the following:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
IE_TYPE
1
>
=>
.
$
>
3
>
9
=2
$
/
/*.<
-
.
1
:
=2
3
2 3
:
=2
9
2 9
'
2- + " .
'
2- + " 1
% #2
169 / 266
2 1
=>
9
2.0 draft
:
=>
>
14/09/2006
2 .
=2
3
$
PAGE:
:
=>
1
$
ISSUE:
/
:
.
DATE:
2- + "
# #
2- + " .
# #
2- + " 1
" .
.
1
Figure 12-8 SYNC burst IE
The SP-RCST sends at SP/SP-RCST handshake procedure the SAC field content and the
CRC-16 to the SP unit. The SP unit will insert the information received in the next SYNC
packet according to the SYNC burst IE structure depicted in previous figure. IE_TYPE is a
5-bit field with value 0x0E.
Once the SYNC burst IE is ready, it is inserted among native MPEG-2 traffic according to
the structure on next figure:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
170 / 266
MPEG-2 HEADER
GROUP ID
LOGON ID (1)
LOGON ID (2)
SYNC burst IE
DEMDEC measurement IE
SYNC burst IE
DEMDEC measurement IE
padding
Figure 12-9 SYNC MPEG packet format
•
•
•
•
•
•
MPEG-2 header is a 4-byte field, MPEG-2 standard header.
GROUP_ID is a 1-byte field with value 0.
LOGON_ID is a 2-byte field with value 0.
SYNC Burst IE (as previously described).
DEMDEC measurement IE is a 21-byte field (the OBP is the responsible of
inserting the measures and the SP unit shall only reserve the place of the 21- bytes).
PADDING is calculated to have the size of a complete MPEG packet (188 bytes)
The SYNC packet that is going to be sent has a specific SYNC_PID (SP receives it in a
resource_answer message from SP-RCST). It is not necessary to include it in a specific
position, it can be inserted wherever desired but respecting the appropriate frame.
Every time a SYNC packet is inserted, the PCR of the MPEG2 video packets shall be
updated accordingly. Once the SP sends the first traffic packet it will start inserting the
SYNC packet in the traffic flow with the frequency defined in the SYNC_period message
and with the content described before. As there is no control of the bandwidth used and the
bandwidth assigned neither the SP nor the SP-RCST are allowed to request RBDC on the
channel receiving the timeslots for more capacity.
If we want to take advantage of the multicast feature of the OBP we should use the
multicast option to give service to the downlinks where the IRDs are present. However this
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
171 / 266
introduces a problem: if the NCC is not in one of those downlinks the SYNC won’t arrive
and the SP-RCST will lose the synchronization. To solve this issue there are two
possibilities:
•
•
Multicast including NCC Downlink
Multi-channel Transmission in the SP-RCST.
12.1.3.1 Multicast including NCC Downlink
This is the most simple approach and it’s the one we are going to implement. In any case
the NCC will belong to the route used by the SP to transmit the video so it will receive any
traffic.
The disadvantages are:
•
the bandwidth is wasted if no IRD is present in the same downlink.
•
IRDs could try to access the service even if they are not subscribed.
These side-effects can be reduced with some requirements:
•
The VSP always transmit the SYNC and the SNMP traffic in the first quarter of the
burst.
•
The OBP is configured in such a way that only the first quarter of the mux table of
the NCC is switched for the multicast route.
•
This route can only be used in this case.
•
Use of conditional access.
12.1.3.2 Multi-Channel Transmission in the SP-RCST.
An alternative to use a multicast where the NCC is always listening is to use two channels
for the transmission of the SP-RCST:
•
•
The channel Id 0 for signaling (SYNC messages) and SNMP traffic.
Another channel for the transmission of the video.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
172 / 266
Channel Id (C3)
Superframe
5
24 packets
24 packets
0
24 packets
24 packets
Time
Capacity assigned to SP RCST:
•
CRA sig: 100 kbps
•
Video: 1,5 Mbps
Figure 12-10 Multi-Channel Transmission on SP-RCST
If we want to make real selective multicast to only the destinations served by the VSP
(without including the NCC) the timeslots coming in the channel id for video will not
reach the NCC and therefore we cannot use them to send the SYNCs. To solve this
problem we need other timeslots in another channel: channel Id 0. But if we do this we
have the problem of overlapping. This can be avoided if the channel Id 0 is used for both
kinds of traffic: syncs and video. With this solution there is no problem of confidentiality
of the video because we don’t broadcast the video to all the downlinks. We only transmit a
small part of the video that is not enough to access the contents illegally. Typically the
NCC could grant the bursts as on the figure above.
In this way we should allocate a bandwidth that assures that a SYNC is sent every 18
superframes. In the case of a burst of 24 packets we would need:
(24 MPEG packets/superframe * 188 bytes/packet * 8 bits/byte)/ 18 superframes = 518
kbps. This is a very high value that could be decreased in some other ways:
•
•
The periodicity of the SYNC can be reduced for the SP-RCST (by configuration in
the NCC).
The SP-RCST could not send the SYNC with this periodicity and trusting that the
NCC will wait for a number of repeats before considering that the SP-RCST is
down.
Now we have to define a way so that the SP-RCST can be assigned a channel to the traffic
received from the SP:
AEO-005479
SATLIFE
D311
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
173 / 266
In the case of the video, tables transmitted to the IRD and IP traffic from SP to the
NCC the SSRC value of the RTP header shall be 0x00000001.
In the case of sync messages and the tables transmitted to the NCC the SSRC value
shall be 0x00000002.
This means that there cannot be RTP packets with a mix of packets of both types.
The SP uses the SSRC value contained in the RTP to know what timeslots to use. In the
first case it will use timeslots for normal traffic (channel between 5 and 14) and in the
second case the timeslots of the channel 0 (to the NCC).
The SP-RCST has both option implemented, so it is up to MS and SP to choose which one
to use.
12.2 SP-RCST Software Design
12.2.1 Software platform
The SP-RCST software runs on a MPC8260 using VxWorks 5.4 as the OS. We use an
additional package, the Wind Manage SNMP 9.3. The development environment –
Tornado 2.0.2.
12.2.2 Software Architecture
On below figure presented the main modules of SP-RCST software architecture.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
174 / 266
SP-RCST Controller
(LCM, Configuration, State-Machine )
SP-RCST
Management
Agent
Legend:
Control
Traffic
SP Traffic Controller
SP Signalling Controller
Control &
Traffic
External
Subsystem
PCR
Controller
SpSal
MPEG2
Signalling
SP-RCST Physical
Layer Controller
(alarm processor,
DVB-S Monitor)
IP/MPE
DVB-RCS Tx
DVB-S Rx
Physical layer HW and driver primitives
(DVB-S Rx, DVB-RCS/MPEG Tx, M&C, PCR logic)
Figure 12-11 SP-RCST Software Architecture
12.2.2.1 SP-RCST Controller
The SP-RCST controller is a subsystem that takes care of different stage of terminal
lifecycle, implements the terminal state-machine and is responsible for different SW
management tasks, terminal configuration, system processes and etc.
12.2.2.2 SP Traffic Controller
The SP Traffic Controller represents the traffic part implementation of the SP/SP-RCST
protocol and is responsible for reception and handling of data traffic from SP. The main
duty of this block is to receive RTP packets from the SP, verify their correctness and
forward them to SpSAL for further processing. SP Signaling Controller.
The SP Signaling Controller represents the control/status part of the SP/SP-RCST protocol
implementation. The main purpose of this subsystem is to perform initial handshake with
SP and to notify SP-RCST Controller that SP/SP-RCST connection is established. When in
“operational” state the SP Signaling Controller sends a SoF message to the SP every frame.
12.2.2.3 SP SAL
The SpSAL is responsible for forwarding of received MPEG2 data stream from and to SPRCST system. It represents an application-specific adaptor of VSP to the satellite network.
Performs all tasks required to connect SP to the connection oriented satellite network,
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
175 / 266
particularly transmitting SP-generated video stream. During logon and calibration stages,
SpSAL operates in exactly the same way as the RCST SAL.
12.2.2.4 Signaling
This subsystem includes modules required to process DVB-RCS and
SatLife/AmerHis/IBIS signaling extensions. It is responsible for MPEG2, DVB-S and
DVB-RCS tables reception and parsing, with subsequent forwarding of relevant data to
other subsystems. Generates Frame Resource Assignment Table, which represents a
resource assignment for the SP-RCST in the given frame.
The subsystem is exactly the same as the Signaling subsystem in the IBIS SUS RCST, and
thus shared with that type of RCST.
12.2.2.5 Physical Layer – HW & drivers
This layer is responsible for DVB-S receiving and MF-TDMA transmitting. The layer
includes the SW packages required in embedded system to support HW modules. Also,
this layer supplies to the upper SW layers comfortable interface to access the services
provided by the HW on the board, by mean of SW drivers or additional packages.
The subsystem is exactly the same as the Physical Layer – HW & drivers subsystem in the
IBIS SUS RCST, and thus shared with that type of RCST.
12.2.2.6 Physical Layer Controller
The responsibility of this SW module is to configure the HW layer as required by other
terminal SW subsystems (Signaling, RCST controller, SAL & etc.). Provides services like
calibration process and correction messages processing.
The subsystem is exactly the same as the Physical Layer Controller in the IBIS SUS
RCST, and thus shared with that type of RCST.
12.2.2.7 SP-RCST Management Agent
The agent implements SP-RCST management services, which are used by different
management front-end modules. Its implementation covers all SP-RCST specific MIB
variables.
12.2.2.8 PCR Controller
This subsystem is responsible for monitoring the NCR counter, notifies other subsystems
when a requested time is elapsed and implements a PCR timer mechanism.
12.2.3 Subsystems Design
12.2.3.1 SP-RCST Controller
The SP-RCST controller is a subsystem that takes care of different stage of terminal
lifecycle, implements the terminal state-machine and is responsible for different SW
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
176 / 266
management tasks, terminal configuration, system processes and etc. The internals of the
SP-RCST Controller are depicted in the next figure.
12.2.3.1.1 State Machine
This class represents a state machine of the SP-RCST and implements a state transition
logic. The class has one State objects that is currently active. Events processing is
delegated to the active state object, and the state object implements a behavior associated
with a state of the SP-RCST.
LCM
(Life Cycle Mgr)
States
States
Actual
States
State Machine
Notification and
Error Processing
Configuration
AAA Agent
(Authentication
And Authorization)
SpSAL, Signalling, Physical Layer Controller, SP Signalling Controller
Figure 12-12 SP RCST Controller internals
12.2.3.1.2 LCM
The LCM performs the different SW related tasks and system processes: SW subsystems
creation, initialization and deletion, initialization of some system processes, etc.
Configuration
The Configuration class implements an SP-RCST configuration logic, like SP-RSCT
parameter setting, Forward and Return link configuration and so forth. Other classes (state
classes) use services provided by the Configuration class to implement more high-level
logic.
12.2.3.1.3 AAA Agent
It is a remote part of the whole Authentication-And-Authorization system of NCC and
responsible for relevant authorization and authentication procedures. It handles Logon and
Logoff procedures of the terminal.
12.2.3.1.4 Notification and Error Processing
The Notification and Error Processing class implements a notification handling logic. It
receives errors and notifications from other SP-RCST subsystems, translates them into a
standard event format and passes the event to the state machine for further processing.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
177 / 266
12.2.3.2 SP Traffic Controller
The SP Traffic Controller represents the traffic part implementation of the SP/SP-RCST
protocol and is responsible for reception and handling of data traffic from SP. The main
duty of this block is to receive RTP packets from the SP, verify their correctness and
forward them to SpSAL for further processing.
In this version of the SP-RCST this subsystem is very simple, it implements only a thin
wrapper for a UDP socket. It checks a protocol of the incoming packets, and if it is RTP,
the packets are forwarded to the SpSAL.
The SP/SP-RCST protocol defines that every RTP packet that VSP sends should carry an
entire burst content. If VSP sends MPEGs without such a mapping and SP-RCST just fills
the bursts with incoming MPEGs on first come – first sent basis, there may be a problem
with multi-channel transmission. Some video traffic may get into the signaling channel and
some signaling/table information may get into the traffic channel. However, as the
signaling part of the SP/SP-RCST protocol defined today, it is not possible for the VSP
unit to know what the size is of the next burst that is going to be “filled” (in case that the
SP-RCST has an assignment of several bursts of different sizes). Therefore, in the design
of SP Traffic Controller we have assumed that the SP-RCST resource assignment is
composed of one or several bursts of identical size.
12.2.3.3 SP Signaling Controller
The SP Signaling Controller represents the control/status part of the SP/SP-RCST protocol
implementation. The main purpose of this subsystem is to perform initial handshake with
SP and to notify SP-RCST Controller that SP/SP-RCST connection is established.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
178 / 266
Service Provider
SP RCST
Resource_Request
Waiting
for
Resource
Request
Resource_Answer
SYNC_period
Waiting
for
Handshake
completion
SAC_field
SOF
MPEG2/ RTP
Traffic
SOF
MPEG2/ RTP
Stop_Transmission
Figure 12-13 SP/SP-RCST signaling handshake
When in “operational” state the SP Signaling Controller sends a SoF message to the SP
every frame. Beside this, the SP Signaling Controller implements an interface that enables
to other subsystems (SP-RCST Controller, SpSAL) to send different messages to VSP.
12.2.3.4 SP SAL
The SpSAL represents an application-specific adapter of VSP to the satellite network.
Performs all tasks required to connect SP to the connection oriented satellite network,
particularly transmitting SP-generated video stream. It is responsible for preparing VSPgenerated MPEG2 data stream for the transmission. During logon and synchronization
stages, SpSAL operates in exactly the same way as the RCST SAL.
AEO-005479
SATLIFE
D311
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
179 / 266
IP
IP Rx
FRAT Processor
Sp Traffic Controller
RTP
TCP/IP Stack
SATLIFE-AEO-SYS-DD-3
Tx Trf
Rx
Signalling
Sp Sal Scheduler
MPEG loader
MPE to IP
Tx Ctrl
Receiving Path
RTP Traffic Handler
Physical layer HW and driver primitives
Figure 12-14 SpSAL internals
The SP/SP-RCST protocol defines that every RTP packet that VSP sends should carry an
entire burst content. If VSP sends MPEGs without such a mapping and SP-RCST just fills
the bursts with incoming MPEGs on first come – first sent basis, there may be a problem
with multi-channel transmission. Some video traffic may get into the signaling channel and
some signaling/table information may get into the traffic channel. However, as the
signaling part of the SP/SP-RCST protocol defined today, it is not possible for the VSP
unit to know what the size is of the next burst that is going to be “filled” (in case that the
SP-RCST has an assignment of several bursts of different sizes). Therefore, in the design
of SpSAL we have assumed that the SP-RCST resource assignment is composed of one or
several bursts of identical size.
12.2.3.4.1 RTP Traffic Handler
RTP Traffic handler receives an RTP packet from the SP Traffic Controller and loads the
traffic payload into the Physical Layer with help of MPEG loader. Checking whether an
RTP packet arrived inside the time window is done by FPGA. The packets arrived outside
a time window is dropped and not transmitted at all.
12.2.3.4.2 MPEG Loader
MPEG Loader checks whether an arrived RTP packet carries a payload of entire burst by
comparing its data length with the next burst size. If the size matches the required one, the
RTP packet is passed to Physical Layer for the transmission.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
180 / 266
12.2.3.4.3 FRAT Processor
FRAT Processor gets a FRAT table from the Signaling subsystem once for every frame,
and depending on the SP-RCST state either loads it to the Physical Layer (Fine Sync and a
connection with SP is established) or passes it to the SpSAL scheduler for further
processing (all other states).
12.2.3.4.4 SpSAL Scheduler
When SP-RCST is in the “Fine Sync and a connection with SP is established” state, the
SpSAL Scheduler dispatches received FRAT to the Physical Layer subsystem “as is”. In
any other state the scheduler analyses the table and prepares payload for signaling bursts if
required (CSC, SYNC, DULM) and after that loads the FRAT table and the payload into
the Physical Layer subsystem.
12.2.3.5 Signaling
This subsystem includes modules required to process DVB-RCS and
SatLife/AmerHis/IBIS signaling extensions. It is responsible for MPEG2, DVB-S and
DVB-RCS tables reception and parsing, with subsequent forwarding of relevant data to
other subsystems. Generates Frame Resource Assignment Table, which represents a
resource assignment for the SP-RCST in the given frame.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
181 / 266
C2P
Tx Tables Processor
RLS (Return Link
Signalling)
FLS (Forward Link
Signalling)
SYNC, CSC,
DULM
DVB/DVBRCS Tables
SpSAL, SP-RCST Controller, Physical Layer Controller
Physical layer HW and driver primitives
Figure 12-15 Signaling internals
12.2.3.5.1 C2P module
This module Implements the C2P protocol, which is used for connection management.
When the Signaling subsystem receives an C2P TIM message the C2P module decodes its
content and sends the decoded data towards appropriate subsystem. When a C2P message
should be sent towards NCC this module prepares a DULM IE and sends it to the NCC.
12.2.3.5.2 Tx Tables Processor
The Tx Tables Processor analyzes frame tables (SCT, FCT and TCT) and TBTP, translates
them into frequency and time parameters, builds a FRAT (Frame Resource Assignment
Table) and passes the FRAT to SpSAL. The SpSAL loads the FRAT table to MF-TDMA
Transmitter and also uses it to prepare a content to be sent.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
182 / 266
12.2.3.5.3 RLS - Return Link Signaling
RLS gathers return link signaling from other subsystems in the terminal, and transfers
them, according to type, to the MF-TDMA Transmitter.
12.2.3.5.4 FLS - Forward Link Signaling
FLS receives the forward link signaling tables from the DVB receiver, processes them and
routes the signaling information to a suitable module for further processing.
The subsystem is exactly the same as the Signaling subsystem in the IBIS SUS RCST, and
thus shared with that type of RCST.
12.2.3.6 Physical Layer – HW & drivers
This layer is responsible for DVB-S receiving and MF-TDMA transmitting. The layer
includes the SW packages required in embedded system to support HW modules. Also,
this layer supplies to the upper SW layers comfortable interface to access the services
provided by the HW on the board, by mean of SW drivers and additional packages.
SpSAL and IBIS signalling
Tx M&C
Rx M&C
S
DVB-S
Rx
DVB-RCS Tx
MF-TDMA
Tx
PCR
M&C
DVB-S signal
T
M&
C
Figure 12-16 Physical Layer internals
12.2.3.6.1 DVB Receiver
DVB Receiver is responsible for acquiring the DVB-S signal, receiving of transport stream
and processing the incoming MPEGs and routing different elements of this stream to a
suitable module: Traffic to DVB-to-IP, Signaling tables to FLS and PCR to MF-TDMA
Tx.
12.2.3.6.2 Rx Monitoring & Control
Rx M&C is in charge of configuring the DVB Rx according to the defined parameters. The
Physical Layer Controller subsystem provides the configuration.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
183 / 266
12.2.3.6.3 MF-TDMA Transmitter
This module transmits bursts from the terminal to satellite, in MF-TDMA scheme. It gets
FRAT tables and the traffic to send from SpSAL subsystem.
12.2.3.6.4 Tx Monitoring & Control
Tx M&C is responsible for configuring the MF-TDMA Tx to the correct frequency, timing
and power levels, according to corrections sent by the NCC. Another role of this module is
to monitor MF-TDMA transmitter parameters.
12.2.3.6.5 PCR
The PCR module performs all PCR-related tasks: PCR synchronization, NCR extraction
and FPGA transmitter synchronization to the NCR.
The subsystem is exactly the same as the Physical Layer – HW & drivers subsystem in the
IBIS SUS RCST, and thus shared with that type of RCST.
12.2.3.7 Physical Layer Controller
The responsibility of this subsystem is to configure the HW layer as required by other
subsystems (Signaling, SP-RCST controller, SpSAL etc.). It also provides services like
calibration mechanism and correction message processing.
SP-RCST Controller, Signalling
Correction
Processor
Calibration
Processor
DVB Monitor
Physical Layer HW
Figure 12-17 Internals of the Physical Layer Controller
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
184 / 266
12.2.3.7.1 Correction Processor
Correction Processor handles on-going corrections of the terminal’s transmission
parameters when SP-RCST is in the Fine Sync state. It receive the corrections from
Signaling subsystem.
12.2.3.7.2 Calibration Processor
Calibration Processor performs a calibration of SP-RCST terminal, including sending
calibration bursts and handling the correction messages from the NCC. The Calibration
Processor operates when the SP-RCST is in one of the calibration states.
12.2.3.7.3 Tx-TDMA & Rx-DVB M&C
Tx and Rx M&C handles any changes in the physical channel parameters and monitors the
Tx and Rx status.
The subsystem is exactly the same as the Physical Layer Controller in the IBIS SUS
RCST, and thus shared with that type of RCST.
12.2.3.8 SP-RCST Management Agent
The agent implements SP-RCST management services, which are used by different
management front-end modules. Its implementation covers all SP-RCST specific MIB
variables. The following figure illustrates the SP-RCST management plane.
12.2.3.8.1 Routing of SNMP messages
SP-RCST does not have an ability to transmit IP packets via its Air Interface by itself. For
this task it needs to forward the outgoing IP packets towards SP, which encapsulates them
into MPEGs and passes the MPEGs back to the SP-RCST for transmission. We employ an
IP stack services to achieve this IP forwarding functionality. The SP is defined as a default
gateway in the SP-RCST routing table, therefore all outgoing IP packets go there. The
packets destined for the MS, SP unit encapsulates into MPEGs and dispatches back to the
SP-RCST for transmission.
AEO-005479
SATLIFE
D311
SNMP Front-End
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
185 / 266
CLI Gront-End
HTTP Front-End
(future)
SP-RCST
Management
Agent
SP-RCST Ctrl and other subsystems
Figure 12-18 SP RCST Management Plane
12.2.3.8.2 SP-RCST Management Agent
The management agent implements SP-RCST management services, which are used by
different management front-end modules. Its implementation covers all SP-RCST specific
MIB variables.
12.2.3.8.3 CLI Front-End
Command-Line Interface front-end, passes commands/status requests and results between
SP-RCST console and SP-RCST Management Agent
12.2.3.8.4 SNMP Front-End
SNMP agent front-end, translates and passes SatLife SP-RCST specific commands/status
requests and results between SNMP browser/NMC and SP-RCST Management Agent. For
general SNMP requests, like IP and Ethernet statistics, the module interacts with OS
services.
12.2.3.9 PCR Controller
This subsystem is responsible for monitoring the NCR counter, notifies other subsystems
when a requested time is elapsed and implements a PCR timer mechanism.
12.3 SP-RCST Hardware Design
The SP-RCST Hardware Design is depicted on the next figure.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
186 / 266
Management & Control
Block
Control
8260 Interface
Preamble
MUX
Channel Coding
I, Q
Shaping Filter
Samples
I, Q
Sample
Clock
Symbol Clock
Scrambler
Fast CLOCK
Data/Signaling
interface,
Special burst
insertion
I, Q
EN
CS
Timer INT
118 Interface
Timing
Block
Figure 12-19 SP-RCST Hardware Design
12.3.1 Data/Signaling block
Data/Signaling block is responsible for reception traffic & signaling (DULM) data from
MPC8260 and prepares it to transmission with modulator. This block includes:
•
•
•
•
•
Data queues.
RTP packet to MPEG packet.
Parallel to serial conversion.
Burst formatting.
Etc.
L-Band
Interface
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
187 / 266
12.3.2 Scrambler block
The block applies a randomization to data bit stream.
12.3.3 Channel coding block
This block applies Turbo Code to each packet sent to uplink.
12.3.4 Preamble block
Preamble block prepares an appropriate preamble for placement at the beginning of the
burst.
12.3.5 MUX block
MUX block schedules the insertion of preamble or payload packets into the burst.
12.3.6 Shaping filter block
This block filters the QPSK symbols with SRRC in order.
12.3.7 Timing block
Timing block is responsible to prepare all timing signals required to properly work of
QPSK modulator including PCR PLL block to synchronize on the NCR counter value.
These includes the following signals:
•
•
•
•
All required clocks.
SOF & other interrupt generation.
Internal chip selects.
Internal enable signals.
12.3.8 M&C Block
M&C block is responsible for all management and control activities of FPGA modulator,
including:
Receive superframe burst table from 8260.
•
Configure modulator with appropriate burst parameters.
•
Manage M&C interface between FPGA & L-band transmitter and between FPGA
& CPLD.
Scheduling activities inside modulator.
•
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
188 / 266
13. REGENERATIVE GATEWAY DESIGN
13.1 RSGW OVERVIEW
The Return Channel Satellite Gateway (RSGW) provides SatLife users with
internetworking capabilities to external networks such as PSTN or ISDN and the Internet
(see figure). From their point of view, a RSGW is the hub in an access network with a star
topology.
The SatLife RSGW is based on the AmerHis RSGW which provides Internet/Intranet
access, voice and videoconferencing against PSTN/ISDN using H.323 protocol and
multicast streaming. SatLife improvements include the extension of audio/video services to
support SIP protocol, improved NAT traversal support and optimization of ISDN/PSTN
call termination.
Figure 13-1 Context of the SatLife return Channel Satellite Gateway
The services offered by the RSGW are commercialized by a RSGW Service Provider. By
using almost standard RCSTs to access the satellite network, the RSGW pretends to be a
low cost station that may attract also medium to small Service Providers.
The RSGW is designed to share its satellite and terrestrial bandwidth resources among a
high number of simultaneously active subscribers (typically in the order of hundreds,
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
189 / 266
considering an 8 Mbps capacity). In this sense, the RSGW differs from a standard RCST
that may require only in the order of ten simultaneous communications with other RCST.
Finally and in order to support the delivery of business-class data services, the RSGW is
able to provide service guarantees to RSGW subscribers. The RSGW guarantees different
QoS values for users at different subscription levels (roughly speaking, the higher fee the
subscriber pays the higher QoS values have to be guaranteed).
13.2 SUBSCRIBERS AND SERVICES
RSGW subscribers are organized in Virtual Satellite Networks (VSN). A VSN represents a
group of AmerHis users authorized to use the complete pool of private IP addresses. The
same private IP addresses can be used by several VSNs. Mesh communications are only
possible between members of the same VSN.
The RSGW handles two types of subscriptions:
•
Prosumer subscription: the prosumer subscription corresponds to subscriber
willing to access the Internet through the RSGW and to use the RSGW voice
services. All prosumer subscriptions belong to a certain VSN (“ISP VSN”)
managed by the RSGW Service Provider.
•
Corporate subscription: the corporate subscription corresponds to an AmerHis
subscriber will of providing his users located in different “branch offices” sites with
a way to communicate, in star mode, with the ground network “Head Office”. Each
branch office uses a RCST and reaches the Head Office through the RSGW, using
a dedicated access. These corporate subscriptions will use a “Corporate VSN” and
manage their private IP addresses without restrictions by the RSGW Service
Provider .
The RSGW will support either the “ISP VSN” (with prosumer subscriptions) or the
“Corporate VSN” (i.e. only one VSN per RSGW). This means that there will be two
RSGW set-ups: a “ISP VSN” set-up and a “Corporate VSN” set-up. Both set-ups differ
mainly in IP addressing issues and in the connected external network.
13.2.1 Summary of AmerHis services
This section gives an overview of the services offered in the AmerHis RSGW.
Internet Access
The Internet access service (for Prosumer RSGWs) provides AmerHis users with access to
the Internet at rates up to 4 Mbps, with asymmetric rates being possible.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
190 / 266
RSGW
W
Prosumer Subscriber
ISP
UT
Internet
RCST
Prosumer Subscriber
Figure 13-2 Internet Access Service
Internet access is provided to users with private IP addresses, which will get a public IP
address through network address translation (NAT) performed in the RSGW, and to users
with public IP addresses. Internet access may be also initiated from the Internet side for the
latter subscribers.
The RSGW Service Provider is the responsible for selecting an ISP, which will provide the
required Internet access link and supply a range of public IP addresses.
Intranet Access
Intranet access (for Corporate RSGWs) provides AmerHis users with access to the
corporate Head Office network at rates up to 4 Mbps, with asymmetric rates being
possible.
Corporate RCST
RSGW
Telco
UT
Corporate RCST
Head Office
Network
Figure 13-3 Intranet Access Service
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
191 / 266
The access to the corporate Head Office is provided using a dedicated link contracted to a
Telco (i.e. not by traversing the Internet). The RSGW will use this link as the default route
of the Intranet.
The corporation is free to assign any private IP address to the UTs within the corporate
VSN and use its own set of public IP addresses. The RSGW will just forward packets back
and forth the corporate Head office network, without interfering (e.g. no NAT will be
applied).
Access to UTs may be initiated also from the Head Office network side.
H.323 based audio/video communication
The audio/video services provided by the RSGW can be subdivided into three services:
•
A call set-up support service. It performs mainly terminal registration and address
translation from an alias or E.164 number into a network transport address.
•
An internetworking or ISDN gateway service for voice. It translates between the
H.323 protocol used in the AmerHis network and the ISDN format, both for traffic
and signaling.
•
An internetworking or ISDN gateway service for video. It translates between the
H.323 protocol used in the AmerHis network and the H.320 format, both for traffic
and signaling.
In all cases, AmerHis multimedia terminals shall be fully H.323v2 compliant.
The RSGW can provide the call set-up service when UTs establish
•
calls with the ISDN (either voice or video)
•
calls with UTs with a private or public IP address belonging to the same VSN and
belonging to the same or another RSGW
The latter calls use AmerHis mesh connections in order to convey voice/video traffic (only
signaling goes through the RSGW).
Note that calls with UTs belonging to a different VSN will be forwarded to the ISDN and
treated as ISDN calls.
Multimedia calls between an AmerHis UT and an Internet H.323 terminal will be allowed,
although a call set-up support service will not be provided (i.e. the calling user has to know
the destination IP address). Note that users with private IP addresses, which use NAT to
access the Internet, will only be able to place calls, but not to receive them.
Finally, the voice internetworking service provides connectivity between AmerHis VoIP
terminals and standard phones connected to the PSTN or ISDN, while the video
internetworking service offers connectivity between H.323 terminals within AmerHis and
H.320 ISDN multimedia terminals, at either 128 kbps or 384 kbps.
For both types of internetworking services, calls can be initiated from both ends, ISDN or
AmerHis, with independence of the RSGW subscriber address type (public or private).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
192 / 266
RSGW
SoftPhonee
ISDN
IP Phone
PSTN
Terminal Adapter
UT
RCST
Standard
Phone
Figure 13-4 H.323 based Voice and Video Internetworking Service
Star IP Multicast service
The RSGW provide its subscribers with access to IP multicast flows generated or received
by a multicast enabled terrestrial network. The RSGW delivers these multicast flows
dynamically on user request.
RSGW
RCST
Multicast
source
Multicast enabled
ISP/Corporate
network
UT
RCST
Figure 13-5 Multicast Service
The multicast enabled network may be directly the ISP/Corporate network. Alternatively,
if the directly connected network does not support multicast protocols, the RSGW may
connect to the multicast enabled network through a GRE tunnel.
Only one RSGW per VSN can support the multicast service.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
193 / 266
13.2.2 New SatLife services
13.2.2.1 Audio/Video communication based on SIP protocol
SIP stands for Session Initiation Protocol. It is an application-layer control protocol that
has been developed and designed within the IETF with easy implementation, good
scalability, and flexibility in mind.
The SIP protocol is used for creating, modifying and terminating sessions with other
participants. By sessions, we understand a sender and a receiver (or user agents) that
communicate and the state kept during the communication.
The SatLife RSGW supports SIP services using a SIP proxy.
The SIP proxy server included in the RSGW performs the following functions for
voice/video calls (in case of being to/from ISDN/PSTN, only for voice calls):
•
Call control function allows establishing the call and setting the right parameters
for a correct communication.
•
Network access control allows the user agent to authenticate using a
username/password in order to register into the SIP proxy.
•
Programmable routing function allows the SIP proxy to establish fixed rules in
order to forward some calls to other SIP proxies depending on the destination
address.
•
Rendezvous point function allows the SIP proxy to receive all the signaling
messages for call establishment and release from all user agents of the domain.
Thus SIP proxy is in charge of locating the called SIP user.
•
Proxy chaining is the ability of the SIP proxy to forward a call to other proxies
13.2.2.1.1 SIP voice calls with ISDN/PSTN terminals
The SatLife RSGW allows a voice call to be established from a SatLife subscriber with a
SIP user agent registered in the RSGW SIP proxy to an ISDN/PSTN terminal. Thus, the
RSGW is in charge of translating both traffic and signaling from ISDN protocol to/from
SIP protocol.
For this internetworking service, calls can be initiated from both ends, ISDN or SatLife,
with independence of the RSGW subscriber address type (public or private).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
194 / 266
Figure 13-6 SIP Voice Call to ISDN/PSTN
13.2.2.1.2 SIP voice/video with SIP terminals located at the Internet
A SatLife subscriber SIP user agent is able to establish a communication (voice and video)
to an external SIP terminal located at the Internet. Both of them will communicate using
SIP protocol through the Access Router located at the RSGW.
Figure 13-7 SIP Voice/Video Calls to Internet SIP endopoints
For this service it is necessary to differentiate based on the type of IP address assigned to
the subscriber.
AEO-005479
SATLIFE
D311
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
195 / 266
A SatLife UT with a public IP address is able to send and receive SIP voice/video
calls being actively registered in the RSGW SIP proxy. That means that the SIP
proxy is in charge of finding the Internet user agent (in case of an outgoing call) or
finding the SatLife user agent (in case of an incoming call).
A SatLife UT with a private IP address (i.e. NATed in the RSGW) is able to make
outgoing SIP voice/video calls only if it is deregistered from the RSGW SIP proxy.
In any case, it could be registered to a third party SIP proxy located in the Internet.
13.2.2.1.3 Voice/Video calls with SIP terminals within the same VSN
A SatLife subscriber with a SIP user agent registered in the RSGW SIP proxy is able to
establish a communication (voice and video) to another SatLife subscriber located in the
same VSN and registered at the same or a different RSGW.
Thus, the RSGW will be in charge of the signaling communication in order to allow both
parties to start the communication, but after this phase a direct communication from one
user to the other (without passing through the RSGW) will be performed. In that way only
one satellite hop will be performed as the OBP will be in charge of routing the traffic.
Calls can be set-up with independence of the RSGW subscriber address type (public or
private).
Figure 13-8 Voice/Video Calls between SatLife SIP Terminals
13.2.2.1.4 NATed endpoint support
A SatLife UT NATed at the subscriber RCST is able to make voice/video calls being
registered in the RSGW SIP proxy, even if the NAT implemented at the subscriber RCST
does not support SIP Application Level Gateway (ALG) functionality.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
196 / 266
13.2.2.2 Call termination optimization for ISDN/PSTN voice/video calls
The SatLife RSGW allows optimizing the termination of the H.323 voice/video service by
not terminating an ISDN/PSTN call initiated by a SatLife UT necessarily in the
subscriber’s RSGW, but by using a collaborating ITSP node.
As a collaborating ITSP node we understand an external ITSP, accessible through
Internet/Intranet and with an adequate network infrastructure, or a secondary RSGW
belonging to the same VSN. If the RSGW service provider reaches adequate agreements, it
may be more convenient for cost reasons to let these ITSPs terminate certain calls instead
of doing so locally.
The RSGW service provider decides for each collaborating ITSP the conditions under
which the routing of a call is going to be performed. These conditions are based on call
destination and/or type of service (voice/video) and may be defined taking into account the
best rates offered by each ITSP in each case.
This process of call termination optimization does not affect the SatLife user as it is
transparent for him.
Figure 13-9 H.323 Voice/Video Call Termination Optimization
13.2.2.3 H.323 service improvements
13.2.2.3.1 Internet calls improvements
Thanks to improved NAT traversal functionality, a SatLife H.323 enpoint with private IP
address can be actively registered with the RSGW Gatekeeper while placing calls towards
H.323 users located in the Internet. It is no longer necessary to de-register first from the
Gatekeeper, as required for AmerHis.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
197 / 266
From the Internet user point of view, calls will appear as being originated by the RSGW
GK (proxy functionality).
13.2.2.3.2 NATed endpoints support
The SatLife RSGW supports NAT traversal, allowing a H.323 terminal, which is NATed at
the subscriber RCST, to make voice/video calls towards ISDN/PSTN, Internet H.323
endpoints and non-NATed H.323 endpoints within the same VSN.
Thus a NATed H.323 terminal is able to perform H.323 voice/video calls even if the
subscriber RCST NAT does not support a H.323 ALG.
13.3 Functional Architecture
13.3.1 Overview
The RSGW is composed by the following sub-systems, as shown in next figure :
•
Satellite Subsystem (RSGW-SS): Its function is to forward those IP packets in the
air interface addressed to the RSGW to the local RSGW LAN and vice-versa, using
the DVB-S and DVB-RCS standards.
•
Ground Subsystem (RSGW-GS): It provides access to external networks (i.e. the
Internet, an Intranet, ISDN) and provides related auxiliary services.
•
Management Subsystem (RSGW-MS): It manages and controls the RSGW station.
SatLife developments have impact on the Ground and Management subsystems, which are
further detailed in the following sections.
RSGW
ISDN
Air I/F
Satellite
Subsystem
Ground
Subsystem
ISP
Management subsystem
Figure 13-10 RSGW Subsystem Breakdown
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
198 / 266
13.3.2 Ground system
The RSGW-GS is composed of the following elements:
QoS/SLA control: It assures that subscribers get bandwidth resources according to their
SLA and guarantees QoS for voice/video services.
Access router: It provides access to the ISP or Telco, performs NAT for prosumer
subscribers using private IP addresses and supports the multicast service.
Audio/Video sub-system: It supports H.323 and SIP based call set-up and ISDN gateway
services for audio and video communications.
Figure 13-11 RSGW-GS Elements
13.3.2.1 Audio/video subsystem
13.3.2.1.1 VoIP gateway
The VoIP gateway allows subscribers using H.323v2 or SIP compliant terminals to
connect to standard phones in PSTN/ISDN. It is responsible for providing all translations
necessary for transmission formats and control procedures between the IP supported
portion (SatLife) and the PSTN/ISDN part of hybrid calls.
13.3.2.1.2 Videoconference gateway
The Video gateway allows subscribers using H.323v2 compliant terminals to connect to
H.320 compliant terminals connected to the ISDN.
13.3.2.1.3 Gatekeeper
The Gatekeeper provides call control services to the H.323 endpoints. Examples of such
services are address translation, admission control and call authorization.
The RAS (Registration, Admission and Status) protocol defined in H.225.0 is used to
communicate between a terminal and a gatekeeper.
A main function of the RAS channel is to allow the terminal to be attached to a gatekeeper
by registering itself. Registration basically results in an update of the gatekeeper’s address
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
199 / 266
translation table. This allows other terminals to locate a registered terminal and to
determine its transport address in order to initiate a call signaling channel.
A second function of the RAS channel is to perform admission control, authorizing
network access and the use of the VoIP or videoconferencing gateways. The Gatekeeper
Zone will correspond to all those RCST users allowed to use the call set-up support and
PSTN/ISDN gateway services.
13.3.2.1.4 SIP Proxy
The SIP proxy provides call control services to the SIP user agents. Examples of such
services are address translation, admission control and call authorisation.
13.3.3 Management subsystem
The management subsystem does fault, performance and configuration management of the
RSGW station, besides of accounting data collection.
Figure 13-12 Management Modules
Two functional blocks can be identified:
•
Operator management module.
•
Management from the NMC module
13.3.3.1 Operator management module
The Operator management module of the RSGW has to handle fault management,
configuration and performance management. It provides the RSGW operators with an
adequate Man-Machine interface to manage the station and allows:
Fault Management. Detection, isolation and correction of abnormal operations occurring in
the RSGW elements.
Subscriber and Configuration Management. Configuration of most important and
frequently used parameters of RSGW elements. Configuration of subscriber accounts,
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
200 / 266
allowing configuration (addition, deletion and edition) of administrative data, routing
information, dial plan and QoS configuration.
Performance Monitoring. Evaluation and reporting of RSGW equipment behaviour.
Service performance evaluation.
Accounting. Measures the use of RSGW services. Log of information for billing purposes.
Station management functionality can be provided both locally and remotely, either
through a LAN, the Internet/Intranet or through a dial-up connection.
13.3.3.2 Management from the NMC
Being a network element within the SatLife network, the RSGW supports remote
management from the Network Management Centre (NMC). The management operations
are grouped into the following categories:
Remote RSGW monitoring: Monitoring (no control) of RSGW (except for GW-RCST
IDUs), including fault management, by means of SNMP mechanisms. The RSGW
implements a private MIB for this purpose.
Remote GW-RCST monitoring & control: GW-RCST IDUs are monitored and controlled
directly by the NMC as any other subscriber RCST IDU, using SNMP through the satellite
interface.
Accounting Support: The NMC has access to local accounting files by means of a FTP
server.
Management interactions between the NMC and the RSGW (except GW-RCST M&C) are
done through the terrestrial interfaces and are protected by a security mechanism.
13.4 Physical Architecture
Figure 13 shows the physical architecture of the SatLife RSGW. No new HW elements
have been added with respect to the AmerHis RSGW.
The VoIP Gateway and Video Gateway functionality, which could have been incorporated
in a single equipment, is separated into different equipment as to increase RSGW
modularity and facilitate a progressive service deployment.
The Gateway Management Module (GMM) Computer implements the functionality of the
RSGW-MS. The Remote Access Router provides a back-up link for accessing the GMM
remotely.
Note that all represented switches are physically the same switch, which is partitioned into
three different sub-switches. For the sake of clarity, however, the switch has been divided
into three in Figure 13.
The SIP proxy runs in the same computer as the AmerHis H.323 Gatekeeper.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
201 / 266
Figure 13-13 RSGW Physical Architecture
13.5 Voice/Video Communications
13.5.1 H.323 service
The H.323 service in SatLife is exactly the same as the service offered in AmerHis but
additionally, several improvements are introduced. These improvements are focused on
NAT traversal in case the NAT is located both in subscriber RCST or the RSGW. On this
purpose, several solutions are described for each case.
13.5.1.1 NAT traversal support
We distinguish between two problems associated to the NAT, as we have just mentioned:
•
NAT located in the Access Router: The H.323 ALG of the RSGW Access Router is
problematic when the calling user is actively registered in the GK. Proposed
solution is to use the GK in GK proxy mode (see section 2.5.1.1.1).
AEO-005479
SATLIFE
D311
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
202 / 266
NAT located in the subscriber RCST: The H.323 communication will not be
correctly established if an H.323 ALG is not implemented. Proposed solution is to
use GK Configuration for NATed endpoints (see section 2.5.1.1.2).
13.5.1.1.1 GK proxy
The voice/video service as defined in AmerHis project obliged the H.323 user terminal to
unregister from the GK so that the H.323 ALG (running in the Access Router) could work
properly and in this way allow a user with a private IP address to make a call towards an
H.323 terminal at Internet. For a more detailed description of the problem, see DR-01.
This section describes a new way which allows terminals with private IP address to call
H.323 terminals in Internet despite the fact that the calling terminal is actively registered in
the GK. This is achieved thanks to the GK proxy mode, which is equivalent to
H225/H245/RTP routed mode (that is, all the call traffic including RTP voice traffic is
forwarded by the GK). Therefore GK acts as if it was an H.323-H.323 Gateway (see Figure
14).
In fact, the only calls that will be made in GK proxy mode will be from SatLife Network
IP addresses of the RSGW’s VSN to Internet public IP addresses. On the contrary, if the
call is established between two terminals whose IP address are inside the VSN Network
range, the call will be made in H.225 routed mode (H.245 and RTP will be sent directly
between the two terminals).
So the GK proxy mode will not be triggered for calls between endpoints with addresses
inside the following ranges:
- All the private IP address range (including those belonging to the RSGW). Then, we
are covering all the private IP addresses of the VSN.
- All the public IP address ranges belonging to the VSN the local RSGW belongs to
(including those belonging to the RSGW).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
203 / 266
H.323
H.225 (RAS)
LRQ/LCF
Rem ote
term inal
H.225 (Signalling)
H.245
RTP
ISP
Satlife
RSGW 1
H.323
GK 1
VoIP
GW
RCST
RCSTs
User 1
Access
Router
SLA
Figure 13-14 Outgoing Internet Call in GK Proxy Mode
H .2 2 5 (R A S )
L R Q /L C F
H .2 2 5 (S ig n a llin g )
H .2 4 5
R TP
H .3 2 3
RSG W
2
G K
RCST
U s e r2
S a tlife
I S IPS P
RSG W
H .3 2 3
1
G K
V o IP
G W
1
RCST
U s e r1
V o IP
G W
A ccess
R o u te r
SLA
R C STs
2
R CSTs
SLA
A ccess
R o u te r
Figure 13-15 Internal H.323 Call
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
204 / 266
Figure 14 is an example of an H.323 call towards Internet where the GK forwards all the
traffic, whereas the Figure 15 shows a call between two terminals of the same VSN and
therefore H.245/RTP traffic is directly exchanged among RCSTs.
13.5.1.1.2 NATed endpoints support
This new feature allow an H.323 endpoint with a private IP address and NATed at the
RCST (with no H.323 ALG implementation) to make calls towards another endpoint
regardless of being located in ISDN/PSTN, Internet, or another H.323 endpoint belonging
to the same VSN.
The way how the GK works for that kind of endpoints is simple. First of all, the GK
detects automatically if an endpoint is NATed as soon as it registers with the GK. For that
purpose, the H.323 terminal must be pre-registered specifying the alias and the public IP
address of the NAT used by the RSCT (this could impose an static translation for that
H.323 endpoint).
In case that an H323 terminal is detected as being NATed and makes a call towards
another H.323 endpoint, the GK behaves as if it was GK proxied for this terminal
(regardless of the GK proxy is enabled or not). That is, H.225, H.245 and RTP are routed
through the GK.
As you can see in the Figure 14, if a call is made towards an H.323 terminal in Internet all
the traffic is forwarded by the GK.
Regarding the configuration of the GK, there is no a significant change in the configuration
file. Simply the support of NATed endpoints has to be enabled and the endpoints to be
treated as NATed are inserted (specifying the E.164 alias).
13.5.2 SIP service
The aim of this section is addressing all call management related issues needed to provide
voice and video conference services for SIP protocol. Conference services call
management implies configuration of two different RSGW elements: SIP proxy server and
VoIP Gateway.
13.5.2.1 Protocol
The RSGW supports the SIP/v2.0 protocol (RFC 3261), which includes both call
establishment (SDP) and call control protocols.
13.5.2.2 Record Routed mode
There are two ways how the SIP Proxy manages the signaling messages for call
establishment.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
SIP proxy
(RSGW)
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
205 / 266
SIP proxy
INVITE
INVITE
INVITE
SIP
SIP
BYE
SIP calling
party
SIP proxy
(RSGW)
SIP called
party
SIP proxy
INVITE
100 Trying
INVITE
100 Trying
INVITE
100 Trying
180 Ringing
180 Ringing
180 Ringing
DEFAULT
BEHAVIUR
regardless of
the mode:
INVITE message
and the rest of
messages
involved in this
transaction are
forwarded from
SIP proxy to SIP
proxy.
200 OK
200 OK
200 OK
ACK
BYE
200 OK
The call release
messages are
exchanged
directly
between the two
call parties
Figure 13-16 Non Record Routed Mode
Non Record Routed mode: This is the default mode a SIP proxy normally is configured.
The SIP proxy only forwards the SIP messages for call set up (INVITE message) towards
the corresponding remote SIP proxy without changing it at all. After doing that, the SIP
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
206 / 266
doesn’t get involved at all in the call (including the call release, represented by BYE
message). In Figure 16 you can see an example of this behaviour.
If we want the SIP proxy to generate CDR, this mode is not the best one, as the SIP proxy
must be aware both of connection and disconnection of the call.
SIP proxy
(RSGW)
SIP proxy
INVITE
With Record
Routing
INVITE
BYE
INVITE
BYE
SIP
SIP
Figure 13-17 Record Routed Mode
Record Routed mode: In contrast to the previous case, this mode makes the call parties to
send the BYE message not directly between them but through the corresponding SIP
proxy. In fact, as soon as the SIP proxy of the RSGW receives the INVITE message it
includes a new field (Record Route) before forwarding it to the following User Agent.
Thanks to this field, our SIP proxy is informing the called party that it wants to be in the
path of the following request messages, including BYE message. So this message will be
forwarded at least by the SIP proxy of the RSGW.
This way, the SIP proxy is aware of all the call procedure and therefore obtains enough
information in order to generate CDR files (see previous figure).
13.5.2.3 Communication between SIP proxies
In contrast to the method employed in H.323, in which special messages (LRQ from H.225
RAS) are used for Inter-gatekeeper communication for alias-to-address translation, the
case of SIP proxy is much simpler.
Depending on the destination alias, the SIP proxy will forward the INVITE message
towards:
•
Directly to the destination endpoint if the SIP destination endpoint is registered in
the local SIP proxy or destination is towards ISDN/PSTN.
•
Towards a SIP proxy of another RSGW.
AEO-005479
SATLIFE
D311
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
207 / 266
Towards one or more outbound SIP proxies located in Internet
For the last two bullets, INVITE messages are statically forwarded towards the
corresponding SIP proxy based on E.164 prefixes or the remote SIP domain.
Call routing through other SIP proxies (regardless of whether they belong to other RSGWs
or not) is based on the routing logic you configure in your server. That is, for alias-toaddress translation for remote SIP terminals, the SIP proxy located in the RSGW performs
proxy chaining.
An example of SIP proxy chaining is shown in previous Figure.
13.5.2.4 Registration and call admission policy
Following a similar approach than for H.323, the SatLife SIP users belonging to a domain
(served by the SIP proxy in the RSGW) must be pre-registered in the user database located
in the GMM. Unless it is pre-registered, a user will not be able to make or receive calls
from other SIP users.
In contrast to the H.323 pre-registration, in which an alias is attached to an IP address, the
SIP proxy only needs a username, which is the assigned E.164 alias, and a password to
authenticate the user. So the IP address is not necessary at all for pre-registration. This
feature allows a user to be reachable from any SIP terminal with independence of its IP
address.
Apart from this, the SIP proxy allows you to create groups of users and assign them some
privileges for accessing SIP resources, in our case represented by the VoIP GW. That is,
only users included in the group will be allowed to make calls towards ISDN/PSTN.
13.5.2.5 NAT traversal support
We distinguish between two cases of NAT location:
•
NAT located in the Access Router: The RSGW supports SIP ALG in the RSGW
Access Router (see section 2.5.2.5.1).
•
NAT located in the subscriber RCST: The SIP communication will not be correctly
established if an SIP ALG is not implemented. Proposed solution is to use
Symmetric Signaling and Symmetric Media (see section 2.5.2.5.2).
13.5.2.5.1 Use of SIP ALG
SIP calls towards Internet are one of the supported SatLife services.
In case that the origin IP address is private and that a call is placed to the Internet, the
router behaves performing NAT/NAPT. The problem involved in this feature is that in a
normal SIP call establishment procedure, we find embedded Media Addresses (@IP +
port) of the calling terminal. This information is inside the SDP header (text format), which
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
208 / 266
is inside the SIP packet. The called terminal uses this embedded Media Address to send its
RTP packets. Then, if this Media Address remains being private, these RTP packets will
never reach the RSGW.
This is exactly what happens if a normal NAT/NAPT is performed in the router. This
NAT/NAPT only can translate those IP addresses located in the IP header but not the ones
embedded in the SIP/SDP messages. For that reason the solution is the SIP ALG, a special
capability running in the router capable of translating all the private IP adresses, both in the
IP header and inside the SIP signaling messages.
13.5.2.5.2 NATed endpoints support
This feature allows a SIP endpoint with a private IP address and NATed at the RCST to
make calls towards another endpoint located in ISDN/PSTN, Internet, or belonging to the
same RSGW.
We consider that the RCST is not going to implement a SIP ALG, and only just a normal
NAT/NAPT. So the effort to traverse this NAT in the RCST has to be made by SIP proxy,
above all, and the SIP terminal located in SatLife.
Among all the proposals made for NAT traversal for the SIP protocol (STUN, TURN, SIP
ALG, etc.), there is a method which is supported by the vast majority of developers of SIP
devices. In fact, it is not a method but two: use of symmetric signaling and symmetric
media. Although they are presented as two different methods, they are complementary.
The main idea of symmetric signaling (see Figure 18 and Figure 19) is to maintain an
open translation in the NAT/NAPT of the RCST so that the SIP messages can pass directly
through this NAT/NAPT in both directions (incoming and outgoing). For that purpose, the
SIP proxy sends void UDP packets to this translation to prevent the timeout from expiring
and the port remains unchanged for this particular SIP NATed endpoint. That way, BYE
message and its response (SIP message for call clearing) will be able to arrive at the
NATed endpoint.
The SIP proxy detects that an endpoint is NATed as soon as it registers in the server. Then,
the SIP server tags it as being behind a NAT. Then, every time that this terminal makes a
call the SIP proxy detects that there is a NATed terminal involved in a communication and
then modifies the SDP headers of the communication regarding the Media Addresses (@IP
and port of the NATed endpoint).
AEO-005479
SATLIFE
D311
SIP calling
party
SATLIFE-AEO-SYS-DD-3
RCST
(NAPT)
ISSUE:
PAGE:
14/09/2006
2.0 draft
209 / 266
SIP proxy
(symmetric)
REGISTER
REGISTER’
New port translation
activated. Timer is on.
200 OK
Timer is on.
DATE:
UDP
The SIP proxy detects that
this endpoint is behind a
NAT by mismatching
between IP@ from IP
header (changed by NAT)
and inner IP addresses.
Then a flag “Behind NAT”
is activated and contact
information is modified for
this endpoint in the User
Location Data Base.
UDP
UDP
UDP
UDP
UDP
The SIP proxy sends
every X seconds
(configurable value for all
the terminals) an UDP
packet (void) to trigger the
NAT timer and maintain
the SIP signalling port
open.
Timer is on.
Figure 13-18 Symmetric Signaling Call Set-up
Regarding symmetric media, the method is much simpler. In this case, as the SIP proxy
does not participate at all in the packet sending, this method is done exclusively by both
endpoints. The calling endpoint (NATed one) must send the very first RTP packet to create
the binding in the NAPT. The called endpoint must send its RTP packets to the correct IP
address and port in order to traverse the NAPT in the RCST.
AEO-005479
SATLIFE
D311
SIP calling
party
SATLIFE-AEO-SYS-DD-3
RCST
(NAPT)
ISSUE:
PAGE:
14/09/2006
2.0 draft
210 / 266
SIP proxy
(symmetric)
INVITE
INVITE’
Already activated IP@
and port translation.
Timer is on.
DATE:
100 Trying
SIP called
party
SIP proxy detects the
received INVITE comes
from a NATed endpoint.
INVITE
SIP proxy modifies
the IP@ and port
for media packets
of NATed endpoint
from SDP header
for NAT traversal
purposes.
100 Trying
180 Ringing
180 Ringing
200 OK
200 OK
UDP
UDP
UDP
RTP
UDP
BYE
BYE
The called party
decides to hang up
the call. Therefore
sends the BYE to
the SIP proxy,
which is configured
with Record Route.
200 OK
Thanks to UDP packets sent
by SIP proxy, the signalling
port translation is opened
and BYE message can
reach NATed endpoint.
200 OK
Figure 13-19 Symmetric Signaling Call Release
13.5.3 Dial Plan
The main function of a dial plan is to provide the users with an identity in order to be
reachable not only by the rest of the SatLife users but for users located in the ISDN/PSTN.
Although a dial plan has already been designed for H.323, and general design aspects to be
considered are the same for SIP, some additional relevant aspects shall be taken into
account in order to expand this dial plan to SIP:
•
The SIP dial plan should be compatible with standard telephones, H.320 ISDN
phones as well as with SIP IP conference endpoints, allowing thus unified user
identification.
•
The SIP dial plan should support E.164 numbers to allow SIP endpoints to appear
as ISDN terminals using Direct Inward Dial.
AEO-005479
SATLIFE
D311
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
211 / 266
The SIP dial plan should allow RSGW administrators to choose their own dialing
extensions for accessing administered endpoints not associated with a Direct
Inward Dial number independently from others.
The SIP dial plan should be coherent with the H.323 dial plan so that the user has a
uniform dialing pattern regardless of the type of endpoint (SIP or H.323).
The SIP dial plan will only take into account a VoIP GW (not VC GW) in order to
terminate ISDN/PSTN calls locally.
As in H.323 system, alias address is the key SIP feature allowing definition of a Dial Plan
as well. In SIP environment, alias addresses are used instead of the actual transport
addresses of endpoints. In call establishment, a calling endpoint gives the SIP proxy the
alias of the terminating endpoint that it wishes to reach. The SIP proxy will forward the
call session initiation to another SIP proxy depending on the destination alias. This is done
until a SIP proxy has the called terminal registered in its User Location data base.
13.5.3.1 Number structure
The number structure for SIP is exactly the same as in H.323 so that a user with a SIP
endpoint has exactly the same dialing pattern as a H.323 user. The structure will be:
service prefixes, zone prefixes and endpoints aliases.
13.5.3.1.1 Service prefixes
Within the SatLife scenario, the Service Prefix should be dialed before any other prefix or
endpoint alias. As we have said before, for SIP environment we only can use the VoIP GW
and then there is only one service defined (see Table 1).
The prefix to be used for this service is the same one used for voice service in H.323.
Prefix
07
Service description
ISDN voice/phone calls
Table 13-1 SIP Service
13.5.3.1.2 Zone prefixes
Following the same design of H.323 dial plan, each SIP proxy serves one (and only one)
zone and has an associated zone prefix identifying it.
Zone Prefix definition has to be coordinated between all SIP proxies. Addition of each new
SIP proxy, in the SIP proxy call routing configuration, requires populating new Zone
Prefix list in each RSGW’s SIP proxy belonging to the same VSN.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
212 / 266
We adopt the prefix format of the H.323 dial plan. Taking advantage of the fact that the
H.323 environment and SIP environment are totally independent, this three digit prefix
would also be the same one used in the GK Zone.
13.5.3.1.3 Endpoint aliases
As the VoIP GW for SIP is the same as the one used for H.323, we take the same endpoint
classification as with H.323: DID and IVR.
If DID is used, the extension number is the ISDN extension number as assigned by the
Telco. The number of digits and the format of this alias will vary depending on numbering
plan of the country in which the RSGW is placed.
If IVR is used, the extension number is assigned by the RSGW Service Provider. In order
to avoid overlapping with DID extensions, it should be assured that at least the very first
digit of these aliases is different from the very first digit of the DID aliases. Normally, this
digit belongs to an area prefix so it will be exactly the same for all the DID alias.
The VoIP GW is able to consult sequentially the GK and the SIP proxy to find the user
who has the dialed DID or IVR alias. So we do not need to divide and assign in advance
the DID and IVR aliases between SIP and H.323 systems.
13.5.3.2 Type of calls and dial plan in action for SIP
In order to show designed Dial Plan in action, call routing decisions taken and clarify how
dial plan works, this section presents all possible call scenarios.
Calls between SatLife SIP users and ISDN Users:
SatLife provides internetworking services with ISDN, this implies that satellite based users
can call to ISDN user as well as ISDN user can call to SatLife users.
ISDN > SatLife calls
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
213 / 266
RSGW
!
When an ISDN user calls a SatLife user there are two available possibilities:
DID User: Is a SatLife user that has assigned a public E.164 phone number. In order to be
accessed from the ISDN a user should dial:
00 XXX DDDDDDDDDDDDDDDDD
IVR phone number
+ ZZZZZ…Z
Endpoint Alias
Note that in case that the ISDN user is located in the same country in which the RSGW is
placed, the 00+X···X must not be dialed.
IVR Users: ISDN users dials the IVR phone number number and then is prompted to dial
the extension number to reach the destination party.
SatLife > ISDN calls
AEO-005479
SATLIFE
D311
0 7
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
214 / 266
…
DD DD
D
Service prefix
ISDN destination number
If an SatLife user wants to establish a telephony call to an ISDN user, it dials the VoIP
gateway prefix (see Table 1) and the E.164 destination number. SIP proxy shall route the
call to the appropriate this gateway.
Calls between user belonging to the same RSGW:
When a SatLife user calls another SatLife user belonging to the same SIP domain (i.e. the
same RSGW), it shall use both Zone Prefix to indicate destination SIP proxy and endpoint
extension (it can be DID alias or IVR Extension).
!
"
"
Calls between user belonging to two different RSGWs within the same VSN:
When an SatLife user calls another SatLife user belonging to the same VSN but to a
different SIP domain, it dials destination Zone Prefix to indicate destination SIP proxy and
endpoint extension.
The local SIP proxy, based on the destination prefix, statically forwards the INVITE
message to the appropriate destination SIP proxy through the Internet/Intranet interface.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
215 / 266
The rest of SIP signaling messages will pass through both SIP proxies, as they are
configured with Record Route feature. However, voice traffic will be exchanged directly
between SatLife SIP user terminals.
Calls between users belonging to two different RSGWs of different VSNs:
When a SatLife SIP user calls another SatLife SIP user belonging to a different VSN, it
shall use ISDN VoIP GW service prefix indicating destination endpoint DID alias (adding
00XXX if necessary) or IVR number + extension (depending on the destination user
contract). From the SIP proxy point of view, these calls are handled as normal ISDN calls.
Calls shall be routed through ISDN since there is not unicity of addressing space. Calls
between SatLife users through ISDN implies a double satellite hop, but this is the only
possible method to avoid addressing conflicts.
Calls between SatLife Users and Internet Users:
!
Apart from providing the possibility to the SatLife SIP users with making calls towards
ISDN, RSGW allows this users to make Internet/Intranet SIP calls.
In this case, the SIP proxy does not provide an address translation service and this has to be
consulted in external SIP proxies. In case of user with private IP address, it has to register
with another external SIP proxy in order to reach other terminals located at internet.
13.5.3.3 SatLife user numbering plan example
Depending on the kind of contract in terms of DID or IVR the user owns, the numbering
plan will be different. See tables below as an example of VoIP access for a RSGW located
in Spain (NOTE: ZZZ is the Zone prefix belonging to the RSGW SIP domain).
DID Users:
AEO-005479
SATLIFE
D311
Users calling from
SATLIFE-AEO-SYS-DD-3
0034
ISDN (local)
-----
SATLIFE (same VSN)
ISSUE:
PAGE:
14/09/2006
2.0 draft
216 / 266
Prefixes
ISDN (international)
SATLIFE (different VSN)
DATE:
07 0034
User alias
91YYYYYYY
ZZZ
IVR Users:
Note that the 003491DDDDDDD is the IVR access phone number.
Users calling from
ISDN (international)
ISDN (local)
SATLIFE (different VSN)
SATLIFE (same VSN)
Prefixes
User alias
003491DDDDDDD
91DDDDDDD
07 003491DDDDDDD
81LLLLLLL
ZZZ
13.5.4 Call termination optimization for ISDN/PSTN voice/video calls
This new service is proposed in order to minimize the cost of long distance
SATLIF ISDN calls. That is, when a SatLife user wants to call a person who is located in
a different country of the location of its assigned RSGW, the RSGW is able to route the
call in order to terminate this ISDN/PSTN call in another node (like for example an
external ITSP or another RSGW belonging to the same VSN).
An example of this (for the case of routing the call through different RSGWs) can be seen
in next figure:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
217 / 266
RSGW
AU
RSGW
AU
RSGW
RSGW
National call record:
Brazil Brazil
International call record:
Spain Brazil
Figure 13-20 Optimized Call Termination Example
The aim of this feature is to minimize the cost of the calls from a H.323 SatLife endpoint
towards ISDN/PSTN.
The prerequisites to be fulfilled to implement this optimization are:
• All the Full RSGWs involved in this call routing optimization must belong
to the same VSN
• The routing criteria are not always to route the call to the nearest RSGW to
the final destination. They are the result of RSGW service provider’s
agreements with other RSGWs and ITSPs.
• As a consequence of the previous requirement, the update of the routing
policies should be simple and easy.
13.5.4.1 Call routing through an external ITSP
This method is based on the interconnection of the RSGW’s GK and the ITSP’s GK, either
following a hierarchical (parent-child) or a plain structure (only neighbor GKs) for
ISDN/PSTN call routing, depending on the ITSP´s internal GK architecture. The ITSP
could be connected to a Clearing House and this one connected to other ITSPs covering
other areas of the globe.
All ISDN calls that are not routed by the local RSGW would be transferred to the ITSP GK
(parent or neighbor GK).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
218 / 266
H.225 (RAS)
ARQ/ACF
H.225 (Signalling)
H.245
RTP
ISDN
VoIP
GW
ITSP 2
(Brazil)
ITSP2
GK
Clearing House
Satlife
ITSP 1
RSGW 1
H.323
GK 1
ITSP1
GK
VoIP
GW
RCST
User 1
RCSTs
SLA
Access
Router
ISDN
(Spain)
Figure 13-21 RSGW – ITSP Interworking
In Figure 21 and Figure 22 you can see the packet exchange between all the parties
involved in a H.323 call establishment to a ISDN terminal through more than one ITSP in
hierarchical structure of GKs (GK1 is child of ITSP1 GK). As you can see, although the
Call signaling and voice packets go through a different path, all the call traffic is sent
towards the Internet interface.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
ISSUE:
PAGE:
14/09/2006
2.0 draft
219 / 266
ITSP1 GK
Gatekeeper 1
User 1
DATE:
ITSP2 GK
VoIP GW
ARQ
1
2
3
ARQ
5
6
4
H.225 RAS message
exchange
ACF
ACF
Setup
Setup
Call Processing
7
Call Processing
Setup
Call Processing
ARQ
8
ACF
Alerting
Alerting
Alerting
Connect
Connect
Connect
9
H.245 messages exchange
10
RTP Packet exchange
10
Figure 13-22 Message Exchange between the RSGW and an external ITSP
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
220 / 266
1. The user dials the destination number (an international number) preceded by the prefix
corresponding to one of the two GWs of the RSGW the user is a subscriber of (VoIP or
VC). For example, the VoIP GW prefix is the 07 and the VC GW prefix is the 06:
RSGW1
VoIP GW
prefix
International destination number
RSGW1
VC GW
prefix
International destination number
2. When the GK1 receives the ARQ from the User1, the GK1 checks the user’s
permissions. Then the VoIP and VC GWs prefixes are replaced by other prefixes that obey
to a convention of call routing prefixes between the GK1 and the ITSP1 GK.
3. After the digit manipulation, the next step is to decide where to route this ARQ in order
to find the E.164 alias-IP@ translation. For that purpose, the GK1 looks up a Routing
Policy table, which is implemented based on prefixes routing.
4. Let’s see the case that it is an ISDN/PSTN call (VoIP) to be terminated remotely, so the
prefix for VoIP according to the convention would be 001, for example. Then the GK
sends an ARQ message towards the Parent GK (ITSP1 GK), which detects the
international prefix dialed after the 001 and knows to which external GK route the
international dialed prefix.
5. The Parent GK sends and ACF message containing the IP address of ITSP2 GK.
6. The GK1 receives the ACF, which it is translated into another ACF message towards the
User terminal. This message contains the IP address of the GK1 as the H.225 Call
Signaling address, because it is Routed Mode.
7. The Setup H.225 message is sent by the User terminal, pass through GK1 and through
GK2.
8. H.225 Call Signaling messages are exchanged in Routed Mode. The packets are sent
through the Internet connection (Access Router).
9. The H.225 Connect message includes the H.245 Transport Address of the VoIP GW of
the ITSP2. This is so because the call is not H.245 Routed mode in both Gatekeepers.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
221 / 266
10. H.245 Call Control and RTP packets exchange is directly between both terminals.
13.5.4.2 Call routing through a secondary RSGW
This method is almost equivalent to the case of routing call towards an external ITSP but
the ITSP GK is replaced by the GK of the secondary RSGW and also the GK structure is
plain. So the GK of the secondary RSGW would be configured as a neighbor GK.
This implies that the secondary RSGW should allow definition of subscribers with
permission to use voice/video GW services without being registered in the GK of the
secondary RSGW.
13.6 Station Management and Operations
13.6.1 GMM Architecture
The GMM is the element inside the RSGW which provides the operator with an interface
to manage the devices which are part of the RSGW as well as the offered services and its
users. The GMM is also in charge of performing some scheduled functions related to
O&M like backup and accounting.
Figure 23 shows the GMM functional architecture scheme.
As it can be seen, the main functions performed by the GMM have been represented and
grouped together into more general ones:
Management: It includes all the functions related to station management. They are carried
out by different applications such as HP Open View Network Node Manager (NNM) and
software developed by Indra Espacio which are interconnected.
Security: This block contains two functional blocks related to security apart from the
authentication methods provided by both the FTP and Web Servers.
Synchronization: The NTP client synchronizes the GMM clock with a NTP Server of an
upper stratus located at internet. The NTP server allows the rest of RSGW equipment to
synchronize its clocks to the GMM time.
IGMP Adapter: This application improves the multicast performance.
The GMM has a MySQL database. This database contains all the information needed by
the agents, the main RSGW configuration parameters, the subscriber information and it
also contains the SIP proxy endpoints information. Thus the database is used by the SIP
proxy in order to register SIP endpoints and for authentication purposes.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
222 / 266
SCRIPTS
BACKUP
SUBSCRIBERS
MANAGEMENT SW
RSGW
CONFIGURATION SW
HMI
TFTP
Server
CISCO
FAULT
MANAGEMENT
Script turn
on /o ff Power
Switch
DB
PERFORMANCE
MONITORING
mySQL
HP OV NNM
NOTIFY
SW
ScriptMail
Configu ration
SCRIPTS
ACCOUN
TING
CDRs
SDRs
SNMP
AGENT
FTP
Server
MANAGEMENT
IP SEC
NTP
CLIENT
Windows
FIREWALL
NTP.org
Windows
SECURITY
NTP
SERVER
IGMP
AD APTER
SW
NTP.org
Figure 13-23 GMM Functional Architecture
13.6.2 RSGW Subscriber Management and Configuration Tool
RSGW has been built through integration of a diverse set of best-in-class network devices.
Each device has its own commands and configuration mechanisms, furthermore
configuration information of such devices is dynamic since most of them has to be
configured based on subscriber data which is dynamic in nature.
It is clear then that configuring network devices and manage configuration and subscriber
information is a complex task that requires a development of a dedicated tool. Main
GMM
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
223 / 266
advantages of building a Subscriber Management and Configuration Management Tool are
listed bellow:
• Console operators uses Subscriber Management and Configuration Tool to
perform most usual configuration operations. The tool hides the complex
and diverse knowledge required in order to configure each network device.
This drastically reduces complexity of configuration operations reducing
efforts and accelerating progression in the learning curve and therefore
obtain a reduction of operation cost and avoids costly and annoying errors.
• Allows a mechanism to manage subscription and configuration data
efficiently and safely. These information can be stored in a database,
classified by its owner and then populated to network devices. This allows
recovery of such valuable information in case of disasters or fault situation
of any device.
• Allowing a fast and efficient configuration mechanism empowers sense of
integration between all networks devices that composes the RSGW and
increases product ´s perceived added value.
Subscriber Management and Configuration Tool are integrated in the same Java
programmed application. In order to open the application, the operator has to use the
Subscriber Management menu on the NNM.
The application has been separated in two parts according to the kind of operation it
performs, thus there is a part related to Subscriptions and a part related to general
configuration of the RSGW. It is possible to access to one part or the other using two
buttons on the top of the GUI.
13.6.2.1 RSGW Configuration
RSGW Configuration Management is a sub-application inside the Subscriber Management
and Configuration Tool. Configuration Management allows the operator to check and
change the most important parameters of the RSGW using a graphical interface. This tool
is normally not used very frequently, as the RSGW configuration parameters should be
stable after the main configuration process.
However, when a change is required, this tool allows the operator to execute the changes in
a secure way, as it performs all needed security checks in order to assure the robustness of
all the operations performed.
The RSGW Configuration Tool is launched from a NNM menu and it has the appearance
shown in next figure.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
224 / 266
Figure 13-24 RSGW Configuration Tool
The SatLife RSGW Configuration Tool is based on AmerHis RSGW Configuration Tool,
however some improvements have been added in order to manage SatLife needs.
The RSGW Configuration Tool is divided into the following tabs: QoS, Routing, Data
Profile, General, Dial Plan, DVB-S.
For SatLife the possibility of editing SIP proxy setting is integrated inside the Dial Plan
tab, thus it is possible to edit SIP proxy neighbors and local SIP proxy specific parameters.
In order to offer call termination through alternative RSGWs or external ITSP nodes for
voice/video calls, it is also possible to configure 10 collaborating ITSPs and 5 routing
policies per collaborating ITSP. Finally a specific field called Internal Networks has been
added in order to manage support for NAT traversal for voice/video calls.
As it has been explained before, the RSGW Configuration Tool makes the changes
necessary in the equipment and saves all configuration into the MySQL database of the
GMM. Thus coherence between database and equipment is always needed. In order to
assure this coherence, the RSGW Configuration Tool implements an assisted roll-back
operation facility.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
225 / 266
When starting the RSGW Configuration Tool the operator is asked to perform a backup of
the RSGW. Note that this backup is also done automatically every day, but in case some
changes have been done since the last backup, it is recommended to do a new backup
before doing any change. If, during the process of setting up any configuration parameter,
the application detects that any of the equipment has had any problem, it automatically sets
the application into a non-coherent state and advises the operator to do a restore of the
RSGW in order to recover coherence between database and equipment.
Note that if the RSGW Configuration Tool reaches this non-coherent state, the full
Subscriber Management and Configuration Tool remains blocked till a RSGW restore
operation has been performed.
13.6.2.2 Subscriber Management
Subscriber Management is a sub-application inside the Subscriber Management and
Configuration Tool. This tool allows the operator to configure all the parameters relative to
subscribers.
Without the use of the Subscriber Management tool, the process of adding a subscriber into
the RSGW would imply changes in some of the equipment and it would mean accessing
each of the equipment from its native interface, usually a non-graphical interface.
This tool is expected to be used frequently by the operator, as any changes/operations
related to any of the subscribers may be done using this tool. These operations include
addition, deletion of subscribers or checking subscribers information.
As it was done for the RSGW Configuration Tool, all the parameters configured in the
equipment related to subscribers are also saved in the MySQL database hosted in the
GMM. In order to assure the coherence between equipment data and database a semiautomatic roll-back strategy has been taken into account in the development of the
Subscriber Management Tool. Thus, the application is able to detect any equipment failure
during the configuration process and when a failure is detected the subscriber is set to state
“Corrupted”, which means that the information related to this subscriber in the database is
not coherent with the equipment data. In this state the application doesn’t allow to perform
any operation but deleting this subscriber, so that the application can recover the
coherence.
The RSGW Subscriber Management Tool is launched from a NNM menu and it has the
appearance showed in the next figures.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
226 / 266
Figure 13-25 RSGW Subscriber Management Tool Main Screen
In the main screen (see Figure 25) it is possible to get a list of all the subscribers with its
main configuration or get a limited list of subscribers for a performed search.
From this point the operator can add, edit or delete subscribers. After pressing Add button
or Edit button (after selecting a subscriber), all the information susceptible to be configured
related to the subscriber is shown in two flip cards (see Figure 26).
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
227 / 266
Figure 13-26 Subscriber Edition/Adition Interface
Information related to each subscriber is divided basically in Administrative information,
Routing information, Dial Plan information and voice/video services, Traffic Profile and
Data Classification information.
For SatLife, as difference with AmerHis, the Subscriber Management Tool has the
possibility to set SIP specific parameters (i.e. configure E.164 alias/email alias address and
password for each of the subscriber’s SIP user agents).
13.6.3 Accounting
SIP voice/video calls CDR files are generated using daily background script running in the
GMM. Those files contain start/end time of the call, call type (incoming/outgoing) and
endpoint addresses.
Note that H.323 CDR files are also generated as it was done for AmerHis RSGW as well
as SLA Enforcer SDR files.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
228 / 266
13.6.4 Backup
13.6.4.1 SIP Proxy Backup
The SatLife RSGW performs a daily backup of all the equipment data and configuration
files as well as some NNM files related to alarms and the GMM database. This backup
includes, as a difference with AmerHis, the backup of the SIP proxy configuration files.
This backup is performed automatically and daily by the GMM. It is stored in the GMM
allowing an easy restore of the RSGW in case of a failure, loss of data or any other
unexpected event. Note that the operator can also perform a manual backup from the NNM
menu and from the Configuration Tool.
The access method used to perform SIP proxy backup is through FTP from the GMM
(acting as FTP client) to the SIP proxy (acting as FTP server).
13.6.4.2 SIP Proxy Restore
In case of loss of data or an unexpected event that causes a mismatch between the database
data and the configuration of the SIP proxy, the SIP proxy can be restored to a previous
backup configuration.
This is done manually by the operator from the NNM menu and it is integrated into the
RSGW restore functionality offered in AmerHis. That means that a complete RSGW
restore operation is performed, not only a SIP proxy restore.
13.6.5 Performance Management
The NNM allows the operator, using the menu, to get performance information from the
different RSGW equipment.
In addition to the information already provided for AmerHis RSGW, the SatLife RSGW
NNM provides the operator with information related to the new services. It provides
information about active SIP/H.323 voice and video calls, using a Real Time graphic.
13.6.6 Fault Management
The SIP proxy runs in a server which has the Linux Operative System. The init process
available in Unix machines is configured so that the SIP proxy is always running (that is,
when it goes downs, it is restarted again). Furthermore, there is a watchdog card available
in the server to reboot it in case it is not able to refresh the timer.
The server supports IP, so it is shown in the GMM network map and is polled periodically.
To add features for monitoring purposes the Net-SNMP agent is installed. By default that
agent sends the authentication failure and coldStart traps. To have more information some
objects defined in its MIBs can be polled. The following table summarizes those objects:
Object
Description
Mib
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
229 / 266
MemAvaiReal
Available Real/Physiscal
Memory Space on the host
UCD-SNMP-MIB
SsCpuRawIdle
Idle CPU Time
UCD-SNMP-MIB
Table 13-2 Monitored GK/SIP Proxy Server Parameters
13.6.6.1 GMM SNMP Agent
For SatLife no SNMP Agent adaptation is contemplated with respect to AmerHis SNMP
Agent.
13.6.6.2 RSGW MIB modifications
For SatLife no MIB modification is contemplated.
13.6.6.3 HP OV NNM customizations
Main customization of HP OV include the change of Gatekeeper performance parameters
to Gatekeeper/SIP Proxy nomenclature as, although Gatekeeper and SIP Proxy are
different functional entities, they reside physically in the same equipment.
Moreover a new submenu has to be created in order to show active SIP voice/video calls.
13.7 Conclusions
RSGW developments have been mainly focused on improvements of multimedia services.
Some RSGW enhancements foreseen initially have been discarded after deeper analysis
and taking into account project scope and available resources. In the following, main
aspects which have been finally not implemented are briefly discussed.
Multi-VSN RGW (or VLAN RSGW)
With current SatLife system capabilities, giving support to more than one VSN per RSGW
would be at the cost of replicating almost all RSGW elements. A commercially interesting
multi-VSN RSGW should at least allow sharing GW-RCST IDU and ODU equipment
between multiple VSNs and this would probably require some VLAN support from the
GW-RCSTs (and from the NCC). As these system changes have been finally discarded,
using a different RSGW for each VSN is recommended instead.
IPSec with VoIP
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
230 / 266
The current VoIP ISDN GW within the RSGW would require a HW and SW upgrade to
support high rate situations with IPSec. In principle, RSGW hardware upgrades are not
planned within SatLife project scope.
SIP Videoconference and Multiconference
Current RSGW Videoconference ISDN GW equipment does not support SIP and a HW
upgrade is not contemplated7. The same applies to multiconference support: RSGW
upgrade with MCU HW is not contemplated.
In any case, SIP Videoconference ISDN services and MCU services can be provided by
accessing an external ITSP. This would follow the same philosophy as the one applied to
the H.323 Call Termination Optimization service, i.e. the RSGW shall be able to provide
services on its own, but also be able to interact with external specialized service providers.
14. SOFTPHONE
14.1 INTRODUCTION
14.1.1 Purpose
This document describes the Multiprotocol Softphone or SIPM architecture.
Softphone Multiprocolo SIPM is an IP video telephony terminal with instant messaging
and presence (IMP) capacities.
This document describes the architecture in general terms and a high level description of
the designed components and their relationship.
7
Note that, in any case, SIP videoconferences are supported between RSGW subscribers and towards the
Internet.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
231 / 266
14.1.2 Related Documentation
<CODE> Multiprotocol Softphone (SIPM) requirements specification
14.2 GENERAL DESCRIPTION
14.2.1 System Introduction
Multiprocol Softphone (SIPM) allows to establish audio and video communications by
means of VoIP technology and instant messaging and presence (IM&P) multiparty
sessions. The most important characteristics are:
•
•
•
•
•
It is based on components which can be adapted to the requirements of VoIP and
IMP services.
Integration of different video and audio codecs, with or without royalties.
It is based on the more extended VoIP protocols for terminals: H.323 and SIP.
It is based on the IM&P standard protocols: SIMPLE and Jabber.
Access to different types of agendas (LDAP, Jabber, local).
On the other hand, access to VoIP and IM&P services are made through servers online
which support the protocols mentioned above. Thanks to the use of standard protocols,
Softphone must be able to be integrated on different technological environments and offer
services in residential, corporate segment, etc…
14.2.2 High-Level Architecture
From a general point of view, Softphone is organized in different layers as can be seen in
the following figure:
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
232 / 266
Figure 14-1: Multiprotocol Softphone High-Level Architecture
The architecture is summarized in the next components:
For the VoIP part, H323 and SIP protocols are modeled as two components of independent
signaling management which access to the same general interface.
On IM&P, a similar treatment for SIMPLE and XMPP protocols is applied.
In the agenda processing, local and remote agendas based on LDAP and XMPP, are
covered.
14.3 COMPONENT DESCRIPTION
In this chapter it’s described the components which conform the Multiprotocol Softphone
SIMP application architecture model. It’s also indicated the different designed components
and the interaction between them and the simplified classes diagrams which implement
them.
14.3.1 APPLICATION MAIN COMPONENTS
The application is made up of different components interrelated according to the following
diagram of packages.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
233 / 266
Figure 14-2: Multiprotocol Softphone Components
The components of the system are:
•
Softphone: Multiprotocol Softphone application or main executable
•
Setup: component that is in charge of installing/uninstalling the application and
necessary operations such as verifying the installation requirements
•
OpenH323: Component based on the free stack of openh323.
•
SIP/SIMPLE: Component which acts as SIP and SIMPLE stacks.
•
XMPP: Component which manages IM&P communications based on
Jabber/XMPP.
•
Codecs: Components which implement audio codecs.
•
Video: Component which implements the video control and its coding and
decoding.
•
Handsets: Component for the management of USB handsets which allow to dial
and use them as audio devices.
•
VoIP Communications: Component to manage common audio and videoconference
operation, integrating their different modules (codecs, devices...) and supported
protocols.
•
IM Communications: Common operations management component for instant
messaging systems so that they can be accessed uniformly, providing also the
necessary graphical interface for these operations.
AEO-005479
SATLIFE
D311
•
•
•
•
•
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
234 / 266
Agenda: Control operations over the different agendas available in the system
component, so that they can be used jointly offering, in addition, the necessary
interface to make them.
LDAP: Component to consult LDAP.
Addins Framework: Library for developing
modularizable and extensible
applications by means of addins/plugins.
AMH: External library of Telefonica I+D´s components which extend MFC
functionality.
TFC GUI: library for developing graphical interfaces with skins support.
OpenH323 Component
For the implementation of the component which supports the functionality of H.323
protocol we will use the OpenH323 library, because it is free, stable and widely tried in
different projects. The main classes which form the H.323 component are shown on the
following diagram.
Figure 14-3: OpenH323 Component
SIP/SIMPLE Component
For the implementation of SIP/SIMPLE component, we will use and complete the library
developed in TID AMHRTC. SIP defines in its specification a layered architecture which
are implemented by different classes of the library.
Syntax and Codification Layer: Codification and decodification of the message
fields.
Transport Layer: Transmission and reception messages through different transports.
Transaction Layer: Management for broadcastings and correspondence between
requests and responses.
Transaction User Layer: Converser of user’s operations into transactions, for
example to manage registry, calls.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
235 / 266
The component is made up of the following classes:
Figure 14-4: SIP/SIMPLE Component
Addins Architecture
In order to guarantee the architecture modularity, it is based on the concept of addins (or
plugins). An addin is, basically, an extension to the main functionality of the application. It
is inserted by loading it in execution time libraries which implement these plugins.
Softphone uses framework Aladdin to develop modularizable and extensible applications,
based on grouping the functionality in implemented components through an Addin
inherited class. The functionality which implements an addin is defined through the
interfaces which it implements. The connection between components (both calls to
methods and event reception) is made through those interfaces and in the main thread of
the application.
In addition the ConfigManager component is defined so that addins can use the
configuration in a unified way and could be notified of their changes.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
236 / 266
Figure 14-5: Addins Architecture
XMPP Component
To implement the XMPP/Jabber component, we will use and complete the library
developed on TID, which implements different IM&P protocols. XMPP supports IMP
sessions, contact list management and presence control of these contacts; all this
functionality is reflected in the design of this component.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
237 / 266
Figure 14-6: XMPP Component
Other Internal Components Architecture
14.3.1.1.1 Configuration
Softphone will allow configuring all the parameters which are possible, although users can
only configure the most convenient. In addition, this configuration will be able to come
from different sources. The application will support the configuration through a local file,
but also the configuration through a remote file in server or the command line. The
architecture which allows implementing this functionality is shown in the following class
diagram.
Figure 14-7: Configuration Component
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
238 / 266
14.3.1.1.2 Agendas
The application will dispose an agenda architecture which allows integrating different data
sources and supporting different agenda structures. At first, local file system, Ldap access
and XMPP will be supported, but the architecture could to include any other. For the
agenda structure, it will contain elements (AgendaEntry) and groups (AgendaGroup). The
groups will contain elements (at first groups nested by simplicity are not contemplated),
and elements will be able to have different presence states (Presence).
Figure 14-8: Agenda Component
14.3.1.1.3 File Transfer Component
The application will support the file transfer through the components which can implement
this functionality, which at first will be only the XMPP component. All file transfers will
be managed in a unified way, allowing its visualization and uniform control, through the
FileTransferManager component
Figure 14-9: File Transfer Component
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
239 / 266
14.3.1.1.4 Event Management
The application supports a uniform system of events or warnings management, where there
could exist different sources (calls, messages, statistics....) and different receivers (audible
notes, window notes....). The event notification could enable and disable itself globally for
a receiver or for each event independently.
Figure 14-10: Event Management
14.3.1.1.5 Statistics Management
This application supports a uniform system of statistics management, where there can be
different sources (calls, system statistics....) and different receivers (at first only a browser
of them). The statistics generation could be enable or disable by each source of statistics.
Figure 14-11: Statistics Management
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
240 / 266
14.3.1.1.6 Handsets
The application will allow to create components to support different handset devices from
which users can dial, the call state can be notified (mainly the incoming calls through the
call signal) and can be used as audio devices for conference.
Figure 14-12: USB Handsets Component
14.3.2 USER INTERFACE
The user interface is formed by different components:
•
Main Window with support skins and which will be able to include internal Tab
Windows which could be shown in tabs form.
•
Tab Windows which could be shown within the main window or through Top
Windows
•
Top Windows: Non-modals windows which will allow to show Tab Windows
outside the Main Window.
•
Other elements:
o
TrayIcon: Notification Icon
o
Configuration: Configuration dialogue with different property pages.
o
Configuration Assistant which allows configuring in an easily and friendly
way the main components of the application.
o
Help: Help pages of the application.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
241 / 266
Figure 14-13: User Interface Components
15. SNMP BASED DVB-RCS AUTHENTICATION PROTOCOL
The authentication protocol to be used by SNMP follows the Quick Key exchange as
mentioned in the DVB-RCS document, thus making our design conformant with the DVBRCS specs. This key exchange protocol uses the cookie value (secret static value shared
between the RCST and NMC) to authenticate the RCST to the NCC via NMC. The flow
diagram and the byte structure of these messages are shown in Figure 15-1 and Table 15-1
respectively.
NMC
RCST
QKE
QKE Response
Figure 15-1: Flow Diagram of the QKE Authentication protocol
AEO-005479
SATLIFE
D311
Nonce
Quick_Key_Exchange () {
SATLIFE-AEO-SYS-DD-3
Bits
Bytes
Pns
}
Quick_Key_Exchange_Response () {
Nonce
Authenticator
}
Bits
8
Bytes
Pns
20
Pha
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
242 / 266
Bit Number/Description
Random string
Bit Number/Description
Random string
Authentication value
Table 15-1: QKE and QKE Response message structures
The QKE and QKE Response messages are encapsulated via SNMP get and the response
to SNMP Get messages. SNMP is used for transport of the authentication messages. The
NMC knows the OID of each client which is defined in the MIB of the RCST as shown in
the Figure 15-2 below (only part showing the security OID is shown for clarity). This is the
MIB definition file which exists in each RCST.
-================================================================
=
-- Definition of security MIB OID Tree
-================================================================
=
nonceNMC
OBJECT-TYPE
SYNTAX
OCTET STRING(SIZE(28))
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"176 bits of NMC nonce, needed to create
the Hash value to be sent by the RCST in the QKE response"
::= { applicationLayer 1}
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
243 / 266
qke
OBJECT-TYPE
SYNTAX
OCTET STRING(SIZE(28))
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"176 bits of QKE response needed to perform RCST authentication"
::= { applicationLayer 2}
Figure 15-2: Amerhis-RCST MIB file in each RCST
15.1 NMC Side
At the NMC side in order to generate the SNMP GET (OID: qke) the followinf interfaces
are needed:
A ‘C’ module generating random value (8 bytes), which acts as the nonce from the
NMC to the RCST: Byte * get_nonce (int length);
A ‘C’ module, which will verify the Hashed Message Authentication Code value sent
by the RCST in the QKE Response: Boolean compare_auth_value (byte * RCST
auth_value, byte * NCC nonce , byte * Secret Cookie);
Static Value: Cookie value (16 bytes long or could be the MAC address)
The flow diagram as shown in Figure 15-3 below shows what happens on the NMC side.
All the above modules are encapsulated SNMP using the NET-SNMP toolkit. The NMC
application first generates the SNMP Get message with the OID qke as shown in Figure
15-2. The response of this get is then encapsulated in the terminal and received at the
NMC. The NMC removes the SNMP wrapper and then uses interfaces 2 and 3 to verify the
hashed Message Authentication String sent by the terminal.
AEO-005479
SATLIFE
D311
G enerate nonce
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
244 / 266
R andom
gen erato r
M ake the Q uick K ey
ex change P aylo ad
E ncapsulate into S N M P
paylo ad know in g the
specific O ID
S end to R C S T
NETSNM P
A P IS
N ew N M C
A pplication
G et S N M P response
from the R C S T
G et the Q K E response from
the S N M P w rapper
V erify the A uth enticatio n
value using the static coo kie
value and the non ce valu e
B ased on result
inform the N C C
A uthentication
Function
O ld N M C
A pplication
Figure 15-3: NMC flowchart during the sending of the QKE protocol using SNMP
15.2 RCST Side
Figure 15-4 shows the flow of data at the RCST side. In order to create the response to the
SNMP GET (OID: qke) the interfaces are:
A ‘C’ module generating random value (8 bytes), which acts as the nonce from the RCST
to the NMC: Byte * get_nonce (int length);
A ‘C’ module, which will create the Hash value sent by the RCST in the QKE Response:
byte * get_auth_value (byte * NCC nonce , byte * RCST nonce, byte * Secret Cookie);
Static Value: Cookie value (16 bytes long or could be the MAC address)
AEO-005479
SATLIFE
D311
Get SNM P request
from the NM C
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
245 / 266
RSCT SNM P
application
Generate nonce
Create the Authentication
value using the static cookie
value and the nonce value
Random
generator and
authentication
m odule
M ake the Quick Key
exchange Response
Payload
Encapsulate into SNM P
payload knowing the
specific O ID
RSCT SNM P
application
Send to NM C
Figure 15-4: RCST flowchart of the QKE protocol using SNMP
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
246 / 266
16. IMPLEMENTING IPV6
For IPv6 some simulation work was done using 6 to 4 router. The tests involved measuring
delay when we only had an IPv4 network and also the delay when we had an IPv6 network
trying to connect to IPv4 network using 6 to 4 router. The testbed used for these
measurements is shown in and the scenario used in shown in and has the following
characteristics:
The satellite emulator is based on the NIST-NET emulator with three interfaces to emulate
OBP (3 spot beams).
It is multicast capable (multicast routing)
Secure IP Multicast Streaming
IPSec and Scalable Multicast key management (GSAKMP & LKH)
Video LAN is used as streaming application
R
Content
R
Consum
Consum
Video LAN
Streaming
192.168.8.1
MROUTE
R+
192.168.7.1
HU
B
Key
Management
Key
Management
HU
B
Key
Management
192.168.9.1
HU
B
Figure 16-1: Testbed Diagram
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
247 / 266
Host 2
IPv4
Network
Host 1
IPv6
Network
IPv4 Router
6to4 Router
Satellite
and IPv4
Network
6to4 Router
Host 3
IPv6
Network
Figure 16-2: IPv4 and IPv6 Scenario
The tests involved running the video LAN application, which was streaming content from
host1.
In the first set of tests, both host 1 and host2 very having IPv4 address and the delay was
collected at both ends to measure the end to end delay for this scenario as shown in Figure
16-3.
The second set of tests, host1 had an IPv4 and IPv6 interface. Host2 only had an IPv6
interface. So a 6 to 4 router was needed on both sides of the satellite emulator.
Figure 16-4 shows the difference between the two tests. There is approx around 50 ms
delay because of address translation done by the 6 to 4 networks.
Regarding actual demonstrations, most of SATLIFE terminals and gateway do not support
IPv6 and hence IPv6 was only simulated.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
248 / 266
Figure 16-3: End to End delay in IPv4 network scenario
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
249 / 266
Figure 16-4: End to End delay difference in IPv4-IPv6 networks
17. CONCLUSIONS
The upgrading of the services functionality of IBIS and AmerHis has caused a redefinition
of the design of the different subsystems. SatLife includes the evolution and enhancements
on both transparent and regenerative platform. In the case of the transparent part, the
design of the HUB and the RCST were included.
The description of the system has been shown in the document and each manufacturer has
presented the development that they will have to face to be compliant with SatLife service
requirements. This is closely related to the DE331, where the tests to verify these features
are described in detail.
This deliverable D310 was produced including contributions from the partners AEO, ASP,
TID, UoS, NERA, EMS, INDRA, TID, UPM, THALES and SHIRON. The main sections
considered in the final delivery were:
General System Desing
Regenerative System Design
OBP Design
Transparent System Design
Regenerative NCC Design
Transparent Hub Desing
NERA User Terminal Desing
EMS User Terminal
Service Provider Desing
Video Monitoring Unit Desing
Service Provider Terminal Design
Regenerative Gateway Desing
Softphone
SNMP Based DVB-RCS Authentication Protocol
Implementing IPV6
Checklist of simulation feedback compliance and future improvements
Only pending an update and reviewed contribution for the regenerative NCC, to be
delivered with some time in advance with respect the first NCC software delivery.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
251 / 266
18. ANNEX A: TR 101-290
The DVB Measurement Guidelines (TR 101 290) provides guidelines for measurement in
Digital Video Broadcasting (DVB) satellite, cable, and terrestrial digital television
systems. The document defines a number of measurement techniques, so the results
obtained are comparable when the measurements are carried out in compliance with the
appropriate definition. Chapter 5 of TR 101 290 recommends and defines tests at the
Transport Stream level. Those tests are divided into three priorities:
• Priority 1, necessary for de-codability (basic monitoring)
• Priority 2, recommended for continuous or periodic monitoring
• Priority 3, application-dependent monitoring (not implemented)
18.1 First priority: necessary for de-codability (basic monitoring)
No.
Indicator
Precondition
1.1
TS sync loss
1.2
Sync byte
Sync_byte not equal to 0x47
1.3 a(1)
PAT rate
Sections with table_id 0x00 do not occur at least every 0,5 s
on PID 0x0000.
1.3 a(2)
PID 0x0 (PAT)
Section with table_id other than 0x00 found on PID
0x00
1.3 a(3)
PAT scrambling
Scrambling_control_field is not 00 for PID 0x0000
1.4
Continuity counter
Incorrect packet order: a packet occurs more than twice
Loss of synchronization with consideration of hysteresis
parameters
lost packet
1.5 a(1)
PMT rate
Sections with table_id 0x02, (i.e. a PMT), do not occur at
least every 0,5 s on each program_map_PID which is referred
to in the PAT
1.5 a(2)
PMT scrambling
Scrambling_control_field is not 00 for all packets containing
information of sections with table_id 0x02 (i.e. a PMT) on
each program_map_PID which is referred to in the PAT
1.6
Absence of PID
Referred PID does not occur for a user specified
period.
Table 18-1: TR 101 290 Priority 1
•
1.1 TS sync loss
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
252 / 266
The most important function for the evaluation of data from the MPEG-2 TS is the sync
acquisition. The actual synchronization of the TS depends on the number of correct sync
bytes necessary for the device to synchronize and on the number of distorted sync bytes,
which the device cannot cope with. It is proposed that five consecutive correct sync bytes
(ISO/IEC 13818-1 [1], clause G.01) should be sufficient for sync acquisition, and two or
more consecutive corrupted sync bytes should indicate sync loss. After synchronization has
been achieved the evaluation of the other parameters can be carried out.
•
1.2 Sync byte
•
1.3 PAT error
•
1.4 Continuity counter
•
1.5 a PMT error
•
1.6 Absence of PID
The indicator Sync byte error is set as soon as the correct sync byte (0x47) does not appear
after 188 or 204 bytes. This is fundamental because this structure is used throughout the
channel encoder and decoder chains for synchronization. It is also important that every
sync byte is checked for correctness since the encoders may not necessarily check the sync
byte. Apparently some encoders use the sync byte flag signal on the parallel interface to
control randomizer re-seeding and byte inversion without checking that the corresponding
byte is a valid sync byte.
The Program Association Table (PAT), which only appears in PID 0x0000 packets, tells
the decoder what programs are in the TS and points to the Program Map Tables (PMT)
which in turn point to the component video, audio and data streams that make up the
program. If the PAT is missing then the decoder can do nothing, no program is decodable.
Nothing other than a PAT should be contained in a PID 0x0000.
For this indicator three checks are combined. The preconditions “Incorrect packet order”
and “Lost packet” could cause problems for Integrated Receiver Decoders (IRD), which
are not equipped with additional buffer storage and intelligence. It is not necessary for the
test equipment to distinguish between these two preconditions, as they are logically OR-ed,
together with the third precondition, into one indicator. The latter is also covering the
packet loss that may occur on ATM links, where one lost ATM packet would cause the
loss of a complete MPEG-2 packet. The precondition “a packet occurs more than twice”
may be symptomatic of a deeper problem that the service provider would like to keep
under observation.
The Program Association Table (PAT) tells the decoder how many programs there are in
the stream and points to the PMTs, which contain the information where the parts for any
given event can be found. Parts in this context are the video stream (normally one) and the
audio streams and the data stream (e.g. Teletext). Without a PMT the corresponding
program is not decodable.
It is checked whether there exists a data stream for each PID that occurs. This error might
occur where TS are multiplexed, or demultiplexed and again remultiplexed.
18.2 Second priority: recommended for continuous or periodic monitoring
No.
Indicator
Precondition
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
253 / 266
No.
Indicator
Precondition
2.1
Transport
Transport_error_indicator in the TS-Header is set to “1”
2.2
CRC
CRC error occurred in CAT, PAT, PMT, NIT, EIT, BAT, SDT
or TOT table
2.3 a
PCR repetition
Time interval between two consecutive PCR values more than
40 ms
2.3 b
PCR discontinuity
The difference between two consecutive PCR values (PCRi+1 –
PCRi) is outside the range of 0...100 ms without the
discontinuity_ indicator set
2.4
PCR accuracy
PCR accuracy of selected program is not within ±500 ns
2.5
PTS
PTS repetition period more than 700 ms
2.6 (1)
Scrambled packet
Packets with transport_scrambling_control not 00 present, but
no section with table_id = 0x01 (i.e. a CAT) present
2.6 (2)
PID 0x1 (CAT)
Section with table_id other than 0x01 (i.e. not a CAT) found on
PID 0x0001
Table 18-2: TR 101 290 Priority 2
•
2.1 Transport
•
2.2 CRC
•
2.3 a PCR repetition
•
2.3 b PCR discontinuity
•
2.4 PCR accuracy
The primary Transport_error_indicator is Boolean, but there should also be a re-settable
binary counter which counts the erroneous TS packets. This counter is intended for
statistical evaluation of the errors. If an error occurs, no further error indication should be
derived from the erroneous packet. There may be value in providing a more detailed
breakdown of the erroneous packets, for example, by providing a separate Transport error
counter for each program stream or by including the PID of each erroneous packet in a log
of Transport error events. Such extra analysis is regarded as optional and not part of this
recommendation.
The CRC check for the CAT, PAT, PMT, NIT, EIT, BAT, SDT and TOT indicates
whether the content of the corresponding table is corrupted. In this case no further error
indication should be derived from the content of the corresponding table. See DVB
Standard for table definitions.
The PCRs are used to re-generate the local 27 MHz system clock. If the PCR do not arrive
with sufficient regularity then this clock may jitter or drift. The receiver/decoder may even
go out of lock. In DVB a repetition period of not more than 40 ms is recommended.
The PCR discontinuity indicator error is set in the case that a discontinuity of the PCR
values occurs that has not been odeling appropriately by the discontinuity indicator.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
254 / 266
The accuracy of ±500 ns is intended to be sufficient for the colour sub-carrier to be
synthesized from system clock. This test should only be performed on a constant bit rate
TS as defined in ISO/IEC 13818-1 [1] clause 2.1.7.
•
2.5 PTS
The Presentation Time Stamps (PTS) should occur at least every 700 ms. They are only
accessible if the TS is not scrambled.
•
2.6 CAT (not implemented)
The CAT is the pointer to enable the IRD to find the Entitlement Management
Messages (EMM) associated with the Conditional Access system(s) that it uses. If
the CAT is not present, the receiver is not able to receive management messages.
18.3 H264/MPEG-4 AVC
H264/MPEG-4 AVC is the latest international video coding standard. It was jointly
developed by the Video Coding Experts Group (VCEG) of the ITU-T and the
Moving Picture Experts Group (MPEG) of ISO/IEC. It uses state-of-the-art coding
tools and provides enhanced coding efficiency for a wide range of applications,
including video telephony, video conferencing, TV, storage (DVD and/or hard disk
based, especially high-definition DVD), streaming video, digital video authoring,
digital cinema, and many others.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
255 / 266
19. ANNEX B: RED IMPLEMENTATION GUIDELINES
This text is fetched from [RED93]. Check also [DRD] which contains RED source code.
This section considers efficient implementations of RED gateways. We show that the RED
gateway algorithm can be implemented efficiently, with only a small number of add and
shift instructions for each packet arrival. In addition, the RED gateway algorithm is not
tightly coupled to packet forwarding and its computations do not have to be made in the
time-critical packet forwarding path. Much of the work of the RED gateway algorithm,
such as the computation of the average queue size and of the packet-marking probability
pb, could be performed in parallel with packet forwarding, or could be computed by the
gateway as a lower priority task as time permits. This means that the RED gateway
algorithm need not impair the gateway’s ability to process packets, and the RED gateway
algorithm can be adapted to increasingly-high-speed output lines.
If the RED gateway’s method of marking packets is to set a congestion indication bit in the
packet header, rather than dropping the arriving packet, then setting the congestion
indication bit itself adds overhead to the gateway algorithm. However, because RED
gateways are designed to mark as few packets as possible, the overhead of setting the
congestion indication bit is kept to a minimum. This is unlike DECbit gateways, for
example, which set the congestion indication bit in every packet that arrives at the gateway
when the average queue size exceeds the threshold.
For every packet arrival at the gateway queue, the RED gateway calculates the average
queue size. This can be implemented as follows:
avg ← avg + wq (q – avg)
As long as wq is chosen as a (negative) power of two, this can be implemented with one
shift and two additions (given scaled versions of the parameters) [14].
Because the RED gateway computes the average queue size at packet arrivals, rather than
at fixed time intervals, the calculation of the average queue size is modified when a packet
arrives at the gateway to an empty queue. After the packet arrives at the gateway to an
empty queue the gateway calculates m, the number of packets that might have been
transmitted by the gateway during the time that the line was free.
The gateway calculates the average queue size as if m packets had arrived at the gateway
with a queue size of zero. The calculation is as follows:
m ← (time – q_time ) / s
avg ← (1 – wq)m * avg
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
256 / 266
where q_time is the start of the queue idle time, and s is a typical transmission time for a
small packet. This entire calculation is an approximation, as it is based on the number of
packets that might have arrived at the gateway during a certain period of time. After the
idle time (time-q_time) has been computed to a rough level of accuracy, a table lookup
could be used to get the term (1-wq)(time-q_time)/s, which could itself be an approximation by a
power of two.
When a packet arrives at the gateway and the average queue size avg exceeds the threshold
maxth, the arriving packet is marked. There is no recalculation of the packet-marking
probability. However, when a packet arrives at the gateway and the average queue size avg
is between the two thresholds minth and maxth, the initial packet-marking probability pb is
calculated as follows:
pb
←
C1 * avg – C2
for
C1 = maxp / (maxth-minth)
C2 = maxp * minth
/ ( maxth-minth )
The parameters maxp, maxth, and minth are all fixed parameters that are determined in
advance. The values for maxth and minth are determined by the desired bounds on the
average queue size, and might have limited flexibility. The fixed parameter maxp, however,
could easily be set to a range of values. In particular, maxp could be chosen so that C1 is a
power of two. Thus, the calculation of pb can be accomplished with one shift and one add
instruction.
In the algorithm, when minth ≤ avg < maxth a new pseudo-random number R is computed
for each arriving packet, where R = Random [0,1] is from the uniform distribution on [0,1].
These random numbers could be gotten from a table of random numbers stored in memory
or could be computed fairly efficiently on a 32-bit computer [3]. In the algorithm, the
arriving packet is marked if
R < pb/(1- count * pb)
If pb is approximated by a negative power of two, then this can be efficiently computed. It
is possible to implement the RED gateway algorithm to use a new random number only
once for every marked packet, instead of using a new random number for every packet that
arrives at the gateway when minth ≤ avg < maxth. As Section 7 explains, when the average
queue size is constant the number of packet arrivals after a marked packet until the next
packet is marked is a uniform random variable from {1, 2,.., [1/pb]}. Thus, if the average
queue size was constant, then after each packet is marked the gateway could simply choose
a value for the uniform random variable R = Random [0,1], and mark the n-th arriving
packet if n ≥ R/pb. Because the average queue size changes over time, we re-compute R/pb
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
257 / 266
each time that pb is recomputed. If pb is approximated by a negative power of two, then this
can be computed using a shift instruction instead of a divide instruction.
Figure 19-1 gives the pseudo-code for an efficient version of the RED gateway algorithm.
This is just one suggestion for an efficient version of the RED gateway algorithm. The
most efficient way to implement this algorithm depends, of course, on the gateway in
question.
The memory requirements of the RED gateway algorithm are modest. Instead of keeping
state for each active connection, the RED gateway requires a small number of fixed and
variable parameters for each output line. This is not a burden on gateway memory.
Figure 19-1: Efficient algorithm for RED gateways
19.1 Verification
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
258 / 266
An FTP upload and simultaneous Web browsing on a shared terminal with 64/128/256/512
kbps services.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
259 / 266
19.2 Calculated delay model (inaccurate):
No
filter
Total Partial
Head
drop
T-hold Packet Rate Rate PPS Averag Peak(ms)
size
(kbps) (kbps)
edelay delay
(byte)
(ms)
(ms)
200
200
200
200
200
200
200
200
1460
1460
1460
1460
1460
1460
1460
40
32
64
128
256
512
512
512
512
200
200
300
400
500
800
1460
1460
1460
1460
512
512
512
512
512
8 0,7
16 1,4
64 5,5
128 11,0
128 11,0
256 21,9
512 43,8
32 100,
0
32 5,0
32 2,7
32 2,7
32 2,7
32 2,7
5248
2830
1017
804
1104
758
585
2823
No
filter
Tail
drop
Peak- Retrans
delay (ms) mission
rate
6663 7970
12 %
3672 4260
10 %
1394 1478
5%
1104 1133
2%
1487 1533
1%
1029 1041
1%
794
796
0%
3762 3770
0%
3013
3178
4378
5578
6778
3987
4178
5761
7351
8945
4150
4480
6080
7680
9280
1%
1%
0%
0%
0%
Table 19-1 Estimated characteristics of RED drop.
Table 19-1 shows an estimate of the characteristics of the terminal when using RED.
Parameter values used in the model:
rwnd = 64 KB
Np = 3
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
260 / 266
19.3 Filtering the BW sampling
Target threshold calculation
120
rate (kbps)
100
80
assigned
threshold
60
40
20
0
0
2
4
6
8
time (s)
Figure 19-2 Transient response of the assigned bw filter.
The previous figure shows the transient response of the assigned bw filter used to calculate
the target buffer threshold.
Parameter values:
wbw = 1/16
Calculation interval: 200 ms
Assigned bw up to 0: 100 kbps
Assigned bw at 0+:
0 bps
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
261 / 266
20. ANNEX C: BURST FORMATS AND COMPOSITION
Figure 20-1 Burst carrying ATM cells
Figure 20-2 Composition of a traffic MPEG2 bursts in EN 301 790 [2]
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
262 / 266
Figure 20-3 Composition of a SYNC burst, from Fig. 7, EN 301 790 [2].
Figure 20-4 Composition of an ACQ burst, from Fig. 8, EN 301 790 [2].
Figure 20-5 Composition of a CSC burst, from Fig. 9, EN 301 790 [2].
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
263 / 266
21. ANNEX D: CHECKLIST OF SIMULATION FEEDBACK COMPLIANCE
AND FUTURE IMPROVEMENTS
See a detailed description of the simulation results in deliverable D220.
SIMULATION CONCLUSION AND
RECOMMENDATION
The number of required Channel IDs
should be minimized: since real time
traffic is bursty (high PCR/SCR ratio),
link sharing would allow taking
advantage of the multiplexing gain, and,
therefore, to increase link utilisation.
Diffserv classification must be performed
according to traffic classes (EF, AF, BE),
since each one imposes different QoS
requirements. Flows must be prioritized,
being the non-elastic flows (that is, class
EF) the ones with the higher priority.
Real time services require no buffering,
that is, the use of short queues in order to
minimize jitter, being the packet losses.
Packets must be sent as soon as possible,
since real time services are jitter sensitive.
Related to this issue, the use of DropHead
buffer management is also recommended
to improve the jitter in case of congestion.
Within EF flows (Real-time application
flows), it is advisable the use of different
queues for VoIP and Video (conferencing)
due to the length of Video packets.
In addition, VoIP priority must be higher
than Video to achieve acceptable VoIP
QoS: results show that the use of the same
priority drives to VoIP punishment.
SYSTEM
COMPONENT
AFFECTED
NCC
RCSTs
RCSTs
RCSTs
COMPLIANCE/FUTURE
IMPROVEMENT
COMPLIANCE with
recommendation
To take advantage of multiplexing
gain, NCC assigns same RCST
channel for connections directed to the
same downlink. This does not include
permanent, multicast and jitter
sensitive connections.
COMPLIANCE with
recommendation
Diffserv classification is applied by
terminals, based on DSCP code in IP
header. EF flows can be mapped to HP
or HPjs connections, while AF, BE
traffic could use LP priority.
COMPLIANCE with
recommendation
Real time services must use HP
connections. In this way, the delay is
reduced, and packets are not buffered
for long, drophead or tail policies can
be configured in the user terminal, to
be applied in case of congestion.
COMPLIANCE with
recommendation
It is possible to use different channels
for voice and video flows for (voice
and video) traffic between two
terminals. The way to implement it is
using HPj for voice and HP or LP for
video.
To classify the flows to be transmitted
in different channels, the RCST can
look at several IP header parameters,
as IP address, port, DSCP or protocol.
AEO-005479
SATLIFE
D311
Different PID for VoIP traffic is required
due to its characteristics: jitter sensitive,
and short packets.
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
264 / 266
RCSTs
COMPLIANCE with
recommendation
Using different channels for voice and
video will imply the asssignment of
different PIDs.
RCSTs
COMPLIANCE with
recommendation
To be checked in RCST design
specification.
A BoD scheme is required for AF flows.
The required properties of the selected
scheme are:
Optimality (efficiency in the sharing
of link capacity),
Fairness,
Stability/Quick Convergence.
For EF (Non Elastic) traffic, a different
BoD solution is recommended:
Long term solution: Based on session
level signaling; for example,
SIP/COPS/RSVP + Admission
Control.
Short term solution: BoD based on the
loss rate and channel utilization
measured at the terminal, and
application aware terminal.
In any case, NCC should be notified of the
required resources of each RCST,
differentiating
between
guarantied
resources (for non-elastic EF traffic), and
desired resources for elastic AF (TCP)
traffic. The proposal is to use C2P
“ChannelModify” profile to ask resources
using the guarantied rate field for EF class
and the peak rate field for EF+AF.
Priorities and weighted fair queuing
(WFQ) algorithms are recommended.
In order to assure no starvation of BestEffort flows, it is required to consider an
extra-request of a minimum bandwidth
within the BoD algorithms, and a
minimum link utilization percentage
assigned to BE queue in the WFQ
algorithm.
SIP/COPS/RSVP: Future
Improvement
NCC/RCSTs
Admission Control: NCC uses CAC,
and applies it through CnxEstReq
messages.
RBDC and CRA requests on every
channel
already
implemented
(SAC/SYNC and ChannelModify
procedures).
ChannelModify
is
used
for
guaranteed-capacity requests from the
terminals. It is applicable to HP and
HPjs connections. Within the same
channel it is possible simultaneously
requesting RBDC and CRA capacity.
RCSTs
COMPLIANCE with
recommendation
RCSTs implement a token-bucket
algorithm, assuring that HP flow does
not spend all the resources of the
channel, but only the guaranteed
bandwidth. In this way the LP queue
will have always some bandwidth.
AEO-005479
SATLIFE
D311
It is recommended a FCA policy
proportional to the requested bandwidth.
It improves the performance of AF/BE
traffic in non congested situations.
SATLIFE-AEO-SYS-DD-3
NCC
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
265 / 266
Future Improvement
Current FCA implementation assigns
capacity in a carrousel manner.
AEO-005479
SATLIFE
D311
SATLIFE-AEO-SYS-DD-3
DATE:
ISSUE:
PAGE:
14/09/2006
2.0 draft
266 / 266
END OF DOCUMENT