A flexible QoS architecture for DVB‐RCS2

Fairhurst, Gorry; Secchi, Raffaello; Yun, Ana

doi:10.1002/sat.1026

Cited by 5 publications

(6 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Where possible, packets should be buffered in the IP layer using Active Queue Management (AQM) methods [149] ( § IV-F6). This can require a redesign of the architecture to enable coordination between protocol entities, avoiding the pitfalls of direct implementation of a large number of independent layers and construction of individually buffered "pipes/streams" across the lower layers [135,143,150,151]. In the Linux kernel since Aug 2011, Byte Queue Limits (BQL) has significantly reduced delay within network interface hardware, but without radically altering inter-layer co-ordination [152].…”

Section: F Queuing Delaymentioning

confidence: 99%

Reducing Internet Latency: A Survey of Techniques and Their Merits

Briscoe

Brunström

Petlund

et al. 2016

IEEE Commun. Surv. Tutorials

Self Cite

151

View full text Add to dashboard Cite

Latency is increasingly becoming a performance bottleneck for Internet Protocol (IP) networks, but historically networks have been designed with aims of maximizing throughput and utilization. This article offers a broad survey of techniques aimed at tackling latency in the literature up to August 2014, and their merits. A goal of this work is to be able to quantify and compare the merits of the different Internet latency reducing techniques, contrasting their gains in delay reduction versus the pain required to implement and deploy them. We found that classifying techniques according to the sources of delay they alleviate provided the best insight into the following issues: 1) the structural arrangement of a network, such as placement of servers and suboptimal routes, can contribute significantly to latency; 2) each interaction between communicating endpoints adds a Round Trip Time (RTT) to latency, especially significant for short flows; 3) in addition to base propagation delay, several sources of delay accumulate along transmission paths, today intermittently dominated by queuing delays; 4) it takes time to sense and use available capacity, with overuse inflicting latency on other flows sharing the capacity; and 5) within end systems delay sources include operating system buffering, head-of-line blocking, and hardware interaction. No single source of delay dominates in all cases, and many of these sources are spasmodic and highly variable. Solutions addressing these sources often both reduce the overall latency and make it more predictable.

show abstract

Section: F Queuing Delaymentioning

confidence: 99%

Reducing Internet Latency: A Survey of Techniques and Their Merits

Briscoe

Brunström

Petlund

et al. 2016

IEEE Commun. Surv. Tutorials

Self Cite

151

View full text Add to dashboard Cite

show abstract

“…Because the throughput is sensible to channel quality (because of FMT), the lack of information can lead to overflows. Several QoS architectures have been proposed, such as differentiated services IP QoS [21] or Metropolitan Ethernet QoS [22], or specific to the satellite return channel [23,24].…”

Section: Control Plane Qosmentioning

confidence: 99%

Software‐defined satellite cloud RAN

Ahmed

Dubois

Dupé

et al. 2017

Satell Commun Network

View full text Add to dashboard Cite

SUMMARYThis paper provides an assessment study on the virtualization of a Digital Video Broadcasting -Satellite -Second Generation (DVB-S2)/ Digital Video Broadcasting -Return Channel Satellite -Second Generation (DVB-RCS2) satellite ground infrastructure and proposes a framework, named Satellite Cloud Radio Access Network (SatCloudRAN), that aims to ease the integration of satellite components in forthcoming 5G systems. Special attention is given to the design of SatCloudRAN by considering the split and placement of virtualized and nonvirtualized functions while taking into account the characteristics of the transport links connecting both type of functions. We assess how virtualization and softwarization technologies, namely, network function virtualization and softwaredefined networking, can deliver part of the satellite gateway functionalities as virtual network functions and achieve a flexible and programmable control and management of satellite infrastructure. Under the network function virtualization paradigm, building virtual network function blocks that compose a satellite gateway have been identified, and their interaction exhibited. This paper also gives insights on how the SatCloudRAN approach can allow operators to provide software-defined networking-based (1) bandwidth on demand, (2) dynamic Quality of Service, and (3) satellite gateway diversity.

show abstract

“…To this end, the specification of the lower layers, including physical and datalink, as well as higher layers is provided. In this respect, particular attention can be dedicated to some of the novel functions that are introduced in there: random access to the return link, security [13], Adaptive Coding and Modulation and DRA [14], the concept of Satellite Virtual Network (SVN), the specification of the Return Link Encapsulation [6] as well as the refinement of the QoS management to perform flow identification at the lower layers [15].…”

Section: Dvb-rcs2mentioning

confidence: 99%

Evolution of satellite communications: Integration of ETSI BSM and DVB-RCS for future satellite terminals

Cola

Marchese

Mongelli

2015

Int. J. Satell. Commun. Network.

View full text Add to dashboard Cite

The main added value of the European Telecommunications Standards Institute broadband satellite multimedia (ETSI BSM) architecture is the definition of the Satellite Independent-Service Access Point (SI-SAP) protocol interface, which formally separates Satellite Dependent (SD) from SI layers, thus enabling the implementation of powerful vertical QoS mapping strategies. On the other hand, DVB-S2/RCS satellite standard is considered the driving technology to integrate satellite with terrestrial infrastructure and provide up-to-date services. This paper focuses on the integration of ETSI BSM architecture and DVB-RCS technology, by analysing the adaptations needed on real DVB-RCS terminals to be interoperable with the SI-SAP interface. To this end, the detailed design of an underlying architecture taking into account required adaptations and new functionalities is proposed. The possible further evolutions of the BSM specification are also highlighted, showing the potential for the development of future devices integrating both DVB-RCS and ETSI BSM architectures also in view of the recent upgrade to the DVB-RCS2 standard. The paper also validates the SI-SAP QoS functionalities and proves the performance benefits in terms of QoS and quality of experience of Web-browsing by means of a satellite emulator developed fors this aim. also thanks to the deployment of Adaptive Coding and Modulation available in the second version of the standard. DVB-S and DVB-S2 standards were initially conceived to support video broadcast over satellite, but actually, they can support more general broadcast and broadband transport so as to meet the current service users' demands.As far as the return channel air interface is concerned, the second version of the DVB-RCS standard, defined as DVB-RCS2 [4], has recently appeared. It must be noticed that DVB-RCS(2), unlike DVB-S2, has been designed for data rates lower than those offered on the forward link, because traditionally, return links have been conceived to transport a limited amount of traffic (e.g. satellite signalling) rather than broadband traffic. The new release (DVB-RCS2) actually extends the features already available in the DVB-RCS standard and also provides the specification of the higher layers of the protocol stack. The market penetration of DVB-RCS [5] is, however, still controversial, as terminals still implement proprietary solutions, thus possibly lacking interoperability. The introduction of DVB-RCS2 technology is expected to cope with this market fragmentation, owing to the definition of a standardised protocol interface (Return Link Encapsulation[6]) between network layer (e.g. IP) and DVB-RCS2 layer. Nevertheless, the overall DVB-RCS2 protocol stack still lacks modularity, whereby the upgrade of functions (e.g. cross-layer QoS management) involving IP and DVB-RCS2 layers cannot be easily implemented without significant changes in the protocol interfaces. A straightforward solution to these yet unsolved issues is to actually provide a hardware abstraction layer working o...

show abstract

A flexible QoS architecture for DVB‐RCS2

Cited by 5 publications

References 15 publications

Reducing Internet Latency: A Survey of Techniques and Their Merits

Reducing Internet Latency: A Survey of Techniques and Their Merits

Software‐defined satellite cloud RAN

Evolution of satellite communications: Integration of ETSI BSM and DVB-RCS for future satellite terminals

Contact Info

Product

Resources

About