ETSI TS 102 292 V1.2.1 (2015-07)

Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM) services and architectures; Functional architecture for IP interworking with BSM networks

RTS/SES-00372

General Information

• Status: Published
• Publication Date: 30-Jul-2015
• Technical Committee: SES SCN - Satellite Communications and Navigation
• Current Stage: 12 - Completion
• Due Date: 21-Jul-2015
• Completion Date: 31-Jul-2015

Standards Content (Sample)

ETSI TS 102 292 V1.2.1 (2015-07)






TECHNICAL SPECIFICATION
Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM)
services and architectures;
Functional architecture for IP interworking
with BSM networks

---------------------- Page: 1 ----------------------
2 ETSI TS 102 292 V1.2.1 (2015-07)



Reference
RTS/SES-00372
Keywords
architecture, broadband, interworking, IP,
satellite, terminal
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TS 102 292 V1.2.1 (2015-07)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Architectural framework . 9
4.1 Principles . 9
4.2 Basic concepts . 9
5 Overview . 10
6 SI-SAP architecture . 13
7 Network architecture . 14
7.1 BSM network architecture . 14
7.2 BSM network interfaces . 16
8 Logical architecture . 17
8.1 Client server networking . 17
8.2 Decomposition . 18
8.3 Logical interfaces . 19
9 Scenarios . 19
9.1 Summary . 19
9.2 Network engineering functions . 20
9.3 Packet processing . 21
9.3.0 General . 21
9.3.1 Ingress processing . 22
9.3.2 Egress processing . 22
History . 24


ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 102 292 V1.2.1 (2015-07)
List of figures
Figure 1: BSM protocol stack for unicast services .11
Figure 2: BSM protocol stack for multicast services .12
Figure 3: SI-SAP detailed overview .14
Figure 4: Star configuration access network .15
Figure 5: Meshed configuration .15
Figure 6: Reference model of BSM access from ETSI TR 101 984 [i.5] .16
Figure 7: Logical decomposition .18
Figure 8: Protocol interfaces .19

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 102 292 V1.2.1 (2015-07)
List of tables
Table 1: Interfaces for BSM access .17
Table 2: Summary of BSM packet processing .20
Table 3: BSM protocols and network engineering .21
Table 4: BSM protocols and packet processing .23

ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 102 292 V1.2.1 (2015-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Terrestrial Internet protocols, in particular for signalling, management and control, are often ill adapted to the specifics
of satellite networks (ETSI TR 101 984 [i.5]). It has been the goal of the BSM work to investigate which protocols
should be adapted to the BSM world and propose a number of specific technical specifications to achieve this goal. In
order to link all those documents under a common framework, the present document defines a BSM functional
architecture. The architecture is not satellite system specific and relies on client server architectures to perform the
needed tasks without interference with IP protocol operations.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 102 292 V1.2.1 (2015-07)
1 Scope
The present document presents the architecture that relates the work done in SES BSM TRs on standardization (see
ETSI TR 101 984 [i.5] and ETSI TR 101 985 [i.1], Addressing and Routing (see ETSI TR 102 155 [i.2]), Multicasting
(see ETSI TR 102 156 [i.3]) and Performance and QoS (see ETSI TR 102 157 [i.4]). The present document provides the
introduction to the subsequent Technical Specifications (TSs). The focus of the BSM work is on IP version 4 (IPv4).
Actual protocol specification is beyond the scope of the present document and will be issued in specific Technical
Specifications (TSs).
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 295: "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM) services and architectures; BSM Traffic Classes".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 101 985: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP over Satellite".
[i.2] ETSI TR 102 155: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP interworking over satellite; Addressing and routing".
[i.3] ETSI TR 102 156: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP interworking over satellite; Multicasting".
[i.4] ETSI TR 102 157: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP Interworking over satellite; Performance, Availability and Quality of Service".
[i.5] ETSI TR 101 984: "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); Services and architectures".
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 102 292 V1.2.1 (2015-07)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
adaptation: process of adapting standard protocols for better performance over a satellite (or other) subnetwork
architecture: abstract representation of a communications system
function: any discrete element that forms a defined part of an architecture
scenario: predicted sequence of events
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
ARP Address Resolution Protocol
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
BSM Broadband Satellite Multimedia
BSM_ID BSM IDentifier
CSF Client Server Function
DSCP Differentiated Services Code Point
DVB-S Digital Video Broadcast-Satellite
HTTP Hyper Text Transfer Protocol
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IP Internet Protocol
IPv4/v6 Internet Protocol version 4/6
MAC Media Access Control
MPE Multi-Protocol Encapsulation
MPLS Multi Protocol Label Switching
NAT Network Address Translation
ND Neighbour Discovery
OBP On-Board Processing
OSI Open System Interconnection
PEP Performance Enhancing Proxy
PIM Protocol Independent Multicast
QID Queuing IDentifier
QoS Quality of Service
RSVP Resource reSerVation Protocol
SAP Service Access Point
SD Satellite Dependent
SDU Service Data Unit
SI Satellite Independent
SMAC Satellite Medium Access Control
SNPA Sub Network Point of Attachment
SPHY Satellite PHYsical
ST Satellite Terminal
TCP Transmission Control Protocol
UDP User Datagram Protocol
VLAN Virtual Local Access Network
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 102 292 V1.2.1 (2015-07)
4 Architectural framework
4.1 Principles
The BSM architectural framework is based on the principle that the recommended Technical Specifications should be
linked by a common thread. Obviously all BSM protocols can be classified in the OSI layered model: the protocols the
BSM uses to transport IP traffic mostly belong to the layers 2, 3 and above as they deal with MAC layer adaptation to
support IP services and address resolution, network protocols such as routing, and finally policy control and
management protocols for quality of service and resource management ETSI TR 101 985 [i.1]. It has been a
recommendation of the IP interworking over satellite ETSI TR 102 155 [i.2], ETSI TR 102 156 [i.3] and ETSI
TR 102 157 [i.4] that the "adaptation" of the IP protocol at the ingress and egress of the BSM be located in a "Protocol
Manager". This entity is mainly a control path entity that intercepts the appropriate IP protocols and ensures that they
are correctly supported over the BSM.
In the BSM protocol stack, the "manager" resides mostly above the SAP. Its major functions include:
• How IP protocols and packet markings are to be interpreted and transmitted through the BSM.
• Which Satellite Independent (SI) protocols are used.
• And how they in turn trigger the Satellite Dependent (SD) functions.
4.2 Basic concepts
In addition to the definitions provided in clause 3.1 some concepts that are basic the BSM architecture are further
explained below:
• Adaptation: as defined in clause 3.1, adaptation refers to the process of adapting standard protocols for better
performance over, in the present document, a BSM satellite subnetwork. Adaptation, which should be
transparent to the general Internet, involves, for example, changing timers, filtering traffic and reducing the
transmission of messages over the satellite link to the protocol servers.
• Architecture: the architecture is an abstract representation of a communications system. Three
complementary types of architecture are defined:
- Protocol architecture: the protocol stacks involved in the operation of the system and the associated
peering relationships.
- Functional architecture: the discrete functional elements of the system and the associated logical
interfaces.
- Network architecture: the discrete physical (network) elements of the system and the associated
physical interfaces.
• Scenario: in the present document a scenario will describe a realistic worked example, showing how a defined
set of functions operate and apply to a specific IP interworking situation (or situations). Scenarios demonstrate
both "why" a given set of functional specifications is needed and "how" the proposed functional
decomposition works to provide the desired result. In general, a scenario will be described by reference to one
or more architectures.
• Function: a function converts a set of inputs into a set of outputs. A function is formally defined by the sets of
inputs and of outputs. The set of inputs can be a continuum (e.g. an analog signal) or discrete (e.g. a digital
signal). It might be that some inputs produce no output e.g. silent discard in address resolution. Inputs and
outputs can be assembled in blocks or vectors (datagrams, packets, frames, etc.). This is the most basic
definition and it proves to be sufficient in some cases (black box diagram). At the opposite, a function is
ultimately defined when it is possible to derive an output from any input. Between these two ends, all
intermediate definitions are possible. In the BSM, a function can use any combination of the following:
- a protocol element (e.g. a complete stack or an single protocol entity);
- a logical element (e.g. a process or procedure); and
- a physical element (e.g. a router or server).
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 102 292 V1.2.1 (2015-07)
• Network engineering:
1) In telephony, the discipline concerned with determining internetworking service requirements for
switched networks, and developing and implementing hardware and software to meet them. In addition,
network engineering includes the end-to-end provisioning of network resources to meet service needs.
2) In computer science, the discipline of hardware and software engineering to accomplish the design goals
of a computer network.
3) In radio communications, the discipline concerned with developing network topologies. Because the
BSM is concerned with all three functions all of those definitions apply.
• Traffic engineering: the determination of the numbers and kinds of circuits and quantities of related
terminating and switching equipment required to meet anticipated traffic loads throughout a communications
system. Traffic engineering also targets the reduction and suitable distribution of loads across the network.
5 Overview
Figure 1 presents the BSM protocol stack for unicast services and figure 2 the same stack with the added multicast
protocols. An important feature of both figures is the Satellite Independent Service Access Point interface or SI-SAP
interface. This interface provides the BSM with a layer of abstraction for the lower layer functions and makes use of a
BSM specific identifier, the BSM_ID (BSM_Identity), to address BSM points of attachment. It allows the BSM
protocols developed in the Satellite Independent layer to perform over any BSM family. Moreover, the SI-SAP also
enables the use of standard Internet protocols for example address resolution or multicast group management, directly
over the BSM or with minimal adaptation to BSM physical characteristics. Finally the SI-SAP even makes it possible to
envisage switching from one satellite system to another and to even a non-satellite technology while preserving the
BSM operator's investment in layer 3 software development.
Figure 1 shows that there are only a small number of generic functions that need to cross the SI-SAP and those are
related to connection/session management, resource management or security. As seen in figures 1 and 2, the BSM
protocols are based on the OSI layered protocol stack. For the IP services most of the work has concentrated on the
network layers with links to the underlying data link and MAC layers. The reason for this is simple: the developed
protocols for IP over BSM should primarily be located in the satellite independent part of the BSM stack to be
applicable to a range of different satellite dependent lower layers such as for example, DVB-S and DVB-RCS.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 102 292 V1.2.1 (2015-07)
IPv4 and IPv6
IP Routing
IP QoS Management IP Security
IP Route Determination
BSM BSM BSM
BSM BSM QoS BSM QoS
Routing Traffic Security
Address
Address Resolution Adaptation Mgmt
Adaptation Manager Mgmt
Table
SIAF
IP Packet Forwarding
SI-C-SAP
SI-U-SAP SI-M-SAP
Segmentation BSM SD
BSM
/ Queue
Address Resolution
encapsulation Manager
SDAF
BSM BSM
Resource Security
Satellite Data Unit Switching
Mgmt Mgmt
Satellite Link Control (SLC)
Satellite Medium Access Control (SMAC)
Satellite Physical (SPHY)

Figure 1: BSM protocol stack for unicast services
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 102 292 V1.2.1 (2015-07)
IPv4 and IPv6
IP Mcast
IP Multicast Routing
Security
BSM Multicast SI
BSM Multicast BSM Multicast Group
Routing Mcast
Address
Address Resolution Management
Adaptation Security
Table
SIAF
IP Packet Forwarding
SI-U-SAP SI-C-SAP SI-M-SAP
Segmentation
SD Multicast
BSM Multicast
/
Functions
Address Resolution
encapsulation
SDAF
BSM SD
Resource Security
Satellite Data Unit Switching
Mgmt Mgmt
Satellite Link Control (SLC)
Satellite Medium Access Control (SMAC)
Satellite Physical (SPHY)

Figure 2: BSM protocol stack for multicast services
The major identified requirements for the BSM specific protocols at the satellite independent layer (above the SI-SAP)
are:
• No BSM protocol should bring any changes to Internet protocols.
• And when specific BSM functions are required they should be done via proxies or managers.
As mentioned in clause 4, the recommendations the IP over BSM Technical Reports (see ETSI TR 102 155 [i.2],
ETSI TR 102 156 [i.3] and ETSI TR 102 157 [i.4]) have proposed a number of specifications that are essential for the
BSM to adequately handle current and future IP traffic. The specifications under development are identified within the
OSI stack in figures 1 and 2. They cover advances in multicast, address resolution and routing/forwarding as well as
resource management. The relationship between these functions is highlighted in clause 6.
ETSI

---------------------- Page: 12 ----------------------
13 ETSI TS 102 292 V1.2.1 (2015-07)
6 SI-SAP architecture
The SI-SAP (Service - Access Point) provides an abstract interface allowing BSM protocols to be truly System
Independent (SI) and to apply to all BSM families. The SI-SAP is the interface at which services from the lower layers
are translated into system independent semantics.
For traffic handling the SI-SAP uses a BSM_Identity (BSM_ID) and a Queue Identifier (QID):
• The BSM_ID uniquely identifies a BSM subnetwork point of attachment (SNPA) and allows IP layer address
resolution protocols (equivalent to ARP for IPv4 and ND for IPv6) to be used over the BSM. The details of the
BSM_ID in term of format and its usage will be specified in the TS on Address Resolution.
• The QID enables the BSM data transfer (IP packets) to be queued, policed and transmitted properly across the
BSM network.
The traffic classes are central to the concept of the Queue Identifier (QID). Traffic classes available at the SI-SAP
enable QoS, performance management and resource allocation. They are defined in details in ETSI TS 102 295 [1]. The
BSM queues can be defined by QoS specific parameters (flowspecs, path labels or DiffServ markings) and associated to
lower layer transfer capabilities (e.g. to different capacity request categories in the DVB-RCS model). Some QIDs
could be assigned permanently and others being dynamically created to satisfy as certain QoS. The QID however is not
limited to a capacity allocation class; it relates also to flow/behaviour with defined properties. This includes:
• buffer allocations for queueing;
• buffer management policies (e.g. RED / drop tail);
• priority in terms of transmission;
• capacity allocation class (as mentioned in the previous clause); and
• PID/channel ID mapping for segmentation/reassembly.
All of the BSM services such data transfer, address management, group advertisement etc. use SI-SAP primitives; these
primitives are used to define the exchanged information between the satellite independent upper layers and the satellite
dependent lower layers via the SI-SAP. The primitives are classified into functional groups within the User plane (U),
Control plane (C) and Management plane (M). Figure 3 presents a detailed overview of the SI-SAP data transfer
functions.
ETSI

---------------------- Page: 13 ----------------------
14 ETSI TS 102 292 V1.2.1 (2015-07)
IPv4 and V6
Satellite Independent
BSM SI
Access Functions BSM
BSM
QOS Adaptation
Traffic
SI
and Management
Manager
Management
BSM
Traffic
IP to
Address
Classes,
BSM_ID
Resolution
QID
IP Packet Forwarding
SI-SAP
SI-U-SAP SI-C-SAP SI-M-SAP
Satellite Dependant Access Functions
BSM BSM SD
BSM_ID Resource Management
Address
to lower layer
Resolution
address
BSM_ID,
QID=1
BSM
Queue 1
SD
Management
Queue 2 BSM SD
Queue Manager
Queue N
Segmentation/
encapsulation

Figure 3: SI-SAP detailed overview
7 Network architecture
7.1 BSM network architecture
This clause reviews the major network architectures used for BSM networking. It also identifies the major interfaces
that the BSM functional architecture will use. The network architectures are essential to define the specific client-server
functions that will enable IP services over the BSM. For each of the recommended specifications (TS) a specific
"manager" located in the appropriate server (in the appropriate domain) will be defined in relation with the appropriate
BSM network configuration. Hence, the client server architecture relates to the specific network architectures and BSM
hardware in the following way:
• protocol clients are located in all STs and in Gateways when appropriate; protocol clients should not be
located in attached networks;
• protocol servers are located/distributed in the network or even across a network and are not strictly associated
with gateways but with operators control and management networks; STs and/or Gateways communicate with
the servers that are managed by its operator;
• all STs can be connected to multiple local hosts and can act as gateways to another subnetwork; and
• in any of the defined configurations an OBP payload can be involved on the control path especially as regards
resource management.
ETSI

---------------------- Page: 14 ----------------------
15 ETSI TS 102 292 V1.2.1 (2015-07)
The BSM network architectures are:
•
...