WP 3100 : Encapsulation and IP Mapping



Similar documents
Introduction VOIP in an Network VOIP 3

Implementing VoIP support in a VSAT network based on SoftSwitch integration

Optimal batch scheduling in DVB-S2 satellite networks

VoIP Bandwidth Considerations - design decisions

How To Deliver High Quality Telephony Over A Network

Advanced Networking Voice over IP: RTP/RTCP The transport layer

Voice over IP: RTP/RTCP The transport layer

VoIP over DVB-RCS A Radio Resource and QoS Perspective

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc

IEEE Broadband Wireless Access Working Group. ATM Based MAC Layer Proposal for the Air Interface Specification

VoIP over Wireless Opportunities and Challenges

Analysis of the bandwidth efficiency of DVB-S2 in a typical data distribution network

How To Understand The Gsm And Mts Mobile Network Evolution

Figure 1: cellular system architecture

Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network

A TALE OF 3 SATELLITE RETURN TECHNOLOGIES

Resources Management using Adaptive Fade Mitigation Techniques in DVB-S2/RCS Multi-Beam Systems

Voice over IP. Presentation Outline. Objectives

A CONTROL FRAMEWORK FOR ADAPTIVE CAPACITY ALLOCATION IN MOBILE DVB-RCS

An architecture for the delivery. of DVB services over IP networks Rennes, January 2007 INTRODUCTION DIGITAL VIDEO TRANSPORT

CMA5000 SPECIFICATIONS Gigabit Ethernet Module

RESOURCE ALLOCATION FOR INTERACTIVE TRAFFIC CLASS OVER GPRS

A study of Skype over IEEE networks: voice quality and bandwidth usage

Analysis of QoS parameters of VOIP calls over Wireless Local Area Networks

BENEFITS OF USING MULTIPLE PLP IN DVB-T2

AN ANALYSIS OF DELAY OF SMALL IP PACKETS IN CELLULAR DATA NETWORKS

Ajay Gummalla-July 2001

Link Layer. 5.6 Hubs and switches 5.7 PPP 5.8 Link Virtualization: ATM and MPLS

Network Simulation Traffic, Paths and Impairment

Clearing the Way for VoIP

2G/3G Mobile Communication Systems

How To Analyze The Security On An Ipa Wireless Sensor Network

Extended-rtPS Algorithm for VoIP Services in IEEE systems

PERFORMANCE OF THE GPRS RLC/MAC PROTOCOLS WITH VOIP TRAFFIC

point to point and point to multi point calls over IP

SATELLITE ACCESS PROCEDURES

QUALITY OF SERVICE OF VOIP OVER DVB-RCS

RTP Performance Enhancing Proxy

TCP in Wireless Networks

This topic lists the key mechanisms use to implement QoS in an IP network.

Management of Telecommunication Networks. Prof. Dr. Aleksandar Tsenov

Attenuation (amplitude of the wave loses strength thereby the signal power) Refraction Reflection Shadowing Scattering Diffraction

Deployment Aspects for VoIP Services over HSPA Networks

VoIP-Kapazität im Relay erweiterten IEEE System

2 nd Generation DVB Interactive Satellite System

Calculating Bandwidth Requirements

ANALYSIS OF LONG DISTANCE 3-WAY CONFERENCE CALLING WITH VOIP

Master Course Computer Networks IN2097

Final for ECE374 05/06/13 Solution!!

VoIP with QoS and Bandwidth-on-Demand for DVB-RCS

Bandwidth usage of common networking applications

How To Determine The Capacity Of An B Network

GSM and Similar Architectures Lesson 07 GSM Radio Interface, Data bursts and Interleaving

Newtec. DVB-RCS enables new networking solutions for the broadcast industry. Newtec Productions N.V. Jean-Pierre De Muyt. Group of Companies P 1

Sources: Chapter 6 from. Computer Networking: A Top-Down Approach Featuring the Internet, by Kurose and Ross

Voice over Internet Protocol (VoIP) systems can be built up in numerous forms and these systems include mobile units, conferencing units and

VOICE OVER WI-FI CAPACITY PLANNING

ESSENTIALS. Understanding Ethernet Switches and Routers. April 2011 VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK

Introduction to EDGE. 2.1 What Is EDGE?

DVB-S2 and DVB-RCS for VSAT and Direct Satellite TV Broadcasting

Channel Bonding in DOCSIS 3.0. Greg White Lead Architect Broadband Access CableLabs

Digital Audio and Video Data

Unit 23. RTP, VoIP. Shyam Parekh

Encapsulating Voice in IP Packets

Application Note How To Determine Bandwidth Requirements

Network administrators must be aware that delay exists, and then design their network to bring end-to-end delay within acceptable limits.

SIP Trunking and Voice over IP

Advanced VSAT Solutions Bridge Point-to-Multipoint (BPM) Overview

Network Performance Optimisation: The Technical Analytics Understood Mike Gold VP Sales, Europe, Russia and Israel Comtech EF Data May 2013

Bluetooth voice and data performance in DS WLAN environment

Adaptive DCF of MAC for VoIP services using IEEE networks

Challenges and Solutions in VoIP

HX System Quality of Service

VoIP QoS. Version 1.0. September 4, AdvancedVoIP.com. Phone:

ENTERPRISE CONNECTIVITY

The Evolution of 3G CDMA Wireless Networks. David W. Paranchych IEEE CVT Luncheon January 21, 2003

How To Recognize Voice Over Ip On Pc Or Mac Or Ip On A Pc Or Ip (Ip) On A Microsoft Computer Or Ip Computer On A Mac Or Mac (Ip Or Ip) On An Ip Computer Or Mac Computer On An Mp3

Performance Analysis of Scheduling Algorithms

Dynamic Reconfiguration & Efficient Resource Allocation for Indoor Broadband Wireless Networks

Transport and Network Layer

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29.

The Basics. Configuring Campus Switches to Support Voice

Customer White paper. SmartTester. Delivering SLA Activation and Performance Testing. November 2012 Author Luc-Yves Pagal-Vinette

Distributed Systems 3. Network Quality of Service (QoS)

Voice-Over-IP. Daniel Zappala. CS 460 Computer Networking Brigham Young University

VegaStream Information Note Considerations for a VoIP installation

MPLS Environment. To allow more complex routing capabilities, MPLS permits attaching a

APPLICATION NOTE 209 QUALITY OF SERVICE: KEY CONCEPTS AND TESTING NEEDS. Quality of Service Drivers. Why Test Quality of Service?

Protocols. Packets. What's in an IP packet

3. Simulator Description. Figure 1: UMTS Architecture (air interface and radio access network). the data stored at the buffer up to a certain maximum

Data Networking and Architecture. Delegates should have some basic knowledge of Internet Protocol and Data Networking principles.

ENSC 427: Communication Networks. Analysis of Voice over IP performance on Wi-Fi networks

Scheduling for VoIP Service in cdma2000 1x EV-DO

VoIP Bandwidth Calculation

Voice Over IP Per Call Bandwidth Consumption

Curso de Telefonía IP para el MTC. Sesión 2 Requerimientos principales. Mg. Antonio Ocampo Zúñiga

An Introduction to VoIP Protocols

Transcription:

WP 3100 : Encapsulation and IP Mapping Rider to the ARTES 5 Adaptive Coding and Modulation (ACM) Project ESA Workshop Presentation 14.2.2007 Bjarne Risløw Thrane and Thrane Rita Rinaldo ESA, TEC-ETC Page 1

Objective of Work Package Design of return link framing structure and IP-mapping with optimum performance for future return link interactive systems Minimum overhead High spectral and power efficiency RRM simplicity and flexibility! Using input from: WP3300 FEC and WP3400 Modem Performance Using assumptions of: Traffic scenarios (traffic distribution found from literature, measurements etc) System scenario (from ACM main project) DVB-RCS standard GSE (Generic Stream Encapsulation) specifications Page 2

Return Link Frame format with ACM Current RCS systems implement Adaptive Coding through Satellite Terminal (ST) frequency hopping between carriers of different data rates With the introduction of high order modulations this becomes inefficient because of the many modulation formats/coding rates combinations (ACM modes), which are used in the system Bandwidth segmentation among carrier types per ST type and MODCOD would imply an important loss because of unpredictability of traffic and fading variations Need for ACM mode change burst by burst in the same carrier Page 3

Fixed Information Length (FIL) Frequency 1024 ks/s Slot 12 Slot 13 Slot 14 Slot 15 Slot 16 Slot 17 Slot 18 512 ks/s Slot 7 Slot 8 Slot 9 Slot 10 Slot 11 512 ks/s 256 ks/s Slot 3 Slot 1 Slot 4 Slot 5 Slot 2 Slot 6 Time Superframe duration Fill problem Fill Problem TBTP is semi-static Allocation Problem complex to allocate resources inefficient, will get empty slots difficult to keep jitter constant TBTP structure must be signalled (overhead) Page 4

Fixed Burst Length (FBL) Frequency Burst using 2 basic slots 1024 ks/s Slot 11 1 ms Slot 12 1 ms Slot 13 1 ms Slot 14 1 ms Slot 15 1 ms Slot 16 1 ms Slot 17 1 m Slot 18 1 ms 512 ks/s Slot 7-2 ms Slot 8-2 ms Slot 9-2 ms Slot 10-2 ms 512 ks/s 256 ks/s Slot 3-2 ms Slot 1-4 ms Slot 4-2 ms Slot 5-2 ms Slot 2-4 ms Slot 6-2 ms Time Superframe duration is a multiple of 4 ms No padding due to fill TBTP is (semi-) static (can change symbol rates) Simplified resource allocation simple, all slots can be used efficient, no empty slots jitter is constant No signalling of TBTP structure necessary Page 5

GSE Protocol Generic Stream Encapsulation Protocol (GSE) considered: - Devised primarily for efficient IP encapsulation over DVB-S2/GS with ACM (Interactive/ Professional application areas) - DVB-TM extended the scope of GSE, which shall horizontally replace MPE/MPEG TS in the second generation IP-based DVB systems. - DVB-SH introduces a generic stream interface - Specifications to be approved by DVB-TM in March 2007 - Layer 2 security to be introduced by 09/2007 Page 6

What is GSE? (I) GSE protocol allows for direct encapsulation of IP and other protocol packets over physical layer bursts/frames It replaces MPE/MPEG-TS or AAL5/ATM encapsulation Key GSE functionalities: Multiprotocol encapsulation support capabilities: IPv4, IPv6, MPEG, ATM, Ethernet, Transparent to network layer functionalities: IP encryption and IP header compression Several addressing modes supported: 6 Bytes MAC Address (including multicast and unicast) No Address (IP-header processing) 3 Bytes Address (optional for the receiver) Implicit binding to Group ID/logon ID in DVB-RCS networks -> important overhead saving ATM VPI/VCI could also be used Page 7

What is GSE? (II) Fully flexible fragmentation of PDUs over physical layer frames Reassembly process is based on Fragmentation ID labels Reassembled PDU integrity guaranteed by a CRC check GSE is future proof New link protocols can be included through specific protocol type values Can be extended to include Layer 2 security Page 8

GSE Protocol: GSE Packets format No fragmentation - 4 bytes - 4 bytes CRC Present in the modified version only Fragmentation - 7 bytes 1st fragment - 3 bytes following fragments - 4 byte CRC Page 9

GSE for the return link: Motivation The selected FBL solution calls for Layer 3 Packets encapsulation over a variable information burst length -> MPEG and ATM are no longer appropriate RRM simplicity and flexibility leading to: improved system efficiency (no bandwidth segmentation) real time jitter sensitive applications requirements satisfaction No padding loss Suitability to the utilization of interference cancellation techniques for system capacity increase Advantage of utilizing the same encapsulation protocol as in the forward link Re-use of protocol SW Efficiency gain is dependent on the actual traffic distribution: 10% up to 35% with respect to AAL5/ATM 3% up to 15% with respect to MPE/MPEG In addition to the throughput gain, a power efficiency gain is achieved thanks to the utilization of burst lengths matched to the traffic nature GSE is robust with respect to different traffic distributions Page 10

GSE for the return link: specific issues Two alternative design considered in the activity: No CRC per full encapsulated PDU (as from current GSE specs) CRC-32 to be added per burst Modified version: Use CRC pr. IP packet instead in-stead of pr. burst Motivation: Reduced overhead since DVB-S2 has very long frames (burst), but DVB-RCS has short (bursts). Simulations performed for the two solutions to assess the gain in terms of overhead GSE encapsulator at the ST fragments incoming PDUs based on the burst length assigned by the RRM and signalled through TBTP Thanks to the FragID presence, PDU fragments with different QoS requirements can be interleaved to ensure real-time traffic requirements satisfaction Page 11

Traffic Model Traffic Model based on specific traffic cases IPLEN is length of IP packet ATRAINLEN is average length of a sequence (train) of IP packets with length IPLEN Nominal Traffic Case Case IPLEN ATRAINLEN Description [bytes] [Bytes] [IP Packets] 1 40 120 3 Short ACK train 2 40 240 6 Typical ACK train 3 40 1200 30 Large ACK train 4 1476 29520 20 Web object flight (WOF) 5 80 Infinite Infinite VoIP A VoIP case with compressed header IPLEN = 44 bytes was also simulated A VoIP packet is 4 voice samples a 10 ms (10 bytes) in one burst Page 12

Emulate GSE Protocol (I) Bursts Total Overhead [Bytes] Overhead [%] 20 10 Bursts IPLEN=40 KBYTE:60 TRAINLEN: Poisson(3) 0 0 2 4 6 8 10 12 14 16 18 TRAINLEN [IP Packets] 400 200 Padding Encapsulation 0 0 2 4 6 8 10 12 14 16 18 TRAINLEN [IP Packets] 60 40 20 0 Padding 0 Encapsulation 2 4 6 8 10 12 14 16 18 Total overhead TRAINLEN [IP Packets] Protocol emulation program: Emulate GSE protocol by encapsulating IP packets. Input: - IP packet length - - IP packet train length - Burst length (KBYTE) For each TRAINLEN calculate - Number of bursts, - Overhead - Padding Average by assuming Poisson distribution of TRAINLEN => Input to burst length optimisation Page 13

Traffic Distribution Packet size distribution uplink 5.00E-01 4.00E-01 Propabillity 3.00E-01 2.00E-01 1.00E-01 From traffic measurements a nominal traffic distribution model was made: 0.00E+00 0 200 400 600 800 1000 1200 1400 1600-1.00E-01 Packet size Case Description Traffic Distribution Packets [%] Traffic Distribution Bytes [%] 1 Short ACK train 12.5 1.8 2 Typical ACK train 20 2.9 3 Large ACK train 2.5 0.4 4 Web Object Flight (WOF) 15 80.4 5 VoIP Case 50 14.5 The measurement did not include VoIP, but this is interesting for DVB-RCS so a relatively large amount of VoIP was assumed for the nominal case. Page 14

Traffic Distribution Scenarios Different traffic scenarios investigated Packets density Bytes density Description Nominal Case ACK Centric WOF Centric VoIP Centric VoIP Centric Header Compression PD BD PD BD PD BD PD BD PD BD Short ACK train 12.5 1.8% 40% 13% 12% 0.7% 2% 0.7% 2% 0.9% % Typ. ACK train 20 2.9% 25% 6% 20% 1.1% 4% 1.3% 4% 1.9% Large ACK train 2.5 0.4% 5% 2% 2.5% 0.1% 1% 0.3% 1% 0.5% Web object flight 15% 80% 5% 59% 50% 97% 3% 37% 3% 51% VoIP Case 50% 14.5% 30% 19% 15% 1.6% 90% 60% 90% 47% Spectral Eff. N opt 730 670 1370 730 450 Page 15

Jitter Requirements VoIP assumptions - G729A Codec assumed - 1 Voice sample 10 bytes (10 ms of voice) - N voice samples are packet into one voice block, N=4 used in analysis giving a voice block of: - 80 bytes with full headers (IP, RTP) - 44 bytes with header compression - Maximum two (40 ms) voice blocks in one physical burst - Jitter should be within 10-30 ms - Jitter is reduced by play-out delay buffer Page 16

Modem Performance (I) Modem assumptions based on simulation results Overhead required (depending on modulation, code rate and block length) Modem performance (depending on modulation, code rate and block length) HPA loss included (depending on modulation) Burst length optimisation performed on the baseline demodulator performance, but including that anticipated improvement was possible. The performance was checked with the optimised demodulator algorithms. Page 17

Modem Performance (II) Overhead (UW Length and Pilot Period) BLOCK LENGTH 408 816 1504 3008 [Information bits] N UW Lp N UW Lp N UW Lp N UW Lp QPSK r = 1/3 48 20 48 20 48 20 48 20 r = 1/2 48 50 48 50 32 100 32 100 r = 3/4 32 50 32 100 24 100 24 100 r = 6/7 16 100 16 100 16 100 16 100 8PSK 16 10 16 10 16 10 16 10 16APSK 16 8 16 8 16 8 16 8 Modem Loss BLOCK LENGTH 408 816 1504 3008 [Information bits] QPSK r = 1/3 0.38 0.25 0.25 0.25 r = 1/2 0.34 0.34 0.32 0.32 r = 6/7 0.25 0.35 0.16 0.16 8PSK r = 2/3 1.0 0.65 0.4 0.4 r = 6/7 1.6 0.75 0.70 0.60 16APSK r = 2/3 0.6 0.6 0.35 0.25 HPA Loss Modulation HPA Loss [db] QPSK 0.2 8PSK 0.4 16APSK 0.5 Page 18

MODCOD Distribution Probability 0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0 1 2 3 4 5 6 7 8 9 10 11 12 MODCOD Number QPSK 8PSK MOD COD Modulation FEC Rate 1 QPSK 1/3 2 QPSK 1/2 3 QPSK 2/3 4 QPSK 3/4 5 QPSK 5/6 6 QPSK 6/7 7 8PSK 2/3 8 8PSK 3/4 9 8PSK 5/6 10 8PSK 6/7 11 16APSK 2/3 12 16APSK 3/4 MODCOD distribution based on system simulations from ACM Modem Phase 1 MODCOD distribution approximately same for both consumers (512 ks/s) and SME (2 Mbps) since larger antenna for SME. Page 19

Figure of Merit Spectral Efficiency η IP = KIP/BURSTLEN. The number of IP bits pr transmitted symbol, including all overhead K IP number of IP bits in burst, BURSTLEN is burst length Power Efficiency Eb IP /N 0 = E s /N 0-10*log 10 10(η IP ). The actual energy used to transmit each IP bit. E s /N0 is the energy used to transmit one channel symbol. A reduction of protocol or burst format overhead can be used both to improve either spectral or power efficiency or both Page 20

Methodology for Burst Length Optimisation For all MODCODs m { For all burst lengths BLEN { Find physical layer overhead (PHYOH) for a given MODCOD and BLEN Find symbols available for information data Ks = BLEN - PHYOH Find required E s /N 0 in order to demodulate the burst for a certain PER. Find bytes available for encapsulated IP data KBYTE= Ks*M*r/8 Emulate GSE protocol for each traffic scenario (assume Poisson distribution of TRAINLEN, except for VoIP) and determine the average overhead and padding. Find the power efficiency Eb IP /N 0 (BLEN,m) and spectral efficiency ηip(blen,m) for the given burst length and MODCOD.}} Average for all MODCODs Average for all Traffic Cases Final sensitivity analysis Page 21

QPSK Spectral Efficiency Power Efficiency Average # of IP bits/symbol 2 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 QPSK Spectral Efficiency (Average all FEC rates) Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP Average Required Eb/No pr IP bit 15 10 5 QPSK Power Efficiency (Average all FEC rates) Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP 0.2 0 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Burst Length [Symbols] 0 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Burst Length [Symbols] The spectral and power is averaged for all FEC code rates (uniform distribution) - For Short/Typical Ack train short bursts is optimum (2-400 symbols) - For WOF a long burst is optimum (> 2000 symbols) - Long bursts have better FEC/modem performance. This is not modelled in the spectral Efficiency figure of merit. Taken into account in the power efficiency figures. Page 22

Encapsulation and Padding Loss (QPSK) 60 50 40 QPSK Encapsulation Loss Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP 100 90 80 70 60 QPSK Padding Loss Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP [%] 30 [%] 50 40 20 30 10 20 10 0 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Burst Length [Symbols] 0 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Burst Length [Symbols] Plots showing details of encapsulation and padding loss. Actual overhead depends on how well an IP packet fit a container size - A 40 bytes IP packet fits exactly a 40 bytes container size giving no padding overhead, but very badly to a 39 bytes container. This effect gives very rugged curves (actually even more rugged than plot shows) Traffic is modelled as train of IP packets so this reduces variations. Page 23

8PSK Spectral Efficiency Power Efficiency Average # of IP bits/symbol 3 2.5 2 1.5 1 0.5 8PSK Spectral Efficiency (Average all FEC rates) Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP 0 0 500 1000 1500 Burst Length [Symbols] Average Required Eb/No pr IP bit 15 10 5 8PSK Power Efficiency (Average all FEC rates) Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP 0 0 500 1000 1500 Burst Length [Symbols] Averaged over all 8PSK FEC rates Same as for QPSK, but now a burst contains more data and compared to QPSK shorter bursts will be optimum Page 24

16APSK Spectral Efficiency Power Efficiency 3 16APSK Spectral Efficiency 15 16APSK Power Efficiency (Average all FEC rates) Average # of IP bits/symbol (Average all FEC rates) 2.5 2 1.5 1 Case 1: Short Ack Case 2: Typical Ack 0.5 Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP 0 0 100 200 300 400 500 600 700 800 900 1000 Burst Length [Symbols] Average Required Eb/No pr IP bit 10 5 Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP 0 0 100 200 300 400 500 600 700 800 900 1000 Burst Length [Symbols] Averaged over all 16APSK FEC rates Even shorter bursts is optimum Page 25

MODCOD Distribution Spectral Efficiency Power Efficiency Average # of IP bits/symbol 3 2.5 2 1.5 1 0.5 Spectral Efficiency (MODCOD Averaging) Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP Average all cases Average Required Eb/No pr IP bit 15 14 13 12 11 10 9 8 7 Power Efficiency (MODCOD Averaging) Case 1: Short Ack Case 2: Typical Ack Case 3: Long Ack Case 4: Web Oject Flight Case 5: VoIP Average all cases 6 0 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Burst Length [Symbols] 5 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Burst Length [Symbols] The burst length optimisation was based on the chosen MODCOD distribution Optimum single burst length: Spectral efficiency: 730 symbols Power efficiency: 890 symbols Page 26

Multiple Burst Lengths (I) Frequency Burst using 2 basic slots 1024 ks/s Slot 11 1 ms Slot 12 1 ms Slot 13 1 ms Slot 14 1 ms Slot 15 1 ms Slot 16 1 ms Slot 17 1 m Slot 18 1 ms 512 ks/s Slot 7-2 ms Slot 8-2 ms Slot 9-2 ms Slot 10-2 ms 512 ks/s 256 ks/s Slot 3-2 ms Slot 1-4 ms Slot 4-2 ms Slot 5-2 ms Slot 2-4 ms Slot 6-2 ms Time Superframe duration is a multiple of 4 ms Assume that a burst is either 1 or 2 basic slots - As assumed in RRM project (ARTES-1) General solution: A burst can use 1 or N basic slots (N fixed, i.e. still only two burst types) Page 27

Multiple Burst Lengths (II) Spectral Efficiency Power Efficiency N1 opt,n2 opt [symbols] η IP [bits/symbol] N1 opt,n2 opt [symbols] E bip /N 0 [db] Single Burst Length 730 1.71 890 7.15 Two Burst Lengths (690,1380) 1.74 (810,1620) 6.71 N2=2*N1 Two Burst Lengths (730,2190) 1.75 (730,2190) 6.66 N2=3*N1 Two Burst Lengths N2=4*N1 (570,22809 1.75 (730,2920) 6.65 -The two burst length solution was not found to be significantly better than a single burst length for the nominal traffic scenario. - However, what happens for different traffic scenarios. Page 28

Traffic Distribution Sensitivity: Single Burst Length [IPbit/symbol] 0.4 0.3 0.2 0.1 Nominal ACK Centric WOF Centric VoIP Centric Spectral Efficiency Loss Eb/No IP [db] 0 400 500 600 700 800 900 1000 2 1.5 1 0.5 Power Efficiency Loss Y-axis is delta change from optimum. 0 400 500 600 700 800 900 1000 Short Burst Length [symbols] A single burst length of 700-900 symbols would be in-efficient for VoIP, not ideal for WOF Page 29

Traffic Distribution Sensitivity: Double Burst Length [IPbit/symbol] 0.2 0.15 0.1 0.05 Nominal ACK Centric WOF Centric VoIP Centric Spectral Efficiency Loss 0 400 450 500 550 600 650 700 0.8 Power Efficiency Loss Eb/No IP [db] 0.6 0.4 0.2 0 400 450 500 550 600 650 700 Short Burst Length [symbols] N2 = 3*N1 is most robust solution for all traffic scenarios N1=540 is optimum with respect to power efficiency Page 30

Further Sensitivity Analysis Other IP packet lengths (ACK, Web Objects Flight, VoIP with or without header compression) 40 or 52 byte ACK has little impact on optimum burst length 1476 or 1500 bytes IP packet length has little impact 80 or 44 byte VoIP has some impact (not dramatic) Traffic Distribution - Web browsing - ACK Centric - VoIP - VoIP Centric - File/Object transfers WOF Centric - Solution chosen to be robust against traffic distribution, see previous slide for results Link budget assumptions/ MODCOD distribution Lower C/(N+I); More coding and robust modulation => Longer optimum burst length High C/(N+I); Less coding and less robust modulation => Shorter optimum burst lengths Test +/- 3dB change in link budget 3% loss in spectral efficiency 0.1 db loss in power efficiency Modem performance - Better overall performance with improved algorithms - Same optimum burst lengths Conclusion: Chosen solution is robust against parameter changes Page 31

FIL and FBL Comparison Spectral Efficiency 1-ATM MPEG GSE Protocol Traffic Cases K = 424 bits K=1504 bits N 1 =540, N 2 =1620 symbols Nominal 1.55 1.77 1.83 ACK Centric 1.50 1.60 1.67 WOF Centric 1.60 1.84 1.89 VoIP Centric w/header compression 1.20 (1.48) 1.40 1.61 Power Efficiency 1-ATM MPEG GSE Protocol Traffic Cases K = 424 bits K=1504 bits N 1 =540, N 2 =1620 symbols Nominal 9.23 6.98 6.56 ACK Centric 9.40 7.75 7.41 WOF Centric 9.11 6.74 6.14 VoIP Centric w/header compression 11.00 (9.33) 8.48 7.59 Page 32 18% gain wrt ATM 14% gain wrt MPEG 33% gain wrt ATM The power efficiency gain is due to the utilization of the long burst size in particular for long IP packets

Comparison against DVB-RCS For DVB-RCS either 1-ATM (53 bytes) or 1-MPEG (188 bytes) burst containers Demodulator loss is: - 0.3 db for ATM (a bit optimistic using conventional algorithms) - 0.25 MPEG Figure of Merit Spectral Efficiency [IP bits/symbol] Encapsulation ATM MPEG GSE-FBL Nominal 1.32 1.50 1.83 ACK Centric 1.28 1.35 1.67 WOF Centric 1.36 1.56 1.89 VoIP Centric w/header Compression 1.02 (1.27 * ) 1.18 1.61 Improvement: 38 % gain wrt ATM 22 % gain wrt MPEG *) 57 byte ATM container size Also power efficiency gain can be achieved Page 33

GSE Protocol Assumption Comparison of GSE protocol versions: Modified (CRC pr. IP packet) Original (CRC pr. burst) Nominal Traffic Scenario: Small advantage of modified version (up to 1%) VoIP Scenario (using header compression) Small advantage of original protocol (up to 1%) Conclusion: Not justified to modify the GSE protocol for RL and should use the standard GSE protocol used for FL. Page 34

Burst Format Definitions MOD COD r Modulation Information length [Bits / Bytes] IP length [symbols] UW Length [symbols] Pilots NP (PP) [symbols] E s /N 0 [db] η IP [bit/ symbols] E bip /N 0 [db] S1 QPSK 1/3 312/39 462 48 26 (20) 1.0 0.58 3.38 S2 QPSK 1/2 480/60 478 48 10 (50) 3.1 0.89 3.66 S3 QPSK 2/3 656/82 493 32 11 (50) 5.1 1.21 4.25 S4 QPSK 3/4 736/92 493 32 11 (50) 6.2 1.36 4.88 S5 QPSK 5/6 848/106 510 20 6 (100) 7.7 1.57 5.69 S6 QPSK 6/7 880/110 514 16 6 (100) 8.1 1.63 6.02 S7 8PSK 2/3 928/116 462 16 58 (10) 9.2 1.72 6.80 S8 8PSK 3/4 1040/130 462 16 58 (10) 10.8 1.93 7.94 S9 8PSK 5/6 1152/144 462 16 58 (10) 12.6 2.13 9.26 S10 8PSK 6/7 1192/149 462 16 58 (10) 13.5 2.21 10.08 S11 16APSK 2/3 1184/148 445 16 75 (8) 11.3 2.19 7.87 S12 16APSK 3/4 1336/167 445 16 75 (8) 12.7 2.47 8.79 L1 QPSK 1/3 992/124 1485 48 83 (20) 0.2 0.61 2.33 L2 QPSK 1/2 1568/196 1568 32 16 (100) 2.2 0.97 2.38 L3 QPSK 2/3 2096/262 1571 24 17 (100) 4.3 1.29 3.20 L4 QPSK 3/4 2360/295 1575 24 17 (100) 5.3 1.46 3.68 L5 QPSK 5/6 2632/329 1579 20 17 (100) 6.6 1.62 4.46 L6 QPSK 6/7 2712/339 1583 16 17 (100) 7.0 1.67 4.80 L7 8PSK 2/3 2848/356 1422 16 178 (10) 8.2 1.76 5.71 L8 8PSK 3/4 3200/400 1422 16 178 (10) 9.7 1.98 6.72 L9 8PSK 5/6 3552/444 1422 16 178 (10) 11.4 2.19 7.99 L10 8PSK 6/7 3656/457 1422 16 178 (10) 12.2 2.26 8.71 L11 16APSK 2/3 3656/457 1371 16 229 (8) 10.6 2.26 7.04 L12 16APSK 3/4 4112/514 1371 16 229 (8) 12.1 2.54 8.02 Page 35

Signalling Issues (I) No explicit signalling of burst type is necessary - If a terminal gets allocated M=3*N+K consecutive slots it must transmit N long burst and then K short bursts, K=0,1 or 2. - Might increase jitter to mix short and long burst, but DAMA controller should ensure that terminal gets allocated capacity with fixed distance for jitter sensitive services - Association of traffic with burst types - Can be based on VBDC. DAMA controller should allocate long bursts as much as possible to maximise efficiency - For RBDC below certain level should use short bursts to minimise jitter Page 36

Signalling Issues (II) Update of TCT and TPTB tables proposed (similar to what has been proposed in the ESA RRM project) TCT Table - New Timeslot (FBL) - Split UW and pilots must be signalled TPTB Table - MODCOD long burst - MODCOD short burst Assuming MODCOD pre-defined in new standard, otherwise TCT table must be used to signal MODCOD definitions Page 37

Conclusion (I) A frame/burst format suitable for utilization of ACM over the return link of future interactive systems has been proposed Fixed burst length gives significantly simplified and improved RRM efficiency GSE protocol assumed for mapping IP packets over variable information length bursts No modification of GSE protocol necessary New FEC scheme improves demodulator performance New burst format simplifies and enhances burst synchronisation Page 38

Conclusion (II) A detailed cross-layer optimization has been carried out for devising burst formats: Different applications and traffic models considered MODCOD distributions assumed as from system simulation results Sensitivity analysis for assessing robustness of the devised solution 2 (Short and long) burst lengths selected to improve efficiency against different applications and traffic distributions Simulation results have shown an efficiency gain of 10% up to 35% with respect to AAL5/ATM and 3% up to 15% with respect to MPE/MPEG assuming the same physical layer performances 40% up to 60% with respect to AAL5/ATM and 20% up to 30% with respect to MPE/MPEG when the current DVB-RCS standard is assumed as the benchmark Minor changes to TCT and TBTP tables required Page 39