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