deliverable d5.1: satellite resource manager – high level...

D5.1 Satellite Resource Manager – High Level Design Description

1

VIVALDI PROJECT

DOCUMENT WORKPACKAGE 5

Deliverable D5.1: Satellite Resource Manager – High Level Design

Description V1.0

Project full title: Advancing interactive Broadband satellite access by optimal

convergence of session based services over DVB-RCS

Proposal/Contract no.: FP6-2004-IST-4 027762

SIXTH FRAMEWORK PROGRAMME PRIORITY 2

IST-Information Society Technologies

D5.1 Satellite Resource Manager – High Level Design Description VIVALDI 027762

CONFIDENTIAL 2

Revision Record

Revision Page Description of Revision Date

0.1 All Document creation (first draft) 04.01.2008

1.0 All Final document 12.02.2008


CONFIDENTIAL 3

ACRONYMS AND ABBREVIATIONS


Full Description

ACE Admission Control Unit

AF Assured Forwarding

AH Authentication Header (ipsec)

AMP Air Mac Processor = Newtec’ engineering name for the Satellite Resource Allocator for the return capacity

API Application Programming Interface

ASCII American Standard Code for Information Interchange

ATA Analogue Telephone Adapter

ATM Asynchronous Transfer Mode

BE Best Effort

C++ Mid level (object oriented) programming language (ISO)

CAC Call Admission Control

CD Critical Data

CPE Customer Premises Equipment

CPU Central Processing Unit

DiffServ Differentiated Services

dPEP Distributed Performance Enhancing Proxy

DNS Domain Name System

DSCP DiffServ Code Point

DSL Digital Subscriber Line

DTLS Datagram Transport Layer Security; RFC 4347

DVB Digital Video Broadcasting

DVB-RCS DVB-Return Channel by Satellite

ETCP Enhanced TCP (TelliNet)

EF Expedited Forwarding

ESA European Space Agency

ESP Encrypted Security Payload (ipsec)

EU European Union

GEO Geostationary

GRE Generic Routing Encapsulation / IP tunnelling protocol


CONFIDENTIAL 4


Full Description

HTTP Hyper Text Transfer Protocol

HIT Header Information (IP/UDP) Tunnelling

ICE Interactive Establishment (STUN)

ICMP Internet Control Message Protocol; initially RFC 792

IETF Internet Engineering Task Force

INI Text based INI configuration file (de facto standard format)

IP Internet Protocol

IPC Inter Process Communication

ISDN Integrated Services Digital Network

ISP Internet Service Provider

IntServ End-to-End flow capacity reservation

LAN Local Area Network

OS Operating System

OSS Operations Support System

MAC Medium Access Control

MGCP Media Gateway Control Protocol

NAT Network Address Translation

PEP Performance Enhancing Proxy

PHB Per Hop Behaviour

PLR Packet Loss Rate

POP3 Post Office Protocol version 3

PSTN Public Switched Telephone Network

PSU Pushback Signalling Unit

PT Payload Type (RTP)

PVC Permanent Virtual Circuit

QoS Quality of Service

RC Request Class

RSVP Resource Reservation Protocol

RT Real Time

RTP Real Time Protocol

RTT Round Trip Time

SabLabs ESA SatLabs / Satellite Laboratories


CONFIDENTIAL 5


Full Description

SDP Session Description Protocol, RFC 2327

SIH Shape Information Headers

SIP Session Initiation Protocol

SSRC Synchronization Source Identifier (RTP)

SRTP Secure Real-Time Transport Protocol; RFC 3711

STUN Simple Traversal of UDP over NATs; RFC 3489

TCI Tag Control Identifier

TCP Transmission Control Protocol

TKK Helsinki University of Technology / VIVALDI project partner

TLS Transport Layer Security

TOS Type Of Service (IP header field)

UDP User Datagram Protocol

VLAN Virtual LAN

VoIP Voice over Internet Protocol

VPN Virtual Private Network

WP Work Package


CONFIDENTIAL 6

CONTENT

Acronyms and Abbreviations.............................................................................................. 3

Content................................................................................................................................ 6

1 Purpose of this Document ......................................................................................... 9

2 Applicable Documents ............................................................................................. 10

3 Document Organization ........................................................................................... 11 3.1 Conventions ................................................................................................. 12

4 High Level Meta Architecture defined in ViValdi & Satellite Resource Allocation . 13

5 Satellite Resource Allocator Top Level Design and SatLabs recommendations. .. 16 5.1 IP Layer QoS................................................................................................ 17 5.2 MAC layer QoS ............................................................................................ 18

5.2.1 DVB-RCS Request classes……………………………………………………. 18

6 Top Level Design of the Satellite Resource Allocator............................................. 20 6.1 Satellite recosurce Allocator (or AMP) Functionality overview ................... 20 6.2 Design of two core functionalities: Allocation Algorithm, Placement Algorithm.. .................................................................................................................... 22 6.3 Static architecture of the Satellite Resource Allocator (AMP)..................... 24

6.3.1 Component overview…………………………………………………………… 24 6.4 Component responsibility ............................................................................ 24

6.4.1 AMP startup script……………………………………………………………….24 6.4.2 amp process…………………………………………………………………….. 25 6.4.3 amp watchdog…………………………………………………………………... 25 6.4.4 apy process……………………………………………………………………… 25 6.4.5 apy watchdog…………………………………………………………………….25 6.4.6 httpd……………………………………………………………………………… 25 6.4.7 ntpd………………………………………………………………………………. 25 6.4.8 platform daemons………………………………………………………………. 25 6.4.9 Scheduler………………………………………………………………………... 25 6.4.10 ReturnLinkInputParser…………………………………………………………. 25 6.4.11 BurstContainer………………………………………………………………….. 26 6.4.12 BLA………………………………………………………………………………. 26 6.4.13 PME……………………………………………………………………………….27 6.4.14 Synchronisation Module……………………………………………………….. 27 6.4.15 ntpd………………………………………………………………………………. 27


CONFIDENTIAL 7

6.4.16 Local time………………………………………………………………………... 27 6.4.17 TimeServer……………………………………………………………………….27 6.4.18 Ntp………………………………………………………………………………... 27 6.4.19 HD…………………………………………………………………………………28 6.4.20 Management Interface…………………………………………………………. 28 6.4.21 Counters…………………………………………………………………………. 28 6.4.22 Watchdog………………………………………………………………………... 28 6.4.23 CLI………………………………………………………………………………... 28 6.4.24 collect_config.pl script………………………………………………………….. 28 6.4.25 VCI dispenser…………………………………………………………………… 28 6.4.26 CocoYami………………………………………………………………………...28 6.4.27 RMCP Parser…………………………………………………………………….28 6.4.28 Debug……………………………………………………………………………. 29 6.4.29 Output……………………………………………………………………………. 29 6.4.30 PMTwriter………………………………………………………………………... 29 6.4.31 TableMaker……………………………………………………………………… 29 6.4.32 TableSender…………………………………………………………………….. 30 6.4.33 SitManager………………………………………………………………………. 30 6.4.34 Scheduler………………………………………………………………………... 30 6.4.35 SlotPoolContainerActor………………………………………………………… 30

Appendix A Overview Of simultation Results.................................................................. 32


CONFIDENTIAL 8

LIST OF FIGURES

Figure 1: VIVALDI Meta Architecture ............................................................................... 13 Figure 2: Satellite Resource Allocator (Return Scheduler) and Interfaces...................... 15 Figure 3: mapping L3 QoS into L2 QoS; marking the different components & paths ..... 16 Figure 4: Aggregation of demand related to classification of traffic................................. 19 Figure 5: AMP in the 2 way satellite system .................................................................... 20 Figure 6: the two core algorithms of the Satellite Resource Scheduler........................... 23 Figure 7: AMP functional block diagram........................................................................... 24 Figure 8: SlotPoolContainer slot allocation and placement ............................................. 31


CONFIDENTIAL 9

1 PURPOSE OF THIS DOCUMENT

This document is part of the VIVALDI FP6 EU project - "Satellite Resource Manager" work package 5 deliverables.

The VIVALDI meta architecture model describes typical function blocks that together offer extensive support for session based services via satellite. It is the purpose of this document to describe the high level description of the Satellite Resource Manager functional blocks.


CONFIDENTIAL 10

2 APPLICABLE DOCUMENTS

# Title, Version,

/1/ FP6-2004-IST-4 027762 ;VIVALDI, Annex 1 – description of work

/2/ VIVALDI D2.3 System Technical Requirements Specification

/3/ VIVALDI D3.1 System Architecture Document

/4/ VIVALDI D5.2 Satellite Resource Manager – Recommendations to SatLabs

/5/ VIVALDI D2.4 Literature Study and Survey on Applicable Technologies

/6/ VIVALDI D3.3 Recommendations to SatLabs

/7/ SatLabs Guidelines

/8/ VIVALDI D6.1 Media Flow – Top Level Design

/9/ RRR: Recursive Round Robin Scheduler, Rahul Garg and Xiaoqiang Chen, In the Proceedings of the IEEE Global Telecommunications Conference, Globecom'98, November 1998. Sydney. Extended version appeared in Computer Networks 31(18): 1951-1966 (1999).


CONFIDENTIAL 11

3 DOCUMENT ORGANIZATION

This document is outlined as follows:

Section 4 this section describes where and how the Satellite Resource allocator within the Vivaldi defined Meta architecture.

Section 5 describes how the Satellite Resource allocator top level design fits within the work and guidelines performed within the SatLabs recommendations related to QoS.

Section 6 zooms in on the top level design of the Satellite resource allocator, identifying the two key process for the Satellite Resource allocator and providing also information on the different component which form the full Satellite Resource allocator functionality

Appendix A provides an overview of the algorithm optimization work and the related simulations which have been performed in the scope of the Vivaldi project.


CONFIDENTIAL 12

3.1 Conventions

The following terms are used to define the significance of particular requirements.

“SHALL” This word or the adjective “required” in the document signifies that the item is an absolute requirement of this specification.

“SHALL NOT” This phrase means that the item is an absolute prohibition of this specification.

“SHOULD” This word or the adjective “recommended” means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.

“SHOULD NOT” This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

“MAY” This word or the adjective “optional” means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.

Italicized text is descriptive or explanatory.

Each requirement is prefixed by a (type) in parentheses indicating the type of requirement. The following abbreviations are used to indicate the type of requirement.

Functional <F>, Performance <P>, Control <C>, Management <M>, Environmental <E>, Scalability <S>, Availability <A>.


CONFIDENTIAL 13

4 HIGH LEVEL META ARCHITECTURE DEFINED IN VIVALDI & SATELLITE RESOURCE ALLOCATION

VIVALDI evaluates means and enables satellite service providers to optimize interactive and broadband session based services via DVB-RCS.

The VIVALDI meta architecture model describes typical function blocks that together offer extensive support for session based services via satellite. The aim and functionality of these function blocks is quite broad.

Flo

w M

odu

le

Data Path

Module Controller

Config. Source

Signaling

Admission Control Unit

Push-Back Signaling

Signaling Server

Flo

w M

odu

le

Flo

w M

odu

le

Flo

w M

odu

le

Flo

w M

odu

le

Figure 1 – VIVALDI Meta Architecture

With respect to the satellite resource manager work package (WP 5) two groups within these function blocks can be distinguished:

The function blocks that are related and linked to the Satellite Resource Manager functionality:

Including the “Signalling Server” and the “Admission Control Unit” and to a lesser extent the module controller

And the function blocks that are mainly part of the media flow functionality:


CONFIDENTIAL 14

Including the “Flow Modules” and the “Module Controller”.

The Satellite Resource Allocator or Manager will grant and allocate the satellite capacity on the return links based on the requests coming in from the operator, the Signalling server and/or the requests signalled via the terminals bandwidth request classes.

In the VIVALDI Meta-Architecture the detection/handling of detected broadband or real-time (VoIP) streaming data is two-folded:

- The so called “Deterministic Approach” highly relies on e.g. addressing input provided by signalling components, bandwidth reservation components, or some pre-configured static e.g. address configuration. Especially due to the necessary interfacing or detailed address configuration – this deterministic approach comes with the burden of a higher complexity. At the same time it is the nature of this deterministic approach to provide more optimal performance (e.g. detection/prioritization already as of the first packet of a VoIP stream). And some desired features like not only prioritizing, but also configuring complex QoS setups like limiting the maximum number of VoIP per satellite terminal and signalling the end user when exceeding this maximum, will only be possible with support from outside the pure media flow. Within this approach the interfacing towards the Satellite Resource Allocator will be coming from (most likely) via the interfacing with the Signalling server and as such reserving the required bandwidth during the period of the VoIP session.

- In opposite to that the so called “Probabilistic Approach” for the media flow functionality provides the media flow components with functions that are mainly independent of e.g. signalling or bandwidth reservation. It thereby highly eases the setup/implementation of corresponding satellite services, provided much higher flexibility, support for plain “Internet like” broadband or real-time (VoIP) services, that do not use e.g. special VoIP servers or proxies of the satellite service providers. Within this approach, typically the bandwidth is directly requested through the DVB-RCS capacity request signalling between the terminals and the Satellite Resource allocator.

The figure below indicates the different approaches and interfaces related to the Satellite Resource Allocator. The detailed algorithms implemented in the Satellite resource allocator are specific to the companies and are part of the Newtec’s and Gilat detailed design specifications.

Appendix A provides an overview of simulations which were ran on a number of different algorithms during the ViValdi project.


CONFIDENTIAL 15

Figure 2 : Satellite Resource Allocator (Return Scheduler) and Interfaces

Return Schedulerterminal

RCS hub

ConnectionReservation

SIP/H.323 server VoIP signalling

Control plane intf. to satellite resource allocation

TBTP

Algorithms

DVB-RCS system domain

PC/VoIP

C2P

Flow

Mod

ule

RBD

C

Return Schedulerterminal

RCS hub

ConnectionReservation

SIP/H.323 server VoIP signalling

Control plane intf. to satellite resource allocation

TBTP

Algorithms

DVB-RCS system domain

PC/VoIP

C2P

Flow

Mod

ule

RBD

C


CONFIDENTIAL 16

5 SATELLITE RESOURCE ALLOCATOR TOP LEVEL DESIGN AND SATLABS RECOMMENDATIONS.

Prior and in parallel with the ViValdi project a lot of work on the support of QoS within the DVB-RCS layer has been done within the SatLabs forum. The ViValdi consortium partners Gilat, Newtec, Avanti and SatLynx, all four being active SatLabs members participated at these working group.

Therefore and also to keep the ViValdi work aligned with the DVB-RCS and SatLabs guidelines (/7/), the starting point and close follow with SatLabs was performed during the ViValdi project. Below the concept of the interaction between the terminal and the Hub part is given. (As also documented in /7/)

Figure 3: mapping L3 QoS into L2 QoS; marking the different components & paths

EF AF BE XX

RC1 RC2 RC3

MAPPING

MAPPINGRBDC

VBDC

AVBDC

L3 IP QOS

L2 DVB-RCS

Traffic path Request path

PID VP/VC Ch-id [0..15]

MA

PP

ING

MAPPING

RCxCRA

FCA

MA

PP

ING

MA

PP

ING

TBTPAllocationpath

CRARBDC

VBDC

AVBDC


CONFIDENTIAL 17

Figure 3 presents the mapping between layer 3 IP QoS and layer 2 DVB-RCS and also mapping within layer 2 DVB-RCS between several elements.

To better structure the diagram, three paths are identified, namely the Request path, the Traffic path and the Allocation path.

• The request path is based on the DVB-RCS signalling between terminal and Hub (NCC), at the end of the Request path, all request are processed by the Satellite Resource Allocator

• The Allocation Path signalling the allocated bandwidth towards the requesting terminals (via means of TBTP); This path start directly after the processed requests. The Satellite Resource Allocator is responsible for granting and allocating this bandwidth slots within the TBTP.

• The traffic path has no direct relation with the Satellite Resource allocator and is mainly interacting with the Media Flow. (see /8/)

5.1 IP Layer QoS

The RCST supports QoS differentiation in line with the DiffServ architecture. In this context the RCST may serve as an interior node in a DiffServ domain or as an edge node of the DS domain. A DS domain is a contiguous set of nodes operating with a common set of service provisioning policies and PHB definitions. This means that each node within the domain operates according to the same PHB specification. A DS domain boundary occurs between nodes where the service provisioning policy or PHB specification is changed going from one node to the other. A DS boundary node can be a node at the boundary between a DS-capable domain and a domain that is not DS-capable or between two different DS domains.

The DVB-RCS network can be regarded as a single DS domain as seen from the user. (Including both the NCC and terminal parts)

The RCST is recommended to support at least the 3 following PHBs:

• Expedited Forwarding PHB • At least one Assured Forwarding PHB Class (AF3) • Best Effort PHB

RCSTs may be capable of supporting additional PHBs.

As a DiffServ node the RCST is capable of mapping packets to the different PHBs supported by the DVB-RCS network. The classifier used to this end should map a packet to the PHB of choice based at least on the DSCP value in the packet header. In general an RCST will typically support classification based on additional criteria. (Media Flow part see /8/) As a DiffServ domain edge node, the RCST is also capable of remarking the DSCP field of packets.


CONFIDENTIAL 18

In particular, RCST packet dispatching delay and delay jitter is affected by the RCST performance, the traffic load on the RCST and the NCC slot assignment by the Satellite Resource Allocator.

The Satellite Resource Allocator is itself affected by the NCC performance, the assignment policy applied for the RCST (SLA management), the resource provisioning, the dynamic demand load on the NCC, the demand congestion policy applied by the NCC and the sufficiency of the dynamic demand expressed by the RCST.

5.2 MAC layer QoS

MAC layer QoS support consists in capacity request calculation/generation and scheduling/dispatching of packets from the supported queues to fill-up the assignments in TBTP.

5.2.1 DVB-RCS Request classes

Request Classes and PHB A Request Class (RC) is a representation of a PHB at the MAC layer (in the DAMA Controller). It defines a behaviour of the MAC layer for a given aggregation of traffic. This behaviour includes a combination of Capacity Categories associated to the RC and a Priority with respect to the other RCs supported by a RCST. As an example, an RCST can have two RCs using VBDC only: one has a priority over the other.

An RC is a concept similar to the PHB, but seen from layer 2. An RC can be seen as part of a PHB instantiation, since it will strongly influence the traffic forwarding.

The RCST maps each PHB onto an RC and it shall be possible to map any PHB to any RC. In general, several PHBs can be mapped to a same RC. Such a generic mapping is illustrated in Figure 4, which shows how several PHBs can get their demand aggregated and expressed as demand of a common RC. Several RCs can be served by a common Assignment Policy, as applicable.


CONFIDENTIAL 19

Request Class

Per Hop Behavior Request

ClassAssignmentPolicies

DVB-RCS Network

MAC protocol

RCST

NCCDAMA controller

Per Hop Behavior

Per Hop Behavior

Figure 4 - Aggregation of demand related to classification of traffic. For short term QoS an RCST has to support one RC per PHB with the following association:

• EF PHB is mapped to the Real-Time (RT) RC • AF PHBs are mapped to the Critical Data (CD) RC • BE PHB is mapped to the Best Effort (BE) RC •

The RCST may be capable of supporting additional PHBs and RCs.

The NCC shall explicitly instruct the RCST of which RC shall be used for each PHB, by assigning a corresponding RC to each of these PHBs.

The above SatLabs concepts have been adopted within the Top Level Design of the Satellite Resource Allocator.


CONFIDENTIAL 20

6 TOP LEVEL DESIGN OF THE SATELLITE RESOURCE ALLOCATOR

6.1 Satellite resource Allocator (or AMP) Functionality overview

The AMP is short for Air MAC Processor. MAC is the common abbreviation for Medium Access Control. As such its main functionality is to control the access to the satellite medium on the Return Link. AMP is the implementation name of the Satellite Resource allocator within the Newtec system lines.

Its main tasks can be listed as follows:

- Create the signalling tables - Control access to the network on L2 (logon/logoff) - Fairly distribute the available timeslots over the SITs(Scheduling) - Control network time synchronisation - Collect statistics about SITs and resources - Dynamic QoS: support of DiffServ mechanisms (Main VIVALDI focus part) - Rainfade mitigation (not within the scope of the ViValdi project)

Figure 5: AMP in the 2 way satellite system


CONFIDENTIAL 21

Figure 5 shows the AMP as it interacts with the other devices in a 2 way satellite network.

The AMP sends out MPEG/DVB-SI/DVB-PSI tables to the IP Encapsulator (IPE). The IPE encapsulates these tables (together with the IP data) in MPEG frames on an ASI link towards the forward Modulator (MOD). The MOD sends out a DVB carrier (S/S2) containing the encapsulated tables and IP data.

There are different “types” of tables. Some describe the satellite network composition, both in the return link (all the details of the superframe structure) and in the forward link (the different services and how to access them (data broadcast service and forward link signalling service being the most important)). Then there is the NCR table which contains a timestamp, providing a network clock reference.

Next there is the Terminal Burst Time Plan (TBTP). This table tells the terminals, who may burst on which slot in a superframe. It is sent out every superframe

Finally there is the Terminal Information Message table (TIM). This can be sent out in broadcast mode to all terminals (global time correction, QoS configuration settings) or in unicast mode to a particular terminal (logon TIM, logoff TIM, time correction TIM). The logon TIM, in particular, contains information that the terminal needs to know to come into operation.

With the information in these tables, the terminals have enough information to properly send out bursts on the return link slots. The burst demodulator (BDM) simply demodulates and decodes these bursts and sends out information about them to the AMP over UDP. The AMP then processes these bursts. There are 2 types of bursts: CSC and TRF. CSC bursts are used by a terminal to logon. TRF bursts are used by a terminal to convey payload towards the HUB and also to request additional TRF slots. Additional information sent along with each burst concerns signal level, time offset, frequency offset, terminal identification, payload status, decoding status etc...

The AMP then uses all this information to update the forward link tables, effectively closing the Layer 2 loop.

The AMP interfaces with several devices for management and configuration. First of all it interfaces with Provisioning from which it gets the configuration for the terminals (mainly the service level agreement).

Towards the Performance Management Tool (PMT), the AMP provides performance metrics about the SITs and resources.

The AMP has a specific interface for receiving dynamic terminal SLA parameter and bandwidth reservation through VoIP signalling interfaces updates from the Common Controller (COCO).

The AMP can also be configured on the fly on an RMCP interface exposed to the SEMS. This same interface is used by the SEMS to monitor certain parameters in real time (alarms, logged on sits, missed slots, etc.).

Next, the AMP acts as a ntp client to stay in sync with other devices in the HUB.


CONFIDENTIAL 22

The AMP runs on the 2 way satellite Linux platform and as such provides ssh access so that an operator can access log files and configuration files remotely.

Finally the AMP has a script to generate certain resource configuration files (for carriers, tables, etc.), not only for its own configuration but also for that of the BDMs. As input for the config files, it collects information directly from the DB through sql queries.

6.2 Design of two core functionalities: Allocation Algorithm, Placement Algorithm

The top level design of the Satellite Resource allocator is split into two major processes:

• The first process handling the received request coming from the terminals and carrying indication of the required QoS level (through indication of the Channel_ID). This allocation algorithm has to take account of:

o # of requested slots (bandwidth)

Through terminal request or through reservation (CoCo) Interface

o Associated requested QoS

o SLA assigned to this terminal

o Current load of the Network (congestion or not)

Resulting in two outputs:

The total of slots assigned to the different terminals; depending on the implementation the allocation granting can include BW QoS marking (the RCST will be able to transmit session data over session allocations) or without

RBDC Ack – If the BW request for the session was sent form the RCST (as RBDC req), the Satellite resource allocator can initiate a RBDC acknowledge for the relevant RCST.

• The second process starts with this information of granted slots and assigns the well defined places within the TBTP. The target of the placement algorithm is to place the slots on a per terminal basis as equidistant as possible, since this has proves (through simulations) to be the most performing in reducing the jitter. The optimized algorithm is based on the RRR: Recursive Round Robin Scheduler (/9/).


CONFIDENTIAL 23

Figure 6 : the two core algorithms of the Satellite Resource Scheduler.

Allocation algorithmes

List of logged on sits SAC (RBDC, VBDC) + CRA requests

Placement Algorithm

TBTPs

List of slots per SIT


CONFIDENTIAL 24

6.3 Static architecture of the Satellite Resource Allocator (AMP)

6.3.1 Component overview

Figure 7: AMP functional block diagram Figure 7 provides a functional block diagram of the software architecture of the AMP. The arrows represent the flow of information between the components. This section simply lists the different components in the AMP and elaborates on their responsibilities.

6.4 Component responsibility

6.4.1 AMP startup script This script is started at bootup after network and ntp.

It can also be manually run to control the amp, apy and associated watchdog processes. Functionality provided are: start, stop, status and restart.

“start” starts the amp and apy watchdog processes.

“stop” kills amp, apy, amp watchdog and apy watchdog processes.

“status” reports if amp, apy, amp watchdog and apy watchdog processes are running and with which PID.

“restart” is a “stop” followed by a “start”

AMP device

amp process

apy process

apy watchdog

amp watchdog

httpd

ntpd

platform daemons (snmpd, ripd, sshd, ...)

RTLinkInputParser BLA

SitManager

SITs

CoCoYami

TimeServer

Scheduler

PME SynchronisationModule

PMTwriter Output

AMP startup script

HD

AMP required libraries

ConfigServer

Ntp

SlotPoolContainerActorSlotPoolContainerActorSlotPoolContainerActor collect_config.pl script LoggedOn

Sits

Shaper

TableMaker

TableSender

VCI dispenser

ManagementInterface

RMCP Parser

SlotMap

CountersCountersCounters

WatchdogCLI

BurstContainer Burst Burst Burst Burst Burst

local time

config files pmt files output files other

SlotMapSlotMapTableQ1 TableQ1 TableQ1 TableQ1 TableQ1 TableQ1 TableQ1 TableQi TableQ1 TableQ1 TableQ1 TableQn ...

Common Controller

BDM

IPE

platformservices PMT SEMS

Provisioning

DB

TFS

Debug


CONFIDENTIAL 25

6.4.2 amp process This process performs the main functionality of the AMP device. Its components are described further on. Figure 7 shows which components belong to it.

6.4.3 amp watchdog This script is a while true loop around the amp process, which should never exit.

So if it would exit (e.g. due to a segfault), the watchdog starts the amp process again.

6.4.4 apy process APY is short for AMP Proxy. It is the RMCP interface of the AMP device for provisioning actions.

Basically the APY’s role is to change the provisioning.xml file and trigger the amp process (SitManager) to read this file and process it.

6.4.5 apy watchdog This script is a while true loop around the apy process, which should never exit.

So if it would exit (e.g. due to a segfault), the watchdog starts the apy process again.

6.4.6 httpd Standard Linux httpd daemon allowing the fetching of the pmt files present on the HD under /usr/local/amp/pmt/..

6.4.7 ntpd This is a class capable of checking if a given NTP server is stable.

It is used when SEMS polls the RMCP interface to check if the AMP NTP is stable.

6.4.8 platform daemons These are the 2 way satellite standard platform daemons such as sshd, snmpd, ripd ... Describing these is out of scope of this document.

6.4.9 Scheduler The Scheduler object runs at the heart of the AMP. Its thread controls the parsing of the inputs (BLA lookup, CocoMessage Queue parsing) and the sending of information of output (PMTwriter buffers, Tables).

A small task is also the resetting of the Synchronisation Module when no good bursts are coming in.

6.4.10 ReturnLinkInputParser This object listens on a specific multicast address for UDP messages coming from the BDM. It parses those messages into individual bursts and places them in the BurstContainer.

The information put there per burst, is the following:

- frequency: RF frequency the bursts was received on - timeslotId: CSC or TRF burst - RCSTcapacity: unused, see CSC burst syntax in [10] - macAddress: macAddress in a CSC burst


CONFIDENTIAL 26

- burstArrivalTime: expected arrival time of the burst - timeOffset: timeoffset of the burst with respect to the expected one - freqOffset: frequency offset of the burst with respect to the configured one - decodingStatus: does the burst have a CRC error or not - atmStatus: byte describing the status of the different ATM cells in the burst:

IDLE (no payload), USED, HEC (error in HEC of ATM header) - nrIterations: number of decoding iterations the BDM performed - C0: burst power level difference with the nominal BDM input level - EsNo: EsNo of the burst (indication of signal-to-noise ratio) - symbolrate: configured symbolrate of the related slot - SAC: SAC bytes of a TRF burst. See [10]. For 2 way satellite 1.5, the SAC

contains following fields: group_id (1 byte) logon_id (2 bytes) request type (1 byte) request value (1 byte)

- VpiVci: VPI VCI of one of the ATM cells in the burst ((0,0) for an IDLE burst)

6.4.11 BurstContainer This is the queue of incoming bursts.

6.4.12 BLA BLA is short for Burst Lookup Actor. The BLA processes the bursts of the BurstContainer based on the information from the SITs and from the SlotMaps in the scheduler. The latter contain information about the TBTPs scheduled during recently passed superframes. To do the lookup, there should be at least a RTT worth set of SlotMaps.

The outcome of a processed burst is an annotated slot which is passed to the PME. In case of a CSC burst, a logon can be directly triggered for a provisioned SIT.

A burst object contains the burst content, arrival time, frequency plus various measurements.

An annotated slot encapsulates this burst object and adds some additional information:

superframe count: Superframe count at which the burst was received

ownerSit: Sit that own this slot (TBTP assignee or CSC MAC address owner)

burstingSit: Sit that burst on this slot (can differ from owner)

frameid: Frame id of the slot (unique within the superframe)

carrierid: Carrier id of the slot (unique within the frame)

slotid: Slot id of the slot (unique within the pair (frame,carrier))

AMPGenerated: Is the slot generated by the AMP (assigned, no burst reported)

stolen: Is this slot stolen (VPI/VCI or group_id/logon_id does not match owner)


CONFIDENTIAL 27

The BLA keeps 2 Counter objects:

- Number of not annotatable slots: this indicates the number of bursts that arrived which failed the BLA lookup (e.g. BDM config doesn’t match AMP config).

- Number of bursts out of window: this indicates the number of bursts whose NCR timestamp does not fall in the set of SlotMaps provided by the Scheduler (this indicates a timing mismatch between the AMP and the BDM (i.e. SEMS)).

6.4.13 PME PME is short for Performance Management Engine. The PME takes Annotated Slots as input from the BLA and the Scheduler (AMP generated).

It handles following responsibilities:

- Sends frequency offset and time offset information to the Synchronisation Module.

- Provides the associated SIT objects with info about if the annotated was “good” or “bad”. The SIT then decides, based on the “bad” burst threshold it has, to logoff or not. “bad” can mean for example, the slot was assigned but the burst received was not decodable.

- Checks if the associated SIT sent idle ATM cells for a period larger than a configurable threshold. If so the SIT is logged off.

- Finally pushes the annotated slots further to the PMTwriter, so it can aggregate them.

- The PME keeps 2 Counter objects:

- Number of missed bursts: this indicates the number of “bad” bursts - Number of OK bursts: this indicates the number of bursts “good” bursts

6.4.14 Synchronisation Module

This object gets frequency and time offsets from the PME.

6.4.15 ntpd Standard Linux ntp daemon which polls a set of ntp servers i.e. the TFS-A and TFS-B GPS receivers. It adapts the local time such that the AMP is synchronised with absolute time.

6.4.16 Local time The local clock of the AMP server.

6.4.17 TimeServer An object providing the NCR time based on the local clock.

6.4.18 Ntp A class capable of checking if a given ntp daemon is stable. This check is done when requested through an RMCP call for an ntp alarm (typically by the SEMS).


CONFIDENTIAL 28

6.4.19 HD The hard disk plays the usual role on a Linux server (contains executables, logfiles ...). Specifically for the AMP, it contains the config files (/usr/local/amp/), the pmt files (/usr/local/amp/pmt/) and the output files (/usr/local/amp/output/).

6.4.20 Management Interface The management interface is an interface class which is used a buffer between the amp functionality and RMCP for provisioning commands (can be lengthy in time).

6.4.21 Counters Several components make use of the Counter objects to make certain metrics available to the RMCP interface expressed in a number per second. A single thread is started for all counters to achieve this.

Examples are: BurstContainer (received packets/sec ...), BLA (not annotatable bursts/sec, out-of-window/sec), PME, Scheduler (missed slots/sec), tablesender (tablessend/sec,...), sitmanager (csc failed/sec).

6.4.22 Watchdog A class providing a thread which aggregates multiple keepalive signals (from distinct threads) into a single watchdog keepalive. Currently unused. Can be used to work with a hardware watchdog.

6.4.23 CLI The class DebugClass is used to implement a CLI. Other objects can register debug commands to allow a user some debugging functionality on them. E.g. SitManager registers a debug command to logon a sit.

6.4.24 collect_config.pl script A script which can be manually run to collect the information related to the Access Layer from the DB through mysql queries. Based on this information it generates the carrierinfo.xml, 2 way satellite.xml and tableConfig.xml files needed by the AMP. It also generates the BDM init files to be used by the SEMS.

6.4.25 VCI dispenser An object that dispenses a VCI upon request (SIT creation) and keeps track of all VCIs assigned. This implies a single VPI per AMP (the value “3” is used for the 2 way satellite VPI).

6.4.26 CocoYami CocoYami is short for Common Controller Yet Another Management Interface. It replaces the original RMCP based interface and is used by the Common Controller in a 2 way satellite system. The COCO typically acts as part of a FUP service or bandwidth reservation system.

6.4.27 RMCP Parser The RMCP Parser is responsible for parsing the RMCP requests towards the amp process. Typical usage of this interface is by SEMS, which polls certain RMCP variables, such as the PME’s number of OK bursts, device alarms, etc. An AMP user (e.g. SEMS)


CONFIDENTIAL 29

can also use this interface to dynamically configure certain AMP internal settings, such as FCA allocation or not, setting scheduling parameters, etc. Finally, this interface is also used by the apy process to trigger the parsing of the (modified) provisioning.xml by the SitManager.

6.4.28 Debug The Debug block provides the mechanism for other blocks to send debug/log strings towards the standard output and dedicated outputfiles. Besides the string, a level and id is provided. The Debug block uses the level to filter out unwanted info up to a certain level (predefined to allow everything, changeable through CLI). The id is used to identify the “domain” of the message. For example, “domain” could be BLA or Config. Typically, only a certain set of “domains” are allowed to pass through.

6.4.29 Output The output block is a thread that gets string input from the Debug block. It buffers the string inputs and writes them to the relevant log files every ¼ second.

6.4.30 PMTwriter This object is responsible for writing performance data to disk. Its main function is the aggregating of information from the annotated slots from the PME, information from the SITs (logon/logoff events) and information from the SlotPoolContainerActor (capacity scheduling information, number of logged on sits...). The information is aggregated every 5 minutes (configurable in the PMT.xml file).

6.4.31 TableMaker The TableMaker is responsible for creating the static tables (i.e. the tables sent out at a regular interval) and pushing them to the TableSender queues together with their interval. All intervals are by default 1 second, unless if configurable.

An exhaustive list of those static tables:

NCR Network Clock Reference (configurable, set to 40ms)

PAT Program Association Table

NIT Network Information Table (configurable: transmit enabled/disabled)

SDT Service Description Table

PMT Program Map Table (for the RMT program)

SPT Satellite Position Table

RMT RCS Map Table

RCS_PMT Program Map Table (for the RCS forward link signalling service)

SCT Superframe Composition Table

FCT Frame Composition Table

TCT Timeslot Composition Table

WCT Waveform Composition Table (Sat3Play systems only)


CONFIDENTIAL 30

BTIM Broadcast Terminal Information Message (used to broadcast the 2 way satellite QoS descriptor to all terminals)

6.4.32 TableSender The TableSender has a set of Table queues (corresponding to Table types) which it continuously loops around to see if the time has come to send a Table from that queue. It sends the tables as MPEG data encapsulated in UDP packets towards the IPE.

Tables are added once to their queue with an interval different from zero for the static tables. For more “dynamic” tables, they are placed on a table queue with an interval zero. When sent, they are removed from the Queue. Such tables are the TBTP, which is added each superframe by the Scheduler. And also the TIM which can be sent by the SITs (logon/logoff/wake-up) or the Synchronisation Module (unicast and broadcast 2 way satellite correction TIM).

6.4.33 SitManager The SitManager contains the set of provisioned SIT objects and controls the access to them, such as lookup and provisioning

6.4.34 Scheduler The Scheduler is the object that contains the main loop of the AMP. It is responsible for TBTP computation, grabbing the bursts from the BurstContainer and passing them to the BLA, passing reprovisioning triggers to the SitManager and finally triggering the CocoYami to process its queued messages. All these tasks are performed in a round robin fashion.

The TBTP computation is performed by triggering all SlotPoolContainerActors to calculate the slot allocation and placement of their part of the TBTP.

6.4.35 SlotPoolContainerActor A SlotPoolContainerActor is an object responsible for the allocation and placement of slots that belong to its SlotPoolContainer. A SlotPoolContainer consists of a set of SlotPools. A SlotPool is typically mapped to a single Carrier (possibly repeated over multiple frames in time, not so in 2 way satellite). A Carrier consists of a set of slots on the same frequency. Only TRF slots can be part of a SlotPoolContainer.

Figure 8 gives an overview of the slot allocation and placement actions performed by the SlotPoolContainerActor each superframe. First CRA shaping is done, then VBDC shaping. If the “Keep Alive affects FCA” is enabled, the Keep Alive safety check is performed before Free Capacity allocation. Otherwise Keep Alive follows FCA. Finally, the allocated number of slots are placed one dedicated slots in the TBTP by the Placer.


CONFIDENTIAL 31

Figure 8: SlotPoolContainer slot allocation and placement

sumsumsumsum

CRA shaping

LoggedOnSIToutst. req VBDC cellsoutst. KA VBDC cellsmaxCRAslots/SFclippedmaxVBDCslots/SFclippedweightNrSlotsThisSFtime next sendKAslot

LoggedOnSIT

VBDC RBDC shaping

LoggedOnSITLoggedOnSIT

CRA fromVBDC?

Weightingenabled?

LoggedOnSITLoggedOnSITLoggedOnSIT

KA option 1

KA affects FCA?== y


FCA

FCA enabled?


FCA fromVBDC?

KA option 2


KA affects FCA?== n

Placer


R3MS version

Total Nr Slots

numFCAslots

CRA used

Total Nr Slots

numFCAslots

CRA used

VBDC - RBDCRoundRobin Pos

FCARoundRobin Pos

Total Nr Slots

Total Nr Slots

Total Nr Slots Total Nr Slots

Nr Slots per freq

oldMap

sumsumsumsum

CRA shaping

LoggedOnSIToutst. req VBDC cellsoutst. KA VBDC cellsmaxCRAslots/SFclippedmaxVBDCslots/SFclippedweightNrSlotsThisSFtime next sendKAslot

LoggedOnSIT

VBDC RBDC shaping

LoggedOnSITLoggedOnSIT

CRA fromVBDC?

Weightingenabled?


KA option 1

KA affects FCA?== y


FCA

FCA enabled?


FCA fromVBDC?

KA option 1

KA affects FCA?== y


FCA

FCA enabled?


FCA fromVBDC?

KA option 2


KA affects FCA?== n

Placer


R3MS version

Total Nr Slots

numFCAslots

CRA used

Total Nr Slots

numFCAslots

CRA used

VBDC - RBDCRoundRobin Pos

FCARoundRobin Pos

Total Nr Slots

Total Nr Slots

Total Nr Slots Total Nr Slots

Nr Slots per freq

oldMap


CONFIDENTIAL 32

Appendix A OVERVIEW OF SIMULTATION RESULTS


CONFIDENTIAL 33


CONFIDENTIAL 34


CONFIDENTIAL 35

As already mentioned, the basis algorithm is the RRR (Recursive Round Robin) ((/9/).

Three variants have been explored and simulated, resulting in the following outcomes.

Simulations were made for a Uniform packet distribution and for a packet distribution collected from a real life operational network.

Packet distribution from operational network:


CONFIDENTIAL 36

Simulation results:

• Uniform distribution

Algorithm Max (max)

E(max) Max (sum)

E(sum)

PL-AMP 1 15.6 3.8 15.7 5.5

PL-AMP 2 14.1 3.7 15.2 5.2

PL-AMP 3 12.7 4.0 14.0 5.4

• Operational network distribution

Algorithm Max (max)

E(max) Max (sum)

E(sum)

PL-AMP 1 43.8 17.7 65 34.0

PL-AMP 2 24.0 5.7 32.5 11.6

PL-AMP 3 24.0 4.8 25.0 9.7